Schlagwort-Archive: HTML

Webseiten als ebook im ePub-Format aufbereiten

Oft kommt es vor, dass ein Buch als Webseite aufbereitet wurde. Die Inhalte verteilen sich auf viele, manchmal hunderte einzelne Seiten. Wer wie ich klickfaul ist, findet das gar nicht gut. Das zweite Problem ist, dass auf eBook-Readern das Surfen im netz langsam und unübersichtlich ist. Deswegen möchte man die Webseite vielleicht als ePub aufbereiten. Und so geht man dabei vor, natürlich alles auf eigene Gefahr, respektiere das Urheberrecht!
Das Vorgehen erfordert das kostenlose Programm WinHTTrack, den kostenlosen HTML-Editor phase5, ruhig auch eine ältere Version sowie den freien eBook-Konverter Calibre. Außerdem sollte man sich ein wenig in HTML auskennen.
Mit WinHTTrack laden wir die entsprechende Webseite runter. HTTrack erstellt einen lokalen Ordner aus der Webseite.
Mit Phase5 öffnen wir eine der HTML-Seiten des Buches und schauen uns den Code an. Wir erkennen solche Elemente wie den Kopf, die Navigation, den Inhalt und die rechte Sidebar. Wir wollen alles raus haben bis auf den Inhalt. Dabei gehen wir Schritt für Schritt vor. Zunächst entfernen wir alle Elemente aus dem Head, die wir nicht brauchen, dazu gehören JavaScript-Anweisungen und –Verweise, Meta-Informationen und eventuell auch das CSS. Wir Markieren den entsprechenden Code-Abschnitt und kopieren ihn in die Zwischenablage.
Phase5 hat die schöne Funktion „Dateiübergreifendes Suchen und Ersetzen“, eigentlich der einzige Grund, warum man das Programm einsetzt. Wir rufen diese Funktion auf und kopieren den Markierten Abschnitt in das obere Feld. Links suchen wir noch unseren Unterordner, wo alle HTML-Dateien liegen, die wir vorher runtergeladen haben. Dann klicken wir auf OK und schon geht es los. Je nach der Menge der Dateien kann das einige Sekunden dauern. Ach ja, du solltest vorsichtig sein, der Schritt lässt sich nicht rückgängig machen. Wir wiederholen diesen Schritt, bis wir alle Elemente entfernt haben, die uns gestört haben. Achte dabei darauf, dass du die Struktur nicht zerstörst, schon das Weglassen von Klammern oder die unvollständige Entfernung von Tags kann die Datei für die Konvertierung unbrauchbar machen.
Im Browser kontrollierst du nach, ob das Layout der Seite nun okay ist. Im Idealfall hast du nur noch den reinen Text und die Bilder, das Layout fällt überwiegend weg, weil wir die CSS-Anweisungen gelöscht haben. Achte darauf, dass Elemente wie Zierleisten, Fußleisten oder Navigationen vollständig entfernt wurden.
Anschließend starten wir Calibre. Dort ziehen wir den Webseiten-Ordner in das ‚Bearbeitungsfeld. Achte darauf, dass die Seiten in der richtigen Reihenfolge vorliegen. Hier ist es natürlich ärgerlich, wenn du das händisch nachkontrollieren musst, aber normalerweise solltest du am Dateinamen erkennen, ob die Reihenfolge korrekt ist.
Jetzt nur noch das eBook im gewünschten Format erzeugen, das wars.
Solltest du Leerzeilen oder unerwünschte Umbrüche im Dokument haben, musst du ein wenig herumexperimentieren. Es kann zum Beispiel sein, dass der Seitenersteller Gestaltungsanweisungen direkt in die HTML-Datei geschrieben hat, die nachträglich wieder gelöscht werden müssen. Außerdem stellt Calibre einige Filter bereit, die bei der Nachbereitung helfen können.

Nur-Text unterstützen wir nicht

Heute möchte ich ausnahmsweise mal einen Newsletter zitieren. Ich habe ja privat seit gefühlten zehn Jahren keinen Newsletter abonniert. Entweder bietet jemand einen RSS-Feed an oder er hat Pech gehabt. Wobei ich mit dieser Einstellung total Old-School bin, wie ich mir habe sagen lassen: Der moderne Mensch läßt sich Artikel über Twitter empfehlen.
Nun aber zum genialen Newsletter-Text, den ich euch nicht vorenthalten wollte:

