Website migration: a practical SEO checklist

Moving your website? Plan redirects, preserve useful content, check crawler access, and monitor the launch. A practical migration checklist for your team.

13 April 2026

Nikita Janockin

Platform problems can make a move worth considering: conflicting plugins, maintenance work, or a checkout your customers struggle to use.

Plan the move before replacing the current site.

A platform change can break useful URLs, remove content, or leave links pointing to the wrong address. Its impact depends on the site and the work involved.

Check the pages your customers use, the links that lead to them, and the tools that fetch them. The new site needs to preserve those connections.

Use this checklist to plan the URL map, test the new site, and monitor the launch.

Why Migrations Go Wrong: The Silent Decay Problem

Watch individual pages and query groups as well as total traffic. A stable headline number can hide a problem in one part of the site.

Check branded and non-branded queries separately, alongside the pages that receive visits and enquiries. Investigate unexpected changes rather than assuming the migration is the only cause.

Compare important landing pages before and after the move. Keep a record of redirects, traffic, and enquiries so you can investigate changes.

Include these checks in the project plan.

What to check before moving

Start with access, content, and performance.

Measure the actual experience. Google’s Core Web Vitals guidance still uses LCP 2.5 seconds, INP 200 milliseconds, and CLS 0.1 as the good-experience boundaries.

Keep useful content accessible. Google’s AI search guidance builds on ordinary SEO; special AI schema is not required.

Check mobile content. Google primarily uses the mobile version for indexing. Keep important text, metadata, images, and links available there. Mobile-first indexing guidance.

Phase 1: The Pre-Migration Audit

You cannot protect what you don’t understand. The entire migration hinges on what you document before touching a single line of code.

Baseline Your Current Performance

Export everything. This becomes your benchmark and your insurance policy:

Full URL inventory. Crawl your current site with Screaming Frog or Sitebulb. Every URL, every status code, every redirect chain already in place. For e-commerce sites, this means product pages, category pages, filter/faceted URLs, blog content, and static pages — each with its own migration logic.
Search Console snapshot. Export your top 500 keywords with clicks, impressions, CTR, and average position. Separate branded from non-branded traffic — branded queries often mask non-brand decay.
Backlink profile. Export known external links and include their destination pages in the redirect review.
Structured data audit. Record the existing markup. Keep relevant, supported types and update them to match the new pages.
Core Web Vitals baseline. Record field data and lab tests for important landing pages. Compare the same devices and conditions after the move.
AI visibility baseline. Record relevant referrals and any available search visibility reporting. Manual prompt checks can provide examples, but results vary and are not a complete measure of visibility.

Audit Your Current Technical Debt

Run a full technical audit and record every error, warning, and notice. Your new site should launch with close to zero pre-existing issues. Pass this list to your developers so they know exactly what not to carry over. A migration is your chance to fix legacy problems, not inherit them.

Phase 2: URL Mapping and Redirects

This is the technical core of a migration. Get it right and you preserve your authority. Get it wrong, and nothing else matters.

Map Every URL

Create a comprehensive redirect map — a table that assigns each old URL to its equivalent on the new platform. Categorize URLs by type, because each follows a different mapping logic:

Product pages
Category/collection pages
Filter and faceted navigation URLs
Blog/content pages
Static pages (about, contact, shipping, FAQ)
Image URLs

Understand Platform URL Differences

URL structures depend on platform settings and extensions. These are examples to compare with an export of your actual URLs:

Magento: /catalog/product/product-name.html
Shopify: /products/product-name
WooCommerce: /product/product-name/
PrestaShop: /en/category-name/product-name.html
Headless/custom: Whatever you define in your routing layer

Category names may appear in or disappear from product URLs depending on the platform. Trailing slashes, file extensions, case sensitivity — all of these create mismatches if not mapped explicitly.

Redirect Rules That Protect Your Authority

Every redirect should follow these non-negotiable rules:

