Seo Office Hours, 4 marzo 2022

Pubblicato: 2022-03-22

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

I contenuti si nascondono
1 Test del markup dello schema nel validatore schema.org rispetto a Google Search Console
2 Motivi per cui una pagina potrebbe essere sottoposta a scansione ma non indicizzata
3 Rimuovere le schede di prodotto su un sito di eCommerce può metterti in una posizione di svantaggio?
4 L'importanza della struttura di collegamento interna
5 Schemi di prodotti multipli nella pagina dell'elenco dei prodotti
6 Le tue classifiche possono risentirne se crei pagine in lingue miste?
7 Differenze nei contenuti tra le versioni mobile e desktop
8 Puoi ospitare la tua mappa del sito in un cloud?
9 La cronologia di un dominio può influire sul tuo sito web?

Test del markup dello schema nel validatore schema.org rispetto a Google Search Console

7:41 "John, quindi la mia prima domanda è che Google Search Console sta generando un errore […] nell'elemento di dati strutturato richiesto. Ma quando controllo lo stesso su validator.schema.org, non mostra alcun avviso o errore. Quindi la prima domanda è: è il sito giusto per verificare l'implementazione AMP di una pagina web? […]“

John ha risposto: " Sì, quindi questi strumenti di test hanno scopi leggermente diversi. Probabilmente è per questo che stai vedendo quella differenza. Lo strumento di test in schema.org riguarda maggiormente la comprensione del markup di schema.org in generale, come in generale, in base ai requisiti di schema.org. E lo strumento di test in Search Console si concentra esclusivamente su ciò che possiamo estrarre dai dati strutturati e utilizzare per mostrare nella funzione di ricerca. Quindi è davvero incentrato sulla parte di ricerca di quella storia. E all'interno di Ricerca, utilizziamo solo una piccola parte del markup schema.org. E a volte, abbiamo requisiti leggermente diversi che forse richiediamo un elemento specifico più di quanto richiederebbe il markup di schema.org di base. Ed è per questo che spesso vedi questa differenza. E il validatore schema.org è per il markup teorico, e il validatore di Google è davvero per il lato pratico della Ricerca Google.

9:20 “[…] Fondamentalmente, non è un errore. È un avviso in Search Console. E quando controllo i dettagli in Search Console, dice solo che non stai facendo bene. Quindi ci sarà un modo possibile [per risolvere il problema] o il mio team di sviluppo dovrebbe risolverlo?

John ha spiegato: “Sì, se è un avvertimento, allora non me ne preoccuperei. Fondamentalmente sta solo dicendo che avresti potuto fare qualcosa di diverso. […]. Quello che farei se vuoi scoprire qual è esattamente la differenza, è ricontrollare la documentazione su developer.google.com per la ricerca, dove abbiamo tutti i dati strutturati documentati e tutti i campi obbligatori e consigliati. E probabilmente uno dei campi consigliati o facoltativi è ciò che attiva questo avviso."

Motivi per cui una pagina potrebbe essere sottoposta a scansione ma non indicizzata

14:11 Qual è la possibile ragione per cui […] alcune pagine non sono state indicizzate, anche se sono state scansionate più volte? "

John ha risposto: " Può succedere. Presumo che non sia così frequente perché, di solito, quando decidiamo di eseguire la scansione di qualcosa, siamo anche abbastanza felici di andare a indicizzarlo. Ma può succedere che scansioniamo una pagina e poi, alla fine, decidiamo, in realtà, di non aver bisogno di indicizzarla.

[…] alcune situazioni comuni in cui ciò può accadere, che forse non si applicano al tuo caso, sono se c'è un codice di errore nella pagina. Dobbiamo prima eseguire la scansione, quindi vediamo il codice di errore. Se c'è un noindex nella pagina, dobbiamo prima scansionarlo e poi vediamo il noindex. Se la pagina è un duplicato completo di qualcos'altro che abbiamo già visto, eseguiamo la scansione, vediamo che è un duplicato, ma ci concentriamo nuovamente sulla pagina principale. Quindi quelle sono una specie di situazioni normali in cui eseguiamo la scansione di qualcosa e non lo indicizziamo. Ma può anche succedere che eseguiamo la scansione di qualcosa e poi, quando arriviamo all'indicizzazione, decidiamo, beh, in realtà, vogliamo invece ottenere qualcos'altro dal sito web. "

