Quando si lavora su un sito WordPress, prima o poi arriva quel momento in cui si vuole fare un controllo più serio: link interni, pagine indicizzabili, redirect, titoli SEO, meta description, immagini senza alt, errori 404, canonical, struttura degli heading e così via.
Uno degli strumenti più usati per questo tipo di analisi è Screaming Frog SEO Spider. È praticamente un piccolo crawler installato sul computer che visita il sito pagina dopo pagina, un po’ come farebbe Google, e restituisce una fotografia tecnica molto utile dello stato del sito.
Il problema nasce quando Screaming Frog non riesce a scansionare correttamente il sito.
Nel mio caso specifico, utilizzando Screaming Frog su un sito ospitato su Tophost, la scansione non andava a buon fine. Dopo alcune verifiche e dopo aver aperto un ticket all’assistenza, la risposta di Tophost è stata molto chiara: sistemi di scraping come Screaming Frog vengono bloccati perché effettuano scansioni considerate troppo aggressive.
La cosa importante, però, è questa: Tophost mi ha confermato che i crawler dei motori di ricerca non sono bloccati.
Quindi il punto non è: “Google non riesce a vedere il sito”.
Il punto è: “Screaming Frog, essendo uno strumento esterno di scansione, viene intercettato e limitato dal sistema di protezione dell’hosting”.
E allora cosa si fa?
Vediamolo con calma.
Prima cosa: non è detto che ci sia un problema sul sito
Quando Screaming Frog restituisce errori, non riesce a completare la scansione oppure mostra risposte anomale, la prima reazione è pensare:
“Oddio, ho un problema SEO.”
In realtà non sempre è così.
Se il sito funziona normalmente da browser, se le pagine sono raggiungibili, se Google Search Console non segnala problemi gravi di scansione e se l’assistenza hosting conferma che i crawler dei motori di ricerca non sono bloccati, allora il problema non è necessariamente nel sito.
Molto probabilmente il problema riguarda il modo in cui Screaming Frog viene percepito dal server.
Screaming Frog, infatti, può inviare molte richieste in poco tempo. Per un hosting condiviso o per un sistema con protezioni anti-scraping, questo comportamento può assomigliare più a un bot aggressivo che a una normale visita umana.
E qui entra in gioco Tophost.
Perché Tophost blocca Screaming Frog?
Tophost, come molti hosting, utilizza sistemi di protezione per evitare traffico anomalo, bot indesiderati, scansioni pesanti o attività che possono stressare il server.
Dal punto di vista dell’hosting, Screaming Frog non è “un SEO tool simpatico che vuole aiutarmi a controllare il sito”.
È un software che inizia a richiedere una pagina, poi un’altra, poi un’altra ancora, magari caricando HTML, immagini, CSS, JavaScript, URL interni, redirect e risorse varie.
Se la scansione è impostata in modo troppo veloce, il server può interpretarla come un comportamento aggressivo.
Il risultato può essere uno di questi:
- scansione incompleta;
- risposte 403;
- risposte 406;
- timeout;
- pagine non lette correttamente;
- blocco temporaneo dell’IP;
- dati SEO falsati dentro Screaming Frog.
Nel mio caso, dopo il ticket, Tophost ha confermato che strumenti di scraping come Screaming Frog possono essere bloccati proprio per questo motivo.
Quindi non si tratta per forza di un errore di configurazione WordPress, di Yoast, di GeneratePress, del file .htaccess o del tema.
È più semplicemente una protezione lato hosting.
La cosa fondamentale: Google è bloccato?
Questa è la domanda più importante.
Perché Screaming Frog è utile, certo, ma non è Google.
Se Screaming Frog non riesce a scansionare il sito, bisogna capire se il problema riguarda solo lui oppure anche i motori di ricerca.
Nel ticket, Tophost ha specificato che i crawler dei motori di ricerca non sono bloccati.
Questa frase cambia completamente il peso del problema.
Se Googlebot riesce a visitare il sito, allora non siamo davanti a un’emergenza SEO. Siamo davanti a un limite operativo: non posso usare Screaming Frog nel modo classico, oppure devo usarlo con più attenzione.
Per verificarlo, comunque, conviene controllare sempre anche da Google Search Console.
In particolare, è utile guardare:
- lo stato di indicizzazione delle pagine;
- eventuali errori di scansione;
- lo strumento “Controllo URL”;
- la data dell’ultima scansione Google;
- eventuali problemi di accesso alla pagina;
- la sitemap XML inviata a Google.
Se Google Search Console vede correttamente le pagine, allora il blocco di Screaming Frog non va interpretato come un blocco generale del sito.
Cosa non fare: forzare il blocco a tutti i costi
La prima tentazione potrebbe essere questa:
“Ok, allora provo a camuffare Screaming Frog in qualche modo.”
Tecnicamente, Screaming Frog permette di modificare alcune impostazioni, come user-agent, velocità di scansione, numero di richieste, rendering JavaScript e così via.
Però bisogna stare attenti.
Se un hosting dichiara apertamente che certi sistemi di scraping vengono bloccati perché considerati troppo aggressivi, la soluzione migliore non è cercare di aggirare il blocco in modo furbo.
Non è una buona idea provare a “forzare” il server.
Non è una buona idea aumentare tentativi, richieste o strategie aggressive.
Non è una buona idea trasformare una semplice analisi SEO in una guerra contro il firewall dell’hosting.
Molto meglio ragionare in modo pulito: ridurre il carico, usare strumenti alternativi, controllare il sito con metodi più leggeri e, se necessario, chiedere all’assistenza se esiste una possibilità di scansione temporanea controllata.
Prima soluzione: rallentare Screaming Frog
La prima cosa da provare, se Screaming Frog non funziona su Tophost, è abbassare drasticamente la velocità di scansione.
Screaming Frog può essere configurato per fare meno richieste contemporaneamente. Questo è importante perché molti blocchi non dipendono dal fatto che il programma sia Screaming Frog in sé, ma dal numero di richieste inviate in poco tempo.
In pratica, bisogna trattare il sito come se fosse molto delicato.
Meglio una scansione lenta ma completa che una scansione veloce bloccata dopo pochi secondi.
Una configurazione prudente potrebbe essere:
- poche richieste al secondo;
- numero basso di thread;
- timeout più morbidi;
- scansione limitata alle sole pagine HTML;
- esclusione di immagini, CSS, JavaScript e risorse non indispensabili;
- scansione in modalità “List” invece che “Spider”, se si vuole controllare solo un elenco preciso di URL.
Questo non garantisce che Tophost lasci passare la scansione, perché se il blocco è a monte può intervenire comunque. Però è il primo tentativo sensato da fare.
Il concetto è semplice: Screaming Frog deve sembrare meno una ruspa e più un utente molto paziente.
Seconda soluzione: usare la modalità List di Screaming Frog
La modalità classica di Screaming Frog è la modalità “Spider”: inserisci il dominio e lui segue i link interni, scoprendo progressivamente le pagine.
Il problema è che questa modalità può generare molte richieste.
Una soluzione più controllata è usare la modalità List.
In questo caso non dici a Screaming Frog: “Scopri tutto il sito”.
Gli dai direttamente un elenco di URL da controllare.
Questo elenco può arrivare da:
- sitemap XML;
- elenco pagine WordPress;
- esportazione manuale degli articoli;
- URL principali del sito;
- pagine più importanti lato SEO;
- risultati già presenti in Google Search Console.
In questo modo Screaming Frog non gira liberamente dentro il sito, ma controlla solo quello che gli viene dato.
È una scansione più limitata, certo, ma anche più controllabile.
Per un sito piccolo o medio, soprattutto un sito vetrina o un blog WordPress, può bastare tranquillamente per individuare problemi importanti.
Terza soluzione: partire dalla sitemap XML
Se il sito usa WordPress e Yoast SEO, Rank Math o un altro plugin SEO, molto probabilmente ha già una sitemap XML.
La sitemap è uno dei punti migliori da cui partire, perché contiene l’elenco delle URL che il sito sta dichiarando ai motori di ricerca.
Invece di far scoprire tutto a Screaming Frog, si può prendere la sitemap e usarla come base dell’analisi.
Questo approccio è molto utile perché permette di controllare le pagine realmente importanti.
Per esempio:
- homepage;
- pagine istituzionali;
- articoli del blog;
- categorie;
- portfolio;
- pagine servizio;
- eventuali landing page.
Se Screaming Frog non riesce a scansionare il sito intero, lavorare sulla sitemap è una buona alternativa.
Non sarà una scansione completa come quella fatta da uno spider libero, ma consente comunque di verificare molte cose fondamentali:
- title;
- meta description;
- status code;
- canonical;
- heading;
- word count;
- indexability;
- redirect;
- errori sulle pagine principali.
Quarta soluzione: controllare tutto da Google Search Console
Quando Screaming Frog viene bloccato, Google Search Console diventa ancora più importante.
Perché?
Perché Screaming Frog simula una scansione.
Google Search Console, invece, mostra dati collegati al modo in cui Google vede davvero il sito.
Sono due cose diverse.
Screaming Frog è ottimo per un audit tecnico immediato, ma Google Search Console ti dice se Google sta realmente indicizzando, scansionando o ignorando determinate pagine.
Da Google Search Console puoi controllare:
- quali pagine sono indicizzate;
- quali pagine sono escluse;
- se ci sono pagine con redirect;
- se ci sono errori 404;
- se Google ha letto correttamente una URL;
- se una pagina è canonica o duplicata;
- se la sitemap è stata letta;
- quando Google ha scansionato l’ultima volta una pagina.
In una situazione come questa, Search Console diventa il riferimento più affidabile.
Se Screaming Frog non passa ma Google sì, bisogna dare più peso ai dati di Google.
Quinta soluzione: usare strumenti SEO meno aggressivi
Screaming Frog è molto potente, ma non è l’unica strada.
Se l’hosting blocca gli spider troppo aggressivi, si possono usare strumenti più leggeri o più mirati.
Per esempio, si può procedere con controlli separati:
- un tool per verificare i link rotti;
- un tool per controllare title e meta description;
- PageSpeed Insights per performance e Core Web Vitals;
- Google Search Console per indicizzazione e copertura;
- il controllo manuale della sitemap;
- browser e DevTools per analisi HTML;
- strumenti di validazione schema;
- estensioni browser per SEO on-page.
Il vantaggio di Screaming Frog è che mette tutto insieme in un’unica scansione.
Ma se non funziona, non significa che l’audit SEO sia impossibile. Significa solo che bisogna spacchettare il lavoro in più controlli mirati.
È meno comodo, ma spesso è sufficiente.
Sesta soluzione: creare una copia di staging del sito
Questa è una delle soluzioni migliori se si vuole fare un audit completo senza stressare il sito online.
Si può creare una copia del sito in un ambiente di staging, magari su un hosting diverso o in locale, e far scansionare quella copia da Screaming Frog.
In questo modo non si tocca il sito pubblico e non si rischia di far intervenire le protezioni Tophost.
Naturalmente bisogna fare attenzione a un aspetto: la copia di staging deve essere il più possibile fedele al sito reale.
Devono esserci:
- stessa struttura URL, per quanto possibile;
- stessi contenuti;
- stessi menu;
- stessi articoli;
- stesse categorie;
- stessi template;
- stessi plugin principali;
- stessa gestione di title e meta description.
Non serve necessariamente replicare tutto al 100%, ma più la copia è simile, più l’audit sarà utile.
Questa soluzione è particolarmente interessante per chi lavora in modo professionale sui siti WordPress, perché permette di fare test tecnici senza disturbare l’ambiente di produzione.
Settima soluzione: chiedere a Tophost una scansione temporanea controllata
Visto che Tophost ha risposto in modo chiaro, una possibilità è chiedere se possono consentire temporaneamente una scansione limitata.
Non è detto che accettino, ma si può provare.
La richiesta dovrebbe essere molto precisa.
Non bisogna scrivere semplicemente:
“Mi sbloccate Screaming Frog?”
Meglio scrivere qualcosa del tipo:
Vorrei effettuare un controllo tecnico SEO del mio sito con Screaming Frog. Posso configurare lo spider con una velocità molto bassa e una scansione limitata alle sole pagine HTML. È possibile autorizzare temporaneamente il mio IP oppure indicarmi una configurazione consigliata per non attivare i sistemi di protezione?
Questo approccio è più professionale perché dimostra che non vuoi stressare il server.
Stai chiedendo una finestra di lavoro controllata.
Se la risposta è no, pazienza. Almeno hai una conferma definitiva e puoi organizzarti con metodi alternativi.
Ottava soluzione: fare un audit manuale delle pagine più importanti
Un audit SEO non deve per forza partire da tutte le URL del sito.
Su molti siti, soprattutto siti professionali, le pagine davvero importanti sono relativamente poche.
Per esempio:
- homepage;
- pagina servizi;
- pagina chi sono;
- pagina contatti;
- pagina preventivo;
- pagine portfolio;
- articoli principali del blog;
- categorie strategiche;
- landing page con traffico organico.
Se Screaming Frog non riesce a scansionare tutto, si può costruire una lista delle pagine più importanti e controllarle manualmente.
Per ogni pagina si possono verificare:
- title SEO;
- meta description;
- H1;
- struttura H2/H3;
- presenza di contenuto sufficiente;
- link interni;
- immagini e attributi alt;
- canonical;
- velocità;
- responsive;
- leggibilità;
- call to action;
- dati strutturati;
- indicizzazione in Google.
È un lavoro più artigianale, ma spesso molto più utile di una scansione automatica letta male.
Perché un conto è avere 500 righe esportate da Screaming Frog.
Un altro conto è guardare davvero le pagine che portano valore al sito.
Nona soluzione: controllare i link rotti in altro modo
Uno degli usi più frequenti di Screaming Frog è trovare i link rotti.
Se però Screaming Frog viene bloccato, bisogna trovare un’alternativa.
Per WordPress, si può procedere in vari modi:
- controllare gli errori 404 da Google Search Console;
- usare temporaneamente un plugin per broken link checking;
- analizzare i log del sito, se disponibili;
- controllare manualmente i menu e i link principali;
- usare strumenti online che fanno scansioni meno aggressive;
- verificare i link interni presenti negli articoli più importanti.
Attenzione però ai plugin per controllare link rotti: alcuni possono essere pesanti, soprattutto se lasciati sempre attivi.
Meglio usarli temporaneamente, fare il controllo, correggere gli errori e poi disattivarli.
Su WordPress, questa è spesso una buona regola generale: i plugin tecnici di diagnosi vanno usati quando servono, non sempre lasciati attivi senza motivo.
Decima soluzione: non ossessionarsi con la scansione completa
Qui bisogna essere sinceri: Screaming Frog è comodissimo.
Quando funziona bene, dà una visione tecnica fantastica.
Ma non bisogna trasformarlo in un feticcio.
Un sito può essere controllato anche senza una scansione completa.
Le cose più importanti da verificare sono:
- Google riesce a scansionare il sito?
- Le pagine principali sono indicizzate?
- La sitemap è corretta?
- Non ci sono errori 404 importanti?
- I redirect principali funzionano?
- I title SEO sono scritti bene?
- Le meta description sono coerenti?
- Gli H1 sono unici e sensati?
- Il sito è veloce?
- Il sito è accessibile?
- I contenuti rispondono davvero alle intenzioni di ricerca?
- I link interni aiutano l’utente e Google a muoversi?
Se queste cose sono sotto controllo, il sito non è “fuori controllo” solo perché Screaming Frog non riesce a completare una scansione su Tophost.
Il file .htaccess può risolvere?
Dipende.
Se il blocco avviene a livello di configurazione server o di protezione hosting, modificare il file .htaccess potrebbe non servire a nulla.
Anzi, bisogna stare molto attenti a non complicare inutilmente la situazione.
Il file .htaccess può gestire redirect, regole di riscrittura, accessi, sicurezza e alcune configurazioni Apache. Ma se Tophost intercetta Screaming Frog prima o tramite sistemi di protezione più alti, non è detto che tu possa risolvere tutto da lì.
Quindi, prima di mettere mano a regole strane, conviene chiedersi:
“Il problema nasce dal mio sito o da una protezione dell’hosting?”
Nel caso della risposta ricevuta da Tophost, sembra evidente che il blocco sia voluto e legato alla protezione contro sistemi di scraping.
Quindi non conviene riempire .htaccess di tentativi casuali.
Meglio mantenere il sito pulito.
Devo cambiare hosting?
Non necessariamente.
Questa è una domanda legittima.
Se Screaming Frog non funziona su Tophost, devo cambiare hosting?
La risposta è: dipende dal tipo di lavoro che devi fare.
Se hai un sito piccolo, un sito vetrina, un blog personale o un sito aziendale non enorme, probabilmente puoi convivere con questo limite.
Puoi usare:
- Google Search Console;
- sitemap;
- controlli manuali;
- strumenti alternativi;
- scansioni più leggere;
- audit su staging.
Se invece lavori spesso con audit tecnici completi, siti grandi, centinaia o migliaia di URL, migrazioni SEO, controlli massivi e scansioni professionali, allora il limite può diventare fastidioso.
In quel caso potresti valutare un hosting più adatto a questo tipo di attività, oppure un ambiente di staging tecnico separato dove fare le scansioni.
Ma per un sito normale, il blocco di Screaming Frog non è automaticamente un motivo sufficiente per cambiare hosting.
È più un limite operativo da conoscere.
Il rischio più grande: interpretare male i dati
Quando uno spider viene bloccato, il rischio non è solo non avere dati.
Il rischio è avere dati sbagliati.
Per esempio, Screaming Frog potrebbe mostrarti pagine come non raggiungibili quando in realtà lo sono.
Oppure potrebbe segnalare errori che dipendono dal blocco dell’hosting e non dal sito.
Oppure potrebbe non trovare pagine che Google invece vede tranquillamente.
Questo è il punto più delicato.
Una scansione parziale o bloccata può creare falsi problemi.
Quindi, quando Screaming Frog non funziona bene su Tophost, non bisogna prendere tutto quello che mostra come verità assoluta.
Bisogna sempre confrontare i dati con:
- browser;
- Search Console;
- sitemap;
- controllo manuale;
- risposta del server;
- eventuali log;
- strumenti alternativi.
Un audit SEO fatto bene non si basa mai su un solo strumento.
Un metodo pratico per continuare l’audit SEO
Se mi trovassi davanti a un sito Tophost dove Screaming Frog viene bloccato, procederei così.
Prima controllerei Google Search Console, per capire se Google vede correttamente il sito.
Poi controllerei la sitemap XML, verificando che contenga solo pagine utili e indicizzabili.
Dopo farei una lista delle URL principali del sito: homepage, pagine servizio, articoli più importanti, categorie strategiche, portfolio e pagine di conversione.
A quel punto proverei Screaming Frog in modalità List, con velocità molto bassa, usando quell’elenco di URL.
Se anche così venisse bloccato, passerei a un controllo manuale e ad altri strumenti specifici.
Infine, se avessi bisogno di un audit completo, creerei una copia di staging del sito e farei la scansione lì.
Questo metodo evita di perdere tempo contro il blocco dell’hosting e permette comunque di ottenere informazioni utili.
E per i motori di ricerca?
La cosa da tenere sempre a mente è che Screaming Frog non è il motore di ricerca.
È uno strumento.
Molto utile, ma pur sempre uno strumento.
Se Tophost blocca Screaming Frog ma lascia passare Googlebot, Bingbot e gli altri crawler legittimi, il sito può continuare a essere scansionato e indicizzato normalmente.
Ovviamente è sempre meglio verificare, non fidarsi alla cieca.
Ma non bisogna nemmeno andare nel panico.
Un blocco anti-scraping non significa automaticamente che il sito sia invisibile su Google.
Significa che il server protegge il sito da determinate scansioni automatiche.
Conclusione
Se Screaming Frog non funziona su Tophost, la prima cosa da fare è non confondere il problema dello strumento con un problema SEO del sito.
Nel mio caso, Tophost ha confermato che sistemi di scraping come Screaming Frog vengono bloccati perché possono effettuare scansioni troppo aggressive, ma ha anche specificato che i crawler dei motori di ricerca non sono bloccati.
Questa distinzione è fondamentale.
Screaming Frog può non riuscire a completare la scansione, ma questo non significa automaticamente che Google non riesca a leggere il sito.
La soluzione migliore è lavorare in modo più controllato: ridurre la velocità di scansione, usare la modalità List, partire dalla sitemap, controllare Google Search Console, verificare manualmente le pagine più importanti e, se serve, creare una copia di staging da analizzare senza limitazioni.
In pratica, il blocco di Screaming Frog su Tophost è un fastidio, non necessariamente un disastro.
L’importante è non forzare il server, non interpretare male i dati e non basare tutto su un unico strumento.
Perché un audit SEO serio non dipende solo da Screaming Frog.
Dipende dalla capacità di leggere il sito nel suo insieme: struttura, contenuti, indicizzazione, prestazioni, accessibilità, link interni e reale utilità per l’utente.
Screaming Frog aiuta tantissimo.
Ma se su Tophost viene bloccato, il lavoro SEO non finisce lì.
Semplicemente, si cambia metodo.
