Orario d'ufficio SEO – 24 dicembre 2021

Pubblicato: 2021-12-29

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

I contenuti si nascondono
1 Contenuti e cloaking con paywall
2 Potenziali problemi di indicizzazione
3 Aggiornamento delle recensioni sui prodotti: lingue e paesi interessati
4 Localizzazione delle pagine per i paesi di lingua inglese
5 Aggiunta di contenuto dinamico alle pagine
6 Rendering e indicizzazione di file JavaScript
7 URL di indicizzazione generati attraverso la ricerca all'interno di un sito web
8 siti SEO come YMYL
9 Implementazione di dati strutturati breadcrumb
10 Tradurre solo alcune pagine di un sito web
11 Budget di scansione e URL generati automaticamente
12 Scansione di URL con parametri

Contenuti protetti da paywall e cloaking

00:49 “Per quanto riguarda i dati paywall con contenuto paywall. […] Abbiamo un sito web. Abbiamo scritto molti articoli e tutto è accessibile a Google. E vorremmo aggiungere un paywall lì, ma […] solo […] mostra il contenuto del paywall a Google con gli snippet di dati strutturati che hai. È considerato occultamento?

Quindi, controllo se si tratta di Googlebot e solo [quindi] mostro […] i dati strutturati – […] i dati con paywall. Ma poi all'utente normale […], non mostro i dati strutturati, va bene?”

John non vedeva il problema con questa soluzione: “Va bene. Tecnicamente , sarebbe comunque considerato cloaking, perché stai mostrando qualcosa di diverso, ma dalle nostre politiche, è accettabile. Perché gli utenti, […] se passano attraverso il paywall, […] vedrebbero il contenuto che stai mostrando a Googlebot”.

Potenziali problemi di indicizzazione

03:38 “Pubblico contenuti di alta qualità, ho inviato una mappa del sito e talvolta richiedo l'indicizzazione da Google Search Console. Ma ho ancora problemi con l'indicizzazione del nuovo contenuto, oppure è indicizzato [con un ritardo]. […] È un bug di Google o è un nuovo aggiornamento dell'algoritmo?"

John ha risposto: “Non c'è nessun bug dalla nostra parte al riguardo. […] Semplicemente non indicizziamo tutti i contenuti e alcuni siti Web generano molti contenuti. E se non indicizziamo tutto […], può andare bene. Ma forse vuoi che tutto sia indicizzato e non possiamo fare tutto sempre.

La parte difficile […] è che, in passato, […] molti siti Web non erano tecnicamente eccezionali. Era un po' più chiaro quale tipo di contenuto non veniva indicizzato. Al giorno d'oggi, i siti Web sono tecnicamente a posto, ed è […] come se la barra della qualità fosse un po' più alta […]. Chiunque può pubblicare qualcosa che, in teoria, potrebbe essere indicizzato, ma […] dobbiamo assicurarci di indicizzare le cose giuste che sono effettivamente utili e rilevanti per gli utenti. Quindi a volte dobbiamo lasciare alcune cose non indicizzate".

Aggiornamento delle recensioni dei prodotti: lingue e paesi interessati

14:01 “Informazioni sull'aggiornamento delle recensioni dei prodotti. […] Anche se l'aggiornamento riguarda solo i siti in lingua inglese, ho notato dei movimenti anche nella ricerca tedesca. Mi chiedevo se questo aggiornamento delle recensioni dei prodotti o qualsiasi tipo potesse avere un effetto anche sui siti Web in altre lingue […]?”

Come ha detto John, " La mia ipotesi era che questo fosse globale e in tutte le lingue […]. Ma di solito, cerchiamo di spingere il team di ingegneri a prendere una decisione in merito, in modo da poterlo documentare correttamente nel post del blog. Non so se è successo con l'aggiornamento delle recensioni dei prodotti. […] Sembra qualcosa che potremmo fare in più lingue e non sarebbe legato solo all'inglese. E anche se inizialmente fosse inglese, sembra qualcosa di rilevante su tutta la linea e dovremmo cercare di trovare modi per estenderlo anche ad altre lingue nel tempo. Quindi non sono particolarmente sorpreso di vedere i cambiamenti in Germania […]”.

