Nach dem Sturm: Home - Publications - Articles - Meta Tags - Tips for Tags

Home

Publications

Articles

The Zen of Serving Web Pages

The Connection between Browser and Server

What Sound Does a Web Hit Make?

Nine Aspects of a Web Log Entry

The Philosophy of Hits, Views, and Visits

How to Recognize a Human Being

Words and Their Meaning

Meta Tags

Of Robots and Search Engines

Tips for Tags - The Basics

Tips for Tags - Advanced

Tipps für Tags - Für Experten

Von Christian Treber, Experte für Internet-Anwendungen

Die bisher beschriebenen Tags werden von praktisch allen Suchmaschinen im Internet verstanden. Darüber hinaus gibt es Tags,

die im Internet nur von einigen Suchmaschinen unterstützt werden
die von bestimmten Werkzeugen wie z. B. Webcontentmagementsysteme verwendet und ausgewertet werden
deren Verwendung zukünftig Bedeutung haben könnte (s. a. "Dublin Core Meta Tags[1]").

Ich empfehle die Verwendung der folgenden speziellen Tags:

author: Der Autor des Dokuments.

In Verbindung mit der Emailadresse nützlich, um einen Ansprechpartner ausfindig machen zu können (z. B. "Christian Treber, (ctreber@hotmail.com)").

