Website Redesign Cost in 2026: Scope, Budget, Drivers

How much does a redesign cost? Three project scenarios

Budget follows scope, and scope resolves into one of three scenarios. A visual refresh reuses the existing platform and templates. A UX/UI redesign rebuilds structure and interfaces on top of a working system. A full rebuild replaces the platform and usually the CMS. Deciding which of the three the business actually needs removes most of the spread between quotes, because that spread was rarely about hourly rates in the first place.

The table below is the first artefact we put in front of a client. It compares the three scenarios on the dimensions that move a budget: what is in scope, what gets delivered, who has to be on the team, what the calendar depends on, what the number is calculated from, and where the project can go wrong.

Visual refresh on the existing platform

A visual refresh updates styling, key templates, imagery and typography inside the current CMS without touching how the site is organised. Information architecture, integrations, the content model and the URL structure all stay as they are, which is exactly why this scenario is the cheapest and the fastest to run.

The team is small: a designer and a front-end developer, with minimal back-end involvement to wire new styles into existing templates. Most of the calendar time goes to approvals rather than production, which is why this scenario is usually handled by a small web design agency in the USA team rather than a full delivery squad.

This is the honest answer when the brand has moved on and the visuals look dated, but the structure works, the forms convert acceptably and the sales team can find what it needs. If analytics show that people reach the right pages and still do not convert, a repaint will not change the outcome.

UX/UI redesign with implementation

A UX/UI redesign reworks the structure and the interfaces on top of a platform that stays in place. It includes discovery, a reworked information architecture, new page templates, a design system and front-end implementation, plus content adaptation to the new templates.

Cost concentrates in the number of unique templates and the depth of the design system, not in the number of pages. Twelve unique templates with defined states and components cost far more to design and build than a site section with 200 pages sharing four of them.

The team adds a UX lead or analyst, QA and back-end capacity for template logic. Pick this scenario when the site looks acceptable but does not produce qualified leads, buries the evidence a buying committee needs, or forces the sales team to send PDFs instead of links.

Full rebuild with possible CMS migration

A full rebuild replaces the platform and usually the CMS, then carries content, integrations and search equity across to it. Scope covers platform selection, CMS and content migration, integration rework, SEO migration checks and a longer testing cycle. This is the only scenario where migration risk becomes a budget line of its own.

The CMS decision is the budget fork in this scenario. It should be justified by constraints such as an unsupported platform version, blocking security or performance limits, or an integration model that cannot be extended, rather than by a preference for a currently fashionable stack. We have seen replatforming decisions taken on aesthetics and paid for twice: once in the migration, once in retraining the editorial team.

Nielsen Norman Group's argument on radical redesign versus incremental change is the one we lean on with clients here: the size of the change should be justified by user evidence and business goals, not by how tired the current site feels to the people who see it every day. It is a design decision framework, not a 2026 pricing study, and we use it that way.

The same phrase, "website redesign", is sold at all three scopes. That is the whole reason price comparison without scope comparison produces nothing useful.

What business outcomes should the budget support?

A redesign budget becomes defensible when it is tied to outcomes the business already measures: qualified leads, sales enablement, shorter deal cycles, less manual work for the marketing team. Choosing those outcomes before scoping is what decides which parts of the project deserve money and which quietly disappear.

Vague goals cannot be priced. "A modern site" has no deliverable behind it, so every vendor fills the gap with their own assumption, and the quotes diverge again. Translate the goal into outcomes you can name to a vendor in one sentence each.

The outcome set we see most often in B2B corporate site projects looks like this:

• More qualified inbound requests: not more traffic, but more requests that pass your own qualification criteria.
• Better lead quality at the same volume: forms and content that filter out enquiries sales cannot use.
• Materials sales can send: solution pages, comparison content and case evidence that work inside a deal, not just in a campaign.
• Self-service content that reduces pre-sales load: technical detail, integration lists and pricing logic that answer questions before a call.
• Faster publishing by the in-house team: editors who can ship a page without a developer.

