The editor is where a WordPress post is assembled. It is not the last place the post will be seen. A saved preview can look right while the anonymous page still serves older cached HTML, a link leads to the wrong language, or the public metadata describes an image that does not exist. The useful question is not “Does Preview look good?” but “What evidence shows that the released URL works for a visitor?”
This is a repeatable publishing QA workflow for a small WordPress site. It separates checks you can finish while the post is a draft from checks that require a public or staging URL. It also gives each failure a safe next action. The checklist is based on DocsHook’s own release checks and public-page audit; it is not a claim that every WordPress installation will fail in the same way.
Why WordPress preview cannot prove the final visitor page
WordPress provides editor canvas widths and a separate front-end preview in a new tab. Both are valuable for checking a draft before release. Neither is a substitute for opening the final URL without an editor session after publication. WordPress.com’s visitor-preview guidance explicitly recommends an unauthenticated browser for the visitor view. The exact preview interface and cache behavior depend on your WordPress version, theme, plugins and host.
Real users report this gap: one WordPress.org thread describes content present in the editor and preview but missing from the published page; another describes a logged-out page that differs from the editor. Those are reports from other sites, not diagnoses of DocsHook. Cache is one possible branch, not the automatic answer to every mismatch. LiteSpeed’s troubleshooting guide explains how to compare cached and uncached responses when that branch is plausible.
Compare the draft, front-end preview and final anonymous URL
Keep three views separate in your notes: the saved draft or editor preview, a front-end preview or staging page, and the final anonymous URL. Record the exact URL, time, login state, viewport, and whether a cache layer reported a hit or miss. A draft returning 404 to anonymous visitors can be correct; it is not evidence that the eventual published URL works. Conversely, a public page returning 200 proves reachability, not that it shows the right language, content or metadata.
Before publishing a WordPress article: ten safe checks
- Freeze the intended URL and language. Record the proposed slug and language. Check whether another post already uses the slug. Do not create a translation relationship to a page that does not yet exist.
- Match each important claim to evidence. Label your own test, product documentation, community report and unverified hypothesis separately. Record environment versions and last actual test date.
- Read the page as a reader. Confirm the opening answers a concrete question, each H2 advances the diagnosis, and the conclusion does not promise an outcome the evidence cannot support.
- Scan the rendered text. Look for unrendered Markdown, placeholder copy, raw block comments, duplicate paragraphs, broken code indentation and an accidental test label.
- Inspect media and tables. Use only images you may publish, check their actual file size and useful alt text, and test wide tables or code at a phone width. No image is better than a fabricated screenshot.
- Check links and actions. Open the first and last internal links, each call to action and high-value external source. Ensure the link points to the intended language and final destination; a 200 response alone is insufficient if it redirects elsewhere.
- Set editorial context. Confirm author display name, category, excerpt, disclosure when relevant, and whether comments are intentionally open or closed. Check that a draft is not accidentally listed publicly.
- Prepare search and social metadata. Write a specific SEO title and description; decide whether a share image exists. Check intended canonical, robots and language annotations, but reserve final HTML verification for after publication.
- Preview at more than one width. Use the editor canvas and front-end preview at desktop and phone widths. Check heading hierarchy, navigation, text line length, buttons, tables and code. This is a draft check, not a substitute for anonymous QA.
- Save a rollback point. Keep the prior content or revision and know how to restore it. For theme, plugin or template changes, use a staging environment and a restorable backup before touching the production design.
After publishing: eight checks on the final anonymous URL
- Request the exact canonical URL anonymously. Record the HTTP status and final URL after redirects. A successful response at an unexpected destination is a failure of the intended path.
- Compare the visible article. Check title, opening, headings, code, images, last paragraph and important links against the approved draft. Repeat after a normal refresh.
- Compare cache states when applicable. Inspect response headers and a second anonymous request. If a cached copy differs, investigate that layer before editing the article again. Do not disable production cache blindly.
- Inspect the public HTML head. Verify one intended canonical, index/noindex as planned, title, meta description, Open Graph and Twitter card. A sharing card set to “large image” without an image is a metadata mismatch even when the article itself is correct.
- Check structured data and dates. Parse JSON-LD rather than trusting a plugin save message. Check Article or BlogPosting type, displayed author, language, and actual publish/modified timestamps. Do not write a “last tested” date unless you really retested.
- Use a narrow anonymous viewport. Confirm no whole-page horizontal overflow, open the mobile menu, follow a relevant link, and check that code and tables scroll locally. A simulator does not establish physical touch or screen-reader behavior.
- Verify discovery paths. Check that the article appears in its category, Guides or other intended entry point, and the appropriate XML sitemap. Sitemap presence is not proof of a Google crawl or index decision.
- Review the language pair and surrounding copy. For an existing translation, verify reciprocal hreflang and each page’s own-language canonical. If there is no translation, do not invent a language alternate. Update homepage or Guides text that still says the article is “coming soon.”
For a release with several editors, record the checks with a reviewer, timestamp, observed result, URL and evidence link. A simple shared note is enough. The checklist is deliberately divided because an anonymous post-publication check cannot be truthfully marked complete while the article remains a private draft.
DocsHook found a no-image social card and stale discovery copy
During DocsHook’s 1 November 2026 review of our Gutenberg mobile-table article, the first anonymous HTML check showed twitter:card=summary_large_image with no og:image or twitter:image. We changed that post’s Rank Math card setting to summary, saved it and checked the public cache miss and hit responses. The new public HTML showed summary. That is an observed metadata correction on this site, not evidence that all large-image cards without images break in every sharing app.
The same release exposed copy that was still framed around “our first guide” on the English Home and Guides pages. We changed those sentences to describe the published library and verified the anonymous pages. The article itself had been approved; the surrounding discovery copy needed a separate check. Our visitor-versus-logged-in cache guide covers a different, experimentally tested cache branch. It does not mean caching caused either of these editorial findings.
A guessed Chinese URL caused a false language-audit failure
In a read-only DocsHook audit on 1 November 2026, our first script guessed that the Chinese Guides and About pages lived at /zh/guides/ and /zh/about/. Both requests reached English pages. A naive check reported an English lang on “Chinese URLs.” We inspected the final URLs and the existing hreflang links, then reran the audit against the actual /zh/指南/ and /zh/关于/ paths. Their responses declared zh-CN. The initial “language bug” was our test-path error, not a Polylang defect.
The corrected sample covered nine public DocsHook URLs: English and Chinese Home, Guides and About, the English and Chinese cache guides, and the English mobile-table guide. All nine returned 200, had one H1, one canonical link, a description and parseable JSON-LD. The 31 distinct internal link targets found in that sample returned successful responses after redirects. This is a bounded check of those URLs at that time, not a full crawl, visual accessibility audit or search-index report.
How to stop, revise or roll back a failed publication check
Stop if the live URL exposes private content, returns the wrong site, points its canonical to an unintended page, or gives visitors a broken critical action. Restore the prior version or remove the new public entry point while investigating. Revise for a factual error, unusable mobile table, missing source, stale surrounding copy or inconsistent social metadata; fix the smallest layer and repeat the anonymous check. Proceed when the required observations are recorded and remaining limitations are disclosed. Search Console indexing can take longer; do not use “not indexed yet” as a same-day release failure by itself.
Evidence sources and limits of this publishing QA guide
DocsHook first-hand work: 1 November 2026 release checks and the bounded nine-URL public audit described above. Product guidance: WordPress preview modes, WordPress.com visitor view, and LiteSpeed troubleshooting. Search guidance: Google canonical signals and Google sitemaps. Community reports: the two WordPress.org cases linked earlier. No search-volume, ranking, crawl or indexing outcome is inferred from this workflow.