301 Redirect

TL;DR — A 301 redirect permanently sends anyone (or any bot) who visits an old URL to a new one. It’s the right tool when a page moves for good — a new domain, a new URL, HTTP to HTTPS, or merging two pages into one. Set it up on your server, point each old URL to its real replacement (not just your homepage), and leave it in place. Google says a 301 doesn’t cost you ranking value, so there’s nothing to be afraid of.

What a 301 redirect is

When a browser or a search engine asks for a page, your server answers with a three-digit HTTP status code. 200 means “here’s the page.” 404 means “not found.” A 301 means “Moved Permanently” — this URL has a new home, go there instead.

So a 301 redirect is your server telling everyone: the thing you asked for lives at a different address now, and that’s permanent. Visitors get sent to the new page automatically, and search engines update their records to point at the new URL.

When you’d use one

Reach for a 301 whenever a page’s address is changing for good:

• You changed a URL — renamed a page, restructured your site, cleaned up a messy URL.
• You moved to a new domain — a rebrand or a site migration.
• You switched to HTTPS — every http:// URL should 301 to its https:// twin.
• You merged pages — two similar articles became one; redirect the old ones to the survivor.
• You retired a page that has a clear replacement — send it to the closest equivalent, not a dead end.

Google’s own advice: “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.”

The one number you should ignore

You’ll hear people say a 301 “loses 10–15% of link juice.” That’s an old myth. Google is direct about it: “301 and other permanent redirects don’t cause a loss in PageRank.” So don’t avoid redirecting a page because you’re worried about “leaking” value — a proper 301 hands the destination the signals the old URL had earned.

(You’ll also see confident-sounding claims that a 301 “passes 90–99% of link equity.” Ignore those too — Google doesn’t publish any such percentage, and the number is made up.)

Three things to get right

1. Point each old URL at its real replacement — not your homepage. If you dump every retired page onto the home page, Google may treat those as errors (a “soft 404”) and not pass the value. Match old to new one-to-one.
2. Use a real 301, not a fake one. A redirect done purely in JavaScript, or a “click here if you’re not redirected” link, isn’t the same thing — Google might not even see it. Do it on the server.
3. Leave it up. Google says to keep redirects generally at least a year so everything has time to transfer. Honestly, if you can, keep them forever.

What about a 302?

A 302 is the temporary version — “this page has moved for now, but the original is still the real one.” If you use a 302 when you meant a 301, Google may keep the old URL in its results instead of the new one. When the move is permanent, use a 301. (There’s a whole comparison of 301 vs. 302 worth reading separately.)

Want the server configs, the timing details, the redirect-chain rules, and how to catch a “fake” 301 that’s quietly failing? Switch to the Advanced tab.

TL;DR — A 301 (HTTP “301 Moved Permanently”) is a server-side response that permanently moves a URL and is the strongest signal for consolidating ranking onto the destination. Google is explicit that permanent redirects don’t cause a loss in PageRank — the “~15% loss per hop” rule is dead, and there’s no published percentage of equity passed, so don’t invent one. Implement it at the server (Apache, nginx, application code) or the edge (Cloudflare), not with a JavaScript or delayed meta-refresh workaround. Redirect old URLs to their relevant 1:1 equivalent — not everything to the homepage, which Google may reclassify as a soft 404. Keep chains short (Google follows up to 10 hops but recommends staying under ~5; Mueller has said ~5 per crawl). It’s instant at the server; full index/signal consolidation takes weeks to generally at least a year.

What a 301 actually is

A 301 is an HTTP status code — “301 Moved Permanently” — returned by your server (or your CDN’s edge) in the response headers, before any page body. That’s the important part: a real 301 happens at the protocol level, in the response to the request. It isn’t a plugin feature, a <meta> tag, or a JavaScript snippet — those are workarounds for when you can’t do it at the server, and they behave differently (more on that below).

Google puts the definition simply: “The 301 and 308 status codes mean that a page has permanently moved to a new location.” (308 is the newer permanent-redirect code that also preserves the request method; for SEO purposes Google treats 301 and 308 the same — “use HTTP permanent redirects if possible, such as 301 and 308.”)

A few protocol details worth knowing before you implement one: a 301 response is heuristically cacheable by default, so a browser or intermediate cache can hang onto it — which is exactly why a “fixed” redirect can still send testers to the old target until a cache clears. And because a 301 has been around since HTTP/1.0, a user agent is allowed to change a POST request to GET when it follows one — so don’t assume a 301 preserves the original request method on a form submission; use a 308 instead if that matters. The Location header itself just needs to be a URI reference (it can technically be relative), though pointing it at an absolute URL avoids ambiguity in practice.

