A website migration can improve a business for years and still cause an avoidable search problem in one afternoon. The usual failure is not one dramatic mistake. It is a chain of smaller gaps: missing URL inventory, generic redirects, stale canonicals, blocked resources, broken internal links and no clear monitoring owner.
This website migration SEO checklist turns the move into a controlled release. It covers domain changes, URL restructuring, CMS replacements, redesigns and hosting moves. Not every step applies equally to every project, but the sequence does: understand what changes, preserve what should remain, test before launch and monitor after it.
Google provides separate guidance for moves with URL changes and hosting changes without visible URL changes. Start by identifying which type you are actually performing.
What counts as a website migration
A migration can change one or more layers:
• Domain: example.com moves to a new domain.
• Protocol or hostname: HTTP to HTTPS, or www to non-www.
• URL structure: category paths, filenames or parameters change.
• CMS or framework: WordPress moves to another platform, or rendering architecture changes.
• Hosting or CDN: infrastructure changes while public URLs remain the same.
• Design and templates: navigation, headings, content modules and internal links change.
• Content consolidation: multiple pages merge, split or retire.
• International structure: language or country URLs are reorganized.
Risk rises when several layers change together. A new domain, CMS, design and content strategy launched on the same day make it harder to identify the cause of a problem. Separate major changes where business constraints allow.
The MOVE SAFE framework
Use MOVE SAFE as the migration operating system:
M — Map every important old URL and its destination.
O — Observe current performance, crawl state and templates.
V — Verify the new build in a controlled environment.
E — Execute redirects and launch steps in a defined order.
S — Submit updated discovery and ownership signals.
A — Audit live pages, logs and reports.
F — Follow trends long enough to distinguish migration effects from noise.
E — Exit legacy infrastructure only when old traffic and crawl demand are safely handled.
The framework gives each step an owner and evidence requirement.
Set scope and ownership
Write a one-page migration brief before technical work begins.
□ Define what is changing and what is not.
□ Name the launch owner, SEO owner, developer, analytics owner and rollback decision-maker.
□ Record the planned launch window and freeze period.
□ List dependencies such as DNS, certificates, CDN, consent tools, forms and third-party scripts.
□ Agree on stop conditions.
□ Decide which old systems must stay available for redirects, logs or rollback.
Useful stop conditions include a failed payment or lead form, widespread 5xx errors, missing canonical tags, a sitewide noindex directive, broken analytics or redirects sending important pages to irrelevant destinations.
Capture the baseline
You cannot diagnose a migration without knowing the starting state.
□ Export indexable URLs from the CMS.
□ Crawl the existing site.
□ Export XML sitemap URLs.
□ Collect top landing pages and conversions from analytics.
□ Export Search Console pages, queries, indexing and sitemap information.
□ Record current status codes, canonicals, robots directives and hreflang.
□ Identify pages with external links.
□ Save structured-data results for key templates.
□ Record Core Web Vitals and performance for representative templates.
□ Save server-log samples where available.
Do not use one source as the complete inventory. CMS exports miss orphaned or legacy URLs. Analytics misses pages with little traffic. Sitemaps may contain stale URLs. Combining sources reveals the migration surface.
Inventory and map URLs
The URL map is the project’s control file.
For each old URL, record:
Old URL | Action | New URL | Reason | Priority | Tested
Retain | 200 | Same URL | Content remains | High | Yes/No
Move | 301/308 | Closest equivalent | URL changed | High | Yes/No
Merge | 301/308 | Consolidated page | Topics combined | Medium | Yes/No
Retire | 404/410 | None | No replacement exists | Low | Yes/No
Review | TBD | TBD | Owner decision required | High | No
Google recommends permanent server-side redirects for permanent moves. A redirect should point to the closest relevant replacement, not automatically to the homepage. Large groups of irrelevant redirects can confuse users and search engines.
Preserve query parameters only when they affect meaningful content or tracking requirements. Avoid redirect chains such as old A → interim B → final C. Map old A directly to final C.
The original redirect coverage calculation
Use this score for priority control:
High-value redirect coverage = correctly tested high-value legacy URLs ÷ total high-value legacy URLs × 100
A URL counts as correctly tested only when it:
1. returns the intended permanent redirect;
2. resolves in one hop;
3. lands on a live, indexable and relevant page;
4. uses the expected canonical;
5. is reachable through updated internal links.
Do not invent a universal passing percentage. For pages carrying revenue, leads, strong external links or important rankings, unresolved mappings should be treated as launch blockers.
Build and test the destination
Use a staging environment that users can test but search engines cannot accidentally index. Google notes that temporary hostnames can be protected with noindex while testing. Before launch, every temporary block must be removed.
Content and template checks:
□ Each destination page has the intended title, H1 and main content.
□ Important text is present in rendered HTML.
□ Mobile pages contain equivalent primary content and descriptive image alt text.
□ Canonicals point to the final preferred URLs.
□ Pagination, filters and faceted navigation behave intentionally.
□ Structured data matches visible content and final URLs.
□ Hreflang pairs are complete if multilingual pages are involved.
□ Image, CSS and JavaScript resources are accessible.
□ Forms, search, downloads and checkout or lead flows work.
□ Consent and analytics tags fire only as intended.
Technical checks:
□ HTTPS certificates and hostname coverage are valid.
□ The destination handles expected traffic.
□ Custom 404 pages return a real 404 status.
□ 5xx behavior is monitored.
□ Robots.txt does not block required resources.
□ XML sitemaps contain canonical destination URLs only.
□ Internal links use final URLs, not redirects.
□ Navigation, breadcrumbs and related links are crawlable.
□ Search Console verification will remain available.
Prepare redirects and canonical signals
Redirects, canonicals, sitemaps and internal links should tell the same story.
If an old URL permanently moves to a new URL:
• the old URL should issue a permanent server-side redirect;
• internal links should point directly to the new URL;
• the new page should normally self-canonicalize;
• the new URL should appear in the current sitemap;
• old URLs should be removed from new sitemaps;
• content should remain equivalent enough for the mapping to make sense.
A canonical tag is not a replacement for a redirect when a page has actually moved. It is a preferred-URL signal for duplicate or very similar content. Google treats redirects and canonicals as different mechanisms.
Test redirect rules on samples from every pattern, then run the full high-priority list. Watch for loops, chains, case sensitivity, encoded characters, trailing-slash errors and protocol or hostname conflicts.
Launch-day sequence
A controlled launch has a written order.
1. Freeze unapproved content and template changes.
2. Take a final data and configuration backup.
3. Confirm DNS, certificate, CDN and rollback readiness.
4. Deploy the destination.
5. Remove staging-only noindex and crawl blocks.
6. Activate tested redirects.
7. Verify key pages, forms and templates from outside the internal network.
8. Check robots.txt, canonicals, status codes and rendered content.
9. Publish the new sitemap.
10. Confirm analytics and conversion tracking.
11. Inspect a sample of old URLs and high-value new URLs.
12. Record issues, owners and next review times.
For a domain change, use the relevant Search Console site-move tools and verify both properties where required. For hosting-only moves, monitor DNS propagation and logs on old and new infrastructure.
Post-launch monitoring
The first review should happen immediately, but migration monitoring must continue.
Watch:
• 4xx and 5xx errors;
• redirect loops and chains;
• old URLs still receiving traffic or crawls;
• sitemap processing;
• indexed-page patterns;
• canonical selection;
• search impressions, clicks and landing-page trends;
• analytics sessions and conversions;
• server response time;
• mobile rendering and structured-data errors;
• external links still pointing to critical retired URLs.
Compare by page groups, not only total traffic. A stable sitewide total can hide a damaged high-value template. Separate brand and non-brand queries where useful, and annotate unrelated campaigns or seasonality.
Search Console data is not instantaneous. A short delay or fluctuation does not automatically prove failure. Combine reports with live crawls, analytics and server logs.
Migration scorecard
Score each area from zero to two:
Area | 0 | 1 | 2
Map | Important URLs unmapped | Partial map | All priority decisions resolved and tested
Observe | No baseline | Limited exports | Crawl, analytics, Search Console and link evidence captured
Verify | Staging untested | Template samples checked | Full priority journeys and technical controls tested
Execute | Informal launch | Basic runbook | Sequenced launch, stop conditions and rollback owner
Submit | Signals conflict | Some updated | Redirects, canonicals, links and sitemap align
Audit | No live checks | One-time spot check | Scheduled crawl, log and report monitoring
Follow | No trend plan | Sitewide totals only | Page-group trends and issue ownership
Exit | Legacy removed immediately | Partial retention | Redirect/log infrastructure retained until evidence supports retirement
The score is a management tool, not a ranking guarantee. Any zero in Map, Verify or Execute should trigger a launch review.
Common mistakes
Changing everything at once
A domain, CMS, design and content rewrite in one release multiplies uncertainty. Phase changes where possible.
Redirecting everything to the homepage
This creates a poor user experience and weakens topical continuity. Use the closest relevant destination or a genuine 404/410 when no replacement exists.
Leaving staging directives live
A sitewide noindex or restrictive robots rule can block discovery. Verify from the public environment after deployment.
Keeping internal links pointed at old URLs
Redirects are a safety net, not an internal navigation system. Update links directly.
Retiring old hosting too quickly
Old infrastructure may still be needed for redirects, logs or rollback. Exit only after evidence shows it is safe.
Expecting immediate stability
Search systems need time to recrawl and process signals. Monitor patiently while fixing clear technical errors promptly.
Frequently asked questions
Will a website migration always reduce rankings?
No, but temporary fluctuation is possible. Careful mapping, testing and monitoring reduce avoidable risk; they cannot guarantee unchanged rankings.
How long should redirects stay live?
Google recommends keeping redirects for as long as possible, generally at least a year for site moves. Business and backlink requirements may justify keeping important redirects longer.
Should old URLs remain in the new sitemap?
No. The new sitemap should list canonical destination URLs. Redirects handle requests for old URLs.
Do I need the Change of Address tool?
It is relevant to certain domain moves, not every redesign, hosting change or path update. Follow the current Search Console guidance for your migration type.
Should I request indexing for every migrated URL?
No. Submit an accurate sitemap and use manual inspection selectively for a small number of important pages. Repeated requests do not replace a crawlable site and consistent signals.
ORIGINAL ELEMENT
The MOVE SAFE framework, redirect-coverage formula and eight-area scorecard convert migration advice into a release-control system without inventing universal thresholds.
