Was eine Plattform AI-ready macht — vier Schichten unter dem Cloudflare-Score

TL;DR

Der Cloudflare-Score ist die Diagnose. Die vier Schichten darunter sind die Therapie. Wer in der LLM-Welt sichtbar bleiben will, muss alle vier bauen — nicht eine.

Schicht 1 — Discoverability

llms.txt, Sitemap-Hygiene, RSS-Discovery, .well-known. Macht die Plattform für Agenten überhaupt erst auffindbar.

Schicht 2 — Content-Modell

Chunking, Definition-Listen, retrievalfähige H3-FAQ-Strukturen, klare semantische Anker. Macht den Inhalt zitierfähig statt nur lesbar.

Schicht 3 — Bot-Access-Control

Content-Signals-Protocol (ai-train, search, ai-input), differenzierte Crawler-Allowlist, klare Trennung von Training und Retrieval. Macht aus „erlaubt“ oder „verboten“ eine pro Zweck steuerbare Entscheidung.

Schicht 4 — API/Auth/MCP/Skill Discovery

WebMCP, openapi.yaml, .well-known-Discovery, Skill-Manifeste. Macht die Plattform agentenbedienbar — nicht nur lesbar.

 

Drei Sätze für Entscheider: Klassische SEO-Routinen bedienen Schicht 2 halb und Schicht 1 gar nicht. Wer Schicht 3 ignoriert, verschenkt Verhandlungsmacht gegenüber Trainings-Crawlern. Wer Schicht 4 ignoriert, ist im Agenten-Web ein passives Dokument statt ein bedienbares System.

Schicht 1 — Discoverability: damit Agenten wissen, dass es Sie gibt

Discoverability ist die Vorbedingung. Wenn ein LLM-Agent Ihre Plattform nicht findet, hilft die beste Content-Architektur nichts. Cloudflare prüft hier drei Signale, die wir in der eigenen Plattform alle drei aktiv halten: llms.txt im Root, eine getrennte llms-full.txt für die kompletten Inhalte, sowie eine RSS-Discovery, die nicht nur den Blog, sondern auch Service-Seiten und Wissensbestand auflistet.

Was klassische SEO hier verschenkt

Eine sitemap.xml reicht Suchmaschinen, aber nicht Agenten. LLM-Crawler arbeiten mit zwei unterschiedlichen Profilen: Training-Crawler wollen Volltext und sauberes Markup, Retrieval-Crawler wollen Chunks und Zitat-Stellen. Die llms.txt liefert dem Retrieval-Profil eine kuratierte Karte der Plattform — was darf zitiert werden, was ist der kanonische Pfad, welche Seiten gehören thematisch zusammen.

Konkret bei Moselwal

Wir generieren llms.txt und llms-full.txt über die Extension moselwal/semantic-delivery aus den TYPO3-Inhalten. Pro Site (moselwal.de, ole-hartwig.eu, blog.ole-hartwig.eu, nozzleops.de) ein eigener Index, der RSS-Discovery referenziert. Die Site-Sets laden das automatisch — keine manuelle Pflege.

Quick-Check für Ihre Plattform

curl -sI ihre-domain.tld/llms.txt | grep -i content-type
curl -s ihre-domain.tld/llms.txt | head -20
curl -sI ihre-domain.tld/.well-known/ai-plugin.json

Wenn alle drei Calls 200er Antworten mit korrekten Content-Types liefern, ist Schicht 1 wenigstens grundsätzlich da. Inhaltliche Qualität ist eine zweite Frage.

Schicht 2 — Content-Modell: damit Sie zitiert werden, nicht nur indexiert

Schicht 2 ist die, an der die meisten Mittelständler scheitern. Nicht aus Faulheit — sondern weil klassisches CMS-Denken Texte als Aufsatz strukturiert. LLMs aber lesen in Chunks. Sie suchen nach klar abgrenzbaren Antwort-Blöcken, in denen Frage und Antwort, Begriff und Definition, Symptom und Maßnahme zusammen stehen.

