Elfogyott vagy kivezetett termék oldalának kezelése webshopban

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

Mit jelent valójában, hogy egy termék „elfogyott”?

Rövid válasz: ugyanaz a szó két teljesen különböző helyzetet takar, és a kettő más technikai kezelést kíván. Átmeneti készlethiánynál a termék létezik, csak most nincs raktáron. Kifutásnál a termék megszűnt, és soha többé nem lesz belőle.

A webshopok jelentős része ezt a két esetet ugyanabba a dobozba teszi: a termék eltűnik a listákból, az oldal 404-et ad, vagy csendben átirányít a kategóriára. (Saját tapasztalat.) Ez az egyik legdrágább technikai hiba, amit egy webshopban el lehet követni, mert pont azokat az oldalakat dobja el, amelyek évek alatt gyűjtöttek be hivatkozásokat, értékeléseket, keresési előzményt, kérdés-válasz tartalmat és márkanév-alapú keresési forgalmat.

Egy termékoldal nem csak eladási felület, hanem tudásforrás is. A cikkszám, a méretadatok, a kompatibilitási lista, a vásárlói kérdések és a szerviz-információk akkor is értéket adnak, amikor a termék éppen (vagy végleg) nem rendelhető. A döntésed tehát nem az, hogy „megtartom vagy törlöm”, hanem az, hogy milyen állapotban tartom életben az oldalt, és mit ajánlok helyette.

Mikor tartsd meg az oldalt, és mikor nyúlj átirányításhoz?

Rövid válasz: tartsd meg az oldalt mindaddig, amíg az érkező látogató kérdésére a legjobb választ ez az oldal adja. Átirányíts csak akkor, ha van egy konkrét, azonosítható utódtermék, ami valóban ugyanazt a feladatot látja el.

A gyakorlatban négy tiszta eset van:

• Átmeneti készlethiány (várható visszaérkezés): az oldal marad, HTTP 200-as válasszal. Jelenjen meg rajta a várható visszaérkezés dátuma (ha van), egy „értesíts, ha újra kapható” űrlap, és 2-4 valóban hasonló alternatíva. Az értesítéskérés a legerősebb eszközöd: e-mail címet gyűjt, tehát a látogató nem vész el.
• Kifutott termék, van valódi utód: ilyenkor van értelme a 301-es átirányításnak az utódtermék oldalára. Feltétel, hogy az utód tényleg helyettesítő legyen (ugyanaz a funkció, kompatibilitás, méret). Ha az utód csak „hasonló kategóriájú”, ne irányíts át.
• Kifutott termék, nincs egy az egyben utód, de van releváns választék: az oldal maradjon, 200-as válasszal, egyértelmű „ez a termék kifutott” jelöléssel, megtartott műszaki adatokkal és 3-6 kézzel (vagy szabály alapján) kiválasztott alternatívával.
• Szezonális, visszatérő termék: soha ne töröld. Egy karácsonyi vagy nyári cikk oldala 10-11 hónapig „halott”, aztán újra keresetté válik. A törlés minden évben újraindítja az oldal előéletét.

(Hivatalosan igazolt: a Google Search Central dokumentációja szerint a 301-es átirányítás akkor a helyes megoldás, ha a tartalom új helyre költözött. Szakmai feltételezés: abból, hogy a Google következetesen a „releváns cél” elvét hangsúlyozza, arra következtetek, hogy a nem releváns célra mutató átirányítást előbb-utóbb soft 404-ként kezeli, azaz gyakorlatilag figyelmen kívül hagyja.)

Mikor helyes a 410-es válasz, és mikor árt?

Rövid válasz: a 410 (Gone) akkor a jó választás, ha tudod, hogy a termék végleg megszűnt, nincs értelmes utódja, és az oldalnak nincs önálló információs értéke sem.

A 404 és a 410 között a különbség szándék kérdése. A 404 annyit mond: „nem találom”. A 410 azt: „létezett, én szüntettem meg, ne gyere vissza”. (Hivatalosan igazolt: a HTTP szemantikáját leíró RFC pontosan így definiálja a kettőt, és a Google is megerősítette, hogy a 410-es oldalakat valamivel gyorsabban ejti ki az indexből, mint a 404-eseket.)

Mikor add ki:

• véglegesen megszűnt cikkszám, amit soha nem gyártanak újra, és nincs kompatibilis utód;
• hibásan felvitt, duplikált vagy teszt-termékoldal;
• jogi vagy megfelelőségi okból kivont termék, ahol nem szeretnéd, hogy az oldal tovább éljen.

Mikor ne add ki: ha az oldalra külső hivatkozások mutatnak, ha márkanévre vagy cikkszámra rendszeresen keresik, ha vásárlói kérdések és válaszok vannak rajta, vagy ha bizonytalan vagy a végleges kivezetésben. Ezekben az esetekben a megtartott, alternatívát ajánló oldal többet hoz. (Saját tapasztalat: a 410 legnagyobb kockázata nem az indexelés, hanem az, hogy a régi vásárló, aki a szervizhez keresi a termék adatlapját, üres falba ütközik és rossz élménnyel távozik.)

