Warum ein modernes CMS MCP nativ unterstützen sollte

KI-Assistenten gehören zum Content-Workflow. Warum CMS-Plattformen MCP unterstützen sollten – für direkte Content-Pflege, interne Links, SEO und GEO.

8. November 2026

  • MCP verbindet kompatible KI-Assistenten mit den strukturierten Inhalten und Funktionen eines CMS.
  • Content-Erstellung, interne Verlinkung und Content-Cluster lassen sich ohne manuelle Übertragung bearbeiten.
  • Ein angebundener SEO-/GEO-Dienst wie Vysentra erweitert die Prüfprozesse, garantiert aber keine Sichtbarkeit.
  • Drafts, Berechtigungen, Validierung und menschliche Freigabe bleiben Voraussetzung.

Vom Copy-and-paste-Workflow zur direkten Arbeit am Content

ChatGPT erstellt einen Entwurf. Die Redaktion kopiert ihn in das CMS, verteilt Zwischenüberschriften auf Felder, ergänzt interne Links, sucht die richtige Sprachversion und kontrolliert die Metadaten. Danach beginnt dieselbe Arbeit beim nächsten Artikel erneut. Der Text entsteht schnell, aber die eigentliche Content-Produktion bleibt eine Folge manueller Übergaben.

Das Problem ist nicht, dass KI Inhalte generiert. Das Problem ist die fehlende Verbindung zwischen dem System, in dem wir denken und arbeiten, und dem System, das die Inhalte verwaltet. Unternehmen nutzen ChatGPT, Claude, Langdock oder OpenWebUI bereits für Recherche, Strukturierung, Übersetzung, technische Reviews und redaktionelle Entwürfe. Wenn das CMS für jeden dieser Schritte einen manuellen Import verlangt, bremst es den Workflow unnötig.

Ein modernes Content-Management-System sollte deshalb eine standardisierte, sicher kontrollierbare Schnittstelle für KI-gestützte Werkzeuge bereitstellen. Das Model Context Protocol (MCP) ist dafür ein relevanter Ansatz. Für anspruchsvolle Redaktionsteams ist MCP-Unterstützung inzwischen ein ernst zu nehmendes Auswahlkriterium – aber nicht allein der Nachweis einer guten CMS-Architektur.

Was ist MCP – und was hat ein CMS davon?

MCP steht für Model Context Protocol. Das offene Protokoll beschreibt, wie Anwendungen Werkzeuge und Kontext für KI-Assistenten verfügbar machen. Ein MCP-Server kann beispielsweise Funktionen bereitstellen, mit denen ein berechtigter Assistent Dokumente sucht, Inhalte liest, strukturierte Änderungen vorbereitet oder Metadaten aktualisiert. Ein entsprechend konfigurierter MCP-Client ruft diese Funktionen auf.

Ein MCP-fähiges CMS ist damit nicht bloß eine Datenquelle für Antworten. Es wird zum operativen Teil des Workflows. Der Assistent arbeitet mit Dokumenttypen, Feldern, Referenzen und Berechtigungen statt mit losgelösten Textfragmenten. Ob Schreibzugriffe, Publishing oder bestimmte Tools verfügbar sind, hängt von der konkreten Integration und ihrer Konfiguration ab.

Wichtig ist die Abgrenzung: MCP ist weder ein Sprachmodell noch ein Qualitäts- oder Sicherheitsstandard für Inhalte. Es ersetzt keine Redaktion, keine Content-Governance und keine API-Sicherheit. Es standardisiert den Zugang zu Werkzeugen. Die eigentliche Verlässlichkeit entsteht aus sauberem Content-Modell, kontrollierter Authentifizierung, Prüfregeln und nachvollziehbaren Freigaben.

Fünf Workflows, für die sich ein CMS mit MCP auszahlt

1. Inhalte direkt im CMS erstellen und überarbeiten

Ein Assistent kann vorhandene Inhalte lesen, wiederkehrende Begriffe erkennen und neue Beiträge an das tatsächliche Content-Modell anpassen. Der Entwurf entsteht als strukturiertes Dokument: Titel, Slug, Zusammenfassung, Textabschnitte, Key Points und SEO-Metadaten liegen bereits in den vorgesehenen Feldern. Die Redaktion prüft und veröffentlicht ihn anschließend. Das vermeidet den Umweg über Dokumentdateien und Copy-and-paste.

