Nach drei Wochen ist der Fachbeitrag freigegeben. Die Fachabteilung hat zweimal korrigiert, die Rechtsabteilung hat einen Satz entschärft, die Bereichsleitung hat die Überschrift geändert. Jetzt muss er nur noch auf die Website.
Die Webredakteurin öffnet das CMS, kopiert den Text aus dem Dokument, repariert die Zwischenüberschriften, sucht die Bilder im Laufwerk, schreibt Alt-Texte, ergänzt die Meta-Beschreibung, setzt drei interne Links und wählt Kategorie und Tags. Um 18:40 Uhr ist der Beitrag online. Am nächsten Morgen meldet sich die Rechtsabteilung: Der entschärfte Satz steht in der alten Fassung auf der Seite. Kopiert wurde aus dem falschen Dokument.
Die letzte Meile ist der Weg vom freigegebenen Text zur veröffentlichten Seite. Sie taucht in kaum einer Prozessbeschreibung auf, kostet aber je Beitrag eine halbe bis eine Stunde Handarbeit und ist die häufigste Stelle, an der freigegebene und veröffentlichte Fassung auseinanderlaufen. Mit einer Anbindung über MCP lässt sich der Inhalt direkt aus der Arbeitsumgebung als Entwurf im CMS anlegen, passend zur dortigen Struktur. Die Veröffentlichung selbst bleibt eine menschliche Entscheidung.
Was ist die letzte Meile im Content-Prozess?
Alles, was zwischen Freigabe und Livegang passiert: Text übertragen, Formatierung reparieren, Bilder hochladen, Alt-Texte und Metadaten pflegen, Kategorien setzen, interne Links ergänzen, Vorschau prüfen, veröffentlichen. Dazu kommen nachträgliche Korrekturen, die dann an zwei Orten gepflegt werden müssen.
In den meisten Teams gilt ein Beitrag als fertig, sobald er freigegeben ist. Die Planung zeigt ihn als erledigt, die Beteiligten wenden sich dem nächsten Thema zu. Was danach passiert, ist Aufgabe einer Person, die oft nicht an der Entstehung beteiligt war: die Webredaktion, eine Werkstudentin, im kleineren Team die Marketingleitung selbst am Abend.
Der Begriff stammt aus der Logistik. Dort bezeichnet er den letzten Abschnitt der Lieferkette bis zur Haustür, der im Verhältnis zur Strecke am teuersten und am fehleranfälligsten ist. Die Parallele ist genauer, als sie zunächst wirkt. Auch im Content-Prozess ist der letzte Abschnitt kurz, kleinteilig, schlecht standardisiert und deshalb überproportional teuer.
Die Arbeitsschritte selbst sind banal. Keiner davon erfordert besondere Kompetenz. Gerade deshalb werden sie nicht geplant, nicht gemessen und nicht verbessert. Sie passieren einfach, irgendwann zwischen Freigabe und dem Zeitpunkt, an dem jemand nachfragt, warum der Beitrag noch nicht online ist.
Warum taucht die letzte Meile in keiner Aufwandsrechnung auf?
Weil sie auf viele kleine Handgriffe verteilt ist, die einzeln harmlos wirken, und weil sie häufig bei Personen anfällt, deren Zeit nicht dem Beitrag zugerechnet wird. In der Summe ist sie trotzdem einer der größeren Posten pro Veröffentlichung.
Wer den Aufwand für einen Beitrag schätzt, denkt an Recherche, Schreiben und Abstimmung. Das sind die sichtbaren Teile. Wie viel Zeit tatsächlich in den unsichtbaren Posten steckt, steht im Beitrag zur Frage, wo die neun Stunden pro Beitrag wirklich hingehen. Die letzte Meile ist einer dieser Posten, und sie wächst mit jedem zusätzlichen Kanal und jeder zusätzlichen Website.
Die folgende Aufstellung ist ein Arbeitsmodell aus Gesprächen mit Content-Teams, keine erhobene Messung. Sie hilft, den eigenen Aufwand ehrlich zu schätzen.
| Arbeitsschritt | Typischer Aufwand | Fehlerrisiko |
|---|---|---|
| Text übertragen und Formatierung reparieren | 10 bis 15 Minuten | hoch, falsche Fassung oder verlorene Auszeichnungen |
| Bilder suchen, hochladen, zuschneiden | 5 bis 15 Minuten | mittel, Bildrechte und Größen |
| Alt-Texte schreiben | 5 Minuten | hoch, werden oft weggelassen |
| Meta-Titel und Beschreibung | 5 bis 10 Minuten | mittel, Länge und Bezug zum Inhalt |
| Kategorien, Tags, Autor | 2 bis 5 Minuten | niedrig, aber uneinheitlich |
| Interne Links setzen | 5 bis 10 Minuten | mittel, werden unter Zeitdruck gestrichen |
| Vorschau prüfen und veröffentlichen | 5 Minuten | niedrig |
| Spätere Korrekturen doppelt pflegen | unregelmäßig | hoch, Dokument und Seite laufen auseinander |
Bei acht Beiträgen im Monat sind das schnell sechs bis acht Stunden, die niemand eingeplant hat. Bei mehreren Websites, Sprachversionen oder Microsites vervielfacht sich der Wert, weil dieselben Handgriffe je Zielsystem anfallen. Das ist keine dramatische Zahl. Dramatisch ist, dass sie in keinem Bericht erscheint und deshalb auch niemand den Auftrag bekommt, sie zu senken.
Welche Fehler entstehen beim Übertragen ins CMS?
Fünf Fehler wiederholen sich: Es wird die falsche Fassung veröffentlicht, Formatierungen gehen verloren, Metadaten fehlen, Bildangaben sind unvollständig, und spätere Korrekturen landen nur auf der Website, nicht im Dokument. Alle fünf haben dieselbe Ursache: Der Inhalt wechselt das System, und an dieser Grenze geht Kontext verloren.
- VersionsbruchDas Dokument liegt in mehreren Fassungen vor, und kopiert wird aus der, die gerade offen ist. Die Freigabe galt einer anderen. Das ist der teuerste Fehler, weil er erst auffällt, wenn jemand die Seite liest, der den Prüfstand kennt.
- FormatverlustZwischenüberschriften werden zu fettem Text, Listen zu Absätzen, Tabellen zu Leerzeichen. Für Leser ist das ärgerlich, für Suchmaschinen und KI-Systeme, die Struktur auswerten, ist es ein echter Nachteil.
- Fehlende MetadatenMeta-Beschreibung, Alt-Texte und Kategorien werden unter Zeitdruck als Erstes weggelassen. Sie sind unsichtbar, also fällt ihr Fehlen niemandem auf, bis die Seite in der Suche schlecht abschneidet.
- Unklare BildrechteIm Laufwerk liegt eine Bilddatei ohne Angabe zu Urheber und Nutzungsrecht. Wer überträgt, muss raten oder nachfragen. Beides kostet Zeit, das Raten zusätzlich Risiko.
- Drift nach dem LivegangEin Tippfehler wird direkt im CMS korrigiert, eine Zahl aktualisiert. Im Dokument bleibt die alte Fassung. Beim nächsten Update wird wieder aus dem Dokument kopiert, und der alte Fehler ist zurück.
Die entscheidende Frage ist nicht, ob eure Webredaktion sorgfältig arbeitet. Sie lautet: An wie vielen Stellen existiert ein veröffentlichter Beitrag bei euch gleichzeitig, und welche davon gilt? Jede Antwort größer als eins ist eine Fehlerquelle, unabhängig von der Sorgfalt.
Warum die bisherigen Lösungen nicht gereicht haben
Das Problem ist nicht neu, und es gab immer Versuche, es zu lösen. Jeder davon hat einen Teil abgedeckt und einen anderen geöffnet.
Direkt im CMS schreiben. Der naheliegendste Weg. Wer gleich im CMS arbeitet, muss nichts übertragen. Der Preis ist hoch: Ein CMS ist für Verwaltung und Darstellung gebaut, nicht für Zusammenarbeit. Kommentare der Fachabteilung, Änderungsverfolgung, Freigabestufen, Markensprache, KI-Unterstützung mit Kontext, all das fehlt oder ist nur rudimentär vorhanden. Teams, die so arbeiten, verlagern die Abstimmung deshalb in E-Mails und Chats, und dort entsteht dasselbe Versionsproblem, nur an anderer Stelle.
Kopierhilfen und Exportfunktionen. Werkzeuge, die Dokumente sauberer ins CMS bringen, lösen den Formatverlust. Sie lösen nicht die Frage, welche Fassung kopiert wird, und sie füllen keine Metadaten. Der Handgriff wird schneller, er verschwindet nicht.
Feste Schnittstellen. Die technisch sauberste Variante war bisher eine programmierte Integration zwischen Content-Werkzeug und CMS. Sie funktioniert, ist aber teuer: Sie muss je CMS gebaut werden, bildet ein fest definiertes Content-Modell ab und muss bei jedem größeren Update gewartet werden. Für ein Unternehmen mit einer Hauptseite in TYPO3 und zwei Microsites in WordPress bedeutet das zwei Projekte, zwei Wartungsverträge und zwei Stellen, an denen etwas brechen kann. Viele Teams haben deshalb verzichtet und sind beim Kopieren geblieben.
Was allen drei Wegen fehlt, ist ein Verständnis der Zielstruktur. Ein CMS ist nicht einfach ein Textfeld. Es hat Felder, Komponenten, Inhaltstypen, Seitenbäume und Arbeitsbereiche. Wer Inhalte sauber übergeben will, muss wissen, wohin welcher Teil gehört. Bisher musste das ein Mensch wissen, oder eine Programmierung, die genau ein Modell kannte.
Was ist MCP und warum verändert es die Veröffentlichung?
MCP steht für Model Context Protocol, einen offenen Standard, über den KI-Anwendungen mit anderen Systemen sprechen. Für die Veröffentlichung heißt das: Die KI kann die Struktur eines CMS auslesen, also Felder, Komponenten und Kategorien, und Inhalte passend dazu als Entwurf anlegen. Statt einer starren Integration je System gibt es eine gemeinsame Sprache.
Das Protokoll wurde Ende 2024 veröffentlicht und hat sich seitdem als verbreiteter Standard für die Anbindung von KI an Werkzeuge etabliert. Der Grundgedanke ist einfach: Ein System beschreibt, welche Aktionen es anbietet und welche Daten es bereitstellt. Eine KI-Anwendung kann diese Beschreibung lesen und die Aktionen ausführen, im Rahmen der Rechte, die ihr gegeben wurden.
Für die letzte Meile ist ein Punkt entscheidend. Eine klassische Schnittstelle überträgt Daten in ein vorher festgelegtes Format. Eine Anbindung über MCP kann zusätzlich erkennen, wie das Zielsystem aufgebaut ist. Sie sieht, dass der Beitragstyp in Contentful ein Feld für den Teaser hat, dass in Storyblok eine bestimmte Komponente für Zitate existiert oder dass in WordPress eine Kategorie bereits angelegt ist. Der Inhalt wird damit nicht einfach abgeladen, sondern in die vorhandene Struktur einsortiert.
Das bedeutet nicht, dass jede Schnittstelle überflüssig wird. Wann eine feste Integration weiterhin die bessere Wahl ist, etwa bei sehr hohen Stückzahlen oder vollautomatischen Abläufen ohne menschliche Prüfung, steht im Beitrag MCP oder API: welcher Weg für eure Daten der richtige ist. Für den typischen redaktionellen Fall, also wenige bis einige Dutzend Veröffentlichungen im Monat mit menschlicher Prüfung, ist MCP der deutlich leichtere Weg.
Der Text wird als Block übergeben. Was ein Teaser, was eine Zwischenüberschrift, was ein Zitat ist, muss im CMS von Hand zugeordnet werden. Jedes Zielsystem braucht eine eigene Programmierung.
Die Struktur des Zielsystems wird ausgelesen, Inhalte landen in den passenden Feldern und Komponenten. Dieselbe Arbeitsumgebung kann mehrere CMS bedienen, ohne je ein eigenes Integrationsprojekt.
Wie unterscheiden sich WordPress, TYPO3, Contentful und Storyblok bei der Anbindung?
Vor allem darin, wie sie Inhalte organisieren. WordPress denkt in Beiträgen mit Kategorien und Tags, TYPO3 in Seitenbäumen mit Inhaltselementen, Contentful in frei definierten Content-Modellen, Storyblok in Stories aus wiederverwendbaren Komponenten. Je strukturierter das System, desto wichtiger ist, dass die Übergabe diese Struktur kennt.
In vielen Unternehmen ist die Systemlandschaft gemischt. Die Hauptseite läuft auf TYPO3, weil sie vor Jahren mit einer Agentur aufgebaut wurde. Die Kampagnenseiten und der Blog laufen auf WordPress, weil es schneller ging. Für den Produktbereich wurde zuletzt ein Headless-System eingeführt. Genau diese Mischung macht die letzte Meile so teuer, weil jede Übertragung anders funktioniert.
| CMS | Wie Inhalte organisiert sind | Worauf es bei der Übergabe ankommt | Typische Stolperstelle |
|---|---|---|---|
| WordPress | Beiträge und Seiten mit Kategorien, Tags und Metadaten | Als Entwurf anlegen, Tonalität und Aufbau bestehender Beiträge treffen, Kategorien und Metadaten mitgeben | Page-Builder-Layouts, die nicht aus reinem Text bestehen |
| TYPO3 | Seitenbaum mit Inhaltselementen | Inhalte als Seiten und Inhaltselemente anlegen, möglichst in einem Workspace vorbereiten | Individuell entwickelte Inhaltselemente, die zuerst bekannt sein müssen |
| Contentful | Frei definierte Content-Modelle, Entries in Spaces und Environments | Felder des Modells exakt befüllen, Entwürfe statt veröffentlichter Entries | Pro Space muss die Anbindung eingerichtet sein, Pflichtfelder und Referenzen |
| Storyblok | Stories aus verschachtelten Komponenten | Vorhandene Komponenten und Content-Typen nutzen, Entwürfe vor dem Livegang prüfen | Tiefe Verschachtelung, Komponenten, die nur bestimmte Kinder erlauben |
WordPress ist der einfachste Fall. Die Struktur ist überschaubar, und ein Beitrag besteht im Kern aus Titel, Inhalt, Auszug, Kategorie, Tags und SEO-Feldern. Schwieriger wird es nur, wenn die Seiten mit einem Page Builder gestaltet sind und Inhalte in verschachtelten Layout-Elementen stecken. Dann lohnt es sich, für Beiträge eine schlanke Vorlage festzulegen, in die übergeben wird, statt jedes Layout nachzubauen.
TYPO3 ist in vielen mittelständischen Unternehmen und im öffentlichen Bereich gesetzt. Hier ist die wichtigste Funktion für die letzte Meile der Workspace: ein Arbeitsbereich, in dem Änderungen vorbereitet und geprüft werden, bevor sie live gehen. Eine Übergabe, die Inhalte dort ablegt, passt genau in die Logik, mit der TYPO3-Redaktionen ohnehin arbeiten. Vorher sollte geklärt sein, welche individuellen Inhaltselemente eure Agentur gebaut hat, denn die müssen bei der Übergabe bekannt sein.
Contentful ist ein Headless-System. Es gibt keine Seiten im klassischen Sinn, sondern Inhaltstypen mit genau definierten Feldern, die von verschiedenen Ausgabekanälen genutzt werden. Für die Übergabe heißt das: Jedes Feld muss exakt befüllt werden, Pflichtfelder dürfen nicht leer bleiben, Verweise auf andere Einträge müssen stimmen. Hier spielt eine strukturbewusste Übergabe ihren größten Vorteil aus, weil ein Mensch bei komplexen Modellen sonst lange sucht, wohin was gehört.
Storyblok verbindet Headless-Ansatz und visuelle Bearbeitung. Seiten bestehen aus Komponenten, die ineinander verschachtelt werden. Gute Storyblok-Setups haben eine überschaubare Bibliothek an Komponenten, und eine Übergabe sollte genau diese nutzen, statt eigene Strukturen zu erfinden. Entwürfe lassen sich vor dem Livegang in der Vorschau prüfen, was die Kontrolle für die Webredaktion einfach macht.
Wie sieht ein Übergabeprozess aus, in dem nichts verloren geht?
In sechs Schritten: Freigabe am Inhalt statt am Dokument, Zielstruktur einmal festlegen, als Entwurf übergeben, Vorschau durch die Webredaktion prüfen, Korrekturen nur an einer Stelle pflegen und den Livestatus zurück in die Planung melden.
Die Technik ist dabei der kleinere Teil. Wer eine Anbindung einrichtet, ohne den Ablauf zu klären, automatisiert nur das Kopieren aus der falschen Fassung. Diese Reihenfolge hat sich bewährt.
- Schritt 1Freigabe am Inhalt, nicht am DokumentSolange Freigaben an Dateien hängen, gibt es mehrere Fassungen. Die Freigabe muss dort erfolgen, wo der Inhalt entsteht, damit eindeutig ist, welcher Stand übergeben wird. Wie ihr Freigaben dabei kürzer macht, steht im Beitrag zu Freigabeprozessen.
- Schritt 2Zielstruktur einmal festlegenJe Inhaltstyp wird einmal geklärt, wohin er im CMS gehört: Beitragstyp, Kategorie, Felder, Komponenten. Das ist eine Stunde Arbeit mit der Webredaktion und erspart danach jede Einzelentscheidung.
- Schritt 3Immer als Entwurf übergebenDie Anbindung legt Inhalte als Entwurf oder im Arbeitsbereich an, nie direkt live. Das ist keine technische Einschränkung, sondern eine Prozessentscheidung, die ihr bewusst trefft.
- Schritt 4Vorschau durch die WebredaktionDie Webredaktion prüft Darstellung, Bilder und Verlinkung in der Vorschau und veröffentlicht. Ihre Rolle verschiebt sich vom Übertragen zum Prüfen, und genau dort ist ihre Erfahrung am meisten wert.
- Schritt 5Korrekturen an einer StelleSpätere Änderungen werden in der Arbeitsumgebung gemacht und erneut übergeben, nicht direkt im CMS. Sonst entsteht nach dem Livegang wieder eine zweite Fassung.
- Schritt 6Livestatus zurückmeldenDie Planung erfährt, dass und wo der Beitrag online ist. Ab hier lassen sich Ergebnisse dem Thema zuordnen, statt sie später mühsam zusammenzusuchen.
Der fünfte Schritt ist der unbequemste, weil er Gewohnheiten ändert. Einen Tippfehler direkt im CMS zu korrigieren, ist schneller. Wer es trotzdem an der Quelle tut, verhindert, dass derselbe Fehler beim nächsten Update zurückkommt. Hilfreich ist eine einfache Regel: Alles, was den Inhalt betrifft, wird an der Quelle geändert. Alles, was nur die Darstellung betrifft, darf im CMS bleiben.
Wer darf was? Rechte und Verantwortung bei der Anbindung
Die Anbindung bekommt nur die Rechte, die sie für die Übergabe braucht: lesen, um die Struktur zu kennen, und Entwürfe anlegen. Veröffentlichen bleibt bei Menschen. Jede Aktion wird protokolliert, und die IT weiß von Anfang an, welcher technische Zugang mit welchen Rechten existiert.
Die häufigste Sorge in Gesprächen über diese Art der Anbindung lautet: Dann veröffentlicht ja die KI. Diese Sorge ist berechtigt, wenn man die Rechte falsch vergibt. Sie ist unbegründet, wenn man sie richtig vergibt. Die meisten CMS trennen ohnehin zwischen Rollen, die Entwürfe anlegen, und Rollen, die veröffentlichen dürfen. Die Anbindung bekommt die erste Rolle.
| Aktion | Anbindung | Webredaktion | Marketing |
|---|---|---|---|
| Struktur und Kategorien lesen | ja | ja | ja |
| Entwurf anlegen oder aktualisieren | ja | ja | ja |
| Bilder in die Mediathek laden | ja, mit Angaben | ja | nach Absprache |
| Veröffentlichen | nein | ja | nach Absprache |
| Bestehende Seiten löschen | nein | ja | nein |
| Einstellungen und Plugins ändern | nein | nein | nein |
Für die IT sind drei Fragen wichtig: Über welchen technischen Benutzer läuft die Anbindung, welche Rechte hat er, und wo ist nachvollziehbar, was er getan hat? Wer diese Fragen beantworten kann, bevor die Anbindung eingerichtet wird, verkürzt die Prüfung erheblich. Wie ihr IT und Datenschutz so einbindet, dass daraus keine wochenlange Schleife wird, steht in IT und Datenschutz früh einbinden.
Was ändert sich für Webredaktion und Marketing?
Für die Webredaktion ist die Veränderung am größten, und sie wird anfangs oft skeptisch gesehen. Wer bisher übertragen hat, fürchtet, überflüssig zu werden. Das Gegenteil ist der Fall. Die Übertragung war nie der wertvolle Teil der Arbeit. Wertvoll ist das Wissen darüber, wie eine Seite wirken muss, welche Struktur Suchmaschinen und Leser brauchen und welche Komponenten in welcher Situation passen. Genau dieses Wissen fließt in Schritt 2 ein, die Festlegung der Zielstruktur, und in Schritt 4, die Prüfung.
Für das Marketing verändert sich vor allem die Sicht. Bisher endete der Überblick bei der Freigabe. Was danach passierte, war für die Planung unsichtbar. Mit einer Übergabe, die den Livestatus zurückmeldet, sieht die Planung, was tatsächlich veröffentlicht ist und wann. Das klingt nach einer Kleinigkeit, verändert aber die Gespräche über Kapazität. Statt zu fragen, warum etwas noch nicht online ist, lässt sich sehen, wo es liegt.
Für Teams mit mehreren Websites kommt ein dritter Effekt hinzu. Ein Thema, das auf der Hauptseite als Fachartikel und auf einer Microsite als kürzere Fassung erscheinen soll, wird an einer Stelle erarbeitet und an zwei Zielsysteme übergeben. Die Ableitung entsteht dort, wo auch der Kern liegt. Wie ihr Kern und Ableitungen grundsätzlich organisiert, steht im Beitrag zur Multichannel-Strategie.
Wie rechnet sich eine Anbindung ans CMS?
Über drei Posten: die eingesparte Übertragungszeit, die vermiedenen Korrekturschleifen nach falschen Veröffentlichungen und die vollständigeren Metadaten, die sich in der Sichtbarkeit niederschlagen. Der erste Posten lässt sich sauber rechnen, die beiden anderen solltet ihr benennen, aber nicht in Euro überhöhen.
Für den ersten Posten genügt eine einfache Rechnung. Nehmt die Zahl der Veröffentlichungen pro Monat, multipliziert sie mit dem Aufwand für die letzte Meile und mit der Zahl der Zielsysteme, die ein Inhalt typischerweise erreicht. Das Ergebnis multipliziert ihr mit zwölf und eurem internen Stundensatz.
| Annahme | Wert |
|---|---|
| Veröffentlichungen pro Monat | 12 |
| Aufwand letzte Meile je Veröffentlichung | 45 Minuten |
| Davon durch Übergabe als Entwurf vermeidbar | etwa zwei Drittel |
| Eingesparte Stunden pro Jahr | rund 72 |
| Interner Stundensatz | 70 Euro |
| Rechnerischer Wert pro Jahr | rund 5.000 Euro |
Das ist für sich genommen keine Zahl, die eine Investition allein trägt. Sie wird interessant in Kombination mit den anderen Posten und mit der Zahl der Zielsysteme. Bei drei Websites oder mehreren Sprachversionen verdoppelt oder verdreifacht sich der Wert schnell. Und sie wird vollständig, wenn ihr dazurechnet, was ein einziger Fehler kostet, bei dem eine nicht freigegebene Aussage öffentlich wird. Wie ihr solche Posten sauber in einen Business Case für das Chefgespräch bringt, ohne zu übertreiben, steht in der Vorlage für den Business Case.
In eigener Sache
Ich arbeite für contentbird. Dort lässt sich seit Herbst 2026 freigegebener Content per MCP direkt nach WordPress, TYPO3, Contentful und Storyblok übergeben, als Entwurf, passend zu Seitenbaum, Content-Modell oder Komponenten des jeweiligen Systems. Der Anlass war genau die Situation aus diesem Beitrag: Fehlende Veröffentlichung war in Gesprächen mit Content-Teams einer der häufigsten Gründe, warum Arbeitsumgebung und Website getrennt blieben.
Dieser Beitrag ist übrigens selbst auf diesem Weg entstanden. Er wurde als Entwurf über eine MCP-Verbindung in dieses WordPress übergeben und vor der Veröffentlichung hier im CMS geprüft.
Wann lohnt sich eine Anbindung ans CMS nicht?
Wenn ihr nur wenige Beiträge im Monat veröffentlicht, wenn eure Seiten überwiegend individuell gestaltete Landingpages sind oder wenn der Freigabeprozess davor noch nicht geklärt ist. Im letzten Fall automatisiert ihr nur den Fehler.
Bei zwei oder drei Veröffentlichungen im Monat ist die letzte Meile lästig, aber nicht teuer. Hier lohnt es sich eher, die Arbeitsschritte in eine Checkliste zu bringen, damit Metadaten und Alt-Texte nicht vergessen werden. Das kostet nichts und beseitigt die häufigsten Fehler.
Bei Seiten, die jedes Mal individuell gestaltet werden, etwa Kampagnenseiten mit eigenem Aufbau, liegt der Aufwand nicht im Übertragen von Text, sondern in der Gestaltung. Eine Übergabe kann Text und Bausteine liefern, die eigentliche Arbeit bleibt im visuellen Editor. Der Nutzen ist hier kleiner.
Und wenn bei euch noch unklar ist, welche Fassung freigegeben ist und wer freigibt, löst eine Anbindung dieses Problem nicht. Sie macht es schneller sichtbar, was ein Gewinn sein kann, aber zuerst ist der Prozess dran.
Selbstcheck: Wie teuer ist eure letzte Meile?
Setzt Haken bei allem, was auf euch zutrifft.
kurze Einordnung zu unserer Veröffentlichung:
Zwischen Freigabe und Livegang liegen bei uns je Beitrag mehrere Handgriffe: Text übertragen, Formatierung reparieren, Bilder, Alt-Texte, Metadaten, Kategorien, interne Links. Das kostet geschätzt eine halbe bis eine Stunde pro Veröffentlichung und taucht in keiner Planung auf. Außerdem ist es die Stelle, an der freigegebene und veröffentlichte Fassung auseinanderlaufen können.
Inzwischen lassen sich Inhalte über einen offenen Standard namens MCP direkt aus der Arbeitsumgebung als Entwurf ins CMS übergeben, passend zur Struktur von WordPress, TYPO3, Contentful oder Storyblok. Veröffentlicht wird weiterhin von uns, nach Prüfung in der Vorschau.
Vorschlag: Wir erheben einen Monat lang den tatsächlichen Aufwand der letzten Meile und klären mit der IT, welche Rechte eine solche Anbindung bräuchte. Danach entscheiden wir auf Basis eigener Zahlen.
Fazit: Fertig ist ein Beitrag erst, wenn er richtig online ist
Die letzte Meile ist kein spektakuläres Problem. Sie ist eine Reihe kleiner Handgriffe, die niemand plant und niemand misst. Genau deshalb ist sie so teuer, und genau deshalb passieren dort die Fehler, die im Nachhinein am peinlichsten sind: die alte Fassung auf der Seite, die fehlenden Alt-Texte, die Korrektur, die beim nächsten Update wieder verschwindet.
Was sich verändert hat, ist die Technik. Mit MCP gibt es erstmals einen Weg, Inhalte strukturbewusst in verschiedene CMS zu übergeben, ohne für jedes System ein eigenes Integrationsprojekt aufzusetzen. Was sich nicht verändert hat, ist die Verantwortung. Die Entscheidung, was live geht, bleibt bei Menschen. Die Arbeit, die sie bisher davon abgehalten hat, sich auf diese Entscheidung zu konzentrieren, muss es nicht.
Häufige Fragen
Veröffentlicht die KI dann selbstständig auf unserer Website?
Nur wenn ihr ihr dieses Recht gebt, und davon ist abzuraten. Sinnvoll ist eine Anbindung, die Inhalte als Entwurf oder in einem Arbeitsbereich anlegt. Die Veröffentlichung erfolgt danach durch eine Person nach Prüfung in der Vorschau. Die meisten CMS trennen diese Rechte ohnehin über Rollen.
Brauchen wir dafür eine Agentur oder Entwicklung?
In der Regel nicht für die Anbindung selbst, wohl aber für die Klärung der Zielstruktur, wenn euer CMS stark individualisiert ist. Bei TYPO3 mit eigenen Inhaltselementen oder Contentful mit komplexen Content-Modellen lohnt eine kurze Abstimmung mit der Agentur, die das System gebaut hat. Bei WordPress und gut gepflegten Storyblok-Setups geht es meist ohne.
Was passiert mit unseren Page-Builder-Layouts?
Für redaktionelle Inhalte wie Fachartikel oder News legt ihr am besten eine schlanke Vorlage fest, in die übergeben wird. Aufwendig gestaltete Einzelseiten bleiben Arbeit im visuellen Editor. Eine Übergabe kann dort Texte und Bausteine liefern, ersetzt aber nicht die Gestaltung.
Ist MCP sicher?
MCP ist ein Protokoll, keine Sicherheitsgarantie. Sicher wird eine Anbindung durch die Rechte, die ihr vergebt, durch einen eigenen technischen Benutzer und durch Protokollierung. Wer diese drei Punkte vor der Einrichtung mit der IT klärt, hat die wichtigsten Fragen beantwortet.
Können wir mehrere CMS gleichzeitig anbinden?
Ja, und genau dort liegt der größte Nutzen. Ein Inhalt wird einmal erarbeitet und freigegeben und danach an verschiedene Zielsysteme übergeben, etwa als Fachartikel auf der TYPO3-Hauptseite und als Kurzfassung im WordPress-Blog. Jede Übergabe richtet sich nach der Struktur des jeweiligen Systems.
Was ist mit bestehenden Inhalten, die schon im CMS liegen?
Die Anbindung kann bestehende Inhalte lesen und als Vorlage für Aufbau und Tonalität nutzen. Ob ihr ältere Inhalte zusätzlich in die Arbeitsumgebung übernehmt, ist eine eigene Entscheidung. Für die Sichtung des Bestands hilft eine Content-Inventur, bevor ihr irgendetwas migriert.
Wie lässt sich euer Marketingalltag einfacher machen?
In 30 Minuten schauen wir gemeinsam darauf, wo euch heute unnötige Abstimmungen, manuelle Aufgaben, Toolwechsel oder wiederkehrende Content-Arbeit Zeit kosten.
Wenn die letzte Meile bei euch spürbar Zeit kostet, schauen wir uns euren Weg von der Freigabe bis zur veröffentlichten Seite an und klären, welche Handgriffe wegfallen könnten und was dafür im CMS vorbereitet sein muss.
Alles an eurem tatsächlichen Marketingalltag.
30 Minuten, um deinen Marketingalltag zu vereinfachen Kostenfrei. Du nimmst konkrete Ansatzpunkte mit, die ihr intern direkt weiterverwenden könnt.
Dennis Gumprich
Dennis begleitet Marketing- und Kommunikationsteams bei der Frage, wie generative KI in bestehende Content-Prozesse passt, ohne Qualität, Markensprache und Freigaben zu untergraben. Schwerpunkte: Content Operations, AI Governance und Toolauswahl in Mittelstand und Konzern.
Transparenzhinweis: Dennis arbeitet für contentbird, einen Anbieter von KI-gestützter Content-Software. Produkterwähnungen sind im Beitrag gekennzeichnet. Mehr über Dennis · LinkedIn
Weiterlesen
Entstehung dieses Beitrags
Dieser Beitrag ist unter Einsatz von KI entstanden. Struktur, Recherche und Formulierungsentwürfe wurden KI-gestützt erarbeitet. Fachliche Einordnung, Prüfung der Aussagen und die finale Fassung liegen bei Dennis Gumprich.
Zur Belastbarkeit der Aussagen
Die Aufwandswerte und die Beispielrechnung sind Arbeitsmodelle aus Gesprächen mit Content-Teams und keine erhobenen Messwerte. Die Beschreibung der vier CMS ist bewusst vereinfacht, die tatsächliche Struktur hängt stark von der jeweiligen Einrichtung ab.
