Rapporto di rendering
Il rapporto di rendering è la quota del testo di una pagina che esiste già nell’HTML inviato dal server, prima che venga eseguito qualsiasi JavaScript.
Una pagina al 95 % la legge qualsiasi cosa sappia scaricare un URL. Una al 10 % è un guscio quasi vuoto che diventa pagina solo dentro un browser, e la maggior parte dei crawler non sono browser. È la verifica che più siti non superano.
Perché il rapporto di rendering decide la tua citabilità?
Un modello non naviga. Qualcosa scarica il tuo URL, tiene il testo che riceve, e quel testo è tutto ciò che il modello avrà mai di te. Se il tuo contenuto si assembla sul client, quello che resta è una barra di navigazione e uno stato di caricamento.
Google è l’eccezione che genera la confusione. Esegue JavaScript, in una fase separata successiva alla scansione, e la sua stessa documentazione continua a raccomandare il rendering lato server perché, con le sue parole, non tutti i bot possono eseguire JavaScript. I bot che portano risposte stanno in gran parte in quel secondo gruppo.
Quale rapporto di rendering è buono?
Si misura come quota del testo finale presente nell’HTML grezzo. Le fasce sono grossolane di proposito: oltre il 90 % la pagina è praticamente completa senza script, e sotto il 60 % un crawler vede qualcosa di diverso da ciò che hai pubblicato.
- Oltre il 90 % — la pagina è praticamente completa senza JavaScript.
- Fra il 60 % e il 90 % — il contenuto principale c’è e alcune parti no. Di solito recensioni, prezzi o schede.
- Sotto il 60 % — un crawler che non esegue JavaScript vede una pagina diversa da quella che hai pubblicato.
- Vicino allo 0 % — un guscio vuoto. Il sito esiste solo per i browser.
Come si corregge un rapporto di rendering basso?
Rendering lato server o generazione statica per il contenuto che conta, cosa che ogni framework moderno supporta e che la maggior parte dei progetti semplicemente non ha mai attivato. Non cambia il design né la tecnologia: cambia chi assembla l’HTML.
Dove una ricostruzione non è in discussione, la toppa economica è servire una versione testuale a chi la chiede, per negoziazione di contenuto o con una copia Markdown documentata. Non ripara la pagina, ma fa sì che il contenuto esista da qualche parte raggiungibile da un crawler.
Su che cosa si regge questo?
La documentazione di Google è qui la fonte più forte, ed è quella che di solito viene citata al contrario. Tutte e tre si leggono per intero e gratis.
- JavaScript SEO basics, Google Search Central
Documenta le tre fasi —scansione, rendering, indicizzazione— e afferma che il rendering lato server resta una buona idea perché non tutti i bot possono eseguire JavaScript. Quella frase è tutto l’argomento.
- GEO: Generative Engine Optimization
Misura cosa rende visibile un contenuto dentro le risposte generate. Nulla di ciò vale per un contenuto che il crawler non ha mai ricevuto.
- La convenzione llms.txt
La toppa parziale abituale: pubblicare una versione Markdown di ciò che dice la pagina, per agenti che non eseguiranno uno script.
Domande frequenti su Rapporto di rendering
Google non esegue comunque il JavaScript?
- Lo esegue, in una fase di rendering successiva alla scansione. Questo copre Google e non dice nulla sul resto, e la documentazione di Google continua a raccomandare il rendering lato server perché non tutti i bot possono eseguire JavaScript. Ottimizzare per l’unico crawler che fa rendering è puntare sul crawler sbagliato.
Un buon rapporto di rendering significa rinunciare a React?
- No. React, Vue e Svelte fanno rendering lato server, e i framework costruiti su di essi lo fanno per impostazione predefinita. Un rapporto basso è quasi sempre una configurazione mai attivata, non un limite della tecnologia.