WordPress Headless CMS: La Guida per Sviluppatori [2026]

WordPress alimenta il 43% di tutti i siti web secondo W3Techs, e un numero crescente di team sta eliminando completamente il frontend PHP per usarlo come API di contenuti. Ecco tutto quello che devi sapere per far girare WordPress in modalità headless — dalla scelta tra REST API e WPGraphQL al deployment di un frontend Next.js su Vercel con ISR.

Cos'è WordPress Headless? (E Perché Dovresti Interessartene?)

WordPress headless è una configurazione in cui WordPress gestisce la gestione e l'archiviazione dei contenuti mentre un'applicazione frontend separata — costruita con Next.js, Nuxt, Astro o qualsiasi framework — recupera quei contenuti tramite API. WordPress mantiene la sua dashboard di amministrazione, l'editor, l'ecosistema di plugin e il database MySQL. Ma invece di renderizzare le pagine con temi PHP, espone i contenuti tramite la REST API di WordPress o WPGraphQL, e il tuo frontend si occupa interamente del livello di presentazione.

Pensala così: WordPress diventa la cucina, e il tuo framework frontend è il ristorante. La cucina prepara il cibo (i contenuti), ma il ristorante decide come impiattarlo, com'è la sala da pranzo e come i clienti vivono l'esperienza.

Architettura Tradizionale vs Headless

Nel WordPress tradizionale, tutto è un monolite. Un visitatore richiede una pagina, PHP elabora la richiesta, interroga MySQL, la processa attraverso i template del tema e restituisce HTML renderizzato. Il tema controlla layout, stile, routing — tutto.

Nel WordPress headless, rimuovi completamente quel livello di rendering. WordPress vive dietro un'API, di solito su hosting gestito come WP Engine o Kinsta. Il tuo frontend — un'app React, Vue o Svelte — fa richieste API per recuperare i contenuti e li renderizza come vuoi. I due sistemi possono vivere su server completamente diversi, stack tecnologici diversi, pipeline di deployment diverse.

C'è una sfumatura che 9 guide su 10 ignorano: decoupled e headless non sono esattamente la stessa cosa. WordPress decoupled può ancora ricorrere al rendering PHP per alcune pagine (come l'area admin o le route legacy). Completamente headless significa che il frontend WordPress è completamente disabilitato — solo API, nessun rendering di temi. In questa guida parliamo dell'approccio completamente headless.

Quando Passare a Headless (e Quando Restare Tradizionale)

Passare a headless ha senso quando il tuo team ha sviluppatori frontend che vogliono lavorare con strumenti moderni, quando devi distribuire contenuti su più canali (web, app mobile, segnaletica digitale), o quando le performance sono un requisito non negoziabile. Non ha senso per tutti, ed essere onesti su questo ti farà risparmiare settimane di lavoro sprecato.

Vai Headless Quando...

• Il tuo team conosce già React/Vue/Svelte. Se i tuoi frontend dev scrivono JSX tutto il giorno, costringerli nei temi PHP è come chiedere a uno chef di cucinare con un microonde.
• Hai bisogno di distribuzione multi-canale. Un unico backend WordPress può alimentare il tuo sito marketing, l'app mobile e il chiosco in-store attraverso la stessa API.
• Le performance sono un requisito rigido. Le pagine statiche servite da un edge CDN batteranno sempre il rendering PHP su un server condiviso.
• Stai usando WooCommerce headless. I frontend e-commerce complessi beneficiano enormemente di storefront personalizzati con React/Next.js.
• Vuoi la DX moderna. Hot module replacement, TypeScript, librerie di componenti, CI/CD — l'intera toolchain frontend.

Resta Tradizionale Quando...

• Gli editor di contenuti hanno bisogno di anteprima live e page builder. Gutenberg, Elementor e WPBakery assumono un tema tradizionale. Passare a headless elimina la maggior parte dei workflow di editing visuale.
• Sei uno sviluppatore solista o un piccolo team. Headless aggiunge il 40-60% di complessità di setup. Se sei solo tu a mantenere un blog, un tema tradizionale è più semplice.
• Dipendi molto da plugin frontend. Form di contatto, plugin SEO (Yoast renderizza i meta tag lato server), banner di consenso cookie — tutti assumono il rendering PHP.
• Il budget è limitato. Avrai bisogno di hosting separato per WordPress e il tuo frontend. Sono due fatture invece di una.