In our practice we ask one question before scoping anything: which of these outcomes would you personally use to defend this budget to the board? The ranking that comes back cuts features nobody can justify, and it usually cuts them faster than any negotiation over rates.

One warning. Outcomes that depend on demand generation rather than on the site itself belong to digital marketing budgets and should not be attached to the redesign budget. Pipeline growth driven by a new outbound team or a new product launch will happen with or without new templates, and pinning it to the redesign sets up a comparison nobody can win.

What work is included in the estimate?

A trustworthy estimate lists deliverables, not hours in the abstract. It should show three blocks: discovery and information architecture, design and development with integrations, and content, migration, testing and launch. Anything not named inside one of those blocks is not in the price, whatever the covering email says.

Grouping this way makes competing quotes comparable even when vendors use different internal naming. You are no longer matching line labels, you are matching deliverables: does each vendor produce a page inventory, a design system, a redirect map, an accessibility test report. When a block is missing, the gap is visible immediately instead of surfacing as a change request in month three.

Accessibility belongs in the estimate explicitly rather than as a line bolted on at the end. The W3C Web Accessibility Initiative's guidance on planning and managing web accessibility treats it as roles, reviews, training and testing distributed across a project, and budgeting it that way is cheaper than retrofitting after launch. We keep it as named work in the design, development and testing blocks, without making legal claims about any particular jurisdiction.

Discovery, research and information architecture

Discovery converts assumptions into a documented scope. The deliverables are concrete: stakeholder and sales interviews, an analytics and search review of the current site in the form of an SEO site audit, a content inventory, the target information architecture, and a page inventory mapped to templates.

This is the cheapest place in the project to remove cost from everything downstream. Cutting a template at the IA stage costs a conversation. Cutting it after design and implementation costs the design, the implementation and the rework.

When discovery is skipped to save money, the scope changes do not disappear, they just get discovered during development and priced as change requests at change-request rates. In our experience that is the single most common reason a fixed-price project ends up costing more than the time-and-materials alternative it was chosen over.

Design, development and integrations

This block is where most of the money sits. Deliverables include design system components, unique page templates, responsive states, front-end implementation, CMS template configuration, CRM and marketing automation integrations, plus forms and lead routing, all of which sit inside the web development part of the project.

The cost unit here is the unique template and the unique component, plus each integration endpoint together with its error handling. An integration that writes a lead into a CRM is not one line of work: it is field mapping, validation, retry behaviour, duplicate handling and a decision about what happens when the CRM is unavailable.

Client-side dependencies belong in the estimate too, because they set the calendar. Someone has to provide system access, own the integration on your side and decide the lead routing rules. When those are unassigned, the vendor's timeline assumptions quietly become invalid.

Content, migration, testing and launch

The third block covers content adaptation or writing, media preparation, content migration, the redirect map, SEO migration checks, functional and accessibility testing, performance checks and a launch runbook.

Content preparation and the migration of legacy pages are the most commonly underestimated lines in the whole project. A page counted as "migrated" often needs a new structure, new imagery, a rewritten intro and a decision about whether it should survive at all, and none of that is copy and paste.

Acceptance criteria belong in this block, written during scoping. Criteria agreed in writing before development are a specification. Criteria discussed after launch are a negotiation, and the client rarely wins it.

What drives cost beyond page count?

Page count is a weak predictor of website redesign cost. The real drivers are the number of unique templates, the volume and state of content, legacy systems that must keep working, the number and depth of integrations, language and market requirements, and how many people must approve each step.

Start by dismantling the page-count instinct. Two hundred pages built on four templates is a cheaper project than thirty pages built on twenty templates, because the work is in the templates and the components, not in the rows of a sitemap. Any vendor pricing per page is either pricing a visual refresh or has not looked at your site.

Before you request quotes, run your own site through this checklist:

• Unique templates: how many genuinely different page layouts exist, counting states and edge cases.
• Content state: how much content is current, owned and reusable, and how much is orphaned.
• Legacy constraints: which systems and URLs cannot change.
• Integrations: how many, in which direction, and who owns the field mapping.
• Languages and markets: which locales exist, who maintains them, and whether they differ in content or only in language.
• Approvals: how many people sign off, and whether legal or compliance review is involved.

