Das Ende des Monokanals – das Web bekommt zwei Gesichter

Aber, müssen Websites ab jetzt neu gedacht werden?
Suchmaschinen lesen anders.
Und bald lesen sie gar nicht mehr.
Was früher der Crawler war, ist heute das Large Language Model (LLM). Es liest keine Seiten mehr, sondern strukturiert Daten, versteht Zusammenhänge und zitiert Marken, die semantisch klar kommunizieren.
Das verändert alles.
Nicht nur, wie Inhalte geschrieben werden. Sondern wie Websites gebaut, strukturiert und ausgeliefert werden.
Willkommen im Zeitalter der Generative Engine Optimization (GEO) und mit ihr in der Ära von MCP-readiness.
Das Ende des Monokanals Web?
Bislang hatten Websites vorallem ein Publikum: Menschen. Ja, da gibt es noch Robots und Suchmaschinen, aber das will ich hier nicht näher ausführen. User bedienen Websites via Browser, sie klicken sich durch Menüs und konsumieren Inhalte visuell.
Doch heute gibt es zwei gleichwertige Nutzergruppen:
- Menschen, die mit grafischen Interfaces interagieren
 - Maschinen, die über APIs, Schemas und Sprachmodelle Inhalte verarbeiten
 
Das Web spaltet sich also in zwei Erlebnisräume:
- Human Web: alles, was Nutzer sehen, klicken, erleben
 - Machine Web: alles, was Maschinen verstehen, verknüpfen und weiterverarbeiten
 
Marken, die weiterhin nur den ersten bedienen, verlieren Relevanz im zweiten und damit zunehmend ganzheitlich.
ABER, Achtung. Ganz so einfach ist das alles ja nicht. Spoiler: Die Webseite bleibt relevant und sie bleibt immer noch nur "ein" Kanal
GEO – Optimierung für Maschinen
Generative Engine Optimization (GEO) bedeutet, Inhalte so zu strukturieren, dass sie nicht nur lesbar, sondern interpretierbar werden.
Maschinen „sehen“ keine Layouts oder Emotionen, sie erkennen Muster, Beziehungen und semantische Tiefe.
Drei Kernprinzipien
- Tokens statt Worte: LLMs übersetzen Sprache in Zahlenmuster. Nur klar strukturierter Text wird korrekt verstanden.
 - Semantik schlägt Stil: Saubere HTML-Hierarchien, eindeutige Überschriften und strukturierte Daten sind Pflicht.
 - Zitierfähigkeit statt Ranking: In der Welt der KI zählt nicht, wer auf Seite 1 steht, sondern wer als Quelle genannt wird.
 
GEO ist also nicht mehr bloß SEO mit KI-Bezug, es ist die Grundlage dafür, dass Marken überhaupt noch vorkommen, wenn Maschinen Inhalte synthetisieren.
MCP-readiness – die Kommunikationsschicht für Maschinen
Während das Frontend der Raum für User bleibt, liefert man parallel eine zweite Schicht, z.B. für ein Model Context Protocol (MCP).
Diese ist ein zusätzlicher Kanal, über den Maschinen mit Marken/Unternehmen sprechen werden, nicht visuell, sondern strukturell.
Was MCP leistet
- Stellt Inhalte über strukturierte APIs, JSON und semantische Modelle bereit
 - Schafft eine standardisierte Kommunikationsbasis zwischen Content-System und KI-System
 - Sichert, dass Markenbotschaften auch ohne Interface verstanden werden
 
Damit wird MCP-readiness zur neuen technischen und strategischen Disziplin: Neben der "herkömmlichen" Website müssen Marken zusätzlich Inhalte KI-kompatibel publizieren.
MCP-readiness ist noch Theorie
Aktuell befinden wir uns noch am Anfang dieser Entwicklung.
Die meisten sogenannten MCPs sind experimentell, oft Teil von Prototypen oder Forschungsprojekten. Wirklich repräsentative Use Cases gibt es bisher kaum und jede Implementation funktioniert anders.
Von einer Standardisierung sind wir noch weit entfernt. Es gibt weder feste Protokolle noch einheitliche Modelle, wie Maschineninhalte semantisch konsumieren oder verarbeiten sollen.
Trotzdem:
Wer seine Systeme heute schon strukturiert, modular und semantisch aufsetzt, schafft die Grundlage, um morgen flexibel auf diese Standards reagieren zu können. MCP-readiness ist deshalb weniger eine Technologie, sondern eine strategische Haltung, mit der Marken auf das nächste Web vorbereitet sind.
Wie sieht das in der Praxis aus?
Die folgenden Beispiele zeigen, wie MCPs heute schon konkret eingesetzt werden könnten.
Alles Theorie, natürlich sind daher auch diese Beispiele recht abstrakt. MCPs existieren heute selten als klar umrissene Produkte oder Plattformen. Die Beispiele sollen helfen, die Idee hinter MCP-readiness besser einzuordnen: es geht darum, Inhalte und Services so zu strukturieren, dass sie nicht nur für Menschen, sondern auch für Maschinen verständlich, abrufbar und weiterverwendbar sind.
Das Ziel ist also nicht, sofort eine eigene „MCP“ zu entwickeln, sondern Systeme und Inhalte so vorzubereiten, dass dieser Schritt in Zukunft technisch möglich und strategisch sinnvoll wird.
Drei anschauliche Beispiele für MCPs
1. MCP für Produktdaten
Beispiel:
Ein Werkzeughersteller stellt seine Produktdaten (z.B. Maße, Materialien, Zertifikate) als API bereit. So können KI-Systeme, Einkaufsplattformen oder B2B-Suchsysteme die Daten automatisiert auswerten.
Was passiert ...
- Der Webshop bleibt der Kanal für Menschen
 - Die API wird zum MCP-Kanal für Maschinen
 - KI-Modelle oder Marktplätze interpretieren Daten direkt
 
