A legtöbb komolyabb SEO-probléma nem hibás kulcsszóstratégiából születik, hanem abból, hogy valami olyan került nyilvánosságra, aminek nem kellett volna. A fejlesztői vagy tesztkörnyezet indexelése pontosan ilyen: hónapokig észrevétlen marad, aztán egyszer csak a dev.pelda.hu előzi meg a pelda.hu-t egy fontos keresésre, vagy ami rosszabb, egy ügyfél megtalálja a saját, még nem kész árlistáját a Google találatai között.
Ez a cikk azt járja körbe, hogyan derül ki egy ilyen szivárgás, mekkora kár származhat belőle, és milyen sorrendben érdemes felszámolni. A végén találsz egy ellenőrzőlistát, amit új fejlesztési környezet indításakor érdemes végigmenni.
Hogyan derül ki, hogy a staging aldomain bekerült a Google-be?
A leggyorsabb ellenőrzés egy site: keresés az aldomainre: ha a Google bármit visszaad, az az oldal indexelve van. Ez egyetlen keresősávba beírt parancs, mégis a legtöbb weboldal-tulajdonos soha nem futtatja le.
Tovább a témában: Aldomain vagy alkönyvtár? Blog, webshop és nyelvi verziók elhelyezése · Belső keresési találati oldalak kezelése
A tipikus aldomain-neveket érdemes végigpróbálni, mert a fejlesztők nagyjából ugyanabból a néhány szóból válogatnak:
site:dev.pelda.husite:staging.pelda.husite:teszt.pelda.huéssite:test.pelda.husite:uj.pelda.hu,site:new.pelda.hu,site:beta.pelda.husite:pelda.hu -inurl:www(ez kiszűri a fő hosztot, és megmutatja a többi aldomaint)
Ha ismered a fejlesztő szokásait, próbáld a dátumos vagy verziószámos változatokat is: v2.pelda.hu, 2025.pelda.hu. Az ügynökségek gyakran saját domainen tárolják az ügyfélprojekteket, ilyenkor a site:ugynokseg.hu pelda típusú keresés is találhat.
(Hivatalosan igazolt: a Google Search Central dokumentációja szerint a site: operátor közelítő, nem teljes körű listát ad, tehát a nulla találat nem jelent biztos tisztaságot. Saját tapasztalat: a gyakorlatban mégis ez fogja meg az esetek nagy részét, mert egy indexelt tesztkörnyezet ritkán rejtőzik el egyetlen URL-ben, általában több tucat oldal kerül be egyszerre.)
A Search Console tulajdon felvétele az aldomainre
A site: keresés csak azt mutatja meg, mi látszik kívülről. A pontos képhez fel kell venni az aldomaint önálló tulajdonként a Google Search Console-ban. Két út van:
- Domain szintű tulajdon (DNS TXT rekorddal igazolva): ez egyszerre lefedi az összes aldomaint és protokollt. Ha van hozzáférésed a DNS-hez, ezt válaszd, mert innentől semmilyen aldomain nem tud észrevétlenül elindulni.
- URL-előtag tulajdon az adott aldomainre (
https://dev.pelda.hu/): gyorsabb, ha csak egyetlen környezetet vizsgálsz, de aldomainenként külön kell felvenni.
A felvétel után az Oldalak (korábban Lefedettség) jelentés megmutatja, hány URL van ténylegesen indexelve, és hány van kizárva, illetve milyen okból. Ez az egyetlen hely, ahol a Google saját nyilvántartását látod, nem pedig a találati lista töredékét. Fontos: friss tulajdonnál az adatok néhány nap késéssel töltődnek fel, tehát az azonnali üres jelentés még nem bizonyíték.
Visszakövetés a belső linkekből
A harmadik nyom a belső hivatkozás. Egy tesztkörnyezet ritkán indexelődik magától: valahonnan link mutat rá. A leggyakoribb források:
- A migráció után az éles oldalon maradt abszolút URL-ek (képek, PDF-ek, űrlapok action attribútuma) még a staging hosztra mutatnak.
- A sitemap.xml véletlenül a staging címeket tartalmazza, mert az adatbázis-másolat után nem futott le a domain-csere.
- Egy projektdokumentum, Trello-kártya vagy nyilvános GitHub README, ami tartalmazza a teszt URL-t.
- Külső eszközök (sebességteszt, screenshot-szolgáltatás, hírlevélküldő kattintásfigyelője), amelyek nyilvános naplót vezetnek.
A visszakövetéshez futtass egy crawlt az éles oldalra, és szűrj a külső hivatkozásokra: minden olyan cél, ami a saját domain másik aldomainjére mutat, gyanús. Parancssorból is gyorsan látszik, ha van hozzáférésed a fájlokhoz:
grep -rIn "dev\.pelda\.hu\|staging\.pelda\.hu" /var/www/eles/ | head -50
Az adatbázisban is érdemes keresni, mert a WordPress-tartalom gyakran tárol abszolút URL-eket a bejegyzések törzsében és a beállításokban.
Miért baj, ha a fejlesztői környezet indexelődik?
Három szinten okoz kárt: duplikált tartalom, kulcsszó-kannibalizáció, és a legrosszabb esetben olyan adatok kiszivárgása, amelyeknek soha nem lett volna szabad nyilvánosságra kerülniük.
Duplikált tartalom. A staging jellemzően az éles oldal majdnem pontos másolata. A Google ilyenkor eldönti, melyik változatot tekinti a kanonikusnak, és ez a döntés nem mindig a te érdeked szerint alakul. (Hivatalosan igazolt: a Search Central kifejezetten leírja, hogy duplikált tartalom esetén a rendszer egyetlen URL-t választ reprezentánsnak, és a többit összevonja alá. Szakmai feltételezés: a választás szempontjai között szerepelhet a hivatkozási profil és a kanonikus jelzés, de a pontos súlyozás nem nyilvános, ezért nem lehet előre megjósolni, melyik hoszt nyer.)
Kannibalizáció. Ha mindkét változat indexben van, ugyanarra a keresésre versenyeznek. Előfordul, hogy a tesztváltozat jelenik meg, ami rendszerint régebbi, félkész, néha teljesen hibás tartalmat mutat. A látogató ilyenkor nem talál működő űrlapot, rossz telefonszámot lát, vagy a kosár nem működik. A mérésben ez úgy jelenik meg, hogy a forgalom megvan, a konverzió viszont eltűnik.
Adatkiszivárgás. Ez a legsúlyosabb. A tesztkörnyezet gyakran tartalmaz olyat, ami az élesen nincs: még nem publikált árazást, belső jegyzetekkel teli aloldalt, ügyfélnevekkel feltöltött referencialistát, vagy egy éles adatbázis-másolatot valódi rendelési adatokkal. Ha a keresőrobot bejut, ezek is indexelhetők. Saját tapasztalat: a leggyakoribb konkrét eset, amivel találkoztam, a tesztkörnyezetbe másolt éles rendelésállomány, ahol a rendelés-visszaigazoló oldal azonosító alapján, bejelentkezés nélkül hívható volt. Ilyenkor már nem SEO-ügyről beszélünk, hanem adatvédelmi incidensről, amit a hazai szabályozás szerint dokumentálni és bizonyos esetekben bejelenteni kell.
Van egy negyedik, kevésbé látványos következmény is: a crawl-költségvetés. A robot időt és erőforrást fordít egy olyan hosztra, aminek semmi haszna. Nagy oldalaknál ez érzékelhető, egy néhány száz oldalas céges honlapnál viszont a gyakorlatban elhanyagolható, ezért nem érdemes emiatt pánikolni.
Milyen sorrendben kell kitakarítani egy indexelt tesztkörnyezetet?
A helyes sorrend: először zárd le a hozzáférést jelszóval vagy 403-mal, ezután kérd az eltávolítást a Search Console-ban, és csak a végén foglalkozz a hivatkozásokkal és a robots.txt-tel. A fordított sorrend a leggyakoribb hiba, és pont az a lépés akadályozza meg a takarítást, amivel a legtöbben kezdik.
1. lépés: HTTP-alapszintű jelszóvédés vagy 403
Az Apache-on ez két fájl. A .htpasswd előállítása:
htpasswd -c /etc/apache2/.htpasswd fejleszto
Majd a staging gyökerében lévő .htaccess-be:
AuthType Basic
AuthName "Zart fejlesztoi kornyezet"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Nginx alatt a szerverblokkban:
auth_basic "Zart fejlesztoi kornyezet";
auth_basic_user_file /etc/nginx/.htpasswd;
Ettől kezdve minden kérés 401-es választ kap, tartalom nélkül. Ha valamiért a jelszóablak zavaró (például automatizált tesztek futnak a környezeten), a másik megoldás az IP-alapú engedélyezés, ahol minden más kérés 403-at kap. Mindkettő ugyanazt éri el a keresőrobot szempontjából: nem jut hozzá a tartalomhoz.
Fontos részlet: a lezárás előtt győződj meg róla, hogy az eltávolítási kérelem beadásához szükséges Search Console-tulajdont már igazoltad, mert a HTML-fájlos igazolás egy jelszóval védett hoszton nem fog működni. DNS-alapú igazolással ez a probléma nem áll fenn.
2. lépés: noindex, ha a lezárás nem lehetséges
Ha valamilyen kényszerből nyilvánosnak kell maradnia a környezetnek (például külső partner tesztel rajta), akkor minden oldalnak noindex fejlécet vagy meta taget kell kapnia. Szerveroldalon a HTTP-fejléc a biztosabb, mert a nem HTML-típusú fájlokra (PDF, kép) is érvényes:
Header set X-Robots-Tag "noindex, nofollow"
HTML-ben a <head> szakaszba kerülő meta name="robots" content="noindex" ugyanezt teszi, de csak a HTML-oldalakra. (Hivatalosan igazolt: a Google dokumentációja szerint a noindex csak akkor érvényesül, ha a robot le tudja tölteni az oldalt, tehát a robots.txt nem tilthatja le ugyanazt az URL-t.)
3. lépés: eltávolítási kérelem a Search Console-ban
A tulajdonon belül az Eltávolítások menüpontban lehet ideiglenes elrejtést kérni. Prefix opcióval egyszerre az egész hoszt eltüntethető a találatokból. (Hivatalosan igazolt: ez az eszköz nagyjából hat hónapig rejti el az URL-eket, nem törli őket véglegesen az indexből.) Ezért önmagában soha nem elég: a hat hónap alatt kell elérni, hogy a Google a lezárt vagy noindex jelzésű állapotot lássa, és magától kivezesse az oldalakat.
Ha az aldomain teljes egészében megszűnik, a legtisztább megoldás, ha a DNS-rekordot törlöd, vagy a hoszt minden kérésre 410-es választ ad. A 410 (Gone) egyértelműbb jelzés a 404-nél, és saját tapasztalatom szerint a kivezetés valamivel gyorsabban zajlik le vele, bár ezt hivatalos forrás nem számszerűsíti.
4. lépés: a bemenő hivatkozások megszüntetése
Amíg link mutat a staging hosztra, a robot időről időre visszatér. Cseréld le az éles oldalon maradt abszolút URL-eket, javítsd a sitemapet, és kérd meg a fejlesztőt, hogy a nyilvános dokumentációkból vegye ki a teszt címeket. WordPressnél a keresés-csere művelet szerializált mezőket is érint, ezért erre való eszközt használj, ne nyers SQL-t.
Miért nem elég a robots.txt-tiltás, ha az oldalak már bent vannak?
Mert a robots.txt a letöltést tiltja, nem az indexelést, és egy már indexelt URL-nél épp azt akadályozza meg, hogy a Google meglássa a noindex jelzést. Ez a takarítás legfélreértettebb pontja.
A logika a következő. Ha a Disallow: / szabály él, a robot nem tölti le az oldalt. Ha nem tölti le, nem látja sem a meta robots taget, sem az X-Robots-Tag fejlécet, sem azt, hogy az oldal időközben 404-et vagy 410-et ad. Az index bejegyzése így befagy: az URL bent marad, jellemzően cím és leírás nélkül, olyan sorral, hogy az oldal tartalma nem érhető el. (Hivatalosan igazolt: a Google Search Central kifejezetten figyelmeztet arra, hogy a robots.txt-vel blokkolt URL-ek külső hivatkozások alapján továbbra is megjelenhetnek a találatokban, és hogy a noindex nem működik letiltott URL-en.)
A gyakorlati következtetés: a robots.txt jó eszköz megelőzésre, ha a hoszt még soha nem volt indexelve, de rossz eszköz kármentesítésre. Ha már bent vannak az oldalak, a robots.txt-tiltást fel kell oldani ahhoz, hogy a lezárás vagy a noindex jelzés eljuthasson a robothoz. A 401-es és 403-as válasz ebből a szempontból jobb, mert azt a robot letöltési kísérlet közben látja, tehát a jelzés megérkezik.
Van egy másik gyakori tévhit is: hogy a robots.txt-ben felsorolt tiltott útvonalak titkosak. Nem azok. A fájl bárki számára letölthető, és a benne szereplő könyvtárnevek gyakorlatilag útmutatót adnak arról, hol keresse valaki az érdekes tartalmat. Ezért soha ne írj bele érzékeny elérési utakat.
Miért a jelszóvédés az egyetlen megbízható megoldás?
Mert minden más eljárás azt feltételezi, hogy a másik fél betartja a kérésünket, a jelszó viszont nem kér, hanem megakadályoz. Ez a saját, határozott szakmai álláspontom, és a mögötte lévő érvelés egyszerű.
A robots.txt egy udvarias kérés. A noindex szintén: azt kéri a keresőtől, hogy ne jelenítse meg a tartalmat, amit egyébként letöltött és feldolgozott. A nagy keresők ezeket tiszteletben tartják, de a nyílt weben mozgó szereplők köre már rég nem merül ki a Google-ben és a Bingben. Tartalomgyűjtő szolgáltatások, archiváló rendszerek, adatgyűjtő botok és az AI-modellek tanítására dolgozó crawlerek egy része nem, vagy csak részben követi ezeket a jelzéseket, és a viselkedésük nem ellenőrizhető kívülről.
A jelszóvédés ezzel szemben nem jelzés, hanem korlát. A tartalom el sem hagyja a szervert. Nem kell bíznod semmilyen külső fél jóindulatában, és nem kell attól tartanod, hogy egy új, ismeretlen crawler más szabályok szerint működik. Ugyanez igaz az adatvédelmi oldalára is: egy 401-es válasz mögötti ügyféladat nem szivárog ki akkor sem, ha valaki véletlenül megosztja a linket.
Szakmai feltételezés: ahogy egyre több AI-rendszer gyűjt tartalmat a webről, a jelzés-alapú védelem értéke tovább csökken. Ez nem bizonyítható előre, de a kockázat aszimmetrikus: a jelszóvédés beállítása körülbelül tíz perc, a kiszivárgott adatok visszaszerzése viszont lehetetlen. Ezért érdemes alapból a szigorúbb megoldást választani, és a többit csak kiegészítésnek tekinteni.
Ez természetesen nem jelenti azt, hogy a noindex vagy az eltávolítási kérelem felesleges. Egy már megtörtént indexelésnél mindkettőre szükség van a helyreállításhoz. Csak arról van szó, hogy hosszú távon egyik sem helyettesíti a lezárást, legfeljebb késlelteti a következő bajt.
Mit tartalmazzon egy új fejlesztési környezet indítási ellenőrzőlistája?
A lényeg, hogy a védelem az első tartalom feltöltése ELŐTT legyen a helyén, mert utólag már csak kármentesítés van. Az alábbi lista végigmenve nagyjából negyedóra, és a leggyakoribb hibákat kizárja.
- HTTP-alapszintű jelszóvédés a teljes hoszton, még az első oldal feltöltése előtt. Ellenőrizd egy privát böngészőablakból, hogy tényleg kér-e jelszót.
- Kimenő e-mail letiltása vagy elfogása. A tesztkörnyezetből kiküldött rendelés-visszaigazoló és hírlevél valódi ügyfeleket ér el. Használj fejlesztői levélfogó eszközt, vagy irányítsd át az összes kimenő levelet egy belső címre.
- Fizetési és külső integrációk sandbox módban. Az éles API-kulcs a tesztkörnyezetben valódi tranzakciót és valódi adatot mozgat.
- Analitika és mérőkódok kikapcsolása. A staging forgalma torzítja az éles adatokat, és hamis konverziókat generál.
- Éles ügyféladatok anonimizálása. Ha adatbázis-másolattal dolgozol, cseréld le a neveket, e-mail-címeket és telefonszámokat. Ez adatvédelmi szempontból nem opció, hanem elvárás.
- X-Robots-Tag noindex fejléc a teljes hoszton, második védelmi vonalként arra az esetre, ha a jelszóvédés valamiért kikerülne.
- A hoszt felvétele Search Console domain-tulajdonként DNS-igazolással, hogy ha mégis indexelődik valami, arról értesülj.
- Naptári emlékeztető a lezárásra. Az élesítés után a tesztkörnyezet vagy szűnjön meg, vagy kapjon gazdát, aki felel érte. A gazdátlan staging az, amelyik két év múlva bajt okoz.
- Írásos átadás a projekt végén: melyik aldomain marad, melyik szűnik meg, ki fér hozzá. Ha a fejlesztő elérhetetlenné válik, ez a dokumentum lesz az egyetlen kapaszkodó.
Érdemes ezt a listát egyszer kitölteni sablonként, és minden új projektnél átfutni rajta. A tapasztalatom szerint nem a tudás hiányzik ezekhez a lépésekhez, hanem az, hogy senki nem érzi a magáénak a feladatot: a fejlesztő azt hiszi, a marketinges figyeli, a marketinges azt hiszi, a fejlesztő beállította.
Mikor érdemes szakértőt bevonni?
Ha a kiszivárgott tartalom személyes adatot vagy üzleti titkot érint, ott már nem SEO-feladatról van szó. A technikai takarítás mellett ilyenkor fel kell mérni, mi került ki, mennyi ideig volt elérhető, és van-e bejelentési kötelezettség. Ehhez érdemes adatvédelmi kérdésekben jártas szakemberrel egyeztetni.
A tisztán SEO-jellegű esetekben, ahol csak duplikált tartalom keletkezett, a fenti lépések önállóan is elvégezhetők. Az eredmény nem azonnali: az index frissülése hetekben mérhető, és a helyreállás mértéke sem garantálható előre. Ami biztosan segítheti a folyamatot, az a következetesség: ha a Google minden visszatéréskor ugyanazt a lezárt vagy noindex állapotot látja, jó eséllyel viszonylag gyorsan kivezeti az érintett URL-eket.
A gyakorlati tanulság röviden: a fejlesztői környezet nem a weboldal melléktermeke, hanem a rendszer része, és ugyanolyan gondosságot kíván, mint az éles oldal. Aki ezt egyszer végigcsinálja, másodszor már nem felejti el a jelszót feltenni.
Források és további olvasnivalók
- Google Search Central: Robots.txt bevezető és útmutató
- Google Search Central: Az indexelés szabályozása (noindex, X-Robots-Tag)
- Google Search Central: Duplikált tartalom kezelése és kanonikus URL-ek
- Google Search Central: Az eltávolítási eszköz és a SafeSearch jelentések súgója
- Google Search Console súgó: Tulajdon hozzáadása és igazolása
- Robots Exclusion Protocol (RFC 9309, IETF)
- MDN Web Docs: HTTP hitelesítés (401, 403 státuszkódok)
- Apache HTTP Server dokumentáció: mod_authn_core és mod_headers
- Nginx dokumentáció: ngx_http_auth_basic_module
- Nemzeti Adatvédelmi és Információszabadság Hatóság: adatvédelmi incidensek bejelentése
- Egy site: keresés az aldomainre 30 másodperc alatt megmutatja, indexelődött-e a fejlesztői környezet.
- A robots.txt-tiltás megakadályozza az újralátogatást, de a már indexelt URL-eket nem távolítja el, sőt megnehezíti a noindex észlelését.
- A helyes sorrend: előbb jelszóvédés vagy 403, utána Search Console eltávolítási kérelem, végül a belső hivatkozások kitakarítása.
- Saját tapasztalatom szerint a jelszóvédés az egyetlen tartósan működő védelem, minden más csak késleltetés.
- Új fejlesztői környezetet ne indíts el addig, amíg a jelszóvédés és a levélküldés-blokkolás nincs beállítva.
Gyakori kérdések
Honnan tudom biztosan, hogy a tesztoldalam nincs a Google-ben?
Teljes bizonyosságot csak a Search Console ad: vedd fel az aldomaint önálló tulajdonként (legjobb a DNS-igazolású domain-tulajdon), és nézd meg az Oldalak jelentésben, hány URL van indexelve. A site: keresés gyors előszűrés, de közelítő listát ad, ezért a nulla találat nem bizonyíték.
Elég, ha beírom a robots.txt-be, hogy Disallow: /?
Megelőzésre igen, kármentesítésre nem. Ha az oldalak már indexelve vannak, a tiltás megakadályozza, hogy a Google letöltse őket, és így a noindex jelzést vagy a 404-es választ sem látja. Ilyenkor az URL-ek bent ragadnak az indexben, cím és leírás nélkül.
Mennyi idő alatt tűnik el az indexből egy lezárt tesztkörnyezet?
Ez oldalanként és URL-enként eltérő, jellemzően hetekben mérhető, mert a Google a saját újralátogatási ütemezése szerint fedezi fel az új állapotot. A Search Console eltávolítási kérelme azonnal elrejti a találatokból, de csak nagyjából fél évig, ezért a mögöttes technikai lezárásra mindenképp szükség van.
A jelszóvédés nem akadályozza a Search Console tulajdon igazolását?
A HTML-fájlos és HTML-tages igazolást igen, mert a Google nem éri el a fájlt. Ezért érdemes DNS TXT rekorddal, domain szintű tulajdonként igazolni, ami a jelszóvédéstől függetlenül működik, és egyszerre lefedi az összes aldomaint.
Mi a teendő, ha valódi ügyféladat került ki a staging oldalon keresztül?
Először zárd le a hozzáférést, majd mérd fel, pontosan mi volt elérhető és mennyi ideig. A gyorsítótárazott változatok eltávolítását is kérni kell. Ez a pont már túlmutat a SEO-n: adatvédelmi incidensként kell kezelni, és érdemes ilyen kérdésekben jártas szakértővel egyeztetni a bejelentési kötelezettségről.
Aldomain vagy alkönyvtár legyen a fejlesztői környezet?
Fejlesztésre az aldomain a tisztább, mert szerverszinten egyben lezárható, és nem keveredik az éles oldal útvonalaival. Egy alkönyvtárba tett tesztváltozat ugyanazon a hoszton él, ezért nehezebb elkülöníteni, és sokkal könnyebben szivárog be az éles oldal belső linkhálózatába és sitemapjébe.
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.