---
title: "Site migrations: a zero-drama checklist"
description: "What counts as a migration Any change that alters URLs, hosts, templates or rendering at scale: domain change , HTTP to HTTPS , URL restructure…"
url: https://optimizeall.com/learn/technical-seo-mastery/site-migrations-checklist
updated: 2026-10-05
---

Technical SEO Mastery · Migrations, auditing workflow and monitoring · lesson 16 of 18 · 16 min

# Site migrations: a zero-drama checklist

## What counts as a migration

Any change that alters URLs, hosts, templates or rendering at scale: **domain change**, **HTTP to HTTPS**, **URL restructure**, **platform/CMS change** (e.g. WordPress to Shopify, or a move to a headless front end), **merging sites**, and **major redesigns**. Several at once multiplies risk — if you can, separate a domain move from a replatform.

Even perfect migrations can cause temporary fluctuation while Google recrawls and reprocesses. Google has said a medium-sized site can take a few weeks for most pages to move, and larger sites longer. Set expectations in writing before you start.

## Phase 1: Planning (weeks before)

1. **Define scope and owners.** Who signs off redirects, who deploys, who monitors?
2. **Benchmark everything:** full crawl of the old site; Search Console exports (performance by page and query, Page indexing counts); analytics landing-page traffic and conversions; rank tracking for priority queries; backlink list of top-linked URLs; log sample.
3. **Inventory URLs** from all sources: crawl, sitemaps, Search Console, analytics, backlinks, logs. Crawls alone miss old URLs that still receive links.
4. **Build the redirect map** — old URL to most relevant new URL, one hop, 301/308. Prioritise by traffic, links and revenue. Pages with no equivalent get 404/410 intentionally.

```text
old_url,new_url,type,priority,notes
/services/seo-audit.html,/services/technical-seo-audit/,301,high,top converter
/blog/2019/05/gbp-tips,/guides/google-business-profile/,301,high,merged into guide
/careers/intern-2018,,410,low,no equivalent
```

5. **Plan content and template parity.** Titles, meta descriptions, headings, body content, internal links, structured data, hreflang, canonicals, image alt text — carry them over or consciously improve them.
6. **Choose timing** away from peak seasons (Ramadan and Eid campaigns for Gulf retailers, Black Friday, Diwali, back-to-school).

## Phase 2: Staging and pre-launch QA

- Staging protected by authentication (not only robots.txt).
- Crawl staging and compare against the benchmark: missing pages, title changes, lost internal links, structured data errors, canonicals pointing at staging hosts.
- **Test the redirect map** against staging with a list crawl: every old URL should return one 301 to a 200 destination.
- Check robots.txt and meta robots for the **production** configuration — confirm `Disallow: /` and staging `noindex` will not ship.
- Check rendering and Core Web Vitals of new templates.
- Prepare new XML sitemaps.

## Phase 3: Launch day

1. Deploy redirects together with the new site.
2. Verify robots.txt, a sample of meta robots and canonicals on production immediately.
3. Crawl the old URL list: confirm 301s resolve in one hop to 200 pages.
4. **Domain moves:** verify both properties in Search Console and use the **Change of Address** tool (for domain-level moves).
5. Submit new sitemaps. Keeping a sitemap of old URLs available for a short time can help Google discover the redirects.
6. Update external profiles you control: Google Business Profile website link, social profiles, directories, ad destination URLs, email templates.

## Phase 4: Post-launch monitoring (first 4–12 weeks)

| Check | Frequency | Where |
|---|---|---|
| 404s and 5xx on old and new URLs | Daily, first two weeks | Logs, crawler, Search Console |
| Googlebot crawl of new URLs | Daily | Logs, Crawl stats |
| Indexing of new URLs vs old | Weekly | Page indexing, URL Inspection samples |
| Traffic and conversions by page group | Daily then weekly | Analytics vs benchmark |
| Rankings for priority queries | Weekly | Rank tracker |
| Structured data and CWV | Weekly | Enhancement and CWV reports |

