Was ist eigentlich ein AI-ready CMS?

TL;DR — die 90-Sekunden-Zusammenfassung

Was heißt AI-ready?

Ein AI-ready CMS stellt Inhalte strukturiert, semantisch klar und maschinenlesbar bereit. Entscheidend sind APIs, Taxonomien, strukturierte Inhalte, Governance, Zugriffskontrolle und langfristige Portabilität — nicht nur AI-Features im Backend.

Was es nicht ist

Kein Chatbot-Plugin, kein Editor-AI-Assistent, kein „GPT im Backend“-Feature. Diese Lösungen sind UI-Add-ons; ein AI-ready CMS ist eine Daten- und Auslieferungs-Disziplin.

Die vier Schichten

1) Structured Content — semantische Annotation, Taxonomien und Vererbung. 2) Semantic Delivery — Multichannel-Auslieferung an Web, Agent, Voice, Social. 3) Agent-Interaktion — Tool-API direkt im Browser via WebMCP. 4) Vertrauen & Governance — Provenance-Signaturen, AI-Readiness-Score, Audit-Trail, Versionierung.

Open Source wird strategisch

Sobald KI-Vermittler Ihre Inhalte zitieren, wird Content-Portabilität zur Standortfrage. Geschlossene CMS-Stacks koppeln Sie an die Roadmap eines Anbieters; Open-Source-Schichten bleiben unter Ihrer Kontrolle — das verbindet CMS, Souveränität und KI-Strategie zu einer Architektur-Entscheidung.

Wie wir das lösen

Wir setzen die vier Schichten in TYPO3 14 mit sieben Open-Source-Erweiterungen um. Ergebnis 100/100 im Cloudflare-Agent-Readiness-Score — mehr Beleg, dass die Definition trägt, weniger Verkaufsargument.

Für wen es jetzt relevant ist

Mittelständler mit strukturierten Inhalten (Produkt-Stammdaten, Service-Beschreibungen, Wissensartikel), die in 12–18 Monaten KI-Agenten in den Kundendialog, das Vertriebs-Briefing oder die interne Suche integrieren werden. Aus dem Bestand-CMS heraus: 6–9 Monate gestaffeltes Engagement, kein Big-Bang-Rewrite.

 

Warum klassische CMS nicht für AI gebaut wurden

Content-Management-Systeme sind in den 2000er Jahren für zwei Zielgruppen entstanden: Redakteure, die Inhalte pflegen, und Suchmaschinen, die sie indexieren. Beide haben spezifische Bedürfnisse — die ein KI-System nicht teilt.

Was Redakteure brauchen

Strukturierte Eingabemasken, Versionierung im UI-Sinn, Vorschau, Workflow-Freigaben, Mehrsprachigkeit. Das CMS-Datenmodell ist optimiert auf Bearbeitbarkeit: jeder Inhalt liegt als atomare Editor-Einheit vor, die ein Mensch öffnen, anpassen und freigeben kann.

Was Suchmaschinen brauchten

Saubere HTML-Struktur, Meta-Description, sitemap.xml, kanonische URLs. Das hat einen Jahrzehnt-Markt geprägt: SEO-Plugins, Title-Optimierer, Schema.org-Add-ons als Aufkleb-Felder. Die Annahme: Google liest die Seite, indexiert sie, schickt User vorbei.

Was AI-Systeme brauchen — und was klassische CMS nicht mitliefern