Use permanent redirects for permanent moves. Google recommends server-side 301 or 308 responses. Use 302 or 307 for temporary changes. Redirect guidance.
Point directly to the final URL. Avoid unnecessary hops and loops. Test the destination.
Check destination responses. A replacement page should return 200 and contain the expected content.
Update internal links directly. Don’t rely on redirects for internal navigation. Point all internal links to the new URLs from day one.
Use relevant replacements. If no equivalent content exists, return 404 or 410 rather than sending unrelated pages to the homepage.

Where to Implement Redirects

The choice affects performance:

CDN or hosting layer: Use supported redirect rules and test the public URL. Check the provider’s limits before importing a large map.
Application level: Use the platform’s redirect manager or an appropriate plugin. Test its rules after deployment.
Web server level: Apache .htaccess or Nginx config blocks. Works, but harder to maintain at scale.

Phase 3: Preserving Technical SEO

Redirects are necessary but not sufficient. The new site must carry over every signal that search engines and AI systems use to understand your content.

What Must Transfer 1:1

Meta titles and descriptions. These don’t always transfer automatically between platforms. Verify each priority page manually.
Heading hierarchy. Preserve H1, H2, H3 structure. Don’t let a redesign flatten your content architecture.
Schema markup. Keep accurate, relevant structured data and update its URLs. Do not copy obsolete markup or claims the new page no longer supports.
Internal link architecture. Preserve link equity flow. Broken internal links create orphan pages and dilute PageRank.
Image alt text. Often lost in migration. Verify it carries over, especially for e-commerce product images.
Canonical tags. Ensure these point to the correct new URLs, not leftover old paths.
Hreflang tags. If you serve multiple languages or regions, each version needs separate redirect mapping and hreflang verification.

Performance: Match or Improve

Test important pages under the same conditions before and after the move. Use field data when available; a Lighthouse run is a diagnostic, not a guarantee of visitors’ experience.

Track loading, responsiveness, and layout shifts separately. Investigate regressions alongside content and indexing changes.

Phase 4: Access for search and browser agents

Include crawler access in the launch checks.

Check the search services your customers use and the agents that need to navigate the site.

How AI Engines Discover and Cite Your Content

Different services retrieve and process pages differently. Test the published HTML and the interactive page instead of assuming every crawler behaves like a browser.

Check for these practical problems:

Previously cited content is removed, merged, or moved without preserving its identity
Structured data that AI uses for context disappears
Your robots.txt or CDN (especially Cloudflare) begins blocking AI crawlers on the new site
Content shifts from server-side rendered to client-side JavaScript that AI crawlers can’t parse

The AI Crawler Checklist

Before launching your new site, verify:

Distinguish search from training. OpenAI uses OAI-SearchBot for search, GPTBot for training, and ChatGPT-User for user-requested visits. Check robots.txt and CDN rules for the access you intend. OpenAI crawler documentation.
Return important content in HTML. Static generation or server rendering makes it available without waiting for client scripts. Check the actual response.
Keep expandable content in the document. An accordion can work when its text is already in HTML. Avoid fetching essential content only after a click.
Keep crawl access and internal links working. Google does not use llms.txt for Search rankings or AI visibility. Check the official guidance before adding another file to maintain.
Keep markup accurate. Structured data should describe the visible content. It does not guarantee an AI citation.

Content Structure for AI Citation

Write sections that help a person find an answer. Use descriptive headings, explain unfamiliar terms, and provide evidence for factual claims.

Lead each section with a direct answer before providing context
Use clear H2/H3 headings that match how users phrase questions
Keep paragraphs focused and long enough to explain the point.
Link factual claims to sources the reader can check.
Use consistent names for your company, products, and people.

Measure AI Visibility After Migration

Post-launch, add these to your monitoring stack alongside traditional SEO metrics:

Citation tracking. Query AI platforms weekly with your target prompts. Are you still being cited? Has a competitor replaced you?
AI referral traffic. Review visits and enquiries from identifiable AI sources in your own analytics. Compare their usefulness rather than assuming a conversion rate.
AI crawler activity. Review response codes and verified crawler traffic in server logs. A missing user-agent entry alone does not prove blocking.

Phase 5: Pre-Launch Testing

