A robots.txt-t sokan kapcsolóként kezelik: beírnak egy sort, és onnantól abban a hitben élnek, hogy az adott oldal eltűnt a keresőből. A valóság ennél sokkal szárazabb és sokkal technikaibb. A fájl egy illesztési szabályrendszer, ami minden egyes URL-re külön lefut, és aminek a kimenete gyakran meglepi azt is, aki írta.
Ebben a cikkben végigmegyünk azon, hogyan dönti el a bejáró, melyik sor vonatkozik egy konkrét URL-re, mit csinál pontosan a csillag és a dollárjel, öt gyakorlati szabálypáron nézzük meg a tényleges hatást, végül pedig a tesztelésre, a Search Console jelentésére és a szerverhibák következményeire térünk ki. A szöveg végén találsz egy másolható, minimalista WordPress robots.txt-t is.
Hogyan dönti el a kereső, melyik szabály illeszkedik egy URL-re?
Hivatalosan igazolt: a Google és a Robots Exclusion Protocol szabványt (RFC 9309) követő bejárók nem a fájlbeli sorrend alapján döntenek, hanem az adott URL-re illeszkedő szabályok közül a leghosszabb útvonal-mintát alkalmazzák. Ha egy Allow és egy Disallow minta pontosan ugyanolyan hosszú, akkor a Google dokumentációja szerint az engedélyezés érvényesül.
Tovább a témában: Engedd vagy tiltsd az AI-crawlereket? Döntési fa vállalkozásoknak · Konverzióoptimalizálás (CRO)
Mielőtt azonban a hossz számítana, a bejáró kiválasztja a rá vonatkozó csoportot. Egy crawler mindig csak egyetlen csoportot vesz figyelembe: azt, amelyik a legpontosabban nevezi meg őt. Ez a gyakorlatban azt jelenti, hogy ha van egy User-agent: * csoportod és külön egy User-agent: GPTBot csoportod, akkor a GPTBot kizárólag a saját blokkjában szereplő sorokat követi, a csillagos csoport szabályait pedig teljesen figyelmen kívül hagyja. Nincs öröklés, nincs összefésülés. Ez az egyik leggyakoribb félreértés az AI-bejárók kezelése körül.
Két további részlet, ami sokakat megfog: az útvonalak illesztése kis- és nagybetűre érzékeny (a /Blog/ és a /blog/ két különböző dolog), a user-agent nevek viszont nem. A Sitemap sor pedig független a csoportoktól, bárhol állhat a fájlban.
Mit csinál pontosan a csillag és a dollárjel?
A csillag tetszőleges hosszúságú karaktersort helyettesít, a dollárjel pedig az URL útvonalának végét rögzíti. A kettő kombinációja adja a robots.txt szinte teljes kifejezőerejét.
*: bármennyi (akár nulla) tetszőleges karakter. A/*.pdfminta illeszkedik a/doksik/arlista.pdfés a/doksik/arlista.pdf?utm_source=hirlevelcímre is.$: az útvonal vége. A/*.pdf$már csak az elsőre illeszkedik, a paraméteres változatra nem.- Minden minta implicit módon előtag-illesztés: a
Disallow: /keresesminden olyan URL-re hat, amelynek az útvonala ezzel a karaktersorral kezdődik.
Saját tapasztalat: a hibák nagyjából fele abból ered, hogy valaki azt hiszi, egy sor pontos egyezést ír elő, holott előtagot ír elő. A másik fele abból, hogy a dollárjelet olyan mintában használják, ahol paraméteres URL-eket is le kellene fedni.
Melyik öt szabálypárt érdemes fejből ismerni?
1. A klasszikus WordPress admin-kivétel
Disallow: /wp-admin/ és Allow: /wp-admin/admin-ajax.php. A /wp-admin/options.php címre csak a tiltás illeszkedik, tehát blokkolt. Az /wp-admin/admin-ajax.php címre mindkettő illeszkedik, de az Allow minta jóval hosszabb, ezért az nyer, és a fájl bejárható marad. Erre azért van szükség, mert sok téma és bővítmény ezen keresztül tölt be tartalmat, és ha a bejáró nem éri el, torzul a megjelenítés.
2. Perjel a minta végén, vagy nélküle
Disallow: /kereses hatálya alá esik a /kereses, a /kereses/, a /kereses?q=cipo, de a /keresesi-tippek is. Ha csak a könyvtárat akarod tiltani, akkor Disallow: /kereses/ a helyes forma. Ha pontosan egyetlen URL-t, akkor Disallow: /kereses$. Ez a három sor három különböző halmazt jelent, és a különbség nálam a legtöbb auditban okoz meglepetést.
3. Paraméteres URL-ek szűrése
Disallow: /*? és Allow: /*?oldal=. A /termekek?oldal=2 címre mindkettő illeszkedik, de az engedélyezés hosszabb, tehát bejárható. A /termekek?szuro=piros blokkolt. Ami trükkös: a /termekek?szuro=piros&oldal=2 szintén blokkolt marad, mert az Allow minta közvetlenül a kérdőjel után várja az oldal= részt, itt viszont ampersand előzi meg. Ha ezt is engedni akarod, Allow: /*oldal= kell.
4. Dokumentumok tiltása kiterjesztés alapján
Disallow: /*.pdf$ a paraméter nélküli PDF-eket fedi le. Ha a kampánylinkjeiden UTM paraméterek is vannak, a /arlista.pdf?utm_medium=email átcsúszik a szűrőn. A biztonságos forma a Disallow: /*.pdf, ez viszont már a /pdf-generalas/ típusú útvonalakat nem érinti, mert a mintában szerepel a pont.
5. Fordított logika: mindent tiltok, kivéve
Disallow: / és Allow: /blog/. Fejlesztői környezetnél vagy erősen korlátozott bejárásnál használt minta. A /blog/valami-cikk/ engedélyezett, minden más blokkolt. Fontos: ez nem azonos az indexelés tiltásával. Egy robots.txt-vel blokkolt URL továbbra is megjelenhet a találatok között, ha máshonnan hivatkoznak rá, csak leírás nélkül. Ha ki akarsz venni valamit az indexből, a noindex meta címke vagy a HTTP fejléc a helyes eszköz, és ahhoz a bejárónak el kell érnie az oldalt.
Hogyan tesztelem a robots.txt-t élesítés előtt?
A rövid válasz: valódi URL-listán, gépi illesztéssel, nem szemre. Az alábbi menetrend nálam bevált.
- Szedj össze egy reprezentatív URL-listát: sitemap, a Search Console legtöbb megjelenítést hozó 200 URL-je, plusz a szervernapló friss Googlebot-kérései.
- Futtasd le a listát a jelenlegi robots.txt-vel. Ez lesz a viszonyítási alap.
- Futtasd le ugyanazt a listát az új szabályokkal, és csinálj különbséglistát. Csak azt kell átnézned, ami változott.
- A tényleges illesztéshez használj szabványkövető parsert. A Google 2019-ben nyílt forráskódúvá tette a saját robots.txt értelmezőjét, és a Screaming Frog is tud beillesztett szabályok szerint tesztelni.
- Nézd át külön a CSS, JS és képfájlokat: ha ezeket blokkolod, a megjelenítés alapú kiértékelés sérülhet.
- Élesítés után a Search Console URL-ellenőrzőjében kérj élő tesztet néhány kulcsfontosságú oldalra, és nézd meg a Bejárás engedélyezett sort.
- Egy-két héttel később ellenőrizd az Oldalak jelentésben a Robots.txt által letiltva kategóriát.
Szakmai feltételezés: a nagyobb nyelvi modellek bejárói vélhetően hasonló előtag-illesztést használnak, mert a szabvány ezt írja le, de a viselkedésük dokumentáltsága gyengébb a Google-énál, ezért érdemes szervernaplóból is visszaellenőrizni, mit tesznek valójában.
Mit mutat a Search Console robots.txt-jelentése?
A jelentés a Beállítások menüpont alatt található, és a korábbi robots.txt tesztelőt váltotta le. Hivatalosan igazolt: legfeljebb 20 gazdagépet listáz (az aldomainek és a http, illetve https változatok külön sorok), megmutatja az utolsó bejárás idejét, a lekérés státuszát, az észlelt figyelmeztetéseket és hibákat, és megnyithatod a korábban letöltött fájlváltozatokat is. Van benne újrabejárás-kérés is.
Amit viszont nem ad meg: nem mondja meg, hogy egy konkrét URL blokkolt-e. Erre az URL-ellenőrző eszköz való. A kettőt együtt érdemes használni: a jelentés azt mutatja meg, hogy a fájlt egyáltalán le tudta-e tölteni a Google és milyen tartalommal, az URL-ellenőrző pedig azt, hogy egy adott cím átmegy-e a szűrőn.
Saját tapasztalat: a leggyakoribb rejtett probléma itt derül ki, mégpedig az, hogy az aldomainen (például egy webshop vagy egy tudásbázis külön hoston) egy másik, régi robots.txt fut, amiről mindenki elfeledkezett. A robots.txt mindig gazdagép-, protokoll- és portszintű: a fődomain fájlja nem vonatkozik az aldomainre.
Mi történik, ha a robots.txt 5xx hibát ad vissza?
Ez a legalábecsültebb kockázat az egész témában. Hivatalosan igazolt: a Google dokumentációja szerint, ha a robots.txt szerverhibát (5xx) vagy 429-es választ ad, a Google átmenetileg úgy kezeli az oldalt, mintha teljesen tiltva lenne, és visszafogja a bejárást. Ha az elérhetetlenség 30 napnál tovább tart, az utoljára gyorsítótárazott példányt használja, és ha az sem áll rendelkezésre, akkor abból indul ki, hogy nincs bejárási korlátozás.
Ennek a tükörképe is fontos: a 4xx válaszokat (a 429 kivételével) a Google úgy értelmezi, hogy nincs korlátozás, tehát a hiányzó robots.txt teljesen szabad bejárást jelent. Ez rendszerint nem baj, viszont ha egy WAF vagy CDN téved, és 403-at ad a Googlebotnak a robots.txt-re, akkor az összes tiltásod csendben megszűnik.
Néhány gyakorlati következtetés:
- Tedd fel a
/robots.txtcímet az uptime-figyelődre, és ne csak a 200-as státuszt nézd, hanem egy jellemző karaktersort is a tartalomban. - A robots.txt-t a fájl gyorsítótárazása miatt (általában legfeljebb 24 óra) nem lehet azonnali kapcsolóként használni, ne is tervezz vele órás pontosságú műveletet.
- Karbantartás alatt inkább az oldalak adjanak 503-at, a robots.txt viszont maradjon elérhető és változatlan.
Hogy néz ki egy minimalista WordPress robots.txt?
Az alábbi változat a legtöbb tartalmi vagy szolgáltatói WordPress oldalon elég. Másold be, a sitemap sorban cseréld ki a domaint.
User-agent: *Disallow: /wp-admin/Allow: /wp-admin/admin-ajax.phpDisallow: /?s=Disallow: /*?replytocom=Sitemap: https://pelda.hu/sitemap_index.xml
Ami szándékosan nincs benne: a /wp-content/ és a /wp-includes/ tiltása (ezekkel a megjelenítéshez szükséges CSS és JS fájlokat zárnád ki), a Crawl-delay (a Google nem támogatja), és a noindex direktíva (a Google 2019. szeptember 1-jén megszüntette a támogatását). Ha nincs fizikai robots.txt a gyökérben, a WordPress egy virtuális fájlt szolgál ki, amit egy feltöltött valódi fájl felülír.
Miért fut a legtöbb magyar oldalon felesleges és félig hibás robots.txt?
Saját tapasztalat és nézőpont: a robots.txt fájlok jelentős része nem döntés eredménye, hanem üledék. Egy 2012-es blogbejegyzésből másolt húszsoros sablon, amire ráragadt egy bővítmény által generált szűrő, egy fejlesztői környezetből ottfelejtett sor, és három olyan tiltás, aminek az eredeti indoka már nem létezik.
A jellemző hibák sorrendben: a képmappa kizárása, ami elvágja a képkeresési láthatóságot; a Disallow: / ottfelejtése az élesítés után; a paraméteres oldalak tiltása abban a hitben, hogy ez kiveszi őket az indexből (nem veszi ki, csak vakká teszi a keresőt a tartalmukra); és a nem támogatott direktívák, amelyek semmit nem csinálnak, viszont hamis biztonságérzetet adnak.
Az én mércém egyszerű: minden sornak legyen megnevezhető indoka, és legyen legalább egy URL, amire bizonyíthatóan hat. Ami ezt nem állja ki, az kikerül. Egy rövid, átlátható robots.txt nem garantál jobb helyezést, de megszünteti azt a kockázati felületet, amit egy senki által nem értett fájl jelent. A bejárási keret optimalizálása amúgy is inkább a belső linkelés, a sitemap higiénia és a szervergyorsaság kérdése, nem a robots.txt-é.
Források és további olvasnivalók
- Google Search Central: Robots.txt bevezető és útmutató, valamint a Google robots.txt specifikációja
- Google Search Central: Hogyan értelmezi a Google a robots.txt fájlt (illesztési szabályok, státuszkód-kezelés)
- IETF RFC 9309: Robots Exclusion Protocol
- Google nyílt forráskódú robots.txt parser (google/robotstxt)
- Google Search Console Súgó: robots.txt-jelentés és URL-ellenőrző eszköz
- Bing Webmaster Guidelines: robots.txt kezelés
- WordPress Developer Resources: a virtuális robots.txt kiszolgálása
- OpenAI dokumentáció: GPTBot és a bejárók kezelése
- Nem a sorrend számít: az illeszkedő szabályok közül a leghosszabb útvonal-minta érvényesül, döntetlennél az Allow.
- A csillag bármilyen karaktersort helyettesít, a dollárjel az URL végét rögzíti, és ez a kettő teljesen más találati halmazt ad.
- A robots.txt tiltás a bejárást akadályozza, az indexelést nem garantáltan: tiltott URL cím alapján is bekerülhet a találatok közé.
- Ha a robots.txt 5xx hibát ad, a Google átmenetileg teljes tiltásként kezeli az oldalt, ezért a fájl elérhetőségét monitorozni kell.
- A legtöbb WordPress oldalnak öt-hat sornyi robots.txt is elég, a hosszú öröklött fájlok többet ártanak, mint használnak.
Gyakori kérdések
A robots.txt-ben a sorrend számít?
Nem. A Google és a szabványkövető bejárók az illeszkedő szabályok közül a leghosszabb útvonal-mintát alkalmazzák, függetlenül attól, hogy a fájlban hol áll. Azonos hosszúságú Allow és Disallow esetén az engedélyezés érvényesül. Csoporton belül tehát nyugodtan rendezheted a sorokat olvashatóság szerint.
Ha letiltok egy oldalt a robots.txt-ben, kikerül a Google indexéből?
Nem feltétlenül. A tiltás a bejárást akadályozza, nem az indexelést. Egy blokkolt URL bekerülhet a találatok közé leírás nélkül, ha máshonnan hivatkoznak rá. Ha biztosan ki akarod venni, engedd a bejárást, és tegyél az oldalra noindex meta címkét vagy HTTP fejlécet.
Mi a különbség a Disallow: /kereses és a Disallow: /kereses/ között?
Az első előtagként illeszkedik, tehát a /kereses, a /kereses/, a /kereses?q=cipo és a /keresesi-tippek is a hatálya alá esik. A második csak azokra az URL-ekre hat, amelyek útvonala a /kereses/ karaktersorral kezdődik. Pontosan egy URL tiltásához a Disallow: /kereses$ formát használd.
Mi történik, ha a robots.txt fájlom szerverhibát ad vissza?
A Google dokumentációja szerint az 5xx és a 429 válaszokat átmenetileg teljes tiltásként kezeli, és visszafogja a bejárást. Ha az állapot 30 napnál tovább tart, a gyorsítótárazott példányt használja, annak hiányában pedig korlátozás nélkül jár be. Ezért érdemes a robots.txt elérhetőségét külön monitorozni.
Vonatkozik a fődomain robots.txt-je az aldomainre is?
Nem. A robots.txt mindig gazdagép, protokoll és port szintű. A shop.pelda.hu saját robots.txt fájlt igényel, és a http, illetve https változat is külön kezelendő. A Search Console robots.txt-jelentése éppen ezért listázza külön sorokban a gazdagépeket.
Hogyan tesztelhetem a szabályokat élesítés előtt?
Állíts össze egy valós URL-listát a sitemapből, a Search Console adataiból és a szervernaplóból, majd futtasd le rajta a régi és az új szabálykészletet egy szabványkövető parserrel, például a Google nyílt forráskódú robots.txt értelmezőjével. Csak a különbséglistát kell átnézned, élesítés után pedig az URL-ellenőrzővel érdemes ellenőrizni néhány kulcsoldalt.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.