Seo Office Hours, 12 novembre 2021

Questo è un riepilogo delle domande e delle risposte più interessanti del Google SEO Office Hours con John Mueller del 12 novembre 2021.

Pagine Noindex in Google Search Console

8:16 “ [Alcune pagine] sono state impostate erroneamente su noindex. Questo è stato risolto un paio di mesi fa. […] Abbiamo provato a richiedere l'indicizzazione tramite Search Console [e] reinviando le mappe dei siti, ma ancora queste pagine non vengono indicizzate. Hai qualche idea su cosa potrebbe impedire a Googlebot di ascoltare le richieste di indicizzazione o se ci sono problemi noti in Search Console con l'indicizzazione?"

John: “Non credo che ci siano problemi noti al riguardo, ma a volte siamo un po' prudenti riguardo all'invio di richieste di indicizzazione, che probabilmente è in parte ciò che vedi lì. […] Da un lato, se vediamo che una pagina è noindex per un periodo di tempo più lungo, di solito rallentiamo con la scansione di quella. […] Significa anche che quando la pagina diventa indicizzabile, riprenderemo la scansione, quindi è essenzialmente quel tipo di spinta che devi fare.

Un'altra cosa è che, poiché Search Console riporta essenzialmente gli URL che conosciamo per il sito Web, è possibile che l'immagine appaia peggiore di quanto non sia in realtà. Potrebbe essere qualcosa che potresti esaminare, ad esempio, guardando nel rapporto sul rendimento e filtrando quella sezione del sito web o quei pattern URL, per vedere se quel numero di pagine ad alto noindex in Search Console sta generando rapporti su pagine che non erano molto importanti e le pagine importanti di quelle sezioni sono effettivamente indicizzate".

John ha anche affermato che "[...] una mappa del sito è essenzialmente un buon inizio, ma un'altra cosa che potresti fare è chiarire con i collegamenti interni che queste pagine sono molto importanti per il sito Web in modo da poterle scansionare un po' più velocemente. Questo può essere un collegamento interno temporaneo in cui dici: per un paio di settimane, ci colleghiamo a singoli prodotti dalla nostra home page. […] In sostanza, quando scopriamo che il collegamento interno è cambiato in modo significativo, di solito andiamo a ricontrollare anche quelle pagine. Quindi potrebbe essere un approccio temporaneo per spingere di nuovo le cose nell'indice. Con i collegamenti interni, non stai dicendo che si tratta di pagine importanti sul Web, ma piuttosto pagine importanti relative al tuo sito Web. Quindi, se modifichi in modo significativo il collegamento interno, può succedere che altre parti del sito Web, che forse erano solo a malapena indicizzate, a un certo punto si interrompano. Quindi è per questo che lo farei a livello temporaneo e direi, voglio reinserirli nel sistema in modo che vengano ripetuti alla velocità normale, e poi cambierò il collegamento interno in modo che tutto sia di nuovo più normale .”

Per quanto riguarda l'aggiunta di collegamenti al footer, John ha aggiunto: “Penso che funzionerebbe anche questo. Di solito è meglio se riusciamo a trovarlo su pagine molto importanti del sito web, di solito come nella tua home page, […] dove stai dicendo che questo è importante per te, quindi, andremo a ricontrollare quella pagina. "

Tag canonici e alternativi