Keep redirects in place for **at least a year** (Google's guidance), and ideally indefinitely. Keep the old domain registered.

## Worked example: platform change

A Lahore-based retailer moves from a custom PHP store to a hosted e-commerce platform. The platform forces `/products/` and `/collections/` URL patterns. The team exports every legacy URL (including those only found in backlinks and logs), maps products by SKU and categories by name, uses the platform's redirect manager for one-hop 301s, recreates custom title templates, and moves blog content with matching slugs where possible. After launch, logs reveal thousands of hits to old image URLs used in Google Images; they add image redirects too — a commonly forgotten item.

## Rollback criteria

Agree in advance what triggers a rollback or an emergency fix: for example, robots.txt blocking the site, redirects failing for a large share of legacy URLs, or checkout broken. Without predefined criteria, teams argue while visibility drops.

## Hands-on: validate a redirect map before and after launch

```python
# pip install requests pandas
import pandas as pd, requests

m = pd.read_csv("redirect_map.csv")          # columns: old_url,new_url,type,priority
BASE_OLD = "https://staging.example.com"      # switch to production on launch day
results = []
for row in m.itertuples():
    url = BASE_OLD + row.old_url
    try:
        r = requests.get(url, allow_redirects=True, timeout=20)
    except requests.RequestException as e:
        results.append((row.old_url, "ERROR", str(e)[:80], 0, "")); continue
    hops = [h.status_code for h in r.history]
    final_path = requests.utils.urlparse(r.url).path
    expected = row.new_url if isinstance(row.new_url, str) else None
    if row.type in (410, "410"):
        ok = r.status_code == 410 and not hops
    else:
        ok = len(hops) == 1 and hops[0] in (301, 308) and r.status_code == 200 and final_path == expected
    results.append((row.old_url, r.status_code, final_path, len(hops), "OK" if ok else "FAIL"))

out = pd.DataFrame(results, columns=["old", "final_status", "final_path", "hops", "result"])
print(out.result.value_counts())
out[out.result != "OK"].to_csv("redirect_failures.csv", index=False)
```

Run it on staging before launch (with authentication if needed), again on production within the first hour, and daily for the first two weeks on the high-priority tier.

## Worked example 2: a UAE brand merges two domains

A UAE beauty brand (illustrative) merges its separate Arabic domain into `/ar-ae/` on its main site. The plan separates the domain move from any redesign, maps every Arabic URL one-to-one, keeps hreflang reciprocal between `/en-ae/` and `/ar-ae/` from day one, uses Change of Address in Search Console, and updates Google Business Profile and social links. Post-launch monitoring by page group shows Arabic pages recrawled and indexed at the new URLs over the following weeks, with the old domain's redirects kept indefinitely.

## Common mistakes

- Redirecting everything to the home page.
- Changing URLs, content and design at once without benchmarks, so nobody can diagnose drops.
- Removing redirects after a few months "because traffic moved".
- Forgetting image, PDF and hreflang URLs.

## Video lecture: Site migrations: a zero-drama checklist

Lecture coming soon · 13 chapters · about 8 minutes. Read the full transcript below.

1. Site migrations
2. What counts
3. Phase 1: plan
4. The redirect map + parity + timing
5. Phase 2: staging QA
6. Hands-on: redirect map validator
7. Phase 3: launch day
8. Phase 4: monitor 4–12 weeks
9. Example 1: Lahore replatform (illustrative)
10. Example 2: merging an Arabic domain (illustrative)
11. Watch me do it: launch-day redirects
12. Rollback criteria and mistakes
13. Recap and try this now

## Lecture transcript

### Site migrations

A site migration is the single riskiest thing most websites ever do in search. Done well, visibility dips briefly and recovers. Done badly, years of rankings can disappear in a week. In this lecture you'll learn what counts as a migration, a four-phase plan from benchmarking to post-launch monitoring, how to build and test a redirect map with a script, and how to set rollback criteria before you need them.

### What counts

What counts as a migration? Any change that alters URLs, hosts, templates or rendering at scale. A domain change. HTTP to HTTPS. A URL restructure. A platform or CMS change, like WordPress to Shopify or a move to a headless front end. Merging sites. And major redesigns. Doing several at once multiplies risk, so if you can, separate a domain move from a replatform. And set expectations in writing: even perfect migrations can fluctuate while Google recrawls, and larger sites take longer.

### Phase 1: plan

Phase one: planning, weeks before. Define scope and owners: who signs off redirects, who deploys, who monitors. Benchmark everything: a full crawl, Search Console exports by page and query, indexing counts, analytics landing pages and conversions, rank tracking, top-linked URLs and a log sample. Then inventory old URLs from every source: crawl, sitemaps, Search Console, analytics, backlinks and logs. Crawls alone miss old URLs that still receive links.

### The redirect map + parity + timing

Build the redirect map. Old URL to the most relevant new URL, in one hop, with a three-oh-one or three-oh-eight. Prioritise by traffic, links and revenue. Pages with no equivalent get a deliberate four-oh-four or four-ten. Plan content and template parity: titles, meta descriptions, headings, body content, internal links, structured data, hreflang, canonicals and alt text, carried over or consciously improved. And choose timing away from peak seasons, like Ramadan and Eid campaigns for Gulf retailers, Black Friday, Diwali or back-to-school.

### Phase 2: staging QA

Phase two: staging and pre-launch QA. Protect staging with authentication, not just robots.txt. Crawl staging and compare against the benchmark: missing pages, title changes, lost internal links, structured data errors, canonicals pointing at staging hosts. Test the redirect map against staging with a list crawl or the script in the lesson text. Check that the production robots.txt and meta robots won't ship a Disallow slash or a staging noindex. Check rendering and Core Web Vitals of new templates. And prepare the new XML sitemaps.

### Hands-on: redirect map validator

Hands-on. The script in the lesson text reads your redirect map and requests each old URL. For normal rows it passes only if there's exactly one redirect hop, a three-oh-one or three-oh-eight, ending at a two-hundred page with the expected path. For rows marked four-ten, it passes only if the old URL returns four-ten directly. It prints pass and fail counts and writes failures to a CSV. Run it on staging before launch, on production within the first hour, and daily for two weeks on the high-priority tier.

### Phase 3: launch day

Phase three: launch day. Deploy redirects together with the new site. Immediately verify robots.txt, and a sample of meta robots and canonicals, on production. Crawl the old URL list and confirm one-hop redirects to two-hundred pages. For domain moves, verify both properties in Search Console and use the Change of Address tool. Submit new sitemaps; keeping an old-URL sitemap available briefly can help Google discover the redirects. And update external profiles you control: Business Profile, social profiles, directories, ad destinations and email templates.

### Phase 4: monitor 4–12 weeks

Phase four: post-launch monitoring, for four to twelve weeks. Daily for the first two weeks: four-oh-fours and five hundreds on old and new URLs, and Googlebot crawling of new URLs in logs and Crawl stats. Weekly: indexing of new versus old URLs, traffic and conversions by page group against the benchmark, rankings for priority queries, and structured data and Core Web Vitals reports. Keep redirects for at least a year, as Google advises, and ideally indefinitely. And keep the old domain registered.

### Example 1: Lahore replatform (illustrative)

Worked example one, with illustrative details. A Lahore retailer moves from a custom PHP store to a hosted e-commerce platform that forces its own product and collection URL patterns. The team exports every legacy URL, including those found only in backlinks and logs, maps products by SKU and categories by name, uses the platform's redirect manager for one-hop redirects, and recreates custom title templates. After launch, logs reveal thousands of hits to old image URLs used in Google Images, so they add image redirects too. That's a commonly forgotten item.

### Example 2: merging an Arabic domain (illustrative)

Worked example two, also illustrative. A UAE beauty brand merges its separate Arabic domain into an ar-a e folder on its main site. The plan separates the domain move from any redesign, maps every Arabic URL one-to-one, keeps hreflang reciprocal between English and Arabic from day one, uses Change of Address, and updates the Business Profile and social links. Monitoring by page group shows Arabic pages recrawled and indexed at the new URLs over the following weeks, and the old domain's redirects stay in place indefinitely.

### Watch me do it: launch-day redirects

Watch me do it. I'll validate a redirect map on launch day. Step one: an hour before launch, I run the validator against staging with the full map of five thousand five hundred rows. Result: five thousand four hundred and twelve OK, eighty-eight fail. Step two: I open the failures. Sixty are two-hop redirects, because old URLs point to an interim slug that itself redirects. Twenty-five end at a two hundred page, but not the expected path; the platform lowercased them. Three return four-oh-four; typos in the map. Step three: the developer fixes the interim slugs in the redirect manager and corrects the three typos. I update the expected paths for the lowercase cases, because the destination is right. Step four: launch. Within the first hour, I switch the base URL to production and run the validator again. All high-priority rows pass. Step five: I check robots.txt on production, a sample of meta robots and canonicals, and submit the new sitemap. For this domain move, I also complete Change of Address in Search Console. Step six: I schedule the validator daily for two weeks on the priority tier, and I watch logs for four-oh-fours on old URLs.

### Rollback criteria and mistakes

Rollback criteria and common mistakes. Agree in advance what triggers a rollback or an emergency fix: for example, robots.txt blocking the site, redirects failing for a large share of legacy URLs, or checkout broken. Without predefined criteria, teams argue while visibility drops. Common mistakes: redirecting everything to the home page, changing URLs, content and design at once without benchmarks, removing redirects after a few months, and forgetting image, PDF and hreflang URLs.

### Recap and try this now

Recap. Plan, benchmark and inventory. Build a one-hop redirect map and prove it with a script on staging and production. Launch with verification, Change of Address and sitemaps. Monitor daily, then weekly, and keep redirects for at least a year. Try this now. Take your last migration's redirect map, or your current URL list, and run the validator on the top two hundred URLs by traffic. Every fail is a live problem.

## Key takeaways

- Benchmark crawl, Search Console, analytics, rankings and backlinks before any migration.
- Build a one-hop 301 redirect map from every known old URL, prioritised by traffic, links and revenue.
- QA staging and redirects before launch, and verify production robots.txt and directives immediately after.
- Use Change of Address for domain moves, keep redirects at least a year, and monitor for weeks.

## Try it

Draft a migration plan outline for a site you know: benchmarks, URL sources, redirect map columns, QA steps, launch checks and rollback criteria.

- [Previous: Mobile-first indexing, HTTPS and security headers](https://optimizeall.com/learn/technical-seo-mastery/mobile-first-https-and-security-headers)
- [Next: Auditing workflow, tools and Search Console monitoring](https://optimizeall.com/learn/technical-seo-mastery/auditing-workflow-and-search-console-monitoring)
- [All lessons of Technical SEO Mastery](https://optimizeall.com/learn/technical-seo-mastery)