Crawl trap: teljes útmutató

A crawl trap, magyarul feltérképezési csapda, olyan webhelyrész, ahol a keresőrobot szinte végtelen számú, egymástól alig különböző URL-t talál. Tipikus forrásai a végtelen naptárak, a szűrők és rendezések kombinációi, a munkamenet-azonosítók és a hibás relatív linkek. A csapda elviszi a robot figyelmét a fontos lapokról, ezért fel kell ismerni, le kell zárni, és rendszeresen mérni kell.

Alapfogalmak

A crawl trap nem egyetlen hiba, hanem egy jelenség neve. Akkor beszélünk róla, amikor egy webhely a belső linkjein keresztül korlátlanul sok új URL-t kínál fel a robotnak, és ezek az URL-ek nem hoznak új, értékes tartalmat. A robot minden új címet önálló lapnak tekint, amíg meg nem nézte, ezért követi őket. Egy jól felépített webhelyen a feltérképezhető URL-ek száma véges, és nagyjából megegyezik a valódi tartalmi lapok számával. Egy csapdát tartalmazó webhelyen ez a szám elméletben végtelen.

A jelenség szorosan összefügg a crawl budget fogalmával. A kereső minden webhelyre korlátozott erőforrást fordít: annyi kérést küld, amennyit a szerver elbír, és amennyit a webhely tartalma szerinte megér. Ha ennek a keretnek jelentős része értéktelen URL-ekre megy el, az új vagy frissített fontos lapok később kerülnek feltérképezésre. Kis webhelyen ez ritkán okoz látható gondot, nagy webáruházban vagy hírportálon viszont hetekkel késleltetheti egy új kategória megjelenését.

A leggyakoribb csapdatípusok

Típus	Hogyan keletkezik	Felismerés jele
Végtelen naptár	A naptárnézetben mindig van "következő hónap" link, évekre előre és hátra	Sok üres, dátumparaméteres URL a naplóban
Szűrőkombinációk	Minden szűrő minden másikkal kombinálható, és mindegyik saját URL-t kap	Hosszú, sok paraméteres URL-ek, azonos termékekkel
Rendezés és nézet	Ugyanaz a lista ár, név, népszerűség szerint, rács és lista nézetben	Azonos tartalom, eltérő paramétersorrend
Munkamenet-azonosító	A rendszer a session ID-t az URL-be írja	Minden látogatáskor új URL ugyanarra a lapra
Relatív link hiba	Egy rossz relatív link minden szinten új mappát fűz az útvonalhoz	Ismétlődő mappanevek egyre hosszabb útvonalban
Belső keresés	A keresési találati oldalak linkelve vannak, és tetszőleges kifejezésre új URL keletkezik	Kereső paraméteres URL-ek a feltérképezett lapok között

Kapcsolódó fogalmak

Feltérképezés (crawl): a robot letölti a lapot, és kigyűjti belőle a linkeket.
Indexelés: a kereső eldönti, hogy a letöltött lapot felveszi-e a találati adatbázisba. A csapda elsősorban a feltérképezést terheli, de gyakran indexelési zajt is okoz.
Duplikált tartalom: a csapdában keletkező URL-ek többnyire ugyanazt vagy majdnem ugyanazt mutatják.
URL-tér: az összes URL, amelyet a webhely a linkjein keresztül elérhetővé tesz. A csapda ezt a teret teszi korlátlanná.

Mi nem crawl trap

Nem minden sok URL-es webhelyrész csapda. Egy több tízezer termékes webáruház sok lapot tartalmaz, de ha mindegyik lap egyedi terméket vagy kategóriát mutat, akkor ez egyszerűen nagy webhely. A csapdát az különbözteti meg, hogy az URL-ek száma a tartalomtól függetlenül nő: újabb kattintással újabb cím keletkezik, de új információ nem.

Hogyan működik?

A robot működése egyszerű: letölt egy lapot, kigyűjti a benne lévő linkeket, és a még nem látott URL-eket sorba állítja. Ez a folyamat addig tart, amíg van új cím a sorban és van rá keret. A robot nem látja előre, hogy egy URL mögött érdemi tartalom van-e, ezt csak a letöltés után tudja megítélni. Egy csapda pontosan ezt a vakfoltot használja ki: minden letöltött lap újabb, még nem látott címeket kínál.

