Warum Drupal-Sites von KI gelesen und zitiert werden

KI-Systeme crawlen bereits Artikel, öffnen Produktseiten w laufenden Gesprächen und folgen Links beim Vorbereiten von Antworten. Manchmal zitieren sie die Quelle. Oft lesen sie Hunderte Seiten und senden fast keinen Traffic zurück.

Cloudflare schätzt, dass automatisierte Bots inzwischen rund 57 % aller Web-Requests erzeugen. Maschinen-Traffic hat menschlichen Traffic überholt. KI-Crawler und Agenten sind Teil dieser Veränderung, obwohl nicht jeder Bot mit KI verbunden ist.

Eine Analyse der Cloudflare-Logs über einen Monat im März 2026 fand, dass KI-Crawler 1.241 Seiten pro Zitat abrufen, das eine KI-Answer-Engine sendete. Dieselben Logs zeigten GPTBot, OAI-SearchBot, ClaudeBot und andere Crawler, die sowohl normale HTML-Seiten als auch alternative Markdown-Versionen anforderten.

Die praktische Frage ist, ob ein KI-System versteht, was es findet. Kann es Produktname, Preis, Einheit und Verfügbarkeit erkennen? Stimmen die strukturierten Daten mit der sichtbaren Seite überein? Findet es den aktuellen Wert oder eine Kopie, die seit letztem Jahr nicht aktualisiert wurde?

Drupal von KI zitiert funktioniert, wenn ein gespeicherter Wert auf der Seite, in JSON-LD, in einer Markdown-Version, in einem Produkt-Feed und über eine API erscheint. Redakteure aktualisieren ihn einmal. Jede generierte Version kann mit folgen. Lesen Sie auch: KI-Empfehlung für Lieferanten: Shortlist-Fakten - warum veröffentlichte Specs zählen, sobald Fetcher die Seite lesen können.

JSON:API ist Teil von Drupal Core. Contributed Modules ergänzen Markdown, llms.txt, Feeds, Authentifizierung und MCP-Tools. Manche gibt es seit Jahren; andere sind neu.

In diesem Artikel:

• Besuchen KI-Crawler bereits Ihre Website?
• Was braucht KI, bevor sie Ihre Seite zitieren kann?
• Wie machen Drupal-Felder Fakten für KI verständlicher?
• Wie veröffentlicht Drupal Content in Formaten, die KI lesen kann?
• Wie ist Drupal-Content über einzelne Seiten hinaus verfügbar?
• Was braucht Drupal noch über gute Module hinaus?
• Ist Drupal bereit für das Web der LLMs?
• Häufige Fragen

Besuchen KI-Crawler bereits Ihre Website?

Der Cloudflare-Crawler-Report zeigt, dass 52 % der Crawler-Requests im Juni 2026 mit KI-Training zusammenhingen, gegenüber 22 % im Frühjahr 2025. KI ist nicht die einzige Quelle automatisierter Zugriffe, macht aber inzwischen einen großen Teil der Crawling-Aktivität aus.

Diese Requests dienen unterschiedlichen Zwecken. GPTBot sammelt Trainings-Content, OAI-SearchBot unterstützt Suche, und ChatGPT-User kann während eines Live-Gesprächs eine Seite öffnen. Eine robots.txt-Regel für den einen kontrolliert nicht zwingend die anderen.

Das sehen Sie in Ihren Server-Logs:

203.0.113.50 - - [13/Dec/2025:10:15:30 +0000] "GET /products/pump-a HTTP/1.1" 200 1234 "-" "GPTBot/1.0"

Der Eintrag identifiziert URL, Bot und Response-Status. Analytics-Tools verpassen Crawler-Traffic oft, weil Bots keine Browser-Skripte ausführen. Nutzen Sie Server-, CDN- oder WAF-Logs.

Abgerufen zu werden ist noch weit von einem Zitat entfernt. Das Verhältnis oben macht das deutlich. Die Seite braucht trotzdem eine nützliche, direkte und aktuelle Antwort.

Was braucht KI, bevor sie Ihre Seite zitieren kann?

Ein KI-System braucht sechs Dinge von einer Unternehmens-Website. Drupal hat eine praktische Antwort auf jedes davon.