Ihr E-Mail-Client kann leider keinen HTML-Code darstellen, weshalb
dieser Newsletter auf Ihrem Monitor nicht angezeigt wird. Wir bitten um Nachsicht, dass wir nicht jeden E-Mail-Client hinsichtlich der Darstellung unserer HTML-Newsletter testen können. Bei Fragen kontaktieren Sie uns bitte über unsere Impressumsseite [Linkspam entfernt]

Okay, ich benutze den Thunderbird, wahrscheinlich bin ich der Einzige. Außerdem habe ich den HTML-Quatsch abgeschaltet, HTML ist was für Leute, die gut sehen können und auch Wert auf hübsche E-Mails legen. Ich bin ein Plain-Text-Verfechter und brauche in einer Mail weder Header noch eigenwillige Layout-Tabellen. Jeder Newsletter-Versender sollte damit rechnen, dass die Empfänger HTML wes Grundes auch immer abgestellt haben und eine Text-Fallback-Lösung anbieten.
Aber lustig, dass dieser Telefon-Tarife-Anbieter nicht alle Clients durchtesten möchte und offenbar lieber gar keinen Inhalt anbietet als einen Text-Newsletter.
Alberner war nur eine Regierungsbehörde, die ihren Newsletter als PDF-Anhang bereit gestellt hat. Bei den Anbietern scheint der Glaube vorzuherrschen, sie könnten den Leuten vorschreiben, wie sie ihre Newsletter zu lesen hätten und die Leute würden sich das auch noch gefallen lassen, anstatt das Zeug ungelesen in den Papierkorb zu schieben.

Was bringen automatische Testtools für die Barrierefreiheit – die Validierung

Mittlerweile dürfte sich jede Webagentur damit schmücken, barrierefreie Websites zu bauen. Sie machen das sozusagen im Vorbeigehen, ohne Experten zu engagieren, ohne Praxistests mit Betroffenen und ohne großartig Ahnung von BIT-V oder WCAG zu haben – behaupte ich mal, denn viele Websites ob uralt oder nagelneu erfüllen nicht einmal die minimalen Basics, zum Beispiel die Verwendung von HTML-Elementen. Vielleicht greifen einige dieser Agenturen auf mehr oder weniger automatische Testtools zurück – was besser ist als gar nichts zu tun. Grund genug, sich einiger dieser Tools anzugucken und sie hier in lockerer Folge einmal vorzustellen.Ich beginne dort, wo jeder Code-Schreiber anfangen sollte, bei der Validation.

Validatoren

Dirk Jesse hat in seinem Beitrag Alles valide oder was? schon einiges zu dem Thema Validierung gesagt, dem ich nicht viel hinzufügen kann. Dennoch möchte ich das Thema vom Blickwinkel der Barrierefreiheit betrachten.

Im ersten Schritt sollte immer überprüft werden, ob die Seiten validen Code enthalten. Das hilft vor allem dabei, fehlerhafte Tags, Attribute und Werte zu finden,was zu Fehlern in der Darstellung führt.

Valide oder nicht valide – das ist nicht mehr die Frage

Kurioserweise glauben viele Leute, valider Code sei schon barrierefrei. Ergo, nicht valider Code ist eine Barriere. Die letztere Ansicht stimmt heute nicht mehr: Dank HTML5 und WAI ARIA haben sich die Möglichkeiten für barrierefreie Websites entscheidend verbessert. Beide Standards sind allerdings noch nicht verabschiedet und validieren dementsprechend zumindest beim W3C nicht. Es gibt allerdings einen experimentellen HTML5-Validator, der explizit bei der Doctype ausgewählt werden muss, wenn man nicht den neuen Doctype von HTML5 verwendet.

Jeder Code-Leser dürfte aber in der Lage sein, ARIA oder HTML5-Fehlermeldungen von echten Fehlern unterscheiden zu können. Bei CSS3 sieht es ähnlich aus. Ich plädiere stark dafür, stabile Elemente schon heute zu verwenden, weil sie die Benutzerfreundlichkeit und Zugänglichkeit erhöhen. Außerdem wird so Druck auf die Programmierer von Browsern und das W3C ausgeübt, diese Elemente auch zeitnah einzuführen.

