Continua la mia chiacchierata con Walid Gabteni di Light on SEO! Dopo una breve parentesi su UX e CSS Sprite abbiamo parlato della possibilità di nascondere degli elementi della pagina a Google con Javascript in modo volontario e, a volte, involontario. Buona lettura!
Walid: e poi c’è anche il discorso della user experience. Stavo per dire, non c’entra niente con la SEO, non è vero, c’entra. Però c’è anche… il mega-menù, secondo me, quando è fatto bene, con l’iconografia – non so se si dice così in italiano – giusta, che sia leggibile.
Perché non tutti i mega-menù sono brutti Emanuele, vero?
Emanuele: eh, ma per me è come con gli slider, ho un’antipatia particolare per i mega-menu! Poi, ripeto, so che in certi frangenti ci sta e possono esserci anche di bei design, ma il 95% di quello che vedo fa schifo. Poi magari ho visto quelli sbagliati!
Walid: no, guarda. C’è della roba bellissima poi, ad esempio, con le icone su tutti i link che rendono veramente le cose molto più semplici da capire, ce ne sono di fatti bene. Magari con un CSS sprite per non caricare 200 mila immagini.
I mega-menù, secondo me, se son fatti bene, possono essere anche un aiuto dato all’utente per trovare quello che cerca.
Emanuele: per gli ascoltatori meno tecnici: cosa sono gli sprite?
Allora gli sprite di per sé sono delle figure che possono essere anche tipo nei video game, l’omarino che vedete è uno sprite in 2D. Una figura piatta in 2D. Nel sito sono delle immagini che vengono caricate dove, praticamente, c’è una lista, un insieme di iconcine, per esempio: noi facciamo in modo di caricare la stessa immagine, lo stesso file con una chiamata sola, ma la posizioniamo in più punti e “spostando” la parte visualizzata via CSS noi facciamo apparire tutte le varie iconcine dove devono apparire caricando, ripeto, un’immagine sola, facendo una sola chiamata e velocizzando molto la cosa.
Lo dico per i meno tecnici e magari qualcuno si può anche interessare a questa cosa: per altro è una roba che faccio implementare molto spesso, perché è una soluzione vecchissima che c’era già 25 anni fa, ma che pochi usano per qualche strano motivo.
Walid: sì poi la differenza è notevole. Se hai 150 immagini caricate solo per il menù è un problema.
Emanuele, sì, direi anch’io. E poi sul mega-menù, tornando sull’argomento, mi pare che quel lavoro che abbiamo fatto insieme sull’ecommerce del tuo cliente, aveva un problema del genere: c’era un problema di javascript nel menù che non si caricava. Non mi ricordo se era quello, comunque delle volte capita che questi mega-menù, essendo molto complessi, abbiano dentro del javascript e delle robe che va tenuta d’occhio. Siamo sicuri che Google stampi la pagina uguale a come la stampiamo noi?
Adesso, in teoria, il browser che utilizza, chiamiamolo così….insomma, la tecnologia che utilizza il crawler di Google è pari al Chrome in produzione, più o meno. Quindi, in teoria dovremmo vedere le stesse cose che “vede” lui e controllare. Detto questo keep it simple, se si può togliere il javascript dal menù secondo me è meglio, no? Sei d’accordo?
Walid: sì, dipende. A volte poi vogliamo fare un mega-menù, per ottimizzare l’esperienza utente, però vogliamo nascondere dei link a Google perché per la nostra strategia abbiamo deciso che non vogliamo vengano crawlati. Vogliamo chiudere, cioè nel senso, cerchiamo di massimizzare la SEO e abbiamo scelto , ad esempio, una strategia basata sul siloing appunto perché puntiamo sulle chiavi più generiche, sulle macro categorie. Vogliamo aprire con i mega-menù per facilitare l’accesso agli utenti alle pagine più profonde. Però non ne vogliamo linkare dal punto di vista di Google.
Emanuele: ok, quindi tu lo utilizzi ancora come cosa il javascript per fare uno pseudo-cloaking, per nascondere delle cose?
Walid: io no, faccio cloacking server, che è molto diverso.
Emanuele: molto più alla radice
Walid: sì però sono delle cose che sono fattibilissime con i JS. Anche se Google interpreta il JS, basta fare dei test e vedrete che funziona benissimo. Tu puoi ricostruire l’URL su un elemento span ad esempio, dopo un evento: ci sono degli eventi Javascript che Google-bot non provoca. Anche se interpreta il javascript non provoca gli eventi e quindi non succede niente. Non vede che questi elementi span in realtà si trasformano in link
Emanuele: OK, lui vede un contenitore vuoto
Walid: no, non vede un contenitore vuoto. Vede quello che gli fai vedere.
Emanuele: ah, cioè tu gli mostri il testo ma non gli mostri il link. Il link lo fai generare da qualcos’altro.
Walid: esatto
Emanuele: ok, ho capito adesso. Ma tipo? Che tipo di eventi? Perché questa cosa qua non l’ho mai fatta sinceramente con gli eventi.
Walid: allora, può essere un mouse over, se non dico cazzate, quindi col mouse. Una volta il mouse spostato sull’elemento allora l’elemento diventa un link
Emanuele: chiaro, ci aggiunge proprio il tag HTML nel codice, sul mouse over.
Walid: sì, oppure gli puoi anche aggiungere un’altra roba on-click. Gli puoi anche aggiungere un altro elemento on-click. Tu potresti benissimo prendere un elemento span e renderlo cliccabile.
Emanuele: ok, tu on-click gli fai aprire un’altra pagina.
Walid: sì, con lo stile CSS lo puoi rendere veramente come un link, come se fosse un tag HTML a
Emanuele: sì, purtroppo questa cosa l’ho vista fare da un giornale on-line che vende link: secondo me per far finta di vendere dei link ma in realtà non venderli veramente. Tra l’altro a caro prezzo, molto bello. Infatti avevo idea che avessero delle stupidaggini del genere. Bisognerebbe guardare la Search Console e vedere se questo link prima o poi, viene rilevato da Google, perché naturalmente se non lo vede non te lo dà.
Walid: assolutamente. La Search Console , occhio perché io non sono sicuro che Google prenda in conto soltanto i link che vedi nella Search Console . Ho un dubbio, non sono sicuro ma ho un dubbio su questa cosa. Quello di cui stai parlando è comunque già un brutto segnale.
Emanuele: io il campo dei link della Search Console la uso molto poco, devo dir la verità. Perché ci trovi un sacco di boiate, anche se ultimamente un mio cliente ci ha trovato una serie di link da un IP che è venuto fuori che era il suo server e praticamente c‘era Plesk che, se tu chiamavi l’IP della macchina, ti dava una copia 1 a 1 del sito che Google aveva preso come fosse un altro sito. Quindi, praticamente è un mirror del sito che naturalmente linkava internamente il sito con il dominio appioppato da DNS, quindi uno schifo totale. Brutto, brutto, brutto. Ecco, lì è servita la cosa dei link della Search Console .
Walid: te parlavi prima del Javascript, io sono andato su una cosa volontaria per nascondere i link. È ovvio che con i mega-menù…cioè volevo solo riprendere quello che dicevi dicendo che è molto importante assicurarsi infatti che Google veda bene i link se avete del javascript dentro.
Emanuele: tu come la testeresti questa cosa?
Walid: allora, praticamente hai uno strumento molto semplice che è quello del test mobile, il Mobile Friendly Test di Google.
Emanuele: ok, col fetch, sì perchè poi puoi guardare il codice anche da lì
Walid: sì, e perché se non sbaglio, interpreta il Javascript. Tu non vedi il codice sorgente ma il DOM.
Emanuele: il DOM, esatto che è quello importante. Ecco, questa è una distinzione importante che aveva fatto anche Altavilla in un post tempo fa, che effettivamente magari come operatori lo diamo per scontato, ma c’è una grossa differenza tra il codice renderizzato sul DOM e il codice sorgente della pagina. Cioè a noi ci interessa come è stato interpretato dal browser, dal crawler. Insomma, quello che è l’output vero e proprio, non tanto quanto è il codice sorgente. Google non legge il codice sorgente, guarda e valuta il render.
Walid: che non lo legga non lo so, secondo me lo guarda. Il codice sorgente è sempre importante. Dipende, ti do un esempio: se nel codice sorgente nella meta robot ha il noindex che cambi mentre sta caricando la pagina, e poi nel DOM, alla fine, questo noindex diventa index, lui ti prenderà in conto il noindex. Darà la priorità al noindex perché è una direttiva molto importante. E forse si parla anche di sicurezza qui.
Emanuele: era quello che volevo dire. Cioè, secondo me il codice sorgente lui va a leggere determinati meta tag, ci sono delle cose che rimangono nel codice. Questa cosa che l’interpretasse, come dire, della pipe line dell’interpretazione è molto interessante che è una cosa che non avevo effettivamente mai neanche pensato di studiare.
Walid: questo l’ho provato, veramente te lo dico con certezza. Poi sono delle prove comunque che magari sono di 2 o 3 anni fa, quindi ci sta che nel frattempo delle cose siano cambiate.
Un’altra cosa che può essere interessante per valutare come Google vede la pagina, e secondo me è molto comodo. C’è un plug-in per Chrome e Firefox che si chiama Gooreplacer, lo puoi settare con delle espressioni regolari, poi bloccare le chiamate fatte dal tuo browser ad alcune risorse.
Con questo plug-in puoi simulare il file robots.txt di un sito e quindi puoi bloccare, tramite l’espressione regolare, tutte le risorse che sono bloccate a Google.
Allora usando questo Gooreplacer sulla versione in corso, in produzione di Chrome, dovresti vedere quello che vede Google. Ed è bellissimo, per esempio tanti pensano che andando a vedere la cache di Google per una determinata pagina possiamo vedere un po’ quello che vede Google. In parte, il punto è che la cache di Google la state guardando con il vostro navigatore: se non bloccate le risorse che sono bloccate a Google dal robot.xt di conseguenza non vedete la pagina come le vede Google. Anche se state guardando la cache. Parlo di alcuni elementi CSS, Javascript, ecc.
Emanuele: anch’io di solito uso il mobile testing tool, diciamo in maniera approssimativa. Perché poi nessuno ci certifica, o almeno non penso di averlo mai letto, il fatto che usi la stessa tecnologia del crawler, però mi dà probabilmente solo una buona approssimazione.
Walid: no, è ancora in dubbio questa cosa perché…ora comunque è diventato molto più difficile fare cloaking perchè, ora tanti concorrenti possono andare a vedere il tuo cloaking usando lo strumento di Google, il mobile friendly test o anche lo strumento per provare i micro dati.
Detto questo è sempre possibile fare la differenza tra il Google bot e o strumento di Google, del mobile test, con il vero Google bot che passa sul tuo sito. Se state attenti su come sono fatte le chiamate verso il vostro sito, quindi sto parlando degli header, la roba che non vedi nei log, andare a leggere questi header potrete vedere qualche differenza.
Quindi mi immagino che non sia esattamente le stessa cosa (il mobile friendly test e Google-bot) ma il comportamento globale, cioè nel senso gli user agent e Google bot, gli IP sono gli IP di Google bot, il rendering sembra fedele, l’header è un po’ diverso… non lo so, però comunque è una strada. Poi c’è la Search Console anche.
Emanuele: tu dici il fetche as Google, dove adesso c’è solo quello screenshot schifoso. Col menù ti puoi anche un po’ aiutare, sul codice io ho avuto dei problemi, nel senso che delle volte mi sembra che carichi una parte della pagina e non tutto. Mi è capitato di avere delle pagine molto grosse dove secondo me sinceramente delle librerie non arrivava a caricarle perché non arrivava a leggere tutti i codici. Ti è mai capitato?
Walid: può essere ma…non mi è capitato di pagine non caricate integralmente, cioè nel senso mi sono arrivate delle risorse che non è riuscito ad ottenere, però pagine non caricate perché troppo lunghe no
Emanuele: io ho il dubbio che il fetch as Google, essendo che viene chiamato direttamente dagli utenti e non ha un limite di chiamate, venga limitato nell’utilizzo anche se faresti fatica a spammare questa cosa.
Probabilmente lo puoi fare in un qualche modo ma, non è che a Google gli sdrai i server facendo chiamate di fetch as Google. Mi dà comunque l’idea di essere più limitato, cioè magari utilizza la stessa tecnologia di Google bot però ha delle limitazioni per far sì che, se per assurdo tutti i webmaster del mondo si mettono a spammare delle richieste attraverso il fetch as Google, non gli dia dei problemi alla piattaforma.
E quindi anche lì, il fatto che sia 1 a 1 col crawler e che si possa dormire sonni tranquilli o che certe cose siano effettivamente dei problemi perché sul fetch as Google io vedo un problema, io ho un po’ di dubbi. Cioè, purtroppo non abbiamo uno strumento…
Walid: non lo so
Emanuele: eh, il problema è che noi lavoriamo comunque sempre con gli strumenti che abbiamo, non so come dire. Sono tutti escamotage, anche questo di usare il mobile testing tool in teoria dovresti usarlo per vedere se il tuo sito è ottimizzato mobile. In realtà lo usi per vedere magari se carica delle librerie, se fa delle cose un po’ impropriamente.
Walid: sì, ma secondo me è anche il bello della SEO, è andare ad approfittarti di certi strumenti per farne un uso diverso.
Emanuele: sicuramente può essere divertente
Walid: poi sempre meglio di niente
Emanuele: certo, sempre meglio di non aver niente da fare, niente da tentare in determinati frangenti. Questo è poco ma sicuro.
Continua la mia chiacchierata con Walid Gabteni di Light on SEO! Dopo una breve parentesi su UX e CSS Sprite abbiamo parlato della possibilità di nascondere degli elementi della pagina a Google con Javascript in modo volontario e, a volte, involontario. Buon ascolto!
Dario says
Ciao Emanuele e Walid. e’ stato molto interessante.
Per quanto riguarda l’aspetto del dom, mi risulta che google durante la fase iniziale del crawling dovrebbe gia’ poter recepire tutte le componenti fondamentali sul linking e sui dati strutturati (per questo molti siti sviluppati in react o angular vengono servite con dinamiche di server side rendering).
La seconda fase del crawling (il rendering) oltre ad essere differita anche di giorni rischia di diventare problematica o inconcludente se il sito e’ particolarmente lento. Google impiega le risorse per il rendering come lo fa per il crawling (si parla di rendering budget).
Quindi mi viene da pensare che decisamente il google-bot e il mobile friendly test possono non coincidere ed hanno degli scopi diversi. Il mobile friendly test potrebbe mettersi in attesa del carciamento del sito per un tempo decisamente piu lungo rispetto al bot.
Detto questo mi sembra che il cloacking dei link suggerito da Walid sia un’ottima pensata
Non conoscevo gooreplacer, sicuramente gli daro’ un’occhiata 🙂
Grazie e buona giornata.
Emanuele Vaccari says
Ciao Dario! Grazie per il commento molto interessante.
Come dici tu anche io credo che Google faccia un “pre-crawl” basato sul codice per “calcolare” alcuni dati, diciamo, “fattuali” nel codice stesso, come i dati strutturati e, come giustamente dici tu, i link. Ci sono i cosiddetti “grafi” dedicato ed è inutile per Googlebot, penso, gestire un crawl sempre alla stessa profondità e con le stesse risorse ogni volta se gli interessa solamente, ad esempio, un singolo aspetto.
Sul fatto che il rendering sia tendenzialmente differito di giorni tu hai fatto dei test guardando le risorse chiamate da GoogleBot? Personalmente non ho mai ragionato in questi termini, cioè con un delay molto lungo, è una questione interessante. Sul rendering budget ci sono e mi è chiaro, è logico in termini di economia computazionale ed è un buon motivo per fare siti belli veloci (tipo questo!).
Il fatto che Googlebot si possa “stufare” di una pagina che è lenta a renderizzarsi prima che il Mobile Testing Tool è una riflessione interessante, diciamo che eviterei di pormi il problema facendo un sito come si deve o dicendo di farlo a chi mi chiede “perché non mi posiziono?” :).
Grazie del contributo molto interessante!
Francesco says
Ciao, complimenti argomento interessantissimo.
Una domanda ma Gooreplacer come si configura per vedere quello che vede Google?
Emanuele Vaccari says
Ciao Francesco, grazie per il feedback gentile!
Devo ancora metterci le mani ma quello che intendeva Walid è che con questo tool puoi far onorare il robots.txt al browser e, ad esempio, bloccare le risorse di rendering bloccate anche a Google:il robots.txt è fatto per i robot, i crawler, non viene onorato dai browser ed è per questo che vedi cose “diverse”!