5 marzo 2019 – Note sull'Hangout di assistenza di Google

Ci uniamo a John Mueller a casa sua in questo Hangout di assistenza per i webmaster. Abbiamo avuto delle ottime domande su Page Speed, hreflang e backlink. Il video e la trascrizione completa si trovano dopo il nostro summery. Se ti piace, considera di iscriverti alla nostra newsletter settimanale! Riassumiamo i migliori articoli SEO della settimana in bocconcini facilmente digeribili.

Puoi spiegare il problema con l'utilizzo di json - ld tramite un tag manager?

11:18

Quindi penso che ciò di cui abbiamo parlato sia un certo numero di volte e anche un sacco di questi ritrovi e ci sono nuovi post sul blog scritti anche da varie persone, incluso Barry. Ma ciò essenzialmente risale a, per noi essere in grado di estrarre il contenuto da tag manager significa che dobbiamo essere in grado di eseguire il rendering del processo JavaScript dei file di script da tag manager e generare la scrittura lì e includere il lato di indicizzazione. Quindi è qualcosa che richiede sempre molto lavoro per i nostri sistemi e non è sempre qualcosa che facciamo per tutte le pagine, in particolare quando vediamo che la pagina altrimenti sarebbe la stessa, allora è un po' difficile per i nostri sistemi giustificarlo dobbiamo anche elaborare tutto questo JavaScript. E per di più, molti degli strumenti di test non elaborano il tag manager e non generano nemmeno l'output, quindi è davvero difficile per gli strumenti confermare che questo markup funzioni correttamente. Ci vuole più tempo per l'elaborazione nella ricerca, potrebbe essere un po' traballante e che non sai esattamente in cosa viene indicizzato in un dato momento. Quindi questi sono tutti motivi per cui dal mio punto di vista va bene usare tag manager per qualsiasi altra cosa. Va bene usarlo anche per JsonLD per i dati strutturati nella ricerca, ma vale la pena tenere presente che non è un ottimo approccio per i dati particolarmente strutturati nella ricerca. Sono modi molto più semplici per fornire i dati della struttura direttamente sulla pagina Web, semplificando la manutenzione, semplificando il monitoraggio per testare tutto ciò. Quindi è quello che consiglierei di farlo, non sto dicendo che non puoi usare tag manager qui per questo puoi sicuramente usarlo e faremo del nostro meglio per prenderlo e usarlo e così via, ma non è del tutto lo stesso livello di velocità e flessibilità, sicurezza quando si tratta di fornire effettivamente i dati della struttura direttamente sulle pagine.

Riepilogo: sebbene sia possibile utilizzare JSON-LD e altri dati strutturati tramite Google Tag Manager, non è l'approccio migliore. Affinché Google possa estrarre il modulo di contenuto Tag Manager e deve eseguire il rendering di JavaScript. Elabora lo script da Tag Manager e genera la scrittura e quindi l'indice. Esistono modi semplici per fornire dati strutturati direttamente sulla pagina che lo rendono più semplice su Google.

In che modo Google seleziona un URL da mostrare nella Ricerca?

15:20

Quindi questo tipo di entra nella domanda generale su come Google scelga un URL da mostrare nella ricerca e da un lato c'è un aspetto in questo caso come la pagina di destinazione per l'immagine 1 che ha un rel canonico impostato per visualizzare tutta la pagina, sarebbe significa che queste pagine non sono equivalenti. Quindi è una specie di incostante che vorremmo riprendere e utilizzare quel canonico, penso che sia un aspetto da tenere a mente. L'altra cosa da tenere a mente è che anche quando capiamo che queste pagine potrebbero essere viste come equivalenti, sta a noi usare più fattori per determinare quale di queste pagine è quella canonica. Quindi, per questo, usiamo un rel canonico, usiamo i reindirizzamenti se abbiamo qualcosa. Usiamo link esterni interni usiamo cose come sitemap, link hreflang, tutto ciò ci ha aiutato a capire quale di questi URL è quello che dovremmo mostrare e se l'URL canonico che specifichi è uno che non usi mai nel resto del tuo sito Web, è probabile che diremo che rendere quel collegamento rel canonico è stato un errore che il webmaster non intendeva effettivamente in questo modo, e forse dovremo scegliere un URL diverso come canonico. Quindi immagino sia quello che accadrà qui o ignoreremo il rel canonical perché questi non sono la stessa cosa o sceglieremo invece una delle altre pagine esistenti perché quella è una delle pagine che è come fortemente collegata all'interno il sitoweb. Quindi non penso che questa configurazione specifica sarebbe così utile nel tuo caso.

