If-Modified-Since und SEO

[hotti]

Moin,

bei google hab ich gelesen "stellen Sie sicher, dass Ihr Server If-Modified-Since unterstützt" u. weiter: "Sie sparen dadurch Bandbreite..."

Also, ich hab das nicht so ganz verstanden und auch eine andere Sache nicht in diesem Zusammenhang, da las ich neulich, dass eine Suchmaschine anhand dieser Headergeschichten erkennt, ob eine Seite dynamisch erzeugt wird oder als Datei vorliegt.

Und jetzt meine Fragen dazu:

Kann es sein, dass google & Co nicht gerne kommt, wenn die Seiten dynamisch erzeugt werden, weil die da jedesmal die komplette Seite neu requesten müssen?

Das ist dann wohl so, dass google & Co gerne schon anhand des Headers sehen will, obs was Neues auf der Site gibt?

Wird so ein (google & Co)-freundlicher Header nur erzeugt, wenn HTML-Seiten auch als Datei vorliegen?

Oder: Wie kann ich Letzteres selbst beeinflussen und überhaupt: Wie sieht denn so ein header aus, von einem Server, der "If-Modified-Since" unterstützt?

Viele Grüße,
Horst

[Felix Riesterer]

Lieber hotti,

--
Hotti is doof

wirklich?

Liebe Grüße,

Felix Riesterer.

[Der Martin]

Hallo,

bei google hab ich gelesen "stellen Sie sicher, dass Ihr Server If-Modified-Since unterstützt" u. weiter: "Sie sparen dadurch Bandbreite..."

ja, mag durchaus sein. Man schafft dadurch die Möglichkeit, dass der Client nicht stur die Seite X anfordert, sondern sagen kann: "Ich habe Seite X vom 17.07.2009 22:48h im Cache und brauch jetzt die aktuelle."  Und dann antwortet der Server entweder mit Status 304 Not Modified, wenn die Version beim Client noch aktuell ist, oder er liefert eben die komplette Seite mit Status 200 aus (das tut er auch, wenn er den If-Modified-Since-Header nicht kennt oder auswertet).
Man spart also Bandbreite, indem man gecachte Versionen einer Ressource verwendet, *wenn* die noch aktuell sind, und dennoch nicht "blind" auf den Cache vertraut.

Also, ich hab das nicht so ganz verstanden und auch eine andere Sache nicht in diesem Zusammenhang, da las ich neulich, dass eine Suchmaschine anhand dieser Headergeschichten erkennt, ob eine Seite dynamisch erzeugt wird oder als Datei vorliegt.

Kann ich mir nicht vorstellen. Dieser "Conditional Request" und auch die Reaktion des Servers darauf ist nicht davon abhängig, ob die Seite ststisch oder dynamisch erzeugt wird.

Kann es sein, dass google & Co nicht gerne kommt, wenn die Seiten dynamisch erzeugt werden, weil die da jedesmal die komplette Seite neu requesten müssen?

Keine Ahnung, frag Google.

Oder: Wie kann ich Letzteres selbst beeinflussen und überhaupt: Wie sieht denn so ein header aus, von einem Server, der "If-Modified-Since" unterstützt?

Siehe oben. Apache reagiert standardmäßig so.

Schönes Wochenende,
 Martin

[hotti]

hi,

Also, ich hab das nicht so ganz verstanden und auch eine andere Sache nicht in diesem Zusammenhang, da las ich neulich, dass eine Suchmaschine anhand dieser Headergeschichten erkennt, ob eine Seite dynamisch erzeugt wird oder als Datei vorliegt.

Kann ich mir nicht vorstellen. Dieser "Conditional Request" und auch die Reaktion des Servers darauf ist nicht davon abhängig, ob die Seite ststisch oder dynamisch erzeugt wird.

Konkret verstehe ich das so:

UA(egal) steckt in den Request-Header die Frage:
"If-Modified-Since: date_time_x"
wobei date_time_x das Datum+Uhrzeit ist, was UA im Cache hat, weil UA die Seite schonmal requestet hat vor einiger Zeit.

Der Webserver, der das unterstützt, schreibt in den Header:
"Last Modified: date_time_y"
wobei er für y das Dateidatum nimmt, sofern es eine HTML-Datei ist, die direkt aus dem Dateisystem gezogen wird. Wurde jedoch ein CGI-Script requestet, was zur Laufzeit erzeugt wurde, ist dieses Header-Field nicht vorhanden (dynamischer Content).

