A Last-Modified HTTP fejléc közli az ügyféllel az időt utolsó változtatás oldal (objektum). Ha a kliens (böngésző, keresőrobot) megkapta a Last-Modified fejlécet, akkor a cím legközelebbi elérésekor, feltéve, hogy az oldal (objektum) a helyi gyorsítótárban van, hozzáad egy If-Modified-Since kérdést (hogy változott-e az oldal a beérkezés dátuma óta az Utolsó módosításban). A szervernek viszont, miután megkapta az If-Modified-Since kérést, ellenőriznie kell a beérkezett időbélyeget az oldal utolsó módosításának időpontjával, és ha az oldal nem változott, akkor a 304-es nem módosítva választ kell adnia.
Ha az oldal nem változott, akkor a 304-es nem módosított kódú fejlécek elküldése után a szerver leállítja az adatátvitelt, az oldal törzse, képek és egyéb objektumok nem kerülnek továbbításra.
Az oldal utolsó módosítási idejének ellenőrzésének helyes végrehajtása jelentősen (akár 30%-kal vagy még többet) csökkentheti a szerver terhelését. A helyes megvalósítás azt jelenti, hogy ellenőrizni kell az oldalgenerálás megkezdése előtti időt egy dinamikus webhelyen. Ebben az esetben az oldal létrehozásához szükséges összes művelet (tartalom lekérése az adatbázisból, sablonok elemzése, megjegyzések fogadása stb.) nem kerül végrehajtásra. Ez különösen igaz azokra a webhelyekre, amelyek nagy forgalmúak, és a felhasználó hosszú ideig látogatja. Példa: A felhasználó egy sporthíroldalon tartózkodik, és folyamatosan frissíti kezdőlap a mérkőzés eredményének közzétételéig. Néhány perc alatt több tucatszor lehet kérni és fogadni egy oldalt. Ha a Last-Modified fejlécet megadtuk, és az If-Modified-Since kérést helyesen dolgoztuk fel, akkor az oldal ténylegesen egyszer kerül elküldésre, és minden további kérés 304-es nem módosítva választ kap.
A keresőmotorok azt javasolják, hogy küldje el a Last-Modified fejlécet, és megfelelően kezelje az If-Modified-Since-t a webmesteri irányelvek segítségével.
A jegyzet: aktiválódik az oldal adaptív verziója, amely automatikusan alkalmazkodik az Ön böngészőjének kis méretéhez, és elrejti az oldal egyes részleteit a könnyebb olvashatóság érdekében. Jó szórakozást!
Sziasztok kedves blog olvasók Folytatjuk a témát, az egyik legfontosabb SEO tényezőt. Ez a cikk a belső optimalizálás bonyodalmait érinti, mivel arra a válaszkódra összpontosít, amelyet a keresőmotorok és a látogatók az oldalhoz való hozzáférésükkor kapnak.
Annak ellenére, hogy az oldal egészének építésénél és optimalizálásakor ez meglehetősen apró részlet, nagyon fontos! Ugyanis fontos, hogy az az oldal, amelyen nem történt változás egy robot vagy egy személy legutóbbi látogatása óta, 304-es kódot adjon, ami azt jelenti, hogy az oldal változatlan maradt. Amikor a szerver elküldi ezt a kódot a kliensnek, az oldalon lévő összes PHP szkript végrehajtása el sem indul, hanem a gyorsítótárból töltődik be az oldal, ami jelentősen csökkenti a szerver terhelését és felgyorsítja a felhasználó számára az oldalbetöltést. .
Így a szerverünk helyes válaszainak beállításával legalább öt legyet megölünk egy csapásra:
Valamiért számomra az utolsó pont tűnik a legkedvesebbnek (mivel a SEO-t érinti, és növeli az oldalad hitelességét a keresőkben), bár kétségtelenül a többi pont is rendkívül fontos.
Korábban már elmondtuk, hogy a változatlan oldalak kérésére a szervernek vissza kell térnie 304 Nem módosítva, és milyen kódot kell visszaadnia a szervernek, ha a kliens először lép fel az oldalra, vagy olyan oldalra lép, amely megváltozott? Ilyen esetekben a szervernek vissza kell adnia az állapotot 200 OK. Különösen adott kódot nem kell küldeni, ha minden rendben van az oldallal, akkor mindig 200-at ad ki.
Ezért csak a 304-es kódról kell gondoskodnunk, mivel a szerver a mi beavatkozásunk nélkül nem küldi el. Ehhez a cím is segítségünkre lesz Utoljára módosítvaés kérni.
Utoljára módosítva a fejléc, amellyel küldjük PHP használatával, ez a fejléc az oldal legutóbbi módosításának pontos idejét tartalmazza (másodpercben). Ehhez az időmérés általánosan elfogadott mértékét használják: Unix időbélyegzőt.
Unix időbélyegző a másodpercek száma a Unix-korszak kezdete óta: 1970. január 1. Az írás pillanatában a Unix időbélyegzője 1370597447 másodperc, ami 2013.07.06. 09:30:47 GMT (+00:00).
Vagyis nem kell mást tennünk, mint küldeni egy PHP fejlécet az utasítással Utoljára módosítvaés a kívánt dátum:
Header("Last-Modified: ".gmdate("D, d M Y H:i:s", $utolsó_módosított_idő)." GMT");
Ahol a fejléc egy HTTP-fejléc küldésére szolgáló konstrukció, Utoljára módosítva- amit küldünk és közvetlenül a kettőspont után jön az értéke:
Gmdate("D, d M Y H:i:s", $utolsó_módosítási_idő)." GMT".
Az utoljára módosított érték a függvény gmdate(), amely az általam kitalált változót tartalmazza $utolsó_módosított_idő(nevezheted akárhogy is). Változóban $utolsó_módosított_időés tartalmazza az utolsó módosítás idejét a formátumban Unix időbélyegzőés a funkciót gmdate() arra szolgál, hogy a dátumot a megfelelő formába hozzuk (greenwichi idő).
Az érthetőség kedvéért álljon itt egy példa: ha egy függvényben vagyunk gmdate() tegye az értéket 1365003142 , akkor a kimenet a következő lesz: 2013. április 3., szerda, 15:32:22.
Most, hogy megtudtuk, hogyan működik az egész folyamat, felmerülhet a kérdés: „Meg kell-e kézzel jeleznünk az utolsó módosítás időpontját minden oldalon?”. Válasz: "Igen!" Személy szerint én ezt teszem - manuálisan, a legmegbízhatóbb lehetőség. Viszont kifejezetten ehhez a bloghoz megadtam mindent, pl ha új megjegyzés az oldalon, majd egy változóba $utolsó_módosított_idő a megjegyzés hozzáadásának időpontja rögzítésre kerül, ez azért történik, hogy a keresőmotorok indexelhessék az új megjegyzéseket, és tudják, hogy a webhely „élő”. Minden webhely más és más, és saját algoritmust kell kidolgoznia az oldal utolsó módosításának dátumának megadásához, vagy mindig manuálisan kell megadnia.
Még egyszer hangsúlyozom, hogy az algoritmusom a következő:
1) Az anyag létrehozásának dátumát manuálisan jelzem meg, ha valamit változtatok a cikkben (elírás vagy kiegészítés), akkor ismét manuálisan adom be az utolsó frissítés új időpontját.
2) Ha a látogató megjegyzést fűz hozzá, akkor a változóban $utolsó_módosított_idő automatikusan, tudomásom nélkül beírja a megjegyzés hozzáadásának időpontját, mivel valójában ez lesz az oldal utolsó módosításának dátuma.
Amit nem vettem figyelembe: a nálam lévő oldal jobb oldali oszlopában friss cikkek, ajánlottÉs legjobb 10. Folyamatosan és minden oldalon egyszerre változnak. Ha minden alkalommal, amikor megváltoztatom a webhely jobb oldali oszlopát, megváltoztatnám (automatikusan vagy manuálisan - nem számít) az oldal legutóbbi módosításának dátumát, akkor ennek a műveletnek a lényege elveszne. Úgy döntöttem, hogy ezeket a változásokat nyomon kell követni és figyelembe kell venni a specifikációnál $utolsó_módosított_idő nem éri meg, mivel ezek nem szolgálnak a SEO számára.
Ahogy írtam, nem tudom pontosan megmondani, hogyan kell automatizálni egy oldal utolsó módosítási dátumát, de elmondom, hogy NE!
Az első dolog, ami a legtöbb embernek eszébe juthat, az az, hogy elküldi a fájl utolsó módosításának dátumát az oldal tartalmával együtt a fejlécben. Személy szerint a cikkem szövegei fájlokban vannak, nem pedig adatbázisban, így számomra ez a módszer nagyszerű megoldásnak tűnhet, hogy ne írjam be minden alkalommal Unix időbélyegző manuálisan. De nem! A legtöbb gazdagép, sőt talán az összes, a létrehozás dátumát veszi a fájl utolsó módosításának dátumaként, nem veszi figyelembe a későbbi módosításokat.
Szerintem megérted az ilyen esetekben a következményeket. Egy népszerű ukrán tárhelyszolgáltató (és azt hiszem, nem ő az egyetlen) a GYIK-ben valami ilyesmit ír: „A fájl utolsó módosításának dátuma helyett használja a funkciót idő(), amely Unix időbélyegző formátumban adja vissza a pontos időt." Ez olyan abszurd! Csak a helyszínen lő! Ezt a tárhelyszolgáltatót pedig „az egyik legjobbnak” tartják, miután ezt elolvastam, azonnal nem akartam az ügyfelük lenni.
Ez csak anti-SEO, gondolja meg magát, feljön a keresőoldalára, és azt nézi: „Hűha! Épp most volt az utolsó oldalváltás, így sejtettem, hogy mikor jövök, osztály! Néhány nappal később ugyanarra az oldalra érkezik: „Nézd, megint megváltozott, ez véletlen... Várj, miért nem látok semmilyen változást? Oké, máskor is visszajövök." Megint jön: "Nos, nem, srácok, ez már nem vicces, biztos nem lehet bennetek megbízni." Íme egy mese :)
Aztán az emberek csodálkoznak, hogy a keresési eredmények miért nem olyanok, mint szeretnék, hanem azért, mert a banális elveszett a webhelyről bizalom(bizalom). Akárcsak a „A pásztorról és a farkasokról” című példázatban.
Tehát kitaláltuk a fő hibákat: nem lehet megadni az aktuális időt, és nem javaslom, hogy adja meg a fájl módosítási idejét. Most pedig folytassuk annak megértését, hogyan működik mindez.
Állítsa be a fejlécek küldését Utoljára módosítva ez az esetnek pontosan 1/3-a, még kell: választ adni a kérésre és bekapcsolni oldal gyorsítótárazása. Mindkét művelet nem igényel sok időt és kódsorokat.
egy kliens kérés az Ön szerveréhez, amelyben az ügyfél megkérdezi: „változott az oldal az utolsó látogatásom óta?”. Ha az oldal nem változott, akkor le kell állítani az oldal további betöltésének végrehajtását a következő paranccsal:
Ugyanakkor az oldal törzsét nem szabad elkezdeni rajzolni, mindez MI ELŐTT történik az oldalon bárminek az első kimenete! Ezzel együtt vissza kell küldeni a szerver választ a kliensnek 304 Nem módosítva, ezzel azt mondva, hogy az oldalt ki kell venni a gyorsítótárból. Térjünk is közvetlenül a lényegre:
If (isset($_SERVER["HTTP_IF_MODIFIED_SINCE"]) && strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"]) >= $last_modified_time)( header("HTTP/1.1 304 Not Modified"); die; ) fejléc("Last-Moified" : ".gmdate("D, d M Y H:i:s", $utolsó_módosítási_idő)." GMT");
Tehát az első sorban ellenőrizzük a segítségével, hogy a HTTP_IF_MODIFIED_SINCE kérés megérkezett-e a szerverünkre, és azonnal ellenőrizzük, hogy a bejövő HTTP_IF_MODIFIED_SINCE másodpercek száma nagyobb-e, mint a $utolsó_módosított_idő vagy nem? Ha több, akkor a kliens utolsó látogatásának időpontja későbbi, mint az oldal utolsó módosításának időpontja, innen levonjuk azt a pusztán logikus következtetést, hogy az oldal nem változott, ami azt jelenti, hogy a szerver választ a második sor 304 Nem módosítva a 3. sorban pedig megöljük (leállítjuk) az oldalon található összes szkript végrehajtását. Más szóval, leállítjuk a letöltést.
Ha az ügyfél nem küldött nekünk HTTP_IF_MODIFIED_SINCE kérést, vagy az utolsó látogatása korábban volt, mint az oldal legutóbbi módosításának dátuma, akkor (alapértelmezés szerint) visszaküldjük a kódot 200 OKés az ötödik sorban elküldjük neki az oldalváltás AKTUÁLIS dátumát, ahelyett, hogy ő volt.
Az IF_MODIFIED_SINCE-ről és a kód elrendezéséről mindent elmondott, amire szüksége van, kivéve azt, amit az strtotime () függvény csinál:
Strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"])
Egy figyelmes és hozzáértő olvasó már sejthette, hogy ez a függvény egy rendes dátumot Unix időbélyegzővé alakít át, mivel ebben a $last_modified_time változót állítottuk be, és ezért összehasonlításképpen mindent közös nevezőre kell hoznunk. közös rendszer mérések.
És végül csak engedélyeznünk kell a gyorsítótárazást, ez a következő sorokkal történik:
Header("CacheControl: nyilvános"); header("Lejár: " . date("r", time()+10800));
Ahol az 10800 az az idő (másodpercben), ameddig az oldalt gyorsítótárazni akarjuk, azaz ezt a példát 3 órán keresztül.
És mint mindig, aki nem ért semmit, annak mindent teljes terjedelmében közzé teszek, ahogy az a blogomon el van rendezve:
= $utolsó_módosított_idő)( header("HTTP/1.1 304 Nincs módosítva"); die; /* ölj meg mindent, ami lent van */) header("Last-Modified: ".gmdate("D, d M Y H:i:s", $utolsó_módosított_idő)." GMT"); ?> És ment az oldal többi részeAzt hiszem, észrevetted, hogy ez az egész történet a Last-modified-el a - címkéjének analógja. Tehát a lastmod ismerkedési és tanácsadó jellegű, és senki sem fog vitatkozni a szervered válaszaival. Természetesen nem ritka, hogy az oldaltérképben szereplő lastmod eltér a LastModified fejléctől, de mostantól ugyanazoknak kell lenniük az Ön számára! Elvégre most valamiféle tudományt tanultunk, nem azért, hogy olyan szerencsétlen webmesterekhez legyünk, akik nem haladtak tovább a sitemap.xml-nél.
Én személy szerint benne vagyok Ebben a pillanatban Egyáltalán nem használom a lastmod címkét az oldaltérképeimben, talán később átgondolom, de egyelőre nem látom értelmét, hogy ennyire aprólékos a megfelelő címekkel. Utoljára módosítva :)
És végül ellenőrizze a helyességet Utoljára módosítvaés ezzel a szolgáltatással megteheti: kattintson a gombra.
Köszönöm a figyelmet, és külön köszönet a folyamatosan növekvő feliratkozóknak, számomra ez a legnagyobb ösztönzés arra, hogy gyakrabban írjak a blogra. Tehát ha még nem iratkozott fel az új cikkekre, üdvözöljük!
Last-Modified és If-Modified-Since fejlécek a WordPresshez
Kevesen figyelnek a HTTP-fejlécekre Utoljára módosítvaÉs Ha-Módosítva-Azóta az oldal optimalizálásakor, de hiába! Fontos, hogy az oldal, amelynek tartalma nem változott a keresőrobot legutóbbi látogatása óta, egy 304-es kódot adjon, ami valójában azt jelzi, hogy ez az oldal nem lett kiegészítve semmivel - nem szerkesztette, nem egészítette ki a szöveget, ehhez a bejegyzéshez nem adtak megjegyzést stb. P.
Ha ez a http fejléc hiányzik, akkor a Yandexben az eredmények dátum szerinti rendezésekor a webhely nem lesz látható a legtöbb felhasználó számára.
Éppen ezért fontos, hogy ne csak helyesen állítsd be, hanem minden alkalommal, amikor szerkesztesz egy bejegyzést, frissítsd a dátumot az aktuálisra. Ezt manuálisan kell megtenni.
A megjegyzésekkel egyszerűbb: ha egy látogató megjegyzést fűz hozzá, akkor egy változóban $utolsó_módosított_idő a megjegyzés hozzáadásának időpontja automatikusan beírásra kerül - ez az oldal legutóbbi módosításának dátuma.
1. Amikor a szerver ilyen kódot ad vissza, az oldalon lévő összes PHP szkript végrehajtása el sem indul. Az oldal a keresési gyorsítótárból töltődik be, és ez, amint érti, jelentősen csökkenti a szerver terhelését a tárhelyszolgáltatója nagy örömére, és felgyorsítja az oldal betöltését a látogató számára, aki szintén nem örülhet.
Hogyan történik ez?
Az internet átkutatásakor a Google és a Yandex pókok minden webhely másolatát tárolják adatbázisukban. Ez a példány egyfajta összehasonlítási mintaként szolgál: minden a régi, vagy történtek-e változások. Ha pedig a Last-Modified és If-Modified-Since fejlécek nincsenek beállítva, vagy rosszul vannak konfigurálva, akkor a webhely új oldalai indexelésre kerülnek, és a keresőmotor gyorsítótárában lévő főoldal hosszú ideig nem frissül, akárcsak a megjegyzés feed nincs frissítve.
De a gyakran frissülő oldalakhoz ( hírcsatornák, naponta többször frissül, aktívan kommentált blogok stb.) van egy hátránya: a gyorsítótárban lévő információk túl gyorsan elavulnak, és az ember még az oldal újratöltésekor sem látja a legfrissebb híreket, nem lát új megjegyzéseket. De még mindig a baj fele. Az a baj, hogy a robot ezt sem látja, hacsak nincs benne a megfelelő Last-Modified fejléc.
header("Utoljára módosított: ".gmdate("D, d M Y H:i:s ")."GMT");
Ha webhelyét gyakran frissítik (például gyakran kommentálják bejegyzéseit), a következő fejléckészlettel letilthatja a gyorsítótárazást:
header("Lejár: ".gmdate("D, d M Y H:i:s", time() + 7200)." GMT");
Ez azt jelenti, hogy minden kérésnél újra ellenőrizni kell a tárolt példány érvényességét.
Ha nincs letiltva a no_cache függvény meghívásával, akkor Firefoxban és IE-ben az oldal a gyorsítótárban tárolódik, és ez az oldal, amely minden további kérésnél visszaküldésre kerül.
Az oldal frissítéséhez és a legújabb verzió lekéréséhez meg kell nyomnia a billentyűkombinációt Ctrl+F5, a szokásos Frissítés gomb (F5) nem működik. És azt kell mondanom, hogy az IE gyorsítótárában lévő dokumentumok nagyon-nagyon hosszú ideig tárolhatók.
Operában a gyorsítótár oldala a Frissítés gomb vagy az F5 megnyomásával törlődik. CRTL + F5 az Operában - indítsa újra az összeset lapok megnyitása Mint tudod, ha sokat nyitottál belőlük - a várakozás során szakállat növeszthetsz.
Ha letiltja az oldal gyorsítótárazását a no_cache függvénnyel, akkor az Opera és a Firefox az If-Modified-Since fejléc mechanizmusát használja az ilyen oldalak elérésekor. Így gyorsítótárazás történik, de a böngésző megkérdezi a szervert, hogy az oldal valóban megváltozott-e vagy sem - ez a helyes kérdés.
Ezért ennek a paraméternek a feldolgozását is össze kell kapcsolni. Nem írom le, hogy mit és mit jelent a függvény, egyszerűen megadom azt a kódot, amely helyesen adja vissza a fejléceket, és nem okoz konfliktust a legtöbb tárhelyen, amellyel dolgoznom kellett. Ez a kialakítás működik sweb.ru, eomy.net, timeweb.ru, fastvps.ru, startlogic.com
header("Lejár: ".gmdate("D, d M Y H:i:s", time() + 7200)." GMT");
header("Cache-Control: nincs gyorsítótár, újra kell érvényesíteni");
$mt = filemtime($file_name);
$mt_str = gmdate("D, d M Y H:i:s ")."GMT";
if (isset($_SERVER["HTTP_IF_MODIFIED_SINCE"]) &&
strtotime($_SERVER["HTTP_IF_MODIFIED_SINCE"]) >= $mt)
(header("HTTP/1.1 304 Nincs módosítva");
meghal;
}
header("Utoljára módosítva: ".$mt_str);
echo $szöveg;
header("Vary: Accept-Encoding");
header("Accept-Encoding:gzip,deflate,sdch");
?>
Tehát csak annyit kell tennie, hogy másolja ezt a kódot, és hozzáadja a fájlhoz header.php A te témád FELETT . Azok. ez a kód a fájl legtetején, a kód többi része ELŐTT található
Figyelem! Mielőtt bármit hozzáadna, mentse el ezt a fájlt a számítógépére, hogy visszaállíthassa az eredeti verziót, ha az Ön verziója nem teszi lehetővé az ilyen fejléc-konfigurációt.
Ellenőrizzük az eredményt a szolgáltatáson a Last-Modified és If-Modified-Since fejlécek ellenőrzésére http://last-modified.com/ru/if-modified-since.html
Voálá! A Last-Modified és If-Modified-Since fejlécek megfelelő beállításával egy csomó bónuszt kaptunk:
Greenwichi idő. A HTTP-dátumok mindig GMT-ben vannak kifejezve, soha nem helyi időben.
| Leírás | Cím |
|---|---|
| RFC 7232, 3.3 szakasz: If-Modified-Since | Hypertext Transfer Protocol (HTTP/1.1): Feltételes kérések |
Az ezen az oldalon található kompatibilitási táblázat strukturált adatokból jön létre. Ha hozzá szeretne járulni az adatokhoz, kérjük, nézze meg a https://github.com/mdn/browser-compat-data webhelyet, és küldjön lehívási kérelmet.
Frissítse a kompatibilitási adatokat a GitHubon
| Asztali | Mobil | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Króm | él | Firefox | internet böngésző | Opera | szafari | android webview | Chrome Androidra | Firefox Androidra | Opera Androidra | Safari iOS rendszeren | Samsung internet | |
| Ha-Módosítva-Azóta | Chrome teljes támogatásIgen | Edge Teljes támogatás 12 | Firefox Teljes támogatásIgen | IE Teljes támogatás Igen | Opera Teljes támogatásIgen | Safari Teljes támogatás Igen | WebView Android Teljes támogatás Igen | Chrome Android Teljes támogatás Igen | Firefox Android Teljes támogatásIgen | Opera Android Teljes támogatás Igen | Safari iOS Teljes támogatás Igen | Samsung Internet Android Teljes támogatás Igen |
A Last-Modified HTTP fejléc közli az ügyféllel, hogy mikor módosították utoljára az oldalt (objektumot). Ha a kliens (böngésző, keresőrobot) megkapta a Last-Modified fejlécet, akkor a legközelebbi cím elérésekor, feltéve, hogy az oldal (objektum) a helyi gyorsítótárban van, hozzáadja az If-Modified-Since kérdést (hogy az oldal megváltozott az Utolsó módosítás dátuma óta). A szervernek viszont, miután megkapta az If-Modified-Since kérést, ellenőriznie kell a beérkezett időbélyeget az oldal utolsó módosításának időpontjával, és ha az oldal nem változott, akkor a 304-es nem módosítva választ kell adnia.
Ha az oldal nem változott, akkor a 304-es nem módosított kódú fejlécek elküldése után a szerver leállítja az adatátvitelt, az oldal törzse, képek és egyéb objektumok nem kerülnek továbbításra.
Az oldal utolsó módosítási idejének ellenőrzésének helyes végrehajtása jelentősen (akár 30%-kal vagy még többet) csökkentheti a szerver terhelését. A helyes megvalósítás azt jelenti, hogy ellenőrizni kell az oldalgenerálás megkezdése előtti időt egy dinamikus webhelyen. Ebben az esetben az oldal létrehozásához szükséges összes művelet (tartalom lekérése az adatbázisból, sablonok elemzése, megjegyzések fogadása stb.) nem kerül végrehajtásra. Ez különösen igaz azokra a webhelyekre, amelyek nagy forgalmúak, és a felhasználó hosszú ideig látogatja. Példa: Egy felhasználó egy sporthíroldalon tartózkodik, és folyamatosan frissíti a kezdőlapot, várva a mérkőzés eredményének közzétételét. Néhány perc alatt több tucatszor lehet kérni és fogadni egy oldalt. Ha a Last-Modified fejlécet megadtuk, és az If-Modified-Since kérést megfelelően dolgoztuk fel, akkor az oldal ténylegesen egyszer kerül elküldésre, és minden további kérés 304-es nem módosított választ kap.
A keresőmotorok azt javasolják, hogy küldje el a Last-Modified fejlécet, és megfelelően kezelje az If-Modified-Since-t a webmesteri irányelvek segítségével.
Győződjön meg arról, hogy webszervere támogatja az If-Modified-Since HTTP fejlécet. Ez a fejléc lehetővé teszi a webszerver számára, hogy közölje a Google-lal, ha a webhely tartalma megváltozott az utolsó feltérképezés óta. Ennek a funkciónak a támogatása csökkenti a terhelést áteresztőképességés költségek.
Google: Webmesteri útmutató
Győződjön meg arról, hogy a HTTP-fejlécek helyesek. Különösen fontos a szerver által az If-Modified-Since kérésre adott válasz tartalma. A Last-Modified fejlécnek a dokumentum utolsó módosításának helyes dátumát kell visszaadnia. Még akkor is, ha a szerver nem adja meg a dokumentum utolsó módosításának dátumát (Last-Modified), webhelye indexelve lesz. Ebben az esetben azonban a következőket kell figyelembe venni:
- a keresési eredmények nem jelenítik meg a dátumot webhelye oldalai mellett;
- dátum szerint rendezve a webhely nem lesz látható a legtöbb felhasználó számára;
- a robot nem tud információt szerezni arról, hogy a webhely oldala frissült-e az utolsó indexelés óta. És mivel korlátozott az oldalak száma, amelyeket a robot egy látogatás során kap az oldalról, a megváltozott oldalak ritkábban kerülnek újraindexelésre.