Riepilogo: Google utilizza il rel canonical, i reindirizzamenti, i collegamenti interni, le mappe dei siti, hreflang per capire con l'URL è quello che Google dovrebbe mostrare. Ma se l'URL canonico specificato è uno che non viene mai utilizzato nel resto del tuo sito, Google potrebbe ignorare il rel canonical e scegliere un'altra pagina che è fortemente collegata internamente.

È una buona idea includere autori nei post del blog invece di un utente editor generico?

17:38

Penso che sia una buona mossa, soprattutto se sai chi ha scritto l'articolo in origine e puoi trattarlo come una pagina di destinazione dell'autore, penso che sia una buona mossa. Anche solo dal punto di vista dell'utente, se qualcuno va sul tuo sito web e all'improvviso vede oh questi articoli sono stati scritti da Barry invece del semplice editore e hai una pagina di destinazione per quell'autore, allora questo potrebbe essere un segno che è meglio per il utente che potrebbe essere qualcosa che gli utenti raccolgono o vanno alla pagina di destinazione dell'autore e vedono oh questo autore è in realtà un esperto in questo campo ed è attivo lì da alcuni anni, penso sia sempre utile avere su un sito Web in generale, e per quanto riguarda le classifiche di Google è difficile dire se ciò avrebbe un effetto diretto. Ma almeno gli effetti indiretti sono che gli utenti potrebbero fidarsi dei tuoi contenuti più come quelli consigliati o penso che sia qualcosa che ci si aspetterebbe.

Riassunto: Sì! Avere una pagina di destinazione dell'autore è un modo per mostrare EAT dei tuoi autori. Migliorerà anche l'esperienza dell'utente in generale invece di avere un generico "Editor" o "Admin"

Qual è il consiglio se la tua interfaccia utente può essere tradotta in altre lingue ma i contenuti supplementari, come i contenuti generati dagli utenti, rimangono in un'altra lingua?

21:48

Quindi questo è qualcosa che accade un po' soprattutto per i contenuti generati dagli utenti. Quindi, se hai un forum o un blog o qualcosa del genere e le persone commentano in una lingua, ma hai la configurazione in modo che l'interfaccia utente possa cambiare in altre lingue. Quindi hai rapidamente una situazione in cui l'interfaccia utente potrebbe essere in francese o in tedesco ma il contenuto potrebbe essere ancora in spagnolo, ad esempio perché tutti commentano in spagnolo ed è essenzialmente qualcosa che puoi gestire in più modi. Quindi puoi dire che la mia versione canonica è la versione spagnola e tutto è proprio come la versione spagnola che è un'opzione che puoi fare. Puoi utilizzare le annotazioni hreflang tra quelle versioni per dire che questa è la versione più francese del mio contenuto che posso fornire il contenuto principale non è in francese ma l'interfaccia utente è in francese, quindi l'utente che accede alla pagina sarà in grado di navigare in qualche modo il mio sito web è qualcosa che potresti fare. Ed essenzialmente quelle sono le diverse varianti che puoi fornire lì per farci sapere un po' di più su quali sarebbero le tue preferenze. Da un punto di vista pratico, alla fine dipende più da te per quanto riguarda il modo in cui vuoi essere mostrato nella ricerca. Quindi, se pensi che sia utile per un utente francese venire sul tuo sito e atterrare sulla pagina con il contenuto in spagnolo e l'interfaccia utente in francese e quindi utilizzare le annotazioni hreflang tra quelle versioni. Se ritieni che un utente in Francia avrebbe problemi a navigare nel tuo sito se il contenuto principale è in spagnolo anche se l'interfaccia utente è in francese, forse ha senso mantenere solo la versione spagnola con l'interfaccia utente spagnola indicizzata. Quindi alla fine dipende da te, penso che nessuna di queste due sia una soluzione perfetta. A volte dipende un po' dall'uniformità dei tuoi contenuti, dalla chiarezza con cui capisci quali versioni linguistiche desideri avere indicizzato e quali versioni gli utenti si aspettano di vedere nei risultati della ricerca. Quindi, ad esempio, se sei un forum molto internazionale e le persone pubblicano in tutti i tipi di lingue diverse, probabilmente è difficile dire che vuoi solo indicizzare questa versione dell'interfaccia utente, forse ha senso avere tutte le versioni dell'interfaccia utente indicizzate. Lo svantaggio ovviamente di avere tutte le versioni dell'interfaccia utente indicizzate è che moltiplica il numero dei tuoi URL che ha improvvisamente il tuo sito. Quindi ciò significa che dobbiamo eseguire la scansione molto di più e se si tratta di un grande sito di contenuti generati dagli utenti significa che dobbiamo eseguire la scansione, da una parte tutti i contenuti generati dagli utenti e quindi dobbiamo eseguire la scansione di tutti i multipli di quello per ogni diverso versione in lingua, che non so se è utile, se è troppo per la scansione del tuo sito Web se ciò impedisce forse che contenuti più recenti vengano visualizzati rapidamente nei risultati di ricerca. È qualcos'altro su cui pesare. Se stai solo parlando di poche migliaia di articoli, forse questo è un problema minore.