1. Abrufbare Seiten: robots.txt, eine WAF-Challenge, eine Login-Wall oder clientseitig gerendertes JavaScript können einen Crawler stoppen. Drupal rendert standardmäßig vollständiges HTML serverseitig, sodass der Hauptcontent nicht von JavaScript abhängt. Siehe Kann KI Ihre Website tatsächlich lesen? für die Checks außerhalb des CMS.
2. Explizite Fakten: ein Modell kann „Lieferung dauert 10 Werktage“ zuverlässiger nutzen als „Wir liefern schnell“. Drupal speichert Werte wie Abmessungen, Normen, Mindestbestellmengen und Service-Limits in benannten Feldern.
3. Eine Bedeutung überall: wenn die Seite EUR 120 sagt, JSON-LD EUR 99 und das PDF „Kontaktieren Sie uns“, muss das System wählen. Drupal kann Seite, strukturierte Daten, Feed und API-Antwort aus demselben Feld erzeugen.
4. Aktuelle Informationen: ein sichtbares Aktualisierungsdatum hilft, aber der Publishing-Prozess zählt mehr. Entity-Updates und Cache-Metadaten in Drupal können jede Ausgabe aktualisieren, die von einem geänderten Preis oder einer Spec abhängt.
5. Content getrennt vom Layout: Modelle können HTML parsen, aber Menüs, Banner und wiederholte Elemente verbrauchen Kontext. Drupal hält das Content-Modell getrennt vom Theme und kann dieselbe Entität bei Bedarf in saubereren Formaten veröffentlichen.
6. Ein Weg, größere Sammlungen zu durchsuchen: 5.000 Produktseiten einzeln zu öffnen, ist verschwenderisch. Drupal bietet Views, Feeds und JSON:API, während MCP-Module begrenzte Tools für Agenten bereitstellen können.

Dasselbe Drupal-Feature liegt unter den meisten dieser Antworten: Felder.

Wie machen Drupal-Felder Fakten für KI verständlicher?

Stellen Sie sich vor, ein Hersteller verkauft eine Pumpe mit 12-V-Versorgung, maximal 4.500 Litern pro Stunde, IP68-Schutz und zwei Jahren Garantie.

Diese Werte können als ein Absatz ins Body-Feld geschrieben werden. Das geht schnell. Es macht jeden Wert aber schwer wiederverwendbar. Ein Entwickler muss den Fließtext parsen oder die Daten in eine Produkttabelle, Schema-Markup und externen Feed kopieren. Die Kopien driften auseinander, sobald jemand eine davon bearbeitet.

In Drupal kann jeder Wert ein eigenes Feld haben:

Die Produktseite zeigt diese Felder. JSON-LD labelt sie, eine View baut eine Vergleichstabelle, JSON:API liefert sie an eine Anwendung, und ein MCP-Tool durchsucht sie per Parameter.

Ein Wert, mehrere Verwendungen.

Wenn ein Redakteur die Verfügbarkeit ändert, kann Drupal die relevanten Cache-Einträge invalidieren und jede Ausgabe aus dem neuen Wert neu erzeugen. Das Team muss sich nicht merken, dass derselbe Satz in drei Templates und zwei Dateien kopiert wurde.

Jedes CMS mit striktem Content-Modell kann einen Teil dieser Vorteile liefern. Drupals Vorteil ist, dass Berechtigungen, Cache-Metadaten, Views und JSON:API dieselben Entitäten und Felder bereits verstehen. Dasselbe Muster steht im Zentrum von strukturierten Content-Operations im großen Maßstab.

Wie veröffentlicht Drupal Content in Formaten, die KI lesen kann?

Das Web testet mehrere Wege, Content für LLMs leichter lesbar zu machen: saubereres HTML, JSON-LD, Markdown-Versionen, llms.txt und neue Discovery-Dateien. Manche sind etablierte Standards. Andere sind Experimente mit gemischter Evidenz.

Drupals Vorteil ist praktisch. Es kann alle aus demselben Content-Modell unterstützen, ohne Redakteure zu separaten Kopien zu zwingen. Für jedes Format sind die nützlichen Fragen dieselben: Was löst es, wie viel Evidenz spricht dafür, und was kann Drupal heute liefern?

Warum zählt die normale HTML-Seite am meisten?

KI-Crawler verstehen HTML bereits. Google sagt ausdrücklich, dass separate KI-Dateien für generative Search-Features nicht nötig sind. Eine gut gebaute Drupal-Seite ist deshalb die erste Priorität, kein Fallback nach JSON-LD, Markdown oder llms.txt. 10 SEO-Funktionen, die ein modernes CMS haben sollte deckt die Crawlability-Basis ab, die Drupal bereits unterstützt.

Die Hauptfakten sollten in der ersten HTML-Antwort stehen. Überschriften sollten ihre Abschnitte beschreiben. Tabellen sollten echte HTML-Tabellen sein, keine Screenshots. Videos sollten Transkripte haben. Wichtige Informationen sollten nicht nur in einem PDF leben.

