Should you really redirect ALL URLs during a site migration?

Why does Google emphasize the completeness of redirects so much?

When a site changes its domain name, protocol (HTTP to HTTPS), or URL structure, Google does not guess where your pages have gone. Each indexed URL represents an accumulated trust signal: backlinks, click history, internal PageRank.

If you leave orphaned URLs returning 404 errors, you waste that capital. Google then considers that part of your site has disappeared and redistributes rankings to other sites. A poorly executed migration can lead to a loss of organic traffic of 30 to 60% within a few weeks.

Are images really as critical as pages?

Yes, and this is often the overlooked point. Google Images accounts for a significant share of organic traffic for many sites, particularly in e-commerce and media. If your images are no longer accessible or do not redirect, you lose that channel.

Specifically, each indexed image has its own PageRank and ranking history. A well-placed image can generate hundreds of clicks per month. Without a 301 redirect, you start from scratch on Google Images, just as if you were launching a new site.

What’s the difference between a partial migration and a full migration?

A partial migration (changing URL structure without changing the domain) follows the same rules as a full migration. The nature of the change does not matter: what counts is that Google can follow the trail.

Many practitioners think that an internal technical overhaul allows for shortcuts. Mistake. If you change from /category/product to /products/category, each old URL must individually redirect to the new one. Generic wildcard redirects rarely work well and create semantic inconsistencies that Google penalizes.

• Every indexed URL must have a 301 redirect to its exact equivalent or the semantically closest resource.
• Images are full URLs: they must redirect exactly like HTML pages.
• A migration without a comprehensive redirect plan is akin to launching a new site while losing the old one.
• Temporary 302 redirects do not transfer link equity: only permanent 301 redirects do.
• Google does not automatically consolidate: if you forget an entire category, it disappears from the SERPs.

Does this statement truly reflect observed field practice?

Yes, largely. The failed migrations I've audited all show the same pattern: partial or rushed redirects. The client redirects 70% of URLs, thinks that’s enough, and loses 40% of traffic in two months.

But let's be honest: Google does not say how long it takes for redirects to be fully accounted for. On large sites (100,000+ pages), I observe consolidation delays of 3 to 6 months. Mueller's statement omits this critical point. [To be verified] for each context: site size, crawl frequency, quality of backlinks.

What are the most common field mistakes despite this guideline?

The first classic mistake: redirecting all outdated product pages to the homepage. Google hates that. You lose semantic relevance, and link equity dilutes unnecessarily.

The second trap: forgetting URL parameters. An e-commerce site with ?utm_source or ?color=red generates thousands of indexed URLs. If your redirects do not handle these variants, you leak juice. A third often overlooked point: old pagination pages. A category with 20 indexed pages must redirect each /page/2, /page/3 to its exact equivalent, not to /page/1 of the new structure.

In what cases can exceptions be allowed?

On dead or completely obsolete content without backlinks or traffic: a 404 or 410 is sometimes cleaner than a forced redirect. If a page hasn’t been crawled for 3 years and appears nowhere in your logs, letting it die doesn’t change anything.

But beware: this logic applies only to a minority of pages. The temptation to consider 30% of the site as “unnecessary” leads directly to disaster. I’ve seen clients justify the absence of redirects on thousands of pages by claiming they “didn't matter,” only to discover they generated 15% of the traffic through long tail.

How can you plan a migration without losing rankings?

First and foremost, conduct a complete crawl of the existing site: Screaming Frog, Oncrawl, Botify, whichever tool you prefer. Retrieve every indexed URL from Search Console and cross-reference with your server logs. You need to know EXACTLY how many URLs Google is aware of.

Next, build a 1:1 mapping table between old and new URLs. Each row = a 301 redirect to implement on the server side. If a page disappears without an exact equivalent, redirect to the parent category or the semantically closest resource. Never redirect more than 10% of your URLs to the homepage: Google sees that as a manipulation signal.

What technical mistakes should absolutely be avoided during implementation?

The first recurring folly: redirect chains. Old URL → temporary new URL → final new URL. Google loses PageRank with each jump, and consolidation becomes random. Your redirects must point directly to the final destination.

The second technical trap: implementing redirects in JavaScript or via meta refresh. Only server-side 301 redirects (Apache, Nginx, IIS) correctly transfer link equity. A JavaScript redirect may work for the user, but Google does not treat it the same way. A third mistake: not testing at scale. On 50,000 redirects, statistically 2 to 5% will fail (typos, mapping errors, regex conflicts). Test on a representative sample BEFORE going live.

How can you validate that the migration was successful afterwards?

Monitor four key indicators in the 90 days post-migration: Google crawl rate (Search Console, crawling statistics), number of 404 errors (should remain marginal), changes in organic traffic by segment (branded vs non-branded), average rankings on your top keywords.

If you see a drop in crawl or a spike in 404 errors, it means your redirects do not cover the entire spectrum. Analyze the 404 errors in Search Console to identify orphaned URLs and continuously add missing redirects during the first 3 months. A migration is never perfect on the first try: the key is to correct promptly.

• Crawl the entire site before migration and export all indexed URLs (Search Console + server logs).
• Create a 1:1 mapping file between old and new URLs, manually validated on a sample.
• Implement server-side 301 redirects, never in JavaScript or meta refresh.
• Test redirects in a staging environment with a bulk URL checker tool before production.
• Monitor Search Console daily for the first 30 days to detect emerging 404 errors.
• Keep redirects active for at least 12 months, ideally indefinitely if external backlinks persist.