HTTPS, mobile indexing e l’infinito ( di Google ) – 📢 EV SEO Newsletter #27

In questo volume:

1. Gli spazi infiniti (da incubo) nella SEO
2. Da luglio Chrome 68 segnalerà i siti non HTTPS come “non sicuri”
3. L’estensione Lighthouse di Google Chrome
4. Habemus mobile indexing!

Eccomi! Come al solito la domenica notte vale come domenica… no? Sono stato a trovare qualche amico da “Da zero a SEO” e quindi vi chiedo di portare pazienza per l’ennesima volta!

1 ► Glenn Gabe oltre a essere una fonte piuttosto valida di news SEO ultimamente scrive anche degli articoli piuttosto interessanti: l’ultima sua pubblicazione parla degli spazi infiniti nella SEO.

Si intende con spazio infinito uno di quei simpatici errori di codice/impostazione sistemistica che generano loop infiniti di pagine autogenerate per tanti possibili motivi. Sopratutto nei CMS proprietari ( quelli per intenderci sviluppati mediamente piuttosto approssimativamente dalle “WEBBE AGENZI” ) può capitare di trovare, in fase di crawling, liste infinite di url ricorsivi che si autoreferenziano allegramente in modo relativo, generando comunque pagine con status code che indica un “successo” 2XX.  Per intenderci ad esempio:

1. sitorotto.it/url/
2. sitorotto.it/url/url/
3. sitorotto.it/url/url/url/
4. sitorotto.it/url/url/url/url/… ( continua all’infinito come un rotolone Regina )

Quando Google inciampa in una di queste meraviglie della scienza succede che:

• Googlebot continua a seguire questo percorso fino a bruciare completamente il crawl budget;
• Rileva una quantità mostruosa di pagine mediamente vuote, e quindi di scarsissima qualità, che “ai suoi occhi” comporranno gran parte del sito;
• Potenzialmente non verranno mai scansionate determinate pagine perché, ad esempio, posizionate più in profondità del loop che non riesce a superare nella struttura oppure…
• … perchè il loop si genera in una pagina raggiungibile dal menu di navigazione e quindi mediamente scansionata molto presto durante il crawling;

Insieme ad un redirect loop è una di quelle cose che letteralmente ammazza un sito lato SEO. E’ sempre bellissimo trovare uno di questi errori e fare bella figura quando il sito prende vita ma è altresì sempre orribile vedere il sito crollare nelle SERP perché abbiamo generato un problema di questo tipo. Questo genere di errori fa perdere “fiducia” a Google e per esperienza riprendere il crawl budget perso ( Google lo abbassa quando capisce che gli si fa perdere tempo ) è una faticaccia.

L’articolo di Gabe è doppiamente interessante perché parla di come affrontare il problema su siti di livello enterprise, probabilmente nel senso sia di grandezza dell’azienda che in riferimento ai perigliosi viaggi cosmici all’astronave di Star Trek: siti formati da centinaia di migliaia di pagine.

A volte non è facile diagnosticare questi problemi quando non ce la si può semplicemente cavare notandoli con una semplice scansione di Screaming Frog, la quale richiede una quantità di memoria misurabile in 2000 tab di Chrome ( unità di misura ufficiale per la misurazione di RAM completamente piena ) per lavorare su numeri così elevati di URL. La guida è ottima e vi consiglio un’attenta lettura, magari insieme alla mia guida alla cancellazione delle URL dall’indice di Google che trovate sul mio sito!

2 ► Luglio 2018 sarà un mese triste per il web: con il rilascio di Chrome 68 il browser segnalerà ogni sito non HTTPS come non sicuro.

Parlo di mese triste perché personalmente ritengo inaccettabile e potenzialmente pericolosa una imposizione del genere:

