What this tool does
This htaccess redirect generator writes the rules for the five cases that account for nearly every
redirect anyone actually needs: one URL to another, a pasted list of old and new paths, an entire
domain moving, www and the bare domain, and forcing https. Every rule comes out twice — Apache
for .htaccess, and the equivalent Nginx block beside it — because the question is the same on
both servers and finding out mid-job that the host is not Apache costs an hour.
Nothing is uploaded. The rules are assembled in your browser, and you paste them where they belong.
How to use it
- Pick the case from the first dropdown. The fields change with it.
- Leave the status on 301 unless the move is genuinely temporary.
- Copy the Apache block into
.htaccess, or the Nginx block into theserver { }for the site. - Reload and test with
curlbefore you tell anyone the migration is done.
301, 302, 307 and 308
Four codes, two questions: is the move permanent, and may the method change from POST to GET?
| Code | Permanent | Method preserved | Use it for |
|---|---|---|---|
| 301 | Yes | No — POST becomes GET | Almost every SEO redirect |
| 302 | No | No | A sale page, a maintenance detour |
| 307 | No | Yes | A temporary move of an API or form endpoint |
| 308 | Yes | Yes | A permanent move where POST bodies must survive |
For content URLs, 301 is the answer. A 302 leaves the old URL indexed and the ranking where it was, which is exactly right for a two-week campaign page and exactly wrong for a permanent move that somebody set to 302 by accident and left there for a year.
Redirect and RewriteRule must not fight
Apache runs mod_rewrite before mod_alias, regardless of the order the lines appear in the file.
So a RewriteRule forcing https and a Redirect for the same path do not run top to bottom the way
they read: the rewrite fires first, the browser follows it, and the Redirect you wrote above it
may never be consulted. Two consequences worth internalising:
- Do not write both kinds of rule for the same URL. Pick one mechanism per path.
- The output here puts the
RewriteEngine Onsection first, so what you read first is what runs first.RewriteEngine Onappears once per file; repeating it is harmless but teaches the habit.
One more trap in the same family: Redirect matches by prefix. Redirect 301 /a /b also
catches /about, /archive and everything else starting with those characters. The tool warns you
when two rules in your list overlap that way.
Chains cost you crawls, not rankings
A redirect that points at another redirect works. It is just slower for every visitor, and each hop is a fetch a crawler has to spend on you. When you add a second migration on top of an old one, rewrite the first rule to point at the final destination rather than stacking a new one in front of it. Ten-hop chains are usually three separate site rebuilds nobody flattened.
Test it before you believe it
curl is the only witness that does not lie, because your browser has already cached the answer:
curl -sIL https://example.com/old-page | grep -E "^(HTTP|location)"
-I sends a HEAD request, -L follows the chain and prints every hop, so a two-hop redirect is
visible as two HTTP/2 301 lines. What you want to see is one 301 and one 200.
Browsers cache a 301 aggressively and often ignore a shift-reload, so a rule you got wrong once can
appear to still be wrong after you fix it. Test in a private window, or with curl, and never
publish a 301 you are not sure about — start with a 302 while you are still deciding.
After the redirects
Two files usually need attention on the same day. A moved URL is still listed in your sitemap until you regenerate it, and a sitemap full of redirecting URLs is reported as an error in Search Console. And if the site has language versions, every hreflang annotation pointing at an old path is now a wasted signal, because those tags must name the final URL.