• Chunkbare Inhalte — RAG-Pipelines brauchen Abschnitte mit semantischen Grenzen, nicht Wall-of-Text. Klassische CMS speichern Bodytext als Blob.
• Maschinenlesbare Metadaten jenseits von Title/Description — Audience, Tone, Channel, Geltungsbereich, Aktualitätsstatus. Existieren als CMS-Felder schlicht nicht.
• Stabile, retrieval-tauglich Embeddings-Quellen — mit klar abgrenzbaren Sektions-Spines und Heading-Hierarchien, die ein LLM beim Crawlen wiedererkennt.
• Explizite Taxonomien — KI-Systeme arbeiten mit kontrollierten Vokabularen. Klassische Tag-Felder mit Freitext sind dort wertlos.
• APIs als Ausgangs-Standard — nicht als CMS-Plugin nachgereicht, sondern als primärer Auslieferungs-Channel neben HTML. JSON-Routen, OpenAPI-Manifeste, MCP-Tool-Listen.
• Provenance & Versionierung mit kryptografischer Verifikation — nicht nur ein „last modified“-Feld, sondern signierte Herkunfts-Ketten, die ein Audit-Tool oder ein KI-Agent verifizieren kann.
• Zugriffskontrolle pro Channel — „diese Inhalte sind für KI-Crawler offen, jene nur für eingeloggte Partner“. Klassische FE-Group-Logik reicht hier nicht aus.

Die Folge in der Praxis

Wer 2026 sein klassisches CMS einem LLM-Retrieval-System hinwirft, bekommt entweder schlechte Antworten (halluzinierende Chunks, weil die Struktur fehlt) oder gar keine Antworten (weil der Crawler die Inhalte nicht zuordnen kann). Das ist kein CMS-Versagen — es ist eine Architektur, die nicht für diese Anforderung gebaut wurde. AI-ready heißt: die fehlenden Schichten zusätzlich bereitstellen, ohne dass das Editorial-Team das Backend neu lernen muss.

Wie AI-Systeme Inhalte konsumieren

Ein KI-Agent oder ein RAG-System liest Ihre Inhalte nicht wie ein Browser. Wer ein AI-ready CMS bauen will, muss verstehen, was der Konsument auf der anderen Seite tut.

Crawling: was der Agent zuerst abfragt

Moderne KI-Crawler (Cloudflare AI Crawl Agent, Anthropic-User-Agent, OpenAI-Bot, Perplexity-Crawler) gehen nicht mehr nur über sitemap.xml. Sie suchen nach /.well-known/llms.txt-Manifesten, Schema.org-JSON-LD im DOM, openapi-Endpoints und MCP-Discovery-Routen. Wenn Sie diese Endpunkte fehlen lassen, finden die Agenten Ihren Content seltener — unabhängig von Ihrer SEO-Position.

Chunking: wie der Inhalt zerlegt wird

Bevor Inhalte in eine Vektor-Datenbank wandern, werden sie in Chunks zerlegt — typischerweise 200–1.000 Tokens. Die Frage ist: wo wird geschnitten? Wenn das CMS keine semantischen Grenzen liefert (klare H2/H3-Hierarchie, abgeschlossene Sektionen), schneidet der Tokenizer mitten in Tabellen, listet Code-Blöcke halb, zerreisst Definitionen. Die Folge: schlechte Retrieval-Treffer.

Embeddings: wie der Inhalt vektorisiert wird

Jeder Chunk wird zu einem Vektor (typischerweise 1.024–3.072 Dimensionen). Inhalte mit klarer Heading-Struktur, expliziten Audience-Tags und sauberen Zitaten produzieren distinkte Embeddings, die in der Ähnlichkeitssuche präzise treffen. Inhalte mit Editorial-Marketing-Sprache („Passgenaue Lösungen für Ihr Business“) produzieren matschige Vektoren, die zu allem und nichts passen.

Retrieval: wie der Agent eine Antwort baut

Bei einer User-Frage berechnet das System einen Query-Vektor, sucht die nächstgelegenen Chunks in der DB und reicht sie dem LLM als Kontext. Das LLM antwortet mit Bezug auf die abgerufenen Chunks („laut Inhalt X…“). Wenn Ihre Chunks gut sind: das LLM zitiert Sie korrekt. Wenn sie schlecht sind: das LLM halluziniert auf Basis seines Trainingswissens, weil der Kontext nicht ausreichend war.

Interaction: wenn der Agent handeln will

Read-Only ist die einfache Hälfte. Sobald der Agent eine Aktion auslösen soll (Anfrage senden, Termin buchen, Suche verfeinern), braucht er eine deklarative Tool-API. Das Model Context Protocol (MCP) hat sich dafür als Standard etabliert; im Browser übernimmt der WebMCP-Layer die Brücke zwischen dem im User-Browser laufenden Agenten und den CMS-Operationen.