Nutzen

Der HTML-Validator stellt zum Beispiel sicher, dass in XHTML alle Bilder einen Alternativ-Text haben. Er kann allerdings nicht beurteilen, ob dieser Text sinnvoll ist oder nicht. Er kann auch nicht sehen, ob jemand HTML für Überschriften verwendet oder sie per CSS gestaltet. div id=”h1″ ist ebenso valide wie “h1″. Die Validierung verhindert allerdings grobe Fehler wie falsche Tag-Attribut-Paare, was kein Browser der Welt korrigieren oder interpretieren kann. Er prüft auch nicht die Trennung von Layout und Struktur, die dank CSS eigentlich Standard sein sollte. Kein Validator der Welt verhindert, dass jemand mit ” ” seine Abstände einstellt oder Absätze über “br” statt über “p” erzeugt, das sind typische Artefakte von WYSIWYG-Editoren.

Fazit

Basis barrierefreier Websites ist fehlerfreier Code. Wer seinen Code nicht prüft, riskiert fehlerhafte Darstellung im Browser, was normalerweise einen Rattenschwanz weiterer Probleme nach sich zieht. Der Validator ist allerdings nur der Anfang und nicht das Ende der Testphase. Er schwächelt dort, wo es um semantisch sinnvolle Auszeichnungen geht und hier kommt es auf das Können des Code-Schreibers an.
Einen recht interessanten Artikel dazu gibt es bei Wait till I come. Chris und Remy Sharp diskutieren über die Bedeutung des Validierens, Chris vertritt als Protagonist der Barrierefreiheit im wesentlichen unseren Standpunkt.

HTML oder Plain Text – die Zukunft der Mail

Immer wieder einmal keimt die Debatte auf, ob man Mails als HTML oder reinen Text versenden sollte. Die Diskussion ist eigentlich müßig, HTML-Mails bieten kaum Vorteile, dafür jede Menge Nachteile.
HTML-Mails sind mit oder ohne Bilder recht groß. Die Größe wird dabei von Gestaltungs-Elementen bestimmt, die wenn im Web verwendet an der Fähigkeit des Webdesigners zweifeln ließen: Inline-CSS, Layout-Tabellen, 0-Pixel-Graphiken und so weiter. Die Vielfalt der Mailprogramme und MailClients lässt nur eine begrenzte Bandbreite an Gestaltungselementen zu. Dazu kommt noch, dass die Mailfenster selbst unterschiedlich breit sein können. Das reicht von der Miniansicht auf Smartphones bis zur Maxidarstellung auf 24-Zoll-Displays. Ein festes Design sieht deshalb fast immer lächerlich aus: zu groß für das Smartphone, zu schmal für das große Display. Ein fluides Design sieht hingegen auf einem großen Display einfach alber aus, weil die Mail dann irgendwie zu kurz geraten aussieht.

Datenschutz

Viele Anbieter möchten über Newsletter Tracking betreiben. Das geht einerseits über speziell generierte Links in den Mails und über Bilder, die über das Web nachgeladen werden. Das könnte ein Verstoß gegen den Datenschutz sein, ich kann mich zumindest nicht daran erinnern, jemals danach gefragt worden zu sein, ob ich mit der Erhebung solcher Daten einverstanden bin. Es ist auch nicht naheliegend anzunehmen, der Empfang eines Newsletters könnte für solche Zwecke verwendet werden. Deswegen wird der Benutzer auch nicht gesondert auf solche Probleme achten. Für einen Tracking-Link ist es hingegen egal, ob er in HTML oder PlainText verwendet wird.

Mobilität

Wer seine Mails mobil abruft, wird sich über Mails freuen, die 100 Kilobyte groß sind, 200 x 150 Pixel große Bilder nachladen und wegen des Tabellen-Designs sowohl horizontal als auch vertikal gescrollt werden müssen. Bestimmt.

Sicherheitsrisiken

