Webshop-platformváltás SEO-teendői, hogy megmaradjon a forgalom

Scheo · 2026-10-20 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Webshop-platformot váltani (például WooCommerce-ről Shopify-ra, UNAS-ról Shoprenterre vagy egy egyedi rendszerről bármelyikre) jóval összetettebb, mint egy bemutatkozó oldalt költöztetni. Egy céges oldalnak pár tucat URL-je van, egy webshopnak könnyen több tízezer. Ezek nagy részét a szűrők, a lapozás és a termékváltozatok generálták, kézzel senki sem hozta létre őket, ezért a költözéskor is könnyű megfeledkezni róluk. Ez a cikk azokra a kérdésekre fókuszál, amelyek csak webshopnál jönnek elő.

Miben más egy webshop-migráció, mint egy általános weboldal-költöztetés?

Egy webshopnál az URL-ek többségét a rendszer generálja, a termékadatok külső rendszerekbe (Merchant Center, ár-összehasonlítók) is kifolynak, a bevételt pedig egy pontosan felépített mérés követi. Platformváltáskor mindhárom réteg egyszerre sérülhet, ezért itt nem elég a régi oldalakat egyesével átirányítani az újakra.

Egy bemutatkozó oldalnál a migráció lényegében tartalom- és URL-kérdés. Webshopnál ehhez négy terület társul.

• A termék-, kategória- és főleg a szűrő- és lapozó-URL-ek tömege, amelyek közül sok organikus forgalmat vagy külső linket kapott.
• A vásárlói vélemények, amelyek a termékoldal tartalmát és a csillagos találatokat adják.
• A termékazonosítók, amelyekre a Merchant Center, a Shopping-kampányok és az ár-összehasonlító oldalak teljesítménytörténete épül.
• A GA4 e-kereskedelmi eseményei, amelyek nélkül az átállás után nem tudod szétválasztani a valódi forgalomvesztést a mérési hibától.

Hivatalosan igazolt. A Google Search Central költözési útmutatója szerint ha a költözéssel az URL-ek is változnak, a régi URL-eket állandó (301-es) átirányítással kell az új megfelelőjükre irányítani, és az átirányításokat legalább egy évig érdemes fenntartani. A Search Console címváltoztatási eszköze csak domainváltásnál használható. Ha ugyanazon a domainen belül váltasz platformot, nincs rá szükség.

Honnan gyűjtsd össze a régi URL-eket az átirányítási térképhez?

A teljes régi URL-listát több forrásból kell összefésülni, mert egyik forrás sem mutat mindent. A feltérképező csak azt találja meg, amire link mutat, a szűrő-URL-ek viszont sokszor csak a keresési adatokban és a szervernaplóban látszanak.

1. Search Console teljesítményjelentés oldalanként, a leghosszabb elérhető időszakra (16 hónap) exportálva. Ebből látszik, mely URL-ek kaptak megjelenést és kattintást.
2. GA4 nyitóoldal-jelentés organikus szűréssel, a lekérdezési paraméterekkel együtt.
3. Teljes feltérképezés a régi oldalról (például Screaming Frog), a paraméteres URL-ek feltérképezését is engedve.
4. Szervernapló néhány hétre visszamenőleg. Itt látszanak azok a régi URL-ek, amelyeket a Googlebot rendszeresen lekér.
5. Visszamutató linkek egy linkelemző eszközből, céloldal szerint csoportosítva.
6. Régi XML-oldaltérképek és a termékfeed, mert ezekben a készleten kívüli termékek URL-jei is benne vannak.

Az összefésült listát forgalom és linkek szerint rangsorold. Nem minden URL-nek kell egyedi cél, de annak igen, amelyik az elmúlt egy évben kattintást kapott, vagy külső link mutat rá.

Hogyan építsd fel a termék- és kategória-URL-ek átirányítási térképét?

Az átirányítási térkép egy táblázat, amelyben minden régi URL mellett ott áll a tartalmilag legközelebbi új URL, a két rendszert pedig a termékazonosító (SKU, cikkszám) köti össze. Ha azonosító alapján párosítasz, a termékoldalak térképe nagyrészt gépiesen előállítható.

