Website Redesign Cost: What Shapes the Budget?
Your website redesign cost depends on the work required to move from the current site to the desired result. Page and template counts matter, but so do content, custom features, integrations, accessibility, migration, testing and ownership after launch. Therefore, a useful estimate starts with a defined scope, not a universal price range.
This guide explains the decisions that shape a redesign budget. It also gives you a practical way to prepare for a quote and compare proposals on equal terms.
Website redesign cost starts with the scope
A redesign can mean a visual update to an existing system or a structural rebuild. Those are different projects. A visual refresh may retain the information architecture, content management system (CMS), content and integrations. By contrast, a structural redesign may change how people navigate the site, how editors publish content and how external tools exchange data.
First, define the business problem. For example, a company may need clearer service pages and stronger calls to action while keeping its current platform. Another company may need new audience journeys, multilingual content and a different CMS. Although both projects are called redesigns, the second contains more research, planning, implementation and testing.
The budget should reflect that difference. A proposal is meaningful only when it identifies what will change, what will remain and who is responsible for each part.
These scope decisions change the estimate
The following matrix connects common requirements to the work they create. Use it to find missing assumptions before asking for a quote.
| Scope driver | Question to answer | Work affected |
|---|---|---|
| Business goals | What should the redesigned site help users and the business accomplish? | Discovery, priorities, user journeys and success criteria |
| Pages and templates | How many pages exist, and how many distinct layouts or content types are needed? | Inventory, design, development, migration and QA |
| Content | Is current content ready, or does it need auditing, writing, editing or translation? | Content strategy, production, approvals and migration |
| Design depth | Will the project adapt an established system or create custom components? | Research, interface design, design system and front-end work |
| CMS | Will the current CMS remain, be reconfigured or be replaced? | Data structure, editorial workflow, development and training |
| Integrations | Which forms, analytics, CRM, ecommerce or other systems must work with the site? | Technical discovery, development, privacy review and testing |
| SEO migration | Will URLs, structure or content change? | URL mapping, redirects, metadata, validation and monitoring |
| Accessibility | Which accessibility requirements and target standard apply? | Design rules, content, development and testing |
| Launch and support | Who handles hosting, deployment, maintenance and later updates? | Infrastructure, handoff, monitoring and ongoing support |
Not every project needs every workstream. However, leaving a relevant one undefined does not remove the work. It often turns it into an assumption, exclusion or later change request.
Page count and template count measure different work
Page count tells you the volume of content to review, move and test. Template count tells you how many distinct structures must be designed and built. For that reason, a 100-page site built from five repeatable templates can have a different workload from a 25-page site with many unique layouts.
Start with a content inventory. List the current URLs, their purpose, content owner and likely action: keep, revise, merge, remove or create. Then group pages by template or content type. This reveals whether the project needs a small set of reusable components or many exceptions.
Also separate pages from states. A contact form, for instance, may need success, validation and error states. Search, account areas and ecommerce flows can add more. These details affect design and QA even when they do not appear as ordinary pages in the inventory.
Content responsibility can expand or reduce the project
Existing content rarely moves by itself. Someone must decide what stays, fix outdated material, prepare new copy, source approved media and check the migrated result. Therefore, a quote should state whether the client, the redesign partner or another team owns each task.
Content readiness changes timing as well as cost. If approved copy is available before design, the team can test layouts with realistic material. If writing happens during development, late changes may alter components, page length and approvals.
Define the handoff format too. “Client supplies content” could mean finished copy in a structured document, rough notes that need editing or text scattered across the old site. Those inputs require different amounts of work.
Template adaptation and custom design require different effort
Template adaptation works within an existing theme, framework or component library. It can be appropriate when the system already supports the needed structure and brand expression. Custom design gives the team more control over user journeys, components and visual behavior, but it also requires more decisions and implementation work.
Neither route is automatically better. The right choice depends on the business goals, brand requirements and functional constraints. For example, adapting a stable system may suit a focused marketing site. A product catalog with unusual filtering and several audience paths may need custom components.
When reviewing a proposal, look beyond the word “custom.” Ask which templates and components will be created, how responsive behavior is covered and whether a reusable design system is included. Specific deliverables make the design depth easier to compare.
CMS and integrations add dependencies
Keeping the current CMS may reduce migration work, but it does not remove technical discovery. The team still needs to understand content models, permissions, plugins, editorial workflows and hosting constraints. Meanwhile, replacing the CMS creates decisions about data structure, migration and training.
Integrations deserve their own list. Forms, analytics, customer relationship management tools, payment services, search and authentication may rely on external systems. As a result, each integration can add access requirements, edge cases and acceptance tests.
If the site uses WordPress and will move between servers or installations, the official WordPress migration documentation outlines considerations such as files, database data and configuration. Your proposal should translate the relevant technical tasks into named deliverables and responsibilities.
URL changes need an SEO migration plan
When URLs change, a redesign needs more than a new interface. Old URLs must be mapped to relevant new destinations, redirects must be implemented and the move must be checked after launch. Google Search Central’s site-move documentation recommends preparing URL mapping and using permanent server-side redirects for changed URLs.
Therefore, ask whether the scope includes a URL inventory, redirect map, metadata transfer, analytics checks and post-launch monitoring. If the information architecture and URLs will remain unchanged, the migration scope may be smaller. Still, the team should verify that important pages, metadata and tracking survive deployment.
SEO migration does not guarantee unchanged rankings. It is a risk-management workstream that helps search engines and users reach the intended content after structural changes.
Accessibility and QA must be defined before testing
Accessibility affects design, content and code, so it should not appear only as a final test. The Web Content Accessibility Guidelines (WCAG) 2.2 provide testable success criteria across three conformance levels. The project brief should identify the relevant target and how it will be evaluated, without treating a technical standard as a universal legal conclusion.
Quality assurance also needs boundaries. At minimum, define the browsers, devices, viewport ranges, content types, forms and integrations to test. Then state who fixes issues and what counts as acceptance.
A short review on one desktop browser is different from structured testing across representative devices and workflows. Consequently, two proposals may contain very different QA effort even if both list “testing” as a deliverable.
Initial work and ongoing responsibilities belong in separate columns
A redesign proposal is easier to understand when one-time project work is separated from recurring responsibilities.
| Initial redesign work | Ongoing responsibility |
|---|---|
| Discovery and requirements | Hosting and infrastructure |
| Information architecture and content planning | Software or service licenses |
| Interface and component design | Maintenance and security updates |
| Development and integration setup | Monitoring and incident response |
| Content migration and redirect implementation | Content operations |
| Pre-launch QA and deployment | Support and future improvements |
This distinction does not mean the same provider must handle both columns. Instead, it makes ownership visible. A proposal should say what is included for launch, what continues afterward, who owns accounts and assets, and whether support has a separate agreement.
Compare proposals by normalizing the scope
Headline totals are not comparable when the underlying work differs. Before choosing, put each proposal into the same set of rows: goals, inventory, content, design, CMS, integrations, migration, accessibility, QA, launch and post-launch ownership.
Next, compare five things for every row:
- Included work and deliverables
- Exclusions and client responsibilities
- Assumptions used to prepare the estimate
- Acceptance criteria or review rounds
- Ownership after handoff
For instance, one proposal may include content migration, redirect mapping and launch support. Another may assume the client handles all three. The lower total is not necessarily cheaper once the missing work is assigned.
If you need a more formal document for collecting responses, use our website redesign RFP checklist. When the scope is clear and you are evaluating potential partners, our guide to choosing a website design company covers selection criteria beyond price.
Prepare these inputs for a redesign quote
A useful brief does not need to solve the project in advance. It needs enough detail for a provider to identify the work, risks and open questions. Prepare:
- Current website URL and any related sites or platforms
- Business goals and priority user actions
- Main audiences, languages and markets
- Current page inventory and estimated new pages
- Expected templates or content types, if known
- Content status and responsibility for writing, editing, media and migration
- Brand guidelines and desired level of visual change
- CMS preferences, editorial roles and access constraints
- Required integrations and the owner of each external system
- Known URL changes and SEO migration needs
- Accessibility target and testing expectations
- Approval stakeholders, review process and fixed launch constraints
- Hosting, maintenance, monitoring and support responsibilities after launch
Also label unknowns. A good discovery process can resolve them, but they should not be hidden inside a fixed assumption. Finally, ask each provider to show optional items separately and explain what could change the estimate.
Before launch, turn the accepted scope into a testable plan. Our website launch checklist can help you review content, functionality and technical details without confusing launch work with long-term maintenance.
A realistic budget begins with a comparable brief
There is no responsible universal answer to what a redesign should cost. The useful answer comes from defining the desired change, measuring the content and template workload, documenting technical dependencies and assigning responsibility for migration, QA and support.
Once those inputs are clear, you can compare proposals based on the same outcome instead of a vague label. ID7 Studio develops websites with design decisions tied to strategy, clarity and business goals. If you are preparing a redesign, request a tailored proposal based on your actual scope.
