Menü

Schönheit liegt im Auge des Betrachters

Valides HTML, tabellenloses Webdesign

Valides HTML, tabellenloses Webdesign

100%  valides HTML oder tabellenloses Webdesign 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>.... 
(Es fehlt das ">" vor "Hier")
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. Es 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.

[OUTDATED]

Kommentare:

Ja bei 797 Treffern ist es ein WUNDERWERK was du Spinner da vollbracht hast^^ loooool

Ratte
Antworten

Hi, ich bin kein Techniker und daher klingen obige Zeile alle logisch für mich. Jedoch möchte ich an dieser Stelle einfach mal meine Erfahrung einbringen. Ich hing etliche Monate zu sehr wichtigen Begriffen auf der 2ten Google-Seite fest. Erst nachdem ich nachweislich "nur" meinen Code validiert habe, sprang meine Seite auf einmal unter die Top3 bei meinen wichtigsten Begriffen. Daher denke ich dass euer letzter Absatz alles ausdrückt! Weiter so...

Heimarbeiter
Antworten

Ein Hinweis auf die Validatoren des W3C wären ggf. noch gut, damit lässt sich vieles verbessern.

CS
Antworten

 
outdated