Kernidee: Strukturierte Produktdaten sind die semantische Schnittstelle zwischen Marke und Maschine.
2. MCP für komplexe Services
Beispiel:
Ein Energieversorger bietet einen Glasfaser-Verfügbarkeits-Check an. Neben der Website, auf der User ihre Adresse eingeben, stellt das Unternehmen denselben Service über eine strukturierte MCP-Schnittstelle bereit.
So kann z.B. ein Sprachassistent, ein Partnerportal oder eine KI-Anwendung direkt prüfen, ob Glasfaser an einer Adresse verfügbar ist ohne die Website zu nutzen.
Was passiert ...
- Die Website bleibt der Kanal für Menschen
 - Die MCP stellt denselben Service als API bereit
 - Maschinen (z.B. Assistenten, Chatbots, LLMs) können direkt auf den Service zugreifen
 
Kernidee: Komplexe Services werden maschinenlesbar und so in andere Systeme oder KI-Assistenten integrierbar.
3. Corporate-Data-Hub
Beispiel:
Ein Unternehmen bündelt CMS-, DAM-, PIM- und CRM-Daten in einem semantischen API-Layer. Dieser Layer wird zur MCP-Schnittstelle für interne und externe KI-Systeme.
Was passiert ...
- Alle Daten werden an einer Quelle gepflegt
 - Maschinen greifen über eine standardisierte Schnittstelle zu
 - KI-Assistenten, Lieferantenportale und Forschungsnetzwerke nutzen denselben Datenbestand
 
Kernidee: Eine MCP als zentrale, maschinenlesbare Wahrheit des Unternehmens, ein Interface für KIs, APIs und Agenten.
Ein anschauliches Beispiel beschreibt Marcelo Lewin in seinem englischsprachigen Artikel From Hard-Coded Content to Building Adaptive Experiences with AI.
Er zeigt, wie ein einzelner CMS-Eintrag künftig zwei Ebenen enthalten kann:
eine deterministische für feste Inhalte und eine nicht-deterministische für kontextuelle Anweisungen an KI-Systeme.
Im Beispiel zum Thema „Einrichtung eines smarten Thermostats“ wird der Anleitungstext für Menschen mit zusätzlichen, natürlich formulierten Hinweisen ergänzt, die ein LLM nutzen kann, um den Inhalt individuell zu adaptieren, etwa nach Gerät, Standort oder Nutzerverhalten.
Diese Dual-Layer-Logik verdeutlicht, wohin MCP-readiness führt: Inhalte werden nicht nur veröffentlicht, sondern maschinenverständlich beschrieben, damit sie sich kontextbewusst weiterverwenden lassen.
Das Frontend bleibt – aber als einer von mehreren Kanälen
Das Frontend ist und bleibt vorerst der sichtbarste Kanal. Als Schnittstelle zwischen Marke und Mensch. Doch aus technischer Sicht ist es heute nur einer von mehreren Ausgabekanälen, die auf denselben strukturierten Inhalt zugreifen.
Anstelle von zwei getrennten Welten - einer grafischen Oberfläche und einer Maschinenebene - denken wir Websites inzwischen von einem gemeinsamen strukturellen Kern her. Dieser Kern beschreibt Inhalte und Komponenten semantisch, unabhängig davon, wo sie ausgespielt werden.
Der Paradigmenwechsel:
Nicht mehr das Frontend selbst ist der Ursprung des Webauftritts, sondern die strukturierte Repräsentation des Inhalts. Also das, was Maschinen und Menschen gleichermaßen verstehen können.
Aus diesem Kern lassen sich alle Kanäle ableiten:
- das visuelle Frontend für User
 - potenziell ein MCP-Layer für maschinelle Schnittstellen,
 - und/oder weitere kontextuelle Ausgaben (z.B. Chatbots, Sprachassistenten, Dokumentation, Print).
 
