A company decides the site looks old. They bring in a studio, get something cleaner, launch it, feel good about it for a week. Then the demo requests don’t move. Sometimes they drop. Six weeks later somebody opens Search Console, half the old rankings are gone, and nobody in the room can say why. I’ve been called in to fix that mess more times than I’d like.
A B2B website redesign reworks a site that already has traffic, rankings and a pipeline attached to it, run as one plan: strategy, information architecture, content, SEO migration, interface, development, measurement, in roughly that order. New colors and a new homepage are the last ten percent of the job and the part everyone has opinions about. The first ninety decides whether demo requests go up or rankings go away.
The technical layer any new site needs (the keyword map, Core Web Vitals, schema) is in SEO Starts Before the First Line of Code, which assumes a clean sheet. This guide assumes you have equity you can’t afford to set on fire. Some of the screenshots come from Algorithm.com, the analysis tool I built when I got tired of arguing about SEO from memory.
TL;DR
- Pick the scope word first. Refresh, redesign, rebuild and rebrand are four projects with four risk profiles, and the wrong word is how a six-week refresh becomes a nine-month migration.
- Two failure modes: the right buyers never find the site, or they find it and leave. They call for different work. Name yours before design starts.
- One primary metric, agreed by sales and marketing before wireframes. “Traffic is up” is a report, not a result.
- Migration is where the traffic bleeds out: deleted pages, a shredded internal-link graph, rewritten titles and intent drift, none of which a 301 fixes.
- Sometimes the answer is: not yet. The funnel math decides, and the ROI section shows how to run it.
Website refresh, redesign, rebuild or rebrand: scope the project first
Four words get used for four different projects. The one you pick decides the budget, the timeline and how much of the migration section below applies to you, so it comes first.
| What changes | What stays | When it’s the right call | SEO risk | |
|---|---|---|---|---|
| Refresh | Visual layer: typography, color, components, imagery | URLs, architecture, content, platform | The site works and looks dated | Low, if templates keep their structure and titles |
| Redesign | Architecture, UX, content, design system; often templates | Platform, most URLs, earned equity | The site is in one of the two failure modes below | Medium; the migration section is the risk |
| Rebuild | Platform, stack, CMS, usually everything above | The domain and whatever equity you migrate on purpose | The CMS is the bottleneck, or the site can’t be rendered for crawlers | High; every URL and template moves at once |
| Rebrand | Name, identity, positioning, often the domain | Little, sometimes not even the domain | The company has changed what it is | Highest; entity signals move along with the URLs |
A rebrand moves the entity along with the URLs. Google and the AI engines hold a picture of who the company is, assembled from your site and from third-party mentions: name, domain, people, what it’s known for. Change the name and the domain in the same quarter and that picture gets rebuilt from scratch, which is slow even when every redirect is perfect. A rebrand that changes what the company is needs a year of entity work alongside the migration: Organization schema with sameAs pointing at the renamed LinkedIn, Crunchbase and Wikidata records, the old name kept in alternateName, press coverage that uses both names in one sentence, and the Change of Address tool in Search Console, which only exists for domain moves and does nothing for URL changes inside a domain. Google’s own guidance is to keep the redirects in place for at least a year; I’ve yet to see a reason to remove them at all.
Everything below is written for the two middle rows. A refresh needs the baseline export and the title-parity check and little else. A rebuild needs all of it.
When a B2B website needs a redesign: five triggers, two failure modes
The standard triggers are legitimate: conversion has sagged and the funnel math no longer closes; the homepage H1, the Organization schema description and the LinkedIn About section describe three different companies; publishing a solution page needs an engineering ticket; positioning has shifted to a segment the site never speaks to; or the company has outgrown a site built for ten people and needs governance, localization, a resource center. Every redesign framework lists some version of these five, and they’re right as far as they go.
The trigger tells you the site is in pain, and stops there. Every weak B2B site I’ve audited has one of two problems underneath, and I sort by that before anything else. One: the right people never see it. Buyers ask narrow questions at every step of the buyer journey, in Google and increasingly in ChatGPT, Perplexity and the AI Overviews: “[category] for a 200-person fintech,” “how do we do [the job] without hiring for it.” Filter the Performance report to queries containing “for”, “vs”, “alternative” or “without”; a site that earns impressions on none of them is in this mode, and no visual refresh or ad budget changes it. Two: they see it and leave. Traffic’s fine, demos aren’t. This is the mode everybody reaches for a redesign to fix (new hero, shorter form, cleaner homepage), and a redesign fixes it least reliably, because the problem is rarely visual.
There’s a version of the second mode that isn’t a redesign problem at all. Traffic is healthy, the pages load, the design is fine, and the demo rate is still flat. Nine times out of ten that’s positioning: the site is clear about what the product does and silent about who it’s for and why it beats the alternative the buyer already has. A redesign repackages that silence in a nicer grid. If you can’t write the one-sentence answer to “why us, for this buyer, instead of the incumbent” before the project starts, fix the sentence first.
A separate cause, and the one that makes the pain recur: how the project gets staffed. A studio takes the visuals, an SEO agency gets “looped in,” a freelancer writes the words, and the money leaks out of the gaps between three competent people with no shared plan. Both wrecks this produces, the beautiful invisible site and the keyword sludge with no hierarchy, come from running the two jobs as a relay, build it then optimize it, when every SEO decision that changes anything is a build decision.
Step 1. Baseline, goals and one primary metric
The first deliverable of a redesign is an export. The second is a one-page agreement on what the site is for. Wireframes come third, and most projects start with them.
Baseline export: Search Console, GA4 and the crawl
Before the project changes anything, I pull the full Search Console window (queries, pages, countries, devices), the ranking URLs with their positions, backlinks per URL (a per-domain count hides which pages hold them), conversions by landing page from analytics and from the CRM, and a full crawl of the current site so the internal-link graph exists somewhere other than the live server. Three settings decide whether that export is even possible:
| Setting | Default | Before the project | What’s lost otherwise |
|---|---|---|---|
| Search Console data window | 16 months, then deleted | Export the full window | The pre-redesign baseline for every URL |
| Search Console Performance table | 1,000 rows in the UI | Pull through the Search Analytics API or the Looker Studio connector | The long tail on any site with more than a few hundred URLs |
| GA4 event data retention | 2 months | Switch to 14 months on day one; the change is not retroactive | Pre-launch conversion data in Explorations by the time the site is live |
Six months in, when someone asks whether the old pricing page was earning, that export is the only place the answer lives. How I read it is in the B2B SEO audit; the redesign inherits its findings.
One primary metric, two supporting, one ignored segment
The agreement is harder to get than the export. If marketing, sales, product and the CEO define success differently, all four will still sign off on wireframes, and the site gets redesigned again in eighteen months.
What I ask for is one primary metric, two supporting ones, and a named segment the site is allowed to ignore. For most B2B sites the primary metric is qualified demos or SQLs per month from the site, counted in the CRM. Analytics counts submits; the CRM counts the ones sales accepted. Supporting metrics are usually organic leads by landing page and the MQL→SQL rate. The ignored segment is whichever one makes the homepage impossible: students, job seekers, the ten-seat customer a company now selling to enterprise no longer wants. Once that segment is written down, the homepage can speak to one buyer, and the metric becomes the review criterion: a design gets judged on whether it moves a security lead to the security page in one click.
If an agency is coming in, these two deliverables are the brief. It needs the baseline export and where it lives; one named person who owns the redirect map and the internal-link diff, on your side or theirs; and the primary metric, from the CRM. An agency that doesn’t ask about the first two before quoting is pricing a visual refresh, whatever the proposal calls it.
Step 2. Buyers, positioning and messaging before UI
The buying committee: who reads the site and what each one fears
A VP of Engineering checking out an infrastructure tool is thinking will this fall over in production and will my CTO have my head for it, and the hero copy that answers “I’d love a flexible, enterprise-grade solution” answers nobody. The voice in the buyer’s head comes from sales-call recordings and the lost-reason field in the CRM, and it’s the first input to the design brief.
Where the buyer sits rewrites the design. An enterprise security lead reads white space and restraint as competence, opens the security page before anything else, and sees a “chosen by 1,000+ companies” strip as a consumer product wearing a suit. An SMB owner reads the same restraint as a site nobody finished, wants the price on the page and the logos above the fold, and bounces off a form that asks for company size. The two of them read the same page backwards; consumer brands know this split as mass market versus luxury, colour and discounts on one side, black-and-white restraint on the other, and B2B buyers sort the same way. Density gets set here, at profiling, and carried into the design brief.
A consumer decision is one person, one sitting. A B2B decision goes through a buying committee that finance, IT and leadership will all pick apart before anyone signs, and the numbers on it are larger than most homepages assume:
| Source | Finding |
|---|---|
| Forrester, 2025 buyers’ survey | 13 internal stakeholders and 9 outside influencers per decision; 94% of buyers use generative AI somewhere in the process |
| Gartner, B2B buying journey | Buying groups of 6–10, each member arriving with 4–5 pieces of information gathered on their own; 17% of total buying time spent with all suppliers combined, about 5% per supplier on a short list |
The website gets the rest of the buyer’s time, and one homepage can’t carry three roles: the engineer, the RevOps lead and the CFO each arrive with a different problem and a different bar for trust.
Positioning in six lines, tested under a competitor’s logo
Before anyone opens Figma I want six lines on one page:
- The category
- Who it’s for
- The problem
- The promise
- What makes it different from the incumbent (the one sentence from the failure-modes section)
- The proof
If those six lines don’t exist, the designers fill the hero with “powerful, flexible, enterprise-grade,” which every competitor’s homepage also says. Test the lines mechanically: paste them under the nearest competitor’s logo. If they still read true, you have a category description, and positioning hasn’t started. “See production incidents before your customers do” passes; “comprehensive infrastructure monitoring” doesn’t. The six lines then live in one document with a sign-off date, and every copy ticket, from the hero to the headline above the demo form, links to it.
Competitor analysis: table stakes and open slots
I keep competitor analysis to one number. Take the five pages ranking for the query your solution page wants and score them on the blocks they carry: published pricing or a range, a comparison against named alternatives, an integrations list, a security or compliance page, named people with credentials, an implementation timeline, a guarantee with terms. Anything four of the five carry is table stakes; without it the buyer reads your page as incomplete before reading a word. Anything none of them carry and a buyer would use, a cost calculator, a migration-effort estimate, live onboarding dates, is open ground.
Step 3. Information architecture, UX and forms
The Industry → Solution → Use Case → Product → Proof ladder
Most B2B sites are filed under the company’s own furniture, Features, Solutions, Integrations, Resources. Buyers arrive with an industry, a problem, or a job to be done, and the site asks them to translate. A data platform refiled around buyer context, “business intelligence for operations teams,” “embedded analytics for product teams,” catches searches a single Analytics page will never see.
The architecture that does this runs down a ladder: Industry → Solution → Use Case → Product → Proof → Conversion. Not every site needs every rung, and a 40-page company shouldn’t build 400 pages to fill them. But every commercial intent the audit found needs a home somewhere on that ladder, and each home carries one intent. The keyword map from the audit, the clusters, the entities each page has to cover, the proof and comparison blocks a commercial page needs, is an input to the wireframes, and a design that arrives first leaves no slot for any of it: the new pages and blocks get bolted on after launch, into templates that were never drawn for them. For a redesign, two checks: does the existing site have the rungs, and does each page stay on its own? Before the design system gets built, one solution template goes together as a prototype with the copy and the industry it will ship with, because lorem ipsum hides whether the ladder survives contact with the texts.
Primary navigation follows the same rule. Solutions by industry and by role go in the menu; the company’s own categories go second. A homepage’s job is to route: three doors, one per committee role, one primary CTA, and the proof each role needs one click away.
Is your solution page a guide? Scoring intent passage by passage
Staying on one rung is where I find the most damage, and it’s measurable. A solution page exists to move a buyer who already knows the category toward a demo. Score its passages by the intent they serve and a surprising number of “commercial” pages turn out mostly educational: a definition of the category, a history of the problem, five paragraphs of why this matters before the product appears. The SERP puts that page next to guides instead of vendors. On one page I scored recently, 54% of the passages were informational and the page turned informational in the first paragraph. The buyer who arrived ready to evaluate got a lesson.
During a redesign, the educational passages move to a guide that links down to the solution page, the solution page keeps what a buyer needs to choose, and internal linking makes the relationship explicit both ways. Search Console shows whether the fix took: filter the Performance report to the solution page and look at the queries it earns clicks for. If the top ten are “what is [category]” and “how does [category] work”, the page is still a guide.
Proof placement, density and mobile
I start from functional minimalism: strip everything that doesn’t help the next step, and white space makes the one thing that matters legible. Proof sits where the doubt spikes, technical credibility up top for an engineer, ROI and peer logos mid-page for a business buyer, a low-commitment next step at the end, none of it parked in a testimonial carousel at the bottom of the page. Session recordings on the solution template (Microsoft Clarity or Hotjar) show where the scroll stops, and that’s where the proof block goes. Density comes from the profiling in Step 2.
B2B sites still lose the field buyer on a phone: the plant manager, the distributor rep placing an order from a truck. Templates get signed off on a 27-inch monitor and the demo form gets tested on a phone the week before launch, if at all. Walk the demo path on a mid-range Android over 4G at the wireframe stage; what to check on a phone before sign-off is in our mobile SEO checklist.
Launch gate per template: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 at the 75th percentile. Before launch these are lab checks in Lighthouse; INP has no lab equivalent, so a mega-menu, a chat widget and a consent banner initializing in the same second get tested by hand on the phone. Field confirmation arrives after 28 days of CrUX data.
B2B demo form fields: three questions per field
On forms I’ve stopped quoting conversion statistics, because the field-count numbers that circulate are a decade old and unsourced. Each field gets three questions instead:
| Question for each field | Yes | No |
|---|---|---|
| Does sales need this answer before the first call? | Keep it | Sales asks it on the call |
| Can it be inferred: company size from the email domain, industry from the company? | Enrich after the submit (HubSpot’s Breeze Intelligence, Clearbit before it, ZoomInfo, or a Clay workflow) | The next question decides |
| Does the answer change routing, priority or the follow-up sequence? | Keep it as the one routing field | Cut it |
A field that fails all three is friction with no payoff, and most B2B forms carry four or five of them. Usually name, work email and one routing field survive; a free-mail domain routes to nurture. Lead qualification happens after the submit, in the CRM. One primary CTA per page is my default, and the first A/B test on the template runs against it.
Step 4. Platform, CMS and design system
Platform choice is simpler than the vendor comparisons make it. Stay if the current CMS can render what the new architecture needs and a marketer can publish a solution page; move only if the CMS is the bottleneck, because moving turns the redesign into a rebuild and prices like one.
Marketing owns three of the decisions here. First, the design system: a page is a composition of components from it. If the solution template is a set of blocks the CMS can rearrange, marketing adds the eleventh industry page in an afternoon; if every page is a composition of its own, the architecture above stops growing the week the agency leaves.
Second, who owns the stack. Whether a marketer can publish a new solution page, change a CTA and drop a case study into the proof block without filing a ticket is the whole test. Webflow collections, WordPress block themes with the tokens in theme.json, a headless CMS with a working preview: any of them pass. A hand-coded template passes Lighthouse and fails this one. Write the content model into the contract: a case study is a structured item with industry, product, metric and quote as fields, so the proof block on each solution page can pull the three relevant cases by industry. A case study saved as a rich-text page can’t be pulled by anything.
| Decision | When it’s the right one | What it adds to the project |
|---|---|---|
| Stay on the current CMS | It serves the content as HTML and the team publishes without engineering | Nothing. Templates and URLs stay; the migration shrinks to title parity and an internal-link diff |
| Move to a marketing CMS (Webflow, HubSpot CMS, a WordPress block theme) | Every page is a ticket, there is no content model, no preview, or the stack can’t be hosted where legal needs it | Content export and field mapping, every URL and every integration moving in one launch. Budget and schedule it as a rebuild |
| Go headless | Engineering owns the front end for product reasons and marketing gets a working preview in the deal | Everything a move adds, plus a rendering check per template before sign-off, because what the front end draws after the HTML arrives is what crawlers don’t see |
Third, accessibility, which in B2B is now a procurement line: enterprise and public-sector buyers ask for a WCAG 2.2 AA conformance statement in the RFP, with the US ADA Title II rule holding larger state and local governments to WCAG 2.1 AA from April 2026 and passing that requirement down to their vendors through procurement. Of the criteria 2.2 added, the first ones a B2B site trips sit in the nav and the demo form (2.5.8 Target Size: any icon-only button under 24×24 CSS pixels fails), and the design system is the cheapest place to fix them once, at component level.
On the copy itself: AI-generated text carries no penalty for being AI-generated; what Google penalizes is scaled content abuse (the March 2024 spam policy, indifferent to how the pages were made) and a site whose content is unhelpful overall, scored site-wide. A hundred templated solution pages spun from one prompt trips both, and B2B readers catch it before Google does; every solution page, whoever drafted it, has to pass the competitor-logo test from Step 2 before it ships.
Three build gates I check inside the development. Rendering: on each template, “View crawled page” in URL Inspection against what the browser shows; anything that appears only after a click or a scroll isn’t in the HTML Google received, and the AI crawlers in Vercel and MERJ’s December 2024 study fetched JavaScript files without executing them. Staging: HTTP 401 plus an X-Robots-Tag: noindex header, since a CMS password page returns 200 and gets indexed as a login screen; removing the block goes on the launch checklist as its own line, because a staging noindex shipped to production is the launch-day bug I get called about most. Crawler access: review robots.txt by agent name; a rule written in 2023 against GPTBot does nothing to OAI-SearchBot, the agent behind ChatGPT search, and since July 2025 a site that moves behind Cloudflare gets the AI crawlers blocked by default on new zones without anyone deciding it. The agent list and the rendering mechanics are in the technical SEO audit guide.
Step 5. SEO migration: what the 301 checklist misses
This is the section I’d move to the front if I trusted you to read it there. Every migration article says to set up your 301s, and you should. I’ve watched sites with a spotless redirect map still shed 30–40% of their traffic after a redesign, because the damage came from places the checklist never mentions.
Pages cut while still ranking. Any URL with clicks in the sixteen-month export, a referring domain in the backlink export, or a conversion in the CRM gets a verdict before it gets deleted, and “delete” is the rarest of the four:
| Verdict | When it applies | What you do |
|---|---|---|
| Keep | Page ranks, earns traffic or links | Carry it over as-is. Don’t “freshen” what works. |
| Improve | Right intent, weak execution | Same URL, same title if it ranks; upgrade the content only. |
| Merge | Two thin pages chasing one intent | Combine into the stronger URL, 301 the other into it. |
| Redirect | Dead weight but holds links or history | 301 to the closest live replacement. Never to the homepage. |
The internal link graph, shredded by a new template. Your old crawl has a unique-inlinks count for every URL, and that number is what the new templates are about to change. Rebuild navigation and templates from scratch and you can shred that graph without anyone noticing; rankings sag a few weeks later and get blamed on the algorithm. Diff the new site against the crawl export from the baseline: Screaming Frog’s Compare mode set to the old crawl and the staging crawl, sorted by the change in unique inlinks. If a page that had forty internal links now has three, that’s the finding. The old footer linked every solution page, the new footer links four, and a related-content block that used to be hand-curated now shows “latest posts.”
Titles and headings rewritten in a “copy refresh.” A title tag and an H1 that rank are assets. Swap them wholesale and you can reset a page’s relevance overnight. Google also rewrites titles in the results from the H1 and the anchor text pointing at the page, so changing the H1 alone changes what the SERP shows even when the title tag is untouched. Preserve first, improve second, and log every deliberate change with the date so a drop three weeks later can be matched to it.
Intent drift. An informational resource that ranked for years becomes a hard sales page, or two intents get merged into one page for cleanliness. Compare the top queries for the URL in the Performance report, 28 days before and after launch; if the “what is” queries gave way to nothing, the page drifted, and the old intent needs its own URL back.
Redirect mechanics done half-way. 301, not 302, for anything permanent. Google has said on the record that 3xx redirects don’t lose PageRank, so chains aren’t fatal, but every hop is a place something can break; flatten them. A “301 redirect SEO penalty” after a relaunch is usually one of the four traps above. Then repoint internal links to the final URLs: crawl the new site on staging and filter internal links that answer 3xx. And keep a sitemap of the old URLs submitted for a few weeks after launch so Googlebot recrawls them and processes the redirects sooner; it’s in Google’s site-move documentation.
The range every checklist quotes is a 10–25% traffic dip in the first thirty days and two to eight months to recover, and as an average I’ve no reason to argue with it. The average hides one variable that does most of the work: the share of URLs that moved. A redesign that keeps its URLs and only swaps templates sits at the bottom of that range or below it. A rebuild that moves every URL and rewrites the navigation sits past the top, and the recovery clock on it starts only when the last redirect is right.
What I don’t have is a number that splits that dip between URLs moved and internal links lost. On the sites where I’ve seen both, they arrived together, and nobody runs the controlled version where only one of them changes. Until someone does, the URL share is what I plan around and the link diff is what I check first when the dip outruns it. The status-code mechanics (410 vs 301, canonical vs redirect, how to read a redirect audit) are in the technical SEO audit guide.
Step 6. Launch and measurement: pipeline parity
A redesign renames things. GA4 events get new names, the HubSpot or Salesforce form IDs change, the CRM field that stored the landing page gets a new key, the UTM convention gets tidied. Each change on its own is sensible. Together they mean that two months after launch, “leads by landing page” can’t be set against the baseline, and the question the whole project was supposed to answer has no answer. The standard launch checklist stops at “verify GA4 is firing”; I check one step further, at the CRM record. Before launch I want a mapping of every conversion event, old name to new, with the old names kept as GA4 key events until the first full month of the new ones exists; a test lead submitted from each form template and traced to the CRM record with the landing page attached, because a HubSpot form rebuilt in the new design gets a new GUID and every workflow keyed to the old one goes silent without an error; hidden fields on every form for landing page, referrer and the UTM set, written server-side so a consent banner can’t blank them; and an inventory of the URLs currently live in Google Ads, LinkedIn, nurture emails and the sales deck, because every one of them is about to hit a redirect or a 404.
The Core Web Vitals report in Search Console runs on 28 days of CrUX field data, and so does the field section of PageSpeed Insights, so for the first month the only readings of the site you shipped are lab runs per template and your own field data, if the web-vitals library is on the page and reporting into GA4.
Before go-live I want a 30/60/90 list: which template gets the first A/B test, which form field comes out first, which solution page gets its second case study. Without it the site freezes on launch day.
| Check | When | What passes |
|---|---|---|
| GSC sixteen-month export, crawl of the old site | Before design starts | Both files exist somewhere other than the live server |
| URL inventory from crawl, GSC, analytics and backlink export | Before IA sign-off | Every old URL has a verdict: keep, improve, merge, redirect |
| Redirect map | Before staging | One-to-one, no chains, nothing to the homepage |
| Title and H1 parity on ranking pages | Copy sign-off | Ranking pages keep both unless the change is deliberate and logged |
| Internal-link diff | Staging | No ranking page lost more than half its inbound internal links; no internal link answers 3xx |
| Staging block removed, canonicals on production | Launch hour | URL Inspection live test clean on one URL per template |
| Campaign URLs: ads, nurture emails, partner listings, the sales deck | Launch day | Each lands on 200 or 301 |
| Event parity | Launch week | A test lead from each form reaches the CRM with the landing page on the record |
| Monitoring | Daily until the top fifty pages show as indexed, then weekly for ninety days | Indexed count, crawl errors, CWV per template and leads by landing page, read against the baseline rather than against last week |
A site can hold its total traffic steady while the three pages that drove demos flatline; leads by landing page is the row in that table I’d keep if I could keep only one.
Content during a redesign: grade, merge, cut
A redesign is the wrong moment to rewrite the blog for topical authority, and the blog is rarely where the project earns its cost back. The cluster-by-cluster plan adds pages that restate answers the index already holds, and the solution pages that sell inherit the blog’s grade. What I hand clients is short. Grade the existing posts on what they add; merge or cut the rest; the grading method is in the audit guide. To check cannibalization, filter the Performance report to one query, switch to the Pages tab, and if two URLs trade the impressions between them week to week, neither is holding the position; the merge keeps the URL with the more backlinks, moves the unique passages from the other, and 301s it. Then write what the pages ranking for the query don’t have: a case, screenshots, numbers, a named author with a footprint you can verify. Five to ten of those is a year’s plan, and I’ve had a site under a month old show up in rankings on a handful of pieces like that and a clean build alone.
B2B website redesign timeline and cost: what moves the estimate
Three to six months and from about $10,000 for a mid-sized site that stays on its platform; six to twelve months and a different budget if the CMS moves. Timeline is the number people get wrong by a factor of two, and content stretches it more than design does: interviews and drafts for twenty pages take longer than the templates that hold them, and the approval loop for a security page can outlast the build of the entire site.
| Project | Typical duration | What usually slips it |
|---|---|---|
| Refresh, same templates and URLs | 6–10 weeks | “While we’re at it” scope: one new template becomes five |
| Redesign, same platform, mid-sized site | 3–6 months | Copy and case studies; the messaging page not signed off before UI |
| Rebuild with a CMS move | 6–12 months | Content export and field mapping, CRM and marketing-automation rewiring |
| Enterprise or multilingual | 9–15 months | Legal and accessibility review per page, hreflang, a second migration per locale |
Cost moves with the same variables, roughly in this order: the number of templates (a 200-page site on eight templates costs less than a 50-page site on twenty, because templates are what get designed, built and tested); whether the CMS moves, which makes it a rebuild (see the table in Step 4); integrations with CRM, marketing automation, product data, scheduling and chat, each a project inside the project; content rewriting, the line most often underestimated because it looks like a freelancer’s afternoon and is usually two months of interviews and drafts; the SEO migration itself, URL mapping, redirect testing, the internal-link diff and the post-launch watch; multilingual architecture, which doubles the templates in practice; and enterprise governance, approvals, accessibility compliance, legal review, which costs mostly in calendar months.
One number I’ll put on it: a B2B website redesign done as the sequence above, with the baseline, the migration and the measurement layer in scope, starts at around $10,000 and goes up from there with the list. I won’t quote a ceiling, because every agency quotes a different one and none of them has seen your site; the two lines that move the estimate most are integrations and content, and both are unknowable before the audit. Budget 10–15% on top for the things nobody scoped.
SEO migration is the cheapest line on the estimate and the most expensive line to cut, on every budget I’ve seen. Removing it saves a few percent of the build and risks the entire organic channel the redesign was supposed to grow. If the budget has to lose something, lose a template.
Where the weight sits, by company type
Company type decides which stage carries the weight and where the audit looks first.
| Company type | Where the weight sits | The usual failure |
|---|---|---|
| B2B SaaS | Positioning, pricing page, trial or demo path; feature architecture by use case rather than by feature name | A Features page that lists capabilities and a Pricing page that hides the number |
| Technology / infrastructure | Technical credibility for an engineering buyer; docs treated as an SEO asset rather than a support cost | Marketing site and documentation on separate domains with no link between them |
| Professional services | Proof: named people, credentials, cases with numbers; the About page as a commercial page | “Our team of experts” over stock photography |
| Manufacturing / industrial | Product taxonomy, spec sheets, applications, distributor and RFQ paths | A catalog in PDF that Google can’t read and a buyer can’t filter |
| B2B e-commerce / customer portal | Catalog as crawlable HTML, account-based pricing, reorder and quote paths, filters built on procurement logic | The catalog behind a login, and faceted filters minting a million ?color=&size= URLs that spend the crawl before Google reaches a product page |
| Enterprise | Governance, localization, committee-specific paths: security, procurement, legal | One homepage trying to speak to the CISO, the CFO and the end user at once |
Common B2B website redesign mistakes, by stage
| Stage | Mistake | How it shows up later |
|---|---|---|
| Scoping | Calling a rebuild a refresh; changing name and domain in one quarter | A migration nobody budgeted; entity signals rebuilt from zero |
| Strategy | No primary metric; no baseline export | “Traffic is up” as the only report, and no way to check it |
| Positioning | Messaging written after the UI; stock claims (“innovative”, “client-focused”, “tailored solutions”) and no named buyer | A hero every competitor could have shipped, and a demo rate the new design doesn’t move |
| Architecture | The keyword map, the entity pages and the commercial blocks never reach the design brief; navigation by department; solution pages that teach for five paragraphs | A site that looks new and has no page for half the intents in the audit; commercial pages competing with guides instead of vendors |
| Design | A trend-led design with no buyer behind it: colour and discounts for someone who reads restraint as competence, or monochrome minimalism for someone who reads it as unfinished; six-field forms; desktop-first templates | Traffic that reads and leaves, especially on a phone |
| Content | Rewriting the blog for topical authority; templated copy at scale | A site-wide downgrade the solution pages inherit |
| Migration | Pages cut while ranking; internal links left to ride redirects; titles rewritten | Rankings gone weeks after launch, blamed on an update |
| Launch | Staging noindex shipped; canonicals on the staging domain; GA4 events renamed without a map | Deindexation, then a quarter with no comparable numbers |
ROI: when not to redesign
A serious conversion-focused redesign stopped being “affordable marketing” some time ago, while organic CTR on queries that trigger an AI Overview keeps sliding. For some companies the most useful thing I can say is: don’t do this yet.
The decision takes three numbers. First, what a closed deal is worth to you. Second, how many qualified leads a redesign would add per month; that one comes from the baseline, as the gap in demo rate between your best solution page and the median one, applied to the median pages’ traffic, and it has to survive a CFO reading it. Third, the all-in cost from the section above, including the months of monitoring and iteration after launch. Multiply the first two and set them against the third.
If it closes, the work is the sequence above, run by people who can hold design and search in the same head. That’s what we do at Neon: UX/UI design and custom web development with the migration in the plan from the first meeting. If the math doesn’t close, we’ll say that too.
My bet for the next two years: the redesigns that survive will be the ones where the migration plan and the intent map existed before the moodboard, and by 2028 the “we lost half our rankings after the relaunch” story will read the way “we built the whole site in Flash” reads now, a known mistake nobody serious makes twice.
FAQ
Can we redesign without changing URLs?
Usually, and it’s the single cheapest way to protect rankings: new templates, new design system and new copy on the same URLs keep the migration to the two checks in the CMS table. URLs change when the architecture does, and then the change is deliberate and mapped.
Should we move the CMS and redesign at the same time?
Only if the CMS is the reason for the project. Doing both at once moves every URL, template and integration in one launch, which is the worst case for the migration and the hardest to debug when something drops. If the platform is merely old, redesign on it first and migrate later, when the new architecture is proven.