Stabile URLs zählen ebenfalls. Pathauto erzeugt vorhersagbare Aliase, Redirect bewahrt alte Links. Last-Modified und ETag lassen einen Server 304 Not Modified zurückgeben, und JSON-LD sollte dateModified aus dem echten Änderungsdatum der Entität nehmen.

Drupals Position: diese Anforderung ist bereits durch die normale Architektur der Plattform abgedeckt. Drupal rendert vollständiges HTML serverseitig, speichert Content in Feldern, erzeugt stabile Aliase und hat ausgereifte Tools für Redirects, Sitemaps und Cache-Metadaten. Eine korrekt konfigurierte Drupal-Site startet mit dem Format, das jeder Crawler bereits versteht.

Warum bleibt generiertes JSON-LD mit der Seite konsistent?

JSON-LD beschreibt eine Seite mit schema.org-Typen und -Properties. Ein Produkt kann Name, Marke, Kennung und Angebot haben. Ein Artikel kann Autor und Änderungsdatum identifizieren. Eine Organisation kann offizielle Profile auflisten.

Auf einer bestehenden Drupal-Site liefern Metatag und Schema.org Metatag die übliche Implementierung. Für Feld-Mapping und CI-Validierung siehe JSON-LD in Drupal: strukturierte Daten aus Feldern mit Schema.org Metatag.

Metatag definiert Defaults pro Content-Typ. Tokens ziehen Werte aus der Entität. Schema.org Metatag druckt ein JSON-LD-Skript im Page-Head. Ein Produkt-Mapping könnte nutzen:

• den Node-Titel für name,
• dedizierte Spec-Felder für additionalProperty,
• das Preisfeld für price,
• das Währungsfeld für priceCurrency,
• das Entity-Änderungsdatum für dateModified.

Redakteure fügen kein JSON in einen Texteditor ein. Sie aktualisieren das Produkt.

Diese Unterscheidung zählt. Handgeschriebenes JSON-LD kann nach der nächsten Content-Änderung von der Seite abweichen. Generiertes JSON-LD liest dieselben Felder wie das sichtbare Template, sodass beide Ausgaben zusammen wandern.

Schema.org Blueprints kann stattdessen ein neues Drupal-Content-Modell aus schema.org-Definitionen aufbauen. Das passt zu einem neuen Katalog; kombinieren Sie beide Mapping-Systeme auf einem Content-Typ nicht ohne klaren Grund.

JSON-LD hilft einem System zu erkennen, was ein Wert bedeutet. Es garantiert kein Zitat oder Ranking, ist aber ein etablierter Weg, Produkte, Artikel, Organisationen und andere Entitäten zu beschreiben.

Drupals Position: die Unterstützung ist ausgereift. Metatag und Schema.org Metatag erzeugen JSON-LD aus denselben Feldern, die die sichtbare Seite bauen. Redakteure ändern den Fakt einmal, und Drupal aktualisiert beide Versionen. Neue Projekte können mit Schema.org Blueprints weitergehen und das Content-Modell von Anfang an um schema.org-Typen aufbauen.

Was bringen Markdown-Versionen, und was nicht?

Markdown entfernt viel Code und wiederholtes Layout um einen Artikel. Überschriften, Absätze, Links, Listen und Tabellen bleiben. Navigation, Banner und dekorative Wrapper können verschwinden.

In derselben Analyse aus März 2026 fügte der Site-Betreiber Markdown auf jeder Seite hinzu und prüfte danach einen Monat Crawler-Traffic. Dedizierte .md-URLs erhielten echte Requests. Rund 35 % der GPTBot-Requests und 23 % der OAI-SearchBot-Requests gingen an Markdown-Dateien. Amazonbot und ClaudeBot nutzten sie seltener. ChatGPT-User und PerplexityBot berührten sie kaum.

Die Evidenz ist gemischt. Keiner der zehn gemessenen Bots forderte Markdown über Content Negotiation an. Bots luden auch HTML und Markdown, was Crawler-Traffic um etwa 7 % erhöhte. Der Test zeigte nicht, dass Markdown zu mehr Zitaten führte, und Google sagt, separate Markdown-Dateien seien für Search nicht nötig.

Markdown ist deshalb ein vernünftiges Experiment, kein Ersatz für gutes HTML. Wenn eine Site es veröffentlicht, ist eine dedizierte .md-URL mit Discovery-Link nützlicher als ein Accept: text/markdown-Header.