The drivers that surprise clients most are approval chains and legacy data. Design is visible and gets scrutinised. A four-step approval cycle with a legal review at the end is invisible in a quote and doubles the calendar.

Unique templates, content volume and legacy systems

Counting templates honestly means counting states, not just layouts. A product page with an empty state, a gated state, a comparison variant and a localised legal block is not one template, and the same applies to listing and object cards in real estate website development, and the difference between the naive count and the honest one is often the difference between two quotes.

Content debt shows up as pages with no owner, outdated PDFs that sales still sends, and product data maintained in spreadsheets that nobody wants to declare as a source of truth. Every one of those becomes a decision during migration, and decisions cost calendar time even when they cost little effort.

Legacy constraints are the third driver: an ERP or customer portal that cannot change, an authentication scheme that has to survive, historical URLs that carry links and rankings built up by years of SEO in the USA. These do not make a project impossible, but they turn integration and migration lines from estimates into engineering work that has to be investigated before it can be priced.

Languages, integrations and approval dependencies

Multilingual B2B requirements are a cost driver, not an automatic upgrade to a higher project tier. Adding languages affects the translation workflow, per-locale content ownership, locale-specific templates and legal blocks, hreflang and URL structure. It does not, by itself, require a full rebuild, and any quote that jumps a tier the moment a second language appears is worth questioning.

Language is also not the same thing as country. A German-language edition of a site is a content and workflow requirement. A Germany-specific market edition is a different proposition: different legal blocks, different offers, sometimes different products and a separate content owner. Pricing those two as one item is one of the most common estimating errors we see in B2B projects, and it distorts the budget in both directions depending on which one the vendor assumed.

Integrations scale by depth rather than by count. A read-only feed into a CRM is a fraction of the work of a bidirectional sync with deduplication and conflict rules. Ask three questions per integration: which direction does data flow, is there a sandbox environment, and who owns the field mapping when it changes.

Approval dependencies close the list. The number of decision makers, the number of review cycles per artefact and the presence of legal or compliance review all add calendar time and rework. We plan review cycles explicitly for this reason: an unnamed reviewer who appears at the design approval stage costs more than an extra template.

How is the budget calculated and which pricing model fits?

Build the budget bottom-up from deliverables: count unique templates, integrations and migrated content, apply role-based effort assumptions, then add testing, launch and contingency. The pricing model follows scope certainty, so a fixed price fits a locked scope and time and materials fits work that is still being discovered. We use the same method across our English, German and Russian-language projects so that estimates stay comparable.

One rule governs the whole exercise: every coefficient is an assumption, and every assumption must be visible and challengeable. A budget where the reader cannot see which numbers were chosen and why is a quote, not a model.

Fixed price, time and materials, and phased delivery

Fixed price requires a scope locked in enough detail to be defended by both sides. It demands a complete specification, a change-request process and a client who can make decisions on schedule. What it hides is the risk premium: a vendor pricing uncertainty adds a buffer you cannot see and cannot negotiate away.

Time and materials is often cheaper in reality when scope is genuinely unknown, because you are not paying for someone else's uncertainty buffer. It demands governance in exchange: a maintained backlog, sprint reviews with working software, a spend cap, and someone on the client side who accepts or rejects work as it lands.

Phased delivery is the compromise we recommend most often. A bounded discovery phase is priced fixed, because its deliverables are known, and the implementation phase is scoped and priced using the output of discovery. The client gets a defensible number before committing the larger budget, and the vendor prices real requirements instead of guesses.

The choice comes down to one honest question: how much of the scope do you genuinely know today? If the answer is "most of it, in deliverable-level detail", fixed price is available. If not, forcing a fixed price simply converts uncertainty into a premium plus a change-request pipeline.

Illustrative calculation with explicit assumptions

The calculation below is hypothetical. The figures are assumptions chosen to demonstrate the method, not our rates, not a market average and not a quotation. Effort is expressed in units, where one unit is one person-day, so you can apply your own blended day rate and your own assumptions instead of ours.

