[email protected]
0333 050 1245

Protect Rankings: Website Migration SEO Checklist for Owners, 60 Days Monitoring

  1. Home
  2. »
  3. Blog
  4. »
  5. Why optimise images: boost speed, SEO, and conversions

Protect your rankings by nailing three tasks before you flip the switch: a full URL crawl and value map, a 1:1 301 redirect plan, and staged mobile-first rendering tests. Get those right and you’re most of the way there. Expect a period of monitoring afterwards, whatever anyone tells you. At Kukoo, we’ve steered enough clients through this to know the tools that matter: Screaming Frog, Google Search Console, and a healthy dose of patience.

TL;DR:

  • Building a comprehensive URL inventory from multiple sources and tagging each URL by business value is essential before initiating a migration.
  • Creating a precise 1:1 redirect map that avoids blanket redirects to the homepage minimizes traffic loss and indexing issues.
  • Conducting thorough staging tests, including mobile rendering and structured data validation, helps catch problems before the site goes live.
  • Launch day checks should include DNS propagation, redirect verification, sitemap submission, and immediate crawl tests to ensure a smooth transition.
  • Monitoring should continue for at least 60 days post-launch, focusing on key metrics like impressions, crawl errors, and backlink integrity to detect slow-burning issues.

Table of Contents

Building your pre-migration checklist and website migration plan

Every successful migration starts with a document nobody wants to write: the master URL inventory. Skip this step and you’re flying blind, redirecting from memory, and hoping nothing important falls through the cracks. It won’t.

Pull your full URL list from three sources, not one. Screaming Frog or Sitebulb will crawl your existing site and surface every indexed page, but crawlers miss orphaned pages that still pull traffic. Cross-reference against Google Search Console’s performance report and your server logs to catch URLs that Google visits even if your own navigation has forgotten they exist.

Step 1: Export and tag every URL

Once you have your master list, tag each URL by what it’s worth to the business, not just what it looks like on paper.

  1. Traffic value — pull 12 months of organic sessions per URL from your analytics platform.
  2. Backlink value — check which pages attract external links using your backlink tool of choice.
  3. Conversion value — flag pages that generate leads, sales, or sign-ups directly.
  4. Ranking value — note pages holding page-one positions for commercial terms.

A blog post with modest traffic but a dozen quality backlinks deserves the same care as your top landing page. Treat them the same and you’ll lose link equity you spent years earning.

Step 2: Build the 1:1 redirect map

This is where most migrations quietly fail. Semrush’s migration research confirms that a comprehensive checklist built around pre-migration crawling and precise redirect mapping substantially cuts the risk of traffic loss, and the redirect map is the single biggest lever in that process.

Every legacy URL needs a destination on the new site, and that destination should be the closest content match, not the homepage. Blanket redirects to the homepage are a well documented failure mode. According to technical SEO guidance on migration redirects, routing many old URLs to one homepage destination triggers “soft 404” behaviour, where Google effectively treats the redirect as a dead end and drops the page from its index anyway.

Handle three scenarios explicitly:

  • Direct match: old page maps to an equivalent new page, one-to-one, no exceptions.
  • Consolidation: several thin legacy pages merge into one authoritative hub, and all contributing URLs redirect there. When you do this, preserve the exact anchor text that pointed to those pages internally, because that anchor text carried relevance signals worth keeping.
  • Genuine removal: pages with no modern equivalent and no ongoing value get a proper 410 Gone status rather than a forced redirect to somewhere irrelevant. A 410 tells Google plainly that the page is gone and won’t return, which processes faster than leaving a confusing 404 or an unrelated redirect.

Step 3: Snapshot everything and document what you can’t see

Before a single line of code changes, screenshot your Search Console coverage report, export your current rankings for priority keywords, and record baseline Core Web Vitals scores. You need a “before” picture to judge the “after” against.

While you’re at it, document every canonical tag, meta description pattern, schema markup type, and hreflang configuration currently live. If your developer can’t tell you why a page has a particular canonical tag, check the Wayback Machine for historical snapshots. It’s saved more than one migration when the original CMS export turned out to be incomplete.

Finally, agree your rollback plan and communication chain before launch day, not during a panic on launch day. Decide who has authority to pause the migration, how quickly DNS can revert, and who tells clients or stakeholders if something breaks. Set a launch window during your lowest traffic period, typically a weekend evening, and assign clear owners for redirects, DNS, content QA, and monitoring. For a wider view of the tasks that sit either side of this stage, our website launch checklist and website audit guide both cover ground that overlaps with migration planning.

How do you test staging before launch?

Staging is where you catch problems while they’re still cheap to fix. Once you’re live, every error costs rankings and time.

