URL redirects and rewrites are essential for handling site restructuring, legacy URLs, and clean URL patterns on a static site — this guide covers implementing both effectively with Nginx.
Redirects vs Rewrites: The Key Difference
A redirect tells the browser "go to this different URL instead" (visible URL change, an actual round-trip); a rewrite serves different content for a URL internally without the browser knowing/URL changing — different use cases, and conflating them causes confusion.
Setting Up 301 Redirects for Moved Content
location = /old-page.html {
return 301 /new-page.html;
}
A 301 (permanent redirect) tells search engines and browsers this content has permanently moved — important for preserving SEO value when restructuring content, similar in spirit to general redirect map practices.
Redirecting an Entire Old Path Structure
location ~ ^/blog/2023/(.*)$ {
return 301 /articles/$1;
}
Pattern-based redirects handle bulk URL structure changes without needing individual redirect rules for every single affected page.
Setting Up Clean URLs (Rewriting .html Extensions Away)
location / {
try_files $uri $uri.html $uri/ =404;
}
Allows /about to serve /about.html without the extension appearing in the URL or requiring a visible redirect — a rewrite, not a redirect, since the URL the visitor sees doesn't change.
Handling Trailing Slash Consistency
rewrite ^/(.*)/$ /$1 permanent;
Choose one consistent convention (with or without trailing slash) and redirect the other to it — avoids duplicate content issues from the same page being accessible at two different URL forms.
Redirecting Non-WWW to WWW (or Vice Versa)
server {
server_name olddomain.com;
return 301 https://www.yourdomain.com$request_uri;
}
Building a Redirect Map for a Major Site Migration
See redirect map practices discussed in broader site migration contexts — for significant restructuring affecting many URLs, build a systematic mapping (old URL to new URL) rather than ad-hoc individual rules, ensuring comprehensive coverage and easier maintenance.
Testing Redirects After Deployment
curl -I https://yourdomain.com/old-page.html
Verify the correct status code (301) and target location header, confirming redirects behave as intended before relying on them in production.
Avoiding Redirect Chains
A redirects to B redirects to C creates unnecessary extra round-trips and can confuse search engine crawlers — where possible, update redirects to point directly to the final destination rather than accumulating chains over successive restructurings.
Common Errors
Redirect works in browser but search engines still show old URL — search engine re-crawling and index updates take time even after correct 301 redirects are in place; this is expected latency, not necessarily a configuration problem.
Continue Reading
- How to Configure Nginx for Single Page Applications (SPA Routing)
- How to Handle 404 Pages Correctly on a Static Site
- How to Set Up a Sitemap and robots.txt for a Static Site
Browse more articles in Static Site Hosting & Frontend Deployment.