Now change one assumption and watch which lever matters. Move the template count from 12 to 18, leaving everything else identical, and design, front-end and CMS configuration rise from 72 to 108 person-days. QA, project management and contingency scale with them, and the total moves from roughly 192 to roughly 245 person-days. A 50% increase in unique templates raises the budget by about a quarter, which is why template consolidation is the first conversation we have when a number comes back too high.

Run the same test on integrations or on migrated content volume and you will see the same effect at a smaller scale. That sensitivity is the real output of the model: not the total, but the knowledge of which three inputs your budget actually depends on.

Published vendor prices can be useful as reference points, provided nobody mistakes them for market rates. Each of the following is one supplier's own published commercial offer, quoted here as an example of packaging, not as research:

• Pixel Plus (Russia) lists regular support formats starting from 29 000 RUB, with post-paid work at 3 800 RUB per hour. One supplier's published tariff, not an average.
• OuterBox (USA) publishes a maintenance budget range of 100 to 2 500 USD per month and a development rate of 200 USD per hour. One agency's commercial offer.
• Rheinspace (Germany) publishes Betreuung packages at 119, 229 and 399 EUR per month, with the top tier including an SLA and a dedicated contact. One agency's packaging example.

Three suppliers in three markets package the same category of service in three incompatible ways. That is the point of quoting them: it shows why a support line in a quote means nothing until you read what is inside it. We do not publish our own rates in an article, because a rate without a scope is exactly the number this article argues against.

Which additional and recurring costs need a separate budget?

The project price is not the total cost of ownership. Licences, hosting, support hours, content production, analytics tooling, accessibility re-testing and post-launch iteration all continue after go-live, and they should be budgeted for at least the first year alongside the project itself.

One-off costs that quotes routinely omit, because they sit on the client side of the boundary:

• Photography and illustration: new templates expose how thin the existing image library is, which is most obvious in visual-first sectors such as beauty salons SEO projects.
• Copywriting: new structure needs new text, and adaptation is not the same as writing.
• Legal and compliance review: privacy notices, cookie handling, regulated claims.
• Third-party plugins and components: search, forms, personalisation, translation tooling.
• Data cleanup: product data, contact records and lead routing rules before integration.

Recurring costs follow their own line: hosting and CDN, CMS or component licences, monitoring, security updates, support and SLA hours, analytics and CRM seats. As the vendor support offers quoted above show, support is packaged in wildly different ways, from a monthly retainer to hourly post-paid work, so compare what is inside the package rather than the headline number.

Reserve a post-launch iteration budget explicitly. The first 60 to 90 days after go-live produce the highest-value fixes of the whole project, because that is when real user behaviour meets the new structure. Funding those fixes from a reserve is cheaper and much faster than raising a change request against a closed project.

Accessibility is an ongoing responsibility rather than a one-time audit. W3C WAI planning guidance frames it as roles, training and review cycles that continue as content changes, which in budget terms means periodic re-testing after major content or template updates, not a certificate obtained once at launch.

How do you compare agency quotes fairly?

Normalise every quote onto the same scope before you compare totals. Ask each vendor to state inclusions, explicit exclusions, client responsibilities, assumptions and change-request pricing. A cheaper quote is usually a smaller scope, not a better deal, and the difference surfaces during implementation at the worst possible moment.

The checklist below is what we ask clients to run against every estimate they receive, including ours. Each row should be answerable from the document itself, without a follow-up call.

Five red flags justify a follow-up question before anything else: a single total with no breakdown, pricing quoted per page, no named assumptions, no exclusions section, and no client responsibilities. Any one of them means the number in front of you cannot be compared with another number.

Ownership of what you buy deserves its own line in the quote. Design source files, front-end code, custom components and content all need explicit terms, and third-party licences need to be listed separately from work performed. The United Nations specialised agency for intellectual property puts the practical test plainly:

"Ventures don't necessarily need to own every line of code, but they must have clear permissions to use, modify, and commercialize the software." - United Nations specialized agency for intellectual property

