robots.txt în WordPress în 2026 (ce să pui în el, de fapt)

Un fișier robots.txt bun pentru WordPress are cam cinci rânduri. Blochează /wp-admin/, permite admin-ajax.php, arată crawlerelor sitemapul și oprește-te acolo — listele stufoase de 40 de rânduri pe care le găsești pe forumuri fie strică randarea, fie nu fac nimic. Tot fișierul:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

Înlocuiește domeniul, iar dacă folosești un plugin SEO care preia sitemapurile, îndreaptă rândul Sitemap spre indexul acelui plugin. Asta e tot. Dacă fișierul tău e mai lung de atât, rândurile în plus probabil te costă ceva.

WordPress generează deja unul — până creezi un fișier real

WordPress vine cu un robots.txt virtual. Când sosește o cerere pentru /robots.txt și nu există niciun fișier real în rădăcina site-ului, WordPress interceptează cererea și tipărește un răspuns în memorie. Nu se scrie nimic pe disc. Rezultatul implicit este blocul wp-admin de mai sus, plus un rând Sitemap: pentru wp-sitemap.xml, pe care core-ul îl emite începând cu WordPress 5.5.

Două lucruri schimbă acel rezultat. Dacă este bifat Setări → Citire → Descurajează motoarele de căutare să indexeze acest site, WordPress înlocuiește tot conținutul cu Disallow: /, ceea ce blochează absolut totul. Bifa aceea este cea mai frecventă cauză a dispariției unui site din căutare după lansare. În al doilea rând, pluginurile și temele pot modifica rezultatul virtual prin filtrul robots_txt, așa cum pluginurile SEO își injectează propriile rânduri de sitemap și propriile reguli.

Acum, partea care le mănâncă oamenilor după-amiezile. Un fișier robots.txt fizic în rădăcina site-ului anulează în tăcere tot ce am spus mai sus. Serverul tău web găsește un fișier real pe disc, îl servește, iar WordPress nici nu se încarcă. Generatorul virtual nu rulează. Filtrul robots_txt nu se declanșează. Editorul de robots.txt din pluginul tău SEO îți poate arăta în continuare o interfață frumoasă cu regulile corecte în ea, și nimic din toate astea nu ajunge la un crawler.

Unde stau regulile	Editabile din adminul WordPress	Câștigă la o cerere reală
Virtual (niciun fișier pe disc)	Da, prin filtrul robots_txt sau printr-un plugin	Numai când nu există niciun fișier fizic
Fișier fizic în rădăcina site-ului	Doar dacă pluginul scrie pe disc	Întotdeauna

Deci, înainte să depanezi orice: deschide https://site-ultau.ro/robots.txt în browser, apoi conectează-te prin SFTP sau prin managerul de fișiere al hostingului și verifică dacă un robots.txt real stă lângă wp-config.php și .htaccess. Dacă da, acela e robots.txt-ul tău. Ori îl editezi acolo, ori îl ștergi și lași WordPress să preia — dar alege una. Rulându-le pe amândouă ajungi cu o adresă de sitemap veche, pe care nu o mai găsește nimeni.

De ce se blochează /wp-admin/, dar se permite admin-ajax.php

/wp-admin/ conține panoul de administrare. Acele adrese sunt inutile în rezultatele căutării, iar accesarea lor consumă buget de crawl pe pagini care redirecționează spre un ecran de autentificare. Blocarea directorului nu e subiect de dispută.

admin-ajax.php stă în același director, dar nu este o pagină de administrare. Este endpointul pe care pluginurile și temele îl folosesc pentru cererile AJAX din partea publică a site-ului — butoane de „încarcă mai mult”, grile de produse filtrate, calculatoare, formulare. Dacă un crawler nu îl poate accesa, nu poate vedea conținutul pe care îl încarcă acele funcții, iar Google îți randează pagina așa cum ar vedea-o un vizitator cu funcția stricată.

Dacă Google chiar are nevoie să acceseze admin-ajax.php pe site-ul tău anume depinde de faptul dacă partea publică îl folosește. Răspunsul sincer: pe multe site-uri moderne nu contează deloc, pentru că tema folosește REST API la /wp-json/. Rândul Allow este o poliță de asigurare ieftină împotriva unui mod real de eșec, nu un factor de clasare. Păstrează-l pentru că nu costă nimic.

Nu bloca /wp-content/ sau /wp-includes/

Acesta este cel mai prost sfat despre robots.txt care încă circulă și vine dintr-o epocă în care Google nu randa paginile.

