Site migrations are where many websites lose traffic. The new site looks better, but URLs changed without redirects, a Disallow: / came over from staging, or thousands of old pages suddenly return 404. With a plan, you can migrate with little or no lasting traffic loss, and often gain from a faster, cleaner site.

Types of migration (and their risk)

Migration URLs change? Risk
New server / hosting, same site No Low (watch speed, uptime, DNS)
HTTP → HTTPS Protocol only Low with 301s
Redesign, same CMS Sometimes Medium
New CMS or framework (e.g. WordPress → static site) Usually High
New domain All High
Merging sites, restructuring folders Many High

The more URLs change at once, the more carefully you need to map them. Avoid changing domain, CMS and structure in a single step if you can.

1. Inventory the old site

Collect every URL that matters:

  • a full crawl of the current site;
  • XML sitemaps;
  • Search Console Performance export (pages with clicks and impressions);
  • analytics landing pages;
  • backlink tools (pages with external links);
  • server access logs (URLs Googlebot actually crawls). See log file analysis for SEO.

Mark the pages with traffic or backlinks. These are the ones that must be redirected perfectly.

2. Map old URLs to new URLs

Build a spreadsheet: old URL → new URL → action.

Action When
Keep (same URL) Best option when possible
301 to the equivalent page URL changed, content still exists
301 to the closest relevant page Merged or consolidated content
410 (or 404) Content removed, no real equivalent

Don’t send everything to the home page: Google treats mass home page redirects as soft 404s. See 301 vs 302 redirects.

Archive URLs (old categories, tags, author pages, feeds) can usually be redirected by pattern to the closest section.

3. Prepare the new site on staging

  • Block staging from indexing with a password (and noindex), not just robots.txt.
  • Keep titles, headings, and main content of important pages at least as strong as before.
  • Correct canonicals (production host, not staging), hreflang, structured data, and internal links pointing to the new URLs. See canonical URLs.
  • New XML sitemap with the new URLs. See XML sitemaps.
  • Test speed: a migration is a good moment to improve TTFB. See web performance testing.

4. Implement and test redirects before launch

Write the redirects at the web server level (fast, independent of the application):

location = /old-post/ { return 301 /blog/old-post/; }
location = /old-post  { return 301 /blog/old-post/; }
location = /removed-post/ { return 410; }
location ^~ /category/ { return 301 /blog/; }

Generate the rules from your mapping spreadsheet with a script. For thousands of URLs, one exact location = per URL is easy to check and fast. Then test the full list:

while read -r old expected; do
  got=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "https://example.com$old")
  echo "$old -> $got (expected $expected)"
done < redirect-tests.txt

5. Launch day

  1. Lower DNS TTL a day or two in advance, if the server changes. See DNS propagation.
  2. Deploy the new site and the redirects together.
  3. Change robots.txt from staging (Disallow: /) to production. Check https://example.com/robots.txt immediately.
  4. Verify HTTPS, the canonical host (www or not), and HTTP → HTTPS redirects.
  5. Spot-check the top pages, and run the redirect test list against production.
  6. Submit the new sitemap in Search Console. See Google Search Console setup.
  7. For a domain change, use Search Console’s Change of Address tool, after the 301s are live.

6. Monitor for weeks

Watch Where
404s and 5xx on old URLs Server logs, Search Console Pages report
Indexing of new URLs Search Console (sitemap + Pages report)
Clicks and impressions by page Search Console Performance (compare with pre-launch)
Rankings for key terms Rank tracker
Crawl activity Search Console Crawl stats, access logs

Some fluctuation in the first few weeks is normal. A steady decline usually means missing redirects, blocked crawling, or weaker content on key pages.

Keep redirects in place

Keep 301s for at least a year, and ideally for good, especially for URLs with backlinks. Keep the old domain registered and redirecting after a domain change.

Common migration mistakes

  • Staging Disallow: / or noindex left on the live site.
  • No redirects, or everything redirected to the home page.
  • Redirect chains from earlier migrations (old → older → new). Point them straight to the final URL.
  • Canonicals or sitemaps still pointing to the staging host or old domain.
  • Removing well-ranking content during the redesign.
  • Forgetting images, PDFs and other files that had search traffic or links.

Quick checklist

Phase Must do
Before Inventory URLs, map old → new, build staging
Test Redirect list, canonicals, robots, speed
Launch Deploy + redirects together, fix robots.txt, submit sitemap
After Monitor 404s, indexing, traffic; keep redirects

Related: technical SEO on your own server and the robots.txt guide.

  • SEO
  • Migration
  • Web Development