15:41 "[…] quali altri fattori [oltre a quelli già menzionati] potrebbero indurre Googlebot a decidere, oh, non vogliamo indicizzarlo alla fine?"

John ha detto: “Non lo so a prima vista. Penso che la qualità complessiva del sito Web abbia sicuramente un ruolo in questo, ma di solito, se non siamo convinti della qualità del sito Web, probabilmente non eseguiremmo la scansione della pagina in primo luogo. Quindi questa è, penso, una specie di situazione complicata. E se guardi in Search Console, penso che praticamente per ogni sito avrai il raggruppamento di scoperti ma non indicizzati e anche scansionati e non indicizzati. Questo è, penso, abbastanza comune tra i siti".

La persona che ha posto la domanda voleva sapere se c'è qualcos'altro che dovrebbe esaminare oltre alla qualità della pagina e ai problemi tecnici. John ha consigliato di non concentrarsi troppo su una pagina, “ Penso anche che sia importante non concentrarsi troppo su quella pagina specifica. Quindi, se sei sicuro che, da un punto di vista tecnico, sia tutto a posto, non darei per scontato che la qualità di quella specifica pagina sia un problema, ma piuttosto la qualità percepita di quella parte del sito web o il intero sito web stesso. È un po' il luogo in cui cercherei di vedere cosa puoi fare per migliorare le cose, non solo quella singola pagina che non è stata indicizzata, ma più o meno qual è il quadro più ampio intorno a quella pagina. "

La rimozione di elenchi di prodotti su un sito di e-commerce può metterti in una posizione di svantaggio?

21:48 Quindi gestiamo un sito di eCommerce e ora siamo in una fase in cui vogliamo apportare importanti aggiornamenti alle nostre pagine di categoria. […] in una bozza, vogliamo sbarazzarci degli elenchi di prodotti. Quindi hai le schede dei prodotti con la ricerca sfaccettata, dove puoi filtrare i prodotti che stai cercando. […] quando rimuoviamo l'intero elenco di prodotti dalle pagine delle categorie, avremmo uno svantaggio nelle classifiche perché, in primo luogo, tutti gli altri concorrenti hanno questo tipo di elenchi di prodotti? E in secondo luogo, suppongo che questo sia un elemento così consolidato per le pagine di eCommerce che gli utenti si aspettano […] di avere una sorta di panoramica di tutti i prodotti e i filtri consentono loro di cercare i prodotti che desiderano. "

John ha risposto: “ Non vedrei alcun problema da un punto di vista SEO. Penso che ci siano diverse cose a cui dovresti prestare attenzione, […] in modo che possiamo ancora trovare tutti i singoli prodotti che abbiamo collegamenti puliti lì. Ma se stai semplicemente ridisegnando questa pagina di categoria e facendola sembrare più simile a una pagina informativa, non mi aspetterei alcun problema. Inoltre, non penso che facciamo nulla di speciale con quel tipo di pagine di categoria in Cerca, quindi da quel punto di vista, essenzialmente stai solo cambiando il design.  

Penso che sarebbe diverso se fosse una pagina di prodotto e tu dovessi cambiarla completamente perché cerchiamo di riconoscere le pagine di prodotto e capire dov'è il prezzo, dov'è la disponibilità , questo genere di cose. E se lo facessi sembrare completamente diverso […], allora potrei immaginare che ciò influisca sul modo in cui raccogliamo le pagine dei prodotti e se possiamo mostrarlo nei risultati di Ricerca prodotti o meno. Ma le pagine delle categorie, per quanto ne so, non facciamo niente di speciale con loro. Quindi, se li nascondi, essenzialmente, e ti assicuri che possiamo ancora trovare i collegamenti ai prodotti […] potresti farlo. Ma se vuoi renderli più utili fornendo più informazioni su di essi, penso che sia una buona idea".

