About .htaccess Redirects
When you need redirects
Any time a URL changes. A redesign, a restructure, a move to https, a page merged into another - each leaves an old address that people and search engines still hold.
A redirect sends them to the new page and, done properly, carries the ranking signals the old URL had earned. Skip it and those signals go nowhere, along with anyone following an old link.
This generator turns a list of old and new URLs into the .htaccess rules that do it.
Which 3xx code to use
A 301 says the move is permanent. Search engines transfer the old URL's signals to the new one and eventually drop the old address from their index. This is what you want in almost every case.
A 302 says the move is temporary. The old URL stays indexed and keeps its signals, which is right for a maintenance page or a seasonal promotion and wrong for anything else. A 302 left in place for months is one of the quieter ways to lose rankings, because nothing about it looks broken.
307 and 308 are the newer equivalents of 302 and 301. Search engines treat them the same way, and the difference is technical: they preserve the original request method, so a form POST arrives at the new URL as a POST rather than being converted to a GET. That matters for APIs and form handlers and rarely for ordinary pages. Apache needs version 2.4 or later to serve a 308.
The rest of the 3xx range is not for this. 300 and 305 are effectively unused, 304 is a caching response rather than a redirect, and 303 exists to send a browser to a confirmation page after a form submission - none of them belong in a redirect file.
How the matching actually works
Redirect matches on the start of the path rather than the whole of it. A rule for /blog also catches /blog/post and /blog/category/thing, without anything being listed for them. This is useful once you know it and surprising when you do not, because a broad rule placed above a specific one makes the specific one unreachable.
The same behaviour is how you move a whole domain: a single rule with / as the old address catches every page on the site. Point it at the root of the new domain and every URL follows.
What Redirect does not understand is patterns. There are no wildcards here, so /* is read as a literal path and matches nothing - prefix matching is doing that job already. Where you genuinely need a pattern, RedirectMatch takes a regular expression instead, and is worth reaching for only when a prefix will not do.
Common mistakes
- Redirecting everything to the homepage, which reads as a soft 404 and helps nobody.
- Chains, where A goes to B goes to C. Point every old URL at the final destination.
- Loops, where two rules send traffic back and forth until the browser gives up.
- Redirecting to a page that is not a reasonable replacement for the old one.
- Editing .htaccess without a backup. A syntax error takes the whole site down.
Where these rules go
.htaccess is an Apache configuration file that lives in the root of your site. LiteSpeed reads it too; Nginx does not, and needs its own syntax in the server config.
Rules apply in order, so put specific redirects above general ones. Keep a copy of the working file before you change anything, because a mistake here returns a 500 for every page rather than failing quietly.
For a handful of URLs this file is the right place. For hundreds, a plugin or a database-driven rule is easier to maintain than a file nobody wants to open.
Using the .htaccess redirect generator
Pick the redirect type, add a row for each URL that has moved, and download or copy the rules. Old paths are relative to your domain; destinations should be full URLs.
Test a few by hand afterwards. A redirect that works in a browser but returns the wrong status code still costs you the signals it was meant to carry.
Where to go next
Check the rules do what you expect with our
redirect checker, which follows every hop and shows the status codes. Confirm the destination returns a
status code of 200, and build the rest of your config with the
.htaccess generator.