Redirects and Site Migrations Done Right: The 2026 SEO Playbook

Administrator in Search Engine Optimization Jul 03 / 1 week ago

In March 2025, I audited a Manchester retailer that had just replatformed from Magento 2 to Shopify. Six weeks after launch, organic traffic sat 61% below its pre-migration baseline. The cause was painfully simple. The development agency had mapped redirects for the top 500 pages and let the other 14,000 product and category URLs die as 404s. Recovery took four months and cost roughly GBP 40,000 in lost revenue, by the client's own accounting.

Here is what stung the most. Every one of those losses was preventable with a spreadsheet and two days of unglamorous work.

Redirects are the least fashionable part of technical SEO. Nobody presents a redirect map at a conference. Yet in fifteen years of doing this work, I have watched more traffic get destroyed by careless migrations than by any single Google update. This guide is the playbook I wish that agency had followed.

By the end, you will know exactly when to use a 301, 302, 307, or 308. You will know when a canonical tag beats a redirect, how to find and flatten redirect chains, and how to run an HTTPS move, a domain change, or a full replatforming project without watching rankings evaporate. I will share the exact checklist I run on client migrations, with honest time estimates, the failure points that appear on almost every project, and the tools that actually earn their price. I will also defend three positions that still start arguments in SEO circles. A 302 does not leak PageRank. Redirecting dead pages to your homepage is worse than serving a 404. And you should almost never remove migration redirects, even after Google's one-year minimum has passed.

What Is the Real Difference Between a 301 and a 302 Redirect?

A 301 redirect tells browsers and search engines that a page has moved permanently. A 302 says the move is temporary. Google treats a 301 as a strong signal to make the new URL canonical and show it in results. With a 302, Google keeps the old URL indexed and expects the original to return. Both pass full link equity, so the real difference is canonicalization, not lost value.

Think of it this way. A 301 is a change-of-address card filed with the post office. A 302 is a note on your door saying you are on holiday. Both get the visitor to the right place today. Only one tells the system to update its records.

Use a 301 when content has genuinely moved or merged for good. Use a 302 for short-lived situations. A seasonal sale page that redirects to a holding page in January. A product temporarily out of stock. Geo-based routing during a phased rollout. Google's redirects documentation is explicit about this split. Permanent redirects (301 and 308) signal that the target should become canonical. Temporary ones (302, 303, 307) do not.

One practical wrinkle from experience. If you leave a 302 in place for months, Google usually starts treating it as permanent anyway. I have seen 302s canonicalize the target after eight to twelve weeks. So the choice matters most in the first weeks after a change. Pick the code that matches your actual intent, and your index state will follow faster.

Do 302 Redirects Pass PageRank, or Is That an SEO Myth?

All 30x redirects pass PageRank. Google's Gary Illyes confirmed in 2016 that no 30x redirect dilutes PageRank anymore, and John Mueller later explained that redirects simply help Google pick a canonical URL where all signals concentrate. The old advice that a 302 leaks equity is a myth in 2026. The real risk with a wrong redirect type is canonical confusion, not lost link value.

This myth refuses to die because it used to be partly true. Around 2010, redirects did carry a small PageRank cost, similar to a link. Google removed that penalty years ago, and Search Engine Land documented the official confirmation when Illyes announced it.

So why do I still see agencies bill clients for "302 to 301 equity recovery" projects? Habit, mostly. And sometimes revenue.

Here is my contrarian take. Chasing individual 302s on a healthy site is usually a waste of an audit day. Wrong status codes matter in exactly two situations. First, during a migration, where a fleet of 302s can delay canonicalization by weeks. Second, when a 302 keeps a dead URL indexed and it cannibalizes the page you actually want ranking. Outside those cases, spend the time on your internal linking strategy instead. Links you control move rankings far more than redirect-code housekeeping.

When Should You Use a 307 or 308 Redirect Instead?

Use 308 when you need a permanent redirect that preserves the HTTP method, and 307 for the temporary equivalent. Google treats a 308 like a 301 and a 307 like a 302 for indexing. The method-preserving distinction only matters when POST requests are in play, such as forms and APIs. For everyday page moves, a 301 remains the boring, correct default.

