Schlagwort-Archiv: CSS

Webseiten als ebook im ePub-Format aufbereiten

1 Antwort
Vorlesen mit webReader

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.

Barrierefreiheit durch strukturierte Texte

2 Antworten
Vorlesen mit webReader

In der Regel haben Redakteure keinen Einfluß auf die technische Ausgestaltung von Redaktionssystemen. Deshalb können sie nur eingeschränkt auf die Möglichkeiten zur Strukturierung von Texten Einfluß nehmen.
Dennoch dürfte jedes aktuelle Redaktionssystem zumindest rudimentäre Möglichkeiten zur Textformatierung haben. Puristen wie ich arbeiten mit HTML, meiner Ansicht nach die einfachste Form der Textstrukturierung.
Beliebter sind jedoch die What-You-See-is-what-you-get oder kurz WYSIWYG-Editoren. In WordPress ist zum Beispiel der TinyMCE integriert, der an gängige Textverarbeitungen erinnert. TinyMCE in der erweiterten Ansicht
Weniger stark verbreitet sind Mischformen. Eine der bekannteren Formen der Textformatierung ist die Wiki-Syntax, wie sie in MediaWiki eingesetzt wird.
WIKI Editor
Der Nachteil von HTML und anderem Markup ist, dass man die Formatierungsanweisungen im Editor sehen kann. Für meinen Geschmack ist das aber ein Vorteil. Zum einen können so auch Blinde den Text formatieren. TinyMCE ist zwar mit Tastatur bedienbar, Mein Jaws und ich kommen damit aber nicht zurecht. Zum Anderen hat man volle Kontrolle über die Formatierung. Bei WordPress kommt es recht häufig zu seltsamen Umbrüchen, Formatierungen und Darstellungsproblemen, die man mühsam nachbearbeiten muss. Übrigens gibt es in TinyMCE in der erweiterten Ansicht die Möglichkeit, Formatierungen zu löschen und eine spezielle Funktion Einfügen von Text aus Word.

Strukturierung statt Aufhübschung

Ein sehr häufiger Fehler bei der Strukturierung von Texten ist der Einsatz von nichtsemantischem HTML oder CSS bei der Formatierung von Texten. Ich kann zum Beispiel eine Überschrift mit HTML als Überschrift kenntlich machen. Ich kann aber auch ein Div-Element verwenden und das ein wenig fetter und größer gestalten. Das ist übrigens die Regel, nicht die Ausnahme. Die meisten Tageszeitungen verfahren so. Fast immer ist die eigentliche Artikelüberschrift als Überschrift gekennzeichnet, die Zwischenüberschriften hingegen nicht.
Auch TinyMCE bietet in der WP-Standardkonfiguration keine Formatierungen für Zwischenüberschriften an.
Es kommt auch sehr häufig vor, dass Listen nicht korrekt formatiert werden. Die meisten Leute verfahren wie in Word, schreiben einen Bindestrich, ihren Text und drücken dann auf Return. Word bietet in der Standardeinstellung sofort per AutoFormat eine Auflistung an. Im Web klappt das aber nicht.
Dann gibt es noch die Zitate, die mit einer Einrückung gekennzeichnet werden. Ich sehe im Geiste die Redakteure vor mir, die mühsam mit der Tabulatortaste Einrückungen simulieren.
Und hier ist häufig schon Schluss. Abkürzungen und Kennzeichung von Sprachwechseln gehören sicher nicht zum Standardumfang von WYSIWYG-Editoren.

Warum das Ganze?

Blinde benötigen Zwischenüberschriften und Absätze, um Textabschnitte wenn nötig überspringen zu können. Außerdem gibt es im Screenreader verschiedene Möglichkeiten, Texte zu überfliegen, ich bin an anderer Stelle darauf eingegangen.
Für Menschen mit geringer Leseerfharung (funktionale Analphabeten), Lese-Rechtschreibschwäche oder Lernschwierigkeiten ist es hilfreich, wenn Texte sauber strukturiert werden. Dazu gehören unterschiedliche Zeilenlängen bwie im Flattersatz, weil sie dem Auge Orintierung bieten. Die gleiche Aufgabe erfüllen Absätze und Zwischenüberschriften. Aufzählungen, Zitate und Bilder geben dem Text zusätzliche Struktur und dem Leser bessere Orientierung.

Grenzen

