Redirect rules are boring. And then one day they’re very exciting because your migration went live and now half your URLs are 404. (Fun.)

This guide shows a sane way to generate Nginx redirects from a URL list: map old → new, export rules, test, and avoid redirect chains. We’ll use TinyUtils Sitemap Delta because it’s built for this exact job.

TL;DR

  1. Get your old URL list (old sitemap, logs, exports).
  2. Get your new URL list (new sitemap, staging crawl).
  3. Compare them in Sitemap Delta.
  4. Export Nginx rules and test the top URLs.
  5. Fix chains and weird edge cases before launch.

Step 1: Get the right inputs

Old URLs

  • Old sitemap (best)
  • Server logs (great for “what people actually hit”)
  • Analytics exports / Search Console coverage

New URLs

  • New sitemap (best)
  • Staging crawl (good if sitemap isn’t ready)
If you only do one thing: include your high-traffic URLs. Fixing 20 important redirects beats “technically mapped 5,000” every time.

Step 2: Map old → new (don’t wing it)

The goal is to send users to the closest relevant page. Avoid the lazy pattern of redirecting everything to the homepage. It’s a bad user experience and it makes analytics useless.

TinyUtils Sitemap Delta helps by comparing old and new lists, clustering patterns, and exporting redirect rules.

Step 3: Generate Nginx rules

In Nginx, redirects are often done with return 301 or rewrite. Here are common patterns (examples only — your site may differ): 

# Exact match (simple and clean)
location = /old-page/ {
  return 301 /new-page/;
}

# Match both /old-page and /old-page/
rewrite ^/old-page/?$ /new-page/ permanent;

# Folder move example
rewrite ^/old-section/(.*)$ /new-section/$1 permanent;

Rules should be:

  • Specific before wildcard (so you don’t accidentally redirect too much).
  • Consistent about trailing slashes and casing.
  • Deliberate about query strings (don’t “maybe” handle them).
  • Readable enough that Future You can audit them at 2am.

301 vs 302 (don’t overthink it, but don’t guess)

For migrations, you usually want 301 (permanent) redirects. Use 302 (temporary) when you genuinely plan to change it back soon — like a short campaign, a temporary maintenance page, or an A/B test. If you’re moving URLs “for good”, 301 is the default.

Query strings: keep, drop, or map?

The sneaky redirect bugs usually involve query parameters. Decide what your policy is and make it consistent:

  • Keep: good when parameters matter (filters, search, pagination).
  • Drop: good when they’re just tracking (UTM) and you want clean URLs.
  • Map: only when you have a real 1:1 parameter change between old and new systems.

“We’ll figure it out later” turns into redirect loops and analytics chaos. Pick a rule early.

Step 4: Test (before you deploy, not after)

Testing doesn’t need to be fancy. It just needs to exist.

What to test

  • Top 20–50 old URLs (traffic + backlinks)
  • Templates (blog posts, categories, product pages)
  • Edge cases (uppercase, trailing slash, old folders)

How to test

Use curl and confirm status codes and destinations: 

curl -I https://example.com/old-page/

If you want to follow the redirects and see the final landing page: 

curl -I -L https://example.com/old-page/

If you have a list of URLs, you can test a bunch quickly: 

# urls.txt contains full URLs (one per line)
cat urls.txt | xargs -n 1 -I{} sh -c 'echo \"--- {}\"; curl -sI {} | head -n 5'

You want: 301 from old → new, then 200 on the destination. If you see multiple redirects before the final 200, you’ve created a chain.

Common mistakes (avoid these)

  • Redirect chains: A → B → C. Update rules so A goes directly to C.
  • Looping redirects: usually a trailing slash or HTTP/HTTPS mismatch.
  • Overbroad wildcards: redirecting too much can break unrelated pages.
  • Forgetting canonical redirects: handle http → https and www vs non‑www cleanly and early.
  • Forgetting internal links: fix internal links so they don’t rely on redirects.

Next steps

If you have old + new sitemaps, go straight to TinyUtils Sitemap Delta. Export rules, test the top URLs, and ship. Your future self (and your Search Console graphs) will thank you.

Also: keep your redirect rules in version control if you can, with a short note about why they exist. Redirect files tend to outlive the people who wrote them.