Cosa fare quando il crawl fallisce, disabilitazione temporanea dei meccanismi di sicurezza

Se il tuo crawl di InspectWP fallisce, restituisce un report vuoto o analizza visibilmente solo una pagina di challenge, i meccanismi di sicurezza sul sito di destinazione sono quasi sempre la causa. Questa guida ti accompagna attraverso ogni ostacolo comune, da Cloudflare a Wordfence al .htaccess, e mostra come allentarli o disattivarli brevemente per la durata di un crawl.

1. Perché i crawl falliscono

Sintomi tipici che ti dicono che una barriera di sicurezza è di mezzo:

• Timeout / crawl interrotto: Il sito non risponde o solo dopo più di 30 secondi.
• Report vuoto o quasi vuoto: Nessun titolo, nessun plugin, nessun tema rilevato, molto probabilmente è stata analizzata una pagina di challenge o di blocco.
• HTTP 403 / 429 / 503: Un firewall ha rifiutato la richiesta o è scattato un rate-limit.
• Contenuto sbagliato: Lo screenshot mostra una pagina di controllo Cloudflare, una pagina di blocco di Wordfence, una schermata coming-soon o un modulo di login invece del tuo sito reale.

2. Prima di iniziare

InspectWP utilizza un vero browser Chrome headless e si presenta come un normale visitatore con un Chrome aggiornato. Il crawl proviene da un pool di IP di server variabili. Non esiste quindi né un IP fisso del crawler né un marker InspectWP nello user agent che potresti inserire in whitelist. Questo significa: se la tua protezione anti-bot blocca i visitatori sconosciuti o li sottopone a una challenge, colpisce anche InspectWP, ed è questa la vera causa del problema. La soluzione è perciò sempre allentare la protezione in questione per la durata del crawl o disattivarla brevemente.

3. Cloudflare

Cloudflare è il motivo più comune di crawl falliti. Accedi alla dashboard di Cloudflare e controlla:

• Security → Bots: Imposta Bot Fight Mode e Super Bot Fight Mode su Off.
• Security → Settings: Imposta temporaneamente Security Level su Essentially Off o Low.
• Security → WAF → Tools: Assicurati che Under Attack Mode sia disattivato (usa High o inferiore).
• Custom Rules: Se hai le tue regole WAF personalizzate, controlla se una di esse blocca user agent o IP.

In molti casi InspectWP riesce a superare da solo una Managed Challenge. Se non ci riesce, l'unica soluzione è abbassare il Security Level o disattivare il Bot Fight Mode per la durata del crawl.

4. Wordfence

Wordfence è il plugin di sicurezza WordPress più diffuso e spesso blocca i crawler in modo molto aggressivo. Ecco come gestirlo:

• Wordfence → Tools → Live Traffic: Verifica se al momento del crawl sono state bloccate delle richieste. La voce ti mostra quale regola è intervenuta.
• Wordfence → Firewall → All Firewall Options: Imposta brevemente il firewall su Learning Mode o Disabled.
• Rate Limiting: Aumenta significativamente le soglie di „Quante visualizzazioni di pagina può fare un crawler al minuto“.
• Block fake Google crawlers: Questa opzione può bloccare InspectWP, disabilitala temporaneamente.

5. Sucuri, Solid Security, iThemes Security, All-In-One Security (AIOS)

Altri plugin di sicurezza ben noti usano meccanismi molto simili. Cerca in particolare:

• Protezione da brute-force / rilevamento 404
• Rate-limiting per user agent sconosciuti
• Liste di blocco in evidenza / consigliate
• Blocco per paese

Disabilita la funzione pertinente o alza le soglie temporaneamente.

6. Limit Login Attempts / Loginizer

Questi plugin bloccano gli IP dopo tentativi di login falliti. InspectWP non tenta mai di accedere, ma: se il tuo server ha appena registrato altri login falliti dal range IP del crawl, l'IP potrebbe essere già bannato. Controlla la lista di blocco del plugin e rimuovi la voce se necessario.

7. Plugin anti-bot e anti-spam

CleanTalk, Blackhole for Bad Bots, StopBadBots e simili operano su euristiche e bloccano qualsiasi user agent insolito. L'unica soluzione è: disattivarli brevemente per la durata del crawl.

8. Plugin coming-soon e di manutenzione