Dopo aver appreso che il post del blog di Google menzionava solo l'aggiornamento che interessava i siti Web in lingua inglese, John ha ulteriormente elaborato:

“Con questo tipo di aggiornamenti, proviamo a iniziare con una lingua o una posizione e vediamo cosa dobbiamo modificare, quindi ci espandiamo da lì. […] Con qualcosa che è più legato ai contenuti, di solito ci vuole un po' più di tempo per espandersi in lingue diverse […].”

Localizzazione di pagine per paesi di lingua inglese

17:53 “Conosci altri modi per localizzare lo stesso insieme di pagine per diversi paesi di lingua inglese? […] Abbiamo diversi sottodomini con dominio di primo livello .jo, come forse sottodomini dell'Australia, della Nuova Zelanda, e abbiamo impostato il paese nel backend della JSA e utilizziamo anche hreflang a livello di pagina. […] Non siamo riusciti a trovare altri modi per aiutarci a localizzare questi sottodomini. Hai dei buoni metodi o dei modi in cui possiamo migliorare?”

Ecco come Giovanni ha discusso questo argomento:

“Penso che tu abbia coperto i principali. Questo è il targeting geografico in Search Console e le impostazioni di hreflang.

Il targeting geografico funziona a livello di sottodirectory o sottodominio, ci sono tutte le pagine.

Hreflang è su base per pagina. Se hai una home page per un paese e diverse pagine di prodotto per lo stesso paese, ciascuna di queste pagine dovrebbe essere collegata a hreflang.

L'altra cosa che cerco sempre di consigliare è di avere una sorta di piano di backup, […] qualcosa come un banner basato su JavaScript che puoi mostrare quando riconosci che l'utente si trova sulla versione sbagliata di un sito. Ad esempio, se un utente dall'Australia finisce sulla pagina dall'Inghilterra, potresti mostrare un banner JavaScript che dice: "Ehi, abbiamo una versione australiana di questa pagina qui. Puoi andarci direttamente.' Il vantaggio di un banner basato su JavaScript è che puoi bloccarlo con robots.txt in modo che dal punto di vista dell'indicizzazione non venga visualizzato. E se non esegui il reindirizzamento automatico, […] [i motori di ricerca] saranno in grado di elaborare queste due versioni in modo indipendente.

Se queste pagine sono essenzialmente le stesse, può succedere che trattiamo una di queste pagine come la versione canonica. Ad esempio, se hai una pagina per la Nuova Zelanda e l'Australia e l'intero contenuto è lo stesso, l'unica cosa leggermente diversa è la valuta sulla pagina, allora […] pieghiamo insieme quelle pagine e ne scegliamo una come un canonico e usarlo come base per la ricerca.

Se hai un hreflang, anche su quelle pagine, useremo ancora l'hreflang per mostrare la versione corretta dell'URL. Ma il contenuto indicizzato sarà solo della versione canonica e tutti i rapporti in Search Console saranno per la versione canonica. Questo a volte rende le cose un po' complicate, soprattutto se si dispone di un sito Web più grande con […] lo stesso contenuto per paesi diversi".

Aggiunta di contenuto dinamico alle pagine

25:0 “Il mio sito web ha milioni di pagine, come categorie, sottocategorie e pagine di prodotti, e-commerce […]. Abbiamo aggiunto contenuti dinamici, perché [con] milioni di pagine […] [è] difficile aggiungere contenuti separati o […] contenuti unici su ogni pagina. Abbiamo aggiunto […] contenuti basati su modelli nelle pagine delle categorie, delle sottocategorie e delle pagine dei prodotti. […] Sarebbe positivo o meno per le prestazioni del nostro sito Web, o dovremmo aggiornare il contenuto di ogni pagina? […]”.

Ecco come ha risposto Giovanni:

L'aggiunta dinamica di contenuti pertinenti a una pagina […] può avere senso perché […] [si tratta] essenzialmente solo di eseguire […] una ricerca nel database e di aggiungere contenuti basati su quello. […] Dipende davvero da come lo hai impostato.

La cosa principale che eviterei è che ti imbatti in una situazione in cui stai aggiungendo artificialmente contenuti a una pagina solo nella speranza che questa pagina si classifichi meglio per le parole chiave che aggiungi artificialmente. […] Quando gli utenti vanno lì, saranno come "Perché queste parole chiave casuali su questa pagina?" […] Assicurandomi di avere effettivamente contenuti validi e pertinenti per quelle parole chiave chiave, è più su questo che mi concentrerei […].”

Quando gli è stato inoltre chiesto se fosse necessario scrivere contenuti pertinenti per ogni pagina affinché Google vedesse le pagine come un valore, John ha detto:

“Dovrebbe essere qualcosa sulla pagina che è rilevante. E se è una pagina di categoria, i prodotti che hai elencato sono molto rilevanti […] e di solito hai una descrizione di quella categoria. […] Non è che devi scrivere un articolo di Wikipedia in fondo su tutti questi prodotti e da dove provengono […] ma un po' di informazioni rilevanti per la pagina, che contano.

Rendering e indicizzazione di file JavaScript

28:28 “Il mio sito web […] [usa] Reagisci con il rendering lato client, […] quando disattiviamo JavaScript e il browser, la mia pagina è completamente vuota. Questa può essere la causa del ranking più basso o forse delle scarse prestazioni della pagina web?"

La risposta di John è stata: “ Non dovrebbe essere. […] Per la ricerca, eseguiamo il rendering ed elaboriamo il JavaScript sulle pagine. Se è visibile in un normale browser e non stai facendo nulla di particolarmente male, allora saremo in grado di indicizzare quelle pagine normalmente. Puoi ricontrollare con lo strumento Ispeziona URL in Search Console per vedere se il contenuto è effettivamente visibile quando Googlebot tenta di eseguire il rendering della pagina e se il contenuto è visibile, dovresti essere tutto pronto . "

URL di indicizzazione generati attraverso la ricerca all'interno di un sito web

30:11 "Abbiamo già aggiunto una casella di ricerca nel nostro sito Web , quindi l'utente viene sul nostro sito Web e cerca lì, e genera un URL univoco per ogni ricerca. Questi URL dovrebbero essere indicizzabili o no ?"

Come disse John, “ Di solito no. […] Ci sono due ragioni principali per questo.

Da un lato, è molto facile finire in una situazione in cui hai un altro milione di URL che sono solo ricerche diverse, che non ti forniscono alcun valore. Lo chiamiamo spazio infinito […]. È qualcosa che vuoi evitare.

L'altra cosa che vuoi evitare è che le persone facciano spam nella casella di ricerca e cerchino di indicizzarle , che potrebbe essere qualcosa come cercare il loro numero di telefono e […] il loro tipo di attività […]. Improvvisamente, la pagina di ricerca del tuo sito web si classifica per quel tipo di attività e mostra il loro numero di telefono, anche se non hai alcun contenuto che corrisponda a quelle query, […] lo fanno per cercare di essere visibili nei risultati di ricerca. Bloccherei questo tipo di pagine di ricerca con robots.txt. In questo modo puoi essere sicuro che non saremo in grado di indicizzare nessuno dei contenuti".

Siti SEO come YMYL

31:55 "Un'azienda SEO potrebbe essere classificata come un sito Web Your Money o Your Life o è solo correlata a siti Web di consulenza medica e finanziaria?"

Secondo John, “[…] non penso che i siti web SEO siano così critici per la vita delle persone. Ovviamente, se lavori in un'azienda SEO, sei legato a questo, ma non è che il sito Web stesso sia un sito Web di tipo Your Money o Your Life. […] Non tutti i siti Web che vendono qualcosa rientrano in questa categoria.