Drupals Position: Drupal unterstützt das Experiment ordentlich. Markdownify erzeugt Markdown aus der normalen Drupal-Seite und kann dedizierte .md-URLs, einen /markdownify/-Pfad oder eine ?_format=markdown-Antwort veröffentlichen. Version 1.2 unterstützt Drupal 9, 10 und 11. Der Content bleibt in Drupal, und die Markdown-Version ändert sich mit. Ein Team kann das Format testen, ohne einen zweiten Publishing-Workflow.

Wo hilft llms.txt, und wo nicht?

Das vorgeschlagene llms.txt-Format gibt einem KI-System einen kurzen Markdown-Guide zu einer Website. Es kann die Organisation beschreiben und auf bevorzugte Dokumentation, Service-Seiten oder Referenzmaterial verweisen. Es ist eine neue Konvention, und die Branche hat nicht vereinbart, wie viel sie zählt.

Die Site verzeichnete 52 Requests für /llms.txt während des Monatstests. Jeder Request kam von einem SEO-Audit-Tool. Kein KI-Crawler oder Answer Engine forderte die Datei an. Auf Acquias Hosting-Plattform gingen grob 5.000 von 400 Millionen Requests an llms.txt. Das sind 0,001 %, wieder meist Audit-Tools.

Googles Guidance für KI-Features in Search sagt, Website-Betreiber bräuchten keine neuen KI-Textdateien, spezielles Markup oder Markdown für generative Ergebnisse. Google crawlt viele Formate, gibt ihnen aber keine Sonderbehandlung. llms.txt zu pflegen „schadet (noch hilft) nicht“, weil Search die Datei ignoriert.

Es gibt trotzdem einen echten Use Case. Coding-Agenten können llms.txt als Einstieg in API-Dokumentation nutzen. Wenn Entwickler Ihre Docs in Cursor, Claude Code oder einen anderen Coding-Assistenten laden, spart die Datei Zeit. Für eine Marketing-Site bleibt es eine günstige Wette, kein bewiesener Weg zu Zitaten.

Drupals Position: wenn Sie llms.txt wollen, ist Drupal bereit. Das llms.txt-Modul veröffentlicht es unter /llms.txt, unterstützt wiederverwendbare Abschnitte, Tokens, umgebungsspezifischen Content und Cache-Invalidierung und bietet einen Admin-Screen. Drupal behandelt die Datei als verwalteten Content statt als vergessene Textdatei auf dem Server. Der Standard wird vielleicht nicht überall genutzt, aber eine Drupal-Site kann ihn heute sauber unterstützen.

Was sollen neue KI-Discovery-Module lösen?

Manche Tools schauen bereits über llms.txt hinaus. Sie müssen APIs, Authentifizierungsmethoden, MCP-Server und Aktionen entdecken, die eine Website einem Agenten erlaubt.

Das Drupal-Modul AI Agent Readiness erkundet diese Richtung. Es erzeugt /llms.txt und /llms-full.txt aus Drupal-Entitäten und kann einen API-Katalog, Agent-Skills-Index, MCP-Server-Card, OAuth-Metadaten und /auth.md veröffentlichen. Es respektiert Drupal-Zugriffsregeln und unterstützt Headless-Installationen.

Das Paket war bei Vorbereitung dieses Artikels erst wenige Wochen alt und fiel nicht unter Drupals Security-Advisory-Policy, braucht deshalb noch einen Production-Review. Seine Existenz zeigt, wie schnell das Drupal-Ökosystem auf neue KI-Discovery-Konventionen reagiert.

Drupals Position: die Konventionen entstehen noch, aber Drupal hat bereits eine Implementierung, die sie mit echten Entitäten, Berechtigungen und Zugriffsregeln verbindet. Ein Team kann Standards mitreifen lassen, ohne Content in ein anderes System zu verschieben.

Wie ist Drupal-Content über einzelne Seiten hinaus verfügbar?

Seiten funktionieren zum Lesen. APIs, Feeds und MCP-Tools helfen Software, größere Sets zu durchsuchen oder zu vergleichen, ohne Tausende URLs einzeln zu öffnen.

Das unterscheidet sich von gewöhnlichen KI-Zitaten. ChatGPT, Google und andere Answer Engines können öffentliches HTML ohne direkte Integration crawlen. Sie entdecken und nutzen nicht automatisch jeden JSON:API-Endpoint oder MCP-Server. Ein Feed, eine API oder ein MCP-Tool wird nützlich, wenn eine konkrete Anwendung, ein Partner oder ein Agent verbunden ist. Diese Features bereiten Drupal auf direkte Maschinennutzung vor; sie sind keine Ranking-Signale.