Der HTML-Bestand der Redaktionssysteme ist eher begrenzt.n Einfache Tabellen lassen sich vielleicht noch einfügen, aber schon bei th oder caption dürfte Schluß sein.
Man kann sie auch nicht selber einfügen, weil die Systeme in der Regel Tags rausfiltern, die sie nicht kennen. Das gilt dann entsprechend für Abkürzungs- oder Sprachwechsel-Tags. Den Backend-Texteditor um solche Funktionen zu ergänzen dürfte aber die geringste Herausforderung sein.

Mehr Verständnis

Es gibt also kurz zusammengefasst zwei Kernprobleme bei der Strukturierung von Texten:

  1. Die Programmierer von Redaktionssystemen setzen nur Standardanforderungen um oder arbeiten gar mit Layout statt Struktur, setzen also CSS statt HTML ein.
  2. Die Reddakteure ihrerseits sind mit den Grundlagen der Strukturierung von Texten im Web nicht vertraut. Entweder kommen sie aus dem Printbereich, wo andere für das Layout zuständig sind. Oder sie sind gelernte Online-Redakteure, in deren Kursen HTML und CSS stiefmütterlich behandelt wird, weil Photoshop viel spannender ist

Barrierefreiheit muss daher auch bei der Programmierung des Redaktionssystems berücksichtigt werden.

Weiterlesen

Accessibility for web writers. Vierteilige Serie auf 4Syllables
Anleitungen und Hinweise für barrierefreie Textdokumente von WoB11
Ten Guidelines for Improving Accessibility for People with Dyslexia JISC-CETIS

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

Hinterlasse eine Antwort
Vorlesen mit webReader

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.

Mobiles Webdesign

Hinterlasse eine Antwort
Vorlesen mit webReader

Das mobile Webdesign erfordert ein vollständiges Umdenken bei den Designern. Natürlich läßt sich ein Website, die für Bildschirme erstellt wurde, im Web kaum lesen.
Ein Kernproblem ist das Scrollen. Der Bildschirmnutzer ärgert sich bereits, wenn er sowohl horizontal als vertikal scrollen muss. In der Regel wird er ersteres ohnehin lassen. Daher muss eine mobile Website so aufgebaut sein, daß man gar nicht horizontal scrollen muss.
Ohnehin sind Größenangaben im mobilen Web anders zu bewerten. Im containerbasierten Design sind relative vor absoluten Größenangaben zu bevorzugen. Im Webdesign gibt es nur zwei relative Größenangaben: Prozent und em.
Auch die Farbkombination muss mit Bedacht gewählt werden. Mobile Geräte sind in puncto Farbdarstellung weniger leistungsfähig als Bildschirme. Zudem spielt insbesondere bei Texten der Kontrast eine höhere Rolle. Weiß auf schwarz bzw. schwarz auf weiß sind optimal zu lesen, jede andere Farbkombination ist schlechter.
Eine Navigation ist dann optimal, wenn sie nur wenige wichtige Links anbietet. Was für barrierefreie Webseiten bereits üblich ist, bietet sich auch für mobile Webseiten an: interne Sprunganker und Accesskeys. Interne Sprunganker bieten die Möglichkeit, einzelne Elemente von Webseiten zu überspringen, wie etwa die Navigation, um direkt zum Inhalt zu gelangen. Accesskeys sind Tastenkürzel, bei mobilen Webseiten wären das Zahlen, welche die direkte Ansteuerung von Elementen erlauben.
Auf Bilder sollte man weitgehend verzichten. Jeder Handynutzer kennt die zweifelhafte Qualität der Bildanzeige. Generell sollten Bilder ebenfalls nicht breiter sein als Handy-Display. Zudem verlangsamen viele kleine Bilder die Downloadgeschwindigkeit.

Barrierefrei glücklich – kein Pfusch beim Design

Hinterlasse eine Antwort
Vorlesen mit webReader

Handwerklich schlecht gemacht ist Design, wenn improvisiert wird. Nachdem wir die Grundlagen tabellenfreier Layouts betrachtet haben, fragen wir uns nun, wie man “Abstand hält”.

Schlechte Designer verwenden dazu das geschütze Leerzeichen oder nonbreaking space, also HTML-Entität &nbsp;. Oder man verwendet das break <br> als Abstandhalter für Absätze. Das ist nicht sinnvoll, früher oder später möchte man eventuell so etwas ändern und muss es dann aufwändig suchen und entfernen. Sinnvoller ist es hier, von Anfang an auf CSS zu setzen. By the way, man sollte auf Inline-CSS nach Möglichkeit vollständig verzichten.