UA(egal): Mozilla, FF, IE, google & co...

Hab ich das so richtig verstanden?

Hotti

[Der Martin]

Hallo,

Dieser "Conditional Request" und auch die Reaktion des Servers darauf ist nicht davon abhängig, ob die Seite ststisch oder dynamisch erzeugt wird.

UA(egal) steckt in den Request-Header die Frage:
"If-Modified-Since: date_time_x"
wobei date_time_x das Datum+Uhrzeit ist, was UA im Cache hat, weil UA die Seite schonmal requestet hat vor einiger Zeit.

Richtig.

Der Webserver, der das unterstützt, schreibt in den Header:
"Last Modified: date_time_y"
wobei er für y das Dateidatum nimmt, sofern es eine HTML-Datei ist, die direkt aus dem Dateisystem gezogen wird. Wurde jedoch ein CGI-Script requestet, was zur Laufzeit erzeugt wurde, ist dieses Header-Field nicht vorhanden (dynamischer Content).

Diesen Header gibt er auch aus, wenn er das If-Modified-Since nicht versteht oder nicht verstehen "will".
Das Entscheidende ist jedoch der HTTP-Status der HTTP-Response. Der ist "304 Not Modified", wenn der Server mitteilen will: Ja, deine gecachte Version ist noch aktuell, ich hab auch nichts neueres.
Im anderen Fall sendet er ganz normal einen Status 200 und liefert die angeforderte Ressource aus.

Durch diesen Mechanismus ist der Conditional Request vollständig abwärtskompatibel zu HTTP-Servern und -Clients, die das nicht kennen.

Ciao,
 Martin

[Malcolm Beck´s]

hi,

UA(egal) steckt in den Request-Header die Frage:
"If-Modified-Since: date_time_x"
wobei date_time_x das Datum+Uhrzeit ist, was UA im Cache hat, weil UA die Seite schonmal requestet hat vor einiger Zeit.

Der Webserver, der das unterstützt, schreibt in den Header:
"Last Modified: date_time_y"
wobei er für y das Dateidatum nimmt, sofern es eine HTML-Datei ist, die direkt aus dem Dateisystem gezogen wird. Wurde jedoch ein CGI-Script requestet, was zur Laufzeit erzeugt wurde, ist dieses Header-Field nicht vorhanden (dynamischer Content).

Vergleich doch mal die ganz einfachen Header-Ausgaben deiner Seite, die gesendet werden:

Startseite

Date: Sat, 18 Jul 2009 09:17:15 GMT
Server: Apache
Last-Modified: Fri, 17 Jul 2009 18:56:44 GMT
Etag: "285ea8c1-121c-46eeb597b52c9"-gzip
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1822
Connection: close
Content-Type: text/html

http://rolfrost.de/cgi-bin/news.cgi

Date: Sat, 18 Jul 2009 09:18:46 GMT
Server: Apache
Cache-Control: no-cache;
Pragma: no-cache;
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 5515
Connection: close
Content-Type: text/html;

Ich gehe mal stark davon aus, dass die Startseite eine Statiche Ressource ist.

Jedenfalls kann man auf deinem Server den von Edgar beschriebenen Apache-Bug sehen, da dein Server zwar Etag und Last-Modified sendet, die Ressourcen aber immer neu ausgeliefert werden (Status 200), also keine 304-Not-Modified, auch für deine CSS (Header auslesen).

Vielleicht hilft dir schon ein (ich weiss aber nicht, ob dass auch in Verbindung mit mod_deflate funktioniert, ich zippe meine Ressourcen mit PHP):

<FilesMatch "\.(html|htm|jpg|jpeg|gif|png|mp3|flv|mov|avi|html|swf|css|js|ico)$">  
## Expires  
  ExpiresActive On  
  ExpiresDefault "access plus 10 years"  
## Etag  
  FileETag MTime Size  
## Cache-Control  
  Header set Cache-Control "public, no-transform"  
</FilesMatch>

mfg

[hotti]

hi,

Ich gehe mal stark davon aus, dass die Startseite eine Statische Ressource ist.

