Website Redesign Cost: Estimate and Compare a Real Budget

Website redesign cost: start with the scope

A useful website redesign cost is a scope-based estimate, not a borrowed market average. Start with the pages, content, workflows, integrations, and operating responsibilities that exist now. Decide what the new site must accomplish, then estimate the work required to move from the current state to that result.

A complete estimate separates discovery, content, design, implementation, integrations, migration, testing, launch, and monitoring. It also keeps one-time work separate from recurring platform, hosting, software, and support costs. This makes the estimate easier to explain, revise, and compare with a proposal.

The honest answer to “how much does a website redesign cost?” is therefore a method rather than a universal number. The same page count can describe a small visual refresh, a full rewrite, a platform migration, or a change to the business workflows behind the site. Those are different projects and should not share one price assumption.

• Inventory the current pages, templates, forms, media, data, and integrations.
• Name the business outcome and the visitor journeys the redesign must support.
• Decide what to keep, rewrite, merge, migrate, or remove.
• List workstreams, quantities, owners, dependencies, and acceptance evidence.
• Estimate low, likely, and high effort instead of one falsely precise total.
• Record fixed and recurring third-party costs on their own lines.
• Keep contingency visible and tied to known uncertainty.

Estimate the work in a defensible sequence

Begin with an inventory. Export the current CMS content, review the sitemap, look at representative analytics, and crawl the public site. Reconcile those sources because each may contain items that the others miss. Record the purpose and owner of each page, template, form, integration, document, and media group.

Next, give every content item a decision. A keep moves with limited change. A rewrite retains the topic but requires new copy. A merge combines several items and needs a decision about what survives. A migration moves content or data between systems or formats. A removal still needs a URL, archive, or retention decision. Counting these decisions is more informative than counting pages alone.

Turn the decisions into workstreams that can be assigned and accepted. Discovery, content, design, implementation, integration, migration, accessibility, testing, launch, and monitoring are useful starting categories, but the names should match the real project. A workstream without an owner, dependency, or definition of done is not ready to estimate.

For each workstream, identify a unit and quantity before estimating effort. A unit may be a page, template, component, form, integration, redirect, review cycle, or user journey. Estimate low, likely, and high effort per unit. Keeping quantity and effort separate shows whether uncertainty comes from an incomplete inventory or from genuinely variable work.

GOV.UK's service guidance is written for government digital services, not small-business websites, but it provides a useful boundary: understand the problem, users, constraints, and wider journey before committing to a build solution. It also treats delivery as multidisciplinary work whose required skills change by phase. For a redesign estimate, that means identifying missing capabilities instead of assuming one role covers research, content, design, engineering, accessibility, testing, and operations.

Build a website redesign cost worksheet

Copy the columns below into a spreadsheet and create one row per workstream, or one row per group of similar items when they will be delivered and accepted together. The worksheet is intentionally on the page: WebmastersGallery is not offering a public download until its download gate and list separation are complete.

Use one unit consistently within a row. Keep the quantity, effort, rate, and fixed-cost fields separate so a reviewer can challenge the right assumption. Record billing frequency beside every fixed cost. A platform subscription and a one-time migration task should not disappear into the same total.

Acceptance evidence should describe something observable. “Homepage complete” invites disagreement. A clearer entry records the approved breakpoints, required states, real content, form delivery result, accessibility checks, or other evidence that both sides agreed to review.

Record assumptions, exclusions, and contingency

An estimate only holds while its assumptions hold. State who supplies final copy, whether the current data exports cleanly, which accounts and credentials will be available, how many review cycles are included, and what is already approved. Put dependencies beside the person or organization that controls them.

Write exclusions with the same care as deliverables. New photography, translation, data cleanup, copy approval, legal review, marketing automation, or post-launch support may belong to the owner rather than the vendor. They still consume time or money even when they are outside a proposal.

Use a visible contingency for known uncertainty instead of padding individual estimates. A labeled contingency can be discussed and reduced as questions are answered. It is not a substitute for undefined scope. If a workstream is unscoped, keep it open until discovery establishes the quantity, owner, dependency, and acceptance evidence.

Keep the worksheet after launch and compare the likely scenario with the actual result. That comparison can improve the next estimate because it uses the organization's own delivery evidence rather than an unrelated project's average.

Identify the cost drivers that apply to this redesign

The largest source of variation is usually not a label such as “small-business site” or “marketing site.” It is the set of workstreams underneath the label. Use the inventory to decide which of the following drivers are present and how they change quantities, skills, dependencies, and testing.

• Content decisions: pages that need rewriting, merging, fact review, approval, new photography, or document cleanup.
• Custom components: calculators, directories, filters, configurators, and other features that require their own design, implementation, and testing.
• Business integrations: payments, booking, inventory, CRM, email, forms, and notification delivery.
• Data migration: field mapping, duplicate cleanup, export limits, imports, reconciliation, and retention decisions.
• URL changes: inventory, mapping, redirects, verification, and post-launch monitoring.
• Accessibility: goals, reviews, user involvement, training, tooling, remediation, and specialist support when needed.
• Analytics and consent: event definitions, tags, consent behavior, reporting boundaries, and production verification.
• Multilingual content: translation workflow, review, URL structure, templates, and continuing maintenance for each language.
• Stakeholder reviews: the number of approval points, decision owners, and included review cycles.
• Post-launch operation: monitoring, error handling, fixes, documentation, account ownership, and recurring subscriptions.

Separate five different kinds of redesign

A visual refresh changes presentation while keeping the platform, structure, content, and URLs largely stable. The estimate concentrates on design, component updates, implementation, and testing.

