301 Permanent Redirects, Stated Precisely

What a 301 Says, at the Protocol Level

A redirect is an HTTP response, not a page. The server answers a request with a status code in the 300 range and a Location header naming a different URL; the client then requests that URL instead. Google states that content received from the redirecting URL is ignored and the final target URL's content is processed instead.

A 301 is Moved Permanently. It tells every client — browser, crawler, link checker — that the resource has a new address and that future requests belong there. Browsers cache permanent redirects, sometimes aggressively, which is why a mistaken 301 in production is harder to withdraw than a mistaken 302.

For Google Search, two documented consequences follow from permanence. Google shows the redirect target in search results rather than the source, and Google's canonicalisation documentation treats a permanent redirect as a strong signal that the target should become canonical — above sitemap inclusion, which it calls a weak signal. Note what a 301 is not: an instruction about ranking, or a statement about anything Google measures internally. It is a claim about identity.

The Full Family, as Google Groups Them

Google organises redirects by whether they signal permanence, because permanence is what drives canonicalisation.

Google ranks implementation methods by reliability: server-side redirects, which it calls the best way to ensure Google Search and people are directed to the correct page; meta refresh; JavaScript location redirects, to be used only if you cannot do server-side or meta refresh redirects, because rendering may fail; and crypto redirects, plain text or link-based, which Google may not recognise.

In the HTTP specification, 307 and 308 require the request method and body to be preserved, whereas historical practice with 301 and 302 allowed a client to convert a POST into a GET. Google's Search documentation does not draw that distinction — for indexing it groups 301 with 308, and 302 with 303 and 307.

Chains, Hops, and the Ten-Hop Limit

Google's documentation states that by default its crawlers follow up to 10 redirect hops, and that specific products' crawlers may have different limits. Three points of precision matter here, because this is where published advice goes wrong.

First, where the figure lives. The ten-hop statement appears in Google's documentation on HTTP status codes, network and DNS errors — not in the redirects documentation, which does not discuss chains or hop limits at all.

Second, what Google does not say. Google documents the limit but not the consequence of exceeding it. Practitioner literature commonly asserts that a longer chain causes the URL to be treated as an error and dropped; that is not stated in Google's documentation, so do not present it as Google's position.

Third, the five-hop figure still in circulation. It comes from trade coverage of a January 2020 answer by a Google representative in a video series; current documentation says ten, so treat five as outdated folklore. One further documented point is easy to miss: Google Inspection Tools does not follow redirects, so URL Inspection will not walk a chain for you.

How Long to Keep Them, and the Two Clocks

Google's site-move documentation is unambiguous: keep the redirects for as long as possible, generally at least one year. Google separately notes that a small-to-medium site typically takes a few weeks for most pages to move and that traffic fluctuation during a move is normal.

In practice a year is a floor, not a target. Redirect rules are cheap to keep and expensive to recreate, and external links to old URLs persist for years — from directories, PDFs, trade publications and partner sites. There is rarely a good reason to remove a working redirect at all.

Two separate clocks cause real confusion. The Change of Address tool in Search Console maintains the migration relationship for 180 days after the migration is started, after which Google treats the two sites as unrelated. The redirects themselves should stay for at least a year. The tool also requires that 301 redirects already be in place and that you own both properties at domain level in the same account, and it cannot be used for HTTP to HTTPS moves, same-domain path changes, or a www to non-www transition.

What Google Does and Does Not Say About Signal Transfer

This is where confident claims outrun the evidence, so it deserves care.

What is verifiable: Google's current redirects documentation does not mention PageRank, link equity, ranking signals or signal loss anywhere. That page addresses canonicalisation and which URL is shown in results. Google's canonicalisation documentation describes a permanent redirect as a strong signal that the target should become canonical. And Google's site-move documentation says keeping redirects for at least a year allows it to transfer signals to the new URLs, including reassigning links from other sites — which affirms that signals transfer, without quantifying anything.

What is not documentation: the widely repeated claim that 301 redirects lose no PageRank traces to a 2016 statement by a Google employee on social media, to the effect that 30x redirects no longer lose PageRank. That is a remark by an individual, nearly a decade old, about a system Google does not describe publicly. It is also sometimes quoted as though Google's documentation contained the sentence. It does not.

The defensible position: signals transfer, Google says so, and nobody outside Google can quantify the transfer. Keep percentages out of the board paper.

Seven Migration Mistakes That Actually Cost Rankings

• Redirecting everything to the homepage. It happens because it is one line of configuration and it silences the 404 report. It answers a request for a specific page with something that does not replace it, serving neither the visitor nor the consolidation Google is being asked to perform. Map page by page; where no equivalent exists, redirect to the nearest genuine parent, and otherwise serve a deliberate 404 or 410.
• Trusting a canonical tag where a redirect is required. Google is explicit that a canonical preference is a hint, not a rule. Where the outcome must be certain, redirect.
• Chains built one migration at a time. Each project points old URLs at the previous project's target, so three platform changes later a single URL takes four hops. After every migration, flatten the rules so each source points at the current final target.
• Redirect loops. Almost always two rules written by two people — a protocol rule interacting with a trailing-slash rule, or a CDN rule fighting an application rule. The visitor sees a too-many-redirects error; the crawler gets nothing.
• Losing the map. The mapping spreadsheet sits on somebody's laptop and leaves with them. Store it in version control beside the rules.
• Redirecting to a 404 or a noindexed page. The redirect resolves; the destination is gone or excluded. Test the final response of every target, not the redirect's own status.
• Using a 302 for a permanent move. Usually a framework, load balancer or hosting default rather than a decision. Google treats it as temporary and keeps showing the old URL.

Testing the Map Before Launch, and Verifying After

A redirect map is data and should be tested like data — automatically, repeatedly, and before anyone announces a launch date. Build the source inventory from more than the content management system, which knows only about URLs it created. Crawl the live site, then add every URL with impressions in Search Console, every historical landing page in analytics, every path in the server access logs, and every URL with an external link — the last two are where the forgotten but valuable URLs are.

Hold the map as a table of three columns: source, intended target, expected final status. Test it against staging using a staging hostname or a host header override, and assert three things per row — the final status is 200, the hop count is one, and the final URL matches the intended target exactly, including protocol, host, case and trailing slash. Include the awkward cases deliberately: uppercase variants, query strings, both protocols, both hostname forms.

After launch, run the whole map again against production, because the two configurations diverge more often than anyone expects. Keep both Search Console properties verified and read the 404 log daily for a fortnight; real URLs will appear that no inventory caught. Then keep the map and the rules indefinitely, flatten chains after every later migration, and diarise a review a year out. A redirect map is the permanent record of every address the site has ever had, and the next migration begins by reading it.

Frequently Asked Questions