Website Migration Checklist: Protect SEO During a Rebuild

A website rebuild can improve performance, design and content while still creating an organic traffic problem if the migration is handled poorly. Search engines have already learned the old URLs and their signals. The job is to preserve what matters while introducing the new structure deliberately.

Migration is not a launch-day chore. It is a workstream that should start in planning, run through development and continue for weeks after go-live. Treat it as part of website redesign and SEO, not as an afterthought for whoever happens to have FTP access.

What protecting SEO actually means

You are trying to preserve:

• Indexable URLs that already earn impressions and clicks
• Relevance signals in titles, headings and substantive content
• Equity from backlinks pointed at old addresses
• Internal link relationships that help discovery
• Measurement continuity so you can detect problems quickly

You are not trying to freeze the old site forever. Improvement is allowed — and expected — as long as high-value destinations remain findable and coherent.

For the strategic framing around redesign risk, see SEO during a website redesign.

Phase 1: Crawl and export the old site

Create a complete URL inventory before launch. Add traffic, backlink and ranking data where possible so high-value pages are obvious. Do not depend on the old navigation alone; orphaned URLs can still carry search value.

Include:

• HTML pages you intend to keep or replace
• Important PDFs or resources that attract links
• Parameterized URLs that may need consolidation
• HTTP vs HTTPS and www vs non-www variants
• Staging or leftover test URLs that should never be migrated as equals

Store the inventory in a sheet the whole team can use. Migrations fail in shared drives when only one person understands the map.

Phase 2: Map old URLs to new equivalents

Every removed page should be assessed. Use permanent (301) redirects when a meaningful replacement exists. Avoid sending every retired URL to the homepage; that creates a poor user experience and weakens the relevance of the redirect.

Mapping rules of thumb:

One-to-one maps are ideal when content still exists. Many-to-one maps are fine when consolidation is intentional. Many-to-homepage maps are usually lazy.

Phase 3: Carry forward the signals that still matter

Review titles, descriptions, headings, canonical tags, structured data and internal links on important pages. A redesign is a chance to improve them, not a reason to discard proven content without analysis.

Pay special attention to:

• Service pages that already rank or convert
• Location or audience pages with steady demand
• Resource pages with external links
• Any URL named in ads, email or sales collateral

If content must be shortened for design reasons, cut fluff first — not the sections that answer the query.

Phase 4: Technical prep before launch

Confirm the new environment is ready:

• HTTPS everywhere with clean canonical host
• No accidental noindex on production
• XML sitemap generated from final URLs
• Robots.txt that blocks only what should be blocked
• Analytics and tag manager containers pointing at the new property correctly
• Forms and thank-you events tested end to end
• Redirect rules implemented at the server or edge layer, not only as “we’ll add them later”

Run a staging crawl that mirrors production as closely as possible. Catch chains, loops and soft 404s before DNS cuts over.

Phase 5: Launch-day validation

Immediately after launch, check that:

1. Sample high-value old URLs redirect once to the correct new URL
2. New pages return 200 with the intended canonical
3. Homepage and key templates render without missing assets
4. Analytics pageviews and conversion events fire
5. The new sitemap is reachable and submitted in Search Console
6. robots.txt matches the intended indexation policy

Have a hotfix path ready. Migrations that cannot be patched quickly turn small mistakes into week-long traffic dips.

Phase 6: Post-launch monitoring

Watch Search Console for coverage issues, spikes in 404s, unexpected soft 404s and query/landing-page shifts. Compare organic landing pages against your pre-launch baseline.

Some fluctuation is normal. Patterns that need fast response include:

• Top pages dropping while returning errors
• Redirect targets that are thin or off-topic
• Canonical conflicts between www/non-www or trailing-slash variants
• Accidental deindexation of entire directories

Monitor daily in the first week, then several times per week for the next month. Keep a change log so you can correlate dips with deploys.

Common migration mistakes

• Starting the redirect map the night before launch
• Changing URLs purely for aesthetic naming conventions
• Dropping blog or resource sections without checking links and traffic
• Relying on JavaScript-only redirects
• Forgetting to update internal links, so users still hit old paths unnecessarily
• Launching with staging noindex still enabled
• Declaring victory on launch day and ignoring Search Console for a month

Roles and ownership

Assign owners explicitly:

• URL map owner — inventory and redirect decisions
• Content owner — what must be preserved or rewritten
• Engineering owner — redirect implementation and status codes
• SEO / analytics owner — Search Console, crawls, measurement
• Launch lead — go/no-go and hotfix coordination

If nobody owns the map, everyone assumes someone else does.

Migration checklist you can run with

Before build

• Full crawl exported
• Traffic / links / conversions annotated
• Keep / merge / redirect / remove decisions drafted

Before launch

• Final 301 map reviewed
• Staging crawl clean of major errors
• Analytics and forms verified
• Sitemap and robots prepared

After launch

• Spot-check redirects and status codes
• Submit sitemap; inspect key URLs
• Monitor coverage and 404 reports
• Compare organic landing pages to baseline

Treat the old site as an asset inventory and the new site as a controlled transition rather than a clean slate. Migration work is easiest when it starts during planning — and when someone is still watching the numbers after launch day.