Quello che consiglierei qui è, piuttosto che cercare ciecamente di vedere "Questo tipo di sito Web rientra in questa categoria specifica?", […] leggere da dove proviene questa categoria, vale a dire le Linee guida per la valutazione della qualità, e capire un po' di più cosa sta cercando di fare Google con la comprensione di questi diversi tipi di siti web . […] Questo ti darà un po' più di informazioni di base su ciò che sta effettivamente accadendo […].”

Implementazione di dati strutturati breadcrumb

39:56 “Quando si tratta di dati strutturati breadcrumb, devono essere esattamente gli stessi dei breadcrumb che un visitatore vedrebbe su una pagina? A volte vedo una versione ridotta di breadcrumb sulla pagina, mentre i dati strutturati sono un percorso breadcrumb completo. Entrambe le opzioni sono accettabili?"

Come ha detto John, “[…] Cerchiamo di riconoscere se i dati strutturati sono visibili su una pagina o meno. E se non è […], dobbiamo capire “Ha ancora senso mostrarlo nei risultati della ricerca? "

Se stai facendo qualcosa come mostrare una versione più breve di un breadcrumb su una pagina, e non possiamo eguagliarlo, potrebbe essere un po' incostante, se prendiamo effettivamente quel markup breadcrumb e lo usiamo.

Se stai prendendo singole briciole o […] i singoli elementi nell'elenco dei breadcrumb e stai solo mostrando alcuni di questi ma non tutti, è possibile che li raccogliamo semplicemente. Potrebbe essere che raccogliamo ancora il resto perché vediamo […] molte partite di briciole di pane.

Non è garantito che saremo in grado di raccogliere e utilizzare il markup breadcrumb completo di cui disponi se non lo mostri sulla pagina , ed è simile ad altri tipi di dati strutturati.

Penso che l'eccezione principale […] sia […] il markup delle FAQ, dove hai domande e risposte, dove […] la parte importante è che la domanda è effettivamente visibile e la risposta può essere qualcosa come una sezione compressa su un pagina, ma […] almeno deve essere visibile”.

Tradurre solo alcune pagine di un sito web

44:00 “Gestiamo un sito con meno di 300 pagine di indice tutte in inglese. Stiamo cercando di tradurre circa la metà di queste pagine in spagnolo, che verranno inserite nella sottodirectory dello stesso dominio, come /ES, e contrassegnate come versioni linguistiche alternative del contenuto inglese. Va bene tradurre solo alcuni dei contenuti della pagina, o dovremmo tradurre tutto per rispecchiare esattamente il sito Web inglese e avere le migliori possibilità di classificarci in altre posizioni?"

John ha detto: “ Va bene tradurre solo alcune pagine di un sito web. Esaminiamo la lingua delle pagine individualmente. Se hai delle pagine in spagnolo, guardiamo quelle pagine in spagnolo, quando qualcuno sta cercando in spagnolo. Non è il caso di dire: 'Ci sono molte più pagine in inglese che in spagnolo qui. Pertanto, il sito spagnolo è meno importante.' […] Queste sono pagine spagnole e possono classificarsi bene in spagnolo. […] Per gli utenti, a volte, ha senso tradurre più contenuti possibile. Ma di solito, questo è qualcosa che migliori progressivamente nel tempo, in cui inizi con alcune pagine, le localizzi bene e aggiungi più pagine […].

Anche le annotazioni hreflang sono per pagina. Se hai delle pagine in inglese e in spagnolo e le colleghi, va benissimo. Se hai alcune pagine solo in spagnolo, va bene: non hai bisogno di hreflang. Alcune pagine solo in inglese, va bene anche questo. Da questo punto di vista, questo sembra un modo ragionevole per iniziare".

Scansionare il budget e gli URL generati automaticamente

46:12 “Il sito Web di cui sto parlando è un sito Web WordPress. Genera automaticamente più URL indesiderati. […] c'è un modo in cui posso fermare il crawler per scoprire questi URL? So che posso "noindex" e quelli non sono tutti URL indicizzati. Ma poi, posso vederli su Search Console nella parte Esclusa. […] È un sito di notizie, abbiamo migliaia di URL. […] Influirà sul crawling budget?"

