WordPress Headless CMS: Udviklerens guide [2026]

WordPress Headless CMS: Udviklerens guide [2026]

WordPress driver 43 % af alle websites ifølge W3Techs, og et stigende antal teams fjerner PHP-frontendet helt og bruger det i stedet som en content-API. Her er alt, hvad du behøver at vide om at køre WordPress headless – fra valget mellem REST API og WPGraphQL til deploy af en Next.js-frontend på Vercel med ISR.

Hvad er Headless WordPress? (Og hvorfor bør du bekymre dig?)

Headless WordPress er en opsætning, hvor WordPress håndterer indholdsadministration og lagring, mens en separat frontend-applikation – bygget med Next.js, Nuxt, Astro eller et andet framework – henter dette indhold via en API. WordPress beholder sit admin-dashboard, editor, plugin-økosystem og MySQL-database. Men i stedet for at rendere sider med PHP-temaer eksponerer det indhold via WordPress REST API eller WPGraphQL, og din frontend overtager præsentationslaget fuldstændigt.

Tænk på det sådan her: WordPress bliver køkkenet, og dit frontend-framework er restauranten. Køkkenet tilbereder maden (indholdet), men restauranten bestemmer, hvordan det anrettes, hvordan spisesalen ser ud, og hvordan gæsterne oplever måltidet.

Traditionel vs. Headless-arkitektur

I traditionel WordPress er alt en monolit. En besøgende anmoder om en side, PHP behandler anmodningen, spørger MySQL, kører det gennem temaets skabelonfiler og sender renderet HTML tilbage. Temaet styrer layout, styling, routing – alt.

I headless WordPress fjerner du hele dette renderingslag. WordPress sidder bag en API, typisk på managed hosting som WP Engine eller Kinsta. Din frontend – en React-, Vue- eller Svelte-app – laver API-anmodninger for at hente indhold og renderer det derefter, præcis som du ønsker. De to systemer kan leve på helt forskellige servere, med forskellige tech-stacks og forskellige deployments-pipelines.

Der er en nuance her, som 9 ud af 10 guider overser: decoupled og headless er ikke helt det samme. Decoupled WordPress kan stadig falde tilbage til PHP-rendering for visse sider (som admin-området eller legacy-ruter). Fuldt headless betyder, at WordPress-frontendet er helt deaktiveret; det er kun API, ingen tema-rendering overhovedet. I denne guide taler vi om den fuldt headless-tilgang.

Hvornår skal man gå headless (og hvornår skal man blive traditionel)?

Det giver mening at gå headless, når dit team har frontend-udviklere, der gerne vil arbejde med moderne værktøjer, når du skal levere indhold på tværs af flere kanaler (web, mobilapp, digitale skærme), eller når performance er ikke-forhandlingsbar. Det giver ikke mening for alle, og ved at være ærlig omkring det sparer du uger med spildt indsats.

Gå headless, når...

• Dit team allerede kender React/Vue/Svelte. Hvis dine frontend-udviklere skriver JSX hele dagen, føles det som at bede en kok om at lave mad i en mikrobølgeovn at tvinge dem ind i PHP-temaer.
• Du har brug for levering på tværs af kanaler. Én WordPress-backend kan fodre dit marketing-site, din mobilapp og din in-store kiosk gennem den samme API.
• Performance er et hårdt krav. Statiske sider serveret fra en CDN-edge vil altid slå PHP-rendering på en delt server.
• Du kører headless WooCommerce. Komplekse e-commerce-frontends drager enorm fordel af skræddersyede React/Next.js-butiksfrontends.
• Du vil have den moderne DX. Hot module replacement, TypeScript, komponentbiblioteker, CI/CD – hele frontend-værktøjskæden.

Bliv traditionel, når...

• Indholdsredaktører har brug for live preview og page builders. Gutenberg, Elementor og WPBakery antager et traditionelt tema. At gå headless dræber de fleste visuelle redigeringsworkflows.
• Du er solo-udvikler eller et lille team. Headless tilføjer 40-60 % kompleksitet i opsætningen. Hvis det bare er dig, der vedligeholder en blog, er et traditionelt tema simplere.
• Du er stærkt afhængig af frontend-plugins. Kontaktformularer, SEO-plugins (Yoast renderer meta-tags server-side), cookie-samtykke-bannere – alle disse antager PHP-rendering.
• Budgettet er stramt. Du får brug for separat hosting til WordPress og din frontend. Det er to regninger i stedet for én.

