Successful website migration SEO preserves valuable URLs, content, metadata, internal links, redirects, crawlability, indexing signals, structured data, tracking and performance across launch. Missing redirects, lost content, incorrect canonicals, broken links, staging restrictions, faulty sitemaps and slower pages can undermine visibility. Weak monitoring allows these problems to persist; no checklist can guarantee unchanged rankings.
For teams planning SEO for website redesign and migration, professional SEO support belongs in discovery and testing, not only the post-launch review. The aim is to make every important old URL and search intent accountable in the new system.
What is an SEO migration?
An SEO migration is the coordinated work needed to protect search visibility during substantial website changes. A redesign changes presentation; a CMS migration changes content management; replatforming replaces the underlying platform. Each can affect how pages are discovered and understood.
| Migration type | Main SEO risk to inspect |
|---|---|
| Website redesign | Content, navigation and performance changes |
| CMS or ecommerce replatforming | URLs, metadata, templates and rendering |
| Domain or subdomain-to-subfolder move | Redirects and URL references |
| HTTP to HTTPS | Protocol redirects and inconsistent references |
| Hosting or infrastructure change | Availability, response behaviour and access |
Change only what the project requires. Google's site-move guidance recommends separating major changes where possible and notes that rankings can fluctuate during processing. Combining domain, CMS, content and navigation changes makes diagnosis harder, although platform constraints may require a combined release.
What should the migration plan establish first?
Define scope, owners, dependencies and launch criteria before development begins. Record what will change and what should remain stable. An SEO migration plan also needs backups and a practical rollback decision.
SEO owns inventory and validation priorities; developers own implementation; designers own usable navigation; content teams reconcile copy; analytics teams validate measurement. DevOps manages infrastructure, while the project manager coordinates approvals and business stakeholders accept trade-offs.
Document launch timing, escalation contacts and rollback triggers. Restoring old code may not safely reverse new orders or content edits, so assess data reconciliation before treating rollback as a simple switch.
What belongs in the primary SEO migration checklist?
Compare each critical SEO element before migration and after launch. Assign an owner and retain evidence of testing rather than marking tasks complete from visual inspection alone.
| SEO Area | Before Migration | After Launch |
|---|---|---|
| URLs | Inventory and map destinations | Compare old and new sets |
| Redirects | Test mapping rules | Check status and final destination |
| Content | Record valuable copy and intent | Reconcile migrated pages |
| Metadata | Export titles and descriptions | Check missing or changed fields |
| Internal links | Map navigation and contextual links | Find broken links and orphans |
| Canonicals | Define preferred URLs | Inspect live annotations |
| Robots.txt | Prepare production rules | Check critical paths and assets |
| XML sitemap | Generate current canonical URLs | Validate and submit |
| Structured data | Inventory relevant markup | Validate migrated output |
| Analytics | Save baseline and event plan | Verify sessions and conversions |
| Performance | Benchmark representative templates | Check regressions |
| Indexing | Record status and exclusions | Monitor new URL processing |
| Rankings | Save page/query baselines | Compare affected groups |
How do you build a reliable baseline?
Combine a website crawl with CMS exports, search data, analytics and backlink information. A crawl alone cannot discover every orphan page. Preserve dated exports before URLs and reporting dimensions change.
Record status codes, canonicals, titles, descriptions, H1s, H2s, internal links, redirects, images, structured data, pagination, hreflang and robots directives. Reconcile sitemap URLs against CMS records and landing pages to identify gaps.
Export Google Search Console pages, queries, clicks, impressions, CTR and average positions, plus available indexing information. Save Google Analytics organic sessions, conversions and revenue or leads. Include crawl errors, important backlinks, Core Web Vitals and local or international pages. Available reports may be incomplete, so avoid treating one export as a complete URL inventory.
Prioritise pages with revenue, leads, backlinks, search demand or important internal-link roles. Compare historical periods to separate seasonal changes from migration effects.
How should URLs and redirects be mapped?
Assign every known old URL a deliberate outcome: keep, move, merge or remove. Redirect changed pages to the closest relevant replacement. Missing redirects leave users and crawlers without a route to the replacement content.
| Old URL | New URL | Action |
|---|---|---|
| /services/audit | /services/audit | Keep; return 200 |
| /old-guide | /guides/migration | Permanent redirect to equivalent |
| /guide-part-two | /guides/migration | Redirect if content is genuinely consolidated |
| /retired-campaign | No relevant replacement | Return 404 or 410 |
Add current status, canonical destination, content status, priority and owner to the working redirect mapping. Use server-side permanent redirects, commonly 301, following Google's redirect guidance. Avoid homepage catch-alls, irrelevant destinations, chains and loops.
Test old URLs through to the final response, including case, trailing-slash and parameter variants where relevant. Update internal links directly. Keep the old host operational when it must serve redirects, and do not retire rules merely because launch has passed.
What content and navigation should remain stable?
Preserve high-value search intent and meaningful content unless there is a deliberate replacement plan. A visual redesign does not require rewriting successful pages. Unnecessary changes make migration analysis harder.
Reconcile core copy, headings, FAQs, product and category descriptions, images, alt text, metadata and supporting links. Preserve useful Open Graph fields for sharing. Improve clarity, accessibility and conversion design without silently removing information people search for.
Review category hierarchy, subcategories, breadcrumbs, click depth and related content. Replace old URLs in navigation, footers, contextual links and image links. Compare important pages' discoverability so a cleaner menu does not create orphan pages.
How do you validate crawlability and indexing signals?
Check staging protection, production access and canonical consistency separately. A page returning 200 is not necessarily indexable. Inspect HTTP headers, HTML directives and rendered output.
Protect staging with authentication where appropriate. Google's robots.txt guidance explains that crawl blocking is not a reliable way to prevent a URL appearing in search. Crawlers must access a page to observe its noindex directive.
At launch, remove unintended noindex rules and development blocks. Keep necessary CSS and JavaScript accessible. Check robots.txt paths, parameter rules and sitemap references against the actual production host.
Use self-referencing canonical tags on preferred pages and consistent destinations across links and sitemaps. Validate intentional cross-domain or parameter canonicals; never leave staging addresses. Google treats canonical annotations as signals, not guaranteed instructions.
Current XML sitemaps should contain canonical, indexable URLs returning successful responses, excluding redirects and errors. Segment them where useful and submit through Search Console. Google's sitemap guidance explains that submission supports discovery but does not guarantee indexing.
What can rendering, media and performance break?
A redesigned page must remain understandable to crawlers and usable on mobile devices. Validate important templates rather than the homepage alone. A faster-looking interface can still introduce slow interactions or missing content.
For JavaScript-heavy sites, inspect client-side rendering, server-rendered content, hydration, metadata and dynamic links. Verify crawlable links and important content using Google's JavaScript SEO guidance. Test mobile navigation, tap targets, responsive layouts and content parity.
Check broken media, migrated image URLs and valuable image-search assets. Use suitable compression, dimensions and formats such as WebP or AVIF where appropriate. Validate lazy loading rather than assuming images will appear without interaction.
Review server response, JavaScript, CSS, fonts, third-party scripts, caching and CDN behaviour. Core Web Vitals measure loading performance through LCP, responsiveness through INP and visual stability through CLS. Compare lab checks before launch with real-user measurements as they become available.
What changes need extra CMS and ecommerce scrutiny?
CMS migration SEO requires template-level comparison, even when page addresses remain unchanged. WordPress, Shopify, Magento, headless and custom CMS migrations can alter defaults. Replatforming SEO therefore needs explicit acceptance tests.
Check metadata and schema fields, pagination, category structures, filters and faceted navigation. Ecommerce migration SEO also needs product URLs, out-of-stock handling, product markup and canonical rules reviewed. Do not redirect every temporarily unavailable product away automatically.
Migrate relevant organisation, breadcrumb, product, article, local-business and review markup with its content. Preserve FAQ markup only where appropriate; valid markup does not guarantee enhanced search appearance. Validate output after deployment without adding unsupported claims.
For domain migration SEO, verify old and new Search Console properties and align redirects, canonicals, sitemaps, branding and analytics. Update important backlinks where possible, plus email and marketing links. Document every additional change if domain and platform must move together.
What should happen before and during launch?
Pre-launch SEO QA should prove the migration plan works; launch-day checks must confirm production matches it. A passing staging test cannot detect every deployment configuration error.
- Before launch: crawl staging with authorised access; compare URLs, content, metadata, links and redirects.
- Validate technical signals: check HTTPS, canonicals, robots, sitemap, schema and hreflang where relevant.
- Check experience and measurement: test mobile rendering, performance, analytics and conversion journeys.
- Deploy: activate redirect rules, remove staging restrictions and record the launch time.
- Verify live: crawl critical URLs, test redirects, inspect server errors and confirm Search Console verification.
- Confirm discovery and tracking: submit the sitemap, inspect important pages and review logs where available.
Test Google Analytics, Tag Manager, ecommerce, forms, phone events, consent handling and marketing pixels. Missing tracking can resemble organic traffic loss even when search clicks remain steady.
How should post-migration SEO be monitored?
Monitor technical health and business outcomes together, daily immediately after launch where practical. Re-crawl the site and reconcile old and new URL sets. Prioritise important pages and recurring template failures.
| Signal | What to investigate |
|---|---|
| 404s, 5xx errors and chains | Missed mappings or infrastructure failures |
| Indexing and canonical changes | Unexpected exclusions or selected URLs |
| Clicks, impressions and rankings | Affected page/query groups |
| Sessions and conversions | Tracking accuracy and user journeys |
| Performance and crawl logs | Rendering, availability and response regressions |
Review sitemap processing, structured data and backlinks reaching dead URLs. Keep an issue log with ownership, fixes and retest evidence.
What if rankings drop after migration?
Diagnose affected URLs before making broad changes. Temporary fluctuations do not automatically mean failure, but large or persistent losses require investigation. Ranking recovery after migration has no universal deadline.
First compare Search Console with analytics to rule out tracking loss. Then check redirects, indexability, canonicals, robots.txt and sitemaps. Compare content, internal links, removed pages and backlinks, followed by rendering, speed and server errors. Fix confirmed causes and monitor the affected groups before introducing further changes.
