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 disabilitarli per la durata di un crawl o come inserire InspectWP in whitelist.

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 non si maschera da bot di motore di ricerca. Lo user agent contiene il marker InspectWP. Questo significa: se in generale blocchi i bot, blocchi anche InspectWP, e quella è la vera causa principale. La whitelist è solitamente la soluzione più pulita rispetto a disattivare completamente la protezione.

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.

Se non vuoi disabilitare completamente la protezione bot, crea una regola personalizzata WAF di Cloudflare con azione Skip per gli user agent che contengono InspectWP.

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: Cerca le richieste bloccate dagli IP di InspectWP 195.201.17.43 e 46.224.183.125 e aggiungili sotto Whitelisted IPs.
• 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 è: disabilitarli brevemente o aggiungere lo user agent di InspectWP alla whitelist del plugin.

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 inserire in whitelist gli IP di InspectWP 195.201.17.43 e 46.224.183.125. 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 la whitelist 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. Una whitelist a breve termine dell'IP del server InspectWP risolve il problema.

15. Checklist prima di rifare il crawl

• ☐ Cloudflare Bot Fight Mode disattivato
• ☐ Firewall Wordfence in Learning Mode o IP InspectWP in whitelist
• ☐ Plugin di sicurezza (Sucuri / Solid / AIOS) su impostazione moderata
• ☐ IP InspectWP 195.201.17.43 e 46.224.183.125 aggiunti alla whitelist di plugin/hosting
• ☐ 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!