Die Konsequenz für die CMS-Architektur

Jeder dieser Schritte stellt eine spezifische Anforderung an die Datenschicht. Die folgenden vier Schichten beantworten sie systematisch — nicht als KI-Feature, sondern als Datenmodell- und Auslieferungs-Disziplin.

Eigenschaften eines AI-ready CMS — die vier Schichten

Ein AI-ready CMS lässt sich technisch zerlegen in vier Schichten. Jede Schicht beantwortet eine der oben genannten Anforderungen — strukturierte Inhalte, retrieval-fähige Auslieferung, Tool-API für Agenten, Vertrauen und Governance. Wer die vier Schichten hat, hat keine „AI-Features“, sondern eine Plattform-Eigenschaft.

Schicht 1 — Structured Content: semantische Annotation und Vererbung

Die unterste Schicht ist die semantische Anreicherung. Klassische CMS-Felder (Titel, Bodytext, Meta-Description) beschreiben den Inhalt aus Editor-Sicht. Für ein Retrieval-System reicht das nicht: der Agent braucht Kontext, der eine Stufe tiefer geht.

Was technisch passieren muss

• Schema.org-Annotation als JSON-LD im DOM — nicht als Marketing-Feature, sondern für Article, Service, Product, FAQPage, HowTo, Organization, Person und vergleichbare Typen, je nach Inhaltsart.
• AI-Context-Annotationen: Audience (Customer / Partner / Internal / Developer), Tone (Informational / Promotional / Technical / Legal), Channels (Web / WhatsApp / Phone / Email / Social / MCP). Diese Felder existieren in der Bestand-Welt nicht — sie müssen Teil des CMS-Datenmodells werden.
• Hierarchische Vererbung: Ein Inhalt unter „Lösungen › DevSecOps as a Service“ erbt automatisch Audience=customer, Tone=technical von der Eltern-Seite. Editor-Belastung bleibt null.
• Typed Content-Relationships — Service x Person („Service-Lead“), Service x Product („basiert auf“), Article x Service („Handelt von“). Damit der Agent semantisch verknüpfen kann, statt nur Volltext zu lesen.

Wie wir das in TYPO3 umsetzen

In unserem Stack übernimmt das die Erweiterung structured-content: Schema.org-JSON-LD wird automatisch im Frontend gerendert, AI-Context-Felder cascaden durch die Seiten-Hierarchie, der Editor sieht nur wenige zusätzliche Felder im Backend.

Schicht 2 — Semantic Delivery: Multichannel-Auslieferung

Sobald die Inhalte annotiert sind, müssen sie an die richtigen Channel ausgespielt werden — nicht nur an den Browser. KI-Agenten lesen über andere Kanäle als Menschen.

Die vier Channel-Klassen

• Website (HTML) — der klassische Channel, aber jetzt mit eingebettetem JSON-LD und stabiler Section-Spine, sodass ein LLM die Struktur beim Crawlen sicher erkennt.
• AI Agent (llms.txt, MCP-Discovery) — ein /.well-known/llms.txt mit den wichtigsten Routen, semantischen Tags und Service-Manifesten. Daneben eine MCP-Tool-Liste, die der Agent abrufen kann, um zu wissen, was diese Plattform anbietet.
• Voice — Inhalte werden für Voice-First-Auslieferung (Smart Speaker, Telefonbots) als gekürzte, hörgerechte Variante bereitgestellt. STT/TTS-Anbindung optional.
• Social-Media-Distribution — LinkedIn, X, Bluesky, Mastodon als direkte API-Channel mit Schema.org-Anreicherung, plus optionaler RSS-Feed mit OG-Bildern und Provenance-Signaturen.

Wie wir das in TYPO3 umsetzen

In unserem Stack erledigt das die Erweiterung semantic-delivery: Inhalte werden channel-spezifisch transformiert, llms.txt und Discovery-Manifeste werden automatisch aktuell gehalten, Channel-Adapter für Web, AI Agent, Voice und Social-Media sind austauschbar gestaltet.

