Was AI wirklich sieht — und warum gute Inhalte unsichtbar sein können

Stell dir vor, jemand öffnet deine Website — aber nicht mit einem Browser, sondern mit einer einfachen Textlesebrille. Keine Bilder, keine Animationen, kein JavaScript. Nur das, was im HTML-Quelltext steht. Was dieser Besucher sieht, ist oft deutlich weniger als das, was ein normaler Nutzer sieht.

Genau das passiert, wenn AI-Systeme deine Website verarbeiten.

Nicht alle AI-Systeme sind gleich ausgestattet. Manche können JavaScript ausführen und sehen eine Seite ähnlich wie ein Mensch im Browser. Viele aber — darunter Crawler, die für Sprachmodelle Inhalte sammeln — arbeiten mit dem nackten HTML-Quelltext. Was nur durch JavaScript sichtbar wird, existiert für sie schlicht nicht.

Das ist der Ausgangspunkt dieses Teils: Was sehen diese Systeme wirklich? Wo entstehen Lücken? Und was lässt sich dagegen tun?

Zwei Versionen einer Website

Jede moderne Website existiert in zwei Versionen, ohne dass es auf den ersten Blick auffällt.

Die gerenderte Version ist das, was ein Mensch im Browser sieht: Inhalte laden nach, Tabs öffnen sich beim Klick, Preise erscheinen nach einer kurzen Verzögerung, Produktbeschreibungen sind hinter einem “Mehr anzeigen”-Button versteckt. All das ist normal und oft bewusst so gebaut.

Die Quelltext-Version ist das, was ein Server ausliefert, bevor JavaScript ausgeführt wird. Bei vielen modernen Websites ist das ein weitgehend leeres HTML-Gerüst mit einem JavaScript-Bündel, das die eigentlichen Inhalte erst im Browser aufbaut.

Für Menschen ist der Unterschied irrelevant — sie sehen immer die fertige, gerenderte Version. Für Maschinen, die keine vollständige JavaScript-Ausführung vornehmen, ist er erheblich.

Das betrifft besonders Websites, die mit modernen JavaScript-Frameworks gebaut wurden — React, Vue, Angular in ihrer Standardkonfiguration — ohne explizit serverseitiges Rendering einzuschalten. Eine solche Seite kann für einen Menschen perfekt funktionieren und für eine Maschine fast leer sein.

Was konkret unsichtbar wird

Nicht jeder JavaScript-Einsatz ist ein Problem. Animationen, Menü-Interaktionen, Formularvalidierung — das alles ist für maschinelle Lesbarkeit irrelevant. Problematisch wird es, wenn wesentliche inhaltliche Elemente nur per JavaScript sichtbar werden.

Tab-Inhalte. Eine Leistungsübersicht mit vier Tabs — “Beratung”, “Umsetzung”, “Support”, “Wartung” — zeigt beim Laden nur den ersten Tab. Der Inhalt der anderen drei ist im HTML gar nicht vorhanden, bevor JavaScript den aktiven Tab umschaltet. Ein AI-System ohne JavaScript sieht nur “Beratung”.

Das ist in der Praxis der häufigste und folgenreichste Fall: Leistungsseiten mit Tab-Navigation sind ein verbreitetes Designmuster, und in vielen Implementierungen existieren die Inhalte der nicht-aktiven Tabs im initialen HTML schlicht nicht — nicht ausgeblendet, sondern strukturell abwesend. Für ein AI-System, das das vollständige Leistungsangebot erfassen will, ist das struktureller Informationsverlust.

Akkordeons und ausklappbare Bereiche. FAQs, die erst beim Klick aufgehen, sind ein häufiges Beispiel. Die Fragen sind sichtbar, die Antworten nicht. Für AI-Systeme, die explizit nach FAQ-Inhalten suchen, sind diese Seiten leer.

Nachladeende Inhalte (Lazy Loading). Produktlisten oder Artikel, die erst beim Scrollen nachgeladen werden, sind im initialen HTML nicht enthalten. AI-Systeme, die den Quelltext ohne Scroll-Simulation verarbeiten, sehen nur den ersten Abschnitt.

Modale und Overlays. Inhalte, die in Popup-Fenstern erscheinen — Preistabellen, Leistungsdetails, Kontaktformulare mit Informationstext — sind oft im HTML vorhanden, aber auf “unsichtbar” gesetzt und werden nur durch JavaScript eingeblendet. Je nach Implementierung kann ein Crawler das lesen oder nicht.

Inhalte in Bildern ohne Alternativtext. Diagramme, Infografiken, Screenshots mit Text — was visuell kommuniziert, aber nicht im Alt-Text oder als begleitender Text aufgeführt ist, existiert für Maschinen nicht.

Das Konsistenzproblem

Neben der Sichtbarkeit ist Konsistenz ein zweites strukturelles Problem, das bei der maschinellen Verarbeitung ins Gewicht fällt.

Ein Mensch navigiert eine Website mit Kontext. Er weiß, dass die Startseite einen vereinfachten Überblick bietet, die Leistungsseite ins Detail geht und die Preisseite den aktuellen Stand zeigt. Wenn ein Preis auf der Startseite “ab 89 Euro” steht, auf der Leistungsseite “ab 95 Euro” und im FAQ gar nicht erwähnt wird, fragt der Mensch nach oder nimmt den aktuellsten Wert.

