When a website redesign pays off — and when iteration still wins

Read ten agency pages about website redesigns and you get the same list ten times. The design looks dated. The site loads slowly. The layout falls apart on a phone. Rankings are slipping. Every edit in the CMS is a chore. Every one of those observations is fair. Not one of them is a criterion. They are triggers. A trigger explains why you are thinking about a rebuild right now. A criterion explains whether a rebuild is the right answer. The distance between the two is a decent slice of your annual budget.

So I turn the question around. Not: what bothers you about your website? Instead: what change are you trying to achieve, and does it genuinely force a new structure? Almost every symptom on that list can be fixed without rebuilding anything. A slow template gets swapped out. A useless contact form gets replaced in an afternoon. Even a dated design can be renewed one page type at a time without killing a single URL. What you cannot fix in increments is an information architecture that was cut in the wrong places.

That a website is never finished, and that optimisation stays a process rather than a project, is an argument I have made at length elsewhere. I won't rehearse it here. This article runs in the other direction: it looks for the threshold at which iteration stops doing the job.

There is a dull reason the distinction goes missing so reliably. For the agency you hire, a rebuild is the bigger project. A guide that steers you toward iteration sells a retainer. A guide that steers you toward a rebuild sells a project. That isn't an accusation, it explains why the symptom lists look so alike. I'll run the counter-calculation anyway, because a rebuild started for the wrong reason gets paid for twice: once in the project, and once in the visibility that follows it.

For that you need three things that rarely appear together on this topic: the possible paths kept apart, a price tag on each path, and a time cost. The time cost is the interesting part. It puts a number on what a rebuild takes out of your organic visibility before it delivers anything at all. Start with the paths.

First things first: a website rebuild is not one project. It is three very different projects sharing one word. Keep them apart and quotes become comparable. Blur them and you end up comparing offers that have nothing to do with each other, wondering why the range spans a factor of ten.

Path 1: iterate on what you have. The structure stays, the URLs stay, the technology stays. You work in stages: renew page types one by one, improve load time, bring the content along, measure, repeat. My cost anchor for this comes from our own projects, not from market research: budget 15 to 20 per cent of the original build cost per year. As an ongoing engagement that lands between €2,000 and €8,000 a month with us. If iteration is meant to genuinely replace a rebuild, expect the upper end of that range, because at that point you are not maintaining, you are building.

Path 2: partial rebuild on a stable URL structure. New design, new front end, often a new CMS. The page logic, and with it the URL inventory, stays untouched. This is the path most mid-sized companies actually mean when they ask for a new website. From the outside it looks like a new build. Inside, it is a refit.

Path 3: full migration. New information architecture, new URL structure, sometimes a new domain. Everything gets touched, which is exactly why everything can break. This is the only path that carries the full SEO risk.

How do you tell which path you are on? One question does it: does the list of your addresses change? If every URL survives, you are on path 1 or 2, no matter how radical the new design looks. The moment addresses disappear, move, or get re-cut, you are on path 3, even if the design stays identical. I ask this in every first conversation, because it predicts risk better than any brief. Anyone who cannot answer it has no URL inventory, and that is already the first finding.

I won't repeat the price ranges for paths 2 and 3 here. They sit, with the scope each one covers, on our page for B2B website projects, including the audit entry point. The number that actually decides the question appears in none of those quotes, because it only falls due after go-live.

To be clear about the term: the time cost is not the project timeline. It is the time that passes after go-live until your organic visibility is back where it was before. During that window you are paying for the new design and receiving fewer enquiries than you did before. Between the three paths this window differs by orders of magnitude, and almost nobody spells that out.

Path 1 costs no time at all. URLs persist, signals persist, you change pages individually and measure after each stage. If a change does damage, you see it on one page template rather than across the whole domain.

Path 2 costs days to weeks. As long as every address survives, the signals stay attached to it; Google only has to re-crawl the templates and content you changed. If a partial rebuild does move individual addresses after all, Google's own guidance for site moves with URL changes applies to those pages: "a small to medium-sized website can take a few weeks for most pages to move". The condition is a complete redirect map using permanent redirects.

