Website QA Checklist Before and After a Site Update

A website change is not finished when the new page looks right in the editor. It is finished when the intended customer can reach it, understand the next step, complete the action, and produce the expected result for the business.

This checklist is for a specific website change: a page edit, navigation change, form adjustment, booking-tool change, tracking update, template revision, shared-component change, redesign, or release. It is not a generic audit of the entire website.

For a stable website that has not just changed, use the monthly website maintenance checklist instead.

1. Define what changed and what working means#

Keep the test tied to the change rather than expanding into a tour of every page.

Record:

• which pages, templates, or shared components changed;
• which forms, booking tools, tracking, or integrations changed;
• the intended customer action and destination;
• where the resulting lead should arrive;
• what should be counted; and
• who can repair or roll back the change if it fails.

Then describe the expected result in plain language. For example:

A mobile visitor reaches the emergency service page from the primary navigation, taps Request Help, submits the form, sees the confirmation, the inquiry reaches the service inbox, the customer receives the response email, and the conversion is counted once.

That sentence gives the test a finish line.

Capture only enough of the current state to detect a regression: important URLs, a few screenshots where layout matters, current CTA destinations, one known-good form or booking result, the lead recipient, the customer confirmation, and the expected tracking event.

2. Before publishing, test the changed path#

Use the preview or staging state available to you. Check the changed content, buttons, links, forms, and layout before the public version changes.

Focus on the intended path:

1. Open the affected page directly.
2. Use the changed buttons and links.
3. Check the layout on a real phone and desktop where the change affects both.
4. Trigger one expected validation error when a form changed.
5. Complete the form or booking path when preview supports real delivery.
6. Confirm the destination, confirmation state, and expected response.

Preview testing catches obvious mistakes. It does not replace testing after publication because live routing, integrations, email delivery, consent behavior, analytics, and caching may differ.

3. After publishing, complete the real customer path#

Test the public experience as a customer would.

• Reach the changed page through the real navigation, ad, email, or other entry path when relevant.
• Use the affected buttons and links on a real phone.
• Complete one valid form or booking action.
• Test one expected validation error when the form itself changed.
• Confirm banners, sticky elements, autofill, and the mobile keyboard do not block the action when relevant.
• Confirm the success or thank-you state.
• Confirm the inquiry reaches the expected inbox, CRM, calendar, or other destination.
• Confirm the expected customer-facing acknowledgement arrives.
• Confirm the intended action is counted once.

Keep three distinctions clear:

• Seeing a form is not testing the form.
• Seeing a success screen is not proof that the lead arrived.
• A lead arriving is not proof that tracking counted it correctly.

When a form or tracking change could create duplicates, check that a double tap, refresh, return to a thank-you page, or repeated script does not create another submission or conversion.

4. Check shared surfaces when the change can spread#

A specific change can affect pages that were not intentionally edited. This matters when the change touched a shared component, template, integration, global setting, or release bundle.

Check the relevant shared surfaces, such as:

• header and navigation;
• footer contact details;
• shared CTAs or forms;
• reusable page templates;
• thank-you routing;
• analytics or tag behavior;
• consent banners, popups, or sticky elements; and
• one or two representative pages that were not intentionally changed.

Choose representatives based on the implementation. If the same service-page template powers ten pages, test the changed page and one or two others using that template. If a reusable form changed, test each place where that form performs a materially different job.

The goal is to catch regression risk without turning every change into a full-site audit.

Recheck when real activity resumes#

A controlled test proves that one known path worked once. Real activity can expose intermittent delivery, routing, tracking, or workflow failures the test did not reproduce.

When enough normal activity has resumed, compare actual inquiries with the expected inbox, CRM, calendar, tracking, or sales record. A low-volume business may review the next few inquiries individually. A higher-volume business may notice a sudden gap or duplication pattern sooner.

Do not wait an arbitrary number of hours or days. Recheck when there is enough real activity to compare expected behavior with what actually happened.

Fix what broke before you test more#

Once a check fails, fix it or send it to the right owner before testing the rest.

Use this checklist after a specific site change. For Google-facing launch problems, use the launch SEO checklist or the Google Indexing Review. For a stable site, use the monthly maintenance check.