Applied to a redesign, that means you do not need to own every framework and component in the stack, but you do need documented permission to keep running the site, change it and hand it to another vendor. A quote that leaves this unstated is hiding a switching cost.

In our practice we ask clients to send us the structure of competing quotes, not the prices. Differences in scope, inclusions and client responsibilities explain the gap far more often than differences in rate, and once the scopes are normalised the remaining spread is usually small enough to decide on other grounds.

How can you reduce cost through scope and phasing?

Reliable savings come from cutting scope, not from cutting rates. Reduce the number of unique templates, reuse a design system instead of designing pages, migrate only the content that earns its place, and split delivery into phases so the highest-value pages ship first. Rate negotiation moves a budget by a few per cent. Scope decisions move it by a third.

The levers, ranked by the impact we typically see:

1. Template consolidation: merging near-identical layouts is the single largest lever, because it reduces design, implementation, CMS configuration and QA at once.
2. Content pruning: pages with no traffic, no links and no owner should not be redesigned or migrated.
3. Deferring secondary integrations: connect the systems that route revenue now, add the reporting nice-to-haves in phase two.
4. Phasing site sections: ship the conversion path first, then the long tail, exactly as a dental SEO company site ships the booking flow before the blog.
5. Reusing existing platform capability: the current CMS often already does what a custom module is being proposed for.

This ties directly back to the NN/g position on incremental versus radical change: choose the smallest change your user evidence and business goals justify, validate it, and widen scope only when the evidence says the smaller change was not enough. Scope discipline is not the same thing as underinvesting.

Four things should not be cut, because each returns as rework at a higher price: discovery, QA, accessibility work, and redirects with migration checks. A skipped redirect map costs a fraction of a day during the project and can cost a quarter of organic traffic after launch.

The phasing pattern we use most often is simple: core conversion paths first, meaning the pages a buying committee actually touches, then long-tail content and secondary language editions. It also produces a real measurement window, because the first phase goes live early enough for its results to inform the second.

How do you reduce traffic and operational risks at launch?

Protect traffic with a complete redirect map, a staged launch and written acceptance criteria, and protect operations with a documented handover. When URLs change, Google's own migration guidance expects ranking and traffic fluctuation during the transition, so the plan should be monitoring and fast correction, not a promise of zero loss.

The migration control list is short and non-negotiable in our projects:

• Full URL inventory of the current site, from crawl, analytics and server logs combined.
• One-to-one redirect map with no chains and no bulk redirects to the homepage.
• Canonical and hreflang checks, especially for multilingual sites where locale URLs change.
• Sitemap and robots review before and immediately after go-live.
• Structured data parity so rich result eligibility, and the visibility in AI answer engines that GEO work depends on, is not silently lost.
• Analytics and tag migration with event parity verified against the old site.
• Form and lead-routing verification in production, with a real test lead reaching the CRM.

Google Search Central's documentation on site moves with URL changes sets the expectation directly: a move affecting URLs takes time to process and fluctuation during the transition is normal. Any vendor promising no traffic loss during a URL-changing migration is promising something outside their control. What can be committed to is the quality of the redirect map, the monitoring cadence and the response time when something breaks.

For quality checks on the new site, Google's page experience guidance is a practical checklist of what a good user experience looks like on a page. Treat it as exactly that. Performance and usability improvements are worth doing on their own merits, and they should be separated in reporting from any claim about guaranteed ranking movement.

Acceptance criteria are agreed in writing during scoping and cover five areas before go-live: functional behaviour, content completeness, accessibility checks, performance thresholds and analytics verification. A launch date without acceptance criteria is a hope, not a plan.

Operational handover is what makes the site yours after the project closes: CMS training for editors, editor documentation, a component usage guide, transfer of access and credentials, a named support entry point and a defect triage process for the warranty period. Plan the launch window with your own calendar in mind, avoid campaign peaks and quarter ends, and keep a documented rollback plan for the first days.

How do you measure business results?

Measure a redesign on business outcomes, not on visits. For B2B the core set is qualified leads, opportunities created in the CRM, and the marketing team's efficiency in publishing content and supporting sales. Baseline all of it before launch, because after launch the comparison is no longer available.

