# Headless WordPress feeding a Next.js frontend, where does personalization fit?

Asked by Wes Delaney on 2025-11-05. Tags: wordpress, nextjs, headless, cms.

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

### Answer from jwhitfield (2025-11-06)

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:

```tsx
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.

#### Reply from Wes Delaney (2025-11-06)

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.

### Answer from Sofia Lindqvist (2025-11-07)

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.