Website migration SEO checklist

Replatforming is not only a CMS project. Search engines, bookmarks, and partner sites still call old URLs. This website migration SEO checklist is the operational spine we attach to website migration services and methodology engagements: inventory first, redirects signed, parity verified, then cutover with observable signals in Google Search Console.

Why a checklist exists

A migration without a URL inventory is guesswork. Google’s guidance on site moves with URL changes assumes you tell crawlers when locations change, using permanent redirects where appropriate. PunkSolid treats the checklist as a contract between engineering, SEO, and editorial: what must work on day one, what can wait, and what gets a deliberate 410 or removal.

We do not promise identical rankings. We promise auditable decisions—every high-traffic path mapped, every intentional removal documented, and Search Console watched while caches and links catch up.

Before cutover — inventory and mapping

Start by crawling the live legacy site (or exporting server logs plus a commercial crawler). Export status codes, canonical tags, hreflang if present, and indexation hints (noindex, nofollow). Merge that list with analytics landing pages and Search Console top URLs. The union is your working inventory, not the sitemap alone.

Build a redirect map with one row per indexable legacy URL. Target patterns should be 1:1 whenever content survives; use pattern rules only when templates consolidated and someone reviewed examples. Document intentional removals with HTTP 410 or explicit delisting—not soft 404s on the homepage.

Match title and meta description on priority URLs, or improve them with clearer intent rather than meaningless churn. Sudden mass rewrites on money pages can add noise during an already risky window.

Plan the internal link graph for new templates: category hubs, breadcrumbs, and related modules that used to live in WordPress widgets must exist in the destination components. On Astro or Next builds, see WordPress to Astro or Next.js for how templates map to components.

Freeze legacy content or define a sync process if marketing must publish during the rebuild. Every net-new legacy URL without a mapped destination is a future 404.

Verify staging is not indexable: noindex headers, robots blocks, and no accidental sitemap on staging hosts. Lower DNS TTL several days before cutover if you control the zone.

Before cutover — structured data and assets

Reconcile structured data per template type: Organization, Product, FAQ, Medical entity, or Article markup that existed on WordPress must render on the new stack or be deliberately retired. Validate JSON-LD in staging builds; rich-result regressions are easier to fix before launch.

Carry image URLs and alt text through imports; broken media degrades quality signals and accessibility. If CDN paths change, include those paths in the redirect map or update absolute URLs in content exports.

For large healthcare or directory sites, read how we handled scale on healthcare WordPress rebuilds: thousands of pages with signed inventories before DNS moved.

Launch day — redirects and smoke tests

Deploy redirect rules at the edge (CDN, reverse proxy, or origin) before widening traffic to the new stack. Google’s 301 redirect documentation treats permanent redirects as the primary way to pass signals when URLs change.

Smoke-test a priority set (top revenue, compliance, and editorial URLs): status code, final URL, canonical tag, and hreflang if used. Test parameterized URLs you still support; drop parameters only when Search Console history shows they are unused.

Submit or refresh sitemaps in the correct Search Console property (apex vs www must match your live host). Monitor server logs for 404 and 5xx spikes in real time during the first hours.

Keep a rollback note: which DNS or proxy switch reverts traffic, and how long legacy infrastructure stays warm.

After launch — 30 to 90 days

In Search Console, compare coverage, redirect errors, and core query groups week over week. Fix redirect chains (A→B→C) and duplicate parameters that create crawl noise.

Reconcile structured data reports after templates stabilize. When child domains mirror parent content in a network, keep canonical discipline per your ownership map—mirror pages should not compete with owners.

Run a second crawl export at day 30 and diff against the pre-launch inventory. New 404s often trace to late editorial publishes or marketing UTMs treated as paths.

When migrations include tracking stacks (Tag Manager, GA4, consent tools), parity checks belong in the same program—not a separate “analytics ticket.” PunkSolid documents those alongside URL work on website migration deliveries.

Working with agents without losing SEO discipline

AI-assisted rebuilds speed component and content migration, but agents do not replace signed inventories. Use spec-driven development so each migration phase lists acceptance checks: redirect tests, metadata snapshots, and pnpm or framework build gates.

Agents should not invent URLs or canonicals. Humans approve the redirect CSV and any change to regulated copy.

Handoff and ownership

You should leave cutover with: the redirect map in version control, automated tests for top paths where feasible, and a written monitoring cadence. Code ownership means your team can edit redirects without returning to the agency for every marketing campaign.

When to hire help

Internal teams with strong devops and SEO can run this checklist alone. Hire when URL counts reach thousands, when multiple properties canonicalize together, or when WordPress plugin surface blocks a straight export. PunkSolid’s website migration services package inventory, rebuild, and the checklist into one program with repository handoff.

Checklist snapshot (printable)

Before cutover: crawl export merged with analytics and Search Console; signed redirect map; staging noindex; structured data spot checks; content freeze or sync policy written.

Launch day: edge redirects live; priority URL smoke tests; sitemap submitted; real-time 404/5xx watch; rollback owner named.

After launch: weekly coverage diff; chain cleanup; day-30 crawl diff against inventory; tracking parity sign-off when martech is in scope.

Treat each line as pass/fail in your project tracker. Grey areas belong in the signed map, not in launch-day improvisation.