Fișierul robots.txt: directivele care contează și greșelile care blochează site-ul

Fișierul robots.txt: directivele care contează și greșelile care blochează site-ul. Pe orice server, acest fișier text de câteva linii decide ce părți din site le poate descărca un crawler și ce părți rămân în afara bugetului de crawlare.

O singură linie scrisă greșit poate scoate din indexare secțiuni întregi, fără ca nimeni să observe imediat. Articolul arată ce directive contează efectiv și care sunt greșelile care blochează site-ul fără niciun semnal vizibil în interfața WordPress.

Fișierul robots.txt: directivele care contează și greșelile care blochează site-ul

Fișierul robots.txt se citește la adresa rădăcină a domeniului, înaintea oricărei alte interacțiuni dintre crawler și site. El transmite reguli de acces, nu reguli de indexare, iar confuzia dintre cele două este sursa majorității greșelilor descrise mai jos.

Standardul care îl guvernează este formalizat ca protocol public, nu o convenție informală între motoarele de căutare.

Ce controlează robots.txt și ce nu poate face

Fișierul fișierul robots.txt controlează exclusiv accesul crawlerului la resurse, adică dacă un bot are voie să descarce o adresă anume. Nu controlează dacă acea adresă ajunge sau nu în indexul unui motor de căutare.

O pagină blocată prin Disallow poate apărea totuși în rezultatele căutării, fără fragment de conținut, dacă Google a găsit-o printr-un link extern. Singurul mod sigur de a scoate definitiv o pagină din index este eticheta noindex sau eliminarea completă a adresei, nu blocarea ei în robots.txt.

Confuzia dintre blocarea accesului și scoaterea din index generează situații în care o pagină interzisă crawlerului continuă să primească vizite din căutare, pentru că fusese deja indexată înainte de blocare. Eliminarea reală a unei adrese din index necesită mai întâi acces de crawlare, exact opusul blocării din robots.txt.

Un exemplu frecvent: o pagină de arhivă de etichete este blocată ulterior prin robots.txt pentru a reduce conținutul subțire din index, dar rămâne vizibilă în rezultate luni la rând, pentru că blocarea nu face altceva decât să oprească recrawlarea ei, nu să o șteargă din baza de date a motorului de căutare.

Sintaxa standardului: directivele care chiar contează

Standardul acceptă un set restrâns de directive, iar restul sunt convenții adoptate informal de unele motoare de căutare, fără garanție de respectare universală.

• User-agent identifică robotul căruia i se adresează grupul de reguli care urmează, de exemplu Googlebot sau caracterul * pentru toți.
• Disallow interzice accesul la o cale anume sau la tot ce începe cu acel prefix, inclusiv parametrii din adresă.
• Allow redeschide accesul la o subcale dintr-un director deja blocat, util când trebuie exceptată o singură pagină dintr-un folder interzis.
• Sitemap indică adresa completă a hărții XML a site-ului și poate apărea oriunde în fișier, indiferent de grupul User-agent.

