Paraméteres URL-ek kordában tartása: nyomkövető kódok, rendezés és munkamenet-azonosítók

Scheo · 2026-08-22 · Frissítve: 2026-09-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Hogyan keletkeznek a végtelen URL-variánsok egy weboldalon?

Rövid válasz: minden paraméter, amit a szervered elfogad és nem dob el, önálló címként viselkedik a feltérképezők felé, és a paraméterek egymással szorzódnak, nem összeadódnak. Ettől lesz néhány ezer termékből több százezer bejárható URL.

Tovább a témában: Belső keresési találati oldalak kezelése · Canonical és duplikáció kezelése a gyakorlatban

A kérdőjel utáni rész számodra csak egy kapcsoló, a Googlebot vagy egy AI-crawler számára viszont új dokumentum: le kell tölteni, fel kell dolgozni, és el kell dönteni róla, hogy kell-e az indexbe. Érdemes típusonként szétszedni a forrásokat, mert a kezelésük is eltér.

• Nyomkövető paraméterek: utm_source, utm_medium, utm_campaign, gclid, fbclid, msclkid, hírlevél-rendszerek saját azonosítói. Tartalmi hatásuk nulla, a mennyiségük viszont gyakorlatilag korlátlan.
• Rendezés és nézetváltás: ?rendezes=ar_novekvo, ?sort=newest, ?nezet=lista, ?db=48. Ugyanaz a termékhalmaz, más sorrendben vagy más csempézésben.
• Szűrők, vagyis facet-navigáció: szín, méret, márka, ársáv. Ezek kombinálódnak egymással, és pont ezért ez a legveszélyesebb csoport.
• Munkamenet-azonosítók: PHPSESSID, jsessionid, sid. Régebbi rendszerek sajátja, és a legrosszabb fajta, mert minden egyes látogatásnál új URL születik ugyanarra a tartalomra.
• Belső keresőmező: ?s=, ?q=, ?kereses=. Végtelen bemenet, gyakran üres találati oldallal.
• Egyebek: nyomtatási nézet, affiliate ref, WordPress replytocom, naptár-lapozók, nyelvváltó kapcsolók.

Számold ki egyszer a szorzatot a saját oldaladra. Ha egy kategórialapon három rendezés, két nézet és négy oldalankénti elemszám választható, az önmagában huszonnégy variáns. Ha ehhez hozzájön öt gyakran használt kampányforrás UTM-mel, már százhúsz cím tartozik egyetlen kategóriához. Kétszáz kategóriánál ez huszonnégyezer URL, miközben tartalmilag kétszáz oldalad van. A szűrők bekapcsolása után ez a szám nem duplázódik, hanem nagyságrendet ugrik.

Miért baj ez, ha a kereső állítólag magától kezeli?

Rövid válasz: a keresők tényleg felismerik a duplikációt, de a felismerés ára a te feltérképezési kapacitásod, és ez az ár nálad jelentkezik, nem a keresőnél.

Hivatalosan igazolt: a Google 2022 tavaszán kivezette a Search Console URL-paraméter eszközét, azzal az indoklással, hogy a rendszer az esetek túlnyomó részében magától felismeri a felesleges paramétereket. Ugyanakkor a Search Central dokumentáció ma is külön fejezetben javasolja a paraméteres URL-ek számának csökkentését, a feltérképezési keret (crawl budget) leírása pedig kifejezetten nevesíti a facet-navigációt és a munkamenet-azonosítókat mint pazarló mintázatot. A két állítás nem mond ellent egymásnak: a kereső kezeli a helyzetet, csak nem ingyen.

Saját tapasztalat: elhanyagolt webáruházak naplófájljában rendszeresen azt látom, hogy a Googlebot kéréseinek nagyjából fele paraméteres címekre megy el, miközben az új termékoldalak lassan, hetes csúszással kerülnek be az indexbe. Amikor a paraméteres kérések aránya érdemben lecsökken, az új tartalom bejárása jellemzően felgyorsul. Ez nem törvényszerű minden oldalon, de elég következetes ahhoz, hogy első helyen nézzem meg.

