Why B2B website rebuilds lose traffic, and how to not
The most expensive thing that happens in a website project is not overspending. It is launching a better site that ranks worse than the one it replaced.
It is common enough to be predictable. A company rebuilds, the new site is faster and looks far better, and organic traffic falls thirty to sixty percent within a month. Nobody can say why, the agency has moved on, and it takes two quarters to recover if it recovers at all.
The causes are almost always the same handful.
URLs changed without redirects. Every page that moves needs a 301 from the old address to the new one. Miss them and you discard the accumulated authority of every link ever pointed at those pages. This is the single biggest cause and the easiest to prevent, and it is still the most common.
Content got shorter. Redesigns are usually driven by design, and design tends toward less text. The page that ranked did so partly because it answered the question thoroughly. A cleaner page with a third of the words often ranks for a third as much.
The staging site got indexed, or the live one got blocked. A noindex or a stray Disallow left in place at launch is a self-inflicted outage that can run for weeks before anyone notices.
Internal linking was rebuilt around a new navigation that happens to bury pages which used to be two clicks from the homepage.
Structured data and metadata were not carried across, so rich results disappear along with the click-through rate they were earning.
The prevention is unglamorous and takes about a day of work: crawl the existing site before touching anything, export every URL with its traffic and rankings, map old to new explicitly, keep the content on pages that already earn traffic, and verify redirects and indexability before and after the switch. Ask any agency quoting you a rebuild how they handle this. The answer tells you a great deal about what you are buying.
What actually determines what a build costs
Quotes for what sounds like the same website routinely differ by a factor of ten, which makes it reasonable to assume someone is overcharging. Usually the quotes are for genuinely different things.
Page count is a weak driver. Twenty pages built from six templates is a much smaller job than eight pages each individually designed. What costs money is the number of distinct layouts, not the number of URLs.
Design origin. Applying an existing brand and design system is a fraction of the cost of creating one. If the identity work has not been done, it is happening inside the website project whether or not it is itemised.
Integrations. A marketing site with a contact form is straightforward. The same site with CRM sync, gated content, event tracking, a customer portal, or a product configurator is a software project that happens to have a homepage.
Content. Someone has to write it. Projects stall on this more than on any technical factor, and a quote that excludes content is quietly excluding the critical path.
Migration complexity, meaning how much existing content, how many URLs, and how much of it needs restructuring rather than moving.
Our own builds run $15,000 to $50,000, quoted fixed after discovery, with six to eight weeks as the typical timeline. Below roughly $15,000 for a B2B site the honest options are a template implementation or a Webflow build, both of which are legitimate choices we will sometimes recommend. Above $50,000 you are usually buying either an application or a brand programme with a website attached.
Choosing the stack without being sold to
Every agency has a default and most present it as an objective conclusion. Here is ours, with the cases where it is the wrong answer.
Astro is our default for marketing sites, which is also what this site is built in. It ships almost no JavaScript by default, which is the largest single lever on Core Web Vitals, and it handles content-heavy sites well. It is the wrong choice if the product experience is genuinely application-like.
Next.js and React where there is real interactivity: a dashboard, an authenticated area, a configurator, a product that lives inside the marketing site. Powerful, and it will be slower than Astro for a brochure site unless someone actively works to prevent that.
WordPress is the right answer more often than modern agencies admit. If your team is fluent in it, the plugin ecosystem is doing real work for you, and the site is well maintained, migrating away is a large cost with a speculative return. We maintain WordPress sites and we will tell you when moving is not worth it. Where it goes wrong is accumulated plugin weight, page builders producing unusable markup, and the security surface of software that must be patched continuously.
Webflow for a small marketing site where a non-technical team needs full editing control and the budget is tight. The constraint is that you are inside their platform, and complex integrations get awkward.
Headless CMS, Sanity or Contentful, when several channels consume the same content or editorial workflow genuinely matters. For a company publishing four blog posts a month it is usually overhead that makes simple edits harder.
The question worth asking any agency is not which stack they use but what they would do if you insisted on a different one. If there is no answer, you are being sold a preference as a diagnosis.
What “SEO-ready” has to mean
Most agencies say the site will be SEO-ready. Very few will say what that includes, so it is worth having a checklist.
Server-rendered or statically generated HTML, so content exists without JavaScript executing. A crawlable internal link structure using real anchors. Clean, stable, human-readable URLs. Editable titles and meta descriptions per page, without a developer. Correct heading hierarchy. Structured data where it applies, and a CMS that emits it rather than requiring hand-written JSON-LD. Canonicals, an XML sitemap, and a robots.txt that says what it should. Image handling that produces modern formats at sensible sizes automatically. And genuinely fast pages, because speed is now part of the ranking calculation rather than an adjacent nicety.
That list is the floor. What it does not include is content, which is what actually earns rankings. A technically flawless site with nothing to say ranks for nothing, and this is where the handoff between developer and marketer usually fails. We build both, which is the reason organic and web sit in the same team here.
Core Web Vitals, and what actually moves them
Three metrics, and in practice the fixes are concentrated.
LCP, how long the largest visible element takes to appear. Almost always the hero image or a web font. Serve modern formats, size them for the viewport, preload the one that matters, and stop the font blocking the render.
CLS, how much the layout jumps. Caused by images without dimensions, fonts swapping at different metrics, and injected banners. Reserve the space and it goes away.
INP, how quickly the page responds to interaction. Overwhelmingly a JavaScript problem, which is why a framework that ships less of it starts ahead.
The largest single lever is usually third-party scripts. A site can be engineered to an excellent score and then have a tag manager, a chat widget, three analytics tools, and a heatmap recorder added to it, at which point the engineering is irrelevant. Deferring, auditing, and sometimes removing those is regular work rather than a one-off, and it belongs with whoever maintains the site.
What happens after launch
A website is not finished at launch, which is the part most proposals skip.
Dependencies need patching. Content and pages change. Analytics need watching, because the first four weeks after launch are when redirect gaps and tracking breaks actually surface. Performance drifts as content and scripts accumulate. This is website maintenance, and it is a distinct purchase from the build.
Most of our web clients stay on a maintenance retainer afterwards, which is also why we are careful about what we build. An agency that hands over a repository and leaves has no incentive to avoid choices that are expensive to live with. We do.
Where we are not the right fit
We do not build e-commerce at scale. We work with Shopify for straightforward catalogues, and a large or complex store is a specialism with its own agencies.
We are not the cheapest option and would not claim to be. A template implementation from a freelancer is a legitimate choice for an early-stage company, and we will say so.
And if what you need is a pure design engagement handed to your own developers, that is our design service rather than this one, and it is priced differently.