Was retrievalfähig heißt, konkret

• Definition-Listen (<dl>) statt Fließtext, wenn es um Begriffsabgrenzung geht. Der LLM-Crawler erkennt das Frage-Antwort-Muster strukturell, nicht erst nach Tokenisierung.
• H3-FAQ-Blöcke, in denen die H3-Überschrift die Frage formuliert und der Absatz darunter die Antwort liefert. Eine Frage, eine Antwort, kein Verschachteln.
• Quick-Check-Snippets direkt im Text — ein Befehl, eine Prüfung, ein Ergebnis. Wird häufiger zitiert als jeder längere Erklärabsatz.
• Operational Decision Blocks mit wenn-dann-Logik. „Wenn Ihre Plattform X tut, dann ist Y die richtige Antwort“. LLMs bauen daraus Entscheidungspfade.

Warum Markdown wichtiger wird

LLMs können HTML lesen, aber sie verstehen Markdown besser. Ein <h2> ist eine H2; ein ## Überschrift ist eine H2 plus ein semantisches Signal, dass hier ein Strukturbruch beabsichtigt ist. Genau deshalb generieren wir aus TYPO3 nicht nur HTML, sondern auch Markdown-Repräsentationen — die llms-full.txt liefert die kuratierten Inhalte als Markdown.

Was klassische SEO halb richtig macht

FAQ-Schema und HowTo-Schema sind ein Anfang, aber kein Ersatz. Schema.org-Markup ist eine Behauptung über den Inhalt; die Chunk-Fähigkeit liegt im Inhalt selbst. Wenn die FAQ-Sektion sechs lange Aufsätze unter ihren Fragen versteckt, hilft das Schema niemandem — weder Suchmaschine noch LLM.

Cross-Link in die operative Praxis

Wie wir das in TYPO3 umsetzen, behandelt der Deep-Dive TYPO3 für AI Retrieval optimieren mit konkretem Bauplan für Content-Blocks, Felder, Templates und semantic-delivery.

Schicht 3 — Bot-Access-Control: erlauben, verbieten, differenzieren

Hier wird es politisch. Schicht 3 ist die Verhandlungsmasse: Wer darf Ihren Inhalt sehen, zu welchem Zweck, und in welchem Volumen. Cloudflare prüft, ob die Plattform zwischen Training, Such-Indexierung und Retrieval („ai-input“) differenziert. Eine pauschale robots.txt mit Disallow: / für alle KI-Bots ist eine politische Geste, aber operativ ein Eigentor — weil sie auch das Retrieval blockt, das Ihre Sichtbarkeit in der Antwortgeneration garantiert.

Content-Signals-Protocol als operative Realität

Cloudflare hat im April 2026 das Content-Signals-Protocol ausgerollt, eine Erweiterung der robots.txt-Logik um drei Signale: ai-train (Training erlaubt/verboten), search (klassische Such-Indexierung), ai-input (Retrieval/RAG für Antwortgeneration). Diese drei sind unterschiedlich zu bewerten:

• ai-train: bewusst entscheiden. Wenn Ihr Inhalt urheberrechtlich geschützt ist und Sie keine Lizenz erteilt haben, ist disallow die korrekte Voreinstellung.
• search: in der Regel erlauben. Sichtbarkeit in Google, Bing, Brave, Kagi hängt daran.
• ai-input: differenzieren. Für eine Service-Seite, die Ihre Kunden in Perplexity finden sollen: erlauben. Für interne Wissensbasis-Einträge: verbieten.

Warum eine Allowlist statt einer Denylist

Crawler-Listen wachsen schneller, als robots.txt-Regeln gepflegt werden. Eine Allowlist („diese Crawler erlauben, alle anderen blocken“) auf Edge-Ebene — also Caddy, Cloudflare-Worker oder NGINX — ist robuster als robots.txt-Einträge, die kein Crawler durchsetzen muss. Wir betreiben das in Caddy mit CrowdSec als WAF; unsere Allowlist enthält rund 12 Crawler aus den Bereichen Such-Engines, Retrieval-Provider, Archiv.