Path 3 costs a year if you are unlucky. This is where hard data finally exists. In June 2026, SALT.agency analysed 1,052 domain migrations. The median time to recovery is 304 days, the mean 489 days. After 90 days, 22.8 per cent had recovered; after 120 days, 27.8 per cent. Around 42 per cent took longer than twelve months, and 13.9 per cent never reached their old level within three years. Recovery is defined strictly here: the point at which the new domain's monthly organic traffic meets or exceeds what the old domain did before the migration.

That limit matters enough to belong in the same paragraph. SALT measured domain migrations. Those numbers are the price tag for path 3, not for every rebuild. Keep the domain and swap templates and you are not buying 304 days. Rebuild the URL structure on the same domain and you land somewhere in between, and any transfer of the SALT figures to that case is an estimate. The data set deserves one honest caveat too: the cases come from the agency's own work plus several hundred migrations contributed by the SEO community. That is not a random sample.

The distribution rewards a second look, because it runs against intuition. Around 42 per cent means that four in ten projects are still below their starting point a full year after the move. And the gap between median and mean, 304 days against 489, tells you the rest. The outliers at the top are long enough and numerous enough to drag the average more than half a year above the median. A rebuild is not a bet with a narrow spread. It is a bet with a long right tail.

Two timeframes fill out the picture. After you report an address change, Google Search Console prioritises the new property for 180 days and forwards signals. Google separately recommends keeping redirects in place as long as possible, "generally at least 1 year". Both say the same thing: a domain change is not an event, it is a condition that lasts quarters.

For contrast, look at how the industry handles this question. Several well-ranking guides quote recovery times of a few weeks to a few months. I went looking for the evidence behind those numbers and found no data set they rest on. More to the point, none of them distinguishes between a refit on unchanged URLs and an actual migration. That distinction is what really determines the duration.

Now the payoff. You can tell a criterion from a symptom by one test: you can check it without arguing about taste. These four qualify.

Criterion 1: the change you want forces a new information architecture, not new templates. The test question: do you have to cut pages differently, merge them, split them, or hang them in a different hierarchy before the goal becomes reachable at all? If the answer is yes, we are talking about structure. If you only want different building blocks on the same pages, we are talking about design.

Criterion 2: your annual iteration budget cannot reach the real problem. If 15 to 20 per cent of the original build cost goes into treating symptoms every year without ever touching the cause, that is not a budget problem, it is a structural one. The tell is a requirement that has been solved three times running as a one-off workaround.

Criterion 3: the CMS blocks the editors, not the designers. The line here is sharp. If your team needs the agency to publish a new landing page, the system is the problem. If a new landing page merely turns out ugly, the design system is. Only the first case justifies changing technology, and choosing the replacement is a piece of work in its own right — that is where our headless CMS work starts.

Criterion 4: the expected gain exceeds the time cost. This is the hardest one. If you end up on path 3, the expected gain has to be worth more than roughly a year of dampened organic performance. Run it with your own numbers: enquiries per month from organic search, average deal value, close rate. If organic search delivers the bulk of your pipeline, a year-long dip is an expensive new design.

Here is the arithmetic with round, made-up numbers. Assume your website produces 30 qualified enquiries a month, 18 of them from organic search. At a 20 per cent close rate and an average deal value of €30,000, that is roughly €108,000 in deal value per month from organic search. If that performance drops by a third on average across twelve months after a full migration, the time cost alone comes to about €430,000 in deal value. The project budget sits on top. Run the same arithmetic with your own figures before you compare a single quote. The result changes the question. It is no longer whether the rebuild is affordable, but whether the gain can ever catch up with the shortfall.

My rule of thumb for this, stated as a rule of thumb and not a law of nature: if only criterion 3 applies, swap the system and keep the URLs. If two apply, the partial rebuild is the right path. For a full migration at least three have to apply, and criterion 1 must be among them. Without criterion 1 there is no factual reason to touch the URL structure.

