Key takeaways
- **Website Migration Strategy:** A strong migration strategy keeps the move boring for search engines and customers. The page map, redirect rules, content parity, analytics, and launch checks all need to line up before the switch.
A website migration checklist works when it runs in sequence: benchmark the old site, map every URL, stage redirects, then verify after launch. Skip the order and you lose the diagnostic trail that tells you what broke. Most traffic drops after a migration trace back to two things, missing redirects and changed URLs, both of which this list catches before launch.
Migrations move a site to a new domain, platform, structure, or design. Each type carries its own failure points, and the safest path treats the move as a controlled project rather than a launch-night scramble. If you want the work handled end to end, our website migration service team runs this exact sequence.
The sequence matters because each phase depends on the one before it. You cannot prove a migration held its rankings without the baseline from Phase 1. You cannot build clean redirects without the URL map from Phase 2. You cannot verify redirects on launch day without having staged them in Phase 3. Teams that skip ahead, usually to save time before a deadline, end up doing the skipped work anyway, but under pressure and after traffic has already dropped. Run the phases in order and the project stays diagnosable at every step.
Phase 1: Benchmark before you touch anything
You cannot prove a migration succeeded without a baseline. Capture these while the old site is live and stable:
- Full URL inventory from a crawl (Screaming Frog or Sitebulb) plus the XML sitemap
- Organic sessions and conversions for the last 90 days from Google Analytics 4
- Top 200 landing pages by organic traffic
- Top 500 ranking keywords with current positions
- Google Search Console coverage, impressions, and average position for the last 16 months
- Backlink profile export listing pages that hold the most referring domains
Export everything to dated files. If rankings move after launch, this is the record you compare against.
Date every export in the filename and store the set together in one folder. Six weeks after launch, when a stakeholder asks whether organic traffic is down or just noisy, this folder is the answer. Without it, you are arguing from memory against a real revenue question. Pull the Search Console data for the full 16 months the interface allows, because a single month hides seasonality; a site that always dips in July should not be misread as a migration failure. The backlink export matters most of all, because the pages holding the most referring domains are the ones a missing redirect hurts worst.
Phase 2: Build the URL map
The URL map is the spine of the migration. Every old URL needs a decision: keep, redirect, or retire. One row per URL.
- List every indexable old URL in a spreadsheet
- Assign the matching new URL for each one
- Flag pages with backlinks so they get one-to-one redirects, never a redirect to the homepage
- Mark low-value URLs (expired products, thin tag pages) for retirement with a clear plan
- Confirm no new URL appears twice unless intended
A one-to-one map preserves the link equity you benchmarked in Phase 1. Redirecting old pages to the homepage tells search engines the content is gone, and rankings follow.
Build the map as a spreadsheet with columns for the old URL, the new URL, the decision, whether the page has backlinks, and its organic traffic. Sort by traffic and backlinks so the high-value pages sit at the top where they get the most attention. The retire decision needs the most discipline, because it is tempting to retire anything that looks thin. Check the traffic and backlink columns first; a tag page you assume is worthless may hold a link from a news site that still sends visitors. When a page genuinely has no traffic, no backlinks, and no indexed status, retiring it without a redirect is fine, but write down why so a future audit does not flag it as a mistake.
Phase 3: Prepare the staging environment
- Block staging from indexing with HTTP authentication, not just robots.txt
- Rebuild internal links to point at final URLs, not redirect targets
- Carry over title tags, meta descriptions, and H1s unless you are deliberately rewriting them
- Migrate structured data markup and verify it with the Rich Results Test
- Confirm canonical tags point to the correct final URLs
- Match or improve page speed; test Core Web Vitals on staging
HTTP authentication on staging is not optional. A robots.txt disallow is a request that some crawlers honor and some ignore, and a staging site that gets indexed creates duplicate content that competes with production. Password-protecting the whole staging environment removes the risk entirely. On internal links, point them at the final destination URL, not the old URL that will 301. Every internal link that fires through a redirect adds a hop, wastes crawl budget, and slows the page. Fixing them on staging is cheap; fixing thousands of them on a live site after launch is not.
Phase 4: The migration checklist table
Run this table on launch day. Check each item before moving to the next column.
| Step | Action | Owner | Verify |
|---|---|---|---|
| 1 | Deploy 301 redirect map | Dev | Spot-check 25 redirects return 301 |
| 2 | Remove staging index block | Dev | Confirm pages return 200 |
| 3 | Update robots.txt for production | SEO | Fetch robots.txt, confirm crawl allowed |
| 4 | Submit new XML sitemap in Search Console | SEO | Sitemap status reads Success |
| 5 | Verify canonical tags on live pages | SEO | 20 pages self-canonical correctly |
| 6 | Check analytics tracking fires | Analytics | Real-time report shows sessions |
| 7 | Test top 50 pages for 200 status | SEO | Zero unexpected 404s |
| 8 | Confirm HTTPS and redirect from HTTP | Dev | HTTP forces to HTTPS |
Phase 5: Redirects done right
Redirects decide whether ranking signals transfer. The rules:
- Use 301 (permanent) redirects for every moved page, not 302
- Point each old URL to its closest new equivalent, one to one
- Avoid chains: old URL to final URL in a single hop, never A to B to C
- Keep the redirect map live for at least 12 months; backlinks and bookmarks take time to update
- Test the full map with a crawler before launch, then again the hour after launch
A redirect chain leaks a portion of link equity at each hop and slows crawlers. If you inherit chains, collapse them so every source resolves in one step.
The 301 versus 302 distinction is not pedantic. A 301 tells search engines the move is permanent and passes ranking signals to the new URL. A 302 says the move is temporary, so signals stay with the old URL that no longer exists. Using 302 by accident, which happens when a developer picks the default redirect type without thinking, is a quiet way to lose rankings that looks correct in a browser because the page still loads. Verify the status code explicitly, do not trust that the redirect works just because the destination appears.
Phase 6: Launch-hour verification
The first 60 minutes catch most disasters:
- Crawl the live site and compare the URL count against your inventory
- Pull the redirect map through a crawler and confirm every source returns 301 to the right target
- Check that the production robots.txt does not block the whole site
- Confirm the new sitemap submitted cleanly in Search Console
- Load the top 10 landing pages and confirm content, canonicals, and tracking
The single most damaging launch-day error is a robots.txt or a site-wide noindex tag carried over from staging. It blocks every page from being crawled or indexed, and if it sits unnoticed for a week, the whole domain can drop out of search. Check it first, before anything else, and check it by fetching the live robots.txt directly rather than assuming the deploy handled it. The crawl comparison against your Phase 1 inventory is the other high-value check; a live URL count far below your inventory means pages did not deploy or are returning errors, and the crawl surfaces exactly which ones.
Phase 7: The first 30 days
- Monitor Search Console coverage daily for a spike in 404s or excluded pages
- Watch organic sessions against the 90-day baseline; a 10 to 15 percent dip for two to four weeks is common and usually recovers
- Fix any 404 with traffic or backlinks by adding a redirect the same day
- Re-submit the sitemap if indexing stalls
- Track your top 500 keywords weekly and note which pages recover first
If traffic has not stabilized after four weeks, return to your URL map and redirect audit. The cause is almost always a mapping gap.
Assign an owner to every launch step
The table in Phase 4 lists owners for a reason: a migration fails on the seams between people as often as on the technical work. Name a person, not a team, for each critical step.
| Step | Owner confirms |
|---|---|
| Redirect map deployed | Every source returns 301 to the right target |
| Staging index block removed | Live pages return 200 and are crawlable |
| Production robots.txt | The file does not block the whole site |
| Sitemap submitted | Search Console reads the sitemap as Success |
| Analytics tracking | Real-time report shows live sessions |
The two failures that recur are a staging crawl block left on after launch, which de-indexes the whole domain without anyone noticing, and a robots.txt that blocks the site. Both are on the list above, and both are caught in the launch hour only if a named person owns the check rather than assuming someone else ran it.
A rollback plan before you flip
Decide in advance what would send you back, and how, so you are not debating during an outage.
- Keep the old site reachable for at least 48 hours where the architecture allows.
- Define the trigger: checkout failing, a 404 rate that spikes, or top pages dropping out of the index.
- Know the mechanism: pointing DNS back or re-enabling the old server, and who executes it.
- Time-box the decision so a fault does not turn into an hour of debate under pressure.
A rollback costs only the overlap window. The migrations that go badly are the ones where the old site was torn down at launch, so a fault at hour two had no path back except a rushed forward fix while traffic was already dropping.
Reading the first 30 days
The post-launch numbers only mean something against the Phase 1 benchmark, so read them as a trend, not a daily verdict.
- A 10 to 15 percent dip in the first two weeks is normal reindexing, not a failure.
- Impressions on new URLs should climb while 404s fall toward zero.
- The one signal that means a real problem is a 404 spike that does not fall.
- Compare rankings weekly against the pre-move baseline, not day to day, so noise does not drive panic.
If the trend is recovery, hold steady and let reindexing finish, usually by weeks six to eight. If 404s stay high or a specific page never recovers, that is a mapping gap to trace, and the benchmark tells you exactly which pages to check.
Related terms
You may see this topic described with related searches like cms migration checklist, how long to do website migration, migrate website checklist, site migration checklist, and web migration. Those phrases are useful when they clarify what the reader needs next, but they should still point back to one clear plan.
Related searches such as website migration plan, website migration process, website migration steps, website migrations, and website transition plan are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Related searches such as what is site migration and what is website migration are useful when they clarify what the reader needs next. They should support the same plan rather than pulling the page in several directions at once.
Frequently asked questions
How long does a site take to recover after migration?
Most sites see rankings settle within two to four weeks and fully stabilize by eight weeks, assuming redirects are clean and URLs map one to one. A dip of 10 to 15 percent in the first fortnight is normal. If a decline deepens past week four, treat it as a redirect or mapping problem, not a waiting game.
Do I need to redirect every single old URL?
Redirect every URL that has traffic, backlinks, or indexed status. You can retire genuinely dead pages (expired products, duplicate tags) without a redirect, but document that choice. When unsure, redirect it; an unnecessary 301 costs nothing, a missing one costs rankings.
Should I migrate during a slow traffic period?
Yes. Launch on a low-traffic day, typically midweek, so you have staff available to fix issues and fewer users hit any temporary errors. Avoid launching before a weekend or holiday when no one is watching Search Console.
What is the single most common migration mistake?
Redirecting old pages to the homepage instead of their equivalent new page. It looks tidy and destroys rankings, because search engines read a homepage redirect as a signal the original content no longer exists. Always map old to closest new.
How many URLs can I realistically map by hand?
A careful person can map a few hundred URLs by hand in a day or two, and the manual pass is worth it because it catches judgment calls a script misses. Past a thousand URLs, script the bulk mapping by pattern and reserve manual work for the top revenue and top backlink pages. The hybrid approach, scripted mapping with manual QA on the pages that matter most, is the standard for larger sites.
Do I need to keep the old site running after launch?
You do not need the old site serving pages, but you must keep the redirects from the old URLs live for at least 12 months. Backlinks, bookmarks, and cached search results keep sending visitors to old URLs long after launch, and each of those requests needs a 301 to reach the new page. Take down the old content, keep the redirect layer running.
Get help with your migration
If you would rather hand this off, our website migration service team runs the full sequence, from baseline through post-launch monitoring. For budgeting, see the website migration cost guide, and for the fundamentals start with what is website migration.