404-es oldalak helyes kiszolgálása
A közelmúltban esedékes volt Google Sitemaps frissítés alkalmával fedeztem fel, hogy több ügyfelem oldaltérképét is kiutasították a rendszerből. A hiba forrása az volt, hogy az illetékes tárhelyszolgáltató helytelenül szolgálta ki a 404-es hibalapokat. Korábban már Baranyai László is értekezett Barátságos hibaüzenetek - 404 címmel a Weblabor hasábjain hasonló témában, azonban ezúttal én a tartalmi kialakítás helyett az oldalak helyes kiszolgálására szeretném a hangsúlyt fektetni.
A legtöbb szolgáltató a testreszabott 404-es hibalapokat az Apache (illetve egyéb használt webkiszolgáló) ErrorDocument direktívája segítségével állítja be. Az opció értéke lehet relatív és abszolút útvonal is, így egy másik hoszton elhelyezett perszonalizált lapra is dobhatjuk a látogatót a keresett weblap hiányában. Ennek azonban ára van, ahogy arra az Apache kézikönyvének vonatkozó passzusa fel is hívja a rendszergazdák és fejlesztők figyelmét:
A külső címre redirektálást követően az eredeti 404-es HTTP státuszkód elvész, az érintett keresőrobot pedig mindebből csak annyit lát, hogy az adott webcím alatt minden oldal létezik, végtelen mennyiségű weblap tartozik a webhelyhez, ami nyilvánvalóan nem igaz. A spider pedig véletlenül sem akar ebbe belefutni.
Megoldást jelenthet a külső hoszton a statikus 404-es lap helyett minimális szerveroldali szkript használata, ahol szabályozható a kiküldött státuszkód.Alternatív megközelítésként pedig feleslegesen ne redirektáljunk külső, csupán tartalmában 404-es lapra, használjunk relatív útvonalat a webhely tárhelyére feltöltött weblaphoz.
■ A legtöbb szolgáltató a testreszabott 404-es hibalapokat az Apache (illetve egyéb használt webkiszolgáló) ErrorDocument direktívája segítségével állítja be. Az opció értéke lehet relatív és abszolút útvonal is, így egy másik hoszton elhelyezett perszonalizált lapra is dobhatjuk a látogatót a keresett weblap hiányában. Ennek azonban ára van, ahogy arra az Apache kézikönyvének vonatkozó passzusa fel is hívja a rendszergazdák és fejlesztők figyelmét:
Note that when you specify an ErrorDocument that points to a remote URL [...], Apache will send a redirect to the client to tell it where to find the document, even if the document ends up being on the same server. This has several implications, the most important being that the client will not receive the original error status code, but instead will receive a redirect status code.
A külső címre redirektálást követően az eredeti 404-es HTTP státuszkód elvész, az érintett keresőrobot pedig mindebből csak annyit lát, hogy az adott webcím alatt minden oldal létezik, végtelen mennyiségű weblap tartozik a webhelyhez, ami nyilvánvalóan nem igaz. A spider pedig véletlenül sem akar ebbe belefutni.
Megoldást jelenthet a külső hoszton a statikus 404-es lap helyett minimális szerveroldali szkript használata, ahol szabályozható a kiküldött státuszkód.
<?php
header("HTTP/1.0 404 Not Found");
?>
[...]
404 + Location
HTTP/1.0 404 Not Found
Location: http://host.tld/notfound
Tipusú kiszolgálást is követik a böngészők. A Location nem csak 3xx kód esetén értelmezhető, úgyhogy logikailag sem hiszem, hogy hibádzik a megközelítés.
Ez kvázi az ErrorDocument
ErrorDocumentdirektívájánál, a procedúra végén 200 OK státuszt kap a kliens.Valóban, és máshogy
Viszont egyszerű megoldás lehet például ez (Apache 1.3):
El tudok képzelni egy mod_rewrite megoldást is, ami lekezeli az Explórert, és csak neki 302 érkezik, a többieknek meg mondjuk a meta-változatot.
IE alatt?
Vagy valahogy ezt is ki lehet kerülni?
Gábor
dokumentum hossz alapján nézi
http://website101.com/Search_Engine_Positioning/404error_IE_theft.html
404 files (pages) under 512 bytes are ignored by the IE5+ browser and replaced by Microsoft's own error page. Therefore, be sure to create error pages that are larger than 512 bytes in order to defeat the browser's attempt to hijack your traffic.