Website Redesign Services: What Should Be Included Before You Sign a Proposal?

Key Takeaways

• A useful website redesign proposal defines the business problem, pages, content, functionality, technical work, testing, launch and support rather than promising a vague new website.
• Confirm who writes, supplies, migrates and approves every piece of content. Content delays are one of the easiest ways for a redesign to drift.
• SEO protection needs a current-site inventory, URL decisions, redirects, metadata, internal links and post-launch monitoring in the written scope.
• Ask for named accessibility, performance and browser tests with clear acceptance criteria rather than general assurances.
• Make ownership, licences, hosting access, warranties, change control and ongoing costs clear before paying a deposit.

A sound website redesign proposal tells you what problem will be solved, what will be delivered, who is responsible and how everyone will decide that the work is complete. If it only lists a homepage, mobile design and SEO-friendly build, there is too much room for different interpretations.

The most expensive gaps often sit between disciplines. A designer expects the client to provide finished copy. The client expects the agency to rewrite it. A developer assumes the old URLs can change. The marketing team expects all tracking to survive. None of these assumptions are unreasonable, but they must be made explicit before work starts.

Begin with the Reason for the Redesign

Name the current problems in plain language. Examples might include weak mobile enquiries, slow product pages, confusing services, an editor that is difficult to use, an inaccessible booking journey or a design that no longer matches the business.

Turn those problems into outcomes that can be checked. Instead of improve conversions, agree to simplify a particular enquiry route and ensure its events are recorded. Instead of improve SEO, agree to preserve valuable pages, correct a known crawl problem and implement an approved structure.

Useful baseline evidence can include:

• current organic landing pages and search queries;
• enquiry and sales journeys;
• mobile and desktop analytics;
• Core Web Vitals and representative lab tests;
• accessibility findings;
• support tickets and editor frustrations;
• important backlinks and indexed URLs;
• customer questions and sales objections.

Our guide to the signs and process of a website redesign can help decide whether the business needs a refresh, redesign or full rebuild. The scope then follows that decision rather than defaulting to the largest project.

Define the Pages and Information Architecture

A page count alone is not enough. Ten standard pages can be simpler than one product finder with several states. Request a sitemap or page inventory that distinguishes unique templates, repeated content entries and functional journeys.

Spell out:

• pages that stay, merge, move or disappear;
• navigation and footer structure;
• service, location, product and article templates;
• filtering, search and pagination;
• account, booking, checkout or portal journeys;
• legal, policy and accessibility pages;
• error, confirmation and empty states;
• multilingual or regional variants;
• files, documents and media libraries.

Ask who approves the information architecture and how later changes affect cost and timing. A wireframe phase is useful because it tests hierarchy and content before polished visual work makes change expensive.

A professional website redesign service also explains which parts of the existing structure are worth preserving. A redesign is not a reason to erase everything that already works.

Make Content Responsibilities Unambiguous

Content can include copy, images, video, downloads, case studies, biographies, product data, testimonials, policies and metadata. The proposal makes clear who audits, writes, edits, supplies, licenses, uploads and approves each type.

Clarify:

1. Whether copywriting is included and how many review rounds are allowed.
2. Whether old content will be migrated automatically, manually reviewed or rewritten.
3. Who checks factual accuracy, prices, qualifications and legal statements.
4. Who sources photography and what usage rights are included.
5. Whether image optimisation, alt text and captions are included.
6. Who enters final content in the CMS.
7. What happens if content arrives late.

Do not accept lorem ipsum through most of the design process if the real copy is complex. Headings, tables, FAQs and long service explanations affect layouts. Test designs with representative content early.

If the team needs help shaping the structure as well as the words, custom website design connects content, user journeys and visual decisions instead of treating copy as a final fill-in task.

Put SEO Migration Work in Writing

Every redesign can affect search, even when the domain stays the same. Templates, internal links, headings, rendering and content may all change. If URLs change, the project also becomes a migration.

Cover these areas in the SEO scope:

• a crawl and export of the current site;
• a record of indexed and organic landing pages;
• title, description, heading and canonical rules;
• content consolidation decisions;
• a one-to-one URL redirect map;
• structured data review;
• XML sitemap and robots rules;
• internal-link updates;
• Search Console and analytics continuity;
• pre-launch crawl checks;
• monitoring after launch.

Google's current site move guidance recommends preparing and testing the new site, mapping URLs, implementing redirects and monitoring both old and new URLs. It also says temporary ranking movement can happen during a significant move. No credible proposal can promise zero movement or guaranteed positions.

Use our detailed website migration SEO checklist as an acceptance list. If the supplier excludes SEO migration, appoint someone to own it before design decisions become fixed. A separate SEO service can review the inventory and launch plan.

Specify UX and Visual Design Deliverables

Ask what you will actually review. A design service may include moodboards, style directions, wireframes, component designs, responsive layouts, prototypes and a design system, but these are not interchangeable.

Record the following:

• which pages receive bespoke layouts;
• which device widths or responsive behaviours are demonstrated;
• how many visual directions and revision rounds are included;
• who supplies brand assets and whether brand work is part of the project;
• whether states such as errors, menus, filters and form validation are designed;
• how feedback is collected and approved;
• whether final design files are handed over.

Focus review on real tasks. Can a mobile visitor understand the service, compare the options and make an enquiry? Can an editor add a case study without inventing a layout? A beautiful homepage does not prove that these journeys work.

