Seo Parity Audit.

Seo Audit Comparativo

Attraverso questo tutorial andiamo a vedere il SEO Parity Audit con Screaming Frog: un’analisi spesso sottovalutata che però può farci scoprire numerose criticità che ostacolano la corretta indicizzazione organica sul Motore di Ricerca.

Grazie a questa analisi sarai in grado di valutare se esistono delle differenze nel modo in cui viene servito il sito web in diversi scenari durante le scorribande del Crawler.

I casi più interessanti per eseguire il SEO Parity Audit sono i seguenti:

• Sito Mobile vs Sito Desktop.
• JavaScript vs HTML raw.
• Sito Live vs sito in Staging (fondamentale durante le migrazioni).

Con il SEO Spider sarai in grado di isolare gli elementi di SEO On-page che variano fra le diverse versioni e che potrebbero impattare il crawling e, di conseguenza, la fase di indexing e il ranking assegnato dal Motore di Ricerca.

Tra gli elementi più comuni da considerare in questo processo includiamo:

• Strutturazione delle pagine;
• Codice di risposta HTTP;
• Titolo della pagina;
• Headings;
• Canonicals;
• Hreflangs;
• Dati Strutturati;
• etc.

Javascript Parity Audit

Configurare il JavaScript Rendering

La prima operazione per eseguire un Parity Audit su un sito web che prevede delle risorse JS è configurare la modalità di scansione JavaScript Rendering:

1Configuration›2Spider›3Rendering›4JavaScript

Abilitando la scansione JavaScript il SEO Spider scansiona e serve sia l’HTML statico sia quello renderizzato dopo l’esecuzione del JavaScript. Nella tab di configurazione, oltre a scegliere “JavaScript Rendering”, ti consiglio di impostare come Viewport l’opzione “Googlebot Mobile Smartphone”, visto l’orientamento del Motore di Ricerca verso il Mobile First Indexing.

Una volta definita la modalità di scansione dovrai abilitare le risorse da esaminare dal menu 1Configuration›2Spider›3Crawl. Ricorda che se alcune risorse sono presenti in un sottodominio o in un differente root domain devi selezionare anche l’opzione Check external links, altrimenti il SEO Spider non utilizzerà quegli elementi nel rendering.

Completato anche questo aspetto non ti resta che avviare il crawl: il SEO Spider scansionerà il sito web e ti proporrà il rendering delle pagine utilizzando Chrome in modalità headless.

HTML raw e HTML renderizzato

Terminata la scansione potrai consultare i filtri della tab JavaScript e iniziare a valutare se esistono differenze tra l’HTML raw e quello renderizzato. Con i filtri scopri quali pagine presentano contenuti JavaScript e se ci sono differenze nei meta tag, nei canonical o in altri elementi On-page come titoli e heading che vengono aggiornati solamente dopo l’esecuzione di JavaScript.

In modo semplice e intuitivo potrai visualizzare le pagine con contenuti JS e soprattutto quali di questi elementi sono presenti solo dopo la renderizzazione.

Una volta riscontrate delle differenze ti basterà consultare la finestra inferiore di Screaming Frog, selezionare la tab View Source, scegliere come filtro Visible Content e visualizzare l’anteprima delle due versioni abilitando l’opzione Show Differences.

In questo contesto il Parity Audit è molto utile per scoprire se ci sono link presenti solamente nell’HTML renderizzato, che potrebbero non venire mai scoperti dal Bot del Motore di Ricerca e quindi non essere seguiti e indicizzati.

Per scoprire quali link sono presenti solo dopo l’esecuzione del JS clicca sulla tab Outlinks e imposta Rendered HTML come filtro. Per un’analisi più approfondita puoi esportarli con la voce di menu:

1Bulk Export›2JavaScript›3Contains JavaScript Links

Oltre all’analisi dei link puoi valutare tutta una serie di elementi che variano dopo l’esecuzione dello script JS, in base alle esigenze del tuo progetto.

Filtri Tab Javascript

I filtri messi a disposizione da Screaming Frog sono un supporto imprescindibile per gestire al meglio il tuo Parity Audit. Nella versione attuale del SEO Spider la tab JavaScript ne conta 18.

123

1Tab JavaScriptLa tab con i dati del confronto tra HTML raw e renderizzato.2FiltriIl menu a tendina con tutti i filtri della tab.3Word CountParole nell’HTML raw e renderizzato, con la differenza e la percentuale JS.

