What does a website
redesign include?

1. Start with the reason for changing the website

“The site feels old” may be true, but it is not yet a project objective. Ask what the current website prevents the business or its customers from doing.

The answer might be practical: visitors cannot understand the offer, important services are difficult to find, the team cannot update content, the mobile journey is awkward, or the site no longer represents the business. Each problem points to a different scope.

Choose one primary outcome and a small number of supporting outcomes. A redesign cannot reliably solve every marketing, sales, and operational problem at once.

2. Decide whether you need a refresh, restructure, or rebuild

Not every project needs to replace the whole site. The existing content, platform, visual system, and technical condition determine how deep the work should go.

The labels matter less than the boundary. State which existing parts remain, which will change, and which will be replaced. This prevents a visual update from quietly becoming a platform migration halfway through the project.

3. Audit the current site before removing anything

Begin with an inventory of the existing pages, templates, forms, downloads, integrations, and tracking. Mark what is accurate, outdated, duplicated, missing, or still valuable.

Use available evidence carefully. Search queries can show how people discover a page. Analytics can show which pages receive visits and where journeys stop. Inquiry emails and sales conversations can reveal the questions the website fails to answer. None of these signals explains the whole problem alone.

Check technical dependencies as well: domain and DNS access, hosting, forms, email delivery, analytics, consent tools, product data, payment or booking systems, and any content management platform. A feature that looks small on the page may depend on an external service or internal workflow.

Create a keep, improve, remove, and add list. This becomes the first practical outline of the new scope.

4. Define the complete redesign scope

A proposal should name the deliverables a buyer will receive. Depending on the project, a website redesign can include:

1. Direction: business context, audience, offer, goals, and the role of the website.
2. Information architecture: page list, navigation, content hierarchy, and important user journeys.
3. Content: responsibility for writing, editing, imagery, product data, migration, and approvals.
4. Design: responsive layouts, visual system, interface states, and reusable components.
5. Development: templates, forms, content editing, store or platform setup, and agreed integrations.
6. Quality checks: mobile layouts, keyboard use, accessibility basics, browser behavior, performance, and important forms.
7. Search continuity: page titles, descriptions, indexing rules, URL changes, redirects, and sitemap updates.
8. Launch and handover: production release, access, documentation, team guidance, and any agreed support.

The exact combination depends on the website. A focused service site and an online store have different operational requirements. Northform's service overview explains how website, store, and interface projects are scoped.

Also list exclusions. Copywriting, photography, complex backend features, third-party subscriptions, ongoing support, and data migration should not be assumed if they are not included.

5. Prepare content and decisions before they block the build

Content is part of the interface. Headlines affect page hierarchy, product details affect templates, and missing photography changes the visual direction. Placeholder material can help explore an early layout, but it cannot define the final page accurately.

Agree who supplies, writes, edits, and approves each content type. For an existing site, decide whether content will be copied as it is, revised, consolidated, or removed. For a store, include product fields, variants, prices, stock rules, delivery information, and legal pages in the content plan.

Set a review process as well. Name the decision-maker, group feedback into agreed review stages, and evaluate each page against the project objective. Unstructured feedback from many people can expand the work without improving the customer journey.

6. Plan migration, launch, and handover

A redesign is not finished when the final layout is approved. The new site still has to replace the current one without losing necessary content, working links, inquiry routes, or operational access.

Before launch, confirm the production domain, forms and destination inboxes, analytics, important redirects, metadata, indexing settings, integrations, and the pages that must remain available. Test the main journey on a phone and with a keyboard. Keep a rollback route for changes that could interrupt the live site.

Handover should match how the website will be maintained. If the team will edit content, provide the agreed editing system, access, and guidance. If updates require development, make that clear before launch. Define any post-launch support separately so ownership is understood.

A useful website redesign brief

You do not need a complete technical specification to start a conversation. A concise brief can give a designer and developer enough context to ask the right questions.

1. What does the business offer, and who is the website for?
2. What is not working on the current site?
3. What should a visitor understand or do?
4. Which pages, content, and features must remain?
5. What new pages, editing needs, or integrations are expected?
6. Who provides content and who approves decisions?
7. Are there launch constraints, existing systems, or access dependencies?

Add the current website link and any useful examples, then discuss the unknowns. The proposal can turn that conversation into a defined set of pages, features, deliverables, cost, and timing.