Quick-Check für Ihre Plattform

curl -s ihre-domain.tld/robots.txt | grep -iE 'ai-train|search|ai-input'
curl -A 'PerplexityBot' -s -o /dev/null -w '%{http_code}\n' ihre-domain.tld
curl -A 'GPTBot' -s -o /dev/null -w '%{http_code}\n' ihre-domain.tld

Wenn die robots.txt keine der drei Direktiven kennt und alle Crawler 200er bekommen, ist Schicht 3 ungeschalten — Sie haben jede Verhandlungsposition verschenkt.

Schicht 4 — API/Auth/MCP/Skill Discovery: bedienbar statt nur lesbar

Schicht 1–3 macht Ihre Plattform lesbar für Agenten. Schicht 4 macht sie bedienbar. Hier entscheidet sich, ob ein KI-Agent in zwei Jahren Ihre Plattform nur erwähnen kann („Moselwal bietet Plattformbetrieb an, hier ist der Link“) oder ob er auf der Plattform handeln kann („Ich habe gerade für Sie ein Erstgespräch gebucht / einen Statusbericht abgerufen / eine Anfrage angelegt“).

Vier Bausteine für Schicht 4

• openapi.yaml mit klaren Operation-IDs, sauberen Schemas und Beispiel-Requests. Nicht generiert, sondern kuratiert.
• .well-known-Discovery mit /.well-known/ai-plugin.json oder dem entsprechenden Protokoll-Manifest, das auf die OpenAPI-Spec verweist.
• WebMCP oder ein vergleichbares Skill-Manifest, das nicht die HTTP-Ebene, sondern die Bedienlogik beschreibt: welche Aktion löst was aus, welche Auth-Variante gilt, welche Quoten greifen.
• Auth differenziert in nützliche und geschützte Endpoints. Service-Endpoints („Rufe Status meiner Anfrage ab“) brauchen User-Token; Discovery-Endpoints („Liste verfügbare Aktionen auf“) sind öffentlich.

Warum das für den Mittelstand kein Hype ist

Mittelständler verwechseln Schicht 4 oft mit „Agenten-API für Endkunden“ und schieben es für 2027 weg. Der eigentliche Hebel liegt aber heute schon im internen Einsatz: Ihre Mitarbeiter bedienen Claude oder ChatGPT, fragen nach internen Daten, lassen Anfragen anlegen. Wenn Ihre eigenen Plattformen kein MCP/Skill-Manifest haben, baut jeder Mitarbeiter sich Workarounds — Copy-Paste, Screenshot-an-KI, manuelle Briefings. Schicht 4 ist daher zuerst eine interne Investition.

Quick-Check für Ihre Plattform

curl -s ihre-domain.tld/.well-known/ai-plugin.json | jq .
curl -s api.ihre-domain.tld/openapi.yaml | head -40
curl -s ihre-domain.tld/.well-known/mcp.json | jq .

Wenn alle drei Calls 404 liefern, ist Schicht 4 nicht gebaut. Das ist heute noch normal; in zwölf Monaten wird es Wettbewerbsnachteil.

Wer ist betroffen?

Die ehrliche Antwort: jeder, dessen Geschäft davon abhängt, im Suchverhalten der nächsten drei Jahre vorzukommen. Der Cloudflare-Befund (200.000 Top-Sites, Mehrheit „nicht bereit“) ist kein Ausreißer-Datenpunkt, sondern der Normalzustand. Für den Mittelstand kristallisieren sich drei Profile:

Profil A — Sichtbarkeit-im-Web-Mittelstand

Wissensorientierte Anbieter (Beratung, Software, Plattform, B2B-Services) deren Kunden längst in Perplexity und ChatGPT recherchieren. Schicht 1 und 2 sind hier dringend; Schicht 3 ein Mittelthema; Schicht 4 die Investition für die nächsten zwölf Monate.