Schicht 3 — Agent-Interaktion: Tool-API direkt im Browser

Read-Only ist die einfache Hälfte. Sobald ein Agent handeln soll — eine Anfrage anlegen, einen Termin buchen, eine Suche verfeinern — braucht das CMS eine Tool-API. Das Model Context Protocol (MCP) hat sich Anfang 2026 als Standard dafür etabliert.

Was technisch passieren muss

• Tool-Inventar — das CMS deklariert, welche Operationen ein Agent auslösen darf: Suche, Navigation, Form-Submission, Service-Anfrage, Termin-Buchung. Jede Operation hat ein klares Input/Output-Schema.
• Sicherheitskontext — jeder Tool-Call läuft im HTTPS-/SecureContext, mit CSRF-Nonce, FE-Group-Awareness und Logging. Der Agent kann nichts tun, was der angemeldete User nicht ohnehin dürfte.
• Frontend-Integration — die Tools werden direkt im Browser via navigator.modelContext-API ausgespielt. Der Agent läuft im User-Browser, sieht die aktuelle Seite und kann die Tools im SecureContext aufrufen.
• Custom Tool Provider — jede Branche, jedes Mandanten-Setup hat eigene Workflows. Das CMS muss erlauben, dass Tool-Implementierungen plattform-spezifisch ausgetauscht werden, ohne den Browser-MCP-Layer anzufassen.

Wie wir das in TYPO3 umsetzen

In unserem Stack ist das die Erweiterung webmcp: Built-in-Tools für Search, Navigation, Page-Content und Form-Submission stehen zur Verfügung; eigene Tools werden über ein ToolProviderInterface registriert. Eine separate REST-API für Agenten wird nicht benötigt.

Schicht 4 — Vertrauen und Governance

Die letzte Schicht ist die, die viele überhaupt nicht auf dem Schirm haben — und die zugleich der größte Marken-Differenzierer wird, sobald KI-vermittelte Antworten die Norm sind.

Drei Sub-Disziplinen

• Provenance — jeder Inhalt wird kryptografisch signiert (Ed25519 ist ein etablierter Ansatz). Ein Agent oder ein Audit-Tool kann über einen /.well-known/provenance-keys-Endpunkt verifizieren, dass der Inhalt wirklich von dieser Marke kommt und nicht manipuliert wurde. EU-AI-Act-Artikel-50-relevant.
• AI-Readiness-Scoring — Inhalte werden gegen ein Qualitätsraster geprüft: Sind die AI-Context-Felder gesetzt? Ist die JSON-LD-Annotation vollständig? Stimmt der Brand-Voice-Score? Wie alt ist der Inhalt? Editoren sehen den Score im Backend und können punktuell nachbessern.
• Audit-Trail — jede Inhalts-Änderung wird mit Editor, Zeitpunkt, Diff und optionaler KI-Beteiligung protokolliert. Für B2B- und Healthcare-Plattformen ist das nicht-verhandelbar; für alle anderen wird es spielentscheidend, wenn EU-AI-Act-Compliance gefragt wird.

Wie wir das in TYPO3 umsetzen

In unserem Stack zwei Erweiterungen: content-provenance für Ed25519-Signaturen, content-intelligence für Quality-Gates, AI-Readiness-Score, Brand-Voice-Konsistenz und Audit-Trail.

Orchestrierung — wenn der Agent in mehreren Schritten denken muss

Die vier Schichten beschreiben das CMS aus statischer Sicht. Für produktive Use Cases kommt eine fünfte Disziplin dazu, die quer durch die Schichten geht: Orchestrierung von mehrstufigen Workflows.

Wo es ohne nicht geht

Ein Beispiel aus der Praxis: Ein Interessent fragt nach einem Service-Briefing. Der Agent muss (1) die relevanten Service-Inhalte aus der RAG-Pipeline ziehen, (2) eine personalisierte Zusammenfassung generieren, (3) den Editor um Freigabe bitten, (4) eine PDF erzeugen, (5) per E-Mail versenden, (6) ein CRM-Ticket anlegen. Das passt nicht in einen einzelnen Prompt — dafür braucht es eine Workflow-Engine, die einzelne Steps koordiniert, blockt, wartet, wieder aufnimmt.

