Website Redesign Scope: What a Buyer Should Lock Before Quotes

Turn the redesign brief into a quoteable scope

"Redesign our website" is not a stable unit of work. One supplier may price a visual reskin of existing pages. Another may assume new information architecture, copywriting, a content-management migration and a rebuilt component library. Both proposals can be internally reasonable while remaining impossible to compare.

Start with the business outcome and the boundaries. State whether the project is intended to clarify positioning, improve lead capture, replace an unsupported platform, meet accessibility requirements, improve performance or consolidate websites. Record which outcomes are priorities and which are constraints. A redesign cannot by itself guarantee traffic, leads or rankings, so do not make those results acceptance criteria.

Attach a current-state pack: crawl or URL inventory, analytics baseline, search queries and landing pages, content exports, form and integration list, brand files, hosting architecture, known accessibility defects and representative performance measurements. Label assumptions that still need discovery.

Ask suppliers to price the same discovery output before committing to a full build if the inventory is incomplete. The result should be a signed scope matrix, not only a presentation. Every row needs an owner, deliverable, acceptance method, dependency and exclusion.

Choose the redesign depth before choosing the supplier

A reskin keeps most content, URLs and platform behavior while changing the visual system. It is usually the narrowest option, but it preserves structural problems. A template rebuild changes page architecture and components while keeping the platform. A platform migration changes the content model, publishing workflow, integrations and operating responsibilities. It has the widest test surface.

Do not bundle a domain move, platform change, content rewrite and rebrand without naming the interactions. Google recommends changing one major element at a time where practical because simultaneous changes make migration problems harder to isolate. [1]

A good proposal states which redesign depth it assumes and prices optional work separately. If the buyer cannot identify the depth, fund a short discovery rather than forcing suppliers to hide risk inside contingency.

Lock the content, template and component inventory

Count content before counting pages. A 200-URL site might use eight templates, but each URL still needs a disposition: keep, revise, merge, remove or redirect. Record the content owner, source, target template, rewrite status, legal review, assets and migration method. Distinguish copywriting from content entry and content entry from migration scripting.

Define templates by purpose and data, not by a screenshot. Typical entries include home, service detail, product detail, category, article, case study, contact and utility pages. For each one, list required fields, optional blocks, structured data, navigation behavior, responsive layouts, empty states and editor controls.

The component inventory should include every interaction state. A button needs default, hover, focus, disabled and loading behavior. A form needs labels, instructions, validation, error summary, success confirmation and failure handling. Navigation needs keyboard behavior, current-page indication and small-screen behavior. Cookie or consent interfaces need their own states.

Require a content freeze or a controlled delta process before migration. If editors keep changing the source site, identify the final export time and who reconciles late changes. State whether the supplier must preserve revision history, authors, dates, media metadata and redirects from attachments.

Make URL and search migration a named deliverable

Every current URL needs a launch outcome. Keep valuable URLs unchanged where possible. When a URL must change, map it to the closest relevant new destination and implement a server-side permanent redirect. Do not redirect every removed page to the home page, and do not create chains through multiple old URLs.

Google's site-move guidance tells owners to prepare an old-to-new URL map, test the new site, configure redirects and submit a sitemap. It also warns that significant moves can cause temporary search fluctuations while URLs are recrawled and reindexed. [1] A proposal should therefore include the mapping, redirect implementation, validation and post-launch monitoring, not promise unchanged rankings.

Lock canonical behavior, indexability, robots rules, XML sitemap generation, internal links, structured data and handling for removed content. Google treats redirects and canonical annotations as strong canonical signals and sitemap inclusion as a weaker signal. It advises consistent signals and self-referential canonicals on canonical pages. [2]

Acceptance evidence should include a machine-readable URL map, zero redirect loops, no unexpected development noindex directives, no internal links to redirected URLs, correct status codes for removed pages and a sitemap containing only preferred indexable URLs.

Specify accessibility as tests, not a promise

"Accessible website" is too vague to price or accept. Name the target, usually WCAG 2.2 Level AA where appropriate to the organization, the page and component sample, supported browsers and assistive technologies, test stages, defect severity and who remediates failures. Legal obligations vary, so the buyer should obtain jurisdiction-specific advice rather than treating a technical checklist as legal certification.

WCAG 2.2 is a W3C Recommendation and W3C recommends it as the current conformance target. It adds criteria addressing issues such as focus not being obscured, dragging alternatives, minimum target size and accessible authentication. [3]

Require automated checks and manual review. Manual scenarios should cover keyboard-only navigation, visible focus, zoom and reflow, headings and landmarks, forms and errors, alternative text, contrast, dialog focus, motion controls and representative screen-reader tasks. Automated tools find only part of the problem.

Put accessibility into design acceptance, component acceptance and final content QA. A technically sound template can still fail when an editor uploads an unlabeled image or writes an unclear link. The handover should include authoring guidance, known exceptions, test evidence and an owner for issues found after launch.

Set performance budgets on representative pages

A single desktop Lighthouse score is not a performance contract. Choose representative page types, a mobile test profile, network and device conditions, cache state, geography and a repeatable build-time test. Separate lab acceptance before launch from field monitoring after real users arrive.

