The SEO Website Migration Checklist That Prevents Traffic Disasters

The SEO Website Migration Checklist That Prevents Traffic Disasters

A new website launch should be a celebration. For a client, it's the exciting culmination of months of work. For a designer or developer, it's the moment their creation goes live. But for an SEO agency owner, it's often a moment of pure terror.

We've all seen it happen. A client gets a shiny new site, and overnight their rankings plummet. Leads dry up. Panic ensues. The client calls you, the agency, demanding to know why the traffic has vanished. You then discover the web developer launched the new site without telling anyone, changing every URL and deleting half the pages in the process. Years of your hard work, gone.

This isn't a rare occurrence. It happens because most web developers, and even many agencies, treat SEO as an optional extra during a website rebuild. They see it as a simple 'flick of the switch' process. They are wrong. A website migration is a high-stakes technical procedure that can make or break a client's online presence.

At Straight Up Digital, we've managed enough of these to know that hope is not a strategy. A plan is the only thing that works. I'm sharing our exact, battle-tested checklist for managing a website migration. This isn't a theoretical guide from a marketing blog; it's our pre-launch, launch day, and post-launch process for protecting our clients' most valuable asset: their organic traffic.

Why Most Website Migrations Go Wrong

The core problem is a lack of planning and a failure to respect the authority the old site has built up over years. Google doesn't automatically know that `new-site.com/awesome-new-service-page/` is the replacement for `old-site.com/services/old-service`. You have to tell it, explicitly and permanently.

Here are the common disasters we get called in to fix:

• No Redirects: The developer simply deletes the old site and uploads the new one. Every old URL now returns a 404 'Not Found' error. Every backlink pointing to those pages is now worthless. Traffic evaporates.
• A Lazy Homepage Redirect: Almost as bad. The developer redirects every single old URL to the new homepage. This tells Google that all your specific service pages and blog posts are gone, and it erodes the authority of those pages.
• URL Structure Changes Without a Map: The new site might have a cleaner URL structure, which is great. But if you don't map every old URL to its new equivalent, you're back at square one.
• Forgetting Tracking Codes: The new site goes live without Google Analytics, Google Tag Manager, or any conversion pixels. There's no data to analyse, and the client thinks their ads have stopped working.
• Leaving The Site on 'Noindex': This is a classic. The staging site is rightly from Google using a 'noindex' tag in the code. On launch day, nobody remembers to remove it. The new site effectively tells Google 'please ignore me', and it happily complies.

Cleaning up this mess is expensive, stressful, and often only partially successful. The best approach is to prevent it from ever happening.

The Three Phases of a Successful SEO Migration

A chaotic launch happens when you try to do everything at once. A smooth migration relies on a structured, phased approach. We break the entire project into three distinct parts:

1. Phase 1: Pre-Launch Preparation. This is where 90% of the work happens. It's the meticulous planning that ensures launch day is boring, which is exactly what you want.
2. Phase 2: Launch Day. This is a calm, procedural checklist, not a frantic scramble.
3. Phase 3: Post-Launch Monitoring. The job isn't done when the site is live. You need to watch the data and reassure the client.

Let's break down each phase.

Phase 1: The Pre-Launch Preparation (The 90%)

If you get this part right, everything else is straightforward. Rushing the pre-launch phase is the single biggest mistake an agency can make. Do not cut corners here.

Step 1: Benchmark Everything

You cannot know if the migration was a success if you don't have a perfect snapshot of the old site's performance. You need to capture this data before anything changes.

• Crawl the current site: Use a tool like Screaming Frog or Sitebulb to crawl every single URL. Export this data to a spreadsheet. You want a complete list of every page, image, PDF, and file on the server. Include their associated title tags, meta descriptions, H1 tags, and word counts.
• Record keyword rankings: Get a baseline report of where the client ranks for their top 20, 50, or 100 commercial keywords. You will need this to check for stability after the launch.
• Screenshot analytics: Go into Google Analytics or GA4 and save reports for the last 30, 90, and 365 days. You want to preserve data on overall traffic, top landing pages by organic traffic, and conversion goals.

This data is your insurance policy. If something goes wrong, you have the 'before' picture to help diagnose the problem.

Step 2: Create the Master Redirect Map

This is the single most important document in the entire migration process. It is the architectural plan that tells search engines how to find their way from the old structure to the new one.

It is, quite simply, a spreadsheet with two columns:

• Column A: Old URL. Every single URL from the crawl you performed in Step 1 goes here.
• Column B: New URL. The corresponding page on the new website goes here.