Damit wird die Gestaltung eines Frontends nicht mehr zum Aufbau einer isolierten Oberfläche, sondern zum „Übersetzen“ einer semantischen Basis in ein erlebbares Interface. So entsteht Konsistenz, nicht durch Synchronisierung, sondern durch gemeinsame Herkunft.
Vom strukturellen Kern zur fertigen Seite - ein Prototyp
Unser Prototyp zeigt genau diesen Ansatz in der Praxis. Er nutzt ein Large Language Model (LLM), um aus den Inhalten im CMS einen vollständigen Seitenentwurf zu generieren, nicht auf Basis von Layout-Vorlagen, sondern durch das Verstehen der strukturellen Beschreibung der Komponenten.
Jede Komponente im CMS ist über ein JSON-Schema definiert: das Modell weiß also, welche Datenfelder existieren, welche Beziehungen bestehen und wann eine Komponente sinnvoll eingesetzt wird.
Das LLM greift auf diese Strukturen zu, wählt passende Module aus, fügt Inhalte kontextgerecht zusammen und erstellt daraus einen Website-Draft, der direkt im CMS landet, damit ihn Redakteure prüfen und weiter bearbeiten können.
So entsteht eine Seite, die:
- aus der semantischen Struktur heraus aufgebaut wird,
 - sich im Frontend visuell konsistent darstellen lässt,
 - und theoretisch auch auf jedem anderen Kanal bereitgestellt werden könnte.
 
Der strukturelle Kern wird damit zur gemeinsamen Quelle
das Frontend und mögliche MCP-Layer / Machine-Channels sind nur noch verschiedene Formen seiner Darstellung
🎥 Video: Unser Prototyp im Einsatz auf YouTube
Headless als Schlüssel – warum Struktur alles verbindet
Damit dieses mehrkanalige Modell funktioniert, braucht es ein CMS, das Inhalte nicht nur visuell, sondern strukturell denkt.
Genau hier kommt zum Beispiel Storyblok ins Spiel: Als Headless-System trennt es die Inhaltspflege vollständig von der Darstellung und liefert Inhalte in modularer, komponentenbasierter Form.
Diese Trennung schafft die Grundlage, um in Zukunft verschiedene Ausgabekanäle – etwa Frontend und MCP – gezielt zu bedienen.
Denn ein möglicher MCP-Channel wird nicht einfach aus dem CMS „mitgeliefert“, sondern muss bewusst konzipiert werden: er ist kein visueller Ausgabekanal, sondern ein semantischer – gedacht für Maschinen, nicht für Menschen.
Ein solcher Kanal lässt sich heute noch nicht visualisieren, weil sein Ausgabeformat von KI-Systemen individuell interpretiert und personalisiert werden kann.
Doch wer seinen Content-Stack nach den drei GEO-Grundprinzipien strukturiert – Tokens statt Worte, Semantik statt Stil, Zitierfähigkeit statt Ranking – ist bereits hervorragend aufgestellt, um genau diese Entwicklung mitzugehen.
Unser Frontend Package spielt dabei eine zentrale Rolle: es wurde von Anfang an strukturell gedacht, jede Komponente ist inhaltlich und technisch eindeutig beschrieben. Damit sprechen CMS und Frontend schon heute eine gemeinsame Sprache, auf der sich künftige maschinelle Kanäle problemlos aufbauen lassen.
Das Ergebnis
- Inhalte können strukturiert und konsistent über verschiedene Kanäle ausgespielt werden
 - Neue Layouts oder Landingpages lassen sich schnell und modular aufbauen
 - Systeme, die auf semantische Daten zugreifen (z. B. KI oder zukünftige MCPs), finden eindeutig beschriebene Komponenten vor
 
Headless ist also nicht nur eine Frage der Architektur,
sondern die Voraussetzung für ein Web, das Menschen und Maschinen aus einer gemeinsamen strukturellen Quelle bedienen kann.
Struktur wird zur gemeinsamen Währung
Headless liefert sie, das Frontend nutzt sie,
und KI-Systeme verstehen sie.
Fazit: Die Zukunft des Webs ist zweikanalig
- Human Web: visuelle, emotionale und interaktive Erlebnisse für Nutzer:innen
 - Machine Web: strukturierte, semantische und zitierfähige Daten für KI-Systeme
 
Wer heute in GEO, Headless und MCP-readiness investiert, stellt sicher, dass seine Marke in beiden Welten vorkommt - gesehen, verstanden und zitiert.
Markenkommunikation endet nicht am Bildschirm.
Sie beginnt dort, wo Maschinen anfangen, zu lesen.
Was Unternehmen jetzt tun können:
- Inhalte konsequent semantisch strukturieren
 - Headless-Architekturen priorisieren
 - Frontends und Content-Modelle gemeinsam denken
 
Denn MCP-readiness ist kein Projektziel, sondern eine Haltung in der Art, wie wir digitale Marken zukünftig aufbauen.
