Kurz gesagt: Aus Word, Google Docs oder einem Browser eingefügter Text kommt selten als sauberes HTML an — er trägt unsichtbare Inline-Styles, leere Tags und Microsofts eigenes proprietäres Markup mit sich, weshalb eine Seite in Ordnung aussehen kann, während sie die im CMS gespeicherten Inhalte aufbläht und dessen Styling durcheinanderbringt. Kombiniere diesen Guide mit AI Hidden Characters, Text Difference, Character Counter und Encoding Converter.
HTML vor der Veröffentlichung zu bereinigen bedeutet, dieses versteckte Markup auf einfache Struktur zurückzuführen — Absätze, Überschriften, Links — bevor es ein CMS erreicht, das es exakt so rendert, wie es eingefügt wurde.
Woher der Markup-Ballast wirklich kommt
Microsoft Word speichert Formatierung intern als HTML-ähnliches Markup, und das Kopieren aus Word in einen Browser schleppt dieses veraltete Markup mit — bedingte Kommentare, mso-*-Inline-Styles und namensraumbehaftete Tags, die außerhalb von Word nichts bedeuten, aber trotzdem wortwörtlich eingefügt werden. Google Docs und Rich-Text-Editoren fügen eigene Inline-style-Attribute für jede Textspanne hinzu, selbst wenn das visuelle Ergebnis identisch mit dem Standardstil des CMS ist.
Warum das echte Probleme verursacht, nicht nur unordentlichen Code
Ein CMS rendert jedes HTML, das es bekommt — trägt eingefügter Inhalt ein inline font-family: Calibri oder eine feste font-size, kann das die tatsächliche Typografie der Seite in genau diesem Absatz überschreiben und inkonsistent wirkende Seiten erzeugen, die schwer zu diagnostizieren sind, weil das HTML bei schnellem visuellen Check in Ordnung aussieht. Leere Tags (<span></span>, verschachteltes <p><p></p></p>) rendern nicht sichtbar, werden aber trotzdem gespeichert, indexiert, und können Inhaltslängen-Prüfungen oder Accessibility-Scanner stören, die das rohe DOM parsen.
Was "sauberes" HTML wirklich bedeutet
Sauberes HTML behält semantische Struktur — <p>, <h2>, <strong>, <a> — und wirft alles ab, was nur existiert, um die exakte visuelle Formatierung des Quelldokuments zu reproduzieren. Der href eines Links zählt; die Inline-Farbe eines Spans meist nicht, da das eigene Stylesheet des CMS entscheiden sollte, wie Text aussieht, nicht die Quelle des Einfügens.
Ein Einfügen-und-Bereinigen-Workflow
- Füge zuerst in einen einfachen Zwischenschritt als Klartext ein, wenn die Quelle Word oder ein stark formatierter Editor ist — das allein entfernt den Großteil des proprietären Markups.
- Hat das CMS eine Option "als Klartext einfügen" oder "aus Word einfügen", nutze sie statt eines rohen Einfügens.
- Prüfe das Ergebnis auf leere Tags und Inline-
style-Attribute vor der Veröffentlichung, nicht nachdem ein Leser seltsame Formatierung meldet. - Füge nur semantisch bedeutsame Formatierung wieder hinzu — Fett für Betonung, Links, Überschriften — nicht visuellen Stil, der das eigene CSS der Seite dupliziert.
Häufige Fehler, die du vermeiden solltest
- Direkt aus Word in den Rich-Text-Editor eines CMS einfügen ohne einen zwischengeschalteten Bereinigungsschritt.
- Annehmen, eine Seite "sieht in Ordnung aus" bedeute sauberes HTML — der Ballast ist unsichtbar, bis man das Markup inspiziert oder ein Längenlimit trifft.
- Sichtbare Formatierung manuell löschen, während die zugrunde liegenden Inline-Styles und leeren Tags im HTML-Quellcode verbleiben.
- Dies als einmalige Korrektur behandeln statt als Schritt in jedem Publishing-Workflow mit viel Einfügen.
Sauberes HTML geht nicht darum, wie eine Seite heute aussieht — es geht darum, keine unsichtbare Markup-Schuld zu verschicken, die später als inkonsistentes Styling, aufgeblähtes Seitengewicht, oder ein CMS-Feld auftaucht, das still sein Zeichenlimit erreicht hat.