Soft 404 és a hibás oldalak: csendes indexelési szivárgás

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

A legtöbb weboldalhiba hangosan jelez: leáll a szerver, eltűnik a menü, piros hibaüzenet villan a képernyőn. A soft 404 nem ilyen. Csendben dolgozik, hónapokig észrevétlen marad, és közben lassan kikoptatja az oldalaidat a Google indexéből. A tulajdonos annyit lát, hogy a forgalom valamiért fogy, pedig a tartalomhoz senki nem nyúlt.

Végigmegyünk azon, mi pontosan a soft 404, miért nehezebb eset egy tisztességes 404-es hibánál, hogyan bányászod elő a Search Console-ból, és melyik helyzetben melyik HTTP-státusz a helyes válasz. Ahol releváns, jelölöm, mi hivatalos Google-információ, mi a saját tapasztalatom, és hol lépek a szakmai feltételezés terepére.

Mi az a soft 404, és miben más, mint egy valódi 404?

Röviden: a soft 404 olyan oldal, amelynek a tartalma gyakorlatilag hibaüzenet vagy üresség, a szerver viszont 200 OK státuszkóddal adja vissza, mintha minden rendben volna. A tartalom és a technikai válasz ellentmond egymásnak.

Minden oldalletöltés két csatornán üzen. Az egyik az, amit az ember lát: szöveg, kép, menü. A másik az, amit csak a gép lát: a HTTP-válasz státuszkódja. A 200 azt jelenti, hogy „itt a kért tartalom”, a 404 azt, hogy „nincs ilyen oldal”, a 410 pedig azt, hogy „volt, de véglegesen megszűnt”. A látogató a státuszkódból semmit nem érzékel, a keresőrobot viszont elsősorban ebből dolgozik.

Hivatalosan igazolt: a Google Search Central dokumentációja külön nevesíti a soft 404 esetet, és leírja, hogy a keresőrendszer a tartalom alapján is besorolhat egy oldalt nem létezőként, akkor is, ha az 200-as státusszal érkezik. A Search Console Oldalindexelés jelentésében ez önálló okként jelenik meg, és az érintett URL-ek nem kerülnek be az indexbe.

Egy magyar példa. Egy székesfehérvári autószerviz oldalán a „Nyári gumiakció” aloldalt ősszel kiszedték a menüből, de az URL megmaradt, és a sablon egyetlen mondatot tölt be: „Ez a kampány lezárult.” Státusz: 200 OK. A Google szemében ez soft 404, a látogató szemében pedig zsákutca.

Miért veszélyesebb a soft 404 a valódi 404-nél?

Röviden: mert a valódi 404 egyértelmű, gyorsan feldolgozható jelzés, a soft 404 viszont bizonytalanságot okoz, feltérképezési kapacitást éget, és sem a rendszereidben, sem a méréseidben nem jelenik meg hibaként.

Egy tiszta 404-es oldalt a robot megtalál, feldolgoz, és az URL idővel kikerül az indexből. Ez rendben van, sőt egészséges: minden élő weboldalon keletkeznek megszűnt címek. A soft 404 esetében viszont a szerver azt állítja, hogy van tartalom, ezért az URL a rendszerek szemében továbbra is élő. Marad a sitemapben, marad a belső linkek között, és a robot időről időre visszatér rá.

Saját tapasztalat: több webshopnál láttam, hogy a kifutott termékek több ezer URL-en éltek tovább 200-as státusszal, egy „A termék jelenleg nem rendelhető” szöveggel. A feltérképezési statisztikában ezek aránytalanul nagy szeletet vittek el, miközben az új kategóriaoldalak lassabban kerültek be. Ok-okozati összefüggést nem tudok bizonyítani, de a mintázat visszatérő.

A legfontosabb különbség mégis a láthatatlanság. A soft 404-es oldalak gyakran a menüből és a láblécből is elérhetők maradnak, tehát belső linkerőt kapnak olyan címek, amelyek semmilyen értéket nem közvetítenek, a felhasználó pedig nem kap egyértelmű jelzést arról, hogy rossz helyen jár. Közben a hibafigyelő rendszereid csendben maradnak: az uptime-monitor 200-as választ lát, az analitikában ez egy sima oldalmegtekintés. Ezért nevezem csendes szivárgásnak.

Hogyan találod meg a soft 404-eket a Search Console-ban?

Röviden: az Indexelés menüpont Oldalak jelentésében keresd a „Soft 404” okot, majd az URL-ellenőrző eszközzel nézd meg egyesével, mit lát a Google, és a szerver milyen státuszt küld.

