Is it really necessary to redirect everything during a website migration?

Why does Google recommend redirecting everything without exception?

The logic is simple: Google needs to understand that the old domain is dead and that the new one fully replaces it. If some pages remain active on the old site, crawlers will continue to index them and distribute PageRank between two domains.

What’s the result? A dilution of the signal. Instead of properly transferring the accumulated authority, you're splitting your SEO capital. Google doesn't know if the old domain is still active or if it should switch to the new one. This ambiguity slows down — or even blocks — migration in Search Console.

What happens if we leave a few orphan pages lingering around?

Forgotten pages on the old domain will continue to be crawled. Google will waste time and crawl budget visiting URLs that no longer need to exist. Meanwhile, the new site receives less attention, and the indexing of new pages is delayed.

Worse still: if these orphan pages still generate traffic or backlinks, you're creating internal competition. Users land on the old domain, bounce back, and Google interprets this as a negative signal for the new site. An absurd but common situation.

How can we avoid oversights in a complex migration?

The answer is summed up in one word: comprehensive mapping. Before making any changes, extract the complete list of indexed URLs via Search Console, your XML sitemap, and a full crawl with Screaming Frog or Botify. Cross-reference these sources to identify gaps.

Then, establish a 1:1 redirection matrix between the old and new domain. Each source URL must point to a relevant destination — not just the homepage for convenience. If an old page has no direct equivalent, redirect to the parent category or the semantically closest page.

• Audit all indexed URLs before migrating — not just those from the sitemap
• Create a correspondence table between the old and new domain, validated manually
• Test the redirects in staging before switching to production
• Monitor 404 errors and redirect chains post-migration via Search Console
• Maintain the redirects for at least 12 months to give Google time to transfer everything

Is this instruction as absolute as it seems?

On paper, yes. In reality, the complexity of real sites sometimes requires compromises. A site with several hundred thousand pages containing obsolete sections or massive duplicates may not merit redirecting every orphan URL.

Let’s be honest: not all pages hold the same SEO value. A page without backlinks, traffic, or indexing for years doesn’t contribute anything to the transfer of PageRank. Redirecting it to a new URL could even dilute thematic relevance if the match is forced. In this case, a 410 Gone or a 404 might be cleaner than an artificial redirect.

What are the risks of an overly rigid approach?

The first pitfall: unnecessary redirects inflate server load and slow down the site. An .htaccess file with 50,000 redirect rules can become a maintenance nightmare and impact performance.

The second pitfall: massively redirecting to irrelevant pages sends confusing signals to Google. If you redirect 500 old discontinued product pages to a single generic category, you create a disguised soft 404. Google eventually ignores these redirects and treats them as errors. [To be verified]: Google has never published a specific threshold beyond which a mass of redirects becomes suspicious, but field observations show that a ratio greater than 20:1 (20 old URLs to 1 new) often triggers devaluation.

In what cases can we deviate from the all-redirect rule?

Case number one: zombie pages. Technical pages without content, URLs automatically generated by a poorly configured CMS, session or tracking parameters — all indexed URLs by mistake. Redirecting them makes no sense. It’s better to block them in robots.txt or return a 410.

Case number two: obsolete or non-compliant content. A blog section dating from 2008 with outdated SEO advice, expired event pages, or discontinued products. If the new site no longer covers these topics, forcing a redirect creates inconsistency. A clean 404 with a well-designed error page is sometimes more honest.

What should be done concretely before the switch?

First step: crawl the old domain thoroughly. Not just the XML sitemap — it only reflects what the CMS is willing to display. Use Screaming Frog, Botify, or Oncrawl to extract all discovered URLs, including those without internal links.

Second step: cross-reference this crawl with Search Console data. Export the list of indexed pages and the list of pages receiving traffic over the last 12 months. You will discover discrepancies — indexed pages but not crawled, or vice versa. These anomalies need to be resolved before migration.

How to structure the redirection plan without getting lost?

The method that works: an Excel or Google Sheets table with at least three columns: Source URL, Destination URL, HTTP code (301 or 410). Add columns for organic traffic, the number of backlinks, and validation status.

Then, segment by content type: blog articles, product sheets, category pages, institutional pages. Each segment follows a different redirection logic. Product sheets should point to their new versions; blog articles can be grouped by theme if the structure has changed.

What mistakes should absolutely be avoided post-migration?

Classic mistake: redirect chains. You redirect A to B, then B to C. Google follows the chains, but this dilutes PageRank with each hop and slows down crawls. Ensure that each old URL points directly to its final destination.

Second mistake: not monitoring 404 errors in Search Console. After migration, check the coverage report weekly. Each reported 404 is a missed redirect. Correct them as they arise — do not let hundreds of errors accumulate.

• Crawl the old domain entirely and extract all indexed URLs
• Create a redirection matrix with Source URL, Destination URL, and manual validation
• Test redirects in a staging environment before going live
• Activate domain redirection in Search Console as soon as it goes live
• Monitor 404 errors and redirect chains for at least 3 months
• Keep redirects active for 12 to 18 months to give Google time to transfer everything