REST API vs WPGraphQL: Scegliere il Livello Dati

WordPress ti dà due modi per recuperare contenuti in una configurazione headless: la REST API integrata e il plugin WPGraphQL. La REST API viene fornita con il core di WordPress e funziona subito — nessun plugin necessario. WPGraphQL richiede l'installazione di un plugin ma ti permette di interrogare esattamente i campi di cui hai bisogno, eliminando il problema dell'over-fetching che affligge REST. Nella nostra esperienza, WPGraphQL vince per la maggior parte dei progetti, ma REST ha un vantaggio sottovalutato: la cache HTTP nativa.

WordPress REST API: L'Opzione Integrata

La REST API è disponibile su ogni installazione di WordPress dalla versione 4.7 (dicembre 2016). Colpisci /wp-json/wp/v2/posts e ottieni JSON. Semplice, ben documentata, e funziona senza alcuna configurazione.

Il problema? L'over-fetching. Quando richiedi un post, WordPress restituisce tutto: contenuto renderizzato, contenuto grezzo, excerpt, ID autore, ID media in evidenza, categorie, tag, meta fields, GUID, stato commenti, stato ping, template e circa altri 15 campi di cui probabilmente non hai bisogno. Per una pagina di listing del blog dove ti servono solo titoli, slug ed excerpt, stai trasferendo 3-5x più dati del necessario.

// REST API: Recupera 5 post recenti con autore e categorie
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// Il parametro _embed include oggetti autore e categoria
// Ma include anche OGNI campo di ogni post -- ~8KB per post
// Per 5 post, stai guardando ~40KB di JSON

Puoi usare il parametro _fields per limitare i campi restituiti (?_fields=id,title,slug,excerpt), ma non aiuta con le risorse embedded, e farai comunque più richieste se hai bisogno di dati correlati.

WPGraphQL: Interroga Solo Ciò che Ti Serve

WPGraphQL è un plugin open-source gratuito di Jason Bahl (ora mantenuto da WP Engine) che aggiunge un'API GraphQL completa a WordPress. Scrivi una query specificando esattamente quali campi vuoi e ricevi esattamente quelli — niente di più.

# WPGraphQL: Stessa query -- 5 post recenti con autore e categorie
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Risposta: ~2KB di JSON strutturato con precisione
# Nessun campo extra, nessun bloat

Confronto Side-by-Side del Codice

Ecco com'è la risposta effettiva:

Quale Scegliere?

Usa REST quando stai costruendo qualcosa velocemente, il tuo team non conosce GraphQL, o hai bisogno di caching HTTP aggressivo senza strumenti aggiuntivi.

Usa WPGraphQL quando stai costruendo un frontend di produzione con esigenze di dati complesse, vuoi payload più piccoli, o il tuo team usa già GraphQL altrove.

Verdetto: Per un progetto WordPress headless serio con Next.js, WPGraphQL è la scelta migliore. Il risparmio di payload, la developer experience con GraphiQL IDE e il fetching dei dati con singola richiesta valgono la dipendenza dal plugin.

Configurare WordPress come Headless CMS

Configurare WordPress come headless CMS richiede sei passaggi: installare WordPress, aggiungere i plugin giusti, configurare il modello di contenuti, disabilitare il tema frontend, impostare l'autenticazione e verificare che l'API funzioni. L'intero processo richiede circa 30-45 minuti se lo hai già fatto prima, o un paio d'ore la prima volta.

Passaggio 1: Inizia con una nuova installazione di WordPress su hosting gestito. Kinsta, WP Engine e Cloudways offrono tutti ambienti ottimizzati per WordPress. Se stai solo sperimentando, un'installazione locale con LocalWP va benissimo.

Passaggio 2: Installa i plugin essenziali:

Passaggio 3: Crea il tuo modello di contenuti con ACF. Definisci gruppi di campi che mappano i tuoi componenti frontend. Un tipo di post portfolio potrebbe avere campi per projectUrl, techStack (repeater), clientName e projectYear.

Plugin Essenziali