1. Nyisd meg a Search Console-t, és bal oldalon válaszd az Indexelés > Oldalak jelentést.
2. Görgess le a „Miért nincsenek indexelve az oldalak?” táblázathoz, és keresd a Soft 404 sort.
3. Kattints rá: megkapod a példa-URL-ek listáját. Ez mintavétel, nem feltétlenül a teljes halmaz.
4. Exportáld a listát, és nézd meg, milyen mintázat rajzolódik ki: azonos könyvtár, paraméteres címek, kereső-találati oldalak, régi kampányoldalak.
5. Egy-egy URL-nél használd az URL-ellenőrző eszközt, és kérj élő tesztelést. Itt látod, mit tölt be a robot, és renderelés után mi marad a képernyőn.
6. Javítás után ugyanitt kérheted a javítás ellenőrzését. Az újrafeldolgozás napokig, nagyobb oldalnál hetekig is eltarthat.

A Search Console mintavételes, ezért tegyél mellé két másik forrást. Az egyik a saját szerver: parancssorból másodpercek alatt ellenőrizhető a státusz.

curl -s -o /dev/null -w "%{http_code}\n" https://pelda.hu/regi-kampany/

Ha erre 200 érkezik, miközben az oldalon az áll, hogy nincs ilyen tartalom, megvan a hiba. A másik forrás egy feltérképező szoftver, amellyel az egész oldalt végigjáratod, és kilistázod a vékony, alacsony szószámú, 200-as státuszú oldalakat. Saját tapasztalat: a 100 szó alatti, sablonos oldalak listája szinte mindig kiadja a soft 404-gyanús halmazt. Érdemes a Beállítások > Feltérképezési statisztika részt is megnézni: ha egy évek óta működő, sokszor átalakított oldalon a 4xx válaszok aránya gyakorlatilag nulla, az önmagában gyanús.

Milyen esetekben keletkezik soft 404 egy magyar kkv oldalán?

Röviden: a leggyakoribb forrás a webshop kifutott terméke, az üres szűrő- és keresőoldal, a rossz státusszal kiszolgált saját hibasablon, és a lejárt kampány- vagy eseményoldal.

• Üres kereső-találati oldal. A WordPress alapkeresője a /?s=kifejezes címen 200-as státusszal ad vissza egy „Nincs találat” oldalt. Ha ezek a linkek bárhonnan elérhetők, indexelésre jelentkeznek.
• Üres kategória vagy címke. Egy debreceni kisbolt webshopjában a „Karácsonyi ajándék” kategória januárban kiürül, de az URL él tovább.
• Kombinált szűrők. Szín, méret és ár együtt szűrve nulla találatot ad, mégis 200-as oldal születik, ráadásul rengeteg variációban.
• Lejárt kampány- és eseményoldalak. Egy nyíregyházi rendezvényszervezőnél a tavalyi eseményoldalak mind élnek, tartalmuk viszont egyetlen sor: „Az esemény lezajlott.”
• Saját hibaoldal rossz státusszal. Készül egy szép, márkázott hibaoldal, és egyszerű átirányítás küldi rá a nem létező címeket. Az átirányítás célja 200-as, tehát minden hibás URL soft 404 lesz.
• Átirányítás a főoldalra. Ez a leggyakoribb jó szándékú hiba. Hivatalosan igazolt: a Google a tartalmilag irreleváns célra mutató átirányításokat is soft 404-ként kezelheti.
• Hiányzó nyelvi változat. Egy budapesti B2B cégnél az angol aloldalak fele nem készült el, a nyelvváltó mégis odalinkel, és egy üres sablon fogadja a látogatót.

Melyik HTTP-státusz a helyes az egyes esetekben?

Röviden: ha az oldal nincs és nem is lesz, 404 vagy 410 jár; ha véglegesen máshová került, 301; ha csak átmenetileg nem elérhető, 503. Hiányzó tartalmat soha ne fedj el 200-as státusszal.

• Nincs ilyen URL, elgépelés, régen törölt oldal: 404 Not Found. Ez az alapeset.
• Végleg megszűnt tartalom, nem lesz pótlás: 410 Gone. Hivatalosan igazolt: a Google a kettőt hasonlóan kezeli, a 410 valamivel határozottabb jelzés.
• Az oldal véglegesen máshová került, a tartalom lényegében ugyanaz: 301 Moved Permanently a valóban megfelelő új címre. Ha nincs ilyen, inkább 404.
• Ideiglenes áthelyezés, kampányos átterelés: 302 vagy 307.
• Karbantartás, ideiglenes leállás: 503 Service Unavailable, lehetőleg Retry-After fejléccel.
• Ideiglenesen elfogyott termék, amely visszajön: maradjon 200, de a tartalom maradjon értékes (leírás, paraméterek, alternatívák), a készletet pedig jelezd strukturált adatban OutOfStock értékkel.
• Véglegesen kifutott termék: 301 az utódra, ha az tényleg ekvivalens; egyébként 404 vagy 410, a hibaoldalon kategórialinkkel.
• Üres keresési találat vagy üres szűrő: ne engedd indexelni. Vagy 404-es státusz, vagy noindex és a paraméteres címek kizárása.
• Belépéshez kötött tartalom: 401 vagy 403, nem pedig egy 200-as „jelentkezz be” oldal.