Warum gibt Core JSON:API Drupal einen Vorsprung?

JSON:API ist Teil von Drupal Core. Einmal aktiviert, stellt es Drupal-Entitäten und Felder über vorhersagbare Endpoints unter /jsonapi bereit. JSON:API ist read-only by default, nutzt Drupals Zugriffsprüfungen und lässt sich über JSON:API Extras einschränken - ohne separaten API-Bau.

Anonyme Requests lesen nur, was die anonyme Rolle sehen darf. Schreiben ist nur möglich, wenn die Site das bewusst aktiviert und Berechtigungen vergibt.

Die Standard-API ist breit. JSON:API Extras kann Ressourcen deaktivieren, Felder entfernen, Typen umbenennen und interne Pfade durch klarere ersetzen. Ein Team kann deshalb eine Content-API testen, ohne sie von Grund auf zu bauen. Die erste Aufgabe ist zu entscheiden, was exponiert wird.

Drupals Position: strukturierte Content-APIs sind kein späteres Add-on. JSON:API ist bereits in Core, standardmäßig read-only und durch Drupals Berechtigungen gesteuert. JSON:API Extras liefert die Kontrolle für eine kleinere, klarere öffentliche Schnittstelle.

Wie bleiben Drupal-Feeds mit der Website konsistent?

Manche Consumer brauchen eine Datei. Drupal Views wählt Entitäten, Felder und Filter, während Views Data Export größere CSV-, JSON- und XML-Exporte in Batches erzeugt. Die View liest dieselben Felder wie die Produktseite, sodass Redakteure keine zwei Quellen pflegen.

Große Batch-Exporte sollten nach einem eindeutigen Wert wie der Node-ID sortieren. Ohne stabile Sortierung können Datensätze zwischen Batches wandern und doppelt erscheinen oder verschwinden.

Drupals Position: Views gibt Site-Betreibern bereits einen visuellen Query Builder, und Views Data Export macht dieselbe Query zu CSV, JSON oder XML. Seite und Feed lesen weiter dieselben Felder.

Wie steuert Drupal, wer auf die Daten zugreifen darf?

Öffentliche Produktdaten können Drupals anonyme Berechtigungen nutzen. Partnerpreise oder private Dokumentation brauchen Authentifizierung.

Key auth hängt einen API-Key an einen Drupal-User. Die Rollen des Users entscheiden weiter, was verfügbar ist. Für OAuth liefern Consumers und Simple OAuth registrierte Clients, Bearer-Tokens und Scopes.

Diese Struktur unterstützt eine übliche kommerzielle Regel: anonyme User sehen eine Preisspanne, ein autorisierter Partner kann den exakten Vertragspreis anfordern.

Drupals Position: Maschinenzugriff nutzt dieselben User, Rollen und Berechtigungen wie die Website. Öffentliche Daten, API-Keys und OAuth-Clients können in einem Zugriffsmodell sitzen, statt separate Security-Systeme zu werden.

Wie hält Drupal API-Antworten und Feeds aktuell?

Drupal hängt Cache-Tags an gerenderte Seiten und API-Antworten. Diese Tags identifizieren Entitäten und Konfiguration, aus denen die Antwort gebaut wurde.

Wenn ein Redakteur einen Produktpreis ändert, weiß Drupal, welche gecachte Ausgabe von diesem Produkt abhängt. Purge kann diese Invalidierung an CDN oder Reverse Proxy senden. Das betroffene Objekt wird entfernt. Der Rest des Caches bleibt warm.

Das vermeidet, nach jeder Bearbeitung den gesamten Cache zu leeren. Wenn ein anderes System sofort ein Signal braucht, kann ein Webhook nur den geänderten Datensatz zum Abruf anstoßen.

Dieses Muster nutzten wir für den KI-Dokument-Chatbot von ProjektMagazin. Das Retrieval-System verbindet sich über JSON-APIs mit Drupal und indexiert mehrere Content-Typen mit Taxonomie, Autor und Custom-Metadaten. Webhooks aktualisieren geänderten Content, mit geplanter Synchronisation als Fallback. Neu veröffentlichte Informationen stehen dem Chatbot innerhalb von Sekunden zur Verfügung.

Drupal bleibt der Ort, an dem Redakteure Content verwalten. Die KI-Anwendung erhält aktuelle, strukturierte Daten, ohne die visuelle Website erneut zu crawlen.

Drupals Position: Cache-Tags und Entity-Events sagen Drupal genau, was sich änderte. Seiten, APIs, Feeds, CDNs und externe KI-Indexe können aus derselben redaktionellen Aktion aktualisieren.

