Last-Modified, <lastmod>, If-Modified-Since
ofwel
Het nut van de Last-Modified HTTP header response of in de sitemap.xml inhoud

Introductie (Home)

Basis benodigheden

Goals en Ethiek

Veel Geduld Nodig

Website Leeftijd

Googlebot Bezoek

Google's Indexering

Google's Instabiliteit

Supplemental Index

W3C validatie

Googlebot Detectie

Google Account

Zoekmachine Optimalisatie

Teller op je Website

Page Rank (PR)

Last-Modified

Sitemaps

Robots.txt

Frames en Fabels

Hoe Zoekt Google

Link Populariteit

Resultaten

27-juli-2007 geschreven. Bijgewerkt: 25 jan. 2008
Een ervaringsverhaal over zoekmachine optimalisatie voor beginnende websites. Doe je voordeel ermee.

LASTMODIFIED, HEADERS EN ZOEKMACHINES:

Hoewel het voor mij onduidelijk is welke informatie van de headers, die worden geretourneerd bij het opvragen van een pagina door de spider (googlebot), van belang zijn meende ik dat de <lastmod> info in de sitemap of een goede response op de HTTP-header If-Modified-Since niet mochten ontbreken. Dit is immers de informatie waaraan de spider zal kunnen zien of de pagina sinds zijn laatste bezoek is gewijzigd of niet? De HTTP-headers kunnen b.v. getest worden in deze HTTP viewer.

Het ontbreken van deze "Last-Modified" header return regel betekent ook dat bij het samenstellen van een sitemap.xml alle lastmodified data gelijk aan de tijd van dat programmagebruik werd gemaakt en geen relatie heeft met de eigenlijke "Last-Modified" datum-tijd op je server. Overigens doet de googlebot waarschijnlijk niets met de <lastmod> datum uit de sitemap. Die klopt immers maar zelden. Meestal worden sitemaps niet automatisch vernieuwd omdat daar speciale software voor op de server moet worden geïnstalleerd door de gebruiker. De <lastmod> info in de sitemap is òf te oud òf te nieuw, omdat als de sitemap wordt gemaakt met een programma op de PC of van internet en de server geen goede HTTP-header retourneert, alle files de aanmaakdatum van de sitemap meekrijgen, ook al is er geen enkele file vernieuwd behalve de sitemap zelf. Ergo de <lastmod> info klopt heel vaak niet en dus er kan ook geen enkele spider op vertrouwen. Dit nog afgezien van het feit dat de datum door de gebruiker manipuleerbaar is en dus ook onbruikbaar voor een spider als betrouwbare parameter.

Het valt echter wel op dat de googlebot ook regelmatig voor de website (alleen dus voor "-", dus het opvragen van de hoofdpagina, index.html of index.php) pagina alleen de HTTP-header opvraagt en niet naar de inhoud van de pagina kijkt (commando HEAD in ca de helft van de googlebot bezoeken aan de hoofdpagina). Na toevoeging van onderstaande software ter verkrijging van de juiste Last-Modified informatie en daarmede ook de 304 "not modified" response indien nodig, valt nu op bij het analiseren van de access_log file dat de googlebot regelmatig van alle html pagina's nu een 304 "not modified" return krijgt. Voorheen gebeurde dit alleen bij alle andere extensies zoals .pdf of .xml zoals de sitemap.xml file. Dat betekent dus dat googlebot tegen een door hem opgegeven datum van zijn laatste bezoek of cache verifiëert of de file sindsdien gewijzigd is of niet. Waarschijnlijk wordt tegen de laatste cache datum gechecked. Krijgt hij dan de 304 return dan wordt de file ook niet gelezen en wordt de GET functie afgebroken. Dat is eenvoudig vast te stellen omdat er dan geen email meldingen komen van de googlebot detector die pas geactiveerd wordt als de pagina daadwerkelijk wordt uitgelezen. Dat betekent dus een grote ontlasting van de server. Providers doen er dus maar beter aan wel degelijk de "lastmod" info te retourneren in de header. Sinds ik zelf nu deze "Last-Modified" info in de header retourneer is de strategie van de googlebot duidelijk aan het veranderen. Heel vaak een datumcheck met een 304 return en dus geen uitlezing van de files meer. Tevens wordt regelmatig de cache datum in google OOK BIJ een 304 return aangepast zonder dat de inhoud van de cache wordt vernieuwd.