A második kár kevésbé látványos, de tartósabb. Ha ugyanarra a tartalomra tíz cím mutat, akkor a külső hivatkozások, a belső linkek és a felhasználói jelek is szétszóródnak közöttük. Ilyenkor a kereső dolga eldönteni, melyik változat az igazi, és nem mindig azt választja, amelyiket te szeretnéd. A harmadik kár a saját méréseidben csapódik le: a jelentéseidben ugyanaz az oldal öt sorban szerepel, és a valós teljesítménye elmosódik.

Mi a különbség a canonical, a robots.txt tiltás és a noindex között?

Rövid válasz: a canonical azt mondja meg, melyik változat számítson eredetinek, a noindex azt, hogy egy már letöltött oldal ne kerüljön be az indexbe, a robots.txt pedig azt, hogy a robot le se töltse. Három különböző beavatkozási pont, és nem helyettesítik egymást.

• Canonical (rel=canonical): jelzés, nem parancs. A kereső figyelembe veszi, de felül is bírálhatja. Az oldal feltérképezhető marad, tehát kérést továbbra is fogyaszt, viszont a jelek egy címre konszolidálódnak. Akkor jó, ha a variáns tartalma lényegében azonos az eredetivel.
• Noindex (meta robots vagy X-Robots-Tag fejléc): ez már utasítás, a keresők betartják. Az oldal kikerül az indexből, de a robot letölti, és a rajta lévő linkeket egy ideig követi. Akkor válaszd, ha az oldal nem való a találatok közé, de a rajta átvezető útvonalra szükség van.
• Robots.txt tiltás (Disallow): a feltérképezést akadályozza meg, nem az indexelést. Ez a leghatékonyabb eszköz a kapacitás védelmére, viszont a legdurvább is, mert a tiltott oldalról a kereső semmit nem tud meg.

A leggyakoribb ütközés, amit érdemes elkerülni

Ha egy URL-t robots.txt-ben letiltasz, és ugyanarra az oldalra noindex vagy canonical is kikerül, akkor a noindex és a canonical soha nem fog érvényesülni. A robot ugyanis nem tölti le az oldalt, tehát nem is látja a benne lévő utasítást. Ráadásul a tiltott cím bekerülhet a találatok közé, ha máshonnan hivatkoznak rá: ilyenkor jelenik meg a leírás nélküli, csupasz URL-es találat. Hivatalosan igazolt: ezt a viselkedést a Google Search Central dokumentációja is külön kiemeli a robots.txt és a noindex leírásában.

A sorrend tehát: ha azt akarod, hogy egy oldal biztosan kikerüljön az indexből, előbb engedd feltérképezni és tedd rá a noindexet, és csak akkor tiltsd le robots.txt-ben, amikor már eltűnt a találatok közül, és a további bejárás felesleges.

Melyik paramétertípusnál melyik eszközt válaszd?

Rövid válasz: ami önálló keresési igényt szolgál ki, azt hagyd indexelni (lehetőleg tiszta, paraméter nélküli címen); ami ugyanazt a tartalmat mutatja más csomagolásban, azt canonicallal kezeld; ami végtelen kombinációt termel, azt zárd ki a feltérképezésből.