The metric set we recommend keeping small and stable:

• Qualified lead volume and quality, judged against your own qualification criteria rather than form submissions.
• Form-to-opportunity conversion, which exposes whether new forms attract better or merely more enquiries.
• CRM opportunity creation with source attribution, so the site's contribution is visible without being overstated.
• Sales enablement usage: which site materials the sales team actually sends into deals.
• Publishing throughput: pages shipped per month and time per page by the in-house team.

Instrumentation has to be budgeted during the project, not after it. Event tracking, CRM field mapping, lead source attribution and dashboards are development work, and adding them retroactively usually means a second round of QA on forms and integrations.

Be realistic about the measurement window. B2B sales cycles and seasonality mean a fair comparison often needs one to two quarters plus a matched period from the previous year, and the pre-launch baseline has to exist for that comparison to mean anything.

For the operational health of the site after launch, delivery metrics offer a useful second lens. DORA has used five software delivery performance metrics since 2024, including deployment rework rate, the share of unplanned deployments caused by incidents. We treat that as a reference for how healthy ongoing site operations are, not as a redesign ROI metric, and we would not put it in a board report about pipeline.

One discipline holds all of this together: do not attribute pipeline growth solely to the site. Report the site's contribution alongside the other changes in the same period, and the numbers will survive scrutiny from a sales director who was there.

What should you send an IT partner for an estimate?

Send the site address, the business goals the redesign has to serve, the list of systems it must integrate with, the languages and markets in scope, and your desired timing. That is enough to agree on scope and return a preliminary, assumption-based estimate without a discovery contract.

A complete request package looks like this:

• Current site URL, plus read access to analytics and search console data if you can share it.
• Business goals and target outcomes, ranked, in the form described earlier in this article.
• Integration list: system names, data direction, who owns each system internally.
• Content volume and ownership: roughly how many pages, in what state, maintained by whom.
• Languages and markets, stated separately, since a language is not a country.
• Constraints: platform requirements, security rules, hosting location, legal or compliance review.
• Desired timing, including any fixed dates such as an event or a product launch.

What we do with that package is straightforward: map it to one of the three scenarios, write down the assumptions we had to make, and return a scope-based preliminary estimate where every assumption is visible and can be corrected by you. If an assumption is wrong, the estimate changes, and that is the point of showing it.

Structured information also improves the conversation with any supplier, not only with us. As the publisher of the Secure Software Development Framework notes about structured software documentation:

"Software purchasers and consumers can also use it to foster communications with suppliers in acquisition processes and other management activities." - Publisher of the Secure Software Development Framework

Webdelo works as a B2B IT partner for mid-size companies on corporate sites, integrations and multilingual editions for the US and German markets. If you are scoping a redesign now, send us the site address, your business goals, the integration list and your desired timing, and we will come back with the project composition we would propose and a preliminary estimate with the assumptions written out.

Conclusion

Website redesign cost becomes predictable as soon as scope is defined, deliverables are named and assumptions are visible. Pick the smallest of the three scenarios your business evidence justifies, price it bottom-up from deliverables, and compare vendors on scope rather than on totals.

Five decisions set the budget, and everything else is detail:

• Scenario: visual refresh, UX/UI redesign, or full rebuild with migration.
• Unique templates and components, counted honestly with their states.
• Integrations, counted by depth and direction rather than by name.
• Content and migration volume, after pruning what should not survive.
• Pricing model, chosen to match how much of the scope is genuinely known today.

Two protections pay for themselves on almost every project: acceptance criteria agreed in writing during scoping, and a redirect and migration plan built before launch rather than after the first traffic report.

Every figure in this article is either a labelled assumption used to demonstrate the method or a single vendor's published commercial offer. None of them are market rates, and none of them should be copied into your budget without being replaced by your own inputs.

If you want a second opinion on a scope or a quote you already have, send us your site address, the business goals behind the redesign, the list of integrations and your desired timing. We will discuss the project composition with you and come back with a preliminary estimate and the assumptions behind it.