WPGraphQL for ACF merita attenzione speciale. Senza di esso, i tuoi campi ACF non appariranno nelle query GraphQL. Dopo l'installazione, puoi interrogare i campi personalizzati così:

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

Disabilitare il Frontend WordPress

Passaggio 4: Non vuoi che i visitatori raggiungano l'URL di WordPress e vedano un tema rotto. Aggiungi questo al functions.php del tuo tema o usa un mu-plugin:

// Reindirizza tutte le richieste frontend all'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;
    }
});

Passaggio 5: Imposta le Application Passwords per l'autenticazione. Vai su Utenti > Il tuo profilo > Application Passwords, genera una password e usala per le richieste API autenticate (creazione/aggiornamento di contenuti da strumenti esterni).

Testare la tua API

Passaggio 6: Apri il browser e vai su https://your-site.com/graphql — dovresti vedere il GraphiQL IDE. Prova a interrogare i tuoi post. Se usi REST, vai su https://your-site.com/wp-json/wp/v2/posts e verifica di ottenere JSON.

Pro tip: il GraphiQL IDE che viene fornito con WPGraphQL è davvero eccellente per esplorare il tuo schema. Hai autocomplete, documentazione e cronologia delle query. È il modo più veloce per capire quali campi sono disponibili e come sono strutturati i dati ACF.

Costruire un Frontend Next.js con WPGraphQL

Il modo più pulito per costruire un frontend WordPress headless nel 2026 è con App Router di Next.js 15 e React Server Components. I Server Components recuperano i dati sul server senza spedire JavaScript al client, e WPGraphQL ti dà query precise — è un abbinamento naturale. Quando ho configurato per la prima volta WPGraphQL con Next.js App Router, il problema più grande era la gestione delle immagini — ma ci arriviamo.

Setup del Progetto e Variabili d'Ambiente

Inizia con un nuovo progetto Next.js. Vercel offre anche un template WordPress ufficiale se vuoi un'architettura di riferimento.

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

Crea .env.local con i tuoi endpoint WordPress:

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

Ora crea una utility GraphQL leggera. Non hai bisogno di Apollo o urql per i Server Components — il semplice fetch funziona perfettamente perché non c'è stato lato client da gestire:

// 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: rivalida ogni ora
  });

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

Per le opzioni di framework React, dai un'occhiata al nostro confronto tra Next.js e React con Vite — ci sono motivi validi per saltare il framework, anche se per il lavoro con headless CMS le SSR e ISR integrate rendono Next.js la scelta pratica. E se stai scegliendo tra Next.js e Remix, lo analizziamo nel nostro post su perché raccomandiamo Next.js per la maggior parte dei progetti.

Recuperare i Post con Server Components

Ecco la pagina di listing del blog come Server Component — nessun useEffect, nessuno stato di caricamento, nessuna idratazione lato client:

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

Pagine di Post Dinamiche

Le pagine dei singoli post usano generateStaticParams per pre-renderizzare tutti i post al momento della build, poi ISR raccoglie i nuovi contenuti:

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

Non dimenticare di configurare next.config.ts per le immagini WordPress:

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

export default nextConfig;

Deployment di WordPress Headless in Produzione

Una configurazione WordPress headless in produzione usa un dual hosting: WordPress vive su hosting WordPress gestito (WP Engine, Kinsta o Cloudways), mentre il frontend Next.js viene deployato su una piattaforma edge come Vercel o Netlify. Questa separazione significa che ogni livello può scalare indipendentemente — WordPress gestisce l'editing dei contenuti e le richieste API, mentre il frontend serve pagine statiche e ISR dai nodi edge CDN in tutto il mondo.

Architettura di Hosting

Il flusso di dati funziona così: gli editor di contenuti pubblicano nella dashboard WordPress, WordPress archivia i contenuti in MySQL, il frontend Next.js recupera i contenuti tramite WPGraphQL, Vercel genera HTML statico all'edge e i visitatori colpiscono la CDN — senza mai toccare direttamente WordPress.

Per l'hosting frontend, dai un'occhiata al nostro confronto tra Vercel e Netlify per un'analisi dettagliata. Entrambi funzionano bene per WordPress headless. Se stai considerando alternative basate su container, il nostro confronto tra Railway, Render e Fly.io copre anche quelle opzioni.