Lock staging down properly first. Use HTTP authentication or a site-wide noindex directive so search engines can’t accidentally crawl and index your unfinished site. That said, locking staging down doesn’t mean testing it in isolation. Run DOM parity checks against your production templates so you know the rendered output matches what you intend to ship, not just what the CMS preview shows you.

Mobile rendering deserves particular attention here. Google finished its move to mobile-first indexing some time ago, which means the mobile version of your staging site is the version Google will actually evaluate at launch. Render your staging pages using Google’s mobile user agent and compare the resulting HTML, including your schema markup, directly against the legacy site’s mobile output. Discrepancies here are one of the most frequently missed checks in the entire process.

Structured data needs its own pass, separate from general rendering checks. Validate every JSON-LD block using Schema as your reference, then run affected page types through Google’s Rich Results Test. If your legacy site used Organization, Article, Product, or FAQ schema, confirm each type migrated intact and correctly nested, not just present somewhere in the page source.

Then crawl staging in full and compare it against your legacy crawl, treating both as canonical QA sources rather than approximate guides. Look specifically for:

  • Missing pages that exist on the legacy site but weren’t rebuilt on staging.
  • Internal links still pointing to old legacy URLs instead of new staging paths.
  • Duplicate title tags or meta descriptions carried over by accident.
  • Pages accidentally left with noindex that should be indexable at launch.

Pro Tip: Run your staging crawl twice, once early in development and once 48 hours before launch. Developers make last-minute template changes constantly, and a second crawl catches the noindex tag someone forgot to remove after the “final” review.

If your new build runs on a JavaScript framework, check whether content renders server-side or client-side. Migrations to headless or JS-heavy stacks need to preserve pre-rendered HTML through SSG or SSR rather than leaning on client-side rendering alone, because relying on the browser to build the page delays indexing and can leave Googlebot seeing a blank shell on first crawl.

What should you check on launch day?

Launch day rewards preparation and punishes improvisation. Work through this sequence in order, and don’t skip ahead because the previous step “probably” worked.

  1. Schedule DNS changes for a low-traffic window and lower your TTL settings in advance so propagation completes faster. Monitor server response times throughout, since a sudden traffic spike hitting a fresh server configuration can expose performance issues you didn’t see on staging.
  2. Verify redirects are live, both manually and in bulk. Manually test your twenty highest-value URLs by hand, then run a full bulk redirect check across your entire URL map to confirm nothing reverted to a 404 during deployment.
  3. Remove the staging noindex and confirm your live robots.txt permits crawling of the pages you want indexed. This sounds obvious until you remember how many sites have launched with the staging noindex tag still live in production.
  4. Submit your XML sitemaps through Search Console and confirm your property verification carried over. If you’re moving domains, submit a Change of Address request through Search Console so Google understands the shift is deliberate, not a hijack attempt.
  5. Check canonical tags, hreflang, and HTTP status codes across a representative sample. A wrong canonical pointing back to a staging URL will quietly cannibalise your new page’s ranking potential.
  6. Run a live crawl immediately and inspect your highest-value landing pages individually, checking title tags, schema output, and internal linking against what you validated on staging.

Extra bullet points to fold into that sequence rather than treat as an afterthought:

  • Confirm your analytics and conversion tracking fired correctly on the new domain or template before you consider launch complete.
  • Check that forms, checkout flows, and any gated content still function, since a broken form won’t show up in an SEO crawl but will show up in your conversion numbers within hours.
  • Keep your rollback trigger and the person authorised to pull it on standby for the first few hours, not just theoretically documented somewhere.

What should you monitor after migration, and for how long?

The work doesn’t end at launch. It shifts from execution to observation, and that phase matters just as much.

What should you monitor after migration, and for how long? — overview diagram

Build a monitoring dashboard covering four things: Search Console clicks and impressions, index coverage status, crawl error rates, and raw server logs showing what Googlebot is actually requesting. Prioritise your “top pages” list from the pre-migration snapshot above everything else. If your ten highest-traffic pages hold steady, you’re likely fine even if smaller pages wobble.

Expect some volatility. Rankings shuffle for a week or two after almost any migration as Google recrawls and reprocesses your site. Well-executed migrations typically stabilise within four to eight weeks, though complex domain moves or large replatforms can take the full 90 days to fully settle.

The real risk window: most technical faults surface in the first two weeks, but their ranking impact often doesn’t show clearly in Search Console data until week three or four. Don’t wait for a dramatic drop to start checking; check daily from day one instead.