HTML-Mails stellen ein Sicherheitsrisiko dar. Sie landen doch recht häufig im Spam (wo sie auch meistens gut aufgehoben sind). Viele Webmailer blockieren zunächst die Volldarstellung.
Dem Leser geht es um den Inhalt der Mails und nicht um bunte Logos, farbenfrohe Graphiken und flockige Bilder, weswegen er kein Interesse daran hat, sich die Volldarstellung anzusehen.

Wozu gibt es RSS und Webseiten?

Newsletter sind eine aussterbende Rarität wie Gästebücher. Viele Nutzer greifen heute auf RSS, Twitter oder Facebook zurück, um sich aktuelle Informationen zu beschaffen. Immerhin bietet das Inhaltsverzeichnis eines Newsletters – wenn es gut gemacht ist – einen schnellen Überblick über die Neuigkeiten. Das funktioniert aber nicht, wenn bunte Bilder, Disclaimer und weitere Informationen den Blick auf den Inhalt verstellen.
HTML sollte dem Web vorbehalten bleiben, wo es gut aufgehoben ist und seinen Zweck erfüllt. Es gab früher und gibt bis heute keinen Grund, seine Mitmenschen mit HTML-Mails zu belästigen. Und mal ehrlich, wann hast du das letzte Mal das tolle Design eines Newsletters bewundert?
Wirklich absurd sind Newsletter, die als PDF verschickt oder irgendwo heruntergeladen werden müssen. Die Anbieter haben wohl nicht wirklich verstanden, dass das Internet keine Litfassäule ist.
Auch wenn der Newsletter als Informationsmedium eine große Rolle spielt und ähnlich wie der RSS-Feed zumindest in absehbarer Zeit nicht aussterben wird, sollte man die Kraft des Mediums nicht überschätzen. Entscheidend ist, wie viele Leute man tatsächlich erreicht und nicht, wie viele Leute den Newsletter abonniert haben. Im Mailprogramm ist es leichter, die Löschen-Taste zu drücken als ein Abo abzubestellen. Die Anbieter werden es nicht gerne hören, aber die Zahl der echten Leser steht in keinem guten Verhältnis zur Zahl der Abonnenten. Auch das ist ein Grund, sich auf das Wesentliche zu konzentrieren und alle möglicherweise störenden Elemente zu entfernen.

Ist selfHTML tot?

Wer sich ein wenig mit HTML beschäftigt, kommt eigentlich nicht an Deutschlands größter Referenz vorbei: selfHTML. Ich dachte also, das sei der erste und beste Anlaufpunkt, um Informationen über HTML 5 und die neuen Standard für Formulare XFORMS zu bekommen. Fehlanzeige, schockiert stelle ich fest, dass das Projekt seit 2007 eingefroren ist.
Dabei dürfte mit HTML 5, CSS 3 und der WCAG 2.0, den neuen Richtlinien für Barrierefreiheit, der Bedarf an Informationen stark gestiegen sein.
In den letzten drei Jahren dürfte sich rund um das Web mehr getan haben als von 2000 – 2007. Der Firefox hat auf dem deutschen Markt den Internet Explorer eingeholt, der IE ist in einer neuen Version erschienen, Opera hat diverse Updates gemacht, Chrome und Safari sind neue Wettbewerber bei Windows-Computern. CSS 3 und HTML 5 könnten in absehbarer Zeit verabschiedet werden und einige der genannten Browser unterstützen bereits Teile der Spezifikationen. Das mobile Web wird langsam Realität, neue Endgeräte, Betriebssysteme und Browser erobern den Markt.
Mit anderen Worten: der Bedarf für eine Referenz ist gigantisch, aber zumindest im deutschsprachigen Web gibt es keine Referenz mehr, die diese Bereiche abdeckt.
Im siteeigenen Blog wird die Frage diskutiert, ob man ein Wiki einrichten sollte. Natürlich sollte man nichts überstürzen, jede verfehlte Aktionen kostet Zeit und Nerven und könnte das endgültige Aus bedeuten. Wer vergleichbare Projekte kennt weiß, wie viel Aufwand und Energie dahinter steckt, das Projekt am Leben zu erhalten. Ich frage mich allerdings schon, warum jetzt erst solche Fragen diskutiert und warum offenbar in den letzten drei Jahren keine anderen Projekte ausprobiert wurden. Warum wurde das klassische Modell, auf dem selfHTML entstanden ist, nicht einfach weiter geführt?
Man wird wohl nicht daran vorbei kommen, das W3C selbst als Referenz zu nehmen, denn es sieht nicht so aus, als ob in Deutschland sich in absehbarer Zeit etwas brauchbares entwickeln wird. Schade eigentlich, denn ich habe viel mit selfHTML gearbeitet und war immer froh darüber, mir keine teuren Bücher und stundenlanges Wühlen in mittelmäßigen Foren leisten zu müssen.

