A site migration SEO checklist is a launch control document used when a website is redesigned, rebuilt, replatformed, moved to a new domain or given a new URL structure.
It helps protect the pages that already matter to organic search by checking URLs, redirects, content, indexation, internal links, sitemaps, tracking and post-launch signals before problems become harder to fix.
The checklist does not make a migration risk-free. Its job is to reduce preventable mistakes and give marketing, development and SEO teams a shared process before, during and after launch.
For larger migrations, involve a technical SEO South Africa consultant before URL, template and platform decisions are locked in.
Quick answer
A site migration SEO checklist helps you answer five practical questions:
- Which current URLs need to be protected?
- Where will old URLs redirect?
- Can the new site be crawled and indexed?
- Have internal links, canonicals and XML sitemaps been updated?
- How will search performance, leads, sales and indexing be monitored after launch?
Google’s site move guidance covers areas such as URL mapping, Search Console settings, noindex handling and moved or removed content. Those are the kinds of controls a migration checklist should bring into one working document.
Who should use this checklist?
This checklist is useful for marketing managers, developers, founders, ecommerce managers, SEO reviewers and agencies working on a website move.
Marketing teams use it to protect traffic, leads and sales. Developers use it to manage redirects, templates, sitemaps and launch rules. Business owners use it to understand what needs to be signed off before the new site goes live.
Small design edits do not always need a full migration process. But if URLs, page templates, navigation, content, indexation rules or tracking are changing, use a migration checklist.
Site migration SEO checklist
| Stage | What to review | Why it matters | Priority |
|---|---|---|---|
| 4–6 weeks before launch | Crawl the current live site | Creates a baseline of URLs, status codes, metadata, canonicals and internal links. | High |
| 4–6 weeks before launch | Export organic landing pages | Shows which pages already attract search traffic, leads or sales. | High |
| 4–6 weeks before launch | Review Search Console page data | Identifies URLs with clicks, impressions and existing Google visibility. | High |
| 4–6 weeks before launch | Identify pages with backlinks | Backlinked URLs need careful redirect decisions. | High |
| 4–6 weeks before launch | Mark business-critical pages | Service, product, category, pricing and local pages need extra protection. | High |
| 3–4 weeks before launch | Finalise the new URL structure | Prevents late changes that create redirect and internal-link problems. | High |
| 3–4 weeks before launch | Build the redirect map | Old URLs should point to the closest relevant new URLs. | High |
| 2–3 weeks before launch | Compare old and new page content | Key pages should still satisfy the same search intent after the rebuild. | High |
| 1–2 weeks before launch | Review staging noindex, robots.txt and canonicals | Development settings must not block the live site. | High |
| 1–2 weeks before launch | Prepare the new XML sitemap | The sitemap should contain final, indexable, canonical URLs. | Medium |
| Launch week | Test mapped redirects | Confirms old URLs resolve to the right new destinations. | High |
| Launch week | Crawl the new live site | Finds broken pages, blocked URLs, noindex errors and incorrect canonicals. | High |
| Launch week | Test forms, checkout and tracking | Prevents reporting gaps after launch. | High |
| First 48 hours after launch | Monitor Search Console and analytics | Catches early crawl, indexing and reporting issues. | High |
| First 2–4 weeks after launch | Review key URL groups | Shows whether commercial pages are being discovered and used after the move. | High |
| First month after launch | Re-crawl after fixes | Confirms that corrections were implemented properly. | Medium |
The timing does not need to be exact for every project, but the sequence matters. URL decisions and redirect planning should happen before development is finalised, not after the site is ready to launch.
How a migration checklist differs from related SEO documents
A migration checklist often overlaps with audits, redirect maps and launch QA documents, but it is not the same thing.
| Document | Main purpose | How it differs |
|---|---|---|
| Site migration SEO checklist | Coordinates SEO controls before, during and after a site move. | It brings migration-specific checks into one launch process. |
| Technical SEO audit | Diagnoses crawlability, indexation, performance, architecture and technical issues. | It is broader and more investigative. A checklist is more operational. |
| Redirect map | Maps old URLs to new URLs. | It is one part of the migration checklist, not the full process. |
| Website launch QA checklist | Reviews design, forms, layout, browser testing and functionality. | It may not go deep enough on organic landing pages, redirects, canonicals and indexing. |
| Post-launch monitoring plan | Tracks what happens after launch. | It starts after the site is live, while migration SEO begins before the build is final. |
A redirect map tells developers where old URLs should go. A website technical audit can diagnose deeper technical issues. The migration checklist connects those pieces so the right work happens in the right order.
When you need a site migration SEO checklist
Use a migration checklist for any project that changes how search engines or users access your pages.
Common scenarios include moving to a new domain, changing from HTTP to HTTPS, moving from one CMS to another, replatforming an ecommerce store, changing URL folders or slugs, merging websites, moving content from a subdomain to a subfolder, rebuilding navigation or removing large sets of content.
The more the project changes URLs, content or templates, the more important the checklist becomes.
Example: ecommerce replatforming
Imagine a South African online store moving from WooCommerce to Shopify.
The current site has category pages ranking in Google, product URLs linked from suppliers and buying guides that bring organic traffic. The new platform creates different URL patterns for products, collections and blog content.
Without a migration process, the store might launch with a cleaner design but lose control of search-critical pages. Old category URLs could redirect to the homepage. Product URLs could return 404 errors. Buying guides could disappear from navigation. Transaction tracking could fail, making performance harder to judge.
A stronger migration process would export the current product, category, brand and guide URLs; mark pages with traffic, revenue, backlinks or seasonal value; map old category URLs to the closest new category URLs; preserve useful buying guidance; review filters and canonicals; update breadcrumbs and internal links; and monitor revenue-driving landing pages after launch.
For ecommerce migrations, an ecommerce SEO consultant should be involved before platform defaults decide the URL structure, category setup and indexation rules.
Example: service-business domain migration
A service business moving from an old domain to a new brand domain has a different risk profile.
The site may not have thousands of products, but it may depend heavily on a small group of pages: SEO services, pricing, location pages, case-study-style resources, contact pages and high-performing guides. If those URLs are not mapped carefully, the new site can look correct while the old search value is scattered across weak redirects, missing pages and changed messaging.
For a domain migration, the checklist should focus on verifying both old and new properties, mapping every valuable old URL to the closest new destination, keeping redirects in place for long enough, checking that service pages still target the right intent and monitoring the most commercially important page groups after launch. Google’s site-move documentation recommends keeping redirects for as long as possible, generally at least one year, and notes that this helps Google process the move and transfer signals to new URLs.
Google’s Change of Address tool guidance is relevant for domain or subdomain moves, but not for every migration. The guidance explains that the tool checks ownership and 301 redirects on a few pages before submitting a move request.
Pre-migration planning
Start with the current website, not the new design.
The first step is to understand what already exists and what already works. Crawl the live site, export organic landing page data, review Search Console clicks and impressions, identify backlinked URLs and mark pages that support enquiries, sales or visibility.
That baseline helps the team decide which pages should be kept, improved, merged, redirected or retired. It also prevents a common migration mistake: judging the new site only by how it looks, rather than by what search value it needs to preserve.
Redirect planning
Redirects are one of the highest-risk parts of a migration because they affect users, search engines and legacy URLs at the same time.
Google’s redirect documentation explains that redirects tell users and Google Search that a page has moved to a new location. It also notes that Google may use certain redirects as a signal that the redirect target should be treated as canonical.
Good redirect planning means old service pages go to equivalent new service pages, old category pages go to equivalent new category pages, and product pages go to the same product or the closest relevant alternative. Removed articles should only redirect where there is a genuinely useful replacement.
A redirect map is not finished just because every old URL has a destination. The destination must make sense for the user, the topic and the search intent.
Crawl, indexation and content checks
A migration can fail even when the site looks right visually.
Before launch, crawl the staging site. After launch, crawl the live site. Review whether key pages return a 200 status code, can be crawled, can be indexed, use the correct canonical tag and appear in the XML sitemap where appropriate.
Content also needs a side-by-side review. The new page does not need to copy the old one, but it should not remove the information that made the old page useful. Service pages still need clear service detail. Category pages still need useful buying context. Guides still need internal links and next steps. Headings should still make the page topic clear.
If development noindex rules were used on staging, make sure there is a clear launch step to remove them from the live site. Google’s noindex guidance explains that noindex can block a page from appearing in Search, and Google’s site-move guidance specifically refers to preparing a list of URLs where development noindex rules need to be removed.
Internal links, sitemaps and tracking
The new site should link directly to final live URLs. Redirects are useful for old URLs and external paths, but the new navigation, breadcrumbs, related resources and CTA links should not rely on them.
This is also where migration work becomes commercial. If enquiry forms, call tracking, ecommerce events or thank-you pages break during the move, the business may not be able to judge whether the migration is performing properly. Test tracking before launch, then check it again once the live site is active.
XML sitemaps should contain final, canonical, indexable URLs only. Google’s canonical documentation describes sitemap inclusion as a signal that can help URLs become canonical, although redirects and rel=canonical annotations are stronger canonicalization signals.
Launch-week review
Launch week should be focused and evidence-based.
The team should confirm that the preferred domain version loads correctly, HTTP redirects to HTTPS, old URLs redirect to mapped destinations, key pages return 200 status codes, main pages are indexable, robots.txt and canonical tags are correct, the XML sitemap is live, navigation works, and conversion tracking is recording data.
This is not the week to redesign the SEO strategy. It is the week to verify that the agreed migration controls are working.
Post-launch monitoring
A migration should be monitored in stages, not checked once and forgotten.
In the first 48 hours, focus on critical launch problems: broken redirects, blocked pages, noindex mistakes, server errors, analytics gaps and missing conversion tracking.
During the first week, compare priority URL groups. Look at service pages, ecommerce categories, product groups, local pages, pricing pages and high-value resources separately. Overall traffic can look stable while commercially important sections are underperforming.
During the first month, review Search Console clicks, impressions, indexing changes, canonical signals, XML sitemap processing, crawl errors, leads, calls, sales and enquiries. Re-crawl the site after fixes so the team can confirm that corrections were implemented properly.
For larger migrations, keep monitoring beyond the first month. Domain changes, ecommerce replatforms and large URL restructures can take longer to settle, especially when many URLs need to be recrawled and reprocessed.
When to get expert help
Get expert help before launch when the migration affects revenue, leads, large URL sets or business-critical search visibility.
A technical SEO review is especially useful when the website has hundreds or thousands of URLs, the site is moving to a new domain, organic search contributes to leads or sales, the migration involves Shopify, WooCommerce or Magento, developers have changed URL structures, or important service, category, product or location pages are being rebuilt.
It is also worth getting support when Search Console already shows crawl or indexing issues, the new site uses JavaScript-heavy templates, or a previous migration caused traffic losses.
The useful question is not whether SEO will be affected. A migration usually changes something. The better question is which risks can be found and fixed before launch.
Final site migration SEO sign-off
Before the website goes live, make sure the team can answer yes to these questions:
- Have current URLs been crawled and exported?
- Have organic landing pages and Search Console pages been reviewed?
- Have high-value service, category, product, local and resource pages been marked?
- Have old URLs been mapped to relevant new URLs?
- Has staging been reviewed for crawlability, canonicals, noindex rules and robots.txt settings?
- Do internal links point to final live URLs?
- Does the XML sitemap contain final, indexable, canonical URLs?
- Have analytics, forms, calls and ecommerce tracking been tested?
- Has the live site been crawled after launch?
- Is Search Console monitoring in place for redirects, indexing and key page groups?
Next step
A migration should not be signed off only because the new site looks finished. It should be signed off because the old URLs, new URLs, redirects, indexation rules, content, internal links and tracking have been reviewed.
Build the checklist before launch. Assign owners. Test the riskiest URLs. Crawl the live site immediately after launch. Then monitor the pages that matter most to enquiries, sales and visibility.
If the migration involves a new platform, new domain, changed URLs or pages that generate leads or revenue, discuss a technical SEO review before the launch date is fixed.