Hoe gebruik je WordPress met Next.js voor een headless website?

Moderne websites vereisen snelheid, flexibiliteit en ijzersterke SEO. Een headless WordPress-installatie met Next.js biedt alledrie. Door je contentmanagementsysteem te scheiden van je frontend, profiteer je van het beste van twee werelden: de vertrouwde bewerkingservaring van WordPress en de razendsnelle renderingmogelijkheden van Next.js.

Deze handleiding leidt je door alles heen, van het begrijpen van de architectuur tot het implementeren van een productieklare headless website.

Of je nu een ontwikkelaar bent die experimenteert met ontkoppelde CMS-systemen of een team dat een verouderde WordPress-website wil moderniseren, deze stapsgewijze handleiding biedt je de nodige ondersteuning.

Kort samengevat: bouw een snelle en schaalbare headless website

• Gebruik een ontkoppelde opzet om contentbeheer en frontend van elkaar te scheiden voor meer flexibiliteit.
• Haal content op via REST API of GraphQL voor efficiënte dataoverdracht.
• Verbeter de prestaties met statische generatie, server-side rendering en slimme caching.
• Implementeer op moderne hostingplatforms en beveiligde API's voor snelheid , schaalbaarheid en bescherming.

Wat is headless WordPress en waarom combineer je het met Next.js?

Om de kracht van deze combinatie te begrijpen, moet je eerst het concept van een 'headless' architectuur begrijpen en waarom deze twee specifieke technologieën zo'n perfecte combinatie vormen.

De architectuur van een headless WordPress CMS definiëren

Traditioneel WordPress is een monolithisch systeem. Het beheert de opslag van content, de bedrijfslogica en de paginarendering op één plek. Wanneer een bezoeker op uw site terechtkomt, raadpleegt WordPress de database, verwerkt PHP-templates en levert een volledig gerenderde HTML-pagina.

Headless WordPress breekt met dat model. In een headless architectuur:

• WordPress fungeert uitsluitend als backend. Het beheert de content, gebruikersauthenticatie en gegevensopslag.

• De frontend is volledig gescheiden. Een JavaScript-framework zoals Next.js verzorgt alle rendering en gebruikersinteractie.

• Een API vormt de brug tussen de twee. WordPress stelt content beschikbaar via zijn REST API of GraphQL-endpoint, en Next.js haalt die data op om pagina's te bouwen.

De term "headless" komt van het verwijderen van de "head", de frontend-presentatielaag, uit WordPress.

Je WordPress-installatie bestaat nog steeds, redacteuren loggen nog steeds in op /wp-admin en berichten worden nog steeds op dezelfde manier aangemaakt. Maar bezoekers communiceren nooit rechtstreeks met WordPress. Ze communiceren met je Next.js-frontend.

Voordelen van het ontkoppelen van de backend en de frontend

Het loskoppelen van je WordPress-backend van je frontend-architectuur biedt een aantal enorme voordelen:

• Prestatiewinst : Next.js rendert pagina's vooraf als statische HTML tijdens het bouwproces. Er vindt geen PHP-verwerking plaats bij elk verzoek, wat de Time to First Byte (TTFB) aanzienlijk verkort.

• Frontend-vrijheid : Je kunt je frontend opnieuw opbouwen of ontwerpen zonder WordPress aan te raken. Wissel van framework, herontwerp lay-outs of voer A/B-tests uit zonder CMS-migraties.

• Verbeterde beveiliging : Uw WordPress-installatie kan op een privéserver of een subdomein draaien, verborgen voor het openbare internet. Aanvallers kunnen wp-login.php als ze het niet kunnen vinden.

• Schaalbaarheid : Statische pagina's die via een CDN , kunnen pieken in het verkeer moeiteloos opvangen. Uw WordPress-server ontvangt alleen API-verzoeken, geen paginaladingen.

• Contentlevering via meerdere kanalen : dezelfde WordPress-content-API kan tegelijkertijd een website, een mobiele app, een spraakassistent en een kiosk bedienen.