How Google processes a 301 (canonicalization + indexing)

A permanent redirect is one of the strongest canonicalization signals Google has. When Googlebot follows a 301, the indexing pipeline uses the redirect as a signal that the redirect target should be the canonical URL. Google keeps a record of both ends: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.”

That’s why you sometimes still see an old URL in results for a while after a move — Google is holding it as an “alternate name.” Google says not to panic: for a domain move, “it’s very likely that Google will continue to occasionally show the old URLs in the results, even though the new URLs are already indexed. This is normal… the alternate names will fade away without you doing anything.”

A redirect outranks weaker canonicalization signals. Gary Illyes once put the hierarchy bluntly — a redirect “should be much higher weight… than whether the page is on an http URL or https.” So a stray 301 can quietly override a canonical tag or an HTTPS preference pointing the other way. (Full treatment in canonicalization.)

Worth being precise about what this signal does and doesn’t promise: a 301 is a strong canonical-target signal, not a guarantee. It tells Google which URL should be canonical — it doesn’t guarantee that URL gets indexed, that it ranks, that traffic follows, or that every other signal (links, content quality, site authority) transfers automatically. Treat “canonical choice” and “indexing, ranking, and traffic outcomes” as separate questions; a 301 only answers the first one directly.

The PageRank myth — get this exactly right

This is the single most-mangled fact about 301s, so here’s the precise version.

Google’s exact statement: “301 and other permanent redirects don’t cause a loss in PageRank.” That’s it. Not “you keep 85%,” not “you lose 10–15% per hop.” No loss.

The “~15% loss per hop” rule traces to old, pre-2016 statements about PageRank damping across redirects (commonly attributed to Matt Cutts). Google reversed that publicly around 2016 — as reported at the time, Google stopped applying PageRank dilution across 30x redirects, and the destination gets the authority.

The corollary that trips people up in the other direction: do not claim a 301 “passes 90–99% of link equity.” Google publishes no such number. “Doesn’t cause a loss in PageRank” is a directional statement, not a percentage — and any specific percentage you see is folklore, not something Google has ever confirmed. Cite the “no loss” wording; never invent a figure.

I’ll add my own note of caution here. I actually tested the “signals stick after a year” claim by removing 301s on four well-linked Ahrefs posts and watching what happened (Is It OK to Remove 301 Redirects After a Year? We Tested It). Referring domains dropped noticeably once the redirects came off, and organic traffic was mixed — one post up, one down, two roughly flat, with one apparent “drop” that actually predated the removal. My honest conclusion: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” Small sample, so I hedge — but the practical takeaway is the boring one: don’t remove your redirects.

Timing — three different clocks

“How long does a 301 take to work?” depends on which clock you mean:

• The server: instant. The moment the rule is live, every request gets a 301 and users land on the new URL. No waiting.
• The index: days to weeks. Google has to re-crawl the old URL, see the redirect, and process the target. Google’s own framing: “a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer,” and “visibility of your content in Search may fluctuate temporarily during the move. This is normal.”
• Full signal consolidation: generally at least a year. Google: “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” This is the same one-year figure Illyes gave when he said signals need about a year to fully pass from the source to the target.

Practical rule: keep 301s in place for at least a year, and really just keep them forever if the URLs cost you nothing.

Implementing a 301

Do it as close to the server as you can. Here are the four paths that cover almost everyone. (These are illustrative; adapt paths/hostnames to your setup, and the Scripts tab has copy-paste versions plus how to test them.)

Back up your existing .htaccess or nginx config before you edit it — a malformed rule can take the whole site offline, not just the one URL you’re redirecting.

Apache (.htaccess)

For a single URL with mod_alias:

Redirect permanent "/old-page" "https://example.com/new-page"

For pattern-based rules with mod_rewrite:

RewriteEngine on
RewriteRule "^/service$" "/about/service" [R=301,L]

nginx

location = /service {
  return 301 https://example.com/about/service;
}

WordPress

WordPress has no built-in redirect manager, so you add one:

