A WordPress Gutenberg draft preview isn’t the same thing as a successful REST request. The REST response tells you what WordPress stored. The browser tells you what a reader, or an editor, will actually see. Those are different checks, and treating them as one is how broken headings, missing media, raw Markdown, and mobile overflow reach the last gate. Treat every WordPress Gutenberg draft preview as its own evidence packet, with one frozen body and one rendered target.
WordPress Gutenberg draft preview starts with the exact final body
The WordPress block editor treats paragraphs, headings, lists, images, and other content elements as blocks. That structure needs to survive the handoff from the local draft to the WordPress post. A readable Markdown file isn’t proof that the final HTML is correct.
Start by freezing the final artifact. Convert the draft into Gutenberg HTML, normalize its line endings, and calculate a SHA-256 hash. Store the path and hash in the receipt before any WordPress write. The artifact evaluated by the local shadow checks must be the exact artifact sent to WordPress.
A minimal local handoff looks like this:
source pack -> draft -> Gutenberg HTML -> static QA -> body hash -> WordPress draftThe order matters. If you write the draft first and convert it later, you can end up verifying one body and staging another. That’s not a small bookkeeping error. It breaks the chain of evidence.
Use REST to verify draft status, not to pretend the page is rendered
The WordPress REST posts endpoint exposes draft as a distinct status and supports creating and updating posts through the posts endpoint. That makes REST useful for a controlled write and an authenticated readback.
The safe sequence is:
- find an existing post by the deterministic slug;
- if it exists, stop unless its status is
draft; - create or update with
status=draft; - read the post back with edit context;
- compare the stored body against the gated Gutenberg artifact;
- record the post ID, status, and body hash.
There’s deliberately no “publish if everything looks good” step in this lane. A draft receipt proves storage, not approval. The policy boundary stays outside the writer so a worker can’t turn a staging helper into a publisher by passing a flag.
The same rule applies to metadata. Yoast title, meta description, focus keyword, and schema values should be written through the declared draft path and then read back. If the target doesn’t expose the expected meta schema, the result is BLOCKED, not “probably fine.”
Browser preview checks the rendered page
The Chrome DevTools Protocol exposes navigation, screenshots, and page inspection domains. A WordPress Gutenberg draft preview uses those capabilities for a non-mutating browser check after the REST readback.
The browser gate should inspect an authenticated preview or editor surface in two viewport sizes. Desktop catches layout and content-order problems. A narrow viewport catches horizontal overflow, clipped media, and headings that become unreadable on a phone.
At minimum, inspect:
- the expected title;
- the first visible heading;
- semantic H2 and H3 structure;
- featured or planned media and its alt text;
- links in the article body;
- overflow and broken embeds;
- editor/admin authentication state;
- the final URL and preview identity.
If the authenticated tab is missing, the browser gate is BLOCKED. Don’t open a fresh tab and assume that its login state will match the keepalive session. WordPress security layers can send fresh tabs to reauthentication even while an existing admin tab is valid.
The WordPress Gutenberg draft preview should be treated as a two-part check: storage and rendering. That’s why the receipt needs both the REST readback and the browser evidence. The browser check is read-only. It should restore the previous tab URL, close any gate-owned tab, and leave the draft untouched. A screenshot is evidence of what was rendered at one moment, not permission to publish.
Keep Markdown out of the WordPress body
Raw Markdown is an easy failure to miss because it looks readable in a local file. The final body should contain Gutenberg block comments and semantic HTML, not lines such as ## Heading or [anchor text](https://example.com).
Static checks should reject:
- frontmatter in the final body;
- raw Markdown headings and links;
- unfinished placeholders or insertion notes;
- model instructions or chatty process language;
- unbalanced Gutenberg block markers;
- missing real H2 elements;
- missing meaningful internal body links;
- media without alt and provenance metadata.
The check should run before the REST write and again against the authenticated readback. A clean local artifact followed by a mismatching WordPress body is a hash failure, not a successful draft.
Separate vendor claims from hands-on evidence
WordPress documentation can support claims about the block editor and REST status. Chrome DevTools documentation can support claims about the browser instrumentation surface. Neither source proves that a particular TRT preview rendered correctly on this machine.
Keep the evidence classes visible in the draft package:
- vendor claims come from official WordPress or Chrome documentation;
- secondary evidence explains a workflow or known limitation;
- personal testing records the exact local command or observation;
- hands-on-required claims stay blocked until a receipt exists.
That distinction matters for a preview guide because the dangerous sentence is often the most casual one: “the preview works.” A real receipt needs the target identity, the final body hash, the viewport, the timestamp, and the observed result. If any of those are missing, call it what it’s: unverified.
A preview failure needs a narrow rollback
If the post readback isn’t draft, stop. Don’t “repair” the status by making another write. If the body hash differs, preserve both hashes and create a repair item. If browser authentication is lost, leave the draft alone and re-establish the browser session through the approved operator path.
A rollback in this lane means disabling the wrapper, preserving the receipt, and leaving the target draft in its current safe state. It doesn’t mean deleting a post to make the dashboard look clean. Deletion would destroy evidence and create a second risk.
For the broader operating model, the Hermes async subagents guide shows why receipts and worker boundaries matter. The Codex use-case hub is the companion for the larger build-and-review workflow.
A WordPress Gutenberg draft preview is a verification stage, not a green light. Freeze the body, stage only draft, read it back, render it in an authenticated browser, inspect desktop and narrow views, and hand the exact evidence to an independent reviewer. That’s slower than clicking Publish. It’s also how you avoid publishing a page that only looked correct in the source file.
Sources and evidence boundary
WordPress documentation supports the block and draft-status claims. Chrome DevTools documentation supports the instrumentation claims. The local hands-on receipt covers only the target and commands recorded for this calibration run. It doesn’t turn a missing browser session or an unverified target into a PASS.
