Október 21.: a Google szerint az ékezetes útvonalakat kódolva írd be a robots.txt-be

A Google keresési csapata 2026. október 21-én kiadta a „The Non-Canonical Cabinet” című sorozat második epizódját, és két mondat miatt érdemes végighallgatni. Az egyik: a robots.txt hozzáférési protokoll, vagyis a bejárást szabályozza, nem azt, hogy egy rendszer mit tesz a már letöltött adattal. A másik: a nem angol karaktereket a robots.txt szabályaiban kódolva írd ki, hogy a többi robot se hagyja ki a sort. A második mondat a magyar oldalakat érinti, mert nálunk az útvonalakban ott lehet az á, az é és az ő. Átolvastam a videó feliratát és a Google három fejlesztői oldalát, és összeszedtem, mit állít a Google, és mit nem.

Kézzel rajzolt kép: az asztalon kigöngyölt papírtekercs szolgál útként, rajta robotok haladnak egymás után a lapos köveken, az egyik megáll a megjelölt kövekből álló szakasz szélén és felemeli a kezét, jobbra pedig egy nő figyeli őket a laptopja mögül.

Mit mondott a Google október 21-én?

A videó „What can you actually put in a robots.txt?” címmel jelent meg a Google Search Central csatornáján 2026. október 21-én, és 9 perc 45 másodperc hosszú. Ez a „The Non-Canonical Cabinet” sorozat második epizódja, a műsorvezetők Gary Illyes és Cherry Prommawin.

Illyes két mondatban rendezi el, mire való a fájl:

robots.txt is an access preference protocol.

Majd ugyanerről:

It doesn't dictate what a system does with the data after it has already crawled it.

A kódolásról Cherry Prommawin beszél, és tőle hangzik el ez a tanács is:

to be safe across the entire global internet infrastructure, you should use the encoded version in your robots.txt rules. Google's parser is flexible and will automatically translate Chinese characters, German umlauts or emojis by encoding them.

A videó záró összefoglalása ugyanezt ismétli meg: az emodzsikat és a nem angol karaktereket százalékos kódolással írd le a robots.txt szabályainak útvonalaiban, hogy minden robot számára biztonságosak legyenek. Ugyanezek a sorok a Search Engine Roundtable átiratában is olvashatók.

A robots.txt a bejárásról szól, nem a későbbi felhasználásról

Ez a videó legfontosabb állítása, és szembemegy azzal, amit sokan hisznek a fájlról. A robots.txt arról rendelkezik, hogy egy robot lekérheti-e az oldaladat. Arról nem rendelkezik, hogy a már letöltött szöveggel mi történik azután. Illyes mondata pontosan ezt zárja ki: „It doesn't dictate what a system does with the data after it has already crawled it.”

A Search Engine Journal elemzése ugyanerről a videóról két dolgot emel ki. Az egyik: ha egy AI-robotot ki akarsz zárni, a fájlban kifejezetten az ő saját user-agent tokenjét kell megcímezned. A másik: a szabvány a bejárásra vonatkozik, a későbbi felhasználásra nem. Ugyanez a cikk említi, hogy létezik egy IETF-munkaanyag Illyes társszerzőségével, amely felhasználási preferenciát is bevinne a robots.txt-be. Ez munkaanyag, tehát nem szabvány, és nem találtam olyan forrást, amely szerint bármelyik robot ma követné.

A tiltás ezért robotonként külön feladat. A Google saját robotjait felsoroló oldala szerint a Google-Extended önálló terméktoken, amellyel a kiadó azt kezelheti, hogy a Google által bejárt tartalom felhasználható-e a Gemini-modellek későbbi generációinak tanításához. Ugyanez az oldal hozzáteszi, hogy a Google-Extended nem befolyásolja az oldal bekerülését a Google Keresőbe, és rangsorolási jelzésként sem használja a Google.

Az OpenAI külön neveket használ. Az OpenAI robotjait leíró oldal négyet sorol fel: OAI-SearchBot, OAI-AdsBot, GPTBot és ChatGPT-User. Ugyanitt áll, hogy az OAI-SearchBot elől kizárt oldalak nem jelennek meg a ChatGPT keresési válaszaiban, navigációs hivatkozásként viszont még megjelenhetnek. Az Anthropic és az OpenAI külön botjairól korábban írtam, és a robots.txt technikai alapjait is végigvettem.

Mit ért a Google, és mit a többi robot?

A Google saját értelmezője mindkét alakot egyformán olvassa. A robots.txt-specifikáció ezt írja:

The path in the rules can be either raw UTF-8 characters or percent-encoded UTF-8 strings (per RFC 3986). ... Disallow: /foo/bar/ツ and Disallow: /foo/bar/%E3%83%84 are treated identically by the parser.

A Google tehát nem írja elő a kódolást. Ajánlani viszont ajánlja: a specifikáció mai, „Last updated 2026-10-23 UTC” dátumot viselő alakjában ott áll ez a mondat is:

While Google’s systems parse raw UTF-8 characters properly, using percent-encoding for rule paths can make it easier to process these files with third-party tools and services.

Ez ugyanaz az indok, amelyet a videó is mond: nem a Google értelmezője a szűk keresztmetszet, hanem a körülötte lévő világ, „to be safe across the entire global internet infrastructure”. Hogy melyik robot bukik el egy kódolás nélküli útvonalon, arról egyetlen általam elolvasott forrás sem közöl mérést. A videó német umlautokat, kínai karaktereket és emodzsikat nevez meg, magyar betűket nem.

Ugyanabban a specifikációban van egy sor, amely a fájl egészére vonatkozik:

The robots.txt file must be a UTF-8 encoded plain text file ... if the character encoding of the robots.txt file isn't UTF-8, Google may ignore characters that are not part of the UTF-8 range, potentially rendering robots.txt rules invalid.

Ha a robots.txt-edet olyan szerkesztő mentette el, amely nem UTF-8-ban dolgozik, akkor a magyar ékezetes betűket tartalmazó sorok a Google saját leírása szerint érvénytelenné válhatnak. A kódolt alak ezt a csapdát is megkerüli, mert a százalékos jelölés csak ASCII-karakterekből áll. Ez az utolsó mondat a saját következtetésem, a Google oldala ennyit nem mond ki.

Magyar betűk, kódolva

A kilenc magyar ékezetes betű százalékos alakját magam számoltam ki a Python urllib.parse.quote függvényével, mert a Google lapjain és a videóban német umlautok és kínai karakterek szerepelnek példaként, magyar betűk nem: á %C3%A1, é %C3%A9, í %C3%AD, ó %C3%B3, ö %C3%B6, ő %C5%91, ú %C3%BA, ü %C3%BC, ű %C5%B1.

Egy útvonalon ez így néz ki: az /árak/ helyett /%C3%A1rak/ kerül a szabályba, a /szolgáltatások/ helyett pedig /szolg%C3%A1ltat%C3%A1sok/. Ezek az átírások is a sajátjaim.

Egy teljes szabály a kódolt alakkal így fest. Ez a példa a saját összeállításom, a Google oldalain nem szerepel:

User-agent: *
Disallow: /%C3%A1rak/

A Google értelmezője számára ez ugyanaz, mint a Disallow: /árak/, mert a specifikáció a két alakot azonosan kezeli. A különbség csak a többi robotnál jelentkezhet, és ott sem mérte meg senki.

Az ékezetes domainről és az URL szavairól

A Google URL-szerkezetről szóló oldala a „Last updated 2026-10-21 UTC” dátumot viseli, és két dolgot ír elő. Az egyik: használj a közönséged nyelvén lévő szavakat az URL-ben, és ha van ilyen, átírt szavakat. A másik: a nem ASCII-tartományba eső karaktereket százalékosan kódolva kell írni, és a szabvány által fenntartott karaktereket szintén. Az oldal példája a német /gem%C3%BCse ajánlott alakja és a /gemüse nem ajánlott alakja.

A „Last updated” dátum nem mondja meg, melyik sor változott azon a napon, úgyhogy nem állítom, hogy a kódolásról szóló tanács új. A videó magyarázat, szabályváltozást a Google nem jelentett be.

Az ékezetes domain kérdése a sorozat első, 2026. október 14-i epizódjában került szóba. Az arról szóló beszámoló szerint Illyes az URL-ben lévő kulcsszavakat „an incredibly small signal”-nak nevezte, amely „really only matters when we have absolutely nothing else to go on”. Az automatikus feliratokban az is elhangzik, hogy a nemzetközi karaktereket tartalmazó domainnevek punycode alakra alakulnak át, és ez az alak xn-- előtaggal kezdődik. Az egyik műsorvezető szerint az ilyen domain segítheti a márka felismerését, és ha a vállalkozásod nagyon helyi, abban is segít, hogy az emberek ki tudják betűzni és el tudják olvasni a domaint. A rangsorolásról ebben az epizódban nem esett szó.

