A website redesign is the most dangerous purchase a personal injury firm makes, and almost nobody involved in selling one says so. The danger is not the new design. It is what the project quietly does to the site's accumulated history: the URLs, the links, the structures that years of visibility were built on, all of it movable, all of it droppable, none of it visible in the mockups the partners approve. This piece is the preservation protocol: why redesigns tank traffic, what the machinery actually tracks, and the sequence that lets a firm get a new site without donating its history to the void.
To the systems that decide your visibility, your site is not a brand. It is a set of documents, each with an identity, a history, and an accumulated record: what links to it, what it has been about, how it has behaved over time.
The patent record is blunt about how literal this is. Google's document-identification patents, US 9411889 and its family, describe assigning persistent identification tags to documents; the crawler's anchor-indexing patents, US 10210256 among them, describe tracking what links say about each document and scheduling attention partly by URL change behavior. The machinery is an archive of document identities, and the value your site has built lives in those identities.
A redesign, done carelessly, is an identity massacre. URLs change because the new CMS prefers different patterns. Pages get merged, split, or dropped because nobody inventoried them. The internal links that concentrated authority get regenerated from a new menu. In one launch weekend, the archive's carefully accumulated records point at documents that no longer answer, and the system does what any archive does with dead references: it starts forgetting.
That is the mechanism behind the industry's most common horror story, the post-launch traffic cliff. Not a penalty. Not an algorithm update that happened to coincide. An identity transfer that never got executed, by a project that never knew it was responsible for one.
The repair begins with a reframe for the owner approving the budget: a redesign is two projects wearing one invoice.
Project one is the visible one: new design, new platform, new content presentation. Designers and developers own it, and they are usually good at it.
Project two is invisible and carries most of the commercial risk: the identity transfer. Every existing URL mapped to its successor. Every page's accumulated history escorted to its new address. The internal architecture rebuilt deliberately rather than regenerated accidentally. Nobody owns project two by default, because designers are not paid for it and owners do not know it exists. The protocol below is project two, written down.
Inventory before anything. Every URL the site has, with its traffic, its external links, and its purpose, captured BEFORE design work begins. This is the only moment the full picture exists; after launch, the evidence of what was lost is itself lost. The inventory is also where the redesign earns a bonus: it is the natural moment for the prune-merge-keep pass, because moving house is when you decide what not to pack.
The redirect map, one to one, written, reviewed. Every old URL resolves to its most equivalent new home: page to its successor, never everything to the homepage. The map is a document, owned by a name, reviewed against the inventory, and finished before launch, not reconstructed in a panic two weeks after. Blanket homepage redirects are the signature of a project that skipped this step, and the machinery treats them as the mass disappearance they are.
Preserve what the pages ARE, not just where they live. Titles, headings, the content that earned each page its queries, the structured data declaring what the firm is, the authorship layer: all inventoried, all either carried over or changed on purpose with a reason logged. Redesigns love to "freshen" the exact elements the archive used to understand each document, and every unforced rewrite is a new identity the system must re-learn from scratch.
Rebuild the internal architecture deliberately. The new menu and templates will regenerate the site's internal link graph, which is the authority distribution system. Decide it: which pages deserve concentration, which hierarchy teaches geography and topics, parent above child. My own restructure ran this way, every flat address redirected into a nested hierarchy mapped in advance, because structure is information and launch is when you either state it or scramble it.
Launch like a surgeon, then watch the instruments. Stage the full redirect map before cutover. On launch, verify the map live, submit the new reality to the search consoles, and then watch the only honest instruments daily for the first weeks: crawl activity, index coverage, 404 reports, and the server logs where bots narrate exactly what they are finding. The logs are where a leaking migration confesses first, long before the traffic chart does.
A quiet rule separates the clean migrations from the forensic ones: change one variable per launch. Redesigns attract passengers. The firm is rebuilding anyway, so the rebrand comes aboard, then the new domain, then the platform switch, then a content rewrite, and the launch weekend ships five identity changes in one cutover. When traffic drops after that, nobody can say which change did it, and the recovery is guesswork because the experiment had no controls.
The disciplined sequence holds the variables apart. If the domain must change, move the domain first, same site, same URLs where possible, and let the move settle until the instruments read steady. If the content needs rewriting, rewrite it on the live site before the redesign, page by page, where each change's effect is observable. Let the redesign itself change what a redesign must change, the design and the platform, while the protocol escorts everything else across unchanged. Each step is individually boring, individually measurable, and individually reversible, which is exactly what a launch weekend of five simultaneous changes is not.