301 or 302 — the choice that matters
A 301 is permanent. It tells search engines the page has moved for good, passes the ranking signals to the new URL, and is cached by browsers — often indefinitely.
A 302 is temporary. Signals stay with the old URL and browsers re-check each time.
Almost every redirect you write should be a 301. Use a 302 only when the old URL will genuinely come back: a page down for maintenance, a seasonal landing page, an A/B test.
The [msm_tool slug="htaccess-redirect-generator"] defaults to 301 for that reason, and it catches the two mistakes that cause the most damage.
Browser caching makes a wrong 301 expensive
This is the part people discover too late. Once a browser has seen a 301 it may never ask again, even after you remove the rule from the server.
So a 301 pointing at the wrong destination is not fixed by deleting it. Visitors who already hit it keep going to the wrong place until their cache clears, which can be weeks. Testing in a private window is not enough — test the rule before it goes near production, not after.
This is also why a 302 is the safer choice while you are still deciding. Switching a 302 to a 301 later costs nothing; switching a bad 301 back costs your visitors.
Loops and chains
A redirect pointing at itself produces an infinite loop and the page becomes unreachable. The generator refuses that outright rather than writing it.
Chains are subtler and more common: A redirects to B, and B was already redirecting to C. Every hop costs time, and search engines stop following after a handful. Each hop also loses a small amount of the signal being passed along.
When you add a redirect, check whether the destination is itself redirected. Point A straight at C and collapse the chain.
Order matters
Apache evaluates rules top to bottom and the first match wins. A broad rule placed above a specific one prevents the specific one from ever running.
Put the most specific rules first and the catch-alls last. This is the usual explanation for "my redirect isn't working" when the syntax is plainly correct.
Redirect and RedirectMatch
The simple Redirect directive takes literal paths and is right for one-to-one moves. It also matches prefixes, which surprises people: a rule for /blog also catches /blog-archive.
RedirectMatch takes a regular expression and is what you want for patterns — moving an entire directory, changing a URL structure, appending or removing a segment. It is more powerful and correspondingly easier to get wrong, so test it against URLs that should not match as well as ones that should.
Bulk redirects
For a site migration, put each old and new address on the same line and generate them together. That is far less error-prone than writing hundreds by hand, and the tool reports how many lines it skipped as incomplete rather than silently dropping them.
Before a migration, export the list of URLs that actually have traffic or backlinks. Redirecting everything is unnecessary; redirecting the pages people reach is essential, and a spreadsheet of old-to-new pairs is the artefact that makes the whole thing survivable.
htaccess is not free
Apache reads the file on every request, for every directory in the path. A file with thousands of rules is measurably slower than one with a few dozen.
If you are on your own server, redirects belong in the main configuration where they are read once at startup. .htaccess exists for shared hosting where you cannot touch that configuration — which is most of the time, and is a good enough reason to use it.
After deploying
- Test each rule with a fresh browser profile or a command-line request, checking the status code rather than just the landing page.
- Confirm you get one hop, not two.
- Watch for a rise in 404s in the server logs for a fortnight afterwards.
- Keep the redirects. Removing them a year later breaks every old link that still exists on other people's sites.