John Mueller 2026. október 19-én a Blueskyn azt válaszolta, hogy a nyers szögletes zárójel és annak százalékosan kódolt alakja két különböző URL, és azt javasolta, hogy a linkekben, a canonical címkékben és a sitemapban ugyanazt az alakot használd. Ezt a választ nem lehet átvinni az ékezetekre: Mueller a szögletes zárójelről, a pluszjelről és a szóközről beszélt, ékezetes betűkről nem. Az ő kérdése az URL-ekről szólt, a videó tanácsa pedig a robots.txt szabályairól.

Egy perc a saját robots.txt-edben

Négy dolgot nézz meg, és mindegyik a fenti forrásokból következik.

Először nyisd meg a fájlt. A böngésző címsorába írd be a domainedet, utána pedig a /robots.txt-t. Ha nincs ilyen fájlod, akkor nincs benne mit kódolni.

Másodszor keress ékezetes vagy más nem ASCII-karaktert a Disallow és az Allow sorok útvonalaiban. A magyar oldalakon ez az /árak/, a /szolgáltatások/ és a hasonló útvonalak esetében fordul elő.

Harmadszor, ha találtál ilyet, írd mellé a kódolt alakot is. A Google számára a két alak azonos, ezt a specifikáció mondja ki. A kódolás a többi robot miatt van, és a videó szerint így biztonságos a teljes internetes infrastruktúrában.

Negyedszer ellenőrizd a fájl mentési kódolását. UTF-8 nélkül a Google saját leírása szerint az ékezetes betűket tartalmazó szabályok érvénytelenné válhatnak.

Amit ez a négy lépés nem ad meg, az a már bejárt tartalom sorsa. Arra a robots.txt nem válasz, és ezt a Google mondta ki október 21-én. Ha azt szeretnéd, hogy egy adott AI-robot ne járja be az oldaladat, a saját user-agent tokenjét kell megcímezned, és erről a véletlen önkizárásról szóló írásomban megtalálod, mi szokott félresikerülni. Ha az AI-összefoglalóból szeretnél kimaradni, arra a robots.txt szintén nem a megfelelő eszköz: a három kapcsolóról szóló írásban végigvettem, melyik beállítás mit vesz ki. A teljes botkizárásnak pedig ára van, és erről is írtam: ha kitiltottad az AI-botokat, a Google is kieshet.

Amit nem tudok

Nem tudom, melyik robot hibázik el egy kódolás nélküli, ékezetes útvonalat. Ilyen mérést egyetlen forrásban sem találtam, és magam sem futtattam. A videó német umlautokat, kínai karaktereket és emodzsikat nevez meg, a magyar betűkről egyik Google-oldal sem beszél.

A magyar domainekről sincs Google-állítás. Az első epizód általában beszél a nemzetközi karaktereket tartalmazó domainnevekről, a .hu regisztrációról és a magyar ékezetekről nem.

Az IETF-munkaanyagról annyit tudok, amennyit a Search Engine Journal ír: létezik, és Illyes a társszerzője. Ez munkaanyag, tehát nem szabvány, és nem találtam olyan robotot, amelyről valaki leírta volna, hogy már követi.

És nem tudom, miért éppen most került ki ez a videó. Szabályváltozást egyik Google-oldal sem jelent be, úgyhogy magyarázatként olvasom, és a saját robots.txt-emet is így néztem végig.

A videót és a Google három fejlesztői oldalát 2026. október 23-án nyitottam meg, és a fenti angol mondatokat onnan idézem szó szerint. A fordítások, a százalékos átírások és a következtetések a sajátjaim.

Gyakori kérdések

Muszáj kódolva írnom az ékezetes útvonalakat a robots.txt-ben?

Nem muszáj, de a Google is ezt ajánlja. A robots.txt-specifikáció szerint a szabályok útvonala lehet nyers UTF-8 karakter vagy százalékosan kódolt UTF-8 szöveg, és a két alakot az értelmező azonosan kezeli: „Disallow: /foo/bar/ツ and Disallow: /foo/bar/%E3%83%84 are treated identically by the parser.” Ugyanez az oldal a „Last updated 2026-10-23 UTC” dátumot viselő alakjában hozzáteszi: „using percent-encoding for rule paths can make it easier to process these files with third-party tools and services.” A 2026. október 21-i videóban Cherry Prommawin is a kódolt alakot javasolja, és az indok a Google értelmezőjén kívüli világ: „to be safe across the entire global internet infrastructure, you should use the encoded version in your robots.txt rules.” Hogy melyik robot bukik el a nyers alakon, arról egyetlen forrásban sem találtam mérést, és a magyar betűkről egyik Google-oldal sem beszél.