1. Exportáld a régi rendszerből a termékeket SKU-val és URL-lel, az újból ugyanígy.
2. Párosítsd a két listát SKU alapján. Táblázatkezelőben egy FKERES vagy XKERES függvény elég hozzá.
3. A párosítatlan sorokat kézzel nézd át. Ezek jellemzően a megszűnt termékek és az átnevezett változatok.
4. A kategóriákat kézzel párosítsd, mert a kategóriafa platformváltáskor gyakran átrendeződik.
5. A megszűnt terméket a legközelebbi utódtermékre vagy a szülőkategóriára irányítsd. Ha a főoldalra irányítod, azt a Google jó eséllyel soft 404-ként kezeli.

Egy térkép-részlet így néz ki (régi URL, új URL, státuszkód).

• /termek/feher-pamut-polo-123 ; /products/feher-pamut-polo ; 301
• /kategoria/noi-polok ; /collections/noi-polok ; 301
• /termek/kifutott-pulover-88 ; /collections/noi-puloverek ; 301

Saját tapasztalat. A változatok (méret, szín) URL-jeit sokan kifelejtik. Ha a régi rendszer minden változatnak saját URL-t adott, az újban viszont egyetlen termékoldal van változatválasztóval, akkor minden régi változat-URL-t a közös termékoldalra kell irányítani, lehetőleg olyan paraméterrel, amely előre kiválasztja az adott változatot.

Kerüld az átirányítási láncokat is. Ha egy korábbi költözésből már vannak átirányítások, azokat is közvetlenül az új célra állítsd át, így egy kérésre egyetlen ugrás jut.

Miért a régi szűrő- és lapozó-URL-eknél vész el a legtöbb forgalom?

Saját tapasztalat. A webshop-migrációknál a forgalomvesztés nagyobb része jellemzően a régi szűrő- és lapozó-URL-ek elhanyagolásából jön. A termék- és kategóriaoldalakat szinte mindenki átirányítja, a paraméteres URL-ek (például ?szin=piros&meret=m vagy ?page=3) viszont kimaradnak a térképből, így az élesítés napján egyszerre több száz vagy több ezer indexelt oldal ad 404-et.

Egy jól beállított szűrőkombináció (mondjuk piros női póló M-es méretben) gyakran hosszú, specifikus keresésekre rangsorol. Szakmai feltételezés. Ezek a keresések átlag fölött konvertálnak, mert a látogató már pontosan tudja, mit akar, ezért arányaiban több bevétel vész el velük, mint amennyit a puszta kattintásszám mutat.

Az alábbi szabályok szerint érdemes kezelni őket.

• Forgalmat hozó szűrő-URL. Ha az új rendszer tud indexelhető szűrőoldalt (saját URL-lel, címmel és leírással), irányítsd oda. Ha nem tud, a szűrő alapkategóriájára irányíts.
• Forgalom nélküli szűrő-URL. Egy csoportos szabállyal az alapkategóriára irányíts, a paraméterek eldobásával.
• Lapozó-URL. Ha az új rendszer is lapoz, a régi 3. oldal menjen az új 3. oldalra. Végtelen görgetésnél a kategória első oldalára irányíts.
• Rendezési és nézet-paraméter (ár szerint, rácsnézet). Ezek mehetnek az alap-URL-re.

Ha a régi tartományt egy saját Apache-szerver szolgálja ki, egy régi lapozó-szabály például így irányítható át. A QSD jelző eldobja a régi paramétereket.

RewriteCond %{QUERY_STRING} (^|&)page=([0-9]+)

RewriteRule ^kategoria/noi-polok$ /collections/noi-polok?page=%2 [R=301,L,QSD]

Szakmai feltételezés. A bérelt (SaaS) webshopok átirányítás-kezelője platformonként eltérően bánik a lekérdezési paraméterekkel. Van, ahol a paraméteres régi URL az útvonal alapján megtalálja a szabályt, és van, ahol 404-re fut. Ezt még a platform kiválasztása előtt teszteld néhány valódi régi URL-lel.

Hivatalosan igazolt. A Google külön útmutatóban foglalkozik a szűrős navigáció feltérképezésével, és jelezte, hogy a rel=next/prev jelölést már nem használja indexelési jelként. A költözés idején viszont a régi szűrő-URL-eket ne tiltsd le a robots.txt-ben, mert akkor a Googlebot nem látja az átirányításokat, és a régi URL-ek még sokáig benne maradhatnak az indexben.

