Redirect Rule Generator

The Pitfalls of Using 302 for a Site Redesign

If a URL has changed for good, use a 301. This isn't a matter of preference. A 301 is a signal to "forget the old URL and use the new one," prompting search engines to transfer the index and existing ranking signals to the new address. A 302 means "go somewhere else for a bit," so search engines keep the old URL in their index.

Using a 302 for a redesign leads to this state a few months later: the old URL keeps appearing in search results, the new URL isn't indexed, and the value of any new links you build gets trapped at the old address. Even if you later fix it with a 301, it takes more time for things to transfer again.

Conversely, using a 301 for something you plan to revert is also risky. Browsers cache 301s aggressively, so even after you remove the rule, visitors' browsers will keep redirecting to the new address for a while. For things you'll soon roll back, like event pages or maintenance notices, use a 302.

Chains and Loops — What This Tool Catches

A redirect chain is a sequence like A→B→C. They often happen after multiple site redesigns. If you set up /old→/new in the first redesign, and then add /new→/final in the second, visitors coming to the old URL get bounced twice.

Google will generally follow a few hops, but each step adds a round-trip, slowing down the page load and wasting crawl budget. The perceived speed difference is significant on mobile. The solution is simple: update the old rules to point directly to the final destination. Create two lines: /old→/final and /new→/final.

This tool warns you if it finds a chain within the rules you've entered and shows you the actual path. It also catches infinite loops that redirect to themselves. However, it can't know about chains created by old rules already on your server, so you should check your existing configuration files before deploying.

# Check how many hops a redirect actually takes — -L follows all the way
curl -sIL https://example.com/old-page | grep -E "^HTTP|^[Ll]ocation"

# Example result (2-hop chain — needs fixing)
#   HTTP/2 301
#   location: https://example.com/new-page
#   HTTP/2 301
#   location: https://example.com/final-page
#   HTTP/2 200

URL Migration Process for a Site Redesign

Following these steps can minimize ranking loss. This is a battle-tested process.

1. Gather a complete list of old URLs. Combine data from Google Search Console's Pages report (indexed URLs), your existing sitemap.xml, web server access logs, and other webmaster tools (like Bing's). Using logs helps you catch URLs that even search engines don't know about.
2. Map old URLs to new ones on a 1-to-1 basis, starting with the pages that get the most traffic. If you're short on time, accurately mapping just the top 20% of URLs can preserve most of your traffic.
3. Copy your mapping list, created as two columns in a spreadsheet (Old URL / New URL), and paste it directly into this tool.
4. Apply the rules to a staging environment first. Spot-check a few URLs with `curl -I`, then deploy to production (e.g., `nginx -t → systemctl reload nginx`).
5. Replace your sitemap with one containing the new URLs and resubmit it. Also, update all internal links to point directly to the new addresses. Don't let your own site rely on redirects.
6. If you also changed your domain, use Search Console's Change of Address tool. You must keep the old domain running with the 301 redirects for at least one year.
7. For several weeks, monitor Search Console for indexing status and 404 errors, and add any missed URLs.

Server-Specific Pitfalls

The same rule can have unique gotchas depending on the server.

• nginx: The `location` block cannot match query strings (e.g., `?id=3`). This tool creates an `if` statement that compares `$request_uri` for any URL containing a `?`. This `if` block must be placed inside your `server` block, but outside any `location` blocks.
• nginx domain normalization: To redirect HTTPS requests, an SSL certificate for that domain must be in place first. If you just add a `www`→`non-www` rule without a certificate for the `www` subdomain, visitors will see a certificate error before the redirect happens. The same applies to domain migrations; you must continue to renew the old domain's SSL certificate.
• Apache: `.htaccess` files apply immediately without a server restart, but if your rules aren't working, check that `AllowOverride All` is set in your Apache config and that `mod_rewrite` is enabled (`a2enmod rewrite`). For hundreds of rules, performance is better if you move them into the virtual host configuration, as `.htaccess` is read on every request.
• Netlify: Forcing HTTPS and standardizing your www/non-www domain is best handled in the Domain management section of the Netlify dashboard, so you don't need to add rules for this in `_redirects`. Only the first matching rule from the top down is applied. To make a rule take precedence over existing files, add a `!` after the status code.
• Regex Mode: Rules are evaluated from top to bottom. If you place a broad pattern like `/*` at the top, more specific rules below it will never be reached. Place narrower rules first.