• Pages with Blocked Resources: le pagine con risorse (JavaScript, CSS, immagini) bloccate dal robots.txt o in errore, che possono compromettere il rendering.
• Contains JavaScript Links: il filtro visualizza le pagine che contengono collegamenti ipertestuali scoperti nell’HTML renderizzato solo dopo l’esecuzione di JavaScript. Questi collegamenti non sono nell’HTML grezzo: è buona norma includere i link importanti lato server nell’HTML statico.
• Contains JavaScript Content: mostra tutte le pagine che contengono il testo del corpo solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Google è in grado di renderizzare le pagine e vedere il contenuto lato client, ma considera di includere il contenuto importante lato server nell’HTML grezzo.
• Noindex Only in Original HTML: tutte le pagine che contengono un tag noindex nell’HTML statico ma non nell’HTML renderizzato. Quando Googlebot incontra un tag noindex salta il rendering e l’esecuzione di JavaScript: usare JavaScript per rimuovere il noindex nell’HTML renderizzato non funzionerà.
• Nofollow Only in Original HTML: identifica le pagine che contengono un attributo nofollow nell’HTML statico e non nell’HTML renderizzato. Questo significa che i collegamenti nell’HTML grezzo prima dell’esecuzione di JavaScript non saranno seguiti. Rimuovi il nofollow se i link devono essere seguiti, scansionati e indicizzati.
• Canonical Only in Rendered HTML: restituisce tutte le pagine che contengono un tag canonical solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Ti consiglio di includere il canonical nell’HTML statico (o nell’intestazione HTTP) per assicurarti che Google possa vederlo, senza fare affidamento solo sull’HTML renderizzato.
• Canonical Mismatch: identifica le pagine che contengono un canonical diverso nell’HTML statico rispetto all’HTML renderizzato. Questa condizione può causare segnali contrastanti e comportamenti indesiderati da parte del Motore di Ricerca.
• Page Title Only in Rendered HTML: restituisce le pagine che contengono un title solo nell’HTML renderizzato. Un Motore di Ricerca deve quindi renderizzare la pagina per vederlo: considera di includere il contenuto importante lato server nell’HTML grezzo.
• Page Title Updated by JavaScript: identifica le pagine con title modificati da JavaScript, cioè con un title nell’HTML statico diverso da quello nell’HTML renderizzato.
• Meta Description Only in Rendered HTML: restituisce le pagine che contengono una meta description solo nell’HTML renderizzato dopo l’esecuzione di JavaScript.
• Meta Description Updated by JavaScript: tutte le pagine con meta description modificate da JavaScript, quindi diverse tra HTML statico e HTML renderizzato.
• H1 Only in Rendered HTML: le pagine che contengono un H1 solo nell’HTML renderizzato. Un Motore di Ricerca deve renderizzare la pagina per considerare l’heading: includi gli heading lato server nell’HTML statico.
• H1 Updated by JavaScript: le pagine con H1 modificati da JavaScript, cioè con un H1 nell’HTML grezzo diverso da quello nell’HTML renderizzato.
• Uses Old AJAX Crawling Scheme URLs: gli URL che usano ancora il vecchio schema di scansione AJAX con il frammento #!, non più supportato da Google.
• Uses Old AJAX Crawling Scheme Meta Fragment Tag: le pagine che contengono il meta tag fragment del vecchio schema AJAX.
• Pages with JavaScript Errors: le pagine con errori JavaScript rilevati nella console di Chrome durante il rendering.
• Pages with JavaScript Warnings: le pagine con avvisi JavaScript nella console di Chrome.
• Pages with Chrome Issues: le pagine con problemi segnalati da Chrome durante il rendering.

Mobile vs Desktop

Con il Mobile First Indexing il Motore di Ricerca ha definito in modo inequivocabile l’importanza del mobile per il posizionamento organico: il Parity Audit fra le versioni Mobile e Desktop è un’attività essenziale nell’ottimizzazione di un sito web.

Per eseguire il Parity Audit dovrai eseguire tre azioni separate:

1. Scansione del sito web con lo user agent “Googlebot (Smartphone)”.
2. Crawl con lo user agent “Googlebot (Desktop)” o un altro user agent desktop.
3. Utilizzare la modalità di scansione Compare per confrontare i due crawl precedenti.

