Check whether a website change is actually live
The coding assistant says "site updated". The preview looks right. That tells you something useful about the preview, and nothing yet about what visitors see.
What you'll make
a short completion record for a small website change that says how far it really got, with the evidence for each stage and the next step named.
What you'll need
the agreed change, whatever evidence exists (a local preview, a GitHub link, a deployment log), the public web address, and Codex, Claude Code or a colleague’s report to check. It’s a read-only check: publishing belongs to whoever owns the site’s release process. About 15 minutes.
Example result.
Local preview: opening 09:30, closing 17:00. Checked.
GitHub change: none supplied.
Deployment: none supplied.
Public page: not checked.
Status: local change ready for release review. Next: site owner releases it.1. Agree where “finished” is
A website change can stop at four points, and each one proves only itself:
- Local preview: the change works on someone’s computer. Evidence: a file path or a preview screenshot.
- GitHub change: the change is recorded in the project’s history. Evidence: a commit or pull-request link, such as
github.com/acme/site/commit/4f2a9c1. - Deployment: a release process published that version. Evidence: a log line such as “Deploy succeeded · commit 4f2a9c1 · production”.
- Public check: someone looked at the live page. Evidence: the public address and the time it was checked.
Agree which of these the job should reach. A prototype can be finished at the first. A live update isn’t finished until the fourth. Merging a change doesn’t always deploy it: some sites publish automatically, others need a manual release.
Why this works: “done” means different things to the person who built it and the person who reads the website.
What you should see: the target stage written down, with the public address and the change people should see.
2. Ask for the evidence at each stage
Audit the completion state of [website task], read-only. Public address: [URL]. Expected visible change: [description].
Separate: saved local files, check results, GitHub branch and commit or pull request, deployment run, and a check of the public page. For each, give the link or path, the version where relevant, what was observed and any gaps. Do not invent a run, treat a preview as live, show credentials, edit, push or deploy. State the furthest stage the evidence supports and the next action and owner.[website task] is the change in a few words. [URL] is the public page. [description] is what visitors should now see.
Why this works: asking for the evidence stage by stage stops a success at one stage being reported as success at all of them.
What you should see: four stages, each marked with evidence or “none supplied”.
3. Look at the live page yourself
Open the public address in a private or incognito window, so you aren’t looking at a copy your browser saved earlier. Check the changed text, images and anything people click. Then type a wrong address on the same site, such as /no-such-page, and make sure it shows a “page not found” message rather than the homepage.
If the deployment log names a version, compare it with the GitHub link. A deployment can succeed with an older version, or publish to a test site instead of the real one.
Why this works: “Deploy succeeded” means the job reported success. Only the public page shows what visitors get.
What you should see: the change visible on the live page, or a clear note that it isn’t.
Check the result
- Each stage in the record has its own evidence, or says “none supplied”.
- A deployment is matched to the same version as the GitHub change.
- The public check names the address and the time you looked.
- The status line names the furthest stage reached, not the one you hoped for.
The usual failure: a local preview reported as a live site. The assistant’s message says “site updated”, the preview is right, and nobody has checked GitHub, the deployment or the public page. Spot it by asking for the link at each stage.
The evidence establishes only [stage reached], not [stage claimed]. Correct the status report. Keep the verified results, mark missing GitHub, deployment or public evidence explicitly, and name the next step in this site's release process. Don't perform that step.[stage reached] and [stage claimed] are two of the four stages, such as “local preview” and “live”.
Worked example: an opening time that was still local
Fictional example. The task: change a shop’s opening time on its website from 09:00 to 09:30, keeping the 17:00 closing time.
The assistant replied: “Site updated. Opening hours now show 09:30–17:00.” It supplied a preview screenshot and nothing else.
- The failure. “Site updated” described a local preview. No commit, deployment or public check existed.
- The repair. The correction prompt with “local preview” and “live” produced the record in the example result. The useful work isn’t lost. It’s just located accurately.
- The next case. Two days later, the deployment log says “Deploy succeeded”, but the public page still shows 09:00. The record becomes “Deployment: succeeded · Public page: shows 09:00 at 14:10”. The one question for the release owner: “Which version and which site did that deployment publish?” Don’t upload again until that’s answered.
Try it
Follow the evidence all the way to the public page
Select the furthest evidence actually supplied. Completed steps do not imply the next one.
Opening 09:30; closing 17:00 shown correctly.
Only the local preview is supplied. GitHub, deployment and public verification are not established.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Optional training: keep a version-linked release record
Task and expected change:
Public address:
Version reviewed:
Checks run:
GitHub commit or pull request, and merge state:
Deployment run, environment and version:
Public check: address, time and what you saw:
Gaps and next owner:Record what each check covered. “Opening and closing times match” says more than “everything checked” when those were the only things looked at.
Optional training: extra checks for technical owners
For a page that matters to search or sharing, the technical owner may also check its canonical URL (the address search engines treat as the main one) and its metadata (the title and description that appear in search results and link previews). If the change touches a form, sign-in or anything that sends data, test that it still works through your normal test process. A homepage that loads doesn’t prove every feature does.
Optional training: know when local is the right finish
For a practice tool, such as a calculator a few colleagues will open from a shared folder, a checked local version can be the complete job. Putting it on a public site adds hosting, security, accessibility and maintenance decisions. Agree those first. GitHub’s deployment and release documentation explain the controls, and the Codex beginner’s guide has the full practice route.