Am întâlnit echipe care și-au pus la punct tot ce înseamnă server: TTFB mic, cache sănătos, CDN bine reglat. Și totuși, graficele de crawl rămâneau plafonate, ca și cum cineva ținea frâna de mână trasă. Când am început să scormonim atent, problema nu era în PHP, nu în Node, nici în imagini.
Se ascundea în preludiul fiecărei conexiuni, în rezolvarea DNS. Dacă numele de domeniu se rezolvă în 300–400 ms din marile huburi de rețea sau, mai rău, dă rateuri intermitente, orice crawler, fie el intern sau Googlebot, se răzgândește, reduce ritmul, reîncearcă. De aici apare senzația aceea ciudată că totul e configurat bine, dar traficul nu vine.
DNS-ul nu este doar o carte de telefon. Pentru crawl rapid, devine un mecanism de semnal, un fel de „servers healthy” sau „servers flaky”. Când rezolvarea e iute și stabilă, cresc șansele ca robotul să apese pedala și să consume mai mult din bugetul tău de crawl.
Când nu, apar microîntreruperi, time-out-uri sau, mai perfid, o variabilitate mare între locații. Iar variabilitatea, pentru crawl, e tot un fel de „nu am încredere”.
Ce înseamnă performanță DNS privită prin lupa unui crawler
Tentația este să privești doar media răspunsului. Dar crawlul simte percentilele 95 și 99, nu media lucioasă din prezentări. Mai contează și consistența între regiuni, rata de erori tranzitorii (SERVFAIL, time-out, NXDOMAIN în lanțuri de CNAME), diferența dintre comportamentul la cache rece și la cache cald, precum și reacția infrastructurii la fallback pe TCP atunci când pachetele se fragmentează. Pentru un crawler, 60 ms stabili peste tot bat 20 ms la Frankfurt și 400 ms la Singapore.
Apropo de lanțuri: fiecare salt suplimentar, de la CNAME la CDN și apoi la A sau AAAA, adaugă latență și riscuri. Țintește lanțuri scurte, previzibile, fără surprize la apex. Dacă furnizorul tău face CNAME flattening la rădăcină, e ideal. Dacă nu, ia în calcul ALIAS sau ANAME, ori o arhitectură care nu obligă apexul la redirecționări DNS încâlcite.
Cum construiești un sistem de măsurare credibil, nu doar „pinguri cu dig”
În timp am ajuns la un principiu simplu: măsurători din mai multe locuri, cu două tipuri de teste, cache rece și cache cald, pe ambele familii de adrese, IPv4 și IPv6. În practică, îmi place să combin trei surse de adevăr care se completează elegant.
Prima este monitorizarea activă, repetabilă, din infrastructura ta, pe care o poți controla și grafica așa cum vrei. Prometheus cu Blackbox Exporter te lasă să probezi DNS-ul ca pe orice alt serviciu. Alegi ce record testezi, ce recursor folosești, cât aștepți și ce coduri consideri valide. Din aceste probe construiești obiective de fiabilitate și alerte care au sens pentru crawl, nu doar pentru NOC.
A doua este măsurarea „din lume”, prin rețele pe care nu le controlezi. Aici intră platforme precum RIPE Atlas sau sondele unor servicii comerciale. Avantajul este că vezi cum se propagă efectiv latența și erorile în regiuni diferite, cu rezolvatoare reale, uneori capricioase. Da, vei descoperi ciudățenii, de la rezolvatoare care rescriu până la interceptări sau rute mai puțin fericite. E bine să le știi, fiindcă robotul web le vede înaintea ta.
A treia este comparația cu furnizori autoritativi și cu rezolvatoare publice, ca reper. Nu pentru marketing cu „suntem cei mai rapizi”, ci pentru a-ți calibra așteptările. Dacă infrastructura ta rămâne constant deasupra curbei furnizorilor de top într-o regiune, ai un semnal că e vorba de rutare sau de topologie anycast care cere atenție.
Un pipeline minimalist cu Prometheus și Blackbox, explicat ca între prieteni
Nu complicăm lucrurile. Descarci Blackbox Exporter, îl rulezi lângă Prometheus și îi spui, cu o bucățică de YAML, ce să întrebe. Un început rezonabil arată cam așa:
# blackbox.yml
modules:
dns_a_cold:
prober: dns
timeout: 3s
dns:
query_name: example.com
query_type: A
recursion: true
transport_protocol: "udp"
preferred_ip_protocol: "ip4"
validate_answer_rrs: true
valid_rcodes: ["NOERROR"]
dns_aaaa_cold:
prober: dns
timeout: 3s
dns:
query_name: example.com
query_type: AAAA
recursion: true
preferred_ip_protocol: "ip6"
valid_rcodes: ["NOERROR"]În Prometheus, definești jobul care lovește acest modul din mai multe locuri. Dacă vrei cache rece constant, folosește etichete unice în subdomeniu la fiecare probă, de pildă un timestamp, astfel încât recursorul să nu aibă ce servi din memorie. Pentru cache cald, întrebi mereu același nume.
# prometheus.yml (fragment)
scrape_configs:
- job_name: 'dns-crawl'
metrics_path: /probe
params:
module: [dns_a_cold]
target: ["example.com"]
static_configs:
- targets:
- 127.0.0.1:9115
relabel_configs:
- source_labels: [__address__]
target_label: __param_target
- target_label: instance
replacement: "resolver-1.1.1.1"
- target_label: __address__
replacement: blackbox-exporter:9115Dacă preferi linia de comandă, dig rămâne un aliat bun, mai ales în scripturi. Un truc pentru cache rece este să pui un prefix aleator la fiecare interogare, de exemplu: dig a $(date +%s).example.com @1.1.1.1 +noadflag +tries=1 +timeout=2. Nu te baza pe acest artificiu pentru grafice pe termen lung, dar e excelent ca să reproduci o suspiciune de latență.
În practică, vei crea mai multe module pentru A, AAAA, CNAME-ul critic, apex și zonele care redirecționează mult trafic, cum ar fi un subdomeniu media. Vei măsura atât prin rezolvatoare publice, 1.1.1.1 sau 8.8.8.8, cât și direct către autoritativul tău, ca să separi problemele de recursie de cele din infrastructura proprie.
Măsurători „din lume” și ce îți spun sondele când nu ești în birou
Adevărul neplăcut este că nu toate rezolvatoarele joacă după manual. Vei întâlni recursori care rescriu, rețele care interceptează, pe scurt situații pe care într-un laborator nu le-ai vedea. De aceea este util să rulezi teste geografice cu sonde independente.
Întrebi din Tokyo, Varșovia sau São Paulo, nu doar din Frankfurt. Urmărești nu doar media, ci dispersia în timp, intervalul 5–95% și coada de latențe foarte mari. Coada aceea lovește crawlingul nocturn, când multe joburi se suprapun.
Dacă ții la un etalon de piață, un panou public de comparație te ajută să nu alergi după fantome. Vezi unde se află furnizorii mari de DNS autoritativ în regiunea ta, iar dacă tu ești constant în afara ferestrei lor, probabil este o chestiune de rutare sau de topologie anycast, nu o zi proastă a serverului.
SLO-uri care contează pentru crawling și alerte care nu bâzâie degeaba
După câteva săptămâni de măsurători, poți să îți asumi ținte realiste. Îmi place un percentil 95 sub 50 ms pe rezolvarea A și AAAA în piețele principale, cu o rată de erori sub 0,5% pe ferestre de 10 minute. Separ în mod explicit problemele de autoritativ, care se văd identic din toți recursorii, de cele de recursie, care afectează doar un subset de rețele.
Alertele le trimit în două trepte, una blândă pentru echipa de rețea când p95 trece de prag timp de 15 minute și una fermă pentru eșecuri dure repetate, mai ales pe apex sau pe CNAME-urile critice. Între aceste stări încerc să păstrez observarea calmă, fără panică. Este ușor să îți otrăvești on-call-ul cu alarme false.
Merită să urmărești diferența dintre IPv4 și IPv6. Sunt regiuni în care AAAA-urile au altă soartă decât A-urile. Pentru un crawl complet și consistent, nu vrei un web dual-stack doar pe hârtie. Pe grafice, vrei linii apropiate, nu două lumi paralele.
Optimizări care chiar se văd în grafice
Începe cu topologia. Dacă nu ești deja pe un DNS autoritativ cu anycast global solid, merită să iei în calcul migrarea. Nu este doar orgoliu tehnic. Latența scade aproape peste tot, iar variația dintre regiuni se liniștește. Pentru CDN-urile moderne, cuplul autoritate anycast plus edge aproape de utilizator aduce un dublu câștig pentru oameni și pentru crawlere.
Apoi simplifici lanțurile. Câte CNAME-uri sunt cu adevărat necesare. Poți muta logica înapoi în autoritativ și lăsa răspunsuri A și AAAA curate. La apex, dacă nu ai flattening, încearcă să reduci dependențele. Fiecare verigă în plus este un punct potențial de întârziere.
Ajustează TTL-urile. Pentru domeniile pe care trece crawling intens, TTL-uri moderate, nici ridicol de mici, nici arhaic de mari, sunt o cale de mijloc sănătoasă. Menții cache-ul eficient, dar nu blochezi propagări importante zile întregi. Pe traseele fierbinți pot funcționa TTL-uri mai scurte, dar doar dacă ții sub control QPS-ul pe autoritativ și costurile.
Nu ignora DNSSEC, însă monitorizează-l corect. Semnăturile mari pot declanșa truncări și fallback pe TCP. Dacă vezi salturi inegale în latență după activare, verifică MTU-urile, EDNS și răspunsurile fragmentate. Siguranța merită, dar nu dacă o plătești cu o coadă de 800 ms la percentila 95.
Un cuvânt și despre IPv6. Faptul că „merge” nu înseamnă că merge bine. Dacă AAAA-urile sunt mai lente sau mai fragile, crawlerul va tot încerca. Investighează rutarea, anunțurile BGP și paritatea de peering cu IPv4. Ar fi păcat să pierzi viteză în 2025 dintr-un detaliu de peering.
Cum legi totul de SEO fără să cazi în clișee
Crawlul nu e un scor, este un flux. Când DNS-ul e sănătos și previzibil, serverele par în formă, iar roboțeii cresc debitul. Asta se simte în indexare proaspătă și în ritmul cu care se consumă site-ul. E acel tip de optimizare invizibilă care dă tonul.
Dacă planifici publicarea de conținut, ritmul crawlingului îți dictează când se văd rezultatele și cât de repede se propagă schimbările. Uneori, e mai util să repari o coadă la rezolvare decât să mai storci încă 20 ms din TTFB. Și da, chiar dacă discutăm infrastructură, știe toată lumea că zona editorială contează.
Când îți calibrezi strategia, include și capitolul tehnic: conținut bun, sitemap curat, servere sprintene și un DNS care nu stă în drum. Dacă ai nevoie de un exemplu foarte concret de sincronizare între editorial și tehnic, gândește-te la planificarea unor articole seo în perioadele în care infrastructura e liniștită și rapidă. E un detaliu mic, dar multiplică efectul.
O mini hartă de implementare, spusă simplu
Îți iei o oră, pui Blackbox lângă Prometheus, adaugi câteva module DNS și niște joburi. Desenezi în Grafana un panou cu p50, p95 și p99 pentru A și AAAA, separate pe rezolvatoare. Duplici testele pe autoritativ. După o zi, ai prima hartă a problemelor reale. Între timp, rulezi măsurători geografice și vezi dacă există regiuni mofturoase.
Dacă apar, discuți cu furnizorul de DNS despre rute și instanțe anycast. Dacă nu, privești lanțurile CNAME cu o sprânceană ridicată. Alertele le setezi simplu la început și le rafinezi după două săptămâni.
De obicei, următoarea scenă e previzibilă în cel mai bun sens. Graficele se strâng, percentilele grele coboară, robotul prinde curaj. Iar tu te bucuri de un rezultat pe care rar îl aplaudă cineva, dar pe care îl simte tot site-ul. Este genul de reparație pe care o faci bine o dată, apoi te mai întorci doar pentru reglaje fine sau schimbări de furnizor.
Un gând pragmatic
Oricât de seducător este să optimizăm paginile până la ultimul kilobyte, crawlingul se împiedică adesea de lucrurile pe care nu le vedem. O rezolvare DNS leneșă, un apex complicat, o instanță anycast departe de utilizatori.
Când le pui la punct cu un sistem de monitorizare care nu minte, restul începe să aibă sens. Este una dintre cele mai bune investiții tehnice pentru un SEO sănătos pe termen lung.
