Soft 404

SEO-hatás

A keresőrobotoknak véges ideje van az oldaladra. Minden 200-as hibaoldal elvesz ebből a keretből, és a valódi termék- vagy szolgáltatásoldalak helyett kerül sorra. A Search Console Oldalak indexelése riportjában az ilyen címek „Soft 404” okkal kimaradnak, de a feltérképezésük addigra megtörtént.

Ha sok hibaoldal ugyanazt a szöveget mutatja, duplikációs problémát is kapsz. A duplikált tartalom és a vékony tartalom jelzés ilyenkor teljesen jogos: tényleg több száz egyforma, üres oldal van kint.

Üzleti hatás

A legdrágább eset a webshopoknál jön elő. Kifutott termék, 200-as válasz, a Google hónapokig kint tartja a címet, a vásárló pedig egy üres lapra érkezik hirdetésből vagy találatból. Ez elköltött kattintás, nulla bevétellel.

Mit néz ebből a riport

Az audit egy biztosan nem létező URL-t kér le a domainről, és megnézi a válasz státuszkódját. Ha 200 érkezik 404 helyett, a szabály közepes hatású hibaként jelenik meg, kód hatókörrel. Az ajánlás egyszerű: a nem létező oldalak 404-es státuszt adjanak, ne 200-as soft 404-et.

Minden nyilvános weboldalra vonatkozik, mérettől és platformtól függetlenül. Statikus bemutatkozó oldalon is számít, mert a régi, törölt aloldalak linkjei évekig élnek.

Kiemelten érinti:

• webshopokat, ahol folyamatosan fogynak ki és tűnnek el termékek
• hírportálokat és blogokat, ahol archivált tartalmat törölnek
• SPA- és headless oldalakat, ahol a szerver alapból minden útvonalra 200-at ad
• migrált oldalakat, ahol a régi URL-struktúra megszűnt

Kevésbé releváns zárt admin-felületeknél és bejelentkezés mögötti területeknél. Staging környezetben sem ez az elsődleges kérdés, ott a noindex és a jelszavas védelem a fontosabb. Landing oldalaknál, amelyek kampány után lejárnak, viszont külön gondold végig: 404 vagy 301-es átirányítás a helyes lezárás.

Lépések

1. Nyiss meg a domaineden egy biztosan nem létező címet, például /ilyen-oldal-nincs-98765.
2. Nyisd meg a böngésző devtools Network fülét, és frissíts.
3. Kattints a lista első sorára, a dokumentum-kérésre.
4. Olvasd le a Status oszlopot. Ez a válasz igazi státuszkódja.
5. Ugyanezt futtasd le parancssorból is curl -I paranccsal, mert a devtools néha átirányítás utáni állapotot mutat.
6. Ellenőrizd a Search Console Oldalak indexelése riportjában a „Soft 404” sort.
7. Nézz rá néhány törölt termék vagy régi bejegyzés címére is, ne csak egy kitalált URL-re.

Jó jel

• a válasz HTTP/2 404
• a hibaoldal emberi szöveget és kereső mezőt kínál
• a Search Console Soft 404 sora üres vagy egyszámjegyű
• a törölt termékek vagy 404-et adnak, vagy célzott 301-et kapnak

Rossz jel

• a válasz HTTP/2 200, a szövegben pedig „Az oldal nem található”
• minden hibás URL a főoldalra vált át 301-gyel vagy 302-vel
• a Search Console Soft 404 listája több száz címet tartalmaz
• a sitemap olyan címeket sorol fel, amelyek már nem élnek

WordPress

1. Nézd meg a telepített átirányító és SEO-bővítményeket. Kapcsold ki a „404 átirányítása a főoldalra” típusú opciókat.
2. Ellenőrizd, hogy a sablonban van-e 404.php fájl. Ha nincs, a WordPress az index sablont használja, ami félrevezető lehet.
3. Egyedi sablonkódnál soha ne írj saját üzenetet status_header(404) nélkül.
4. Törölt bejegyzésnél döntsd el: 404 marad, vagy kapcsolódó tartalomra mutató 301 lesz belőle.

Shopify

1. A platform alapból 404-et ad a nem létező útvonalakra, a 404.liquid sablon rendezi a megjelenést.
2. A hibaforrás általában egy alkalmazás, ami minden 404-et a főoldalra terel. Az app beállításaiban kapcsold ki ezt.
3. A kifutó termékeket inkább archiváld, és készíts célzott átirányítást a kategóriára, ne a kezdőlapra.

Unas

1. Ellenőrizd egy kitalált URL-lel, hogy 404 érkezik-e vissza.
2. Az admin átirányítás-kezelőjében nézd át a szabályokat, és szedd ki a gyűjtő jellegű, főoldalra mutató sorokat.
3. Törölt termék helyett a hasonló termékre mutató 301 a jobb megoldás, tömeges főoldal-átirányítás helyett.

Shoprenter

1. Kérj le egy nem létező terméklapot, és olvasd le a státuszkódot.
2. Az URL-átirányítások listáját tisztítsd meg a felesleges, mindent a kezdőlapra küldő szabályoktól.
3. Az inaktív termékek kezelését egységesítsd: vagy maradnak elérhetők, vagy 404-et adnak.

Egyedi fejlesztés

1. A szerveroldali útvonalkezelésben minden nem talált erőforrásnál explicit módon állítsd 404-re a státuszt.
2. SPA-nál a szerver döntsön a kódról, ne a kliens. A keretrendszerek erre adnak eszközt, például a Next.js notFound() hívását.
3. API-válaszoknál se adj 200-at hibaüzenettel, mert ugyanez a probléma jelentkezik gépi fogyasztóknál.
4. Tegyél a CI-be egy egyszerű ellenőrzést, ami egy random URL-re 404-et vár.

• Minden 404 a főoldalra megy - a keresők ezt tömeges soft 404-ként kezelik, és a főoldal jelzései hígulnak.
• A hibaoldal szép, a státuszkód 200 - a dizájnra jut figyelem, a fejlécre nem, pedig a robot csak azt nézi.
• 302-es átirányítás 404 helyett - ideiglenes jelzést küldesz arról, ami véglegesen megszűnt, lásd 301 vs 302 átirányítás.
• Törölt termék változatlanul marad kint - a vásárló kattint, nincs mit venni, a hirdetési költség elveszett.
• Üres szűrő- és keresőtalálat indexelhető marad - végtelen számú tartalom nélküli cím kerülhet a feltérképezési sorba.
• A 404-es oldalon nincs navigáció - a látogató kilép, pedig egy menü és egy keresőmező megtartaná.
• A sitemap tovább hirdeti a halott URL-eket - ezzel te magad kéred a robotot, hogy újra és újra nézze meg őket.

Parancssori ellenőrzés. A válasz első sora árulja el az igazságot:

curl -s -o /dev/null -w "%{http_code}\n" https://pelda.hu/nincs-ilyen-oldal-98765
# helyes:  404
# soft 404: 200

Ha átirányítást gyanítasz, kövesd végig a láncot:

curl -sIL https://pelda.hu/torolt-termek | grep -E "^HTTP|^location"

Szerveroldalon a státuszt a sablon kiírása előtt kell beállítani:

$termek = $repo->find($slug);

if (!$termek) {
    http_response_code(404);
    include __DIR__ . '/templates/404.php';
    exit;
}

A lényeg a sorrend: a http_response_code(404) hívásnak meg kell előznie minden kimenetet, különben a fejléc már elment 200-zal.