The short answer
A defensible website redesign budget is a scope model, not a guessed price. Define outcomes, page and content patterns, integrations, migration risk, responsibilities and acceptance criteria. Compare quotes by normalising inclusions, exclusions, assumptions and recurring costs. Hold a controlled contingency for known uncertainty and assign ownership before approving work.
- Budget by workstream, responsibility and acceptance criteria rather than page count alone.
- Normalise proposals before comparing totals because identical labels often hide different scopes.
- Separate implementation costs from recurring services and optional improvements.
- Keep contingency controlled through a risk register and explicit change process.
On this page
The short answer: price follows responsibility and uncertainty
Website redesign cost cannot be estimated responsibly from page count alone. Ten unique service pages with interviews, migration and integrations can require more work than a larger library built from stable templates and approved content. Start by defining outcomes, repeatable page types, content condition, technical dependencies and who does each task.
A useful budget shows four layers: discovery and decisions, creation and implementation, transition and assurance, and ongoing operation. Quotes become comparable only when each supplier responds to the same scope and states assumptions and exclusions.
Do not ask for a false-precision figure before the team has inspected the current site. Ask for a range tied to assumptions or fund a bounded discovery stage that produces a firmer plan.
- Define the business outcome and priority journeys.
- Inventory content types, languages, integrations and migration needs.
- Assign client and supplier responsibilities.
- Specify acceptance evidence.
- Separate one-time, recurring and optional costs.
| Budget layer | Typical decisions | Evidence before approval |
|---|---|---|
| Discovery | Audience, goals, scope and constraints | Agreed brief and decision log |
| Creation | Content, design, templates and build | Approved samples and working components |
| Transition | Migration, redirects, testing and launch | Mapping, test results and launch plan |
| Operation | Hosting, maintenance, licences and improvement | Owner, service terms and renewal schedule |
Define scope with patterns, not just a page total
Pages are useful inventory units but poor effort units. Group the site into page types such as homepage, service detail, sector landing page, case study, article and contact. For each type, record how many instances exist, whether content is reused, who supplies source material and which approvals are needed.
Add languages separately because translation is a workflow, not a multiplication button. Decide whether translation includes adaptation, terminology review, local proof, metadata, image text, forms and future updates. A multilingual site also needs a clear owner for keeping versions aligned.
Record integrations by behaviour. “CRM integration” is not enough. Specify the fields sent, validation, consent, routing, failure handling, confirmation and test evidence.
| Scope unit | Questions that change effort | Acceptance evidence |
|---|---|---|
| Page type | Unique structure or reusable template? | Approved template on agreed viewports |
| Content item | New, revised, migrated or removed? | Approved copy and source record |
| Language version | Translated, adapted and reviewed by whom? | Named reviewer signs off |
| Integration | What data moves and what can fail? | Test cases pass end to end |
| Asset | Who owns, selects and licences it? | Usage rights and files recorded |
Build the budget by workstream
A workstream budget makes omissions visible. Discovery covers research, stakeholder alignment, analytics review and requirements. Content covers audit, information architecture, copy, editing, translation and migration. Experience design covers journeys, wireframes, visual direction and responsive states. Implementation covers templates, content model, integrations and configuration. Assurance covers accessibility, performance, browser and form testing. Transition covers redirects, analytics, training and launch support.
Ask whether project management, meetings, feedback rounds and handover are included. These activities consume real capacity and should not disappear behind “included” when proposal assumptions differ.
For each workstream, state the responsible party and dependency. Client-supplied copy is not free if nobody internally has time or authority to produce it.
Fictional arithmetic example, not Website Rebuild pricing, a market average or a quote: a buyer enters 24 hours for discovery and content, 36 hours for design and implementation, and 20 hours for migration and assurance. At a purely illustrative CHF 120 entered rate, 80 hours equals CHF 9,600. Add CHF 600 of confirmed project-specific tools and the planning total is CHF 10,200. The calculation is useful because its assumptions are visible. Another proposal with the same total might exclude translation, content entry or support. Replace every figure with quantities and rates from your own scope and suppliers.
- Discovery and decision-making.
- Content strategy, production, translation and migration.
- Information architecture and responsive design.
- Development, CMS configuration and integrations.
- Quality assurance, accessibility and performance checks.
- Search transition, analytics and launch.
- Training, documentation and warranty support.
| Workstream | Client responsibility example | Supplier responsibility example |
|---|---|---|
| Content | Provide source facts and approve claims | Interview, draft, edit and enter approved copy |
| Design | Choose one decision owner | Produce states and document component behaviour |
| Integration | Provide account access and data rules | Implement, test failures and document setup |
| Launch | Approve readiness and staff rota | Execute checklist and monitor technical issues |
Compare quotes with a normalisation sheet
Place proposal totals aside until you have mapped scope. Create one row for every required deliverable and responsibility, then mark each quote included, excluded, allowance, client-supplied or unclear. Request clarification in writing.
Watch for identical phrases that conceal different depth. “Content migration” might mean automated import, manual placement into new templates, or rewriting and quality control. “Responsive design” might mean a few layouts or documented behaviour across component states. “SEO” might refer only to metadata or include URL inventory, redirects and monitoring.
Evaluate the commercial model too. A fixed price transfers some defined-scope risk to the supplier but usually relies on strict assumptions. Time-based work allows change but needs priorities, reporting and spending controls. A phased model can reduce uncertainty before the largest commitment.
| Comparison field | Quote A | Quote B | Clarification needed |
|---|---|---|---|
| Content | Client supplies final copy | Copywriting included for named templates | Who migrates legacy articles? |
| URL transition | Redirects mentioned | Inventory, map and redirect testing | How many URLs and who approves mappings? |
| Feedback | Two rounds per stage | Weekly collaboration | What counts as a round or change? |
| Support | Thirty-day defect period | Monthly service proposed | Define defects, response and optional work |
Expose ownership and recurring costs
The implementation price is only one part of website cost. Record hosting, domains, software licences, fonts, stock assets, consent tools, security services, backups, monitoring, support retainers and third-party integrations. For each, list account owner, billing party, renewal date, cancellation route and export options.
Prefer accounts held in the client’s name where practical. Require access to the domain, hosting, CMS, analytics, source files and repositories appropriate to the project. Document what happens to data, licences and functionality if an ongoing service ends.
Separate necessary recurring operation from optional improvement. Hosting and critical maintenance may be necessary. Content production, conversion experiments and campaign landing pages can be optional planned work. This makes the approval decision honest.
- Supplier and legal owner of each account.
- Billing frequency and renewal mechanism.
- What support is included and what triggers extra work.
- Data and content export process.
- Access, source files and handover materials.
- Consequences of ending the relationship.
| Recurring item | Owner question | Exit question |
|---|---|---|
| Domain | Whose registrar account holds it? | Can the business transfer it directly? |
| Hosting | Who controls configuration and backups? | How are site and database exported? |
| Licence | Is it client-owned or supplier-bundled? | What stops working if it ends? |
| Support | What response and work are included? | How is support cancelled or replaced? |
Budget migration and launch as real work
A redesign can preserve the domain while still changing URLs, content and internal links. Google advises preparing a map from old URLs to new destinations and using permanent server-side redirects for permanent moves. It also recommends updating internal links and monitoring the transition. These activities require inventory, decisions, implementation and testing, so they belong in the quote.
Include analytics configuration and verification, form delivery tests, consent behaviour, accessibility checks, performance testing, content proofreading, backups, rollback planning and staff availability. The website launch checklist should name the person authorised to decide whether the site is ready.
Do not let “launch included” conceal the first days of support. Define the defect window, response route, monitoring and who handles urgent content or integration corrections.
- Old URL inventory and approved destination map.
- Permanent redirects and direct internal-link updates.
- Analytics and key action verification.
- Forms tested through delivery and response.
- Backup, rollback and launch authority.
- Post-launch defect triage and monitoring.
Use contingency without creating a blank cheque
Contingency should cover identified uncertainty, not undefined ambition. Maintain a risk register with probability, impact, owner and response. Examples include undocumented integrations, weak source content, unavailable reviewers or legacy URLs that cannot be exported cleanly.
Release contingency through a written change process. Every change should state the reason, scope, cost or time effect, and which priority moves if the total budget stays fixed. This prevents small additions from accumulating invisibly.
A useful prioritisation model separates must-have launch requirements, should-have improvements and later opportunities. Protect the customer journey, regulatory obligations, data integrity and operational ownership first.
| Risk | Early evidence | Budget response |
|---|---|---|
| Legacy content is inconsistent | Sample audit finds duplicates and missing owners | Fund deeper inventory before migration |
| Integration is undocumented | No test account or field specification | Create a technical discovery item |
| Approvals may be slow | Several stakeholders can veto copy | Name one owner and schedule review windows |
| New ideas appear during design | Backlog grows after every review | Use launch priorities and change control |
Set payment milestones around evidence
Milestones should correspond to reviewable outputs and decisions. A deposit may reserve capacity, but later payments can align with an agreed brief, approved direction, working templates, migration readiness and launch acceptance. The contract should state what approval means and how delayed client inputs affect the plan.
Acceptance criteria need to be observable. Replace “modern, fast and SEO-friendly” with named journeys, supported browsers or devices, content and redirect checks, form-delivery evidence, access handover and agreed performance testing conditions. Avoid guarantees of rankings or lead volume because the supplier cannot control every influence.
Retain a written list of known limitations and post-launch items. Acceptance does not require pretending that optional work was included.
- Deliverable and decision owner.
- Review window and number of included revision cycles.
- Objective acceptance evidence.
- Dependencies and delay treatment.
- Defect definition and correction window.
- Handover items and access confirmation.
Prepare a decision-ready request for proposals
Send each supplier the same concise pack: business objective, priority users and journeys, current-site inventory, page patterns, languages, integrations, responsibilities, constraints, desired operating model and acceptance expectations. Invite suppliers to challenge assumptions and identify risk.
Ask for a scope breakdown, delivery approach, team roles, client inputs, exclusions, recurring costs, ownership and change process. Relevant work examples are useful when they explain a comparable constraint and the supplier’s contribution, not merely show an attractive industry screenshot.
A free homepage concept can help test message hierarchy and mobile direction before implementation. Treat it as one input to scope. Implementation, hosting and ongoing work still require separate quotes and commercial agreement.
YOUR QUESTIONS, ANSWERED
Frequently asked questions
How much does a website redesign cost?
There is no responsible universal figure. Cost depends on strategy, unique page patterns, content, languages, integrations, migration, assurance, responsibilities and ongoing services. Define those elements before comparing estimates.
What should a website redesign quote include?
It should identify deliverables, assumptions, exclusions, client responsibilities, review cycles, acceptance criteria, ownership, recurring charges and change handling. Migration and post-launch support should be explicit when relevant.
Should we ask for a fixed-price website redesign?
Fixed pricing can suit a stable, well-defined scope. If important requirements are uncertain, a paid discovery phase or phased estimate can resolve them before the larger commitment.
How much contingency should we include?
Set contingency from the project’s identified risks rather than applying an unexplained universal percentage. Record each risk and require written approval before contingency is used.
Which recurring website costs should we expect?
Common categories include domain registration, hosting, licences, monitoring, maintenance, support and third-party services. The actual set depends on the chosen architecture and service model, so require a renewal and ownership schedule.
Who should own the website accounts and files?
The business should have clear access and documented rights to the domain, content, data, analytics, design outputs and appropriate source files. Contracts should explain licences, third-party components and what can be exported or transferred when services end.
CHECK THE DETAIL