1. Hagyd indexelni: az olyan szűrt nézetet, amelyre valódi keresési kereslet van, és amelyhez egyedi tartalmat is tudsz adni (saját cím, saját bevezető, saját belső link). Példa: futócipő márka szerinti listája. Itt viszont a helyes lépés az, hogy statikus, beszédes URL-t készítesz neki, és nem paraméteren hagyod.
2. Canonicallal kezeld: a rendezést és a nézetváltást (?rendezes=, ?nezet=, ?db=), a nyomkövető paramétereket (utm_*, gclid, fbclid), az affiliate azonosítókat és a munkamenet-paramétereket, ha technikai okból nem tudod őket megszüntetni. Ezeknél a canonical mindig a paraméter nélküli, tiszta változatra mutasson.
3. Zárd ki a feltérképezésből: a belső keresőt, a naptár-lapozókat, a kosár- és összehasonlító nézeteket, valamint a kettőnél több szűrő kombinációját. Egy tipikus robots.txt részlet: Disallow: /*?s=, Disallow: /*?kereses=, Disallow: /kosar, Disallow: /*?osszehasonlitas=.
4. Noindexet tegyél rá: a nyomtatási nézetre, a köszönőoldalakra, a szűrők olyan mélyebb szintjeire, amelyek még hasznos belső linkeket adnak tovább, de nem valók a találatok közé.
5. Átirányítással (301) intézd el: a régi, elhagyott paramétereket és az egykori munkamenet-azonosítós címeket, ha még mindig érkezik rájuk forgalom.

Az egyértelműség kedvéért: ha egy paramétert canonicallal kezelsz, akkor ne tiltsd le robots.txt-ben. A kettő együtt nem erősíti, hanem kioltja egymást.

Hogyan tárod fel öt lépésben a saját paraméter-káoszodat?

Rövid válasz: a teljes képhez négy adatforrás kell (Search Console, találati lista, naplófájl, saját feltérképezés), az ötödik lépés pedig a döntési tábla, amiben paramétertípusonként rögzíted, mi lesz a sorsuk.

1. Search Console, Oldalak jelentés. Nyisd meg az indexelési riportot, és nézd meg külön a Duplikált, a Google más kanonikus oldalt választott, a Duplikált, a felhasználó nem jelölt meg kanonikus oldalt és a Feltérképezve, jelenleg nincs indexelve kategóriát. Exportáld a listát, és rendezd a kérdőjel utáni rész szerint. Itt derül ki, mely paraméterek jutottak el egyáltalán a keresőig.
2. Találati lista ellenőrzése. A site:domain.hu inurl:utm_, site:domain.hu inurl:sort és site:domain.hu inurl:PHPSESSID típusú lekérdezésekkel gyorsan látod, mi került be ténylegesen az indexbe. A találatszám csak becslés, de a mintázat beszédes: ha az első oldalon paraméteres címek sorakoznak, ott már a felhasználó is furcsa URL-t kap.
3. Naplófájl elemzése. Kérd el a tárhelyszolgáltatótól legalább két hét hozzáférési naplóját, szűrj a Googlebot, a Bingbot és az AI-crawlerek user agentjeire, majd számold ki, a kérések hány százaléka ment kérdőjeles címre. Ez az egyetlen forrás, ami megmutatja, hol égeti el a robot a kapacitást. Ha egyetlen számot akarsz nézni: a paraméteres kérések aránya az összes bot-kéréshez képest.
4. Saját feltérképezés. Futtass végig egy feltérképező szoftvert (Screaming Frog, Sitebulb vagy hasonló) a paraméterek megtartásával, majd ugyanazt paraméter-eldobással. A két futás közti különbség pontosan az a felesleg, amit a robot is bejár. Nézd meg a duplikált címeket, a canonical hivatkozásokat, és azt is, hogy a belső linkjeidben szerepel-e nyomkövető paraméter.
5. Döntési tábla és mérés. Készíts egy táblázatot, amiben minden paraméternév mellett ott áll: mit csinál, hány URL tartozik hozzá, mi lesz a kezelés (indexelhető, canonical, noindex, tiltás, átirányítás) és ki felelős a beállításért. Ezt add oda a fejlesztőnek, és négy-hat hét múlva ismételd meg a naplóelemzést. Ha a paraméteres kérések aránya csökken, a beavatkozás dolgozik.

Miért olcsóbb megelőzni, mint utólag kitakarítani?

Saját nézőpont: egy nyomkövető paramétert kiszedni a linkből néhány perc munka, ugyanezt a paramétert utólag kitakarítani az indexből hónapokig tartó, türelemjátékos folyamat. A kereső ugyanis nem felejt gyorsan: a már megismert címeket még jóval a canonical bevezetése után is visszalátogatja, és a jelentéseidben is ott maradnak.

A megelőzés néhány konkrét szabályból áll. A belső linkjeidbe soha ne kerüljön UTM: a kampánycímkézés a külső csatornák dolga, a saját oldaladon belüli mozgást a webanalitikád amúgy is látja. A munkamenet-azonosítót sütiben tárold, ne az URL-ben; ez ma már minden modern keretrendszerben alapértelmezés, a régi rendszereknél viszont külön be kell állítani. A szűrőknél döntsd el előre, hány szint indexelhető, és a többit vagy kereszthivatkozás nélküli felületre tedd, vagy zárd ki. A paraméterek sorrendjét és írásmódját normalizáld: a ?szin=piros&meret=42 és a ?meret=42&szin=piros a kereső számára két külön cím, ezért a szerver mindig ugyanabban a sorrendben adja vissza őket, üres értéknél pedig hagyja el a paramétert.

Egy dolgot érdemes tisztázni: mindez a technikai higiénia jó eséllyel segítheti az új tartalom gyorsabb bejárását és a jelek összefogását, de önmagában nem hoz jobb pozíciót. Nem a rangsorolást javítja, hanem elveszi az akadályt a jó tartalom elől. Ha az alap tartalmi minőség nincs meg, a tiszta URL-struktúra sem old meg semmit.

Mit jelent mindez az AI-válaszmotorok szempontjából?

Szakmai feltételezés: az AI-alapú válaszmotorok és az őket tápláló feltérképezők jellemzően kisebb merítéssel dolgoznak egy-egy oldalról, mint a hagyományos keresők, ezért náluk a felesleges variánsok aránya még többet árthat. Ha a robot ideje háromnegyed részben rendezési variánsokra megy el, kisebb az esélye, hogy a valóban idézhető, érdemi oldalaidat is feldolgozza. Ez logikus következtetés a megfigyelt bot-viselkedésből, de nyilvános, mérhető dokumentáció nem támasztja alá.

Hivatalosan igazolt: az OpenAI, az Anthropic és a Perplexity is közzéteszi a saját feltérképezőinek user agent nevét és a robots.txt kezelésére vonatkozó szabályait, tehát ugyanazokkal az eszközökkel tudod őket irányítani, mint a Googlebotot. Ha kizársz egy útvonalat, az náluk is érvényes, feltéve, hogy a robot betartja a szabályokat.

A gyakorlati következtetés egyszerű: minél inkább egyetlen, stabil, beszédes cím tartozik egy tartalomhoz, annál könnyebb azt idézni és hivatkozni. Egy válaszmotor forrásmegjelölésében sokkal jobban mutat egy tiszta kategórialap, mint ugyanaz az oldal hat paraméterrel megpakolva.

Milyen ellenőrzőlistával zárd le a munkát?

• Minden paraméteres változat canonicalja a tiszta, paraméter nélküli címre mutat, és a tiszta cím önmagára kanonikus.
• Nincs olyan URL, amin egyszerre van robots.txt tiltás és noindex vagy canonical.
• A belső linkekben és a webhelytérképben nincs nyomkövető paraméter, és a webhelytérkép csak indexelhető címeket tartalmaz.
• A munkamenet-azonosító sütiben van, nem az URL-ben.
• A belső keresőoldal ki van zárva a feltérképezésből.
• A paraméterek sorrendje és kis-nagybetűs írásmódja normalizált, az üres paramétert a szerver eldobja.
• A naplófájlban a paraméteres bot-kérések arányát rögzítetted a beavatkozás előtt, hogy legyen mihez mérni.
• A döntési tábla dokumentálva van, hogy fél év múlva egy új fejlesztő is értse, miért mit tiltottál le.

Források és további olvasnivalók

• Google Search Central: Feltérképezési keret kezelése nagy webhelyeknél
• Google Search Central: A robots.txt bevezetése és korlátai
• Google Search Central: A noindex szabály és az X-Robots-Tag használata
• Google Search Central: Kanonikus URL-ek megadása és a duplikált tartalom kezelése
• Google Search Central Blog: Az URL-paraméter eszköz kivezetése
• Google Search Console súgó: Oldalak indexelése jelentés
• Bing Webmaster Guidelines: URL-struktúra és feltérképezés
• OpenAI dokumentáció: GPTBot és a feltérképezők robots.txt kezelése
• Anthropic súgó: ClaudeBot és a webhely-hozzáférés szabályozása
• W3C, RFC 3986: Uniform Resource Identifier (URI) általános szintaxis
• Schema.org: url és mainEntityOfPage tulajdonságok