ISR e Revalidazione On-Demand

Questa è la parte che rende WordPress headless davvero praticabile in produzione. Abbiamo scoperto che la revalidazione on-demand vale lo sforzo di configurazione, perché senza di essa sei costretto a scegliere tra contenuti obsoleti (lunghi intervalli di revalidazione) e build lente (intervalli brevi che martellano la tua API WordPress).

ISR ti permette di impostare un tempo di revalidate su ogni pagina. Dopo quell'intervallo, il prossimo visitatore ottiene la pagina in cache mentre Next.js la rigenera in background. Ma la vera magia è la revalidazione on-demand — attivare una rigenerazione nel momento esatto in cui il contenuto viene pubblicato:

// 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'); // Rivalida anche la pagina di listing
  }

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

Sul lato WordPress, aggiungi un webhook che si attiva su publish_post usando un plugin come WP Webhooks o un semplice snippet in functions.php che chiama il tuo endpoint /api/revalidate su Vercel. Ora il contenuto va live entro secondi dal clic su "Pubblica" — nessuna build completa, nessuna attesa. Consulta la documentazione ISR di Next.js per ulteriori opzioni di configurazione.

Analisi dei Costi

WordPress Headless vs Headless CMS Nativi

Dopo aver lavorato sia con WordPress headless che con CMS nativi come Sanity, Contentful e Strapi, ecco la mia valutazione onesta: WordPress headless è una scelta pragmatica quando hai un sito WordPress esistente o un team di contenuti. Raramente è la scelta migliore quando si parte da zero.

Dove WordPress Headless Vince

