Redirects that preserve rankings instead of losing them
An .htaccess redirect generator produces Apache mod_rewrite rules — the server-level instructions that send a request for one URL to another, with a status code telling browsers and search engines whether the move is permanent.
Redirects are where site migrations succeed or quietly fail. Done well, a 301 passes the accumulated ranking signals of the old URL to the new one and nobody notices the change. Done badly, you get chains that dilute signals, loops that make the site unreachable, or a blanket redirect to the homepage that throws away every deep link you had.
This generator covers the patterns that account for most real redirect work: forcing HTTPS, canonicalising www, moving single URLs, migrating a domain, and normalising trailing slashes. This page explains what each rule does line by line, and how to deploy without taking the site down.
Choosing the status code
Direct answer: use 301 for anything permanent. The other codes exist for specific situations that are rarer than people assume.
- 301 Moved Permanently
- The default for migrations and canonicalisation. Search engines consolidate signals to the target, and browsers cache it — which is exactly why a mistaken 301 is painful to undo.
- 302 Found
- Temporary. The original URL keeps its ranking signals. Correct for A/B tests, maintenance pages and geo-routing you intend to reverse.
- 307 and 308
- The strict equivalents of 302 and 301 that guarantee the HTTP method is preserved. Matters for POST requests to API endpoints; rarely relevant to page redirects.
- The R and L flags
- R=301 sets the status code; L stops rule processing so later rules do not also fire. Omitting L is a common cause of unexpected double redirects.
- RewriteCond binds to one rule only
- A condition applies to the single RewriteRule immediately following it. Adding a rule in between silently changes which condition guards what.
- Where the file lives
- Rules go in the .htaccess file at your document root, and Apache needs AllowOverride enabled for them to take effect. If nothing happens after uploading, this is the first thing to check.
Reading a generated rule
Copying a rule you cannot read is how loops happen. Here is the HTTPS rule, line by line.
Example 1: Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]1. Turn the rewrite engine on
2. Only when the request is NOT already HTTPS
3. Send it to the same host and path over
https, permanently, and stop processingThe condition on line 2 is what prevents an infinite loop. A rule without it redirects HTTPS requests to HTTPS forever, and the browser gives up with ERR_TOO_MANY_REDIRECTS.
Example 2: Canonicalise www in one hop
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]http://www → https://apex (1 redirect)
not http://www → https://www → https://apexBecause the target specifies both the scheme and the host, the HTTPS and www changes happen together. Ordering the two rules separately produces a two-hop chain on every request.
Example 3: The migration mistake worth avoiding
RedirectMatch 301 ^/(.*)$ https://newsite.com/Every old URL → the new homepage.
Google treats these as soft 404s.
Deep-link ranking signals are lost.Map old URLs to their genuine equivalents. A blanket redirect to the homepage is the most common reason traffic never recovers after a domain move.
Deploying without taking the site down
A syntax error in .htaccess returns 500 for every request on the site, not just the redirected ones. Treat it as production code.
Back up the current file first
Download the existing .htaccess before editing. Being able to restore it in ten seconds is the difference between a hiccup and an outage.
Put rewrite rules near the top
Rules run in order, and CMS platforms append their own front-controller blocks. Placing redirects after a catch-all WordPress block means they never fire.
Test with curl, not a browser
Browsers cache 301s aggressively — you may be seeing yesterday’s redirect. curl -I shows the real status and Location header, and a private window is only a partial substitute.
Avoid chains longer than one hop
Each additional hop adds latency and risk. Audit the full chain after any change: old URL → final URL should be a single 301.
.htaccess is read on every request
Apache re-reads it for every request in every directory along the path. On a busy site, moving rules into the virtual host configuration is measurably faster — and .htaccess is only for shared hosting where you cannot.
Nginx does not read .htaccess at all
These rules only work on Apache. On Nginx, LiteSpeed, Caddy or a CDN edge worker, the equivalent has to be written in that platform’s own syntax. Confirm what your host actually runs before spending an hour debugging a file nobody reads.
A migration redirect checklist
- Export every indexed URL from Search Console and your analytics before the move — not after.
- Map each old URL to its closest equivalent; use the homepage only where genuinely nothing corresponds.
- Keep redirects live for at least a year. Search engines revisit old URLs long after the move.
- Update internal links to point at final destinations so users never traverse a redirect.
- Confirm the new host serves a valid certificate for every hostname you redirect to, using the SSL certificate checker.
- Verify the DNS records for both domains with the DNS checker before switching traffic.
- Re-check that crawl rules on the new domain are correct with the robots.txt tester.
How this page is maintained
The rules quoted on this page are the exact output of this generator, and the flag and condition behaviour follows Apache’s mod_rewrite documentation. The warning that .htaccess has no effect on Nginx-class servers is included because it is the most common reason a correct rule appears to do nothing.
Written and reviewed by the ToolsRacks editorial team. Last reviewed: .