Seo Office Hours, 14 gennaio 2022

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

La dimensione del file robots.txt

00:45 "Ci sono effetti SEO negativi che possono derivare da un enorme robots.txt?"

John ha risposto che "non ci sono problemi SEO negativi diretti con questo. Ma rende molto più difficile da mantenere. E rende molto più facile spingere accidentalmente qualcosa che causa problemi. Solo perché è un file di grandi dimensioni non significa che sia un problema, ma rende più facile creare problemi". […]

04:35 "Oltre ad accorciare radicalmente [il file robots.txt], c'è qualche linea guida per costruirlo?"

John: “No, dipende essenzialmente da te. Alcuni siti hanno file di grandi dimensioni. Alcuni siti hanno file di piccole dimensioni. Dovrebbero funzionare tutti. Abbiamo un codice open source del parser robots.txt che utilizziamo. Quindi quello che puoi anche fare è convincere i tuoi sviluppatori a eseguire quel parser per te o configurarlo in modo da poterlo testare. E poi, controlla gli URL sul tuo sito web con quel parser per vedere quali URL verrebbero bloccati e cosa cambierebbe. E in questo modo, puoi testare le cose prima di farle vivere".

Puoi anche trovare maggiori informazioni sul file robots.txt nella nostra Guida definitiva a Robots.txt per SEO.

Migrazione di una categoria di prodotto in un nuovo dominio

08:56 “Stiamo pianificando di spostare la nostra categoria di prodotti multi-vendor su un nuovo dominio o sottodominio. […] Come classificare il nuovo dominio? Il dominio attuale si posiziona bene su Google e altri motori di ricerca e ci fornisce [con] un buon traffico di ricerca organico. Quanto tempo ci vorrà per far sì che il nuovo dominio riceva la quantità di traffico che stiamo ricevendo ora?"

John ha risposto: “Non credo che ci sia un tempo fisso per quel cambiamento perché sembra che tu non ti stia spostando da un dominio all'altro. Stai passando da un'infrastruttura a un'infrastruttura diversa. E spesso, ciò significa che il contenuto sarà diverso. La struttura delle pagine, forse anche degli URL, sarà diversa. Tutto ciò può cambiare. E tutte queste cose sono elementi che richiedono tempo per essere elaborati. Dipende dal sito Web per quanto riguarda il tempo necessario. E non è che tu possa avere una linea temporale specifica per quello.

Penso che l'altra parte da tenere a mente è che questi cambiamenti possono avere effetti complessivamente positivi o negativi per un sito web. Quindi è possibile fare questo tipo di migrazione e dire, lavoreremo anche sulla SEO e miglioreremo l'interconnessione delle nostre pagine, la struttura degli URL e il formato HTML delle nostre pagine. Tutti questi possono avere effetti molto positivi sul tuo sito web.

Ma allo stesso tempo, se non fai attenzione a queste cose e all'improvviso hai un gran pasticcio di URL e l'HTML non è facilmente comprensibile dai motori di ricerca, allora ciò può avere un effetto negativo. Quindi è qualcosa in cui non dovresti presumere che se stai migrando un negozio di eCommerce da una piattaforma all'altra, sarà lo stesso sull'altra piattaforma dopo un certo periodo di tempo. Può essere simile [o] molto migliore [ma] può anche essere molto peggio. Quindi devi fare attenzione a tutti questi dettagli e pensare a quale sia la struttura finale che desideri e quali elementi SEO vuoi includere in quella migrazione".

11:45 "Quali aspetti negativi dovremo affrontare quando spostiamo quell'infrastruttura in un nuovo dominio?"

Secondo John, “[…] Di solito, cosa succede in una situazione in cui tutto è molto ben allineato, vedrai alcune fluttuazioni nel tempo in cui apprendiamo del nuovo sito Web a quando spostiamo tutto. E questo è qualcosa in cui suppongo che vedrai meno visibilità nella Ricerca. Ma dipende da tutte le modifiche che apporti lì, dove può richiedere molto più tempo. Può anche essere qualcosa in cui il risultato finale è molto peggiore o addirittura molto migliore di prima.

Reindirizzamento dell'app

