What to Decide Before a Website Redesign

Decision in brief: Decide what each visitor should understand and do before choosing a visual style. Inventory the existing URLs, content and inquiry workflow so the redesign preserves useful behavior.

Inventory what already works

List current routes, inbound links, search queries, forms, and pages that generate qualified conversations. Preserve a useful URL unless there is a clear replacement and a verified redirect plan.

Specify the customer journey

For each audience, write the first question, the proof needed to proceed, and the next action. A service page that only describes the company leaves the visitor to infer whether the offer fits.

Define operations after launch

Name who updates copy, approves claims, responds to forms, monitors failures, and checks that contact information remains current. A design handoff without those owners becomes stale quickly.

Turn the brief into page decisions

A useful brief pairs each proposed page with a reader question, the evidence that answers it, and the action the business wants to support. For a service page, that may mean scope, fit, process, examples, and a consultation request. For a support page, it may mean a direct answer and a path to a person. Mark which existing URLs can satisfy the new intent and which genuinely need a new page. This prevents a redesign from creating several near-identical pages that compete for the same question. It also gives writers and designers a testable purpose for every section.

A one-page route worksheet makes the brief actionable. Give it columns for current URL, intended reader, question answered, evidence on the page, next action, owner, and proposed treatment: retain, revise, combine, redirect, or retire. Add the current search and inquiry signal beside each high-value route, with its source and date. A writer can then see whether a proposed page has a distinct purpose; an engineer can see which redirects require testing; and the business owner can approve the response workflow. Keep a separate list of unknowns so an attractive draft does not quietly become an unsupported claim.

Define launch evidence before design approval

Ask the team to demonstrate the critical journeys on a phone and a desktop: finding a service, understanding whether it fits, reaching a working form, and receiving a clear confirmation. Record baseline traffic and inquiry quality before the change so later results have context. Check redirects from retired URLs, page titles, canonical addresses, image descriptions, and crawl access on the real hostname. Finally, name the person who can correct a broken fact or failed handoff after launch. A visual approval is one milestone; a reliable customer journey is the release criterion.

Decision checklist

• Record every current URL and its proposed disposition.
• Choose one conversion action per high-intent page.
• Define form routing and response ownership before design sign-off.
• Plan mobile, accessibility, performance, and SEO acceptance together.

A small test before committing

Pick three existing pages: one that brings qualified inquiries, one that confuses visitors, and one that has an inbound link. For each, write the user question, current answer, desired action, and proposed URL. Ask a real buyer to find the answer on a phone without coaching. If the proposed redesign cannot improve that task while preserving the valuable URL or redirecting it cleanly, revisit the page map before visual design begins.

Worked scenario

For a hypothetical regional equipment supplier, the highest-value change might be separating product-selection guidance from a quote request. That decision changes the page map, form fields, and follow-up workflow before it changes colors or imagery.

For a scoped application of this decision, see Managed Websites & Digital Presence.

Source and further reading

Google documents how to plan URL mapping and redirects when a redesign changes addresses. Record the existing paths before approving a replacement page map. Google Search Central: site moves with URL changes.

About this guide: Shawn Iuliucci, software architect at Innov8now. Examples are planning exercises, not reported customer outcomes. The cover is a concept illustration. Read our authorship, sources and corrections policy.