The technical difference is narrow but real. Older clients sometimes convert a POST request into a GET when they follow a 301 or 302. A 307 and 308 forbid that conversion. If a user submits a checkout form and your redirect flips it to GET, the order data vanishes. That is why payment flows and API endpoints favor 307 and 308.

You will also meet 307 in a place you never configured. When a site uses HSTS, browsers answer http requests with an internal 307 to the https version before any request leaves the machine. If you see 307s in browser dev tools but not in your server config, that is HSTS doing its job, not a bug.

My honest advice for 2026. Standardize on 301 for permanent moves unless your platform emits 308 by default, which some modern frameworks and CDNs do. Both work identically for SEO. What you should not do is mix codes randomly across a migration, because inconsistent signals make debugging miserable when something breaks at 2 a.m. on launch night.

Here is the full comparison, based on Google's current redirect documentation and behavior I have verified in Search Console on live projects.

Method	Type	Google's indexing treatment	Preserves POST	Best use case
301	Permanent, server-side	Strong signal that the target is canonical	No guarantee	Permanent page moves and migrations
302	Temporary, server-side	Old URL stays canonical, at least initially	No guarantee	Short-term moves, A/B routing, stock-outs
307	Temporary, server-side	Treated like a 302	Yes	Temporary moves involving forms or APIs, HSTS
308	Permanent, server-side	Treated like a 301	Yes	Permanent moves where request method matters
Instant meta refresh	Client-side	Interpreted as a permanent redirect	Not applicable	Last resort when server config is locked
Delayed meta refresh	Client-side	Interpreted as a temporary redirect	Not applicable	Countdown or interstitial pages, rarely ideal
rel=canonical	Hint, not a redirect	Suggestion Google can override	Not applicable	Duplicates that must stay accessible to users

Should You Use a Redirect or a Canonical Tag?

Use a redirect when the old URL should stop existing for users. Use rel=canonical when both URLs must stay accessible but only one should rank. A redirect is a directive that Google almost always obeys. A canonical is a hint that Google can, and regularly does, ignore. If you never need visitors on the duplicate URL again, redirect it.

The decision table I use with clients is short.

Moved, merged, or deleted content: redirect. The old page has no job left.
URL parameters, session IDs, tracking variants: canonical. Users still need those URLs to function.
Printer-friendly pages, near-duplicate product variants: canonical.
Syndicated content on partner sites: canonical pointing home, since you cannot redirect a domain you do not own.
HTTP to HTTPS, www to non-www: redirect, always. These are duplicates with zero user value.

The most common mistake I audit is using canonicals as soft redirects because nobody could get server access. Google frequently overrides canonicals when page content differs, and then you have two indexed URLs splitting clicks. The second most common mistake is canonicalizing every paginated page to page one, which quietly hides deep products from crawling. If your on-page hygiene is shaky in general, run through a full on-page SEO checklist before deciding this page by page.

How Do Redirect Chains and Loops Quietly Kill Your Rankings?

A redirect chain forces users and crawlers through multiple hops before reaching content. Googlebot follows up to 10 hops, then Search Console reports a redirect error and the page drops out of indexing. Google recommends keeping chains to three hops or fewer. A loop, where URLs redirect to each other, blocks access entirely. Both waste crawl resources and add latency for every visitor.

Chains rarely come from one bad decision. They accumulate like sediment. A site goes HTTPS in 2019, adds a trailing-slash rule in 2021, migrates domains in 2023, and restructures URLs in 2025. Each project redirects to the URLs of its era. Stack them and you get http://example.com/page redirecting to https, then to the new domain, then to the new path. Four hops for one page.

The worst chain I ever found had seven hops, built across three successive agency handovers. Time to first byte for those URLs was over 2.8 seconds before any HTML arrived. That latency shows up directly in your Core Web Vitals numbers, because every hop is a full network round trip.

The fix is simple and tedious. Point every redirect at the final destination in one hop. Crawl your redirect file, not just your site, and update old rules rather than adding new layers. To see which stale URLs Googlebot still requests daily, and therefore which chains actually burn crawl resources, log file analysis is the only honest source of truth.