In de: http://www.google.com/support/webmasters/ hoodstukje technische richtlijnen kunnen we lezen "Controleer of webserver de HTTP-header If-Modified-Since ondersteunt" hetgeen vaak niet het geval is. Zodra html pagina's ook php worden geparsed door de server bleek bij mijn provider de ondersteuning van deze HTTP-header verloren te zijn gegaan. Die moest ik dus zelf weer herstellen.

Andere info zoals Content-Length kan mogelijk ook een beslissende rol spelen in de reacties van de googlebot. Content-length boven de ca 8k wordt echter niet geretourneerd door de servers van mijn provider ook alleen weer voor .html en .php files in de hoofddirectory. De header geeft dan altijd de melding "chunked" waarbij dus verdere gegevens worden verstrekt zonder dat de lengte bekend is. De reden van de server is dat pagina's dan kennelijk teveel server geheugenruimte opslokken tijdens het retourneren van de header informatie. Zodra echter de file via een GET wordt uitgelezen kan de bot zelf bepalen wat de content-length is. Is deze hetzelfde als die van de file in cache dan kan de bot besluiten dat file vrijwel zeker niet is gewijzigd. Of Content-Lenght werkelijk een rol speelt bij de googlebot acties is mij niet bekend.

Omdat de Last-Modified info was gaan ontbreken door het php parsen van de html files, worden deze door mijn webpagina's (sinds april 2007) op de server nu door de pagina zelf gegenereerd. Een klein php file'tje op de server geplukt van internet en een "include php" op elke pagina zorgen voor de juiste informatie op de server. Dit is het resultaat, althans bij mijn website server met toevoeging het php file'tje. Voor geïnteresseerden kan je het php file'tje downloaden. Je zet het op de server en renamed het naar handle304.php. In een webpagina roep je dat aan door helemaal bovenaan zonder dat er ook maar iets voorstaat, nog geen spatie, de volgende aanroep te zetten:

<?php
include("handle304.php");
setModifiedDate( filemtime(__FILE__) );
?>

Dit zal de file aanroepen en uitvoeren voordat de server de rest van de pagina gaat bekijken. Het file'tje voegt aan de HTTP header de regel Last-Modified toe met de juiste datum en tijd van de betreffende pagina. De server moet dan wel de html files als php parsen wat vermeld wordt in de .htaccess file (zie stukje in googlebot detectie).
Resultaat bij mijn server is nu:

Receiving Header:
HTTP/1.1·200·OK(CR)(LF)
Date:·Thu,·26·Jul·2007·16:57:39·GMT(CR)(LF)
Server:·Apache/2.0.52·(Fedora)(CR)(LF)
X-Powered-By:·PHP/4.3.11(CR)(LF)
Last-Modified:·Tue,·24·Jul·2007·17:54:40·GMT(CR)(LF)
Content-Length:·5170(CR)(LF)
Connection:·close(CR)(LF)
Content-Type:·text/html(CR)(LF)
(CR)(LF)

Zoals gezegd de regel: Last-Modified:·Tue,·24·Jul·2007·17:54:40·GMT(CR)(LF) ontbrak bij mijn originele server informatie door de php parsing van de html files. De datum van google's cache wordt soms aangepast aan een van de laatste googlebot bezoekdatums, ook als de pagina niet is gewijzigd. Als de pagina wel is gewijzigd heb ik overigens niet de indruk dat de cache sneller wordt aangepast, het blijft een random gebeuren. Wil je dat bij het automatisch genereren van de juiste Last-Modified info in de sitemap.xml de goede informatie wordt vermeld dan zal de HTTP-header deze toch moeten retourneren. Een feit blijft dat de Last-Modified informatie weinig houvast biedt voor googlebot beslissingen anders dan het niet uitvoeren van de GET, waarmee de server dus wordt ontlast en een cache datum eventueel toch kan worden aangepast.
email:robvh@onsnet.nu

Valid XHTML 1.0!
introductie | basis_benodigdheden | goals_en_ethiek | veel_geduld_nodig | website_leeftijd | googlebot_bezoek | google's_indexering | google's_instabiliteit | supplemental_index | w3c_validiteit | googlebot_detectie | google_account | zoekmachine_optimalisatie | teller_op_je_website | page_rank | last_modified | sitemaps | robots.txt | frames_en_fabels | hoe_zoekt_google | link_populariteit | resultaten