KI im Content Marketing

Die Bestandsaufnahme der Seite war vollständig. Zumindest schien es so. Bei der Überarbeitung einer Produktseite für einen internationalen Industriekunden hatte unser KI-gestützter Workflow jedes Element der Live-Seite erfasst, bewertet und in das Content-Deliverable übernommen. Mit einer Ausnahme: ein Abschnitt mit anstehenden Messeterminen. Im Browser war er für jede Besucherin sichtbar. In keinem der automatisch erstellten Seiteninventare tauchte er auf.
Solche Fälle haben uns in den vergangenen Monaten begleitet, seit wir unsere Briefing- und Content-Prozesse mit Claude systematisch automatisiert haben. Konkret geht es um zwei Stufen: das SEO-Briefing mit Live-Seiten-Audit, Keyword- und FAQ-Recherche, SERP-Analyse und Verlinkungsplan sowie das Content-Deliverable, das dieses Briefing Element für Element in konkrete Texte übersetzt. Beide Stufen enden in einem Dokument mit festem Aufbau, das an Kunden und Redaktionen geht.
Die verbreitete Darstellung von KI im Content Marketing lautet: Kontextdatei hochladen, Beispiele beilegen, Ergebnis abholen. Unsere Erfahrung ist eine andere. Die Qualität entsteht nicht durch das Hochladen, sondern durch die Regeln, nach denen das System arbeitet, und durch die Prüfung dessen, was es liefert. KI ersetzt die Expertise also nicht. Sie verlagert sie: weg von der wiederholten Ausführung, hin zur Gestaltung und Kontrolle des Prozesses.
Dieser Artikel beschreibt, welche Regeln das bei uns sind, welche Fehler zu ihnen geführt haben und was wir weiterhin bewusst selbst entscheiden.
 

Die Seite richtig erfassen: Warum der Live-Abruf Pflicht ist

Jedes SEO-Briefing und jedes Content-Deliverable beginnt bei uns mit dem Abruf der Live-Seite. Das ist kein optionaler Teil des Prompts, sondern ein fester erster Schritt im Workflow. Vorhandene Briefings, Sitemaps oder frühere Dokumente beschreiben einen Stand, der längst veraltet sein kann. Verlässlich ist nur die Seite, wie sie heute ausgeliefert wird.
Wie gut dieser Abruf funktioniert, hängt vom Aufbau der Website ab. Bei Seiten, die ihre Inhalte vollständig serverseitig ausliefern, erfasst ein einfacher Textabruf alles Relevante. Bei Seiten, die Inhalte erst im Browser nachladen, fehlen im Abruf ganze Abschnitte. Das hat auch eine Sichtbarkeitsdimension: Aktuell führen keine der gängigen KI-Crawler JavaScript aus. Serverseitiges Rendering gehört deshalb zu den Prüfpunkten unserer GEO-Beratung.

Was ein Textabruf nicht sieht

Der eingangs beschriebene Messe-Teaser hatte eine andere Ursache als JavaScript. Das Extraktionswerkzeug las ausschließlich den <main>-Bereich der Seite aus. Das ist bei vielen Tools üblich, um Navigation und Footer herauszufiltern. Der Teaser war jedoch eine globale Komponente, die zentral im CMS gepflegt und außerhalb dieses Bereichs ausgegeben wird. Für jeden Abruf, der sich auf <main> beschränkt, existierte er schlicht nicht.

Das Problematische daran: Das Modell meldet eine solche Lücke nicht. Es arbeitet mit dem, was es erhält, und liefert ein in sich stimmiges, aber unvollständiges Inventar. Unsere Regel lautet seitdem: Jede Bestandsaufnahme besteht aus zwei Teilen, der Textextraktion und einer visuellen Prüfung der gesamten Seite im Browser. Erst wenn beide übereinstimmen, gilt das Inventar als vollständig.

Fehlend heißt nicht: nicht vorhanden

Eine zweite Regel ergänzt die erste. Wenn das Briefing ein Element erwähnt, das im Abruf nicht auftaucht, darf der Workflow es nicht stillschweigend übergehen. Stattdessen landet es als offener Punkt im Dokument, mit dem Hinweis, dass eine manuelle Prüfung nötig ist. So wird aus einer technischen Einschränkung eine zu klärende Frage statt eines unbemerkten Fehlers.

Nichts verlieren: Jedes Element bekommt einen Status

Die häufigste Schwachstelle bei KI-gestützten Überarbeitungen ist nicht falscher Text, sondern fehlender. Ein Sprachmodell, das eine Seite „verbessern“ soll, lässt Inhalte weg, fasst Abschnitte zusammen oder verschiebt Aussagen, ohne das zu kennzeichnen. Deshalb vergibt unser Workflow für jedes Element der Seite einen expliziten Status:

• BEHALTEN: Das Element bleibt unverändert.
• ÄNDERN: Der Text wird überarbeitet, alte und neue Fassung stehen nebeneinander.
• ENTFERNEN: Das Element entfällt, mit Begründung.
• NEU: Das Element kommt hinzu.
• ZUSAMMENFÜHREN: Mehrere Elemente werden zu einem kombiniert.
• UMSORTIEREN: Das Element wandert an eine andere Position.

Der Nutzen liegt in der Vollständigkeit: Kein Element der Live-Seite kann verschwinden, ohne dass es im Dokument als ENTFERNEN auftaucht. Ändert sich die Reihenfolge der Seite grundlegend, stellt das Dokument der Tabelle außerdem eine Übersicht voran, welcher Abschnitt von wo nach wo wandert. Leserinnen und Leser sollen die neue Struktur auf einen Blick erfassen, nicht erst beim Durcharbeiten der Tabelle.

Kürzen mit Nachweis

Wenn ein bestehender Text gekürzt wird, prüft der Workflow, ob jede ursprüngliche Aussage an anderer Stelle der Seite erhalten bleibt. Diese Prüfung wird dokumentiert. Hinzu kommt ein Abgleich über die gesamte Seite: Behandeln zwei Abschnitte dieselbe Aussage, oder beantwortet eine Zwischenüberschrift in Frageform dieselbe Frage wie ein FAQ-Eintrag, wird das markiert und aufgelöst. Jedes Thema erscheint auf einer Seite nur einmal.

Nach dem Go-live: Briefing gegen Live-Seite

Ein gutes Deliverable garantiert keine gute Umsetzung. Das zeigte ein Abgleich, den wir nach der Veröffentlichung einer überarbeiteten Seite durchgeführt haben. Der empfohlene primäre Call-to-Action war nicht umgesetzt worden. Gleichzeitig waren Elemente hinzugekommen, die im Briefing nicht vorgesehen waren.
Seitdem ist der Abgleich nach dem Go-live ein fester Bestandteil des Prozesses. Er prüft drei Dinge: welche Vorgaben nicht umgesetzt wurden, was ohne Vorgabe hinzugekommen ist und wo die Umsetzung vom Briefing abweicht. Weil das Dokument für jedes Element alten und neuen Stand festhält, lässt sich dieser Abgleich systematisch statt stichprobenartig durchführen.

Das System lernen lassen

Ein KI-Workflow ist nur so gut wie die Korrekturen, die in ihn zurückfließen. Der wichtigste Unterschied zwischen einmaligem Prompting und einem belastbaren Prozess liegt darin, wo eine Korrektur landet.

Die Regel korrigieren, nicht nur das Ergebnis

Jede Anmerkung aus einem Review beantworten wir mit zwei Fragen: Was ändert sich in diesem Dokument, und welche Regel verhindert, dass derselbe Fehler beim nächsten Mal wieder auftritt? Die zweite Antwort wird Teil des Workflows. Einige Regeln, die auf diesem Weg entstanden sind:

• Ein Abschnitt ohne Keyword-Bezug ist nicht automatisch ohne Optimierungsbedarf. Inhaltliche Qualität wird unabhängig von der Keyword-Abdeckung bewertet.
• Elemente, deren Ausgestaltung vom Kunden abhängt, etwa Vertrauenselemente im Kopfbereich oder die Formulierung von Buttons, werden aktiv abgefragt statt angenommen.

So sammelt der Skill über die Zeit das Urteilsvermögen des Teams. Er wird nicht dadurch besser, dass das Modell sich verbessert, sondern dadurch, dass wir unsere Anforderungen präziser formulieren.

Eine Architektur, die Änderungen aushält

Kundenanforderungen ändern sich, und ein Workflow muss das abbilden können, ohne neu gebaut zu werden. Wir trennen deshalb konsequent: Markenkontext, Tonalität, die Komponentenbibliothek des CMS und die Regeln für einzelne Seitentypen liegen jeweils in eigenen Referenzdateien. Die Skripte, die daraus das fertige Dokument erzeugen, enthalten keine inhaltlichen Annahmen, sondern verarbeiten nur Daten.
Wie sich das auszahlt, zeigte eine Strukturänderung bei einem Kunden: Downloads wurden in die Produktseite integriert, Produktvarianten wanderten auf eigene Unterseiten. Angepasst werden mussten nur die Referenzdateien zu den Seitentypen. Die Skripte blieben unverändert. Gleichzeitig sorgt die feste Vorlage dafür, dass jedes Dokument denselben Aufbau hat. Pflichtfelder, die nicht befüllt werden konnten, erscheinen automatisch in der Liste offener Punkte.

