22 gennaio 2019 – Note sull'Hangout della Guida di Google

Questa settimana John è nella Grande Mela, New York. Si è unito a IRL, da sinistra a destra, da Martin Splitt del team Java Script di Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala e Quason Carter. Questa settimana ci sono state alcune grandi domande su Cloudfare, The QRG e The New Page Speed ​​Tool. Il link al video e la trascrizione completa sono disponibili di seguito!

A volte Cloudflare blocca Googlebot?

7:58

"Sì, al momento non so come sia configurato con Cloudflare, ma so che in passato bloccavano le persone che falsificavano Googlebot. Quindi se usi, tipo, il tuo, non lo so, Screaming Rana o qualcosa del genere-- dici, sto usando l'user agent di Googlebot, quindi lo bloccherebbero perché potrebbero dire, ad esempio, che questo non è un Googlebot legittimo. Possiamo bloccarlo. Ma per la maggior parte, penso che abbiano abbastanza pratica per riconoscere i normali Googlebot e consentirne la scansione normale."

Riepilogo: a volte, durante il test può sembrare che Cloudflare stia bloccando Googlebot. Quello che probabilmente sta succedendo qui è che Cloudflare sta bloccando le persone che fingono di essere Googlebot. Pertanto, se utilizzi uno strumento come Screaming Frog e scegli Googlebot come user agent, potresti non essere in grado di eseguire la scansione dei siti utilizzando Cloudflare .

I collegamenti innaturali possono ancora danneggiare un sito in modo algoritmico? In tal caso, l'uso dello strumento di disconoscimento può essere d'aiuto?

14:01

"Penso che fosse una buona domanda. Quindi, dal mio punto di vista, quello che guarderei lì è, da un lato, sicuramente il caso in cui c'è un'azione manuale. Ma anche i casi in cui vuoi anche vedere molte azioni manuali direbbe, beh, se il team di spam web esaminasse questo ora, ti darebbe un'azione manuale. Tipi di casi in cui diresti, beh, l'azione manuale è più una questione di tempo e non come se fosse basato su qualcosa che è stato fatto-- non so-- dove è stato chiaramente fatto un paio di anni fa, e non era un po' al limite, ma il tipo di cose in cui lo guardi e dire, se qualcuno del team di spam web ricevesse questo come suggerimento, intraprenderebbe un'azione manuale, e questo è sicuramente il tipo di cosa in cui lo ripulirei e farei un disconoscimento per quello. Sì, penso è difficile dire se c'è una sequenza temporale specifica. Ma in generale, se il team webspam ha guardato questo e ha detto, come, le cose sono andate avanti. Questo era chiaramente d uno un paio di anni fa. Non era del tutto dannoso. Quindi probabilmente non intraprenderebbero azioni manuali per quello. "

E suppongo che probabilmente non puoi rispondere a questo, ma c'è un modo in cui, ad esempio, diciamo che non abbiamo ricevuto un'azione manuale, o loro non hanno ricevuto un'azione manuale. Questi link possono danneggiarli algoritmicamente? Perché sentiamo di vedere alcuni miglioramenti in alcuni siti, sai, dopo aver sconfessato. Quindi, ancora una volta, so che è sempre... non è mai in bianco e nero.

Questo può sicuramente essere il caso. Quindi è qualcosa in cui i nostri algoritmi quando lo guardiamo e vedono, oh, sono un mucchio di link davvero pessimi qui, quindi forse saranno un po' più cauti riguardo ai link in generale per il sito web. Quindi, se lo ripulisci, gli algoritmi lo guardano e dicono, oh, c'è-- c'è un po'-- va bene. Non è male.

Riepilogo: se disponi di collegamenti creati appositamente per la SEO e ne hai molti, gli algoritmi di Google possono diffidare di tutti i tuoi collegamenti. Meglio rinnegare per casi come questo.

In che modo gli algoritmi di Google misurano l'EAT degli editori?

33:40

"Non lo so. Penso che probabilmente sia difficile da capire algoritmicamente. E se ci fossero cose tecniche che dovresti fare, te lo faremmo sapere. Quindi se ci sono cose come il markup della paternità che noi avuto in alcuni punti che pensiamo possa essere utile per qualcosa del genere, lo porteremmo sicuramente là fuori. Ma molte cose sono davvero più tipi di fattori di qualità morbidi che cerchiamo di capire, e non è qualcosa di tecnico che tu "o stai facendo o non facendo. È più, come, cercare di capire come un utente potrebbe guardare a questo. Quindi non qualcosa di specifico che potrei indicare. "

Riepilogo: Google esamina molti "fattori di qualità morbida". Guarda le cose dal punto di vista di un utente. Inoltre, il markup della paternità può aiutare Google a capire meglio le cose.

Se c'è qualcosa nelle Linee guida per i valutatori della qualità, è ragionevole presumere che Google voglia che ciò si rifletta nei suoi algoritmi?

34:44

Penso che, in generale, sia probabilmente una buona pratica mirare a questo. Evito di concentrarmi troppo su ciò che Google potrebbe utilizzare come fattore algoritmico e di guardarlo più come: pensiamo che sia un bene per il Web e, quindi, cercheremo di andare in quella direzione e fare queste tipo di cose. Quindi non tanto è come se stessi creando un buon sito Web solo per poter classificare meglio, ma sto creando un buon sito Web perché quando mi presento nelle ricerche, voglio che le persone abbiano una buona esperienza. E poi torneranno sul mio sito web e forse compreranno qualcosa. Quindi è un po' la direzione in cui la vedrei, non come, tipo, fare questo per classificarsi, ma farlo per avere una relazione sana ea lungo termine sul web.

Riepilogo: pensa a cosa è meglio per gli utenti. Anche se non tutto ciò che è nel QRG è attualmente riflesso negli algoritmi di Google, questi sono tutti ottimi passi verso il miglioramento della qualità generale.

Esiste uno schema per aiutare i siti ad apparire più in alto per i risultati della ricerca vocale?

