Eine Website kann für einen Menschen vollkommen logisch sein und für Software trotzdem aussehen wie ein Raum voller Türen ohne Beschriftung.
Wir sehen einen farbigen Button mit „Termin buchen“ und wissen sofort, was passiert. Wir erkennen an einem Pluszeichen, dass sich darunter vermutlich weitere Informationen öffnen. Drei kleine Kreise in Schwarz, Blau und Rot verstehen wir als Farbauswahl. Steht „E-Mail-Adresse“ oberhalb eines Eingabefeldes, müssen wir nicht lange darüber nachdenken, welche Information dort hineingehört.
Menschen interpretieren Oberflächen ständig. Wir beziehen Position, Farbe, Gestaltung, Gewohnheiten und Kontext mit ein. Eine Maschine braucht dafür deutlich klarere Signale.
Und genau deshalb bekommt etwas eine neue geschäftliche Bedeutung, das in guter Webentwicklung eigentlich schon lange selbstverständlich sein sollte: semantisches HTML.
OpenAI dokumentiert inzwischen in den Hinweisen für Publisher und Entwickler ausdrücklich, dass ChatGPT Atlas ARIA-Tags nutzt, um Seitenstruktur und interaktive Elemente zu interpretieren. Rollen, Labels und Zustände helfen dem Agenten dabei, Buttons, Menüs und Formulare zu verstehen und zuverlässiger mit ihnen zu interagieren.
Das Bemerkenswerte daran ist nicht ARIA selbst. Die Technik existiert seit Jahren und wurde vor allem für Accessibility entwickelt. Interessant ist die Überschneidung: Dieselben Strukturen, die Screenreadern erklären, was auf einer Website passiert, können nun auch Systemen helfen, die im Auftrag eines Menschen tatsächlich auf dieser Website handeln sollen.
Damit verändert sich langsam die Frage, was eine technisch gute Website eigentlich leisten muss.
Bisher mussten Maschinen Ihre Website vor allem verstehen
Suchmaschinen analysieren Websites seit Jahrzehnten. Genau deshalb beschäftigen wir uns mit Überschriften, internen Links, strukturierten Daten, Canonicals und einer nachvollziehbaren Informationsarchitektur.
Eine Suchmaschine soll erkennen, worum es auf einer Seite geht. Sie muss Zusammenhänge zwischen einzelnen Inhalten verstehen und entscheiden können, welche URL für welche Suchanfrage relevant sein könnte. Warum Struktur dabei weit mehr ist als eine hübsche Formatierung, haben wir bereits in unserem Beitrag zur Content-Erstellung für Google Optimierung ausführlicher behandelt.
Generative KI erweitert diese Aufgabe. Ein Sprachmodell soll nicht nur Textstellen finden, sondern Zusammenhänge erfassen. Es soll erkennen, welches Unternehmen welche Leistung anbietet, welche Informationen zusammengehören und ob eine Quelle für eine konkrete Antwort überhaupt relevant ist.
KI-Agenten gehen noch einen Schritt weiter. Sie sollen nicht nur verstehen, was auf Ihrer Website steht. Sie sollen möglicherweise auch verstehen, was man dort tun kann.
Ein Nutzer könnte einem Agenten beispielsweise sagen:
„Finde einen Anbieter für eine Erstberatung und buche mir nächste Woche einen Termin.“
Oder er bittet ihn, ein bestimmtes Produkt in einer bestimmten Variante auszuwählen. Vielleicht soll der Agent eine Versandoption prüfen, ein Formular ausfüllen oder eine Anfrage vorbereiten.
Dass das keine rein theoretische Vorstellung mehr ist, zeigt OpenAI selbst. Der Agent Mode in Atlas kann Aufgaben im Browser übernehmen und unter anderem mit Websites interagieren.
Für uns Menschen bestehen solche Vorgänge aus vielen kleinen Entscheidungen, über die wir kaum nachdenken. Wir öffnen ein Menü, erkennen einen Button, wählen einen Termin, sehen sofort, welche Option aktiv ist, und verstehen eine Fehlermeldung häufig schon anhand ihrer Position.
Ein automatisiertes System muss sich diese Bedeutung technisch erschließen.
Genau dort wird eine Website von einer reinen Informationsquelle zu einer bedienbaren digitalen Oberfläche.
Ein Button ist nicht einfach das, was wie ein Button aussieht
Eines der schönsten Beispiele dafür findet sich auf vermutlich Millionen Websites.
Ein Element soll anklickbar sein. Also bekommt irgendein Container eine Hintergrundfarbe, Innenabstand, einen Hover-Effekt und einen JavaScript-Handler.
Das Ergebnis kann so aussehen:
<div class="button" onclick="openBooking()">
Termin buchen
</div>
Für einen Menschen kann diese Lösung vollkommen eindeutig sein. Das Element sieht aus wie ein Button und verhält sich mit der Maus auch so.
Im HTML steht dort trotzdem zunächst nur ein allgemeiner Container.
Die gleiche Funktion kann mit einem Element umgesetzt werden, dessen Bedeutung bereits feststeht:
<button type="button">
Termin buchen
</button>
Optisch müssen Sie zwischen beiden Varianten überhaupt keinen Unterschied sehen. CSS kann einen echten Button genauso gestalten wie ein beliebiges div.
Technisch ist der Unterschied erheblich.
Das native <button>-Element bringt seine Funktion bereits mit. Browser und assistive Technologien wissen, dass es sich um eine Schaltfläche handelt. Auch grundlegendes Interaktionsverhalten ist bereits vorgesehen.
Ein beliebiges div muss diese Bedeutung erst künstlich bekommen. Man könnte ihm beispielsweise role="button" geben. Nur entsteht dadurch noch kein vollständiger Button. Die WAI-ARIA Authoring Practices des W3C weisen ausdrücklich darauf hin, dass eine ARIA-Rolle die dazugehörige Browserfunktion nicht automatisch mitliefert. Tastaturbedienung, Fokusverhalten und weitere erwartete Eigenschaften müssen bei einer individuell entwickelten Komponente selbst korrekt umgesetzt werden.
Das ist einer dieser Punkte, an denen technische Sauberkeit plötzlich erstaunlich praktisch wird.
Ein echter Button ist nicht besser, weil sein HTML schöner aussieht. Er ist besser, weil seine Funktion bereits Bestandteil des Elements ist.
Semantisches HTML beschreibt Bedeutung statt nur Gestaltung
Genau darum geht es bei Semantik.
HTML soll nicht ausschließlich sagen: „Hier steht etwas.“ Es kann auch beschreiben, was dieses Etwas ist.
Ein <nav> kennzeichnet Navigation. Ein <main> beschreibt den zentralen Inhalt einer Seite. Ein <button> steht für eine Aktion. Überschriften bilden eine inhaltliche Hierarchie. Listen gruppieren zusammengehörige Elemente.
Diese Bedeutung ist unabhängig vom Design vorhanden. Ein Menü bleibt technisch eine Navigation, auch wenn Sie es morgen optisch komplett verändern. Ein Button bleibt ein Button, egal ob er schwarz, gelb oder transparent dargestellt wird.
Damit entsteht eine zweite Ebene unterhalb der sichtbaren Oberfläche. Für Menschen ist das hilfreich, sobald sie assistive Technologien verwenden. Für Browser und andere Systeme entsteht zugleich eine strukturiertere Beschreibung der Seite.
Das Prinzip kennen wir im SEO längst aus einer anderen Richtung. Mit Schema.org und strukturierten Daten versuchen wir ebenfalls, Maschinen nicht nur Text zu liefern, sondern zusätzliche Informationen darüber, was dieser Text bedeutet. Semantisches HTML und strukturierte Daten sind nicht dasselbe, folgen an dieser Stelle aber einem ähnlichen Grundgedanken: Bedeutung sollte nicht ausschließlich aus der Optik erraten werden müssen.
Formulare zeigen sehr schön, wie schnell Bedeutung verloren geht
Kontaktformulare sind optisch meistens ziemlich eindeutig.
Über einem Eingabefeld steht „E-Mail-Adresse“. Daneben befindet sich vielleicht ein Feld für die Telefonnummer. Darunter folgt eine Nachricht und am Ende ein Button.
Für einen sehenden Menschen ist der Zusammenhang leicht zu verstehen. Technisch kann diese Beziehung trotzdem fehlen.
Sauber wäre beispielsweise:
<label for="email">E-Mail-Adresse</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
required
>
Das Label steht hier nicht einfach zufällig in der Nähe des Eingabefeldes. Über for="email" und id="email" sind beide Elemente programmatisch miteinander verbunden.
Das klingt nach einer Kleinigkeit, verändert aber die Qualität der Information.
Ein Screenreader kann eindeutig erkennen, was dieses Feld erwartet. Ein Browser versteht den Eingabetyp. Und ein System, das ein Formular automatisiert bedienen soll, bekommt ebenfalls eine klarere Beschreibung der vorgesehenen Eingabe.
Warum ein Placeholder kein vollwertiger Ersatz ist
Sehr beliebt sind reduzierte Formulare, bei denen die Feldbezeichnung ausschließlich innerhalb des Eingabefeldes steht:
<input type="email" placeholder="E-Mail-Adresse">
Sieht aufgeräumt aus.
Der Text verschwindet allerdings üblicherweise, sobald eine Eingabe beginnt. Bei einem kleinen Formular fällt das kaum auf. Bei einer umfangreicheren Anfrage mit Name, Unternehmen, Telefon, E-Mail, Leistung, Budget und Nachricht wird aus der visuellen Sparsamkeit schnell ein Orientierungsproblem.
Ein sichtbares und technisch verknüpftes Label ist deshalb nicht altmodisch. Es ist eindeutig.
Und Eindeutigkeit wird zunehmend wertvoll.
Bei interaktiven Websites reicht die Rolle allein nicht mehr
Eine Website besteht heute selten nur aus Text, Bildern und Links.
Menüs öffnen sich. Accordions klappen auf. Tabs wechseln Inhalte. Filter werden aktiviert. Produktvarianten ändern Preise. Dialogfenster erscheinen über dem eigentlichen Inhalt.
Damit muss ein System teilweise nicht nur erkennen, welche Funktion ein Element hat, sondern auch in welchem Zustand es sich gerade befindet.
Ein einfaches Accordion kann beispielsweise über einen Button gesteuert werden:
<button
type="button"
aria-expanded="false"
aria-controls="antwort-1"
>
Wie läuft die Beratung ab?
</button>
aria-expanded="false" bedeutet, dass der zugehörige Bereich aktuell geschlossen ist. Wird er geöffnet, ändert sich der Zustand:
aria-expanded="true"
Das W3C beschreibt diese Verbindung im offiziellen ARIA Accordion Pattern. aria-expanded bildet den aktuellen Zustand ab, während aria-controls auf den gesteuerten Inhaltsbereich verweist.
Für einen Menschen ist diese Veränderung meistens sofort sichtbar. Ein Pfeil dreht sich, Text erscheint oder die Box wird größer.
Der technische Zustand sollte dieselbe Geschichte erzählen.
Genau darin liegt ein häufiger Schwachpunkt moderner Websites: Die sichtbare Oberfläche funktioniert, während die programmatische Beschreibung hinterherhinkt.
Das Accordion ist geöffnet, aber aria-expanded steht weiterhin auf false. Eine Produktoption ist optisch markiert, aber technisch nicht als ausgewählt gekennzeichnet. Ein Menü verschwindet visuell, einzelne Elemente bleiben jedoch weiterhin über die Tastatur erreichbar.
Solche Fehler gab es lange vor ChatGPT Agent.
KI-Agenten liefern lediglich einen zusätzlichen Grund, sie ernst zu nehmen.
Eine gute Website sollte technisch dieselbe Wahrheit erzählen wie visuell
Dieser Gedanke ist vielleicht wichtiger als jedes einzelne ARIA-Attribut.
Wenn der Besucher sieht, dass ein Element aktiv ist, sollte dieser Zustand nach Möglichkeit auch programmatisch nachvollziehbar sein. Wenn etwas eine Schaltfläche ist, sollte es sich technisch wie eine Schaltfläche verhalten. Wenn eine Beschriftung zu einem Formularfeld gehört, sollte diese Beziehung im HTML existieren.
Das klingt banal.
In der Praxis geht genau diese Klarheit schnell verloren, sobald individuelle Frontend-Komponenten, Pagebuilder, Themes und JavaScript zusammenspielen. Dann entsteht eine Website, die visuell hervorragend funktioniert, deren interne Logik aber wesentlich weniger eindeutig ist.
Für Menschen kann das schon heute Barrieren erzeugen.
Für automatisierte Systeme entsteht zusätzlich Interpretationsspielraum.
Navigation wird plötzlich Teil eines automatisierten Conversion-Pfades
Bei SEO denken wir bei einer Navigation zuerst an Orientierung und interne Verlinkung.
Das bleibt richtig.
Ein Agent könnte sie zukünftig allerdings tatsächlich benutzen müssen.
Der Nutzer wird kaum sagen:
„Öffne bitte /leistungen/beratung/erstgespraech/termin/.“
Er wird sagen:
„Buche mir dort eine Beratung.“
Der Agent muss also möglicherweise zuerst die passende Leistung finden, anschließend den nächsten sinnvollen Schritt erkennen, die Terminbuchung öffnen und sich durch einen mehrstufigen Prozess bewegen.
Damit ist die Navigation nicht mehr nur ein Hilfsmittel zur Orientierung. Sie wird Teil einer Handlungskette.
Auch hier gilt allerdings: Mehr technische Auszeichnung ist nicht automatisch besser. Ein gewöhnliches Website-Menü muss nicht mit möglichst komplexen ARIA-Rollen vollgestopft werden. Native HTML-Strukturen und einfache, nachvollziehbare Interaktionen sind häufig robuster als aufwendig nachgebaute Komponenten.
Das W3C stellt für solche Komponenten eine umfangreiche Sammlung an zugänglichen UI-Patterns bereit. Sie ist vor allem dann wertvoll, wenn eine Oberfläche über einfaches natives HTML hinausgeht.
Das Ziel ist nicht maximal viel Semantik.
Das Ziel ist minimal wenig Mehrdeutigkeit.
Accordions, Modals und individuelle Auswahlfelder sind der eigentliche Härtetest
Statischer Inhalt ist vergleichsweise einfach.
Interessant wird es bei den Stellen, an denen eine Website etwas tut.
Ein Accordion besteht nur aus klickbaren Containern. Ein Tab-System kennzeichnet den aktiven Inhalt ausschließlich über Farbe. Ein Mega-Menü funktioniert hervorragend mit der Maus, aber kaum über Tastatur. Ein Schließen-Symbol in einem Popup besitzt keinen verständlichen Namen. Eine Produktauswahl besteht aus hübschen Farbfeldern, deren Bedeutung und Auswahlzustand ausschließlich über CSS dargestellt werden.
Menschen können erstaunlich viel davon trotzdem bedienen. Wir interpretieren Form, Position und Kontext und gleichen technische Unklarheiten einfach aus.
Genau das können wir von anderen Bedienformen nicht voraussetzen.
Eine sauber entwickelte Komponente benötigt deshalb mehr als die richtige Optik. Ihre Funktion, ihr Zustand und ihre Beziehungen sollten technisch nachvollziehbar bleiben.
Bei einem Modal bedeutet das beispielsweise, dass nicht nur sichtbar ein Fenster erscheint. Auch Fokusführung und Bedienbarkeit müssen zur geöffneten Dialogsituation passen. Bei einer Produktauswahl muss klar sein, welche Optionen existieren und welche davon ausgewählt ist. Beim Accordion muss ein System erkennen können, welcher Button welchen Inhaltsbereich steuert.
Das ist nicht spektakulär.
Aber genau diese unspektakulären Grundlagen entscheiden über technische Zuverlässigkeit.
Spätestens im Checkout bekommt das Thema einen Preis
Bis hierhin könnte man noch sagen: schön für Entwickler, schön für Accessibility.
Im Checkout verändert sich die Perspektive.
Stellen wir uns vor, ein Nutzer beauftragt einen Agenten damit, ein Produkt zu kaufen. Der Agent findet das richtige Angebot, öffnet die Produktseite und soll nun eine Variante auswählen.
Für den Menschen ist sofort klar:
S, M und L sind Größen.
Der schwarze Rahmen zeigt die aktuelle Auswahl.
Ein ausgegrautes Feld ist vermutlich nicht verfügbar.
Im Quellcode könnten die Optionen allerdings nur aus neutralen Containern bestehen:
<div class="size-option">S</div>
<div class="size-option active">M</div>
<div class="size-option">L</div>
Die Information „M ist ausgewählt“ steckt in diesem Fall hauptsächlich in einer CSS-Klasse und ihrer visuellen Darstellung.
Für ein automatisiertes System muss daraus erst Bedeutung abgeleitet werden.
Je komplexer der Checkout wird, desto interessanter wird dieses Problem. Lieferadresse, Versandoption, Zahlungsart, AGB, Mengenwahl, Fehlermeldungen und Bestellbutton bilden zusammen keinen hübschen Seitenabschnitt, sondern einen echten Geschäftsprozess.
Wenn der Vorgang nach erfolgreicher Produktsuche an einer schlecht ausgezeichneten Variantenauswahl scheitert, haben wir kein Sichtbarkeitsproblem mehr.
Wir haben ein Bedienbarkeitsproblem.
Und plötzlich wird semantisches HTML wirtschaftlich.
Terminbuchungen zeigen das noch deutlicher
„Buche mir nächsten Donnerstag um 14 Uhr einen Beratungstermin.“
Als Satz erstaunlich einfach.
Die Website dahinter kann erheblich komplizierter sein.
Vielleicht muss zuerst eine Leistung ausgewählt werden. Danach ein Mitarbeiter. Ein Kalender öffnet sich. Der Monat muss gewechselt werden. Verfügbare Tage werden hervorgehoben. Anschließend folgt die Uhrzeit, dann ein Formular, eine Einwilligung und schließlich die Buchungsbestätigung.
Für einen Menschen entsteht dieser Ablauf hauptsächlich über die sichtbare Oberfläche.
Ein Agent muss jeden dieser Schritte technisch nachvollziehen.
Gerade Datepicker, individuell entwickelte Select-Felder und modale Buchungsschritte gehören deshalb zu den interessanten Komponenten einer modernen Unternehmenswebsite.
Denn hier wird aus der Theorie sehr schnell ein Geschäftsvorgang.
Ein KI-System, das Ihr Unternehmen empfiehlt, ist schön.
Ein System, das anschließend zuverlässig den Termin buchen kann, ist erheblich interessanter.
Barrierefreiheit und KI-Bedienbarkeit sind nicht dasselbe
An dieser Stelle wäre es einfach, aus dem Thema eine bequeme Marketingformel zu machen:
Barrierefrei = KI-ready.
So einfach ist es nicht.
Barrierefreiheit umfasst deutlich mehr als semantisches HTML und ARIA. Kontraste, Tastaturbedienung, Fokusführung, Alternativtexte, verständliche Fehlermeldungen, Vergrößerung und viele weitere Aspekte gehören ebenfalls dazu.
Umgekehrt ist eine Website nicht automatisch barrierefrei, nur weil ein Agent ihre wichtigsten Buttons erkennt.
Die Verbindung liegt an einer anderen Stelle.
Accessibility und agentische Bedienbarkeit teilen teilweise dieselbe technische Grundlage.
OpenAI bestätigt genau diese Überschneidung für Atlas. Die dort verwendeten ARIA-Tags sind dieselben Rollen und Beschriftungen, die Screenreader unterstützen. Eine zugänglichere Website kann dem Agenten dadurch ebenfalls helfen, Seitenstruktur und interaktive Elemente besser zu verstehen.
Accessibility wird damit nicht plötzlich zum KI-Trick.
Vielmehr zeigt sich, wie sinnvoll robuste Webstandards sind. Sie lösen nicht nur das Problem, für das sie ursprünglich eingeführt wurden.
Und bitte jetzt nicht überall aria-label verteilen
Das wäre die typische Reaktion auf eine neue technische Entwicklung.
Wenn ARIA Agenten hilft, brauchen wir offenbar möglichst viel davon.
Nein.
ARIA ist kein Qualitätsstempel, den man über beliebiges HTML klebt.
Wenn ein natives HTML-Element die benötigte Funktion bereits besitzt, ist dieses in vielen Fällen die bessere Wahl. Ein echter <button> benötigt normalerweise kein zusätzliches role="button". Ein <nav> besitzt bereits Navigationssemantik. Ein korrekt verwendetes <label> ist für normale Formularfelder häufig die sauberste Lösung.
ARIA ergänzt dort, wo zusätzliche Informationen notwendig sind. Beispielsweise bei Zuständen, Beziehungen oder komplexen individuell entwickelten Komponenten.
Wer ein div mit einer Rolle versieht, übernimmt damit außerdem Verantwortung für das Verhalten, das Nutzer von dieser Rolle erwarten. Genau deshalb lohnt sich vor komplexen Eigenkonstruktionen ein Blick in die WAI-ARIA Authoring Practices.
Die sinnvolle Reihenfolge bleibt erfreulich unspektakulär:
Erst sauberes HTML. Dann prüfen, welche Bedeutung bereits vorhanden ist. Anschließend gezielt ergänzen.
Das ist weniger sexy als „AI-Optimierung“.
Funktioniert dafür aber tatsächlich.
Was hat das alles mit SEO und GEO zu tun?
Hier muss man etwas aufpassen.
Es gibt keinen belastbaren Grund für die Behauptung, Google würde eine Seite besser ranken, weil irgendwo ein <button> statt eines klickbaren <div> verwendet wird.
Aus einer technischen Empfehlung für KI-Agenten einen neuen Rankingfaktor zu basteln, wäre genau die Art SEO-Märchen, die wir nicht brauchen.
Der Zusammenhang liegt eine Ebene höher.
SEO sorgt dafür, dass Inhalte gefunden und eingeordnet werden können. GEO beschäftigt sich zusätzlich damit, wie Informationen von generativen Systemen verstanden, verarbeitet und als Quelle genutzt werden können. Die Unterschiede und Überschneidungen haben wir bereits ausführlicher unter SEO vs. GEO eingeordnet.
Agentische Systeme erweitern diese Kette:
Gefunden werden. Verstanden werden. Empfohlen werden. Bedient werden.
Eine Website kann bei den ersten drei Punkten hervorragend aufgestellt sein und anschließend trotzdem verlieren.
Das Unternehmen wird korrekt genannt.
Die Leistung wurde verstanden.
Der Agent öffnet die Website.
Und dann scheitert die Buchung an einem technisch unklaren Kalender oder die Produktauswahl an einer rein visuellen Komponente.
Die Sichtbarkeit war vorhanden.
Die technische Anschlussfähigkeit fehlte.
Genau deshalb gehört Frontend-Qualität zunehmend in dieselbe strategische Diskussion wie SEO und GEO.
Von Sichtbarkeit zu Handlungsfähigkeit
Vielleicht ist das der spannendste Gedanke hinter diesem Thema.
Jahrelang lautete die zentrale technische SEO-Frage:
Kann eine Suchmaschine verstehen, worum es auf dieser Seite geht?
Mit generativer KI kam eine weitere hinzu:
Kann ein System verstehen, weshalb dieses Unternehmen für eine bestimmte Frage relevant ist?
Agenten ergänzen nun:
Kann das System anschließend auch etwas auf dieser Website erledigen?
Das betrifft nahezu alle geschäftlich relevanten Interaktionen: eine Anfrage senden, einen Termin buchen, ein Produkt konfigurieren, eine Variante auswählen, einen Standort bestimmen, einen Filter setzen oder einen Warenkorb füllen.
Je wichtiger ein solcher Vorgang für Ihr Unternehmen ist, desto wichtiger wird die Frage, wie eindeutig er technisch aufgebaut wurde.
Dabei verschwindet klassisches SEO keineswegs. Genau das Gegenteil ist der Fall. Eine solide technische und inhaltliche Basis bleibt Voraussetzung dafür, dass Inhalte überhaupt zuverlässig gefunden, eingeordnet und verarbeitet werden können. Unser Leitfaden zur Google Suche zeigt deshalb auch bewusst das Zusammenspiel aus Technik, Content und Nutzererfahrung.
Ein einfacher Selbsttest für Ihre Website
Für einen ersten Eindruck brauchen Sie keinen neuen „AI Readiness Score“.
Nehmen Sie einen geschäftlich wichtigen Ablauf Ihrer Website. Beispielsweise Ihre Kontaktanfrage oder Terminbuchung.
Gehen Sie den Prozess einmal Schritt für Schritt durch und stellen Sie sich bei jeder Interaktion dieselbe Frage:
Woher weiß ein technisches System, was hier gerade passiert?
Ist die Aktion tatsächlich als Button umgesetzt oder sieht sie nur so aus? Ist jedes Formularfeld eindeutig beschriftet? Wird ein geöffneter Bereich auch technisch als geöffnet gekennzeichnet? Hat ein Icon-Button einen verständlichen Namen? Ist eine gewählte Variante tatsächlich als ausgewählt erkennbar?
Und funktioniert der Vorgang auch dann logisch, wenn man die reine Optik gedanklich entfernt?
Wenn die Antwort regelmäßig lautet „Das sieht man doch“, haben Sie wahrscheinlich eine Stelle gefunden, die technisch genauer betrachtet werden sollte.
Denn genau dort verlassen Sie sich darauf, dass der Nutzer Ihre Gestaltung interpretiert.
Welche Bereiche Unternehmen zuerst prüfen sollten
Nicht jede Interaktion besitzt denselben wirtschaftlichen Stellenwert. Beginnen Sie deshalb dort, wo aus Interesse eine Handlung werden soll.
Bei klassischen Unternehmenswebsites betrifft das meist Navigation, Kontaktformular, Angebotsanfrage und Terminbuchung. Bei Onlineshops kommen Filter, Produktvarianten, Warenkorb und Checkout hinzu. Plattformen und Kundenportale sollten zusätzlich Login, Suche, mehrstufige Formulare und individuell entwickelte Bedienelemente betrachten.
Dabei geht es nicht darum, eine Website ausschließlich für KI-Agenten umzubauen.
Wenn Sie an diesen Stellen saubere Strukturen, verständliche Beschriftungen, nachvollziehbare Zustände und funktionierende Tastaturbedienung herstellen, verbessern Sie häufig gleichzeitig die Website für reale Nutzer.
Und genau darin liegt der eigentliche Wert.
Sie bauen keine Sonderlösung für irgendeine mögliche Zukunft. Sie bauen Ihre Website heute technisch besser und schaffen damit gleichzeitig eine bessere Grundlage für das, was danach kommt.
Fazit: Sauberes HTML war nie unwichtig. Jetzt bekommt es nur einen weiteren Nutzer
Semantisches HTML ist kein neuer KI-Trend.
ARIA wurde nicht für ChatGPT entwickelt. Formularlabels existieren nicht, weil plötzlich Agenten Websites bedienen. Und auch der <button> hat einige Jahre Internetgeschichte überstanden, bevor Sprachmodelle auftauchten.
Neu ist der geschäftliche Zusammenhang.
Websites werden zunehmend nicht nur von Menschen betrachtet und von Suchmaschinen gecrawlt. Systeme beginnen, Inhalte zu verstehen und im Auftrag ihrer Nutzer mit Websites zu interagieren.
Damit treffen mehrere Anforderungen aufeinander. Menschen brauchen verständliche Oberflächen. Screenreader benötigen programmatisch erkennbare Strukturen. Suchmaschinen brauchen nachvollziehbare Inhalte. Generative KI braucht Kontext. Und Agenten benötigen zusätzlich Interaktionen, deren Funktion und Zustand zuverlässig erkannt werden können.
Für Unternehmen bedeutet das nicht, dass jetzt jede Website hektisch „KI-ready“ gemacht werden muss.
Es bedeutet etwas wesentlich Vernünftigeres:
Eine gute Website sollte im Code dieselbe Klarheit besitzen wie auf dem Bildschirm.
Wer heute eine Website technisch analysiert, sollte deshalb nicht bei Ladezeit, Meta-Daten und Überschriften aufhören. Navigation, Formulare, Dialoge, Zustände, Filter, Produktvarianten, Terminbuchungen und Checkout gehören genauso dazu.
Denn in einer agentischen Welt reicht es irgendwann möglicherweise nicht mehr, dass ein KI-System Ihr Unternehmen findet und empfiehlt.
Die interessantere Frage lautet:
Versteht es auch, wie aus dieser Empfehlung eine Anfrage, ein Termin oder ein Kauf wird?
Und genau dort wird aus sauberem HTML ein Wirtschaftsfaktor.
FAQ zu semantischem HTML und KI-Agenten
Nutzt ChatGPT Agent tatsächlich ARIA-Informationen?
Ja. OpenAI dokumentiert in den Publisher- und Entwickler-FAQ, dass ChatGPT Atlas ARIA-Tags nutzt, um Seitenstruktur und interaktive Elemente zu interpretieren. Beschreibende Rollen, Labels und Zustände helfen dabei, unter anderem Buttons, Menüs und Formulare besser zu verstehen.
Ist eine barrierefreie Website automatisch besser für KI-Agenten?
Es gibt eine deutliche technische Überschneidung, aber keine automatische Gleichsetzung. Barrierefreiheit umfasst zahlreiche weitere Anforderungen. Semantisch saubere und zugängliche Strukturen können jedoch gleichzeitig auch automatisierten Systemen die Interpretation einer Website erleichtern.
Ist ein echtes <button> besser als ein klickbares <div>?
Wenn die Funktion tatsächlich eine Schaltfläche ist, normalerweise ja. Das native Button-Element besitzt bereits passende Semantik und vorgesehenes Interaktionsverhalten. Bei einem beliebigen Container müssen diese Eigenschaften selbst korrekt ergänzt werden. Die technischen Grundlagen dazu beschreibt das W3C in seinen WAI-ARIA Authoring Practices.
Muss ich jetzt möglichst viele ARIA-Attribute verwenden?
Nein. Native HTML-Elemente sollten bevorzugt werden, wenn sie die benötigte Bedeutung bereits mitbringen. ARIA ergänzt dort, wo zusätzliche Rollen, Beziehungen oder Zustände notwendig sind.
Verbessert semantisches HTML direkt mein Google-Ranking?
Ein pauschaler direkter Rankingvorteil lässt sich daraus nicht seriös ableiten. Der Nutzen liegt in einer klareren technischen Struktur, besserer Accessibility, robuster Bedienbarkeit und einer besseren Grundlage für Systeme, die Inhalte und Interaktionen maschinell interpretieren.
Was sollte ich auf meiner Website zuerst überprüfen?
Beginnen Sie mit den Wegen, die wirtschaftlich relevant sind: Kontaktformular, Terminbuchung und zentrale Navigation. Bei Onlineshops gehören Produktauswahl, Filter, Warenkorb und Checkout ebenfalls ganz nach oben auf die Liste.