Riepilogo: puoi scegliere una versione linguistica come versione canonica oppure puoi aggiungere annotazioni hreflang tra quelle versioni linguistiche.

Devo rinnegare un gran numero di URL casuali che rimandano al mio sito?

27:58

No, è essenzialmente la mossa giusta da fare e soprattutto se è qualcosa di cui sei davvero preoccupato. Quindi penso che per la maggior parte dei siti Web non abbia senso andare là fuori e rinnegare cose che sono proprio come incerte e strane perché per la maggior parte le ignoriamo semplicemente. Quindi, in particolare per quanto riguarda i collegamenti, se è qualcosa che quando lo guardi dici bene, questo potrebbe essere visto come questi collegamenti vengono acquistati da noi, come naturalmente messi lì da noi, se qualcuno del team del sito Web dovesse prendere un guardalo manualmente e penserebbero che siamo noi a fare qualcosa di stupido, questo è il tipo di cosa in cui direi che probabilmente rinnegarli o rimuoverli sarebbe la mossa giusta lì, ma altrimenti se è solo un collegamento incerto e sembra che ci siano milioni di altri collegamenti lì, qualcuno ha eseguito uno strumento e ha rilasciato tonnellate di collegamenti in questo forum, quindi è qualcosa che i nostri algoritmi hanno già capito. Quindi non è qualcosa di cui non mi preoccuperei.

Riepilogo: Google è bravo a capire quali link ignorare. Ma è meglio essere al sicuro piuttosto che dispiaciuti quando si tratta di rinnegare.

Quanto è importante la velocità della pagina per Google?

42:30

Qual è la politica attuale? Quindi la velocità è qualcosa che conta un po' per noi e ha un grande effetto sugli utenti, quindi è qualcosa che personalmente prenderei abbastanza sul serio e penso che la parte bella della velocità sia che ci sono vari strumenti che ti danno misure piuttosto obiettive lì su cui puoi effettivamente lavorare. Per quanto riguarda molti di noi o altri problemi relativi alla SEO come, non conosco la qualità dei loro contenuti, cose come quella velocità è qualcosa che è abbastanza misurabile e qualcosa su cui puoi lavorare, e dovrebbe anche essere qualcosa che abbiamo utilizzato è un effetto diretto del comportamento dei tuoi utenti all'interno del tuo sito web. Quindi non è solo qualcosa che dal punto di vista di Google, come diciamo noi, la velocità è importante, è un tracker del ranking, ma è qualcosa che vedrai direttamente quando gli utenti accedono al tuo sito Web e il tuo sito Web impiega improvvisamente un paio di secondi in più per caricare quegli utenti reagirà in modo molto diverso sul tuo sito web e avrai più problemi a convertirli in clienti, comunque tu definisca i clienti sul tuo sito web.

Riepilogo: la velocità è estremamente importante quando si tratta di Google. È una metrica facilmente rintracciabile e facilmente utilizzabile. Esistono ottimi strumenti che forniscono informazioni dettagliate sulle prestazioni del tuo sito e su cosa puoi fare per aumentare la velocità della pagina.

Se pago per Google Ads il mio posizionamento sarà migliore o peggiore?

47:24

