Wer in diesen Wochen PageSpeed Insights öffnet, findet unter den vertrauten Kategorien eine neue: „Agentisches Browsing“. Google bewertet dort seit Mai 2026 nicht mehr nur, wie schnell Ihre Website für Menschen ist, sondern wie gut KI-Agenten sie lesen, verstehen und bedienen können. Und in dieser Kategorie taucht dreimal ein Begriff auf, den die wenigsten je gehört haben: WebMCP.

Wir haben beides auf unserer eigenen Website umgesetzt. Hier ist die Einordnung und der ehrliche Praxisbericht.

Was Google seit Mai 2026 prüft

Die neue Kategorie ist offiziell experimentell und fließt (noch) nicht in die klassischen Scores ein. Aber sie zeigt unmissverständlich, wohin die Reise geht. Drei Prüfungen laufen standardmäßig:

  1. Der Accessibility-Baum: die strukturierte Textversion Ihrer Seite, die auch Screenreader nutzen. KI-Agenten „sehen“ Websites nicht als Pixel, sondern als diese Struktur. Saubere Überschriften, beschriftete Formularfelder und echte HTML-Inhalte sind hier bares Geld, dieselben Hausaufgaben wie bei der Barrierefreiheit.
  2. Layout-Stabilität: Springt das Layout beim Laden, verklickt sich nicht nur der Mensch, sondern auch der Agent. Das ist derselbe CLS-Wert, den wir im Artikel zu den Core Web Vitals erklären.
  3. Eine gültige llms.txt: die kuratierte Inhaltsübersicht für KI-Systeme im Stammverzeichnis. Was das ist und warum sie zum LLMO-Grundgerüst gehört, steht im Artikel LLMO: So taucht Ihr Unternehmen in KI-Antworten auf.

Bemerkenswert daran: Google adelt damit Maßnahmen, die bis vor Kurzem als Nische galten. Wer LLMO bisher für Zukunftsmusik hielt, bekommt jetzt von Google ein Prüfprotokoll dazu.

Von „Agent rät“ zu „Website sagt, was sie kann“

Bisher bedienen KI-Agenten Websites wie ein sehr geduldiger Praktikant ohne Einarbeitung: Seite anschauen, raten, wo man klickt, hoffen, dass das Formular abgeschickt wurde. Das ist langsam und geht erstaunlich oft schief.

WebMCP (Web Model Context Protocol) dreht das um. Der Standard-Vorschlag (gemeinsam von Google und Microsoft beim W3C eingebracht) lässt eine Website ihre Aktionen als „Tools“ ausweisen: mit Namen, Beschreibung und klar definierten Feldern. Der Agent muss nicht mehr raten, wo er klickt. Die Website sagt ihm: „Das hier kann ich. Diese Angaben brauche ich. So rufst du mich auf.“

Das Schöne: Für den häufigsten Fall (Formulare) braucht es dafür kein JavaScript, sondern nur ein paar zusätzliche HTML-Attribute am bestehenden Formular:

<form
  toolname="website_check_anfordern"
  tooldescription="Fordert den kostenlosen Website-Check an."
  toolautosubmit
>
  <label for="url">Ihre Website-Adresse</label>
  <input
    id="url"
    name="url"
    type="url"
    required
    toolparamdescription="Vollständige Adresse der zu prüfenden Website"
  />
  <!-- … -->
</form>

Für Aktionen ohne Formular gibt es zusätzlich eine JavaScript-API (document.modelContext), über die sich Tools programmatisch registrieren lassen. Wenn Ihnen das bekannt vorkommt: WebMCP überträgt die Idee von MCP (dem Standard, mit dem KI-Modelle Werkzeuge nutzen) auf den Browser.

Unser Praxisbericht: eingebaut in einem Nachmittag

Auf clicktype.de sind seit heute zwei WebMCP-Tools live: Ein KI-Agent kann den kostenlosen Website-Check anfordern und eine Kontaktanfrage senden, mit sauberer Rückmeldung an den Agenten, ob es geklappt hat.

Der ehrliche Aufwand: gut eine Stunde. Nicht, weil WebMCP so trivial wäre, sondern weil die Hausaufgaben schon gemacht waren: unsere Formulare sprechen mit einem sauberen API-Endpunkt, jedes Feld hat ein echtes Label, die Seite ist vollständig maschinenlesbar. Wer auf einem soliden Fundament baut, schraubt neue Standards in Stunden an. Wer auf einem Baukasten-Flickenteppich sitzt, fängt bei null an.

Genauso ehrlich: Heute ruft diese Tools noch fast niemand auf. WebMCP steckt in der Chrome-Erprobungsphase (Origin Trial), andere Browser sind noch in der Diskussion. Es wird 2026 niemand eine Anfrage über WebMCP stellen, der sie nicht auch klassisch gestellt hätte.

Warum wir es trotzdem jetzt einbauen

Drei Gründe, und keiner davon heißt „weil es neu ist“:

  • Die Richtung ist eindeutig. Wenn Google eine eigene Prüfkategorie dafür ausrollt und mit Microsoft gemeinsam am Standard schreibt, ist das keine Spielerei mehr. Agenten, die Termine buchen, Anfragen stellen und Bestellungen auslösen, sind der erklärte Plan der Browser-Hersteller.
  • Früh üben, am eigenen Objekt. Wir bauen so etwas zuerst bei uns ein, bevor wir es Kunden empfehlen. Was wir dabei über Feldbeschreibungen, Rückmeldungen und Stolperfallen gelernt haben, fließt direkt in Kundenprojekte.
  • Der Aufwand ist klein, wenn die Basis stimmt. Und das ist der eigentliche Punkt: Die Basis (schnelle Technik, saubere Struktur, Maschinenlesbarkeit) ist dieselbe, die heute schon über Sichtbarkeit in KI-Antworten entscheidet. WebMCP ist dann nur noch die Kür.

Für wen lohnt sich das jetzt schon?

Die Reihenfolge ist entscheidend. WebMCP ist der zweite Schritt, nicht der erste:

  1. Erst die Pflicht: eine Website, die Menschen und Maschinen lesen können – schnelle Ladezeit, klare Struktur, beschriftete Formulare, strukturierte Daten, llms.txt. Das ist klassisches LLMO und wirkt sofort, weil KI-Systeme diese Signale heute schon auswerten.
  2. Dann die Kür: Aktionen als Tools ausweisen. Am meisten profitieren Websites, deren wichtigste Aktion ein klarer Vorgang ist: Termin buchen, Tisch reservieren, Anfrage stellen, Angebot anfordern. Genau die Vorgänge, die ein Assistent künftig im Auftrag seines Nutzers erledigt.

Ein Gedanke zum Schluss: Als Suchmaschinen groß wurden, gewannen die Websites, die früh verstanden hatten, wie Google liest. Bei KI-Agenten wiederholt sich das gerade – nur schneller. Der Unterschied zwischen „früh dabei“ und „zu spät“ ist diesmal kein Jahrzehnt, sondern ein paar Quartale.

Ob Ihre Website für KI-Systeme lesbar ist, prüfen wir übrigens als festen Punkt im kostenlosen Website-Check: Antwort werktags innerhalb von 48 Stunden, ohne Verkaufsshow. Und wenn ein KI-Agent diesen Check für Sie anfordert: umso besser, dann wissen Sie, dass es funktioniert.