36:10

Non lo so. Non riesco a pensare a niente a caso. Quindi c'è il markup dicibile che puoi usare, che è probabilmente ragionevole per-- tipo di guardare per vedere dove potrebbe avere un senso in una pagina. Non credo che lo useremo ancora in tutte le località.

Riepilogo: il markup pronunciabile non è ancora utilizzato in tutte le località geografiche. Ma questo è un buon punto di partenza.

Alcuni suggerimenti per vincere gli snippet in primo piano

38:03

Ma i frammenti in primo piano, in particolare, non penso che abbiamo alcun tipo di markup specifico per quello. Quindi è qualcosa in cui se hai una struttura chiara sulla pagina, questo ci aiuta molto. Se siamo in grado di riconoscere tabelle simili su una pagina, possiamo estrarlo molto più facilmente. Considerando che se usi HTML e CSS fantasiosi per farlo sembrare una tabella, ma in realtà non è una tabella, allora è molto più difficile per noi tirarlo fuori.

Riepilogo: non è possibile aggiungere markup per vincere uno snippet in primo piano. Ma un buon uso dei tag h e delle normali tabelle HTML può davvero aiutare.

Lo schema della posizione deve essere aggiunto a tutte le pagine?

50:47

Risposta 51:42 - Per quanto ne so, è solo la home page. Non lo so. Qualcuno di voi lo conosce?

Risposta da Liz 51:4 7 - Dovrebbe essere solo una pagina di solito con organizzazione e azienda. Questa è generalmente la raccomandazione.

MARTIN SPLITT 52:00 - Immagino che non importi quale-- non importa tanto quali pagine, proprio come non metterle su ogni pagina che hai, immagino, sia la parte più importante. Penso che dipenda da... se sei un sito di notizie, probabilmente ha senso inserirlo nella pagina dei contatti, o nella pagina delle informazioni, o qualcosa del genere. Mentre nel sito di un negozio o di un ristorante, probabilmente va bene inserirlo nella home page.

GIOVANNI 52:20 - Penso anche che in questo caso non ci importi tanto perché dobbiamo riuscire a trovarlo da qualche parte come la home page o la pagina dei contatti. Ma se ce l'abbiamo altrove, per noi non cambia nulla. Quindi la cosa più importante con cui non confrontarlo è il markup della recensione in cui a volte vediamo le persone inserire come una recensione dell'azienda su tutte le pagine del sito Web con la speranza di ottenere le stelle e i risultati di ricerca per ogni pagina del loro sito. E questo sarebbe un male per noi. Ma le informazioni di contatto, se le hai contrassegnate, sono... Non vedo problemi in questo.

Riepilogo: non importa. Dovrebbe essere nella pagina dei contatti e probabilmente nella tua pagina delle informazioni e nella home page. Avere uno schema di posizione nel sito non è un problema, ma probabilmente non è nemmeno necessario.

Perché il nuovo strumento PageSpeed ​​Insights, basato su Lighthouse, è molto più severo quando si valutano i siti Web?

53:05

Marie Haynes: Non è una mia domanda, ma per dare un po' di contesto, i nuovi dati di Lighthouse per la velocità della pagina sono molto più severi di quanto non fossero Page Speed ​​Insights in passato. Quindi qualcosa che ha avuto un punteggio come 80 su Page Speed ​​Insights potrebbe essere un 29 rosso su Lighthouse. Quindi è una buona domanda. È probabile che ciò causi... perché sappiamo che nei dispositivi mobili i siti molto lenti potrebbero essere retrocessi. Quindi è positivo se diciamo, sai, se sei in rosso nel test del faro, che dovremmo davvero migliorare le cose perché potrebbe causare una retrocessione, o c'è un limite?

Risposta 54:07 - Quindi non abbiamo una mappatura uno-a-uno degli strumenti esterni e di tutto ciò che utilizziamo per i social. Sì, questo rende davvero difficile dirlo, ma nella ricerca, proviamo a utilizzare un mix di dati reali, di cosa si tratta, dei test di laboratorio, che è un po' come il test di Lighthouse, e i dati del report di Chrome UX, dove essenzialmente cosa stiamo misurando è ciò che vedrebbero gli utenti del sito web.

MARTIN SPLITT 55:37 - È anche importante vedere che Lighthouse, ad esempio, misura specificamente una connessione 3G sull'estremità mediana-- o come un telefono a prestazioni medie, sì. Quindi, in pratica, se utilizzi un recente Apple McIntosh o un recente computer Windows veloce con una connessione cablata davvero buona o una connessione Wi-Fi davvero buona nel tuo ufficio, ovviamente, stai vedendo un tempo di caricamento di due secondi, ma un vero utente con il proprio telefono in libertà probabilmente non lo sta vedendo. Quindi è uno di questi casi in cui non fa mai male rendere il tuo sito web più veloce, ma questo è davvero, davvero difficile da dire come sembrerebbe dal punto di vista interno, poiché stiamo usando metriche molto specifiche che non stanno necessariamente mappando uno su uno a ciò che gli strumenti stanno esponendo....ovviamente è importante risolverlo, perché non vuoi che i tuoi utenti aspettino sul tuo sito Web per sempre. Questo ti farà male. Questo danneggerà i tuoi utenti. Questo ti farà solo del male nella ricerca. Ma non pago... direi che guarda solo gli strumenti. Se gli strumenti ti dicono che stai andando bene, non dovresti preoccuparti troppo. Se gli strumenti ti dicono che stai andando davvero male, allora penso che il tempo speso a capire perché dice -- tipo, se quello che dice è rilevante, è sprecato. Dovresti piuttosto cercare di rendere il sito più veloce.

