Ein Test im Juli bei 200 Amsterdamer Restaurants zeigte, dass aktuelle KI-Assistenten keine Tischreservierungen abschließen können, weil das Buchungswidget in einem iframe versteckt ist.

Warum das iframe Agenten blockiert

Die meisten Online-Reservierungstools werden als eingebettetes iframe bereitgestellt. Ein Besucher klickt auf eine Schaltfläche „Reservieren“, ein Kalender öffnet sich und der Nutzer wählt ein Zeitfenster aus. Für einen Menschen funktioniert der Prozess; für einen KI-Agenten stockt er.

  • Der Agent analysiert die Haupt-HTML-Seite.
  • Die Buchungsschaltfläche verweist auf eine URL auf einer anderen Domain.
  • Der Browser lädt diese URL innerhalb eines iframes, wodurch sie von der übergeordneten Seite isoliert wird.

Da die Same-Origin-Policy verhindert, dass Skripte auf der übergeordneten Seite das DOM des iframes lesen oder dessen Netzwerkaufrufe abfangen, sieht ein KI-Agent, der Seiteninhalte liest und HTTP-Anfragen sendet, nur die Schaltfläche. Er sieht niemals den Kalender, die Zeitfenster oder den Bestätigungsprozess. Selbst wenn er auf die Schaltfläche klickt, muss er Captchas lösen, sich an Layoutänderungen anpassen oder die Anti-Automatisierungs-Abwehrmechanismen umgehen, die viele Buchungsdienste einsetzen.

Die fehlende maschinenlesbare Verknüpfung

Eine separate Prüfung von 163 funktionsfähigen Restaurant-Websites ergab, dass nur neun maschinenlesbare Buchungsdaten bereitstellten. Diese neun listeten Basisinformationen – Name und Adresse – unter Verwendung von schema.org-Markup, enthielten jedoch keine Reservierungsaktionen, die ein Agent aufrufen könnte. Schema.org definiert für diesen Zweck Typen wie ReserveAction, doch die meisten Websites veröffentlichen nur beschreibende Metadaten, keine ausführbaren Anweisungen.

In der Praxis sucht ein Assistent nach strukturierten Daten, die ihm sagen, wie eine Aufgabe auszuführen ist, nicht nur, was die Aufgabe ist. Ohne eine ReserveAction oder einen vergleichbaren Endpunkt fällt der Agent auf das Nachahmen eines menschlichen Klicks zurück, was, wie oben beschrieben, unzuverlässig ist.

Eine praktische Lösung, ohne das UI zu zerschlagen

  1. Veröffentlichung einer Buchungs-API – Erstellen Sie einen leichtgewichtigen HTTP-Endpunkt, der JSON-Anfragen für Verfügbarkeitsabfragen und die Erstellung von Reservierungen akzeptiert. Die API liefert Felder wie Datum, Uhrzeit, Personenanzahl und Bestätigungscode zurück. Jeder Agent kann sie nutzen, ohne eine Seite rendern zu müssen.
  2. Die API auffindbar machen – Platzieren Sie einen Verweis an einer bekannten Stelle, wie etwa /.well-known/booking, oder betten Sie einen ReserveAction-Eintrag in das schema.org-Markup der Seite ein. Dies signalisiert Agenten: „Hier gibt es einen programmatischen Weg zu buchen“, ohne dass Scraping erforderlich ist.
  3. Einführung des Model Context Protocol (MCP) – MCP ermöglicht es Assistenten, externe Tools direkt aufzurufen, Eingaben zu übergeben und strukturierte Ausgaben zu erhalten. Große KI-Anbieter unterstützen bereits MCP, sodass ein Restaurant, das einen MCP-kompatiblen Endpunkt implementiert, von Agenten aufgerufen werden kann, als handele es sich um eine integrierte Funktion.

Diese Schritte ermöglichen es, das visuelle iframe für menschliche Nutzer beizubehalten, während Agenten gleichzeitig einen sauberen, zuverlässigen Zugang zu denselben Reservierungsdaten erhalten.

Fazit

Das Einbetten eines Kalenders in ein iframe schützt den visuellen Ablauf für Menschen, lässt KI-Assistenten jedoch im Dunkeln stehen. Das Hinzufügen einer bescheidenen, gut dokumentierten Buchungs-API und deren Bewerbung über Standard-Metadaten oder MCP eröffnet einen neuen Reservierungskanal, ohne die Website komplett überarbeiten zu müssen. Dieser Aufwand erhöht die Sichtbarkeit für die nächste Generation digitaler Assistenten, und das Risiko kann mit denselben Sicherheitskontrollen gesteuert werden, die bereits für das bestehende UI verwendet werden.