Hogyan kösd össze a készletkezelő rendszert a webshoppal?

Rövid válasz: a készletkezelő legyen az egyetlen igazságforrás, a webshop pedig automatikusan vezesse le belőle a termék státuszát, és minden státuszváltás indítson el egy előre definiált műveletsort.

A folyamat vázlata:

ERP / készletkezelő -> szinkron (API vagy ütemezett feed) -> webshop termékstátusz -> státusz-szabály -> oldal-viselkedés + feed + sitemap

1. Adatforrás. A készletkezelőben legyen két külön mező: keszlet_darab (szám) és eletciklus (aktív / átmenetileg elfogyott / kifutó / kifutott). A darabszám önmagában nem elég, mert nulla darab nem jelent kifutást.
2. Szinkron. API-val valós időben, vagy ütemezett feeddel legalább napi többszöri gyakorisággal. Ha ünnepi vagy akciós időszakban vagy, a napi egyszeri szinkron kevés.
3. Státusz-leképezés. A webshop a két mezőből vezessen le egy állapotot: raktáron, átmenetileg elfogyott, előrendelhető, kifutott.
4. Elágazás. Ha az állapot „átmenetileg elfogyott”: 200-as oldal, értesítéskérő űrlap, alternatívák, strukturált adatban OutOfStock. Ha „kifutott”: van-e utódtermék-azonosító a törzsadatban? Ha igen, 301 az utódra. Ha nincs, marad 200-as, „kifutott” jelöléssel és alternatívákkal. Csak külön, kézi jelöléssel („nyomtalanul kivezetve”) menjen 410-be.
5. Automatikus mellékhatások. Minden státuszváltás írja át a strukturált adatot, frissítse a Merchant Center feed availability mezőjét, tegye vagy vegye ki az URL-t a sitemapból, és tegyen naplóbejegyzést.
6. Visszamérés. Hetente futtass egy riportot: hány kifutott termék van utód nélkül, hány URL ad 404-et külső hivatkozással, hány feed-sor tér el az oldal állapotától.

A hatodik lépés az, amit a legtöbben kihagynak, pedig ez teszi a rendszert önjavítóvá. (Saját tapasztalat.)

Mit mondjon a strukturált adat a készletről?

Rövid válasz: pontosan azt, amit a látogató is lát az oldalon, a Schema.org ItemAvailability megfelelő értékével, se többet, se kevesebbet.

A Schema.org több készletállapotot ismer, és érdemes a pontosat használni: InStock, OutOfStock, BackOrder, PreOrder, SoldOut, LimitedAvailability, Discontinued. Az átmeneti készlethiányra az OutOfStock (vagy ha rendelhető, a BackOrder) való, a véglegesen kivezetett termékre a Discontinued.

Példa a kifutott állapotra:

{ "@context": "https://schema.org", "@type": "Product", "name": "Pelda termek", "sku": "ABC-123", "offers": { "@type": "Offer", "url": "https://pelda.hu/termek/abc-123", "availability": "https://schema.org/Discontinued", "itemCondition": "https://schema.org/NewCondition" } }

Átmeneti hiánynál pedig hasznos az availabilityStarts mező, ha tényleg tudod a várható visszaérkezést. (Hivatalosan igazolt: a Google terméktartalomra vonatkozó strukturált adat útmutatója szerint a jelölésnek az oldalon látható tartalommal kell egyeznie, különben a rich result elveszíthető. Szakmai feltételezés: mivel a nagy nyelvi modelleken alapuló válaszmotorok is jellemzően a strukturált adatot használják gyors ténykivonatolásra, jó eséllyel a készletjelzés pontossága náluk is számít, bár erre nyilvános, mért bizonyíték egyelőre nincs.)

Milyen ellenőrzőlistán menj végig minden kifutó terméknél?

Rövid válasz: négy területet kell egyszerre rendbe tenni, mert bármelyik kimaradása ellentmondó jelzést küld.

1. Strukturált adat

• Az availability érték megegyezik az oldalon látható állapottal.
• Kifutott terméknél Discontinued, nem pedig meghagyott InStock.
• Az értékelések és a vásárlói kérdések a jelölésben is maradnak, ha az oldalon is látszanak.
• Ha az oldalt átirányítod, a régi URL-en ne maradjon élő jelölés.

2. Belső linkek

• A kategórialistából és a szűrőkből kerüljön ki a nem rendelhető termék, vagy a lista végére.
• A „kapcsolódó termékek”, „gyakran együtt vásárolt” blokkokból cseréld le a kifutott elemet.
• A blogcikkekben és tudásbázis-cikkekben lévő termékhivatkozásokat futtasd végig egy kereséssel, és pontosítsd őket.
• Ha átirányítottál, ne hagyj a shopon belül átirányításra mutató linket: mindenhol az új URL szerepeljen.

3. Sitemap