How Long Should You Keep 301 Redirects in Place?

Google's official guidance says to keep migration redirects for at least one year, because that is roughly how long it takes to transfer all signals to the new URLs. My advice goes further. Keep them forever unless there is a real technical cost. Backlinks, bookmarks, printed materials, and old emails point at legacy URLs for a decade or more.

The one-year figure comes straight from Google's site move documentation, which also notes that keeping redirects indefinitely is better for users. I treat one year as the floor, not the target.

Here is the math that convinces clients. On a 2024 domain consolidation I worked on, the old domain still received about 3,100 visits per month from legacy backlinks eighteen months after the move. Dropping those redirects would have converted every one of those visits into a 404. The hosting cost of keeping them was under EUR 5 a month as edge rules on Cloudflare.

Redirects at the CDN or server level cost almost nothing to maintain. What does cost something is losing referenced equity. Before you ever consider retiring redirect rules, audit which external links still point at old URLs. The best link building tools all include a backlink export that makes this a twenty-minute job. Any old URL with live links from real sites keeps its redirect. Permanently.

How Do You Plan a Site Migration Without Losing Traffic?

Every migration that keeps its traffic follows the same pattern. Benchmark everything first, map every URL to exactly one destination, build and test redirects on staging, launch with same-day verification, then monitor aggressively for 90 days. Traffic loss almost always traces back to a skipped step in that sequence, not to some mysterious Google penalty.

Here is the checklist I run, with realistic time estimates for a site of 5,000 to 50,000 URLs. Small sites compress this. Enterprise sites multiply it.

Benchmark (week -6, 1 to 2 days). Export 16 months of Search Console queries and pages. Pull GA4 landing-page data. Run a full crawl with Screaming Frog SEO Spider and archive it. Record rankings for your top 200 keywords. You cannot prove recovery without a baseline.
URL inventory and mapping (weeks -5 to -3, 3 to 10 days). Combine crawl data, Search Console, analytics, backlink exports, and server logs into one master URL list. Map each URL to one new destination. This is the step the Manchester retailer skipped.
Build redirect rules (week -2, 2 to 4 days). Prefer pattern-based rules (regex) over 40,000 one-off lines where the URL structure allows it. Implement server-side 301s in Nginx, Apache, or your CDN.
Staging validation (week -1, 1 to 2 days). Crawl the staging site. Verify canonicals, hreflang, and structured data survived. Confirm robots.txt on the new environment does not block crawlers, including the AI crawlers you have made deliberate decisions about in your robots.txt policy for AI crawlers. Prepare the new sitemap. A clean file from an XML sitemap generator works fine for smaller sites, while large sites should generate from the database.
Launch day (1 day). Deploy redirects at the same moment as the new site. Verify the top 100 URLs return a single-hop 301. Submit new sitemaps in Search Console and use the Change of Address tool for domain moves. Our full guide to XML sitemaps and the Indexing API covers how to accelerate discovery here.
Stabilization (days 1 to 14, 30 to 60 minutes daily). Watch Search Console indexing reports and server logs daily. Fix 404s and chains the day they appear.
Audit (days 15 to 90, weekly). Compare traffic and rankings to your baseline, section by section. Reclaim high-value backlinks pointing at old URLs.

Total planning-to-stability effort for a mid-size site is roughly 12 to 20 working days spread over three months. Teams that budget three days total are the ones who call me in month two.

What Does a Bulletproof URL Mapping Process Look Like?

A complete URL map lists every URL that exists, ranks, earns links, or receives traffic, then assigns each one a single new destination. Redirect each old page to its closest equivalent, never in bulk to the homepage. Google treats mass homepage redirects as soft 404s, which means they pass nothing at all.

Most failed migrations fail here, so let me be specific about sources. Your crawl only finds what is linked today. Search Console finds what Google knows. Analytics finds what humans visit. Backlink tools find what other sites reference. Server logs find what anything requests, including ancient URLs from 2015. Union all five. On a recent 30,000-URL project, logs surfaced 4,200 URLs that appeared in no crawl and still received bot and referral hits.

Then triage into three tiers.

