Seo Office Hours, 1 luglio 2022

Questo è un riepilogo delle domande e risposte più interessanti del Google SEO Office Hours con John Mueller del 1 luglio 2022.

PageSpeed ​​Insights o Google Search Console: quale è più accurato?

0:44 “Quando controllo il mio punteggio di PageSpeed ​​Insights sul mio sito web, vedo un semplice numero. Perché questo non corrisponde a ciò che vedo in Search Console e nel rapporto Core Web Vitals? Quale di questi numeri è corretto?"

Secondo John: “[…] Non esiste un numero corretto quando si tratta di velocità ‒ quando si tratta di capire come si comporta il tuo sito web per i tuoi utenti. In PageSpeed ​​Insights, per impostazione predefinita, mostriamo un singolo numero che è un punteggio da 0 a 100, che si basa su una serie di ipotesi in cui assumiamo che cose diverse siano un po' più veloci o più lente per gli utenti. E sulla base di questo, calcoliamo un punteggio.

In Search Console, abbiamo le informazioni di Core Web Vitals , che si basano su tre numeri per velocità, reattività e interattività. E questi numeri sono leggermente diversi, ovviamente, perché sono tre numeri, non solo un numero. Ma, inoltre, c'è una grande differenza nel modo in cui questi numeri sono determinati. Vale a dire, c'è una differenza tra i cosiddetti dati di campo e dati di laboratorio.

I dati sul campo sono ciò che gli utenti hanno visto quando visitano il tuo sito web. E questo è ciò che utilizziamo in Search Console. Questo è ciò che utilizziamo anche per la ricerca. Considerando che i dati di laboratorio sono una visione teorica del tuo sito Web, in cui i nostri sistemi hanno determinati presupposti in cui pensano, beh, l'utente medio probabilmente è così, usando questo tipo di dispositivo e con questo tipo di connessione, forse. E sulla base di queste ipotesi, stimeremo quali potrebbero essere quei numeri per un utente medio. Puoi immaginare che queste stime non saranno mai corrette al 100%.

Allo stesso modo, i dati che gli utenti hanno visto ‒ che cambieranno nel tempo, anche quando alcuni utenti potrebbero avere una connessione molto veloce o un dispositivo veloce e tutto va veloce sul loro sito Web o quando visitano il tuo sito Web, e altri potrebbero non avere quello. E per questo motivo, questa variazione può sempre comportare numeri diversi.

La nostra raccomandazione è generalmente di utilizzare i dati sul campo, i dati che vedresti in Search Console, come un modo per capire qual è la situazione attuale del nostro sito Web, e quindi di utilizzare i dati di laboratorio, ovvero i singoli test che puoi eseguire direttamente te stesso, per ottimizzare il tuo sito web e cercare di migliorare le cose. E quando sei abbastanza soddisfatto dei dati di laboratorio che ottieni con la tua nuova versione del tuo sito web, nel tempo puoi raccogliere i dati sul campo, cosa che avviene automaticamente, e ricontrollare che gli utenti li considerino più veloci o anche più reattivo.

Quindi, in breve, ancora una volta, non esiste un numero corretto quando si tratta di una di queste metriche. […] Ma, piuttosto, ci sono diversi presupposti e diversi modi di raccogliere i dati, e ognuno di questi è leggermente diverso”.

Perché Googlebot ha difficoltà a indicizzare le pagine basate su JavaScript?

4:19 “Abbiamo alcune pagine di clienti che utilizzano Next.js senza un file robots.txt o sitemap. Teoricamente, Googlebot può raggiungere tutte queste pagine, ma perché solo la home page viene indicizzata? Non sono presenti errori o avvisi in Search Console. Perché Googlebot non trova le altre pagine?"

John ha detto: "[...] Next.js è un framework JavaScript, il che significa che l'intera pagina viene generata con JavaScript. Ma anche una risposta generale a tutte queste domande come perché Google non indicizza tutto: è importante innanzitutto dire che Googlebot non indicizzerà mai tutto su un sito web. Non credo succeda a nessun sito web di dimensioni non banali che Google si spenga e indicizzi completamente tutto. Da un punto di vista pratico, non è possibile indicizzare tutto su tutto il web. In modo che il presupposto che la situazione ideale sia tutto è indicizzato ‒ lo lascerei da parte e direi che vuoi che Googlebot si concentri sulle pagine importanti.

L'altra cosa, però, che è diventata un po' più chiara quando, penso, la persona mi ha contattato su Twitter e mi ha fornito un po' più di informazioni sul suo sito Web, è stato che il modo in cui il sito Web generava collegamenti alle altre pagine era in un modo che Google non è stato in grado di cogliere. Quindi, in particolare, con JavaScript, puoi prendere qualsiasi elemento su una pagina HTML e dire, se qualcuno fa clic su questo, esegui questo pezzo di JavaScript. E quel pezzo di JavaScript può essere quello di passare a una pagina diversa, ad esempio. E Googlebot non fa clic su tutti gli elementi per vedere cosa succede ma, piuttosto, andiamo a cercare i normali collegamenti HTML, che è il modo tradizionale e normale con cui ti colleghi alle singole pagine di un sito web.