• The Redirection plugin (free) — the most common pick; add source → target in a UI, no code.
• Yoast SEO Premium — its Redirect Manager can auto-create a redirect when you delete or change a URL’s slug. Note the free version of Yoast has no redirect manager (a lot of tutorials skip this).
• Server-level — if you can edit .htaccess/nginx directly, a server rule is faster than a PHP-based plugin, which runs on every request.

Cloudflare

If you’re on Cloudflare, you can redirect at the edge, before the request ever reaches your origin:

• Single Redirects — one-off rules in the dashboard.
• Bulk Redirects — a redirect list (thousands of source → target pairs) applied account-wide. This is genuinely useful for a full migration, because you don’t have to touch origin config at all — handy when the old server is being decommissioned.

Application code (PHP example)

header('HTTP/1.1 301 Moved Permanently');
header('Location: https://www.example.com/new-url');
exit();

“Fake” 301s — the failure mode nobody checks

Here’s a counterintuitive one worth internalizing: a URL can return 200 OK and still be redirecting. As I’ve written in 11 Types Of Redirects & Their SEO Impact, “A redirect can still be happening with any status code. You may have a page that shows as a 200 OK status code, but still actually be redirecting” — via JavaScript, after the page loads. That “redirect” is invisible to a quick status-code check and carries none of a 301’s guarantees.

Google’s guidance ranks the methods:

• Server-side (301/308): best. Use it whenever technically possible.
• Meta refresh: it depends on timing. Google: an instant meta refresh is interpreted as a permanent redirect; a delayed meta refresh (fires after N seconds) is interpreted as a temporary one. So a content="5;url=…" refresh is not a 301 substitute.
• JavaScript: last resort. Google: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” If the render doesn’t complete, the redirect effectively doesn’t exist for Google.
• “Crypto” / link-only pseudo-redirects: don’t. A page that just links to the new URL with no status code and no refresh is, in Google’s words, something “not all search engines may recognize… as an official redirect.” Don’t rely on it.

The lesson: if you care about SEO, confirm your redirect is a real server 301, not a 200 that redirects in the browser. The Scripts tab shows how to check with curl.

Common 301 mistakes

• Redirecting everything to the homepage. The classic. Google: “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page… This can confuse users and might be treated as a soft 404 error.” A soft 404 won’t reliably consolidate signal. Redirect to the relevant replacement — and if you genuinely consolidated several pages into one, redirecting them all to that new combined page is fine.
• Long redirect chains. Google will follow “up to 10 hops,” but advises going straight to the final destination, “ideally no more than 3 and fewer than 5.” Mueller has said Google follows about 5 hops per crawl attempt for frequently-crawled URLs. My own practical threshold matches: I don’t worry about chains under ~5 hops, but past 5 I’ve seen issues. Chains also add latency for real users. When you add a new redirect, update old rules to point at the final URL, not the previous hop.
• Using a 302 when you mean a 301. A 302 tells Google the original URL should stay the canonical, so a permanent move done with a 302 can leave the wrong URL indexed. Google may eventually reinterpret a long-lived 302 as permanent, but the timeline for that is undefined — as I put it, nobody really knows how long, “usually a few weeks to a few months.” Just use the status code that matches your intent.
• Removing redirects too soon. Under a year risks stranding value on the dead URL. Keep them at least a year; ideally indefinitely.
• Overly broad wildcard rules. A folder-wide catch-all often sends URLs to the wrong place. Map old → new 1:1 as much as possible.
• Forgetting non-HTML assets. In a migration, redirect images and PDFs too; you don’t need to redirect JS/CSS/font files.
• Letting the old host go dark too early. A redirect rule can’t rescue a request that never reaches it — if you decommission the old domain’s DNS, let its TLS certificate expire, or drop the old server before the redirects have done their job, visitors and bots get a connection error instead of a 301. Keep the old host’s DNS, certificate, and redirect rules alive for as long as you’re keeping the redirects.

Bing

Bing treats a 301 as a strong signal to consolidate ranking onto the target URL and deprecate the old URL from its index — the same basic model as Google. Bing’s long-standing guidance recommends keeping a permanent redirect in place for a shorter minimum (on the order of a few months) than Google’s ~1 year, and its migration guidance is that 301s are normally sufficient — its Site Move tool doesn’t replace them. If you’re serving both engines (you are), the safe move is to follow the stricter guidance: real server 301s, kept for at least a year.

Where this sits