/wp-content/ conține temele, pluginurile și fișierele încărcate — foile de stil, scripturile și imaginile care fac ca paginile tale să arate a pagini. /wp-includes/ conține JavaScript din core, de care depind pluginurile. Google îți randează paginile cu un browser fără interfață înainte să le evalueze. Blochează acele directoare și motorul de randare primește o pagină fără CSS și fără imagini. Ce evaluează Google este un zid de text nestilizat, cu aspectul distrus, ceea ce influențează felul în care îți înțelege conținutul și cum îți notează utilizabilitatea pe mobil.

Dacă ai moștenit un fișier cu rândurile astea, șterge-le:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

Poți confirma paguba și singur, în unealta URL Inspection din Google Search Console. Rulează un test live pe orice pagină, uită-te la captura randată și verifică lista de resurse ale paginii pentru elemente blocate. Dacă CSS-ul apare ca blocat, aceea e cauza.

Directiva Sitemap

Un singur rând, adresă absolută, și poate sta oriunde în fișier — nu ține de un grup User-agent.

Sitemap: https://example.com/wp-sitemap.xml

Folosește adresa care chiar funcționează. WordPress core servește wp-sitemap.xml. Majoritatea pluginurilor SEO dezactivează sitemapurile din core și își servesc propriul index la o altă cale, de obicei sitemap_index.xml. Încarcă adresa în browser înainte să o pui în fișier — un rând Sitemap care duce la un 404 e mai rău decât niciun rând, pentru că într-un audit pare corect.

E în regulă să listezi mai multe sitemapuri, câte unul pe rând. Trimiterea sitemapurilor în Search Console merită făcută în continuare separat; directiva din robots.txt este felul în care le găsesc crawlerele care nu văd niciodată contul tău de Search Console.

robots.txt nu e noindex și nu e securitate

Aceste două neînțelegeri produc cele mai multe pagube legate de robots.txt.

Blocarea unui URL nu îl scoate din Google. Robots.txt guvernează accesarea. Dacă un alt site dă link către un URL blocat, Google poate indexa adresa în sine — obții un rezultat cu adresa goală și o notă că nu există informații disponibile. Și mai există o capcană urâtă: dacă o pagină are deja un metatag noindex și apoi o blochezi în robots.txt, Google nu o mai poate accesa, nu mai poate vedea noindex și pagina poate rămâne indexată la nesfârșit. Ca să elimini o pagină, permite accesarea și servește un metatag robots noindex în head-ul paginii sau un antet HTTP X-Robots-Tag. Google a încetat să mai accepte directive noindex în interiorul robots.txt din 2019.

Blocarea unei căi nu o protejează. Fișierul tău robots.txt este public prin definiție. Dacă listezi /fisiere-private-clienti/, arăți fiecărui vizitator și fiecărui scaner exact unde să caute, iar respectarea e voluntară — Google o onorează, boții ostili nu. Orice are nevoie de protecție are nevoie de autentificare, de o restricție de IP sau de reguli la nivel de server în .htaccess, nu de un rând într-un fișier text care anunță ținta.

Reguli care merită adăugate și reguli peste care poți sări

Două adăugiri sunt cu adevărat utile pe multe site-uri. Blocarea căii cu rezultatele căutării împiedică crawlerele să genereze la nesfârșit adrese fără valoare din căutarea internă. Blocarea căii de coș sau de finalizare a comenzii pe WooCommerce ține adresele cu parametri de sesiune în afara crawlului.

Disallow: /?s=
Disallow: /search/

Sari peste astea:

• Crawl-delay — Google o ignoră complet. Folosește controalele pentru rata de accesare din Search Console dacă ai o problemă reală de încărcare a serverului.
• Blocarea /feed/ sau /trackback/ — sunt adrese inofensive, iar fluxurile sunt utile.
• Liste lungi cu nume de boți — oricum, majoritatea boților pe care lumea încearcă să îi blocheze nu se identifică sincer.
• Blocarea /wp-json/ — s-ar putea să fie exact ce folosește tema ta ca să afișeze conținutul.

Construiește fișierul cu generatorul de robots.txt pentru WordPress, care produce varianta minimă corectă și îți permite să adaugi regulile pentru căutare și comerț fără să editezi sintaxa de mână.

După ce îl modifici

Încarcă direct https://site-ultau.ro/robots.txt și confirmă că octeții serviți sunt cei la care te aștepți — nu ce îți arată editorul pluginului. Apoi rulează o inspecție live de URL în Search Console pe o pagină obișnuită și verifică să nu revină blocată nicio resursă CSS sau JavaScript. Google ține robots.txt în cache aproximativ o zi, așa că o reparație nu are efect instantaneu, dar nici o greșeală. Întârzierea aceea e motivul pentru care merită să verifici cu atenție, în loc să testezi direct în producție și să aștepți.