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.

The practical question is:

Is this change safe to publish, and did it break anything that affects inquiries afterward?

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

Start with what changed#

Write down what changed before testing. Keep the checks tied to that change rather than expanding into a tour of every page.

Record:

• which pages or templates changed;
• which shared components changed;
• which forms, booking tools, tracking, or integrations changed;
• the intended customer action;
• the destination that action should reach;
• where the resulting lead should arrive;
• what should be counted.

A headline edit on one page may only need checks on that page. A navigation, template, reusable form, tracking, or shared CTA change should also be checked on representative pages where the same component appears.

Name 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 is more useful than “test the new page.”

Before publishing: establish the baseline#

Capture enough evidence to tell whether the change improved the intended path or introduced a new failure. Keep the baseline brief and useful.

Before publishing, identify who can correct the page or shared component, repair form, booking, email, CRM, integration, or tracking failures, and restore the previous behavior if the change cannot be repaired quickly. Record the responsible name or role with the baseline.

This does not need to become a long release record. A short note, a few screenshots, and one successful test are usually enough for an owner or small team.

The important part is knowing what “working” meant before the change.

Before publishing: test the changed experience in preview#

Use the preview or staging state available to you. Confirm 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.
4. Trigger one expected validation error where a form changed.
5. Complete the form or booking path when the preview environment supports real delivery.
6. Confirm the destination, confirmation state, and expected response.

Preview testing reduces obvious mistakes. It does not replace testing after publication. Live routing, integrations, email delivery, consent behavior, analytics, and caching may differ from the preview.

Immediately after publishing: complete the path#

Test the public experience as a customer would.

1. Open the changed page directly.
2. Reach it through the navigation, ad, email, or other real entry path where relevant.
3. Test it on a real phone.
4. Use every affected button or link.
5. Submit the affected form.
6. Complete the affected booking flow.
7. Confirm the success or thank-you state.
8. Confirm the inquiry reached the expected inbox, CRM, calendar, or other destination.
9. Confirm the expected customer-facing response arrived.
10. Confirm the important action was 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.

The complete test follows the customer action all the way through the business result.

Check collateral damage on shared surfaces#

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

Check the affected shared surfaces:

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

Choose representative pages based on the implementation. If the same service-page template powers ten pages, test the changed page and one or two other pages using that template. If the header changed, test a few different page types. 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 technical testing program.

Test realistic failure points#

A compact test set catches most owner-level failures.

Phone and desktop#

Use a real phone, not only a narrow browser window. Check desktop too, especially when the changed page uses multi-column layouts, embedded tools, or sticky elements.

One valid submission#

Complete the main affected action with valid information. Use a test name that can be identified in the inbox, CRM, calendar, and tracking records.

One expected validation error#

Leave out one required field or use a clearly invalid value. Confirm the message explains the problem and does not erase useful information or trap the customer.

Autofill where relevant#

Forms can behave differently when a phone or browser fills names, email addresses, phone numbers, or addresses automatically. Use autofill when customers are likely to use it.

Keyboard, banner, and sticky-element interference#

On mobile, confirm that the keyboard, cookie or consent banner, chat prompt, popup, or sticky CTA does not cover the fields, buttons, confirmation, or navigation.

Duplicate behavior#

Use the primary action once and confirm one inquiry and one conversion. Check that a double tap, page refresh, return to a thank-you page, or repeated script does not create duplicate submissions or duplicate conversion records.

Confirmation and delivery#

Verify the customer-facing confirmation and the business-facing lead delivery. Test the expected reply or booking notice too.

Recheck after real usage resumes#

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

Compare:

• actual inquiries received;
• inbox, CRM, or calendar delivery;
• tracking records;
• sales or support reports;
• sudden disappearance or duplication of expected activity.

Do not wait an arbitrary fixed number of hours or days. Recheck when enough normal activity has resumed to compare what the business expected with what actually happened.

A low-volume business may need to review the next few real inquiries individually. A higher-volume business may spot a sudden gap or duplication pattern quickly.

Start with the first failed check#

Do not send the whole change back into a vague review loop. Fix the earliest meaningful failure before widening the review.

Use this checklist to verify the changed customer and lead path. Page-clarity problems belong with Landing Pages or Website Builds. Google-facing launch failures belong with the launch SEO checklist or Technical SEO.