Site Migration SEO: Redirect Mapping and Post-Launch QA
A site migration is not complete when the new website goes live. From an SEO perspective, it is complete when search engines can connect the old URLs, signals, content, and internal architecture to the new site without unnecessary ambiguity.
That is why site migration SEO is continuity work.
The central tasks are straightforward in principle: build a complete inventory, decide where valuable URLs should move, validate the redirects, test the new site before release, and monitor the migration closely after launch.
The execution is where migrations become difficult.
A useful framework is:
Inventory → Map → Validate → Launch → Verify → Stabilize
Google's current site migration guidance follows the same general sequence: prepare and test the new site, map old URLs to new ones, implement permanent redirects, submit the new sitemap, and monitor the move. Google also notes that temporary ranking fluctuations are normal while old and new URLs are recrawled and processed.
Site Migration SEO at a Glance
Migration SEO protects more than rankings.
A site move can affect:
- URL equity
- Organic landing pages
- Internal links
- Canonical signals
- Crawl paths
- Structured data
- XML sitemaps
- Search Console reporting
- Analytics and conversion tracking
- Content relevance
- International annotations
- Product feeds
- Backlinks
The practical goal is to make the new site look like the logical continuation of the old one wherever that is genuinely true.
SEO Team Toronto treats migration and replatforming SEO as a controlled rollout for this reason. Redirects matter, but redirects alone do not protect a migration if the destination pages are blocked, canonicalized incorrectly, stripped of important content, or absent from the site's new internal architecture.
Build the Source URL Inventory Before You Map Anything
A redirect map can only be as complete as the URL inventory behind it.
One of the most common mistakes is starting with a crawl export and assuming it represents the whole old site. A crawler only finds URLs it can reach through the paths available during that crawl.
Valuable URLs can sit outside those paths.
Build the inventory from multiple sources:
- Full crawl of the existing site
- Google Search Console landing pages
- Analytics landing pages
- XML sitemaps
- CMS or database exports
- Backlink tools
- Server logs where available
- Paid campaign landing pages
- Historical redirect files
- Known PDFs and downloadable assets
- Legacy subdomains
- Product or category exports
Screaming Frog's site migration workflow recommends combining crawl URLs with other sources such as analytics, Search Console, CMS data, log files, backlinks, and sitemaps for this reason.
Once the URLs are combined and deduplicated, enrich the inventory.
Useful columns include:
- Current URL
- HTTP status
- Page type/template
- Organic clicks
- Organic sessions
- Conversions or revenue
- Backlinks/referring domains
- Current canonical
- Indexability
- Target keyword/topic
- New URL
- Redirect priority
- Notes
This turns a URL list into a migration decision tool.
Mini Example: The URL Your Crawler Misses
Consider an old B2B landing page that is no longer linked from the main navigation.
A current site crawl does not find it. The migration team therefore assumes it has no importance.
Search Console and backlink data tell a different story. The page still receives non-brand impressions and has links from several industry publications.
Without a multi-source inventory, that URL could disappear at launch with no redirect simply because it was orphaned before the project began.
The crawl was correct. The inventory was incomplete.
Redirect Mapping: Match Pages by Meaning, Not Just Slug
Redirect mapping is not a find-and-replace exercise.
The old URL and the new URL do not need matching words. They need matching purpose.
Use this decision framework:
Relevance → Value → Technical Validity
First ask whether the new page is genuinely equivalent. Then consider the value being transferred. Finally confirm the destination is technically suitable.
Exact Equivalent
When an old page has a clear new counterpart, map it directly.
Examples:
/services/seo-audit
→ /services/technical-seo
or
/products/blue-widget-201
→ /products/blue-widget
The destination should satisfy essentially the same user need.
Consolidated Content
Sometimes several old pages have been intentionally merged.
For example:
- /seo-audit-checklist
- /technical-seo-audit-guide
- /website-seo-audit
may become one stronger guide.
If the new page genuinely consolidates those subjects, several relevant old URLs can redirect to it.
Google explicitly allows consolidated pages to receive redirects from several older URLs when the content has genuinely been combined.
No Valid Replacement
Not every old URL should redirect.
If an expired event page, discontinued product, obsolete campaign, or irrelevant thin page has no meaningful replacement, returning a proper 404 or 410 may be more accurate than sending it to a generic category or homepage.
Google advises against redirecting many unrelated old URLs to one irrelevant destination because those redirects may be treated like soft 404s.
A redirect is not better simply because it exists.
Special Assets
Do not forget URLs outside normal HTML templates.
Check:
- PDFs with backlinks
- Image URLs where search visibility matters
- Legacy subdomains
- Campaign landing pages
- Filtered URLs that earned links
- International URLs
- Downloadable tools
- Historical category paths
- High-value parameter URLs
These often sit outside the obvious redesign scope.
Redirect QA Before Launch
A redirect spreadsheet is not a validated redirect implementation.
The rules need to be tested.
Where the deployment setup allows it, load the redirect configuration into staging, a test server, or another safe environment before production release.
For every priority old URL, validate:
- Redirect exists
- Destination is correct
- Redirect is permanent
- No unnecessary intermediate hops
- No redirect loop
- Final response is 200
- Final URL is indexable
- Final canonical is correct
- Destination content is relevant
- HTTPS/hostname version is correct
Google recommends pointing old URLs directly to their final destinations and keeping redirect chains short.
Mini Example: When the 301 Is Correct but the Migration Is Wrong
A retailer tests its old URLs after implementing a migration.
Every source returns a 301. The engineering checklist says redirects are complete.
A deeper QA pass finds that a large group of category URLs redirects to new category pages whose canonical tags point to a different parent category.
Technically, the redirects work.
Search engines are still receiving conflicting consolidation signals.
This is why our technical SEO QA looks beyond status codes to the final page state.
Staging SEO QA Beyond Redirects
Redirects are only one layer of a migration.
A redesign or replatform can keep every redirect correct and still change the information Google uses to understand and rank important pages.
Staging QA should compare the old site with the intended new version at both the template level and the priority-URL level.
Review:
- Robots.txt
- Meta robots
- X-Robots-Tag
- Canonicals
- Titles
- Meta descriptions
- H1s and major headings
- Main content
- Internal links
- Navigation
- Breadcrumbs
- Structured data
- Hreflang
- Rendered HTML
- Pagination
- Faceted navigation
- XML sitemap output
- HTTP responses
- Mobile rendering
- Conversion forms
- Analytics tags
One important check is content parity.
A redesign often reduces copy because the new layout is more visual. If a high-performing page loses sections that established relevance for its target queries, a traffic decline after launch may be an on-page change rather than a redirect problem.
That is where on-page SEO belongs in migration planning.
Google's site-move guidance specifically tells site owners to remove temporary noindex rules and make sure canonicals use the new URLs once redirects are active.
Before release, also save a final crawl of the old production site.
That frozen baseline gives the team something concrete to compare against after launch.
Launch Day Is a Controlled Cutover
Launch day should not be the first time the SEO team sees production.
It should be a verification exercise against pre-agreed expectations.
Use a simple model:
Go → Hold → Roll Back
Go
Proceed when:
- Redirect rules are ready
- Critical staging issues are resolved
- Production robots settings are prepared
- Canonical logic is approved
- Priority content has passed parity checks
- Analytics and conversion tracking are ready
- Rollback ownership is clear
Hold
Pause the release when a known issue could materially affect search continuity.
Examples:
- redirect file incomplete
- production canonical logic unresolved
- top templates still have noindex
- sitemap generation is broken
- core content fails to render
- critical forms or analytics are untested
Roll Back
Rollback should be reserved for material defects that make fixing forward riskier than restoring the previous version.
Possible triggers include:
- widespread 5xx responses
- large-scale redirect failure
- sitewide accidental noindex
- canonical tags pointing to the wrong domain at scale
- priority templates unavailable
- major revenue funnels broken
These criteria should be agreed before launch, not invented during an incident.
Immediately After Go-Live
Manually test the highest-value URLs first.
Check:
- Homepage
- Top organic landing pages
- Top conversion pages
- Major category/service templates
- Several old URLs from each redirect pattern
- Robots.txt
- Meta robots
- Canonicals
- Analytics
- Forms/checkout where applicable
Then begin a production crawl.
For large ecommerce or multi-market migrations, enterprise SEO governance becomes particularly important because teams may need phased validation across templates, regions, catalogues, and release owners.
Domain Changes and Change of Address
Search Console's Change of Address tool is for eligible domain or subdomain moves. It is not required for ordinary path changes or HTTP-to-HTTPS migrations.
Google says it should be used after the site has moved and redirects are active. Its current guidance also says teams moving domains should account for relevant domain variants such as www and non-www properties. See Google's Change of Address documentation.
Post-Launch QA: First Hour, First Day, First Week, First 90 Days
Post-launch QA should become less frequent over time, but more data-driven.
First Hour
Focus on catastrophic failures.
Check:
- Priority pages return expected statuses
- Old URLs redirect
- No production-wide noindex
- Robots.txt permits intended crawling
- Canonicals use the new host/URLs
- Analytics fires
- Lead forms or checkout work
- Main navigation works
- Critical rendered content is present
The first hour is not the time to investigate minor title differences.
It is the time to find anything that could invalidate the release.
First 24 Hours
Run broader technical QA.
- Crawl the new site
- Audit the complete redirect set
- Check redirect chains and loops
- Compare old and new page counts
- Validate XML sitemaps
- Check internal links still pointing to old URLs
- Validate structured data
- Check hreflang where applicable
- Review status-code distribution
- Compare titles/headings/content on key templates
- Confirm analytics dimensions and conversion tracking
The redirect audit should use the old URL inventory rather than relying only on crawling the new website.
Screaming Frog's redirect audit process recommends uploading the full historical old-URL set and following redirects through to their final response.
First Week
Now move from deployment validation into search-engine evidence.
Monitor:
- Search Console Page Indexing
- Submitted sitemap processing
- 404s
- Soft 404s
- 5xx errors
- Google-selected canonicals
- New URL impressions
- Old URL impressions
- Organic traffic by priority landing page
- Conversions by organic landing page
- Crawl Stats
- Server logs where scale justifies them
Look for direction, not only totals.
Old URLs should gradually give way to their intended replacements. Priority new URLs should begin appearing where old URLs previously performed.
Following Weeks and Months
Continue monitoring until the migration has stabilized.
Track:
- unresolved old URLs
- redirect errors
- organic visibility by page group
- indexation
- backlink updates
- conversions
- crawl patterns
- canonical inconsistencies
- content sections that lost visibility
- international URL selection where relevant
Google says a small to medium-sized site can take a few weeks for most URLs to move, while larger sites can take longer. The process happens URL by URL and depends partly on site size and server speed.
Google also recommends keeping permanent redirects in place for as long as possible, generally at least one year.
How to Tell Normal Reprocessing From a Broken Migration
Not every decline after a migration proves the migration failed.
Google explicitly says temporary search visibility fluctuations are normal while it recrawls and reindexes moved URLs.
The useful task is distinguishing normal reprocessing from evidence of a defect.
Signs of Normal Reprocessing
Typical signs include:
- Old and new URLs temporarily coexist in Search
- Rankings move moderately
- New URLs gradually begin receiving impressions
- Redirects consistently resolve to correct equivalents
- New sitemaps are processed
- Google-selected canonicals increasingly reflect new URLs
- Organic traffic shifts from old landing pages to their replacements
- Crawl activity is reaching the new site
This pattern shows movement toward the intended architecture, even if performance is temporarily uneven.
Signs of a Probable Migration Defect
Investigate urgently when:
- Priority old URLs return 404 instead of redirects
- New equivalents remain absent from Search
- Canonicals point to old or unrelated URLs
- noindex remains on production pages
- Robots.txt blocks important sections
- Widespread soft 404s appear
- Redirects terminate in error pages
- Large volumes of internal links still use old URLs
- New templates have lost important content
- Organic traffic disappears without corresponding impressions on new URLs
- Tracking breaks and performance cannot be measured
- The decline continues to deepen while migration signals remain inconsistent
Google's canonicalization guidance explains that redirects, sitemaps, and rel="canonical" are all signals involved in canonical selection. Those signals should reinforce one another rather than conflict after a migration.
A Real Failure Pattern
A 2026 Search Engine Land case study documented a publisher whose traffic fell roughly 90% following a domain migration that was accompanied by unresolved migration and indexing problems, including soft 404s and a large indexing backlog.
That is useful as an example of what a failure can look like, but it is not an industry benchmark for expected migration loss. The case study describes one specific multinational publishing environment and one specific set of failures.
The diagnostic lesson is more important than the percentage.
A healthy migration should show evidence that Google is transferring attention toward the intended new URLs. A broken migration often shows persistent technical contradictions.
Special Migration Cases Need Different Controls
Not every migration changes the same signals.
Domain Change
A domain migration requires:
- old-to-new redirects
- old and new Search Console properties
- domain-variant checks
- Change of Address where eligible
- new XML sitemaps
- canonical updates
- profile-link updates
- high-value backlink outreach where practical
Domain changes create broader signal reassignment than a simple path update, so monitoring should remain particularly disciplined.
CMS or Platform Change
A CMS or replatforming project can change far more than URLs.
Audit:
- generated URL patterns
- template HTML
- structured data
- rendering
- pagination
- faceted navigation
- canonical logic
- product variants
- international settings
- redirects generated by the CMS
- sitemap behaviour
- internal-link structure
For ecommerce sites, ecommerce SEO should be involved when catalogue logic, product variants, collection/category structures, feeds, and filtering behaviour are changing.
Redesign With the Same URLs
A redesign still creates SEO migration risk even when URL paths stay identical.
Potential changes include:
- fewer internal links
- reduced copy
- changed headings
- altered title logic
- new JavaScript rendering
- different schema
- navigation changes
- buried priority pages
- weaker mobile performance
No redirect map is required for URLs that genuinely remain unchanged, but content and architecture parity still need review.
Consolidation or Merger
When several sites or directories are being merged, many-to-one mapping becomes more common.
Be stricter about destination relevance.
Redirecting hundreds of unrelated legacy pages to a single corporate homepage does not preserve their individual purpose. Some should map to consolidated pages, some to category hubs, and others may have no appropriate successor.
A Practical Migration QA Checklist
The purpose of this checklist is not to replace the detailed project plan. It is to confirm that the core continuity signals are aligned.
Before Launch
- Complete old-URL inventory assembled from multiple sources.
- Organic traffic and conversion baselines saved.
- High-value backlink targets identified.
- Every priority old URL has a redirect decision.
- Redirect destinations reviewed for relevance.
- Redirect implementation tested where possible.
- Final old-site crawl saved.
- Staging crawl completed.
- Robots and noindex rules reviewed.
- Canonicals reviewed.
- Content parity checked on priority pages.
- Internal-link changes reviewed.
- Structured data checked.
- Hreflang checked where relevant.
- XML sitemap output validated.
- Analytics and conversion tracking tested.
- Launch blockers and rollback conditions agreed.
At Launch
- Priority new URLs return expected responses.
- Sample old URLs redirect correctly.
- No accidental production noindex remains.
- Robots.txt is correct.
- Canonicals use the new URLs.
- Main navigation and internal links work.
- Analytics is collecting.
- Critical conversions work.
- New sitemap is live.
- Search Console properties are ready.
After Launch
- Full old-URL redirect set audited.
- Full new-site crawl completed.
- Redirect chains and loops reviewed.
- Internal links updated to new URLs.
- 404, soft 404, and 5xx trends monitored.
- Google-selected canonicals sampled.
- Sitemap processing monitored.
- Priority organic landing pages compared with baseline.
- Conversions compared with baseline.
- Crawl Stats or logs reviewed where useful.
- High-value external links updated where practical.
- Unresolved defects assigned owners.
- Fixes re-crawled after deployment.
- Redirects retained long-term.
The redirect map protects continuity on paper.
Post-launch QA proves whether that continuity actually made it into production.
A strong site migration SEO process should leave one coherent story for search engines: the old URLs moved to relevant new destinations, the new pages are crawlable and indexable, their canonical and internal-link signals agree, the content still satisfies the intended searches, and tracking confirms what happened after launch.
If you are planning a domain move, redesign, CMS change, or replatform, our migration and replatforming SEO services cover URL inventory, redirect mapping, staging QA, launch controls, and post-launch stabilization.