Le prestazioni mobili sono un fattore molto importante per i tuoi utenti, così come tutto il resto. Quindi direi di assicurarti che il tuo sito web funzioni bene in condizioni reali. Magari prendi anche un telefono economico e prova il sito web di tanto in tanto, e se... è qualcosa che mi piace fare e che facevo prima di entrare a far parte di Google con il team di sviluppo con cui stavo lavorando. Ero tipo, guarda, vuoi usare questo sito web su questo telefono? Era come, oh, questo è orribile. Dico, mhm, sì, quindi forse dovremmo fare qualcosa al riguardo.

JOHN - In Chrome, puoi configurarlo e provare diverse velocità di connessione. Emulatore mobile. Penso che siano cose davvero buone da guardare e anche, tipo, guardare la tua base di utenti. Guarda i tuoi dati analitici se vedi che le persone stanno usando il tuo sito web solo con un iPhone di fascia alta, allora forse è meno problematico che se vedi che le persone si connettono al tuo sito da connessioni rurali casuali, che sono lento e hanno dispositivi di fascia bassa, quindi forse è di più.

Riepilogo: Lighthouse misura le velocità per una connessione 3G, quindi la maggior parte dei siti funzionerà molto più rapidamente di quanto visualizzato qui per la maggior parte delle sessioni. Nota: dopo che questo Hangout è stato terminato, Martin ha continuato dicendo che è la "prima pittura di contenuto" che è più importante per quanto riguarda le potenziali retrocessioni in classifica.

Se ti piacciono queste cose, amerai la mia newsletter!

Il mio team e io riferiamo ogni settimana sugli ultimi aggiornamenti, notizie e suggerimenti SEO di Google.

Video e trascrizione completa

Domanda 1:32 - Mi chiedevo se avessi più indicazioni o altri punti di vista sui test in un modo che i SEO possano utilizzare per essere più precisi ed essere più sicuri nel riferire all'azienda. Abbiamo provato questa cosa e ha avuto il suo impatto. E l'abbiamo fatto in un modo infallibile, un po' come raccomanderebbe Google.

Risposta 3:20 - Quindi, dal mio punto di vista, cerco di separare le cose di tipo più tecnico da quelle di tipo qualitativo. Quindi qualsiasi cosa che sia davvero una cosa tecnica chiara, puoi praticamente testare se funziona o non funziona. Non è una questione che funzioni o che non funzioni, ma molte di queste cose tecniche, specialmente quando guardi il rendering, o quando guardi Google può effettivamente indicizzare questo contenuto, questo è qualcosa che o funziona o non funziona. Dove diventa complicato è tutto ciò che riguarda: è indicizzato, ma come viene visualizzato nelle classifiche? E penso che per molto di questo, non ci sia un modo assoluto per testarlo davvero. Perché se lo verifichi in una situazione isolata, come se crei un sito di test, e lo configuri con tutti i consigli che hai, non puoi davvero presumere che un sito di test funzionerà allo stesso modo di un normale sito web. A volte ci sono cose semplici, come se fosse un sito di test, allora forse non faremo il rendering completo perché pensiamo che non abbia senso dedicare così tanto tempo a questo e questo, perché, tipo, nessuno lo guarda. Non compare mai nei risultati di ricerca, perché dovremmo preoccuparci di mettere così tante risorse dietro a questo? Mentre se lo facessi su un normale sito Web, funzionerebbe in modo molto diverso. Quindi è qualcosa in cui non ho una guida chiara su cosa dovresti fare o cosa non dovresti fare. Sembra più il genere di cose in cui guardi le tendenze generali in cui vedi che il sito Web viene visualizzato, il tipo di cambiamenti nelle classifiche che stai vedendo per quelle query e provi ad applicare le migliori pratiche lì.

Domanda 5:21 - Quindi forse se-- un esempio concreto forse puoi usarlo per-- forse sarebbe utile, quindi qualcosa come un test del tag del titolo, giusto? Se lo stavi facendo... cosa, semmai, dovremmo cercare? O c'è qualcosa da guardare per districare: è dovuto al nostro test o è dovuto a qualcosa che cambia nel server, nell'algoritmo, nelle dinamiche competitive? [RISATE] Supponendo che stiamo facendo altre cose per guardare a quelle esternalità.

Risposta 5:56 - Penso che una modifica del tag del titolo sia in realtà piuttosto complessa da parte nostra in quanto ci sono una sorta di interazione tra Google utilizza un tag del titolo che stai effettivamente fornendo, da un lato, per la classifica, dal d'altra parte, per la visualizzazione nei risultati della ricerca. Come per desktop e dispositivi mobili, abbiamo una quantità diversa di spazio, quindi potremmo mostrare tag del titolo leggermente diversi. Gli utenti potrebbero rispondere in modi diversi. Quindi potresti classificarti allo stesso modo, ma gli utenti potrebbero pensare, oh, questa è un'ottima pagina. Lo mostrerò più in alto, o lo farò clic su di esso nei risultati di ricerca perché sembra una pagina fantastica. E poi hai più traffico. Ma la classifica è in realtà la stessa. Quindi è una cosa buona? Probabilmente, suppongo. Se stai solo guardando la classifica, allora sembrerebbe che tu non abbia cambiato nulla da nulla e abbiamo solo ottenuto più traffico.

Ma è qualcosa in cui ci sono molti aspetti diversi che fluiscono lì dentro. Quindi è qualcosa in cui penso che, come SEO, sia utile, da un lato, avere la comprensione tecnica di ciò che è successo, ma anche avere una maggiore comprensione del marketing e della qualità di come reagiscono gli utenti al cambiamento, cosa sono cambiamenti a lungo termine che potremmo influenzare con gli utenti, come puoi guidarli per assicurarti che il nostro sito sia visto come il sito più pertinente nelle situazioni in cui le persone cercano qualcosa a tale riguardo. E penso che sia qualcosa che è davvero difficile da testare. È tipo, anche nel marketing tradizionale, dove hanno anni e anni di pratica, è davvero difficile da testare, tipo, questo ha davvero un grande impatto o no? È qualcosa in cui finiscono per guardare il quadro più ampio o fare studi sugli utenti, cosa che puoi fare anche come SEO. Scusate. [RISATA]