Ja, alles was bei mir mit .html endet, sind echte Dateien ;-)

[..] Apache-Bug sehen, da dein Server zwar Etag und Last-Modified sendet, die Ressourcen aber immer neu ausgeliefert werden (Status 200), also keine 304-Not-Modified, auch für deine CSS (Header auslesen).

Schon gesehen, ja...

Vielleicht hilft dir schon ein (ich weiss aber nicht, ob dass auch in Verbindung mit mod_deflate funktioniert, ich zippe meine Ressourcen mit PHP):

Danke auch Dir, ich lasse erst mal alles so wie es ist. Aber eine Frage hab ich noch, das ist mir noch nicht ganz klar und beim TCP-Dumpen aufgefallen:

Datum/Uhrzeit von "If-Modified-Since" (request) und "Last Modified" (response) sind absolut gleich, auch nachdem ich den Cache geleert habe. Wie läuft denn das im Einzelnen ab, das Header-Geschwätz? Gerne auch'n Link.

Viele Grüße,
Hotte

[ChrisB]

Hi,

Konkret verstehe ich das so:

UA(egal) steckt in den Request-Header die Frage:
"If-Modified-Since: date_time_x"
wobei date_time_x das Datum+Uhrzeit ist, was UA im Cache hat, weil UA die Seite schonmal requestet hat vor einiger Zeit.

Der Webserver, der das unterstützt, schreibt in den Header:
"Last Modified: date_time_y"

Ja, nur eben "anders herum".

Der Server hat die Ressource bei der ersten Anfrage durch den Client mit einem Last-Modified-Header (neben ggf. weiteren das Caching beeinflussenden) ausgeliefert.

Der Nutzer fordert die Seite jetzt erneut an; Client schaut in seinen Cache und merkt, die hab' ich eigentlich schon. Also frag ich mal beim Server nach, ob die sich inzwischen geändert hat - dazu dient If-Modified-Since:
"Hey Server, mein Nutzer interessiert sich für Ressource /XY, aber ich hab da noch eine Version in meinem Cache liegen, von der du mir gesagt hast, dass sie am 18.7.2009 um 17:03:47 Uhr zuletzt geändert wurde. Hat die sich inzwischen geändert? Wenn nein, sag bitte nur kurz Bescheid [304 Not Modified], dann zeig ich dem Typ vorm Bildschirm einfach die Version, die ich noch auf Halde liegen habe, merkt der Pinsel doch eh nich'. Falls du aber was neues hast, dann lass das gleich mal rüberwachsen."

wobei er für y das Dateidatum nimmt, sofern es eine HTML-Datei ist, die direkt aus dem Dateisystem gezogen wird. Wurde jedoch ein CGI-Script requestet, was zur Laufzeit erzeugt wurde, ist dieses Header-Field nicht vorhanden (dynamischer Content).

Das liegt am Server/Script, wie er/es den Zeitpunkt der letzten Änderung ermitteln will (oder auch nicht).
Last-Modified enthält bei Dateien in der Regel wirklich nur den letzten Änderungszeitpunkt, den das Dateisystem hergibt. (Beim ETag ist das anders, da fliessen per Default noch Sachen wie der INode etc. mit ein.)

Aber natürlich kann ein Script, was Daten bspw. aus einer Datenbank ausliest und darüber idealerweise ebenfalls einen letzten Änderungszeitpunkt zur Verfügung hat, natürlich auch entsprechende Angaben an den Client senden und Requests nach noch nicht "veralteten" Ressourcen mit einem 304 beantworten, um Traffic zu sparen. Nur muss man das bei Scripten i.a.R. selber implementieren.

MfG ChrisB

[hotti]

hi Chris,

Donnerwetter, das hast Du aber sehr schön erklärt, vielen Dank!!!

Btw., hab grad ebend mal eine Datei geändert und mir die Dumps angeschaut, im Vergleich mit dem anderen Kram, den ich nicht geändert habe. Wieder was dazugelernt.

Aber natürlich kann ein Script, was Daten bspw. aus einer Datenbank ausliest und darüber idealerweise ebenfalls einen letzten Änderungszeitpunkt zur Verfügung hat, natürlich auch entsprechende Angaben an den Client senden und Requests nach noch nicht "veralteten" Ressourcen mit einem 304 beantworten, um Traffic zu sparen. Nur muss man das bei Scripten i.a.R. selber implementieren.