REST API vs. WPGraphQL: Valg af datalag

WordPress giver dig to måder at hente indhold på i en headless-opsætning: den indbyggede REST API og WPGraphQL-pluginnet. REST API følger med WordPress-core og virker out of the box uden behov for plugins. WPGraphQL kræver installation af et plugin, men lader dig query nøjagtigt de felter, du har brug for, hvilket eliminerer problemet med over-fetching, der plager REST. Efter vores erfaring vinder WPGraphQL til de fleste projekter, men REST har én undervurderet fordel: native HTTP-caching.

WordPress REST API: Den indbyggede mulighed

REST API er tilgængelig på enhver WordPress-installation siden version 4.7 (december 2016). Ram /wp-json/wp/v2/posts, og du får JSON tilbage. Simpelt, veldokumenteret og det virker uden konfiguration.

Ulempen? Over-fetching. Når du anmoder om et indlæg, returnerer WordPress alt: renderet indhold, raw-indhold, uddrag, forfatter-ID, featured media-ID, kategorier, tags, meta-felter, GUID, kommentarstatus, ping-status, skabelon og cirka 15 andre felter, du sandsynligvis ikke har brug for. Til en blog-listeside, hvor du kun har brug for titler, slugs og uddrag, overfører du 3-5 gange mere data end nødvendigt.

// REST API: Fetch 5 recent posts with author and categories
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// The _embed parameter includes author and category objects
// But also includes EVERY field on each post -- ~8KB per post
// For 5 posts, you're looking at ~40KB of JSON

Du kan bruge parameteren _fields til at begrænse, hvilke felter der returneres (?_fields=id,title,slug,excerpt), men det hjælper ikke med indlejrede ressourcer, og du vil stadig skulle lave flere anmodninger, hvis du har brug for relaterede data.

WPGraphQL: Query det, du har brug for

WPGraphQL er et gratis open source-plugin af Jason Bahl (nu vedligeholdt af WP Engine), der tilføjer en fuld GraphQL-API til WordPress. Du skriver en query, der specificerer præcis, hvilke felter du ønsker, og du får nøjagtigt det tilbage – ikke mere.

# WPGraphQL: Same query -- 5 recent posts with author and categories
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Response: ~2KB of precisely structured JSON
# No extra fields, no bloat

Side-om-side kode-sammenligning

Her er, hvad response-payloads faktisk ser ud som:

Hvilken skal du vælge?

Brug REST, når du bygger noget hurtigt, dit team ikke kender GraphQL, eller du har brug for aggressiv HTTP-caching uden ekstra værktøjer.

Brug WPGraphQL, når du bygger en produktions-frontend med komplekse databehov, du ønsker mindre payloads, eller dit team allerede bruger GraphQL andre steder.

Klar dom: Til et seriøst headless WordPress-projekt med Next.js er WPGraphQL det bedre valg. Besparelsen på payload, developer experience med GraphiQL IDE og data-hentning i en enkelt anmodning gør plugin-afhængigheden det værd.

Opsætning af WordPress som Headless CMS

Opsætning af WordPress som headless CMS tager seks trin: installer WordPress, tilføj de rigtige plugins, konfigurer din indholdsmodel, deaktivér frontend-temaet, opsæt godkendelse, og verificér, at din API virker. Hele processen tager cirka 30-45 minutter, hvis du har gjort det før, eller et par timer første gang.

Trin 1: Start med en frisk WordPress-installation på managed hosting. Kinsta, WP Engine og Cloudways tilbyder alle miljøer optimeret til WordPress. Hvis du bare eksperimenterer, virker en lokal installation med LocalWP fint også.

Trin 2: Installer de essentielle plugins:

Trin 3: Opret din indholdsmodel med ACF. Definer feltgrupper, der mapper til dine frontend-komponenter. En portfolio-posttype kan have felter for projectUrl, techStack (repeater), clientName og projectYear.