Megállítja a robots.txt, hogy az AI tanuljon a tartalmamból?

Nem. A 2026. október 21-i videóban Gary Illyes ezt mondja: „robots.txt is an access preference protocol”, majd „It doesn't dictate what a system does with the data after it has already crawled it.” A fájl tehát a bejárásról rendelkezik, és nem arról, hogy a már letöltött adattal mit tesz egy rendszer. A Search Engine Journal ugyanerről a videóról azt írja, hogy létezik egy IETF-munkaanyag Illyes társszerzőségével, amely felhasználási preferenciát is bevinne a fájlba, de ez munkaanyag, tehát nem szabvány. A Google-Extended külön eset: a Google leírása szerint önálló terméktoken, amellyel a kiadó a Gemini-modellek későbbi generációinak tanításához felhasznált tartalmat kezelheti, és ugyanez az oldal írja, hogy nem befolyásolja az oldal bekerülését a Google Keresőbe, és rangsorolási jelzésként sem használják.

Hogyan zárok ki egy AI-robotot?

A saját user-agent tokenjének megcímzésével. A Search Engine Journal a 2026. október 21-i videóról azt írja, hogy ha egy AI-robotot ki akarsz zárni, a fájlban kifejezetten az ő saját user-agent tokenjét kell megcímezned. Az OpenAI robotjait leíró oldal négy nevet sorol fel: OAI-SearchBot, OAI-AdsBot, GPTBot és ChatGPT-User. Ugyanitt áll, hogy az OAI-SearchBot elől kizárt oldalak nem jelennek meg a ChatGPT keresési válaszaiban, navigációs hivatkozásként viszont még megjelenhetnek. A Google oldalán a Google-Extended tartozik a Gemini-tanításhoz. Egy általános szabály tehát nem elég, mert minden robot a saját nevére hallgat.

Számít, hogy magyar kulcsszó van az URL-ben?

A Google URL-szerkezetről szóló oldala azt írja, hogy használj a közönséged nyelvén lévő szavakat az URL-ben, és ha van ilyen, átírt szavakat. A súlyáról a sorozat első, 2026. október 14-i epizódjában Gary Illyes beszélt: az URL-ben lévő kulcsszó szerinte „an incredibly small signal”, amely „really only matters when we have absolutely nothing else to go on”. A jelzés tehát létezik, de kicsi, és akkor jut szóhoz, amikor semmi más nem áll a Google rendelkezésére. Ugyanaz az URL-szerkezetről szóló oldal kéri azt is, hogy a nem ASCII-tartományba eső karaktereket százalékosan kódolva írd; a példája a német /gem%C3%BCse ajánlott és a /gemüse nem ajánlott alakja.

Használhatok ékezetes domaint?

A sorozat első, 2026. október 14-i epizódja erről annyit mond, hogy a nemzetközi karaktereket tartalmazó domainnevek punycode alakra alakulnak át, amely xn-- előtaggal kezdődik. Az automatikus feliratok szerint az egyik műsorvezető úgy fogalmaz, hogy az ilyen domain segítheti a márka felismerését, és ha a vállalkozásod nagyon helyi, abban is segít, hogy az emberek ki tudják betűzni és el tudják olvasni a domaint. A rangsorolásról ebben az epizódban nem esett szó, és a magyar ékezetekről vagy a .hu regisztrációról egyik Google-oldal sem beszél. John Mueller 2026. október 19-én azt válaszolta, hogy a nyers szögletes zárójel és a kódolt alakja két különböző URL, és ugyanazt az alakot javasolta a linkekben, a canonical címkékben és a sitemapban. Ez a válasz a szögletes zárójelről, a pluszjelről és a szóközről szólt, ékezetes betűkről nem.

Mi a UTF-8 szerepe a robots.txt-ben?

A Google robots.txt-specifikációja szerint a fájlnak UTF-8 kódolású egyszerű szöveges fájlnak kell lennie, és ha a fájl karakterkódolása nem UTF-8, a Google figyelmen kívül hagyhatja azokat a karaktereket, amelyek nem tartoznak az UTF-8 tartományba, ami a robots.txt szabályait érvénytelenné teheti. Egy magyar oldalon ennek konkrét következménye van, mert az ékezetes betűket tartalmazó sorok eshetnek ki így. A százalékosan kódolt alak csak ASCII-karakterekből áll, úgyhogy ezt a csapdát megkerüli. Ez az utolsó mondat már a saját következtetésem, a Google oldala ennyit nem mond ki.

Források