A website redesign checklist should reduce uncertainty before layouts are created. It gives the designer, developer and business owner one shared picture of what must change, what must stay and how launch quality will be judged.

The short answer: inventory the current site, define the business goal, assign every important URL a destination, prepare real content, document integrations and agree on launch checks before design begins.

1. Define the business reason for the redesign

Write down the specific problem the redesign should solve. Examples include unclear positioning, difficult editing, weak enquiry paths, inaccessible interfaces, slow templates or a product story that no longer matches the offer.

  • Name the primary audience and the decision the site should help them make.
  • Choose the qualified action that matters most after launch.
  • Separate business goals from visual preferences.
  • Record what evidence will show whether the problem improved.

2. Inventory the current website

Create a list of public URLs, page purpose, indexability, traffic or lead importance, backlinks where known, content owner and proposed action. A redesign should not discover valuable pages only after they disappear.

  • Keep pages that still serve a distinct visitor and search job.
  • Improve pages with useful demand but weak structure or content.
  • Merge overlapping pages into one stronger destination.
  • Remove pages only when a useful replacement or intentional retirement is defined.

3. Create the URL and redirect plan

When a path changes, map the old URL to the closest relevant new destination. Google recommends permanent server-side redirects for moved URLs and updating internal links, canonicals and sitemaps to use the final addresses.

Avoid sending every removed page to the homepage. A redirect should preserve the visitor intent. Test for one-hop responses and remove links that point through redirect chains.

4. Prepare content before final layout decisions

Real headings, proof, product detail and calls to action reveal requirements that placeholder copy hides. Content does not need to be polished before wireframes, but the team should know what each page must communicate and which evidence is available.

  • Assign one primary purpose and one H1 topic to every indexable page.
  • Identify claims that need proof, attribution or removal.
  • Collect final logos, screenshots, photography and permissions.
  • Define repeated content types that belong in a CMS.

5. Document functionality and integrations

List forms, booking tools, analytics, consent controls, CRM connections, search, localization, gated files, embeds and any data source the new site depends on. For each item, record the owner, required fields, success state, failure state and test method.

6. Set the design and component boundary

Agree which page types need custom composition and which repeated patterns should become components. A useful system covers real content variation without turning every page into the same layout.

7. Define performance and accessibility checks

Test representative templates with production assets, fonts, scripts and embeds. Core Web Vitals are field-oriented metrics for loading, interactivity and visual stability, while accessibility review also needs keyboard, focus, labels, headings, alternative text and readable contrast checks.

8. Agree on approvals and launch ownership

  • Name who approves strategy, copy, design, development and launch.
  • Set review windows and define what counts as a revision.
  • Record access needed for domains, hosting, analytics and integrations.
  • Keep a rollback path and a post-launch monitoring owner.

Website redesign launch handoff

The final handoff should include the approved page map, redirect file, content source, component rules, CMS model, integration settings, analytics checks and a list of known limitations. This makes launch a controlled change rather than a visual switch.

Frequently asked questions

When should content be written during a redesign?

Content strategy and real examples should shape early structure. Final copy can continue during design, but waiting until development to define page purpose, proof and content length creates avoidable layout and scope changes.

Does every old URL need a redirect?

Every moved URL with a useful replacement should be mapped. A removed page with no equivalent may require a deliberate 404 or 410 response instead of an irrelevant redirect. The decision should follow the page purpose and available replacement.

How long should a website redesign take?

There is no responsible universal duration. Timing depends on content readiness, page systems, CMS complexity, integrations, migration controls, decision speed and the number of review rounds.