Est. reading time: 8 minutes

Most redesigns are scoped as design and development projects. New templates, new navigation, often a new platform underneath. Organic search shows up as a single line near the end of the plan, usually “set up redirects,” assigned to whoever has capacity during launch week.

Then the new site goes live, organic traffic drops over the following month, and the team starts investigating a Google update that never happened. The pattern we see when we audit these accounts is consistent. The damage was done months before launch, in decisions nobody flagged as SEO decisions (which URLs survive, what happens to the copy, how the new navigation links the catalog together).

Keeping your rankings through a redesign is mostly a matter of knowing what they are attached to before anything changes, then changing those things on purpose or leaving them alone. That takes an inventory, a URL map, a content freeze, and a launch checklist. Here is the sequence we run.

A website redesign changes what your rankings are built on

Google ranks individual URLs, not the site as a whole, which is why a redesign carries more risk than it appears to from inside the project. A ranking position is the product of a specific URL, the content on it, the internal links pointing to it, and the backlinks it has earned over years. A redesign routinely changes all four at once, then measures the outcome as one traffic number.

So the first deliverable is an inventory, built before design work starts. Pull twelve months of page-level performance from Search Console, sorted by clicks, so seasonal pages make the list. Crawl the current site with Screaming Frog or a comparable tool to capture the full URL set, including the aging blog posts nobody in the planning meeting remembers publishing. Then pull backlinks by page from Ahrefs or Semrush, because a page holding external links is load-bearing even when its own traffic looks modest.

Merge those three exports into a protected list. Every URL that earns organic entrances or holds backlinks goes on it, along with its current title tag, H1, and a saved copy of the body content. That list is the reference point for every decision that follows. The crawl will also surface technical debt worth fixing while developers are already in the code.

Map every changed URL to a one-to-one redirect

If the redesign changes URL structure (a platform switch, cleaner paths, merged categories), every URL on the protected list needs a mapped destination before launch. Google’s indexing pipeline treats a permanent server-side redirect (a 301 or 308) as a signal that the redirect target should become the canonical URL, and permanent redirects cause no loss in PageRank. The mechanism only works when each old URL points somewhere specific.

Build the map as a two-column spreadsheet, old URL to new URL, and have a person review it, because wildcard rules mishandle the exceptions that matter most. Point each redirect at the closest equivalent of the old page, not at the homepage. Google’s site move documentation warns that redirecting many old URLs to one irrelevant destination can be treated as a soft 404, which discards the signals you were trying to carry over. A retired product should resolve to its successor or its category, a merged article to the page that absorbed it, and pages with no equivalent should return a deliberate 404 or 410.

Chains leak. Every extra hop adds latency, and while Googlebot can follow up to 10 redirect hops, Google’s advice is to redirect to the final destination directly. Redesigns stack chains by accident, because new rules get layered on top of redirects left over from the last migration, so update the old rules to point at final destinations as well, and make sure internal links in the new build target new URLs so navigation never routes through the site’s own redirects.

Keep the redirects live long after launch. Google recommends holding them for at least a year so signals finish transferring, and the backlinks still pointing at old URLs are an argument for keeping them permanently.

The new templates rewrite the content that was ranking

Redirects preserve the address. Content parity decides whether the page still deserves its position once Google recrawls it, and this is where redesigns lose rankings while every redirect resolves perfectly.

New templates cut body copy for the sake of visual polish. Product and collection descriptions shrink, FAQ blocks disappear, H1s turn into styled graphics, and a long service page becomes four short panels. Each of those pages was ranking because its content answered specific queries. Remove the answers and the relevance that earned the position goes with them.

Component choices matter here as well. Googlebot renders JavaScript, and it does not interact with the page, so copy that only enters the DOM after a tap or a click is invisible to it. If the new design tucks descriptions into interactive components, confirm the text is present in the rendered source without any interaction.

The protection is unglamorous. Launch every protected page with its existing title tag, H1, and body content intact, and treat copy rewrites as a separate project with its own before-and-after measurement. Google’s migration guidance says to change one thing at a time, moving the site first and changing the layout after, and the same logic covers content. When a redesign and a rewrite ship together and rankings drop, nobody can tell which change caused it.

A rebuilt front end also changes how fast pages load and render, which carries its own ranking implications.

Staging settings that follow the site into production

The most expensive redesign mistakes are configuration, and they ship with the final deploy. Staging environments usually run behind a sitewide noindex tag or a robots.txt that blocks crawling, for the sensible reason that nobody wants a half-built site indexed. Google lists leftover noindex and robots.txt blocks among the most common migration mistakes, because when those settings reach production, pages start dropping out of the index as Google recrawls them, and the decline is gradual enough that teams go looking for other causes. The inverse failure, a staging subdomain left crawlable and indexed before launch, creates a duplicate of the new site, so keep staging behind authentication from day one.

Navigation is the quieter version of the same problem. New designs trim header and footer links to simplify the layout, and every trimmed link removes a crawl path and a share of internal authority from the page it pointed to. A page that lost its rankings after a redesign sometimes lost nothing except the six internal links that used to point at it.

Both problems are catchable with one exercise. Crawl the staging build with JavaScript rendering enabled and diff it against the protected list. Every protected URL should exist, return a 200, keep its title and H1, carry a self-referencing canonical, remain indexable, and hold roughly the internal link count it had before. Then run the identical crawl against production within an hour of launch, because the deploy is the moment staging settings carry over.

What a normal post-launch dip looks like, and when it’s something worse

Even a clean migration moves around for a while. Google is explicit that rankings fluctuate while it recrawls and reindexes after a move, that a medium-sized site takes a few weeks for most pages to settle, and that larger sites take longer. A dip in week one proves nothing by itself. The job in that window is separating reprocessing from breakage, and the checks are specific:

• Crawl the complete old-URL list and confirm every redirect resolves in a single hop to a 200 at the mapped destination.
• Watch the page indexing report in Search Console for spikes in 404s or a growing count of pages excluded by noindex.
• Track rankings on the protected list specifically, because sitewide averages hide movement on the pages that produce revenue.

If the redirects verify, the pages are indexable, and content parity held, give the reprocessing window its few weeks before changing anything. If protected pages are still falling after that window with all three confirmed, one of the earlier steps was missed, and a fresh crawl compared against the inventory will usually show which one.

The whole program comes down to an inventory, a spreadsheet, a content freeze, and two crawls. That short list separates the redesigns that keep compounding from the ones that reset years of accumulated search equity. If a redesign is on your roadmap and you’d rather have the search side run in parallel while the designers work, we’re easy to reach.