Google's current Core Web Vitals guidance defines good thresholds as LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, evaluated at the 75th percentile separately for mobile and desktop. [4] Field data needs enough traffic and time, so a new site may not have immediate field evidence. Lab tests are useful for prelaunch regressions, but Google notes that field conditions and interaction behavior can produce different results. [5]

Budget the causes, not only the scores: maximum critical CSS and JavaScript, image formats and dimensions, font files, third-party tags, video behavior and layout reservations. Identify who can add scripts after launch and how regressions are reviewed.

A fair acceptance clause might require agreed lab budgets on named templates at launch, no severe regression from the baseline and real-user monitoring installed for post-launch review. It should not demand field percentile data that cannot exist yet.

Define measurement, consent and integrations before build

Create a measurement plan that maps each business question to an event, trigger, parameters, consent condition, reporting destination and test case. Common events include form start, form success, qualified lead, demo booking, telephone click, document download and checkout milestones. Define the authoritative success signal. A button click is not the same as a completed form or accepted CRM record.

Include analytics property ownership, tag manager access, cross-domain behavior, campaign parameters, internal-traffic handling, consent behavior and data retention. Google Analytics DebugView displays events and parameters as they are collected in real time, but events may be absent when client-side privacy controls or consent settings prevent collection. [6] Test both consented and non-consented paths against the approved policy.

Inventory forms, CRM, marketing automation, search, payments, chat, email, maps and any authentication. For each integration, name the environment, credentials owner, data fields, validation, timeout, retry, duplicate handling, error notice and fallback. Use test accounts and synthetic records, never production secrets in design files.

Acceptance should prove that the browser event, server response and destination record agree for a controlled test. Export the final event dictionary, tag configuration and integration runbook to buyer-owned access.

Worked example: scoping a B2B software redesign

Consider an invented B2B software company with 146 public URLs, 12 service pages, 38 articles, three lead forms and two languages. The current platform is supported, but the templates are inconsistent and editors cannot reuse approved sections. This is a planning example, not a client result.

The buyer chooses a template rebuild, not a platform migration. The scope keeps all valuable URLs, introduces seven templates and 24 documented components, rewrites the home page plus 12 service pages, and migrates the remaining approved content without rewriting it. The buyer supplies translations and legal text. The supplier owns template implementation, content entry for rewritten pages, automated migration for approved articles and a reviewed redirect map.

Acceptance covers WCAG 2.2 AA against the seven templates and critical journeys, agreed mobile lab performance budgets, self-canonicals, structured data, a clean sitemap and three form submissions reaching the CRM with the correct source parameters. A ten-URL pilot is tested before full migration. The old site remains available to the team for rollback during the agreed cutover window.

Supplier A quotes only design and development. Supplier B includes content modeling, migration scripts, redirects, accessibility evidence and handover. B's headline number is higher, but the matrix reveals that A leaves six required workstreams unpriced. The comparison becomes about total accepted scope rather than a misleading price gap.

Compare proposals on exclusions, evidence and ownership

Issue the same scope matrix to every bidder and require them to mark each row included, optional, excluded or assumption. Ask for deliverable examples with confidential information removed: component documentation, test report structure, redirect-map format, release checklist and handover index. Evidence of process is more useful than a gallery alone.

Compare team roles, review rounds, response times, dependency dates, change-control method and payment milestones. Separate fixed-price work from discovery, uncertain integrations and ongoing operations. Require rates or a pricing formula for approved changes.

State ownership of design source files, code, domains, hosting, analytics, fonts, stock assets, plugins, licenses and accounts. Record recurring costs and renewal owners. The buyer should receive repository access, environment documentation, deployment instructions, backups, credentials through a secure channel and an exit path.

A website development proposal should be tested against the same matrix whether it comes from TechLithic or another supplier. If the redesign includes substantial journey or interface work, evaluate the separate UI and UX design scope. Reject vague promises, inaccessible proprietary dependencies, undisclosed recurring fees and acceptance based only on subjective approval.

Use a buyer acceptance and launch checklist

• Is the redesign depth named: reskin, template rebuild or platform migration?
• Does every current URL have a keep, revise, merge, remove or redirect decision?
• Are templates, components, interaction states and responsive behavior enumerated?
• Are copywriting, content entry, migration and translation responsibilities separate?
• Are redirects, canonicals, internal links, indexability, schema and sitemap acceptance tests written?
• Is the accessibility standard, conformance level, sample, manual test plan and remediation owner explicit?
• Are performance budgets tied to representative pages, devices and test conditions?
• Does every analytics event have a trigger, parameter, consent rule and destination test?
• Are integration failures, retries, duplicates and fallback behavior covered?
• Are browser support, security checks, backups, rollback and launch ownership defined?
• Will buyer-owned accounts contain the repository, design files, domains, analytics and deployment access?
• Are recurring licenses, hosting, maintenance, warranties and post-launch support priced?
• Are exclusions, assumptions, dependencies and change-control rules visible beside the quote?
• Does final acceptance require evidence, not only a stakeholder saying the pages look right?

Do not commission a redesign when the problem is only a broken form, unclear offer, missing content or a single slow template. Fix and measure the narrow problem first. Redesign when the current structure, system or experience blocks a defined outcome and the organization can supply decisions, content owners and acceptance time.

For a deeper search review, pair this scope with the SEO audit deliverables guide. If the project includes application features rather than a marketing site, use the MVP development scope guide to define functional and operational acceptance.

Frequently asked questions