Wie exponiert MCP Server Drupal an KI-Agenten?

Eine API exponiert Endpoints. Ein MCP-Server beschreibt Tools, die ein KI-Assistent verstehen und wählen kann.

Das Drupal-MCP-Server-Modul basiert auf dem offiziellen PHP MCP SDK. Es unterstützt MCP-Tools, Ressourcen, gespeicherte Prompts, Sampling und Authentifizierung. Version 2.0 funktioniert mit Drupal 10 und 11.

Das Modul nutzt Drupals Tool API. Ein Plugin definiert eine Operation mit typisierten Inputs und Outputs. Ein Administrator exponiert sie unter /admin/config/services/mcp-server/tools, benennt sie und wählt, ob Authentifizierung nötig ist.

Nützliche Tools könnten sein:

• search_products mit Kategorie- und Spec-Filtern,
• get_product_details mit stabiler Produktkennung,
• find_document mit Query und Dokumenttyp,
• request_quote mit Pflichtfeldern und Validierung.

Die Beschreibung sagt einem Agenten, wann er ein Tool aufruft, welche Parameter es akzeptiert und was es zurückgibt. Lokale Assistenten verbinden sich über STDIO mit vendor/bin/drush mcp:server; Remote-Clients nutzen HTTP unter /_mcp.

Simple OAuth 2.1 kann einzelne Tools mit Bearer-Tokens und Scopes schützen. Eine öffentliche Dokumentationssuche darf anonymen Lesezugriff erlauben. Eine Angebotsanfrage oder content-ändernde Operation sollte Authentifizierung und Drupal-Berechtigungen verlangen.

Release 2.0 war zum Prüfzeitpunkt Beta, unterstützte bereits das volle MCP-Protokoll und wurde für neue Drupal-Implementierungen empfohlen. Das frühere mcp-Projekt wird hinein gemerged. Starten Sie mit einem nützlichen Tool, exponieren Sie dann weitere Operationen über dieselbe Architektur.

Drupals Position: Drupal hat heute einen funktionierenden MCP-Server. Er unterstützt das volle Protokoll und verbindet Tools mit Drupal-Berechtigungen, Authentifizierung und typisierten Operationen. Die Integration ist neu, aber die Plattform muss nicht auf MCP-Support warten.

Was ist WebMCP, und wie unterscheidet es sich vom MCP Server?

WebMCP hilft einem KI-Agenten, eine Website im Browser zu bedienen. Ohne es muss der Agent die Seite inspizieren, Button oder Formularfeld finden, raten, was jedes Control tut, Werte eingeben und Fehler interpretieren. Eine kleine Layout-Änderung kann diese Sequenz brechen.

WebMCP lässt die Seite eine Aktion als Tool mit Name, Zweck und definierten Inputs beschreiben. Eine Drupal-Angebotsseite könnte request_quote mit Feldern für Produkt-ID, Menge, Land und E-Mail exponieren. Der Browser-Agent sieht diese Definition, sammelt fehlende Informationen vom User und ruft das Tool auf. Er muss nicht mehr erraten, welches sichtbare Input die Produktnummer enthält oder welcher Button das Formular absendet.

Es gibt zwei Wege, ein Tool zu definieren. Die deklarative API fügt Informationen zu einem normalen HTML-Formular hinzu, sodass dasselbe Formular für Menschen weiter funktioniert. Die imperative API nutzt JavaScript und navigator.modelContext.registerTool() für Aktionen mit mehr Logik, etwa Katalog filtern, Buchungsslot prüfen oder konfiguriertes Produkt vorbereiten. Die Aktion läuft weiter auf der Website und kann die Seite vor dem User aktualisieren.

Das unterscheidet sich von Drupals MCP Server. MCP Server exponiert Drupal-Tools vom Backend über STDIO oder einen HTTP-Endpoint. Ein verbundener Assistent kann sie nutzen, ohne die Website im Browser zu öffnen. WebMCP-Tools leben in einer Seite und werden verfügbar, nachdem ein kompatibler Browser sie besucht. Sie können den aktuellen Page-State nutzen und den User in der sichtbaren Interaktion halten.

Für Drupal könnte eine einfache WebMCP-Integration ein bestehendes Webform annotieren. Eine fortgeschrittenere lebt im Theme oder Custom Module, das JavaScript an ausgewählte Routes hängt. Drupal-Formular, Validierung und Submission-Handler erledigen weiter die echte Arbeit. WebMCP gäbe dem Browser-Agenten einen zuverlässigen Weg, sie aufzurufen.