Domanda 7:58 - Ho una domanda più diretta. Quindi molti dei nostri siti, sai, stanno utilizzando Cloudflare e abbiamo notato che bloccano direttamente Googlebot, giusto? Ma non ha avuto molto impatto sulle nostre classifiche, sulla nostra visibilità, ecc. Quindi stiamo cercando di capire come, tipo, state usando un altro bot per eseguire la scansione di un indice al di fuori di Googlebot direttamente, e come dovremmo pensarci quando i CDN stanno facendo di tutto per bloccare il bot?

Risposta 8:33 - Sì, al momento non so come sia configurato con Cloudflare, ma so che in passato bloccavano le persone che falsificavano Googlebot. Quindi, se usi, tipo, il tuo, non so, Screaming Frog o qualcosa del genere, dici che sto usando l'agente utente di Googlebot, lo bloccherebbero perché potrebbero dire, tipo, che questo non è un legittimo Googlebot. Possiamo bloccarlo. Ma per la maggior parte, penso che abbiano abbastanza pratica per riconoscere i normali Googlebot e lasciarli strisciare normalmente.

Domanda 9:02 - Sì, è stato interessante. Perché ha contattato un gruppo di colleghi di altre agenzie e stavano replicando situazioni simili anche sul proprio sito. Ad esempio, c'era un ticket di supporto all'interno di Cloudflare e anche quello veniva bloccato quando stavo solo cercando di eseguire il rendering direttamente da Googlebot o smartphone Googlebot.

Risposta 9:21 - OK, sì. Bene, non abbiamo alcuna soluzione. Ad esempio, se i siti Web ci bloccano, siamo un po' bloccati. Ma di solito se un servizio come Cloudflare ci bloccasse per impostazione predefinita, ciò influirebbe su molti siti Web. E lo noteremo. Probabilmente contatteremmo Cloudflare per qualcosa del genere. Potrebbe essere che forse hanno livelli di servizio diversi. Quindi è come se fossi al livello inferiore, allora è come un servizio gratuito, ma abbiamo un limite con la quantità di traffico. Non so se hanno qualcosa del genere. È qualcosa che ho visto con alcuni altri hoster, dove se hai una sorta di configurazione di hosting predefinita gratuita, a volte hanno solo un limite di traffico e bloccano le cose.

MARTIN SPLITT: Potresti non vederlo immediatamente nelle statistiche da come sei in classifica e cose del genere. Perché fondamentalmente, se abbiamo contenuti da te, e fondamentalmente, il sito Web non lo è, a seconda di ciò che è bloccato, in questo caso, significa che non l'ho visto. E gestisco alcuni siti Web dietro Cloudflare e non ho avuto problemi. Ma poi di nuovo, non ho un sito web gigantesco o mi piacciono enormi quantità di traffico perché ho un piano gratuito. Questo è... ma se non ricevi un errore dalla nostra parte, potrebbe essere solo che stiamo mantenendo il contenuto che abbiamo visto l'ultima volta. E questo si classifica bene, e va bene.

Risposta 12:09 - Sì, quindi penso che ciò che accadrebbe in un caso come il tuo è che rallenteremo la scansione. E cercheremmo di mantenere il contenuto che possiamo recuperare di più sull'indice e rieseguiremmo la scansione un po' più a lungo. Ma ciò significa anche che se apporti modifiche al tuo sito web, ci vorrà più tempo per rilevarlo. Se dobbiamo rieseguire la scansione di cose in modo significativo, come, non so, AMP, o se ne aggiungi qualcosa di simile all'intero sito, ci vorrà molto più tempo. Quindi, se vedi davvero regolarmente che non possiamo eseguire la scansione con un normale Googlebot, allora è qualcosa che mi occupo con l'host in modo che possiamo vederlo.

Domanda 14:01 - Ottimo. Quindi ho una domanda sullo strumento di disconoscimento. Quindi otteniamo continuamente persone che vogliono che eseguiamo audit di collegamento. E da Penguin 4.0, quindi settembre del 2016, dove Gary Illyes ha detto, e penso che anche tu abbia detto, tipo, Google è abbastanza bravo a ignorare i collegamenti innaturali. Quindi il mio pensiero in quel momento era, beh, non avremmo dovuto usare lo strumento di rinnegamento per chiedere a Google di ignorare i collegamenti che stanno già ignorando, a meno che tu non abbia un'azione manuale per i collegamenti innaturali. Quindi lo abbiamo consigliato solo a siti che sono stati attivamente, sai, creando collegamenti, cercando di manipolare cose, cose che sono collegamenti innaturali. Ma penso che ci sia così tanta confusione tra i webmaster perché vedo persone tutto il tempo, sai, che fanno pagare tonnellate di denaro per l'audit-- per rinnegare i collegamenti che sono solo-- so che vengono ignorati. Quindi mi piacerebbe se potessimo avere solo un po' più di chiarimento. Quindi forse, se posso farti un esempio, come se ci fosse un imprenditore che, alcuni anni fa, ha assunto una società di SEO, e quella società di SEO ha pubblicato un sacco di guest post solo per i link e, sai, roba che era di qualità media, se capisci cosa intendo, non ultra spam, possiamo essere sicuri che Google stia ignorando quei link? O dovremmo entrare e rinnegare?

Risposta 15:22 - Penso che sia stata una buona domanda. Quindi, dal mio punto di vista, quello che guarderei è, da un lato, che sicuramente il caso è dove c'è un'azione manuale. Ma anche, i casi in cui vuoi vedere anche molte azioni manuali direbbero, beh, se il team di spam web esaminasse ora questo, ti darebbe un'azione manuale. Tipi di casi in cui diresti, beh, l'azione manuale è più una questione di tempo e non un po' come se fosse basata su qualcosa che è stato fatto-- non so-- dove è stato chiaramente fatto un paio d'anni fa, ed era una specie di confine no. Ma il tipo di cose in cui guardi e dici, se qualcuno del team di spam web ricevesse questo come suggerimento, intraprenderebbe un'azione manuale, e questo è sicuramente il tipo di cosa in cui lo ripulirei e lo farei come un disconoscimento per questo. Sì, penso che sia difficile dire se c'è una linea temporale specifica. Ma in generale, se il team di webspam ha guardato questo e ha detto, tipo, le cose sono andate avanti. Questo è stato chiaramente fatto un paio di anni fa. Non era del tutto dannoso. Quindi probabilmente non intraprenderebbero azioni manuali per quello.

