- Alapértelmezésben egy termékoldal legyen, a szín és a méret jól jelölt változatként rajta.
- Külön URL-t akkor adj a változatnak, ha önálló keresési igény, saját tartalom és saját készlet is tartozik hozzá.
- A canonical a Google számára jelzés, nem parancs, ezért a belső linkelésnek és a sitemapnak ugyanazt kell mondania.
- A Merchant Center feedben minden változat külön sor, közös item_group_id-vel, saját GTIN-nel és készlettel.
- Az AI-asszisztensek a látható, szöveges változatlistát tudják idézni, a csak JavaScriptből előhúzott adatot jó eséllyel nem.
Egy pólót hét színben és öt méretben árulsz. Ez harmincöt variáció. A kérdés minden webshop-átalakításnál előkerül: legyen ebből egyetlen termékoldal jól jelölt választókkal, vagy legyen belőle hét (esetleg harmincöt) külön URL, amit a kereső külön-külön indexel? A döntés nem ízlés kérdése, hanem azon múlik, hogy a változatra van-e önálló keresési igény, van-e saját tartalma, és van-e saját üzleti élete a raktárban. Ez a cikk végigviszi a döntést, és megmutatja, mi történik közben a canonicallal, a Merchant Center feeddel és az URL-szerkezettel.
Egy URL vagy külön oldalak: mi a helyes alapértelmezés?
A helyes alapértelmezés az egy termékoldal, amelyen a szín és a méret jól jelölt, választható változatként jelenik meg, és a szétszedés csak markáns keresési igény esetén éri meg. (Saját tapasztalat.)
Az indok egyszerű: a linkek, a megosztások, a vásárlói vélemények és a viselkedési jelzések egyetlen oldalon gyűlnek össze, nem oszlanak szét harmincöt gyenge oldalra. Egy magyar kkv-webshopnál a hosszú farok amúgy sem a színnél kezdődik. A tipikus keresés a férfi pamut póló vagy a fekete férfi póló, nem a férfi pamut póló fekete XL 180 grammos. Ha harmincöt oldalra vágod szét ugyanazt a terméket, harmincöt majdnem üres, majdnem azonos oldalt kapsz, amiből a kereső egyet választ ki magának, a többit pedig jó eséllyel nem indexeli.
A fordítottja is igaz. Ha a színnek önálló piaca van (például festéknél, fonalnál, parkettánál, gumiabroncsnál a méret gyakorlatilag maga a termék), akkor az egyoldalas megoldás elfojtja azt a keresletet, amiért fizetnél a hirdetésben.
Mit néz valójában a kereső egy változatos terméknél?
Azt nézi, hogy az adott URL tartalma önmagában elég egyedi és elég értékes-e ahhoz, hogy külön találatként megérje megjeleníteni.
(Hivatalosan igazolt:) a Google Search Central dokumentációja szerint a lényegében azonos tartalmú URL-eket a kereső csoportosítja, és a csoportból egyetlen megjelenítendő URL-t választ. A választásba beleszámít a canonical jelzés, de nem csak az: a belső linkelés, a sitemap tartalma, az átirányítások és a hreflang is befolyásolja. Ez a magyarázata annak, hogy hiába állítasz be canonicalt, a Search Console mégis másik URL-t jelöl meg kiválasztottként.
Gyakorlati következmény: ha külön oldalt csinálsz a fekete és a fehér változatnak, akkor tényleg különbözzenek. Más címsor, más termékfotó, más bevezető, más gyakori kérdés, más belső link. Ha csak a szín szó cserélődik három helyen, akkor a különálló oldal nem hoz többet, viszont hoz karbantartási terhet és kannibalizációt.
Hogyan dolgozza fel az AI-asszisztens a színt és a méretet?
Az AI-asszisztensek azt tudják idézni, ami az oldalon szövegesen, renderelt állapotban ott van. (Szakmai feltételezés, de következetesen ezt látjuk a mérésekben.)
Amikor egy asszisztenstől azt kérdezi valaki, hogy "hol kapok fekete pamut pólót 3XL-ben", akkor a modellnek konkrét, szöveges tényre van szüksége: milyen színek és milyen méretek érhetők el, és melyik van készleten. Ha ez az információ csak akkor jelenik meg, amikor a látogató rákattint a színválasztóra, és egy JavaScript-hívás tölti be, akkor sok crawler számára ez a tartalom egyszerűen nincs ott.
Ezért az egyoldalas megoldásnak van egy kemény feltétele: a változatlistának a kiinduló HTML-ben, szövegesen is szerepelnie kell. Egy sor is elég, például "Elérhető színek: fekete, fehér, sötétkék, bordó. Elérhető méretek: S, M, L, XL, XXL, 3XL." Ez az a fajta mondat, amit egy válaszmotor ki tud emelni, és amit egy hagyományos kereső is összeköt a felhasználó szűkítő szándékával.
Hogyan állítsd be a canonicalt, hogy ne fusson félre?
A canonical annak a szabálynak a leképezése, amit már eldöntöttél: ha egy oldalad van, minden változat-URL a fő termékoldalra mutat, ha külön oldalaid vannak, mindegyik saját magára.
Egyoldalas modellnél a paraméteres változatok (?szin=fekete, ?meret=xl) mind ezt kapják:
<link rel="canonical" href="https://pelda.hu/ferfi-pamut-polo" />
Több hibát látunk itt, mint bárhol máshol a webshop-technikában:
- A canonical relatív útvonalat kap, vagy protokoll nélküli címet. Mindig teljes, abszolút URL legyen.
- A paraméteres URL canonicalja saját magára mutat, mert a sablon dinamikusan generálja a jelenlegi címet. Ez pont az ellenkezőjét éri el a szándéknak.
- A változat-URL-ek benne vannak a sitemapban, miközben canonicaljuk máshova mutat. Ez ellentmondó jelzés.
- A változat-URL-eket robots.txt-ben tiltják le. Ha a kereső nem töltheti le az oldalt, a rajta lévő canonicalt sem látja, tehát épp az összevonást akadályozod meg. (Hivatalosan igazolt: a Search Central kifejezetten óv attól, hogy a duplikációt robots.txt-vel kezeld.)
Külön indexelhető változatoknál a canonical önmagára mutat, a fő kategórialap vagy a szülő termékoldal pedig linkeljen mindegyikre. (Hivatalosan igazolt:) a Search Console URL-paraméter eszköze 2022 óta nem elérhető, tehát nincs olyan felület, ahol utólag elmagyarázhatnád a Google-nek a paramétereidet. A szerkezetnek magától kell érthetőnek lennie.
Mi történik a Merchant Center feedben?
A feed logikája független a weboldalétól: ott minden változat mindenképpen külön sor, akkor is, ha a webshopban egyetlen oldalról vásárolják meg.
(Hivatalosan igazolt, a Merchant Center termékadat-specifikáció alapján:) a változatokat az item_group_id attribútum köti össze. Minden változat kap saját id-t, saját availability és price értéket, és megkapja a megkülönböztető attribútumokat: color, size, material, pattern, size_type, age_group, gender. Ha a gyártó minden változathoz külön GTIN-t adott ki, akkor minden sorba a saját GTIN kerül, nem a szülőtermék kódja.
A gyakorlati buktató itt a link mező. Egyoldalas modellnél minden változat sorába érdemes a változatra ugrató URL-t tenni (https://pelda.hu/ferfi-pamut-polo?szin=fekete&meret=xl), hogy a hirdetésre kattintó vásárló a helyes állapotban lássa a terméket. Ez nem mond ellent a canonicalnak: a feed a hirdetés célját írja le, a canonical az indexelést. A két rendszer külön beszél.
Amit mérni érdemes: ha a feedben egyetlen szülőterméket adsz fel változatok nélkül, elbukod a méret- és színszűrésre épülő megjelenéseket, és a visszaküldési arány is romolhat, mert a vásárló nem azt kapja, amit a hirdetésben látott. (Saját tapasztalat.)
Milyen URL-szerkezet bírja el a későbbi bővítést?
Olyan, amelyben a fő termékoldal címe stabil, a változat pedig utólag is felvehető anélkül, hogy a régi URL megszűnne.
Három működő minta:
- Paraméteres változat egyoldalas modellhez:
/ferfi-pamut-polo?szin=fekete&meret=xl. Egyszerű, a canonical rendet tesz, a paraméterek sorrendje legyen mindig ugyanaz. - Beszédes útvonal külön indexelt színnél:
/ferfi-pamut-polo-fekete. Akkor válaszd, ha a színnek önálló keresési igénye van, és tényleg saját tartalmat adsz mellé. - Kettős szint, ahol a méret nem indexelt:
/ferfi-pamut-polo-fekete?meret=xl. Ruházatnál ez a leggyakoribb helyes válasz, mert a színre keresnek, a méretre nem.
Amit kerülj: kereszthivatkozás nélküli, azonosítóra épülő URL (/p/48213-2), több paraméter ugyanarra a dologra (?szin= és ?color= egyszerre), és a szűrőparaméterek összekeverése a változatparaméterekkel. A szűrő listát változtat, a változat terméket. Ne ugyanaz a mechanizmus kezelje őket.
Hogyan dönts el egy konkrét terméket?
Három kérdés, ebben a sorrendben. Ha mindháromra igen a válasz, adj külön indexelhető URL-t. Ha bármelyikre nem, maradj az egy oldalnál.
- Van-e önálló keresés a változatra? Nézd meg a Search Console lekérdezéseit és a kulcsszókutatást. Ha a "fekete" jelző havi szinten mérhető keresési mennyiséget hoz a termékkategóriádban, az igen. Ha csak elméletileg logikus, az nem.
- Eltér-e érdemben a kép és a leírás? Ha a változathoz saját fotósorozat, saját anyagleírás vagy saját használati kontextus tartozik, az igen. Ha ugyanaz a szöveg egy kicserélt szóval, az nem.
- Van-e külön készlet és külön üzleti élete? Ha a változat önállóan fut ki, önállóan árazódik, önállóan akciózható, az igen. Ha a raktárkészlet közös és a döntés a kosárban dől el, az nem.
Van egy negyedik, csendes szempont is: ki fogja karbantartani? Egy kétfős kkv-nál a hetven külön termékoldal reális kockázata nem az SEO, hanem az, hogy fél év múlva harminc oldalon elavult ár és hiányzó kép lesz. (Saját tapasztalat.)
Milyen strukturált adat írja le pontosan a változatokat?
Egyoldalas modellnél a ProductGroup a megfelelő típus, amely a hasVariant mezőben sorolja fel a konkrét Product elemeket. (Hivatalosan igazolt: a Schema.org szókészlet és a Google termék-strukturáltadat dokumentációja is tartalmazza.)
Vázlatosan így néz ki a lényeg:
{"@type": "ProductGroup", "productGroupID": "POLO-001", "variesBy": ["https://schema.org/color", "https://schema.org/size"], "hasVariant": [{"@type": "Product", "sku": "POLO-001-FEKETE-XL", "color": "fekete", "size": "XL", "offers": {"@type": "Offer", "availability": "https://schema.org/InStock"}}]}
A variesBy mondja meg, mely tulajdonságok mentén tér el a változat. Ha ezt kihagyod, a kereső csak találgat. Külön indexelt oldalaknál minden oldalra sima Product jelölés kerül a saját sku, gtin és offers adataival, és érdemes az isVariantOf mezővel visszamutatni a csoportra.
Mit ellenőrizz a bevezetés után?
- A fő termékoldal kiinduló HTML-je szövegesen tartalmazza az elérhető színeket és méreteket, JavaScript futtatása nélkül is.
- Minden változat-URL canonicalja abszolút és a szándékolt célra mutat (ellenőrizd forráskódban, ne csak a bővítmény beállításában).
- A sitemap csak azokat az URL-eket tartalmazza, amelyeket indexelni akarsz.
- A robots.txt nem tiltja le a változat-URL-eket, ha canonicallal akarod összevonni őket.
- A feedben minden változat külön sor, közös
item_group_id-vel, saját GTIN-nel, saját készlettel és árral. - A feed
linkmezője a helyes változatra visz, és az oldal valóban abban az állapotban töltődik be. - A
ProductGroupvagyProductjelölés hibamentesen átmegy a Rich Results Test és a Search Console jelentésén. - A kifutott változat URL-je nem 404-re esik, hanem az elérhető változatra irányít át, vagy megmarad tájékoztató oldalként.
- Négy héttel a bevezetés után a Search Console-ban megnézed: az új URL-ek indexelődtek-e, és nem esett-e vissza a fő termékoldal megjelenése.
- Az AI-forgalmat külön csatornaként követed a GA4-ben, hogy lásd, hoz-e egyáltalán látogatót az asszisztensekből érkező hivatkozás.
A mérésnél legyél óvatos az ok-okozattal. A változatkezelés átállítása ritkán önmagában mozgatja a számokat, és a szerkezeti változás után jellemzően hetekig tart, mire a kereső újraértékeli az oldalakat. Semmilyen beállítás nem garantál helyezést vagy forgalmat, de a következetes szerkezet jó eséllyel csökkenti a felesleges kannibalizációt.
Milyen hibák fordulnak elő a leggyakrabban?
A leggyakoribb az, amikor a webshop mindkét modellt egyszerre futtatja: van egy egyoldalas termék változóválasztóval, és emellett a rendszer generál külön termékoldalakat is minden színre, mert a régi importban így volt. Ilyenkor ugyanaz a termék kétszer szerepel, egymás ellen. A második leggyakoribb a méret indexelése. Ruházatnál a méretre gyakorlatilag nincs önálló keresési igény, viszont a szorzás miatt ez viszi el az indexelési keretet. A harmadik a kifutott változat kezelése: a boltok kiveszik az oldalt, 404 lesz belőle, és a felépített link egyszerűen elvész, ahelyett hogy az elérhető változatra vinne. (Saját tapasztalat, mindhárom ismétlődő minta magyar kkv-webshopoknál.)
Források és további olvasnivalók
- Google Search Central: Consolidate duplicate URLs (canonicalizálás)
- Google Search Central: Product structured data dokumentáció (Product, ProductGroup, Offer)
- Google Merchant Center Súgó: Termékadat-specifikáció (item_group_id, color, size, gtin)
- Schema.org szókészlet: ProductGroup, hasVariant, isVariantOf, variesBy
- Google Search Console Súgó: Oldalindexelés jelentés és az URL-ellenőrző eszköz
- W3C: HTML Living Standard, a link elem és a rel attribútum értékei
- OpenAI dokumentáció: a böngésző- és keresőfunkciók működése
Gyakori kérdések
Ha egy termékoldalt használok, elveszítem a színre érkező keresési forgalmat?
Nem szükségszerűen. Ha az elérhető színek szövegesen szerepelnek az oldalon, a címben vagy a leírásban is megjelenik a domináns szín, és a kategórialapon van szűrhető, indexelhető szín szerinti lista, akkor a keresési igény nagy részét le tudod fedni külön termékoldalak nélkül.
Indexeltessem külön a méreteket?
Ruházatnál és lábbelinél jellemzően nem éri meg, mert a méretre önálló keresési igény alig van, viszont a variációk szorzata elviszi az indexelési keretet. Ott indokolt, ahol a méret maga a termék, például gumiabroncsnál, parkettánál vagy szerelvényeknél.
Mi legyen a canonical a paraméteres változat-URL-en?
Egyoldalas modellnél a fő termékoldal abszolút URL-je. Ellenőrizd a forráskódban, mert sok webshop-sablon dinamikusan az aktuális címet írja be, ami pont az összevonás ellen dolgozik. Ne robots.txt-vel tiltsd le a változat-URL-eket, mert akkor a canonicalt sem látja a kereső.
Külön feedsort kell adnom minden színnek és méretnek?
Igen. A Merchant Center termékadat-specifikációja szerint minden megvásárolható változat külön ajánlat, közös item_group_id-vel összekötve, saját azonosítóval, GTIN-nel, árral és készlettel. Ez akkor is így van, ha a webshopban egyetlen oldalról vásárolják meg.
Mi történjen a kifutott színnel vagy mérettel?
Ne törölj 404-re. Ha a változat végleg megszűnt, irányítsd át a fő termékoldalra vagy a legközelebbi elérhető változatra. Ha csak átmenetileg fogyott el, tartsd meg az oldalt, jelöld OutOfStock státusszal, és ajánld mellé az elérhető alternatívát.
Honnan tudom, hogy megérte-e a szétszedés?
Négy-nyolc héttel a bevezetés után nézd meg a Search Console-ban, hogy az új URL-ek indexelődtek-e, kapnak-e önálló megjelenést és kattintást, és nem esett-e vissza közben a fő termékoldal. Ha az új oldalak nem kapnak saját lekérdezéseket, a szétszedés csak karbantartási terhet hozott.
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.