Quindi riceviamo questa domanda ogni tanto e la domanda qui è tipo, il mio posizionamento sarà influenzato ma la parte migliore o peggiore è qualcosa che sentiamo anche dire da alcune persone, che il tuo posizionamento non migliorerà se usi Google Ads alcune persone dicono che il tuo ranking si abbasserà se utilizzi gli annunci di Google perché vogliamo che tu acquisti più annunci e nessuno dei due è vero. Quindi i nostri risultati di ricerca sono completamente indipendenti dal fatto che utilizzi o meno Google Ads, sono completamente indipendenti dalle tecnologie che utilizzi sul tuo sito web. Quindi, se usi qualcosa come l'analisi o un altro strumento di monitoraggio, dipende totalmente da te. Se monetizzi con Adsense o una di queste altre reti pubblicitarie, dipende solo da te. Quindi, indipendentemente dal fatto che utilizzi o meno i prodotti Google all'interno del tuo sito Web, l'utilizzo di altri servizi Google per il tuo sito Web dipende totalmente da te. È qualcosa per cui preferiamo che questi servizi stiano in piedi da soli e se dici questo motivo particolare per cui il servizio Google non è eccezionale, non voglio usarlo, sentiti libero di usare qualcos'altro. Non vogliamo metterti in quella scatola in cui sei come bloccato tra concentrarti sul tuo sito Web e fare ciò che ritieni sia giusto per i tuoi utenti e dover utilizzare questo particolare prodotto. Quindi è davvero il caso che non leghiamo insieme e lo facciamo in modo esplicito e lavoriamo sodo per assicurarci che queste cose funzionino bene.

Riepilogo: Google Ads non ha alcun effetto sulle classifiche organiche.

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 completo e trascrizione

Domanda 1:14 - Due settimane fa il nostro sito web ha perso il 94% del traffico di Google durante la notte. Con il traffico di ricerca costante negli ultimi 20 anni e senza cambiamenti sostanziali, presumiamo che qualcosa di tecnico potrebbe condividere IPS o SSL tramite una CDN come cloudfare causare un forte calo del traffico algoritmico. Abbiamo scavato più a fondo e abbiamo trovato alcuni siti con contenuti estremamente rischiosi sullo stesso IP. Possiamo cambiare il nostro tema e avere un certificato dedicato, tuttavia continueremo a perdere traffico, cosa potrebbe succedere qui?

Risposta 2:01 - Ma in generale solo perché altri siti sono ospitati sullo stesso indirizzo IP in genere non è motivo di preoccupazione. Quindi, in particolare con hoster più grandi, condividere gli indirizzi IP è abbastanza comune con CDN, l'indirizzo IP condiviso è estremamente comune. Ed è qualcosa che cambia perché molti CDN hanno endpoint in paesi diversi e condividono tali endpoint con i diversi siti Web che sono attivi lì. Quindi, essenzialmente, l'utente e la Germania potrebbero vedere un indirizzo IP diverso rispetto a un utente negli Stati Uniti, ad esempio, ma in generale questa è una pratica estremamente comune, la condivisione di indirizzi IP e non è qualcosa che sarà problematico. All'inizio questo era qualcosa che a volte era molto utile per riconoscere date e host. Dove se vedessimo un indirizzo IP e 9000 siti con indirizzi statici e sono tutti spam e se ci fossero altri due siti Web sullo stesso host, allora potrebbe essere difficile per noi renderci conto del tipo, questi due siti vengono davvero completamente siti separati rispetto a questi 9.000 altri siti. È una specie di situazione complicata per gli algoritmi. Ma nella maggior parte dei casi come questo vedremo un mix di tutti i tipi di siti diversi, quindi siti diversi in lingue diverse per paesi diversi con utenti target diversi alcuni siti di spam alcuni siti non di spam sullo stesso indirizzo IP e tutto va benissimo . Quindi non sarebbe un motivo per noi dire, oh come perché c'è un sito di spam su questo indirizzo IP che sarebbe un problema. Quindi non so in particolare cosa sia successo qui con questo sito Web, do un'occhiata al fatto che in generale anche l'aspetto del nostro sito Web stava andando bene nella ricerca per così tanti anni prima di tendere a dire che va bene per il tuo sito ma non è necessariamente qualcosa che lo terremmo sempre così.

Quindi, solo perché il sito stava andando bene in passato e la ricerca non significa che continuerà a fare bene nella ricerca da un lato sì, le aspettative degli utenti cambiano, dall'altro gli algoritmi di Google cambiano. Quindi queste cose possono sempre cambiare e può succedere che le cose a volte cambino in modo significativo e il nostro obiettivo c'è meno da dire come questo particolare sito Web è un cattivo algoritmo, ma piuttosto per dire che abbiamo riconosciuto che forse abbiamo mancato di servire le aspettative degli utenti o abbiamo fatto le cose in modi che non corrispondono più a ciò che gli utenti si aspettano, quindi i nostri algoritmi cambiano per cercare di riportare i risultati, dicono gli utenti, e pertinenti al giorno d'oggi ai risultati di ricerca. Quindi è qualcosa che può sempre giocare a seconda del tipo di sito web.

