How we preserve SEO during a website rebuild

A website rebuild changes more than the design.

Even when the domain stays the same, the new implementation can change URLs, headings, internal links, content depth, rendering, metadata, structured data, navigation, and page relationships.

That is why we treat a rebuild as a search migration, even when the project is not moving to a new domain.

Start with an inventory of the current site

Before changing routes, we want to know what already exists.

That includes public URLs, important service pages, articles, location pages, portfolio entries, indexed legacy routes, and any pages receiving meaningful search traffic or backlinks.

The goal is not to preserve every weak page forever.

The goal is to make intentional decisions instead of discovering old URLs only after they become 404s.

Stable URLs are cheaper than unnecessary migrations

If an established URL still describes the page correctly, keeping it is often the safest choice.

A redesign does not require a new slug.

Every changed URL creates redirect work and asks search engines to transfer signals to a new address.

We make that change when the information architecture improves enough to justify it.

Redirects should map meaningfully

When a route does change, the old URL should point to the closest useful replacement.

A retired kitchen-remodeling page should not be redirected to the homepage simply because the homepage exists.

Redirects are part of the information architecture.

They tell visitors and crawlers where the old document moved.

Our routing and URL design guide explains why stable addresses matter beyond SEO.

Canonicals have to agree with the new structure

The rebuilt page should identify its production URL as canonical.

Redirect targets, internal links, sitemap URLs, structured data URLs, and canonicals should all agree.

Mixed signals create unnecessary ambiguity.

This is why we centralize metadata instead of hand-writing canonical URLs independently on dozens of routes.

Internal links need to survive the rebuild too

A page can keep the same URL and still lose importance if the new navigation stops linking to it.

Rebuilds frequently change page depth and link relationships.

We review whether important service pages remain reachable through normal navigation and whether relevant articles, locations, or case studies still support them contextually.

Internal linking is not decoration. It describes the structure of the site.

Rendering changes deserve attention

A rebuild may also change how the page reaches the browser.

If the old site served meaningful HTML and the new site depends on a large client-side rendering path, that is a material technical change.

Our preference is to keep important business content server rendered or statically generated so the document remains straightforward to crawl and fast to display.

Metadata and structured data should be regenerated from the new source

A rebuild is a good opportunity to remove copied or stale metadata.

Titles, descriptions, social fields, breadcrumbs, service schema, article schema, and other structured signals should reflect the new page rather than surviving as leftovers from the old implementation.

The page should tell one coherent story across visible content and machine-readable metadata.

The sitemap should describe the new site, not the old one

Once the new architecture is ready, the sitemap should be generated from the new route and content system.

Old URLs that now redirect should not remain listed as canonical sitemap entries.

New pages should appear because they exist in the real content registry, not because somebody manually remembered to add them to XML.

See why our sitemaps come from the codebase.

Preview indexing needs to stay controlled

Rebuilds create a special risk because preview environments may contain old and new structures at the same time.

We explicitly mark nonproduction deployments as nonindexable so a crawler does not discover unfinished route experiments and treat them as another version of the public site.

That architecture is covered in why preview deployments are explicitly noindex.

Launch is not the end of the migration

After release, we watch the site.

Search Console can show crawl behavior, impressions, clicks, queries, landing pages, and indexing changes.

We check redirects, 404s, canonical behavior, sitemap processing, and whether important pages remain discoverable.

Ranking movement alone does not prove the rebuild is broken. Search engines still have to recrawl and reevaluate changed documents.

Avoid panic-driven second rebuilds

One of the easiest mistakes is seeing volatility and immediately changing everything again.

That creates a second set of signals before the first set has been fully processed.

If the technical migration is clean, we want enough data to distinguish a real problem from normal reassessment.

The business goal still matters

A rebuild should not preserve weak impressions simply for the sake of preserving them.

If the old site appeared for broad irrelevant searches and the new site becomes more focused around valuable commercial intent, raw impression volume may move while lead quality improves.

The technical job is to preserve legitimate search equity and remove migration mistakes.

The strategic job is to make the new site better aligned with the business.

Both matter.