Van a WordPress adminfelületén egy kapcsoló, ami egyetlen pipával képes hónapokra kivonni a keresőkből egy egyébként rendben lévő weboldalt. A Beállítások, Olvasás menüpont alatt lakik, a neve Keresőmotorok indexelésének tiltása, alatta pedig ott a WordPress saját, óvatos megfogalmazása: a keresőmotorokon múlik, hogy eleget tesznek-e a kérésnek. Ez a mondat sokakat megtéveszt. Úgy hangzik, mintha egy udvarias jelzésről lenne szó, amit a Google esetleg figyelmen kívül hagy. A valóság ennél sokkal határozottabb.
Az elmúlt években rendszeresen találkoztam olyan weboldallal, ahol a szerves forgalom csökkenésének teljes magyarázata ez az egy beállítás volt. Nem tartalomprobléma, nem algoritmusfrissítés, nem versenytárs. Egy pipa. És ami ennél is kellemetlenebb: a tulajdonos legtöbbször nem a leállás napján vette észre, hanem hetekkel később, amikor már a márkanévre sem jött vissza a saját oldal.
Mit csinál pontosan a keresőmotorok indexelésének tiltása kapcsoló?
Hivatalosan igazolt: a kapcsoló bekapcsolásakor a WordPress a blog_public beállítás értékét nulla értékre állítja, és ennek két, egymástól független következménye lesz a nyilvános oldalon.
- Minden публikus oldal HTML fejlécébe bekerül egy robots metacímke
noindex, nofollowtartalommal. Ez a modern WordPress-verziókban awp_robotsszűrőn keresztül generálódik. - A WordPress által kiszolgált virtuális robots.txt fájl tartalma lecserélődik: minden robotra teljes tiltás kerül, vagyis
Disallow: /sor jelenik meg. - A vezérlőpulton, az Egy pillantás alatt dobozban megjelenik egy figyelmeztetés, hogy a keresőmotorok le vannak tiltva.
- A népszerű SEO bővítmények (Yoast SEO, Rank Math, SEOPress) piros vagy sárga értesítést tesznek az admin felület tetejére.
A második pont miatt keletkezik egy sajátos csapda, amit érdemes érteni. A Google dokumentációja szerint a noindex utasítás csak akkor tud érvényesülni, ha a robot be tudja járni az adott oldalt és el tudja olvasni a metacímkét. Ha a robots.txt eleve tiltja a bejárást, akkor a kereső nem látja a noindexet, és előfordulhat, hogy egy URL bent ragad az indexben leírás nélkül. A gyakorlatban tehát a kapcsoló nem egyszerűen kivon az indexből, hanem egy zavaros, nehezen kiszámítható állapotot hoz létre, amiből a kilábalás lassabb, mint amire számítanál.
Szakmai feltételezés: ez a kettősség lehet az oka annak, hogy két hasonló méretű oldal ugyanolyan hosszú tiltás után eltérő ütemben áll vissza. Amelyiknél a robotok nem is jutottak be, ott az újrafelfedezés több körbe telik, mint ahol az oldalak bejárhatók maradtak.
Két fontos kivétel. Egy: ha a webszerver gyökerében fizikai robots.txt fájl van, akkor azt a WordPress nem írja felül, tehát a robots.txt látszólag rendben lehet, miközben a noindex metacímke ott van az összes oldalon. Kettő: bizonyos SEO bővítmények átveszik a robots kimenet vezérlését, így a metacímke formája eltérhet a WordPress alapértelmezettjétől. Ezért nem elég az adminfelületen ránézni a pipára, a végeredményt magán az élő oldalon kell ellenőrizni.
Honnan tudom biztosan, hogy be van kapcsolva a tiltás?
A legmegbízhatóbb módszer az, ha nem az adminfelületnek hiszel, hanem annak, amit a szerver ténylegesen kiszolgál. Három egymást kiegészítő ellenőrzés van, és élesítéskor mindhármat érdemes lefuttatni.
Forráskód-ellenőrzés a böngészőben
Nyisd meg az oldalt, majd a jobb gomb, Oldal forrásának megtekintése menüponttal (vagy Ctrl+U, Macen Cmd+Option+U) nézd meg a HTML-t. A keresőbe írd be, hogy robots. Ha a <head> szakaszban ott a noindex, akkor megvan az ok. Fontos, hogy ne a fejlesztői eszközök Elements fülét nézd, mert az a JavaScript által módosított állapotot mutatja, hanem a nyers forrást. Ellenőrizz legalább négy oldalt: a főoldalt, egy szolgáltatásoldalt, egy blogbejegyzést és egy kategóriaoldalt, mert a tiltás bővítmény-szinten sablononként is eltérhet.
Parancssoros ellenőrzés curl-lel
Ha van terminálod, ez a leggyorsabb út, és ez a változat cache-től és bejelentkezéstől függetlenül azt mutatja, amit a robotok kapnak:
curl -s https://pelda.hu/ | grep -i "name=.robots"a metacímke kiszedésérecurl -sI https://pelda.hu/ | grep -i "x-robots-tag"a HTTP fejlécben érkező tiltás felderítésére, amit a forráskódban nem is látnálcurl -s https://pelda.hu/robots.txta tényleges robots.txt tartalmához
Ha WP-CLI hozzáférésed van a szerverhez, akkor a wp option get blog_public parancs azonnal megmondja az igazságot: a nulla érték jelenti a tiltást, az egyes az engedélyezést. Ez a leggyorsabb ellenőrzés, ha egyszerre több oldalt kell átvizsgálnod.
Search Console jelzések
Hivatalosan igazolt: a Google Search Console Indexelés, Oldalak jelentésében külön sorként szerepel a Kizárva a noindex címke miatt kategória. Ha ez a szám hirtelen több száz vagy több ezer URL-re ugrik, gyakorlatilag biztos, hogy globális tiltás van érvényben. Egyedi URL-re az URL-ellenőrző eszköz ad választ: az Élő URL tesztelése gomb megnyomása után a Indexelés engedélyezve sorban jelenik meg, hogy noindex került észlelésre a robots metacímkében. Érdemes tudni, hogy ez a jelentés késleltetett, tehát a hiba javítása után napokig még a régi állapotot mutathatja.
Hogyan néz ki a helyes és a hibás forráskód-részlet?
A különbség egyetlen sorban látszik. Így néz ki a hibás állapot, amit élesítés után semmiképp nem akarsz látni:
<meta name='robots' content='noindex, nofollow' />
És így néz ki a rendben lévő oldal. Vagy egyáltalán nincs robots metacímke a fejlécben (ez teljesen szabályos, mert az indexelhetőség az alapértelmezés), vagy egy ilyen sor szerepel, amit tipikusan egy SEO bővítmény generál:
<meta name='robots' content='index, follow, max-image-preview:large, max-snippet:-1, max-video-preview:-1' />
A robots.txt oldalán ugyanez a kettősség. A hibás változat mindössze két érdemi sor: User-agent: *, majd Disallow: /. A jól beállított WordPress robots.txt ezzel szemben csak az adminfelületet zárja ki, az AJAX végpontot viszont engedi, és megadja a webhelytérkép helyét: Disallow: /wp-admin/, Allow: /wp-admin/admin-ajax.php, valamint Sitemap: https://pelda.hu/wp-sitemap.xml.
Mikor kapcsolják be véletlenül a tiltást?
Saját tapasztalat: az esetek túlnyomó többsége visszavezethető néhány jól körülhatárolható helyzetre, és ezek mind emberi folyamathibák, nem technikai meghibásodások.
- Staging másolat élesítése. A fejlesztői környezetben teljesen indokolt a tiltás. Amikor a kész oldalt egy migrációs bővítménnyel (Duplicator, All-in-One WP Migration, WP Migrate) átmásolják az éles domainre, az adatbázis options táblája is átjön, benne a nullára állított értékkel.
- Fejlesztői átadás. Az oldal elkészül, a fejlesztő átadja az ügyfélnek, de az utolsó lépés (a pipa levétele) senkinek nem szerepel írásban a feladatlistáján. Mindenki azt hiszi, a másik elintézte.
- Újratervezés vagy nagyobb átalakítás. A munka idejére bekapcsolják, hogy a félkész állapot ne kerüljön a keresőbe, majd az élesítés napján a figyelem a dizájnra és a űrlapokra megy el.
- Tárhelyváltás vagy klónozás. Az új szerverre került példány örökli a beállítást, és ha a régi oldal még hetekig fut, senki nem nézi meg az újat ilyen szemmel.
- Több szerkesztő, tisztázatlan jogosultságok. Adminisztrátori joggal bárki elkattinthatja, és a WordPress erről nem küld értesítést senkinek.
Miért nem azonnal látszik a forgalomvesztés?
Ez a cikk legfontosabb pontja, és egyben a saját nézőpontom: ez a leggyakoribb egyetlen kapcsolóból eredő forgalomvesztés, és ritkán derül ki azonnal. A Google nem söpri ki a teljes indexet abban a pillanatban, amikor a noindex megjelenik. Az URL-eket egyesével, saját ütemterve szerint járja be újra, és csak az újrabejárás pillanatában veszi tudomásul a tiltást. Egy nagy forgalmú főoldal akár naponta többször is sorra kerül, egy ritkán frissülő aloldal viszont hetekig érintetlen maradhat.
Ebből az következik, hogy a forgalom nem leszakad, hanem lassan lecsorog. Az első héten alig látszik, a másodikon már gyanús, a negyediken pedig félreértelmezhető: szezonalitásra, algoritmusfrissítésre, hirdetési szünetre fogják. Saját tapasztalat: a legtöbb esetben, amivel dolgom volt, a felismerés a második vagy harmadik hónapban jött meg, jellemzően akkor, amikor valaki rákeresett a cégnévre, és nem találta a saját oldalát. Ha havonta ránézel a Search Console Oldalak jelentésére, akkor ez a hiba napok alatt kiderül, nem hónapok alatt.
Mennyi idő az újraindexelés a visszaállítás után?
Hivatalosan igazolt: a Google nem közöl konkrét határidőt az újraindexelésre, és nem vállal időbeli kötelezettséget. Az újrabejárás gyakorisága több tényezőtől függ, például az oldal frissítési ritmusától, a belső és külső hivatkozásoktól, valamint attól, mennyi erőforrást szán a Google az adott webhelyre.
Saját tapasztalat: a pipa levétele után a főoldal és a legerősebb aloldalak jellemzően napokon belül visszakerülnek, a teljes URL-készlet visszaállása viszont több hét, nagyobb oldalaknál akár hónapok kérdése. Ami ennél is lényegesebb: a rangsorbeli pozíciók visszatérése külön történet. Ha egy kulcskifejezésre hónapokig nem voltál elérhető, a versenytársak közben megörökölték a helyet, és a visszakapaszkodás nem automatikus. A gyors javítás segítheti a helyreállást, de önmagában nem jelent biztos visszatérést a korábbi pozíciókra. Ezt őszintén érdemes kommunikálni mindenkinek, aki érintett a döntésben.
A folyamatot gyorsíthatod, ha a javítás után beküldöd a webhelytérképet a Search Console-ban, a legfontosabb tíz-húsz URL-re kézzel kérsz indexelést az URL-ellenőrző eszközben (napi korlát van, ezért prioritási sorrendben haladj), és frissíted a belső hivatkozásokat a kulcsoldalakra. Bing és a rá épülő felületek felé az IndexNow protokoll ad gyorsabb jelzési lehetőséget.
Milyen ellenőrzőlista kell az élesítés napjára?
Ezt a hat pontot érdemes írásban rögzíteni, és minden élesítésnél végigmenni rajta, függetlenül attól, mennyire rutinos a csapat.
- Vedd le a pipát és mentsd el. Beállítások, Olvasás, majd a Keresőmotorok láthatósága soron a jelölés eltávolítása és a Változtatások mentése gomb. Utána töltsd újra az oldalt, és győződj meg róla, hogy a beállítás valóban mentésre került.
- Ellenőrizd a forráskódot négy különböző sablonon. Főoldal, szolgáltatásoldal, blogbejegyzés, kategóriaoldal. Mindegyiknél keresd a robots metacímkét, és nézd meg a HTTP fejlécben az X-Robots-Tag jelenlétét is.
- Kérd le az élő robots.txt fájlt. Ha
Disallow: /sort látsz, akkor vagy a WordPress beállítás nem mentődött, vagy fizikai robots.txt fájl van a gyökérben, amit kézzel kell javítani. - Nézd át a SEO bővítmény saját tiltásait. A globális kapcsolón kívül a bővítmények tartalomtípusonként, taxonómiánként és bejegyzésenként is tudnak noindexet állítani. Ellenőrizd a bejegyzés-szerkesztő oldalsávjában lévő láthatósági beállítást is a kulcsoldalakon.
- Üríts minden gyorsítótárat. Az oldalcache (WP Rocket, LiteSpeed, W3 Total Cache), a szerveroldali cache és a CDN (például Cloudflare) egyaránt kiszolgálhatja még a noindexes HTML-t azután is, hogy a beállítást javítottad. Ez a lépés hiányzik a leggyakrabban.
- Zárd le Search Console-lal, és tegyél naptárba visszaellenőrzést. Küldd be a webhelytérképet, futtass élő URL-tesztet a főoldalra, kérj indexelést a kulcsoldalakra, majd három, hét és tizennégy nap múlva nézd meg az Oldalak jelentésben, csökken-e a noindex miatt kizárt URL-ek száma.
Mit tegyek, ha kiderül, hogy hónapok óta noindex volt az oldal?
Az első és legfontosabb, hogy ne indíts pánikból nagy szerkezeti átalakítást. Láttam már olyat, hogy a felfedezés után egyszerre cserélték a témát, írták át az URL-szerkezetet és telepítettek új SEO bővítményt, aminek az lett a következménye, hogy utólag semmilyen adatból nem lehetett szétválasztani, mi okozta a további mozgásokat.
Helyette: javítsd a beállítást, ürítsd a cache-t, ellenőrizd a robots.txt fájlt, küldd be a webhelytérképet friss módosítási dátumokkal, és onnantól kezdve figyeld heti bontásban a Search Console Oldalak jelentését. Ha a noindex miatt kizárt URL-ek száma két-három hét alatt látványosan csökken, akkor a folyamat jó irányba tart. Ezzel párhuzamosan érdemes tartalmi frissítést tenni a legfontosabb oldalakra, mert a friss, érdemben megváltozott tartalom jó eséllyel gyorsítja az újrabejárást. Ez a lépés nem ad biztosítékot a korábbi pozíciók visszaszerzésére, de a helyreállás ütemét kedvezően befolyásolhatja.
Végül egy folyamatjavaslat: tedd az élesítési ellenőrzőlistát a projekt átadás-átvételi dokumentumába, és a felelős nevével együtt írd alá. Ez a hiba nem tudáshiányból ered, hanem abból, hogy senki nem érezte magáénak az utolsó kattintást.
Források és további olvasnivalók
- Google Search Central: Robots metacímkék, data-nosnippet és X-Robots-Tag specifikáció
- Google Search Central: Bevezetés a robots.txt fájlba, valamint a robots.txt specifikáció
- Google Search Console súgó: Oldalindexelés jelentés és URL-ellenőrző eszköz
- WordPress.org dokumentáció: Settings Reading Screen és a blog_public beállítás
- WordPress Developer Resources: wp_robots szűrő és a do_robots függvény
- WP-CLI kézikönyv: wp option parancs
- IndexNow protokoll hivatalos dokumentációja
- A kapcsoló nem kérés a keresőmotorok felé, hanem noindex metacímke minden oldalon, plusz Disallow: / a generált robots.txt fájlban.
- A leggyakoribb ok a staging másolat élesítése vagy a fejlesztői átadás, ahol senki nem vette le a pipát.
- Az ellenőrzés két parancs: forráskódban a robots metacímke, illetve a robots.txt tartalmának lekérése.
- A Search Console Oldalak jelentésében a Kizárva a noindex címke miatt sor a legmegbízhatóbb visszajelzés.
- A visszaállás után az újraindexelés napokban indul, de a teljes helyreállás hetekbe vagy hónapokba is telhet, és nem előre kiszámítható.
Gyakori kérdések
Ha levettem a pipát, miért látszik még mindig a noindex a forráskódban?
Szinte mindig gyorsítótár okozza. Az oldalcache bővítmény, a szerveroldali cache és a CDN külön-külön is kiszolgálhatja a régi HTML-t. Üríts minden szintet, majd ellenőrizd újra curl paranccsal, mert az a szervertől kapott friss választ mutatja.
A kapcsoló minden keresőre hat, vagy csak a Google-re?
A robots metacímke és a robots.txt is minden szabálykövető robotnak szól, tehát a Google, a Bing, a DuckDuckGo és az AI-asszisztensek bejárói egyaránt látják. Egyes robotok figyelmen kívül hagyhatják, de erre nem érdemes építeni.
Elég, ha csak a robots.txt fájlt javítom ki?
Nem. A WordPress kapcsoló két helyen hat egyszerre, és a noindex metacímke önmagában is elegendő ahhoz, hogy az oldalak kikerüljenek az indexből. Mindkettőt ellenőrizni kell, mert javíthatod az egyiket úgy is, hogy a másik változatlan marad.
Honnan tudom, hogy a forgalomesésem ettől van, vagy más okból?
A Search Console Oldalak jelentésében a noindex címke miatt kizárt URL-ek száma a legjobb jelzés. Ha ez a szám egy adott dátum után ugrik meg, és az időpont egybeesik egy élesítéssel vagy migrációval, akkor nagy valószínűséggel megtaláltad az okot.
Staging környezetben is le kell venni a tiltást?
Nem, ott indokolt bekapcsolva hagyni, sőt jelszavas védelem is javasolt. A hiba nem a staging beállításából ered, hanem abból, hogy az élesítés után senki nem állítja vissza a beállítást az éles környezetben.
Mennyi idő alatt jön vissza a korábbi forgalom?
Erre nincs kiszámítható válasz, és a Google sem közöl határidőt. A fő oldalak jellemzően napokon belül visszakerülnek az indexbe, a teljes visszaállás viszont hetekbe vagy hónapokba telhet, a pozíciók visszaszerzése pedig külön munkát igényel.
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.