How to Implement 301 Redirects for a Site Migration
Redirects are the mechanism by which everything the old site earned reaches the new one. This guide explains what each type means, what the vendor has actually published about accumulated value and the mistakes that quietly undo the work, without turning into a configuration manual.
What A Redirect Actually Does
A redirect tells anything arriving at an old address where the content now lives. It does that for people and for crawlers at the same time, using the same instruction, which is the fact everything else on this page follows from.
What the visitor experiences. Almost nothing.
Somebody clicking an old link arrives at the new page. There is no error, no warning and usually no perceptible delay. From their side the migration is invisible, which is exactly the intention.
What a crawler receives. A statement.
Not just a destination. It is a claim about the relationship between the two addresses. Whether the move is permanent or temporary is part of that statement, which is block two.
Why the dual purpose matters. One mechanism, two audiences.
You cannot serve people correctly and communicate badly with crawlers, nor the reverse. A redirect that sends a visitor somewhere useless is also telling a crawler something useless. Both consequences arrive together.
What this page will not cover. How to create them.
That belongs to whoever builds and maintains the site. What follows is what has to be decided and what goes wrong.
Permanent Or Temporary
The two common redirect types differ in what they claim rather than in what they do. Both send a visitor to the same place. They disagree about whether the move is going to last.
Permanent. This has moved and is not coming back.
The old address is finished, the new one has taken over and anything holding a reference to the old one should update it. That is the correct statement for a migration.
Temporary. This is somewhere else for now.
The old address still matters and will return. Appropriate for maintenance, for a seasonal page or for testing. Wrong for a move that is never being reversed.
Why using the wrong one is consequential. It contradicts the plan.
A migration announced with temporary redirects is telling everything that the old addresses remain the real ones. The site is then saying one thing through its redirects and another through everything else.
Why it happens. Defaults and haste.
Some systems create temporary redirects unless told otherwise. Under launch pressure nobody checks which type was produced. It is worth confirming rather than assuming, because both look identical to a visitor.
What Happens To Accumulated Value
This is the question everybody asks and the one most heavily speculated about. Our position is to report what the vendor has published and to stop there.
What the documentation states. Checked August 2026.
The published site move guidance says that permanent redirects do not cause a loss in the vendor's own link-based measure. That is their wording, in their own documentation. It is a stronger statement than most of what circulates on the subject.
What that does not mean. Worth being precise.
It is a statement about that particular measure rather than a guarantee about every signal that contributes to a ranking. Position depends on more than one input. The documentation does not claim otherwise.
What we will not state. A percentage.
Figures circulate about how much value passes through a redirect. None is attributable to a published source, so we do not repeat them. If somebody quotes one, ask where it came from.
The practical reading. The mechanism is sound.
A correctly built permanent redirect to a genuinely equivalent page is intended to carry the old address forward. What goes wrong is almost never the redirect type. It is the destination, the chain or the removal, which are blocks four, five and eight.
Redirect Chains
A chain is an address that redirects to an address that redirects again. Everything still works, nothing reports an error and the site is doing more work than it needs to on every one of those requests.
How they form. Successive migrations.
A site moves, so old addresses point at new ones. Years later it moves again, then the second set of redirects is built from the current addresses. The oldest addresses now travel through two hops to arrive, then three after the next move.
Why nobody notices. The destination is correct.
Testing an old address confirms it arrives at the right page. It does, eventually. The check that finds a chain is one that counts the hops rather than one that confirms the endpoint.
Why they matter. Speed and clarity.
Each hop is another request before anybody sees anything. And a longer chain is a less direct statement about where content lives, which is worth avoiding on principle even without quantifying the cost.
The fix. Flatten them.
Every old address should point directly at its final destination rather than at an intermediate one. Once found, this is straightforward, which makes chains one of the better returns available after a migration.
Redirect Loops
A loop is a chain that returns to where it started. The first address points at the second, the second points back at the first, so nothing ever arrives anywhere.
What happens. The page breaks entirely.
Unlike a chain, this is not a quiet inefficiency. The browser gives up and reports an error. The page is completely unreachable for everybody.
How they occur. Two rules that disagree.
Usually two separate redirect instructions created by different people at different times, each sensible alone. One says an old address now lives at a new one. Another, added later, says the reverse.
Why they are easier than chains. They announce themselves.
A loop produces a visible failure, so somebody reports it quickly. A chain produces nothing and can persist for years.
Where they hide. Edge cases.
The dangerous loops are on address types nobody tests, which is another argument for testing every category rather than a sample.
Where Redirects Live
Redirects can be handled at three different levels. Which one is used has consequences for speed, for maintainability and for who is able to change them.
At server level. The fastest, also the least accessible.
Handled before the site itself is involved, which is efficient. It also means changes require somebody with access to that layer, which on many arrangements is not the person who needs to make them.
At platform level. Managed by the system itself.
Slower than server level, since the platform has to be running to answer. Considerably easier to maintain, because the people responsible for the site can see and edit the list.
Through an added component. The most accessible.
Common on content systems, easy for anybody to use and dependent on that component continuing to exist and be maintained. Where redirects live inside something that could be removed, they can vanish with it.
What to decide, plus when. Before the mapping.
Whichever level is chosen has to be capable of holding the volume the map will contain, which is block seven.
Platform Limits Are A Real Constraint
Some hosted platforms restrict how many redirects can be created, else restrict how they behave. That has to be established before a mapping is built rather than discovered when somebody tries to load it.
What the restrictions look like. Three kinds.
A ceiling on how many can exist. Restrictions on the patterns that can be expressed, so each has to be listed individually. And limits on which address types can be redirected at all.
Why this bites during a migration specifically. Volume.
Ordinary site maintenance produces a handful of redirects. A migration produces one for every address the old site had, which on a mature site can be a number no hosted platform was designed to hold.
What happens when it is discovered late. Compromise.
A map that cannot be loaded gets reduced. Something has to be dropped. What gets dropped is usually the long tail of old addresses, which is where the accumulated links sit.
How to establish it. Ask, before choosing.
How many redirects the platform supports and whether patterns can be used. Both are answerable in advance and both belong in the decision about which platform to move to.
How Long To Keep Them
Indefinitely, where that is possible. There is published guidance on the minimum. The practical answer sits well beyond it.
What the documentation advises. Checked August 2026.
The vendor's own site move guidance recommends keeping redirects for as long as possible and generally for at least a year, so that signals transfer and links on other sites are recrawled and reassigned. It adds that from a user's perspective, keeping them indefinitely is worth considering.
Why the minimum is a minimum. Links do not expire.
A link made five years ago on somebody else's site still exists and still sends people. Removing the redirect it depends on breaks it. Neither the link nor the person clicking it knows anything about your migration timetable.
What removal actually does. Undoes the migration, quietly.
Taking redirects away later is the delayed version of never having built them. Nothing announces it. Traffic that had been arriving simply stops, long after anybody is looking for a cause.
The better parallel action. Update the links themselves.
The same guidance suggests updating your own links and asking about high-value ones elsewhere, since a direct link is better than a redirected one. That reduces dependence rather than removing protection.
Testing Them Against The Map
Redirects are verified against the mapping rather than inspected on their own. Without the map there is no standard to test against, which is one of several reasons the map has to exist first.
What testing establishes. Three things.
That every source address in the map resolves. That it resolves to the destination the map specifies rather than to something plausible. And that it arrives in one hop rather than through a chain.
Why a sample fails. Failures cluster.
Problems concentrate by address type rather than spreading evenly. A sample of ordinary pages can pass completely while every parameter address fails, because the rule that handled one never covered the other.
When to do it. Twice.
Before launch, while corrections are cheap. And immediately afterwards, because the live environment can behave differently from the one it was tested in.
What to do with what you find. Fix in order of value.
Priority list first, then everything else. The map is in URL mapping for a site migration, diagnosis is in redirect errors and recovery after migration, the wider catalogue is in common site migration mistakes. The full series is on the website migration guide.
Removed later,
the migration
quietly undone.
The permanent type confirmed rather than assumed because some systems default to temporary, chains flattened so every old address arrives in one hop, the platform ceiling established before the map is built, redirects kept rather than tidied away a year later, with only published statements repeated about what carries across.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