A végtelen naptár példája

Egy rendezvényoldal naptárnézetében minden hónapnál ott van az "előző" és a "következő" gomb, és mindkettő egy dátumparaméteres URL-re mutat. A robot a mostani hónapból átlép a következőbe, onnan a rákövetkezőbe, és így tovább. A rendszer minden hónapra kirajzol egy lapot, akkor is, ha abban a hónapban egyetlen esemény sincs. Évtizedekkel előre és hátra is lehet lépkedni, így a robot gyakorlatilag korlátlan számú, üres lapot talál. Mindegyik lap technikailag rendben van: sikeres választ ad, van címe, van tartalma, csak éppen értéktelen.

A kombinatorikus robbanás

A szűrőknél a probléma a kombinációkból fakad. Ha egy kategóriában több szűrőcsoport van, és mindegyikből több érték választható, a lehetséges kombinációk száma a csoportok és értékek szorzatával nő. Ehhez jön a paraméterek sorrendje: ha a rendszer a kiválasztás sorrendjében írja az URL-be a paramétereket, ugyanaz a szűrés több különböző címen is elérhető. Egy rendezési opció és egy lapozás tovább sokszorozza a számot. Ezt részletesen a faceted navigation útmutató tárgyalja.

A relatív link csapda példája

Egy blog sablonjában a lábléc "Kapcsolat" linkje egy perjel nélkül kezdődő, relatív útvonalra mutatott (kapcsolat/). A böngésző ezt mindig az aktuális útvonalhoz viszonyítva oldja fel. A főoldalon ez helyes címet adott, egy cikkoldalon viszont a cikk útvonala után fűzte a kapcsolat mappát. Mivel a szerver minden ismeretlen útvonalra a cikksablont adta vissza sikeres válasszal, a kapott lapon újra ott volt ugyanaz a hibás link, amely még egy kapcsolat mappát fűzött hozzá. A robot így egyre hosszabb, ismétlődő útvonalakat talált, mindegyik mögött ugyanazzal a tartalommal. A javítás két lépés volt: gyökérrel kezdődő link a sablonban, és valódi 404 válasz az ismeretlen útvonalakra.

Miért nem veszi észre magától a kereső?

A keresők valamennyire felismerik a mintákat, és egy idő után ritkábban térnek vissza az ismétlődő, értéktelen URL-ekre. Erre azonban nem érdemes építeni. A kereső csak a letöltések után tanul, vagyis a keret egy része mindenképpen elmegy. Ráadásul ha a csapda URL-jei belső linkeket is kapnak, a kereső azt látja, hogy maga a webhely tartja őket fontosnak. A tiszta jelzés mindig a webhely tulajdonosának feladata.

A csapda mellékhatása, hogy a belső linkek ereje is szétaprózódik. Ha a kategóriaoldal száz szűrőlinket és negyven terméklinket tartalmaz, a robot a szűrőlinkeket ugyanúgy követi, mint a termékeket. A feltérképezési sorban így a termékek helyett gyakran a szűrt változatok kerülnek előre.

Fő módszerek

A crawl trap kezelésének három rétege van: megszüntetni a forrását, lezárni a feltérképezést, és tisztázni az indexelési jeleket. A leghatékonyabb mindig az első, mert ami nem keletkezik, azt nem kell tiltani. A második és harmadik akkor jön, amikor a funkcióra a látogatóknak szükségük van, de a keresőnek nincs.

1. A forrás megszüntetése

Naptár: a lapozás álljon meg ott, ahol már nincs esemény, vagy korlátozd egy észszerű időablakra. Üres hónapra ne legyen link.
Munkamenet: a session azonosító sütiben legyen, ne az URL-ben.
Relatív linkek: a sablonokban használj gyökérrel kezdődő útvonalat (perjellel kezdődőt), így egy rossz szinten lévő link sem fűz újabb mappát az útvonalhoz.
Paramétersorrend: a rendszer mindig ugyanabban a rögzített sorrendben írja a paramétereket, így egy szűrés csak egy címen létezik.
Üres találat: ha egy kombináció nem ad eredményt, ne keletkezzen rá link.

