Skip to main content

Redirect Rules Generator

What it does

The Redirect Rules Generator takes a list of old-to-new URL pairs and emits the matching rule syntax for the four redirect formats most commonly hit in real engagements: Apache .htaccess, nginx rewrite directives, Cloudflare Rules expressions, and IIS web.config rewrite rules. You choose 301 (permanent) or 302 (temporary) per row. Output is formatted for direct paste into the relevant configuration file. It sits alongside the rest of our SEO tool suite.

Common situations

You are migrating a site to a new URL structure and have a spreadsheet mapping every old URL to its new home. Paste the pairs into the generator, pick the format your hosting stack uses, and the output is the redirect block ready to deploy. This is faster and less error-prone than hand-writing several hundred rule lines.

A retired piece of content has been replaced by an updated version at a new URL. Set up a single 301 redirect from old to new. The old URL’s accumulated SEO equity transfers to the new URL once Google has recrawled and processed the redirect.

You have an A/B test running on the homepage and need a temporary redirect from the canonical URL to the variant during the test window. 302 is the right code, and the generator emits it correctly. After the test, swap to 301 if the variant is the new permanent version, or remove the redirect to restore the original.

A security audit has flagged that your site is reachable on both http:// and https://, and on both www.example.com and example.com. Generate the canonicalisation redirects: HTTP to HTTPS, plus www-to-non-www (or the reverse, depending on which you’ve picked as canonical). Pick one canonical form per concern and 301 every other variant to it.

You are moving from one platform to another (Squarespace to WordPress, custom CMS to Webflow, etc.) and the URL structure is changing along with the platform. Map the old URLs to their new locations, generate the redirects in your new platform’s syntax, deploy alongside the launch. Skipping this step is the most common reason “we re-platformed and lost half our search traffic”.

What you need to know

A redirect tells the browser (and search engine bots) that the requested URL has moved. 301 means permanently, so bots transfer the SEO equity of the old URL to the new URL over time. 302 means temporarily, so bots keep the old URL as canonical and treat the new location as a temporary detour. Use 301 for permanent moves; use 302 only for genuinely temporary redirection like A/B tests, maintenance pages, or geographic routing.

Redirect chains are when one URL redirects to another which redirects to another. Every additional hop costs SEO equity and adds latency. Google has been clear that chains over three hops are penalised. The fix is consolidation: redirect old to new directly, not old to intermediate to new. The Redirect Chain Tracer shows what the actual chain looks like in production, which often differs from what was intended.

The four supported formats are not interchangeable. They each match a specific server context.

Apache .htaccess is the dominant format on shared hosting and most WordPress stacks. Rules go in the .htaccess file at the site root. The format is simple but matching is regex-based and edge cases are easy to miss.

nginx rules live in the server config (typically /etc/nginx/sites-available/yoursite.conf), not in a per-directory file like Apache. The rewrite directive uses regex; permanent for 301, redirect for 302. nginx config requires a reload after changes.

Cloudflare Rules are configured in the Cloudflare dashboard, not in any file on your server. They run at the edge before requests reach your origin, which is faster but harder to audit alongside the rest of your codebase.

IIS web.config is the Microsoft Windows hosting format, used on .NET sites and SharePoint. The XML structure is verbose but the rules engine is powerful.

The generator does not handle redirect exceptions, rules that say “redirect everything except this path”. For exception logic, you typically need to write the rules by hand or use a higher-level tool. For straight one-to-one mappings, the generator covers the case cleanly.

Frequently asked questions

When should I use 301 vs 302?

301 for permanent moves, where the old URL is going away and the new URL is the replacement. 302 for temporary moves, where the old URL is coming back. The default for most cases is 301; 302 is the exception. SEO equity transfers on 301 but not on 302.

Do redirects affect SEO?

Yes, both positively and negatively. A 301 redirect transfers the old URL’s SEO equity to the new URL over time. A redirect chain (multiple hops) leaks equity at each hop. A redirect to a non-200 destination (404, 5xx) breaks the chain entirely. Plan migrations carefully and verify with the Redirect Chain Tracer post-launch.

How long until Google processes a 301?

Days to weeks for a single URL; weeks to months for site-wide migrations. Google has to recrawl both the old and new URLs, process the redirect, and update its index. There is no way to accelerate this beyond submitting the new URLs in Search Console for indexing.