Every URL from the old site must be mapped to its most relevant equivalent on the new site. Service pages go to service pages. Blog posts go to blog posts. If a page from the old site is being retired, you must redirect its URL to the next most relevant page; often a parent category or a related article. Never let it become a 404, and never just redirect it to the homepage unless you have absolutely no other choice.

This map is the instruction manual for the developer. It must be complete and accurate. You, the SEO agency, are responsible for creating it. It is not the developer's job.

Step 3: Technical SEO Checks on the Staging Site

Before the new site is ready for launch, the developer will have it on a staging or development server. You need access to this.

• Check for staging blocks: Confirm the site is blocked from indexing, usually with a `noindex` tag or a password. Crucially, make a note that this needs to be removed at launch.
• Crawl the staging site: Run Screaming Frog on the staging site. Are the URLs matching the structure you agreed on? Are there any unexpected 404 errors?
• Check canonical tags: Ensure pages have correct self-referencing canonical tags to prevent duplicate content issues.
• Review the robots.txt file: Is the new robots.txt file correct? It should allow crawlers to access all important CSS and JS files, and it shouldn't be blocking key pages.
• Verify tracking codes: Use Google Tag Assistant or browser developer tools to check that GA4, Google Tag Manager, and any other advertising pixels are installed correctly. Run test conversions if you can.

Step 4: Content and On-Page Review

Don't assume all the valuable content from the old site made it to the new one. Check it yourself.

• Do a content audit: Compare the exported crawl from the old site with the new one. Have any high-traffic or high-ranking pages been removed or drastically changed? This is your chance to raise a red flag.
• Check on-page elements: Are the title tags, meta descriptions, and H1 tags from the old site being carried over? Or have they been improved? The developer might just use the page name as the title tag, which is rarely optimal.
• Check internal links: Click through the new site. Are the internal links logical? Is the main navigation clear? Broken internal links are a common problem on new builds.

Phase 2: The Launch Day Plan

Because you did all the hard work in Phase 1, launch day should be methodical and predictable. We use a strict sequence of events.

The Go-Live Sequence

1. Confirm the time: Coordinate a specific launch time with the client and developer. Aim for a low-traffic period, like late at night or early in the morning.
2. Implement the redirects: The developer must now implement the 301 redirects from your master map. This is job number one.
3. Remove indexing blocks: The password protection or `noindex` tag on the staging site must be removed as it goes live.
4. Push the new site live: This is the developer's part.
5. Run a quick spot-check: As soon as it's live, grab 10-15 URLs from your redirect map. Paste the old URL into your browser and confirm it redirects to the new URL correctly.
6. Run a list crawl: Take your full list of old URLs from Column A of your map and run it through a tool that checks HTTP status codes. Every single one should return a 301 or a 200 (if the URL structure didn't change). Anything returning a 404 is an emergency fix.
7. Submit XML sitemap: Go to Google Search Console, add the new XML sitemap, and submit it.
8. Request indexing: Use the 'Inspect any URL' tool in Google Search Console for the homepage and a few other key pages. This gives Google a gentle nudge to come and look at the new setup.

Phase 3: The Post-Launch Monitoring

Your job is not done. What happens in the days and weeks after launch will determine the long-term success of the project.

The First 24-48 Hours

• Watch real-time analytics: Keep an eye on Google Analytics. Is traffic flowing? Are people visiting more than just the homepage?
• Check Google Search Console: Look at the 'Coverage' report. New errors will show up here first. Be ready to act on them.

The First Month

• Monitor rankings: Check your rank tracking software daily. Some slight movement is normal as Google figures things out. A dramatic, sustained drop is not. Investigate immediately.
• Crawl the live site again: A week after launch, do another full crawl of the live site. You will often find broken links or redirect chains that were not apparent on the staging site.
• Review analytics and GSC: Compare the traffic to your top landing pages before and after the migration. Are the new pages acquiring the traffic the old pages used to have? This confirms your redirects are working and being recognised by Google.
• Communicate with the client: This is vital. Send them an update after 24 hours, after a week, and after a month. Reassure them about small fluctuations and be proactive. Show them the stability in the data. This builds trust and shows you have the situation under control.

###

A website migration isn't just a design project; it's the technical evolution of a vital business asset. Applying this level of diligence isn't about being fussy or getting in the developer's way. It's about protecting your client's revenue, preserving the authority you have worked so hard to build, and proving your agency's true value.

Stop being the agency that has to clean up a mess. Become the strategic partner that gets it right from the start. That is how you keep clients for the long haul.