WordPress站点Nginx正则重定向需排除打印页面的问题求助

Got it, let's sort out this redirect problem for your WordPress blog. The key here is to redirect all unwanted suffixes on your post slug, but leave the print-friendly URLs untouched—no more accidental redirects or loops.

Option 1: Use Location Priority (Most Reliable) #

Nginx processes location blocks in order of priority, so we can first "whitelist" the print pages, then handle the redirect for everything else. Here's the config:

# First, catch the print URLs and pass them straight to WordPress
location ~* ^/easy-fluffy-american-pancakes/print/\d+$ {
    try_files $uri $uri/ /index.php?$args;
}

# Then, redirect any other path under your slug to the main post URL
location ~* ^/easy-fluffy-american-pancakes/.+ {
    return 301 $scheme://$host/easy-fluffy-american-pancakes/;
}

This works because Nginx will match the print URL rule first (since it's a regex location placed before the redirect rule) and skip the redirect entirely for those paths. All other extra suffixes will hit the second rule and get redirected correctly.

Option 2: Single Regex with Negative Lookahead #

If you prefer a single location block, you can use a negative lookahead assertion (Nginx supports PCRE regex by default, so this should work). This regex explicitly excludes paths starting with print/ followed by numbers:

location ~* ^/easy-fluffy-american-pancakes/(?!print/\d+).+ {
    return 301 $scheme://$host/easy-fluffy-american-pancakes/;
}

Breaking down the regex:

• ^/easy-fluffy-american-pancakes/ matches the start of your post's slug path
• (?!print/\d+) is the negative lookahead: it means "don't match if the next part is print/ followed by one or more digits"
• .+ matches any remaining characters after the slug

Why Your Original Regex Failed #

The regex you tried (^/easy-fluffy-american-pancakes/(.+)|(?!print/[0-9]*/)) had two critical issues:

1. The logic was reversed—you were either matching any suffix OR excluding print paths, which created conflicting, unpredictable matches.
2. It didn't account for Nginx's matching order, leading to either no matches at all or redirect loops when the redirected URL accidentally matched the rule again.

Quick Testing Tips #

• Use 302 temporary redirects first instead of 301—browsers cache permanent redirects, which can make testing a headache. Switch to 301 once you confirm everything works.
• Double-check your WordPress permalink settings to ensure they don't clash with Nginx's rules.
• If you need this for multiple posts, you can generalize the regex (e.g., ^/([^/]+)/(?!print/\d+).+), but be careful not to break other valid subpaths like category pages.

内容的提问来源于stack exchange，提问作者David Brossard