How to Plan a Website Redesign Without Losing Traffic

A redesign loses search traffic when a URL stops resolving, a ranking page's content gets thinned out, or a title tag changes without anyone checking what happened next — not because the new design looks different. Google's own documentation on moving a site is explicit that the mechanism, not the look, is what matters: a permanent redirect is what carries a page's ranking signal to its replacement (Google Search Central, "301 redirects", checked September 2026). Plan the redesign in this order — inventory, URL decisions, content, testing, launch, monitoring — and a new look doesn't have to cost you anything you already earned.

Step 1: Inventory every page you currently have

Before any design work starts, get a complete list of what's actually live and what's actually getting traffic. Two sources, combined:

• Google Search Console's Pages report (or Performance filtered by page) shows what's indexed and what gets clicks and impressions today. This is your priority list — anything on it needs a decision before launch, not after.
• A full crawl of the live site, using any crawler that follows internal links, catches pages Search Console hasn't surfaced yet, including ones with external backlinks but little direct search traffic.

For each URL, record its type (homepage, blog post, product, category, landing page) and whether it currently ranks for anything you can identify. A redesign that treats "the site" as one object, instead of a list of specific URLs with specific jobs, is how individual pages get dropped without anyone noticing until traffic falls.

Step 2: Decide, per URL, whether it stays or gets redirected

This is the step most redesigns skip, and it carries the actual search-traffic risk. For every URL in your inventory, decide one of three things: it keeps its exact current address, it moves to a new address with a redirect, or it's retired with a redirect to the closest remaining equivalent.

Google's guidance names the mechanism directly: "Use server side permanent redirects if technically possible," and it recommends HTTP permanent redirects "such as 301 and 308" (Google Search Central, "Site moves with URL changes", checked September 2026). A 301 tells Google the move is permanent, not a temporary detour.

If you're only redesigning the look and keeping the same domain and paths, this step is short — confirm every existing URL still resolves once the new design is live, and you're done. If the redesign changes your URL structure, you need a specific new-address mapping for every URL, not a blanket redirect to the homepage. Our redirects checklist covers building that mapping and setting the redirect on common platforms in more depth than repeated here.

Step 3: Fix the content before you touch the layout

Redesigning the visual layer before the content is settled means redesigning around copy you're about to rewrite anyway. Go through your priority list from Step 1 and, for each page that matters, ask what it needs to say and whether it currently says that clearly. Consolidate thin, overlapping pages into one stronger page rather than launching a new layout around several weak ones — when you do that, the consolidated page needs its own redirect plan for whichever URLs it replaces, from Step 2.

Keep your existing page titles and meta descriptions unless you have a specific reason to change one. If a page ranks, its title is part of why it ranks; change titles individually and watch what happens rather than rewriting all of them the same week you also change the layout, the URLs, and the content. Stacking every kind of change into one launch makes it much harder to tell which change caused a traffic drop if one shows up.

Step 4: Test on a real environment before it's public

Google's own guidance for a hosting or infrastructure change describes exactly this kind of pre-launch check: "Create a testing environment, perhaps with IP-restricted access, through which you test all of the features before the website goes live" (Google Search Central, "Changing your web hosting and SEO", checked September 2026). The same page recommends opening the new site directly and reviewing "pages, images, forms, and downloads (such as PDF files)" (same source), and, for broader testing before the real domain switches over, using "a temporary hostname for your new infrastructure (like beta.example.com) so you can test accessibility by browsers" (same source).

Before launch, also confirm Google itself can reach the new version: the same guidance points to "the URL Inspection Tool in Search Console" to check that a search crawler can access the new infrastructure (same source). A design that looks right to you in a browser and a page that a crawler can actually fetch and index are two different checks — do both.

Step 5: Launch, with redirects live from the first moment