Zum Abstandhalten werden die Eigenschaften margin und padding verwendet. Margin ist der Außenabstand, padding der Innenabstand oder Einbettung. Diese Eigenschaften können etwa für Links, Absätze, Bilder und andere Elemente verwendet werden, auch für div oder span. Werden sie nicht vergeben, wird normalerweise das browserseitige CSS eingesetzt.

Die beiden Eigenschaften lassen sich verfeinern, indem man unterschiedliche Abstände eingibt:

margin-left: 5px; margin-right:4px; margin-top:3px; margin-bottom:2px;

Typographische Abstände lassen sich wie gewohnt definieren über word-spacing oder letter-spacing. Damit kann – was sonst – die Abstände zwischen Worten und Buchstaben regulieren.

Wie baue ich ein tabellenfreies Webseiten-Layout

2 Antworten
Vorlesen mit webReader

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.

Link – die Kunst der richtigen Verbindung

1 Antwort
Vorlesen mit webReader

Auch Links wollen richtig gesetzt werden. Es ist zwar nett, am Ende eines elektroischen Textes alle Links zu erhalten, auf die im Text verwiesen wurde, aber dieses Verfahren stammt noch aud Zeiten des Papiers. Wir erinnern uns mit Schaudern an ellenlange Listen mit Fuß- und Endnoten und Anmerkungen, die zwar kleingedruckt aber dennoch um so umfangreicher sind.

Womit wir mitten im Thema sind: Eine Fußnote innerhalb eines elektronischen Textes muss prinzipiell anklickbar sein. Dabei öffnet sich entweder ein kleines neues Fenster, in dem der Text der Fußnote angezeigt wird oder das Dokument springt zur Fußnote. In letzterem Falle ist es unbedingt notwendig, eine Möglichkeit zu schaffen, damit der Leser genau dort hin zurück kommt, wo er herkam.

Häufiger tritt aber der Fall auf, dass man auf ein Dokument verweisen möchte: vielleicht als Beispiel, als Quellenverweis oder als weiter gehende Informationsquelle. In diesem Falle wird der Link direkt im Text gesetzt.

Möchte ich auf eine Pressemitteilung der Messe München verweisen, dann schreibe ich etwa: “Die Messe München sagt”, wobei der ganze Text ein Link ist, daraus schließt der Leser, dass hier auf die quelle der Aussage zurückverwiesen wird.

Dabei müssen Links deutlich erkennbar sein, etwa farblich oder unterstrichen. Dabei verwendet man am besten die klassischen Linkfarben des Web: blau für nicht-besuchte Links, lila für besuchte Seiten. Auf jeden Fall sollte man darauf verzichten, den User durch verschieden farbige Texte zu verwenden. Farben sollten immer eine bestimmte Bedeutung haben, die sich möglichst schnell erschließt.

Wenig hilfreich sind nackte Links, ob sie anklickbar sind oder nicht. Wenn sie “sprechend” sind, also im Linktext etwas aussagekräftiges drin steht, ist das schon besser, dennoch nicht unbedingt zielführend: http://www.oliveira-online.net/wordpress/wp-admin/post.php?action=edit&post=246

Betreibt man eine professionelle Site mit vielen externen und internen Links sollte man sich überlegen, ob man ein neues Fenster öffnen will oder ob der Link im gleichen Fenster geöffnet werden soll. Wird der Link im gleichen Fenster geöffnet, ist es aufwendiger, zum ursprünglichen Artikel zurückzukehren, sofern man das möchte. Öffnet man den Link in einem neuen Fenster, ärgert sich der User gegebenenfalls darüber. Folgende Regel halte ich für einen sinnvollen Kompromiß: Siteinterne Links werden im gleichen Fenster geöffnet, externe Links in neuem Fenster. Man kann auch im Title-Tag des Ankers hierauf hinweisen.

Wohin der Online-Journalismus steuert und wie man Links nicht verwendet, erfährt man in diesem Telepolis-Artikel.

SEO IV – schwerer wirds immer – technische Aspekte

Hinterlasse eine Antwort
Vorlesen mit webReader

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 IV – die Strukturebene

1 Antwort
Vorlesen mit webReader

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.