Deine Website bekommt bald Besuch, der kein Mensch ist

In meinem letzten Website-Bericht stand eine Kategorie, die es im Jahr davor noch nicht gab. Sie heisst «Agentisches Browsing» und steht ganz unten, hinter Leistung, Barrierefreiheit und SEO. Bei mir stand dort zuerst eine 1 von 2.

Ich habe eine Weile gebraucht, um zu verstehen, was Google damit eigentlich misst. Und noch länger, um einzuordnen, wie ernst man es nehmen sollte. Die kurze Antwort: ernster als der Hype, aber weniger dringend, als manche behaupten.

Was hier eigentlich geprüft wird

Bisher wurde eine Website danach bewertet, wie schnell sie lädt, wie gut sie bedienbar ist und ob Suchmaschinen sie verstehen. Alles drei geht davon aus, dass am Ende ein Mensch davorsitzt.

Diese Annahme stimmt immer seltener. Wenn heute jemand seinen KI-Assistenten bittet, einen Handwerker in der Region zu finden oder Preise zu vergleichen, besucht nicht der Mensch die Website, sondern ein Programm in seinem Auftrag. Und diese Programme lesen eine Seite völlig anders als du und ich.

Die neue Kategorie prüft vier Dinge:

• Den Accessibility-Baum. Das ist die strukturierte Fassung deiner Seite, die ursprünglich für Screenreader gedacht war. Für KI-Agenten ist sie inzwischen die wichtigste Informationsquelle.
• Die visuelle Stabilität. Wenn sich beim Laden noch Elemente verschieben, klickt ein Agent möglicherweise auf die falsche Stelle.
• WebMCP. Ein vorgeschlagener Standard, über den eine Website ihre eigenen Funktionen aktiv für Agenten bereitstellen kann.
• Eine Datei namens llms.txt. Eine maschinenlesbare Zusammenfassung im Wurzelverzeichnis der Domain.

Es gibt keine Note von 0 bis 100 wie bei den anderen Kategorien, sondern nur ein Verhältnis bestandener Prüfungen. Google sagt selbst, es gehe vorerst darum, Daten zu sammeln, nicht darum, eine Rangliste zu erstellen.

Der Punkt, an dem Google sich selbst widerspricht

Und hier wird es interessant. Bei llms.txt sagen zwei Abteilungen desselben Unternehmens etwas Unterschiedliches.

Das Search-Team hat einen Leitfaden veröffentlicht, in dem llms.txt ausdrücklich unter den Dingen steht, die man für die Sichtbarkeit in KI-Suchfunktionen nicht braucht. John Mueller von Google hat die Datei sogar öffentlich mit dem Keywords-Meta-Tag verglichen, also mit jener Angabe aus den frühen 2000er-Jahren, die irgendwann von allen ignoriert wurde.

Gleichzeitig prüft Chrome mit Lighthouse genau diese Datei.

Der Widerspruch löst sich auf, wenn man zwei Dinge auseinanderhält. Für die Suche und für Zitate in KI-Antworten bringt llms.txt tatsächlich nichts. Für einen Agenten, der bereits auf deiner Seite ist und sich zurechtfinden muss, kann sie helfen. Das ist ein Unterschied wie zwischen einem Wegweiser an der Autobahn und einem Lageplan im Eingangsbereich.

Meine Einschätzung: Die Datei ist in zwanzig Minuten gebaut und kostet danach nichts. Man sollte sie machen und dann nicht mehr darüber reden. Wer sie als Ranking-Massnahme verkauft, verkauft dir etwas, das Google selbst ausgeschlossen hat.

WebMCP ist der eigentlich spannende Teil

Deutlich interessanter finde ich den zweiten neuen Baustein, auch wenn er heute für kaum ein KMU relevant ist.

Um zu verstehen, warum, muss man wissen, wie KI-Agenten aktuell mit Websites umgehen. Sie laden die Seite, machen davon eine Bildschirmaufnahme und lassen ein Bilderkennungsmodell raten, welcher Pixelbereich wohl der Suchknopf ist. Dann bewegen sie den Zeiger dorthin und klicken. Das funktioniert erstaunlich oft, aber es ist langsam, fehleranfällig und bricht bei jedem Redesign.

WebMCP dreht das um. Statt raten zu lassen, meldet die Website ihre Funktionen selbst an. Sie sagt sinngemäss: hier ist meine Suche, sie nimmt einen Suchbegriff entgegen und liefert eine Liste zurück. Der Agent ruft die Funktion dann direkt auf, so wie ein Programm eine andere Funktion aufruft. Keine Bildschirmaufnahme, kein Raten.