2. Interne Verlinkung systematisch prüfen

Ein Assistent kann per CMS-Zugriff einen Bestand aus Services, Branchen, Projekten und Insights auslesen, passende Kontextlinks vorschlagen und Orphan Pages (Seiten ohne interne Eingangslinks) oder unklare Ankertexte identifizieren. Dabei muss er Links anhand tatsächlich existierender Zielseiten und ihrer Sprachen validieren. Ein Linkgraph entsteht aus den vorhandenen Referenzen und URLs, nicht aus frei erfundenen Empfehlungen.

3. Content-Cluster über den Bestand hinweg analysieren

Welche Artikel decken ein Thema bereits ab? Wo überschneiden sich Suchintentionen? Welche Service-Seite führt zu den fachlichen Beiträgen, und wo fehlt der Rücklink? Die Informationen lassen sich aus CMS-Dokumenten extrahieren und als Cluster, Tabelle oder Graph visualisieren. Ein MCP-Server erzeugt dabei noch keine Visualisierung. Dafür braucht es ein zusätzliches Analyse- oder Visualisierungstool.

4. Sprachversionen konsistent weiterentwickeln

Bei mehrsprachigen Websites lassen sich Änderungen an einer Ausgangsversion mit den dazugehörigen Übersetzungen vergleichen. Ein Assistent erkennt beispielsweise fehlende Abschnitte, veraltete CTAs oder Links auf die falsche Sprachversion. Lokalisierung bleibt redaktionelle Arbeit: deutsche, englische und serbische Suchintentionen, Terminologie und Lesererwartungen unterscheiden sich. Ein 1:1-Abgleich der Texte wäre hier nicht sinnvoll.

5. SEO- und GEO-Checks im Content-Workflow verankern

Vor einer Veröffentlichung lassen sich SEO Title, Meta Description, Überschriften, Entity-Konsistenz, interne Links, fachliche Vollständigkeit und Antworten auf konkrete Nutzerfragen prüfen. Wird zusätzlich ein spezialisiertes System wie der Vysentra MCP angebunden, kann der Assistent Content-Daten mit dessen verfügbaren SEO- und GEO-Funktionen kombinieren. Welche Prüfungen und Änderungen tatsächlich automatisiert werden, richtet sich nach den bereitgestellten Tools und ihren Zugriffsrechten. Kein MCP garantiert Rankings oder Erwähnungen in KI-Antworten.

Welche Funktionen Sanity über MCP konkret bereitstellt

Der gehostete Sanity-MCP-Server unter mcp.sanity.io stellt nicht nur einen einfachen Content-Connector bereit. Er bietet Tools für Dokumente, Schemata, Suche, Releases, Assets und Projektverwaltung. In einer aktuellen Anbindung sind mehr als 50 Tools sichtbar; der verfügbare Umfang hängt von Client, Rollen und der Weiterentwicklung des Dienstes ab. Entscheidend für Content-Teams ist, wie sich diese Funktionen kombinieren lassen.

Dokumente lesen und gezielt ändern

Mit query_documents führt der Assistent GROQ-Abfragen aus. get_document liest ein Dokument über seine ID. create_documents legt strukturierte Inhalte an, patch_documents verändert gezielt bestehende Felder und publish_documents veröffentlicht freigegebene Entwürfe. unpublish_documents und discard_drafts unterstützen die Trennung zwischen Live-Inhalten und redaktionellen Änderungen. So kann ein Assistent beispielsweise Metadaten eines bestimmten Beitrags aktualisieren, ohne sämtliche anderen Felder zu ersetzen.

Content-Modell und Validierung verstehen

get_schema und schema_type_get machen Dokumenttypen, Felder und Referenzen nachvollziehbar. Mit documents_validate lassen sich Inhalte vor dem Publishing gegen das im Projekt hinterlegte Schema prüfen. Das ist gerade bei modularen Websites wichtig: Ein Text für einen FAQ-Block gehört in eine andere Struktur als ein Projektbeleg oder eine Code-Section. Sanity weist zugleich darauf hin, dass benutzerdefinierte Validierungsregeln über MCP derzeit nicht vollständig ausgeführt werden und mehrere parallel registrierte Schemas die Prüfung einschränken können.

Verwandte Inhalte über Semantik suchen

