all planning guides

project planning / digital experience

How to scope a website redesign before asking for a price

by ninety two · updated October 9, 2026

“We need a new website” describes an intention. It does not yet describe the job. A useful redesign brief explains who the site serves, what those people need to do and what your team will be responsible for after launch. Start there before comparing prices.

Choose the journeys that matter

Write down the few actions the site needs to support: understand a service, evaluate relevant work, request a quote, apply for a job or make a donation. Different audiences may need different routes. Prioritize those routes instead of giving every page equal weight.

For each journey, identify the question a visitor must answer before taking the next step. A service buyer may need scope and process; a candidate may need role information. Bring examples from real sales or support conversations so the architecture follows actual questions.

Inventory content and templates separately

List existing pages and decide which to keep, combine, rewrite or remove. Identify the person who will supply and approve each piece of content. If photography or copywriting is part of the engagement, name it in the scope. A design schedule needs content deadlines alongside review deadlines.

Count reusable page types as well as individual URLs. A service page, case study and article may each need a distinct template, while many pages can share one template. Explain any unusual layouts or interactive features; a page count alone will not capture that work.

Name the connections and migration work

List forms, CRM connections, booking tools, payment flows and other integrations. Confirm who owns each account, whether access is available and which system should hold the final record. Ask the proposal to distinguish a simple embed from custom integration work.

Include the CMS, any existing content that must move and the team members who will edit it. Agree whether migration includes formatting cleanup, image preparation and link checks. Decide what the new team should be able to change without a developer.

Treat launch as a deliverable

Ask for a launch checklist covering redirects, metadata, indexability, sitemap, forms and analytics. When URLs change, map the important old addresses to their new destinations. Google’s site-move guidance explains the role of URL mapping and redirects; it does not promise that a redesign will improve rankings.

Define testing across relevant screen sizes, keyboard use and key user journeys. Establish what constitutes a launch blocker and who approves the release. An attractive homepage is one part of acceptance; a working inquiry path and usable content matter just as much.

Reference: Google Search Central: site moves with URL changes

Agree who owns the site afterward

Separate the build from hosting, maintenance, content changes and optimization. Ask what a recurring agreement covers, how requests are prioritized and what falls outside the monthly scope. Identify who manages backups, access and renewals.

The final brief should fit into a clear set of decisions: priority journeys, templates, content owners, integrations, migration, acceptance checks and ongoing responsibilities. Send that same brief to each potential partner so the proposals can be compared on the same basis.

put the brief to work.

Share your current URL, content inventory and required integrations. Start with an assessment if the scope still needs defining.

Keep this page with your project brief, or use your browser’s print option for a copy.