Google und Microsoft schrieben den Vorschlag gemeinsam. Er ist derzeit ein W3C Community Group Draft, kein W3C-Standard. Chrome bietet eine frühe Preview hinter einem Flag, andere Browser haben Support nicht zugesagt. Es sollte deshalb als Erweiterung mit normalem HTML-Fallback ergänzt werden. Es ersetzt weder Backend MCP Server noch JSON-LD noch ein zugängliches Formular.

Drupals Position: WebMCP ist noch ein Browser-Vorschlag, es gibt kein ausgereiftes Drupal-Modul zum Installieren. Drupal ist gut aufgestellt, weil Webform, Form API und Custom Modules Aktion und Validierung bereits vom sichtbaren Interface trennen. Dieselbe Drupal-Operation kann heute Menschen und morgen Browser-Agenten dienen, wenn der Vorschlag reift.

Warum sollten Formulare und Agent-Anfragen dieselbe Validierung nutzen?

Ein Agent, der ein Angebot anfordert, sollte die Regeln des Website-Formulars nicht umgehen.

Beide Wege sollten dieselben Felder verlangen, sie gleich validieren und das Ergebnis am selben Ort speichern. Wenn eine fehlende E-Mail-Adresse im Formular einen Fehler erzeugt, sollte dasselbe über API oder MCP-Tool klar werden.

Drupal Webform kann das zentrale Submission-System bleiben. Ein Endpoint oder MCP-Tool übergibt Daten an dieselbe Validierung und Handler. Agent-Anfragen können markiert und in eine Review-Queue geschickt werden.

Drupals Position: Drupal braucht kein zweites Intake-System für Agenten. Form API und Webform können Validierung, Speicherung und Business Rules an einem Ort halten, während verschiedene Interfaces sie aufrufen.

Was braucht Drupal noch über gute Module hinaus?

Drupal liefert starke Bausteine. Es macht nicht jede Drupal-Website automatisch leicht für KI nutzbar.

Ein Wert, der in einem langen Body-Feld versteckt ist, bleibt versteckt, bis jemand ihn in ein dediziertes Feld verschiebt. Derselbe Fehler tritt auf, wenn Specs nur in Bildern leben; siehe Text in Bildern und SEO. Eine leere Produktbeschreibung bleibt leer, auch nach JSON-LD. Ein MCP-Tool kann keine nützliche Garantiezeit zurückgeben, wenn die Site sie nie gespeichert hat.

Module schreiben die Antwort nicht. Sie veröffentlichen, labeln und exponieren Informationen, die die Organisation pflegen will.

Konfiguration zählt ebenfalls. JSON:API kann unnötige Felder exponieren, Schema-Mappings können unvollständig sein, und ein CDN kann alte Antworten liefern, wenn Invalidierung fehlt. Schreibfähige MCP-Tools brauchen enge Authentifizierung und Berechtigungen.

Drupal passt zu substanziellem Content, vielen Attributen, mehreren Sprachen, Integrationen und strikten Zugriffsregeln. Eine Fünf-Seiten-Broschüre braucht diese Maschinerie vielleicht nicht. Ein mehrsprachiger Katalog oder eine Dokumentationsbibliothek profitiert, weil ein Entity-Modell wiederholte Arbeit über Templates, Skripte und Repositories ersetzt.

Deswegen zählt Drupal-Konfiguration so stark. Content-Typen, Felder, Berechtigungen, Metadaten, Cache-Regeln, API-Ressourcen und MCP-Tools müssen dasselbe System beschreiben. Drupal liefert all diese Teile, aber das Projektteam muss sie noch korrekt verbinden. Gute Konfiguration lässt ein Content-Update überall erscheinen, wo es soll. Schlechte lässt nützliche Daten vergraben, dupliziert oder falschen Usern exponiert.

Ist Drupal bereit für das Web der LLMs?

LLMs stellen Websites vor neue Anforderungen. Seiten brauchen klares serverseitig gerendertes HTML und strukturierte Fakten. Derselbe Content braucht vielleicht auch JSON-LD, Markdown, Discovery-Dateien, Feeds, APIs oder Tools, die ein Agent aufrufen kann.

Drupal unterstützt diese ganze Spanne. Core liefert strukturierte Felder, HTML-Rendering, mehrsprachigen Content, Berechtigungen, Views, Cache-Metadaten und JSON:API. Ausgereifte Contributed Modules ergänzen JSON-LD, stabile URLs, Redirects, Exporte und Authentifizierung. Neuere Module decken bereits Markdown, llms.txt, KI-Discovery-Dateien und das volle MCP-Protokoll ab.

