WordPress als Headless CMS: De Developer's Gids [2026]

WordPress drijft 43% van alle websites aan volgens W3Techs, en een groeiend aantal teams gooit de PHP-frontend er volledig uit en gebruikt het als een content-API. Dit is alles wat je moet weten over het draaien van WordPress headless -- van de keuze tussen REST API en WPGraphQL tot het deployen van een Next.js-frontend op Vercel met ISR.

Wat is Headless WordPress? (En Waarom Zou Je Dat Willen?)

Headless WordPress is een setup waarbij WordPress de contentopslag en -beheer afhandelt, terwijl een aparte frontend-applicatie -- gebouwd met Next.js, Nuxt, Astro of een ander framework -- die content via een API ophaalt. WordPress behoudt zijn admin-dashboard, editor, plugin-ecosysteem en MySQL-database. Maar in plaats van pagina's te renderen met PHP-thema's, stelt het content beschikbaar via de WordPress REST API of WPGraphQL, en neemt je frontend de presentatielaag volledig over.

Zie het zo: WordPress wordt de keuken, en je frontend-framework is het restaurant. De keuken bereidt het eten (content) voor, maar het restaurant bepaalt hoe het geserveerd wordt, hoe de eetzaal eruitziet en hoe gasten de maaltijd beleven.

Traditionele vs Headless Architectuur

Bij traditioneel WordPress is alles een monoliet. Een bezoeker vraagt een pagina op, PHP verwerkt het verzoek, bevraagt MySQL, verwerkt het via de template-bestanden van je thema en stuurt gerenderde HTML terug. Het thema beheert de lay-out, styling en routing -- alles.

Bij headless WordPress schrap je die volledige renderinglaag. WordPress zit achter een API, meestal op managed hosting zoals WP Engine of Kinsta. Je frontend -- een React-, Vue- of Svelte-app -- doet API-verzoeken om content op te halen en rendert die vervolgens zoals jij wilt. De twee systemen kunnen op volledig verschillende servers draaien, met verschillende tech stacks en deployment pipelines.

Er is een subtiliteit die 9 van de 10 gidsen overslaan: decoupled en headless zijn niet precies hetzelfde. Decoupled WordPress kan nog steeds terugvallen op PHP-rendering voor bepaalde pagina's (zoals het admin-gedeelte of legacy routes). Volledig headless betekent dat de WordPress-frontend volledig uitgeschakeld is -- alleen API, geen thema-rendering. In deze gids hebben we het over de volledig headless aanpak.

Wanneer Ga je Headless? (En Wanneer Blijf je Traditioneel?)

Headless heeft zin als je team frontend-developers heeft die met moderne tools willen werken, als je content via meerdere kanalen moet leveren (web, mobiele app, digitale borden) of als performance niet onderhandelbaar is. Het is niet voor iedereen de juiste keuze, en eerlijk zijn daarover bespaart je weken verspilde moeite.

Kies voor Headless Wanneer...

• Je team al React/Vue/Svelte kent. Als je frontend-devs de hele dag JSX schrijven, voelt ze dwingen in PHP-thema's als een chef laten koken in een magnetron.
• Je multi-channel delivery nodig hebt. Één WordPress-backend kan je marketingsite, mobiele app en kiosk in de winkel via dezelfde API voeden.
• Performance een harde eis is. Statische pagina's geserveerd via een CDN-edge verslaan PHP-rendering op een gedeelde server altijd.
• Je headless WooCommerce draait. Complexe e-commercefrontends profiteren enorm van aangepaste React/Next.js-storefronts.
• Je de moderne DX wilt. Hot module replacement, TypeScript, componentbibliotheken, CI/CD -- de volledige frontend-toolchain.

Blijf Traditioneel Wanneer...

• Content-editors live preview en page builders nodig hebben. Gutenberg, Elementor en WPBakery gaan uit van een traditioneel thema. Headless gaan doodt de meeste visuele bewerkingsworkflows.
• Je solo developer of een klein team bent. Headless voegt 40-60% setup-complexiteit toe. Als jij alleen een blog onderhoudt, is een traditioneel thema eenvoudiger.
• Je sterk leunt op frontend-plugins. Contactformulieren, SEO-plugins (Yoast rendert meta-tags server-side), cookieconsent-banners -- deze gaan allemaal uit van PHP-rendering.
• Budget krap is. Je hebt aparte hosting nodig voor WordPress en je frontend. Dat zijn twee rekeningen in plaats van één.

