Come e perché gli sviluppatori devono usare la Google Search Console
Riparte con un approccio differente la serie Search Console Training su YouTube, la guida alla Google Search Console realizzata da Daniel Waisberg, Search Advocate della compagnia: se la prima stagione ha fatto focus su alcuni tra i più utili strumenti per webmaster e SEO a disposizione nella suite, le nuove puntate avranno un taglio più specifico. E infatti si comincia da un tema ben preciso, ovvero la descrizione e l’analisi dei tool della GSC che possono servire agli sviluppatori per semplificare e migliorare il loro lavoro.
Google Search Console, vantaggi anche per i developer
Visto che fornisce molte informazioni sulle ottimizzazioni SEO, gli sviluppatori potrebbero pensare che la Search Console non sia utile per loro, premette Waisberg, che punta però a smentire questa tesi.
Nel video infatti spiega quali sono i rapporti più utili per aiutare gli sviluppatori a costruire siti web che siano “sani, trovabili e ottimizzati per la ricerca su Google”, e citando in particolare quattro strumenti, analizzati poi in dettaglio:
- Il rapporto sullo Stato di copertura dell’indice, per scoprire i problemi di indicizzazione della ricerca in tutto il sito.
- Lo strumento Controllo URL per il debug a livello di pagina di problemi di indicizzazione.
- Il rapporto Problemi di sicurezza per trovare e risolvere i problemi che influenzano il sito
- Il nuovo Rapporto Metriche vitals web essenziali, che analizza i Core Web Vitals per assicurare che il sito offra una eccellente page experience agli utenti.
Costruire un sito trovabile e indicizzabile
Il primo rapporto utile ai developer citato in questo episodio è l’Index Coverage, perché per chi lavora nello sviluppo di un sito è cruciale sapere se Google può trovare e fare crawling delle pagine.
“Piccoli glitch possono avere un effetto massiccio, quando si tratta di consentire a Googlebot di leggere i siti web”, dice Waisberg: ad esempio, “a volte vediamo aziende aggiungere accidentalmente un tag noindex a interi siti web, o impedire la scansione dei contenuti con errori nei loro file robots.txt”.
Questi problemi possono essere facilmente scoperti utilizzando il rapporto sullo stato di copertura dell’indice, che il Googler torna a descrivere rapidamente, fornendo anche degli esempi pratici sul tipo di status visualizzato.
- Gli errori impediscono l’indicizzazione delle pagine, che quindi non appariranno in Google, determinando una potenziale perdita di traffico per il sito.
Esempi di errore sono uno status code di risposta 404 o 500, oppure inserire una direttiva noindex in una pagina inviata nella Sitemap.
- Valide con avviso sono pagine che, a seconda del tipo di problema, possono o meno essere mostrate su Google e che quindi conviene esaminare.
Ad esempio, Google potrebbe trovare delle pagine che sono indicizzate, anche se bloccate da robots.txt: ciò viene contrassegnato come un avvertimento perché non è chiaro se si intendeva bloccare la pagina dai risultati della ricerca.
- Le pagine valide sono quelle correttamente indicizzate, che possono essere mostrate su Google Search.
- Le pagine escluse non sono state indicizzate e non appariranno nella Ricerca, ma Google pensa “che questa sia la vostra intenzione o che sia la cosa giusta da fare”.
Per esempio, la pagina ha una direttiva noindex impostata consapevolmente oppure appare secondo Google come duplicato di un’altra pagina.
Controllare i problemi delle singole pagine
Per fare il debug di un problema con una pagina specifica si può utilizzare lo strumento Inspect URL della Google Search Console, che indica lo stato corrente delle pagine, permette di testare live un URL o di chiedere a Google di fare crawling su una pagina specifica, e anche di visualizzare informazioni dettagliate sulle risorse caricate in pagina.
Secondo Waisberg, ci sono varie importanti opzioni disponibili per gli sviluppatori, e in particolare Request Indexing, che avvia una richiesta di nuova indicizzazione a Google (utile in caso di modifiche alla pagina), e View Crawled Page (Visualizza pagina sottoposta a scansione), che consente di verificare la risposta HTTP e il codice HTML restituito.
Migliorare la salute del sito
Se avere un sito che si possa trovare e indicizzare in Google è il primo step, il secondo è rappresentato dal lavoro per ottimizzare la salute del progetto: anche in questo caso la GSC offre vari strumenti per gli sviluppatori, che possono avere dati chiave e indicazioni utili per il loro lavoro.
È il caso del Rapporto sui problemi di sicurezza, che mostra degli avvisi quando Google scopre che il sito potrebbe essere stato violato o usato in modi che potrebbero potenzialmente danneggiare un visitatore o il suo dispositivo.
Tra gli esempi di hacking ci sono l’iniezione di codice dannoso nelle pagine per reindirizzare gli utenti verso un altro sito o per creare automaticamente pagine del sito con frasi senza senso piene di parole chiave; un attacco può anche usare la tecnica dell’ingegneria sociale, che può anche ingannare gli utenti a fare qualcosa di pericoloso, come rivelare informazioni riservate o fare download di software dannoso.
Il nuovo Core Web Vitals Report
L’ultimo strumento presentato è il Rapporto Metriche vitals web essenziali, che mostra le prestazioni delle pagine del tuo sito in base a dati di utilizzo reali (talvolta chiamati dati sul campo).
Il report si basa sulle prime tre metriche individuate da Google per la Page Experience, e quindi:
- LCP, o Largest Contentful Paint, la quantità di tempo che ci vuole per renderizzare il più grande elemento di contenuto visibile nel viewport, a partire da quando l’utente richiede l’URL. Questo valore è importante perché dice al lettore che l’URL si sta effettivamente caricando.
- FID, o First Input Delay, è il tempo a partire dal momento in cui un utente per la prima volta interagisce con la pagina, quando clicca sul link o toccare il pulsante, fino a quando in cui il browser risponde a quell’interazione. Questo è importante nelle pagine in cui l’utente deve fare qualcosa, perché misura quando la pagina è diventata interattiva.
- CLS, o Cumulative Layout Shift, è la quota totale di layout di pagina che si sposta durante la fase di caricamento; questo punteggio è valutato da 0 a 1, dove 0 significa nessun cambiamento e 1 significa il più mutevole. È una metrica importante perché è molto fastidioso avere elementi che si spostano mentre un utente sta cercando di interagire con la pagina.
Il rapporto è suddiviso tra mobile e desktop e mostra un resoconto aggregato con maggiori dettagli, ed è importante sapere che una pagina è inserita nel rapporto solo se ha una quantità minima di dati di segnalazione per una qualsiasi di queste metriche.
