Partially. Yoast can still manage SEO titles, descriptions, and structured data as fields in the WordPress admin, but it no longer outputs anything into a page directly — the frontend has to read those fields via the API and render its own <title>, meta tags, and JSON-LD.

Only if the frontend shares the exact same origin as WordPress, which is rare in a real headless setup. Across origins, cookie-and-nonce auth runs into CORS and SameSite restrictions that will block legitimate requests unpredictably — a token-based scheme avoids the problem entirely.

Yes, but not with WordPress’s default cookie+nonce auth, which assumes same-origin. A cross-origin frontend needs a token-based scheme (Application Passwords or a JWT/OAuth layer) — covered in full on the Auth page.

A minimal one, yes — WordPress still needs a theme to activate, and some admin-only screens still render through it. But the theme’s templates are irrelevant to what visitors see; all the real rendering logic lives in the frontend application.

It doesn’t break the plugin’s admin fields, but it does mean those fields no longer automatically appear in the rendered page — the frontend has to explicitly fetch and render the title, meta description, canonical URL, and structured data itself.

Yes. A preview token should resolve to the exact draft state the editor just saved — which post revision or autosave that corresponds to needs to be explicit in the token or the endpoint logic, not assumed.

Yes — WPGraphQL for Advanced Custom Fields exposes ACF field groups directly in the schema, following the same register_graphql_field pattern used for any other custom data.

Fetch related data (authors, terms, meta) in a single batched query keyed by the IDs already in the result set, rather than querying per item inside a loop — the same eager-loading principle _embed uses internally on wp/v2.

The built-in _fields query parameter (?_fields=id,title) works on wp/v2 endpoints and narrows the response to exactly those fields — useful for internal tooling, but a dedicated custom endpoint is still the safer choice for a public frontend contract.

By design, a JWT itself can’t be invalidated early without extra infrastructure — most setups maintain a short server-side blocklist of revoked token IDs, checked on each request, or simply keep token lifetimes short enough that revocation matters less.

Disable introspection for unauthenticated requests, enforce query depth/complexity limits, and move to persisted queries so the server only ever executes a known, pre-approved set of queries rather than arbitrary client-submitted ones.

Explicitly exclude the preview route from any caching layer, or mark its responses as non-cacheable at the HTTP level — a preview response should never be eligible to become a cached page for anyone else.

With a single catch-all route that looks up content by slug against the API, rather than one hardcoded route per post type — this keeps new content types and archives from requiring a frontend code change every time.

No. If the site is mostly standard pages and posts with no unusual frontend requirements, a well-built traditional or block theme is simpler, cheaper, and just as fast. Headless earns its complexity when the frontend has requirements WordPress themes genuinely can’t meet — a native mobile app sharing the same content, a highly interactive SPA, or multiple frontends consuming one content source.

Not by itself — anyone with the URL could then guess or enumerate other IDs. A signed, short-lived token tied to that specific post is the standard approach, so the link can’t be reused or extended arbitrarily.

Yes, as of recent WordPress versions omitting it triggers a deprecation notice. Set it explicitly — __return_true for genuinely public data, or a real capability/token check for anything else — rather than leaving it implicit.

Use GraphQL when pages routinely need several related content types assembled together and REST would otherwise mean multiple round trips or heavy over-fetching via _embed. Use REST when most pages need one resource type with light relations — it’s simpler to build, cache, and debug.

Start from the frontend’s actual data needs. If most pages need one resource type with light relations, REST with a custom namespace is simpler to build, cache, and debug. If pages routinely need several related content types assembled together, GraphQL (via WPGraphQL) avoids the over-fetching and multiple round trips REST would otherwise require.

Build a custom namespace for anything a public frontend depends on directly. Extending wp/v2 with register_rest_field is fine for small internal additions, but a frontend-facing contract deserves its own versioned space that WordPress core updates can’t reshape underneath you.

Next.js (or a similar framework with server rendering and ISR) when SEO and initial load performance matter — most content sites. A plain client-rendered SPA is reasonable when the frontend is behind a login, an internal tool, or genuinely doesn’t need to be indexed by search engines.

No. Preview must call a distinct, authenticated endpoint capable of returning draft or pending content — never the public content endpoint gated by a flag, since that risks accidentally exposing draft content publicly.

Trusted, non-browser integrations — a build pipeline, a server-side script, an internal tool — where the credential is stored securely server-side and never exposed to a browser or end user.

Usually authentication and preview links, in that order — both depend on same-origin cookies and PHP-rendered URLs that a decoupled frontend simply doesn’t have. The default REST API alone doesn’t solve either problem; both need explicit design, covered on the Auth and Preview pages.

A resolver that fetches its own data independently for every node in a list, instead of batching those lookups by ID across the whole list in one query. WPGraphQL’s built-in loaders handle this correctly for core types; custom resolvers need to follow the same batching pattern deliberately.

Incremental static regeneration for most editorial content — static speed with the ability to update a single page on demand. Reserve full server-side rendering for pages with genuinely per-request data, since it gives up the performance benefit ISR provides.

Before the content model and API contract are finalized, not after. Once a live frontend depends on a specific field shape or permission structure, changing it becomes a coordinated release across two codebases instead of a single edit.

Before launch, specifically the token scope, CORS configuration, and revocation strategy — these are far cheaper to get right in design review than to discover through an incident once real user accounts depend on them.

Before the rendering strategy and routing pattern are locked in — both are costly to change once a site is live and indexed, so getting them matched to the actual content shape at the start avoids a much more expensive migration later.

Before it reaches editors in production — token expiry, cache exclusion, and revision handling are all cheaper to verify in a design review than to fix after an editorial team has already lost confidence in the workflow.

Before the frontend starts consuming it in production, ideally at the point the endpoint contract is first drafted — changing field names or shapes afterward means coordinating a release across the WordPress plugin and every frontend consumer at once.

Before the schema ships to production with introspection and arbitrary queries enabled — complexity limits, persisted queries, and naming conventions are all far cheaper to set correctly at launch than to retrofit after a frontend already depends on the open configuration.

An httpOnly, Secure, SameSite-appropriate cookie, not localStorage or sessionStorage. Client-side JavaScript should never be able to read the token directly.

Usually a CORS or SameSite cookie restriction blocking the request before it reaches WordPress at all — the browser, not WordPress, refuses to send or accept the credentials, which often shows no clear error in application logs.

It generates a link back to WordPress itself, rendered by a PHP theme template — but in a headless architecture, that template isn’t what visitors see, so the preview shows nothing meaningful. The link has to be rebuilt to point at the frontend instead.

REST responses are cacheable by URL because the URL itself encodes the request. A GraphQL request is typically a POST with a query body, so there’s no URL to key a cache on — production setups use persisted-query hashes or a GraphQL-aware CDN to get equivalent caching.

A TTL is a guess about how often content changes and is wrong in both directions — either serving stale content for too long, or rebuilding pages that haven’t actually changed. A webhook fired on the actual publish event revalidates exactly the page that changed, exactly when it changed.