Website Migration Checklist: Move Without Losing Traffic

Moving a website to a new design, platform, host or domain can be smooth or catastrophic. The difference is usually preparation. Pages that rank can vanish, links can break, forms can stop working and analytics can go silent. This website migration checklist walks through the steps that protect your traffic, leads and reputation before, during and after the move.

Know what kind of migration you are doing

Different changes carry different risks.

• Hosting change: same site, new server. Lower risk, but watch DNS and email.
• Platform change: for example from one CMS to another. URL structures, templates and plugins often change.
• Redesign: new layout and content, possibly new URLs.
• Domain change: new domain name, the highest SEO risk.
• Protocol change: moving from http to https.
• Structure or content consolidation: merging or removing pages.

Combinations multiply the risk. If possible, avoid changing everything at once.

Phase one: planning

1. Set goals and scope. Why are you migrating, and what must stay the same?
2. Choose a timeline outside peak business periods. Avoid launches before holidays or major campaigns.
3. Assign roles: project owner, developer, designer, content lead, SEO lead and approver.
4. Create a risk list and a rollback plan if things go wrong.
5. Back up everything. Files, database, email settings and DNS records. See WordPress backup strategy if relevant.
6. Record baseline performance: organic traffic, rankings for key terms, conversions, page speed and top landing pages. Export from analytics and Search Console.

Phase two: inventory what you have

Crawl the existing site

Use a crawler to list every URL, with status codes, titles, headings, canonical tags, internal links and page types. Combine with data from Google Search Console and analytics to identify:

• Pages with traffic and conversions.
• Pages with backlinks. Use backlink tools or Search Console links report.
• Pages that rank well.
• Thin, outdated or duplicate pages.

Decide what happens to each page

For every old URL, choose one:

1. Keep with the same URL.
2. Keep with a new URL and a redirect.
3. Merge into another page with a redirect.
4. Remove with a suitable redirect or a proper 410 or 404 if there is no relevant replacement.

Avoid redirecting everything to the homepage; it frustrates users and search engines. See 301 vs 302 redirects.

Map redirects

Create a spreadsheet with old URL, new URL, redirect type and notes. Test the map on a sample. Keep it as a working document through launch.

Phase three: build and prepare the new site

1. Set up a staging site that is blocked from search engines and password protected.
2. Migrate content accurately: text, images, metadata, headings, alt text and structured data. Review on-page SEO checklist.
3. Preserve SEO elements: title tags, meta descriptions, canonical tags, hreflang tags if relevant, and internal links. See canonical tags explained and hreflang tags guide.
4. Check site architecture and navigation. See website structure for SEO.
5. Set up redirects according to the map.
6. Prepare XML sitemap and robots.txt for the new site. See XML sitemap and robots.txt guide. Make sure robots.txt on the live site does not block crawling when you launch.
7. Install analytics and tracking: analytics tags, conversion events, ad pixels and consent banner. See GA4 events and conversions setup and cookie consent banner guide.
8. Test forms, checkout, search and integrations: email delivery, CRM connections and payment gateways.
9. Test performance and mobile layouts. See website speed optimization tips.
10. Run accessibility checks. See accessible web design basics.

Phase four: pre-launch testing

Crawl the staging site and compare it with the old site crawl:

• Do all important pages exist?
• Are titles, headings and meta descriptions present?
• Are there broken links or redirect chains?
• Are canonical tags correct?
• Is the noindex tag on staging removed when it goes live?
• Do images load and have alt text?
• Does structured data validate?

Test redirects with the redirect map using a list-mode crawl. Ask colleagues and a few customers to try key tasks on different devices and browsers.

Phase five: launch day

1. Announce a content freeze on the old site a day or two before, to avoid losing updates.
2. Take final backups.
3. Switch DNS or deploy the new site according to the plan. If DNS changes, lower the TTL value in advance so propagation is faster.
4. Remove staging restrictions: password protection and noindex tags.
5. Check the live site immediately: homepage, key pages, forms, checkout, search, redirects, SSL certificate and robots.txt.
6. Submit the new sitemap in Search Console. If the domain changed, use the change of address tool where available.
7. Verify analytics is recording and conversions fire.
8. Check email if the host or DNS changed: make sure email still works and SPF, DKIM and DMARC records are in place. See SPF, DKIM and DMARC explained.
9. Notify stakeholders that the site is live and who to contact about issues.

Phase six: monitor and fix

The weeks after launch are crucial.

• Daily for the first week: check Search Console for crawl errors, coverage issues and security problems. Check server logs if available. See log file analysis for SEO.
• Review analytics: compare traffic and conversions with the baseline. A temporary dip can occur, but a steep or sustained drop signals a problem.
• Fix broken links and missing redirects quickly.
• Check rankings for key terms.
• Update external profiles: Google Business Profile, social bios, directories and email signatures with the new URLs or domain.
• Request reindexing of important pages if needed.
• Collect user feedback about errors or confusion.
• Keep the old site's redirects in place for at least a year, ideally permanently for pages with backlinks.

Mind the old hosting account. Do not cancel it until you are sure everything has been moved, including emails and files.

Common mistakes

• Launching with noindex still on.
• Forgetting redirects.
• Changing URLs unnecessarily.
• Losing metadata and structured data.
• Breaking forms and tracking.
• Cancelling the old host too soon.
• Launching without a rollback plan.

A sample redirect map

A redirect map is a simple table. For example:

• /about-us.html redirects to /about
• /services/web-design-bangalore redirects to /services/web-design
• /blog/2022/05/seo-tips redirects to /blog/seo-tips
• /old-offer redirects to /services (the closest relevant page)
• /team/john-smith redirects to /about#team

Add columns for the status code, the date the redirect was tested and any notes. Sort by traffic so the most important URLs are tested first. Keep the table after launch as a reference when errors appear in Search Console.

Communicating with customers and staff

Tell people what to expect. If the site will be offline briefly, announce the time in advance. If login details, account areas or order tracking change, send clear instructions. Give staff a short brief about the new site: what has changed, where to find things and whom to contact about problems. Prepare standard replies for customer questions. A calm, well-informed team keeps minor glitches from turning into frustration.

What to do if traffic drops

A modest fluctuation after launch is normal as search engines reprocess the site. If traffic falls sharply, investigate in this order: check that the site is indexable (no noindex, no robots block), confirm redirects are working, look for server errors, review canonical tags and check that key pages have not lost content or internal links. Compare pages that lost traffic with the old versions. Fix issues, request reindexing of important URLs and keep monitoring. Most recoveries come from correcting technical errors quickly, which is why daily checks in the first weeks matter.

Keep documentation

Record what you changed, when and why. Store the crawl files, redirect map, backups and checklist with notes on the problems found and how they were solved. Next time you migrate or redesign, this record will save time and reduce mistakes. It also helps anyone who inherits the site to understand its history, which is useful when diagnosing unexpected behaviour months later.

A short summary checklist

1. Backup and baseline.
2. Crawl and inventory.
3. Redirect map.
4. Staging build and tests.
5. Launch with a plan.
6. Monitor and fix.

If you need support planning a migration, contact me.