A 301 is one status code in a family. It pairs most directly with the 302 redirect (its temporary counterpart) — the 301 vs. 302 decision is really “is this move permanent or not?” It’s a close cousin of canonicalization (a 301 is a strong canonical signal, but for moving a page, not for consolidating duplicates that both stay live — those call for rel="canonical"). And it’s the backbone of any site migration. For the wider set of codes — 302/307 temporary, 308 permanent, 404/410 gone, 5xx errors — see the HTTP status codes cluster this page lives in.

AI summary

A condensed take on the Advanced version:

• 301 = HTTP “301 Moved Permanently” — a server-side response that permanently moves a URL and is one of the strongest canonical-target signals Google has. That’s a signal, not a guarantee — it doesn’t itself promise indexing, ranking, or traffic. Google treats 301 and 308 the same for SEO, but a 301 may drop a POST to GET and is heuristically cacheable by default; use 308 if you need the method preserved.
• No PageRank loss. Google’s exact wording: “301 and other permanent redirects don’t cause a loss in PageRank.” The old “~15% loss per hop” rule is dead — and Google publishes no percentage of equity passed, so never quote “90–99%.”
• Three timing clocks: server = instant; index migration = days to weeks (longer for big sites); full signal consolidation = generally at least a year. Keep redirects at least a year, ideally forever.
• Implement at the server/edge: Apache .htaccess (Redirect permanent / mod_rewrite [R=301]), nginx (return 301), WordPress (Redirection plugin or Yoast Premium — free Yoast has no redirect manager), Cloudflare Single/Bulk Redirects (edge-level, no origin config), or app code.
• “Fake” 301s: a page can return 200 and still redirect via JavaScript (invisible to a status check). Instant meta refresh ≈ permanent; delayed meta refresh ≈ temporary; JS is last resort (Google may never see it if rendering fails); link-only “crypto” redirects are unreliable.
• Top mistakes: redirecting everything to the homepage (risks a soft 404); long chains (keep under ~5 hops); using a 302 for a permanent move; removing redirects too early; broad wildcards instead of 1:1 mapping.
• Patrick’s caveat: his own test removing 301s after a year showed messier, mixed real-world results than the clean “one year and you’re safe” story — so keep the redirects.

Official documentation

Primary-source documentation from the search engines.

Google

• Redirects and Google Search — what a 301 is, server-side vs. meta-refresh vs. JavaScript redirects, meta-refresh timing rules, and implementation code samples (PHP, Apache, nginx).
• Site moves with URL changes — the “no loss in PageRank” statement, the “keep redirects generally at least 1 year” guidance, redirect-chain limits, the soft-404 warning, and moving small vs. large sites.
• How to specify a canonical URL — where redirects rank as a canonicalization signal.
• Crawling and Indexing — the parent hub for redirects, canonicalization, and crawl controls.

Bing / Microsoft

• Bing Webmaster Guidelines — Bing’s stance on redirects and permanent moves.
• Website Migration with Bing (Dec 2020) — Bing’s Site Move tool and the note that 301s are normally sufficient and the tool doesn’t replace them.

Platform implementation

• Cloudflare — Bulk Redirects — account-wide redirect lists applied at the edge.
• Cloudflare — URL forwarding (Redirects) overview — Single vs. Bulk Redirects.
• Yoast — How to create a 301 redirect in WordPress — the WordPress-specific paths (including that redirect management is a Premium feature).

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google — what a 301 is and when to use it

• “The 301 and 308 status codes mean that a page has permanently moved to a new location.” — Google Search Central, Redirects and Google Search. Jump to quote
• “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” Jump to quote
• “Use server side permanent redirects if technically possible… we recommend that you use HTTP permanent redirects if possible, such as 301 and 308.” — Google Search Central, Site moves with URL changes. Jump to quote

Google — PageRank / consolidation (the accuracy spine)

• “301 and other permanent redirects don’t cause a loss in PageRank.” — Google Search Central, Site moves with URL changes. Jump to quote
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical… The other URL becomes an alternate name of the canonical URL.” — Google Search Central, Redirects and Google Search. Jump to quote

Google — timing

• “Keep the redirects for as long as possible, generally at least 1 year. This timeframe allows Google to transfer all signals to the new URLs… From users’ perspective, consider keeping redirects indefinitely.” — Google Search Central, Site moves with URL changes. Jump to quote
• “A small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer… the visibility of your content in Search may fluctuate temporarily during the move. This is normal.” Jump to quote

Google — redirect chains, soft 404s, and fake redirects