• Betere ontwikkelaarservaring : Frontend-teams werken met React- en JavaScript-tools die ze al kennen, zonder PHP of WordPress-themaontwikkeling te hoeven leren.

Waarom is Next.js ideaal voor de prestaties en SEO van headless WordPress?

Next.js onderscheidt zich om verschillende redenen van andere JavaScript-frameworks voor headless CMS-projecten.

• Server-side rendering (SSR) en statische sitegeneratie (SSG) geven je controle over wanneer en hoe pagina's worden weergegeven. Je kunt je blog statisch genereren tijdens het bouwen, productpagina's die regelmatig veranderen server-renderen, of beide strategieën combineren op je website.

• De ingebouwde beeldoptimalisatie via de next/image- component zorgt ervoor dat afbeeldingen met de juiste afmetingen en WebP-indeling automatisch worden geladen met lazy loading. Dit verbetert de Core Web Vitals-scores direct.

• Bestandsgebaseerde routing maakt dynamische routes eenvoudig. Door een [slug].js- bestand in je paginadirectory aan te maken, worden alle URL's van blogberichten automatisch afgehandeld.

• Met API Routes kun je serverlogica, zoals formulierverwerking of webhook-afhandeling, rechtstreeks in je Next.js-project toevoegen zonder een aparte backend.

• De SEO-functionaliteit is ingebouwd. Next.js genereert de volledige HTML op de server, waardoor zoekmachinecrawlers de complete pagina-inhoud ontvangen zonder te hoeven wachten tot JavaScript is uitgevoerd. In combinatie met de next/head A meta-tag zorgt dit ervoor dat uw site SEO-concurrerend blijft.

REST API versus GraphQL voor het ophalen van WordPress-content

WordPress biedt twee API-benaderingen voor headless-configuraties:

De WordPress REST API is standaard onderdeel van de WordPress-kern. Er zijn geen extra plugins nodig. De API biedt de volgende eindpunten: /wp-json/wp/v2/posts voor berichten en /wp-json/wp/v2/pages voor pagina's. Het gebruik van fetch() en werkt prima voor simpele contentaanvragen.

WPGraphQL is een plugin die een GraphQL-endpoint toevoegt aan WordPress. In plaats van een groot JSON- object met tientallen velden te ontvangen die je niet nodig hebt, schrijf je een query die alleen de exacte velden opvraagt ​​die je frontend vereist.

Dit verkleint de payloadgrootte, vereenvoudigt het ophalen van geneste gegevens (bijvoorbeeld berichten met hun categorieën en auteursgegevens in één verzoek) en geeft je frontendteam een ​​sterk getypeerd schema om mee te werken.

Voor kleine projecten of teams die nog niet bekend zijn met GraphQL, is de REST API meer dan voldoende. Voor grotere websites met complexe contentrelaties biedt WPGraphQL doorgaans betere prestaties en een gebruiksvriendelijkere ontwikkelomgeving .

Vereisten voor het bouwen van een headless WordPress- en Next.js-installatie

Voordat je code schrijft, moet je een solide basis leggen en je omgeving voorbereiden.

Vereiste tools en omgevingsinstellingen

Om een ​​headless WordPress-installatie te kunnen volgen, hebt u de volgende tools op uw computer nodig:

• Node.js (versie 18 of later): Download het van nodejs.org. Voer `node -v` in je terminal om de installatie te bevestigen.

• npm of Yarn: npm wordt meegeleverd met Node.js. Yarn is optioneel, maar wordt door sommige teams geprefereerd.

• Een werkende WordPress-installatie: lokaal (met LocalWP, MAMP of Docker ) of een gehoste instantie. De enige vereiste is dat deze toegankelijk is via HTTP.

• Een code-editor: VS Code met de ESLint- en Prettier-extensies biedt de beste Next.js-ontwikkelervaring.

• Git : Voor versiebeheer en implementatieworkflows.

Voor lokale WordPress-ontwikkeling is LocalWP de snelste manier om zonder configuratie een WordPress-site op je eigen computer op te zetten.

De benodigde WordPress-plugins installeren (WPGraphQL, REST API)

