What this SEO migration checklist covers
This seo migration checklist is for teams that need to move a site without guessing their way through it. It is written for in-house SEOs, marketers, developers, content teams, and agencies responsible for a website migration, whether that means a domain migration, platform migration, or a site redesign with SEO risk attached.
The focus is practical. It covers the pre migration checklist work that prevents avoidable mistakes: inventorying URLs, identifying the pages that matter most to organic visibility, mapping redirects, checking technical settings, and agreeing who owns each task. It also covers launch planning, so the migration is not treated as a single switch-flip moment. Post-launch checks are included too, so problems are caught early rather than after traffic has already fallen.
You will not find a promise of zero loss. That is not realistic. What this website migration checklist does is help you reduce risk, spot gaps before launch, and make recovery faster if something slips through. If you are planning a migration and need a structured way to protect organic visibility, this is the right place to start.
SEO migration basics: what can go wrong and why planning matters
A migration can fail in a few predictable ways. Pages that used to rank disappear because search engines cannot find a clear path from the old URL to the new one. Redirects are missing, chained, or point to the wrong destination, so link equity gets diluted and users hit dead ends. Canonical tags can clash with the redirect plan, which leaves Google unsure which version to index. A rushed launch can also waste crawl budget on duplicate, parameterised, or low-value URLs, slowing discovery of the pages that matter.
The bigger problem is usually not one mistake but several small ones that stack up. A site redesign may change URL structure, internal linking, templates, and content all at once. A platform migration can alter how sitemap.xml is generated, how robots.txt behaves, or how metadata is rendered. If those changes are not mapped before launch, the team ends up troubleshooting in production, which is the most expensive place to do it.
That is why a seo website migration checklist exists in the first place. It turns a risky project into a series of controlled checks: inventory the current site, map every important URL, confirm 301 redirects, test indexation signals, and verify that search engines can still crawl the right pages. Each step protects organic visibility in a different way. Skip the inventory and you miss pages. Skip redirect mapping and you lose relevance. Skip post-launch monitoring and you do not know whether traffic recovery is happening or whether the site is drifting further.
A good seo migration is not just about preserving rankings on day one. It is about making sure the new site can be crawled, understood, and trusted quickly enough for traffic recovery to begin. Treat each checklist item as a control point. If it does not reduce risk, it probably does not belong in the launch plan.
Pre-migration audit and inventory
Before anyone touches templates, build a baseline inventory of what the site already earns and what it cannot afford to lose. A proper pre migration checklist starts with a site audit, but not the vague kind that produces a long export and little else. You need a working list of URLs, performance data and ownership details so you can compare the old site with the new one after launch.
Start with a full crawl of the live site and export every indexable URL. Then compare that crawl with analytics and Google Search Console so you are not relying on one source of truth. Analytics shows what actually brings traffic and conversions; Search Console shows which pages have search visibility, impressions and queries. The overlap matters, but so do the gaps. A page with modest traffic and strong branded demand may still be business-critical. A page with no traffic today may still need to stay because it supports internal linking or sits in a conversion path.
Your inventory should capture more than the URL itself. At minimum, record the current URL, page type, title tag, canonical tag, indexation status, organic sessions, conversions, top queries, backlinks if available, and the intended new destination. If the migration changes information architecture, note the section or template the page belongs to as well. That makes URL mapping easier later, especially when similar pages need to be consolidated rather than copied one for one.
Baseline Metrics to Capture
| Metric | Description |
|---|---|
| Organic Sessions | Number of visits from search engines. |
| Conversions | Actions taken by users that meet business goals. |
| Top Queries | Search terms that lead to the site. |
| Backlinks | External links pointing to the site. |
| Indexation Status | Whether a page is indexed by search engines. |
For most teams, the fastest way to keep this usable is a spreadsheet with a few fixed columns and clear ownership. A simple structure works better than a sprawling document nobody updates. For example:
- old URL
- page purpose
- current organic value
- new URL
- redirect type
- canonical target
- notes or exceptions
- owner
If you are dealing with a large site, add a priority field so the highest-value pages are reviewed first. That usually means landing pages, category pages, product pages and any URL that drives leads or revenue. Low-value archive pages can be handled differently, but only after someone has checked whether they still attract links or search demand.
This is also the point to review technical signals that affect the migration plan. Export the current sitemap.xml and compare it with the crawl so you can see which URLs are missing, orphaned or blocked. Check robots.txt for rules that may interfere with crawling during testing or after launch. Review canonical tag behaviour on key templates, especially if the new platform changes how canonicals are generated. None of this is glamorous, but it prevents avoidable surprises when the new site goes live.
A useful habit is to benchmark the current site before any development work starts. If you want a cleaner process, use pre-migration crawl benchmarking to capture the baseline in a repeatable way. That makes post-launch checks far easier because you are comparing against a known state rather than guessing what changed.
The inventory should end with a clear list of pages that must be protected, merged, redirected or retired. If that decision is not made before launch, it tends to get made under pressure later, which is when mistakes creep in. If you own the migration, start here: crawl the site, reconcile it with analytics and Search Console, and lock the URL mapping before development is signed off.
Build the URL map and redirect plan
Map every important old URL to a clear destination before launch, and treat that mapping as a control document, not a rough note. The aim is not to preserve every URL forever. It is to preserve relevance, crawl efficiency and the signals that matter to search engines.
Build the URL map around page intent. Keep category pages pointed at equivalent category pages, product or service pages pointed at the closest live equivalent, and content pages redirected to the nearest matching article or resource. If there is no sensible match, decide whether the page should return a 410, stay live, or be consolidated into a broader page. Do not force everything through a 301 redirect just because it is easier.
A useful redirect mapping sheet needs four fields at minimum: old URL, new URL, redirect type, and notes. The notes column is where you record judgement calls, such as whether a page has backlinks worth preserving, whether the new page is a close topical match, or whether the old URL should be retired because it has no value. Keep the language consistent so the developer, SEO lead and content owner are all reading the same instruction.
Use 301 redirect rules for permanent moves. That covers most migration work, but not every case. Temporary redirects belong in rare situations where the destination is not final, and chained redirects should be removed before launch. One redirect is acceptable; two or three in a row usually means the plan needs tightening.
Match redirects to the new site architecture, not just the old folder structure. If the redesign changes how content is grouped, map by intent first and URL pattern second. A blog post about pricing should not be sent to a generic blog index because the old slug looked similar. The closer the destination matches the original purpose, the better the chance of keeping organic visibility stable.
Check the technical side of the mapping at the same time. Canonical tag settings should point to the final destination, not the old URL. If the migration changes domains or subfolders, make sure the redirect plan and canonical tag logic do not conflict. The same applies to XML sitemaps and internal linking: once the new URLs are live, they should reflect the final structure, not the legacy one.
A practical way to reduce mistakes is to review the mapping in layers. First, confirm the high-value pages and pages with external links. Then check the rest of the site by template type. Finally, test edge cases such as trailing slashes, uppercase variants, parameters and paginated URLs. Those are the places where redirect mapping often breaks down.
If the migration is commercially important, this is the point where specialist support pays for itself. A clean URL mapping plan is usually the difference between a controlled move and a messy one. Check that every indexable old URL has a decision attached to it: redirect, retain, consolidate or retire.
Technical pre-launch checks
Before launch, the technical seo checks should answer one question: can search engines still crawl the right pages and understand which version of each page to index? Migrations usually fail in the details, not in the design handover. A small configuration error can block discovery or send mixed signals.
Start with robots.txt. Make sure it is not blocking important sections of the new site, especially if the staging environment used restrictive rules that were never removed. A common mistake is leaving a disallow in place on the live domain, or carrying over a staging directive that stops key templates from being crawled. Check the file directly in the browser and confirm it matches the launch plan, not the test environment.
Next, review the xml sitemap. It should list only live, indexable URLs that you actually want in search results. Remove old URLs, parameter variants, redirected pages and anything marked noindex. If the sitemap still contains legacy addresses, Google can waste crawl budget revisiting pages that should have been retired. The same applies to any sitemap index files: every referenced sitemap should be current and clean.
Canonical tags need manual review, not just a template check. Each indexable page should point to its preferred live URL, and that URL should return a 200 status. Canonicals that point to redirected URLs, staging domains or non-canonical variants create confusion and slow down indexation. On larger migrations, spot-check templates rather than assuming the CMS has handled everything correctly. Product pages, category pages and blog templates often behave differently.
If the migration includes international versions, confirm hreflang only after the core crawl signals are stable. Broken language annotations can be as damaging as missing canonicals, but they are usually secondary to basic crawlability. Fix the fundamentals first.
Use Google Search Console to verify the new property, submit the updated sitemap and inspect a sample of important URLs with the live test. You want to see the expected canonical, indexability status and rendered page content. If the site is large, compare the number of submitted URLs with the number of valid indexed pages once launch is live. A sharp mismatch usually means something in the crawl path is still wrong.
Check that robots.txt, sitemap.xml and canonical tags all agree on the same set of indexable pages. If they do not, search engines will spend crawl budget sorting out your signals instead of consolidating them.
Content and internal link updates
Content migration is where a lot of the quiet damage happens. Redirects can be right and the site can still lose relevance if page copy, metadata and internal linking are left behind or handled mechanically.
Treat the content pass as part of site architecture, not a cosmetic tidy-up. If a page is moving to a new URL, check whether the heading, title tag, meta description and body copy still match the search intent that page earned before the migration. A product category that ranked because it answered a specific commercial query should not be rewritten into generic brand language just because the CMS template changed. The same applies to service pages, guides and comparison pages: keep the topic intact, then improve the page only where the new structure gives you a clear reason.
Internal linking needs the same discipline. During content migration, links often break in less obvious ways than a 404. Navigation may still work, but deeper links that support crawl paths and topical relevance can disappear when modules are rebuilt, content blocks are removed or old CMS fields are not carried across. Review links in body copy, related content modules, breadcrumbs and footer areas. If a page used to sit close to a cluster of supporting articles, keep that relationship in the new site architecture rather than flattening everything into a generic menu.
Metadata deserves a manual review too. Titles and descriptions should be rewritten where the URL or page purpose changes, but not so aggressively that they lose the query language that was already working. Canonical tag settings should also be checked against the final destination, especially where content has been merged or split. A page that now exists in a new format should point clearly to the preferred version, not to an old template or a near-duplicate.
For larger migrations, prioritise content updates by value. Start with pages that drive organic visibility, revenue or strong internal linking equity, then work down to lower-impact URLs. That keeps the migration checklist focused on what can actually move the needle, rather than spending time polishing pages that have little search demand.
Before sign-off, compare the old and new versions of the most important pages and confirm that the topic, metadata and internal linking still support the same intent. If those signals drift, rankings usually do too.
Launch day and post-launch checks
Launch day needs a tighter rhythm than the rest of the migration. The job is not done when the site goes live; it is done when you have checked the right signals, fixed the obvious faults, and confirmed that Google can crawl the new setup without confusion. See also SEO Migration Services.
On day 0, run quality assurance against the live site before you assume anything is stable. Check that the main templates load, key pages return the expected status codes, and the most important redirects resolve to the right destination. Then confirm that the XML sitemap points to live URLs only, robots.txt is not blocking sections that should be crawled, and canonical tags match the preferred live version of each page. If the migration involved a new CMS or platform, test a few representative page types rather than trusting one template to stand in for all of them.
Google Search Console should be open from the first hour. Submit the new sitemap, inspect a sample of important URLs, and watch for spikes in crawl errors, excluded pages, or sudden drops in indexation. A small dip in crawl activity is normal after a major change. A sustained fall usually means Google is spending crawl budget on the wrong URLs, or it is still finding old paths that should have been retired.
Post-Launch Monitoring Metrics
| Metric | When to Check | Key Signals |
|---|---|---|
| Crawl Errors; Day 0; Spikes in errors or excluded pages | ||
| Indexation; Day 3; Changes in indexed pages | ||
| Traffic Patterns; Week 1; Consistency in branded vs non-branded pages | ||
| Query Coverage; Week 1; Appearance for key search terms | ||
| Traffic Recovery; Month 1; Stability or improvement in traffic |
By day 3, move from basic checks to post migration monitoring. Compare indexed pages, impressions, clicks, and top landing pages against the pre-launch baseline. Look for patterns rather than one-off movements. If branded pages hold steady but non-branded pages fall away, the issue is often structural: redirects, canonicals, internal links, or page relevance. If everything drops together, the problem may be broader, such as a blocked section, a broken sitemap, or a server issue that affected crawlability.
By week 1, the focus should shift to traffic recovery and query coverage. Check whether the pages that mattered before launch are still appearing for the same search terms, and whether Google is surfacing the intended destination URLs. This is where manual review matters. Automated reports will tell you that pages are indexed or not indexed; they will not tell you whether the wrong page is ranking because the new site architecture has diluted relevance.
A simple post migration checklist at this stage should include:
- crawl the live site and compare it with the pre-launch URL list
- review Google Search Console coverage and page indexing reports
- check redirect chains and any unexpected 404s
- confirm XML sitemap submission and processing
- inspect the pages that lost the most traffic or impressions
- verify that internal links point to the new live URLs, not legacy paths
By month 1, you should know whether the migration is settling or still leaking visibility. If traffic recovery is slow, isolate the cause before changing too much at once. One common mistake is to keep editing redirects, canonicals, and content simultaneously, which makes it hard to see what actually helped. Make one change, measure it, then move to the next issue.
If you are managing a larger migration, assign owners for technical SEO, content, and QA before launch day. The fastest way to lose time after go-live is to discover that nobody is responsible for checking Search Console, server logs, or redirect exceptions when the first problems appear.
When to escalate or roll back
Escalate when the problem is bigger than a normal launch wobble. A few broken URLs, a temporary crawl delay, or a short-lived dip in impressions can happen even when the seo migration is sound. The question is whether the issue is isolated or systemic.
Treat it as serious if traffic loss is broad across non-brand pages, if important landing pages stop ranking, or if Search Console shows a sharp rise in excluded, duplicate, or soft 404 URLs after launch. A rollback strategy becomes relevant when the new site is blocking discovery or replacing the wrong pages at scale. That includes an incomplete redirect set, conflicting canonical signals, or a new information architecture that has removed pages with commercial demand.
Escalation should also happen when quality assurance finds a pattern rather than a one-off defect. One broken template can be fixed quickly. The same fault across hundreds of URLs usually points to the deployment process, not the page itself. At that stage, the real question is whether to patch it manually or pause the release until the root cause is corrected.
A rollback does not have to mean a full return to the old site. In many migrations, the safer move is partial rollback: restore the most valuable sections, reinstate the previous redirect logic, or freeze further changes until the technical fault is understood. The decision should sit with whoever owns launch planning, with clear thresholds for traffic loss, indexation failure, and business impact.
If you are still within the launch window, agree those thresholds before anything goes live. Once the site is in production, hesitation costs more than a controlled rollback.
Final checklist summary
Before launch, run the migration checklist as a final gate, not a box-ticking exercise. The point is to check that launch planning, quality assurance, redirect mapping, and indexation controls all line up before traffic moves.
Start with the basics. Every important old URL should have a clear destination, every redirect should be tested, and every canonical tag should point where you expect. Check that the live sitemap reflects the new structure, that robots.txt is not blocking anything needed for crawling, and that internal links point to final URLs rather than temporary ones. If the site uses templates, spot-check more than one page type; a clean homepage tells you very little about a broken product, category, or article template.
For the seo website migration checklist, the last review should also include Search Console access, analytics tagging, and a quick crawl of the live site to catch obvious gaps before Google does. If you are working across multiple teams, confirm who owns fixes on launch day and who has authority to pause or roll back if something looks wrong.
Read the post migration checklist as if you were seeing the site for the first time. If any redirect, canonical, sitemap, or indexation decision feels ambiguous, fix it before launch rather than hoping monitoring will catch it later.