Alla fine della domanda, John ha aggiunto che è importante controllare le modifiche dal punto di vista dell'utente : “[…] hai menzionato 'gli utenti sarebbero confusi'. Lo ricontrollerei. Quindi dal lato SEO delle cose, penso che vada perfettamente bene, ma dal lato utente delle cose, probabilmente è qualcosa che vorresti prima testare".

L'importanza della struttura di collegamento interna

25:18 " Se disponi di dati strutturati per l'impostazione di breadcrumb, il collegamento interno è ancora importante per la SEO?"

John ha risposto: "Sì, assolutamente. È qualcosa in cui il collegamento interno è supercritico per la SEO. Penso che sia una delle cose più importanti che puoi fare su un sito web per guidare Google e guidare i visitatori verso le pagine che ritieni importanti. E ciò che pensi sia importante dipende totalmente da te. Puoi decidere di rendere le cose importanti dove guadagni di più, oppure puoi rendere le cose importanti dove sei il concorrente più forte, o forse sei il concorrente più debole. Con i collegamenti interni, puoi davvero concentrare le cose su quelle direzioni e quelle parti del tuo sito. E non è qualcosa che puoi semplicemente sostituire con dati strutturati.

Quindi, solo perché ci sono dati strutturati su una pagina da qualche parte, non li vedrei come un sostituto del normale collegamento interno. Anche se nei dati strutturati fornisci anche URL, noi non utilizziamo tali URL nello stesso modo in cui utilizzeremmo normali link interni in una pagina. Quindi non è assolutamente il caso che le annotazioni hreflang sostituiscano i collegamenti tra le versioni nazionali o le annotazioni breadcrumb sostituiscano i collegamenti tra i diversi livelli di un sito web. Dovresti davvero avere normali collegamenti HTML tra le diverse parti del tuo sito web. E, idealmente, non dovresti avere solo un set di collegamenti di base, ma, piuttosto, dovresti guardarlo in modo strategico e pensare a cosa ti interessa di più, e come puoi evidenziarlo con i tuoi collegamenti interni? "

Schemi di prodotti multipli nella pagina dell'elenco dei prodotti

29:50 Per una pagina di elenco di prodotti, possiamo implementare più schemi di prodotto nella pagina di elenco di prodotti? "

John ha detto: " Dal nostro punto di vista delle politiche, non penso che dovresti farlo, almeno l'ultima volta che ho controllato le politiche sui dati strutturati, perché per i dati strutturati di prodotto, vogliamo davvero che si applichino al elemento della pagina. E se hai più prodotti su una pagina, non è che uno di essi sia l'elemento principale della pagina. Quindi, da questo punto di vista, non dovresti utilizzare più elementi di dati strutturati di prodotti su una pagina di categoria […]. "

Le tue classifiche possono risentirne se crei pagine in lingue miste?

30:30 Esiste una best practice per le pagine con linguaggio misto utilizzato? Ad esempio, la nostra scuola internazionale in Giappone si rivolge a famiglie giapponesi e non giapponesi, ma conserviamo la maggior parte delle informazioni sulla nostra home page in inglese. Aggiungiamo anche il supporto sulla pagina in giapponese. […] Poiché la nostra comunicazione nella vita reale è un linguaggio misto, avere la home page riflette ciò che sembrava più naturale. Siamo puniti nella ricerca se una pagina è una lingua intenzionalmente mista?”

John ha risposto: “Non direi necessariamente che una pagina è punita in un caso del genere. Ma cerchiamo di capire qual è la lingua principale di una pagina e questo ci aiuta a capire per quale tipo di query saremmo in grado di mostrare questa pagina. Quindi, penso, è un po' complicato in un caso come questo.