E, con questo framework, non ha generato questi normali collegamenti HTML. Quindi non siamo stati in grado di riconoscere che c'è altro da scansionare, più pagine da guardare. E questo è qualcosa che puoi correggere nel modo in cui implementi il ​​tuo sito JavaScript. Abbiamo un sacco di informazioni sul sito di Documentazione per gli sviluppatori di ricerca su JavaScript e SEO, in particolare, sull'argomento dei collegamenti perché ogni tanto viene fuori. Esistono molti modi creativi per creare collegamenti e Googlebot ha bisogno di trovare quei collegamenti HTML per farlo funzionare. […]”

E fatta eccezione per la documentazione ufficiale di Google, dai un'occhiata alla Guida definitiva alla SEO JavaScript sul nostro blog. “

Il collegamento alle pagine HTTP influenza la SEO del tuo sito web?

7:35 "Influisce negativamente sul mio punteggio SEO se la mia pagina si collega a un sito Web esterno non sicuro? Quindi su HTTP, non HTTPS.

John ha detto: “Prima di tutto, non abbiamo una nozione di punteggio SEO, quindi non devi preoccuparti del punteggio SEO.

Ma, a prescindere, capisco che la domanda sia del tipo: è male se mi collego a una pagina HTTP anziché a una pagina HTTPS. E, dal nostro punto di vista, va benissimo. Se queste pagine sono su HTTP, allora è a questo che ti collegheresti. Questo è ciò che gli utenti si aspetterebbero di trovare. Non c'è niente contro il collegamento a siti del genere. Non c'è alcun inconveniente per il tuo sito web per evitare di collegarsi a pagine HTTP perché sono vecchie o croccanti e non così belle come su HTTPS. Non mi preoccuperei di questo".

Dovresti eliminare il tuo file di disconoscimento?

10:16 “Negli ultimi 15 anni, ho rinnegato oltre 11.000 link in totale. […] I collegamenti che ho sconfessato potrebbero provenire da siti compromessi o da contenuti senza senso, generati automaticamente. Dal momento che Google ora afferma di avere strumenti migliori per non includere questi tipi di link compromessi o spam nei loro algoritmi, dovrei eliminare il mio file di disconoscimento? C'è qualche rischio o svantaggio nella semplice eliminazione?"

John ha risposto: "[...] Rinnegare i collegamenti è sempre uno di quegli argomenti complicati perché sembra che Google probabilmente non ti stia dicendo tutte le informazioni.

Ma, dal nostro punto di vista, […] lavoriamo sodo per evitare di prendere in considerazione questi collegamenti. E lo facciamo perché sappiamo che lo strumento Disavow links è in qualche modo uno strumento di nicchia e i SEO lo sanno, ma la persona media che gestisce un sito Web non ne ha idea. E tutti quei collegamenti che hai menzionato sono il tipo di collegamenti che qualsiasi sito Web ottiene nel corso degli anni. E i nostri sistemi capiscono che queste non sono cose che stai cercando di fare per ingannare i nostri algoritmi.

Quindi, da quel punto di vista, se sei sicuro che non c'è nulla intorno a un'azione manuale che hai dovuto risolvere riguardo a questi collegamenti, eliminerei il file di disconoscimento e […] lascerei tutto da parte. Una cosa che farei personalmente è scaricarlo e farne una copia in modo da avere una registrazione di ciò che hai eliminato. Ma, altrimenti, se sei sicuro che queste sono solo le cose normali e croccanti da Internet, lo cancellerei e andrei avanti. C'è molto di più su cui dedicare il tuo tempo quando si tratta di siti Web che semplicemente rinnegare queste cose casuali che accadono a qualsiasi sito Web sul Web. "

È meglio bloccare la scansione con robots.txt o il meta tag robots?

14:19 “Cosa è meglio: bloccare con robots.txt o usare il meta tag robots sulla pagina? Come possiamo prevenire al meglio la scansione?"

John: “[…] Di recente abbiamo fatto anche un episodio di podcast su questo . Quindi lo verificherei. […]

In pratica, c'è una sottile differenza qui dove, se sei in SEO e hai lavorato con i motori di ricerca, probabilmente lo capisci già. Ma per le persone che sono nuove nell'area, a volte non è chiaro esattamente dove siano tutte queste linee.

Con robots.txt, che è il primo che hai menzionato nella domanda, puoi bloccare la scansione. Così puoi impedire a Googlebot di guardare le tue pagine. E con il meta tag robots, quando Googlebot esamina le tue pagine e vede quel meta tag robots, puoi fare cose come bloccare l'indicizzazione. In pratica, entrambi fanno sì che le tue pagine non vengano visualizzate nei risultati di ricerca, ma sono leggermente diverse.