De WordPress REST API is standaard ingeschakeld in alle moderne WordPress-installaties. Je kunt controleren of het werkt door https://yoursite.com/wp-json/wp/v2/posts in je browser te bezoeken.

Voor WPGraphQL:

• Log in op je WordPress-dashboard.

• Ga naar Plugins → Nieuwe toevoegen .

• Zoek naar WPGraphQL en installeer de plugin van Jason Bahl.

• Activeer het.

• Er verschijnt een nieuw menu-item voor GraphQL in je dashboard. Ga naar GraphQL → Instellingen om het eindpunt te configureren.

Je kunt ook WPGraphQL voor ACF installeren als je Advanced Custom Fields . Hiermee worden aangepaste veldgegevens beschikbaar gesteld via je GraphQL-schema.

Om je GraphQL-endpoint te testen, ga je in je dashboard naar GraphQL → GraphiQL IDE. In deze interactieve omgeving kun je query's schrijven en testen voordat je ze in je Next.js-project gebruikt.

WordPress API-configuratie voor headless levering

Verschillende WordPress-instellingen beïnvloeden de levering via headless API's:

• Permalinks : Ga naar Instellingen → Permalinks en selecteer een andere optie dan 'Platte permalink'. De REST API werkt niet correct met platte permalinks. 'Berichtnaam' ( /%postname%/ ) is de meest gebruikelijke keuze.

• CORS-headers: Standaard kunnen WordPress REST API-reacties cross-origin-verzoeken van uw Next.js-ontwikkelserver blokkeren. Voeg CORS-headers toe aan het functions.php-bestand of gebruik een plugin zoals WP CORS om verzoeken van uw Next.js-domein toe te staan.

• Applicatiewachtwoorden: Voor privé- of conceptcontent ondersteunt WordPress applicatiewachtwoorden (geïntroduceerd in WordPress 5.6). Genereer er een in je gebruikersprofiel en voeg deze toe aan je API-verzoeken als een Basic Auth-header.

• Zichtbaarheid van openbare content: Zorg ervoor dat berichten die u wilt weergeven, openbaar zijn en niet met een wachtwoord beveiligd of privé.

De basisprincipes van React en Next.js begrijpen voordat je begint

Headless WordPress-ontwikkeling met Next.js vereist bekendheid met:

• De basisprincipes van React: componenten, props, state en de useEffect- en useState- hooks.

• Next.js-paginaweergavemethoden: om het verschil tussen getStaticProps , getServerSideProps en getStaticPaths .

• Async JavaScript: Je schrijft asynchrone code voor het ophalen van gegevens met behulp van async/await en de Fetch API.

• JSX-syntaxis: Hoe schrijf je HTML-achtige syntaxis in JavaScript?

Als je nog niet bekend bent met Next.js, is het zeker de moeite waard om een ​​paar uur te besteden aan de officiële Next.js-handleiding op nextjs.org/learn voordat je aan dit project begint.

Stapsgewijze handleiding voor het verbinden van WordPress en Next.js

Nu de basis is gelegd, gaan we de backend met de frontend . Deze handleiding maakt gebruik van het Next.js Pages Router-paradigma, dat veel gebruikt wordt voor statische blogarchitecturen.

Stap 1: Een nieuw Next.js-project maken en configureren

Open je terminal en maak een nieuwe Next.js-applicatie aan met behulp van het hulpprogramma create-next-app.

npx create-next-app@latest my-headless-site cd my-headless-site

De installatiewizard vraagt ​​of je TypeScript, ESLint, Tailwind CSS en de App Router wilt gebruiken. Kies voor deze handleiding de Pages Router voor maximale compatibiliteit met bestaande tutorials en plugins. TypeScript wordt aanbevolen voor grotere projecten.

Maak vervolgens een .env.local- bestand aan in de rootmap van je project om je WordPress-URL op te slaan:

NEXT_PUBLIC_WORDPRESS_API_URL=https://your-wordpress-site.com/wp-json/wp/v2 WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Voeg dit bestand nooit toe aan versiebeheer. Voeg .env.local toe aan je .gitignore .