Două caractere speciale schimbă sensul unei reguli, iar confuzia dintre ele produce blocaje neintenționate. Asteriscul * înlocuiește orice secvență de caractere în interiorul unei căi, util pentru a bloca toate adresele care conțin un anumit parametru, indiferent de poziție. Semnul dolar $ marchează sfârșitul exact al adresei, astfel încât o regulă precum Disallow: /*.pdf$ blochează fișierele PDF, dar nu și o adresă care conține șirul .pdf urmat de alte caractere.

Când mai multe reguli dintr-un grup se suprapun pe aceeași adresă, câștigă regula cu calea cea mai lungă și mai specifică, nu cea scrisă ultima în fișier. O regulă Allow de un singur caracter mai lungă decât un Disallow concurent are prioritate, indiferent de ordinea în care apar cele două linii.

Directiva Crawl-delay este ignorată de Googlebot, deși unele motoare mai mici o respectă. Dacă problema reală este un crawler prea agresiv pe un server cu resurse limitate, soluția corectă se configurează din Google Search Console sau prin reguli de server, nu din robots.txt.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://exemplu.ro/sitemap_index.xml

Greșelile care blochează site-ul fără niciun semnal vizibil

Fișierul nu generează erori în browser atunci când e scris greșit. Site-ul arată identic pentru un vizitator uman, în timp ce crawlerul primește reguli complet diferite.

• Disallow: / lăsat dintr-un site de testare mutat în producție blochează întregul domeniu pentru toate motoarele de căutare, fără nicio avertizare, iar simptomul apare abia după câteva zile, când traficul organic începe să scadă vizibil.
• Blocarea directoarelor cu fișiere CSS și JavaScript împiedică Google să randeze corect pagina și poate afecta evaluarea experienței vizuale a site-ului, chiar dacă paginile în sine rămân accesibile.
• Căile sunt sensibile la majuscule și minuscule: /Produse/ și /produse/ sunt trasee diferite pentru crawler, chiar dacă serverul le tratează identic.
• Lipsa unui slash final la o regulă menită să blocheze un singur director blochează din greșeală orice adresă care începe cu același șir de caractere, de exemplu /produs fără bară finală blochează și /produse-recomandate/.
• Mai multe fișiere robots.txt generate de pluginuri diferite, care se suprapun pe subdomenii sau pe protocoale diferite, ajung să se contrazică între ele, iar crawlerul aplică mereu doar fișierul servit la adresa exactă pe care o cere.

Fiecare dintre aceste greșeli reduce efectiv bugetul de crawlare disponibil sau blochează descoperirea de conținut nou, mecanisme descrise pe larg în ghidul despre controlul bugetului de crawlare.

Fișierul robots.txt pe WordPress

WordPress generează automat un robots.txt virtual dacă pe server nu există unul fizic, vizibil la adresa rădăcină a site-ului, dar fără fișier real pe disc.

• Pluginurile SEO, inclusiv Rank Math, oferă o interfață pentru a edita acest fișier fără acces FTP, iar modificarea salvată înlocuiește complet versiunea virtuală.
• Bifa de confidențialitate din Setări, opțiunea care descurajează indexarea site-ului, adaugă automat reguli de blocare și rămâne activată din greșeală după o migrare.
• Temele și pluginurile de cache pot crea fișiere robots.txt statice suplimentare, care rămân pe server și ignoră modificările făcute ulterior din panoul WordPress.
• Directoarele /wp-admin/ se blochează în mod normal, dar fișierul admin-ajax.php din același director trebuie exceptat explicit, pentru că este folosit de multe teme și pluginuri inclusiv pe partea publică a site-ului.
• Un fișier robots.txt fizic, încărcat manual în rădăcina instalării, are prioritate permanentă față de versiunea virtuală generată de WordPress, chiar dacă nu mai este actualizat de nimeni după migrare.

Verificarea completă a configurării robots.txt, alături de restul fișierelor tehnice ale unui site, face parte din serviciul de audit SEO oferit de echipa noastră.

Robots.txt, meta robots și eticheta canonical: cine face ce

Cele trei mecanisme se confundă des, deși rezolvă probleme diferite și nu se pot înlocui unul pe celălalt.

• Robots.txt controlează dacă o adresă poate fi accesată de crawler, înainte ca pagina să fie descărcată.
• Eticheta meta robots, plasată în cod sursă, controlează dacă o pagină deja descărcată poate fi indexată sau urmată mai departe.
• Eticheta canonical indică, dintre mai multe adrese cu conținut asemănător, care este versiunea preferată pentru index, fără să blocheze accesul la celelalte.

O greșeală frecventă este blocarea unei adrese prin robots.txt și adăugarea în paralel a unei etichete noindex pe aceeași pagină. Crawlerul nu poate descărca pagina pentru a vedea eticheta, deci noindex-ul nu are niciun efect, iar pagina rămâne expusă riscului de a apărea în index fără fragment. Mecanismul de consolidare a adreselor asemănătoare prin canonical este detaliat pe pagina de SEO tehnic.

Reguli separate pentru crawlerele de inteligență artificială

Pe lângă Googlebot și Bingbot, fișierul robots.txt poate adresa reguli distincte pentru crawlerele folosite la antrenarea modelelor de limbaj sau la generarea răspunsurilor din motoare conversaționale.

• Fiecare astfel de crawler se identifică printr-un nume propriu de user-agent, de exemplu GPTBot sau CCBot, și poate primi un grup separat de reguli în același fișier.
• Blocarea unui crawler de acest tip nu afectează prezența site-ului în rezultatele clasice de căutare Google, pentru că Googlebot citește propriul grup de reguli, separat.
• Decizia de a bloca sau nu aceste crawlere ține de politica proprie privind refolosirea conținutului, nu de o regulă tehnică obligatorie impusă de vreun standard.

Lista de crawlere relevante se schimbă des, pe măsură ce apar servicii noi, așa că fișierul robots.txt merită revizuit periodic și nu scris o singură dată, la lansarea site-ului.

Testarea și validarea înainte de a publica modificări

Orice modificare a robots.txt se testează înainte de a fi lăsată activă pe site-ul live, pentru că efectele unei reguli greșite apar abia după recrawlare.

• Instrumentul de inspectare a adreselor din Google Search Console arată exact dacă o pagină anume este blocată de robots.txt, direct din perspectiva Googlebot.
• Raportul dedicat robots.txt din setările proprietății Search Console arată istoricul versiunilor citite de Google pentru domeniul respectiv și semnalează erorile de sintaxă.
• Comanda curl confirmă rapid, din linia de comandă, conținutul real servit de domeniu, fără interferența cache-ului din browser.
• Verificarea se repetă după fiecare migrare de server, schimbare de plugin SEO sau activare a unui nou sistem de cache, pentru că oricare dintre ele poate suprascrie fișierul.

curl -s https://exemplu.ro/robots.txt

Dacă răspunsul conține un Disallow: / neașteptat sau lipsește complet linia Sitemap, modificarea nu se lasă activă până nu este corectată și retestată.

Robots.txt pe magazine online și site-uri cu mii de pagini

Pe un magazin online, robots.txt gestionează un volum mult mai mare de adrese generate automat, nu doar câteva directoare administrative.

• Filtrele de căutare și paginile de sortare din categorii generează adrese cu parametri care se pot bloca prin reguli dedicate, pentru a nu consuma inutil bugetul de crawlare.
• Coșul de cumpărături, contul de utilizator și procesul de finalizare a comenzii se blochează mereu, pentru că nu au valoare de indexare și expun date tranzitorii.
• Fluxurile XML trimise către comparatoare de preț trebuie să rămână accesibile separat, chiar dacă directorul în care sunt publicate este blocat pentru restul crawlerelor.
• Paginile de produs scoase din stoc temporar nu se blochează prin robots.txt, pentru că blocarea le-ar scoate și din sitemap-ul indexat de motoarele de preț, ci se tratează prin statusul propriu de disponibilitate din platforma de comerț electronic.

Tratarea completă a paginilor de filtrare și paginare pe un magazin online este detaliată în ghidul de SEO pentru WooCommerce, iar strategia generală pentru acest tip de site în pagina de SEO pentru magazine online.

Fișierul robots.txt rămâne un instrument simplu ca sintaxă, dar cu efecte ample atunci când o regulă este scrisă greșit sau lăsată dintr-o versiune de testare. Verificarea lui periodică, alături de restul semnalelor tehnice ale site-ului, intră firesc într-un audit de SEO tehnic. Dacă nu aveți timpul sau certitudinea să faceți aceste verificări intern, serviciile SEO și consultanța SEO oferite de echipa noastră acoperă exact acest tip de corecție tehnică.