2. A feltérképezés lezárása

Ha egy URL-mintára a keresőnek egyáltalán nincs szüksége, a robots.txt Disallow szabálya a legközvetlenebb eszköz. A Google és a Bing is támogatja a csillag helyettesítő karaktert és a dollárjeles sorvég-jelölést, így paraméterekre is lehet szabályt írni. Fontos korlát: a robots.txt csak a letöltést tiltja. Ha egy tiltott URL-re sok link mutat, a kereső a címet tartalom nélkül is felveheti az indexbe. A robots.txt tehát a feltérképezési keretet védi, az indexet nem tisztítja.

A linkek szintjén is lehet csökkenteni a csapda vonzását. Ha a szűrőket és rendezéseket nem hagyományos linkként, hanem űrlapként vagy gombként valósítod meg, amely nem hoz létre követhető href attribútumot, a robot nem találja meg őket a HTML-ben. A rel="nofollow" jelzés ehhez kevés: a Google tippként kezeli, nem kötelező utasításként.

3. Az indexelési jelek tisztázása

Azokra az URL-ekre, amelyeket a robot már ismer, és amelyeket nem akarsz a találatok között látni, a meta robots noindex vagy a canonical a megfelelő eszköz. Egy szabály itt kulcsfontosságú: a noindex csak akkor hat, ha a robot letöltheti a lapot. Ha ugyanazt az URL-t robots.txt-ben is tiltod, a noindexet soha nem fogja látni. Először tehát a noindex vagy canonical végezze el a dolgát, és csak utána, ha kell, jöhet a tiltás.

Döntési szabály

Helyzet	Ajánlott lépés
A funkcióra senkinek nincs szüksége	Szüntesd meg a forrást
A látogatónak kell, a keresőnek soha	Ne legyen követhető link, vagy robots.txt tiltás
Az URL már indexben van, és ki kell kerülnie	Előbb noindex, a kikerülés után mérlegeld a tiltást
Az URL egy fő lap változata	Canonical a fő lapra
Néhány kombinációnak saját keresési kereslete van	Ezeket emeld ki önálló, linkelt lappá, a többit zárd le

Workflow egy újonnan felfedezett csapdához

Azonosítsd az URL-mintát a naplóból vagy a crawlerből.
Keresd meg, melyik sablon vagy funkció termeli a linkeket.
Döntsd el, hogy a funkcióra a látogatónak szüksége van-e.
Ha nincs, szüntesd meg. Ha van, tedd a linkeket nem követhetővé, vagy rögzítsd a paraméterek rendjét.
A már indexelt URL-ekre tegyél noindexet vagy canonicalt, és várd meg a hatást.
Csak ezután írj robots.txt szabályt, és teszteld, hogy nem zár ki fontos lapot.
Néhány hét múlva mérd újra a naplóban a minta kérésszámát.

Gyakori hibák

A crawl trap kezelésénél a legtöbb hiba abból fakad, hogy valaki egy eszközt a másik helyett használ, vagy egyszerre kettőt, amelyek kioltják egymást. A második nagy hibacsoport az, amikor a csapdát csak tünetként kezelik, és a forrás tovább termeli az új URL-eket.

Tévhit: a nofollow megoldja

Sokan úgy gondolják, hogy ha a szűrőlinkekre rel="nofollow" kerül, a robot nem követi őket. A Google azonban ezt tippként értelmezi, és más forrásból, például külső linkről vagy sitemapból megismert URL-t így is feltérképezhet. Emellett a nofollow nem akadályozza meg, hogy a rendszer tovább gyártsa a címeket. A nofollow legfeljebb kiegészítő eszköz, önmagában nem zárja le a csapdát.

Ellenpélda: robots.txt és noindex egyszerre

Egy webáruház észrevette, hogy több ezer szűrt URL került az indexbe. A csapat egyszerre tett noindexet a lapokra és tiltotta őket robots.txt-ben. Az eredmény: az URL-ek hónapok múlva is az indexben voltak, mert a robot nem tölthette le őket, így a noindexet sem látta. A helyes sorrend az lett volna, hogy előbb a noindex dolgozik, és a tiltás csak akkor kerül be, amikor az URL-ek már kikerültek.

