Der Doctype und SEO

Der Doctype ist die Deklaration der verwendeten HTML-Version auf einer Internetseite.

Er steht im Quelltext jeder Webseite ganz oben, noch vor dem ersten HTML-Tag und beginnt mit „<!DOCTYPE html …>“. Über den Doctype teilt man dem Browser mit, welche HTML-Elemente auf einer Webseite verwendet werden. Anhand dieser Informationen arbeitet die Rendering-Engine des Browsers. Hat eine Webseite den falschen Doctype erkennt der Browser viele HTML-Elemente nicht oder nicht richtig. Das kann im Quellcode einer Webseite zu einer ungeahnten Menge an Fehlern führen. Schlimmstenfalls fällt der Browser, beziehungsweise die Rendering-Engine in den Standard-Modus zurück. Dann versucht der Browser die Webseite so gut wie möglich darzustellen. Das gelingt den Browsern erstaunlich gut, auch bei vielen Fehlern im Code. Das visuelle Ergebnis ist also kein verlässlicher Gradmesser für die Qualität des Seitenquelltextes.

Der Browserkrieg und seine Folgen

Zu verdanken haben wir diese Entwicklung dem damaligen Browserkrieg zwischen Microsoft mit seinem Internet Explorer und Netscape mit dem Netscape Navigator. Jeder der beiden versuchte seinen Browser beziehungsweise seinen Standard weltweit zu etablieren und es gab immer wieder neue Elemente und Weiterentwicklungen. Dabei wurden die Standards des W3C zunächst noch als kleinster gemeinsamer Nenner eingehalten. Im weiteren Verlauf dieser wirtschaftlichen Auseinandersetzung, genauer gesagt mit der Einführung von CSS durch das W3C, wurde selbst dieser Minimalkonsens nicht mehr eingehalten und es kam zu immer weiteren Varianten und Stilblüten. Der (erste) Browserkrieg endete 2003. Im Rahmen dieser Auseinandersetzung wurde Microsoft mit kartellrechtlichen Ermittlungen konfrontiert. Mit einer außergerichtlichen Zahlung in Höhe von 750 Millionen US-Dollar von Microsoft an den Konzern AOL, der Netscape 1998 übernommen hatte, endete dieses Kapitel der Internetgeschichte.

Die Auswirkungen sind aber noch bis heute zu sehen. Nach dem Ende des Browserkieges versuchte das W3C mit unterschiedlichen Standards wieder ein wenig Ordnung in dem Wust aus Features, Weiterentwicklungen, technischem Fortschritt, APIs und vor allem Sicherheitslücken zu schaffen. Das ist aber erst mit der Einführung von HTML5 im Oktober 2014 gelungen. HTML5 ersetzt die vorherigen Standards und beinhaltet viele neue Weiterentwicklungen zum Beispiel für Audio, Video, 3D-Grafik und weitere nützliche Funktionen. Außerdem vereinfacht es die Einbindung des Doctypes im Quelltext zu „<!Doctype HTML>“. Jetzt müssen sich Entwickler nicht mehr mit der Frage beschäftigen, ob HTML 4.01 oder doch eher XHTML 1.0 oder noch ein anderer HTML-Standard der Richtige für eine Website ist und alle Features unterstütz: HTML5 unterstützt alle alten Funktionalitäten und fügt HTML ein paar Neue hinzu, insbesondere für das Web 2.0.

Aktualisieren leicht gemacht

Alle Webseitenbetreiber können auf http://validator.w3.org feststellen ob und wenn ja wie viele Fehler sie aufgrund einer falschen oder veralteten Doctype-Deklaration haben. Und sie können ihre Site relativ einfach auf HTML5 umstellen. Es genügt im „<!Doctype html ….. >“ alles nach html zu löschen, bis auf die spitze Klammer („>“) zum Schluss. Und schon ist die Webseite auf HTML5 umgestellt. Das kann man auch wenn man kein Programmierer ist und Zugang zum Quelltext der Seiten hat. Es bietet sich an vorher einen Screenshot der Validierung auf validator.w3.org anzufertigen und nach der Umstellung das Ergebnis zu vergleichen. Man kann die Umstellung auf HTML5 auch simulieren. Einfach den Reiter „Validate by Direct Input“ auswählen und den aktuellen Quellcode der Seite dort in die Textarea kopieren. Nun muss man noch den Doctype wie oben beschrieben auf HTML5 anpassen und kann die Seite analysieren. Unter dem Reiter „Validate by URI“ kann man die bestehende Seite analysieren. Zum Schluss kann man die Ergebnisse vergleichen. Wir sind uns sicher, die Zahl der Fehler wird deutlich zurück gehen. Dieses Verfahren empfiehlt sich auch für große Seiten wie zum Beispiel Spiegel Online .

Probleme können natürlich auftreten, wenn man es mit CMS-Systemen zu tun hat. Da diese bereits seit langem im Einsatz sind oder es sich um Enterprise-Systeme handelt, ist dort häufig ein veralteter Doctype voreingestellt. Das kann man aber umstellen. Es ist wahrscheinlich nicht ganz so einfach wie oben für kleine Webseiten beschrieben. Für große Portale und Marken dürfte der Effekt aber den Einsatz eines Programmierers oder auch eines ganzen Teams rechtfertigen. Selbst wenn die Umstellung bis zu zwei Wochen dauern sollte. Vielleicht kann man in diesem Zusammenhang auch schon die Fehler bearbeiten, die der Validator sowieso anzeigt und den Quellcode generell ein wenig aufräumen und aktualisieren (so genanntes Refactoring). Darüber und über den Sinn einer solchen Maßnahme veröffentlichen wir vielleicht auch bald mal einen Artikel. Sollten sie in der Zwischenzeit bereits professionelle Hilfe benötigen, helfen wir Ihnen gerne.

(Artikel erstmals veröffentlicht am 06. Juli 2015  – Inhalte evtl. nicht mehr aktuell)

Das könnte dir auch gefallen

Kommentar hinterlassen

Deine E-Mail Adresse wird nicht veröffentlicht.

4 Kommentare
04.09.2015

Hallo Marko,

Du hast das Thema bereits in deinem Beitrag erwähnt. Auch heute sehen wir in der Praxis das noch sehr viele Webseiten besonders an diesem Punkt Nachholbedarf haben.

Denn man darf nicht vergessen das Fehler die im Quelltext erzeugt werden, erst vom Browser verbessert werden müssen, damit dieser die Seiten korrekt rendern kann und genau dieser Prozess kostet.

Genau aus diesem Grund sollte man meiner Meinung nach zumindest versuchen die Fehleranzahl im Quelltext möglichst gering zu halten.

17.09.2015

Hallo Marko!
Es wäre super, wenn ihr einen Artikel über das Refaktoring verfassen würdet. Vor allem wäre es sehr interessant, inwiefern solche Maßnahmen die Webseite insgesamt verbessern, z.B. in Bezug auf SEO.

19.09.2015

Hallo Kerstin, danke für deine Erinnerung. Wir müssen mal schauen wie sich das sinnvoll umsetzen lässt. Meistens ist es ja leider so, dass Refactoring als unnötig angesehen wird oder als billiger Versuch eine höhere Rechnung zu schreiben.

20.09.2015

Leider werden viele Templates mit Fehlern programmiert. Aber, wer ein Template kauft, muss dies im gleich bezahlen. Hier wäre es gut, wenn die Möglichkeit bestehen würde, erst das Template mit W3C zu prüfen, bevor man es bezahlen muss. Dann würden viele Programmierer vielleicht umdenken.