language: Die Sprache, in der das Dokument abgefasst ist (Sprachkürzel nach RFC 1766/ISO 639 (http://www.oasis-open.org/cover/iso639a.html); z. B. "de" für Deutsch, "en" für Englisch, "fr" für Französisch). Die Suchmaschine erkennt die Sprache bei längeren Texten meist selbst.

Eine Hilfestellung besonders bei kurzen Texten kann jedoch nicht schaden.

Diese Tags können mit Index-Suchmaschinen (Z. B. Altavista) gezielt durchsucht werden. Verwenden Sie dazu Ausdrücke der Form "name des tags:suchbegriff", also zum Beispiel "author:treber" oder "language:fr". Beim ersten Beispiel werden nur Dokumente gefunden, deren Autor Herr Treber ist. Taucht das Wort "treber" nur im normalen Text auf, wird das Dokument nicht im Suchergebnis angezeigt.

Das folgende Tag (hilft der Suchmaschine bei der Darstellung von Umlauten, Akzenten etc.) sollte ebenfalls aufgenommen werden, um den Suchmaschinen ü, ä usw. gegebenenfalls für Ihre Seiten richtig zu interpretieren.:

<meta http-equiv="content-type" content="text/html; 
charset=iso-8859-1">

Weitere ggf. sinnvolle Tags:

revisit-after:

Zeitraum, nach dem der Robot der Suchmaschinen prüfen soll, ob sich die Seite geändert hat (z. B. "20 days"). ·

expires:

Zeitpunkt, zu dem der Robot der Suchmaschinen prüfen soll, ob sich die Seite geändert hat (z. B. "2000-06-16").

Beispiel-Schablone:

<html>

<head>
<title>Sprechender Titel</title>
<meta name="keywords" content="Markante Schlagwörter und 
Synonyme; evtl. mehrsprachig">
<meta name="description" content="Kurze Beschreibung 
des Inhalts">
<meta name="author" content="Name des Autors, ggf. 
Email-Adresse">
<meta name="date" content="Datum der letzten Änderung">
<meta name="einheit" content="Name der Organisationseinheit 
gem. Styleguide">
<meta name="language" content="Sprachkürzel">
<meta name="location" content="Standort gem. Styleguide">
<meta http-equiv="content-type" content="text/html; 
charset=iso-8859-1">
</head>

<body>
Ihr Text - Bilder bitte mit ALT-Attribut versehen
</body>

</html>

Die Angabe von "zusätzlichen" oder "eigentlich überflüssigen" Meta-Tags ist für die Darstellung der Seite nicht schädlich, so dass man eigentlich nichts falsch machen kann.

Ausnahmen:

Die exzessive Wiederholung von Schlüsselwörtern kann dazu führen, dass die Seite nicht in den Index aufgenommen wird, weil die Suchmaschine dieses Merkmal als Spamming-Versuch (Werbung mit unlauteren Mitteln) interpretiert. Die Angabe eines zu kurzen Revisit-Intervalls kann aus den gleichen Gründen zum Ausschluss führen.

Dublin Core Meta Tags[#1]

Der Dublin Core-Standard (Informationen und Details siehe http://purl.org/dc/) definiert einheitliche Meta-Tags und, das ist besonders wichtig, ihre Semantik (Bedeutung). Noch werden diese Tags nicht breit unterstützt; es bleibt jedoch zu hoffen, dass der Standard bald größere Verbreitung erlangen wird.

Sie können diese Tags bereits jetzt zusätzlich zu den oben genannten verwenden und ihre Dokumente heute "bereit für die Zukunft" machen.

Die Tags:

Tag-Name	Bedeutung
DC.Title	Titel des Dokuments
DC.Subject	Inhalt in Stichpunkten
DC.Description	Beschreibung
DC.Source	Angabe von sekundären Quellen
DC.Language	Sprache
DC.Relation	Beziehung zu anderen Dokumenten (z. B. "IsVersionOf", "IsPartOf")
DC.Coverage	Angaben über geographische, zeitliche, organisatorische etc. Gültigkeitsbereiche
DC.Creator	Autor Ersteller
DC.Publisher	Verantwortliche Person
DC.Contributer	Co-Autoren
DC.Rights	Rechtliche Angaben
DC.Date	Erstellungsdatum
DC.Type	Kategorie (Homepage, Arbeitspapier, Artikel etc.)
DC.Format	Wird noch definiert
DC.Identifier	URL, ISBN-Nummer etc.

Ausschluss von Robots

robots.txt

Die Datei robots.txt wird im Wurzelverzeichnis des Webservers abgelegt (das Verzeichnis, das bei http://servername angesprochen wird).

Der Inhalt der Datei robits.txt, um Robots von allen Seiten des Verzeichnisses fernzuhalten:

User-agent: * 
Disallow: / 
"robots" Meta-Tag

Das Meta-Tag ist in die betroffene Seite aufzunehmen. Inhalt, um alle Robots von dieser Seite und allen referenzierten ("verlinkten") Seiten ausschließen:

<meta name="robots" content="noindex, nofollow">

Die Bedeutung der Optionen:

index: Diese Seite indexieren
noindex: Diese Seite nicht indexieren
follow: Links auf dieser Seite weiterverfolgen
nofollow: Links auf dieser Seite weiterverfolgen

Das Standardverhalten der Robots ist "index, follow".

Kontrolle des Caching-Verhaltens

Caching ist ein Verfahren um Zugriffe auf das Web zu beschleunigen und den Datenverkehr zu verringern.

Allgemein richtet beim Caching der Client (z. B. ein Webbrowser) eine Anfrage nicht direkt an den Zielrechner, sondern zunächst an eine Zwischeninstanz (Proxy). Liegt das angeforderte Datum bereits im Zwischenspeicher (Cache) des Proxy vor, kann die Anfrage schnell beantwortet werden. Ist das Datum nicht vorhanden, fordert der Proxy die Information vom Zielrechner an, legt sie im Cache ab und gibt sie an den Aufrufer weiter.

Ein Problem dabei ist, dass der Proxy entscheiden muss, ob eine Information im Cache noch aktuell ist oder neu vom Zielrechner geholt werden muss. Die an den Webbrowser gelieferte Seite ist unter Umständen nicht mehr aktuell. Verschärft wird das Problem dadurch, dass zum einen der Webbrowser selbst ein Caching durchführt, und zum anderen Proxies oft selbst wieder Proxies verwenden (Cascading Proxy).

Das Speichern veralteter Seiten in Caches wird vor allem dann ein Problem, wenn es sich nicht um (relativ selten geänderte) statische Webseiten handelt, sondern die Seiten von einer Webapplikation dynamisch generiert werden. In diesem Fall werden z. B. bei Suchmaschinen veraltete Trefferlisten zurückgeliefert.

Es gibt mehrere Möglichkeiten, das Caching auszuschalten. Dabei ist zwischen dem Caching im Browser und dem Caching durch Proxies zu unterscheiden. Proxy Cache

Proxies verfolgen in der Regel die folgende Strategie:

Falls Informationen im HTTP-Header das Caching explizit verbieten, wird der Proxy das auch nicht tun und das Objekt immer neu vom Zielrechner laden. Falls für das Objekt eine Authentifzierung erforderlich ist oder eine SSL-Verbindung zum Einsatz kommt, wird der Proxy das Objekt nicht cachen. Falls kein "Last-Modified" oder "ETag" (s. u. ) mitgesendet wird, wird der Proxy das Objekt wahrscheinlich nicht cachen.

Ein Objekt wird als aktuell eingestuft und aus dem Cache zurückgeliefert, wenn

"Expires" oder "max-age" (s. u.) gesetzt ist und die Parameter in den Limits liegen Wenn das Objekt bereits im Rahmen der aktuellen Session vom Zielrechner geladen wurde. Wenn das Objekt erst kürzlich vom Zielrechner geladen wurde und sich das Objekt in Relation dazu schon lange nicht mehr geändert hat (heuristisches Verfahren).

Im anderen Fall prüft der Proxy, ob sich das Objekt zwischenzeitlich geändert hat, und lädt das Objekt ggf. neu. Die Prüfung erfolgt über die Anforderung der "Last-Modified"-Information, d.h. es muss nicht das gesamte Objekt übertragen werden.

Proxies schauen in den Inhalt der Webseiten, die sie transportieren und speichern, in der Regel nicht hinein. Deshalb haben Tags in der Webseite an dieser Stelle keine Wirkung. Es ist aber möglich, dem Proxy über Felder im HTTP-Header Hinweise zum Caching zu geben. Diese Headerinformationen können von der Webapplikation zusammen mit der erzeugten Seite gesendet werden.

[HTTP|TechHTTP_en ] 1.0: 

Expires: Fri, 30 Oct 1998 14:19:41 [GMT|TechGMT_en ]

Zeitpunkt, ab dem die Seite als veraltet betrachtet werden soll.

Last-Modified: Mon, 29 Jun 1998 02:28:12 [GMT|TechGMT_en ]

Zeitpunkt der letzten Änderung. Der Proxy kann den Header eines Objekt anfordern und anhand dieser Information prüfen, ob sich das Objekt verändert hat. Im verkürzten Verfahren fordert der Proxy die Seite mit dem HTTP-Header "If-Modified-Since datum und uhrzeit" an. Der Server wird die Seite nur senden, wenn das Modifikationsdatum des Objekts neuer als das Referenzdatum ist.

HTTP 1.1:

Cache-Control: max-age=3600, must-revalidate

Details s. u.

ETag: "3e86-410-3596fbbc"

Eindeutiger, vom Server vergebener Bezeichner für das Objekt. Analog zu "If-Modified-Since" sendet der Proxy die Anfrage mit dem HTTP-Header "If-None-Match" an den Webserver. Dieser wird nur dann das Objekt schicken, wenn sich das ETag verändert hat.

Folgende Parameter für Cache-Control werden unterstützt:

max-age=: Das maximale Alter in Sekunden (ähnlich wie Expires, aber nicht auf absolutes Datum bezogen).
s-maxage=: Wie max-age, bezieht sich aber nur auf Proxy-Caches (nicht auf Browser-Cache).
public: Erlaubt auch das Cachen von Seiten, für die eine Authentifizierung zu Durchlaufen ist.
no-cache: Keine Caching durch Proxies und Browser. Für jede Anfrage ist zu prüfen, ob eine neuere Version des Objekts vorliegt.
must-revalidate: Instruiert Caches, Anweisungen hinsichtlich Caching strikt zu befolgen.
proxy-revalidate: Wie must-revalidate, bezieht sich aber nur auf Proxy-Caches (nicht auf Browser-Cache).

Beispiel für einen HTTP 1.1-Header mit Kontrollinformationen zum Caching:

HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 [GMT|TechGMT_en ]
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 [GMT|TechGMT_en ]
Last-Modified: Mon, 29 Jun 1998 02:28:12 [GMT|TechGMT_en ]
ETag: "3e86-410-3596fbbc"
Content-Length: 1040
Content-Type: text/html

Es gibt auch so genannte "pragma" HTTP-Header, deren Semantik aber weder eindeutig definiert wird noch deren Beachtung durch Proxies allgemein erwartet werden kann. Deshalb wird von der Benutzung dieser Header abgeraten. Browser Cache

Der Browser wertet den Inhalt der Webseite aus, denn schließlich muss der HTML-Code für die Anzeige interpretiert werden. Das Cachingverhalten des Browsers läßt sich daher sowohl über HTTP-Header als auch über Meta-Tags steuern.

Es sei darauf hingewiesen, dass die Verwendung von Tags im HTML-Quelltext zur Beeinflussung des Cachings eine unsichere Methode ist. Es gibt keine Standards, die ein entsprechendes Verhalten des Browsers festlegen. Die Version 5 des Microsoft Internet Explorers ("MSIE") zum Beispiel ignoriert das "pragma no-cache"-Tag völlig (http://support.microsoft.com/support/kb/articles/Q222/0/64.ASP).

Die Tags im einzelnen, um das Caching einer Seite zu verhindern:

<meta http-equiv="pragma" content="no-cache"> 
<meta http-equiv="expires" content="-1">

Hinweis: Es handelt sich hierbei um spezielle Meta-Tags. Mit "http-equiv" wird signalisiert, dass der "content" so interpretiert werden soll, als ob der Text Bestandteil des HTTP-Headers gewesen ist.