list_embeddings_indices und semantic_search ermöglichen semantische Suche, wenn ein passender Embeddings-Index eingerichtet ist. Damit lassen sich inhaltlich ähnliche Seiten über die reine Keyword-Übereinstimmung hinaus identifizieren. Für einen Content-Cluster ist das ein guter Ausgangspunkt: Der Assistent kann verwandte Dokumente finden, sie mit ihren Referenzen und Links abgleichen und Kandidaten für interne Verlinkungen vorschlagen. Eine fertige Cluster-Visualisierung ist damit allerdings noch nicht Bestandteil des MCP-Servers.

Medien, Releases und Infrastruktur verwalten

Über Media-Library-Tools kann ein Assistent Assets suchen, Metadaten ändern, Verwendungen nachvollziehen und Bilder oder Dateien mit Dokumenten verknüpfen. Upload-Tools übernehmen Dateien aus URLs oder geeigneten lokalen Quellen. create_release, create_version und list_releases helfen, zusammengehörige Content-Änderungen zu organisieren. create_release plant eine Veröffentlichung jedoch nicht automatisch: Dafür sind zusätzliche Schritte im Studio oder über die passende API notwendig.

Außerdem stehen Verwaltungsfunktionen für Projekte, Datasets, Studios, CORS-Einstellungen und Nutzungsdaten zur Verfügung. Das ist für technische Teams hilfreich, ändert aber nichts daran, dass Infrastrukturänderungen besonders restriktive Rechte und eigene Freigaben brauchen.

Sanity: Dokumentation des gehosteten MCP-Servers und seiner Tools

Welche Aufgaben erst durch die Kombination mehrerer Systeme entstehen

Ein Tool namens semantic_search analysiert keine Suchintention. Und patch_documents entwickelt keine SEO-Strategie. Die Tools ermöglichen den Zugriff und die Veränderung von Content-Daten; der Assistent muss die Informationen fachlich auswerten und geeignete Werkzeuge orchestrieren.

Für die interne Verlinkungsanalyse kombiniert ein Assistent beispielsweise query_documents mit einer Auswertung der vorhandenen URLs, Sprachversionen und Referenzen. Die Auswahl sinnvoller Linkziele verlangt zusätzlich redaktionelles Urteil. Für die Darstellung eines Content-Clusters braucht es eine Visualisierungskomponente außerhalb des Sanity-MCP.

Für SEO- und GEO-Analysen gilt dasselbe. Sanity liefert Artikel, Metadaten, Entitäten und Links. Externe Prüfwerkzeuge – etwa ein entsprechend angebundener Vysentra MCP – ergänzen Search-Daten und fachliche Diagnostik, sofern die jeweiligen Tools verfügbar sind. Der Assistent verbindet Befunde mit konkreten CMS-Dokumenten und bereitet gezielte Änderungen vor. Die Sichtbarkeit in Suchmaschinen und KI-Antwortsystemen bleibt unabhängig davon zu bewerten.

Eine weitere Unterscheidung betrifft die Produktfamilie: Der allgemeine Sanity-MCP-Server unter mcp.sanity.io bietet Lese- und Schreiboperationen für Content-Management. Sanity Context MCP stellt in eigenen, konfigurierbaren Endpoints primär Kontext, GROQ-Zugriffe oder Knowledge-Base-Suche für Assistenten bereit. Beide Integrationen decken unterschiedliche Aufgaben ab; Sanity Context ersetzt nicht die Schreibtools des allgemeinen MCP-Servers.

Sanity Context: verfügbare Tools für GROQ- und Knowledge-Base-Modus

Beispiel: ein kompletter Publishing-Workflow ohne Copy-and-paste

Angenommen, ein B2B-Unternehmen möchte einen technischen Beitrag zur Integration von Produktionsdaten veröffentlichen. Die Redaktion definiert Suchintention, Zielgruppe, fachliche Quellen und Freigabeverantwortung. Der KI-Assistent liest anschließend die relevanten bestehenden Service-Seiten und Insights aus dem CMS. Er erkennt, welche Fragen schon beantwortet sind und welche Perspektive der neue Artikel ergänzen muss.

Danach legt der Assistent einen Entwurf im richtigen Content-Typ an. Er schreibt die Antwort auf die zentrale Fachfrage früh in den Beitrag, ordnet die technischen Abschnitte, verknüpft zwei fachlich passende Seiten und bereitet Title sowie Description vor. Ein SEO-Check überprüft, ob Suchintention, Headline, Links und Entitäten zusammenpassen. Ein separater GEO-Check prüft, ob Definitionen, technische Voraussetzungen und belegte Aussagen für KI-Suchsysteme klar verständlich sind.

