Redesigning a website without losing your rankings

Have this conversation before design starts, not after.

A redesign is a trade. Something is being improved — brand, conversion, maintainability, speed — and something is being risked. Name both. Specifically:

• Which pages carry organic traffic that the business depends on.
• Which pages have inbound links from elsewhere.
• Which pages convert, regardless of traffic.
• Which of those are allowed to change substantially, and which are not.

In most cases a small number of pages account for most of the organic value. Those pages get protected treatment: same URL, same or expanded content, same internal links pointing at them. The rest of the site can be redesigned freely.

If the answer is "everything must change", that is a legitimate business decision, but it needs to be made consciously with the traffic cost acknowledged, not discovered afterwards.

Do this before the new site is built, because it changes the build.

1. Export every URL the current site has. Crawl it, then add anything the crawl missed: analytics data, your sitemap, search console data, server logs if you have them. Crawls miss orphaned pages that still receive traffic and links.
2. Attach metrics to each URL. Organic sessions, conversions, inbound referring domains, and ranked queries. This is your protection list, in priority order.
3. Record current on-page elements for every page that matters. Title, meta description, H1, word count, and the main headings. You will need this to verify nothing was quietly shortened during the redesign.
4. Map internal links to your top pages. Count how many internal links point at each one and from where. Flattened navigation is a common and invisible cause of post-launch decline.
5. Note current structured data. Which pages have it and of what type. It is routinely dropped in a rebuild because nobody on the design side knows it exists.
6. Save a copy of robots.txt and all sitemaps.
7. Screenshot or export your current search console performance. You will want an uncontested baseline when someone asks whether traffic dropped.

Keep this in one spreadsheet. It is the single most useful artifact of the whole project.

Every old URL needs a destination. Work through it row by row.

Three rules that prevent most of the damage:

Use permanent redirects for permanent moves. Temporary redirects signal that the old URL is coming back.

No chains. Old URL to new URL in one hop. Redesigns frequently layer new rules on top of redirects from the last redesign, producing four-hop chains. Resolve them to single hops.

Never bulk-redirect to the homepage. It is treated as a soft 404 and it is a bad experience. If there is no equivalent page, return the correct error status.

Test the map on staging before launch. Every row. A spreadsheet of intended redirects is not a tested redirect map.

This is the loss nobody anticipates, because it comes from the design process working as intended.

Redesigns make pages cleaner. Cleaner usually means shorter. A page that ranked because it answered a question thoroughly can lose that ranking when the answer is trimmed to fit a tighter layout, even though the URL never changed.

Check these against your inventory before launch:

• Body content on protected pages is equivalent or better. If the new template cannot hold the content, the template is wrong for that page.
• Titles and H1s are intact. Design systems sometimes standardize headings in ways that remove the terms the page ranked for.
• Internal links to key pages survived. If a footer or sidebar used to link to your top pages and the new design removed it, replace that pathway somewhere.
• Structured data is reimplemented. Products, articles, FAQs, organization, breadcrumbs — whatever was there.
• Images keep alt text and meaningful filenames.
• Canonical tags point at self, not staging.
• Pagination, faceted navigation and parameter handling behave as before. New frameworks often generate URL variants the old site did not.

Two specific failure modes, both common and both severe.

Staging gets indexed. Protect staging with HTTP authentication, not just a noindex rule. Authentication cannot be forgotten at launch.

The block ships to production. This is the more damaging one. A site-wide noindex or a robots.txt disallow carried from staging to production removes the entire site from search results, and it can take days before anyone notices. It must be an explicit, verified item on the launch checklist, checked on the live site after deployment.

Have this written and assigned before launch day. In order.

1. Deploy during a low-traffic window, with the people who can roll back available.
2. Verify robots.txt on the live domain. First check, every time.
3. Check for noindex on the live site. Homepage and a sample of templates. View the rendered source and the HTTP headers.
4. Spot-check redirects on live. Your top 50 URLs by traffic, by hand or by script. Confirm single-hop permanent redirects to the right destinations.
5. Submit the new sitemap in search console and remove obsolete ones.
6. Confirm analytics and tag firing. On the templates that matter, not just the homepage.
7. Verify canonical tags resolve to live URLs.
8. Request indexing on your most important pages.
9. Crawl the live site immediately. Compare against your inventory. Look for unexpected 404s, redirect chains, missing titles.
10. Announce completion with the inventory attached, so anyone investigating later has the baseline.

Assign one person. Check weekly, not daily — daily noise will make you change things you should leave alone.

• Crawl errors and 404s in search console and in server logs. Server logs catch what crawls miss.
• Index coverage. Pages dropping out of the index is the earliest hard signal.
• Impressions and clicks by page, compared against your pre-launch baseline. Page level, not site level, because a site average hides which template broke.
• Query-level movement on protected pages. If a page lost a specific term, compare the new content to your recorded inventory for that page.
• Core Web Vitals. New builds frequently ship heavier than the site they replaced.
• Referral traffic from inbound links. A drop here points at a redirect that is not working.

Expect fluctuation in the first few weeks as redirects are processed and pages are re-evaluated. Distinguish that from a trend. A decline still deepening after a month is a problem to diagnose.

The redirect map is built after launch. It becomes archaeology instead of planning.

The inventory was a crawl only. Orphaned pages with links and traffic get missed entirely.

Content shortened for layout reasons. Nobody connects the traffic loss to the copy decision made three months earlier.

Noindex shipped to production. Severe, invisible for days, and entirely preventable with one checklist item.

No baseline export. Then the conversation about whether traffic dropped has no agreed facts in it.

No owner for the 30-day watch. The project is marked complete at launch, which is exactly when the risk begins.

The inventory and redirect map are not a post-build task. They belong in discovery, because they determine which templates have to hold substantial content and which URLs are not available to change. On our builds this runs in parallel with design rather than after it, and it is part of how website design and development gets scoped — including the launch runbook and the 30-day watch as named deliverables with a named owner, which is also why that watch period shows up in pricing rather than being absorbed quietly.

Agree what better means before the work starts. If the target is no loss of organic traffic, say so, and accept the constraints it places on the design.