Tier 1, must map by hand: pages with rankings, revenue, or external links. Usually 5 to 15% of URLs.
Tier 2, map by pattern: structured sections where regex handles the whole directory.
Tier 3, let die deliberately: expired junk, spam parameters, dead campaigns. Serve 410 so Google drops them fast, instead of redirecting garbage onto your new domain.

That third tier is my most contested opinion. Redirecting everything feels safe but it is not. Dragging thousands of worthless URLs onto a fresh site imports crawl waste on day one. A confident 410 is a feature, not a failure.

What Should You Do on Launch Day and the Week After?

Verify within the first hour that redirects return single-hop 301s, DNS resolves to the new infrastructure, and the new site is crawlable. Then submit sitemaps, confirm Search Console access for old and new properties, and start daily monitoring. The first 72 hours determine whether Google's recrawl goes smoothly or starts with a pile of errors.

My launch-hour routine, in order. First, confirm DNS. For a domain or host change, check that records have propagated with a DNS record lookup and confirm the domain resolves to the right server with a domain-to-IP check. DNS caching means some users hit the old server for hours, so lower your TTL to 300 seconds a week before launch.

Second, curl or crawl the top 100 URLs from your benchmark list. Each should answer with exactly one 301 to a 200. Not a 302. Not two hops.

Third, load robots.txt and the homepage source in a browser. Check for a leftover staging noindex. Yes, this sounds insultingly basic. It is also the single most common launch-day disaster I see, and I have caused it myself once, in 2019. We caught it after 36 hours because Search Console coverage numbers started sliding. The habit of checking daily saved that project.

Fourth, sweep your own templates. Internal links, canonicals, and hreflang should reference new URLs directly rather than bouncing through redirects. Every internal link that hits a redirect wastes a hop you control.

How Do HTTPS Moves, Domain Changes, and Replatforming Differ?

An HTTPS move is the gentlest migration because URLs barely change and no Change of Address is needed. A domain change keeps paths but transfers all trust signals to a new host name, so history checks matter. Replatforming is the hardest, because URL patterns, templates, rendering, and structured data can all change simultaneously. Risk scales with how much changes at once.

HTTPS and protocol moves

Redirect every http URL to its https twin with a single 301, update canonicals and internal links to https, fix mixed content, and consider HSTS once stable. Google explicitly does not require the Change of Address tool for protocol moves. Most sites finished this years ago, but I still find http-canonical stragglers on legacy sections monthly.

Domain changes and consolidations

Before buying or switching to any domain, investigate its past life. Run it through a domain blacklist check and read our guide on checking whether a site is blacklisted, because inherited spam history is brutal to litigate after launch. European teams consolidating ccTLDs, say a .de, .fr, and .co.uk into one .com with hreflang, should benchmark each property separately first. Third-party authority scores will wobble after any move. Measure yours before and after with a domain authority checker, and read up on what domain authority actually measures so nobody panics over a metric Google does not use.

Replatforming and URL restructures

New CMS, new URL logic, new templates. Diff old and new page content, not just status codes, because a 301 to a thinner page still loses rankings. Rebuild your JSON-LD structured data on the new templates, since schema rarely survives a platform swap untouched. And if the new stack renders client-side, test how bots see it. Our guide to JavaScript rendering and indexing covers why a framework migration is really two migrations in one.

Which Tools Actually Help With Redirect and Migration Audits?

Screaming Frog SEO Spider is the workhorse for redirect mapping and chain detection. Sitebulb explains problems better for mixed-skill teams. Ahrefs and Semrush cover the backlink and ranking side of a migration. Google Search Console is the free ground truth for how Google itself experiences your move. No single tool covers everything, so pick one from each category.

Screaming Frog SEO Spider. List mode plus the "always follow redirects" setting audits an entire old-URL list in minutes and exports full chains. About GBP 199 a year, with a free tier up to 500 URLs. Cons: a desktop app that eats RAM on six-figure crawls, and the UI assumes you know what you are doing.
Sitebulb. Similar crawling with far friendlier explanations and prioritized hints. My pick when a client team will read the report themselves. Cons: slower on very large sites and less flexible for scripted, repeated audits.
Ahrefs and Semrush. Not redirect tools, but essential for the mapping inputs, which old URLs hold backlinks and rankings worth protecting. Entry plans run roughly USD 129 and USD 140 per month. Cons: real money, and their crawlers see less of your site than a direct crawl does.
Google Search Console. Free, authoritative, and the only place to run Change of Address. Cons: sampled data, delays of a few days, and a 1,000-row export ceiling unless you use the API.