Our article about website traffic that produces no enquiries offers useful questions for redesigning conversion paths without relying on cosmetic changes.

Name the Development and CMS Scope

The technical section describes the platform, hosting assumptions, integrations and editable content. Ask which features are standard, third-party or custom. Request a list of paid licences and their renewal owners.

Confirm the scope for:

• CMS fields, reusable blocks and permissions;
• forms, spam protection and notifications;
• CRM, booking, payment and email integrations;
• site search, filters and accounts;
• redirects and error handling;
• caching, backups and environments;
• security updates and monitoring;
• analytics, consent and advertising scripts;
• browser and device support;
• code repository and deployment access.

Avoid phrases such as all necessary plugins without a named list. You need to know what the live site relies on and what happens when a licence or integration changes.

Agree an Accessibility Standard and Test Method

Do not reduce accessibility to an automated score or a widget. The proposal names the target, usually a relevant WCAG 2.2 level, and the pages and journeys that receive manual testing.

The W3C's summary of what changed in WCAG 2.2 includes focus visibility, target size, dragging alternatives, consistent help and accessible authentication. These issues need interaction testing, not only colour checks.

Ask who will test keyboard navigation, screen-reader labels, zoom and reflow, form errors, touch targets, motion and colour contrast. Confirm how findings are recorded and which severity must be resolved before launch.

Accessibility also depends on content editors. Training covers headings, link wording, tables, captions and alt text. An accessibility and WCAG review is valuable when you need independent evidence rather than a supplier checking only its own work.

Define Performance Acceptance Criteria

Make “fast” testable. Agree representative pages, mobile test conditions, the tools used and which third-party scripts are included. Separate lab tests used during development from real-user data that becomes available after launch.

The performance scope covers image sizing, fonts, JavaScript, caching, video, consent tools and external widgets. If marketing requests add several scripts after the build has passed testing, record that as a new baseline rather than blaming the original code.

Do not make a single perfect score the contractual goal. Ask for investigation and correction of material problems against an agreed budget. Include post-launch measurement because production hosting, real content and live integrations can behave differently from staging.

Protect Analytics, Forms and Consent

A redesign can look successful while silently losing enquiry data. List every important event and destination before launch: form submissions, telephone clicks, email clicks, bookings, purchases, downloads and qualified lead actions.

The proposal names who:

• documents current tags and events;
• implements the new measurement plan;
• configures consent behaviour;
• tests form delivery and CRM records;
• excludes internal or staging traffic where required;
• verifies advertising conversions;
• obtains access to existing analytics accounts;
• monitors the first live days.

UK cookie and privacy obligations depend on the technologies and purposes involved. Use current ICO guidance on cookies and similar technologies and obtain appropriate legal advice for the organisation rather than copying a generic banner.

Clarify Ownership, Payment and Change Control

Before signing, understand what you own and what you are licensed to use. The contract covers design files, code, content, stock media, fonts, domains, hosting, plugins and third-party accounts.

Also confirm:

• deposit and milestone payments;
• what evidence triggers each milestone;
• the number and meaning of revision rounds;
• the day rate or method for out-of-scope work;
• how changes affect dates;
• what happens if either party pauses the project;
• warranty terms for defects;
• cancellation and handover arrangements;
• whether VAT and ongoing fees are included or excluded.

Make sure important accounts are held by the business or provide suitable shared access. A website must not become unreachable because one freelancer owns the domain or analytics property.

Require a Launch and Support Plan

Launch is a controlled change, not the moment someone presses Publish. The launch plan includes a final content freeze, backup or rollback plan, DNS responsibility, redirect activation, live tests and a named decision-maker.

Agree a post-launch period for genuine defects and distinguish it from new features. Ask how urgent faults are reported, what response times apply and what maintenance is available after the warranty ends.

A useful launch checklist covers priority pages, forms, payments, navigation, search, error responses, analytics, consent, redirects, sitemap, robots rules, performance and accessibility. Record who signs each area off.

Frequently Asked Questions

What should a website redesign proposal include?

It should define objectives, pages, content, design, development, CMS, integrations, SEO migration, accessibility, performance, analytics, testing, launch, ownership, timescales, costs, revisions and post-launch support.

Should copywriting and content migration be included?

They can be included or excluded, but responsibility must be explicit. Confirm who audits, writes, approves, licenses, uploads and checks every content type, plus what happens if material is late.

How should SEO be protected during a redesign?

Inventory current URLs and performance, preserve valuable content and internal links, map changed URLs to relevant destinations, test canonicals and redirects, maintain tracking, submit an accurate sitemap and monitor after launch.

Does a redesign proposal need accessibility testing?

Yes. Name the intended standard, representative pages and manual tests. Automated tools help find some issues, but they cannot fully assess keyboard journeys, screen-reader meaning, form errors or content clarity.

Who should own the website after the project?

The contract should clearly assign ownership or licences for code, design, content and media. The business should have appropriate access to its domain, hosting, CMS, analytics, repository and third-party accounts.

Before You Sign

A good proposal reduces ambiguity without pretending every detail is known on day one. It connects the redesign to a real business problem, names the evidence and sets a fair way to handle change.

Before paying a deposit, highlight every assumption and ask how completion will be proved. If you would like a second opinion on a scope, contact MattDarm with the proposal and current website.