Domanda 5:49 - Un po' di tempo fa sul sito che sembrava superarci in base al fatto che fondamentalmente rubava il nostro contenuto e poi lo modificava in modo da non violare il copyright e quindi superarci. Abbiamo notato lo schema quando ci guardiamo indietro e abbiamo fatto alcune ricerche che sembra che come riprogetteranno il nostro sito, miglioreranno la nostra qualità, miglioreranno le classifiche, quindi lo copieranno e qualche volta nei prossimi mesi o due inizieranno a classificare noi e um ci sembra che in qualche modo gli algoritmi abbiano confuso e stiano attribuendo a quel sito il merito di essere l'autore del contenuto invece di noi e quindi di sopprimerci nelle classifiche di conseguenza.

Risposta 6:37 - Non lo so, dovrei dare un'occhiata ai siti per vedere cosa sta succedendo esattamente lì. Quindi è un po 'complicato dal punto di vista algoritmico dire che, come i nostri algoritmi sceglierebbero sempre quel sito rispetto al tuo sito per quelle query. Ma quello che generalmente mirerei a fare lì è se questi siti stanno copiando i tuoi contenuti, quindi provare a trovare modi per affrontare questo problema alla radice per incoraggiarli a non copiare i tuoi contenuti. Quindi forse esamina cose come un reclamo DMCA, non so se è rilevante nel tuo caso o meno, ma qualsiasi cosa per provare a gestirlo in un modo che la ricerca non debba indovinare quale di queste versioni di il contenuto dovrebbe essere classificato per quelle query.

Domanda 11:18 - Puoi spiegare il problema con l'utilizzo di json-ld tramite un tag manager? Tag manager viene utilizzato per verificare la console di ricerca e probabilmente l'analisi, quindi sicuramente è abbastanza stabile.

Risposta 11:33 - Quindi penso che ciò di cui abbiamo parlato sia un certo numero di volte e anche un sacco di questi hangout e ci sono nuovi post sul blog scritti anche da varie persone, incluso Barry. Ma ciò essenzialmente risale a, per noi essere in grado di estrarre il contenuto da tag manager significa che dobbiamo essere in grado di eseguire il rendering del processo JavaScript dei file di script da tag manager e generare la scrittura lì e includere il lato di indicizzazione. Quindi è qualcosa che richiede sempre molto lavoro per i nostri sistemi e non è sempre qualcosa che facciamo per tutte le pagine, in particolare quando vediamo che la pagina altrimenti sarebbe la stessa, allora è un po' difficile per i nostri sistemi giustificarlo dobbiamo anche elaborare tutto questo JavaScript. E per di più, molti degli strumenti di test non elaborano il tag manager e non generano nemmeno l'output, quindi è davvero difficile per gli strumenti confermare che questo markup funzioni correttamente. Ci vuole più tempo per l'elaborazione nella ricerca, potrebbe essere un po' traballante e che non sai esattamente in cosa viene indicizzato in un dato momento. Quindi questi sono tutti motivi per cui dal mio punto di vista va bene usare tag manager per qualsiasi altra cosa. Va bene usarlo anche per questo per JsonLD per dati strutturati per la ricerca, ma vale la pena tenere presente che non è un ottimo approccio per dati particolarmente strutturati nella ricerca. Sono modi molto più semplici per fornire i dati della struttura direttamente sulla pagina Web, semplificando la manutenzione, semplificando il monitoraggio per testare tutto ciò. Quindi è quello che consiglierei di farlo, non sto dicendo che non puoi usare tag manager qui per questo puoi sicuramente usarlo e faremo del nostro meglio per prenderlo e usarlo e così via, ma non lo è quasi lo stesso livello di velocità e flessibilità, sicurezza quando si tratta di fornire effettivamente i dati della struttura direttamente sulle pagine.

Domanda 14:00 - Un client ha eseguito una migrazione HTTPs spostandosi utilizzando 302 anziché 301, è necessario cambiarlo in 301? Quanto tempo impiegherà Google a capire che si tratta di un reindirizzamento permanente?

