Website migration SEO checklist: before, during, after

Change one thing at a time. If you also redesign, or change copy and structure, ship those in separate releases. You need clean attribution when traffic moves.

• Pick the move type: new domain, new paths, protocol to HTTPS, or platform only.
• Set the canonical host: www or non-www, then redirect the other.
• Pick a trailing slash policy for directories and pages, then stick to it.
• Freeze content and URL changes two weeks before the move.

You need a full list of live URLs. Build it from three sources so you catch everything.

• Crawl the site. Save a CSV of status codes, titles, canonicals and hreflang.
• Export all indexed and discovered URLs from Search Console. Include Page indexing and Performance lists.
• Download the current XML sitemaps and sitemap index.

Add any known legacy paths. Check logs if you have them. Include marketing URLs used in ads or emails.

Filter to 200 pages and important 3xx. Keep 404s that have backlinks. These will need specific mapping or a 410 judgement.

Map every old URL to the single new URL that replaces it. This is the core of a safe move.

• One to one. No fan-in to the home page, no chains, no loops.
• Cover HTTP to HTTPS, host changes, and path changes in one hop where possible.
• Keep query parameters that matter for content. Strip tracking params.
• For removals, use 410 for dead content, or 301 to the closest relevant page.

Store it in the repo as a two column table: old URL, new URL. Review it like code. For example, map /blog/how-to-price to /guides/pricing for a slug change, and /pricing to /pricing for a protocol or host change.

# redirect-map.csv
https://oldsite.com/ -> https://www.newsite.com/
http://oldsite.com/pricing -> https://www.newsite.com/pricing
https://oldsite.com/blog/how-to-price -> https://www.newsite.com/guides/pricing
https://oldsite.com/features/ -> https://www.newsite.com/product/features
https://oldsite.com/en/ -> https://www.newsite.com/en/

Implement at the edge or server. Use an nginx map, a CDN rule set, or framework redirects. Avoid 302s for permanent moves. Use 301s.

# nginx example
map $request_uri $redirect_target {
  /                      https://www.newsite.com/;
  /pricing               https://www.newsite.com/pricing;
  /blog/how-to-price     https://www.newsite.com/guides/pricing;
}
server {
  server_name oldsite.com www.oldsite.com;
  if ($redirect_target) { return 301 $redirect_target; }
  return 301 https://www.newsite.com$request_uri; # default one-hop host+https
}

// next.config.js example
module.exports = {
  trailingSlash: true, // or false, pick one
  redirects: async () => ([
    { source: '/pricing', destination: 'https://www.newsite.com/pricing', permanent: true },
    { source: '/blog/how-to-price', destination: 'https://www.newsite.com/guides/pricing', permanent: true },
  ])
}

• Update all internal links to the new absolute URLs. Do not rely on redirects for internal navigation.
• Set canonicals to the new URLs. Remove any canonical pointing to the old host.
• Update hreflang to the new URLs across all language and region variants.
• Update structured data URLs to the new host and paths.
• Generate a new XML sitemap with only the new URLs.
• Keep the old sitemap available at the old host. Do not delete it yet.
• If moving domain, verify both domain properties in Search Console. Also verify the HTTPS property if you are adding HTTPS.
• Pick www or non-www. Redirect the other host on every path with 301s. Set canonicals to the chosen host.
• Choose a trailing slash policy. /page and /page/ are different. Redirect one to the other consistently.
• For HTTPS moves, fix mixed content. Consider HSTS. Verify the HTTPS property in Search Console.

Next.js specific: use the Metadata API for titles and canonicals, set metadataBase and alternates.canonical. Generate app/sitemap.ts and app/robots.ts. Use next/image and next/font to keep performance steady. Set trailingSlash in next.config. The framework does not pick titles or canonicals for you, you must set them.

Test the map end to end. You want one hop to a 200 on the final URL. Chain and 404 errors will cost weeks of recovery.

1. 1

   Script the checks

   Write a script that requests every old URL. Follow redirects. Fail if the final status is not 200, or if hop count is over one.

2. 2

   Spot check key pages

   Test /, /pricing, /guides, and any page with backlinks. Try a few legacy URLs from the crawl.

3. 3

   Crawl staging

   Crawl the new site on staging. Check titles, canonicals, hreflang and internal links point to the new URLs.

4. 4

   Check the sitemap

   Open the new XML sitemap. Every URL should load as 200 on the new host, with the right trailing slash form.

# simple bash check using curl
while IFS=, read -r OLD NEW; do
  CODE=$(curl -Ls -o /dev/null -w "%{http_code}" "$OLD")
  FINAL=$(curl -Ls -o /dev/null -w "%{url_effective}" "$OLD")
  HOPS=$(curl -Ls -o /dev/null -w "%{num_redirects}" "$OLD")
  if [ "$FINAL" != "$NEW" ] || [ "$HOPS" -gt 1 ] || [ "$CODE" != "200" ]; then
    echo "Fail: $OLD -> $FINAL ($CODE) hops:$HOPS expected:$NEW"
  fi