One item is deliberately missing from that list: Core Web Vitals. The thresholds are well known and apply at the 75th percentile — LCP at most 2.5 seconds, INP at most 200 milliseconds, CLS at most 0.1. INP replaced FID as a Core Web Vital on 12 March 2024. Those values matter, but they are almost always reachable without rebuilding anything. Rebuild because of load time and you are paying for a migration to solve a problem that a front-end rebuild handles.

A share of the rebuild enquiries that reach us are not rebuild enquiries at all. You spot them on the wish list: customer login, documents per customer, prices by contract tier, status lookups, order history. That is no longer a website. That is an application with a website in front of it.

The difference is not academic. It changes budget, team and operations. A website is a publishing system: content is edited and delivered publicly. A portal is a permissions system: it knows users, states and entitlements, and it needs operations, support and a data model. Order both in one project and you get a poor portal and a late website.

There is a quiet route into this trap. The requirement starts small: a download area for datasheets, existing customers only. Then prices should be visible per customer group. Then a form that knows the contract status. Each individual requirement reads like an extension of the website; in aggregate it is a product. Hide that inside the rebuild budget and you lose in two places at once. The date slips, because nobody scheduled the permissions work. The public website turns out badly, because attention is stuck behind the login.

The clean sequence is therefore: decide which of the two things you are building, then talk about the rebuild. The distinction with worked examples sits in Website, web app or portal, and what building the second one actually involves is on our page for web app development. If the answer turns out to be a product, the budget question changes shape entirely — why the same requirement produces quotes an order of magnitude apart is the piece to read next. One sentence to place all of it: the moment your requirements list contains the words "logged in", the rebuild budget is the wrong drawer.

Since 28 June 2025, the European Accessibility Act — Directive (EU) 2019/882 — has applied across the EU, and since then it has shown up in rebuild guides as a driver. Germany transposed it as the Barrierefreiheitsstärkungsgesetz, or BFSG; every member state has its own transposing act, and the details differ. I went through the guides that rank for this. Several cite the law as a reason to rebuild. None qualifies it for the B2B situation. That qualification is exactly the part that matters.

The decisive point is the scope. The directive addresses products and services intended for consumers. Services offered exclusively to other businesses fall outside it as a general rule. German chamber-of-commerce guidance published in 2025 reads it the same way and attaches a condition: the website must address business customers only. Consumers must be able neither to use services nor to conclude contracts through it. On top of that there is a microenterprise exemption for services, and it is cumulative: fewer than 10 employees and no more than €2 million in annual turnover or balance sheet total. Both conditions have to hold together, and for products the exemption does not apply at all.

Before you rely on any of that, check the edges. In practice, companies slide into scope over details: a shop that also ships to private individuals, appointment booking for end customers, ticket sales, a customer account with consumer access. The moment a service is offered to consumers anywhere, the assessment changes. This is a reading from project practice, not legal advice, and the transposing act in your own country may draw the lines differently. When it gets close, have it checked by a lawyer.

The more useful part comes next. Even if accessibility were mandatory for you, no rebuild follows from it. Contrast ratios, focus order, form field labels, alt text, keyboard operability, correct heading levels: all of that is work on the front end and the content. It runs in stages, costs a fraction, and needs not one new URL. Accessibility is an excellent reason for path 1. As an argument for path 3 it does not hold.

The best-documented German case is old and not from B2B, but it works as a lesson in mechanics. Don't read it as evidence of risk in your situation. Do read it as a catalogue of failure modes.

In March 2020, SISTRIX analysed the relaunch of frankfurt.de, the City of Frankfurt's website. The project cost around €1.4 million. The analysis puts the loss at just under 50 per cent of visibility; for mobile data, SISTRIX reports a good 46 per cent drop in visibility since the week of 2 March 2020. On mobile, the number of top-10 rankings fell from 1,337 to 984 within a single week. The case is six years old. The causes are not.

