SEO Migration Checklist

Use this for: Any existing-site transition.

Write down whether the domain, protocol, paths, platform, content or templates will change. Identify the person responsible for redirects, content, hosting and final release. Agree a suitable release window and a recovery plan before making changes. Avoid combining a domain move, redesign and major content rewrite without understanding the extra diagnostic difficulty.

1. List the actual changes and unchanged parts.
2. Assign owners for the affected systems.
3. Agree release and recovery responsibilities.

Use this for: Sites with pre-move data available.

Export Search Console performance for useful page/query groups and a date range suited to seasonality. Save important indexing observations and available analytics outcomes. Note current filters and known tracking limitations so you can compare the same scope later. These are starting observations, not a prediction of what a successful move must achieve immediately.

1. Choose meaningful page groups and periods.
2. Export the relevant reports with filters.
3. Keep the date and measurement limitations with the baseline.

Use this for: Migrations affecting existing content or URLs.

Combine the CMS page list, sitemap, a crawl where available, important landing pages and known external-link destinations. Remove duplicates while keeping meaningful variants and media/download URLs that visitors use. No single report is a complete historical inventory. Prioritize important addresses while explaining any sampling limits.

1. Collect current and important historical addresses.
2. Combine and deduplicate the lists.
3. Flag valuable media, landing pages and unusual variants.

Use this for: Existing addresses affected by the migration.

Use a mapping sheet with old address, outcome, new address when relevant and reason. Keep an unchanged page at its existing address when possible. Map a moved page to its equivalent, a merged page to a useful consolidated replacement, or a genuinely removed resource to an appropriate not-found response when no relevant replacement exists.

1. Choose keep, move, merge or remove for each important address.
2. Name the relevant replacement when one exists.
3. Review ambiguous decisions with the content owner.

Use this for: Rebuilt content or templates.

Save representative old pages or a field export, then compare their main answers, headings, titles, descriptions, images and important actions with the replacement. Preserve useful material unless a deliberate improvement is planned. Do not assume a visually cleaner template has kept every required answer or product detail.

1. Capture representative old content and metadata.
2. Compare with the new page or template.
3. Resolve unintended omissions and misleading changes.

Use this for: Migrations involving media or downloads.

Inventory important images and files alongside pages. Copy the needed assets, update references and map moved file addresses where appropriate. Check actual downloads and image output, including descriptive alternatives. A redirect plan that covers HTML pages but loses a frequently used PDF leaves a real visitor path broken.

1. List important referenced assets.
2. Copy or map their final locations.
3. Open the replacement files and check their references.

Use this for: Actual permanent URL moves.

Give the reviewed mapping to the person controlling server, host or platform redirects. Ask for server-side 301 redirects for permanent moves, directing each old address to its final relevant destination. Google also recognizes 308 as permanent, but confirm platform and tool support. Avoid chains, loops and broad rules that accidentally catch unrelated paths. Test exceptions and important parameter variants rather than assuming a pattern works everywhere.

1. Implement the approved permanent moves.
2. Test representative rules and exceptions.
3. Remove unnecessary chains and loops.

Use this for: A prepared redirect map.

Use a crawler’s list mode or a developer’s request script for the mapping, then manually inspect important results. In Chrome’s Network panel, turn on Preserve log before opening an old address to see the redirect chain. Compare the final status and content with the planned keep, move or remove decision; a 404 is not wrong when removal was intentional.

1. Request the mapped old addresses.
2. Compare status, final destination and content.
3. Investigate mismatches before release.

Use this for: Pages with canonical or multilingual annotations.

Inspect the new page source for rel="canonical" and any hreflang annotations, or have the developer check their header/sitemap implementation. Use intended final URLs rather than staging or obsolete addresses. Compare alternate language pages only when they genuinely correspond; do not make every translation canonical to one language merely because the templates match.

1. Inspect published-output equivalents in staging.
2. Check canonical and applicable locale destinations.
3. Correct stale or conflicting references.

