Publish a specific approved revision
Assign the article an identity independent of its title and URL. Keep a revision identifier with the approval, destination and asset references. If the content changes after approval, make the changed revision visible to the reviewer. This prevents an apparently successful transfer from publishing a draft that nobody approved. A portfolio should also retain the publication identity so content cannot drift into a sibling site.
Define what the HTTP response actually confirms
Read the endpoint’s response contract. HTTP 202 indicates acceptance without completed processing; a job identifier or status URL can provide a route to the later result. Do not label an article published merely because the submission request returned a success-class code. The destination may still reject, queue or fail the operation.
MDN: HTTP 202 Accepted ↗ — Accepted means processing is not complete. The endpoint must define how its eventual result can be checked.
Inspect the rendered destination
After the operation completes, check the resulting page against the approved record. Useful checks include the intended title, revision, canonical, image availability and key links. A reachable URL alone does not prove that the expected revision rendered. Define which discrepancy blocks completion, retain enough detail to diagnose it and avoid creating another article while investigating an existing one.
Make rollback and ownership explicit
Record whether recovery updates the existing article, restores an earlier approved revision or requires a manual step. The correct action depends on the publishing service; do not assume deletion is the safest undo. Retain the source content, asset rights and mapping records in a form the individual publication can export. Shared infrastructure should not make ownership of one article dependent on another site’s account.
Keep these details together.
- Stable content identifiers
- Asset and link checks
- Rendered-page verification
Go a little deeper.
Workflow Library ↗What a publishing workflow needs to prove
A useful publishing record answers three questions: what was approved, what was sent, and what actually appeared.
Read the note ↗A practical reading noteAccepted is a state, not a published page
Follow a request beyond the first HTTP response, then verify the result that matters to the reader.
Read the note ↗