Profil B — Inhouse-AI-Mittelstand

Unternehmen, die intern Claude, Copilot oder ChatGPT Enterprise einsetzen und merken, dass ihre eigenen Systeme nicht agentenkompatibel sind. Schicht 4 ist hier der primäre Hebel — als interne Plattform-Investition, nicht als Marketing-Maßnahme.

Profil C — Plattform-Anbieter und SaaS-Mittelstand

Wer selbst Software oder Daten anbietet, muss alle vier Schichten ernst nehmen, weil seine Kunden zunehmend agentenvermittelt zugreifen werden. Hier ist Schicht 3 entscheidend: differenzierte Steuerung, wer was sieht, zu welchem Zweck, mit welchem Auth.

 

Wer in keines der drei Profile passt, hat tatsächlich noch Zeit. Das sind in der Regel Anbieter, deren Vertriebskanal weder Suche noch Empfehlung ist — also Bestandskundenüber Jahrzehnte oder reine Offline-Modelle. Für alle anderen ist der Befund operativ: Die Pläne für 2027 müssen 2026 starten.

Betreiberempfehlung: in welcher Reihenfolge bauen

Vier Schichten heben gleichzeitig zu bauen, scheitert in fast jedem Mittelstandsprojekt. Empfehlung: in dieser Reihenfolge, mit klaren Sollbruchstellen.

Operational Decision Block

Wenn Sie heute weder llms.txt noch RSS-Discovery haben — dann

starten Sie mit Schicht 1 und einer ehrlichen Inventur Ihrer Inhalte. Welche Seiten gehören zur kuratierten Karte, welche sind technische Restbestände? Erst danach llms.txt generieren. Ein halbherziges llms.txt mit 800 Einträgen ist schlimmer als keines.

Wenn Schicht 1 steht, aber Ihre Texte sind Aufsatz statt Chunk — dann

investieren Sie in Schicht 2, bevor Sie Schicht 3 oder 4 anfassen. Ein gut auffindbarer aber un-zitierbarer Inhalt ist die teuerste Form von Sichtbarkeit. Reformatieren Sie zuerst Ihre wichtigsten 10–20 Seiten in Definition-Listen, H3-FAQ und Operational Decision Blocks.

Wenn Schicht 1 und 2 stehen, aber Sie wissen nicht, welche Crawler Ihre Plattform abrufen — dann

beginnen Sie Schicht 3 mit Beobachtung statt Regelwerk. Eine Woche Access-Log-Analyse pro User-Agent, dann eine bewusst kuratierte Allowlist, dann Content-Signals. Reihenfolge umgekehrt = Selbstblockade.

Wenn Sie interne Mitarbeiter haben, die ChatGPT/Claude operativ nutzen — dann

ist Schicht 4 die nächste Investition unabhängig vom Cloudflare-Score. Beginnen Sie mit dem internen System, das am häufigsten manuell briefingt wird. Ein WebMCP-Skill-Manifest hier spart pro Mitarbeiter und Woche häufig 2–4 Stunden.

Wenn Sie selbst SaaS oder Plattform anbieten — dann

müssen Sie Schicht 4 inhaltlich gestalten, nicht nur technisch. Welche Aktionen sind agentenfreundlich, welche nicht? Welche Quoten? Welche Auth? Das ist eine Produkt-, keine Plattform-Entscheidung.

 

Was wir bewusst nicht tun

• Pauschal alle KI-Crawler blocken, weil das bequem klingt — Sie blocken damit auch die Retrieval-Crawler, von denen Ihre Sichtbarkeit abhängt.
• Schicht 4 vor Schicht 2 angehen, weil API-Bauen technisch attraktiver wirkt als Content-Refactoring — ein agentenfreundlicher Endpunkt auf un-zitierbare Inhalte hilft niemandem.
• llms.txt automatisch aus dem CMS dumpen, ohne kuratierte Auswahl — das verwässert die LLM-Sicht auf Ihre Plattform und schadet mehr, als es nützt.