Essentielle plugins

WPGraphQL for ACF fortjener særlig opmærksomhed. Uden det vil dine ACF-felter ikke appear i GraphQL-queries. Efter installation kan du query custom fields sådan her:

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

Deaktivering af WordPress-frontend

Trin 4: Du vil ikke have, at besøgende rammer din WordPress-URL og ser et ødelagt tema. Tilføj dette til dit temas functions.php eller brug et mu-plugin:

// Redirect all frontend requests to the 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;
    }
});

Trin 5: Opsæt Application Passwords til godkendelse. Gå til Brugere > Din profil > Application Passwords, generér en adgangskode, og brug den til autentificerede API-anmodninger (oprettelse/opdatering af indhold fra eksterne værktøjer).

Test af din API

Trin 6: Åbn din browser og ram https://your-site.com/graphql; du bør se GraphiQL IDE. Prøv at query dine indlæg. Hvis du bruger REST, navigér til https://your-site.com/wp-json/wp/v2/posts og verificér, at du får JSON tilbage.

Pro tip: GraphiQL IDE, der følger med WPGraphQL, er virkelig fremragende til at udforske dit schema. Du får autocomplete, dokumentation og query-historik. Det er den hurtigste måde at finde ud af, hvilke felter der er tilgængelige, og hvordan dine ACF-data er struktureret.

Bygning af en Next.js-frontend med WPGraphQL

Den reneste måde at bygge en headless WordPress-frontend i 2026 er med Next.js 15's App Router og React Server Components. Server Components henter data på serveren uden at sende JavaScript til klienten, og WPGraphQL giver dig præcise queries – det er en naturlig kombination. Da jeg første gang satte WPGraphQL op med Next.js App Router, var den største faldgrube billedehåndtering, men det kommer vi til.

Projektopsætning og miljøvariabler

Start med et friskt Next.js-projekt. Vercel tilbyder også en officiel WordPress starter-skabelon, hvis du vil have en referencearkitektur.

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

Opret .env.local med dine WordPress-endpoints:

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

Opret nu et letvægts GraphQL fetch-værktøj. Du behøver ikke Apollo eller urql til Server Components; almindelig fetch virker perfekt, fordi der ikke er nogen client-side state at administrere:

// 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: revalidate every hour
  });

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

For valg af React-framework, tjek vores sammenligning af Next.js vs. plain React med Vite; der er gyldige grunde til at springe frameworket over, selvom den indbyggede SSR og ISR gør Next.js til det praktiske valg til headless CMS-arbejde. Og hvis du overvejer Next.js kontra Remix, breaker vi det ned i vores indlæg om hvorfor vi anbefaler Next.js til de fleste projekter.

Hentning af indlæg med Server Components

Her er blog-listesiden som en Server Component – ingen useEffect, ingen loading-states, ingen 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>
  );
}

Dynamiske indlægssider

Individuelle indlægssider bruger generateStaticParams til at pre-rendre alle indlæg ved build-time, hvorefter ISR henter nyt indhold:

// 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>
  );
}

Glem ikke at konfigurere next.config.ts til WordPress-billeder:

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

export default nextConfig;

Deploy af Headless WordPress til produktion

En produktionsklar headless WordPress-opsætning bruger dual hosting: WordPress lever på managed WordPress-hosting (WP Engine, Kinsta eller Cloudways), mens Next.js-frontendet deployes til en edge-platform som Vercel eller Netlify. Denne adskillelse betyder, at hvert lag kan scale uafhængigt; WordPress håndterer indholdsredigering og API-anmodninger, mens frontendet serverer statiske og ISR-sider fra CDN-edge-noder verden over.

Hosting-arkitektur

Dataflowet ser sådan ud: indholdsredaktører publicerer i WordPress-admin, WordPress gemmer indhold i MySQL, Next.js-frontendet henter indhold via WPGraphQL, Vercel genererer statisk HTML ved edgen, og besøgende rammer CDN'en uden nogensinde at røre WordPress direkte.

Til frontend-hosting, tjek vores Vercel vs. Netlify-sammenligning for en detaljeret gennemgang. Begge virker godt til headless WordPress. Hvis du overvejer container-baserede alternativer, dækker vores Railway, Render og Fly.io-sammenligning også disse muligheder.