Plugin come SeedProd, WP Maintenance Mode, Elementor Coming Soon o WP Maintenance mostrano ai visitatori esterni una pagina placeholder. InspectWP analizza quindi quel placeholder, non il tuo sito reale. I link di bypass offerti da alcuni plugin solitamente non funzionano per i crawl esterni. Soluzione: disattiva brevemente il plugin, esegui il crawl, riattiva il plugin.

9. Plugin di caching e ottimizzazione

WP Rocket, LiteSpeed Cache, W3 Total Cache e strumenti simili possono produrre risultati di crawl strani quando è attiva un'ottimizzazione aggressiva, ad esempio quando il JavaScript viene ritardato o combinato. Raccomandazioni:

• Svuota la cache prima del crawl
• Mantieni „Bot Cache“ / „Cache for logged-out users“ abilitata, altrimenti InspectWP potrebbe vedere una versione obsoleta
• Controlla le opzioni JavaScript-Delay / lazy-render, InspectWP attende l'interazione, ma ritardi estremi causano timeout

10. Protezione con password, solo membri, contenuti riservati

Una pagina accessibile solo agli utenti loggati o dietro HTTP basic auth non può essere analizzata da InspectWP. Assicurati che l'URL che vuoi analizzare sia pubblicamente raggiungibile senza login. Disattiva brevemente plugin come Restrict Content Pro, MemberPress o Password Protected, oppure imposta la pagina di destinazione come pubblica.

11. .htaccess e nginx, blocchi per IP, paese e user-agent

A livello server, i crawler sono spesso bloccati tramite Deny o RewriteRule. Esempi tipici da file .htaccess che puoi commentare temporaneamente:

# Blocco di user-agent bot (comune)
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|spider) [NC]
RewriteRule .* - [F,L]

# Blocco IP
Deny from 1.2.3.4

# Blocco per paese via mod_geoip
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
Deny from env=BlockCountry

Per nginx, l'equivalente è:

if ($http_user_agent ~* (bot|crawler|spider)) {
    return 403;
}

Commenta queste righe per la durata del crawl.

12. Meccanismi di protezione lato hosting

Alcuni host eseguono il proprio Web Application Firewall (WAF) o regole ModSecurity che non vedrai nell'audit di plugin o .htaccess. Chiedi al loro supporto di allentare la protezione anti-bot per la durata del crawl. Esempi noti:

• All-Inkl, IONOS, Strato: Protezione bot nel pannello di hosting, contatta il supporto o disattiva dal menu cliente.
• SiteGround: AI anti-bot, Smart-WAF, sotto Site Tools → Security.
• Kinsta, WP Engine: Rilevamento bot proprietario, richiedi un allentamento al supporto.
• Hetzner / cloud provider: Raramente problemi WAF, ma sono possibili restrizioni GeoIP.

13. CSP, X-Frame-Options e robots.txt

Per chiarezza: un robots.txt con Disallow: / non impedisce a InspectWP di analizzare, non rispettiamo strettamente il robots.txt. Content-Security-Policy e X-Frame-Options, d'altra parte, possono impedire singole sub-request (iframe, script di terze parti); è normale e non è un errore. I blocker che contano davvero sono le risposte 403/429/503 sul documento principale.

14. Rate limiting e Fail2Ban

A livello server, fail2ban, mod_evasive o nginx limit_req possono bannare l'IP del crawl in pochi secondi, specialmente con molte sub-request parallele. Se hai accesso SSH, controlla /var/log/fail2ban.log o iptables -L. Aumenta le soglie per la durata del crawl oppure rimuovi l'IP bloccato dalla lista dei ban.

15. Checklist prima di rifare il crawl

• ☐ Cloudflare Bot Fight Mode disattivato
• ☐ Firewall Wordfence in Learning Mode
• ☐ Plugin di sicurezza (Sucuri / Solid / AIOS) su impostazione moderata
• ☐ Plugin coming-soon / di manutenzione disattivato
• ☐ Cache del plugin di caching svuotata
• ☐ .htaccess / nginx controllati per blocchi di user-agent/IP
• ☐ Pannello di hosting: protezione bot / WAF rivista
• ☐ La pagina è pubblicamente raggiungibile senza login
• ☐ Cache del browser svuotata e un nuovo crawl di prova eseguito

16. Quando nulla aiuta

Scrivici a hello@inspectwp.com con il dominio e l'ora approssimativa del crawl fallito.

Dopo un crawl riuscito, non dimenticare di riattivare tutti i meccanismi di sicurezza!