kleines Update vom 12.3.2010: Okay, langsam werden mir die Gründe dafür deutlich, warum selfHTML sich nicht weiter entwickelt hat, nachzulesen in einem ellenlangen Forenthread, der sich aus dem Blogeintrag entsponnen hat. Die Programmierer haben sich einen eigenen XML-Dialekt samt Versionsmanager ausgedacht, die Betreiber waren selbst zu eingespannt und frustriert, um das Projekt groß weiter zu entwickeln und die Kommunikation trug nicht dazu bei, die Hilfewilligen einzuladen. Natürlich läuft viel Arbeit im Backend, die man im Frontend gar nicht mitbekommt.
Man plant derzeit einen neuen Wiki-Versuch, leider gibt es auch hier keine regelmäßigen Statusupdates. Trotzdem wünsche ich viel Erfolg. Stefans Vorschläge klingen auf jeden Fall vielversprechend.

Wie baue ich ein tabellenfreies Webseiten-Layout

Die Layouttabelle war vor der Entwicklung der Layoutsprache CSS die einzige brauchbare Möglichkeit, komplexe Layouts zu entwickeln. Seitdem hat sich viel getan: Die Unterstützung für CSS ist so weit etabliert, dass Tabellenlayouts langsam aussterben (sollten). Stattdessen setzt ausgerechnet der Computerverlag Heise konsequent auf Tabellen.

Zunächst einmal muss man verstehen, wie in CSS positioniert und formatiert wird. Alle Elemente – bis auf den body – werden in Div-Containern eingefasst <div>Element</div>. Alle Elemente, die in Div-Containern stehen, lassen sich über externe Stylesheets exakt positionieren.

Die Positionierung erfolgt über die Attribute von position: left, right, top und bottom.Die Höhe und Breite können unabhängig von position mit width und height definiert werden. Das heißt natürlich, dass man nur zwei Attribute von position definieren kann, also entweder left und top oder left und bottom und so weiter. Die Dimension wird über width und height bestimmt.

Alle großen Elemente wie Spalten sollten absolut positioniert werden, sprich:

{position: absolute; left:0; top:0; width: 1000px; height: 200px}

Es gibt die Eigenschaft float, die aber der Internet Explorer nicht unterstützt.

Das könnte unsere Kopfzeile werden, in dieser Kopfzeile können sich Elemente wie Bilder befinden. Im westlichen Kulturkreis liest man von links nach rechts und guckt zuerst nach oben links. Alle großen Container sollten daher von oben links absolut definiert werden. Möchte man etwa ein Objekt unten rechts positionieren, riskiert man, dass das Objekt bei kleinen Bildschirmen außerhalb des Sichtbereiches liegt.

Ein wichtiger Hinweis: Der Screenreader von Blinden greift auf den Quelltext zu und weiß nicht, wie Elemente auf der Seite selbst definiert wurden. Das heißt: Die Elemente der Website müssen im Quellcode genau in der Reihenfolge aufgeführt werden, in der sie auch auf der Seite präsentiert werden. Das heißt in der Regel: von oben links nach unten rechts, wobei die Fußzeile das letzte Element im Quelltext ist. Anders macht es etwa Golem, so dass ein Screenreader hier zuerst die Stellenanzeigen liest, die aber auf dem Bildschirm NACH der Artikelliste angezeigt wird.

Hier meine Seite als Beispiel und hier deren CSS-Code.

SEO IV – schwerer wirds immer – technische Aspekte

Laden Sie alle Beiträge zur Suchmaschinenoptimierung als PDF herunter

Der Titel “SEO leicht gemacht”, den ich bisher verwendet habe, war irreführend. SEO ist zumindest zeitaufwendig und ein Prozess, der genau genommen nie ganz abgeschlossen ist.