Two mistakes were enough. First, the old addresses were connected with temporary redirects instead of permanent ones. Second, a fair number of old paths from the previous system led nowhere: as of 2 March 2020, SISTRIX counted 821 mobile top-10 rankings still pointing at addresses in the old /sixcms/ directory that returned a 404. No design problem, no content problem. Two configuration decisions.

That case carries the mechanics you need for any rebuild. Google treats 301 and 308 as a canonicalisation signal, meaning an instruction to index the redirect target. With 302, 303 and 307 the crawler follows the redirect but does not use it as a canonicalisation signal. Every new address additionally needs a self-referencing canonical tag. Googlebot follows redirect chains up to ten hops; three is the recommended maximum. And the old redirects stay in place for at least a year, preferably longer.

What transfers here is not the size of the damage but the pattern. A city administration has different search patterns than a machinery manufacturer, and search in 2020 was not search today. What has not changed: redirects are a job for technical acceptance testing, not for aftercare, and one wrong status code on a site with a thousand addresses is wrong a thousand times over.

The punchline: the most expensive part of a rebuild is not the design. It is the list nobody wants to look at. If the redirect map is only drawn up after go-live, you have already paid the time cost from the previous section without ever having budgeted for it.

Most guides answer the duration question with the project timeline, and that is also the number printed in the quote. It is the number your steering committee will remember, and it is the wrong one to plan against on its own.

The line I want to draw here is simple. The project timeline ends at go-live. The time cost starts there. A project ships after four months and then needs three more quarters before organic performance is right again. That holds as soon as the URL structure has changed. Plan only the project timeline and you have planned half the thing.

This mix-up has concrete consequences for internal communication. Promise the board four months and you present the first evaluation after six. The result looks worse than the starting point, even though the project ran exactly to plan. So announce the dip in advance. An expected decline that arrives on schedule is a project status. An unexpected decline is a crisis, and crises produce hurried countermeasures that usually make the damage worse.

For your annual planning that means one practical thing: do not put go-live just before your most important season. If your business is decided in the first quarter, a structural rebuild belongs in the second. And if the campaign is already booked, move the rebuild rather than the campaign.

Most rebuild damage is not bad because it happens. It is bad because nobody can prove what happened. Without baseline figures, every discussion after go-live is one opinion against another. So you record four things beforehand, each with a date.

The visibility baseline. Visibility index, top-10 rankings, organic sessions, and enquiries from organic search — as monthly values for the last twelve months. Frozen, exported, filed with a date on it.

The URL inventory. Every indexed address, every address with rankings, every address with inbound links. Not the pages that appear in the menu: the pages that produce performance. In my experience that is a different list.

The redirect map. Old address to new address, one to one, permanent, no chains, no bulk redirects to the homepage. It belongs in acceptance testing, not in aftercare.

The measurement plan. What counts as an enquiry, where it is counted, which event triggers it. If tracking gets rebuilt alongside the website, you lose comparability at exactly the moment you need it. Analytics is a planning-phase decision, not a closing task.

Fix your checkpoints in advance too: day 7 for technical errors, day 30 for indexing, day 90 and day 180 for visibility. Look for the first time after six months and you will mistake a configuration error for a market problem.

Your decision fits in one sentence. Iteration beats a rebuild as long as the information architecture and the technology still hold, and the rebuild is justified when the structure itself is the problem. Everything else is a trigger.

The short version to take away. Check the four criteria honestly. If only the CMS applies, change the system and keep the URLs. If two apply, plan a partial rebuild on a stable URL structure. Only when at least three apply, information architecture among them, is a full migration the right answer — and then you put the time cost into the business case before you sign anything.

If you want to know how it adds up in your case, the shortest route is an inventory: visibility baseline, URL inventory, an assessment of the information architecture. Our page for B2B website projects sets out the three paths with price ranges, scope and the checkpoints we commit to contractually. And the same arithmetic applied to software rather than websites is in when custom software pays off, if that is closer to your situation. If you would rather talk the decision through once with someone who runs the counter-calculation instead of producing a quote: book a call.