Skip to content 
Rule-based redirects with NGINX ensure structure, rankings and loading times - I use nginx redirect rules clearly, quickly and testably. In doing so, I use return for performance and rewrite for patterns, keep status codes clean and prevent chains and loops [1][3].
Key points
- return for fast single redirects, rewrite for samples [1][3]
- 301 for permanent, 302 for temporary - note ranking transfer [3]
- HTTPS and force query strings with $is_args$args received [1][5]
- Regex economical, rules consolidate and test [3]
- Monitoring from chains, 404 and Indexing after rollout
NGINX directives briefly explained
NGINX offers two ways of forwarding: return and rewrite. I use return if I want to redirect a single, clearly defined URL because the server then responds immediately without regex [1][3]. If I need to evaluate patterns, groups or variables, I use rewrite and regulate the flow with flags such as permanent or break [1][7]. Both approaches complement each other, but return remains the first choice for simple cases, as every evaluation saved reduces the latency [3]. This is how I keep configurations lean, easy to read and yet Flexible.
Contexts and execution sequence in NGINX
I take into account the Sequence of processing: First NGINX selects the appropriate server block via server_name, then location matching takes effect (prefix-based locations before regex, and the longest match wins) [1]. rewrite-statements at the beginning of the server take effect early, flags such as last start a new location search, break ends the rewrite phase, while return responds immediately. This allows me to plan where a rule needs to live: global canonicals in server{}, fine-grained patterns in matching location{} blocks.
# Example: early, unique redirects
server {
listen 80;
server_name alt.example.tld;
return 301 https://neu.example.tld$request_uri;
}
When to return, when to rewrite?
I set returnif no pattern is necessary and the target URL is fixed; this way I get the best results. Performance [1][3]. For patterns such as path groups, case insensitivity or path preservation, I need rewrite with regular expressions [5][7]. Example: A domain move with path transfer can be solved elegantly with rewrite and $1 [1]. Individual old product pages that point to a new route can be mapped more quickly and securely with return [3]. This clear scheme prevents subsequent rule collisions and makes audits easier.
Implement canonicalization consistently
I determine early on how paths normalized can be set: Trailing slash yes/no, remove index files, www variant and host canonicalization [3]. This results in fewer special cases.
# variant without slash: /category/ → /category
rewrite ^/(.+)/$ /$1 permanent;
# variant with slash: /category → /category/
rewrite ^/([^.?]+)$ /$1/ permanent;
# Standardize index files
rewrite ^/(.*)/index.(html|htm|php)$ /$1/ permanent;
I stick to $uriif I need a normalized path base, and to $request_uriif the complete original call including query is important for the target. For safe parameter transfer, I prefer to use $is_args$args one [5].
Select status codes correctly
The status code controls how crawlers and browsers interpret a redirect, so I decide it very aware. For permanent moves, I transfer signals via 301 and thus create Clarity for index and user [3]. A 302 signals temporary redirects, for example for tests, banners or short-term A/B routes. 307/308 preserve the method and are suitable for APIs or form POSTs. The following table shows a compact classification of common codes.
| Code | Use | SEO effect |
|---|---|---|
| 301 | Permanent detour | Signals are transmitted, index updated [3] |
| 302 | Temporary route | Old URL remains, signals do not go completely with [3] |
| 307 | Temporary, method remains | Useful for form POSTs and APIs |
| 308 | Permanent, method remains | Stable for permanent API routes |
Refine status codes: use 410/451 correctly
When contents permanently removed I use targeted 410 Goneinstead of blindly redirecting to a category. This means that outdated URLs disappear from the index more quickly and users receive a clear signal. For legally blocked content, I use 451. The key is consistency: I maintain a list for series of discontinued products, which I periodically transfer to the configuration.
# Remove targeted
location = /landing/action-2023 { return 410; }
Securely redirect HTTP to HTTPS
I consistently forward unencrypted calls to HTTPS so that users and crawlers only see the safe variant [1]. The return variant is short, fast and holds query parameters automatically if I use $request_uri or $is_args$args use. This prevents duplicate content and unnecessary chains via intermediate destinations. If you want to learn more about the background to certificates and SSL setups, you will find practical tips in this compact HTTPS forwarding. It remains important: I define exactly one canonical host variant so that crawlers keep the correct reference stable [3].
Secure HTTPS: HSTS and caching
After stable HTTPS conversion I activate HSTSso that browsers can make encrypted requests directly in future. I start conservatively and then increase the duration when all subdomains are prepared. I also control the Caching-semantics for redirects to avoid unnecessary revalidations.
# Only use HSTS on HTTPS servers
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# Explicit caching hints for persistent redirects
location = /alt/kontakt {
add_header Cache-Control "public, max-age=86400";
return 301 /contact/;
}
Set up RegEx redirects cleanly
For patterns I deliberately use Regex but keep it concise and easily testable [3][5]. The tilde operator activates patterns in the location block, while ~* is case-insensitive and thus covers typical typing variants [5]. Groups allow me to group related routes together and take the remaining path with $1 [1]. I avoid extremely broad patterns like .* and prefer concrete path anchors to keep the engine lean [3]. I document each rule briefly so that later extensions can be implemented without breaks. function.
Avoid if-traps and use map
I set if sparingly and prefer to use mapto make decisions outside of request processing to meet [3]. This is how I decouple logic from locations and keep the configuration robust.
# Bundle legacy matrix with map
map $uri $legacy_target {
default "";
/alt/about-us /about-us/;
/alt/shipping /service/shipping/;
}
server {
if ($legacy_target != "") { return 301 $scheme://$host$legacy_target$is_args$args; }
}
Keep query parameters correctly
I save all parameters with $is_args$args or $request_uri, so that tracking, filters and pagination are retained [5]. If I only need a specific value, I extract it via $args and regulate the target route with set and the appropriate variables [5]. This way, users land directly on the right product or search page without losing their selection. This care reduces bounces because user flow and context are retained. For crawlers, this creates a clear, consistent Target.
Clean up parameters instead of losing them
Sometimes I want certain tracking parameters Removewithout losing information. I work with $args and mapto form a clean variant and then forward canonically. In this way, I reduce duplicates without disrupting the user flow [3][5].
# Example: remove utm_*, keep essential filters
map $args $clean_args {
default $args;
~*^(.*)(?:&)?utm_[^&]+(.*)$ $1$2;
}
location /category/ {
# only redirect if the query really changes
if ($args != $clean_args) {
return 301 $scheme://$host$uri$is_args$clean_args;
}
}
Avoid grinding and chains
I prevent Loopsby clearly limiting conditions and never forwarding from A to A [3]. I slow down chains by always pointing directly to the final destination and deleting intermediate stations [3]. In CMS setups, I also check whether plugins generate already-redirects so that no duplicate rules are created. In the event of problems with CMS plugins, a quick check for known traps around a Redirect loop in WordPress. This keeps the server lean and the user reaches the destination in one go. Hop.
Security: Prevent open redirects
I do not allow any open redirects that are not from parameters blind take over. Instead, I whitelist allowed hosts/routes and block everything else.
# Secure /go?dest=... with whitelist
map $arg_dest $go_ok {
default 0;
~^https?://(partner.tld|trusted.tld)(/|$) 1;
}
location = /go {
if ($go_ok = 0) { return 400; }
return 302 $arg_dest;
}
Bundle and test rules
I summarize similar patterns in a Rule and keep the order clear so that blocks do not interfere with each other [3]. Before each rollout, I check the syntax with nginx -t and reload the configuration to avoid downtime. I use curl -I to verify the status code, target and header and keep the test cases in a small checklist. For Apache migrations, I compare existing htaccess redirects and transfer them to NGINX structures. This keeps the file short, maintainable and legible.
Logging and transparency
To see the effect and side effects, I separate 3xx-Logs. This allows me to quickly recognize chains, outliers and incorrect rules and to make targeted changes if necessary [3].
# Write 3xx requests to a separate log
map $status $is_redirect {
default 0;
~^30[12378]$ 1;
}
log_format redirects '$remote_addr - $time_local "$request" $status '
'$bytes_sent "$http_referer" "$http_user_agent"';
access_log /var/log/nginx/redirects.log redirects if=$is_redirect;
Examples from relaunch and migration
During the relaunch, I create redirect matrices that assign each old URL to exactly one Goal assign. I group category paths into patterns and direct them to the new store logic, while individual top sellers point to new detail pages via return. In the case of a domain migration, I always adopt the entire path so that deep links and backlinks remain without friction [1]. For trailing slashes, I define a clear line so that each route only has one valid variant. The same applies to www vs. non-www - I choose a host form and redirect strictly to this Variant [3].
Internationalization and geotargeting
For multilingual performances I rely on Stable URL structures (e.g. /de/, /en/) and avoid forced redirects based on Accept-Language. If I use speech recognition, then careful as a 302 with a clear option to change the language. For country subshops, I check that crawlers can retrieve any variant without geo-redirects and that there are no unwanted 301s [3].
NGINX architecture: Why it's fast
With redirects, I benefit from the event-driven architecture of NGINX, because it serves many connections with few processes [2]. The master manages workers that efficiently accept and respond to thousands of requests in parallel [2]. In contrast to thread-heavy setups, this saves RAM and reduces context switches, resulting in short response times even under high load [2]. Shorter TTFB values help rankings and increase click satisfaction. This architecture predestines NGINX to use redirects even during traffic peaks. fast to be delivered.
Cooperation with CDN and Upstream
If a CDN already uses Host/HTTPS canonicals I deactivate the duplicates in NGINX - or vice versa. A source of truth is important. For edge redirects, I only use the CDN engine if the decision is data at the edge everything else remains in NGINX. This way I avoid divergent rule sets and keep latency and maintenance under control [3].
Monitoring after the rollout
After unrolling, I observe Crawl errorstatus codes and indexing so that every redirect works as planned [3]. In the Search Console, I check 404, soft-404 and conspicuous chains, while I check crawler reports at intervals. I also check loading times, because every unnecessary hop costs time and budget. In the event of anomalies, I adjust rules at an early stage and keep a history of changes to be able to track effects. This constant controlling keeps the redirect landscape healthy.
Briefly summarized
I set return for simple targets, rewrite for patterns and keep status codes unique - so signals are preserved and routes remain clear [1][3]. HTTPS redirects, parameter preservation and a fixed host variant prevent duplicate content and strengthen consistency [1][5]. A few, well-bundled rules beat many small, regex-heavy entries because maintenance and performance benefit [3]. Tests with nginx -t and curl as well as ongoing monitoring ensure quality over the entire life cycle. If you follow these guidelines, you can build a lean redirect strategy that reliably supports user flow and rankings.
