A website redesign checklist that starts with what works

Record the current site before changing it

Write down why the redesign is needed. Separate a business change, such as a new service, from a usability problem, such as a form that people cannot complete. Identify what you can observe today: relevant search queries, landing pages, saved inquiries and repeated customer questions. Record the date range and any gaps in measurement.

Create an inventory of public URLs, including downloads and older pages linked from emails. For each, note its purpose, existing content, known incoming links and planned treatment. Keep, improve, combine and retire are useful decisions. A low-traffic page can still matter if it answers an essential question, so avoid making the choice from a traffic count alone.

Choose between a focused repair and a rebuild

If the offer is clear and the current platform is maintainable, improving navigation, copy or forms may address the problem. A rebuild becomes more reasonable when the information structure, editing workflow or technical limitations prevent the required journey. Make the decision from specific constraints rather than the age of the design.

List the changes that depend on each other. Moving a domain, changing a content system and rewriting every page at the same time makes problems harder to isolate. Google’s site-move guidance recommends separating major changes where practical. A staged release requires temporary coordination, but it can make the outcome easier to diagnose and reverse.

Prepare the content and URL checklist

Give every important existing URL an explicit destination or retirement decision. When a page moves, map it to the closest useful replacement. Do not send unrelated old pages to the homepage merely to avoid an error. Google’s migration guidance describes URL mapping, permanent redirects for moved content and appropriate error responses for content that has no replacement.

• Confirm the page’s audience, main question and next action before rewriting its heading.
• Retain accurate information people need, and remove unsupported claims or expired offers.
• Assign a unique page title, useful description and preferred URL to each public page.
• Update internal links, image references and downloads to their intended final destinations.
• Review old-to-new URL mappings and test redirects without unnecessary intermediate hops.
• Check the production sitemap and indexing settings; remove preview restrictions only from pages intended for search.

A hypothetical redesign decision

Imagine a small equipment-maintenance business with a homepage, a repairs page and a downloadable preparation sheet. Its new design combines repairs and routine servicing under one page. Before approving that structure, the team checks whether each service has different eligibility questions, preparation needs and inquiry routes.

If those needs differ, keeping two focused pages may be clearer. If they overlap, a combined page can work, with the old repairs URL redirected to the relevant replacement. The preparation download keeps a stable address or gets its own redirect. The design review now includes someone arriving through an old email link, not only through the new homepage. This is a hypothetical planning scenario.

Test the tasks that keep the business running

Choose realistic journeys: find a service, understand whether it fits, download a useful document and submit an inquiry. Test them on a narrow screen and using a keyboard. Check that sticky navigation does not obscure content, focus is visible and motion preferences are respected. Form controls need understandable labels associated with their inputs, as described in W3C’s forms guidance.

Submit a clearly labelled test inquiry to an address you control. Verify the stored record and any expected receipt or owner notification. Refreshing or retrying should not create unintended duplicate actions. Also test missing required information and a failed connection. A polished success screen proves little if the inquiry is never saved or cannot be found by the team.

Make launch a reversible, observable step

Name the release owner and preserve a working rollback. Back up content and stored inquiries before making structural changes. After launch, open important URLs directly, inspect redirects and repeat the inquiry test. Confirm that analytics records the agreed actions and respects the visitor’s choices. Do not put inquiry text or email addresses into analytics events.

Review the first week for broken links, crawl or indexing issues, form failures and unexpected visitor paths. Compare equivalent actions and comparable date ranges; a change in tracking can look like a change in performance. Search visibility can fluctuate after URL changes, so avoid treating one early day as a verdict. Keep a short list of observed problems, responsible people and the next fixes.