What’s the difference between a 301 and a canonical tag?

A 301 returns the new URL, so the user and the bot are both redirected. A canonical tag stays on the original URL but tells search engines another URL is preferred for indexing. Use 301 when the URL is genuinely going away; use canonical when you want to keep both URLs accessible but consolidate ranking signals on one.

Can I 301 to an external domain?

Yes. HTTP 301s are not domain-restricted. SEO equity transfers across domains the same way it transfers within a domain. A common use case is closing a microsite and redirecting to the main brand site.

Does the order of rules matter?

In .htaccess, yes: rules are processed top to bottom and the first match wins, so put more specific rules above more general ones. In nginx, server-block matching is more nuanced. In Cloudflare Rules, you set explicit priority. In IIS, top-to-bottom within the rules collection.

What happens if my redirect points at a 404?

The redirect chain breaks. SEO equity is lost. Users get the 404. Bots eventually drop the old URL from the index without it transferring to the new one. Always verify that redirect destinations return 200 (or redirect to a 200). The Redirect Chain Tracer confirms this in seconds.

Should I redirect the old URL or just delete it?

Redirect, almost always. A 410 (Gone) is technically correct for permanently-deleted content but it loses the SEO equity. A 301 to a related page (or the homepage) preserves what equity remains. Only use 410 when there is genuinely no related new URL to redirect to.

Common problems

Problem: redirect rule deployed but the URL still loads the old content.

Almost always a caching issue. Check browser cache (hard-refresh), CDN cache (purge), and platform-level cache such as WordPress page cache or Cloudflare full page cache. The redirect is in place; something between the user and your server is serving cached content.

Problem: a regex rule is matching more URLs than intended.

Apache and nginx regex defaults to greedy matching. ^/old/(.*)$ matches /old/page and also /old/page/and/more. Anchor your patterns: use ^/old/$ for exact match, ^/old/[^/]+$ to match exactly one path segment.

Problem: Google is still indexing the old URL months after the 301.

Either the old URL has stronger external signals (more inbound links) than the new one, the redirect is in a long chain, or the new URL has indexing issues of its own such as a canonical pointing elsewhere or a noindex. Verify the new URL is independently indexable; re-submit to Search Console after fixing.

Problem: htaccess works locally but not on the production server.

Apache may not have mod_rewrite enabled, or AllowOverride may be set to None in the server config. Both are server-level settings the .htaccess file cannot fix on its own. Contact your hosting provider or check the Apache config.

Problem: nginx rules deployed but no behaviour change.

nginx requires a config reload after changes: nginx -s reload or systemctl reload nginx. The new rules are not picked up until the running process reloads. The other common cause is putting rules in the wrong server block, for example in http instead of server.

Tips

  • Test every redirect after deploy. The Redirect Chain Tracer shows the actual chain, since platforms sometimes add unexpected hops (HTTP-to-HTTPS, www-to-non-www, trailing-slash) on top of yours.
  • Keep the redirect map version-controlled. A spreadsheet of old-to-new is a fragile artefact; check the rules into the same repo as the rest of the site.
  • For migrations, redirect the old URLs to the most-relevant new URLs, not to a generic landing page. A page-specific 301 transfers more equity than a 301 to the homepage.
  • Avoid chains. If A redirects to B and B redirects to C, change A to redirect directly to C and remove the B step.
  • Plan the redirect map before the new URLs are finalised, not after. Migrations that go wrong almost always do so because the redirect map was an afterthought.

Related tools in this suite

The Redirect Chain Tracer is the verification tool: paste any URL post-deploy and confirm the redirects are doing what you expect, with no unexpected hops or downgrades. The HTTP Headers Inspector is useful when a redirect’s status code is reporting unexpectedly, for example when you set 301 but the response shows 302.

What this looks like at scale

A handful of redirects can live in .htaccess. A migration with thousands of redirects needs the redirect map version-controlled, deployed via the build pipeline, and verified post-launch with the chain tracer. For very large URL sets, redirect logic should run at the edge (Cloudflare, CloudFront) rather than the origin, which is faster for the user and cheaper on origin compute. The WordPress development service is where migration redirect work typically falls during a re-platforming engagement.

Take it further

If a migration’s redirect strategy needs to be planned alongside the new URL design, that work usually lands as a discrete phase of a larger development engagement. Talk through the migration and we can scope what redirect planning looks like for the size of the move.