The short answer
Check the public page and the customer action after a release. Open the exact address, confirm the approved information is there and try the affected route to the next step. A successful upload is useful evidence, but it is not the same as a working website.
A green deploy can still deliver the wrong page
You approve a new service description and a downloadable guide. The developer says the update is live. Later, a customer sends you a screenshot of the old description, and the download button opens an error page.
The work may have been built correctly and uploaded successfully. Something between the source and the customer's browser still went wrong. The final check has to happen where customers actually use the result.
Approve a result you can identify
Be specific about what is changing: the page address, the important wording, the download or form action and any language versions involved. If several revisions are being discussed, make it clear which one has approval.
A screenshot is helpful for reviewing layout, but it does not show whether a button works or whether the direct URL loads. Keep the accepted version connected to the release so that the team can distinguish a delivery problem from a later content change.
A worked example
Suppose a company replaces a preparation checklist and changes the wording of the button that downloads it.
Where it goes wrong
Only the new build is inspected. The public page still links to an old filename, so the customer sees the right button but receives the wrong document.
What to do instead
Open the public page, use the button and compare the actual downloaded file with the approved version. Record the release and the result of that check.
The acceptance now covers the customer outcome, not just the upload. This is a hypothetical release check, not a report of a particular customer incident.
Walk the path a customer would take
Open the page directly rather than only navigating to it from the homepage. Check the title, the main information and the affected images or downloads. If a form changed, verify the agreed submission and confirmation behaviour using a controlled test, without mixing test enquiries into real sales follow-up.
Try the relevant phone layout and language route. A change to a shared template may affect more than the one screenshot that was approved. The testing should match that scope while remaining proportionate to the work.
Keep a simple recovery path
The release record should make it possible to say what went live and how to restore the previous working version if necessary. That does not mean every punctuation correction needs an elaborate ceremony. It means a meaningful change should be traceable and recoverable.
When a check fails, the job is still open. Correct the public result or use the agreed rollback, then check again. Search engines processing a change later is a separate matter from whether the right page is being served now.
Take this into your next conversation
Questions to ask your agency
- Which public addresses and actions are changing?
- Which revision has been approved?
- What proves the customer receives the right result?
- How would we restore the previous working version?
Common questions
Is a green deployment message enough?
It shows that part of the delivery process completed. Public content, assets and user actions still need checks appropriate to the change.
Do we need to retest the whole website for every edit?
Match the review to the impact. A shared template or enquiry change needs broader checks than an isolated sentence correction.
From explanation to implementation
This guide is published by NAVIFLARE, a website, CRM and AI workflow practice. Source notes identify the platform guidance; worked examples explain a method rather than claim a client result.
Explore website design and developmentYour next step
Tell us what changed and what the customer currently receives. We can discuss a focused check of the affected public pages and the action that is supposed to work.
Discuss a website delivery issue