Stap 2: WordPress-gegevens ophalen met de REST API en getStaticProps

Maak een bestand aan in pages/blog/index.js . Deze pagina toont alle blogberichten die zijn opgehaald via de WordPress REST API:

export default function BlogIndex({ posts }) { return (<ul> {posts.map((post) => (<li key={post.id}> <a href={`/blog/${post.slug}`}>{post.title.rendered}</a></li> ))}</ul> ); } export async function getStaticProps() { const res = await fetch( `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/posts?_embed&per_page=100` ); const posts = await res.json(); return { props: { posts }, revalidate: 60, }; }

getStaticProps wordt tijdens het buildproces op de server uitgevoerd. Het haalt berichten op van WordPress en geeft deze door als props aan je component. Deze revalidate : 60 maakt incrementele statische regeneratie mogelijk, zoals beschreven in het geavanceerde gedeelte.

Stap 3: WPGraphQL gebruiken met Apollo of een andere GraphQL-client

Voor een meer schaalbare aanpak kunt u WPGraphQL gebruiken. Installeer eerst een lichtgewicht GraphQL-client in uw Next.js-project.

npm install @apollo/client graphql

Maak een hulpprogramma-bestand aan in lib/apolloClient.js :

import { ApolloClient, InMemoryCache } from "@apollo/client"; const client = new ApolloClient({ uri: process.env.WORDPRESS_GRAPHQL_ENDPOINT, cache: new InMemoryCache(), }); export default client;

Vervolgens kun je WordPress-berichten opvragen met GraphQL in getStaticProps :

import client from "../../lib/apolloClient"; import { gql } from "@apollo/client"; const GET_POSTS = gql` query GetPosts { posts { nodes { id title slug date excerpt featuredImage { node { sourceUrl altText } } } } } `; export async function getStaticProps() { const { data } = await client.query({ query: GET_POSTS }); return { props: { posts: data.posts.nodes }, revalidate: 60, }; }

Deze aanpak haalt alleen de velden op die uw frontend gebruikt, waardoor de API-reacties compact blijven.

Stap 4: Dynamische routes en statische generatie voor blogpagina's

Om voor elk blogbericht een aparte pagina te maken, moet je dynamische routing gebruiken. Maak in Next.js een bestand [slug].js in de pages/posts/ .

Je gebruikt `getStaticPaths` om Next.js te vertellen welke URL's er gebouwd moeten worden, en `getStaticProps` om de specifieke inhoud voor elke URL op te halen.

export async function getStaticPaths() { const res = await fetch( `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/posts?per_page=100` ); const posts = await res.json(); const paths = posts.map((post) => ({ params: { slug: post.slug }, })); return { paths, fallback: "blocking" }; } export async function getStaticProps({ params }) { const res = await fetch( `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/posts?slug=${params.slug}&_embed` ); const posts = await res.json(); if (!posts.length) { return { notFound: true }; } return { props: { post: posts[0] }, revalidate: 60, }; }

`getStaticPaths` vertelt Next.js welke slugs vooraf gerenderd moeten worden. Door `fallback: "blocking"` , wordt elke slug die niet in de initiële build zit, bij het eerste verzoek door de server gerenderd en vervolgens als statische pagina in de cache opgeslagen.

Stap 5: Het verwerken van berichtinhoud, afbeeldingen en aangepaste velden

WordPress slaat de inhoud van berichten als onbewerkte HTML. Render deze veilig met behulp van React's dangerouslySetInnerHTML :

<div dangerouslySetInnerHTML={{ __html: post.content.rendered }} />

Voor uitgelichte afbeeldingen gebruikt u de queryparameter _embed post._embedded['wp:featuredmedia'][0].source_url .

Wikkel het in de Image- component van Next.js voor automatische optimalisatie:

import Image from "next/image"; <Image src={post._embedded["wp:featuredmedia"][0].source_url} alt={post.title.rendered} width={1200} height={630} />

Voor geavanceerde aangepaste velden (ACF) moet u de WPGraphQL for ACF-plugin inschakelen. De gegevens van de aangepaste velden verschijnen dan in uw GraphQL-schema en kunnen samen met de standaard postgegevens worden opgevraagd.

