# Website migration SEO checklist: before, during, after

You can ship a migration without losing search. Follow this checklist before, during and after the switch. It fits a SaaS, a store or a content site you run yourself.

Updated 2026-09-14 · Source: https://porteur.ai/guides/website-migration-seo-checklist

## Decide scope and sequence

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.

> One change at a time. Do not move domain, redesign and restructure in one release.

## Crawl and export the current site

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.

## Build the redirect map

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
}

```

> Port numbers in code samples are typical, not measured.

```
// 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 },
  ])
}

```

## Prepare the new site

- 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 redirects and pages before launch

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. **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. **Spot check key pages** Test /, /pricing, /guides, and any page with backlinks. Try a few legacy URLs from the crawl.
3. **Crawl staging** Crawl the new site on staging. Check titles, canonicals, hreflang and internal links point to the new URLs.
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

```

## Launch sequence on switch day

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

1. **Deploy redirects** Apply the redirect rules at the edge or server. Confirm one-hop 301s are active.
2. **Deploy the new site** Push the new host, paths and content. Check key pages render with the right canonicals and links.
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. **Submit sitemaps** Submit the new sitemap on the new property. Keep the old sitemap live and listed on the old property.
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. **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.

## After the switch: keep signals flowing

- 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.

## Watch the data and triage issues

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.

## Common mistakes that cost months

- 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.

## Host, slash and HTTPS rules

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.

## Performance and quality guardrails

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.

## Questions

### How to migrate a website without losing SEO?

Ship a one to one 301 redirect map, update canonicals, hreflang and sitemaps to the new URLs, and keep the old sitemap and redirects live. Tell Google about domain moves with the Change of Address tool. Test for one hop to a 200 before launch, then watch Search Console for soft 404s and chains.

### What is SEO migration?

It is the work to preserve organic search signals during a change to URLs, host, protocol, structure or platform. It covers mapping old URLs to new ones, updating signals on page and in sitemaps, and coordinating the switch with Search Console. The goal is continuity, then growth.

### What fluctuation is normal after a move?

Expect some weeks of swings as Google recrawls old URLs, follows 301s and reassigns signals. Branded queries usually stabilise first. Watch for patterns that show a bug, such as a section-wide soft 404 spike or many two hop redirects.

### Do I need the Change of Address tool?

Use it only for domain level moves. It needs both properties verified and 301s in place. It does not apply to path only changes or HTTPS only. You still need a complete redirect map either way.

### How long should I keep redirects?

Keep them as long as you can, at least a year. Google’s guidance prefers permanent retention when possible. Many users and links will hit old URLs for a long time.

### Can I change to HTTPS and www at the same time?

You can, but you take on more risk. If you can, change protocol first, then host, or vice versa. If you must do both, make sure every old URL reaches the final HTTPS chosen host in one hop, and update all signals in one release.

## Read next

- [Build a redirect map: one old URL, one new URL, tested](https://porteur.ai/guides/redirect-map): A practical redirect map: where to find old URLs, how to match them, store the table, apply 301s, and test every row for one hop and a 200.
- [Changing your domain without losing search traffic](https://porteur.ai/guides/domain-change-seo): Change domains without tanking your rankings. Map 301s one to one, use Change of Address, update canonicals and hreflang, and keep redirects for a year.
- [Moving from HTTP to HTTPS: the checklist that keeps rankings](https://porteur.ai/guides/http-to-https-migration): Move from HTTP to HTTPS without losing rankings. Use one-hop 301s, update canonicals and sitemaps, fix mixed content, and verify the HTTPS property.
- [www or non-www: pick one, redirect the other](https://porteur.ai/guides/www-vs-non-www): Pick www or non-www, there is no SEO gain either way. 301 redirect every path to the chosen host, set canonicals, and verify a Domain property.
- [Trailing slash: two URLs for one page unless you decide](https://porteur.ai/guides/trailing-slash-seo): Google sees /page and /page/ as different. Pick one form, redirect the other, and keep links and your sitemap consistent. Here is how to do it.
- [The Sitemaps report: what Success, Has errors and Couldn’t fetch mean](https://porteur.ai/guides/search-console-sitemaps-report): How to submit your sitemap URL, read Success, Has errors and Couldn’t fetch, and fix invalid XML, 404s, cross‑host URLs and missing child sitemaps.

Want a second set of eyes before you flip the switch? Run your site through Porteur’s free check from a URL and see three migration findings in about thirty seconds. Free check: https://porteur.ai/