Die Redaktion bewertet den Entwurf, Engineering prüft die technischen Aussagen und Verantwortliche genehmigen die Publikation. Erst dann wird der Beitrag veröffentlicht. Der Unterschied zum herkömmlichen Ablauf liegt nicht in einer magischen Textqualität, sondern in der direkten Arbeit an konsistenten CMS-Daten – mit weniger manuellen Übertragungen und klareren Prüfpunkten.

Warum Sanity für diese Architektur interessant ist

Das Headless CMS Sanity trennt strukturierte Inhalte von ihrer Darstellung. Dokumenttypen, Felder, Portable Text und Referenzen schaffen eine Grundlage, die ein KI-Assistent nicht erst aus einer fertigen HTML-Seite rekonstruieren muss. Sanity stellt zudem MCP-basierte Integrationsmöglichkeiten bereit, über die autorisierte Assistenten auf relevante Inhalte und Werkzeuge zugreifen können. Der konkrete Funktionsumfang unterscheidet sich je nach Sanity-Konfiguration und verwendetem Endpoint.

Diese Kombination ist vor allem dann wertvoll, wenn eine Website viele Leistungsseiten, Projektbelege, Insights und Sprachversionen verbindet. Ein Assistent kann das Content-Modell berücksichtigen, statt Text unkontrolliert in ein WYSIWYG-Feld zu schreiben. Struktur und Content-Governance bleiben Teil der Architektur.

Sanity ist dabei nicht deshalb die einzige sinnvolle Wahl, weil es MCP unterstützt. Andere CMS können eigene oder externe MCP-Server anbinden; gegebenenfalls erfüllt auch eine robuste API-basierte Integration dieselben fachlichen Anforderungen. Entscheidend sind stabile Tool-Verträge, ein nutzbares Schema, nachvollziehbare Rechte, Drafts, Validierung und ein sauberer Publishing-Prozess. Die Entwicklung solcher Content- und Anwendungsarchitekturen gehört zu unserem Platform Engineering.

MCP nativ anbieten heißt mehr als einen Connector veröffentlichen

Für die CMS-Auswahl sollte die Frage nicht nur lauten: Gibt es irgendwo einen MCP-Server? Ein Drittanbieter-Connector kann schnell starten, aber er kann auch hinter aktuellen Schema-Versionen, Authentifizierungsmechanismen oder neuen Dokumenttypen zurückbleiben. Eine vom Hersteller gepflegte Anbindung reduziert diesen Abstimmungsaufwand – vorausgesetzt, sie unterstützt die relevanten Funktionen tatsächlich.

Eine belastbare Integration muss Dokumente selektiv lesen, Änderungen präzise schreiben, Referenzen korrekt behandeln und Berechtigungen konsequent respektieren. Sie sollte Entwurfs- und Live-Inhalte unterscheiden, Konflikte bei parallelen Änderungen erkennen und Fehler so zurückgeben, dass der Assistent nicht unbemerkt inkonsistente Daten erzeugt.

Auch die Tool-Oberfläche zählt. Eine große Sammlung unklar beschriebener Schreibwerkzeuge hilft wenig. Besser sind verständliche Funktionen mit begrenztem Scope, prüfbaren Eingaben und klaren Ergebnissen. Teams sollten vor der CMS-Entscheidung reale Testfälle aus dem eigenen Redaktionsalltag ausführen – inklusive Fehlerfall, Rollentrennung und Rollback.

Governance: Ein KI-Assistent darf nicht automatisch publizieren

Wer MCP-Zugriff als reine Komfortfunktion betrachtet, übersieht den entscheidenden Architekturpunkt. Ein KI-Assistent kann irren, eine Quelle falsch interpretieren oder eine Anweisung aus einem nicht vertrauenswürdigen Dokument übernehmen. Deshalb braucht der Zugriff dieselbe Sorgfalt wie jede andere Systemintegration.

Leserechte und Schreibrechte sollten getrennt vergeben werden. Produktionszugriffe benötigen aufgabenbezogene Rollen, möglichst kleine Berechtigungsumfänge und klare Freigaben. Sensible Inhalte dürfen nicht allein deshalb an ein externes Modell übertragen werden, weil sie über das CMS erreichbar sind. Datenklassifizierung, Anbieterbedingungen, Aufbewahrung und Mandantentrennung müssen vor dem Einsatz geklärt sein.