Domanda 16:43 - E suppongo che probabilmente non puoi rispondere a questa domanda, ma c'è un modo in cui, ad esempio, diciamo che non abbiamo ricevuto un'azione manuale, o loro non hanno ricevuto un'azione manuale. Questi link possono danneggiarli algoritmicamente? Perché sentiamo di vedere alcuni miglioramenti in alcuni siti, sai, dopo aver sconfessato. Quindi, ancora una volta, so che è sempre... non è mai in bianco e nero.

Risposta 17:03 - Può sicuramente essere così. Quindi è qualcosa in cui i nostri algoritmi quando lo guardiamo e vedono, oh, sono un mucchio di link davvero pessimi qui, quindi forse saranno un po' più cauti riguardo ai link in generale per il sito web. Quindi, se lo ripulisci, gli algoritmi lo guardano e dicono, oh, c'è-- c'è un po'-- va bene. Non è male.

Domanda 17:24 - È comunque bene rinnegare fondamentalmente solo per prevenire un'azione manuale, giusto?

Risposta 17:29 - Penso che se ti trovi in ​​un caso in cui è davvero chiaro che il team di spam web ti darebbe un'azione manuale in base alla situazione attuale, allora è quello che rinnegherei.

Domanda 17:37 - Quindi è bello pensare come da Google, come se qualcuno nel team antispam di Google pensasse, tipo, sai, se guardassero questo, cosa farebbero se lo facessero?

Risposta 17:47 - Sì.

Domanda 17:48 - Il problema, però, è che la maggior parte delle persone non lo sa. Voglio dire, l'imprenditore medio non sa quali link farebbe il team di spam web... Voglio dire, ci sono delle linee guida, ma è molto... sai, è difficile interpretarle. Quindi penso... Voglio dire, ho un paio di preoccupazioni, ma la mia preoccupazione principale è che ci siano persone che spendono un sacco di soldi in audit di link che penso non valgano la pena. D'altra parte, potremmo non eseguire controlli sui link e rinnegare alcuni siti che potrebbero trarne vantaggio. Quindi mi piacerebbe, sai, penso che quello che hai detto ha aiutato molto così che noi... sai, va bene.

Risposta 18:22 - Sì, penso che per la stragrande maggioranza dei siti quel tipo di sito abbia quel normale mix di cose in cui è come se avessi seguito alcuni cattivi consigli in passato, ed è come se fossi andato avanti, e le cose fossero abbastanza naturali ora, allora non hanno davvero bisogno di farlo. Questo è un po' l'obiettivo di tutto questo, ed è per questo che lo strumento di disconoscimento non è come una funzionalità principale in Search Console. Lo cerchi in modo esplicito. È tutto fatto apposta perché per la maggior parte dei siti non è necessario concentrarsi così tanto sui collegamenti. Quello che mi piace dello strumento di disconoscimento, però, è che se sei preoccupato per questo, puoi ancora andare lì ed essere come, OK, so che ci sono queste manciate di cose che abbiamo fatto un paio d'anni fa, e sono davvero preoccupato per questo. Quindi rinnegarli, dal mio punto di vista, non è un problema. Non uscirei e cercherei specificamente tutta quella roba. Ma se lo sai e ne sei davvero preoccupato, allora puoi prendertene cura.

Domanda 19:27 - Ho una domanda su uno dei siti Web dei nostri clienti. Quindi hanno un club attivo... hanno un club in tre città del New South Wales. E ogni club ha un sottodominio sul sito web. Ora, quando aggiungono una pagina al loro sito Web, creano la pagina per ogni sottodominio. Di recente, hanno aggiunto una pagina, che riguarda le attività del loro club, e hanno aggiunto questa pagina ai loro--tutti i sottodomini. Quindi significa che tutti i sottodomini hanno lo stesso contenuto, tranne per il fatto che il titolo della pagina è diverso. Perché quando aggiungono al... per Sydney, aggiungono il nome della loro posizione nel tag del titolo. Quando lo aggiungono per Newcastle, aggiungono Newcastle nel tag del titolo, ma il resto del contenuto della pagina è lo stesso. Quindi sarà un problema perché hanno 50 sottodomini e hanno creato 50 pagine, che hanno lo stesso contenuto tranne il titolo?

Risposta 20:36 - Sembra qualcosa di un po' inefficiente, immagino. Quindi voglio dire, lo stai già tirando fuori e un po' come dire, questo sembra qualcosa che potrebbe essere fatto diversamente. Penso che se ti trovi nel caso in cui hai 50 sottodomini che hanno tutti lo stesso contenuto e stai solo cambiando il tag del titolo, probabilmente non ci stai fornendo molti contenuti davvero utili. Quindi questa è la situazione in cui direi che ha più senso combinare le cose e creare pagine davvero forti piuttosto che diluire le cose in ancora più sottodomini.

Domanda 21:44 - Che ne dici di creare una pagina e quindi utilizzare l'URL canonico per altre pagine di posizione. Voglio solo creare una pagina, di cui parleremo delle loro attività, e userò il collegamento come URL canonico ad altre pagine di posizione.

Risposta 22:10 - Posizione-- sì. Penso che potrebbe avere senso perché poi stai combinando di nuovo le cose. Quindi stai creando una pagina forte piuttosto che un mucchio di pagine diluite.

