A website redesign proposal can look complete while leaving the expensive decisions unresolved. Who writes the service pages? Which old URLs stay? Does the quote include your booking integration, or only a button linking to it? Who fixes problems after launch?
Before hiring an agency, agree on the business problem, the exact deliverables and the evidence you will use to accept the finished site. This website redesign checklist helps you compare proposals on the same basis and spot gaps before they become change requests.
1. Decide whether you need a redesign or a focused repair
Start with an observable problem. Perhaps customers cannot understand your services, mobile navigation is difficult, the team cannot update pages safely, or an important integration no longer fits the business.
Ask the agency to show which parts of the current website contribute to that problem. A full rebuild may be appropriate when the structure and platform both limit what you need. A focused update may be enough when the main obstacle is one service page, a form or a confusing navigation menu.
Write a short brief before requesting quotes:
- Audience: Who should use the site, and what do they need to decide?
- Priority journey: What should a visitor be able to complete, such as assessing a service and requesting a relevant quote?
- Current obstacle: What evidence shows where that journey breaks down?
- Constraints: Which systems, content, launch dates and internal resources must the project work around?
- Success measures: What will you review after launch, and what is the current baseline?
Separate launch acceptance from later business outcomes. You can check whether an enquiry reaches the right inbox before launch. You need subsequent customer activity to assess enquiry quality. Our guide to measuring search leads explains how to connect website activity with sales records.
2. Turn the proposal into a deliverables list
“Ten-page website” does not tell you how much work is included. Ten unique layouts, ten pages using two reusable templates and ten migrated pages with unchanged copy are different projects.
Ask each agency to identify:
- Pages and templates: The page inventory, unique layouts and reusable components.
- Content: Who researches, writes, edits, approves and uploads each page.
- Media: Which images, illustrations or videos are included, and their licensing terms.
- Functionality: The actual behaviour of forms, search, booking, payments and other integrations.
- Migration: Which existing articles, files, products and URLs will be carried over.
- Review rounds: What each round covers, who approves it and how additional changes are priced.
- Exclusions: Work the business or another provider must supply.
Describe integrations as user journeys. For a booking flow, specify whether customers stay on the site, move to another service, receive confirmation and appear in the business’s booking records. A named integration alone leaves those details open.
Request separate figures for initial delivery, optional work and recurring costs. Hosting, premium extensions, third-party services and maintenance can have different renewal dates and owners. Compare the total scope you need rather than the lowest headline price.
3. Agree how existing URLs and search visibility will be handled
A redesign does not automatically require new URLs. Ask which addresses need to change and why. Preserve useful pages and stable URLs when they still serve the site’s structure and customers.
When URLs change, the scope should name the person responsible for inventorying the old site, mapping each relevant old URL to its new destination and testing that map. Include valuable downloadable files and images where their addresses matter.
Google’s site-move guidance recommends server-side permanent redirects, such as 301 or 308, and direct redirects to the final destination where possible. Sending unrelated old pages to the homepage can be treated as a soft 404. A genuinely consolidated page can be an appropriate destination when it contains the relevant replacement content.
Ask for these handover items:
- An approved old-to-new URL map, with removed pages handled deliberately.
- Redirect test results, including checks for loops, chains and incorrect destinations.
- Updated internal links, canonical references and sitemaps.
- A launch check that development-only indexing blocks have been removed from public pages.
- A named owner for monitoring errors and maintaining redirects.
Google advises keeping redirects as long as possible, generally at least one year. Search visibility can still fluctuate during a move. An agency should explain its risk controls and monitoring plan without guaranteeing that rankings or traffic will remain unchanged.
4. Make acceptance tests specific
“Responsive, fast and accessible” is a starting point for a discussion. Your project plan should explain how those qualities will be checked, on which page types and by whom.
Mobile and functional checks
Choose representative pages and the journeys that matter most. Check navigation, readable text, images, forms and third-party tools on the agreed devices and browsers. Include unsuccessful actions: required fields left empty, invalid input, unavailable bookings and a customer returning to an earlier step.
A form test should confirm that the business receives the intended submission and that the visitor sees useful success or error feedback. Record the expected result so both sides can identify a defect consistently.
Performance checks
Agree on test pages, conditions and measures before design sign-off. Test with realistic content and the intended integrations. A lightweight mockup can behave differently once video, analytics and external widgets are added.
Lab tests help diagnose issues during development. Real-user field measurements describe visitors’ actual experiences. PageSpeed Insights documentation explains that its field data covers the previous 28 days and may be unavailable for pages without sufficient data. A single Lighthouse score does not establish real-user performance.
Define a launch testing method and a separate post-launch performance review. Do not make an unavailable field report the only way to accept a new website.
Accessibility checks
Name the accessibility standard and conformance level the project is targeting, such as WCAG 2.2 AA, along with the pages, components and testing methods in scope. Agree who fixes issues found in agency work and third-party components.
Practical checks include keyboard operation, visible focus, meaningful headings, appropriate image alternatives, labelled form controls and helpful error messages. W3C’s forms guidance covers labels, instructions and feedback. These examples are not a complete accessibility audit.
W3C recommends including accessibility in project planning and acceptance testing. Its evaluation guidance also explains that automated tools alone cannot determine conformance; human evaluation is needed.
5. Clarify control, licenses and handover
Ask what the business will receive and control at the end of the project. Do not assume that paying for a website automatically includes every source file, software license or service account.
- Who controls the domain, hosting, content management system and connected services?
- Which design files, code repositories, content exports and documentation are included?
- What rights does the business receive in custom work, and which assets remain subject to third-party licenses?
- Can the internal team update the agreed content without developer help?
- What training and backup or restore instructions will be delivered?
- What happens to access, licenses and support if the business changes providers?
Have the proposal state these terms clearly. Keep ongoing support distinct from fixing defects in the agreed deliverables. Ask for the duration, coverage, response process and exclusions for each.
6. Put launch and the first review in the plan
Choose one person on each side who can approve launch. Record dependencies, who checks the production site and what would trigger a pause or rollback. A rollback plan should identify the previous version, the person able to restore it and any new data that must be protected.
The launch checklist should cover the critical journeys, redirects, public indexing settings, analytics and enquiry delivery. Agree on a post-launch review date and the evidence needed for that review. With low lead volumes, review individual enquiries before drawing conclusions from percentage changes.
Before selecting an agency, ask every shortlisted provider the same question: “Walk us through what you will deliver, what you need from us, and how we will know each part is complete.” Unanswered details are useful places to clarify scope before signing.
Frequently asked questions
Should we redesign the whole website or improve a few pages?
Start with the problem and its evidence. Targeted improvements can suit isolated content or usability issues. A broader redesign may make sense when the structure, platform or editing workflow prevents several necessary improvements. Ask the agency to explain the trade-off in scope, cost and disruption.
How can we compare website redesign quotes fairly?
Give each agency the same brief and ask for a deliverables list. Compare templates, content work, integrations, migration, testing, handover and support. Show optional items and recurring costs separately so a missing service does not look like a saving.
Will a redesign affect our Google rankings?
It can, particularly when URLs, content or site structure change. Preserve valuable content, map changed URLs, test redirects and check indexing settings. These steps help manage risk; they do not guarantee unchanged rankings. Agree on monitoring and responsibility for resolving launch issues.
Does a high PageSpeed score mean the website is finished?
No. A lab score is one diagnostic signal. You still need to test real customer journeys, accessibility, content, integrations and delivery of enquiries. Review real-user performance after launch when sufficient field data is available.
Who should write the new website content?
Either the business or the agency can handle the writing, but the proposal should name the writer, reviewer and approver. The business needs to supply accurate service details and evidence for claims. Agree on content deadlines because design and migration depend on them.
What should we receive when the project is handed over?
Request the access, files, licenses, documentation and training listed in your agreement, plus the URL map, test results and support contacts. The precise handover depends on the platform and contract. Check it before the project starts.
Plan your redesign with a clear brief
Explore The City of Code’s website design and development services, or contact our team with your current website, the problem you want to solve and the journeys that matter most. A clear starting brief makes it easier to discuss the right scope.