Zum Mindeststandard gehören Drafts, Versionierung, Validierung, Audit-Logs und ein Review vor dem Publishing. Besonders kritisch sind automatisches Löschen, umfassende Linkänderungen, globale Übersetzungsupdates und Publikationen über mehrere Sprachen hinweg. Hier sollten Assistenten zunächst einen Change-Plan liefern und Änderungen erst nach Freigabe durchführen.

SEO und GEO profitieren von besseren Content-Workflows – nicht von MCP allein

Ein MCP-Server ist kein direkter Rankingfaktor. Suchmaschinen bewerten nicht, ob eine Redaktion ihre Texte über Copy-and-paste oder über einen MCP-Client in das CMS überträgt. Für die organische Sichtbarkeit zählen weiterhin unter anderem relevante Inhalte, crawlbares HTML, interne Verlinkung, technische Erreichbarkeit und eine klare Informationsarchitektur.

Der indirekte Nutzen liegt in der Prozessqualität. Wenn ein Assistent strukturierte Seiten direkt prüfen kann, fallen fehlende interne Links, inkonsistente Service-Namen, doppelte Themen, veraltete Metadaten und Sprachabweichungen früher auf. Redaktionelle Teams können solche Befunde systematischer beheben und nach der Publikation erneut kontrollieren.

Auch für GEO, also die Sichtbarkeit in KI-Antworten, gilt: Klare Definitionen, überprüfbare Fachinformationen und konsistente Entitäten helfen KI-Suchsystemen, Inhalte richtig einzuordnen. Das garantiert weder Erwähnungen noch Quellenzitate. Entscheidend sind gut strukturierter Content und nachvollziehbare Reviews – nicht die bloße Anbindung eines MCP-Servers. In unserem Bereich Search & AI Visibility verbinden wir diese Anforderungen mit Technical SEO und Content Engineering.

CMS-Auswahl: die Fragen, die wir heute stellen würden

Wer eine neue Content-Plattform einführt oder ein bestehendes CMS bewertet, sollte die Integration in KI-Workflows von Anfang an berücksichtigen. Nicht als isoliertes Feature, sondern als Teil einer funktionierenden Publishing-Architektur.

Wir prüfen im Auswahlprozess, ob die KI-Werkzeuge das echte Schema lesen, sichere Entwürfe erstellen, interne Referenzen auflösen, Sprachversionen erkennen und Änderungen validieren können. Außerdem interessiert uns, wer den MCP-Zugang wartet, wie sich Berechtigungen begrenzen lassen und wie sich Fehler nachvollziehen und zurücknehmen lassen.

Wo eine Herstellerintegration diese Anforderungen erfüllt, spricht viel für sie. Wo ein gut wartbarer eigener MCP-Server oder eine vorhandene API wirtschaftlicher ist, sollte die Architektur diese Option offenhalten. Die Entscheidung hängt an Änderbarkeit, Sicherheit, Betrieb und tatsächlichem Redaktionsaufwand – nicht an einem Logo in der Integrationsliste.

TYPO3, WordPress, Contao oder Webflow: Wann sich die CMS-Migration lohnt

MCP-Unterstützung allein ist noch kein Grund, ein funktionierendes CMS zu ersetzen. Relevant wird eine Migration, wenn die bestehende Plattform strukturierte Inhalte, verlässliche Integrationen und die direkte Arbeit mit KI-Assistenten nur mit wachsendem Wartungs- oder Entwicklungsaufwand ermöglicht. Dann prüfen wir Content-Modell, Redaktionsprozesse, Schnittstellen, SEO-Bestand und die Anforderungen an die neue Architektur gemeinsam.

Wenn TYPO3-Extensions und wiederkehrende Upgrades die Weiterentwicklung bremsen, prüfen wir, ob eine TYPO3-Migration zu einer klareren Content-Architektur führt. Bei WordPress stellt sich dagegen oft die Frage, ob eine WordPress-Migration zu Sanity oder Payload notwendig ist oder Headless WordPress bereits alle Anforderungen erfüllt.