WordPress-sablonban egyetlen sorral rendbe tehető a státusz: status_header( 404 ); nocache_headers();. Sima PHP-oldalnál: http_response_code(404);. Nginx alatt egy véglegesen megszűnt könyvtárra: location /regi-kampany/ { return 410; }.

Hogyan javítod ki a soft 404-eket lépésről lépésre?

Röviden: először leltárt készítesz, utána szándék szerint kategorizálod az URL-eket, csak ezután nyúlsz a státuszkódokhoz, végül kitakarítod a sitemapet és a belső linkeket.

1. Leltár. Search Console export, feltérképező szoftver, és ha van hozzáférésed, szerverlog. A három forrás uniója a munkalistád.
2. Kategorizálás. Minden URL mellé írj döntést: véglegesen megszűnt, átköltözött, ideiglenesen üres, vagy sablonhiba miatt látszik üresnek.
3. Sablonhiba javítása. Ha a baj egyetlen sablonban van, egy javítással több száz cím rendeződik. Mindig ezzel kezdj.
4. Státuszok beállítása az előző szakasz döntési listája alapján.
5. Átirányítási térkép. Csak ott irányíts, ahol a cél tartalmilag tényleg megfelel az eredetinek.
6. Sitemap tisztítása. A megszűnt címeknek nincs helyük az XML sitemapben.
7. Belső linkek. Menü, lábléc, cikkszövegek, bannerek. Amíg belülről linkelsz egy halott URL-re, a robot visszatér rá.
8. Ellenőrzés. curl-lel nézd meg a státuszt, majd a Search Console-ban kérd a javítás ellenőrzését.

Az újraindexelés üteme nem rajtad múlik. Nagyobb oldalnál hetekbe telhet, mire a jelentés letisztul, és ez nem garantál forgalmi növekedést, csak azt, hogy a technikai jelzéseid végre pontosak.

Számít-e mindez az AI-válaszmotoroknál is?

Röviden: jó eséllyel igen, bár erről lényegesen kevesebb hivatalos információ áll rendelkezésre, mint a klasszikus keresésről.

Hivatalosan igazolt: a nagy modellszolgáltatók dokumentálják a saját feltérképező robotjaikat, azok azonosítóit és a robots.txt kezelését. Szakmai feltételezés: ezek a rendszerek is a HTTP-válaszra és a letöltött szövegre támaszkodnak, tehát egy 200-as státusszal kiszolgált „nincs ilyen termék” oldal ugyanúgy bekerülhet a feldolgozott anyagba, mint egy értékes leírás. Ha egy válaszmotor ilyen oldalról idéz, pontatlan képet ad a cégedről. Ez nem bizonyított összefüggés, és önmagában nem ígér jobb AI-láthatóságot; annyi viszont logikusan következik, hogy a tiszta státuszkódok pontosabb gépi értelmezést tesznek lehetővé.

Mit érdemes havonta ellenőrizned?

Röviden: egy negyedórás, hónapról hónapra ismételt kör a legtöbb kkv-oldalon megelőzi a nagyobb bajt.

• Search Console, Oldalak jelentés: nőtt-e a Soft 404 sor darabszáma az előző hónaphoz képest.
• Egy biztosan nem létező URL hívása curl-lel: valóban 404 érkezik?
• A kifutott termékek listája: melyik kap fölöslegesen 200-at.
• Keresőoldal és szűrők: a helyén van-e a noindex.
• XML sitemap: van-e benne olyan cím, ami már nem 200-as vagy nem indexelhető.
• Nyelvváltó és menü: mutat-e üres oldalra.

A soft 404 nem látványos hiba, és pont ezért marad meg évekig. Aki havonta ránéz, percek alatt elkapja azt, amit különben csak a forgalmi grafikon lejtője jelez majd, jóval később.

Források és további olvasnivalók

• Google Search Central: Oldalindexelés jelentés (Page indexing report) súgó
• Google Search Central: HTTP státuszkódok, hálózati és DNS-hibák a Google Kereséshez
• Google Search Central Blog: a soft 404 hibák kezeléséről szóló bejegyzések
• Google Search Console Súgó: URL-ellenőrző eszköz
• IETF RFC 9110: HTTP Semantics (a státuszkódok hivatalos definíciója)
• Schema.org: Product és ItemAvailability (OutOfStock) típusok
• Bing Webmaster Tools dokumentáció: indexelési jelentések
• OpenAI dokumentáció: GPTBot és a webes feltérképezés kezelése
• W3C: webes és HTTP-vonatkozású szabványdokumentációk