{"id":76811,"date":"2024-02-26T09:20:52","date_gmt":"2024-02-26T08:20:52","guid":{"rendered":"https:\/\/kinsta.com\/it\/?p=76811&preview=true&preview_id=76811"},"modified":"2024-02-28T08:59:09","modified_gmt":"2024-02-28T07:59:09","slug":"wordpress-headless-seo","status":"publish","type":"post","link":"https:\/\/kinsta.com\/it\/blog\/wordpress-headless-seo\/","title":{"rendered":"Strategie SEO avanzate per siti WordPress headless"},"content":{"rendered":"

Optare per un sito WordPress headless<\/a> rispetto a un’architettura tradizionale cambia notevolmente le carte in tavola in termini di SEO. Questo approccio separa il front-end del sito dal back-end, aumentando la flessibilit\u00e0 e la velocit\u00e0. Ma comporta anche nuove sfide SEO.<\/p>\n

Ecco come stanno le cose: la visibilit\u00e0 di un sito e il modo in cui le persone lo trovano attraverso i motori di ricerca dipendono dalle tattiche SEO. Per questo motivo, oggi parleremo di alcune strategie SEO avanzate pensate proprio per le configurazioni WordPress headless.<\/p>\n

Vedremo come assicurarci che i motori di ricerca possano scansionare correttamente un sito, di come modificare i meta tag e di molto altro ancora. Che vi occupiate di scrivere il codice del sito o che di elaborare strategie di marketing, vi daremo consigli pratici per affinare le vostre capacit\u00e0 SEO.<\/p>\n

Andiamo al sodo.
\n

<\/div><\/kinsta-auto-toc><\/p>\n

Come rendere “crawlabili” i siti WordPress headless<\/h2>\n

Rendere i siti WordPress headless adatti al crawling presenta alcune sfide uniche che i siti tradizionali non incontrano. L’ostacolo principale deriva dal fatto che il contenuto dei siti headless viene reso dal lato client utilizzando JavaScript<\/a>, il che storicamente ha creato difficolt\u00e0 ai bot dei motori di ricerca in termini di crawling e indicizzazione.<\/p>\n

Tuttavia, tecniche moderne come il rendering dinamico e il rendering lato server hanno reso molto pi\u00f9 semplice affrontare questi problemi.<\/p>\n

Rendering dinamico<\/h3>\n

Il rendering dinamico<\/a> funge da ponte tra i contenuti pesanti in JavaScript e i crawler dei motori di ricerca. Consiste nel presentare ai motori di ricerca un’istantanea HTML statica<\/a> e prerenderizzata dei contenuti del sito, mentre gli utenti continuano a sperimentare la versione dinamica e interattiva.<\/p>\n

In questo modo i crawler possono indicizzare i contenuti del sito senza dover eseguire JavaScript<\/a>, migliorando immediatamente la visibilit\u00e0 e le prestazioni SEO.<\/p>\n

Per implementare il rendering dinamico in un ambiente WordPress headless, di solito si utilizza una soluzione come prerender.io<\/a> o si costruisce un proprio meccanismo di rendering lato server, magari con Node.js<\/a>.<\/p>\n

\"\u00c8
Prerender<\/figcaption><\/figure>\n

Ecco una spiegazione concettuale:<\/p>\n

1. Rilevamento degli user-agent<\/h4>\n

\u00c8 necessario distinguere tra le richieste fatte dagli utenti (browser) e quelle fatte dai crawler (come Googlebot). Questo pu\u00f2 essere fatto controllando lo user-agent nelle intestazioni HTTP delle richieste in arrivo.<\/p>\n

2. Servire contenuti statici ai bot<\/h4>\n

Quando viene rilevato un crawler, invece di servire il solito contenuto ricco di JavaScript, il server reindirizza la richiesta a una versione HTML statica e prerenderizzata della pagina richiesta. Questo pu\u00f2 essere ottenuto utilizzando un servizio di prerendering o disponendo di una configurazione di prerendering sul server che genera pagine HTML statiche dei contenuti al volo, o da una cache.<\/p>\n

3. Come configurarlo con WordPress<\/h4>\n

Servizi come prerender.io offrono un middleware che pu\u00f2 essere integrato nel server. Questo middleware intercetta le richieste in arrivo, verifica se provengono da crawler e, in caso affermativo, serve una pagina prerenderizzata dalla cache di prerender.io o attiva il rendering di una nuova pagina se non \u00e8 presente nella cache.<\/p>\n

Costruendo una soluzione personalizzata, di solito useremmo Puppeteer<\/a> in un ambiente Node.js per il pre-rendering delle pagine. Quando l’API di WordPress invia il contenuto al vostro server Node.js, controlla lo user-agent. Se si tratta di un crawler, Puppeteer esegue il rendering della pagina, salva l’HTML statico e serve questa versione.<\/p>\n

Questo processo pu\u00f2 essere ottimizzato mettendo nella cache le pagine statiche per evitare di renderizzarle a ogni richiesta del crawler.<\/p>\n

Rendering lato server<\/h3>\n

Il rendering lato server<\/a>, invece, prevede il rendering del contenuto della pagina sul server prima che raggiunga il client. Ci\u00f2 significa che quando un bot di un motore di ricerca richiede una pagina, riceve una pagina HTML completamente renderizzata, rendendola immediatamente indicizzabile.<\/p>\n

Si pu\u00f2 implementare il rendering lato server utilizzando vari framework e librerie JavaScript, come React<\/a> e Node.js<\/a>, per eseguire il rendering dei contenuti direttamente sul server. Questo approccio non solo aiuta a rendere i contenuti pi\u00f9 accessibili ai motori di ricerca, ma migliora anche l’esperienza complessiva dell’utente accelerando i tempi di caricamento delle pagine.<\/p>\n

Per il rendering lato server, l’utilizzo di framework come Next.js<\/a> in combinazione con l’API REST di WordPress<\/a> o GraphQL<\/a> pu\u00f2 semplificare il processo.<\/p>\n

Una configurazione tipica potrebbe prevedere il recupero dei dati con GraphQL e il rendering delle pagine sul server utilizzando Next.js, in modo da pre-popolare i contenuti prima che vengano serviti.<\/p>\n

Configurare gli URL canonici<\/h2>\n

La configurazione di URL canonici per un sito WordPress headless \u00e8 un altro modo per mantenere l’integrit\u00e0 SEO, soprattutto quando i contenuti vengono serviti attraverso un front-end disaccoppiato come Gatsby<\/a> o Next.js.<\/p>\n

Gli URL canonici<\/a> aiutano a evitare problemi di contenuti duplicati segnalando ai motori di ricerca quale versione di una pagina di contenuti \u00e8 quella principale o “canonica”. Questo \u00e8 necessario in un ambiente headless in cui i contenuti possono essere accessibili attraverso pi\u00f9 percorsi o endpoint.<\/p>\n

Perch\u00e9 gli URL canonici sono importanti<\/h3>\n

In WordPress headless, il rischio di duplicazione dei contenuti aumenta a causa della separazione del front-end dal back-end di WordPress. Gli URL canonici mitigano questo rischio guidando i motori di ricerca a indicizzare l’URL<\/a> preferito. In questo modo si garantisce che il valore SEO venga consolidato nella pagina canonica, anzich\u00e9 essere diluito in pi\u00f9 versioni dello stesso contenuto.<\/p>\n

Inoltre, la creazione di URL canonici chiarisce quale versione del contenuto deve essere classificata nei risultati di ricerca.<\/p>\n

Come impostare gli URL canonici<\/h3>\n

L’implementazione degli URL canonici in un ambiente WordPress headless pu\u00f2 essere gestita in modo efficiente con l’aiuto del plugin Yoast SEO e di WPGraphQL, per collegare i dati di Yoast SEO alla configurazione headless.<\/p>\n

Ecco una panoramica di alto livello di un processo che lo sviluppatore web Andrew Kepson<\/a> descrive in modo molto dettagliato e che coinvolge un paio di plugin popolari:<\/p>\n