How do I verify that the approved article is actually published?

Open the intended public URL without editor access and compare the article with the exact version that passed review. WordPress's posts schema defines a post's ID separately from its status, which can be publish, future, draft, pending or private.

A publishing response is useful evidence. So is a preview. The remaining check is whether a reader receives the approved words at the intended address.

Which approved version and destination am I checking?

Start with the saved version named in the approval and the URL where it should appear. “The latest draft” is too loose if someone edited it after review.

Keep a short verification note beside that source:

• Version: the approved file, revision or content fingerprint.
• Destination: the intended public URL and the CMS post or deployment it belongs to.
• Audience and time: who should be able to read it, and when it should become available.
• Comparison: the preview URL, time of the public check and any differences found.

Pick a substantive passage to inspect closely, especially one changed in the approved revision. The title alone may be identical in both versions. For a larger article, also review the other changed passages, links and media; one matching sentence cannot establish that the whole article agrees.

If the text is already wrong in the draft preview, return to the conversion check before investigating public delivery.

What does the CMS response prove?

Read the identifier, state and destination separately. The ID locates a record; its status tells you what state the CMS reports. Inspect the schedule and visibility settings when they apply, then check the supplied public link against your intended destination.

For this article, we ran a small synthetic website locally. Its mock CMS returned post ID 42, status publish and link /weekly-report/. Those fields all looked consistent with publication, and its preview contained the approved article.

The public page still contained an old instruction. The runnable example and recorded responses keep that synthetic record and the actual HTTP reads together.

How do I check what a public reader actually receives?

Open the exact destination with the intended audience's access, confirm where the browser lands, and compare the body with the approved source. For a public article, use a session without editor credentials. For restricted content, use an account with the reader's actual permissions.

Our example article explains how to export a weekly report. Its comparison was small enough to inspect directly:

• Approved revision weekly-report-v2: “Select Last seven days before exporting.”
• Preview: the same approved instruction.
• Public response: “Select All dates before exporting.”

The public request returned HTTP 200. The title, help link and inline image also matched the approved source. The wrong date-range instruction was the difference that mattered to someone following the guide.

You can open the saved source and preview comparison and the initial public response. The test made its HTTP reads without cookies or authorization against a server on the same machine. It demonstrates the content comparison; a real site's audience access needs checking at that site's public address.

On your page, follow the important links and confirm that the right images load, too. Read the changed text in context: a matching sentence under the wrong heading or beside an obsolete screenshot can still mislead the reader. Record the actual discrepancy rather than reducing the result to “page opened.”

What if the preview is right but the public article is stale?

Locate where the versions diverge before choosing a correction. Check that you opened the right URL, that the intended revision was published, and that its schedule and visibility match the request. If those agree, inspect the site or hosting layer serving the old body.

In our test, we deliberately initialized a small local cache with the old article. Clearing that cache and reading the same public URL again returned HTTP 200 with “Select Last seven days before exporting.” The corrected response matched the approved HTML and preview; the title, link and inline image stayed unchanged.

That correction cleared only the example's cache. On a real site, use the relevant CMS or host's supported correction, then repeat the public comparison. MDN's cache documentation distinguishes browser caches from shared caches between the browser and server. Opening a private window does not establish that an intermediate cache was cleared.

Record the second observation alongside the first. The correction is verified when the expected content appears at the intended destination for the audience you checked.

What should I do when the result is still uncertain?

Keep the publication check open and name the missing evidence. Inspect the existing post, deployment or request before attempting another write; a lost response does not tell you whether the first attempt succeeded.

A useful handoff says which version was approved, which destination was checked, what appeared there and what still needs resolving. Attach the relevant response or passage and give the next check an owner. The agent handoff guide works through that decision after an interrupted update.

If the public body still says “All dates,” report that exact mismatch. Another “publish succeeded” message would leave the reader with the same wrong instruction.