Find problems before launch, not after.

Staging Environment Protocol

Set up a staging site that mirrors your production environment, but ensure search engines cannot index it. A staging site appearing in search results creates massive duplicate content issues.

Test all redirects in staging before going live
Crawl the staging site with Screaming Frog — look for broken links, missing meta data, orphan pages, and redirect chains
Protect staging with access controls. If using noindex, allow crawlers to fetch it; robots.txt blocking alone does not reliably prevent indexing.
Confirm XML sitemap generates correctly with all new URLs
Test Core Web Vitals against your benchmarks
Test supported rich-result markup with Google’s Rich Results Test.
Check for 404 errors across all page types
Test on actual mobile devices, not just responsive previews

Phase 6: Launch Day

When you flip the switch, every minute counts.

The Launch Checklist

Deploy all redirects simultaneously with the new site
Update internal links to point to new URLs
Submit the new XML sitemap to Google Search Console
Update your Google Analytics/GA4 tracking
If changing domains, update the property address in Search Console
Monitor server logs for errors in real time
Verify redirects are functioning live (test a sample of high-priority URLs)
Ensure robots.txt on the live site allows all intended crawlers — both traditional and AI

Phase 7: Post-Launch Monitoring

Monitor after launch for as long as changes are still settling. The schedule below is a starting point, not a guaranteed recovery period.

Week 1 (Critical)

Monitor Search Console daily for crawl errors
Verify redirect coverage — are all old URLs resolving to new ones?
Track and fix 404 errors immediately
Check indexation status of priority pages
Monitor organic traffic daily, with branded and non-branded segments separated

Weeks 2–8

Track ranking changes for target keyword clusters
Monitor traffic trends against your pre-migration baseline
Fix any broken internal or external links
Update XML sitemaps if new pages are added
Resubmit important pages for indexation if they’re slow to appear
Document the recovery timeline — this data is invaluable for future planning

Ongoing

Continue monitoring AI visibility monthly
Review content when facts or services change. Change modification dates only after substantive updates.
Keep redirect rules active for at least 12 months — removing them too early causes re-emergence of 404s as cached links expire

Common Migration Paths: Platform-Specific Considerations

PrestaShop → Shopify (or Medusa)

Compare the current product, category, and language URLs with the new platform’s routes. Export the real addresses instead of assuming a default pattern, then test the redirect map.

Magento → Shopify

Check product and category URLs, filter parameters, content pages, and the integrations the store relies on. Include these requirements in the platform choice and migration plan.

WordPress → Headless (Next.js, Webflow, Astro)

Check what the new stack returns before JavaScript runs and what the browser renders afterward. Keep important content and links accessible, and verify replacements for existing redirect, schema, and sitemap features.

Bitrix/1C → Modern Stack

Common in the CIS market. The main challenges are data migration from tightly coupled ERP integrations and preserving Cyrillic URL structures. Plan for extensive testing of character encoding in redirects.

Any Platform → Any Platform

Regardless of the specific migration path, the principles are universal: map every URL, redirect properly, preserve structured data, verify AI crawler access, and monitor aggressively post-launch.

The Migration Decision Matrix

Not every site needs a full rebuild. Before committing, honestly assess where you stand:

Migrate when: The platform prevents necessary work, has unresolved security problems, or is no longer supported. Compare the cost of repair with a move.

Redesign instead when: Your issues are primarily cosmetic or UX-related. A redesign on the same platform carries a fraction of the SEO risk.

Do both — carefully: If you must replatform and redesign, don’t do everything at once. Ideally, migrate first with minimal design changes, stabilize rankings, then iterate on design. Changing platform, URL structure, content, and design simultaneously multiplies every risk.

After the launch

Agree the URL map, test important journeys, and keep someone responsible for the launch checks.

After release, review errors, indexing, and enquiries. Fix problems you can reproduce and record what changed.

Planning a move or sorting out a difficult launch? Talk to us about your website. We can review the routes, content, and integrations that need to survive the change. See what is included in our website development service.

Written by Nikita Janockin. Reviewed and updated 10 September 2026.