Bei Contao rücken individuelle Erweiterungen und Abhängigkeiten in den Mittelpunkt; eine Contao-Migration soll diese gezielt auflösen. Unternehmen, die Inhalte aus Webflow auch in Portalen oder Anwendungen einsetzen möchten, profitieren gegebenenfalls von einer Webflow-Migration auf ein strukturiertes Headless CMS.

Wir übertragen nicht einfach Seiten von System A nach System B. Wir prüfen Dokumenttypen, Medien, Sprachversionen, Redirects, interne Verlinkungen und die vorhandene Suchsichtbarkeit. Anschließend entwickeln wir Content-Modell, Frontend und Schnittstellen so, dass neue Prozesse direkt am CMS ansetzen. Die Entscheidung für Sanity, Payload oder den Verbleib auf der bestehenden Plattform fällt auf Basis der tatsächlichen Anforderungen.

Fazit: Das CMS muss Teil des Arbeitsprozesses werden

Sprachmodelle sind längst Werkzeuge für Recherche, redaktionelle Arbeit und technische Prüfungen. Ein CMS, das diese Arbeit nur über manuelle Übertragungen erreicht, schafft vermeidbare Reibung. Deshalb sollten CMS-Hersteller MCP als gepflegte, klar dokumentierte und sicher betreibbare Schnittstelle bereitstellen.

Die entscheidende Voraussetzung bleibt ein gutes Content-Modell. Erst wenn Inhalte strukturiert, Beziehungen verlässlich und Änderungen kontrollierbar sind, entsteht aus der MCP-Anbindung ein tragfähiger Produktionsprozess. Die Redaktion behält die Verantwortung; die Werkzeuge übernehmen wiederholbare Schritte.

Wir entwickeln bei Valanor Content-Plattformen und die dazugehörigen Integrationen so, dass Redaktion, technische Architektur und Search & AI Visibility zusammenarbeiten. Entscheidend ist, dass Inhalte dort weiterverarbeitet werden, wo sie verwaltet werden – mit einer klaren Verantwortung für Qualität und Veröffentlichung.

Häufige Fragen zu CMS und MCP

Was ist ein MCP-Server für ein CMS?

Ein MCP-Server stellt ausgewählte CMS-Funktionen standardisiert für kompatible KI-Assistenten bereit. Er kann je nach Berechtigung Inhalte lesen, Entwürfe anlegen oder definierte Änderungen ausführen.

Braucht jedes CMS einen eigenen nativen MCP-Server?

Nicht zwingend. Eine gepflegte Herstellerintegration ist oft leichter zu betreiben. Ein externer oder selbst entwickelter MCP-Server ist ebenfalls sinnvoll, wenn er das Schema, die Rechte und die relevanten Workflows zuverlässig unterstützt.

Kann ChatGPT damit direkt in Sanity schreiben?

Ja, wenn ein kompatibler Client mit der passenden Sanity-MCP-Integration verbunden ist und die notwendigen Rechte besitzt. Ob Dokumente nur gelesen, als Draft erstellt oder veröffentlicht werden, bestimmt die konkrete Tool- und Berechtigungskonfiguration.

Verbessert MCP automatisch SEO- und GEO-Rankings?

Nein. MCP erleichtert Analysen und Content-Pflege. Sichtbarkeit hängt weiterhin von fachlicher Relevanz, technischer SEO, interner Verlinkung, Content-Qualität und den jeweiligen Such- beziehungsweise Antwortsystemen ab.

Wie schützt man ein CMS vor falschen KI-Änderungen?

Durch rollenbasierte Rechte, getrennte Lese- und Schreibzugriffe, Drafts, Schema-Validierung, Versionierung, Änderungsprotokolle und eine menschliche Freigabe vor Veröffentlichung.

CMS-Migration und KI-Integration

Von TYPO3, WordPress, Contao oder Webflow zu einer Content-Plattform mit MCP.

Ihre bestehende CMS-Umgebung erschwert die Integration von KI-Assistenten, die Wiederverwendung von Inhalten oder die Weiterentwicklung Ihrer Website? Wir prüfen den Wechsel zu Sanity oder Payload, entwickeln die passende Content-Architektur und übernehmen die Migration inklusive SEO, Redirects, Mehrsprachigkeit und technischer Integrationen.

CMS-Migration besprechen

Aleksandar Basara

Managing Director

aleks@valanor.co

+49 (0) 711 16 44 6 83

Lindenspürstrasse 22, 70176 Stuttgart

Aleksandar Basara - Managing Director and CTO at VALANOR