1. Inaccettabile perché un’azienda privata non dovrebbe poter fare leva con le sue quote di adozione per forzare l’implementazione di una tecnologia che non è la panacea di tutti i mali riguardanti la sicurezza come vorrebbero farci credere o, per meglio dire, come vogliono imporre. Tecnologia per altro costosa e la quale implementazione può generare problemi anche gravi a livello SEO;
2. Potenzialmente pericolosa perché l’accettazione passiva di imposizioni autocratiche come questa crea precedenti terrificanti. Ricordo con orrore anche la storia del pedofilo catturato grazie alla segnalazione degli ingegneri di Google che notarono un traffico di materiale pedo pornografico tramite Gmail: trincerandosi dietro “abbiamo sconfitto il mostro” di fatto hanno fatto passare per positiva una mostruosa violazione della privacy, per altro evidentemente sistematica. Intendiamoci: sono contento che un criminale venga punito, ma iniziando da queste cose qui si arriva a scenari da 1984: certi limiti non vanno superati. Google non può appoggiare il proverbiale pisello sul tavolo e imporre al web l’adozione di una tecnologia. Non vedo l’ora che inizi a vendere certificati o salti fuori che 1 anno o 2 fa si è comprata qualche azienda che, ohibò, li vende a caro prezzo. Un utente di EV Oasis mi ha segnalato  che alcuni tipi di certificato sono comunque segnalati come “non sicuri”, ci sarà da ridere ( in modo amaro ) vedrete;

Rimane purtroppo la realtà dei fatti e a questo punto consiglio il passaggio ad HTTPS: un’etichetta così brutta a vedersi come “SITO NON SICURO” non può che impattare negativamente la percezione di un sito web. Dobbiamo giocare con le carte che ci vengono date. Fatevi però consigliare/seguire da un esperto o perlomeno leggete attentamente questa bella guida dal blog di Evemilano. Se volete qualche informazione in più su HTTPS vi consiglio questo mio video di qualche tempo fa per il quale però dovete in parte scusarmi: mi giravano già parecchio le scatole e riascoltandolo è pieno di parolacce, sono un maleducato!3 ► Google ha pubblicato la categoria “SEO Audit” nella estensione di auditing per Chrome Lighthouse, prendo la notizia come pretesto per parlarvi più in generale di questa simpatica estensione, che di fatto compie on demand una serie di test automatizzati sulle singole pagine web, generando poi una pagina html di risultati numerici ( veri e propri voti ) con indicazioni a riguardo dei singoli test passati/falliti, i quali vengono suddivisi in 5 categorie che possono essere incluse o escluse dall’analisi. E’ interessante perché ci da un’indicazione di quello che per Google ( attenzione: non parliamo di Google Search in particolare ) sono le metriche/implementazioni che rendono un sito valido.

Le categorie di analisi sono:

• Performance: abbastanza self explanatory, si tratta di una serie di analisi che vanno a testare la velocità del rendering del sito, la latenza e le “opportunità” di migliorare in generale la velocità del sito attraverso una gestione accurata di librerie, fogli di stili, immagini, compressioni etc. etc. segnalando di fatto possibili migliorie. Forse è l’analisi meno interessante, preferisco di gran lunga GTMetrix/Pingdom;
• Progressive Web App: le PWA sono ibridi di siti/app studiati per funzionare online e offline. ed il termine stesso è stato coniato dagli ingegneri di Google. Questo test indica quali step sono implementati/mancano perché la vostra PWA sia considerata una vera e propria PWA secondo la checklist di Google. Non avendone mai sviluppata una mi fermo qua, non so valutarne l’utilità effettiva e non so sopratutto se c’era già modo di fare test di questo tipo;
• Accessibility: ecco questo è un test interessante se non vi siete mai preoccupati di rendere accessibile il vostro sito web. In breve: fatelo. Viene analizzata la compatibilità con gli screen reader ( implementazione di testo alternativo ad esempio per gli utenti ipovedenti ), il contrasto testo/sfondo, implementazioni di nomi e tags sugli elementi interattivi, errori nelle liste, nello specificare una lingua e altro ancora. Non mi stancherò mai di dirlo: oltre a rendere il vostro sito più umano farà sicuramente piacere anche a Google Search, fidatevi di me.
• Best Pratices: Vengono testate implementazioni di vario genere per “modernizzare la vostra web app ed evitare problemi di performance“ per citare testualmente il tool. Viene controllata la presenza di librerie JavaScript con vulnerabilità, l’implementazione di HTTPS, l’implementazione di elementi deprecati quali WebSQL DB, App Cache e la “document-write()”, l’implementazione del rel=”noopener” e altro ancora. Sono test interessanti e che raramente vengono presi in considerazione dal webmaster medio, anche se utilizzando un CMS aggiornato si passano la maggior parte delle verifiche;
• SEO: innanzitutto sono sorpreso dal fatto che nessuno abbia pubblicato articoli dove si parla delle INCREDIBBBBILI SCOPERTE riguardo ai “fattori di ranking uffiziali di Guggol” estrapolando i ( pochi ) test di Lighthouse fronte SEO. Non sono niente di rivoluzionario e fanno parte di quella che io definisco la “igiene SEO”, elementi… elementari ed imprescindibili se si vuole parlare di ottimizzazione.
  Tra i soliti noti: presenza di title HTML, presenza di meta description, status code 2XX o 3XX ( anche il reindirizzamento è uno status code “positivo” a livello di presenza ), link con anchor text, l’indicizzabilità della pagina ( no noindex e simili ), implementazione corretta di hreflang e rel=canonical.
  Come test più esotici c’è, rullo di tamburi, la tipografia, con un test sulla dimensione e quindi la leggibilità del testo che, a quanto pare, non deve essere inferiore ai 16px da mobile. L’importanza della tipografia nella SEO non si ferma qui ma mi fa piacere che venga perlomeno nominata. Altro test che la maggior parte delle persone non si aspetterebbe è quello del <meta name=”viewport”> implementato in modo adeguato: senza le pagine mobile vengono stampate come quelle desktop con un semplice resize e non si legge nulla.
  Ultimo test esotico riguarda la presenza di “plugin”: immagino si riferisca a Flash, Real Player ( si ci sono siti che lo richiedono ancora ) & company: i browser mobile moderni possono fare tutto quello che fanno questi plugin con HTML5 semplicemente.In buona sostanza questa estensione non è tanto per i siti web quanto i siti web mobile, una buona percentuale dei test si riferisce proprio al mobile web. E parlando di mobile…

4 ► … un paio di giorni fa ho visto per la prima volta dai logfile di un sito che seguo il passaggio al mobile first indexing: Invece che la solita proporzione 10/90% tra le richieste di pagine di parte di Googlebot mobile e quello desktop che vedo solitamente ho trovato un 60/40% in favore di Googlebot mobile.

Non ho notato variazioni veramente significative nelle statistiche di scansione, ne per il numero di richieste ne per la velocità delle stesse. Si è mosso tutto del 10% ma faccio fatica a imputarlo direttamente a questo cambiamento dello user agent della scansione. Il fatto che però anche la quantità di dati scaricati sia uguale mi fa pensare che dobbiamo dare una bella ottimizzata alle risorse…

Il sito in questione macina parecchio traffico ( più di 11 milioni di sessioni lo scorso anno ) e parecchi soldini in AdSense e non mi sorprende vederlo come capofila in questo passaggio: siti con queste caratteristiche, anche se a rigor di logica si potrebbe pensare il contrario sono i primi ad avere questi rilasci applicati e di fatto a testarli ( anche se sicuramente di test ne sono già stati fatti anche prima! ). L’esperienza mobile la stiamo ottimizzando ora e spero non di non dovervi riportare un calo del traffico dovuto al ritardo in questo senso, sicuramente è diventato un paziente osservato speciale. Un giorno se e quando avrò l’ok vi parlerò del percorso che sta facendo, penso ne vedremo delle belle!