Was technisch passieren muss

• Workflows als deklaratives YAML — lesbar für Editoren, versionierbar im Git, ohne dass jeder Workflow ein eigener Code-Deploy wird.
• Blocking/Resume — ein Step könnte auf eine menschliche Freigabe warten oder auf einen externen Webhook. Die Engine muss persistent pausieren können.
• Expression Resolution — Variablen zwischen Steps weiterreichen, ohne Custom-Code in jedem Workflow.
• Pluggable Notifiers + Steps — Email, Slack, Webhook, CRM-Call sind austauschbare Bausteine, keine harten Implementations.

Wie wir das in TYPO3 umsetzen

In unserem Stack zwei Erweiterungen: ai-workflows als deklarative YAML-Engine mit persistenter State-Verwaltung; business-agent als RAG-Pipeline-basierter Conversational Layer mit Access-Class-Routing und einbettbarem Chat-Widget. Der Agent ist nicht das CMS, sondern der Frontend-Konsument der vier Schichten.

Warum Open Source plötzlich strategisch wird

Die vier Schichten und die Orchestrierungs-Engine könnten Sie theoretisch von einem proprietären Anbieter zukaufen. Praktisch wird das in den nächsten 12–18 Monaten zum größten Architektur-Fehler, den ein Mittelständler treffen kann — und zwar nicht aus Lizenz-Romantik, sondern aus drei konkreten Gründen.

Content-Portabilität wird zur Standortfrage

Sobald KI-Vermittler (Claude, ChatGPT, Perplexity, Voice-Agenten) Ihre Inhalte zitieren und weiterverarbeiten, wird die Frage „unter wessen Kontrolle sind meine semantischen Annotationen?“ entscheidend. Mit einem proprietären Stack bestimmt der Anbieter, was als Audience-Tag, als Channel-Marker, als Provenance-Signatur akzeptiert wird — und ob er das Schema morgen ändert. Mit Open-Source-Schichten gehört das Datenmodell Ihnen.

Standards bewegen sich schneller als Anbieter-Roadmaps

Schema.org, MCP, llms.txt, Provenance-Standards (C2PA, JSON-LD-Signed) entwickeln sich seit Anfang 2026 in Monatsabständen. Ein proprietärer CMS-Anbieter, der diese Standards über Plugin-Updates einfüttert, hängt strukturell immer drei bis sechs Monate hinterher — weil er einen Release-Zyklus dazwischen hat. Open-Source-Pakete sind direkt am Standard.

Souveränität wird vom EU AI Act eingefordert

EU AI Act Artikel 50, NIS2, CRA und der BSI-Praxisleitfaden für Plattform-Komponenten machen Transparenz über den Stack zur regulatorischen Anforderung. Wer mit einem proprietären KI-Stack arbeitet, kann seine Lieferkette nicht vollständig dokumentieren. Open Source ist hier kein Bonus, sondern eine Compliance-Erleichterung — plus die Option, EU-souverän zu betreiben, ohne an die Roadmap eines einzelnen Anbieters gebunden zu sein.

Was das für die Architektur-Entscheidung bedeutet

Wer die vier Schichten als Open-Source-Stack baut, kombiniert vier verbundene Eigenschaften in einer einzigen Entscheidung: AI-readiness, CMS-Kontrolle, Open Source, digitale Souveränität. Das ist nicht vier Probleme lösen, sondern ein Problem so lösen, dass die anderen drei mitlaufen.

Was unterscheidet das von einem „AI-Feature“-Add-on?

Die meisten CMS-Anbieter rufen Anfang 2026 ihre KI-Features aus: Editor-Assistent, Auto-Summary-Plugin, Alt-Text-Generator, Frage-Antwort-Chatbot. Das ist nicht falsch, aber es löst ein anderes Problem.

Drei Achsen-Differenz

Warum das ein Architektur-Argument ist

