What this prompt does
This prompt turns the model into a senior full-stack engineer and asks it to produce a complete headless WordPress + Next.js setup that returns real config and code rather than pseudocode. It anchors every deliverable to four placeholders: [wordpress_url] (the backend the frontend points at), [api_layer] (how content is exposed, e.g. WPGraphQL with ACF), [nextjs_version] (which router and version to scaffold against), and [content_types] (the ACF field groups and routes to model).
The structure works because it forces the awkward integration seams to be specified up front instead of discovered at launch. By naming [api_layer] and [nextjs_version] together, the output stays internally consistent — App Router data fetching differs from Pages Router, and a GraphQL layer needs different query code than REST. The explicit deliverable for ISR with on-demand revalidation (a WP save webhook hitting a revalidate route) targets the exact piece that usually fails silently: editors publish and nothing changes on the React frontend.
When to use it
- You want clients to keep editing in familiar WordPress but need a fast React/Next.js frontend.
- You are scaffolding a new headless project and want the ACF-to-frontend data flow defined before you write a line.
- You keep hitting the "content updated but the live site never changes" problem and need the webhook-to-revalidate loop done right.
- You need typed data fetching mapped to specific
[content_types]rather than loose, untyped queries. - You are deciding between WPGraphQL and the REST API and want one consistent path picked for
[api_layer]. - You need preview mode for drafts and a sane fallback for not-yet-built dynamic routes.
Example output
Expect several labelled code blocks rather than prose: the WordPress side (ACF field group definitions and how they are exposed through [api_layer]), an example dynamic page using generateStaticParams, a typed fetch layer pointed at [wordpress_url], the on-demand revalidate route, and an ordered list of webhook setup steps. Image handling via next/image with WP media domains and SEO metadata mapped from WP fields round it out.
Pro tips
- Set
[content_types]precisely (e.g.posts, case studies, team members) — vague values produce generic ACF groups you will rewrite anyway. - Keep
[api_layer]and[nextjs_version]matched to what you will actually ship; mixing routers or APIs in the answer creates code you have to reconcile. - Test the revalidate route end to end before launch — save a post in WP and confirm the change appears. A broken loop here makes the whole CMS feel dead.
- Point
[wordpress_url]at a staging backend first so a misconfigured webhook does not hammer production. - If preview mode misbehaves, ask the model to isolate just the draft-preview and fallback handling and explain the secret/token flow.
