How to Do SEO During a Website Redesign

A redesign destroys organic traffic through a small set of preventable mistakes: changing URLs without one-to-one redirects, shipping a staging noindex to production, removing pages that hold backlinks, and bulk-redirecting everything to the homepage. None of these are subtle algorithm effects; they are release defects. So protecting SEO through a redesign means treating it as a software release with a measured baseline, a complete redirect map, staging verification, and a rollback plan, not as an afterthought the design agency quietly “handles.”

This post owns the redesign case: URLs, templates, or the CMS may change while the content is largely preserved, on the same domain. The redesign-specific layer is what it covers, namely the staging-noindex-to-production discipline, template and design-change handling, and the script for pushing back on an agency. The generic redirect mechanics, how 301s work, redirect-chain hygiene, and the at-launch Change of Address, belong to the live-migration playbook; reference them, do not re-teach them. And if the domain identity itself changes, that is the post-move recovery case, not this one. This post is same-brand redesign or replatform, and the redirect discipline here is scoped to the release, not to parameter canonicalization.

Baseline before you touch anything

The work starts before a single template changes, because you cannot measure recovery without a benchmark. Export the top pages by organic traffic, the queries and positions you currently rank for, the complete list of indexed URLs, and every page that has earned backlinks. This snapshot is the recovery benchmark and the source of your redirect map; capture it from Search Console (Performance for queries and top pages, the Page Indexing report for the URL inventory) and your backlink tool, and store it where you can compare against it weekly after launch. Skipping this step is the most common reason a redesign that lost traffic can never be diagnosed: there is nothing to compare the new state against.

The one-to-one redirect map

Every old URL needs an explicit fate, decided deliberately rather than left to a catch-all rule. The fates are: unchanged and still live; 301 to its direct equivalent; 301 to the page it was merged into; 301 to the nearest genuinely relevant page when no exact equivalent exists; or 410 if the page is truly valueless and carries no equity. Build this as a row-per-URL map so that no URL falls through.

Push back hard on bulk-redirecting unmatched URLs to the homepage. A mass redirect to the homepage signals to Google that there is no equivalent content, which tends to be treated as a soft 404, so the equity is lost rather than transferred and the user lands somewhere irrelevant. The same logic applies to redirecting every blog post to the blog index. Each redirect should land on the most relevant specific destination available, and only fall back to a section page, never to a blanket homepage rule.

Merging and removing pages

When the redesign consolidates several pages into one, redirect all the originals to the consolidated URL and carry their content over, so the signals the originals earned transfer to a page that actually contains the material they ranked for. A redirect to a page that dropped the content is a relevance mismatch and loses the ranking.

When the redesign removes pages, check backlinks and rankings before deleting. A page with no equity and no traffic can be left to 404 or 410 cleanly. A page that holds backlinks or still ranks should be kept, or redirected to the nearest relevant live page so its equity is not stranded. The baseline export is exactly what tells you which pages fall into which category.

Staging discipline and the production swap

Staging environments should be noindex so Google never indexes the work-in-progress, and that is correct. The disaster is the inverse failure at launch: the staging configuration, including its noindex or its restrictive robots.txt, ships to production unchanged, and the live site quietly tells Google not to index it. Sites have lost their entire organic presence this way, and because nothing visibly breaks, it can go unnoticed for days.

Verify the swap explicitly. Within the first hour after launch, confirm the production robots.txt is the crawlable production version and not the staging one, and confirm no production page carries a leftover noindex from the staging build. This single check prevents the most catastrophic and most common redesign failure, and it takes minutes.

The leftover-block problem has more than one form, so check each. A noindex can live in a meta robots tag in the page head or in an X-Robots-Tag HTTP response header, and the header version is easy to miss because it does not appear in the rendered source. A staging environment also frequently sits behind HTTP authentication or an IP allowlist that blocks crawlers entirely; if any of that survives the swap, Googlebot gets a 401 or 403 instead of the page. Crawl a representative sample of the live site with a crawler set to ignore nothing, and confirm every template returns 200 with an indexable directive. Do the same for the canonical tags, because a staging build that hardcoded canonicals to the staging hostname will, after launch, point every production page at a domain that no longer serves content.

Launch and post-launch

In the first hour, run three checks: the production robots.txt is correct, representative redirects across every URL pattern return 301 to live destinations, and no noindex survived from staging. Spot-check the high-value URLs from your baseline specifically, since those carry the most equity.

Define rollback triggers in advance so the decision is not made in a panic. Triggers that warrant rolling back or hotfixing immediately: the site is down, redirects are failing en masse, or an accidental noindex or robots Disallow is live. Conditions that are not triggers: minor styling differences, and the normal ranking fluctuation that follows any significant change while Google re-crawls and re-evaluates the new templates. Distinguishing the two prevents both ignoring a real catastrophe and panicking over expected noise.

Then monitor against the baseline for weeks. Watch indexed count, impressions, positions, and traffic on the pages you captured before launch, and investigate sustained divergence rather than reacting to day-to-day movement. Recovery and re-evaluation are crawl-rate dependent, so treat the timeline as qualitative and the baseline comparison as the real measure of whether the redesign held.

The agency-pushback script

“We’re handling SEO” from a design or development agency usually means they will set meta titles and submit a sitemap, not that they have built and verified a one-to-one redirect map. Ask for the specific artifacts: the redirect map as a row-per-URL document with a fate for every existing URL, written confirmation that the production robots.txt swaps in at launch, and the rollback plan with its triggers. If those three do not exist, the SEO is not actually being handled, regardless of the assurance. The fates table and the staging-robots check are the two artifacts that prevent the launches that destroy traffic, so they are the two you insist on seeing before go-live.

Frequently Asked Questions

Can I just redirect all my old URLs to the new homepage to be safe?

No. Bulk-redirecting unmatched URLs to the homepage tends to be treated as a soft 404, so the equity is lost rather than transferred and users land somewhere irrelevant. Give each old URL a specific fate: its direct equivalent, the page it merged into, the nearest relevant page, or a clean 410 if it is genuinely valueless.

My traffic dropped after launch even though the redesign went smoothly. What should I check first?

Check the production robots.txt and look for a leftover noindex from staging, because shipping the staging configuration to production is the single most common cause and it is invisible in the page’s appearance. Then confirm representative redirects across every URL pattern return 301 to live destinations rather than 404s or chains.

Sources

Google Search Central, “Site moves with URL changes”: https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
Google Search Central, “How to handle redirects for Google Search”: https://developers.google.com/search/docs/crawling-indexing/301-redirects
Google Search Central, “Robots.txt introduction and guide”: https://developers.google.com/search/docs/crawling-indexing/robots/intro