További tipikus hibák

A sitemapban is ott vannak a csapda URL-jei. Az XML sitemap csak kanonikus, indexelendő lapokat tartalmazzon.
Canonical, de linkek maradnak. A canonical nem csökkenti a feltérképezést, csak az indexelési döntést segíti. Ha a linkek maradnak, a robot továbbra is letölti a változatokat.
Túl széles tiltás. Egy elhamarkodott Disallow szabály kizárhat fontos kategóriákat is, ha az URL-mintájuk hasonló.
Csak az egyik csapdát zárják le. A naptárat kijavítják, de a belső keresés oldalai továbbra is linkelve vannak.
Relatív link hiba a 404 oldalon. Ha a hibaoldal sablonja relatív linkeket tartalmaz, és a szerver minden útvonalra sikeres választ ad, végtelen útvonal keletkezik. Ez rokon a soft 404 problémájával.

Egy további, ritkábban emlegetett hiba az átirányítási hurok. Ha két URL egymásra irányít, vagy egy paraméteres cím mindig újabb paraméterrel irányít tovább, a robot körbe jár. Ezt a redirect loop útmutató részletezi.

Mérés

A crawl trap ritkán látszik a webhely felületén, mert a látogató nem kattint végig ötven üres naptárhónapon. A robot viszont igen, ezért a mérésnek a robot szemszögéből kell történnie. Három forrás adja a legtöbb információt: a szervernaplók, a Search Console feltérképezési statisztikái és egy saját crawler futtatása.

Szervernapló-elemzés

A naplóban minden kérés szerepel, a keresőrobotoké is. Szűrd ki a keresőrobotok kéréseit, és csoportosítsd az URL-eket minta szerint: útvonal első két szintje, paraméternevek, paraméterek száma. Ha egy minta sok kérést kap, de kevés indexelt lapot ad, az erős jel. Érdemes azt is megnézni, hány egyedi URL tartozik egy mintához: egy naptármintánál ez a szám folyamatosan nő.

Search Console

A Search Console beállításai között elérhető feltérképezési statisztika mutatja a kérések számát, a válaszkódokat és a fájltípusokat. Az indexelési jelentés "Feltérképezve, jelenleg nincs indexelve" és "Felfedezve, jelenleg nincs indexelve" csoportjaiban gyakran látszanak a csapda URL-jei. Ha ezekben a csoportokban paraméteres vagy ismétlődő útvonalú URL-ek dominálnak, érdemes mintát keresni.

Saját crawler

Egy asztali vagy felhős crawler futtatásakor állíts be URL-limitet, és nézd meg, hol akad el. Ha a crawler nem áll le magától, vagy egy mappában aránytalanul sok URL-t talál, ott valószínűleg csapda van. A crawler azt is megmutatja, melyik lapról érkezik a csapdába vezető link.

Kidolgozott példa

Egy programajánló webhelyen a Search Console-ban a "Felfedezve, jelenleg nincs indexelve" csoport folyamatosan nőtt. A naplóelemzés szerint a robotkérések nagy része a naptár dátumparaméteres URL-jeire ment, sok évre előre. A csapat a naptárlapozást az eseményekkel rendelkező időszakra korlátozta, a régi és a távoli jövőbeli hónapokra nem generált linket, és a már ismert üres hónapokra noindex került. A következő hetekben a naptár URL-jeire eső kérések aránya csökkent, és az új eseménylapok gyorsabban jelentek meg a feltérképezett lapok között. A tanulság a módszer: a mintát naplóból azonosították, a forrást zárták le, és csak utána tisztították az indexet.

Ellenőrzőlista

Van-e olyan URL-minta, amelynek egyedi URL-száma folyamatosan nő?
Megáll-e egy saját crawler a beállított limit előtt?
Csak kanonikus lapok vannak-e a sitemapban?
A szűrők, rendezések, naptárlapozás követhető linkek-e?
Van-e olyan URL, amelyen noindex és robots.txt tiltás egyszerre van?
A belső keresés találati oldalai kapnak-e belső linket?
Vannak-e ismétlődő mappanevek a feltérképezett útvonalakban?

Kapcsolódó részletes útmutatók

X-Robots-Tag: teljes útmutató