Domanda 22:20 - Perché cosa succede quando qualcuno visita il sito Web e sceglie la propria posizione, reindirizza automaticamente quella persona a quel sottodominio per il quale ha indicato la sua determinata posizione. Quindi questo è il motivo per cui hanno bisogno della pagina su quel sottodominio. Quindi penso che questo sia il motivo per cui se manteniamo una pagina e aggiungiamo l'URL canonico, quella ha-- è l'unica opzione che abbiamo in questo momento.

Risposta 23:08 - OK, ma penso che se hai pagine separate che devi averle per motivi tecnici sul sito e metti canonico, è un buon approccio.

Domanda 23:21 - Sarebbe come... come un'azienda che ha più franchising in luoghi diversi che avrebbero essenzialmente lo stesso contenuto per ogni franchising sarebbe in una città o township diversa, o qualsiasi altra cosa, e un tipo di imbuto che dal tuo punto di vista torna a una singola pagina?

Risposta 23:34 - Penso che sia sempre un po' complicato perché stai bilanciando le persone che cercano quel tipo di attività in una posizione specifica con una sorta di pagina informativa su quell'attività direttamente. Quindi è qualcosa in cui a volte ha senso averlo separato per un'azienda. A volte ha senso avere un po' di informazioni generali in un posto centrale e avere proprio come-- pagine di destinazione della posizione che sono più focalizzate sull'indirizzo, sugli orari di apertura, su questo genere di cose.

Domanda 24:12 - Sì, ho-- ho una domanda correlata sul punto canonico che stavi sollevando. Questa è una domanda che io e la mia squadra ci poniamo da diversi anni. E ancora non conosciamo esattamente la soluzione. Quindi, se stai gestendo un grande sito di e-commerce con molti, molti prodotti e molte, molte categorie. Diciamo che sei su una pagina di categoria che ha molti filtri e sfaccettature diverse e cose del genere che cambiano leggermente il contenuto della pagina, ma forse non abbastanza da giustificare l'avere il proprio URL. Ma forse in alcuni casi con determinati filtri, giustifica l'avere un URL del sito. Quindi, come gestisci la scansione in quella situazione? Come funziona un tag canonico? È una soluzione generale creare solo una pagina indicizzata? O dovresti guardare, sai, non indicizzare determinati aspetti e filtri, o usare robot, o come lo controlli per i grandi siti di e-commerce?

Risposta 24:57 - È difficile. Non credo che al momento abbiamo una guida molto chiara al riguardo. Quindi è qualcosa in cui tutti questi diversi tipi di metodi possono avere un senso. In generale, cerco di evitare di usare robots.txt per questo perché quello che può succedere è trovare gli URL. Semplicemente non sappiamo cosa ci sia. Quindi, a meno che tu non stia davvero riscontrando problemi che causavano un carico eccessivo sul server, provo a usare cose come no index, uso rel canonical. Forse usi rel no-follow con collegamenti interni a cose di tipo imbuto per rendere un po' più chiaro ciò che dovremmo scansionare un indice piuttosto che usare robots.txt. Ma una specie di decisione su quando combinare le cose in una pagina a livello di indice e quando impedirne l'indicizzazione, quando guidarla dolcemente verso un URL canonico, è-- a volte è davvero complicato.

Domanda 25:53 - Perché a volte i canonici vengono ignorati se il contenuto della pagina è troppo diverso.

Risposta 25:57 - Esattamente. Se il contenuto è diverso, allora potremmo dire, beh, queste sono pagine diverse. Non dovremmo usare il canonico. Mentre potresti dire, beh, questo è davvero qualcosa che non voglio aver indicizzato. Forse un no-index avrebbe più senso di un canonico. Puoi anche combinarli entrambi. Non consigliamo di combinarli perché è davvero difficile per noi dire, beh, cosa intendi? Stai dicendo che questi sono gli stessi, ma uno è indicizzabile e uno non è indicizzabile, quindi non sono gli stessi. Ma è qualcosa in cui immagino che nel corso dell'anno avrà una guida chiara su cosa potrebbe funzionare lì. Ma soprattutto con siti di e-commerce davvero grandi, il lato della scansione può essere piuttosto impegnativo.

Domanda 26:46 - Quindi c'è uno scenario che ho cercato di capire con un paio di miei clienti ultimamente. Stiamo cercando di capire perché non siamo in grado di eliminare essenzialmente un sito che sta ancora utilizzando HTTP e sembra più o meno abbandonato perché la pagina non viene aggiornata da un po' e il contenuto è vecchio, obsoleto e in generale piuttosto sottile, e quindi ho un paio di teorie a riguardo. In parte, penso, forse è stato nell'indice così tanto tempo che avete creato un fattore di fiducia con loro. And it's kind of hard to unseat them. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Domanda 42:29 - Riguardava i siti web delle agenzie di viaggio per viaggiare. Scegliamo la ricerca interna per mostrare contenuti dinamici, come i primi 10 hotel più economici nella città di ricerca, ok? Quindi il frame della pagina viene caricato in un istante. Ma i primi 10 risultati degli hotel più economici si caricano dinamicamente in circa 30 secondi da quando la ricerca è stata eseguita perché il sito Web deve eseguire questa ricerca nella parte posteriore e quindi confronta e perfeziona i risultati per elencare, per il ricercatore, i primi 10 economici alberghi. Quindi ci vuole un po' di tempo per elencarli. Quindi in questo momento Googlebot vede solo lo sfondo della pagina. Quindi quei 10 segnaposto vuoti erano dove i risultati verranno caricati un po' più tardi dopo che la ricerca interna è stata eseguita. Quindi, poiché questa è una tendenza per i siti Web di viaggi a fornire informazioni il più fresche possibile e il più accurate possibile, sto pensando a cosa sta facendo Google al riguardo. Naturalmente, possiamo elencare alcuni contenuti statici su queste pagine come fanno tutti gli altri siti Web al giorno d'oggi per Google, se così posso dire. Ma questo tipo di vanifica lo scopo di ciò che la maggior parte degli utenti vuole vedere ora, fresco ed economico.