• “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects… we advise redirecting to the final destination directly. If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” Jump to quote
• “Don’t redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site. This can confuse users and might be treated as a soft 404 error.” Jump to quote
• “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects… if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” — Google Search Central, Redirects and Google Search. Jump to quote
• “Google Search interprets instant meta refresh redirects as permanent redirects… Google Search interprets delayed meta refresh redirects as temporary redirects.” Jump to quote

301 redirect implementation checklist

A pass to run before, during, and after putting a permanent redirect (or a batch of them) live:

Before

• Confirm the move is genuinely permanent — if it’s temporary, you want a 302, not a 301.
• Build a 1:1 map of old URL → most relevant new URL (not old URL → homepage).
• For consolidations, decide the single survivor URL each group redirects to.
• Plan to redirect images and PDFs too (skip JS/CSS/font files).

Implementing

• Do it server-side (Apache/nginx/app) or at the edge (Cloudflare) — not via JavaScript or a delayed meta refresh.
• Prefer 1:1 rules over broad folder wildcards that can mis-route URLs.
• Point every rule at the final destination, so you don’t create chains.
• On WordPress, use the Redirection plugin or Yoast Premium (free Yoast has no redirect manager), or a server rule.

Verifying

• Test that each old URL returns a real 301 (not 200, not 302, not a JS redirect) — see the Scripts tab for curl checks.
• Confirm there are no chains over ~5 hops; collapse any you find to a single hop.
• Check that the target returns 200, not another redirect or a 404.
• Test a URL with a query string, fragment, trailing slash, or mixed case — rules can silently drop or mangle these instead of carrying them through.
• Spot-check redirected URLs in GSC URL Inspection to see how Google resolves them.
• For a migration, run a site crawl (Ahrefs Site Audit / Screaming Frog) to catch redirect loops, chains, and old URLs that slipped the map.

After

• Leave the redirects in place generally at least a year — ideally indefinitely.
• Expect the old URL to linger in results for a while (“alternate name”) — that’s normal, don’t remove the redirect to force it.

Detecting and testing 301s

Check it with the Redirect Checker:

1. Paste the URL you’re testing into the single-URL field (or switch to batch mode for up to 20 at once).
2. Click Check redirects to trace the full chain.
3. Read the first hop’s status code and the verdict dot — a real permanent redirect shows 301 (or 308) straight through; a 302/307 mixed in, or a “chain” severity above green, means it isn’t a clean one-hop 301.

The point of these is to answer one question: is this URL really returning a server-side 301, or is something lying to me? (Remember: a page can return 200 OK and still redirect in the browser via JavaScript.)

Don’t just test the bare URL — rerun the check against a version with a query string, a #fragment, a trailing slash, or different casing. Nothing in the HTTP spec guarantees a rewrite rule carries those through; that’s an implementation detail of your specific rule, and it’s common for a RewriteRule or pattern match to quietly drop a query string or fragment that the original URL had.

See the raw status code and redirect chain (curl)

macOS / Linux / WSL

# Show response headers only — look for "HTTP/… 301" and the "location:" target
curl -sI https://example.com/old-page

# Follow the whole chain and print each hop's status + final URL
curl -sIL -o /dev/null -w "%{http_code}  %{url_effective}\n" https://example.com/old-page

# Print every status code in the chain (catches multi-hop chains)
curl -sIL https://example.com/old-page | grep -i "^HTTP\|^location"

A clean permanent redirect looks like HTTP/1.1 301 Moved Permanently (or HTTP/2 301) with a single location: header pointing at the final URL. If you see 302, it’s temporary. If you see 200 but the browser still ends up somewhere else, it’s a JavaScript/meta-refresh “fake” redirect.

Windows (PowerShell)

# MaximumRedirection 0 stops at the first hop so you can read its status code
$r = Invoke-WebRequest -Uri "https://example.com/old-page" -MaximumRedirection 0 -SkipHttpErrorCheck
$r.StatusCode              # 301 for a permanent redirect
$r.Headers.Location        # the target URL

Catch a JavaScript “fake” redirect

curl only sees the server response, not JavaScript. If curl says 200 but the page still moves you in a real browser, the redirect is client-side. Confirm it in Chrome DevTools:

1. Open DevTools → Network, check Preserve log.
2. Load the old URL.
3. If the top request shows Status 301 (or 308), it’s a real server redirect. If the first request is 200 and a later navigation entry appears, it’s a JS/meta-refresh redirect — not a true 301.

