Next.js vs WordPress nel 2025: albero decisionale e via headless

Problema che risolvi: devi scegliere dove vive il CMS e dove vive il frontend senza tabelline con stelle o slogan.

Cosa ottieni leggendo questo pezzo: un albero decisionale (sì/no) e, se vince l’ibrido, uno snippet concreto per leggere post da WordPress in Next.js (App Router) via REST API.

Come sai che la scelta è coerente: ogni ramo termina con un vincolo verificabile (team, budget contenuti, hosting).

Nota: “Next.js” qui sta per “app React con SSR/SSG”; lo stesso pattern REST si applica a Nuxt con useFetch / $fetch verso wp-json.

Albero decisionale (rispondi in ordine)

1. Chi aggiorna i contenuti ogni settimana?

• Principalmente persone non tecniche che vogliono editor WYSIWYG e plugin → privilegia WordPress classico (monolite) o headless WP se il frontend deve essere custom.
• Solo sviluppatori (markdown, Git, review PR) → spesso non serve WordPress: static site generator, Nuxt Content, ecc. riducono superficie.

2. Hai bisogno di login utente, carrello, dashboard o logica applicativa complessa nel frontend?

• Sì → Next.js (o Nuxt) come app; WordPress al massimo come headless CMS, non come “tema + 30 plugin”.
• No, è sito vetrina/blog → WordPress monolite può bastare se hosting e tema sono curati.

3. Il vincolo principale è time-to-market con budget contenuto?

• Sì → WordPress + tema serio + pochi plugin batte quasi sempre un MVP marketing in puro custom.
• No, il vincolo è LCP/INP su funnel critico e controllo totale del markup → frontend custom (Next/Nuxt) + CMS headless o content in repo.

4. Devi integrare dati da API interne, feature flags, A/B server-side, multi-tenant?

• Sì → Next.js/Nuxt (o altro framework app); WordPress monolite diventa attrito.
• No → resta sul monolite finché non misuri un collo di bottiglia reale.

Tre esiti possibili

Headless WordPress + Next.js: pattern minimo

WordPress espone la REST API su /wp-json/ (documentazione in Handbook REST API).

Esempio Server Component (App Router) che legge gli ultimi post (HTML sicuro: sanitizza in produzione se renderizzi content.rendered):

// app/blog/page.tsx — adatta WP_URL in .env
const WP = process.env.WP_URL ?? 'https://example.com'

type WpPost = { id: number; slug: string; title: { rendered: string } }

export default async function BlogIndex() {
  const res = await fetch(`${WP}/wp-json/wp/v2/posts?per_page=5&_fields=id,slug,title`, {
    next: { revalidate: 60 },
  })
  if (!res.ok) throw new Error(`WP ${res.status}`)
  const posts = (await res.json()) as WpPost[]
  return (
    <ul>
      {posts.map((p) => (
        <li key={p.id}>
          <a href={`/blog/${p.slug}`}>{p.title.rendered}</a>
        </li>
      ))}
    </ul>
  )
}

Checklist operativa headless:

• URL canonico e CORS se il browser chiama WP direttamente (meglio: solo server-to-server come sopra).
• Autenticazione per preview bozze: Application Passwords o JWT plugin — non esporre credenziali al client.
• ISR / revalidate in Next o route rules in Nuxt per non martellare WP ad ogni richiesta.

Analogia Nuxt 3

Stessa chiamata in una pagina server:

const WP = useRuntimeConfig().public.wpUrl as string
const { data: posts } = await useFetch(`${WP}/wp-json/wp/v2/posts`, {
  query: { per_page: 5, _fields: 'id,slug,title' },
})

Sintesi

1. Non usare Next.js “perché è moderno” se il team non può mantenerlo.
2. Non usare WordPress come app framework se la logica business vive nel frontend.
3. Se serve editor WP + frontend controllato, headless è l’unica terza via pulita — il codice sopra è il test di fattibilità in meno di un’ora.

Verifica finale: riesci a elencare chi deploya WP, chi deploya il frontend e dove sta la cache HTML? Se la risposta è chiara per entrambi i lati, lo stack è definito.