Die technische Ebene ist dabei die wahrscheinlich komplexeste Ebene. Hier kommt man ohne HTML-Kenntnisse nicht weit.

Die Bots und Crawler der Suchmaschinen können zwar nicht denken, sie sind aber keine totalen Authisten. Deswegen kann man ihnen auch so leicht nichts vormachen.

Sie können zum Beispiel erkennen, ob eine Seite sauber geschrieben ist. Viele der älteren WYSIWYG-Editoren wie Frontpage 2000, aber auch NVU X.X produzieren schlechten Code. Das hat sich wohl gebessert, auch beim Dreamweaver, ein weiteres Manko des WYSIWYG wird sich wohl nie beheben lassen – die Produktion von redundantem und kompliziertem  Code.

Das mag auch daran liegen, dass Stylesheets auf dieser Ebene eher schwierig zu implementieren sind.

Clean the code

Mit sauberem und schlankem HTML-Code kann man das Herz jedes Bots gewinnen. Eine vom WYSIWYG produzierte Seite ist trotz Optimierung doppelt oder dreimal so groß wie eine Handgeschriebene. Der Grund ist ganz einfach: Obwohl z. B. alle Absätze gleich formatiert sind, schreibt der optische Editor in jeden Absatz Schriftart, Schriftyp, Schriftgröße und weitere Informationen rein. Er weiß nicht, dass wir alle Absätze gleich formatieren wollen, weil wir das nicht vroher festgelegt haben.
Ein weiterer Grund sind Layouttabellen, die aus vielerlei Gründen von Webdesignern nach wie vor verwendet werden. Der Vorteil von Tabellen liegt tatsächlich darin, dass sich Elemente recht genau platzieren lassen und dass die Seiten auch dann strukturiert sind, wenn man sie als HTML abspeichert und offline anguckt. Stylesheets werden normalerweise nicht abgespeichert, wodurch natürlich alles verloren geht, was darin festgelegt wurde.
Aber: Layouttabellen vervielfachen den Quellcode.

Pflegeleichter Quellcode

Korrigieren lässt sich das Ganze nur auf Quelltextebene, den Quelltext muss man aber lesen können. Das beste ist wohl, parallel auf beiden Ebenen zu arbeiten, wem phase5, Notepad++ oder HTML-Studio zu spartanisch erscheint.

Banalitäten wie korrekte Dokumentendeklaration, Meta-Description, keine toten Links, Sitemaps, keine Links in JavaScript-Code, Titel für Images, Validierung des Quelltextes und des Style Sheets sollten eigentlich nicht mehr erwähnt werden. Viele Webdesigner vertrauen allerdings eher auf ihre Design- als auf technische Fähigkeiten.

Das alles ist aus einem simplen Grund wichtig: der Bot kann durchaus erkenen, ob eine Seite valides HTML ist, ob Links tot sind oder ob man sich Mühe gegeben hat, sauberen Code zu erstellen. Für den Bot ist es irrelevant, er weiß dann nur, dass da ein Profi am Werk war und das sie Seite nutzerfreundlich ist.

Meta und mehr

Obwohl Meta-Tags heute an sich für die Suchmaschinenoptimierung nicht mehr die Bedeutung wie einst hatten, müssen auch sie gepflegt werden. Der Webdesigner muss sich bemühen, einen ordentlichen Eindruck auf den Bot zu machen. Google und andere beschweren sich durchaus, wenn doppelte Meta-Descriptions vorhanden sind oder wenn die Keywords nicht mit dem Inhalt des Body übereinstimmen.
Ebenso benötigt man auch dann eine robots.txt, wenn man dem Robot eigentlich nichts mitteilen will, wenn man ihm also erlauben will, alle Verzeichnisse zu durchsuchen.

Weiterführendes

SEO VI – Web 2.0 fürs Optimieren
SEO IV – die Strukturebene

SEO leicht gemacht III – Verlinkungen

SEO für alle II – die Inhaltsebene

SEO leicht gemacht – Suchmaschinenoptimierung für alle I

SEO leicht gemacht – Suchmaschinenoptimierung für alle I

Die Kunst der Suchmaschinenoptimierung erfordert Phantasie, Geduld, Gründlichkeit und viel viel Gefrickel. Wir fangen mit dem an, was man nicht tun sollte.

