The redesign that didn't crater: keeping rankings and citations through a rebuild.

One reframe before the mechanics: your old site's rankings, and the addresses machines have learned to find you at, are an owned asset, often years of accumulated equity (the owned half of the channel argument). A redesign moves the business those assets are attached to. Move them properly and nothing is lost. Leave them behind and the market doesn't send a warning letter; it just goes quiet.

Why relaunches lose traffic

Rankings don't belong to your business, or even to your domain. They belong to URLs. Every position your old site holds is attached to a specific address, along with every link anyone ever pointed at it. Redesigns almost always change addresses: new structure, new page names, pages merged or dropped. When an old URL stops existing and nothing says where its replacement lives, search engines find a dead end, the accumulated equity has nowhere to flow, and the ranking re-enters the contest from scratch. Do that across a whole site simultaneously and you get the cliff. The fix has existed for decades: a 301 redirect (a permanent forwarding address, one per URL) passes both visitors and most of the earned equity to the new page. The disaster and its prevention are both this unglamorous:

The inventory before the IA

The order of operations matters: list what you have before anyone designs what you'll get. Pull every URL the old site actually has (a crawl), every URL earning impressions or clicks (Search Console), every URL other sites link to, and every URL AI assistants send visitors to (where they show up as referrals in your analytics). That list is the estate you're moving. It always contains surprises (an old blog post quietly feeding enquiries, a location page ranking for the exact phrase you'd want), and those surprises are precisely the pages a redesign brief written without the inventory would delete. If a page earns, it either survives in the new structure or gets an explicit forwarding address. Nothing that ranks gets deleted casually.

The redirect map and the parity checks

The map itself is a two-column table: every old URL, and the single new URL that most closely replaces it. The standard is closest equivalent, one to one: the old support page goes to the new support page, not to the homepage. Blanket-redirecting everything to the homepage is the classic shortcut, and search engines treat it roughly as politely as customers would. Then parity: for the pages that earn most, check the new versions haven't quietly shed what earned it: the title and heading still say what the page is for, the substance survived the copy "refresh", the structured data that described it survived the new templates, internal links still point to it, and it's at least as fast on a phone. A redesign that keeps addresses but replaces ranking pages with thinner, prettier ones craters politely, a few weeks later. And parity includes the job the page does for humans (turning the visit into an enquiry), because keeping the ranking while breaking the enquiry path is its own way to lose the rebuild.

Launch day, verified

On the day: spot-check the map by actually visiting old URLs (the important ones, from a phone, logged out) and watching them land on the right new pages, in one hop. Submit the new sitemap. Keep the old sitemap's URLs reachable-as-redirects rather than instantly deleted, so engines can find every forwarding address. Then watch Search Console for the two failure smells: a rising count of not-found errors (planks you missed; fix them as they surface) and money pages losing impressions (parity problems). Days of vigilance, not months.

The agent-native lens: addresses that software remembers

When software holds your old addresses. People and search engines aren't an old URL's only audience. Answer engines cite specific pages and may go on citing them after a move, assistants follow those citations, and other companies' tools may call your feeds or endpoints directly. A redesign can break all three without a single visible error. So add the machine-facing addresses to the inventory: product or price feeds, the sitemap, documentation and release-notes pages, any API, and any MCP server whose tools other people's agents may already call by name. Forward what moves, keep anything that gets called working until its callers have switched, and announce the change where integrators will see it. And check the schema.org JSON-LD template by template: if the new design drops the markup that stated prices, hours or specifications, assistants lose the facts while the page looks complete to a person.

When the migration runs on agents. Most of this checklist is clerical, which suits agents. One can merge the crawl, the Search Console export and the link list into the inventory, then propose the closest new URL for each old one by comparing content. On launch day it can request every old address and confirm one hop, the right status and a heading that matches the map, then diff not-found errors and money-page impressions daily. A person approves every row of the map, because the closest match by wording isn't always the closest match by intent. Keep the map, the approvals and the test runs together as the record of what moved where.

If it already fell

If you're reading this after the relaunch, with the cliff behind you: the same work still works, and sooner is better. Recover the old URL list (crawls of the old site linger in archives, and Search Console remembers what earned), build the map now, and put the redirects live. Equity fades at a dead end, but much of it survives weeks and even months of neglect. Restore any earning pages that were deleted outright. Most "the new site killed our SEO" stories are actually "nobody built the bridge" stories, and the bridge can usually still be built. The deeper technical half of that rescue (crawlability, indexing, the machinery under the pages) is its own discipline: technical SEO. Whichever side of the relaunch you're on, keep the result: the URL list, the redirect map, the machine-facing endpoints and the structured data, documented and current, so the next rebuild starts from a list instead of an excavation.