Risposta 14:14 - Quindi probabilmente lo rileveremo anche perché molte persone usano il tag sbagliato di reindirizzamento per gli spostamenti del sito e stiamo ancora lavorando per cercare di capirlo correttamente. Un modo rapido per vedere cosa sta succedendo è controllare nella console di ricerca per vedere se le cose vengono indicizzate correttamente. Quindi, se il nuovo dominio funziona bene, probabilmente va già bene. Detto questo, se hai riconosciuto problemi come questo o altri problemi tecnici su un sito Web che sono facili da risolvere e ritieni che potrebbero avere un grande impatto, allora andremo avanti e risolverlo. Soprattutto il tipo di reindirizzamento sbagliato, è come una modifica di una riga nel file htaccess sulla maggior parte dei siti Web. Quindi è qualcosa che è davvero facile da risolvere. In modo che tu non debba preoccuparti che i motori di ricerca lo interpretino nel modo sbagliato.

Domanda 15:20 - Le nostre gallerie di immagini hanno un URL univoco per immagini come /gallery/image1 o /image2 o /image 3 e vogliamo aggiungere galleria /visualizza tutto e usarlo come URL canonico ma non abbiamo questo link da qualche parte sul sito possiamo farlo? La vista deve essere tutta visibile per il lettore?

Risposta 15:46 - Quindi questo tipo di entra nella domanda generale su come Google scelga un URL da mostrare nella ricerca e da un lato c'è un aspetto in questo caso come la pagina di destinazione per l'immagine 1 con un canonico rel impostato su la pagina visualizza tutta, significherebbe che queste pagine non sono equivalenti. Quindi è una specie di incostante che vorremmo riprendere e utilizzare quel canonico, penso che sia un aspetto da tenere a mente. L'altra cosa da tenere a mente è che anche quando capiamo che queste pagine potrebbero essere viste come equivalenti, sta a noi usare più fattori per determinare quale di queste pagine è quella canonica. Quindi per questo usiamo un rel canonico, usiamo i reindirizzamenti se abbiamo qualcosa. Usiamo link esterni interni usiamo cose come sitemap, link hreflang, tutto ciò ci ha aiutato a capire quale di questi URL è quello che dovremmo mostrare e se l'URL canonico che specifichi è uno che non usi mai nel resto del tuo sito Web, è probabile che diremo che rendere quel collegamento rel canonico è stato un errore che il webmaster non intendeva effettivamente in questo modo, e forse dovremo scegliere un URL diverso come canonico. Quindi immagino sia quello che accadrà qui o ignoreremo il rel canonical perché questi non sono la stessa cosa o sceglieremo invece una delle altre pagine esistenti perché quella è una delle pagine che è come fortemente collegata all'interno il sitoweb. Quindi non penso che questa configurazione specifica sarebbe così utile nel tuo caso.

Domanda 17:38 - Qual è la tua raccomandazione per i siti che hanno molti contenuti che vogliono fornire per altre lingue e paesi ma finora hanno tradotto solo l'interfaccia, quindi non il contenuto principale.

Risposta 17:55 - Quindi questo è qualcosa che accade un po' soprattutto per i contenuti generati dagli utenti. Quindi, se hai un forum o un blog o qualcosa del genere e le persone commentano in una lingua, ma hai la configurazione in modo che l'interfaccia utente possa cambiare in altre lingue. Quindi hai rapidamente una situazione in cui l'interfaccia utente potrebbe essere in francese o in tedesco ma il contenuto potrebbe essere ancora in spagnolo, ad esempio perché tutti commentano in spagnolo ed è essenzialmente qualcosa che puoi gestire in più modi. Quindi puoi dire che la mia versione canonica è la versione spagnola e tutto è proprio come la versione spagnola che è un'opzione che puoi fare. Puoi utilizzare le annotazioni hreflang tra quelle versioni per dire che questa è la versione più francese del mio contenuto che posso fornire il contenuto principale non è in francese ma l'interfaccia utente è in francese, quindi l'utente che accede alla pagina sarà in grado di navigare in qualche modo il mio sito web è qualcosa che potresti fare. Ed essenzialmente quelle sono le diverse varianti che puoi fornire lì per farci sapere un po' di più su quali sarebbero le tue preferenze. Da un punto di vista pratico, alla fine dipende più da te per quanto riguarda il modo in cui vuoi essere mostrato nella ricerca. Quindi, se pensi che sia utile per un utente francese venire sul tuo sito e atterrare sulla pagina con il contenuto in spagnolo e l'interfaccia utente in francese e quindi utilizzare le annotazioni hreflang tra quelle versioni. Se ritieni che un utente in Francia avrebbe problemi a navigare nel tuo sito se il contenuto principale è in spagnolo anche se l'interfaccia utente è in francese, forse ha senso mantenere solo la versione spagnola con l'interfaccia utente spagnola indicizzata. Quindi alla fine dipende da te, penso che nessuna di queste due sia una soluzione perfetta. A volte dipende un po' dall'uniformità dei tuoi contenuti, dalla chiarezza con cui capisci quali versioni linguistiche desideri avere indicizzato e quali versioni gli utenti si aspettano di vedere nei risultati della ricerca. Quindi, ad esempio, se sei un forum molto internazionale e le persone pubblicano in tutti i tipi di lingue diverse, probabilmente è difficile dire che vuoi solo indicizzare questa versione dell'interfaccia utente, forse ha senso avere tutte le versioni dell'interfaccia utente indicizzate. Lo svantaggio ovviamente di avere tutte le versioni dell'interfaccia utente indicizzate è che moltiplica il numero dei tuoi URL che ha improvvisamente il tuo sito. Quindi ciò significa che dobbiamo eseguire la scansione molto di più e se si tratta di un grande sito di contenuti generati dagli utenti significa che dobbiamo eseguire la scansione, da una parte tutti i contenuti generati dagli utenti e quindi dobbiamo eseguire la scansione di tutti i multipli di quello per ogni diverso versione in lingua, che non so se è utile, se è troppo per la scansione del tuo sito Web se ciò impedisce forse che contenuti più recenti vengano visualizzati rapidamente nei risultati di ricerca. È qualcos'altro su cui pesare. Se stai solo parlando di poche migliaia di articoli, forse questo è un problema minore.

