Migrating a site without discarding its rankings

A migration is any change to what lives at which URL — a redesign, a platform move, a domain change, an HTTPS move, or a restructure of the URL hierarchy. Each carries the same risk, and the risk is almost entirely manageable with work done before launch rather than after.

Inventory every URL that exists, not every URL you remember

The single biggest cause of migration loss is a URL that was earning traffic and that nobody knew about. Your CMS's page list is not a complete inventory — it omits everything created outside it, everything retired but still linked, and everything search engines discovered by other means.

• Crawl the live site to depth, following every internal link
• Export every URL with impressions from Search Console over the last 12–16 months, not just recent traffic
• Export server log entries to find URLs that receive crawler or referral traffic but no internal links
• Export the existing sitemaps, including old ones still referenced in robots.txt
• Pull top linked pages from any backlink tool available — an externally linked URL carries equity you must not drop

Deduplicate the union of those sources. That list — not the CMS — is what must be mapped.

Map each URL to its closest equivalent

Every inventoried URL needs a decision, recorded explicitly. There are only four legitimate outcomes, and "we'll sort it after launch" is not one of them.

Redirects that actually preserve equity

The redirect itself is simple. The failure modes are in the details, and each one leaks a proportion of the signal you were trying to carry across.

1. 01Use 301 (permanent), not 302. A 302 signals the move is temporary and consolidation is slower and less complete.
2. 02Redirect in one hop. A chain of two or three redirects loses signal and wastes crawl; map old URLs directly to final destinations.
3. 03Never redirect into a redirect. If B moves to C after A already pointed at B, update A to point at C.
4. 04Preserve query strings where they are meaningful, and strip them where they are not.
5. 05Redirect at the server or CDN edge, not in client JavaScript — a JavaScript redirect is not a redirect as far as a crawler is concerned.

# Test the whole redirect map before launch, against staging.
# Any status other than 301, or more than one hop, is a defect.

while IFS=, read -r old new; do
  result=$(curl -s -o /dev/null -w "%{http_code} %{redirect_url} %{num_redirects}" \
           -H "Host: example.com" "https://staging.example.com$old")
  echo "$old -> $result (expected 301 $new 1)"
done < redirect-map.csv

# Then verify the destination itself returns 200 and is not
# itself canonicalised somewhere else.

Pre-launch parity checks

Before the switch, verify that the new site preserves what the old one signalled. These are quick to check and expensive to discover afterwards.

Launch sequence

1. 01Launch at a low-traffic time, with the redirect map already live at the edge.
2. 02Submit the new sitemap in Search Console immediately; keep the old sitemap accessible so old URLs are recrawled and their redirects discovered.
3. 03For a domain change, use the Change of Address tool in Search Console — it materially speeds consolidation.
4. 04Keep redirects in place for at least a year. They are not a transitional measure; external links persist indefinitely.
5. 05Do not also change content, structure and design in the same release if you can avoid it — when something drops, you want one variable to investigate.

Monitoring: the first two weeks decide the outcome

Migration damage is recoverable if caught in days. The same damage found a quarter later has usually compounded, and the diagnostic trail has gone cold.

• Index coverage daily — watch for a rise in "not found" or "excluded by noindex"
• Impressions and clicks by page, compared against the pre-launch baseline you recorded
• Server logs for 404s receiving crawler traffic — each one is an unmapped URL
• Crawl stats for a fall in crawl rate or a rise in response time
• Core Web Vitals field data, which lags by weeks but reveals regressions a lab test missed

Record the baseline before launch. Without it, every post-launch fluctuation becomes an argument about whether the migration caused it, and nobody can settle the question.

What to expect even when it goes well

A well-executed migration still typically shows a temporary dip while engines recrawl and reconsolidate — commonly a few weeks, longer for large sites. That is normal. What is not normal is a decline that continues past a month, or one concentrated on a single template, which indicates a specific defect rather than reconsolidation.