Ja Freilich. Aber das Beste ist, so wie Eddi geschrieben hat, statischen Content aus statischen Seiten herauszuholen, sofern der Server keine Macke hat, ist das performant, suchmaschinen- und benutzerfreundlich, kurz und gut, gut. Klar kann ich HTML-Content auch aus ner MySQL-Büchse zaubern und hab da automatisch die Möglichkeit der Volltextsuche. Aber irgendwie ist das Overheadig und wenn, so wie bei meinem Provider, der MySQL-Server eine andere Maschine ist wie der Webserver, ist das ja schon der Overkill ;-)

Zumal da noch ne Firewall dazwischenhängt, die eine Drittfirma managed. Mann, was baue ich manchmal fürn Scheis, nur um der Technik willen ;-)

Meine Volltextsuche (find.cgi) sitzt seit gestern auf einer Berkeley-DB, das ist eine Datei, die Perl mit tie() an einen Hash bindet und das flutscht wie die Waldwutzn; ebenso wie auch der FileTransfer mit dem neuen Kabelanschluss, den ich seit Mittwoch habe...

Viele Grüße,
Horst

[Edgar Ehritt]

Hallo,

Also, ich hab das nicht so ganz verstanden und auch eine andere Sache nicht in diesem Zusammenhang, da las ich neulich, dass eine Suchmaschine anhand dieser Headergeschichten erkennt, ob eine Seite dynamisch erzeugt wird oder als Datei vorliegt.

Kann ich mir nicht vorstellen. Dieser "Conditional Request" und auch die Reaktion des Servers darauf ist nicht davon abhängig, ob die Seite ststisch oder dynamisch erzeugt wird.

jain. Prinzipiell hast Du recht. Die meisten Scripte scheren sich aber nicht um das Erzeugen eines Last-Modified-Response-Headers oder/und um die Verarbeitung eines If-Modified-Since-Request-Headers. Das macht aber, wie ich unten noch schreibe, Sinn.
 Somit kann man mit (zumindest) großer Wahrscheinlichkeit davon ausgehen, dass ein fehlender Header Last-Modified einer Ressource aus einer dynamischen Erzeugung herrührt.

Kann es sein, dass google & Co nicht gerne kommt, wenn die Seiten dynamisch erzeugt werden, weil die da jedesmal die komplette Seite neu requesten müssen?

Meines Wissens schweigen sich die Suchmaschinen darüber aus und lassen sich nicht in die Karten gucken.

...Wie kann ich Letzteres selbst beeinflussen ...

Es ist vorallem die Frage, ob Du dies beeinflussen solltest. Denn es hat doch einen Grund, ein Script statt eines statischen Dokuments einzusetzen. Dynamische Inhalte reagieren auf die angelieferten Daten einer Anfrage. Sei dies nun im Falle von CGI-Scripten die HTTP_[VAR-NAME] oder direkte Eingaben in Form fon GET-, Post- oder PUT-Daten. Oder kurz: Jede Anfrage kann andere Inhalte zurückgesandt bekommen. Somit ist die Hin- und Herübertragung von If-Modified-Since-Header und Last-Modified-Headers over head, da sich schlichtweg keine Aussage über den gleichbleibenden Inhalt anhand des Modifizierungsdatums herleiten lässt. In dem Sinne ist die eigentliche Frage nicht, wie man Scripte suchmaschinengerecht aufmotzt, sonder wie man seine Projekte so vernünftig Strukturiert, das gleichbleibende Inhalte statisch serviert werden.

(So, und wo subsumiert man das jetzt? HTTP? Projektverwaltung?)

Gruß aus Berlin!
eddi

[hotti]

hi Eddi,

[..] In dem Sinne ist die eigentliche Frage nicht, wie man Scripte suchmaschinengerecht aufmotzt, sonder wie man seine Projekte so vernünftig Strukturiert, das gleichbleibende Inhalte statisch serviert werden.

Genau. Diese Frage ist mir schon länger beantwortet, nur ein paar Kleinigkeiten zu Details, auf die ich bei meinen letzten Recherchen gestoßen bin, haben noch gefehlt.

Danke und viele Grüße an Alle,
Hotte