BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
How 301 Redirects Work Technically: The HTTP Mechanics, Signal Transfer, and the Source Domain Behind Every Redirect
A 301 redirect is an HTTP response that tells a browser and a search crawler that a URL has moved permanently, and points them to its replacement. At the protocol level it is one status line and one header. At the SEO level it is the mechanism that consolidates a page’s ranking signals onto a new address.
This guide opens the hood. It walks the raw request and response header by header, lists every redirect method Google recognises, separates 301 from 302, 307, and 308, and explains exactly how ranking signals move across a redirect, cited to Google’s own documentation and the HTTP specification instead of asserted.
It also draws the line the field skips. A 301 only carries what the source URL genuinely earned. Redirect a strong, relevant domain and the signals consolidate; redirect a junk one and there is nothing to pass. The redirect is the pipe, the domain is the water. SEO Domains operates the curated marketplace where the aged and expired domains that make a 301 worth running are screened before they are listed.
What a 301 redirect is, at the protocol level
A 301 redirect is the HTTP status code 301 Moved Permanently, returned by a server to tell any client that the requested URL has been permanently replaced by the address in the response Location header. Browsers follow it automatically, cache it, and request the new URL; search crawlers follow it and treat the target as the canonical version of the original page.
The number is a protocol fact, not an SEO convention. The Hypertext Transfer Protocol defines a family of 3xx status codes for redirection, and 301 is the permanent member. RFC 9110, the current HTTP Semantics specification, places its definition in section 15.4.2 and assigns it the reason phrase Moved Permanently. Everything an SEO calls a redirect rides on top of that one status line.
The two parts of a 301: a status line and a Location header
A 301 response is small. It needs a status line that carries the code 301, and it needs a Location header that names the new URL. The body is optional and usually a short human-readable note. The browser never shows that body, because it reads the Location header and immediately requests the new address instead.
That structure is why a redirect feels instant. There is no page to render at the old URL. The server answers the request with an instruction, not a document, and the client acts on the instruction before a visitor sees anything.
Permanent is a promise the client remembers
The word permanent in Moved Permanently is a signal to the client that the move is not coming back. A browser is allowed to cache a 301 and skip the old URL entirely on future visits, going straight to the target. A search engine treats permanence as the cue to consolidate the old page into the new one over time.
This is the trait that makes a 301 the right tool for a domain move, a slug change, or a content merge, and the wrong tool for anything temporary. The permanence is the whole point, and reversing it later is slow because clients have cached the instruction. The contrast with temporary codes is the subject of a later section.
The raw HTTP exchange, header by header
A 301 plays out as two round trips. The client requests the old URL, the server answers 301 with a Location header and a cache directive, then the client requests the URL in that header and the server answers 200 with the real page. Reading the raw headers is the clearest way to see what a crawler reads, and it is the detail the field skips.
The exchange below is the kind of trace any developer can capture with a command-line tool. It is reproduced from the documented MDN Web Docs example for a real 301 on developer.mozilla.org, so the header shapes are authentic instead of invented.
Step 1. The client requests the old URL
GET /en-US/docs/AJAX HTTP/2
Host: developer.mozilla.org
User-Agent: curl/8.6.0
Accept: */*
Step 2. The server answers 301 with a Location header
HTTP/2 301 cache-control: max-age=2592000,public location: /en-US/docs/Learn_web_development/Core/Scripting/Network_requests content-type: text/plain; charset=utf-8 content-length: 97 Moved Permanently. Redirecting to /en-US/docs/Learn_web_development/Core/Scripting/Network_requests
What each line does
The first line of the response is the status line, HTTP/2 301. That single token is the entire decision. It tells the client this is a permanent redirect, and every following header is context for that instruction.
The location header is the destination. Its value is the URL the client requests next, and for a search crawler it is the address that will inherit the original page’s identity. The cache-control header, here max-age=2592000 public, tells the browser it can remember this redirect for 2,592,000 seconds, which is 30 days, before checking again. The content-type and content-length describe the tiny placeholder body that no human reads.
The second round trip, and why crawlers value clean ones
After reading the location header, the client makes a second request, this time for the target URL, and the server answers with a normal 200 OK and the real page. Two requests, one redirect. A search crawler follows the same path, and a single clean hop from old to new is the pattern it processes with the fewest errors. Pile up extra hops and the chain becomes the problem covered in 301 redirect chains.
Every redirect method Google recognises
A server-side HTTP 301 is the strongest redirect, but it is not the only one Google reads. Google’s documentation lists eleven redirect methods and sorts them into permanent and temporary. The permanent group, the one that behaves like a 301 for canonicalisation, includes HTTP 301, HTTP 308, an instant meta refresh, an instant HTTP refresh, a JavaScript location change, and a crypto redirect.
Standard SEO guides stop at 301 versus 302. Google’s own redirect documentation is more complete, and reproducing it is one of the edges this guide adds. The table below is that classification, attributed to Google Search Central.
| Redirect method | How Google treats it | Where it lives |
|---|---|---|
| HTTP 301 (Moved Permanently) | Permanent. Strongest canonicalisation signal. | Server response header |
| HTTP 308 (Permanent Redirect) | Permanent. Same signal as 301, preserves the request method. | Server response header |
| Instant meta refresh (0 seconds) | Permanent. Google interprets a 0-second meta refresh as a permanent redirect. | HTML head tag |
| Instant HTTP refresh (0 seconds) | Permanent. The header-based equivalent of a 0-second meta refresh. | Refresh response header |
| JavaScript location | Permanent, once Google renders the page. Rendering can fail. | Client-side script |
| Crypto redirect | May be read as permanent. Google advises against relying on it. | Plain link plus text |
| HTTP 302 (Found) | Temporary. The source URL stays canonical. | Server response header |
| HTTP 303 (See Other) | Temporary. | Server response header |
| HTTP 307 (Temporary Redirect) | Temporary, preserves the request method. | Server response header |
| Delayed meta refresh (over 0 seconds) | Temporary. | HTML head tag |
| Delayed HTTP refresh (over 0 seconds) | Temporary. | Refresh response header |
Why a server-side redirect beats a client-side one
A server-side 301 or 308 is decided before any page loads. The server reads the request and answers with the redirect, so a crawler gets the instruction in the response headers with no rendering required. That reliability is why it is the default recommendation.
Client-side methods sit lower because they depend on something else happening first. Google states that it interprets and executes JavaScript using its Web Rendering Service after crawling completes, and that the rendering step can fail. A meta refresh lives inside the HTML and is read as permanent only when the delay is zero. The honest reading is that these methods work, but they introduce a dependency a header-level redirect does not have.
301 vs 302 vs 307 vs 308: permanence and the method rule
The 3xx codes split on two axes: permanent versus temporary, and whether the request method is preserved. A 301 is permanent but can let a client switch a POST to a GET. A 302 is temporary. A 307 is a temporary redirect that preserves the method, and a 308 is the permanent redirect that preserves the method. For SEO, permanence is what decides which URL becomes canonical.
The permanent-versus-temporary distinction is the one the SEO field covers, and it matters because it decides canonicalisation. A 301 tells a crawler to consolidate the old URL into the new one. A 302, the temporary code, tells it the original URL is still the one to index, so signals do not move. Choosing 302 for a permanent move is a common way to leak the consolidation a 301 would have delivered.
The method-mutation rule almost no SEO guide mentions
There is a second axis the field rarely covers, and it is a genuine technical edge. According to the Fetch standard cited by MDN Web Docs, when a user agent receives a 301 in response to a POST request, it is permitted to use the GET method in the follow-up request. The method changes. For a navigational page redirect this is invisible, but for an endpoint that expects a POST it can quietly break a workflow.
The fix the specification names is to use 308 Permanent Redirect instead, because altering the method after a 308 is prohibited. So 308 is the method-safe twin of 301, and 307 is the method-safe twin of 302. For redirecting content pages a 301 is correct and standard. For redirecting form submissions or API calls, 308 is the precise choice.
| Code | Permanence | Method preserved | SEO effect | Use it for |
|---|---|---|---|---|
| 301 Moved Permanently | Permanent | Not guaranteed (POST may become GET) | Target becomes canonical, signals consolidate | Permanent content and URL moves |
| 302 Found | Temporary | Not guaranteed | Source stays canonical, no consolidation | Temporary moves, split tests |
| 307 Temporary Redirect | Temporary | Preserved | Source stays canonical | Temporary moves of POST endpoints |
| 308 Permanent Redirect | Permanent | Preserved | Target becomes canonical, like 301 | Permanent moves of POST endpoints |
The full ranking-impact comparison between the permanent and temporary codes is the subject of 301 vs 302 for SEO, which takes the choice from the protocol level into the indexing decision.
How a 301 passes ranking signals
A 301 passes ranking signals through canonicalisation. Google follows the redirect, treats the target as the canonical URL of the original page, and attributes the links that pointed at the old address to the new one. The industry consensus, cited to Moz, is that a 301 carries the large majority of link equity, and Google has stated permanent redirects do not cause a ranking loss by themselves.
The mechanism is not magic. Search engines index pages, score them on signals including the links pointing at them, and pick one canonical URL when two or more addresses serve the same content. A 301 is the clearest instruction to make that canonical the target. Google’s documentation states it directly: Googlebot follows the redirect, and the indexing pipeline uses the redirect as the signal that the redirect target is the canonical URL.
What actually moves across the hop
Three things travel from the old URL to the new one when a 301 is read and accepted. The links that pointed at the old page are attributed to the new page. The canonical identity, the version Google chooses to index and rank, shifts to the target. The relevance the old URL accumulated transfers, but only to the degree the new page is about the same topic.
MDN Web Docs states the link effect plainly: search engines receiving a 301 will attribute links from the original URL to the redirected resource, passing the ranking to the new URL. That is the link-equity transfer in one sentence, from a primary specification source instead of from folklore.
The cited equity figure, and the honest caveat
The number repeated across the field comes from Moz, which has put the link equity a 301 carries in the range of 90 to 99 percent. Treat that as the cited industry estimate it is, not a precise law. Google representatives, including Gary Illyes in a 2016 statement on PageRank and redirects, have said that 301 and other 3xx redirects do not lose PageRank by themselves, which narrowed the older assumption of a fixed decay on every hop.
The two readings are reconcilable. A single, relevant, server-side 301 to a canonical target loses little to nothing. Equity leaks when the redirect is one of the things done wrong, and that failure mode is the next section. Named practitioners such as Aleyda Solis and Marie Haynes have made the same point in their migration guidance: the redirect rule is the easy part, and the losses come from the conditions around it.
One condition sits upstream of all the others, and it is the source domain itself. Because a 301 forwards only the authority the source already holds, the worthwhile move is to acquire a clean, relevant source domain before writing a single rule. The SEO Domains marketplace lists aged and expired domains screened for exactly that, from $100 entry-level names through premium acquisitions, so the redirect starts from authority that is real instead of inflated.
Why a 301 sometimes fails to pass equity
A 301 leaks or loses equity for four documented reasons: the target is not relevant to the source, the redirect runs through a chain of hops, the target is not the canonical URL, or the redirect is a soft client-side method that a crawler does not read as permanent. Each is a done-wrong condition around an otherwise sound mechanism, and each has a fix.
The protocol is reliable. The failures sit in how it is applied. Walking the four causes is the practical core of this topic, because knowing why a redirect underperforms is what separates a clean migration from a traffic drop.
-
Irrelevance: the target is not about the source’s topic
A 301 transfers relevance only to the extent the target covers the same subject. Redirecting a page about running shoes to a generic homepage strips the topical match that gave the links their value. The done-right move is to redirect each URL to the closest equivalent page, not to a catch-all.
The mistake: mass-redirecting every retired URL to the homepage. Google can treat an irrelevant redirect as a soft 404 and decline to pass the signal, so the equity evaporates. The relevance rule is detailed in Relevance requirement for 301 (Koray’s rule).
-
Chains: the redirect passes through extra hops
A clean redirect is one hop, old to new. A chain is old to middle to new, sometimes through three or four stops. Each hop adds latency and a chance for a crawler to stop before the end. The done-right move is to point every old URL straight at the final destination.
The mistake: layering new redirects on top of old ones over years until a URL hops three or four times. Google recommends keeping redirects to a single hop, and long chains are where the trade-press estimates of equity loss come from. The full treatment is in 301 redirect chains.
-
A non-canonical target: the redirect lands on the wrong version
If the redirect points at a URL that itself canonicalises elsewhere, the signal has to travel further and can be split. The done-right move is to redirect to the canonical URL directly, with no trailing-slash, protocol, or parameter mismatch in the way.
The mistake: redirecting to the http version of a page that canonicalises to https, or to a URL with tracking parameters. Google advises redirecting only to canonical URLs, and a mismatch here quietly dilutes the consolidation.
-
A soft redirect: a client-side method read as temporary
A JavaScript or delayed meta-refresh redirect can be read as temporary or missed if rendering fails. The done-right move is a server-side 301 or 308 at the header level, so the instruction is permanent and rendering-independent.
The mistake: using a delayed meta refresh or relying on a script for a permanent move. A delayed refresh is classified as temporary, so the source URL stays canonical and the signals never move. The deeper implementation detail is in 301 implementation best practices.
How to deploy a 301 correctly, step by step
Deploying a 301 correctly is a five-step sequence: confirm the move is permanent, choose the cleanest redirect method for your stack, map each old URL to its closest relevant canonical target, deploy a single-hop rule, then verify the live response code and monitor. The technical work is small; the mapping and verification are where the result is won or lost.
The mechanics differ by server, but the sequence does not. The steps below are the platform-neutral version; the syntax for each stack lives in its own guide.
-
Confirm the move is genuinely permanent
A 301 is a one-way door for clients that cache it. Use it only when the old URL is gone for good. For a temporary move, a 302 or 307 is the correct code instead, so the source URL stays indexed.
The mistake: using a 301 for a seasonal page or a short maintenance move. Clients cache the permanent instruction, and undoing it later is slow.
-
Choose the cleanest method for the stack
A server-side header redirect is the default. On Apache that is a Redirect or RewriteRule in the configuration, with the syntax shown in .htaccess 301 redirect examples. Use 308 instead of 301 when the URL handles POST requests.
The mistake: reaching for a JavaScript or meta-refresh redirect when a header-level rule is available. The client-side method adds a rendering dependency for no benefit.
-
Map each old URL to its closest relevant target
Build a one-to-one map from every retired URL to the closest equivalent page. A page about a product redirects to that product or its nearest replacement, not to the homepage. This mapping is the step that preserves relevance.
The mistake: a blanket rule sending all old URLs to one page. It is fast to write and it strips the topical match Google needs to pass the signal.
-
Deploy single-hop rules and update internal links
Each rule points straight at the final destination, with no intermediate hop. Then update internal links, menus, and the XML sitemap to reference the new URLs directly, so crawlers and visitors never rely on the redirect.
The mistake: leaving internal links pointing at redirected URLs. Every internal link to an old address forces an extra hop and wastes crawl budget on a redirect meant to stay invisible.
-
Verify the live response, then monitor
Request the old URL and confirm the server returns a single 301 and the correct Location, landing on a 200. Then track indexing and traffic on the target. Monitoring the migration in Search Console is covered in Monitoring 301 impact in GSC and the wider strategy hub.
The mistake: deploying and walking away. An unverified redirect can be a chain, a loop, or a wrong target, and the loss only shows up weeks later in lost rankings.
Common 301 mistakes: the consolidated checklist
The mistakes that cost a 301 its equity are a short, repeatable list. Each one is a done-wrong condition, each has a clear technical reason it leaks, and each has a fix. The fixes converge on the same shape: a single, relevant, server-side hop to a canonical target, from a source domain that earned its authority honestly.
The table below consolidates the failure modes scattered through this guide into one scannable reference. The left column is the mistake, the centre column is why it leaks at the protocol or indexing level, and the right column is the done-right fix.
| The mistake | Why it leaks equity | The fix (done-right move) |
|---|---|---|
| Redirecting everything to the homepage | An irrelevant target can be read as a soft 404 and the signal is not passed | Map each URL to its closest relevant equivalent page |
| Redirect chains of two or more hops | Each hop adds latency and a chance the crawler stops before the end | Point every old URL straight at the final destination, one hop |
| Using a 302 for a permanent move | A temporary code keeps the source canonical, so signals never consolidate | Use 301 for permanent moves, 308 when the method must be preserved |
| Landing on a non-canonical URL | The signal travels further or splits when the target canonicalises elsewhere | Redirect directly to the canonical URL, matching protocol and slash |
| JavaScript or delayed meta-refresh redirect | Client-side methods depend on rendering and can be read as temporary | Use a server-side header 301 or 308, rendering-independent |
| Internal links still pointing at old URLs | Every internal link to a redirected URL forces an extra hop and wastes crawl budget | Update internal links, menus, and sitemap to the new URLs |
| Deploying without verifying the live response | An unverified rule can be a chain, loop, or wrong target found only after the loss | Confirm a single 301 plus a 200 on the target before moving on |
| Redirecting from a junk or spam-flagged source domain | A 301 carries only earned authority; a toxic source has nothing clean to pass | Source a clean, relevant aged or expired domain, screened before purchase |
One pattern runs down the fix column. A 301 carries signal when it is a single, relevant, server-side hop to a canonical target, and when the domain it starts from earned real authority in the first place. The first seven rows are execution. The last row is the raw material, and it is the variable this guide closes on.
301 redirect frequently asked questions
The five questions site owners and SEOs raise when they search for how a 301 redirect works technically, answered against Google’s documentation, the HTTP specification, and the cited industry consensus.
Q1Is a 301 redirect permanent, and can it be reversed?
A 301 declares the move permanent, and browsers are allowed to cache the instruction, here for the 30 days the example cache-control header specified. It can be reversed by removing the rule, but the change is slow to take effect for returning visitors because their browser has already cached the redirect. Reversal is possible; instant reversal is not.
Q2How long does a 301 take to work?
For a visitor the redirect is instant, because the server answers with the instruction instead of a page. For search engines the consolidation is gradual. Google has to recrawl the old URL, follow the redirect, and reassign the canonical, which takes from days to weeks depending on the page’s crawl frequency. The redirect fires immediately; the ranking transfer settles over time.
Q3Does a 301 pass all of the link equity?
The cited industry figure from Moz puts it at 90 to 99 percent of link value, while Google representatives have stated that 301 and other 3xx redirects do not lose PageRank by themselves. The reconciliation is that a single relevant server-side 301 to a canonical target loses little to nothing, and the losses people attribute to the redirect trace back to irrelevant targets, chains, and non-canonical destinations.
Q4What is the difference between a 301 and a 308?
Both are permanent and both pass the canonical signal. The difference is method preservation. According to the Fetch standard cited by MDN Web Docs, a client receiving a 301 on a POST request is permitted to switch to GET, while a 308 prohibits changing the method. For ordinary content pages a 301 is correct and standard. For endpoints that handle form or API submissions, 308 is the method-safe choice.
Q5What are the recurring 301 redirect mistakes?
The frequent failures are redirecting everything to the homepage, building chains of two or more hops, using a 302 for a permanent move, landing on a non-canonical URL, and relying on a client-side method for a permanent change. Each one breaks the single-relevant-server-side-canonical pattern that makes a 301 pass its signal cleanly, and each is listed with its fix in the checklist above.
The redirect is only as strong as the domain behind it
A 301 transfers the authority the source URL already holds, and nothing more. The mechanism is identical whether the source is a clean, relevant aged domain or a junk drop, but the outcome is not, because a junk source has no real authority to pass. Sourcing the right domain is the variable that decides what a redirect is worth. SEO Domains operates the curated marketplace where that raw material is screened before it is listed.
Why the source domain decides the outcome
Every technical step in this guide assumes the source has something worth moving. A single, relevant, server-side hop to a canonical target is perfect execution, and it still delivers nothing if the originating domain never earned authority. The redirect is the pipe; the domain is the water. This is why the first decision in any redirect strategy is which domain you are redirecting from.
The clean source versus the junk source
An aged or expired domain with a real, editorially earned backlink profile and a history relevant to the target is a legitimate source for a 301. Its authority is genuine, so the consolidation moves something real. A spam-flagged drop bought for an inflated metric is the opposite: its profile is already discounted in Google’s link graph, so the redirect forwards a liability, not an asset.
How to source a domain that carries a real signal
A source domain that holds up survives a profile check before money changes hands. The signals that matter are documented across the authority-metrics hub, and they are the same ones that decide whether a 301 from that domain consolidates anything:
- Referring domains and the quality, not just the count, of the links pointing in.
- Topical relevance between the source domain’s history and the target it will redirect to.
- A clean spam screen, with the registration history readable through RDAP, the ICANN lookup that replaced WHOIS on 28 January 2025.
- Real prior use rather than a previously spammed or unrelated history.
A junk domain passes none of these, and a 301 from it forwards a discounted profile. A vetted domain passes them, and a 301 from it moves authority that was genuinely earned.
| Check | Junk source (forwards a liability) | Vetted source (forwards an asset) |
|---|---|---|
| Backlink profile | Toxic or spam-inflated, already discounted | Clean, editorially earned |
| Topical relevance | Unrelated to the redirect target | Continuous with the target’s subject |
| Registration history | Opaque or prior abuse | Real prior use, readable in RDAP |
| Screening before sale | None, sold on a raw metric | Multi-signal screen before listing |
| Result of the 301 | Forwards a discounted signal | Consolidates genuine authority |
Browse curated aged and expired domains with clean profiles
The legitimate demand behind a technical 301 search is access to a real, relevant source domain you can redirect with confidence. That is the product: a clean aged or expired domain, not redirect software and not hosting. SEO Domains operates the curated marketplace where aged and expired domains are screened across their backlink profiles, topical history, and authority metrics before they are listed and priced, so the source of any 301 starts as a vetted asset.