Risposta 44:00 - Quindi, se non viene caricato lì, non possiamo indicizzarlo. Ma di solito, è più una questione di noi che non siamo in grado di elaborare JavaScript o forse siamo bloccati dall'accesso effettivo al contenuto lì. Quindi è qualcosa che puoi fare in un modo che funzioni. Non è di progettazione che non funzionerebbe mai. Quindi è qualcosa in cui puoi approfondire i dettagli usando cose come il test ottimizzato per dispositivi mobili per vedere se sono coinvolti errori JavaScript, se le cose sono bloccate e in qualche modo perfezionarlo da lì. Quindi non è impossibile, ma ci vuole un po' di lavoro.

Domanda 44:42 - John, approfondisco questo aspetto assicurandomi che nulla sia bloccato da Google. L'unica cosa che vogliamo che Google faccia è aspettare un po' che i contenuti dinamici vengano caricati sulle pagine, capisci? Questo è il passaggio successivo, se così posso dire perché mentre questa pagina non è come uno scroll senza fine, diciamo Facebook, è una pagina di 10 risultati limitata. Quindi è finito. È limitato. Il fatto è che Google dovrebbe aspettare un po' per il contenuto dinamico. Ti faccio solo un esempio. Ma sono sicuro che ci sono molti altri esempi là fuori in natura. E poiché questa è la tendenza per le persone a vedere contenuti dinamici perché in qualche modo smistano le cose e il tempo che trascorrono sempre meno, le persone trascorrono sempre meno tempo sui siti Web e vogliono trovare il più velocemente possibile il risultati perfetti, se così posso dire. Mi chiedevo se voi ragazzi state guardando verso questo miglioramento.

Risposta 45:55 - Quindi aspettiamo un po' per il rendering. Ma se le persone sono impazienti, allora questo è un segno che dovresti comunque essere più veloce. Quindi è qualcosa su cui lo esaminerei comunque. Ma penso che guardando lo screenshot, come se tutti gli elementi fossero bloccati solo in caselle grigie. Quindi sembra qualcosa che è più un problema tecnico piuttosto che solo un timeout probabilmente.

MARTIN SPLITT : Sì. Stavo per dire, tipo, vediamo molti contenuti dinamici che vengono indicizzati senza problemi, anche se usano come JavaScript e cose del genere. Quindi, se stiamo scadendo, potresti avere un problema in termini di quanto tempo impiegano le ricerche e questo potrebbe effettivamente riflettersi anche altrove. Aspettiamo un po' che i contenuti finiscano.

Domanda 46:48 - Puoi... puoi darmi un lasso di tempo? Quanto aspetti?

MARTIN SPLITT : È davvero, davvero complicato perché fondamentalmente-- quindi il motivo è che non possiamo darti un lasso di tempo è perché il tempo-- e questo suonerà davvero strano, e abbi pazienza per un secondo . Il tempo nel rendering di Googlebots è speciale e non segue necessariamente i principi di Einstein. [RISATE] Quindi non posso dire molto. Quello che posso dire è che se la rete è occupata e la rete è il collo di bottiglia, probabilmente stiamo aspettando, ma aspettiamo solo per così tanto tempo. Quindi, se prendi tipo un minuto o 30 secondi, probabilmente stiamo scadendo nel mezzo. Ma non c'è niente di difficile... se ti dicessi 10 secondi, potrebbe funzionare o meno. Se ti dico 30 secondi, potrebbe o non potrebbe funzionare. Quindi preferirei non dire un numero. Quello che direi, cerca di farlo entrare il più velocemente possibile. E se non riesci a farlo velocemente, prova ad esempio a memorizzare nella cache i risultati della ricerca in modo che la ricerca diventi più o meno all'interno, o la produzione dei risultati sulla pagina diventi sempre più, più o meno istantanea. Oppure prova il rendering dinamico dalla tua parte che potrebbe essere una soluzione alternativa per questo. Quello che puoi anche provare è che puoi provare a metterlo sul lato server e fondamentalmente provare a generare più contenuti possibile al primo passaggio. Questo è qualcosa che avvantaggia anche i tuoi utenti, soprattutto se si trovano su reti lente. Quindi sì. Spiacente, non ho una risposta semplice, ma il tempo in Googlebot è strano.

Risposta 49:29 - Penso che probabilmente dipenda da cosa fa effettivamente il sito web. Una delle cose complicate con la velocità di rendering è che possiamo memorizzare nella cache molte cose inviate da un server più di quanto sarebbe in un browser, perché possiamo usare il nostro indice per molte di queste cose. Quindi a volte se JavaScript è memorizzato nella cache dalla nostra parte, non è necessario recuperarlo. Quindi, se confronti di nuovo i tempi, non corrisponderà a ciò che vede un utente. Non corrisponderà a ciò che vedi in webpagetest.org. Quindi è davvero un po' complicato, e per le parti in cui sappiamo che ci vuole più tempo, saremo un po' più pazienti. Ma è difficile da testare. Ecco perché ora abbiamo tutti questi strumenti di test che mostrano il maggior numero di errori possibile per rendere possibile capire, ad esempio, non funziona affatto? A volte funziona e dove sono a volte i problemi che emergono?

Domanda 50:29 - Per siti Web molto grandi, l'ordine degli URL nelle mappe dei siti XML è importante?

Risposta 50:34 - No. Non ci interessa. È un file XML. Acquisiamo tutti i dati. Elaboriamo tutto in una volta.

Domanda 50:44 - Allora che dire del parametro di priorità nelle mappe del sito?

Risposta 50:47 - Non lo usiamo affatto. Quindi è qualcosa che all'inizio, abbiamo pensato, oh, questo potrebbe essere utile per capire quanto spesso dovremmo eseguire la scansione delle pagine. Ma si scopre che se chiedi ai webmaster, sono come se tutto fosse prioritario. È molto importante. E simile anche con la, credo, frequenza di cambiamento nelle mappe dei siti, dove notiamo anche che, tipo, le persone ci dicono che le cose cambiano continuamente, ma è stato aggiornato l'ultima volta l'anno scorso. Quindi, se hai la frequenza di modifica e la data, otterremmo comunque tali informazioni dalla data. Quindi ignoriamo la frequenza di cambiamento.
Domanda 51:35 - Lo schema aziendale deve essere aggiunto solo alla home page, alla pagina dei contatti o a tutte le pagine?