20:38 “ Sai quali sono i rischi di reindirizzare gli utenti da uno strumento di pagina del sito come un'app? Ha un impatto negativo sul traffico dal punto di vista SEO? […] La nostra app ha un tasso di conversione più elevato [rispetto alla nostra versione mobile], quindi stiamo pensando che forse possiamo reindirizzare alcuni utenti quando accedono ad alcune pagine di prodotti o pagine di categorie […] all'app o all'app store. Forse [può] contribuire a una conversione più elevata?"

La risposta di John è stata: “Penso che nel complesso tu possa farlo. L'aspetto a cui generalmente farei attenzione è che lo fai in un modo che consente agli utenti di accedere all'app se lo desiderano. Non conosco tutti i dettagli al momento per quanto riguarda la connessione tra le app e le pagine web, ma credo ci sia un modo per fare un banner intelligente, dove se puoi riconoscere che l'utente ha l'app installata , è molto facile per loro passare all'esperienza dell'app da lì. Ma non conosco i dettagli specifici per Android e iPhone. […]

In generale, dal punto di vista della ricerca, se possiamo indicizzare le singole pagine mobili, anche le pagine desktop o qualsiasi cosa tu abbia a disposizione lì, va benissimo. E se le persone delle tue pagine finiscono per accedere all'app, anche dal nostro punto di vista va benissimo".

22:57 “Stai parlando di un banner in alto nella pagina del sito. Forse se li stiamo [forzando] a reindirizzare, sarà dannoso per la SEO o per il sito?"

John ha dichiarato: “Penso che probabilmente andrebbe bene. Ci sono due cose che ho nella parte posteriore della mia testa, che potrebbero essere qualcosa a cui prestare attenzione.

Poiché Googlebot utilizza anche uno user agent Android, devi assicurarti di non reindirizzare Googlebot all'app store o all'app perché non installeremo l'app. Quindi questa è una cosa. L'altra cosa riguarda, in particolare, le metriche relative a Core Web Vitals. Se reindirizzi sempre gli utenti mobili direttamente tramite l'app, non avrai molti dati per i Core Web Vitals. E a seconda del tuo sito, […] è anche qualcosa da tenere a mente lì. Ma penso, […] non c'è nulla di negativo dal punto di vista SEO se reindirizzi gli utenti a un'app. Dal punto di vista dell'usabilità, renderlo opzionale è molto più bello. Ma alla fine, questo è tra te e i tuoi utenti".

Google può valutare la somiglianza delle pagine?

26:28 "In che modo Google misura la somiglianza delle pagine?"

John ha detto: “Penso di no. Penso che usiamo hreflang per capire quali di questi URL sono equivalenti dal tuo punto di vista. E li sostituiremo. […]

Lo faremmo solo per cose come rel="canonical" per capire qual è l'URL canonico. Ma per hreflang, penso che sia impossibile per noi capire che questo contenuto specifico è equivalente per un altro paese o un'altra lingua. Ci sono così tante differenze locali che sono sempre possibili”.

Controllo dei backlink di spam

27:22 “Siamo un grande sito di eCommerce e ci sono milioni di backlink. Abbiamo una procedura standard per controllare alcuni backlink di spam ogni mese o diversi mesi. Abbiamo appena notato che il limite superiore dell'elenco di Google Disavow è di soli 2 MB. Mi chiedo se il nostro file ha superato il limite, quindi come gestire quei backlink di spam. […] Attualmente, la maggior parte dei link di spam che abbiamo trovato [sono] indirizzati al nostro sito nelle nostre pagine di ricerca, il che è super strano per me."

John ha risposto: "Di solito, consiglierei, da un lato, di provare a utilizzare il più possibile la direttiva del dominio ‒ che ti consente di risparmiare più voci dallo stesso sito e anche di non concentrarti troppo sul tentativo di ripulire tutti i collegamenti perché è sempre impossibile. Mi concentrerei sull'uso di Disavow per i collegamenti, dove li guardi, pensi, se qualcuno del team del sito Web dovesse guardare questo, sarebbe sicuro al 100% che li hai acquistati o che ci sia stato uno scambio in corso qui. Ma per tutti questi tipi di collegamenti casuali che un sito Web riceve, e anche da pagine di spam o copie o post casuali del forum, quelle non sono cose che devi inserire nel file Disavow. […]

