Hur använder man WordPress med Next.js för en headless webbplats?

Moderna webbplatser kräver hastighet, flexibilitet och bergsolid SEO. En headless WordPress med Next.js levererar alla tre. Genom att separera ditt innehållshanteringssystem från ditt frontend låser du upp det bästa av två världar: WordPress välbekanta redigeringsupplevelse och Next.js blixtsnabba renderingsfunktioner.

Den här guiden guidar dig genom allt, från att förstå arkitekturen till att driftsätta en produktionsklar headless-webbplats.

Oavsett om du är en utvecklare som utforskar frikopplade CMS-inställningar eller ett team som vill modernisera en äldre WordPress-webbplats, har den här steg-för-steg-resursen det du behöver.

TL;DR: Bygg en snabb och skalbar headless webbplats

• Använd en frikopplad uppsättning för att separera innehållshanteringen från frontend för bättre flexibilitet.
• Hämta innehåll via REST API eller GraphQL för effektiv dataleverans.
• Förbättra prestandan med statisk generering, serverrendering och smart cachning.
• Implementera på moderna hostingplattformar och säkra API:er för hastighet, skalbarhet och skydd.

Vad är Headless WordPress och varför kombinera det med Next.js?

För att förstå kraften i den här stacken måste du först förstå konceptet med en "headless" arkitektur och varför dessa två specifika teknologier utgör ett så perfekt par.

Definiera Headless WordPress CMS-arkitektur

Traditionellt WordPress är ett monolitiskt system. Det hanterar innehållslagring, affärslogik och sidrendering på ett och samma ställe. När en besökare landar på din webbplats frågar WordPress databasen, bearbetar PHP-mallar och levererar en fullständigt renderad HTML-sida.

Headless WordPress bryter ner den modellen. I en headless-arkitektur:

• WordPress fungerar endast som backend. Det hanterar innehåll, användarautentisering och datalagring.

• Frontend-gränssnittet är helt separat. Ett JavaScript-ramverk som Next.js hanterar all rendering och användarinteraktion.

• Ett API förenar de två. WordPress exponerar innehåll via sitt REST API eller GraphQL-slutpunkt, och Next.js hämtar den informationen för att bygga sidor.

Termen ”headless” kommer från att man tagit bort ”head”, presentationslagret i frontend-gränssnittet, från WordPress.

Din WordPress-installation finns fortfarande kvar, redaktörer loggar fortfarande in på /wp-adminoch inlägg skapas fortfarande på samma sätt. Men besökare interagerar aldrig direkt med WordPress. De interagerar med ditt Next.js-gränssnitt.

Fördelar med att frikoppla backend från frontend

Att frikoppla din WordPress-backend från din frontend-arkitektur ger flera stora fördelar:

• Prestandaförbättringar: Next.js förrenderar sidor som statisk HTML vid byggtillfället. Det sker ingen PHP-bearbetning på varje begäran, vilket dramatiskt minskar tiden till första byte (TTFB).

• Frontend-frihet: Du kan bygga om eller designa om ditt frontend utan att röra WordPress. Byt ramverk, designa om layouter eller kör A/B-tester utan CMS-migreringar.

• Förbättrad säkerhet: Din WordPress-instans kan köras på en privat server eller en underdomän, dold från det offentliga internet. Angripare kan inte rikta in sig på wp-login.phpom de inte kan hitta den.

• Skalbarhet: Statiska sidor som serveras från ett CDN hanterar trafiktoppar utan problem. Din WordPress-server tar bara emot API-förfrågningar, inte sidinläsningar.

• Flerkanalig innehållsleverans: Samma WordPress-innehålls-API kan hantera en webbplats, en mobilapp, en röstassistent och en kiosk samtidigt.

• Bättre utvecklarupplevelse: Frontend-team arbetar med React- och JavaScript-verktyg som de redan känner till, utan att behöva lära sig PHP- eller WordPress-temautveckling.

Varför Next.js är idealiskt för Headless WordPress-prestanda och SEO?

Next.js sticker ut bland JavaScript-ramverk för headless CMS-projekt av flera anledningar.