• A 301-re vagy 410-re állított URL azonnal kerüljön ki a sitemapból.
• Az átmenetileg elfogyott termék maradjon benne, hiszen az oldal él és értéket ad.
• A lastmod mező tükrözze a valódi módosítást, ne minden generáláskor változzon.
• Nagy katalógusnál bontsd külön sitemapra az aktív és a kifutott, de megtartott termékeket, így a lefedettségi jelentésben látod, melyik csoport hogyan viselkedik.

4. Merchant Center

• A feed availability értéke egyezzen a landing oldal állapotával, különben a tétel elutasításra kerülhet. (Hivatalosan igazolt: ezt a Merchant Center dokumentációja külön kiemeli.)
• Az átmenetileg elfogyott terméket ne töröld a feedből azonnal: állítsd out_of_stock értékre, így az előzménye és az azonosítója megmarad.
• A véglegesen kivezetett tételt vedd ki a feedből, ne csak nullázd a készletet.
• Nézd meg a Diagnosztika fület a kivezetés után 2-3 nappal: a hirtelen megugró elutasítás szinte mindig szinkron-hibára utal.
• Ha automatikus tételfrissítés van bekapcsolva, ellenőrizd, hogy nem írja-e felül a szándékosan beállított állapotot.

Miért rontja a tömeges kategória-átirányítás a felhasználói élményt?

Rövid válasz: mert a látogató konkrét kérdéssel érkezett, és általános választ kap, ráadásul észre sem veszi, hogy hova került.

Ez a saját, határozott álláspontom. Ha valaki egy pontos cikkszámra keresve érkezik, és egy 400 elemes kategórialistán landol, akkor nemcsak hogy nem kapja meg a választ, hanem a bizalma is sérül: úgy érzi, becsapták. A visszalépési arány ilyenkor jellemzően megugrik, és a látogató a következő találatra kattint, ami sokszor egy konkurens webshop. (Saját tapasztalat, több webshop-migráció után.)

Technikailag sem előnyös: a Google többször jelezte, hogy a nem releváns célra mutató átirányítást soft 404-ként kezelheti, tehát az átirányítás „ereje” elvész, csak a felhasználói élményt rontottad el érte cserébe.

A jobb megoldás a megtartott oldal alternatívajánlattal. Az oldal tetején egyértelmű, emberi nyelvű üzenet („Ez a modell kifutott, a gyártó a következő változatot ajánlja helyette”), alatta a megőrzött műszaki adatok, majd 3-6 konkrét alternatíva rövid indoklással, hogy miben tér el az eredetitől. Ez a felület egyszerre szolgálja a keresőből érkezőt, a szervizért kutató régi vásárlót és a válaszmotort, amelyik a termék adatait próbálja kinyerni.

Hogyan látják mindezt az AI-válaszmotorok?

Rövid válasz: az AI-alapú válaszmotorok jellemzően a szöveges és strukturált tartalomra támaszkodnak, tehát a világos, kimondott állapotjelzés többet ér, mint bármilyen vizuális jelölés.

Ha egy termékoldalon csak egy szürke gomb jelzi, hogy nem rendelhető, azt egy szövegkivonatoló rendszer könnyen elnézi. Ha viszont az oldalon szerepel egy mondat, hogy „Ez a termék 2026 tavaszán kifutott, utódja az X modell”, akkor ez idézhető, egyértelmű tény. (Szakmai feltételezés, de a válaszmotorok működésének logikájából következik: a modellek a kimondott állítást tudják visszaadni, a CSS-osztályt nem.)

Ezért érdemes minden kifutott terméknél kiírni egy rövid, önmagában is értelmes blokkot: mikor futott ki, miért, mi a helyette ajánlott termék, és hol érhető el hozzá alkatrész vagy szerviz. Ez a néhány mondat a leggyakoribb valós kérdésekre válaszol, és jó eséllyel javítja az esélyt arra, hogy pontos információ kerüljön a válaszokba. Garanciát persze semmi nem ad rá, mert a válaszmotorok kiválasztási logikája nem nyilvános és folyamatosan változik.

Ugyanez igaz a régi, elavult tartalomra is: ha az oldalon még mindig „Raktáron” felirat áll egy két éve kivezetett terméknél, akkor ezt a téves állítást viszed be a rendszerekbe, és később nehéz korrigálni.

Források és további olvasnivalók

• Google Search Central: Átirányítások és a keresés (Redirects and Google Search)
• Google Search Central: Soft 404 hibák és az URL-eltávolítás dokumentációja
• Google Search Central: Terméktartalom strukturált adat (Product structured data)
• Google Merchant Center Súgó: Termékadat-specifikáció, availability attribútum
• Schema.org: Product, Offer, ItemAvailability
• IETF RFC 9110: HTTP Semantics (404, 410, 301 státuszkódok)
• sitemaps.org: XML Sitemap protokoll
• Bing Webmaster Guidelines
• OpenAI dokumentáció: bot-azonosítók és a webes tartalom kezelése