Risposta 51:42 - Per quanto ne so, è solo la home page. Non lo so. Qualcuno di voi lo conosce?

Risposta da Liz 51:4 7 - Dovrebbe essere solo una pagina di solito con organizzazione e azienda. Questa è generalmente la raccomandazione.

MARTIN SPLITT 52:00 - Immagino che non importi quale-- non importa tanto quali pagine, proprio come non metterle su ogni pagina che hai, immagino, sia la parte più importante. Penso che dipenda da... se sei un sito di notizie, probabilmente ha senso inserirlo nella pagina dei contatti, o nella pagina delle informazioni, o qualcosa del genere. Mentre nel sito di un negozio o di un ristorante, probabilmente va bene inserirlo nella home page.

GIOVANNI 52:20 - Penso anche che in questo caso non ci importi tanto perché dobbiamo riuscire a trovarlo da qualche parte come la home page o la pagina dei contatti. Ma se ce l'abbiamo altrove, per noi non cambia nulla. Quindi la cosa più importante con cui non confrontarlo è il markup della recensione in cui a volte vediamo le persone inserire come una recensione dell'azienda su tutte le pagine del sito Web con la speranza di ottenere le stelle e i risultati di ricerca per ogni pagina del loro sito. E questo sarebbe un male per noi. Ma le informazioni di contatto, se le hai contrassegnate, sono... Non vedo problemi in questo.
Domanda 53:05 - Il test di velocità del sito Web di Google che abbiamo utilizzato ha registrato tempi di caricamento della pagina molto lenti, ma i test indipendenti che abbiamo eseguito con i colleghi all'estero hanno mostrato un tempo di caricamento della pagina molto rapido. Questa falsa registrazione misurata da Google influisce sul modo in cui il nostro sito viene classificato nell'algoritmo di Google?

Marie Haynes: Non è una mia domanda, ma per dare un po' di contesto, i nuovi dati di Lighthouse per la velocità della pagina sono molto più severi di quanto non fossero Page Speed ​​Insights in passato. Quindi qualcosa che ha avuto un punteggio come 80 su Page Speed ​​Insights potrebbe essere un 29 rosso su Lighthouse. Quindi è una buona domanda. È probabile che ciò causi... perché sappiamo che nei dispositivi mobili i siti molto lenti potrebbero essere retrocessi. Quindi è positivo se diciamo, sai, se sei in rosso nel test del faro, che dovremmo davvero migliorare le cose perché potrebbe causare una retrocessione, o c'è un limite?

Risposta 54:07 - Quindi non abbiamo una mappatura uno-a-uno degli strumenti esterni e di tutto ciò che utilizziamo per i social. Sì, questo rende davvero difficile dirlo, ma nella ricerca, proviamo a utilizzare un mix di dati reali, di cosa si tratta, dei test di laboratorio, che è un po' come il test di Lighthouse, e i dati del report di Chrome UX, dove essenzialmente cosa stiamo misurando è ciò che vedrebbero gli utenti del sito web.

MARTIN SPLITT 55:37 - È anche importante vedere che Lighthouse, ad esempio, misura specificamente una connessione 3G sull'estremità mediana-- o come un telefono a prestazioni medie, sì. Quindi, in pratica, se utilizzi un recente Apple McIntosh o un recente computer Windows veloce con una connessione cablata davvero buona o una connessione Wi-Fi davvero buona nel tuo ufficio, ovviamente, stai vedendo un tempo di caricamento di due secondi, ma un vero utente con il proprio telefono in libertà probabilmente non lo sta vedendo. Quindi è uno di questi casi in cui non fa mai male rendere il tuo sito web più veloce, ma questo è davvero, davvero difficile da dire come sembrerebbe dal punto di vista interno, poiché stiamo usando metriche molto specifiche che non stanno necessariamente mappando uno su uno a ciò che gli strumenti stanno esponendo....ovviamente è importante risolverlo, perché non vuoi che i tuoi utenti aspettino sul tuo sito Web per sempre. Questo ti farà male. Questo danneggerà i tuoi utenti. Questo ti farà solo del male nella ricerca. Ma non pago... direi che guarda solo gli strumenti. Se gli strumenti ti dicono che stai andando bene, non dovresti preoccuparti troppo. Se gli strumenti ti dicono che stai andando davvero male, allora penso che il tempo speso a capire perché dice -- tipo, se quello che dice è rilevante, è sprecato. Dovresti piuttosto cercare di rendere il sito più veloce.

Le prestazioni mobili sono un fattore molto importante per i tuoi utenti, così come tutto il resto. Quindi direi di assicurarti che il tuo sito web funzioni bene in condizioni reali. Magari prendi anche un telefono economico e prova il sito web di tanto in tanto, e se... è qualcosa che mi piace fare e che facevo prima di entrare a far parte di Google con il team di sviluppo con cui stavo lavorando. Ero tipo, guarda, vuoi usare questo sito web su questo telefono? Era come, oh, questo è orribile. Dico, mhm, sì, quindi forse dovremmo fare qualcosa al riguardo.

JOHN - In Chrome, puoi configurarlo e provare diverse velocità di connessione. Emulatore mobile. Penso che siano cose davvero buone da guardare e anche, tipo, guardare la tua base di utenti. Guarda i tuoi dati analitici se vedi che le persone stanno usando il tuo sito web solo con un iPhone di fascia alta, allora forse è meno problematico che se vedi che le persone si connettono al tuo sito da connessioni rurali casuali, che sono lento e hanno dispositivi di fascia bassa, quindi forse è di più.