• Server-Side Rendering (SSR) och statisk webbplatsgenerering (SSG) ger dig kontroll över när och hur sidor renderas. Du kan generera din blogg statiskt vid byggtid, serverrendera produktsidor som ändras ofta, eller blanda båda strategierna på din webbplats.

• Inbyggd bildoptimering via next/image- komponenten visar automatiskt bilder med korrekt storlek och WebP-formatering med lazy loading. Detta förbättrar direkt Core Web Vitals-poängen.

• Filbaserad routing gör dynamiska rutter enkla. Att skapa en [slug].js- fil i din sidkatalog hanterar automatiskt alla webbadresser till blogginlägg.

• Med API-rutter kan du lägga till logik på serversidan, som formulärbehandling eller webhook-hantering, direkt i ditt Next.js-projekt utan en separat backend.

• SEO-funktioner är inbyggda. Next.js renderar fullständig HTML på servern, så sökmotorernas crawlers får tillgång till komplett sidinnehåll utan att behöva vänta på att JavaScript ska köras. Kombinerat med metataggkomponenten next/head A håller du din webbplats SEO-konkurrenskraftig

REST API vs GraphQL med WordPress-innehållshämtning

WordPress erbjuder två API-metoder för headless-konfigurationer:

WordPress REST API levereras med WordPress-kärna. Inga ytterligare plugins krävs. Det exponerar slutpunkter: /wp-json/wp/v2/posts för inlägg och /wp-json/wp/v2/pages för sidor. Det är enkelt att använda fetch() och fungerar bra för enkla innehållsbehov.

WPGraphQL är ett plugin som lägger till en GraphQL-slutpunkt till WordPress. Istället för att få ett stort JSON- objekt med dussintals fält du inte behöver, skriver du en fråga som bara begär exakt de fält som ditt frontend kräver.

Detta minskar nyttolastens storlek, förenklar hämtning av kapslade data (t.ex. inlägg med deras kategorier och författaruppgifter i en enda begäran) och ger ditt frontend-team ett tydligt typat schema att arbeta med.

För små projekt eller team som inte är GraphQL-användare är REST API:et helt tillräckligt. För större webbplatser med komplexa innehållsrelationer levererar WPGraphQL vanligtvis bättre prestanda och en renare utvecklarupplevelse .

Förutsättningar för att bygga en headless-installation med WordPress och Next.js

Innan du skriver någon kod måste du etablera en solid grund och förbereda din miljö.

Nödvändiga verktyg och miljöinstallation

För att kunna följa med i en headless WordPress-installation behöver du följande verktyg installerade på din dator:

• Node.js (v18 eller senare): Ladda ner från nodejs.org. Kör node -v i din terminal för att bekräfta installationen.

• npm eller Yarn: npm levereras med Node.js. Yarn är valfritt men föredras av vissa team.

• En körande WordPress-installation: lokal (med LocalWP, MAMP eller Docker) eller en värdbaserad instans. Det enda kravet är att den är tillgänglig via HTTP.

• En kodredigerare: VS Code med tilläggen ESLint och Prettier ger dig den bästa Next.js-utvecklingsupplevelsen.

• Git: För versionskontroll och distributionsarbetsflöden.

För lokal WordPress-utveckling är LocalWP det snabbaste sättet att starta en WordPress-webbplats på din dator utan någon konfiguration.

Installera nödvändiga WordPress-plugins (WPGraphQL, REST API)

WordPress REST API är aktiverat som standard i alla moderna WordPress-installationer. Du kan kontrollera att det fungerar genom att besöka https://yoursite.com/wp-json/wp/v2/posts i din webbläsare.

För WPGraphQL:

• Logga in på din WordPress-instrumentpanel.

• Navigera till Plugins → Lägg till nytt.

• Sök efter WPGraphQL och installera pluginet av Jason Bahl.

• Aktivera den.

• Ett nytt GraphQL-menyalternativ visas i din instrumentpanel. Gå till GraphQL → Inställningar för att konfigurera slutpunkten.

Du kan också installera WPGraphQL för ACF om du använder Advanced Custom Fields, vilket exponerar anpassade fältdata genom ditt GraphQL-schema.

För att testa din GraphQL-slutpunkt, navigera till GraphQL → GraphiQL IDE i din instrumentpanel. Denna interaktiva lekplats låter dig skriva och testa frågor innan du använder dem i ditt Next.js-projekt.

