Redirect Rule Generator

Which status code to use

A 301 says the move is permanent. It is what you want when a URL has genuinely changed address for good: search engines transfer the ranking signals from the old URL to the new one, and browsers cache the redirect, sometimes for a very long time. That caching is the reason a 301 is hard to take back. Set one by mistake and visitors who already followed it may keep being sent to the wrong place long after you fix the rule.

A 302 says the move is temporary and nothing is transferred. Use it while a page is being reworked, during a promotion, or anywhere you intend to put the original back. The rule of thumb is simple: if you would be surprised to serve the old URL again, use 301; otherwise use 302. A 308 and a 307 are the same two meanings for requests that must keep their method, which matters for form posts and almost never for a page move.

Redirect once, and never into a loop

Every hop costs time and dilutes the signal that reaches the destination. A chain from A to B to C should be rewritten as A to C and B to C, which is one rule more and one hop less for everybody. Chains grow on their own during a site move, because each round of renaming adds a rule that points at the previous round's destination rather than at the final one.

Loops are the other failure, and they are usually two rules written months apart that happen to point at each other, or one rule whose pattern matches its own target. A browser gives up after a handful of hops and shows an error, so a loop takes a page offline completely. Test every rule you add by requesting the old URL and reading the location header, rather than by clicking a link and seeing that something loaded.

The three formats, and where each one goes

A _redirects file is a plain list of from to status lines, one per rule, read by several static hosts. It is the simplest of the three and the easiest to review in a pull request. Rules are matched in order, so put specific paths above general ones.

An .htaccess file is read by Apache, per directory, on every request. The rules generated here use Redirect and RedirectMatch, which are enough for path moves and do not need the rewrite engine. Nginx rules go in the server block of your site configuration and take effect on reload; Nginx has no per-directory file, so there is nowhere else to put them.

One thing none of the three can do is redirect a page you no longer control. If the old address is on a host you have left, the redirect has to be configured there, or the old URLs simply die. That is worth checking before a migration rather than after.