Non so se questo è il caso nella tua situazione, ma ho visto che prima [questi link] indirizzano le pagine dei risultati di ricerca con una query specifica che include cose come un numero di telefono o un URL nella speranza che quel telefono numero compare nei risultati della ricerca. E se indicizzi le pagine dei risultati di ricerca o le pagine dei risultati di ricerca che contengono forse una query più lunga, non vengono automaticamente indicizzate.

Calo del traffico rispetto alla rimozione delle pagine AMP

30:43 "Dovremmo aspettarci un calo del traffico se rimuoviamo AMP?"

John: "Presumo che questa sia una configurazione, in cui hai pagine HTML tradizionali e pagine AMP e ti colleghi tra di loro. Penso che ci siano tre cose che si uniscono quando rimuovi le pagine AMP in questo modo.

Da un lato, ci sono alcune funzioni di ricerca limitate alle pagine solo AMP. […] Dovrei ricontrollare, ma non credo che al momento ci siano funzioni di ricerca disponibili solo per le pagine AMP. Quindi da quel punto di vista, non perderesti nulla lì.

L'altra cosa è che le pagine AMP tendono ad essere molto veloci, oppure è più facile creare pagine AMP molto veloci. E poiché utilizziamo la velocità e l'esperienza della pagina come fattore di ranking, è qualcosa per cui se hai molte pagine molto veloci in AMP e passi a pagine più lente che non sono AMP, potresti vedere un effetto lì. Ovviamente puoi anche creare pagine molto veloci che non siano AMP. Non è limitato a AMP. Quindi è qualcosa in cui ricontrollerei per vedere come si applicano le cose per quanto riguarda la velocità.

E penso che il terzo sia […] questo presupposto che le pagine AMP in qualche modo si classificano meglio. E non è così. AMP non è un fattore di ranking. Quindi non dovrebbe essere qualcosa in cui vedresti un cambiamento nel ranking solo perché hai pagine AMP o non hai pagine AMP. […]

Se puoi assicurarti che le tue pagine normali siano veloci ed equivalenti e di avere tutti i dati strutturati di cui hai bisogno in quelle pagine normali, probabilmente puoi disattivare AMP. E sarà essenzialmente molto simile. Quello che probabilmente vedrai è un periodo di transizione in cui alcune pagine AMP sono ancora nella cache AMP e impiegano un po' di tempo per uscire. Ma in generale, è possibile disattivarli. Abbiamo un articolo del Centro assistenza sulla disattivazione delle pagine AMP, quindi ricontrollerei anche quello".

Pannelli della conoscenza

35:17 "Negli ultimi mesi, ho notato che Google esaminava i Knowledge Panel per determinate ricerche di nomi in modo molto coerente su dispositivi mobili e per niente su desktop per la stessa query. […] È possibile capire perché un Knowledge Panel è considerato appropriato per servire utenti mobili ma non utenti desktop in questa situazione? E Wikipedia è il fattore critico per Google quando decide se mostrare o meno un Knowledge Panel?"

John ha detto: “Non sono a conoscenza di cose specifiche che facciamo in modo diverso su dispositivi mobili e desktop per quanto riguarda un Knowledge Panel. Ma è molto comune nelle diverse funzioni di ricerca che, a seconda del tipo di dispositivo nell'area immobiliare che abbiamo a disposizione, attiviamo alcune funzioni e alcune funzioniamo per cercare di essere sicuri di mostrare qualcosa che è utile all'utente in base alla query che stava utilizzando. Da quel punto di vista, non sarei sorpreso se vedessi diversi Knowledge Panel su desktop e dispositivi mobili. Ma penso anche che non ci sia [non] alcun fattore particolare che vorremmo dire, questo è il motivo per cui stai vedendo questo pannello della conoscenza in questo momento e non in un altro momento.