WordPress API-konfiguration för headless delivery

Flera WordPress-inställningar påverkar leverans av headless API:er:

• Permalänkar: Gå till Inställningar → Permalänkar och välj något annat alternativ än "Vanligt". REST API fungerar inte korrekt med vanliga permalänkar. "Inläggsnamn" (/%postname%/) är det vanligaste valet.

• CORS-rubriker: Som standard kan WordPress REST API-svar blockera cross-origin-förfrågningar från din Next.js-utvecklingsserver. Lägg till CORS-rubriker i ditt WordPress-temas functions.php eller använd ett plugin som WP CORS för att tillåta förfrågningar från din Next.js-domän.

• Applikationslösenord: För privat innehåll eller utkastinnehåll stöder WordPress applikationslösenord (introducerades i WordPress 5.6). Generera ett i din användarprofil och inkludera det i dina API-förfrågningar som en Basic Auth-rubrik.

• Synlighet för offentligt innehåll: Se till att inlägg som du vill visa är publicerade, inte lösenordsskyddade eller privata.

Förstå grunderna i React och Next.js innan du börjar

Headless WordPress-utveckling med Next.js förutsätter förtrogenhet med:

• React-grunder: Komponenter, props, state och useEffect och useState .

• Metoder för rendering av Next.js-sidorna: Det är viktigt att förstå skillnaden mellan getStaticProps , getServerSideProps och getStaticPaths

• Async JavaScript: Du kommer att skriva asynkron datahämtningskod med hjälp av async/await Fetch API:et.

• JSX-syntax: Hur man skriver HTML-liknande syntax i JavaScript.

Om du inte har använt Next.js tidigare kommer det att löna sig att spendera några timmar med den officiella Next.js-handledningen på nextjs.org/learn innan du börjar med det här projektet.

Steg-för-steg-guide för att ansluta WordPress och Next.js

Nu när grunden är lagd, låt oss ansluta backend till frontend. Den här guiden använder Next.js Pages Router-paradigmet, vilket används flitigt för statiska bloggarkitekturer.

Steg 1: Skapa och konfigurera ett nytt Next.js-projekt

Öppna din terminal och skapa en ny Next.js-applikation med hjälp av verktyget create-next-app.

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

Installationsguiden frågar om du vill ha TypeScript, ESLint, Tailwind CSS och App Router. För den här guiden, välj Pages Router för maximal kompatibilitet med befintliga handledningar och plugins. TypeScript rekommenderas för större projekt.

Skapa sedan en .env.local -fil i din projektrot för att lagra din WordPress-URL:

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

Använd aldrig versionshantering för den här filen. Lägg till .env.local i din .gitignore.

Steg 2: Hämta WordPress-data med REST API och getStaticProps

Skapa en fil på pages/blog/index.js. Den här sidan listar alla blogginlägg som hämtats från WordPress REST API:

exportera standardfunktionen BlogIndex({ inlägg }) { returnera (}<ul> {inlägg.karta((inlägg) => (<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}/inlägg?_embed&per_page=100` ); const inlägg = await res.json(); return { props: {inlägg }, revalidate: 60, }; }  Behöver du en post som ska användas för att exportera den?

getStaticProps körs vid byggtid på servern. Den hämtar inlägg från WordPress och skickar dem som props till din komponent. Denna revalidering: 60 aktiverar stegvis statisk regenerering, vilket behandlas i det avancerade avsnittet.

Steg 3: Använda WPGraphQL med Apollo- eller GraphQL-klienten

För en mer skalbar metod, använd WPGraphQL. Installera först en lättviktig GraphQL-klient i ditt Next.js-projekt.

npm-installation @apollo/klient graphql

Skapa en verktygsfil på 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;   Välj standardklient för att exportera den

Fråga sedan WordPress-inlägg med GraphQL i getStaticProps:

importera klient från "../../lib/apolloClient"; import { gql } från "@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, }; }  Behöver du en specifik fil? Behöver du en specifik fil?

Den här metoden hämtar endast de fält som ditt frontend använder, vilket håller API-svaren rena.

Steg 4: Dynamiska rutter och statisk generering för bloggsidor

För att skapa individuella sidor för varje blogginlägg behöver du använda dynamisk routing. I Next.js skapar du en fil [slug].js i en pages/posts/ -katalog.

Du kommer att använda getStaticPaths för att ange för Next.js vilka URL:er som ska byggas, och getStaticProps för att hämta det specifika innehållet för varje URL.

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 };   Behöver du detta alternativ? Behöver du detta alternativ? Behöver du detta alternativ? } return { props: { post: inlägg[0] }, revalidate: 60, }; }

getStaticPaths talar om för Next.js vilka slugs som ska förrenderas. Att ställa in fallback: "blocking" innebär att alla slugs som inte finns i den initiala versionen renderas av servern vid den första begäran och sedan cachas som en statisk sida.

Steg 5: Hantera inläggsinnehåll, bilder och anpassade fält

WordPress lagrar inläggets brödtext som rå HTML. Rendera det säkert med Reacts dangerouslySetInnerHTML:

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

För utvalda bilder, använd _embed i REST API-förfrågningar. Få åtkomst till bildens URL via post._embedded['wp:featuredmedia'][0].source_url.

Slå in det med Next.js Image- komponent för automatisk optimering:

importera bild från "nästa/bild"; <Image src={post._embedded["wp:featuredmedia"][0].source_url} alt={post.title.rendered} width={1200} height={630} />

För avancerade anpassade fält, aktivera pluginet WPGraphQL för ACF. Anpassade fältdata visas då i ditt GraphQL-schema och kan efterfrågas tillsammans med standardpostdata.

Avancerade tekniker för Headless WordPress och Next.js

När grunderna fungerar kan du implementera avancerade funktioner för att få din webbplats att kännas som en applikation i företagsklass.

Optimera med stegvis statisk regenerering (ISR)

Med ISR kan du uppdatera statiskt genererade sidor efter driftsättning utan att behöva bygga om hela webbplatsen. Hur du konfigurerar det beror på vilken Next.js-router du använder, och att blanda ihop de två är en vanlig källa till buggar.

Sidorouter ISR (tidsbaserad)

Lägg till ett revalidate- värde (i sekunder) till din getStaticProps- retur:

return { props: { post }, revalidate: 300, // Regenerera var 5:e minut };

När en användare besöker en sida efter att omvalideringsfönstret har löpt ut, hanterar Next.js den cachade sidan omedelbart samtidigt som den återgenereras i bakgrunden. Nästa besökare får den nya versionen.

Sidorouter ISR (på begäran)

För omvalidering på begäran som utlöses av en WordPress-publicerings- eller uppdateringshändelse, skapa en API-rutt på pages/api/revalidate.js. WordPress anropar denna rutt via en webhook:

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

res.revalidate() är den korrekta Pages Router-metoden. Den utlöser en omedelbar bakgrundsregenerering för den specifika sökvägen utan att vänta på att det tidsbaserade fönstret ska löpa ut.

App-routerns ISR

Om du använder App Router (app/ directory) istället för Pages Router är syntaxen annorlunda. Tidsbaserad omvalidering är inställd som en export av ruttsegmentkonfiguration:

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

Omvalidering på begäran i approutern använder revalidatePath() eller revalidateTag(), importerad från next/cache, inuti en serveråtgärd eller rutthanterare, inte inuti en API-rutt:

// 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: "Ogiltig token" }, { status: 401 }); } revalidatePath(`/blog/${slug}`); return NextResponse.json({ revalidated: true }); }  Behöver du en specifik kod? Behöver du en specifik kod?

Viktig skillnad: res.revalidate() tillhör Pages Router. revalidatePath() och revalidateTag() tillhör App Router. Att använda App Router-metoder i ett Pages Router-projekt, eller vice versa, kommer att orsaka tysta fel eller körtidsfel. Matcha metoden med den router du faktiskt använder.

Den här guidens steg-för-steg-avsnitt använder Pages Router genomgående. Om du migrerar till App Router i framtiden, uppdatera all ISR-logik för att använda revalidatePath() i Route Handlers i enlighet därmed.

Lägger till förhandsgranskningsläge för utkastinnehåll

Förhandsgranskningsläget låter redaktörer se utkast till WordPress-innehåll på ditt Next.js-gränssnitt innan de publiceras. Konfigurera två API-rutter:

• /api/preview: Aktiverar förhandsgranskningsläge och omdirigerar till inlägget.
• /api/exit-preview: Inaktiverar förhandsgranskningsläget.

I ditt WordPress-tema eller plugin konfigurerar du för förhandsgransknings-URL (om du använder WPGraphQL JWT-autentisering) så att den pekar på https://your-nextjs-site.com/api/preview?secret=YOUR_SECRET&slug={slug}.

I getStaticProps, kontrollera förhandsgranskningsläge och hämta utkastinnehåll:

export async function getStaticProps({ params, preview, previewData }) { const authHeader = preview ? { Auktorisering: `Bearer ${previewData.token}` } : {}; const res = await fetch( `${process.env.NEXT_PUBLIC_WORDPRESS_API_URL}/posts?slug=${params.slug}&status=draft`, { headers: authHeader } ); // ... }  Behöver du en authHeader för att exportera async-funktionen?

Skapa webbplatskartor och SEO-metadata i Next.js

Installera next-sitemap -paketet för automatisk generering av webbplatskartor:

npm installera nästa webbplatskarta

Skapa en next-sitemap.config.js -fil och konfigurera den så att den inkluderar alla WordPress-inläggsslugs som hämtats vid byggtillfället. Kör next-sitemap som ett postbuild-skript i din package.json.

För SEO-metadata per sida, använd next/head- komponenten eller, om du använder App Router, det inbyggda Metadata API:et:

importera Head från "nästa/head";<Head><title> {post.title.rendered} | Min blogg </title><meta name="description" content="{post.excerpt.rendered}" /><meta property="og:title" content="{post.title.rendered}" /><meta property="og:image" content={featuredImageUrl} /></Head>

Använd RankMath-pluginet i WordPress och exponera dess metadata via WPGraphQL med pluginet Lägg till WPGraphQL SEO. Detta låter redaktörer kontrollera titlar och beskrivningar från WordPress, som Next.js hämtar och renderar.

Läs mer: Använda WordPress som ett Headless CMS

Cachningsstrategier och SWR för klientsidans hämtning

Allt innehåll behöver inte genereras statiskt. Användarspecifik data, kommentarer eller realtidsinventering drar nytta av hämtning på klientsidan. Använd swr -biblioteket från Vercel:

npm installera swr

importera useSWR från "swr"; const fetcher = (url) => fetch(url).then((r) => r.json()); function Kommentarer({ postId }) { const { data, error } = useSWR(`/wp-json/wp/v2/comments?post=${postId}`, fetcher ); if (error) returnera<p> Det gick inte att läsa in kommentarer.</p> ; om (!data) returnerar<p> Belastning...</p> återvända<ul> {data.map((c) =><li key={c.id}> {c.innehåll.renderat}</li> )}</ul> ; }

SWR hanterar cachning, omvalidering och deduplicering automatiskt. Den använder en "stale-while-revalidate"-strategi: den returnerar cachade data omedelbart och hämtar sedan tyst nya data i bakgrunden.

Bästa praxis för implementering, prestanda och säkerhet för WordPress med Next.js

Distribuera ditt Next.js-frontend och WordPress-backend som separata tjänster. Denna separation är en av de viktigaste fördelarna med headless-modellen.

Next.js-distributionen fungerar bäst på Vercel, plattformen som byggts av Next.js-teamet. Vercel hanterar ISR, edge caching, bildoptimering och hantering av miljövariabler direkt ur lådan.

Netlify och AWS Amplify är bra alternativ. För självhostade distributioner, kör Next.js med npm run build && npm start bakom en Nginx reverse proxy.

WordPress-distribution kan köras på vilken standard PHP-värd som helst (WP Engine, Kinsta, SiteGround) eller en VPS. Eftersom WordPress bara hanterar API-svar (inte sidvisningar) hanterar även en måttlig hosting betydande trafik.

Säkerhetshärdning för headless WordPress:

• Flytta din WordPress-installation till en icke-offentlig underdomän som cms.dindomän.com.
• Inaktivera XML-RPC (add_filter('xmlrpc_enabled', '__return_false');).
• Använd en webbapplikationsbrandvägg (WAF) som Cloudflare.
• Begränsa WordPress REST API till autentiserade förfrågningar för känsliga slutpunkter.
• Håll WordPress kärna, teman och plugins uppdaterade.
• Använd starka applikationslösenord för API-autentisering.

Checklista för prestandaoptimering :

• Aktivera CDN-leverans för dina statiska Next.js-tillgångar.
• Använd next/image för alla bilder, det genererar responsiva storlekar och hanterar WebP automatiskt.
• Minimera JavaScript på klientsidan genom att hålla komponenterna serverrenderade där det är möjligt.
• Ställ in lämpliga HTTP-cacherubriker på WordPress API-svar.
• Använd en WordPress-objektcache (Redis eller Memcached) för att snabba upp databasfrågor bakom ditt API.

Felsökning av vanliga fallgropar i WordPress med Next.js Headless-installation

Att övergå till en headless-installation är givande men det innebär en inlärningskurva. Här är de vanligaste hindren och hur man åtgärdar dem:

• CORS-fel under utveckling: Din webbläsare blockerar cross-origin-förfrågningar från localhost:3000 till din WordPress-domän. Lägg till CORS-rubriker till WordPress via functions.php eller använd WP CORS-pluginet. Tillåt ursprung för både dina Next.js-domäner för utveckling och produktion.

• Permalänkar som returnerar 404: REST API kräver icke-enkla permalänkar. Gå till Inställningar → Permalänkar och spara alla icke-enkla alternativ, även om du inte ändrar något. Detta rensar omskrivningsreglerna.

• Bilder från WordPress blockerade av Next.js: Next.js begränsar åtkomst till externa bilddomäner av säkerhetsskäl. Lägg till din WordPress-domän till next.config.js:

module.exports = { bilder: { domäner: ["din-wordpress-webbplats.com"], }, };

• HTML-entiteter i renderat innehåll: WordPress REST API returnerar titlar med HTML-entiteter som &. Använd ett litet verktyg för att avkoda dem, eller installera html-entities npm-paketet.

• Byggandet misslyckas på grund av för många API-förfrågningar: Om du har tusentals inlägg kan det leda till tidsgränser eller att frekvensen når gränserna för att hämta alla slugs i getStaticPaths . Paginera dina förfrågningar med hjälp av frågeparametrarna page och per_page , eller använd fallback: "blocking" och förrendera bara dina senaste inlägg.

• GraphQL-schemafel efter plugin-uppdateringar: WPGraphQL-schemat ändras när du lägger till eller tar bort plugins. Återskapa din Apollo-klientcache eller rensa din lokala schema-ögonblicksbild efter ändringar i WordPress-pluginet.

• Utkast till inlägg som visas i produktion: Om du använder status=any i dina API-frågor under utveckling, se till att produktionsfrågor endast begär status=publish. Använd miljöspecifika API-parametrar för att förhindra att utkast visas offentligt.

Slutsats

Att använda WordPress med Next.js ger dig en skalbar, SEO-vänlig headless-arkitektur som överträffar traditionell WordPress på nästan alla mätvärden.

Ert innehållsteam behåller den välbekanta WordPress-redigeraren medan ert utvecklingsteam bygger med moderna React-verktyg.

Installationen bygger på tre komponenter: WordPress som headless CMS, REST API eller WPGraphQL som datalager, och Next.js som hanterar all frontend-rendering och prestandaoptimering.

Börja med REST API:et, implementera WPGraphQL allt eftersom komplexiteten ökar, och lägg sedan till lager av ISR, förhandsgranskningsläge och on-demand-validering allt eftersom din webbplats mognar. Distribuera ditt Next.js-gränssnitt till Vercel och WordPress till en dedikerad PHP-värd för en ren, produktionsklar separation.

Den här kombinationen är inte längre experimentell. Den driver stora publiceringsplattformar, e-handelssajter och företagsapplikationer. Verktygen är mogna, communityn är aktiv och prestandavinsterna är verkliga. Nu är det rätt tid att bygga.

Vanliga frågor om WordPress med Next.js för en headless-webbplats