Interne KI-Kommentare gehören nicht ins Briefing

Briefing und Textentwurf richten sich an Texter, Redaktion und Kunden, die den Workflow dahinter nicht kennen. Die KI neigt jedoch dazu, ihre Arbeitsweise im Dokument zu kommentieren, etwa mit kurzen Anmerkungen neben einzelnen Abschnitten, die auf interne Regeln oder Statusbegriffe verweisen und für Außenstehende nicht verständlich sind. Im Dokument bleiben deshalb nur Hinweise, die der empfangenden Person beim nächsten Arbeitsschritt helfen, klar vom Seitentext getrennt: Statt „Gemäß Regel zu Bildabschnitten als inhaltliche Lücke gewertet“ steht dort „Dieser Abschnitt enthält bisher nur ein Bild. Bitte zwei bis drei Sätze ergänzen, die erklären, was das Bild zeigt.“

Claude Projects oder Skills: Wie wir entscheiden, was wohin gehört

Begonnen haben wir mit Claude Projects. Ein Project bündelt einen Systemprompt mit Wissensdateien: Kontextdokument, Styleguide, Markenleitfaden, URL-Liste und Beispiel-Briefings. Für den Start ist das ideal, denn der gesamte Kundenkontext liegt an einem Ort.
Mit wachsenden Workflows zeigten sich die Grenzen. Der Systemprompt entwickelte sich zu einem umfangreichen Regelwerk. Das Ausgabeformat ließ sich nur mit eigenem Code zuverlässig reproduzieren. Und dieselbe Prozesslogik existierte für jeden Kunden ein weiteres Mal. Skills lösen diese Punkte: Sie bündeln Anweisungen, Referenzdateien und Skripte in einem Paket, das Claude lädt, sobald eine Anfrage dazu passt. Eine Korrektur wird an einer Stelle vorgenommen und gilt für jeden folgenden Durchlauf.
Projects haben damit nicht ausgedient. Wir nutzen beides, mit einer klaren Aufteilung: Projects enthalten, was wir über einen Kunden wissen. Skills enthalten, wie wir arbeiten.

Wann ein Workflow zum Skill wird

Ein Workflow ist reif für die Überführung in einen Skill, wenn mehrere dieser Bedingungen zutreffen:

• Der Ablauf ist stabil. Es werden Details justiert, nicht mehr die Schritte selbst.
• Das Ergebnis muss bei jedem Durchlauf denselben Aufbau haben.
• Mehr als eine Person führt den Workflow aus.
• Die Logik lässt sich auf weitere Kunden übertragen.

Im Project bleibt, was explorativ ist, was sich inhaltlich noch stark verändert oder was als einmalige Analyse vom Gesprächsverlauf lebt, zum Beispiel ein Redaktionsplan.

Was bei der Überführung zu beachten ist

• Statische Regeln und veränderliche Daten trennen: Alles, was in einem Skill gebündelt ist, ist eine Momentaufnahme. Regeln, Vorlagen und Skripte gehören hinein. Daten, die sich ändern, etwa URL-Listen für den Kannibalisierungs-Check, Keyword-Sets oder Kundenentscheidungen, veralten dort unbemerkt.
• Verbindungen zu Tools einplanen: Ein Skill, der Daten aus SEO-Tools abruft, funktioniert nur bei Kolleginnen und Kollegen, die diese Verbindungen selbst eingerichtet haben. Die Einführung eines Skills im Team umfasst deshalb auch die Einrichtung der Tools dahinter.
• Auslösebedingungen abgrenzen: Skills werden anhand ihrer Beschreibung ausgewählt. Mit wachsender Zahl entstehen Überschneidungen, etwa zwischen Briefing-Varianten für unterschiedliche Seitentypen. Jede Beschreibung braucht daher einen klaren Trigger, wann der Skill aufgerufen werden soll.
• Verantwortung und Versionen festlegen: Jeder Skill braucht eine verantwortliche Person, eine nachvollziehbare Versionierung und einen Testlauf, bevor eine Änderung für alle gilt. Ebenso wichtig ist ein klarer Weg für Korrekturen aus dem Team, damit sie in der Regel landen und nicht nur im einzelnen Dokument.
• Nutzerinnen und Nutzer einweisen: Wer einen Skill verwendet, muss wissen, welche Eingaben er erwartet und dass die ersten Durchläufe eine genauere Prüfung verdienen.

Prozesse so zu verankern, dass sie im ganzen Team funktionieren, ist dieselbe Aufgabe, die wir auch in der Beratung zu SEO-Prozessen und Change Management für Kunden übernehmen.

Was wir noch verbessern

