Site migrations: a zero-drama checklist

Video lecture

Site migrations: a zero-drama checklist

13 chapters · about 8 min · full transcript

Coming soon

Chapter 1 of 13

Site migrations

What counts as a migration
Four phases, zero drama
Redirect maps you can prove

The narrated lecture is in production

Every chapter is scripted and ready. Browse the chapters and read the full transcript now — the video will appear here when it’s published.

Chapters

Transcript of the narration, chapter by chapter.

0:00 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.

0:30 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.

1:06 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.

1:36 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.

2:11 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.

2:48 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.

3:26 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.

4:02 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.

4:38 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.

5:17 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.

5:54 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.

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

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

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)

Define scope and owners. Who signs off redirects, who deploys, who monitors?
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.
Inventory URLs from all sources: crawl, sitemaps, Search Console, analytics, backlinks, logs. Crawls alone miss old URLs that still receive links.
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.

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

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

Deploy redirects together with the new site.
Verify robots.txt, a sample of meta robots and canonicals on production immediately.
Crawl the old URL list: confirm 301s resolve in one hop to 200 pages.
Domain moves: verify both properties in Search Console and use the Change of Address tool (for domain-level moves).
Submit new sitemaps. Keeping a sitemap of old URLs available for a short time can help Google discover the redirects.
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

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

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.

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

Enrol for free to save your progress

Reading is always free. Enrol to keep your place, take the final assessment and earn a verifiable certificate.

Site migrations: a zero-drama checklist