How to rebuild a website without losing SEO

The short answer

Inventory the existing site before development is finished. Decide which URLs stay, move, merge or retire. Preserve valuable content and metadata where appropriate. Implement direct permanent redirects for changed URLs, generate correct canonicals, update internal links and sitemaps, validate indexability before launch, then crawl and monitor the new site after release.

Do not wait until launch day to “do the SEO.”

Step 1 — crawl and inventory the current site

Before replacing anything, create a record of the existing state. This becomes the migration map and post-launch comparison point.

• Indexable URLs
• Status codes
• Titles/descriptions
• H1s
• Canonical targets
• Robots directives
• Internal links
• Structured data
• Sitemap URLs
• Important organic landing pages
• Search Console evidence
• Backlinks to high-value pages where available

Step 2 — classify every important URL

Each meaningful URL should have an intended future state: Keep — same purpose and URL. Move — same/similar purpose, new URL. Merge — several pages consolidate into one stronger destination. Retire — no equivalent value remains. New — genuinely new page.

Avoid redirecting every removed page to the homepage. A redirect should lead to the closest useful replacement.

Step 3 — protect search intent, not just copy

A redesign often changes content substantially. That can be positive, but removing the sections that made a page relevant to its search intent can change performance even if the URL stays the same.

For important landing pages, understand what queries/pages currently receive visibility, which content satisfies that intent, which proof or detail users need, and what internal links support the page. Preserve the purpose while improving the experience.

Step 4 — build the redirect map before launch

For every changed indexable URL, specify the destination and expected status. Prefer direct one-hop permanent redirects. Avoid chains such as: Old A → temporary B → old C → new D.

Test the redirect file/rules in staging or a safe environment where possible.

Step 5 — generate self-referencing canonicals correctly

Canonical bugs can be introduced when a new framework or template inherits one global URL. Every indexable page that should stand on its own generally needs a canonical representing that intended URL.

Fusion Works encountered this exact class of issue on its own site: unique pages inherited the homepage canonical. The implementation was corrected at the metadata-generation layer and verified by recrawling rather than patched page by page.

The lesson is broader than the specific fix: validate generated metadata, not only what the component source appears to say.

Step 6 — update internal links

Redirects are a safety net, not an internal-link strategy. Update navigation, breadcrumbs, body links, cards and CTAs to point directly to final URLs. This reduces redirect hops and makes the new architecture explicit.

Step 7 — migrate metadata and structured data deliberately

Review title, meta description, canonical, robots, Open Graph/social metadata where needed, structured data and breadcrumb structure.

Do not copy old schema blindly if the visible content or page type changed.

Step 8 — protect crawlability and rendering

Common launch mistakes include the following. Validate the production build and live responses, not only screenshots.

• Staging noindex carried into production
• Robots rules blocking important routes
• JavaScript rendering failures
• Canonical host mismatches
• Missing sitemaps
• Production pages returning unexpected errors
• Links pointing to staging domains

Step 9 — preserve measurement

A rebuild can also break the evidence needed to evaluate the rebuild. Before launch, map GA4/GTM implementation, important events/key events, form/lead success states, consent behaviour, Search Console property/sitemaps and CRM/lead attribution fields where relevant.

A migration without reliable measurement makes post-launch diagnosis harder.

Step 10 — launch, recrawl and monitor

After release, crawl the production site, test redirect samples and high-value URLs, verify canonicals/indexability, inspect sitemap, check structured data, validate analytics events, monitor Search Console indexing/crawl signals, and watch important landing pages and queries over time.

A developer marking the migration “complete” is not the same as search engines seeing the intended new state.

Should rankings drop after a redesign?

Some fluctuation can occur when URLs/content/architecture change, but a major loss should not be treated as automatically normal.

Investigate whether intent changed, redirects are wrong, important content disappeared, canonicals/noindex are incorrect, internal links weakened, rendering failed or measurement is misleading.

A pre-launch migration checklist

• Current-site crawl saved
• Priority landing pages identified
• URL disposition complete
• Redirect map complete
• Titles/canonicals/robots reviewed
• Internal links updated
• Structured data matches new content
• XML sitemap generated
• Staging blocks removed correctly at production
• Analytics/lead tracking validated
• Production crawl scheduled immediately after launch