Sapevi che mentre il blog di Ahrefs è gestito da WordPress, gran parte del resto del sito è gestito da JavaScript come React?
La realtà del web attuale è che JavaScript è ovunque. La maggior parte dei siti Web utilizza una sorta di JavaScript per aggiungere interattività e migliorare l'esperienza dell'utente.
Eppure la maggior parte del JavaScript utilizzato su così tanti siti web non avrà alcun impatto sulla SEO. Se hai una normale installazione di WordPress senza molta personalizzazione, probabilmente nessuno dei problemi si applicherà al tuo caso.
Il punto in cui incontrerai problemi è quando JavaScript viene utilizzato per creare un'intera pagina, aggiungere o rimuovere elementi o modificare ciò che era già sulla pagina. Alcuni siti lo utilizzano per i menu, per inserire prodotti o prezzi, per acquisire contenuti da più fonti o, in alcuni casi, per tutto ciò che è presente sul sito. Se questo sembra il tuo sito, continua a leggere.
Stiamo vedendo interi sistemi e app costruiti con framework JavaScript e persino alcuni CMS tradizionali con un tocco JavaScript in cui sono headless o disaccoppiati. Il CMS viene utilizzato come fonte di dati backend, ma la presentazione frontend è gestita da JavaScript.
Non sto dicendo che i SEO debbano uscire e imparare a programmare JavaScript. In realtà non lo consiglio perché è improbabile che tu tocchi mai il codice. Ciò che i SEO devono sapere è come Google gestisce JavaScript e come risolvere i problemi.
JavaScript SEO è una parte di SEO tecnico (ottimizzazione per i motori di ricerca) che rende i siti web ricchi di JavaScript facili da scansionare e indicizzare, oltre che facili da ricercare. L'obiettivo è far sì che questi siti Web vengano trovati e posizionarsi più in alto nei motori di ricerca.
JavaScript non è dannoso per la SEO e non è malvagio. È semplicemente diverso da quello a cui sono abituati molti SEO e c'è un po' di curva di apprendimento.
Molti processi sono simili a ciò che i SEO sono già abituati a vedere, ma potrebbero esserci lievi differenze. Continuerai a guardare principalmente codice HTML, non a JavaScript.
Si applicano ancora tutte le normali migliori pratiche SEO on-page. Vedere la nostra guida sulla SEO on-page.
Troverai anche opzioni familiari di tipo plug-in per gestire molti degli elementi SEO di base, se non sono già integrati nel framework che stai utilizzando. Per i framework JavaScript, questi sono chiamati moduli e troverai molte opzioni di pacchetto per installarli.
Esistono versioni per molti dei framework più diffusi come Reagire, Vue, Angular e Svelte che puoi trovare cercando il nome del framework + modulo come "React Casco". Meta tag, Casco e Testa sono tutti moduli popolari con funzionalità simili e consentono l'impostazione di molti dei tag più diffusi necessari per la SEO.
In qualche modo, JavaScript è migliore dell'HTML tradizionale, ad esempio nella facilità di creazione e nelle prestazioni. In un certo senso, JavaScript è peggiore, in quanto non può essere analizzato progressivamente (come possono esserlo HTML e CSS) e può incidere pesantemente sul caricamento della pagina e sulle prestazioni. Spesso potresti barattare le prestazioni con la funzionalità.
JavaScript non è perfetto e non è sempre lo strumento giusto per il lavoro. Gli sviluppatori lo abusano per cose per le quali probabilmente esiste una soluzione migliore. Ma a volte devi lavorare con ciò che ti viene dato.
Questi sono molti dei problemi SEO più comuni che potresti incontrare quando lavori con siti JavaScript.
Avere tag titolo e meta descrizioni univoci
Avrai comunque voglia di avere qualcosa di unico title tag ed meta descrizioni attraverso le tue pagine. Poiché molti framework JavaScript sono basati su modelli, puoi facilmente ritrovarti in una situazione in cui lo stesso titolo o meta descrizione viene utilizzato per tutte le pagine o un gruppo di pagine.
Controlla il duplicati rapporto in Ahrefs' Site Audit e fai clic su uno qualsiasi dei raggruppamenti per visualizzare ulteriori dati sui problemi riscontrati.
Puoi utilizzare uno dei moduli SEO come Casco per impostare tag personalizzati per ogni pagina.
JavaScript può anche essere utilizzato per sovrascrivere i valori predefiniti che potresti aver impostato. Google elaborerà questa informazione e utilizzerà il titolo o la descrizione sovrascritti. Per gli utenti, tuttavia, i titoli possono essere problematici, poiché un titolo potrebbe apparire nel browser e noteranno un lampo quando viene sovrascritto.
Se vedi il titolo lampeggiare, puoi usare Ahrefs' Barra degli strumenti SEO per vedere sia la versione HTML grezza che quella renderizzata.
Google potrebbe comunque non utilizzare i tuoi titoli o le tue meta descrizioni. Come ho già detto, vale la pena ripulire i titoli per gli utenti. Tuttavia, risolvere questo problema per le meta descrizioni non farà davvero la differenza.
Quando abbiamo studiato la riscrittura di Google, abbiamo scoperto questo Google sovrascrive i titoli il 33.4% delle volte ed meta descrizioni il 62.78% delle volte. In Site Audit ti mostreremo anche quali tag del titolo sono stati modificati da Google.
Problemi relativi ai tag canonici
Per anni Google ha affermato di non rispettare tag canonici inserito con JavaScript. Infine ha aggiunto un'eccezione alla documentazione per i casi in cui non era già presente un tag. Ho causato quel cambiamento. Ho eseguito dei test per dimostrare che funzionava quando Google diceva a tutti che non era così.
Se era già presente un tag canonico e ne aggiungi un altro o sovrascrivi quello esistente con JavaScript, stai assegnando loro due tag canonici. In questo caso Google deve capire quale utilizzare o ignorare i tag canonici a favore di altri segnali di canonicalizzazione.
Il consiglio SEO standard di “ogni pagina dovrebbe avere un tag canonico autoreferenziale” mette nei guai molti SEO. Uno sviluppatore soddisfa questo requisito e rende autocanoniche le pagine con e senza una barra finale.
example.com/page con un canonico di example.com/page ed example.com/page/ con un canonico di example.com/page/. Ops, è sbagliato! Probabilmente vorrai reindirizzare una di quelle versioni all'altra.
La stessa cosa può succedere con versioni parametrizzate che magari si vogliono combinare, ma ognuna è autoreferenziale.
Google utilizza il meta tag robots più restrittivo
Con tag meta robot, Google adotterà sempre l'opzione più restrittiva che vede, indipendentemente dalla posizione.
Se hai un tag indice nell'HTML non elaborato e un tag noindex nell'HTML renderizzato, Google lo tratterà come noindex. Se hai un tag noindex nell'HTML non elaborato ma lo sovrascrivi con un tag indice utilizzando JavaScript, tratterà comunque quella pagina come noindex.
Funziona allo stesso modo per i tag nofollow. Google adotterà l’opzione più restrittiva.
Imposta gli attributi Alt sulle immagini
Mancante attributi alternativi sono un problema di accessibilità, che potrebbe trasformarsi in una questione legale. La maggior parte delle grandi aziende sono state citate in giudizio per problemi di conformità ADA sui loro siti Web e alcune vengono citate in giudizio più volte all'anno. Correggerei questo problema per le immagini del contenuto principale, ma non per cose come segnaposto o immagini decorative in cui puoi lasciare vuoti gli attributi alt.
Per la ricerca sul Web, il testo negli attributi alt conta come testo sulla pagina, ma in realtà è l'unico ruolo che svolge. A mio avviso, la sua importanza è spesso sopravvalutata per la SEO. Tuttavia, aiuta con la ricerca di immagini e il posizionamento delle immagini.
Molti sviluppatori JavaScript lasciano vuoti gli attributi alt, quindi ricontrolla che i tuoi siano presenti. Guarda al Immagini rapporto in Site Audit per trovare questi.
Consenti la scansione dei file JavaScript
Non bloccare l'accesso alle risorse se sono necessarie per creare parte della pagina o aggiungere contenuto. Google deve accedere e scaricare le risorse in modo che possa visualizzare correttamente le pagine. Nel tuo robots.txt, il modo più semplice per consentire la scansione delle risorse necessarie è aggiungere:
User-Agent: GooglebotAllow: .jsAllow: .css
Controlla anche i file robots.txt per eventuali sottodomini o domini aggiuntivi da cui potresti effettuare richieste, come quelli per le tue chiamate API.
Se hai bloccato risorse con robots.txt, puoi verificare se influisce sul contenuto della pagina utilizzando le opzioni di blocco nella scheda "Rete" in Chrome Dev Tools. Seleziona il file e bloccalo, quindi ricarica la pagina per vedere se sono state apportate modifiche.
Controlla se Google vede i tuoi contenuti
Molte pagine con funzionalità JavaScript potrebbero non mostrare tutti i contenuti a Google per impostazione predefinita. Se parli con i tuoi sviluppatori, potrebbero riferirsi a questo come non caricato Document Object Model (DOM). Ciò significa che il contenuto non è stato caricato per impostazione predefinita e potrebbe essere caricato in seguito con un'azione come un clic.
Un rapido controllo che puoi fare è semplicemente cercare uno snippet del tuo contenuto su Google tra virgolette. Cerca "qualche frase dal tuo contenuto" e verifica se la pagina viene restituita nei risultati di ricerca. Se lo è, è probabile che i tuoi contenuti siano stati visti.
Nota a margine.
Il contenuto nascosto per impostazione predefinita potrebbe non essere mostrato nel tuo snippet sul SERP. È particolarmente importante controllare la tua versione mobile, poiché spesso è ridotta all'osso per l'esperienza dell'utente.
Puoi anche fare clic con il pulsante destro del mouse e utilizzare l'opzione "Ispeziona". Cerca il testo nella scheda "Elementi".
Il miglior controllo sarà effettuare una ricerca all'interno del contenuto di uno degli strumenti di test di Google come lo strumento Controllo URL in Google Search Console. Ne parlerò più approfonditamente più tardi.
Controllerei sicuramente qualsiasi cosa dietro una fisarmonica o un menu a discesa. Spesso questi elementi effettuano richieste che caricano contenuto nella pagina quando vengono cliccati. Google non fa clic, quindi non vede il contenuto.
Se utilizzi il metodo di ispezione per cercare contenuti, assicurati di copiare il contenuto e quindi ricaricare la pagina o aprirla in una finestra di navigazione in incognito prima di eseguire la ricerca.
Se hai fatto clic sull'elemento e il contenuto è stato caricato quando è stata eseguita l'azione, troverai il contenuto. Potresti non vedere lo stesso risultato con un nuovo caricamento della pagina.
Problemi di contenuto duplicato
Con JavaScript potrebbero esserci più URL per lo stesso contenuto, il che porta a duplicare il contenuto problemi. Ciò può essere causato da lettere maiuscole, barre finali, ID, parametri con ID, ecc. Quindi potrebbero esistere tutti questi:
domain.com/Abcdomain.com/abcdomain.com/123domain.com/?id=123
Se desideri che venga indicizzata solo una versione, dovresti impostare un canonico autoreferenziale e i tag canonici di altre versioni che fanno riferimento alla versione principale o idealmente reindirizzare le altre versioni alla versione principale.
Controlla il duplicati rapporto in Site Audit. Analizziamo quali cluster duplicati hanno tag canonici impostati e quali presentano problemi.
Un problema comune con i framework JavaScript è che le pagine possono esistere con e senza la barra finale. Idealmente, dovresti scegliere la versione che preferisci e assicurarti che quella versione abbia un tag canonico autoreferenziale e quindi reindirizzare l'altra versione alla tua versione preferita.
Con i modelli di shell dell'app, nella risposta HTML iniziale potrebbero essere visualizzati pochissimi contenuti e codice. In effetti, ogni pagina del sito potrebbe visualizzare lo stesso codice e questo codice potrebbe essere esattamente lo stesso del codice su altri siti web.
Se vedi molti URL con un numero basso di parole in Site Audit, potrebbe indicare che hai questo problema.
Ciò a volte può far sì che le pagine vengano trattate come duplicate e non passino immediatamente al rendering. Ancora peggio, nei risultati di ricerca potrebbero essere visualizzati la pagina sbagliata o addirittura il sito sbagliato. Questo problema dovrebbe risolversi da solo nel tempo, ma può essere problematico, soprattutto con i siti Web più recenti.
Non utilizzare frammenti (#) negli URL
# ha già una funzionalità definita per i browser. Si collega a un'altra parte della pagina quando si fa clic, come la nostra funzione "sommario" sul blog. I server generalmente non elaborano nulla dopo un #. Quindi per un URL come abc.com/#something, qualsiasi cosa dopo un # viene generalmente ignorata.
Gli sviluppatori JavaScript hanno deciso di utilizzare # come trigger per scopi diversi e ciò causa confusione. I modi più comuni in cui vengono utilizzati in modo improprio sono per il routing e per Parametri URL. Sì, funzionano. No, non dovresti farlo.
I framework JavaScript in genere dispongono di router che mappano quelli che chiamano percorsi (percorsi). URL puliti. Molti sviluppatori JavaScript utilizzano gli hash (#) per il routing. Questo è particolarmente un problema per Vue e alcune delle versioni precedenti di Angular.
Per risolvere questo problema per Vue, puoi collaborare con il tuo sviluppatore per modificare quanto segue:
Vue router: Use ‘History’ Mode instead of the traditional ‘Hash’ Mode.
const router = new VueRouter ({mode: ‘history’,router: [] //the array of router links)}
C'è una tendenza crescente secondo cui le persone utilizzano # invece di ? come identificatore di frammento, in particolare per i parametri URL passivi come quelli utilizzati per il monitoraggio. Tendo a sconsigliarlo a causa di tutta la confusione e i problemi. In base alla situazione, potrei essere d'accordo con l'eliminazione di molti parametri non necessari.
Crea una mappa del sito
Le opzioni del router che consentono URL puliti di solito hanno un modulo aggiuntivo che può anche creare mappe dei siti. Puoi trovarli cercando il tuo sistema + mappa del sito del router, ad esempio "Mappa del sito del router Vue".
Molte delle soluzioni di rendering possono anche avere opzioni per la mappa del sito. Ancora una volta, basta trovare il sistema che utilizzi e cercare su Google il sistema + la mappa del sito come "Gatsby sitemap" e sarai sicuro di trovare una soluzione che già esiste.
Codici di stato e soft 404
Poiché i framework JavaScript non sono lato server, non possono realmente generare un errore del server come un 404. Hai un paio di opzioni diverse per le pagine di errore, come:
- Utilizzando un reindirizzamento JavaScript a una pagina che risponde con un codice di stato 404.
- Aggiunta di un tag noindex alla pagina che non funziona insieme a una sorta di messaggio di errore come "404 Pagina non trovata". Questo verrà trattato come un soft 404 poiché il codice di stato effettivo restituito sarà 200 ok.
I reindirizzamenti JavaScript sono OK, ma non preferiti
I SEO sono abituati Reindirizzamenti 301/302, che sono lato server. JavaScript viene in genere eseguito sul lato client. I reindirizzamenti lato server e persino i reindirizzamenti di meta aggiornamento saranno più facili da elaborare per Google rispetto ai reindirizzamenti JavaScript poiché non dovrà eseguire il rendering della pagina per vederli.
I reindirizzamenti JavaScript verranno comunque visualizzati ed elaborati durante il rendering e dovrebbero essere OK nella maggior parte dei casi: semplicemente non sono ideali come altri tipi di reindirizzamento. Vengono trattati come reindirizzamenti permanenti e trasmettono comunque tutti i segnali simili PageRank.
Spesso puoi trovare questi reindirizzamenti nel codice cercando "window.location.href". I reindirizzamenti potrebbero potenzialmente trovarsi anche nel file di configurazione. Nella configurazione Next.js, c'è una funzione di reindirizzamento che puoi utilizzare per impostare i reindirizzamenti. In altri sistemi, potresti trovarli nel router.
Problemi di internazionalizzazione
Di solito ci sono alcune opzioni di modulo per diversi framework che supportano alcune funzionalità necessarie per l'internazionalizzazione come hreflang. Sono stati comunemente portati su diversi sistemi e includono i18n, intl o, molte volte, gli stessi moduli utilizzati per i tag di intestazione come Casco possono essere utilizzati per aggiungere i tag necessari.
Contrassegniamo i problemi di hreflang nel file Localizzazione rapporto in Site Audit. Abbiamo anche condotto uno studio e lo abbiamo scoperto Il 67% dei domini che utilizzano hreflang presentano problemi.
Devi anche fare attenzione se il tuo sito blocca o tratta visitatori provenienti da un paese specifico o utilizza un particolare IP in modi diversi. Ciò può far sì che i tuoi contenuti non vengano visualizzati Googlebot. Se disponi di una logica che reindirizza gli utenti, potresti voler escludere i bot da questa logica.
Ti faremo sapere se ciò accade durante l'impostazione di un progetto in Site Audit.
Usa dati strutturati
JavaScript può essere utilizzato per generare o inserire dati strutturati nelle tue pagine. È abbastanza comune farlo con JSON-LD e probabilmente non causa problemi, ma esegui alcuni test per assicurarti che tutto funzioni come previsto.
Contrassegneremo tutti i dati strutturati che vediamo nel file Problema rapporto in Site Audit. Cerca l'errore "I dati strutturati hanno la convalida schema.org". Ti diremo esattamente cosa c'è che non va in ogni pagina.
Utilizza collegamenti in formato standard
I collegamenti ad altre pagine dovrebbero essere nel formato web standard. I collegamenti interni ed esterni devono essere an <a> taggare con an href attributo. Esistono molti modi per far funzionare i collegamenti per gli utenti con JavaScript che non sono ottimizzati per la ricerca.
Buono:
<a href=”/page”>simple is good</a>
<a href=”/page” onclick=”goTo(‘page’)”>still okay</a>
Bad:
<a onclick=”goTo(‘page’)”>nope, no href</a>
<a href=”javascript:goTo(‘page’)”>nope, missing link</a>
<a href=”javascript:void(0)”>nope, missing link</a>
<span onclick=”goTo(‘page’)”>not the right HTML element</span>
<option value="page">nope, wrong HTML element</option>
<a href=”#”>no link</a>
Pulsante, ng-click, ci sono molti altri modi in cui questo può essere fatto in modo errato.
Nella mia esperienza, Google elabora ancora molti dei collegamenti errati e li esegue la scansione, ma non sono sicuro di come li tratti come segnali di passaggio come PageRank. Il Web è un luogo disordinato e i parser di Google sono spesso abbastanza indulgenti.
Vale anche la pena notare questo link interni aggiunto con JavaScript non verrà rilevato fino a dopo il rendering. Dovrebbe essere un processo relativamente rapido e non motivo di preoccupazione nella maggior parte dei casi.
Utilizzare il controllo delle versioni dei file per risolvere gli stati impossibili da indicizzare
Google memorizza pesantemente nella cache tutte le risorse. Ne parlerò un po' più avanti, ma dovresti sapere che il suo sistema può portare all'indicizzazione di alcuni stati impossibili. Questa è una stranezza dei suoi sistemi. In questi casi, nel processo di rendering vengono utilizzate versioni precedenti dei file e la versione indicizzata di una pagina può contenere parti di file più vecchi.
Puoi utilizzare il controllo delle versioni dei file o l'impronta digitale (file.12345.js) per generare nuovi nomi di file quando vengono apportate modifiche significative in modo che Google debba scaricare la versione aggiornata della risorsa per il rendering.
Potresti non vedere ciò che viene mostrato a Googlebot
Potrebbe essere necessario modificare l'agente utente per diagnosticare correttamente alcuni problemi. Il contenuto può essere reso in modo diverso per diversi user-agent o persino IP. Dovresti controllare cosa vede effettivamente Google con i suoi strumenti di test e ne parlerò tra poco.
Puoi impostare uno user-agent personalizzato con Chrome DevTools per risolvere i problemi dei siti che eseguono il prerendering in base a user-agent specifici oppure puoi farlo facilmente con la nostra barra degli strumenti anche.
Utilizza polyfill per funzionalità non supportate
Possono esserci funzionalità utilizzate dagli sviluppatori che Googlebot non supporta. I tuoi sviluppatori possono utilizzare rilevamento delle caratteristiche. E se manca una funzionalità, possono scegliere di ignorare tale funzionalità o utilizzare un metodo di fallback con a polifill per vedere se riescono a farlo funzionare.
Questo è principalmente una questione di informazione per i SEO. Se vedi qualcosa che ritieni che Google dovrebbe vedere e invece non lo vede, potrebbe essere a causa dell'implementazione.
Usa il caricamento lento
Da quando l'ho scritto originariamente, il caricamento lento è passato per lo più dall'essere guidato da JavaScript all'essere gestito dai browser.
Potresti comunque imbatterti in alcune configurazioni di caricamento lento basate su JavaScript. Per la maggior parte, probabilmente vanno bene se il caricamento lento riguarda le immagini. La cosa principale che controllerei è vedere se il contenuto viene caricato in modo lento. Fai riferimento alla sezione "Verifica se Google vede i tuoi contenuti" sopra. Questi tipi di configurazioni hanno causato problemi con la corretta acquisizione dei contenuti.
Problemi di scorrimento infinito
Se disponi di un'impostazione di scorrimento infinito, consiglio comunque una versione di pagina impaginata in modo che Google possa comunque eseguire la scansione correttamente.
Un altro problema che ho riscontrato con questa configurazione è che, occasionalmente, due pagine vengono indicizzate come una. L'ho visto alcune volte quando le persone dicevano che non potevano indicizzare la loro pagina. Ma ho trovato il loro contenuto indicizzato come parte di un'altra pagina che di solito è il loro post precedente.
La mia teoria è che quando Google ha ridimensionato il viewport per renderlo più lungo (ne parleremo più avanti), ha attivato lo scorrimento infinito e ha caricato un altro articolo durante il rendering. In questo caso, quello che consiglio è di bloccare il file JavaScript che gestisce lo scorrimento infinito in modo che la funzionalità non possa attivarsi.
Problemi di prestazione
Molti framework JavaScript si occupano di un sacco di moderne ottimizzazioni delle prestazioni per te.
Tutte le tradizionali migliori pratiche relative alle prestazioni sono ancora valide, ma ottieni alcune nuove fantasiose opzioni. La suddivisione del codice suddivide i file in file più piccoli. Lo scuotimento dell'albero fa uscire le parti necessarie, quindi non stai caricando tutto per ogni pagina come vedresti nelle tradizionali configurazioni monolitiche.
Le configurazioni JavaScript fatte bene sono una cosa meravigliosa. Le configurazioni JavaScript non eseguite correttamente possono essere gonfiate e causare tempi di caricamento lunghi.
Controlla il nostro Guida ai Segnali Web fondamentali per ulteriori informazioni sulle prestazioni del sito web.
I siti JavaScript utilizzano un budget di scansione maggiore
Le richieste JavaScript XHR mangiano budget per la ricerca per indicizzazione, e intendo dire che lo divorano. A differenza della maggior parte delle altre risorse memorizzate nella cache, queste vengono recuperate in tempo reale durante il processo di rendering.
Un altro dettaglio interessante è che il servizio di rendering cerca di non recuperare risorse che non contribuiscono al contenuto della pagina. Se si sbaglia, potresti perdere alcuni contenuti.
I lavoratori non sono supportati, oppure sì?
Mentre Google storicamente afferma di rifiutare i lavoratori dei servizi e che i lavoratori dei servizi non possono modificare il DOM, Martin Splitt di Google ha indicato che a volte potresti farla franca utilizzando i lavoratori web.
Utilizza connessioni HTTP
Googlebot supporta le richieste HTTP ma non supporta altri tipi di connessione come WebSockets or WebRTC. Se li utilizzi, fornisci un fallback che utilizzi le connessioni HTTP.
Un problema con i siti JavaScript è che possono eseguire aggiornamenti parziali del DOM. Navigare su un'altra pagina come utente potrebbe non aggiornare alcuni aspetti come i tag del titolo o i tag canonici nel DOM, ma questo potrebbe non essere un problema per i motori di ricerca.
Google carica ogni pagina senza stato come se fosse un nuovo caricamento. Non salva le informazioni precedenti e non naviga tra le pagine.
Ho visto i SEO inciampare pensando che ci fosse un problema a causa di ciò che vedono dopo aver navigato da una pagina all'altra, come un tag canonico che non si aggiorna. Ma Google potrebbe non vedere mai questo stato.
Gli sviluppatori possono risolvere questo problema aggiornando lo stato utilizzando il cosiddetto file API History. Ma ancora una volta, potrebbe non essere un problema. Nella maggior parte dei casi, sono solo i SEO a creare problemi agli sviluppatori perché a loro sembra strano. Aggiorna la pagina e guarda cosa vedi. O meglio ancora, eseguilo attraverso uno degli strumenti di test di Google per vedere cosa vede.
A proposito dei suoi strumenti di test, parliamo di quelli.
Strumenti di test di Google
Google dispone di diversi strumenti di test utili per JavaScript.
Strumento di controllo URL in Google Search Console
Questa dovrebbe essere la tua fonte di verità. Quando controlli un URL, otterrai molte informazioni su ciò che Google ha visto e sull'HTML effettivamente visualizzato dal suo sistema.
Hai anche la possibilità di eseguire un test dal vivo.
Ci sono alcune differenze tra il renderer principale e il test live. Il renderer utilizza le risorse memorizzate nella cache ed è abbastanza paziente. Il test live e altri strumenti di test utilizzano risorse live e interrompono anticipatamente il rendering perché stai aspettando un risultato. Ne parlerò più dettagliatamente nella sezione rendering più avanti.
Gli screenshot in questi strumenti mostrano anche le pagine con i pixel dipinti, cosa che Google in realtà non fa durante il rendering di una pagina.
Gli strumenti sono utili per vedere se il contenuto è caricato DOM. L'HTML mostrato in questi strumenti è il DOM renderizzato. Puoi cercare uno snippet di testo per vedere se è stato caricato per impostazione predefinita.
Gli strumenti mostreranno anche le risorse che potrebbero essere bloccate e i messaggi di errore della console, utili per il debug.
Se non hai accesso alla proprietà di Google Search Console per un sito web, puoi comunque eseguirne un test in tempo reale. Se aggiungi un reindirizzamento sul tuo sito web su una proprietà in cui hai accesso a Google Search Console, puoi controllare quell'URL e lo strumento di ispezione seguirà il reindirizzamento e ti mostrerà il risultato del test in tempo reale per la pagina sull'altro dominio.
Nello screenshot qui sotto, ho aggiunto un reindirizzamento dal mio sito alla home page di Google. Il test live per questo segue il reindirizzamento e mi mostra la home page di Google. In realtà non ho accesso all'account Google Search Console di Google, anche se vorrei averlo fatto.
Strumento di test con risultati avanzati
I Strumento di test con risultati avanzati ti consente di controllare la pagina visualizzata come la vedrebbe Googlebot per dispositivi mobili o desktop.
Strumento di test ottimizzato per dispositivi mobili
Puoi ancora usare il Strumento di test ottimizzato per dispositivi mobili per ora, ma Google ha annunciato che chiuderà nel dicembre 2023.
Ha le stesse peculiarità degli altri strumenti di test di Google.
Ahrefs
Ahrefs è l'unico importante strumento SEO che esegue il rendering delle pagine Web durante la scansione del Web, quindi disponiamo di dati provenienti da siti JavaScript che nessun altro strumento ottiene. Eseguiamo il rendering di circa 200 milioni di pagine al giorno, ma si tratta di una frazione di ciò che effettuiamo la scansione.
Ci consente di verificare i reindirizzamenti JavaScript. Possiamo anche mostrare i link che abbiamo trovato inseriti con JavaScript, che mostriamo con un tag JS nei report dei link:
Nel menu a discesa per le pagine in Site Explorer, disponiamo anche di un'opzione di ispezione che ti consente di visualizzare la cronologia di una pagina e confrontarla con altre scansioni. Abbiamo un indicatore JS lì per le pagine renderizzate con JavaScript abilitato.
Puoi abilitare JavaScript in Site Audit esegue la scansione per sbloccare più dati nei tuoi controlli.
Se hai abilitato il rendering JavaScript, forniremo l'HTML grezzo e renderizzato per ogni pagina. Utilizza l'opzione "lente di ingrandimento" accanto a una pagina in Page Explorer e vai su "Visualizza sorgente" nel menu. Puoi anche confrontare le scansioni precedenti ed eseguire ricerche all'interno dell'HTML grezzo o renderizzato in tutte le pagine del sito.
Se esegui una scansione senza JavaScript e poi un'altra con esso, puoi utilizzare le nostre funzionalità di confronto della scansione per vedere le differenze tra le versioni.
Ahrefs' Barra degli strumenti SEO supporta anche JavaScript e ti consente di confrontare l'HTML con le versioni renderizzate dei tag.
Visualizza la fonte e controlla
Quando fai clic con il pulsante destro del mouse in una finestra del browser, vedrai un paio di opzioni per visualizzare il codice sorgente della pagina e per ispezionare la pagina. Visualizza sorgente ti mostrerà lo stesso di una richiesta GET. Questo è l'HTML grezzo della pagina.
Inspect mostra il DOM elaborato dopo che sono state apportate le modifiche ed è più vicino al contenuto visto da Googlebot. È la pagina dopo che JavaScript è stato eseguito e ha apportato modifiche ad essa.
Dovresti utilizzare principalmente l'ispezione sull'origine della vista quando lavori con JavaScript.
A volte è necessario controllare l'origine della vista
Poiché Google esamina per alcuni problemi sia l'HTML grezzo che quello renderizzato, a volte potresti comunque dover controllare l'origine della visualizzazione. Ad esempio, se gli strumenti di Google ti dicono che la pagina è contrassegnata come noindex, ma non vedi un tag noindex nell'HTML visualizzato, è possibile che fosse presente nell'HTML non elaborato e sovrascritto.
Per cose come noindex, nofollow e tag canonici, potrebbe essere necessario controllare l'HTML non elaborato poiché i problemi possono persistere. Ricorda che Google prenderà in considerazione le dichiarazioni più restrittive viste per i tag meta robots e ignorerà i tag canonici quando gli mostri più tag canonici.
Non navigare con JavaScript disattivato
Ho visto questo consiglio troppe volte. Google esegue il rendering di JavaScript, quindi ciò che vedi senza JavaScript non è affatto simile a ciò che vede Google. Questo è semplicemente stupido.
Non utilizzare Google Cache
La cache di Google non è un modo affidabile per verificare ciò che vede Googlebot. Ciò che in genere vedi nella cache è l'istantanea HTML non elaborata. Il tuo browser quindi attiva il JavaScript a cui si fa riferimento nell'HTML. Non è quello che Google ha visto quando ha renderizzato la pagina.
Per complicare ulteriormente il tutto, i siti web potrebbero avere il loro Condivisione di risorse tra le origini (CORS) policy impostata in modo tale che le risorse richieste non possano essere caricate da un dominio diverso.
La cache è ospitata su webcache.googleusercontent.com. Quando quel dominio tenta di richiedere le risorse dal dominio effettivo, la policy CORS dice: "No, non puoi accedere ai miei file". Quindi i file non vengono caricati e la pagina appare interrotta nella cache.
Il sistema di cache è stato creato per vedere il contenuto quando un sito web non è disponibile. Non è particolarmente utile come strumento di debug.
Agli albori dei motori di ricerca, era sufficiente una risposta HTML scaricata per vedere il contenuto della maggior parte delle pagine. Grazie all’avvento di JavaScript, i motori di ricerca ora devono visualizzare molte pagine come farebbe un browser in modo da poter vedere i contenuti così come li vede un utente.
Il sistema che gestisce il processo di rendering su Google si chiama Web Rendering Service (WRS). Google ha fornito un diagramma semplicistico per spiegare come funziona questo processo.
Diciamo che iniziamo il processo dall'URL.
1. cingolato
Il crawler invia richieste GET al server. Il server risponde con le intestazioni e il contenuto del file, che poi viene salvato. Le intestazioni e il contenuto in genere rientrano nella stessa richiesta.
È probabile che la richiesta provenga da uno user-agent mobile poiché Google è attivo indicizzazione mobile-first ora, ma esegue ancora la scansione con lo user-agent desktop.
Le richieste provengono principalmente da Mountain View (CA, USA), ma anche da lì alcuni crawling per pagine adattate alle impostazioni locali al di fuori degli Stati Uniti Come accennato in precedenza, ciò può causare problemi se i siti bloccano o trattano i visitatori di un paese specifico in modi diversi.
È anche importante notare che mentre Google dichiara l'output del processo di scansione come "HTML" nell'immagine sopra, in realtà sta eseguendo la scansione e memorizzando le risorse necessarie per creare la pagina come HTML, file JavaScript e file CSS. Esiste anche un limite di dimensione massima di 15 MB per i file HTML.
2. in lavorazione
Ci sono molti sistemi offuscati dal termine “Elaborazione” nell’immagine. Tratterò alcuni di questi che sono rilevanti per JavaScript.
Risorse e collegamenti
Google non naviga da una pagina all'altra come farebbe un utente. Parte dell'"Elaborazione" consiste nel controllare la pagina per i collegamenti ad altre pagine e file necessari per creare la pagina. Questi collegamenti vengono estratti e aggiunti alla coda di scansione, che è ciò che Google utilizza per stabilire le priorità e pianificare la scansione.
Google estrarrà i collegamenti alle risorse (CSS, JS, ecc.) necessari per creare una pagina da cose come <link> tag.
Come già menzionato, link interni aggiunto con JavaScript non verrà rilevato fino a dopo il rendering. Dovrebbe essere un processo relativamente rapido e non motivo di preoccupazione nella maggior parte dei casi. Cose come i siti di notizie potrebbero essere l'eccezione in cui ogni secondo conta.
Caching
Ogni file scaricato da Google, incluse pagine HTML, file JavaScript, file CSS, ecc., verrà memorizzato nella cache in modo aggressivo. Google ignorerà i tempi della cache e recupererà una nuova copia quando lo desidera. Parlerò ancora un po' di questo e del perché è importante nella sezione “Renderer”.
Eliminazione duplicata
Il contenuto duplicato può essere eliminato o privato della priorità dall'HTML scaricato prima che venga inviato al rendering. Ne ho già parlato nella sezione “Contenuti duplicati” sopra.
Direttive più restrittive
Come ho detto prima, Google sceglierà il più restrittivo dichiarazioni tra HTML e la versione renderizzata di una pagina. Se JavaScript modifica un'istruzione e ciò è in conflitto con l'istruzione HTML, Google obbedirà semplicemente a quella più restrittiva. Noindex sovrascriverà l'indice e noindex in HTML salterà del tutto il rendering.
3. Coda di rendering
Una delle maggiori preoccupazioni di molti SEO con JavaScript e l'indicizzazione a due fasi (HTML e pagina renderizzata) è che le pagine potrebbero non essere visualizzate per giorni o addirittura settimane. Quando Google ha esaminato questo aspetto, ha scoperto le pagine sono arrivate al renderer in un tempo medio di cinque secondie il 90° percentile era minuti. Pertanto, nella maggior parte dei casi, il tempo che intercorre tra l'acquisizione dell'HTML e il rendering delle pagine non dovrebbe essere un problema.
Tuttavia, Google non esegue il rendering di tutte le pagine. Come accennato in precedenza, una pagina con un meta tag robots o un'intestazione contenente un tag noindex non verrà inviata al renderer. Non sprecherà risorse visualizzando una pagina che non può comunque indicizzare.
Ha anche controlli di qualità in questo processo. Se esamina l'HTML o può ragionevolmente determinare da altri segnali o modelli che una pagina non è di qualità sufficientemente buona da indicizzare, non si preoccuperà di inviarlo al renderer.
C'è anche una stranezza con i siti di notizie. Google vuole indicizzare rapidamente le pagine dei siti di notizie in modo da poter indicizzare prima le pagine in base al contenuto HTML e tornare successivamente per visualizzare queste pagine.
4. Rendering
Il renderer è il luogo in cui Google esegue il rendering di una pagina per vedere ciò che vede un utente. Qui è dove elaborerà JavaScript e tutte le modifiche apportate da JavaScript al file DOM.
Per questo, Google utilizza un browser Chrome headless che ora è “sempreverde”, il che significa che dovrebbe utilizzare l’ultima versione di Chrome e supportare le funzionalità più recenti. Anni fa, Google eseguiva il rendering con Chrome 41 e all'epoca molte funzionalità non erano supportate.
Google ha di più informazioni sul WRS, che include cose come negare le autorizzazioni, essere senza stato, appiattire il DOM chiaro e il DOM ombra e altro ancora che vale la pena leggere.
Il rendering su scala web potrebbe essere l'ottava meraviglia del mondo. È un'impresa seria e richiede un'enorme quantità di risorse. A causa delle dimensioni, Google sta adottando molte scorciatoie con il processo di rendering per accelerare le cose.
Risorse memorizzate nella cache
Google fa molto affidamento sulle risorse di memorizzazione nella cache. Le pagine vengono memorizzate nella cache. I file vengono memorizzati nella cache. Quasi tutto viene memorizzato nella cache prima di essere inviato al renderer. Non scarica ogni risorsa per ogni caricamento di pagina, perché sarebbe costoso per lui e per i proprietari del sito web. Utilizza invece queste risorse memorizzate nella cache per essere più efficiente.
L'eccezione è rappresentata dalle richieste XHR, che il renderer eseguirà in tempo reale.
Non è previsto un timeout di cinque secondi
Un mito SEO comune è che Google aspetti solo cinque secondi per caricare la tua pagina. Sebbene sia sempre una buona idea rendere il tuo sito più veloce, questo mito non ha molto senso considerando il modo in cui Google memorizza nella cache i file sopra menzionati. Sta già caricando una pagina con tutto ciò che è memorizzato nella cache dei suoi sistemi, senza effettuare richieste di nuove risorse.
Se aspettasse solo cinque secondi, perderebbe molti contenuti.
Il mito probabilmente deriva da strumenti di test come lo strumento di controllo URL in cui le risorse vengono recuperate in tempo reale anziché memorizzate nella cache e devono restituire un risultato agli utenti entro un periodo di tempo ragionevole. Potrebbe anche derivare da pagine a cui non è stata assegnata la priorità per la scansione, il che fa pensare alle persone di aspettare molto tempo per visualizzarle e indicizzarle.
Non esiste un timeout fisso per il renderer. Funziona con un timer accelerato per vedere se viene aggiunto qualcosa in un secondo momento. Controlla anche il ciclo degli eventi nel browser per vedere quando sono state eseguite tutte le azioni. È davvero paziente e non dovresti preoccuparti di alcun limite di tempo specifico.
È paziente, ma dispone anche di misure di sicurezza nel caso in cui qualcosa si blocchi o qualcuno stia tentando di estrarre Bitcoin dalle sue pagine. Sì, è una cosa. Abbiamo dovuto aggiungere protezioni anche per il mining di Bitcoin pubblicato uno studio a proposito.
Ciò che vede Googlebot
Googlebot non esegue azioni sulle pagine web. Non farà clic su elementi o scorrerà, ma ciò non significa che non abbia soluzioni alternative. Finché il contenuto viene caricato nel DOM senza un'azione necessaria, Google lo vedrà. Se non viene caricato nel DOM fino a dopo un clic, il contenuto non verrà trovato.
Google non ha bisogno di scorrere per vedere i tuoi contenuti perché ha una soluzione intelligente per vedere i contenuti. Per i dispositivi mobili, carica la pagina con una dimensione dello schermo di 411×731 pixel e ridimensiona la lunghezza a 12,140 pixel.
In sostanza, diventa un telefono davvero lungo con una dimensione dello schermo di 411×12140 pixel. Per desktop fa lo stesso e passa da 1024×768 pixel a 1024×9307 pixel. Non ho visto alcun test recente per questi numeri e potrebbe cambiare a seconda della lunghezza delle pagine.
Un'altra scorciatoia interessante è che Google non dipinge i pixel durante il processo di rendering. Sono necessari tempo e risorse aggiuntive per completare il caricamento di una pagina e non è necessario vedere lo stato finale con i pixel dipinti. Inoltre, le schede grafiche sono costose tra giochi, mining di criptovalute e intelligenza artificiale.
Google ha solo bisogno di conoscere la struttura e il layout e lo ottiene senza dover effettivamente dipingere i pixel. COME martyn lo mette:
Nella ricerca di Google non ci preoccupiamo veramente dei pixel perché non vogliamo davvero mostrarli a qualcuno. Vogliamo elaborare le informazioni e le informazioni semantiche, quindi abbiamo bisogno di qualcosa nello stato intermedio. Non dobbiamo effettivamente dipingere i pixel.
Un'immagine può aiutare a spiegare un po' meglio cosa è stato tagliato. In Chrome Dev Tools, se esegui un test nella scheda "Prestazioni", ottieni un grafico di caricamento. La parte verde continua qui rappresenta la fase di verniciatura. Per Googlebot ciò non accade mai, quindi consente di risparmiare risorse.
Gray = Download
Blu = HTML
Giallo =JavaScript
Viola = Disposizione
Green = Pittura
5. Scansiona la coda
Google ha una risorsa che parla un po' del crawl budget. Ma dovresti sapere che ogni sito ha il proprio budget di scansione e ad ogni richiesta deve essere assegnata una priorità. Google deve anche bilanciare la scansione delle tue pagine rispetto a quella di ogni altra pagina su Internet.
I siti più recenti in generale o i siti con molte pagine dinamiche verranno probabilmente sottoposti a scansione più lentamente. Alcune pagine verranno aggiornate meno spesso di altre e alcune risorse potrebbero anche essere richieste meno frequentemente.
Ci sono molte opzioni quando si tratta di eseguire il rendering di JavaScript. Google ha un grafico solido che mostrerò. Qualsiasi tipo di SSR, rendering statico e configurazione di prerendering andrà bene per i motori di ricerca. Gatsby, Next, Nuxt, ecc., sono tutti fantastici.
Il più problematico sarà il rendering completo lato client in cui tutto il rendering avviene nel browser. Anche se Google probabilmente accetterà il rendering lato client, è meglio scegliere un'opzione di rendering diversa per supportarne altre motori di ricerca.
Anche Bing lo ha fatto supporto per il rendering JavaScript, ma la scala è sconosciuta. Yandex e Baidu hanno un supporto limitato da quello che ho visto e molti altri motori di ricerca hanno poco o nessun supporto per JavaScript. Il nostro motore di ricerca, Sì, dispone del supporto ed eseguiamo il rendering di circa 200 milioni di pagine al giorno. Ma non eseguiamo il rendering di ogni pagina di cui eseguiamo la scansione.
C'è anche la possibilità di resa dinamica, che viene visualizzato per determinati user-agent. Questa è una soluzione alternativa e, a dire il vero, non l'ho mai consigliata e sono felice che Google la sconsigli anche adesso.
A seconda della situazione, potresti volerlo utilizzare per eseguire il rendering di determinati bot come i motori di ricerca o anche i bot dei social media. I bot dei social media non eseguono JavaScript, quindi cose del genere Tag OG non verrà visualizzato a meno che non esegui il rendering del contenuto prima di offrirglielo.
In pratica, rende le configurazioni più complesse e più difficili da risolvere per i SEO. Lo è sicuramente cloaking, anche se Google dice che non lo è e che va bene così.
Note:
Se stavi usando il vecchio Schema di scansione AJAX con hashbang (#!), sappi che è stato deprecato e non è più supportato.
Conclusioni
JavaScript non è qualcosa di cui i SEO devono aver paura. Speriamo che questo articolo ti abbia aiutato a capire come lavorarci meglio.
Non aver paura di contattare i tuoi sviluppatori, lavorare con loro e porre loro domande. Saranno i tuoi più grandi alleati per aiutarti a migliorare il tuo sito JavaScript per i motori di ricerca.
Hai domande? Fammi sapere su Twitter.
Ulteriori letture
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
- PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
- PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
- Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
- Fonte: https://ahrefs.com/blog/javascript-seo/