Hogyan vidd át a véleményeket és értékeléseket?

A véleményeket SKU alapján érdemes átvinni, a dátummal, a csillagszámmal, a szöveggel és az ellenőrzött vásárló jelöléssel együtt. Ha a vélemények elvesznek, a termékoldal tartalma szegényebb lesz, és a csillagos megjelenés is eltűnhet a találati listáról.

1. Exportáld a véleményeket CSV-be vagy API-n át, termékazonosítóval együtt.
2. Az eredeti dátumot tartsd meg. Ha az importáláskor minden vélemény a mai dátumot kapja, az félrevezető a vásárló számára.
3. A szerző nevét adatvédelmi szempontból is nézd át. Elég a keresztnév vagy egy monogram.
4. Próbaimportot futtass néhány termékre, és ellenőrizd, hogy a csillagátlag egyezik-e a régi oldalon látottal.
5. A termékoldal strukturált adatában a látható véleményekre épülő aggregateRating szerepeljen.

A Product jelölés egy rövidített részlete így néz ki.

{"@type": "Product", "sku": "POLO-FEH-M", "aggregateRating": {"@type": "AggregateRating", "ratingValue": "4.7", "reviewCount": "38"}}

Hivatalosan igazolt. A Google irányelvei szerint a strukturált adatban jelölt értékelésnek az oldalon is láthatónak kell lennie. Az uniós fogyasztóvédelmi szabályok (2019/2161/EU irányelv) alapján pedig tájékoztatnod kell a vásárlót arról, hogy ellenőrzöd-e a vélemények valódiságát, és ha igen, hogyan. Ha a Merchant Centerben termékértékeléseket is használsz, a vélemény-feedben ugyanazokra az azonosítókra (GTIN, SKU) kell hivatkozni, mint a termékfeedben.

Miért ne változzanak a termékazonosítók a feed miatt?

A Merchant Center az id attribútum alapján követi a termékek teljesítménytörténetét. Ha platformváltáskor az azonosítók megváltoznak, a rendszer új termékként kezeli őket, és ez a Shopping- és Performance Max kampányok tanulási adatainak egy részét lenullázhatja.

Hivatalosan igazolt. A Merchant Center súgója szerint az azonosítónak termékenként egyedinek kell lennie, és ugyanannál a terméknél frissítéskor sem változhat. Szakmai feltételezés. A kampányteljesítményre gyakorolt hatás mértéke fiókonként eltér, az átállás utáni hetekben átmeneti visszaeséssel érdemes számolni.

A gond az, hogy egyes platformok saját, előtaggal képzett azonosítót generálnak (a Shopify Google-csatornája például országkódból és belső számokból rakja össze). Ilyenkor feedkezelő alkalmazással vagy egyedi feeddel állítsd vissza a régi azonosítót, jellemzően a régi SKU-t. Ugyanezt az azonosítót használd a dinamikus remarketingben, a GA4 item_id mezőjében és az ár-összehasonlító oldalak (például Árukereső) feedjében is. Ha mindenhol ugyanaz az azonosító, a hirdetési és mérési adatok egymással összevethetők maradnak. A GTIN, az MPN és a márka mezőt is változatlanul vidd át.

Hogyan építsd újra a GA4 e-kereskedelmi mérést?

Maradj a meglévő GA4-tulajdonnál, az új platformon építsd fel a Google által javasolt e-kereskedelmi eseményeket, és még az élesítés előtt próbavásárlással ellenőrizd őket a DebugView-ban. Új tulajdon nyitásával elveszítenéd az összehasonlítási alapot.

Az események közül a view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info és a purchase a legfontosabb. A vásárlási esemény váza így néz ki.

gtag('event', 'purchase', {transaction_id: 'R-10045', currency: 'HUF', value: 15980, items: [{item_id: 'POLO-FEH-M', item_name: 'Fehér pamut póló', item_variant: 'M', quantity: 2}]});