Apache .htaccess

# Single URL (mod_alias)
Redirect permanent "/old-page" "https://example.com/new-page"

# Pattern / regex rule (mod_rewrite) — R=301 makes it permanent, L stops processing
RewriteEngine on
RewriteRule "^old-section/(.*)$" "https://example.com/new-section/$1" [R=301,L]

# Force HTTP → HTTPS for the whole site
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

nginx

# Single URL
location = /old-page {
  return 301 https://example.com/new-page;
}

# Whole-path prefix
location /old-section/ {
  return 301 https://example.com/new-section/;
}

# Force HTTP → HTTPS
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

WordPress (no plugin — functions.php, use sparingly)

// Runs on every request; a server rule or the Redirection plugin scales better.
add_action( 'template_redirect', function () {
    if ( is_page() && get_query_var( 'name' ) === 'old-page' ) {
        wp_redirect( home_url( '/new-page/' ), 301 );
        exit;
    }
} );

For most WordPress sites, the Redirection plugin or Yoast Premium’s Redirect Manager is the practical choice — no code, and Yoast Premium can auto-create a 301 when you change or delete a URL.

Cloudflare (edge, no origin config)

Cloudflare Single Redirects are built in the dashboard (Rules → Redirect Rules). For a migration, a Bulk Redirects list takes a two-column source → target CSV and applies it account-wide at the edge — the fastest way to move thousands of URLs without touching origin server config.

301 mistakes that turn a clean move into a mess

Redirect every old URL to the homepage

An irrelevant catch-all confuses users and can be treated as a soft 404. Map each old URL to its closest real replacement; return 404 or 410 when no replacement exists.

Add the new target to the end of an old chain

Chaining old → previous → current adds latency and more failure points. Update the oldest rule so it points directly to the final 200 destination.

Leave a 302 on a permanent move

A temporary code asks search engines to prefer the source URL. Use a real server-side 301 or 308 when the move is permanent, then verify the status on the wire.

Remove the redirect as soon as the new URL appears

Index movement is not full signal consolidation. Google recommends keeping redirects for as long as possible, generally at least a year; indefinite retention is better for users and old links when it is operationally cheap.

Trust a broad wildcard without testing its targets

A folder rule can send unrelated URLs to the wrong page. Start with a 1:1 map, test edge cases, and reserve patterns for URL structures whose source-to-target transformation is actually consistent.

Forget non-HTML resources

Images and PDFs can have links and traffic too. Include moved assets in the map when they have relevant replacements; do not blindly redirect every JS, CSS, or font request.

Audit a redirect map before deployment

Paste a CSV containing at least source_url and target_url. Add current source/target status, content type, page title, and topical category when available.

Audit this proposed permanent redirect map.

For each row:
1. Flag homepage or other catch-all targets that are not demonstrably relevant.
2. Flag duplicate sources, missing targets, source=target loops, and likely chains where a
   target also appears as a source.
3. Compare source and target titles/categories only from the supplied data and label the
   mapping relevant, questionable, or insufficient evidence.
4. Recommend one action: keep the 1:1 mapping, map to a closer replacement, return 404/410,
   or investigate manually.

Do not invent replacement URLs or assume a target returns 200 unless the data says so.
Return: critical blockers, row-by-row findings, then the exact URLs to test after launch.

PASTE REDIRECT CSV HERE

The three-clock framework for a 301

“How long does a 301 take?” has no single answer because three systems move on different clocks. Name the clock before you interpret the result.

The framework prevents two common category errors: treating a working server rule as proof that indexing has finished, and treating a changed search result as permission to delete the rule. Validate each clock with its own evidence.

Tools for deploying and checking 301s

Patrick’s free tools

• Redirect Checker — inspect one URL or a quick batch and see the first status, each hop, and the final destination. Use it for the fast “is this a real one-hop 301?” check.
• Redirect Chain Mapper — diagnose what changes at each hop and export cleanup rules for Cloudflare, Apache, or nginx. Use it when the chain itself needs to be collapsed.
• Bulk HTTP Status Code Checker — test up to 500 mapped URLs, filter non-301 sources and non-200 destinations, and export the launch QA set.

Search and infrastructure checks

• Google Search Console URL Inspection — confirm Google has fetched the old URL as a redirect and review canonical selection on the destination.
• Server/CDN logs — verify real Googlebot requests receive the same rule as users.
• A full-site crawler — find missed internal links, old sitemap entries, loops, chains, and redirected assets after a migration.

