htaccess Redirects: 301 Rules That Actually Work

The Three Redirects Every Site Needs

Almost every site needs exactly three foundational redirects, and they're worth setting up on day one rather than during a crisis.

HTTP → HTTPS. Every `http://` request should permanently redirect to its `https://` equivalent. In 2026 there's no excuse for serving plaintext HTTP — browsers flag it, users distrust it, and Google has used HTTPS as a ranking signal for years. The rule preserves the full path: `http://example.com/pricing` becomes `https://example.com/pricing`, not just the homepage. One rule with a condition on the protocol handles the entire site.

Non-www → www (or the reverse — pick one). `example.com` and `www.example.com` are technically different hosts, and without a redirect, search engines see two versions of your site splitting link equity between them. Neither choice is inherently better for SEO; what matters is picking one canonical version and 301-redirecting the other to it, consistently, forever. Flip-flopping between them over the years is how chains are born.

Old URLs → new URLs. After any redesign, restructure, or slug change, every retired URL needs a redirect to its closest equivalent — not to the homepage. Redirecting 200 old product pages to the homepage looks like a soft 404 to Google and confuses users who clicked a specific link. Map each old URL to the most relevant surviving page; only fall back to a category page when no direct equivalent exists.

For Apache these live in `.htaccess`; for Nginx they go in the server block (Nginx has no .htaccess equivalent — rules live in the main config). The Apache .htaccess & Nginx 301 Redirect Rule Generator produces the correct syntax for both from the same input, which eliminates the most common source of broken rules: writing Nginx syntax in an .htaccess file or vice versa.

301 vs 302: The One That Matters

This is the distinction with real consequences. A 301 means "moved permanently": search engines transfer ranking signals to the new URL and eventually drop the old one from the index. A 302 means "moved temporarily": search engines keep the old URL indexed and don't pass link equity, because they expect the move to be undone.

Use 301 for: domain migrations, HTTP→HTTPS, www canonicalization, retired URLs with permanent replacements — anything you don't plan to reverse. Use 302 for: A/B tests, temporary maintenance pages, geo-based detours, anything genuinely short-lived.

The expensive mistake is using 302 for permanent moves — I've seen site migrations run on 302s for months because nobody noticed, with Google dutifully keeping the dead URLs indexed and withholding the ranking signals from the new ones. The equally common mistake is the reverse: 301-ing a page during a two-day sale and then wondering why Google still sends traffic to the sale URL weeks later (because you told it the move was permanent, and it believed you). Match the status code to the intent, and double-check what's actually being served — don't trust the rule you wrote, test the header the server sends.

Order Matters: Put Specific Rules First

Apache processes `.htaccess` rewrite rules top-down, and the first matching rule wins (when it has the `[L]` flag). This means specific rules go before general ones. If your catch-all "redirect everything old to the new domain" rule sits above the "but /blog/launch-post goes to /news/launch-post" exception, the exception never fires — every request matches the general rule first.

The safe ordering: individual page-to-page redirects first, then section-level patterns, then the broad canonical rules (HTTP→HTTPS, www) last. And test after every change — one misplaced rule can redirect your entire site to a single page, which is exactly as catastrophic as it sounds. Keep a backup of the working .htaccess before editing; when a redirect edit goes wrong at midnight, "restore the backup" beats "debug regex under pressure" every time.

Nginx users get a small mercy here: `location` blocks match by specificity rules rather than pure order, but the principle still holds — write the specific before the general and verify with a test request.

Redirect Chains: The Silent SEO Killer

A redirect chain is when URL A redirects to B, which redirects to C (and sometimes to D). Each hop costs: a little link equity, crawl budget, and — most tangibly — page speed, since the browser must complete each redirect round-trip before loading the page. Google officially says it follows up to around 10 hops, but its documentation and its engineers both advise keeping chains to a minimum; in practice, anything beyond 2 hops is a smell, and beyond 3 is a problem.

Chains accumulate silently over years: the 2019 migration redirected `/old` → `/new-2019`; the 2022 rebrand redirected `/new-2019` → `/new-2022`; the www-canonicalization adds another hop on top. Nobody meant to build a chain — each redirect was correct on the day it was written. The fix is a periodic redirect audit: crawl your site (or check Search Console's redirect reports), list every chain longer than one hop, and rewrite them so each old URL points directly at its final destination. A → C, not A → B → C.

Also watch for redirect loops (A → B → A), which browsers abort with an error page and which scream "broken" to both users and crawlers. Loops usually come from conflicting rules — e.g., one rule forcing www and another forcing non-www, each undoing the other. If a page suddenly shows "too many redirects," conflicting canonical rules are suspect number one.

Testing Your Redirects Before You Ship

Never trust a redirect rule you haven't tested with an actual HTTP request. The checklist:

• Check the status code. Use `curl -I` or your browser's devtools network tab: you want to see `301` (or `302` if temporary) and a `Location` header pointing at the right destination. A `200` means the rule didn't fire at all — the page just loaded normally.
• Follow the full chain. `curl -L` follows redirects; count the hops. One hop is ideal, two is acceptable, three or more needs flattening.
• Test the variants. `http://`, `https://`, `www`, non-www, with and without trailing slash, uppercase oddities — each variant should end at the same canonical URL in one hop.
• Test that non-redirected pages still load. A too-broad pattern can catch URLs it shouldn't. Spot-check a handful of normal pages after every rule change.

Redirects are infrastructure: invisible when correct, catastrophic when wrong. Write them carefully, order them specifically-first, test the actual headers, and audit for chains once or twice a year. Do that and they'll never be the reason your traffic chart has a mysterious cliff in it.