Ein AI-System hat diese Kontextintelligenz nicht. Es verarbeitet mehrere Quellen und trifft auf drei verschiedene Informationen zu derselben Frage. Das Ergebnis ist entweder Unsicherheit (“die Preise variieren”) oder eine falsche Aussage. Weder hilft dem potenziellen Kunden, der die Frage gestellt hat.

Das betrifft nicht nur Preise:

• Kontaktdaten: Telefonnummer im Footer anders als auf der Kontaktseite
• Standortangaben: Adresse in der Über-uns-Seite anders als im Google Maps-Widget
• Leistungsumfang: Auf der Startseite breiter beschrieben als auf der Leistungsseite

Bei manuell gepflegten Websites passiert das regelmäßig. Eine zentrale Datenverwaltung — ein Headless CMS, eine strukturierte Datenquelle, aus der alle Seiten ziehen — ist die systemische Lösung. Die einfachere Variante: regelmäßige manuelle Prüfung auf Konsistenz.

Was ein AI-System tatsächlich bevorzugt

Aus dem bisher Gesagten lässt sich ableiten, was maschinell gut lesbare Inhalte auszeichnet. Es sind keine überraschenden Anforderungen — aber es lohnt sich, sie explizit zu benennen.

Direkt im HTML stehender Text. Wesentliche Informationen — Leistungen, Preise, Kontakt, FAQ-Antworten — sollten im HTML-Quelltext vorhanden sein, ohne JavaScript-Ausführung. Das ist für SSR-Frameworks der Standard; bei CSR-only-Setups muss es explizit konfiguriert werden.

Ein häufig übersehener Fallstrick bei SSR: Inhalte, die über eine externe API nachgeladen werden, sind im serverseitigen HTML nur dann enthalten, wenn der Fetch-Request tatsächlich auf dem Server ausgeführt wird — nicht im Browser. Eine Seite kann technisch korrekt SSR nutzen und trotzdem wesentliche Inhalte aus einem CMS erst clientseitig nachladen. Das Ergebnis ist aus Crawlerperspektive dasselbe wie bei CSR: ein Gerüst mit Lücken.

Semantisches HTML. Überschriften in der richtigen Reihenfolge (h1, h2, h3), Absätze als <p>, Listen als <ul> oder <ol>, Navigation als <nav>, Hauptinhalt als <main>. Diese Struktur hilft nicht nur AI-Systemen, sondern auch Screenreadern, Suchmaschinen und der allgemeinen Wartbarkeit.

Konsistente Informationen. Was an einer Stelle steht, steht überall gleich. Das gilt besonders für maschinenrelevante Informationen: Preise, Kontaktdaten, Leistungsbeschreibungen, Standort.

Alt-Texte für inhaltliche Bilder. Jedes Bild, das inhaltlich relevant ist — ein Produktfoto mit sichtbarem Modellnamen, ein Diagramm mit Daten, ein Screenshot mit Text — braucht einen beschreibenden Alt-Text. Dekorative Bilder können ein leeres alt=""-Attribut haben.

Klare Sprache. Marketingphrasen wie “Wir bieten innovative Lösungen für Ihre individuellen Herausforderungen” geben einer Maschine keine extrahierbare Information. “Wir entwickeln Websites für Handwerksbetriebe mit bis zu 50 Mitarbeitern” schon.

Was Betreiber von ihren Entwicklern verlangen können

Für Auftraggeber, die keine technischen Details kennen müssen, gibt es eine handhabbare Kurzliste von Fragen:

Wie ist die Seite technisch aufgebaut? Bei modernen Frameworks: Wird SSR oder Static Site Generation genutzt? Frameworks wie Astro, Next.js, Nuxt und SvelteKit unterstützen das. Rein clientseitiges Rendering ohne SSR ist für inhaltsorientierte Websites heute kein guter Standard mehr.

Sind wesentliche Inhalte ohne JavaScript zugänglich? Das lässt sich einfach testen: Browser-Entwicklertools → JavaScript deaktivieren → Seite neu laden. Was noch zu lesen ist, sehen auch die meisten AI-Systeme.

Gibt es eine zentrale Datenverwaltung? Werden Preise, Kontaktdaten und Kernaussagen an einem Ort gepflegt und von dort auf alle Seiten übertragen? Oder wird jede Seite manuell aktualisiert?

Sind Alt-Texte vorhanden? Bei einem Relaunch oder einer Überarbeitung sollte das systematisch geprüft werden.

Barrierefreiheit und AI-Lesbarkeit: dieselbe Anforderung

Ein Nebeneffekt, den es wert ist zu erwähnen: Die Anforderungen an maschinell lesbare Inhalte sind fast identisch mit den Anforderungen an barrierefreie Websites.

Semantisches HTML, Alt-Texte, serverseitig gerenderter Inhalt, konsistente Informationsstruktur — das sind Grundsätze, die in der professionellen barrierefreien Webentwicklung seit Jahren als Best Practice gelten. Was für Screenreader und assistive Technologien gebaut wurde, ist auch für AI-Systeme gut lesbar.

Das ist kein Zufall. Beide Szenarien — Screenreader und AI-Crawler — verarbeiten eine Seite ohne visuellen Kontext, ausschließlich auf Basis von HTML und Metadaten. Was für das eine funktioniert, funktioniert für das andere.

Für Betreiber bedeutet das: Wer in Barrierefreiheit investiert oder investiert hat, hat damit auch die Grundlage für AI-Lesbarkeit gelegt. Wer beides plant, kann es sinnvoll kombinieren.