Die mitunter lauthals gebrüllte Forderung nach validem HTML oder tabellenlosem Design mag dem Zeitgeist entsprechen, mit Suchmaschinen hat das nichts zu tun. Ein Spider
bewertet solche Kriterien nicht, weil er die Seite nicht darstellen muss. Der Spider verwendet einen groben Hobel - den Parser.
Zunächst sollte man sich vom Gedanken verabschieden, Google würde sauberes, valides HTML aus irgendwelchen "ästhetischen" oder formalen Gründen bevorzugen oder
belohnen. Es wird indexiert, was indexierbar ist - Google kann und muss davon ausgehen, dass Webworker herzeigbare Seiten machen. Es ist nicht Aufgabe einer Suchmaschine, Design nach irgendwelchen
Kriterien zu bewerten. Wenn man die Arbeitsweise des Parser versteht, wird auch klar, warum das sogar einiges an Mehrarbeit bedeuten würde - noch dazu überflüssig, weil die
meisten Seiten mit fehlerhaftem Code auch sonstigen Kriterien nicht entsprechen.
Die Aufgabe des Parsers ist es, nach dem Spidern den Quellcode einer Seite so zu normalisieren, dass der später arbeitende Indexer saubere Daten vorfindet. Diese sauberen Daten
sind keineswegs HTML, sondern ein eigenes, bereinigtes Format.
Der Parser arbeitet sich von "<" zu ">" und wieder weiter zu "<". Die
beiden Buchstaben bedeuten nichts weiter, als dass sich zwischen ihnen ein Tag befindet - zB "a" , der weitere Attribute haben kann, zB "href" mit dem Wert "../index.htm"
Jeder Parser verwendet dabei eine Positivliste, er beachtet also nur das, was ihn interessiert, der Rest wird ignoriert. Das tut übrigens auch der Browser: ein unbekannter Tag, ein unbekanntes
Attribut wird ignoriert, sonst würde ein Browser ja dauernd abstürzen.
Weder Google noch webeye beachten zB die Tags <table>, <tr> und <td> und damit auch keines
der möglichen Attribute.
Anders gesagt: von diesem Konstrukt:
<table width="200" border="2" cellspacing="5" cellpadding="5" title="Wunderwaffe">
<tr class="Superwaffe" id="Megatrick">
<td blabla="oberschlau">Sichtbarer</td>
</tr>
<tr>
<td>Text</td>
</tr>
</table>
bleibt genau nur die Zeichenkette "Sichtbarer Text" über.
Genau dasselbe gilt für DIV-Container:
<div id="Megatrick" title="Wunderwaffe" style="position:absolute; left:52px; top:173px; width:199px; height:35px; z-index:1">Sichtbarer</div>
<div id="Wundertrick" style="position:absolute; left:52px; top:211px; width:199px; height:35px; z-index:2">Text</div>
Damit wird auch klar, warum die oft zitierten Geheimwaffen allesamt Unsinn sind: Es ist nicht möglich, mit irgendwelchen Attributen, für die sich Google nicht interessiert irgendetwas
in den Indexer zu schummeln.
Und was noch klar wird: Genauso wie der Browser ignoriert der Parser nicht-valide Tags oder Attribute. Genauer: Er bemerkt sie gar nicht, weil er sie nicht sucht.
Grobe Fehler
Wie der Parser mit nicht geschlossenen oder falsch verschachtelten Tags umgeht, hängt vom Fall ab: Der Parser enthält natürlich Sicherheitsmechanismen, etwa die Regel: jeder
<h1> (h2.. p, ul...) Tag schließt einen ggf noch offenen Tag.
Ein Beispiel: <a href="index.html" Hier</a> mehr dazu... <table>....
Das Wort "Hier" sieht der Parser nicht, weil er sich nicht für das Attribut "Hier" interessiert und es schon deswegen gar nicht sucht. Er würde entweder keinen
Linktext sehen oder "mehr dazu... " (also alles nach </a>) für den Linktext halten, bis er nach obiger Regel durch einen anderen Tag geschlossen
wird (hier <table>). Möglicherweise werden offene Tags spätestens nach zb 60 Wörtern geschlossen und von da weg als normaler Text gesehen.
Oder: <h1><h2><h3>Keyword</h4> würde als <h3>Keyword</h3> interpretiert werden, weil <h2>
den <h1>-Tag schließt, und <h3> wiederum <h2>. Der Schlusstag </h4> würde jeden <h*> schließen, weil eine Überschrift keine Überschrift
enthalten kann.
Es sind nicht viele solcher Regeln nötig, um jeden noch so fehlerhaften Quellcode irgendwie zu verarbeiten.
Natürlich würde nicht das herauskommen, was sich der Autor gedacht
hat. Der Text würde auch nicht verschwinden, sondern "nur" nicht richtig gewertet werden. Der
Parser versucht nicht zu reparieren, sondern möglichst schnell den
Inhalt eines Dokumentes in eine standardisierte Form zu bringen. Und sicher wird es Knock-Out Regeln geben,
etwa wenn das Verhältnis zwischen Größe des Codes und Größe
des daraus extrahierten Inhaltes einen Grenzwert überschreitet, zb 100k für 30 Wörter.
Geheime Tricks
Ja, das hättet ihr wohl gerne. Die Wahrheit ist: Es wird wohl kurzfristige Schlupflöcher durch Bugs geben, aber wie immer bei der Optimierung greifen Regelwerke der Suchmaschinen
ein. Ein gibt kein Kriterium, das für sich alleine so wirkt, dass eine Seite damit von 0 auf Platz 1 kommt.
Und?
Das bedeutet jetzt natürlich nicht, dass man Kraut und Rüben zusammenbasteln kann, weil es ohnehin egal ist - im Gegenteil. Letztlich macht man Seiten nicht für Suchmaschinen,
sondern für Menschen, die einen Browser benutzen. Im Gegensatz zum Parser muss ein Browser eine Seite auf den Bildschirm bringen. Er muss also weit mehr Tags beachten und richtig interpretieren
können. Wer hier noch unerfahren ist, sollte sich in jedem Fall an das W3C halten und valides HTML/CSS schreiben.
Diese Seite ist übrigens nicht valid. Sie sieht aber in jedem gängigen Browser gleich aus, der alte Netscape 4 macht etwas Mucken, aber es geht.
Nachtrag am 29.05: Es ist wohl Ironie, dass diese Seite beim Suchbegriff "Tabellenloses Webdesign" auf Platz 1 gelandet ist ;-)
|