ISR og On-Demand Revalidation

Dette er den del, der gør headless WordPress faktisk levedygtigt i produktion. Vi har fundet ud af, at on-demand revalidation er indsatsen værd, fordi du uden den sidder fast med valget mellem forældet indhold (lange revalideringsintervaller) og langsomme builds (korte intervaller, der hammer din WordPress-API).

ISR lader dig sætte en revalidate-tid på hver side. Efter det interval får den næste besøgende den cachede side, mens Next.js regenererer den i baggrunden. Men den rigtige magi er on-demand revalidation, der udløser en rebuild, så snart indhold publiceres:

// 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'); // Also revalidate the listing page
  }

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

På WordPress-siden skal du tilføje en webhook, der fyres ved publish_post ved hjælp af et plugin som WP Webhooks eller et simpelt functions.php-snippet, der kalder dit Vercel /api/revalidate-endpoint. Nu går indhold live inden for sekunder efter, du har trykket på "Publicér" – ingen fulde rebuilds, ingen ventetid. Se Next.js ISR-dokumentationen for flere konfigurationsmuligheder.

Omkostningsoversigt

WordPress Headless vs. Specialbygget Headless CMS

Efter at have arbejdet med både headless WordPress og specialbyggede CMS'er som Sanity, Contentful og Strapi, er her min ærlige vurdering: Headless WordPress er et pragmatisk valg, når du har et eksisterende WordPress-site eller indholdsteam. Det er sjældent det bedste valg, når man starter fra bunden.

Hvor headless WordPress vinder

• Indholdsredaktører kender det allerede. WordPress' admin-UI har 20 års forfinelse. Det tager uger at træne et ikke-teknisk team på Sanity Studio eller Contentfuls interface.
• Plugin-økosystem. 60.000+ plugins. Har du brug for flersproget support? WPML. E-commerce? WooCommerce. SEO-indholdsanalyse? Yoast (virker stadig i admin). Ingen specialbygget CMS matcher denne bredde.
• Rekruttering. WordPress har det største udvikler-talentpool af ethvert CMS. Det er dramatisk nemmere at finde en WordPress-udvikler end en Sanity- eller Payload-specialist.
• WooCommerce. Hvis du har brug for headless e-commerce med WordPress-indhold, er WooCommerce + WPGraphQL en bevist stack. Saleor og Medusa er alternativer, men WooCommerce har markedsandelen.

Hvor specialbyggede CMS'er vinder

• Indholdsmodellering. Sanitys GROQ, Contentfuls indholdstyper og Payloads TypeScript-schema er designet til struktureret indhold fra grunden. WordPress' post/page/custom-post-type-model føles som en eftermontering.
• Real-time samarbejde. Sanity har Google Docs-agtig real-time-redigering. Contentful har live-samarbejde. WordPress? Du får en låseskærm med beskeden "Dette indlæg redigeres af en anden".
• API-first arkitektur. WPGraphQL er genialt, men det er stadig et plugin, der sidder oven på en PHP-monolit. Contentfuls API og Sanitys API blev designet API-first fra dag ét.
• Mediehåndtering. WordPress mediebibliotek er funktionelt, men basalt. Sanitys billedpipeline med automatiske beskæringer, hotspots og CDN-levering er i en anden klasse. Contentful og Storyblok integrerer nativt med Cloudinary.
• Developer experience. Strapi og Payload giver dig en lokal dev-experience med hot-reload ved schema-ændringer. WordPress kræver opdatering af admin og kørsel af database-migrationer.

Dom: Hvilken skal du vælge?

Brug headless WordPress, når: du har et eksisterende WordPress-site med års indhold, dine redaktører nægter at lære et nyt CMS, du har brug for WooCommerce, eller du har brug for et specifikt WordPress-plugin, der ikke har nogen modpart andetsteds.

Vælg et specialbygget headless CMS, når: du starter et nyt projekt fra bunden, du har brug for real-time-samarbejde, din indholdsmodel er kompleks og struktureret, eller dit team værdsætter developer experience højere end plugin-bredde.