For the wider stack beyond migrations, our roundup of the 30 best SEO tools covers what earns a subscription and what does not.

What Are the Most Common Migration Failure Points?

The same six mistakes cause most migration losses. A staging noindex shipped to production, a robots.txt blocking the new site, blanket homepage redirects, redirect chains stacked from past projects, lost hreflang or canonicals, and changing platform, design, and URL structure in a single release. All six are cheap to prevent and expensive to discover in week four.

Prevention, point by point.

Staging noindex in production. Add a launch-day check to the deployment checklist itself, not the SEO doc nobody opens.
Robots.txt blocking crawlers. Diff old and new robots.txt files before deploy. One inherited Disallow line can hide a whole directory.
Homepage blanket redirects. Google flags these as soft 404s. Map to equivalents or serve honest 404 or 410 responses.
Stacked chains. Rewrite historical redirect rules to the final URLs instead of appending a new layer.
Lost hreflang and canonicals. Crawl staging with these extractions enabled. Multilingual EU sites suffer here most, because hreflang errors fail silently while rankings drift for weeks.
Everything at once. Separate the platform move from the URL restructure by a few months where the business allows it. Two medium risks beat one enormous one, and when traffic moves you actually know which change caused it.

A confession that belongs here. Early in my career I combined a redesign, a URL restructure, and a hosting change in one weekend because the client wanted a single downtime window. Traffic fell 34% and it took us three weeks just to isolate which change was responsible. Never again.

How Long Does Google Take to Process a Site Move in 2026?

Google says a small or medium site takes several weeks for most pages to be recrawled and reindexed, and larger sites take longer. Ranking fluctuations during that window are documented as normal. In my projects, a clean migration dips 5 to 15% for two to six weeks, then recovers. Deeper or longer dips usually mean a mapping or crawlability defect, not patience required.

Set stakeholder expectations before launch, in writing. The week-two panic meeting goes very differently when you predicted the dip in the kickoff deck.

Timing matters more than most teams admit. Do not launch a migration during your peak revenue season, and avoid launching into the middle of a confirmed algorithm rollout, because you will not be able to tell the migration dip from the update, as plenty of teams learned during the May 2026 core update. My preferred window is the quietest fortnight in the business calendar with no Google rollout announced.

Speed levers that genuinely help: submit both old and new sitemaps so Google recrawls old URLs and discovers new ones, keep server capacity generous because crawl demand spikes after a move, and fix errors within a day rather than batching them for Friday. What does not help is resubmitting the same URLs hourly or panic-editing titles in week one. Recrawl speed is mostly Google's schedule plus your server's ability to keep up.

Where Should You Start Today?

Back to that Manchester retailer. The recovery plan was not clever. We rebuilt the URL map from an archived crawl and eighteen months of logs, shipped 13,400 missing 301s in one release, and reclaimed the top 60 backlinks by hand. Traffic returned to 92% of baseline within eleven weeks. The lesson was never about tactics. It was that redirects deserve project status, not a ticket at the end of a sprint.

Your priority order. First, crawl your current site and flatten every chain past one hop, this week. Second, if a migration is anywhere on your roadmap, start the benchmark exports now, because you cannot capture the past retroactively. Third, write the URL map before anyone writes launch-day code.

One prediction for the next two years. Clean redirects will matter more, not less, because AI search crawlers are worse at chains and JavaScript hops than Googlebot ever was. The sites that treat redirects as infrastructure will quietly inherit the citations and traffic that sloppier competitors drop.

What is the worst redirect chain you have found in the wild? I would genuinely like to know if anyone beats seven hops.

Frequently Asked Questions

Do 301 redirects hurt SEO?