REST API vs WPGraphQL: Kies Je Datalaag

WordPress biedt twee manieren om content op te halen in een headless setup: de ingebouwde REST API en de WPGraphQL-plugin. De REST API zit in de WordPress-core en werkt direct -- geen plugins nodig. WPGraphQL vereist het installeren van een plugin maar laat je precies de velden opvragen die je nodig hebt, waardoor het over-fetching-probleem dat REST plaagt verdwijnt. In onze ervaring wint WPGraphQL voor de meeste projecten, maar REST heeft één onderschat voordeel: native HTTP-caching.

WordPress REST API: De Ingebouwde Optie

De REST API is beschikbaar op elke WordPress-installatie sinds versie 4.7 (december 2016). Ga naar /wp-json/wp/v2/posts en je krijgt JSON terug. Eenvoudig, goed gedocumenteerd en het werkt zonder configuratie.

Het nadeel? Over-fetching. Wanneer je een post opvraagt, geeft WordPress alles terug: gerenderde content, ruwe content, excerpt, auteur-ID, uitgelichte media-ID, categorieën, tags, meta-velden, GUID, commentaarstatus, pingstatus, template en nog zo'n 15 andere velden die je waarschijnlijk niet nodig hebt. Voor een bloglijstpagina waar je alleen titels, slugs en excerpts nodig hebt, verstuur je 3 tot 5 keer meer data dan nodig is.

// REST API: Haal 5 recente posts op met auteur en categorieën
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// De _embed-parameter bevat auteur- en categorieobjecten
// Maar ook ALLE velden per post -- ~8KB per post
// Voor 5 posts kijk je naar ~40KB JSON

Je kunt de _fields-parameter gebruiken om te beperken welke velden terugkomen (?_fields=id,title,slug,excerpt), maar dat helpt niet bij embedded resources en je doet nog steeds meerdere verzoeken als je gerelateerde data nodig hebt.

WPGraphQL: Vraag Precies Wat je Nodig Hebt

WPGraphQL is een gratis open-source plugin van Jason Bahl (nu beheerd door WP Engine) die een volledige GraphQL-API aan WordPress toevoegt. Je schrijft een query die precies aangeeft welke velden je wilt, en je krijgt precies dat terug -- niets meer.

# WPGraphQL: Dezelfde query -- 5 recente posts met auteur en categorieën
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Respons: ~2KB precies gestructureerde JSON
# Geen extra velden, geen ballast

Code-vergelijking Naast Elkaar

Zo zien de respons-payloads er werkelijk uit:

Welke Moet je Kiezen?

Gebruik REST wanneer je iets snel bouwt, je team GraphQL niet kent of je agressieve HTTP-caching nodig hebt zonder extra tooling.

Gebruik WPGraphQL wanneer je een productiefrontend bouwt met complexe datavereisten, je kleinere payloads wilt of je team GraphQL al elders gebruikt.

Ons oordeel: Voor een serieus headless WordPress-project met Next.js is WPGraphQL de betere keuze. De payload-besparing, de developer-ervaring met GraphiQL IDE en het ophalen van data in één verzoek maken de plugin-afhankelijkheid de moeite waard.

WordPress Instellen als Headless CMS

WordPress instellen als headless CMS verloopt in zes stappen: WordPress installeren, de juiste plugins toevoegen, je contentmodel configureren, het frontend-thema uitschakelen, authenticatie instellen en controleren of je API werkt. Het hele proces duurt ongeveer 30 tot 45 minuten als je het eerder hebt gedaan, of een paar uur de eerste keer.

Stap 1: Begin met een verse WordPress-installatie op managed hosting. Kinsta, WP Engine en Cloudways bieden allemaal omgevingen die geoptimaliseerd zijn voor WordPress. Als je alleen aan het experimenteren bent, werkt een lokale installatie met LocalWP prima.

Stap 2: Installeer de essentiële plugins:

Stap 3: Maak je contentmodel met ACF. Definieer veldgroepen die aansluiten bij je frontend-componenten. Een portfolio-posttype kan velden hebben voor projectUrl, techStack (repeater), clientName en projectYear.

Essentiële Plugins