The difference between normal reranking and a genuine problem comes down to pattern, not panic. A gradual dip across many pages that recovers within days is normal churn. A sharp, sustained decline concentrated on specific high-value pages needs immediate triage:

  • Check for redirect chains that formed accidentally when old redirects layered on top of new ones.
  • Look for canonical tags pointing to the wrong URL, especially on pages that were consolidated.
  • Search for pages carrying an accidental noindex tag that survived from staging.
  • Use URL Inspection in Search Console to request re-indexing on your priority pages once fixes are confirmed live.

Backlinks need attention too, separate from technical monitoring. Search Engine Land’s migration guidance is blunt about this: migrations frequently cause ranking drops specifically when redirects, canonical tags, or structured data go missing between the legacy and live environments, and a full comparative crawl is the fastest way to catch it. Reach out to your highest-value linking sites and ask them to update links pointing to old URLs directly, rather than relying on redirects to carry that equity forever.

Common migration mistakes and how to fix them

Most migration failures trace back to a handful of repeat offenders. Recognising the symptom quickly saves you weeks of guessing.

  1. Staging leakage. Your new site ranks poorly or doesn’t appear at all, and a Search Console inspection shows pages marked noindex. Check your robots meta tags and HTTP headers immediately, remove the leftover directive, then request indexing.
  2. Homepage blanket redirects. Traffic craters across dozens of pages at once. Pull your redirect map and check whether multiple distinct URLs all point to the same generic destination. Rebuild those as proper 1:1 redirects to genuinely relevant pages instead.
  3. Redirect chains. Pages redirect two or three hops before landing, diluting authority and slowing crawlers. Audit every redirect for chain length and flatten each one to a single direct hop.
  4. Delayed indexing on JS-heavy pages. New pages sit in “Discovered, not indexed” for weeks. Check whether your framework renders content client-side and switch to server-side or static rendering where possible.

When something breaks and the cause isn’t obvious, work through this sequence: compare your staging and live crawls side by side, check server logs to see what Googlebot is actually requesting and receiving, inspect the affected URL directly in Search Console, then run a render test to see what Google sees versus what a browser shows a visitor. That order finds the fault faster than jumping straight to conclusions.

What we recommend as a minimum migration scope

Having guided plenty of clients through replatforms and redesigns, we’ve settled on a minimum scope we won’t go below: a pre-launch technical audit, proper redirect engineering rather than bulk automated mapping, hands-on launch day support, and 60 days of active monitoring afterwards.

That 60-day window isn’t arbitrary. It covers the period where most technical faults surface and gives enough runway to catch the slower-burning issues, like backlink erosion or gradual index coverage drops, that don’t show up in week one.

60-day website migration monitoring timeline

If you’re running this in-house, involve your developer, your content lead, and whoever owns analytics from day one, not just at launch. Budget for professional support specifically around redirect mapping and structured data validation. Those two areas cause more post-migration recovery work than everything else combined.

Why the standard advice undersells the risk

Most migration checklists treat SEO as a box-ticking afterthought bolted onto a design or development project. That’s backwards. The technical decisions, redirect logic, rendering method, schema handling, get made months before launch, often by developers who’ve never opened Search Console.

The pre-migration audit isn’t a nice-to-have step you squeeze in in if time allows. It’s the entire foundation the redirect map, the staging tests, and the monitoring plan all depend on.

If you take one thing from this, prioritise the redirect map above everything else. A brilliant new design with sloppy redirects will bleed rankings for months. A modest design with precise, well-tested redirects protects what you’ve already earned while you build something better. Get the unglamorous technical work right first.

— Kukoo

How Kukoo can help with your website migration

Migrations go wrong quietly, a missed redirect here, a stray noindex tag there, and by the time rankings drop, the damage is already done. If you’d rather have specialists watching for exactly that, that’s where we come in.

Kukoocreative

We handle web rebuilds, launch support, and post-launch monitoring as a connected process, not three separate handoffs where things fall through the gaps. If you’re facing a complex replatform, a domain change, or you simply don’t have the internal hours to run daily Search Console checks for two months, that’s precisely the gap we fill. Our web design process for business owners walks through exactly how we structure a rebuild from planning through to launch and beyond, and you can see the standard of work behind it in our portfolio. If your migration is on the horizon, get in touch and let’s talk through your scope before you set a launch date.

Sources

Keep these bookmarked through planning and launch. Google Search Console handles verification, sitemap submission, and Change of Address requests. Schema.org remains the reference for every structured data type worth preserving. For crawling, Screaming Frog and Sitebulb both compare legacy and staging sites effectively, and a solid technical audit checklist fills any gaps in your own process. Google’s Rich Results Test and Mobile-Friendly Test cover structured data and rendering previews respectively.

  • The Complete Website Migration Checklist SEO-Friendly — Semrush