How to Preview WordPress Drafts in Astro Before Publishing

Astro’s default model assumes content is known at build time. A page is generated from a stable URL, using a query that returns only publicly visible records, and that HTML is then frozen until the next build. That works perfectly for posts whose WordPress status is publish.

Preview content lives somewhere else. A draft, scheduled entry, or in-progress edit is often stored as a draft plus revision or autosave, not as the public version attached to the site’s normal content path. In WordPress, the preview a logged-in editor sees is usually the latest revision, while the public slug may still point to an older published post—or to nothing at all.

That creates two different retrieval patterns:

• Published pages: fetch by slug through ordinary REST or GraphQL queries during the Astro build.
• Preview pages: fetch by post ID or preview token at request time, usually with authentication.
• Scheduled and draft content: may be excluded from public queries entirely.

So the problem is not rendering. It is addressing and access: previews are private, mutable, and revision-based, while static routes are public, fixed, and build-based.

Three patterns usually appear, but only one fits most editorial teams cleanly.

• Full-site SSR: simplest mental model, because every request can ask WordPress for draft-aware data. The cost is permanent runtime hosting, more caching complexity, and weaker static guarantees. That trade-off matters, especially when comparing Astro’s static and SSR behavior for frequently updated sites.
• Separate preview builds or staging deploys: useful for reviewing branches, layout changes, or near-final content. It is much less reliable for individual draft revisions, autosaves, and last-minute editorial checks.
• A dedicated SSR preview route: the usual sweet spot. Public pages stay fully static, while /preview/... runs server-side, validates a WordPress preview token, and fetches the correct draft or revision at request time.

This route isolates risk instead of turning the whole site dynamic. It also keeps preview logic where it belongs: authenticated, uncached, and explicit.

In practice, that means static for visitors, SSR for editors—a narrow dynamic surface that solves previews without rewriting the delivery model.

Reliable preview begins before Astro fetches anything. WordPress must turn its Preview action into a custom URL that points at Astro’s preview route, not the default frontend. In practice, that URL should carry only the context Astro needs: content type, a stable record key, and—when revision fidelity matters—a revision or autosave reference. This is the part many guides skip, even in a broader Astro and WordPress integration walkthrough.

The most important rule is simple: never key preview by slug. Slugs change during editing, may not exist on drafts, and can point to the wrong version after a rename. Use an immutable identifier instead, such as database ID or another permanent internal key exposed by the API.

A dependable contract usually includes:

• a custom preview URL like /preview?type=post&id=123
• a stable identifier that survives title and slug edits
• an auth mechanism that can read drafts, autosaves, or revisions

Authentication deserves special care. Browser cookies and wp-admin nonces often break across domains, so server-to-server access is usually safer: Application Passwords, JWT, or a signed token exchange handled only on the Astro server. If WordPress cannot package trustworthy preview context, Astro cannot produce trustworthy previews.

Rendering a draft is not enough; the preview route is a private delivery channel. If a CDN, browser, or reverse proxy treats it like ordinary content, stale responses can survive edits, or one editor’s draft can leak into another request. That is why the route used to preview a draft before deployment should opt out of caching at every layer.

• Send Cache-Control: private, no-store, max-age=0 and disable platform edge caching.
• Add Vary: Cookie or the exact auth header used for preview access.
• Return X-Robots-Tag: noindex, nofollow, noarchive so crawlers do not retain the URL.

WordPress credentials must stay on the server. The browser should receive only a signed, short-lived preview token or an HttpOnly session cookie, while Astro performs the authenticated WordPress fetch server-side. Avoid exposing application passwords, bearer tokens, or draft identifiers in client JavaScript, public env vars, or shareable query strings that end up in logs and analytics.