Possiamo capire anche quando ci sono più lingue su una pagina. Ci rende molto più semplice chiarire che, se qualcuno sta effettuando una ricerca in inglese, questa è la pagina giusta da mostrargli. Quindi potrei immaginare per qualcosa come una home page, forse ha senso avere quel mix o un leggero mix. Se hai una home page come inglese principale, allora forse includi alcuni elementi in giapponese. Se hai un'altra versione principalmente giapponese, con alcuni elementi in inglese, va bene. Ma ci aiuta a capire davvero che, per la maggior parte, questa è una pagina in inglese. E se qualcuno sta cercando in inglese un tipo specifico di scuola internazionale in Giappone, allora ha senso per noi dire, beh, ecco un contenuto inglese che sappiamo si adatta alle tue esigenze e che corrisponde alle domande che ci hai dato. Quindi, da quel punto di vista, non direi necessariamente che la pagina sia punita, ma rende molto più difficile per i nostri sistemi capire come classificare correttamente quella pagina.

Una delle cose a cui puoi pensare qui è guardare in Search Console quali query stanno andando al tuo sito web o alla tua home page. E pensa a quale di queste query potrebbe essere interessata se Google non comprendesse correttamente la lingua. E potrebbe benissimo essere che se la maggior parte delle persone cerca il tuo nome o il marchio della tua scuola, in sostanza, probabilmente non ne risentirebbe affatto. D'altra parte, se la maggior parte delle persone cerca query più ampie, query più generiche, quasi come una frase che corrisponderebbe a qualcosa sulla tua home page, allora potrei immaginare che sarebbe un po' più difficile per te apparire nei risultati di ricerca per , solo perché non siamo sicuri che la tua home page sia effettivamente nella lingua di quella query […].

Una cosa che potresti anche fare, […] è rendere la tua home page una specie di questa versione bilingue […] ma creare pagine separate in aggiunta per la singola lingua in modo che se qualcuno sta cercando informazioni a lungo termine su una scuola internazionale come questo, possono ancora trovare quelle pagine in puro inglese o principalmente in inglese e quindi, da lì, passare al resto del tuo sito web […].

Differenze nei contenuti tra le versioni mobile e desktop

34:20 Se c'è una differenza tra i contenuti nella versione mobile e desktop, significa che Google punirà il sito web e influenzerà il ranking del sito web, o significa semplicemente che Googlebot può trovarlo nella versione mobile, ma ha vinto non riesci a classificarti? "

John ha detto: " Quindi, per la maggior parte, abbiamo spostato la maggior parte della nostra indicizzazione sull'indicizzazione mobile-first, il che significa che in un caso del genere avremmo solo esaminato la versione mobile di un sito web. Quindi, in sostanza, se c'è qualcosa di leggermente diverso nella versione desktop di un sito Web, per la maggior parte, non lo useremmo nemmeno per la ricerca. Quindi non è che puniremmo un sito Web a causa di una differenza, ma, piuttosto, è come se guardiamo solo una versione del sito Web e non sappiamo nemmeno cosa c'è nell'altra versione per trattarla in modo diverso .  

E per la manciata di siti che sono ancora nell'indicizzazione desktop, ciò vale il contrario. Ovviamente, se c'è […] qualcosa nella versione mobile che non è nella versione desktop e vieni indicizzato dal crawler desktop, allora non lo vedremmo davvero. Eseguiamo la scansione della versione alternativa di tanto in tanto, ma non la eseguiamo per raccogliere ulteriori informazioni, ma, piuttosto, solo per confermare che esiste questa connessione tra l'URL desktop e l'URL mobile. "

Puoi ospitare la tua mappa del sito in un cloud?

46:20 Abbiamo una pagina davvero enorme con milioni di URL e […] le mappe dei siti sono attualmente in fase di ristrutturazione. E il nostro team IT sta valutando la possibilità di archiviare […] i nuovi file della mappa del sito nel nostro servizio cloud. Ciò significa da example.com/sitemaps a cloud.com/sitemaps. E ci chiediamo, è un problema se memorizziamo le mappe del sito nel cloud? E se questo non è un problema, dobbiamo anche creare un reindirizzamento permanente per il vecchio URL per questo esempio.com/sitemap, o come dovremmo pianificare il trasferimento? "