Zunächst zwei Warnungen:

– Man sollte nicht versuchen, eine Suchmaschine zu manipulieren. Das kommt früher oder später raus und kann schlimmstenfalls zum temporären oder kompletten Verschwinden aus dem Index führen. Google bietet extra einen Petzlink an. Wer dort einmal drin war, kann seine Domain direkt löschen lassen, sie ist verbrannt.

2. Man sollte nicht für eine bestimmte Suchmaschine optimieren. G ist zwar Marktfüher, meiner Ansicht nach werden sich aber früher oder später Spezialsuchmaschinen durchsetzen. Übrigens hat google vor allem in den Deutschland einen wahnsinnigen Marktanteil. In den USA sind Yahoo und Live sehr stark.

Für Suchmaschinenbots gibt es zwei Ebenen: Die Inhaltsebene und die Strukturebene.

Auf der Inhaltsebene ist es wichtig zu wissen, dass Suchmaschinen derzeit keine graphischen Elemente durchsuchen können, also keine Fotos, Flash-Elemente oder gar Audio/Video oder JavaScript.

Auf der Strukturebene – also dem HTML-Code – ist ebenfalls Text entscheidend. Hier muss der Text an der richtigen Stelle stehen, es gibt spezielle Attribute und Tags, die hier ausgewertet werden.

Die Überschriften <h1> – <h6>

Die Hervorhebungen <i> italic = kursiv, <b> – bold = fett, <u> – underline = unterstrichen (Achtung, hier besteht Verwechselungsgefahr mit Links), <blockquote> – Zitat, <ul> für Listen, <big>, <strong>, <p> für Absätze.

Weitere Artikel
Textarbeit

SEO IV – die Technik

SEO leicht gemacht III – Verlinkungen

SEO für alle II – die Inhaltsebene

SEO IV – die Strukturebene

Ebenso wichtig wie die Inhaltsebene ist die Strukturebene. Die Struktur einer einzelnen Website basiert auf der Auszeichnungssprache HTML. Mit WYSIWYG-Editoren läßt sich ein solcher HTML-Code automatisch erzeugen. Von großer Relevanz sind folgende Bereiche:

1. Der Title oder Seitentitel: Er wird in den Suchergebnissen als erstes angezeigt und ist ENTSCHEIDEND dafür, dass ein User eine Seite anklickt. Er steht im Kopf einer HTML-Datei und nicht im eigentlichen Text der Seite. Sieht man ein Suchergebnis mit dem Titel “Unbenannte Seite 1” merkt man sofort, dass da jemand geschludert hat

2. Sprechende Links: Von Content Management CMS erzeugte Seiten waren früher sehr kompliziert. Heute werten Suchmaschinen auch die Links aus, deshalb sollten sie Keywords enthalten, siehe die Adressleiste oben. WordPress kann also standardmäßig sprechende Links erzeugen.

3. Tags im Inhalt: Struktur gewinnt eine Seite wie bei normalen Dokumenten mittels Überschriften und Hervorhebungen. WYSIWYG-Editoren wie Kompozer bieten solche Formatvorlagen standardmäßig an. Dabei sollte man den üblichen Unsinn vermeiden, etwa den ganzen Text fett oder kursiv zu machen oder willkürlich Überschriften vergeben. So doof sind die Bot-Programmierer nun doch nicht.

4. Alternativtexte und Titel für Multimedia: Innerhalb eines Links oder Multimedia-Elements lassen sich Alternativtext und Titeltext vergeben. Der Titel wird angezeigt, wenn man mit der Maus darüber fährt. Es spricht nichts dagegen, dass Suchmaschinen solchen wichtigen Text auswerten, aber die Meisten vergessen schlicht, dass es solch eine Möglichkeit überhaupt gibt.

Wichtig ist, dass über CSS definierte Klassen natürlich nicht gewertet werden können. Dazu müsste der Bot verstehen, was mit der Klasse gemeint ist, das kann er natürlich nicht.

Suchmaschinen lieben RSS-Feeds. Ein Weblog-Eintrag kann so oft innerhalb von Minuten in den Suchergebnissen auftauchen. Natürlich sollten sie auch gefüttert werden, sprich, man sollte etwas Relevantes mitzuteilen haben.