Fișierul robots.txt trebuie să fie accesibil la rădăcina publică a site-ului, printr-o adresă precum https://exemplu.ro/robots.txt. Nu se pune într-un articol, într-o bibliotecă media sau într-un subfolder ales arbitrar. Locația fizică de pe server depinde de găzduire și de aplicație; ceea ce contează pentru robot este răspunsul primit la adresa publică potrivită.
Pentru a afla dacă blochează pagini importante, citești regulile aplicabile robotului vizat și testezi adrese reprezentative: pagina principală, categorii, produse, servicii, articole și resurse necesare afișării. Verifici apoi separat indexarea. O pagină accesibilă în browser poate fi blocată pentru un robot, iar o pagină blocată la accesare poate apărea totuși în rezultatele căutării. Acest ghid explică pașii de verificare, fără a presupune că fiecare website are nevoie de reguli suplimentare.
Locația publică și folderul de pe server sunt lucruri diferite
Întrebarea „unde pun fișierul pe server?” are două niveluri. La nivel public, răspunsul este rădăcina site-ului. La nivelul găzduirii, trebuie identificat directorul din care este servit domeniul respectiv. Unele conturi au un director numit public_html, altele folosesc directoare separate pentru fiecare website sau o aplicație care generează răspunsul dinamic. Nu presupune că primul folder vizibil în managerul de fișiere este cel corect.
Documentația Google despre crearea fișierului robots.txt precizează poziționarea la rădăcină și formatul text simplu. Verificarea practică este să accesezi adresa publică și să confirmi că vezi regulile așteptate. Un fișier încărcat cu succes într-un panou de găzduire nu este, singur, dovada că robotul primește acel fișier.
Dacă ai două domenii în același cont, verifică explicit asocierea dintre domeniu și director. O editare făcută în folderul magazinului poate să nu afecteze website-ul de prezentare, chiar dacă denumirile sunt asemănătoare. Cere furnizorului de găzduire identificarea rădăcinii documentelor pentru domeniul exact atunci când interfața nu este clară. Este mai sigur decât să copiezi fișierul în mai multe directoare și să pierzi evidența versiunii active.
Ce trebuie verificat când există subdomenii și versiuni diferite
Nu trata domeniul principal, subdomeniul de magazin și mediul de test ca fiind automat acoperite de același fișier. Construiește întâi inventarul adreselor folosite efectiv: domeniul public, versiunea cu www dacă există, subdomeniul aplicației și mediul de dezvoltare. Pentru fiecare, notează unde ajunge vizitatorul și cine administrează configurația.
Conform specificației interpretate de Google, regulile au domeniu de aplicare legat de protocol, gazdă și port. Pentru un antreprenor, consecința practică este simplă: verificarea făcută pe o adresă nu ține locul verificării tuturor adreselor folosite de afacere. În special după o migrare, nu presupune că setările vechi au fost transferate corect.
Poți folosi un tabel intern cu coloanele „adresă”, „destinație finală”, „robots.txt verificat”, „responsabil” și „data verificării”. Acesta nu trebuie publicat. Rolul său este să prevină situația în care echipa verifică website-ul principal, dar lasă un magazin nou sau un subdomeniu important cu reguli copiate din mediul de test.
Ce face robots.txt și ce nu poate rezolva
Robots.txt transmite instrucțiuni de accesare roboților care respectă protocolul. Nu este un sistem de autentificare și nu ascunde documente confidențiale. Fișierul este public, iar căile scrise în el pot fi citite. Pentru zone private ai nevoie de control real al accesului, stabilit la nivelul aplicației sau serverului, nu doar de o linie care cere roboților să nu intre.
Google explică în introducerea despre robots.txt că acesta nu este mecanismul potrivit pentru a garanta eliminarea unei pagini din căutare. De aceea, formulează scopul înainte de editare: vrei să limitezi accesarea unor adrese, să împiedici indexarea sau să protejezi informația? Sunt obiective diferite și necesită soluții diferite.
Un magazin poate dori să reducă explorarea unor combinații de filtre, dar să păstreze categorii importante pentru clienți. O firmă poate avea o pagină publică temporară care nu trebuie să apară în Google. O clinică poate avea o zonă de cont care trebuie protejată. Copierea aceleiași soluții pentru toate cele trei situații creează riscuri inutile.
Cum citești un grup de reguli
Începe cu linia User-agent, care identifică robotul sau grupul de roboți vizat. Apoi citește instrucțiunile din acel grup. Disallow indică o cale restricționată, iar Allow poate permite o cale mai specifică. Nu interpreta fișierul ca pe o listă de priorități editoriale: ordinea în care ai scris directoarele nu stabilește importanța lor pentru Google.
Următorul exemplu este strict ilustrativ, pentru un site fictiv. Nu reprezintă o configurație recomandată universal:
User-agent: *
Disallow: /zona-test/
Allow: /zona-test/ghid-public.htmlExemplul separă o zonă pe care nu dorești să o exploreze roboții de un document permis explicit. Înainte să folosești o asemenea structură, întreabă-te dacă documentul public chiar trebuie să stea în zona de test. Uneori, o organizare mai clară a adreselor este preferabilă unei liste tot mai lungi de excepții.
Google aplică regulile în funcție de grupul relevant și de specificitatea căii, nu doar după ultima linie scrisă. Dacă există instrucțiuni dedicate unui robot, verifică acel grup distinct. Nu presupune că regulile generale și cele specifice se combină exact cum ți-ar fi comod. Pentru cazurile cu reguli concurente, consultă specificația oficială și testează adresele concrete.
De ce o singură regulă prea largă poate afecta multe pagini
O restricție asupra unui director poate include pagini care nu au fost luate în calcul când s-a redactat fișierul. Dacă în același director se află atât rezultate interne, cât și pagini de categorie utile, o regulă generală le poate trata împreună. Problema nu este vizibilă doar din numele directorului; ai nevoie de o listă a adreselor reale pe care le conține.
Semnalul care cere verificare imediată este o regulă de tip Disallow: / aplicabilă robotului vizat. Într-un grup simplu, fără excepții mai specifice, ea blochează accesarea întregului site. Poate proveni dintr-o configurație de test. Nu o elimina mecanic fără să verifici destinația: pe un mediu intern ar putea fi intenționată, chiar dacă singură nu îl securizează.
Pentru fiecare regulă largă, scrie ce ar trebui să restricționeze și ce trebuie să rămână permis. Dacă nu poți explica scopul, investighează istoricul sau discută cu administratorul. Eliminarea tuturor regulilor este la fel de puțin riguroasă ca blocarea întregului site. Corecția trebuie să rezolve problema observată și să păstreze restricțiile încă necesare.
Construiește o listă de pagini importante înainte de testare
Nu testa doar homepage-ul. Un site poate permite pagina principală și poate bloca exact categoriile care aduc clienți. Alege adrese din fiecare tip de pagină și include variante reprezentative: un produs disponibil, unul temporar indisponibil, un serviciu, o pagină locală relevantă și un articol informativ. Pentru fiecare, stabilește ce comportament aștepți.
| Tip de adresă | Ce urmărești |
|---|---|
| Pagină de serviciu | Accesare permisă dacă trebuie să fie descoperită în căutare |
| Categorie principală | Absența unei blocări printr-un director comun |
| Produs | Reguli care nu exclud accidental întregul catalog |
| Resursă de afișare | Accesul la fișierele necesare interpretării paginii |
| Zonă de test | Separarea de conținutul public și protecție adecvată |
Adaugă adresele care au generat cereri, vânzări sau trafic relevant în trecut. Lista trebuie să reflecte afacerea, nu doar structura tehnică. Dacă o pagină nu a adus încă trafic, dar este esențială pentru un serviciu nou, include-o. Verificarea preventivă este utilă tocmai înainte să existe pierderi măsurabile.
Verifică răspunsul public, nu doar setarea din administrator
Deschide adresa robots.txt într-un browser fără sesiunea de administrare și citește conținutul. Confirmă că primești textul așteptat, nu o pagină de autentificare, o eroare sau un șablon HTML. Dacă echipa tehnică folosește un instrument pentru inspectarea răspunsului HTTP, cere și codul de răspuns, destinația eventualelor redirecționări și momentul testului.
Compară rezultatul cu sursa pe care ai editat-o. Dacă panoul arată reguli noi, iar adresa publică încă arată versiunea veche, verifică cache-ul, un fișier fizic prioritar sau alt mecanism care generează răspunsul. Nu continua să adaugi reguli în mai multe locuri înainte să identifici sursa efectivă. Altfel, o modificare viitoare poate reactiva o versiune uitată.
Salvează o copie a răspunsului public înainte și după intervenție. Include ora și domeniul exact în nota de lucru. Acest obicei este util când mai mulți furnizori administrează găzduirea, optimizarea și website-ul. În locul unei discuții generale despre „fișierul corect”, poți compara două răspunsuri concrete.
Cum verifici dacă o pagină este blocată sau doar neindexată
Pornește de la adresa exactă și separă trei întrebări: poate fi accesată, poate fi indexată și este deja indexată? Acestea nu au automat același răspuns. O regulă robots.txt privește accesarea. Etichetele și antetele de indexare privesc includerea în index. Starea efectivă în Google depinde și de descoperire, procesare și selecția motorului de căutare.
În proprietatea potrivită din Search Console, folosește instrumentul de inspectare a adresei și citește motivele raportate, inclusiv data informațiilor disponibile. Folosește testarea live atunci când ai nevoie să verifici situația actuală și este disponibilă. Nu confunda rezultatul unui test curent cu istoricul indexării. Dacă mesajul indică o blocare, compară regula cu URL-ul exact, inclusiv calea și eventualii parametri.
Dacă accesarea este permisă, continuă investigația către etichete noindex, răspunsuri de server, redirecționări, canonical și legături interne. Pentru cadrul general al acestor verificări, vezi ghidul de optimizare SEO. Deblocarea accesării este o condiție tehnică utilă, nu o garanție că pagina va primi imediat vizibilitate sau poziții bune.
De ce noindex nu trebuie ascuns în spatele unei blocări
Dacă scopul este excluderea unei pagini publice din Google, analizează mecanismul noindex. Documentația Google despre blocarea indexării explică faptul că robotul trebuie să poată accesa pagina pentru a vedea instrucțiunea. Scrierea noindex în robots.txt nu este o metodă acceptată de Google pentru această sarcină.
Imaginează-ți o pagină fictivă de campanie pe care echipa a adăugat noindex, apoi a blocat-o în robots.txt. Cele două acțiuni nu se completează automat: blocarea poate împiedica robotul să vadă schimbarea din pagină. Rezolvarea pornește de la obiectivul paginii și de la starea ei actuală, nu de la adăugarea unei noi interdicții.
Pentru informații confidențiale, discuția este diferită. O pagină cu date private nu trebuie lăsată publică doar pentru că are noindex. Restricționarea reală a accesului este responsabilitatea aplicației și a administrării serverului. În documentul de lucru, folosește termeni preciși: „nu trebuie explorată”, „nu trebuie indexată” sau „nu trebuie accesibilă public”.
Cum tratezi filtrele și parametrii unui magazin online
Magazinele pot genera numeroase combinații de filtrare și sortare. Înainte să blochezi adresele cu parametri, diferențiază paginile cu utilitate comercială de variantele fără conținut distinct. O selecție relevantă pentru clienți poate merita o pagină bine organizată, în timp ce o combinație arbitrară de sortări poate să nu adauge valoare.
Construiește exemple pentru fiecare familie de parametri și verifică unde sunt folosite. O regulă formulată prea general poate afecta pagini de produs, rezultate utile sau funcții care împart aceeași convenție de URL. Nu copia o listă de interdicții de la un magazin cu altă platformă și altă structură. Aceeași denumire de parametru nu garantează același rol.
Decizia trebuie coordonată cu arhitectura, legăturile interne și strategia de indexare. Robots.txt este doar una dintre componente. În cazul unei schimbări de platformă, păstrează lista adreselor importante și repetă testele după lansare. Ghidul despre pregătirea migrării unui magazin fără neglijarea SEO oferă context pentru această etapă.
Ce verifici într-un website WordPress
În WordPress, începe prin identificarea mecanismului care furnizează răspunsul public: fișier fizic, funcție a platformei sau intervenția unui plugin. Verifică documentația configurației concrete înainte să creezi un fișier nou. O modificare făcută într-un editor SEO poate să nu fie sursa care ajunge efectiv la vizitatori în configurația respectivă.
Nu edita tema pentru o problemă care poate fi rezolvată prin administrarea corectă a fișierului sau prin funcția autorizată existentă. Nu instala un plugin suplimentar doar pentru a evita identificarea sursei. Mai întâi stabilește cine gestionează robots.txt și ce modificare minimă este necesară. Păstrează o copie și asigură-te că poți reveni la configurația anterioară.
După intervenție, verifică un articol, o pagină de serviciu și o pagină de categorie. Site-urile WordPress pot avea structuri diferite pentru aceste tipuri de conținut. Faptul că articolul de test funcționează nu confirmă automat că o regulă nu afectează și paginile comerciale. Verifică și că modificarea nu a schimbat alte setări globale de vizibilitate.
Un scenariu complet de diagnostic după relansarea site-ului
Exemplul următor este fictiv. O firmă relansează website-ul și observă ulterior scăderea vizitelor organice către paginile de servicii. Echipa nu începe prin rescrierea titlurilor, ci verifică lista adreselor vechi, redirecționările și răspunsurile publice. Homepage-ul se deschide normal, însă acest lucru nu elimină posibilitatea unei blocări a unui director.
Administratorul compară robots.txt cu versiunea dinaintea lansării și găsește o restricție pentru directorul în care au fost mutate serviciile. Confirmă că regula se aplică robotului relevant și verifică mai multe URL-uri. Înainte să intervină, salvează configurația și consemnează scopul corecției: permiterea paginilor publice de servicii, fără modificarea accesului la mediul privat.
După corectare, echipa verifică răspunsul public, inspectează paginile și urmărește evoluția. Nu promite revenirea într-un număr fix de zile și nu atribuie orice fluctuație aceleiași cauze. Dacă problemele continuă, verifică și redirecționările, conținutul, indexarea și legăturile interne. Diagnosticul se închide când există dovezi privind problema și corecția, nu doar când fișierul a fost salvat.
Cum organizezi schimbarea fără să pierzi controlul configurației
Pregătește o modificare mică și clară. Documentează regula actuală, scopul ei, adresele afectate și regula propusă. Testează atât exemple care trebuie permise, cât și exemple care trebuie să rămână restricționate. Acest lucru previne o corecție aparent reușită care rezolvă o pagină și creează probleme în altă parte.
Stabilește cine aplică schimbarea și cine verifică rezultatul. Pentru un website mic, aceeași persoană poate face ambele lucruri, dar verificarea trebuie să fie un pas distinct. Salvează versiunea anterioară într-un loc accesibil echipei. Dacă rezultatul este neașteptat, revenirea trebuie să fie rapidă și să nu depindă de memoria celui care a editat.
După publicarea regulilor, nu modifica simultan alte componente fără o nevoie clară. Dacă schimbi în același timp robots.txt, structura URL-urilor și etichetele de indexare, identificarea cauzei unui efect devine mai dificilă. Pentru o relansare care impune schimbări multiple, păstrează un jurnal explicit al fiecărei intervenții.
Ce trebuie să conțină nota de predare către administrator
O solicitare tehnică bună include adresa afectată, regula suspectată și rezultatul dorit. De exemplu: „Pagina de serviciu trebuie să poată fi explorată; regula pentru directorul comun pare să o includă. Verificați grupul aplicabil și păstrați restricțiile pentru zona de test.” Acest mesaj este mai util decât cererea generală de a „repara SEO”.
Atașează momentul verificării și rezultatul observat în răspunsul public. Cere ca după intervenție să fie testate atât pagina afectată, cât și două adrese care nu trebuie schimbate. Notează separat ce rămâne neclar. Dacă problema privește indexarea, nu cere confirmarea rezolvării doar pe baza salvării fișierului: confirmarea tehnică și evoluția din căutare sunt etape diferite.
Păstrează documentul împreună cu istoricul website-ului. La următoarea relansare, echipa va putea înțelege de ce există o excepție și ce pagini protejează verificarea. Astfel, configurația nu depinde de o singură persoană și poate fi evaluată înainte de orice schimbare viitoare.
Întrebări frecvente despre robots.txt
Este obligatoriu să creez un fișier nou pentru fiecare website?
Nu începe prin a crea unul fără verificare. Website-ul poate servi deja un răspuns generat automat. Verifică adresa publică, configurația existentă și scopul urmărit. Un fișier nou, cu reguli copiate la întâmplare, poate fi mai problematic decât păstrarea unei configurații simple care permite accesarea paginilor publice.
Pot pune robots.txt în folderul blogului?
Pentru controlul site-ului, locația relevantă este rădăcina publică a gazdei, nu un subfolder ales pentru comoditate. Dacă blogul este pe un subdomeniu separat, verifică rădăcina acelui subdomeniu. Separă întotdeauna structura vizibilă în URL de organizarea fizică a fișierelor din contul de găzduire.
Dacă pagina se deschide în browser, înseamnă că Google o poate accesa?
Nu este o verificare suficientă. Browserul tău nu aplică automat instrucțiunile destinate roboților. În plus, serverul poate răspunde diferit în anumite condiții. Citește regulile și verifică adresa cu instrumentele potrivite, apoi analizează separat indexarea. O captură a paginii deschise confirmă doar o parte a situației.
Eliminarea unei blocări aduce imediat trafic?
Nu există această garanție. Corecția permite continuarea procesului tehnic, dar vizibilitatea depinde și de descoperire, conținut, relevanță și celelalte condiții ale paginii. Urmărește întâi dacă blocarea a dispărut, apoi dacă paginile sunt procesate și cum evoluează rezultatele. Păstrează așteptări legate de dovezi, nu de un termen arbitrar.
Când trebuie repetată verificarea?
După migrări, schimbări de domeniu, relansări, modificări ale regulilor și incidente care afectează accesul. Este utilă și când apare o scădere neexplicată a paginilor importante. Păstrează aceeași listă de test și actualizeaz-o când lansezi servicii sau categorii noi. Astfel, fiecare verificare poate fi comparată cu cea anterioară.
O verificare bună se încheie cu o concluzie precisă: adresa publică răspunde corect, regulile au un scop documentat, paginile importante au fost testate și indexarea a fost analizată separat. Aceste dovezi sunt mai utile decât un fișier lung, plin de interdicții pe care nimeni nu le mai poate explica.