No. A properly implemented 301 redirect passes full PageRank and helps Google transfer signals to the new URL. Google confirmed in 2016 that 30x redirects no longer dilute link equity. What hurts SEO is redirect misuse: chains with many hops, redirecting pages to irrelevant destinations, or mass redirects to the homepage, which Google treats as soft 404s. A single-hop 301 from an old page to its true equivalent is one of the safest actions in technical SEO.

How many redirects in a chain are too many?

Googlebot follows up to 10 redirect hops before giving up and reporting a redirect error in Search Console. Google's own site move guidance recommends staying at three hops or fewer, and ideally redirecting straight to the final destination in one hop. Every extra hop adds a full network round trip for real users too, which slows page loads. Treat anything beyond two hops as technical debt worth fixing, even though indexing technically survives more.

Can I use a 302 redirect permanently?

You can, but you should not. A long-lived 302 sends Google a mixed signal, saying the move is temporary while behaving permanently. In practice Google usually reclassifies persistent 302s as permanent after weeks or months, so the equity eventually consolidates anyway. The cost is delay and unpredictability during the window when Google still expects the old URL to return. If a move is permanent, use a 301 or 308 from day one and remove the ambiguity.

Do I need redirects if I change domains but keep the same URL paths?

Yes, absolutely. A domain change is still a migration even when every path stays identical. You need a one-hop 301 from every old-domain URL to its twin on the new domain, verification of both properties in Search Console, and a Change of Address submission. Keeping paths identical makes the redirect rules trivial, usually one wildcard rule, but skipping them means every backlink, bookmark, and indexed result points at a dead host.

How long does it take to recover traffic after a site migration?

Google states that small and medium sites take several weeks for most pages to be recrawled and reindexed, with larger sites taking longer, and that ranking fluctuations during this period are normal. In real projects, a well-executed migration typically dips 5 to 15% for two to six weeks before recovering. If traffic is still down 30% or more after six weeks, stop waiting and audit. That pattern almost always indicates missing redirects, blocked crawling, or thinner replacement content.

Should I redirect old pages to my homepage?

No. Google treats bulk redirects to the homepage as soft 404s, which means they pass little or no signal and the old URLs simply fall out of the index. Redirect each old page to its closest relevant equivalent: the same article, the replacement product, or at worst the matching category. If no relevant target exists, serve an honest 404 or 410 instead. A clean 410 is better for your site than a misleading homepage redirect.

What happens if I remove 301 redirects after one year?

Google recommends keeping redirects for at least one year because that is roughly how long signal transfer takes. After that, Google has usually consolidated everything onto the new URLs. But removal still has a cost. Every external backlink, bookmark, and printed link pointing at old URLs starts hitting 404s, and users bounce. Since server-side or CDN redirects cost almost nothing to maintain, the practical answer is to keep them indefinitely and only retire rules with zero remaining traffic and zero live backlinks.

Is a canonical tag as strong as a 301 redirect?

No. A 301 redirect is a directive that Google follows almost without exception. A rel=canonical is a hint that Google weighs against other signals like internal links, sitemaps, and content similarity, and it regularly overrides canonicals it disagrees with. Use canonicals only when both URLs must remain accessible to users, such as parameter variants or print versions. When the duplicate URL has no reason to exist for visitors, a redirect is the stronger and more predictable tool.

Do redirect chains affect Core Web Vitals and page speed?

Yes, directly. Each redirect hop is a complete network round trip that delays the first byte of HTML, which pushes back every downstream metric including Largest Contentful Paint. On slow mobile connections, a three-hop chain can add well over a second before the page even begins loading. Users following old links, ads, or emails through chained redirects get your slowest experience. Flattening chains to one hop is one of the cheapest real-world speed wins available.

How do I set up redirects without server access, for example on hosted platforms?

Most hosted platforms provide a native redirect layer. Shopify has URL redirects under navigation settings, Wix and Squarespace include redirect managers, and WordPress users can use the free Redirection plugin or the redirect manager in Yoast SEO Premium. If the platform sits behind Cloudflare or a similar CDN, edge redirect rules work regardless of server access and execute faster than origin redirects. Avoid JavaScript-based redirects, since Google treats them as a last resort and other crawlers often miss them entirely.