Most people treat 301 redirects htaccess rules as plumbing — point the old URL at the new one, move on. That casual attitude is exactly why so many site migrations bleed 20% to 40% of organic traffic in the weeks after launch. A 301 is not a URL swap. It’s a signal to Google that a page has permanently moved and that its accumulated ranking equity should transfer to the new address. Get the syntax wrong, the status code wrong, or the ordering wrong, and you don’t get an error page — you get a slow, quiet erosion that no one notices until a monthly report shows the damage. This guide covers how these rules actually behave, so the equity you spent years earning survives the move.
What a 301 Actually Does Under the Hood
When a browser or crawler requests a URL and the server returns a 301 Moved Permanently status, two things happen. The client immediately follows the Location header to the new URL, and — critically for SEO — most modern browsers and CDNs cache that redirect aggressively, sometimes for months. Google, meanwhile, treats the 301 as an instruction to consolidate signals: the indexed URL is dropped in favor of the target, and the link equity (the PageRank-style authority passed by inbound links) flows to the destination.
The consolidation is not instant. Google has to recrawl the old URL, see the 301, then recrawl and reprocess the target before the swap fully settles in the index. For a low-authority page that can take days; for a deep, rarely-crawled page it can take weeks. This is why a migration doesn’t recover overnight even when every rule is perfect — you’re waiting on crawl scheduling, not just DNS. Understanding this timeline stops you from panicking (or worse, changing the rules) during the normal settling period.
301 vs 302 vs 307 vs 308: Choose the Right Status Code
The single most expensive mistake in redirect work is using the wrong status code, because the wrong one still works for users while quietly failing for SEO. Here’s the honest breakdown:
- 301 (Moved Permanently) — the default for any move you intend to keep. Passes link equity and tells Google to swap the indexed URL. This is what you want for migrations, HTTPS enforcement, and retired pages that have a replacement.
- 302 (Found / temporary) — signals a temporary move. Google generally keeps the original URL indexed and passes equity cautiously. Use it only when the move is genuinely temporary (A/B tests, short campaigns). Leaving a 302 on a permanent move is a common, invisible equity leak.
- 307 (Temporary Redirect) — the HTTP/1.1 strict version of a 302 that preserves the request method (POST stays POST). Rarely what you want for content SEO.
- 308 (Permanent Redirect) — like a 301 but method-preserving. Correct for API endpoints and form handlers, but for plain content pages the 301 remains the safe, universally understood choice.
Rule of thumb: if the change is forever, it’s a 301. If you can’t say with confidence that it’s temporary, it isn’t — use the 301. Almost every rule you write in 301 redirects htaccess work should carry the permanent code.
First, Confirm .htaccess Is Even Being Read
Before writing a single rule, verify the file is active. On Apache, .htaccess only takes effect when AllowOverride is set to All (or at least FileInfo) for your directory in the server config, and for pattern-based rules mod_rewrite must be enabled. The file must be named exactly .htaccess — the leading dot, no extension — and sit in the web root or the relevant subdirectory.
A five-second sanity check: add a deliberately broken line like this is not valid at the top of the file and reload the site. If you get a 500 Internal Server Error, the file is being parsed and your rules will run. If the site loads fine, .htaccess is being ignored entirely and you’re editing a file the server never reads. Remove the broken line once you’ve confirmed. If you’re on nginx, none of this applies — nginx doesn’t use .htaccess at all, and your redirects belong in the server block with return 301 directives instead.
The Three Tools, and When Each One Wins
Apache gives you three ways to redirect, and mixing them carelessly is where loops and conflicts start. Match the tool to the job:
- Redirect (from mod_alias) — for a single, exact, path-to-path move:
Redirect 301 /old-page/ https://example.com/new-page/. Simple, fast, no regex. Caveat:Redirectis prefix-matching, so/oldalso catches/old-stuffunless you’re careful. - RedirectMatch — for pattern-based moves without full rewrite logic:
RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1maps a whole directory while preserving the tail. - RewriteRule (from mod_rewrite) — for anything conditional: HTTPS enforcement, www canonicalization, query-string logic, or rules that depend on the host or existing parameters. It’s the most powerful and the easiest to break.
Don’t reach for RewriteRule when a plain Redirect would do. The simplest tool that solves the case is the one least likely to create a chain or a loop six months from now when someone else edits the file.
Site-Wide Canonicalization: HTTPS and www in One Pass
The most common permanent redirects aren’t page moves — they’re canonicalization rules that force every visitor onto one scheme and one hostname. Done sloppily, these fire in two hops (HTTP-non-www to HTTPS-non-www to HTTPS-www), which is a chain that wastes crawl budget. Done right, they resolve in a single redirect:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [L,R=301]
The R=301 flag sets the permanent status; the L flag stops rule processing so later rules don’t fire on the same request; %{REQUEST_URI} preserves the requested path so /pricing lands on /pricing, not the homepage. Redirecting everything to the homepage is one of the fastest ways to destroy the equity of deep pages — a redirect to an irrelevant destination is often treated as a soft 404 and passes nothing.
A Worked Micro-Example: Moving a Blog Subfolder
Say you’re consolidating example.com/news/ into example.com/blog/ and keeping every article’s slug. The naive approach is to list every URL by hand. The durable approach uses one pattern rule:
RedirectMatch 301 ^/news/(.*)$ https://www.example.com/blog/$1
Now /news/2025-recap/ becomes /blog/2025-recap/ automatically, and so does every other article. But there’s a trap: if the canonicalization block above runs after this rule without an L flag, a request to the non-www /news/ URL fires the RedirectMatch first, then the canonicalization rule, producing a two-hop chain. The fix is ordering and the L flag — put canonicalization at the top so scheme/host is settled in one hop, then let the content-move rules run on an already-canonical request. After deploying, spot-check a handful of real inbound-link URLs (not just the homepage) to confirm each resolves in exactly one hop to a live 200 page.
The Mistakes That Quietly Leak Equity
These are the failures that don’t throw errors but do cost rankings:
- Redirect chains — A points to B points to C. Each hop dilutes signals slightly and burns crawl budget; three hops before a 200 response means Googlebot spends three fetches to see one page. Always point the old URL directly at the final destination.
- Redirect loops — a rule that eventually redirects a URL back to itself, producing an infinite loop and a browser error. Usually caused by a canonicalization rule that doesn’t correctly exclude the already-canonical case.
- Mass-redirecting to the homepage — treated as a soft 404 for most of those URLs; the equity evaporates. Redirect to the closest relevant page, or return a real 404/410 if no equivalent exists.
- Leaving old 302s in place — a temporary redirect on a permanent move keeps the wrong URL indexed indefinitely.
- Redirecting to a URL that then 404s — the target changed later and no one updated the rule. The redirect “works” but lands on nothing.
None of these announce themselves. They surface as a downward drift in a traffic graph weeks later, which is why post-migration monitoring matters as much as the rules themselves.
Test Every Rule Before It Touches Production
Never validate redirects in a browser — browser and CDN caching will show you stale behavior and lie to you about what the server is actually returning. Use curl against the raw headers:
curl -sI https://example.com/old-page/ | grep -i "HTTP\|location"
This shows the exact status code and the Location target with no caching in the way. To trace a full chain and confirm it resolves in one hop, add -L and count the redirects: curl -sIL https://example.com/old-page/. You want to see a single 301 followed by a 200 — not a stack of 301s. Run this against your highest-value pages (the ones with the most inbound links) before and after deploying, because those are where a mistake costs the most.
Scaling to Thousands of URLs Without a Nightmare .htaccess
Hand-writing individual 301 redirects htaccess entries stops being viable past a few hundred URLs — a bloated .htaccess with thousands of literal rules adds latency to every request, because Apache evaluates the file on each hit. For large legacy inventories, use pattern rules wherever slugs are predictable, and for genuinely one-off mappings use a RewriteMap backed by an external file that Apache reads efficiently. Group your redirects logically, comment each block, and keep temporary rules separate from permanent ones so cleanup is possible later.
Whatever the scale, the equity math is the same: a migration is only as good as your ability to catch the redirects that silently break. This is where rank tracking earns its keep. In SEO Rocket, top-100 rank tracking against a trend line (not single-day spot checks) surfaces the pages that slipped after a migration, and the real-crawler site audit walks your site the way Googlebot does — flagging redirect chains, loops, and redirects that dead-end on a 404 before they cost you a quarter of your traffic. The framework behind that workflow is a playbook proven across 1,000,000+ ranking pages: the equity you preserve on migration day compounds for years, and the equity you leak is gone quietly.
Frequently Asked Questions
How long does it take for Google to process a 301 redirect?
Anywhere from a few days to several weeks, depending on how often Google crawls the old URL. High-traffic pages get recrawled fast; deep, rarely-visited pages take longer. Google has to fetch the old URL, see the 301, then recrawl the target before consolidating signals. Keep the redirect in place for at least a year — ideally permanently — so Google has ample time to transfer everything.
Do 301 redirects pass all the link equity?
Effectively yes for a direct, relevant 301 — Google has stated that permanent redirects to equivalent content pass full PageRank. The losses come from chains (each hop dilutes slightly), redirects to irrelevant pages (treated as soft 404s that pass little to nothing), and using a 302 by mistake. Point old URLs directly at the closest-matching live page for the cleanest transfer.
Should I use 301 or 302 for a temporary page change?
Use a 302 (or 307) only if the change is genuinely temporary and you intend to restore the original URL. Google keeps the original indexed for a 302. If you can’t confidently say the move is temporary, use a 301 — a wrongly-applied 302 keeps the old URL ranking and starves the new one.
Why isn’t my .htaccess redirect working at all?
Most often the file isn’t being read: AllowOverride is restricted in the server config, mod_rewrite is disabled, the file is misnamed, or you’re actually on nginx (which ignores .htaccess). Confirm the file is parsed by temporarily adding an invalid line and watching for a 500 error, then check status codes with curl -sI rather than trusting a cached browser view.
The Bottom Line
Redirects look trivial and behave like precision instruments. Setting up 301 redirects htaccess rules correctly is the difference between a migration that transfers years of authority in a single clean hop and one that leaks it through chains, wrong status codes, and homepage dumps no one notices for a month. Pick the 301 for anything permanent, canonicalize in one pass, point old URLs directly at the closest live equivalent, test every high-value rule with curl before you ship, and then watch the trend line — because the redirects that break are always the ones that break quietly.