Geavanceerde technieken voor headless WordPress en Next.js

Zodra de basisfunctionaliteit werkt, kunt u geavanceerde functies implementeren om uw website de uitstraling van een professionele bedrijfsapplicatie te geven.

Optimaliseer met incrementele statische regeneratie (ISR)

Met ISR kun je statisch gegenereerde pagina's na de implementatie bijwerken zonder je hele site opnieuw op te bouwen. De configuratie hangt af van de Next.js-router die je gebruikt, en het verwarren van beide is een veelvoorkomende bron van bugs.

Pagina's Router ISR (tijdgebaseerd)

Voeg een hervalidatiewaarde (in seconden) toe aan de van getStaticProps :

return { props: { post }, revalidate: 300, // Genereer elke 5 minuten opnieuw };

Wanneer een gebruiker een pagina bezoekt nadat de hervalidatieperiode is verlopen, serveert Next.js direct de pagina uit de cache, terwijl deze op de achtergrond opnieuw wordt gegenereerd. De volgende bezoeker krijgt de actuele versie te zien.

Pagina's Router ISR (op aanvraag)

Voor automatische hervalidatie, geactiveerd door een WordPress-publicatie- of updategebeurtenis, maakt u een API-route aan op pages/api/revalidate.js . WordPress roept deze route aan via een webhook:

export default async function handler(req, res) { if (req.query.secret !== process.env.REVALIDATION_SECRET) { return res.status(401).json({ message: "Ongeldig token" }); } const slug = req.query.slug; try { await res.revalidate(`/blog/${slug}`); return res.json({ revalidated: true }); } catch (err) { return res.status(500).send("Fout bij hervalidatie"); } }

res.revalidate() is de correcte Pages Router-methode. Deze methode activeert een onmiddellijke regeneratie op de achtergrond voor dat specifieke pad, zonder te wachten tot het tijdsvenster is verlopen.

App Router ISR

app/ gebruikt in plaats van de Pages Router, is de syntax anders. Tijdgebaseerde hervalidatie wordt ingesteld als een export van de routesegmentconfiguratie:

// app/blog/[slug]/page.js export const revalidate = 300;

Voor het opnieuw valideren op aanvraag in de App Router wordt gebruikgemaakt van revalidatePath() of revalidateTag() , geïmporteerd uit next/cache , binnen een Server Action of Route Handler, niet binnen een API Route:

// app/api/revalidate/route.js (App Router Route Handler) import { revalidatePath } from "next/cache"; import { NextResponse } from "next/server"; export async function POST(request) { const { slug, secret } = await request.json(); if (secret !== process.env.REVALIDATION_SECRET) { return NextResponse.json({ message: "Ongeldig token" }, { status: 401 }); } revalidatePath(`/blog/${slug}`); return NextResponse.json({ revalidated: true }); }

Belangrijk onderscheid: res.revalidate() hoort bij de Pages Router. revalidatePath() en revalidateTag() horen bij de App Router. Het gebruik van App Router-methoden binnen een Pages Router-project, of omgekeerd, zal leiden tot stille fouten of runtimefouten. Zorg ervoor dat de methode overeenkomt met de router die u daadwerkelijk gebruikt.

In het stapsgewijze gedeelte van deze handleiding wordt de Pages Router gebruikt. Als u in de toekomst overstapt naar de App Router, dient u alle ISR-logica aan te passen om revalidatePath() in de Route Handlers te gebruiken.

Voorbeeldmodus toevoegen voor conceptinhoud

Met de previewmodus kunnen redacteuren concept-WordPress-content op uw Next.js-frontend bekijken voordat ze deze publiceren. Stel twee API-routes in:

• /api/preview : Schakelt de previewmodus in en stuurt door naar het bericht.
• /api/exit-preview : Schakelt de previewmodus uit.

Configureer in je WordPress-thema of -plugin de voor de preview-URL (als je WPGraphQL JWT-authenticatie gebruikt) zodat deze verwijst naar https://your-nextjs-site.com/api/preview?secret=YOUR_SECRET&slug={slug} .

in getStaticProps of de previewmodus is ingeschakeld en haal de conceptinhoud op:

export async function getStaticProps({ params, preview, previewData }) { const authHeader = preview ? { Authorization: `Bearer ${previewData.token}` } : {}; const res = await fetch( `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/posts?slug=${params.slug}&status=draft`, { headers: authHeader } ); // ... }

Sitemaps en SEO-metadata maken in Next.js

Installeer het next-sitemap -pakket voor het automatisch genereren van sitemaps:

npm install next-sitemap

Maak een next-sitemap.config.js -bestand aan en configureer het om alle WordPress-postslugs op te nemen die tijdens het buildproces worden opgehaald. Voer next-sitemap als een postbuild-script in je package.json .

Voor SEO-metadata per pagina kunt u de next/head of, als u de App Router gebruikt, de ingebouwde Metadata API:

import Head from "next/head";<Head><title> {post.title.rendered} | Mijn blog </title><meta name="description" content="{post.excerpt.rendered}" /><meta property="og:title" content="{post.title.rendered}" /><meta property="og:image" content={featuredImageUrl} /></Head>

Gebruik de RankMath-plugin in WordPress en ontsluit de metadata ervan via WPGraphQL met de plugin 'Add WPGraphQL SEO'. Hierdoor kunnen redacteuren titels en beschrijvingen vanuit WordPress beheren, die Next.js vervolgens ophaalt en weergeeft.

Lees meer: ​​WordPress gebruiken als headless CMS

Cachestrategieën en SWR voor client-side fetching

Niet alle content hoeft statisch gegenereerd te worden. Gebruikersspecifieke data, reacties of realtime voorraadgegevens profiteren van ophalen aan de clientzijde. Gebruik hiervoor de swr- bibliotheek van Vercel:

npm install swr

import useSWR from "swr"; const fetcher = (url) => fetch(url).then((r) => r.json()); function Comments({ postId }) { const { data, error } = useSWR( `/wp-json/wp/v2/comments?post=${postId}`, fetcher ); if (error) return<p> Reacties konden niet worden geladen.</p> ; als (!data) retourneer<p> Laden...</p> ; opbrengst<ul> {data.map((c) =><li key={c.id}> {c.content.rendered}</li> )}</ul> ; }

SWR verzorgt automatisch caching, hervalidatie en deduplicatie. Het maakt gebruik van een 'stale-while-revalidate'-strategie: het retourneert direct de gecachede gegevens en haalt vervolgens op de achtergrond geruisloos de nieuwste gegevens op.

Implementatie-, prestatie- en beveiligingsrichtlijnen voor WordPress met Next.js

Implementeer je Next.js-frontend en WordPress-backend als aparte services. Deze scheiding is een van de belangrijkste voordelen van het headless-model.

Next.js-implementaties werken het beste op Vercel, het platform dat is ontwikkeld door het Next.js-team. Vercel biedt standaard edge caching

Netlify en AWS Amplify zijn prima alternatieven. Voor zelfgehoste implementaties kun je Next.js uitvoeren met `npm run build && npm start` achter een Nginx reverse proxy.

WordPress kan worden geïmplementeerd op elke standaard PHP-host ( WP Engine , Kinsta , SiteGround ) of een VPS. Omdat WordPress alleen API-reacties levert (en geen paginaweergaven), kan zelfs een bescheiden hostingpakket aanzienlijk verkeer aan.

Beveiligingsversterking voor headless WordPress:

• Verplaats je WordPress-installatie naar een niet-openbaar subdomein, zoals cms.jouwdomein.com .
• Schakel XML-RPC uit ( add_filter('xmlrpc_enabled', '__return_false'); ).
• Gebruik een webapplicatiefirewall (WAF) zoals Cloudflare.
• Beperk de toegang tot de WordPress REST API tot geauthenticeerde verzoeken voor gevoelige eindpunten.
• Zorg ervoor dat de WordPress-kern, thema's en plug-ins up-to-date zijn.
• Gebruik sterke applicatiewachtwoorden voor API-authenticatie.

Checklist voor prestatieoptimalisatie

• Schakel CDN-levering in voor uw statische Next.js-bestanden.
• Gebruik next/image voor alle afbeeldingen; dit automatisch responsieve formaten
• Minimaliseer client-side JavaScript door componenten waar mogelijk server-side te renderen.
• Stel de juiste HTTP-cacheheaders in voor API-reacties van WordPress.
• Gebruik een WordPress-objectcache (Redis of Memcached ) om databasequery's achter je API te versnellen.

Problemen met veelvoorkomende valkuilen in WordPress met een headless Next.js-configuratie oplossen

Overstappen naar een headless setup is lonend, maar vereist wel wat oefening. Hieronder vind je de meest voorkomende valkuilen en hoe je ze kunt oplossen:

• CORS-fouten tijdens de ontwikkeling: Uw browser blokkeert cross-origin-verzoeken van localhost:3000 naar uw WordPress-domein. Voeg CORS-headers toe aan WordPress via functions.php of gebruik de WP CORS-plugin. Sta origins toe voor zowel uw ontwikkel- als productiedomein van Next.js.

• Permalinks die een 404-foutmelding geven : De REST API vereist niet-plain permalinks. Ga naar Instellingen → Permalinks en sla alle niet-plain opties op, zelfs als u niets wijzigt. Hiermee worden de herschrijfregels vernieuwd.

• Afbeeldingen van WordPress worden geblokkeerd door Next.js: Next.js beperkt de toegang tot externe afbeeldingsdomeinen om veiligheidsredenen. Voeg uw WordPress-domein toe aan next.config.js :

module.exports = { images: { domains: ["your-wordpress-site.com"], }, };

• HTML-entiteiten in weergegeven content: De WordPress REST API retourneert titels met HTML-entiteiten zoals <title> en <title> . Gebruik een klein hulpprogramma om deze te decoderen, of installeer het html-entities .

• De build mislukt vanwege te veel API-verzoeken: Als u duizenden berichten hebt, kan het ophalen van alle slugs in getStaticPaths een time-out veroorzaken of de limieten voor het aantal verzoeken overschrijden. Pagineer uw verzoeken met behulp van de queryparameters page en per_page fallback: "blocking" om alleen uw meest recente berichten vooraf te renderen.

• GraphQL-schemafouten na pluginupdates: Het WPGraphQL-schema verandert wanneer u plugins toevoegt of verwijdert. Genereer uw Apollo-clientcache opnieuw of wis uw lokale schema-snapshot na wijzigingen in WordPress-plugins.

• Conceptberichten die in productie verschijnen: Als je status=any in je API-query's gebruikt, zorg er dan voor dat productiequery's alleen status=publish . Gebruik omgevingsspecifieke API-parameters om te voorkomen dat concepten publiekelijk verschijnen.

Conclusie

Door WordPress met Next.js te gebruiken, krijg je een schaalbare, SEO-vriendelijke headless architectuur die op bijna alle vlakken beter presteert dan traditionele WordPress.

Uw contentteam blijft de vertrouwde WordPress-editor gebruiken, terwijl uw ontwikkelteam bouwt met moderne React-tools.

De opzet is gebaseerd op drie componenten: WordPress als headless CMS , de REST API of WPGraphQL als datalaag en Next.js voor alle frontend-rendering en prestatieoptimalisatie.

Begin met de REST API, schakel over op WPGraphQL naarmate de complexiteit toeneemt, en voeg vervolgens ISR, previewmodus en on-demand hervalidatie toe naarmate uw site volwassener wordt. Implementeer uw Next.js-frontend op Vercel en WordPress op een dedicated PHP-host voor een schone, productieklare scheiding.

Deze combinatie is niet langer experimenteel. Het vormt de basis van grote publicatieplatformen, e-commercewebsites en bedrijfsapplicaties. De tools zijn volwassen, de community is actief en de prestatiewinsten zijn reëel. Nu is het juiste moment om te bouwen.

Veelgestelde vragen over WordPress met Next.js voor een headless website