Der erste Punkt der Liste ist bei uns noch nicht vollständig umgesetzt. Ein Teil der veränderlichen Daten liegt weiterhin direkt in Skills und Projects. Das Ziel ist eine gemeinsame Datenquelle, aus der die Skills zur Laufzeit lesen, statt mit Kopien zu arbeiten, die gepflegt werden müssen. Wir beschreiben diesen Punkt bewusst als offene Aufgabe: Auch ein automatisierter Prozess ist nie abgeschlossen.

Was bewusst beim Menschen bleibt

Automatisierung bedeutet bei uns nicht, dass niemand mehr entscheidet. Einige Schritte haben wir gezielt von der Automatisierung ausgenommen, weil sie Urteilsvermögen, Branchenwissen oder Kundenkenntnis erfordern:

• Proofterms: Die SEO-relevanten Begriffe, die ein Text zwingend enthalten muss, definiert die zuständige Beraterin oder der zuständige Berater. Das System schlägt sie nicht vor.
• Wettbewerbsauswahl: Welche Seiten als relevante Konkurrenz gelten, entscheidet ein Mensch. Das System analysiert anschließend die ausgewählten Seiten im Detail.
• Keywords: Das System schlägt auf Basis von Tool-Daten Keywords vor, die Auswahl wird gemeinsam getroffen.
• SERP-Bewertung: Welche Suchintention hinter einem Keyword steht und welches Content-Format die Ergebnisseite belohnt, bewerten wir selbst.
• Abnahme: Jedes Briefing und jedes Deliverable wird vor der Weitergabe geprüft.

Diese Aufteilung ist keine Übergangslösung, bis die Technik weit genug ist. Sie folgt aus der Frage, wo Fehler am teuersten sind. Ein falsch gewählter Wettbewerber oder eine falsch eingeschätzte Suchintention verzerrt das gesamte Briefing, und alle folgenden Schritte übernehmen diesen Fehler.
 

Fazit: Konsistenz statt Abkürzung

Der Einsatz von KI im Content Marketing hat unsere Arbeit verändert, aber anders als oft dargestellt. Das Ergebnis sind Briefings und Deliverables, die bei jedem Durchlauf denselben Aufbau haben, weniger übersehene Elemente und eine Dokumentation, die sich nach dem Go-live überprüfen lässt. Die Arbeit ist nicht weniger geworden. Sie hat sich verlagert: in die Formulierung von Regeln, in die Prüfung der Ergebnisse und in die Content-Strategie, für die nun mehr Zeit bleibt.
Wer einen ähnlichen Prozess aufbauen möchte, sollte mit einem einzigen, gut verstandenen Workflow beginnen, jede Korrektur als Regel festhalten und von Anfang an klären, welche Entscheidungen beim Menschen bleiben. Die Werkzeuge entwickeln sich schnell. Die Prinzipien dahinter bleiben stabil.

Wenn Sie Ihre Redaktion auf die Zusammenarbeit mit KI vorbereiten möchten, bietet unser Redaktionsworkshop zu SEO und Content dafür einen praxisnahen Einstieg. Für Fragen zu Ihrem konkreten Setup können Sie gern Kontakt mit uns aufnehmen.
 

Häufige Fragen

Bewertet Google KI-gestützte Inhalte schlechter?

Nein, sofern die Inhalte hilfreich sind. Google hat in seiner Stellungnahme zu KI-generierten Inhalten klargestellt, dass die Qualität eines Inhalts entscheidet, nicht die Art seiner Entstehung. Maßstab bleiben Expertise, Erfahrung, Autorität und Vertrauenswürdigkeit (E-E-A-T). Inhalte, die vorrangig zur Manipulation von Rankings erstellt werden, gelten dagegen als Spam, unabhängig davon, ob ein Mensch oder eine KI sie verfasst hat.

Mit welchen Tools arbeitet der Workflow?

Die Grundlage ist Claude. Über Schnittstellen (MCPs) greift der Workflow auf SEO-Tools wie Ahrefs, SISTRIX und Screaming Frog zu, etwa für Suchvolumen, FAQ-Recherche und Crawling-Daten. Für die visuelle Prüfung von Live-Seiten kommt eine Browser-Integration zum Einsatz. Die fertigen Dokumente erzeugt ein Skript in einem festen Format.

Sind für den Aufbau Programmierkenntnisse nötig?

Nicht zwingend. Die Skripte, die unsere Dokumente erzeugen, haben wir gemeinsam mit Claude entwickelt. Hilfreich ist jedoch ein Grundverständnis dafür, wie Dateien, Vorlagen und Daten zusammenspielen. Ohne dieses Verständnis lassen sich Fehler schwer eingrenzen, und die Trennung von Regeln und Daten gelingt selten auf Anhieb.