A volte, per quanto riguarda questo tipo di query, in cui stai vedendo questo cambiamento, potrebbe essere che sia solo sul confine, mostriamo un pannello della conoscenza o meno. E poi forse il tipo di dispositivo lo capovolge ed è tipo, diciamo, sì o no alla fine. Ma questo è qualcosa in cui non penso che ci sia un fattore specifico che è coinvolto nel mostrare questi o non mostrarli. Utilizziamo una varietà di fonti diverse per i Riquadri della conoscenza. E alcuni di questi li vedrai direttamente nel pannello della conoscenza. Quindi è una cosa che puoi approfondire un po'.

Un altro consiglio che darei in merito a queste cose è che ci sono alcune persone esterne a Google che hanno passato molto tempo a esaminare i riquadri della conoscenza e come vengono mostrate le cose quando Google raccoglie le cose. […] Jason Barnard è una delle persone che conosco che lo fa bene. Pubblica continuamente post su Twitter sui pannelli della conoscenza. E forse questo ti dà anche alcune idee su cosa potresti guardare lì. "

Il numero di domande da includere in un elenco di domande frequenti

40:41 “Ho da 15 a 20 domande frequenti sulla mia pagina web. Devo includere tutte le domande nello schema delle FAQ o solo le domande che ritengo importanti?"

Secondo John, "Quando si tratta di dati strutturati, vogliamo vedere i dati strutturati visibili sulla pagina, ma non tutti i contenuti visibili devono essere contrassegnati con dati strutturati. Se hai singoli contenuti sulla tua pagina per i quali desideri fornire dati strutturati, vai avanti e fallo. Non devi farlo per ogni contenuto della tua pagina. Quindi, se hai 20 FAQ e ne annoti cinque, dipende totalmente da te. Puoi persino utilizzare il data-nosnippet per bloccare completamente la visualizzazione di alcuni di questi altri elementi in uno snippet, se è qualcosa che vorresti fare.

I problemi di copertura dell'indice

52:00 "Un [problema] è scansionato ‒ attualmente non indicizzato e [quest'ultimo] è stato scoperto ‒ attualmente non indicizzato. E in entrambi i casi, le pagine non sono indicizzate. […] So che Google non indicizza l'intero contenuto. […] Cosa devo fare per rendere queste pagine almeno [indicizzate] più veloci, come il collegamento dalle home page o il collegamento dalle pagine, che sono già in classifica per alcune delle query del mio particolare sito Web? […] Potrebbe portare più backlink?”

John ha detto: “Penso che tutte queste cose siano di aiuto. E sembra che tu sia sulla strada giusta e sai un po' cosa aspettarti.

Dal nostro punto di vista, è il caso che non indicizziamo i contenuti su tutti i siti Web, e questo è previsto da parte nostra. Quindi, se stai vedendo gran parte dei tuoi contenuti già indicizzati, penso che tu abbia l'approccio giusto. Ma non significa che tutto sia perfetto. E cose come i collegamenti interni, assicurarsi che la qualità complessiva del sito Web sia davvero buona: aiutano molto.

A volte, potrebbe anche avere senso guardare il sito web in generale e dire, beh, ho inviato 500 pagine nel mio secondo file. E 200 di loro vengono indicizzati. Qual è il valore di quelle 300 pagine che non vengono indicizzate? E c'è qualcosa che forse posso fare per passare dall'avere 500 pagine casuali su un sito web? Forse [sta] riducendo fino a 300 pagine davvero buone su un sito Web per concentrare il valore in meno pagine? In modo che almeno quando quelle poche pagine vengono indicizzate, ottieni molto del valore di quelle pagine, che potrebbe essere che si classificano per parole chiave diverse o funzionano per gli utenti a cui tieni di più come un modo per dare priorità dalla tua parte prima di affidare tutto a Google.

Quindi questo sarebbe il mio approccio lì: da un lato, assicurarmi di avere tutto allineato correttamente con i collegamenti interni e la qualità generale del sito web. E d'altra parte, se vedi che molte delle tue pagine non vengono indicizzate, prova a trovare un modo per chiarire a Google a quali pagine dovrebbero dare la priorità, il che potrebbe essere la rimozione di alcune pagine che non interessa o che non sono critici per il tuo sito.