Website Redesign Services

Highly likely if preservation is not planned, and close to avoidable if it is — the causes are well understood and none of them are mysterious. In order of frequency: ranking URLs that now 404 because the new structure did not include them, redirects pointing everything to the homepage rather than to equivalent pages, content removed because it did not suit a new template, heading and internal linking structures rebuilt for visual design with no regard for the previous link graph, and staging noindex directives shipped to production. Notice that four of those five are decisions made during design, which is exactly why the preservation audit has to come first. When a redesign drops traffic and the cause is attributed to an algorithm update, the actual explanation is almost always on this list, and it can usually be confirmed within an hour by crawling the old URL inventory against the new site.

Usually yes, and the recovery is more mechanical than most people expect, because the underlying loss is structural rather than a quality judgment. We reconstruct the pre-redesign URL inventory from Search Console history, archive crawls and backlink data, identify which of those URLs held rankings or external links, and build the one-to-one redirects that should have existed. Where content was deleted rather than merely moved, we restore it into the current design. Two things degrade over time and argue for acting quickly rather than waiting. External links pointing at deleted URLs eventually get removed or updated by the referring sites, and once that happens the equity is genuinely gone rather than merely disconnected. And the longer a URL returns 404, the less crawl attention it receives, so restoration takes longer to be noticed. Recovery at three months is routine; at eighteen months it is partial.

By what it earns, assessed against three inputs: impressions and clicks from Search Console, external links pointing at it, and whether another page on the site already covers the same search intent. A page with meaningful traffic or links is kept and redesigned, regardless of whether it fits the new layout neatly — the layout accommodates it, not the other way round. A page duplicating another page's intent gets consolidated, with the weaker URL redirected into the stronger and its useful content merged in, which usually improves rankings because it ends a cannibalisation problem. A page with no traffic, no links and no distinct intent is removed, and even then we record the decision rather than defaulting to a 404. The failure mode we are guarding against is the reverse process — deciding what to keep by looking at a design comp and asking what fits.

It depends on which risk you would rather carry, and both are legitimate. A single relaunch is faster, cheaper and gives a coherent result, but concentrates all the risk on one day and makes diagnosis harder if something goes wrong, because dozens of variables changed simultaneously. A phased rollout — template by template, or section by section — isolates risk and lets you verify each change against real data before continuing, but costs more, takes longer, and means running two visual systems concurrently for months. Our rule is that if the site is a significant revenue channel and the current traffic is genuinely valuable, phasing is worth the cost; if traffic is modest or the current site is performing poorly enough that there is little to protect, a clean relaunch is the better use of budget. What is never acceptable is a single relaunch without a verified redirect map, which is simply the risk of phasing plus the risk of relaunching combined.

Conversion paths were almost certainly reorganised for visual cleanliness, and this is common enough that we check it before anything else. The specific culprits recur: a phone number that moved out of the header into a contact page, a form that moved below the fold or onto its own page, proof and testimonials relocated to a dedicated page nobody visits, and calls to action restyled to be visually quieter and consequently less noticed. Each change is individually defensible on design grounds and collectively costs a meaningful share of enquiries. The diagnosis is a template-by-template comparison of the pre- and post-launch conversion paths, ideally against recorded session data, and the fix rarely requires reverting the visual work — it requires restoring the specific elements that were carrying the conversions. This is also why we set conversion tracking before a redesign rather than after, because without a baseline the comparison is guesswork.

For a typical service business site, eight to sixteen weeks from kickoff to launch, and the variable that moves it most is not design or development — it is content and stakeholder decisions. The preservation audit takes about a week. Structure and design run three to five weeks. Build runs four to eight depending on template count and content modelling. What extends projects past those ranges is almost always waiting on content that only the client can provide, or unresolved internal disagreement about structure, which is precisely why the page inventory comes first: it forces those arguments into week one where they cost days rather than into week ten where they cost a redesign. We would rather quote a realistic timeline including the content dependency than an optimistic one that assumes it away, since a project that stalls at 80% for two months is worse for everyone than one that took two more weeks up front.