Test yourself: 301 redirects

Five quick questions on permanent redirects. Pick an answer for each, then check.

Prove the redirect actually worked

You’ve put the 301 live. These are the checks that separate “the rule is in the config file” from “Google is consolidating the old URL onto the new one.” Run them in order — the first is instant, the last takes weeks.

Test 1 — The old URL returns a real server 301

• Test to run — Paste the old URL into the Redirect Checker (or run curl -sIL -o /dev/null -w "%{http_code} %{url_effective}\n" https://example.com/old-url).
• Expected result — The first hop is 301 (or 308) with a location: header, and the final URL returns 200. One hop, clean.
• Failure interpretation — A 200 on the old URL means it’s a JavaScript/meta-refresh “fake” redirect, not a server 301; a 302/307 means you shipped the temporary code by mistake.
• Monitoring window — Immediate — the server answers the moment the rule is live.
• Rollback trigger — The checker shows a chain over ~5 hops or a loop — pull the rule and re-point old → final destination 1:1 before re-shipping.

Test 2 — Google has seen the redirect and picked the new URL

• Test to run — Run URL Inspection in Google Search Console on the old URL.
• Expected result — Status reads “Page with redirect,” and inspecting the new URL shows it indexed with itself as the Google-selected canonical.
• Failure interpretation — If the old URL is still “Submitted and indexed” as its own canonical weeks later, Google either can’t fetch the redirect or a conflicting signal (canonical tag, sitemap, internal links) is pointing back at it.
• Monitoring window — Days to a few weeks for a small/medium site; longer for large ones. Google says visibility can fluctuate during the move — that’s normal.
• Rollback trigger — Don’t remove the redirect to “fix” a lingering old URL — Google holds it as an alternate name and it fades on its own. Only revisit if the new URL never gets indexed at all.

Test 3 — The migration didn’t strand traffic

• Test to run — Batch the mapped old URLs through the Redirect Checker (up to 20 at a time) or a full site crawl, and watch the migrated pages in the GSC Performance report.
• Expected result — Every mapped URL is a single hop to a 200, and clicks/impressions on the destination recover toward the old URLs’ prior levels within a few weeks.
• Failure interpretation — A sustained drop usually means a broken map (old URL → wrong or irrelevant page, which Google may treat as a soft 404) rather than the redirect “leaking” PageRank — a proper 301 doesn’t cause a PageRank loss.
• Monitoring window — 2–4 weeks of GSC data before the trend is trustworthy; compare a matched before/after window, not day-to-day noise.
• Rollback trigger — A clear, sustained impressions drop on the migrated set that lines up with the launch date — re-audit the 1:1 map before assuming the redirect itself is the problem.

301 redirect

A 301 redirect is the HTTP status code for a permanent move: it tells browsers and search engines a URL has moved for good, and it's the strongest signal for consolidating a page's ranking signals onto the new URL. Google says permanent redirects don't cause a loss in PageRank.

Related: 302 redirect, Redirect chain

301 redirect

A 301 redirect (HTTP status code “301 Moved Permanently”) is a server-level response that tells browsers and search engines a URL has permanently moved to a new location. It’s the standard mechanism for consolidating duplicate URLs, executing site migrations, moving from HTTP to HTTPS, and preserving ranking signals when a page’s address changes.

Google frames it plainly: “The 301 and 308 status codes mean that a page has permanently moved to a new location,” and it recommends a permanent server-side redirect “whenever possible” when a URL needs to change. In the indexing pipeline, a 301 is a strong hint for canonicalization — Google keeps track of both the old (source) and new (target) URL and treats the target as the one that should be indexed.

Two things people get wrong:

• A 301 doesn’t lose link equity. Google states outright that “301 and other permanent redirects don’t cause a loss in PageRank” — the old “10–15% loss per hop” folklore is outdated. (There’s no published figure for a precise percentage passed; don’t quote one.)
• Keep it in place. Google advises keeping redirects “for as long as possible, generally at least 1 year” so all signals have time to transfer — and ideally indefinitely for users.

Distinct from a 302 redirect (temporary — tells Google to keep the old URL indexed) and from rel="canonical" (a consolidation hint where both URLs stay live). A real 301 is a server response, not a JavaScript or meta-refresh workaround.

Related: 302 redirect, Redirect chain

Changelog