Was wir bei Moselwal konkret tun

Damit das nicht abstrakt bleibt: was bei uns auf den vier Schichten läuft, stand heute.

Schicht 1 — Discoverability

llms.txt und llms-full.txt werden über die Extension moselwal/semantic-delivery aus TYPO3 generiert, pro Site einzeln, mit kuratierter Auswahl statt Voll-Dump. RSS-Discovery liegt unter /feed.rss mit Article-Schema-Anreicherung; sitemap.xml wird aus dem TYPO3-Sitemap-Generator gebaut, die Inhaltsdoctypes sind explizit konfiguriert.

Schicht 2 — Content-Modell

Jeder Blog-Post folgt einem festen Spine: Hero → TL;DR mit Definition-Liste → TOC → H2-Abschnitte mit H3-Unterstrukturen → FAQ-Container mit retrievalfähigen Karten → menu_pages-Cross-Links → CTA. Das ist nicht Marketing-Layout, sondern Retrievability-Engineering. Quick-Check-Snippets und Operational Decision Blocks sind als feste Bausteine im Redaktionsleitfaden verankert.

Schicht 3 — Bot-Access-Control

Caddy mit CrowdSec WAF auf Edge-Ebene, eine kuratierte Allowlist von rund 12 Crawlern (Such-Engines, Retrieval, Archiv), Content-Signals-Protocol in der robots.txt mit differenzierten Werten für ai-train (verboten ohne Lizenz), search (erlaubt) und ai-input (erlaubt mit Quoten). Logs werden wöchentlich pro User-Agent geprüft.

Schicht 4 — API/Auth/MCP/Skill Discovery

Wir betreiben einen eigenen MCP-Server für TYPO3 (siehe MCP-Server-Disziplin). openapi.yaml ist kuratiert, nicht generiert. /.well-known/ai-plugin.json verweist auf die Spec. Skill-Manifeste folgen, sobald die nächste WebMCP-Iteration stabil ist. Wichtig dabei: Schicht 4 nicht aus Begeisterung vorziehen, sondern erst wenn 1–3 belastbar sind.

Diagnose und Selbstbeobachtung

Wir messen den eigenen Cloudflare-Score regelmäßig (100/100 Level 5 Agent-Native, Stand 19. April 2026) und bauen darauf das eigene SearchOps-Monitoring. Wer Schicht 1–4 baut, ohne den Zustand zu messen, baut blind. Ein quartalsweiser Re-Check ist das Minimum.

Fazit

Der Cloudflare-Score ist kein Test, den man bestehen muss. Er ist eine Diagnose-Karte, die zeigt, wo Sie heute stehen. Wer eine Plattform AI-ready bauen will, baut nicht den Score, sondern die vier Schichten darunter: Discoverability, damit Agenten Sie finden. Content-Modell, damit Sie zitiert werden. Bot-Access-Control, damit Sie Verhandlungsmacht behalten. API/MCP, damit Ihre Plattform agentenbedienbar wird.

Für den Mittelstand ist die operative Botschaft klar: nicht alle vier gleichzeitig, sondern in Reihenfolge mit echten Sollbruchstellen. Sichtbarkeitsorientierte Anbieter beginnen mit Schicht 1 und 2; Inhouse-AI-Nutzer mit Schicht 4 im internen System; SaaS-Anbieter müssen Schicht 3 als Produktentscheidung verstehen, nicht als Infrastruktur-Detail.

GEO statt klassischer SEO ist kein Marketing-Slogan. Es ist die Anerkennung, dass Such-Vermittlung und Antwort-Vermittlung zwei unterschiedliche Maschinen sind, die beide ihre eigene Plattform-Architektur erwarten. Wer 2026 nicht damit beginnt, baut den Wettbewerbsnachteil von 2028.