done < redirect-map.csv

Follow an order. You want 301s live before Google crawls again, and Search Console aware soon after.

1. 1

   Deploy redirects

   Apply the redirect rules at the edge or server. Confirm one-hop 301s are active.

2. 2

   Deploy the new site

   Push the new host, paths and content. Check key pages render with the right canonicals and links.

3. 3

   Verify properties

   Confirm both old and new properties are verified in Search Console. Use a Domain property to cover www and non-www.

4. 4

   Submit sitemaps

   Submit the new sitemap on the new property. Keep the old sitemap live and listed on the old property.

5. 5

   Change of Address for domain moves

   If the domain changed, use Settings, Change of address on the old property. It requires both properties verified and 301s in place.

6. 6

   Spot check live traffic

   Open a browser and curl from a different network. Test the top 20 old URLs. Confirm one hop to the right new URL and a 200.

What a fixed launch looks like: https://oldsite.com/blog/how-to-price goes to https://www.newsite.com/guides/pricing in one 301, the new page has a canonical to itself, and the sitemap lists the new URL only.

• Keep the old domain’s redirects in place as long as possible, at least a year. Permanent is better if you can.
• Keep the old sitemap listed for a while so Google can recrawl old URLs and see the redirects.
• Fix internal links that still point to old URLs. Search your code and CMS. Update navigation, footers and templates.
• Update social profiles, app store listings, email footers and paid ads to the new domain.
• Resubmit disavow files if you manage them and you changed domain. Review any IP or firewall rules that could block Googlebot.

Expect fluctuation for some weeks. Branded queries often settle first. Long tail follows. A clean redirect map reduces the dip and the time to recover.

Set a light daily routine for the first 28 days. Then weekly. You want early signals, not noise from hourly checks.

• Search Console Performance: compare clicks and impressions by page. Watch new URLs pick up queries. Filter by brand and non-brand.
• Page indexing report: watch for “Page with redirect” on old URLs and “Indexed” on new URLs. Investigate “Soft 404” spikes immediately.
• Sitemaps report: confirm new sitemap is processed, and the old sitemap is being crawled.
• URL Inspection: test representative URLs on the new site if a page is not appearing.
• Core Web Vitals report: ensure the move did not regress LCP, CLS or INP. Field data uses a 28 day window, so changes take time.
• Server logs or CDN analytics: check Googlebot is hitting old URLs and being redirected once, then crawling the new ones.

Accept normal swings. Do not panic on single day dips. Act on patterns, such as soft 404s on a section, or a redirect chain found in logs.

• Redirecting everything to the home page. Google treats this as soft 404. Map to the closest page instead.
• Deleting the old sitemap. Keep it so Google recrawls old URLs and discovers the redirects.
• Leaving canonicals on the old host. Update them to the new URLs, or you deprecate your own pages.
• Redirect chains and mixed 301 and 302. Enforce one hop and 301 for permanent moves.
• Forgetting hreflang. All language versions must point to their new twins.
• Switching protocol, host and paths at once. You cannot isolate the cause of a drop.
• Not verifying properties. The Change of Address tool does not work without both properties verified.

Google treats www and non-www as different hosts. Pick one. Redirect the other with a 301 on every path. Set canonicals to the chosen host. Verify a Domain property to cover both.

Trailing slash: /page and /page/ are different URLs. The root / is the exception. Choose one, redirect the other, and keep internal links consistent. Next.js has a trailingSlash setting to help enforce this.

HTTP to HTTPS is a site move. 301 every URL to its HTTPS twin in one hop. Update canonicals, sitemaps, hreflang and internal links. Avoid mixed content. Consider HSTS, and the preload list for the strictest policy. Verify the HTTPS property in Search Console.

Google has treated HTTPS as a lightweight ranking signal since 2014. Browsers mark HTTP as not secure. Users notice. Move when you can support it without regressions.

A migration is a good time to enforce performance budgets. Slow or unstable pages can hide SEO wins during the 28 day Core Web Vitals window.

• Largest Contentful Paint good up to 2.5 s, poor above 4 s. Optimise hero images and font loading.
• Cumulative Layout Shift good up to 0.1, poor above 0.25. Fix late loading banners and dimensionless media.
• Interaction to Next Paint good up to 200 ms, poor above 500 ms. Cut long tasks, hydrate less, ship smaller bundles.
• Use PageSpeed Insights to see field data when available, plus a Lighthouse lab run. Expect score variance between runs.
• In Lighthouse, Total Blocking Time is 30 percent of performance score, LCP 25, CLS 25, FCP 10, Speed Index 10.

Next.js tips: prefer static rendering with dynamic opt-in. Use next/image for responsive images, and next/font to self host fonts. These reduce LCP and CLS regressions.