Hos Techsy har vi bygget headless WordPress-frontends for kunder, der migrerer fra traditionel WordPress. Vores typiske tilgang: WPGraphQL + Next.js App Router på Vercel med ISR til performance og on-demand revalidation til indholdsfriskhed. Få en gratis konsultation ->

WordPress MCP og Abilities API: AI-fremtiden

WordPress 6.9 introducerede Abilities API, som merger ind i WordPress 7.0-core (april 2026). Det skaber en standardiseret, typed og discoverable interface til WordPress-funktionalitet – tænk på det som WordPress, der eksponerer sine capabilities i et maskinlæsbart format, som AI-værktøjer kan forstå og bruge.

WordPress MCP Adapter brogger denne Abilities API til Model Context Protocol (MCP), den åbne standard for at forbinde AI-systemer med eksterne værktøjer. Hvad betyder dette egentlig? AI-agenter i Claude, Cursor eller VS Code kan nu opdage, hvad dit WordPress-site kan gøre, og derefter udføre disse handlinger direkte.

Her er et praktisk scenarie: Claude kan oprette et WordPress-indlæg, udfylde ACF-felter med strukturerede data, tildele kategorier, sætte et featured image og udløse din Vercel-revaliderings-webhook – alt sammen i én samtale. Ingen browser, intet admin-panel, ingen copy-paste.

Dette er i en tidlig fase, og MCP-adapteren udvikler sig stadig. Men det signalerer noget vigtigt: WordPress sidder ikke stille, mens specialbyggede headless CMS'er innoverer. Kombinationen af Abilities API + MCP kunne gøre WordPress til en af de mest AI-tilgængelige CMS'er på markedet ved at bruge sit massive plugin-økosystem på måder, som nyere, mindre platforme ikke kan matche. Læs den officielle meddelelse på WordPress Developer Blog for de fulde tekniske detaljer.

Performance: Headless WordPress vs. Traditionel WordPress

Headless WordPress med en statisk frontend forbedrer performance dramatisk sammenlignet med traditionel PHP-renderet WordPress. Traditionel WordPress serverer dynamiske sider ved at køre PHP ved hver anmodning, hvilket resulterer i dårlig Time to First Byte (TTFB). Ifølge performancedata fra midten af 2025 ser kun 31 % af desktop WordPress-klienter og 24 % på mobile gode TTFB-scorer. At gå headless med Next.js og ISR betyder, at sider er pre-renderet og serveret fra CDN-edge-noder, hvilket sænker TTFB til under 100 ms for cachede sider.

WP Engines case study om Android Authority viste en 6x forbedring i Lighthouse-performance-scorer efter migration til headless WordPress. Core Web Vitals-data fortæller en lignende historie: kun 45 % af WordPress-sites består alle tre CWV-metrics på mobile, sammenlignet med 65 % for Shopify og 83 % for Duda.

En vigtig forbehold: headless løser ikke en langsom WordPress-backend. Hvis din WordPress-API tager 3 sekunder at svare, fordi du er på billig shared hosting med 40 plugins, vil din ISR-regenerering også være langsom. Frontendet kan ikke være hurtigere end den API, det afhænger af. Invester i kvalitets-managed hosting; det betyder mere i en headless-opsætning, ikke mindre. WordPress Performance Lead Weston Ruters blog har fremragende data om, hvad der faktisk flytter nålen for WordPress-serverperformance.

FAQ

Hvad er headless WordPress?

Headless WordPress er en arkitektur, hvor WordPress kun fungerer som backend til indholdsadministration, med dets PHP-frontend-tema helt deaktiveret. Indhold leveres gennem REST API eller WPGraphQL til en separat frontend-applikation bygget med frameworks som Next.js, Nuxt eller Astro. WordPress-admin-dashboardet forbliver fuldt funktionelt for indholdsredaktører.

Er WordPress godt som headless CMS?

WordPress fungerer godt som headless CMS, når du har et eksisterende WordPress-site, indholdsredaktører, der kender interfacet, eller har brug for plugin-økosystemet (især WooCommerce). Det er mindre ideelt end specialbyggede headless CMS'er som Sanity eller Contentful, når man starter fra bunden, fordi WordPress' indholdsmodellering og API blev eftermonteret snarere end bygget API-first.