Ricorda che per questo scenario la modalità di archiviazione dei dati di Screaming Frog deve essere impostata su Database Storage Mode.

User Agent Googlebot per smartphone

Scansiona il tuo sito web utilizzando lo user agent “Googlebot (Smartphone)” da 1Configuration›2User-Agent. Se il sito web comprende contenuti o dipendenze JS devi abilitare anche la modalità di scansione JavaScript Rendering.

123

1User-AgentLa sezione della Crawl Config dedicata allo user agent.2Googlebot (Smartphone)Il preset da scegliere per la scansione mobile.3OKConferma la configurazione e avvia il crawl.

User Agent Googlebot

Ritorna nelle configurazioni, imposta lo User-Agent su Googlebot (Desktop) o su un altro user agent desktop e avvia la seconda scansione con Screaming Frog.

123

1Preset User-AgentsGooglebot (Desktop with Chrome Version) per la scansione desktop.2HTTP Request User-AgentLa stringa inviata al server, compilata dal preset.3Robots User-AgentIl token usato per leggere le direttive del robots.txt.

Comparazione Mobile vs Desktop

Ottenute le due scansioni separate non ti resta che metterle a confronto con la modalità Compare.

Ora clicca sull’icona dell’ingranaggio nella parte superiore dello schermo oppure su 1Configuration›2Compare. Così puoi configurare la funzione Change Detection, che ti permette di identificare differenze su elementi specifici come title, meta description, heading, numero di parole, collegamenti interni, dati strutturati e molto altro.

Per includere tutti gli elementi di analisi è sufficiente abilitare l’opzione Select All in cima alla finestra di configurazione.

Se il sito web è responsive e serve contenuti diversi fra mobile e desktop mantenendo gli stessi URL puoi procedere alla scansione di comparazione; altrimenti dovrai impostare anche la funzione URL Mapping. Nella stessa finestra clicca sulla tab corrispondente e uniforma i sottodomini con una RegEx.

Ora non ti resta che cliccare su OK e su Compare per iniziare il processo di analisi.

ApprofondimentoComparare i dati di 2 scansioni.Come funzionano la modalità Compare, la Change Detection e l’URL Mapping di SEO Spider, passo per passo.Leggi la guida →

Quando l’analisi sarà completata potrai visionare i dati nella Change Detection che trovi nella sidebar laterale del SEO Spider.

Idealmente i contenuti dovrebbero essere identici, ma ci potrebbero essere incongruenze fra mobile e desktop: le scopri dalla schermata principale attraverso i 4 filtri introdotti con la versione 16 di Screaming Frog.

1. Added: identifica tutti gli URL presenti in entrambe le scansioni ma con elementi che sono entrati in un filtro del crawl “Current”. Ad esempio un URL aveva un meta title nella versione precedente mentre nella versione attuale l’elemento risulta mancante: in questo caso l’URL sarà nel filtro “Missing” dell’elemento Page Title.
2. New: comprende tutti i nuovi URL che non erano presenti nella scansione precedente ma sono inclusi nella scansione attuale.
3. Removed: URL presenti in entrambe le scansioni con elementi che erano nel filtro della scansione precedente ma non lo sono più nella scansione attuale. Riprendendo l’esempio del Page Title, questo filtro identifica gli URL che non avevano il title ed erano nel filtro “Missing”, ma nella scansione attuale non ci sono più perché ottimizzati.
4. Missing: URL presenti nella scansione precedente ma non rilevati nel crawl “Current”.

Scorrendo in basso nella tab Change Detection hai a disposizione un Summary molto utile che ti mostra subito tutti i cambiamenti rilevati.

Cliccando sui filtri scopri gli URL interessati dai diversi cambiamenti. Di seguito un esempio di come cambia il Page Title delle pagine.

Qui un esempio di come cambia la profondità di scansione fra le due versioni.

Grazie a questi controlli potrai evitare differenze sostanziali fra le versioni che potrebbero inibire o rendere problematico il ranking del sito web.

Siti Staging vs Live

L’ultima ma non meno importante comparazione riguarda i siti in staging rispetto a quelli live. Questo scenario è molto delicato e va sempre preso in grande considerazione durante le migrazioni.

Il processo di Parity Audit segue gli stessi step del confronto Mobile vs Desktop, includendo sempre l’URL Mapping per uniformare gli URL della versione pubblicata e di quella ancora in sviluppo.