WPGraphQL for ACF verdient speciale aandacht. Zonder die plugin verschijnen je ACF-velden niet in GraphQL-queries. Na installatie kun je aangepaste velden opvragen als volgt:

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

De WordPress-Frontend Uitschakelen

Stap 4: Je wilt niet dat bezoekers je WordPress-URL bezoeken en een kapot thema zien. Voeg dit toe aan de functions.php van je thema of gebruik een mu-plugin:

// Stuur alle frontend-verzoeken door naar de API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

Stap 5: Stel Application Passwords in voor authenticatie. Ga naar Gebruikers > Jouw profiel > Application Passwords, genereer een wachtwoord en gebruik dat voor geauthenticeerde API-verzoeken (het aanmaken of bijwerken van content via externe tools).

Je API Testen

Stap 6: Open je browser en ga naar https://your-site.com/graphql -- je zou de GraphiQL IDE moeten zien. Probeer je posts te queryen. Als je REST gebruikt, navigeer naar https://your-site.com/wp-json/wp/v2/posts en controleer of je JSON terugkrijgt.

Pro tip: de GraphiQL IDE die met WPGraphQL meekomt is oprecht uitstekend voor het verkennen van je schema. Je krijgt autocomplete, documentatie en querygeschiedenis. Het is de snelste manier om uit te vinden welke velden beschikbaar zijn en hoe je ACF-data gestructureerd is.

Een Next.js-Frontend Bouwen met WPGraphQL

De schoonste manier om in 2026 een headless WordPress-frontend te bouwen is met de App Router van Next.js 15 en React Server Components. Server Components halen data op de server op zonder JavaScript naar de client te versturen, en WPGraphQL geeft je precieze queries -- een natuurlijke combinatie. Toen ik WPGraphQL voor het eerst koppelde aan de Next.js App Router, was de grootste valkuil de beeldafhandeling -- maar daar komen we zo op.

Project Setup en Omgevingsvariabelen

Begin met een nieuw Next.js-project. Vercel biedt ook een officieel WordPress-startersjabloon als je een referentiearchitectuur wilt.

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

Maak .env.local met je WordPress-endpoints:

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Maak nu een lichte GraphQL fetch-utility. Je hebt Apollo of urql niet nodig voor Server Components -- gewone fetch werkt perfect omdat er geen client-side state te beheren is:

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR: revalideer elk uur
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

Voor React-framework-opties, bekijk onze vergelijking van Next.js versus plain React met Vite -- er zijn valide redenen om het framework te skippen, maar voor headless CMS-werk maken de ingebouwde SSR en ISR Next.js de praktische keuze. En als je twijfelt tussen Next.js en Remix, bespreken we dat in onze post over waarom we Next.js aanbevelen voor de meeste projecten.

Posts Ophalen met Server Components

Dit is de bloglijstpagina als Server Component -- geen useEffect, geen laadstatussen, geen client-side hydration:

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

Dynamische Postpagina's

Individuele postpagina's gebruiken generateStaticParams om alle posts bij de build-tijd te pre-renderen, waarna ISR nieuwe content oppikt:

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

Vergeet niet next.config.ts te configureren voor WordPress-afbeeldingen:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

Headless WordPress Deployen naar Productie

Een productie headless WordPress-setup gebruikt dubbele hosting: WordPress draait op managed WordPress-hosting (WP Engine, Kinsta of Cloudways), terwijl de Next.js-frontend naar een edge-platform zoals Vercel of Netlify wordt gedeployd. Deze scheiding betekent dat elke laag onafhankelijk kan schalen -- WordPress verwerkt content-bewerking en API-verzoeken, terwijl de frontend statische en ISR-pagina's levert vanuit CDN-edge nodes wereldwijd.

Hostingarchitectuur

De datastroom ziet er zo uit: content-editors publiceren in de WordPress-admin, WordPress slaat content op in MySQL, de Next.js-frontend haalt content op via WPGraphQL, Vercel genereert statische HTML op de edge en bezoekers raken het CDN -- en raken WordPress nooit direct aan.

Voor frontend-hosting, bekijk onze Vercel vs Netlify vergelijking voor een gedetailleerde analyse. Beide werken goed voor headless WordPress. Als je container-gebaseerde alternatieven overweegt, behandelt onze Railway, Render en Fly.io vergelijking die opties.

ISR en On-Demand Revalidatie

