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.
Why redesigns tank traffic: the identity problem
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 two projects inside every redesign
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.
The preservation protocol
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.
One variable at a time
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.
The same logic sets the calendar. Schedule the cutover for the firm's quietest stretch, never ahead of a season intake depends on, and freeze all other site changes for the weeks around it: no new pages, no title experiments, no plugin spring-cleaning while the archive is busy re-learning the site's identity. The freeze is not superstition. It is keeping the control group clean, so that whatever the instruments show in week two has one candidate explanation instead of six. Firms resist the slower sequence because the invoice arrives as one project; the archive, meanwhile, processes it as a series of identity claims, and it extends more trust to a site that changes one thing at a time than to one that becomes unrecognizable overnight.
What to demand from whoever builds it
Owners cannot run the protocol themselves, and should not have to. They need only enforce its existence, with questions any vendor should answer in writing before the contract is signed: Where is the URL inventory, and when in your process is it taken? Who writes and reviews the redirect map, and will we see it before launch? What is your policy on changing titles, content, and structure during migration? What gets monitored in the first thirty days, and who reports it? A builder with crisp answers has done this before. A builder who waves at "SEO is included" is pricing project one and hoping project two does not exist.
This is also precisely the moment a pre-redesign audit pays for itself twice: once by establishing the baseline the migration must preserve, and once by finding the gaps the new build should fix rather than faithfully recreate. It is standing work in my Diagnostic for exactly this scenario, the audit run BEFORE the rebuild, so the firm knows what it owns, what it owes, and what the new site must not break: nine deliverables, findings ranked, refundable until the roadmap is clear.
The honest reassurance
Done with the protocol, redesigns are safe; I have moved entire architectures without losing what mattered, my own included, and the watching weeks afterward were boring, which is what success looks like here. The cliff stories all share one anatomy: no inventory, no map, no owner for project two. The firms that fall are not unlucky. They are unprotocoled, and the difference costs a spreadsheet and a conscience.
My free PI Authority Scorecard includes the question that predicts redesign outcomes better than any portfolio: does your firm know, today, which of its pages carry its visibility? Ninety seconds, scored, with a PDF and a short Loom back. Know what you own before anyone rebuilds the building around it.
The technical foundations behind all of this are free at behzadhussain.me with the research at behzadhussain.me
A new website should be a renovation, not an amnesia. Inventory, map, escort, verify, and change one thing at a time. The history your firm spent years building deserves a moving crew, not a demolition one.