Nicht jede neue Konvention wird überleben. Markdown hat gemischte Ergebnisse, llms.txt hat keinen gemessenen Zitationsnutzen, und WebMCP ist noch ein Browser-Vorschlag. Drupal zwingt ein Team nicht, die Website auf eine davon zu setzen. Es lässt Format oder Interface ergänzen, wenn es nützlich wird, während Content, Berechtigungen und redaktioneller Workflow gleich bleiben.

Das ist der echte Vorteil. Drupal löst KI-Sichtbarkeit nicht mit einem modischen Modul. Seine Architektur unterstützt bereits etablierte Anforderungen und gibt Teams einen praktischen Weg, Neue zu adoptieren. Während LLMs ändern, wie Websites gelesen und genutzt werden, ist Drupal eine der Plattformen, die am besten darauf vorbereitet ist. Sobald Fetcher Ihre Seiten lesen können, zeigt Wie messen, ob KI Sie empfiehlt, wie Sie Erwähnungen und Zitate mit einem festen Fragenkatalog tracken.

Häufige Fragen

Ist Drupal gut für KI-SEO?

Ja, besonders wenn eine Website strukturierten Content hat. Drupal-Felder können sichtbare Seiten, JSON-LD, Feeds, JSON:API und MCP-Tools aus derselben Quelle speisen. Drupal rendert HTML standardmäßig serverseitig und hat ausgereifte Module für URLs, Metadaten, Sitemaps, mehrsprachigen Content und Cache-Invalidierung.

Diese Features entfernen technische Hindernisse, garantieren aber keine Empfehlung. Die Site braucht weiter direkte, glaubwürdige Antworten.

Brauche ich ein spezielles Drupal-Modul, um von ChatGPT zitiert zu werden?

Nein. ChatGPT und andere Assistenten können eine normale öffentliche HTML-Seite zitieren. Starten Sie mit serverseitig gerendertem Content, stabilen URLs, klaren Überschriften und expliziten Fakten.

Schema.org Metatag ergänzt JSON-LD, Markdownify .md-Seiten, JSON:API exponiert Entitäten, und MCP Server liefert Tools. Keines davon erzeugt nützlichen Content von selbst.

Sollten wir llms.txt veröffentlichen?

Veröffentlichen Sie es für Entwickler-Dokumentation oder Tools, die der Konvention folgen. Erwarten Sie keinen Google-Gewinn: Google sagt, Search ignoriert llms.txt, und die gemessenen Requests kamen von SEO-Audit-Tools statt großer Answer Engines.

Brauchen wir Markdown-Versionen unserer Seiten?

Optional. Manche OpenAI-Crawler holen dedizierte .md-URLs, während Google sagt, sie seien für Search nicht nötig. Wenn Markdownify eine kleine Änderung ist, aktivieren Sie es, halten HTML kanonisch und prüfen Sie die Logs.

Gibt es einen MCP-Server für Drupal?

Ja. Das MCP-Server-Modul unterstützt das volle Protokoll inklusive Tools, Ressourcen, Prompts, Sampling, STDIO, HTTP und OAuth 2.1. Tool-API-Plugins können über Drupal-Konfiguration als MCP-Tools exponiert werden.

Version 2.0 war bei Vorbereitung dieses Artikels Beta, lieferte bereits die komplette Server-Architektur und wurde für neue Implementierungen empfohlen. Das ältere mcp-Projekt wird hinein gemerged.

Was bekommen wir ohne neue Module?

Drupal Core liefert Felder, serverseitig gerendertes HTML, mehrsprachigen Content, Berechtigungen, Cache-Metadaten, Views und JSON:API. Contributed Modules ergänzen JSON-LD, Markdown, llms.txt, Exporte, API-Authentifizierung, Cache-Purging und MCP.

Wollen Sie Ihre Drupal-Site für KI leichter lesbar und zitierbar machen?

Für ProjektMagazin bauten wir einen KI-Dokument-Chatbot, der sich über JSON-APIs mit Drupal verbindet und mehrere Content-Typen mit Taxonomie, Autor und Custom-Metadaten indexiert. Webhooks aktualisieren geänderten Content innerhalb von Sekunden, mit geplanter Synchronisation als Fallback. Das Retrieval-System läuft seit Monaten in Production.

Interesse an JSON-LD, APIs oder MCP-Tools auf Ihrer Drupal-Plattform? Wir designen Content-Modelle, strukturierte Daten und Agent-Integrationen und bauen sowie betreuen die Site. Besuchen Sie unsere Seite Drupal-Agentur, um zu sehen, wie wir helfen können.