John ha chiesto informazioni sulle dimensioni del sito Web e gli è stato detto che era compreso tra 5.000 e 10.000 URL.

Detto questo, John ha detto: “ Non mi preoccuperei del budget limitato. […] Possiamo eseguire la scansione di molte pagine abbastanza rapidamente, di solito in pochi giorni. L'altra cosa […] è che 'noindex' è un meta tag sulla pagina. Dobbiamo eseguire la scansione della pagina per vedere il meta tag, il che significa che non puoi evitare che controlliamo le pagine "noindex". […] Se vediamo che c'è un "noindex" sulla pagina, di solito nel tempo eseguiamo la scansione di quelle pagine meno spesso. Verificheremo ancora di tanto in tanto, ma non controlleremo tanto quanto una normale pagina altrimenti indicizzata. L'altro approccio consiste nell'usare robots.txt. Con il file robots.txt, puoi bloccare completamente la scansione di quelle pagine. Lo svantaggio è che a volte l'URL stesso può essere indicizzato nei risultati di ricerca, non il contenuto della pagina […].”

Giovanni ha fatto anche il seguente esempio:

“Se […] hai un sito web di notizie sul calcio e alcuni articoli sono bloccati e alcuni articoli possono essere scansionati, se qualcuno sta cercando notizie sul calcio, troverà le versioni indicizzabili delle tue pagine e non importa che ci siano altre pagine bloccate da robots.txt. Tuttavia, se qualcuno esegue esplicitamente una query sul sito per quelle pagine bloccate, potresti vedere quegli URL nella ricerca […]. In una situazione come la tua, […] non mi preoccuperei del crawl budget”.

John ha anche aggiunto: “ Da un punto di vista pratico, sia il 'noindex' che il robots.txt sarebbero in qualche modo equivalenti. […] Questo contenuto probabilmente non verrebbe visualizzato nei risultati di ricerca e avremmo comunque bisogno di scansionarlo se c'è "noindex", ma i numeri sono così piccoli che non contano davvero. Potremmo comunque indicizzarlo con un URL se sono bloccati da robots.txt […]”.

Per quanto riguarda il metodo preferito, John ha detto: “Sceglierei quello che è più facile da implementare dalla tua parte. Se […] hai WordPress e puoi semplicemente avere una casella di controllo sul post che dice "Questa pagina è noindex", forse questo è l'approccio più semplice […]."

Scansione di URL con parametri

54:25 "Vediamo nei nostri file di registro, e anche dimostrando che è Googlebot tramite IEP, molte scansioni dal bot organico agli URL dei parametri UTM, Google Display e campagne universali per app. […] Non vediamo collegamenti provenienti da nessuna parte a quegli URL. […] Hai idea di dove o perché questo potrebbe accadere?”

John ha risposto che "L'unico posto in cui con Googlebot eseguiamo anche la scansione delle pagine che elenchi nelle campagne pubblicitarie […] è per la ricerca di prodotti. Se hai impostato un feed di ricerca prodotto o un feed Merchant Center […], eseguiremo anche la scansione di tali pagine per Googlebot per assicurarci di poterle prelevare per Merchant Center. Se hai taggato URL lì dentro, […] manterremo quegli URL taggati e li rielaboreremo.

Potrebbe anche essere che altre persone siano in grado di inviare questo tipo di prodotti, […] potresti non essere necessariamente tu a inviarli, ma forse qualcuno che sta lavorando per tuo conto o ha anche il permesso di farlo.

Se troviamo collegamenti a queste pagine da qualche parte, proveremo a eseguirne la scansione. Se hai taggato i link interni all'interno di un sito web, cercheremo comunque di raccoglierlo e scansionarlo. Se hai impostato cose in JavaScript che forse hai URL di monitoraggio con questi parametri impostati da qualche parte e quando elaboriamo JavaScript, sembra che sia un collegamento a quegli URL di monitoraggio, potremmo anche elaborarlo. […] Mi sembra che non si tratti di casi individuali […], ma piuttosto di un gran numero di questi URL, e questo assomiglia molto al lato delle cose di Merchant Center”.