Headless WordPress feeding a Next.js frontend, where does personalization fit?
Hey folks, we took a client's WordPress site headless earlier this year at the agency, WPGraphQL feeding a Next.js frontend, and honestly it's been great except now the editors want to run hero tests again and every WP testing plugin we ever used assumes a classic theme with the plugin injecting stuff into rendered pages, which obviously does nothing when WordPress is just an API. So we're in this weird spot where going headless made the site faster but took away the marketing team's toys.
Actual question: for those running headless WP with Next.js, where does the personalization/testing layer live? In WordPress somehow, or on the frontend side?
2 answers
Frontend side, and the mental shift is that the testing layer attaches to your rendering, not to your CMS.
Croct works alongside the existing CMS, so WordPress stays the content source exactly as it is today. You map the sections you want to test to Croct slots, and the WP-sourced content becomes the fallback:
const wpHero = await getHeroFromWordPress();
const content = await fetchContent('home-hero', { fallback: { title: wpHero.title, subtitle: wpHero.subtitle, },});When no experiment or experience targets the slot, visitors get the WordPress content unchanged. When editors launch a hero test, the variant content comes from the Croct dashboard and they publish or pause it without touching WordPress or waiting for a deploy.
On the Next.js side it is the standard @croct/plug-next setup, and because fetchContent runs server-side the tested section arrives in the HTML rather than being swapped in by a script, which is the part the classic WP plugins could never do anyway.
The fallback-is-the-WP-content bit is the piece I was missing. So the editors get their toys back and WordPress doesn't even know. Nice.
We run this exact stack for two clients. One practical tip: decide slot granularity with the editors before you wire anything. We started with one big "homepage" slot and regretted it, because every test touched everything. Section-level slots (hero, proof bar, pricing teaser) map much better to how marketing thinks about tests.
Also keep the WPGraphQL query and the fallback shape in the same module so a field rename in WordPress breaks loudly in one place instead of silently serving a half-empty fallback.