• Dupla mérés. Ha a platform beépített GA4-integrációja és a Tag Manager egyszerre küld adatot, minden vásárlás kétszer jelenik meg. Egy forrást hagyj meg.
• Fizetési szolgáltató. A fizetőoldal domainjét vedd fel az adatfolyam beállításaiban a nemkívánt hivatkozások listájára, különben a vásárlások egy része a fizetési szolgáltatóhoz kerül forrásként.
• Hozzájárulás. Ellenőrizd, hogy a sütisáv a Consent Mode jelzéseit az új platformon is helyesen küldi-e.
• Google Ads konverziók. A konverziócímkét és a bővített konverziókat is újra kell kötni.
• Jegyzet. Az élesítés napját jelöld meg a GA4-ben, hogy később a jelentésekben is látszódjon.

Saját tapasztalat. Az élesítés utáni első napokban a GA4 bevételét naponta vesd össze a webshop admin felületén látható rendelésekkel. Ha a kettő tartósan eltér, a mérést kell javítani, mielőtt bármilyen SEO-következtetést levonnál.

Mi legyen az ellenőrzőlistán az átállás előtt, napján és utána?

A lista három szakaszra bomlik. Az előkészítés során áll össze a térkép és a teszt, az élesítés napján élesednek az átirányítások és indul az ellenőrzés, az utána következő hetekben pedig a hibák javítása és az alapállapottal való összevetés jön.

Az átállás előtti hetekben

• Teljes régi URL-lista az összes forrásból, forgalom szerint rangsorolva.
• SKU-alapú átirányítási térkép, a szűrő- és lapozó-URL-ekre csoportos szabályokkal.
• Az átirányítások tesztelése a tesztkörnyezetben, listás feltérképezéssel.
• A címek, meta leírások, H1-ek és termékleírások átvitele.
• A vélemények próbaimportja és a csillagátlagok egyeztetése.
• A feed-azonosítók egyeztetése a régi feeddel.
• GA4-események próbavásárlással, DebugView-ban.
• Az alapállapot mentése (Search Console export, rangsorok, csatornánkénti bevétel).

Az átállás napján

• Az átirányítások élesítése az új oldallal egy időben.
• A tesztkörnyezet jelszavának és noindex jelölésének levétele, a robots.txt ellenőrzése.
• Az új XML-oldaltérkép beküldése a Search Console-ba.
• A forgalom szerinti első száz régi URL kézi ellenőrzése.
• Éles próbavásárlás, majd a GA4 valós idejű jelentésének ellenőrzése.
• A feed frissítése és a Merchant Center diagnosztikájának átnézése.

Az átállás utáni hetekben

• Az első két hétben naponta a Search Console Oldalak jelentése és a szervernapló 404-es sorai.
• A GA4 bevétel és a rendelési adatok napi összevetése.
• A belső linkek javítása, hogy közvetlenül az új URL-ekre mutassanak.
• A legfontosabb külső linkek frissíttetése a linkelő oldalaknál.
• Az organikus forgalom összevetése az alapállapottal, termék-, kategória- és szűrőoldalakra bontva.
• Az átirányítások megtartása legalább egy évig.

Mennyi idő alatt áll helyre a forgalom egy webshop-költöztetés után?

Erre nincs garantálható válasz. A Google szerint egy közepes méretű webhelynél az oldalak többségének átkerülése néhány hétig tarthat, nagyobb oldalaknál tovább. Szakmai feltételezés. Az első hetekben a rangsorok ingadozása szokásos, és egy gondosan előkészített átállás jó eséllyel kisebb és rövidebb visszaeséssel jár. Ha viszont a 404-es hibák száma hetek múlva is nő, az szinte mindig egy kimaradt URL-csoportra utal, és tapasztalatunk szerint ez leggyakrabban a szűrő- vagy lapozó-URL-ek köre.

Források és további olvasnivalók

• Google Search Central, Webhely áthelyezése URL-változással
• Google Search Central, Átirányítások és a Google Kereső
• Google Search Central, A szűrős navigációs URL-ek feltérképezésének kezelése
• Google Search Central, Product (termék) strukturált adat
• Google Merchant Center súgó, Azonosító (id) attribútum
• Google Analytics súgó, E-kereskedelmi események mérése
• Schema.org, Product, Review és AggregateRating típusok
• Az Európai Parlament és a Tanács (EU) 2019/2161 irányelve