Dit is het deel dat headless WordPress werkelijk levensvatbaar maakt in productie. We hebben gemerkt dat on-demand revalidatie de setup-inspanning waard is, want zonder dat zit je vast tussen verouderde content (lange revalidatie-intervallen) en trage builds (korte intervallen die je WordPress API overbelasten).

ISR laat je een revalidate-tijd instellen per pagina. Na dat interval krijgt de volgende bezoeker de gecachede pagina terwijl Next.js die op de achtergrond regenereert. Maar de echte magie is on-demand revalidatie -- een rebuild triggeren op het moment dat content gepubliceerd wordt:

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Revalideer ook de lijstpagina
  }

  return NextResponse.json({ revalidated: true });
}

Voeg aan de WordPress-kant een webhook toe die afgaat bij publish_post via een plugin zoals WP Webhooks of een eenvoudig functions.php-stukje dat je Vercel /api/revalidate-endpoint aanroept. Nu gaat content live binnen seconden na het klikken op "Publiceer" -- geen volledige rebuilds, geen wachten. Zie de Next.js ISR-documentatie voor meer configuratieopties.

Kostenoverzicht

WordPress Headless vs Doelgebouwde Headless CMS

Na het werken met zowel headless WordPress als doelgebouwde CMSen zoals Sanity, Contentful en Strapi, is dit mijn eerlijke mening: headless WordPress is een pragmatische keuze als je een bestaande WordPress-site of content-team hebt. Het is zelden de beste keuze als je van nul begint.

Waar Headless WordPress Wint

• Content-editors kennen het al. De admin-UI van WordPress heeft 20 jaar verfijning achter de rug. Een niet-technisch team trainen op Sanity Studio of de interface van Contentful kost weken.
• Plugin-ecosysteem. 60.000+ plugins. Meertalig nodig? WPML. E-commerce? WooCommerce. SEO-contentanalyse? Yoast (werkt nog steeds in de admin). Geen doelgebouwde CMS evenaart deze breedte.
• Werving. WordPress heeft de grootste ontwikkelaarspool van welk CMS dan ook. Een WordPress-developer vinden is dramatisch eenvoudiger dan een Sanity- of Payload-specialist.
• WooCommerce. Als je headless e-commerce met WordPress-content nodig hebt, is WooCommerce + WPGraphQL een bewezen stack. Saleor en Medusa zijn alternatieven, maar WooCommerce heeft het marktaandeel.

Waar Doelgebouwde CMSen Winnen

• Contentmodellering. Sanity's GROQ, Contentful's content types en het TypeScript-schema van Payload zijn van de grond af ontworpen voor gestructureerde content. Het post/pagina/custom-posttype-model van WordPress voelt aan als iets dat er achteraf bij is gezet.
• Realtime samenwerking. Sanity heeft real-time bewerking in Google Docs-stijl. Contentful heeft live samenwerking. WordPress? Je krijgt een "Dit bericht wordt bewerkt door iemand anders"-vergrendelscherm.
• API-first architectuur. WPGraphQL is briljant, maar het is nog steeds een plugin bovenop een PHP-monoliet. De API van Contentful en Sanity zijn van dag één API-first ontworpen.
• Mediabeheer. De WordPress-mediabibliotheek is functioneel maar basaal. De beeldpipeline van Sanity met automatische bijsnijdingen, hotspots en CDN-levering is een andere klasse. Contentful en Storyblok integreren native met Cloudinary.
• Developer-ervaring. Strapi en Payload geven je een lokale dev-omgeving met hot-reload bij schemawijzigingen. Bij WordPress moet je de admin vernieuwen en databasemigraties uitvoeren.

Oordeel: Welke Moet je Kiezen?

Gebruik headless WordPress wanneer: je een bestaande WordPress-site hebt met jaren aan content, je editors weigeren een nieuwe CMS te leren, je WooCommerce nodig hebt of je een specifieke WordPress-plugin nodig hebt die nergens anders een equivalent heeft.

Kies een doelgebouwde headless CMS wanneer: je een nieuw project van nul begint, je realtime samenwerking nodig hebt, je contentmodel complex en gestructureerd is, of je team developer-ervaring boven plugin-breedte stelt.