Domanda 21:25 - Abbiamo un blog in esecuzione accanto al nostro sito di e-commerce sin dall'inizio i post del blog sono stati contrassegnati come scritti da un utente editor generico. Osservando le linee guida sulla qualità e EAT, vorremmo sostituire l'editor con il vero nome dell'autore del post, questo tipo di operazione è positiva o potrebbe potenzialmente visualizzare spam?

Risposta 21:48 - Penso che sia una buona mossa, soprattutto se conosci chi ha scritto l'articolo in origine e puoi trattarlo come una pagina di destinazione dell'autore. Penso che sia una buona mossa. Anche solo dal punto di vista dell'utente, se qualcuno va sul tuo sito web e all'improvviso vede oh questi articoli sono stati scritti da Barry invece del semplice editore e hai una pagina di destinazione per quell'autore, allora questo potrebbe essere un segno che è meglio per il utente che potrebbe essere qualcosa che gli utenti raccolgono o vanno alla pagina di destinazione dell'autore e vedono oh questo autore è in realtà un esperto in questo campo ed è attivo lì da alcuni anni, penso sia sempre utile avere su un sito Web in generale, e per quanto riguarda le classifiche di Google è difficile dire se ciò avrebbe un effetto diretto. Ma almeno gli effetti indiretti sono che gli utenti potrebbero fidarsi dei tuoi contenuti più come quelli consigliati o penso che sia qualcosa che ci si aspetterebbe.

Domanda 22:58 - Il markup dello schema con una versione desktop e amp, va bene se la versione desktop viene implementata utilizzando microdati ma la versione amp utilizza json-ld?

Risposta 23:09 - Certo che va benissimo. Per quanto riguarda il formato o quello che viene utilizzato lì non vedo problemi con il fatto che l'unica cosa da tenere a mente è che per quanto ne so alcuni tipi di dati strutturati sono disponibili solo in json-ld. Quindi potrebbe essere qualcosa in cui devi ricontrollare i tipi di dati strutturati che stai utilizzando ma con una versione del tuo sito che utilizza un tipo di dati della struttura sull'altra versione utilizzando un tipo diverso, anche all'interno dello stesso desktop mobile variazione dell'app, questo è certamente possibile, quindi ad esempio se hai un blog forse una directory di prodotti, non lo so, sul tuo sito Web e sito di e-commerce e il sito di e-commerce ha recensioni che utilizzano json-ld e il tuo blog utilizza markup dell'articolo che utilizza microdati, non so se è il modo giusto per farlo, ma andrebbe benissimo.

Domanda 24:19 - Per quanto riguarda la visualizzazione di contenuti nascosti: nessuno va bene per il supporto di Google e ha menzionato che il carattere bianco con sfondo bianco o la dimensione del carattere zero saranno contrari alle linee guida, ma per quanto riguarda display: nessuno?