Hvad er ulemperne ved headless WordPress?

De største ulemper er: øget kompleksitet (to hosting-miljøer i stedet for ét), tab af visuel redigering og page builder-funktionalitet, frontend-plugins holder op med at virke (Yoast meta-rendering, kontaktformularer, cookie-bannere), intet real-time indholdssamarbejde, og GraphQL-API'en er en plugin-afhængighed snarere end core-funktionalitet. Budgettet stiger også, da du betaler for både WordPress-hosting og frontend-hosting.

Hvordan forbinder jeg Next.js til WordPress?

Installer WPGraphQL på dit WordPress-site, og opret derefter et Next.js-projekt med App Router. Sæt dit WordPress GraphQL-endpoint som en miljøvariabel, skriv en simpel fetch-baseret GraphQL utility-funktion, og brug den i Server Components til at query indlæg, sider og custom content types. Ingen Apollo eller urql nødvendig; almindelig fetch virker, fordi Server Components kører på serveren.

WPGraphQL vs. REST API, hvilken er bedre?

WPGraphQL er bedre til produktions-frontends, fordi det kun returnerer de felter, du anmoder om (reducerer payload-størrelsen med 60-80 %), understøtter nestede queries i en enkelt anmodning og giver en GraphiQL IDE til schema-udforskning. REST API er bedre til hurtige prototyper, teams ukendt med GraphQL eller scenarier, hvor native HTTP-caching er kritisk uden yderligere værktøjer.

Hvor meget koster headless WordPress?

En minimal headless WordPress-opsætning koster omkring $14/md.: Cloudways til WordPress-hosting plus Vercels gratis Hobby-tier til frontend. En produktionsopsætning med WP Engine og Vercel Pro koster $40-70/md. Tilføj $0-50/md. for premium-plugins som ACF Pro og WPML. Specialbyggede headless CMS'er har ofte generøse gratis tiers, så omkostninger alene er ikke en grund til at vælge headless WordPress.

Kan jeg bruge WooCommerce med headless WordPress?

Ja. WPGraphQL har en WooCommerce-udvidelse (WPGraphQL WooCommerce eller "WooGraphQL"), der eksponerer produkter, ordrer, kurv og checkout-funktionalitet gennem GraphQL. Dette lader dig bygge custom React-butiksfrontends med fuld e-commerce-kapacitet. Checkout-flowet kræver ekstra arbejde sammenlignet med traditionelle WooCommerce-temaer, men performance- og UX-gevinsterne er betydelige for højt trafikerede butikker.

Har jeg brug for en udvikler til at opsætte headless WordPress?

Ja, en headless WordPress-opsætning kræver frontend-udviklingskompetencer, specifikt React (eller Vue/Svelte) og kendskab til APIs. Du skal bygge hele frontendet fra bunden eller tilpasse en starter-skabelon. Dette er ikke en no-code-løsning. Indholdsredaktører kan stadig bruge WordPress-admin normalt, men den indledende opsætning og løbende frontend-vedligeholdelse kræver udviklerinvolvering.

Hvilke plugins er essentielle for headless WordPress?

De essentielle plugins er WPGraphQL (GraphQL API), Advanced Custom Fields eller ACF (struktureret indholdsmodellering) og WPGraphQL for ACF (eksponerer custom fields via GraphQL). Stærkt anbefalet: Custom Post Type UI til registrering af post types gennem admin og et webhook-plugin som WP Webhooks til at udløse frontend-rebuilds ved indholdspublikation. Undgå frontend-afhængige plugins som Yoast SEOs meta-rendering eller formular-plugins.

Er headless WordPress godt til SEO?

Headless WordPress kan være fremragende til SEO, når det implementeres korrekt med Next.js eller Nuxt, fordi du får server-side rendering, hurtigere sidelastning (forbedrer Core Web Vitals) og fuld kontrol over meta-tags, strukturerede data og URL-struktur. Risikoen er, at du mister automatiske SEO-plugin-funktioner som Yoasts meta-tag-rendering; du skal håndtere meta-tags, sitemaps og strukturerede data manuelt i din frontend-kode.