14:25 “Sto usando un sito Web WordPress e sto usando due plugin. Uno [di loro] aggiunge automaticamente un collegamento rel="canonico" a ogni pagina. […] [L'altro è un plugin traduttore] che aggiunge [a] ogni pagina un collegamento rel=” alternativo”. È logico che dica: per quell'URL, è canonico, ma è anche un'alternativa? È in conflitto da qualche parte nel crawler?"

Giovanni ha dichiarato: “No. Voglio dire, non so esattamente cosa fanno questi due plugin. Da un punto di vista generale, se hai una pagina che contiene un rel=canonical, sei essenzialmente con un detto canonico: il link menzionato lì è l'URL preferito che voglio. Se è la stessa pagina, allora è perfetto perché poi ci dà la conferma che questa pagina è quella che vuoi avere indicizzato.

Il rel="alternato" significa sostanzialmente che ci sono anche versioni alternative di questa pagina. Quindi, con lingue diverse, ad esempio, se hai una pagina in inglese, una pagina in francese, avresti il ​​collegamento rel="alternativo" tra queste due versioni linguistiche. E non sta dicendo che la pagina in cui si trova quel collegamento sia l'alternativa, ma piuttosto è come se si trattasse di due versioni diverse, una in inglese, una in francese. Possono essere entrambi canonici, quindi avere quella combinazione di solito va bene.

L'unico posto a cui prestare attenzione è che il canonico non dovrebbe essere tra lingue diverse. Quindi non dovrebbe essere che sulla tua pagina francese, hai un set canonico sulla versione inglese perché sono essenzialmente pagine diverse. Ma la pagina francese può essere canonica e la pagina inglese può essere canonica, e hai il collegamento alternativo tra le due, ed è essenzialmente un buon set. "

Canonizzazione o tag noindex

16:49 “Abbiamo un sito web con un negozio di e-commerce con molte varianti di prodotto che hanno contenuti sottili o duplicati. Ho fatto un elenco di tutti gli URL che vogliamo indicizzare […] e non vogliamo che siano indicizzati. […] Non sono sicuro di cosa sarebbe meglio: canonizzazione o noindex?”

John ha detto: "Penso che la domanda generale su dovrei usare noindex o rel=" canonical" per un'altra pagina sia qualcosa per cui probabilmente non c'è una risposta assoluta. […] Se stai lottando con quello, non sei l'unica persona che dice, oh quale dovrei usare? Questo di solito significa anche che entrambe queste opzioni possono andare bene. Quindi, di solito, quello che guarderei lì è qual è la tua preferenza davvero forte. Se la preferenza forte è che davvero non vuoi che questo contenuto venga mostrato nella ricerca, allora userei noindex. Se la tua preferenza è di più, voglio davvero che tutto sia unito in una pagina […], allora userei un rel=" canonico". In definitiva l'effetto è simile in quanto è probabile che la pagina che stai guardando non venga mostrata nella ricerca, ma con un noindex – non è sicuramente mostrato, e con un rel=” canonico” – è più probabile che non venga mostrato. "

John ha riassunto: " Puoi anche fare entrambi. Se i link esterni, ad esempio, puntano a questa pagina, avere entrambi lì ci aiuta a capire bene, non vuoi che questa pagina venga indicizzata, ma ne hai anche specificato un'altra, quindi forse alcuni dei segnali possiamo solo avanti”.

Indicizzazione e scansione mobile first

28:26 “[…] Ottimizziamo il nostro sito di conseguenza [per l'indicizzazione mobile-first]. Per quanto riguarda la configurazione, Google consiglia due modi per farlo. Il primo è un web design reattivo e il secondo è un servizio dinamico. Poiché il primo modo è un po' difficile da raggiungere per noi attraverso il nostro ambiente tecnologico, utilizziamo il secondo modo. Ma vediamo ancora che oggigiorno ci sono oltre duecentomila scansioni giornaliere verso il nostro dominio mobile. È una cosa normale da vedere? […] Avevamo il dominio m-dot, quindi lo abbiamo reindirizzato al dominio principale."

John rispose: "Una certa quantità di gattonare in questo modo è normale. Ci vuole molto tempo prima che i nostri sistemi smettano completamente di eseguire la scansione di un dominio anche dopo che è stato reindirizzato, quindi non lo vedrei come un problema. I nostri sistemi hanno una memoria molto lunga per cose come questa a volte e se sposti un sito da un dominio a un altro o se apporti questa modifica mobile con un sottodominio, a volte la scansione si interrompe completamente.

Tecnologie Web vs ranking

36:00 “ C'è qualche relazione o impatto sulle classifiche per i siti web che sono realizzati con normale HTML, CSS, JS e un altro – PWA? […] Uno dei nostri principali concorrenti l'ha adottato di recente e abbiamo notato un enorme salto nelle loro classifiche SERP".

John ha affermato: "Questi sono essenzialmente modi diversi di creare un sito Web e puoi creare un sito Web con molti framework e formati diversi. Per la maggior parte, li vediamo come normali pagine HTML. Quindi, se si tratta di un sito Web basato su JavaScript, lo renderemo e poi lo elaboreremo come una normale pagina HTML. Se è già HTML all'inizio, possiamo farlo. [Ci sono] diversi framework e CMS dietro di esso. Di solito, fondamentalmente lo ignoriamo e diciamo semplicemente, beh, ecco una pagina HTML e possiamo elaborarla.

Quindi solo il fatto che uno dei tuoi concorrenti si sia spostato da un framework all'altro e abbia visto un miglioramento nella ricerca, quel cambio di framework, dal mio punto di vista, non sarebbe in qualche modo responsabile di ciò. Ma piuttosto, forse ora hanno un sito Web più nuovo, insieme a quella modifica del framework. Forse il sito Web più recente ha collegamenti interni diversi, contenuto diverso internamente, [è] significativamente più veloce o significativamente più lento, agli utenti piace molto o hanno fatto una campagna di marketing insieme al lancio del sito Web. Tutte queste cose giocano lì dentro, e queste sono tutte cose che non si limitano al framework che stai usando.

Google PageSpeed ​​Insights vs. Faro

37:39 "I risultati nei dati di laboratorio in Google PageSpeed ​​Insights sono gli stessi dei risultati di Lighthouse nel mio browser Chrome? Usano la stessa formula?"

John ha detto: “Non lo so al cento per cento, ma sono fatti in modo completamente diverso. […] Se utilizzi PageSpeed ​​Insights che viene eseguito su un data center da qualche parte con dispositivi essenzialmente emulati in cui cerchiamo di agire come un normale computer e abbiamo delle restrizioni in atto che lo rendono un po' più lento. […] In Lighthouse, funziona fondamentalmente sul tuo computer con la tua connessione Internet. Penso che Lighthouse all'interno di Chrome abbia anche alcune restrizioni che si applicano per farlo sembrare forse un po' più lento di quanto il tuo computer potrebbe essere in grado di fare solo per assicurarsi che sia comparabile.

Ma essenzialmente, questi funzionano in ambienti completamente diversi, ed è per questo che spesso vedresti numeri diversi lì. […] Se esegui il test con altri strumenti di velocità che funzionano online, potresti [anche] vedere numeri diversi. Inoltre, i dati del campo, i dati che utilizziamo per il ranking di ricerca che vedi in Search Console, possono anche essere numeri completamente diversi solo perché i tuoi utenti potrebbero avere, in media, un diverso tipo di dispositivo o un diverso tipo di connessione Internet. Quindi, anche se le formule sono le stesse, l'intero ambiente attorno a questi sistemi è molto diverso".

Google Scopri

47:09 “Abbiamo notato un grosso problema con Google Discover sul nostro sito web. In due giorni il traffico è sceso del settanta per cento. […] Quindi ci chiediamo se abbiamo sbagliato qualcosa? […] Puoi chiarire cosa è successo esattamente visto che si tratta di un pareggio così drastico? […] Potrebbe essere un errore tecnico?”

John ha detto: "Non so in modo specifico per quanto riguarda il tuo sito web, ma ricevo segnalazioni da molte persone che il traffico Discover è attivo o meno, nel senso che c'è pochissimo spazio nel mezzo se i nostri algoritmi determinano al momento non mostreranno molti contenuti da questo sito Web in Discover, quindi praticamente tutto quel traffico scompare. Nell'altro modo, è la stessa cosa in cui se mostriamo qualcosa dal tuo sito Web in Discover, all'improvviso hai di nuovo quella grande corsa di traffico.

Se si tratta di un problema tecnico, lo vedresti anche nella ricerca web e vedresti i problemi di scansione. Non ho una visione completa di ciò che accade esattamente in Discover, ma di solito i problemi di cui vedo parlare le persone sono, da un lato, problemi di qualità in cui forse la qualità del sito Web non è così buona e per quanto riguarda il politiche individuali che abbiamo per Discover. In particolare, per Discover, abbiamo alcune norme diverse dalla ricerca sul Web e raccomandazioni leggermente diverse per quanto riguarda, credo, i contenuti per adulti, i contenuti clickbaity. […] Questo è tutto menzionato nella pagina del Centro assistenza che abbiamo per Discover. Immagino che molti siti web abbiano un po' un mix di tutte queste cose, e a volte sospetto che i nostri algoritmi trovino un po' troppo, e poi dicono, oh, dobbiamo stare attenti ora con questo sito web. Quindi, senza conoscere il tuo sito Web e senza conoscere i dettagli di ciò che Discover sta raccogliendo esattamente lì, questa è la direzione in cui andrei lì. […]

Dal nostro punto di vista, Discover è il luogo in cui cerchiamo di mostrare un flusso di informazioni alle persone e, per questo motivo, tendiamo a non avere molte informazioni dettagliate su ciò che è necessario fornire esattamente per funzionare davvero bene. Quindi a volte ha senso guardare ciò che le altre persone hanno capito".

Tempo di risposta

50:41 "Quale sarebbe un buon tempo di risposta per un nuovo sito di media?"

Secondo John, " Il tempo di risposta è qualcosa che gioca nella nostra capacità di capire quanta scansione può richiedere un server. Di solito, il tempo di risposta, da un punto di vista pratico, limita o gioca in quante connessioni parallele sarebbero necessarie per eseguire la scansione. Quindi, se vogliamo eseguire la scansione di mille URL da un sito Web, il tempo di risposta per distribuirlo nel corso di una giornata può essere piuttosto ampio. Considerando che se vogliamo eseguire la scansione di un milione di URL da un sito Web e c'è un tempo di risposta elevato, significa che finiamo con molte connessioni parallele al server. Penso che abbiamo alcuni limiti in merito al fatto che non vogliamo causare problemi sul server, ecco perché il tempo di risposta è direttamente collegato alla velocità di scansione.

Per un sito Web di notizie, non è tanto una questione di notizie o meno, quanto piuttosto il numero di URL di cui dobbiamo eseguire la scansione al giorno. Quindi questo è l'angolo che guarderei lì. Può essere che su un sito Web di notizie eseguiamo la scansione di diecimila pagine al giorno e questi sono gli articoli di notizie importanti che vengono tutti trattati. Potrebbe essere che dobbiamo eseguire la scansione di milioni di articoli al giorno perché dobbiamo sempre aggiornare l'archivio […], quindi ovviamente il tempo di risposta, la velocità di scansione, sembra diverso".