What to Include in a Website Redesign Scope

Start with the reason for the redesign

Before deciding what changes, define why the redesign is needed. Common reasons include outdated visuals, poor mobile usability, weak enquiries, old technology, confusing navigation, difficult editing, slow performance, or services that have changed since the site was built.

Audit what should stay

Not everything needs to be replaced. Some pages may still rank, some content may be useful, and some brand assets may still work. A redesign should protect what is already performing while improving the weak parts.

Plan redirects before launch

If URLs change, redirects matter. Without them, users and search engines can land on missing pages. A simple URL map should list old URLs, new URLs, and pages that should be removed.

Use keep, improve and replace decisions

Review important pages by purpose rather than by appearance alone. For each page, ask whether it answers a current customer question, supports a useful enquiry or receives relevant search visits. Check the actual query, enquiry and link evidence where it is available.

1. Keep: Information and URLs that still serve the reader. Design changes may be enough.
2. Improve: A useful page whose copy, proof, navigation or mobile experience needs work.
3. Combine: Closely overlapping pages that can become one stronger destination after a deliberate URL review.
4. Replace or remove: Material that is no longer applicable, with a decision about any useful replacement and inbound links.

Record the reason for each decision. A low page-view count alone does not show that a specialist service page is unnecessary, and a large traffic total does not show that the visitors are relevant buyers.

A simple redesign scope example

Illustrative scope: A consultancy needs clearer service pages and easier editing. The work includes a revised navigation, one approved visual direction, refreshed home and service layouts, migration of agreed content, enquiry forms and responsive review. Its existing resource URLs remain in place.

The client supplies approved service text and project evidence. The team records content editing, new photography and a future member portal separately so none is assumed to be included. The scope names who approves the work, supplies hosting access and verifies enquiry delivery.

An acceptance checklist then describes the expected result: agreed pages present, approved content used, key journeys usable on the chosen browsers and devices, working enquiries and an editing handover. These are sample responsibilities to agree, not a standard package promise.

Create a URL continuity note before the build

List each existing URL, its intended destination and the reason for the decision. A retained page keeps its address where practical. A moved page needs a relevant replacement and a tested redirect. A genuinely removed page may have no equivalent; do not send every missing URL to the home page just to hide an error.

For example, an old general services page might remain as an overview while a specific service gains its own destination. That is different from renaming every page or removing the old address. Agree the actual mapping against the existing site before implementation.

Google’s URL migration guidance explains the technical principles. Include the plan in the launch checks rather than relying on a design preview to prove continuity.

Connect scope to the content and project plan

A clear website brief identifies the reason for change. A content inventory shows the work needed on each page. Use the planning roadmap to place those decisions before design and development, and review website portfolio examples when discussing a suitable direction.