Bij Techsy hebben we headless WordPress-frontends gebouwd voor klanten die migreren vanuit traditioneel WordPress. Onze standaardaanpak: WPGraphQL + Next.js App Router op Vercel, met ISR voor performance en on-demand revalidatie voor verse content. Vraag een gratis consult aan

WordPress MCP en de Abilities API: De AI-Toekomst

WordPress 6.9 introduceerde de Abilities API, die samensmelting met WordPress 7.0 core (april 2026). Het creëert een gestandaardiseerde, getypeerde en ontdekbare interface voor WordPress-functionaliteit -- zie het als WordPress dat zijn mogelijkheden beschikbaar stelt in een machine-leesbaar formaat dat AI-tools kunnen begrijpen en gebruiken.

De WordPress MCP Adapter koppelt deze Abilities API aan het Model Context Protocol (MCP), de open standaard voor het verbinden van AI-systemen met externe tools. Wat betekent dit in de praktijk? AI-agents in Claude, Cursor of VS Code kunnen nu ontdekken wat je WordPress-site kan doen en die acties vervolgens direct uitvoeren.

Een praktisch scenario: Claude kan een WordPress-post aanmaken, ACF-velden vullen met gestructureerde data, categorieën toewijzen, een uitgelichte afbeelding instellen en je Vercel-revalidatiewebhook triggeren -- allemaal in één gesprek. Geen browser, geen admin-panel, geen kopiëren-plakken.

Dit staat nog in de kinderschoenen en de MCP-adapter evolueert nog. Maar het geeft iets belangrijks aan: WordPress zit niet stil terwijl doelgebouwde headless CMSen innoveren. De combinatie van Abilities API + MCP zou WordPress een van de meest AI-toegankelijke CMSen kunnen maken, waarbij het enorme plugin-ecosysteem op manieren wordt ingezet die nieuwere, kleinere platforms niet kunnen evenaren. Lees de officiële aankondiging op de WordPress Developer Blog voor alle technische details.

Performance: Headless WordPress vs Traditioneel WordPress

Headless WordPress met een statische frontend verbetert de performance dramatisch vergeleken met traditioneel PHP-gerenderd WordPress. Traditioneel WordPress serveert dynamische pagina's door bij elk verzoek PHP uit te voeren, wat resulteert in een slechte Time to First Byte (TTFB) -- volgens performancedata van medio 2025 ziet slechts 31% van de WordPress-desktop clients en 24% op mobiel goede TTFB-scores. Headless gaan met Next.js en ISR betekent dat pagina's pre-rendered zijn en geserveerd worden vanuit CDN-edge nodes, waardoor TTFB daalt tot onder de 100ms voor gecachede pagina's.

WP Engine's case study over Android Authority toonde een 6x verbetering in Lighthouse-performancescores na migratie naar headless WordPress. Core Web Vitals-data vertelt een vergelijkbaar verhaal: slechts 45% van de WordPress-sites slaagt voor alle drie CWV-metrieken op mobiel, vergeleken met 65% voor Shopify en 83% voor Duda.

Eén belangrijke kanttekening: headless lost een trage WordPress-backend niet op. Als je WordPress API 3 seconden nodig heeft om te reageren omdat je op goedkope gedeelde hosting zit met 40 plugins, zal je ISR-regeneratie ook traag zijn. De frontend kan niet sneller zijn dan de API waarvan die afhankelijk is. Investeer in kwaliteit managed hosting -- het is in een headless setup belangrijker, niet minder. WordPress Performance Lead Weston Ruter's blog heeft uitstekende data over wat echt verschil maakt voor WordPress-serverprestaties.

FAQ

Wat is headless WordPress?

Headless WordPress is een architectuur waarbij WordPress uitsluitend als content management-backend dient, met het PHP-frontend-thema volledig uitgeschakeld. Content wordt geleverd via de REST API of WPGraphQL aan een aparte frontend-applicatie gebouwd met frameworks zoals Next.js, Nuxt of Astro. Het WordPress-admin-dashboard blijft volledig functioneel voor content-editors.

Is WordPress goed als headless CMS?

WordPress werkt goed als headless CMS wanneer je een bestaande WordPress-site hebt, content-editors die de interface kennen of het plugin-ecosysteem nodig hebt (met name WooCommerce). Het is minder ideaal dan doelgebouwde headless CMSen zoals Sanity of Contentful als je van nul begint, omdat WordPress's contentmodellering en API achteraf zijn toegevoegd in plaats van van dag één API-first gebouwd.