Use this for: Sites with changed internal destinations.

Update navigation, contextual links, breadcrumbs, image links and relevant structured-data URLs. Link directly to the new destination instead of relying on redirects for your own site’s normal paths. Follow important journeys and inspect for isolated pages. Keep labels accurate when content has moved or merged.

1. Update internal references to final addresses.
2. Follow priority navigation and content paths.
3. Fix broken links and orphaned important pages.

Use this for: Sites using a staging environment.

Keep private previews behind proper access control. Review the production robots rules, noindex directives and page responses separately so temporary restrictions do not leak into launch. Retain controls for pages that should remain private or excluded. A successful preview login does not prove an anonymous visitor or crawler can read the live site.

1. List temporary staging restrictions.
2. Prepare the intended production rules.
3. Check public and private page cases separately.

Use this for: Sites with interactive or measured visitor actions.

Use safe test transactions or staging modes to check forms, purchases, downloads and navigation on important templates, including mobile. Confirm the intended analytics events where an approved implementation exists, keeping test traffic distinguishable. A migration can preserve titles while breaking the action that makes the page useful.

1. Test important visitor journeys safely.
2. Check mobile behavior and intended event recording.
3. Resolve broken functions or tracking differences.

Use this for: Immediately after migration release.

Open the preferred live homepage and priority old/new URLs after release. Check their actual content, responses, redirect destinations and search restrictions. Test anonymously where appropriate; a logged-in session can hide an access problem. Escalate a broad outage, wrong redirect rule or broken main journey to the responsible owner promptly.

1. Open priority live pages and old addresses.
2. Check responses, destinations and content.
3. Escalate material release defects.

Use this for: Migrations changing canonical URLs.

Generate the final sitemap from intended canonical pages and inspect its domain, paths and exclusions. Submit it in the correct verified Search Console property and check processing errors. For a domain move, keep monitoring the old and new properties. Sitemap processing helps discovery but does not certify that every mapped page has moved in search.

1. Inspect the final sitemap.
2. Submit it to the relevant verified property.
3. Review processing and important-page observations.

Use this for: Domain or subdomain migrations; other move types are not applicable.

If moving between domains or subdomains, open the old property’s Settings → Change of address after its 301 redirects are in place. You need owner access to both old and new properties in the same Google account. Google does not require that tool for HTTP-to-HTTPS, same-domain path moves or switching www on the same domain. Use the tool’s current checks rather than applying it to every redesign.

1. Identify whether the move changes domain or subdomain.
2. Verify the relevant properties and redirects.
3. Use Change of Address only for a supported move.

Use this for: The post-move review period.

Check important live responses, Page indexing, URL Inspection and comparable search/analytics reports. Investigate missing content, incorrect canonicals, broad exclusions or server failures before attributing a change to normal migration processing. Conversely, a temporary old/new URL mix in search is not by itself proof that the live redirects are broken.

1. Review live technical conditions.
2. Compare like-for-like page and query data.
3. Investigate concrete defects separately from processing changes.

Use this for: Migrations with a serious release defect.

If the release causes a broad outage, misroutes important traffic or breaks a critical action, involve the responsible technical owner and use the prepared recovery plan. Consider the data and operational consequences before reverting. A lower ranking on one day is not a sufficient technical diagnosis. Record the cause and retest the corrected release.

1. Confirm the material defect and affected scope.
2. Consult the agreed release owner and recovery plan.
3. Verify the repaired or restored behavior.

Use this for: Migrations with old addresses still referenced.

Plan continued ownership, HTTPS and redirect hosting for old addresses that must keep working. Google recommends retaining move redirects as long as possible, generally at least a year; useful visitor links may justify longer. Update your own links directly and request important external corrections where appropriate. Do not remove redirects simply because launch week ended.

1. Assign ownership for old-domain and redirect maintenance.
2. Keep required HTTPS and redirects working.
3. Update important references and review actual use.