A template or platform rebuild moves the site onto a new foundation. Existing content may survive, but templates, accounts, integrations, data, and operational responsibilities have to be re-established. The platform decision affects both the project work and the recurring cost.

A content and information-architecture redesign changes navigation, page structure, and the content itself. Inventory, writing, subject-matter review, approvals, and redirect decisions become substantial workstreams rather than minor implementation details.

A migration with URL or domain changes also moves addresses. Google Search Central recommends preparing and testing the new site, mapping old URLs to new destinations, configuring permanent redirects, and monitoring old and new URLs. Budget each activity with an owner and acceptance evidence. The guidance does not guarantee rankings, traffic preservation, or a fixed processing period.

A redesign that changes a business workflow introduces operational work. A new booking, payment, CRM, or inventory flow needs integration setup, data and permission decisions, end-to-end testing, notification checks, staff ownership, and a fallback. Estimate it as a workflow change, not as a visual feature.

A project can contain more than one type. Label each part of the scope so the predictable visual work is not averaged together with uncertain content, migration, or integration work.

Make every proposal show the same information

A proposal total becomes meaningful only when the included work is visible. Normalize competing proposals against the same inventory and worksheet before comparing them. A lower total may represent a different quantity, fewer responsibilities, narrower acceptance criteria, or third-party costs billed elsewhere.

Scope should describe what is included specifically enough to recognize completion. Deliverables should name the artifacts the business receives. Responsibilities should separate vendor work from owner work. Assumptions and exclusions should explain what makes the estimate valid and what is outside it.

Record how changes are requested, approved, estimated, and documented. List third-party fees with the party that owns each account and renewal. Define launch support, the post-launch window, and how both sides will accept the work. Ask who owns the domain, hosting, platform account, code, content, media, data, and export path.

This is a comparison checklist, not legal or procurement advice. Contract terms, data obligations, intellectual-property questions, and regulated requirements may need qualified review appropriate to the organization.

• Scope and quantities
• Deliverables and acceptance evidence
• Vendor and owner responsibilities
• Assumptions and exclusions
• Change handling and review cycles
• One-time and recurring third-party fees
• Launch and post-launch support
• Account ownership, data access, and portability

Budget the safeguards before launch

Discovery is a budget control because it turns an assumed solution into a defined problem, scope boundary, and set of risks. GOV.UK advises using discovery to understand users, constraints, and the wider journey before starting a build. Its timings and staffing model are government-service guidance, not website-redesign benchmarks; the transferable point is to make the important unknowns visible before committing to implementation.

Accessibility requires its own planned resources. W3C states that budget and resource needs depend on accessibility goals and the extent of work. It identifies evaluations, involving users with disabilities, policy and procedure review, staff training, tooling, and experienced support as considerations. W3C also recommends integrating accessibility through planning, implementation, and continuing review. This guide does not certify conformance or provide legal advice.

For a site move, inventory and map URLs before cutover. Test the replacement, redirects, primary journeys, and notification delivery. Google's guidance recommends changing one major thing at a time where possible; when domain, platform, URL structure, hosting, and layout changes must be combined, make the additional dependencies, rollback decisions, and monitoring work explicit.

Plan measurement before launch. Record the baseline, events, reports, owners, review window, and decision thresholds that the project will use. Monitoring is a workstream with a start, an owner, evidence, and an end condition, not a note added after production changes.

Use an illustration without turning it into a benchmark

The inputs below are invented to show how a worksheet behaves. They are not typical, do not come from a real project, and carry no currency or time unit. “Effort unit” can mean any unit the reader applies consistently. The values demonstrate where uncertainty sits; they do not predict anyone else's redesign.

Imagine a services business with a forty-page site that remains on its current platform. Its inventory produces fourteen keeps, sixteen rewrites, six merged destinations, and six removals. The scope includes one existing contact form and one new booking integration, but no domain change.

Read the shape rather than the numbers. The new booking workflow has a wider range than the existing contact form because more setup and end-to-end testing remain unknown. Keeps carry less effort than rewrites. URL work follows from merges and removals. Fixed platform or booking costs would sit on separate rows with their billing frequency.

Normalize bids before comparing totals

Restate every proposal against the same workstreams, quantities, responsibilities, fixed costs, and acceptance evidence. If one proposal assumes final copy and another includes writing, their totals are not comparable until owner-side work is shown. If one includes platform fees and another bills them separately, move those fees into the same fixed-cost view.

Differences in quantity deserve review before differences in price. Two vendors may have interpreted the inventory differently or may be planning different numbers of templates, integrations, redirects, and review cycles. Resolve the scope difference first.

Acceptance evidence also changes the project. A visual approval is not equivalent to verified forms, notification delivery, responsive states, accessibility checks, redirect results, and post-launch monitoring. Normalize the definition of done before treating a lower total as a saving.

After normalization, a remaining gap can reflect a real difference in approach, capability, capacity, or margin. Ask the vendor to explain the gap and record the answer as an assumption, exclusion, or change to the scope. The goal is not to force identical proposals; it is to know what each total actually buys.

How we reviewed this website redesign cost guide

WebmastersGallery built this guide from primary-source research on discovery, multidisciplinary delivery, accessibility resourcing, and site moves. We did not use an agency-quote database, conduct a vendor bidding exercise, or add an unsupported market average.

The estimating worksheet is an editorial framework. It does not provide a quote, prescribe a rate, certify accessibility, promise search performance, or replace legal, procurement, accounting, or specialist advice. The reader supplies the real inventory, effort units, rates, fees, owners, constraints, and acceptance requirements.

The source claims were checked on July 27, 2026. Guidance and product requirements can change, so revisit the primary sources when the project includes a site move, accessibility commitment, or regulated obligation.