Für einen Onlineshop oder ein Buchungssystem ist das mittelfristig ein grosses Thema. Für eine Handwerkerseite mit Kontaktformular vorerst nicht.

Und der Stand ist deutlich früher, als die Aufregung vermuten lässt. WebMCP läuft als Origin Trial, man braucht dafür eine Registrierung, und in Chrome muss ein Schalter umgelegt werden. Wer heute WebMCP einbaut, baut für eine Zukunft, die noch nicht da ist.

Zwei von vier Punkten sind alte Bekannte

Das ist der Teil, den ich am bemerkenswertesten finde.

Der Accessibility-Baum und die visuelle Stabilität sind keine neuen Anforderungen. Beides gibt es seit Jahren. Barrierefreiheit war immer eine Frage von semantischem HTML, sauberen ARIA-Kennzeichnungen und Elementen, die einen lesbaren Namen haben. Layoutstabilität ist seit der Einführung der Core Web Vitals ein Standardthema.

Wer in den letzten Jahren sauber gearbeitet hat, hat hier automatisch einen Vorsprung. Wer geschludert hat, zahlt jetzt ein zweites Mal.

Bei mir selbst war es genau so. Von den vier Prüfbereichen war nur einer wirklich offen, und der Grund war ein einziger Link in meinem Cookie-Banner, der ins Leere zeigte und keinen lesbaren Text hatte. Ein Fehler, der auch für einen blinden Besucher mit Screenreader ein Problem gewesen wäre. Nur hatte ihn nie jemand gemeldet, weil niemand im Cookie-Banner auf Links klickt.

Nach der Reparatur und der zusätzlichen Textdatei stand dort 3 von 3.

Zum Vergleich: Grosse Plattformen mit hunderten Entwicklern scheitern an genau diesen Prüfungen. Es ist also keine Frage der Firmengrösse, sondern der Sorgfalt.

Was ich einem KMU heute raten würde

Meine Reihenfolge, vom Wichtigsten zum Verzichtbaren:

1. Accessibility aufräumen. Jedes Bild braucht einen Alternativtext, jeder Link einen aussagekräftigen Text, jede Überschrift ihre richtige Ebene. Das hilft Menschen mit Behinderung, es hilft Suchmaschinen, und es hilft jetzt eben auch Agenten. Dreifacher Nutzen, keine Wette auf die Zukunft.
2. Layout stabilisieren. Bilder mit festen Abmessungen versehen, damit beim Laden nichts springt. Verbessert nebenbei die Kernkennzahlen, die Google seit Jahren bewertet.
3. llms.txt anlegen. Zwanzig Minuten Aufwand, danach vergessen. Wenn sich der Standard durchsetzt, bist du dabei. Wenn nicht, hast du nichts verloren.
4. WebMCP beobachten. Nicht einbauen, nur im Blick behalten. Wenn du einen Shop oder ein Buchungssystem betreibst, wird das Thema in ein bis zwei Jahren relevant. Vorher nicht.

Was ich ausdrücklich nicht empfehle: Geld in Beratung zu stecken, die dir heute eine Optimierung für KI-Suchmaschinen verkaufen will. Der Markt ist voll davon, und der grösste Teil davon ist nicht belegbar.

Warum das Thema trotzdem zählt

Es gibt einen Satz, der mir seit Wochen nicht aus dem Kopf geht: Der Browser verändert gerade seine Rolle.

Zwanzig Jahre lang war eine Website ein Schaufenster für Menschen. Sie musste hübsch aussehen, schnell laden und verständlich sein. Das bleibt so. Aber daneben entsteht eine zweite Nutzung, bei der eine Maschine die Seite besucht, versteht und für ihren Auftraggeber handelt.

Wenn deine Website für Maschinen unlesbar ist, verschwindest du nicht sofort. Aber du wirst schrittweise unsichtbarer für eine Gruppe von Besuchern, die es vor drei Jahren noch gar nicht gab.

Und das Beste daran: Der grösste Teil dieser Arbeit ist genau das Handwerk, das man ohnehin machen sollte. Sauberes Markup, verständliche Struktur, stabile Darstellung, keine Elemente ohne Namen. Nichts davon ist neu, nichts davon ist teuer, und nichts davon wird wertlos, falls sich die Standards anders entwickeln als erwartet.

Man kann das als lästige Zusatzanforderung sehen. Ich sehe es eher als späte Bestätigung dafür, dass ordentliche Arbeit sich am Ende auszahlt.

Wenn du wissen willst, wie deine Website in dieser Kategorie dasteht, findest du sie unten in jedem Lighthouse-Bericht. Und wenn du Unterstützung dabei willst, das aufzuräumen, was dort bemängelt wird, melde dich einfach.