Launch only after Steps 1 through 4 are done, not as the step where you find out what's missing. If you're changing domains or subdomains as part of the redesign, file a Change of Address request in Search Console at this point — Google's documentation notes this applies specifically when "moving from one domain or subdomain to another (such as example.com to example.net, or a.example.com to b.example.com)," and isn't needed for a same-domain redesign (Google Search Central, "Site moves with URL changes", checked September 2026).

On how long to keep old-URL redirects running, Google's own pages give two different minimums: its site-moves documentation says "Keep the redirects for as long as possible, generally at least 1 year" (Google Search Central, "Site moves with URL changes"), while its Search Console help page on the Change of Address tool says "Maintain the redirects for at least 180 days" (Google Search Console Help, "Change of Address tool", checked September 2026). Since Google's documentation doesn't agree on one number, the safer reading is the longer one — keep redirects live for at least a year, and don't remove them at 180 days just because a different Google page names that as a minimum.

Step 6: Monitor Search Console after launch, not before

The work isn't done at launch. Google's hosting-change guidance recommends watching "the server logs on both new and old servers" to see traffic actually migrating, checking DNS propagation with public DNS tools if you moved infrastructure, and watching the "Index coverage graphs in Search Console" for crawling activity (Google Search Central, "Changing your web hosting and SEO", checked September 2026). The same page notes something worth expecting rather than panicking over: "it's normal to see a temporary drop in Googlebot's crawl rate immediately after the launch, followed by a steady increase over the next few days" (same source).

In the weeks after launch, check Search Console's Pages report specifically for a spike in "Not found (404)" or "Page with redirect" results — either one usually traces back to a URL your Step 1 inventory or Step 2 mapping missed. Add the missing redirect as soon as you find it; a gap found in week three is recoverable, a gap nobody ever checks for isn't.

Website redesign checklist

• Full URL inventory from Search Console's Pages report and a live site crawl, with each page's type and current search performance noted.
• A decision recorded for every URL: keep as-is, redirect to a new address, or redirect to the closest remaining page.
• Every planned redirect is a real 301, mapped to a specific new URL — never a blanket redirect of unrelated pages to the homepage.
• Content reviewed and, where needed, consolidated or rewritten before the new layout is built around it.
• Existing page titles and meta descriptions kept unless there's a specific reason to change one, changed individually rather than all at once.
• New design tested in a restricted or temporary environment, checking pages, images, forms, and downloads.
• URL Inspection Tool checked in Search Console to confirm the new pages are reachable by Google before public launch.
• Change of Address filed in Search Console, only if the domain or subdomain actually changed.
• Redirects kept live for at least a year after launch, not removed at the first minimum figure you find in Google's documentation.
• Search Console's Pages report checked weekly for the first month after launch for 404s or unexpected redirect chains.

Where does this differ from a full platform migration?

This guide assumes the domain, or at least most of the URL structure, stays largely the same — a visual and content redesign, not necessarily a move to a different builder or host. If you're also changing platforms, the steps above still apply, but you're also taking on export, email, forms, checkout, and domain-transfer mechanics a same-platform redesign doesn't touch. Our website migration checklist covers that fuller list, and our guide to using AI to redesign your website covers where AI can speed up the content and audit work in Steps 1 and 3.

Where does Figment fit into a redesign?

If part of the plan is to design the new version in Figma and publish it through Figment, the URL and content steps above still apply — Figment's paid plans support a custom domain, and it publishes real, server-rendered HTML that a crawler can read directly. Figment doesn't run redirects, forms, or a CMS itself, so the redirect mapping from Step 2 still needs to be set at whichever DNS or hosting layer sits in front of the published site. One advantage of designing the redesign in Figma first: you can build the new version in the same file as the old one, side by side, and only publish once you're ready, rather than working against a half-finished live site.

Bottom line: a redesign doesn't cost you traffic on its own. An un-redirected URL, a title changed without anyone watching, or a page nobody tested against a real crawler does. Inventory first, decide every URL's fate before you touch layout, fix content before design, test in a real environment, launch with redirects already live, and keep checking Search Console for weeks afterward — that order is what keeps a new look from becoming a traffic loss.