• Gli editor di contenuti lo conoscono già. L'interfaccia admin di WordPress ha 20 anni di affinamento. Formare un team non tecnico su Sanity Studio o l'interfaccia di Contentful richiede settimane.
• Ecosistema di plugin. Oltre 60.000 plugin. Hai bisogno del multilingua? WPML. E-commerce? WooCommerce. Analisi del contenuto SEO? Yoast (funziona ancora nell'admin). Nessun CMS nativo eguaglia questa ampiezza.
• Assunzioni. WordPress ha il più grande pool di talenti sviluppatori di qualsiasi CMS. Trovare un developer WordPress è molto più facile che trovare uno specialista Sanity o Payload.
• WooCommerce. Se hai bisogno di e-commerce headless con contenuti WordPress, WooCommerce + WPGraphQL è uno stack collaudato. Saleor e Medusa sono alternative, ma WooCommerce ha la quota di mercato.

Dove i CMS Nativi Vincono

• Modellazione dei contenuti. GROQ di Sanity, i tipi di contenuto di Contentful e lo schema TypeScript di Payload sono progettati per contenuti strutturati dalle fondamenta. Il modello post/pagina/custom-post-type di WordPress sembra un'aggiunta posticcia.
• Collaborazione in tempo reale. Sanity ha editing in tempo reale stile Google Docs. Contentful ha collaborazione live. WordPress? Ti ritrovi con una schermata di blocco "Questo post è in fase di modifica da qualcun altro".
• Architettura API-first. WPGraphQL è brillante, ma è ancora un plugin sopra un monolite PHP. L'API di Contentful e quella di Sanity sono state progettate API-first fin dal primo giorno.
• Gestione media. La libreria media di WordPress è funzionale ma basilare. La pipeline immagini di Sanity con ritagli automatici, hotspot e consegna CDN è un'altra categoria. Contentful e Storyblok si integrano nativamente con Cloudinary.
• Developer experience. Strapi e Payload ti danno un'esperienza di sviluppo locale con hot-reload sulle modifiche allo schema. WordPress richiede di aggiornare l'admin ed eseguire migrazioni del database.

Verdetto: Quale Scegliere?

Usa WordPress headless quando: hai un sito WordPress esistente con anni di contenuti, i tuoi editor si rifiutano di imparare un nuovo CMS, hai bisogno di WooCommerce, o hai bisogno di un plugin WordPress specifico che non ha equivalenti altrove.

Scegli un headless CMS nativo quando: stai avviando un nuovo progetto da zero, hai bisogno di collaborazione in tempo reale, il tuo modello di contenuti è complesso e strutturato, o il tuo team dà più valore alla developer experience che all'ampiezza dei plugin.

Da Techsy, abbiamo costruito frontend WordPress headless per clienti che migravano da WordPress tradizionale. Il nostro approccio tipico: WPGraphQL + Next.js App Router su Vercel, con ISR per le performance e revalidazione on-demand per la freschezza dei contenuti. Prenota una consulenza gratuita ->

WordPress MCP e Abilities API: Il Futuro con l'IA

WordPress 6.9 ha introdotto l'Abilities API, che sta confluendo nel core di WordPress 7.0 (aprile 2026). Crea un'interfaccia standardizzata, tipizzata e scopribile per le funzionalità di WordPress — pensala come WordPress che espone le sue capacità in un formato leggibile da macchina che gli strumenti IA possono comprendere e usare.

L'adattatore WordPress MCP collega questa Abilities API al Model Context Protocol (MCP), lo standard aperto per connettere sistemi IA a strumenti esterni. Cosa significa concretamente? Gli agenti IA in Claude, Cursor o VS Code possono ora scoprire cosa può fare il tuo sito WordPress ed eseguire quelle azioni direttamente.

Uno scenario pratico: Claude può creare un post WordPress, popolare i campi ACF con dati strutturati, assegnare categorie, impostare un'immagine in evidenza e attivare il tuo webhook di revalidazione Vercel — tutto in una conversazione. Nessun browser, nessun pannello admin, nessun copia-incolla.

È ancora nelle fasi iniziali, e l'adattatore MCP è ancora in evoluzione. Ma segnala qualcosa di importante: WordPress non sta semplicemente a guardare mentre i CMS headless nativi innovano. La combinazione Abilities API + MCP potrebbe rendere WordPress uno dei CMS più accessibili all'IA disponibili, sfruttando il suo enorme ecosistema di plugin in modi che le piattaforme più nuove e piccole non possono eguagliare. Leggi l'annuncio ufficiale sul WordPress Developer Blog per tutti i dettagli tecnici.

Performance: WordPress Headless vs WordPress Tradizionale

WordPress headless con un frontend statico migliora drasticamente le performance rispetto al WordPress PHP tradizionale. Il WordPress tradizionale serve pagine dinamiche eseguendo PHP ad ogni richiesta, con un Time to First Byte (TTFB) scadente — secondo i dati di performance di metà 2025, solo il 31% dei client WordPress desktop e il 24% su mobile ottengono punteggi TTFB buoni. Passare a headless con Next.js e ISR significa che le pagine sono pre-renderizzate e servite da nodi edge CDN, portando il TTFB sotto i 100ms per le pagine in cache.

Il case study di WP Engine su Android Authority ha mostrato un miglioramento 6x nei punteggi Lighthouse dopo la migrazione a WordPress headless. I dati Core Web Vitals raccontano una storia simile: solo il 45% dei siti WordPress supera tutti e tre i parametri CWV su mobile, rispetto al 65% per Shopify e all'83% per Duda.

Una nota importante: headless non risolve un backend WordPress lento. Se la tua API WordPress impiega 3 secondi a rispondere perché sei su hosting condiviso economico con 40 plugin, la rigenerazione ISR sarà lenta anche lei. Il frontend non può essere più veloce dell'API da cui dipende. Investi in un hosting gestito di qualità — conta ancora di più in una configurazione headless, non di meno. Il blog di WordPress Performance Lead Weston Ruter ha ottimi dati su cosa sposta davvero l'ago per le performance lato server di WordPress.

FAQ

Cos'è WordPress headless?

WordPress headless è un'architettura in cui WordPress funziona solo come backend di gestione dei contenuti, con il suo tema frontend PHP completamente disabilitato. I contenuti vengono consegnati tramite REST API o WPGraphQL a un'applicazione frontend separata costruita con framework come Next.js, Nuxt o Astro. La dashboard admin di WordPress rimane completamente funzionale per gli editor di contenuti.

WordPress funziona bene come headless CMS?

WordPress funziona bene come headless CMS quando hai un sito WordPress esistente, editor di contenuti che conoscono l'interfaccia, o hai bisogno dell'ecosistema di plugin (specialmente WooCommerce). È meno ideale dei CMS headless nativi come Sanity o Contentful quando si parte da zero, perché la modellazione dei contenuti e l'API di WordPress sono state adattate piuttosto che progettate API-first.

Quali sono gli svantaggi di WordPress headless?

I principali svantaggi sono: maggiore complessità (due ambienti di hosting invece di uno), perdita dell'editing visuale e delle funzionalità del page builder, i plugin frontend smettono di funzionare (rendering meta di Yoast, form di contatto, banner cookie), nessuna collaborazione in tempo reale sui contenuti, e l'API GraphQL è una dipendenza da plugin piuttosto che funzionalità core. Anche il budget aumenta perché paghi sia per l'hosting WordPress che per quello del frontend.

Come collego Next.js a WordPress?

Installa WPGraphQL sul tuo sito WordPress, poi crea un progetto Next.js con App Router. Imposta il tuo endpoint GraphQL WordPress come variabile d'ambiente, scrivi una semplice funzione utility GraphQL basata su fetch, e usala nei Server Components per interrogare post, pagine e tipi di contenuto personalizzati. Non hai bisogno di Apollo o urql — il semplice fetch funziona perché i Server Components girano sul server.

WPGraphQL vs REST API — quale è meglio?

WPGraphQL è meglio per i frontend di produzione perché restituisce solo i campi che richiedi (riducendo le dimensioni del payload del 60-80%), supporta query annidate in una singola richiesta e fornisce un GraphiQL IDE per l'esplorazione dello schema. La REST API è meglio per prototipi veloci, team non familiari con GraphQL, o scenari in cui la cache HTTP nativa è critica senza strumenti aggiuntivi.

Quanto costa WordPress headless?

Una configurazione WordPress headless minimale costa circa $14 al mese — Cloudways per l'hosting WordPress più il piano Hobby gratuito di Vercel per il frontend. Una configurazione di produzione con WP Engine e Vercel Pro costa $40-70 al mese. Aggiungi $0-50 al mese per plugin premium come ACF Pro e WPML. I CMS headless nativi spesso hanno piani gratuiti generosi, quindi il costo da solo non è un motivo per scegliere WordPress headless.

Posso usare WooCommerce con WordPress headless?

Sì. WPGraphQL ha un'estensione WooCommerce (WPGraphQL WooCommerce o "WooGraphQL") che espone prodotti, ordini, carrello e funzionalità di checkout tramite GraphQL. Questo ti permette di costruire storefront React personalizzati con piena capacità e-commerce. Il flusso di checkout richiede lavoro aggiuntivo rispetto ai temi WooCommerce tradizionali, ma i guadagni in performance e UX sono significativi per i negozi ad alto traffico.

Ho bisogno di uno sviluppatore per configurare WordPress headless?

Sì, una configurazione WordPress headless richiede competenze di sviluppo frontend — specificamente React (o Vue/Svelte) e familiarità con le API. Dovrai costruire l'intero frontend da zero o personalizzare un template starter. Non è una soluzione no-code. Gli editor di contenuti possono ancora usare l'admin WordPress normalmente, ma il setup iniziale e la manutenzione continua del frontend richiedono il coinvolgimento di uno sviluppatore.

Quali plugin sono essenziali per WordPress headless?

I plugin essenziali sono WPGraphQL (API GraphQL), Advanced Custom Fields o ACF (modellazione strutturata dei contenuti) e WPGraphQL for ACF (espone i campi personalizzati via GraphQL). Fortemente raccomandati: Custom Post Type UI per registrare i tipi di post tramite l'admin, e un plugin webhook come WP Webhooks per attivare rebuild del frontend alla pubblicazione dei contenuti. Evita i plugin dipendenti dal frontend come il rendering meta di Yoast SEO o i plugin per i form.

WordPress headless è buono per la SEO?

WordPress headless può essere eccellente per la SEO quando implementato correttamente con Next.js o Nuxt, perché ottieni il rendering lato server, tempi di caricamento più veloci (che migliorano i Core Web Vitals) e pieno controllo su meta tag, dati strutturati e struttura degli URL. Il rischio è che perdi le funzionalità automatiche dei plugin SEO come il rendering dei meta tag di Yoast — dovrai gestire meta tag, sitemap e dati strutturati nel codice del tuo frontend manualmente.