Da. Un site poate răspunde cu 200 OK pentru tine, dar cu 403, 429, 5xx, CAPTCHA, timeout sau redirect loop pentru Googlebot, AdsBot ori alt crawler. Cauza poate fi la DNS, CDN, WAF, firewall, hosting, cache sau aplicație. Verificarea corectă compară răspunsurile HTTP, redirecturile și logurile, apoi confirmă identitatea crawlerului înainte de orice allowlist.
Poți avea un produs bun, reclame configurate corect și conținut optimizat, dar să pierzi trafic dacă infrastructura refuză cererile automate. De aici începe uneori călătoria de la Ana la Caiafa: verifici WordPress, pluginurile, robots.txt, CDN-ul și setările SEO, iar blocajul se află în firewall-ul hostingului sau într-o regulă WAF pe care nu o controlezi direct.
Site-ul merge pentru tine, dar nu pentru crawler
Un browser și un crawler nu fac neapărat aceeași cerere. Serverul poate diferenția traficul după IP, User-Agent, ASN, țară, frecvență, reputație, cookie-uri sau comportament. De aceea, aceeași adresă poate produce rezultate diferite:
| Cerere | Răspuns | Ce sugerează |
|---|---|---|
| Browser obișnuit | 200 OK | Pagina pare funcțională pentru utilizator |
| Googlebot | 403 Forbidden | Regulă WAF, firewall, IP sau User-Agent |
| AdsBot-Google | 429 Too Many Requests | Rate limiting sau server suprasolicitat |
| Crawler validat în log | 503 Service Unavailable | Problemă la origin, capacitate sau aplicație |
Problema poate fi intermitentă. Un request poate ajunge la un nod CDN fără probleme, iar următorul la un nod sau server care aplică o regulă diferită. Poate apărea și doar din anumite țări ori pe IPv6. Un test unic, făcut de pe laptop, nu este suficient pentru diagnostic.
Unde se poate bloca accesul pe traseul unei cereri
O cerere publică trece, simplificat, prin acest traseu: DNS → CDN → WAF → firewall → web server → cache → aplicație → WordPress → landing page. Fiecare strat poate răspunde cu altă eroare și are alte loguri.
DNS, IPv4 și IPv6
Un record DNS greșit, o propagare incompletă sau un endpoint IPv6 configurat diferit poate face ca unele sisteme să ajungă la alt server. Verifică separat rezolvarea A și AAAA și compară IP-urile cu infrastructura activă.
CDN, WAF și bot management
CDN-ul și WAF-ul pot aplica challenge-uri, rate limiting sau blocări pe baza scorului de risc. Un challenge JavaScript ori CAPTCHA poate fi potrivit pentru trafic suspect, dar inutil pentru un crawler care trebuie să primească HTML-ul paginii.
Firewall, hosting și server
Reguli ModSecurity, Imunify360, protecții anti-DDoS sau filtre pe reputația IP-ului pot returna 403 fără ca WordPress să fie implicat. Dacă requestul nu apare în logul origin, caută cauza în CDN, WAF sau firewall. Dacă apare cu 5xx, verifică resursele și logurile serverului.
Cache, WordPress și pluginurile de securitate
Un cache configurat greșit poate servi un răspuns vechi, iar un plugin poate bloca o clasă de User-Agent-uri sau IP-uri. Verifică și resursele CSS și JavaScript. Pagina poate avea HTML accesibil, dar randarea poate fi afectată dacă asseturile esențiale primesc 403.
Ce înseamnă 403, 429, 5xx și timeout
Codurile HTTP nu sunt simple detalii de server. Ele spun sistemelor Google dacă există conținut util, dacă serverul este disponibil și dacă trebuie redus temporar ritmul de crawl.
403 Forbidden: serverul a înțeles cererea, dar refuză accesul. Google nu folosește conținutul URL-urilor care răspund cu 4xx, cu excepția tratamentului distinct pentru 429.429 Too Many Requests: indică o limitare sau o suprasolicitare. Google îl tratează ca pe o eroare de server și reduce temporar crawlingul.5xx: indică o problemă la server sau la infrastructura din spatele lui. Dacă persistă, crawlingul încetinește, iar URL-urile pot fi eliminate din index.- Timeout și redirect loop: requestul nu ajunge la un răspuns util. Pentru Google Ads, o destinație care nu se încarcă stabil poate fi considerată inaccesibilă.
Google recomandă să nu folosești 401 sau 403 ca mecanism de reducere a crawlului. Dacă serverul este temporar supraîncărcat, 429 sau 503 pot semnala situația, dar nu trebuie menținute pe termen lung.
Cum verifici accesul Googlebot la un URL
- Notează URL-ul exact și deschide-l într-o fereastră incognito, fără autentificare și fără extensii de browser.
- Rulează testul de headere și redirecturi:
curl -I -L --max-redirs 10 https://exemplu.ro/pagina/. - Compară HTTP, HTTPS, www și non-www. Notează statusul final, lanțul de redirecturi și timpul total.
- Verifică URL-ul în URL Inspection din Google Search Console și consultă Crawl Stats pentru probleme de disponibilitate.
- Citește logurile CDN, WAF și origin pentru aceeași perioadă. Păstrează ora UTC, IP-ul, User-Agent-ul, statusul și request ID-ul.
- Verifică separat pagina,
robots.txt, CSS-ul și JavaScript-ul critic. Nu confunda crawlability cu indexability:robots.txtcontrolează crawlarea, iarnoindexcontrolează indexarea.
Cum verifici dacă requestul este Googlebot real
Nu permite accesul doar pentru că User-Agent-ul conține Googlebot. Acesta poate fi falsificat. Pentru un request din log, Google recomandă reverse DNS pe IP, verificarea domeniului rezultat și apoi forward DNS pentru confirmarea că IP-ul corespunde.
host IP_DIN_LOG
host NUMELE_REZULTAT_DIN_REVERSE_DNSGoogle publică și liste de IP-uri pentru crawlerele și fetcherele sale. Googlebot, AdsBot și fetcherele declanșate de utilizator nu sunt aceeași categorie, deci verificarea trebuie făcută pentru crawlerul potrivit.
Google Ads: de ce landing page-ul poate fi respins
Google Ads verifică accesibilitatea destinației separat de crawlingul organic. Conform documentației Google Ads, o pagină poate fi respinsă pentru Destination not accessible dacă AdsBot primește un 403, dacă pagina este blocată în robots.txt, dacă există o eroare de server sau dacă destinația nu este accesibilă în locațiile relevante.
Verifică URL-ul final al reclamei, tracking template-ul, redirecturile și accesul din țările targetate, inclusiv din SUA. După remediere, testează din nou pagina și retrimite reclama la verificare. Nu schimba bugetul, licitațiile sau anunțurile înainte să confirmi că destinația se încarcă stabil.
WAF și rate limiting fără blocaje accidentale
Soluția nu este oprirea securității. Este o regulă mai precisă, documentată și monitorizată. Dacă folosești Cloudflare sau un alt WAF, caută în evenimente acțiunile block, challenge și rate limit, apoi notează regula care a generat răspunsul.
- Permite crawlerele verificate prin mecanismele furnizorului, nu prin User-Agent-ul trimis de client.
- Aplică rate limiting pe endpointuri sensibile, nu global pe toate paginile publice.
- Lasă HTML-ul și resursele critice accesibile pentru crawlerele legitime.
- Testează schimbarea din logs și din Search Console înainte să o consideri rezolvată.
Crawlere AI și tool-uri SEO: accesul nu garantează citarea
Crawlability este o condiție tehnică, nu o garanție că un site va apărea în AI Overviews sau va fi citat de un produs AI. Fiecare operator poate avea reguli, fetchere și politici proprii. Separă Googlebot de AdsBot, Bingbot, crawlerii de social media și tool-urile SEO.
Înainte să modifici robots.txt sau WAF-ul, stabilește ce acces este necesar pentru obiectivul tău. Documentează blocajele, evită allowlist-urile bazate exclusiv pe User-Agent și nu presupune că un crawler AI este echivalent cu Googlebot.
Cum identifici stratul care blochează cererea
| Observație | Cauză probabilă | Dovadă de cerut |
|---|---|---|
| 403 apare în Security Events, requestul nu ajunge la origin | CDN/WAF | Rule ID, timestamp, request ID |
| 403 apare în access log la origin | Firewall, ModSecurity, server | Access log și error log |
| 429 apare după mai multe requesturi | Rate limiting | Prag, fereastră și endpoint |
| 500/503/504 apar intermitent | Resurse, upstream sau aplicație | PHP-FPM, web server și monitorizare |
| Doar IPv6 sau anumite țări eșuează | DNS, geo-blocking sau rutare | Teste separate pe IP și locație |
Checklist de diagnostic pentru Googlebot și AdsBot
- Confirmă URL-ul final și statusul HTTP.
- Verifică redirecturile, DNS-ul, IPv4/IPv6 și SSL/TLS.
- Verifică
robots.txt, meta robots șiX-Robots-Tag. - Compară browserul, Googlebot și AdsBot în logs.
- Validează IP-ul Google prin reverse și forward DNS.
- Identifică regula exactă din CDN, WAF sau server.
- Aplică o excepție punctuală și retestează.
- Urmărește GSC, Crawl Stats și Google Ads după remediere.
Când merită să escaladezi sau să schimbi hostingul
O regulă greșită se poate corecta rapid dacă ai acces la logs și la configurație. Ai nevoie de developer sau administrator de server când blocajul vine din WAF, firewall, PHP-FPM, nginx/Apache ori dintr-o configurație administrată de provider.
Hostingul devine un risc operațional când incidentele se repetă, nu primești logs sau explicații, nu poți controla regulile care afectează paginile publice și nu există monitorizare pentru 403, 429 și 5xx. Înainte de schimbare, păstrează dovezile: URL, ora UTC, status, headere, redirecturi, User-Agent, IP validat și regula identificată.
Dacă nu poți identifica stratul care răspunde cu 403, 429 sau 5xx, începe cu un audit SEO tehnic al crawlability, indexability, logurilor și infrastructurii. Pentru o verificare mai amplă a indexării și priorităților, vezi și serviciul de audit SEO. Problemele care afectează simultan landing page-urile și măsurarea conversiilor pot fi corelate cu tracking, Analytics și CRO.
Întrebări frecvente
Poate Googlebot fi blocat dacă site-ul se deschide normal?
Da. WAF-ul, firewall-ul, rate limiting-ul, geoblocking-ul sau regulile după IP și User-Agent pot produce răspunsuri diferite pentru crawler și browser.
Ce înseamnă 403 pentru Googlebot?
403 Forbidden este un răspuns 4xx. Google nu folosește conținutul URL-urilor care răspund cu 4xx pentru indexare, iar URL-urile deja indexate pot fi eliminate dacă eroarea persistă.
Este suficient să permit User-Agent-ul Googlebot?
Nu. User-Agent-ul poate fi falsificat. Verifică IP-ul prin reverse DNS și forward DNS sau prin listele oficiale Google.
De ce este respinsă reclama dacă landing page-ul merge pentru mine?
AdsBot poate primi un cod de eroare, poate fi blocat de robots.txt, poate întâlni geoblocking sau poate primi un timeout. Testează URL-ul final și din locațiile relevante.
Accesul Googlebot garantează apariția în AI Overviews?
Nu. Accesul tehnic este necesar pentru sistemele care trebuie să citească pagina, dar nu garantează indexarea, poziționarea sau citarea într-un produs AI.
Când trebuie schimbat hostingul?
Când blocajele reapar, providerul nu oferă dovezi sau control asupra regulilor, iar infrastructura nu susține accesul stabil la paginile comerciale.