A noindex az egyik legegyszerűbb SEO-eszköz, mégis rendszeresen ezen bukik el egy technikai átvizsgálás. Nem azért, mert nehéz lenne beállítani, hanem mert rossz helyre kerül. Beírod a bővítménybe, a Search Console mégis indexeltként mutatja az oldalt, vagy éppen ott marad egy tavalyi árlista PDF a találatok között, amire senki nem akart forgalmat. Az alábbiakban végigmegyünk azon, hogy melyik eszköz mire való, hogyan állítod be Apache és Nginx alatt, és hogyan ellenőrzöd, hogy tényleg szól-e valamit a szervered.
Mi a különbség a meta robots és az X-Robots-Tag között?
Ugyanazt mondják a keresőnek, csak máshol mondják. A meta robots a HTML dokumentum fej részében található címke, az X-Robots-Tag pedig egy HTTP válaszfejléc, ami még a fájl tartalma előtt megérkezik. A fejléc emiatt olyan erőforrásokra is ráteheto, amelyeknek egyáltalán nincs HTML szerkezetük.
Hivatalosan igazolt. A Google Search Central dokumentációja szerint a két megoldás lényegében azonos irányelv-készletet támogat, és a kereső mindkettőt egyenrangúan értelmezi. A leggyakrabban használt irányelvek ezek:
noindex, vagyis ne kerüljön be az indexbenofollow, vagyis az oldalon található linkeket ne kövessenoarchive, tehát ne tároljon gyorsítótárazott másolatotnosnippetésmax-snippet, a találati kivonat korlátozásáramax-image-preview, a képelőnézet méretéreunavailable_after, ami adott időpont után veszi ki a találatokból
Ha a két helyen ellentmondás van, a szigorúbb irányelv érvényesül. Vagyis ha a HTML-ben index áll, a fejléc viszont noindex-et küld, a kereső a noindex-et veszi figyelembe. Ez a gyakorlatban jó hír, mert azt jelenti, hogy a szerver szintjén beállított tiltást a sablon nem tudja véletlenül felülírni, csak a fordítottja fordulhat elő.
Mikor nem elég a HTML-be írt meta robots?
Akkor, amikor nincs HTML, vagy amikor a HTML nem a te kezedben van. Ez négy tipikus helyzetet jelent, és mindegyik gyakoribb, mint elsőre gondolnád.
- Letölthető dokumentumok. PDF, DOCX, XLSX, PPTX, CSV, ZIP. Ezekbe nem tudsz meta címkét tenni, a Google viszont a PDF tartalmát feldolgozza és indexeli.
- Képek és videók. Egy JPG vagy PNG önálló URL-en érhető el, és önállóan is megjelenhet a képkeresőben.
- JS-sel épített oldalak. Ahol az oldal tartalma és a fej része is futás közben áll össze.
- Nem a saját sablonodból kiszolgált fájlok. Objektumtárolóból, CDN-ről vagy külön fájlkiszolgálóról érkező erőforrások, ahol nincs, aki a fejlécet beleírja a válaszba.
A JavaScript esete külön figyelmet érdemel, mert itt van egy csapda. Hivatalosan igazolt, hogy a Google rendereli az oldalakat, és a renderelés után beírt meta robots címkét is figyelembe veszi. A fordított irány viszont nem működik. Ha a kiszolgált nyers HTML már tartalmaz noindex-et, a kereső jó eséllyel abbahagyja a feldolgozást, és el sem jut odáig, hogy a JavaScript később kiszedné azt a címkét. Vagyis egy kezdeti noindex, amit a kliens oldali kód majd "eltávolít", tartós indexelési problémát okozhat.
Saját tapasztalat. A nálunk átvizsgált oldalakon a felesleges indexelt tartalom legnagyobb része nem is HTML. Régi árlista PDF-ek, letöltött katalógusok, szerződésminták, egy-egy belső dokumentum, amire valaki linkelt egyszer. Ezek addig maradnak bent, amíg valaki fejléc szinten nem kezeli őket, mert bővítménnyel egyszerűen nincs mit kezdeni rajtuk.
Hogyan tiltod ki a fájltípusokat Apache alatt?
Egy mod_headers szabállyal, fájlkiterjesztés szerint. A legrövidebb, működő változat a .htaccess fájlban így néz ki.
<IfModule mod_headers.c> <FilesMatch "\.(pdf|docx?|xlsx?|pptx?|csv|zip)$"> Header set X-Robots-Tag "noindex, nofollow" </FilesMatch></IfModule>
Néhány dolog, ami itt számít. Az IfModule burkolat azért kell, hogy ne dőljön el a szerver, ha a modul nincs betöltve. A FilesMatch reguláris kifejezés, tehát a pontot escape-elni kell, különben bármilyen karakterre illeszkedik. Ha van hozzáférésed a virtuális hoszt konfigurációjához, oda érdemesebb tenni, mert az Apache a .htaccess fájlokat minden kérésnél újraolvassa a könyvtárláncban, a hoszt-konfigot viszont csak indításkor.
Ha egyetlen fájlt mégis engednél indexelni, arra a legtisztább megoldás egy szűkebb szabály, ami visszavonja a tiltást. Ilyenkor a Header unset X-Robots-Tag sor kerül egy konkrét fájlra illeszkedő FilesMatch blokkba, a fentiek után. A sorrend számít, mert az utoljára futó szabály marad érvényben.
Hogyan állítod be ugyanezt Nginxen?
Egy location blokkal és egy add_header sorral, szintén kiterjesztés szerint.
location ~* \.(pdf|docx?|xlsx?|pptx?|csv|zip)$ { add_header X-Robots-Tag "noindex, nofollow" always;}
Az always kulcsszó nélkül a fejléc csak a sikeres válaszokhoz kerül hozzá, hibakódoknál nem. Ennél viszont van egy sokkal drágább buktató, amire érdemes figyelni. Az Nginxben az add_header irányelvek nem összeadódnak a blokkok között, hanem a legbelső szint teljesen felülírja a külsőt. Ha a server blokkban beállítasz biztonsági fejléceket, majd egy location blokkban hozzáadsz egyetlen add_header sort, abban a blokkban az összes örökölt fejléc eltűnik. Ezt a hibát a böngésző nem jelzi, csak a fejlécek hiányoznak csendben.
Fejlesztői vagy próba-környezetnél ugyanez a szabály egyetlen sorrá egyszerűsödik a server blokk tetején, mert ott az egész kiszolgálót tiltani akarod. Ez összehasonlíthatatlanul megbízhatóbb, mint jelszavas védelem nélkül bízni abban, hogy a staging oldalra senki nem linkel.
Miért nem veszi észre a Google a noindexet, ha a robots.txt tiltja?
Mert a robots.txt a bejárást tiltja, nem az indexelést. Ha az URL le sem tölthető, a kereső soha nem fogja elolvasni sem a meta címkét, sem a HTTP-fejlécet, amiben a noindex áll. A tiltás így pont az ellenkezőjét éri el annak, amit szeretnél.
Hivatalosan igazolt. A Google dokumentációja szerint egy bejárásból kizárt URL továbbra is megjelenhet a találatok között, ha külső vagy belső link mutat rá. Ilyenkor cím és leírás nélkül, csak az URL-lel kerül be, mert a kereső tud a létezéséről, de a tartalmát nem ismeri. Szintén hivatalos, hogy a noindex sor a robots.txt fájlban 2019 szeptembere óta nem támogatott irányelv, tehát az ott elhelyezett tiltásnak nincs hatása.
A helyes sorrend ezért mindig ez.
- Engedd a bejárást, vagyis vedd ki az érintett útvonalat a robots.txt
Disallowsorai közül. - Tedd rá a
noindex-et, meta címkével vagy fejléccel. - Várd meg, amíg a kereső újra bejárja az URL-t és kiveszi az indexből. Ez napoktól hetekig tarthat, ritkán látogatott PDF-eknél inkább hetekig.
- Csak ha az URL már kiesett, és a bejárási keret miatt tényleg zavar, akkor tiltsd le a bejárást is.
A noindex és a Disallow egyidejű használata tehát nem dupla biztosíték, hanem működésképtelen kombináció.
Hogyan ellenőrzöd, hogy tényleg működik?
Két független ellenőrzéssel, mert a kettő mást mutat. A curl azt, hogy a szerver mit küld, a Search Console azt, hogy a Google mit lát belőle.
curl -sI https://pelda.hu/letoltes/arlista.pdf | grep -i x-robots
Ha a válasz üres, a fejléc nem megy ki. Ha kiírja a x-robots-tag: noindex, nofollow sort, a szerver rendben dolgozik. Érdemes megismételni a hívást Googlebot néven is, mert előfordul, hogy egy tűzfal vagy CDN a robotoknak más választ ad.
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://pelda.hu/letoltes/arlista.pdf
A Search Console oldalán az URL-vizsgálat eszközbe illeszd be ugyanazt a címet, és nézd meg az "Indexelés engedélyezett?" sort. Fontos, hogy az "Élő URL tesztelése" gombra is kattints, mert az alapnézet a legutóbbi bejárás állapotát mutatja, ami akár hónapokkal korábbi is lehet. A vizsgálat eredményénél a renderelt HTML fülön ellenőrizheted, hogy JavaScript után mi áll ténylegesen a fej részben. Az eszköz csak olyan címekre működik, amelyek a te tulajdonodban lévő property alá tartoznak, és PDF URL-re is használható.
Az utolsó lépés a türelem. A fejléc helyes jelenléte nem azonos az index állapotával, a kiesés a következő bejárásnál történik meg. Ha nagyon sürgős, az eltávolítás eszköz átmenetileg elrejti a találatot, de az csak ideiglenes, a tartós megoldás továbbra is a noindex.
Miért tartósabb a fejléc-alapú vezérlés, mint a bővítmény?
Saját nézőpont és saját tapasztalat. Azért, mert a szerverkonfiguráció nem része annak a rétegnek, amit a CMS és a bővítményei felülírnak. Egy SEO-bővítmény beállítása az adatbázisban él, és az adatbázis tartalmát sok minden érinti, amiről nem te döntesz.
A tipikus töréspontok ismerősek lesznek. Egy nagyobb bővítmény-frissítés átnevezi a beállításkulcsot, és a korábbi érték alapértelmezettre esik vissza. Valaki sablont vált, az új téma pedig saját fej-kimenetet generál. Egy oldalépítő gyorsítótárból szolgálja ki a HTML-t, és a benne tárolt változat még a régi állapotot tartalmazza. Migráció után az adatbázis egy része átjön, egy része nem. Ezek mind olyan események, amiket a szerverkonfigban elhelyezett szabály egyszerűen túlél, mert fájlban van, verziózható, és a telepítési folyamat része.
Ebből nem következik, hogy a bővítményes megoldás rossz. Egyedi oldalak esetén, ahol a szerkesztő dönti el, hogy egy adott aloldal kerüljön-e be az indexbe, a felületen kattintható kapcsoló a helyes eszköz. A szabály nálunk úgy alakult ki, hogy ami mintázat, az a szerverre kerül, ami egyedi döntés, az a CMS-be. Egy teljes könyvtárnyi letölthető dokumentum mintázat, egy konkrét köszönőoldal viszont egyedi döntés.
Szakmai feltételezés. Ahogy egyre több automatizált látogató tölt le nem HTML erőforrásokat is, a fejléc szerepe várhatóan nőni fog a meta címkéhez képest. Ezt hivatalos forrás nem mondja ki így, csak abból következik, hogy a fejléc az egyetlen olyan csatorna, ami minden fájltípusra egységesen működik.
Milyen hibák viszik el a legtöbb időt a gyakorlatban?
Az alábbi lista végigmegy azokon a pontokon, amiket egy technikai átnézésnél elsőként ellenőrzünk.
- A
noindexés a robots.txtDisallowugyanarra az útvonalra van beállítva, így a tiltás sosem jut el a keresőig. - A próba-környezet teljes tiltása átkerül az éles oldalra a telepítéskor. Ez a legdrágább hiba a sorban, mert az egész oldal kiesik.
- Nginxen egy
locationblokkba kerültadd_headercsendben letörli az örökölt fejléceket. - A
noindexegy olyan oldalon van, amire másik oldalak kanonikus címként mutatnak. Ez ellentmondó jelzés, a kereső nem tudja mit kezdeni vele. - A tiltott URL továbbra is benne van az XML sitemapben, ami szintén ellentmondás.
- A CDN gyorsítótárazza a régi választ, és a frissen beállított fejléc a látogatókhoz nem jut el. Ilyenkor a CDN oldalán is üríteni kell.
- A fejléc csak a HTML válaszra kerül rá, a mögötte lévő fájlkiszolgálóra nem, mert a kettőt más réteg szolgálja ki.
Mit jelent mindez az AI-válaszmotorok felé?
A noindex a keresők indexét érinti, az AI-rendszerek adatgyűjtése pedig ettől részben független kérdés. A kettőt nem érdemes összemosni.
Hivatalosan igazolt. A Google külön robot-azonosítót használ a generatív modellek tanításához kapcsolódó felhasználásra, és ennek vezérlése a robots.txt fájlban történik, nem a noindex irányelven keresztül. Ugyanígy a nagyobb AI-szolgáltatók saját robot-neveket dokumentálnak, amelyeket szintén robots.txt szinten lehet engedni vagy tiltani. Vagyis ha egy PDF-et kiveszel a Google indexéből, attól az még hozzáférhető marad egy másik látogató számára, hacsak külön nem rendelkezel róla.
Fordítva is igaz. Ha egy dokumentum valóban nem való nyilvánosság elé, a robot-irányelvek egyike sem véd meg, mert ezek kérések, nem korlátok. Bizalmas tartalomnál a helyes megoldás a hitelesítés mögé helyezés vagy a kiszolgálás megszüntetése, nem a noindex. A robot-vezérlés arra való, hogy a nyilvános, de nem keresőbarát tartalmaid ne vigyék el a figyelmet a fontos oldalaidról, és ebben a szerepében jól teljesít.
Források és további olvasnivalók
- Google Search Central, Robots meta tag, data-nosnippet és X-Robots-Tag specifikáció
- Google Search Central, Introduction to robots.txt és a robots.txt specifikáció
- Google Search Central, JavaScript SEO alapok és a renderelés folyamata
- Google Search Central Blog, A robots.txt nem támogatott irányelveiről szóló bejelentés
- Google Search Console súgó, URL-vizsgálat eszköz és Eltávolítások eszköz
- Apache HTTP Server dokumentáció, mod_headers és FilesMatch
- Nginx dokumentáció, ngx_http_headers_module és a location blokkok öröklődése
- RFC 9110, HTTP Semantics, a válaszfejlécek kezeléséről
- A meta robots és az X-Robots-Tag ugyanazokat az irányelveket ismeri, csak a fejléc bármilyen fájltípusra ráteheto.
- PDF, kép, táblázat, ZIP és letölthető fájl esetén nincs HTML fej, így ott csak a HTTP-fejléc marad.
- A robots.txt Disallow nem azonos a noindexszel, sőt meg is akadályozhatja, hogy a kereső észrevegye a noindexet.
- Az ellenőrzés két lépésből áll, egy curl-hívásból a fejlécre és egy Search Console URL-vizsgálatból.
- A szerverkonfigban elhelyezett szabályt nem törli le egy bővítmény-frissítés vagy egy sablonváltás, ezért tartósabb.
Gyakori kérdések
A noindex meta tag és az X-Robots-Tag közül melyiket vegye figyelembe a kereső, ha mindkettő ott van?
A szigorúbb irányelv érvényesül. Ha a fejléc noindex-et küld, a HTML-ben pedig index áll, a kereső a noindex szerint jár el. Ezért a szerver szintjén beállított tiltást a sablon nem tudja véletlenül feloldani.
Miért látszik még mindig a Google találatai között az az oldal, amire kitettem a noindexet?
Két gyakori oka van. Vagy még nem járta be újra a kereső az URL-t, ilyenkor türelem kell, vagy a robots.txt tiltja az URL bejárását, így a noindex el sem jut a keresőhöz. Ellenőrizd a robots.txt-t, majd a Search Console élő URL-vizsgálatát.
Hogyan tudok PDF-et kivenni a keresőből, ha meta címkét nem tudok beletenni?
X-Robots-Tag HTTP-fejléccel, amit a szerver ad a válaszhoz. Apache alatt mod_headers és FilesMatch szabállyal, Nginxen egy location blokkban elhelyezett add_header sorral, kiterjesztés szerint szűrve.
Elég a robots.txt Disallow sor, ha nem akarom, hogy egy oldal megjelenjen a keresőben?
Nem. A Disallow a bejárást tiltja, nem az indexelést. Ha link mutat az URL-re, az megjelenhet a találatok között cím és leírás nélkül. A megjelenés megakadályozására a noindex való, és ahhoz a bejárást engedni kell.
Hogyan ellenőrzöm parancssorból, hogy kimegy-e az X-Robots-Tag fejléc?
A curl -sI paranccsal kérd le a válaszfejléceket, és szűrj az x-robots kifejezésre. Érdemes a hívást Googlebot user agenttel is megismételni, mert egy tűzfal vagy CDN a robotoknak más választ adhat.
A noindex megakadályozza, hogy az AI-rendszerek felhasználják a tartalmat?
Nem, ez két külön kérdés. Az AI-robotok hozzáférését a robots.txt fájlban, robot-azonosító szerint lehet szabályozni. Bizalmas tartalomnál egyik irányelv sem véd meg, ott hitelesítés mögé kell tenni az anyagot.
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.