Risposta 24:32 - I contenuti nascosti generalmente non sono qualcosa che apprezziamo. In particolare si presenta come il sito che cerca di inserire nell'indice di Google parole chiave che non sono effettivamente visibili sulla pagina stessa. Quindi è qualcosa che eviterei davvero. Hai menzionato il design reattivo e il resto della tua domanda penso che sia l'unico aspetto che entra in gioco qui. Quindi, se stai utilizzando il design reattivo per rendere questo contenuto visibile per gli utenti mobili o per gli utenti desktop, allora va benissimo. Ma se questo contenuto è essenzialmente sempre invisibile come i caratteri con zero o il carattere bianco su sfondo bianco o il carattere nero su sfondo nero, allora questi sono il tipo di cose che i nostri sistemi prenderanno e diranno bene, forse questo testo qui non è così rilevante come altrimenti potrebbe essere e da un punto di vista pratico probabilmente non otterrai un'azione manuale per qualcosa del genere. Ma a parte cercando di capirlo, cercheranno di svalutare quel contenuto quando si tratta di cercare. In modo che sia meno probabile che venga mostrato nello snippet meno probabile che venga trattato come veramente importante in quelle pagine.

Domanda 25:55 - Dopo l'azione manuale dei collegamenti, per quanto tempo Google tratta il dominio una volta che la richiesta di riconsiderazione è stata accettata ma non ha riacquistato il potenziale posizionamento nel traffico?

Risposta 26:08 - Quindi penso che qui ci siano due aspetti da un lato, se l'azione manuale viene risolta, praticamente direttamente quel sito sarà visibile nella ricerca senza quell'azione manuale. Quindi c'è un'eccezione qui in cui se un sito viene rimosso per motivi di puro spam, verrà essenzialmente rimosso completamente dal nostro indice. Quindi non è che possiamo semplicemente riattivarlo e mostrarlo di nuovo, sarà necessario eseguire nuovamente la scansione ed elaborare quel sito a volte che richiede alcune settimane, ma per tutte le altre azioni manuali è una volta che l'azione manuale è stata risolta e cose sono tornati allo stato precedente, non è che Google nutre rancore e dice che c'era un'azione manuale qui o quindi devo stare molto attento, è davvero risolto è risolto. Per quanto riguarda i link, ovviamente, se il tuo sito si posizionava artificialmente nei risultati di ricerca a causa di link innaturali e hai ricevuto un'azione manuale e lo risolvi rimuovendo questi link innaturali, ovviamente il tuo sito non si classificherà artificialmente più in alto a causa di quei collegamenti innaturali ora sono scomparsi. Quindi è qualcosa in cui sarebbe del tutto normale vedere un cambiamento di visibilità dopo aver risolto qualcosa del genere, allo stesso modo se un sito fosse visibile in modo innaturale a causa di altre cose sul tuo sito Web e lo risolvi rimuovendo quelle altre cose, ovviamente il tuo sito lo farà essere di nuovo visibile naturalmente, ma non sarà visibile in modo innaturale a causa di quelle cose che hai rimosso, quindi è qualcosa da tenere a mente.

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

Risposta 47:34 - Quindi riceviamo questa domanda ogni tanto e la domanda qui è tipo, la mia classifica sarà influenzata ma la parte migliore o peggiore è qualcosa che sentiamo anche dire da alcune persone, che la tua classifica non otterrà meglio se usi Google Ads, alcune persone dicono che il tuo ranking si abbasserà se usi Google Ads perché vogliamo che tu acquisti più annunci e nessuno dei due è vero. Quindi i nostri risultati di ricerca sono completamente indipendenti dal fatto che utilizzi o meno Google Ads, sono completamente indipendenti dalle tecnologie che utilizzi sul tuo sito web. Quindi, se usi qualcosa come l'analisi o un altro strumento di monitoraggio, dipende totalmente da te. Se monetizzi con Adsense o una di queste altre reti pubblicitarie, dipende solo da te. Quindi, indipendentemente dal fatto che utilizzi o meno i prodotti Google all'interno del tuo sito Web, l'utilizzo di altri servizi Google per il tuo sito Web dipende totalmente da te. È qualcosa per cui preferiamo che questi servizi stiano in piedi da soli e se dici questo motivo particolare per cui il servizio Google non è eccezionale, non voglio usarlo, sentiti libero di usare qualcos'altro. Non vogliamo metterti in quella scatola in cui sei come bloccato tra concentrarti sul tuo sito Web e fare ciò che ritieni sia giusto per i tuoi utenti e dover utilizzare questo particolare prodotto. Quindi è davvero il caso che non leghiamo insieme e lo facciamo in modo esplicito e lavoriamo sodo per assicurarci che queste cose funzionino bene.