Wer im Mai 2026 ein Auto-Summary-Plugin in TYPO3 installiert, hat dieselbe Diskussion in zwölf Monaten erneut, wenn das LLM-Modell wechselt oder der Anbieter abgeschaltet wird. Wer in dieselbe Zeit die vier Schichten baut, hat eine Plattform, die mit Claude, GPT-5, Llama 4, einem hauseigenen Mistral-Fine-Tune oder einem Voice-Agent gleich gut umgeht — weil die Datenschicht stabil ist, nicht der Verbraucher.

Anders gesagt: AI-Features sind eine UI-Schicht. AI-readiness ist eine Daten- und Auslieferungs-Schicht. Wer beides verwechselt, baut zweimal.

Was Unternehmen jetzt tun sollten

Wer den Begriff bis hier verstanden hat, hat noch keine Roadmap. Die folgenden vier Schritte sind unsere Standard-Empfehlung für Mittelständler, die in den nächsten 12 Monaten AI-ready werden wollen.

Schritt 1: Standortbestimmung in einer Woche

Vier Fragen ehrlich beantworten:

1. Können Sie für drei beliebige Seiten Ihrer Website die Zielgruppe (Kunde / Partner / Intern / Entwickler) und den Ton (informativ / werblich / technisch / rechtlich) in einem Satz benennen?
2. Gibt es einen standardisierten Discovery-Endpunkt (/.well-known/llms.txt oder Schema.org-JSON-LD im DOM) auf Ihrer Hauptseite?
3. Können Sie für einen Inhalt sagen, wer ihn wann freigegeben hat — und das auch kryptografisch nachweisen, wenn jemand fragt?
4. Wenn ein KI-Agent eine Anfrage zu Ihrem Service stellt: über welchen Channel kommt die Antwort, und ist sie in einer Form, die der Agent ohne Nachinterpretation an den User weitergeben kann?

Vier „Ja“ = AI-ready. Drei = ein bis zwei Schichten fehlen. Zwei oder weniger = Startpunkt der Plattform-Reise.

Schritt 2: Schicht 1 zuerst — Structured Content

Bevor irgendetwas anderes Sinn macht: das CMS-Datenmodell um die AI-Context-Felder erweitern (Audience, Tone, Channels), Schema.org-JSON-LD im Frontend rendern, eine erste /.well-known/llms.txt bauen. Editorial-Belastung: minimal, weil die Felder cascaden. Dauer: typischerweise 6–8 Wochen, abhängig von Datenmodell-Stand.

Schritt 3: Channel-Strategie klären, bevor Schicht 2 startet

Multichannel-Auslieferung lohnt sich nur dort, wo es Konsumenten gibt. Prüfen Sie für Ihre Branche:

• Welche AI-Crawler greifen Ihre Inhalte heute schon ab? (Cloudflare-Analytics oder Server-Log-Analyse beantwortet das in 15 Minuten.)
• Haben Sie Voice-Use-Cases (Smart-Home, Telefon-Service)?
• Welche Social-Channel sind operativ wichtig — LinkedIn, X, Bluesky?

Erst dann die Adapter aktivieren, die einen Konsumenten haben. Sonst betreiben Sie Channels für niemanden.

Schritt 4: Vertrauen ist kein Nice-to-have

Provenance-Signaturen, AI-Readiness-Scoring und Audit-Trail werden in den nächsten 12 Monaten regulatorisch und reputativ relevant. Wer hier spät startet, baut die Schicht im Stress; wer rechtzeitig startet, hat sie als Standardprozess. Empfehlung: spätestens parallel zur Schicht 2, nicht später.

Was nicht zuerst gemacht werden sollte

Auto-Summary-Plugins, Editor-AI-Assistenten, GPT-Backend-Integrationen. Das sind UI-Features, die Sie später problemlos aufkleben können — wenn das Fundament steht. Wer hier zuerst investiert, hat in 12 Monaten ein Plugin, das ersetzt werden muss, und kein Plattform-Fundament. Das ist die teure Reihenfolge.

Was wir bei Moselwal konkret tun

