Website Redesign Checklist: Protect Enquiries from the First Brief to Launch

Before the brief: record what must survive#

A redesign can look finished while the business quietly loses enquiries. The new page loads, the button animates, and the team assumes the handoff works. A useful website redesign checklist follows the customer far enough to know whether the request reached the right place.

Before work starts, save an inventory of current URLs, important search entry pages, service content, downloadable assets and conversion routes. Record the platforms behind forms, scheduling, email and the CRM. Include who can access each system and who will check it at launch, without copying passwords into the project document.

Agree what the redesign is meant to improve. If the scope is uncertain, use the refresh, redesign and rebuild comparison first. A clear boundary reduces last-minute changes that make testing incomplete.

• List the customer tasks the new site must support.
• Capture baseline enquiries and important page performance.
• Name owners for content, technical release and operational handoff.
• Keep a restorable backup and document how restoration works.

During design: review complete tasks, not isolated screens#

Check the message, proof and next step together. A visitor should understand what is offered, whether it fits their need and what will happen after they act. Review long titles, real content and meaningful error messages instead of approving only perfect placeholder states.

Test navigation and forms with a keyboard, a small screen and increased text size. Check focus visibility, label clarity, reading order and whether overlays can be closed. The person who opens a form must be able to reach its last field and submit button without fighting nested scrolling.

Make content ownership explicit. Someone should verify claims, contact details, privacy wording and the evidence used in case studies. Do not carry inaccurate statements into a better-looking template.

Before release: verify the migration and indexing controls#

Preserve existing URLs where practical. For changed addresses, map each important old URL to its closest relevant replacement and test the full redirect path. Sending every removed page to the homepage does not preserve the user’s intent.

Check that production pages return the intended response, have the correct canonical address and are not carrying staging restrictions. Inspect robots directives in both HTML and response headers. Use the Sitemap Audit and Compare tool to confirm the sitemap lists public canonical pages and that internal links point directly to the final destination.

Google’s migration guidance says, “Change only one thing at a time.” If a domain change, platform migration and redesign must happen together, record the added difficulty of isolating a failure and make the release plan correspondingly careful.

Test the enquiry beyond the success message#

Use a clearly labelled test submission and an inbox you are authorized to use. Confirm the record is stored once, includes the correct form source and reaches the business owner. Check the visitor acknowledgement separately; a saved enquiry does not establish that an email was delivered.

Test required fields, invalid values, repeated clicks, a slow connection and a server failure. The form should preserve useful input and explain the actual outcome. Use the form recovery checklist to inspect ambiguous cases, such as a request saved before the browser loses its connection.

If scheduling is involved, check the booking handoff, timezone display, cancellation path and notifications. A release checklist should distinguish tests actually completed from checks deferred for owner review. Never turn a skipped test into a green tick.

At launch: use release gates and a recovery plan#

Name the person who can release and the person who can stop or reverse the release. Define blocking failures in advance: broken forms, inaccessible essential navigation, wrong indexing controls or a failed critical integration. Test the live hostname, not only the preview, because configuration and credentials can differ.

After launch, review response errors, form acceptance, email failures, redirect behavior and important search landing pages. Check measurement with the relevant consent choice. Missing analytics events should not be confused with missing customer activity until the collection path is verified.

If organic traffic drops, use the traffic-drop diagnostic before rewriting content. Keep a timestamped release log so the investigation can compare the first change in performance with the actual deployment.