John ha detto: " È sicuramente possibile ospitare il file della mappa del sito da qualche altra parte. Ci sono due modi in cui puoi farlo. Uno è se hai entrambi i domini verificati in Search Console, allora funziona. L'altro modo è se lo invii con il file robots.txt, dove specifichi "mappa del sito:" e quindi l'URL della mappa del sito. Questo può anche andare a un dominio diverso. […] Reindirizzerei anche il vecchio file della mappa del sito nella nuova posizione solo per essere pulito, ma probabilmente anche se elimini semplicemente l'URL della vecchia mappa del sito e ti assicuri di inviare correttamente quello nuovo, dovrebbe funzionare.  

Quello che potrebbe essere un po' complicato è che non so come Search Console lo mostrerebbe direttamente nell'interfaccia utente, in particolare, se il file della mappa del sito si trova in una posizione diversa, se Search Console mostrasse le informazioni della mappa del sito nel rapporto di indicizzazione, Per esempio. Ma questo è un problema di segnalazione. Non è qualcosa che si basa sulla funzionalità del file della mappa del sito. È davvero solo che Search Console non lo mostra correttamente. E, ancora, forse lo fa. Non sono sicuro al 100%. "

La cronologia di un dominio può influire sul tuo sito web?

49:40 “[…] Quindi [durante il precedente SEO Office Hours ] abbiamo posto quella domanda sul dominio con una storia come fornitore di servizi di scorta. […] il dominio ha una lunga storia perché la prima istantanea di quel sito è del 1997. […] abbiamo rilanciato il nostro sito nel giugno dello scorso anno […]. E il problema principale che stiamo riscontrando è […] che veniamo ancora segnalati [come contenuti per adulti]. E inoltre, abbiamo questo problema […] – scansionato, attualmente non indicizzato. E stiamo cercando di capire se la cronologia del dominio può effettivamente influire sul fatto che stiamo riscontrando problemi con l'indicizzazione. […] crediamo che il contenuto che pubblichiamo sia di buona qualità. È collegato internamente e cerchiamo di costruire un sito di qualità. Il punto in cui lottiamo al momento è il rendimento della pagina, quindi al momento è in corso l'ottimizzazione per questo. Ma usiamo prerender.io , quindi quella che mostriamo per Google è già una versione prerenderizzata. Quindi, quando si tratta del punteggio di Lighthouse, va tutto bene. […] Cosa possiamo migliorare o cercare per capire perché non veniamo indicizzati? Sono felice di condividere anche l'URL.

John ha offerto di poter dare un'occhiata all'URL in un secondo momento, quindi ha risposto: " Di solito, il lato dell'indicizzazione delle cose non sarebbe correlato se prima ci fossero contenuti per adulti sul sito web.

Il lato dell'indicizzazione potrebbe essere interessato se il contenuto che era presente prima era molto spam. Quindi potrebbe essere qualcosa in cui, dal punto di vista dell'indicizzazione, ci vuole solo un po' per capire, oh, questo nuovo sito Web in realtà non è affatto spam.

Ma se fosse semplicemente che prima c'erano contenuti per adulti, allora potrei immaginare che forse i nostri filtri SafeSearch sono un po' lenti nel riconoscerlo. So che abbiamo adottato alcune misure per renderlo più veloce […], o forse c'è qualcos'altro su SafeSearch che è un po' bloccato.

Il lato SafeSearch è qualcosa che puoi controllare se esegui una query sul sito e quindi attivare e disattivare SafeSearch. Dovresti essere in grado di vedere se sta accadendo qualcosa da SafeSearch o meno. Tuttavia, non lo vedi per quanto riguarda l'indicizzazione. Ma posso dare un'occhiata a questo in seguito, e possiamo vedere se c'è qualcosa di super ovvio di cui posso farti sapere. "