Sieben Open-Source-Erweiterungen, eine Architektur

Wir setzen die vier Schichten in TYPO3 14 mit sieben Erweiterungen um — jeweils einer Schicht (plus Orchestrierung) zugeordnet:

• Schicht 1 — Structured Content:structured-content liefert Schema.org, AI-Context-Annotationen (Audience, Tone, Channels), hierarchische Vererbung, Typed Relationships.
• Schicht 2 — Semantic Delivery:semantic-delivery transformiert Inhalte channel-spezifisch (Web, llms.txt, Voice, Social) und hält Discovery-Manifeste aktuell.
• Schicht 3 — Agent-Interaktion:webmcp liefert die Browser-MCP-Schicht mit Built-in-Tools (Search, Navigation, Page-Content) und austauschbarem Tool-Provider-Interface.
• Schicht 4 — Vertrauen:content-provenance signiert Inhalte mit Ed25519; content-intelligence liefert AI-Readiness-Score, Brand-Voice-Konsistenz und Audit-Trail.
• Orchestrierung:ai-workflows führt mehrstufige Agenten-Workflows aus; business-agent ist der RAG-Pipeline-basierte Conversational Layer.

Schicht für Schicht statt Big-Bang

Ein typisches Plattform-Engagement bei uns sieht so aus:

1. Monat 1–2: Bestandsaufnahme + Schicht 1 (Structured Content). Bestehendes Datenmodell wird um AI-Context-Felder erweitert, erste Schema.org-Annotation im Frontend, JSON-LD im DOM, llms.txt-Endpunkt.
2. Monat 3–4: Schicht 2 (Semantic Delivery). Multichannel-Adapter aktivieren — zunächst Web/llms.txt/RSS, später Voice und Social-Channel je nach Bedarf.
3. Monat 5–6: Schicht 3 (Agent-Interaktion). WebMCP-Integration im Frontend, erste Custom-Tools für branchen-spezifische Operationen.
4. Monat 7–9: Schicht 4 (Vertrauen) plus Business-Agent (falls Conversational Use Case vorhanden). Provenance-Signaturen aktivieren, AI-Readiness-Dashboard, Audit-Trail-Logging.

Belegt im Cloudflare-Score

Cloudflare hat im April 2026 den Agent-Readiness-Score gestartet — eine Lighthouse-artige Bewertung dafür, wie gut eine Website von KI-Agenten genutzt werden kann. moselwal.de hat den Test mit 100/100 bestanden. Bei Bestandskunden ist der typische Ausgangswert 30–50; nach Schicht 1 sind wir bei 60–70; nach Schicht 4 bei 90–100.

Open-Source-Stand

Die sieben Pakete sind unter MIT-Lizenz entwickelt; der öffentliche Composer-Release ist in Vorbereitung. Aktuell setzen wir sie im Rahmen von Plattform-Engagements ein.

Fazit

AI-ready ist kein Marketing-Etikett und kein Plugin. Es ist eine Plattform-Disziplin, die vier Schichten umfasst: strukturierte Inhalte mit Audience- und Channel-Annotation, retrieval-fähige Multichannel-Auslieferung, eine Tool-API für Agenten im Browser, plus Provenance und Governance. Wer diese Schichten hat, hat einen CMS-Stack, der mit Claude, GPT-6, einem Voice-Agent oder dem nächsten KI-Konsumenten gleich gut umgeht — weil die Datenschicht stabil ist, nicht der Verbraucher.

Für Mittelständler mit strukturierten Inhalten lohnt sich der Umbau in den nächsten 12 Monaten besonders. Für alle anderen ist es eine bewusste Architektur-Entscheidung mit Zeithorizont von 18–24 Monaten. Open Source ist dabei kein Nice-to-have, sondern die Standort-Garantie für das eigene Datenmodell — zu einem Zeitpunkt, an dem AI-Standards monatlich nachschieben. Wer jetzt die vier Schichten baut, hat in 12 Monaten eine Plattform; wer jetzt ein KI-Plugin installiert, hat in 12 Monaten dieselbe Frage erneut.