Wat zijn de nadelen van headless WordPress?

De voornaamste nadelen zijn: verhoogde complexiteit (twee hostingomgevingen in plaats van één), verlies van visuele bewerking en page builder-functionaliteit, frontend-plugins werken niet meer (Yoast meta-rendering, contactformulieren, cookiebanners), geen realtime contentsamenwerking en de GraphQL-API is een plugin-afhankelijkheid in plaats van kernfunctionaliteit. Het budget stijgt ook omdat je betaalt voor zowel WordPress-hosting als frontend-hosting.

Hoe verbind ik Next.js met WordPress?

Installeer WPGraphQL op je WordPress-site, maak vervolgens een Next.js-project aan met App Router. Stel je WordPress GraphQL-endpoint in als omgevingsvariabele, schrijf een eenvoudige fetch-gebaseerde GraphQL-hulpfunctie en gebruik die in Server Components om posts, pagina's en aangepaste contenttypes op te vragen. Apollo of urql zijn niet nodig -- gewone fetch werkt omdat Server Components op de server draaien.

WPGraphQL vs REST API -- welke is beter?

WPGraphQL is beter voor productiefrontends omdat het alleen de velden teruggeeft die je opvraagt (payload-omvang 60-80% kleiner), geneste queries ondersteunt in één verzoek en een GraphiQL IDE biedt voor schema-verkenning. De REST API is beter voor snelle prototypes, teams die GraphQL niet kennen of situaties waar native HTTP-caching kritisch is zonder extra tooling.

Hoeveel kost headless WordPress?

Een minimale headless WordPress-setup kost ongeveer $14 per maand -- Cloudways voor WordPress-hosting plus Vercel's gratis Hobby-tier voor de frontend. Een productie-setup met WP Engine en Vercel Pro kost $40-70 per maand. Voeg $0-50 per maand toe voor premium plugins zoals ACF Pro en WPML. Doelgebouwde headless CMSen hebben vaak royale gratis tiers, dus kosten alleen zijn geen reden om te kiezen voor headless WordPress.

Kan ik WooCommerce gebruiken met headless WordPress?

Ja. WPGraphQL heeft een WooCommerce-extensie (WPGraphQL WooCommerce, ook wel "WooGraphQL") die producten, bestellingen, winkelwagen en kassa-functionaliteit via GraphQL beschikbaar stelt. Dit laat je aangepaste React-storefronts bouwen met volledige e-commerce-mogelijkheden. De checkout-flow vergt extra werk vergeleken met traditionele WooCommerce-thema's, maar de performance- en UX-voordelen zijn aanzienlijk voor druk bezochte winkels.

Heb ik een developer nodig om headless WordPress op te zetten?

Ja, een headless WordPress-setup vereist frontend-ontwikkelvaardigheden -- met name React (of Vue/Svelte) en bekendheid met API's. Je moet de volledige frontend van nul bouwen of een startersjabloon aanpassen. Dit is geen no-code-oplossing. Content-editors kunnen de WordPress-admin normaal blijven gebruiken, maar de initiële setup en doorlopend frontend-onderhoud vereisen betrokkenheid van een developer.

Welke plugins zijn essentieel voor headless WordPress?

De essentiële plugins zijn WPGraphQL (GraphQL-API), Advanced Custom Fields of ACF (gestructureerde contentmodellering) en WPGraphQL for ACF (stelt aangepaste velden bloot via GraphQL). Sterk aanbevolen: Custom Post Type UI voor het registreren van posttypes via de admin, en een webhookplugin zoals WP Webhooks voor het triggeren van frontend-rebuilds bij contentpublicatie. Vermijd frontend-afhankelijke plugins zoals Yoast SEO's meta-rendering of formulierplugins.

Is headless WordPress goed voor SEO?

Headless WordPress kan uitstekend zijn voor SEO wanneer correct geïmplementeerd met Next.js of Nuxt, omdat je server-side rendering krijgt, snellere paginalaadtijden (wat Core Web Vitals verbetert) en volledige controle over meta-tags, structured data en URL-structuur. Het risico is dat je automatische SEO-pluginfuncties zoals Yoast's meta-tagrendering verliest -- je moet meta-tags, sitemaps en structured data handmatig in je frontendcode afhandelen.