Quindi, se non possiamo eseguire la scansione, non sappiamo cosa ci stiamo perdendo. E potrebbe essere che diciamo, beh, in realtà, ci sono molti riferimenti a questa pagina. Forse è utile per qualcosa. Non lo sappiamo. E poi quell'URL potrebbe apparire nei risultati di ricerca senza alcuno dei suoi contenuti perché non possiamo guardarlo. Mentre con il meta tag robots, se possiamo guardare la pagina, allora possiamo guardare il meta tag e vedere se c'è un noindex lì, per esempio. Quindi interrompiamo l'indicizzazione di quella pagina e la eliminiamo completamente dai risultati della ricerca.

Quindi, se stai cercando di bloccare la scansione, allora sicuramente robots.txt è la strada da percorrere. Se non vuoi che la pagina appaia nei risultati di ricerca, sceglierei quella che è più facile da implementare. In alcuni siti, è più semplice impostare una casella di controllo che dice che non voglio che questa pagina venga trovata nella ricerca e quindi aggiunge un meta tag noindex. In altri, forse la modifica del file robots.txt è più semplice. [Dipende] da quello che hai lì.

Puoi inserire lo stesso URL all'interno di più file di mappe del sito?

16:40 " Ci sono implicazioni negative nell'avere URL duplicati con attributi diversi nelle tue mappe del sito XML? Ad esempio, un URL in una mappa del sito con un'annotazione hreflang e lo stesso URL in un'altra mappa del sito senza tale annotazione".

John ha detto: “[…] Dal nostro punto di vista, questo va benissimo. […] Questo succede ogni tanto. Alcune persone hanno annotazioni hreflang nei file della mappa del sito specificamente separati e quindi hanno anche un normale file della mappa del sito per tutto. E c'è qualche sovrapposizione lì.

Dal nostro punto di vista, elaboriamo questi file della mappa del sito il più possibile e prendiamo in considerazione tutte queste informazioni. Non c'è alcun aspetto negativo nell'avere lo stesso URL in più file di mappe del sito.  

L'unica cosa a cui starei attento è che non hai informazioni contrastanti in questi file della mappa del sito. Quindi, per esempio, se con le annotazioni hreflang, stai dicendo che questa pagina è per la Germania, e poi sull'altro file della mappa del sito, stai dicendo, beh, in realtà questa pagina è anche per la Francia, […] allora il nostro i sistemi potrebbero essere tipo, beh, cosa sta succedendo qui? Non sappiamo cosa fare con questo mix di annotazioni. E poi può succedere che scegliamo l'uno o l'altro.

Allo stesso modo, se dici che questa pagina è stata modificata l'ultima volta 20 anni fa […], e nell'altro file della mappa del sito, dici, beh, in realtà era cinque minuti fa. Allora i nostri sistemi potrebbero guardarlo e dire, beh, uno di voi ha torto. Non sappiamo quale. Forse seguiremo l'uno o l'altro. Forse ignoreremo completamente la data dell'ultima modifica. Quindi questa è la cosa a cui prestare attenzione.

Ma per il resto, se sono appena menzionati più file della mappa del sito e le informazioni sono coerenti o funzionano insieme, in quanto forse uno ha l'ultima data di modifica, l'altro ha le annotazioni hreflang, va benissimo.

Come impedire l'indicizzazione delle pagine video incorporate?

19:00 “Mi occupo di una piattaforma di riproduzione video e talvolta i nostri incorporamenti vengono indicizzati individualmente. Come possiamo impedirlo?"

John ha risposto: "[...] Ho guardato il sito Web e questi sono iframe che includono una pagina HTML semplificata con un lettore video incorporato.

Da un punto di vista tecnico, se una pagina ha contenuto iframe, vediamo quelle due pagine HTML. Ed è possibile che i nostri sistemi abbiano indicizzato entrambe queste pagine HTML perché sono pagine HTML separate. Uno è incluso nell'altro, di solito, ma teoricamente potrebbero anche stare in piedi da soli.

E c'è un modo per impedirlo, che è una combinazione abbastanza nuova con i meta tag robots che puoi fare, ovvero con il meta tag robots indexifembedded insieme a un meta tag noindex robots .

E sulla versione incorporata, quindi il file HTML con il video direttamente al suo interno, dovresti aggiungere la combinazione di noindex più i meta tag indexifembedded robots. E ciò significherebbe che se troviamo quella pagina individualmente, vedremmo che c'è un noindex [tag]. Non dobbiamo indicizzare questo.

Ma con indexifembedded, ci dice che […] se troviamo questa pagina con il video incorporato nel sito Web generale, possiamo indicizzare il contenuto del video, il che significa che la singola pagina HTML non verrebbe indicizzata. Ma la pagina HTML con l'incorporamento, con le informazioni sul video, sarebbe stata indicizzata normalmente. Quindi questa è la configurazione che userei lì. E questo è un meta tag robot abbastanza nuovo, quindi è qualcosa di cui non tutti hanno bisogno. Perché questa combinazione di contenuto iframe o contenuto incorporato è rara. Ma, per alcuni siti, ha senso farlo in questo modo".