How to Fix Every Site Migration Audit Finding
A site migration is any change big enough to alter how search engines see your site: a new domain, a new platform, a new URL structure, a redesign or a move from HTTP to HTTPS. The Site Migration Audit compares crawl data from before the move with the live site afterwards.
It finds lost URLs, checks redirect coverage, tracks ranking shifts, checks indexing, verifies that structured data survived and audits internal links. This page explains what each finding means, which guide fixes it, and the order that gives rankings the best chance of recovering.
Why migrations lose traffic
Search engines have spent months or years learning your old URLs: which pages exist, what they are about, which other sites link to them and how useful they are. A migration asks them to transfer all of that to a new set of addresses. When the handover is clean, most of that history carries across. When it is not, the signals are lost or diluted and rankings fall.
The common causes are rarely dramatic. They are small gaps that add up across hundreds or thousands of pages:
- Old URLs that return a 404 instead of redirecting, so their links and history go nowhere.
- Redirects that pass through several steps, or point everything to the home page instead of the matching page.
- Canonical tags still pointing at the old domain or at staging URLs.
- A robots.txt file or noindex tag copied from the staging site that blocks crawling or indexing.
- Structured data, titles or body text dropped by a new template.
- Internal links still pointing at old addresses, so every click and crawl goes through a redirect.
Google's own documentation says ranking fluctuations are normal while a site move is processed, and that bigger sites take longer. The difference between a temporary dip and a lasting loss is usually whether problems like these are found and fixed quickly. The audit exists to find them while the fix is still simple.
The fix guides
Each guide matches one type of finding, with a platform section at the end for the three most common migration routes.
URLs and redirects
Fixing lost URLs helps you decide for each missing page whether to restore it, redirect it to the closest equivalent or let it go, and includes a redirect map template for bulk work. Fixing broken redirect chains shows how to collapse multi-step chains into a single permanent redirect and where to check them at both the CDN and the server.
Rankings and indexing
Fixing post-migration ranking drops gives a diagnostic checklist for when a dip does not recover. Fixing indexation gaps explains how to use the Page indexing report to find pages that dropped out of the index and what to do for each status.
Signals that should have carried over
Fixing canonicals after a migration covers missing or wrong canonical tags on the new URLs. Fixing sitemap and robots.txt drift deals with sitemaps listing dead URLs and robots rules copied from the wrong environment. Fixing schema lost in a migration compares structured data before and after and shows how to restore it in bulk. Fixing internal links after a migration covers updating links that still point at old addresses.
By platform
WordPress migrations cover
theme changes, permalink and category structure shifts, and moving SEO plugin settings. Shopify
migrations cover Shopify's fixed URL patterns such as /products/ and /collections/
and importing redirects in bulk. Headless
migrations cover moving from a traditional CMS to a separate front end, including how each route
is rendered.
Which findings to fix first
After a migration, the order matters more than usual, because some problems stop search engines from seeing any of your other fixes.
- Anything blocking crawling or indexing. A site-wide
Disallow: /in robots.txt or a leftover noindex tag must be removed immediately, as nothing else helps until it is. - Lost URLs with traffic or links. Redirect your most visited and most linked old pages to their true equivalents first. These carry most of the value.
- Redirect chains and loops. Collapse them so every old URL reaches its new home in one step.
- Canonical tags. Make sure new pages point to themselves, not to the old domain, staging or another page.
- Sitemaps. Submit a sitemap of the new URLs so crawlers find them quickly.
- Internal links, structured data and content parity. Important for full recovery, but they matter less if the steps above are broken.
The before-and-after evidence you need
Every finding in a migration audit is a comparison, so the quality of your fixes depends on the quality of your record of the old site. Gather as much of the following as you can. If the migration has already happened, some of it can still be recovered.
| Evidence | Where to get it | What it helps you fix |
|---|---|---|
| Full list of old URLs | A crawl of the old site, old sitemaps, server logs or analytics landing-page reports | Lost URLs and the redirect map |
| Top pages by clicks | Search Console performance report for the old property | Which redirects to check first |
| Pages with external links | Search Console links report or a backlink tool | Which lost URLs carry the most value |
| Titles, descriptions and headings | An old crawl export | Content and metadata dropped by new templates |
| Structured data per template | An old crawl or saved page source | Schema lost in the move |
| Indexed page counts | Search Console Page indexing report | Indexation gaps |
If you did not crawl the old site before launch, the Internet Archive's Wayback Machine, old XML sitemaps still cached on a CDN, and server access logs are useful places to rebuild the list of URLs that existed.
For domain changes, remember to verify the new domain in Search Console and use the Change of Address tool once redirects are in place. Tracking the audit score over time with the Score History Guide helps you show whether recovery is on course.
What a normal recovery looks like
Owners often panic in the first week, and sometimes relax too early. A realistic picture helps you judge when to act.
Expected, and usually temporary
- Fluctuating rankings and traffic while search engines recrawl and process redirects.
- Old URLs still appearing in results for a while, then being replaced by the new ones.
- Both old and new URLs showing in Search Console reports at the same time.
Warning signs that need investigating
- Important pages missing from the index weeks after launch.
- A steady fall rather than a dip followed by recovery.
- Losses concentrated in one section or template, which usually points to a specific technical cause.
- A sharp rise in 404 errors or in "Page with redirect" and "Excluded by noindex tag" statuses.
Timescales vary widely with site size, how much changed at once and how often the site is crawled. A like-for-like domain move with a clean redirect map is usually processed more smoothly than a move that changes domain, platform, URLs and content all at the same time. When a loss persists, work through the ranking recovery checklist systematically rather than changing several things at once.
Order of work
- Gather the old-site evidence: URL list, top pages, linked pages and a crawl export.
- Run the Site Migration Audit to compare the old data with the live site.
- Remove anything blocking crawling or indexing, then check robots.txt and meta robots on key templates.
- Fix lost URLs, starting with pages that had the most traffic and links, using single-step permanent redirects.
- Collapse redirect chains; the Redirect Checker Guide explains how to test them.
- Correct canonical tags and submit a clean sitemap of the new URLs; the Robots and Sitemap Guide covers both files.
- Restore missing structured data and content, template by template.
- Update internal links to point straight at the new URLs.
- Re-run the audit weekly until findings settle, then monthly for the rest of the first year.
For a wider health check of the new site once the migration issues are fixed, the Site Audit Guide covers the full set of on-site checks.
1. How long does it take rankings to recover after a site migration?
There is no fixed timescale. Google says site moves take time to process and that larger sites take longer, and fluctuations along the way are normal. A clean, like-for-like move often settles within weeks, while a migration that changes the domain, platform, URLs and content all at once can take considerably longer. If important pages are still missing or traffic keeps falling after several weeks, investigate the cause rather than simply waiting.
2. Should I use 301 or 302 redirects for a migration?
Use permanent redirects, which means 301 or 308, for pages that have moved for good. They tell search engines the new URL should replace the old one. Google has said it treats temporary redirects as a signal too, but a permanent redirect is the clearer instruction and is what its site move guidance recommends. Keep 302 or 307 redirects for genuinely temporary situations, such as a short maintenance page or a seasonal campaign.
3. Can I redirect all my old pages to the home page?
It is better not to. Search engines may treat a redirect to an unrelated page, such as the home page, like a missing page, so the value of the old URL is largely lost. Visitors also end up somewhere unhelpful. Redirect each old URL to the page that best matches its content. If there really is no equivalent, a clear 404 or 410 page with helpful links is usually better than a misleading redirect.
4. How long should I keep redirects after a migration?
Google recommends keeping redirects from a site move in place for at least one year, which gives it time to transfer signals and recrawl links. In practice many sites keep them permanently, because other websites, bookmarks and old emails continue to link to the old addresses for years. Redirects cost very little to maintain, so removing them rarely makes sense, and losing them can quietly undo much of the recovery.
5. What is a redirect map?
A redirect map is a spreadsheet that lists every old URL in one column and its new destination in the next. It is the single most important document in a migration, because it drives the redirect rules and lets you check coverage afterwards. Build it from a crawl of the old site plus your analytics and backlink data, match each URL to its true equivalent, and test every row once the redirects are live.
6. Why are my new pages not being indexed after the migration?
The most common causes are a robots.txt file or noindex tag carried over from the staging site, canonical tags pointing at the wrong URL, or new pages that are not linked or listed in the sitemap. Check the Page indexing report in Search Console to see the exact status for affected pages, then fix the cause for each status group. Request indexing only for a handful of the most important pages.
7. Do I need to tell Google about a domain change?
Yes, if you are moving to a new domain. Verify the new domain in Search Console, put permanent redirects in place from every old URL, then use the Change of Address tool in the old property to tell Google about the move. The tool is for domain changes, not for moves within the same domain such as a new URL structure or switching from HTTP to HTTPS, which rely on redirects alone.
The Site Migration Audit compares your pre-migration crawl with the live site, finds lost URLs, validates redirects, tracks ranking shifts, checks indexing and structured data, and audits internal links, so you can fix problems while they are still easy.
Run the Site Migration Audit →