Vor dem Veröffentlichen mit Claude Code prüfen: keine verlorenen Conversions mehr

An einem Morgen öffnete ich die Statistik und erstarrte. Der Artikel vom Vortag hatte dreimal so viele Zugriffe wie sonst. Trotzdem: null Anmeldungen für das kostenlose PDF, null Klicks auf das Lernmaterial. Der Beitrag ging durch die Decke und es bewegte sich kein einziger Euro.

Die Ursache war erschreckend banal. Der Anmelde-Button am Artikelende zeigte noch auf eine Produktseite, die ich ein halbes Jahr vorher abgeschaltet hatte. Und in der englischen Version kippte der Fließtext mittendrin ins Englische, sodass die internationalen Leser genau dort absprangen. Der Text selbst war gut geschrieben, aber die letzten paar Zeilen ließen alles auslaufen.

Seitdem trenne ich strikt zwischen “den Artikel schreiben” und “prüfen, ob er überhaupt veröffentlichungsreif ist”. Wenn ich Letzteres jedes Mal von Hand mache, drücke ich mich garantiert davor. Also habe ich es Claude Code als festes Muster gegeben. Heute lege ich den kompletten Ablauf offen, zum Kopieren und Einfügen.

Das Wichtigste in Kürze

• Wenn die Zugriffe steigen, die Anmeldungen aber nicht, liegt es meist an Fehlern, die du vor dem Publish hättest sehen können: tote Links, alte Produktseiten, englischer Text in der falschen Sprachversion.
• Lege neun Prüfpunkte fest und gehe sie jedes Mal in derselben Reihenfolge durch. Allein das reduziert verlorene Conversions drastisch.
• Claude Code übernimmt das Mechanische: die Seite öffnen und die Punkte stur abhaken. Welcher Button der Star sein soll, entscheidest du.
• Beschränke dich auf einen einzigen Anmelde-Button pro Artikel. Der Leser muss dann nicht wählen und handelt eher.
• Halte das Ergebnis jeder Prüfung in einem Log fest. So kannst du später nachvollziehen, auf welcher Grundlage du veröffentlicht hast.

Lege neun Prüfpunkte fest

Mit “prüf das mal ordentlich” tut weder ein Mensch noch eine KI irgendetwas. Prüfen heißt: eine Liste konkreter Punkte. Das sind die neun, die bei mir fest stehen.

#	Prüfpunkt	Worauf du achtest
1	Seite lädt	Antwortet der Server mit 200 (kein 404 oder 500)?
2	Überschrift korrekt	Stimmt die große Überschrift oben mit dem Artikeltitel überein?
3	Canonical-URL	Zeigt die kanonische URL auf den Artikel selbst?
4	Hero-Bild	Wird das Bild angezeigt (kein altes Bild, kein fehlendes Bild)?
5	Sprache des Texts	Ist jede Sprachversion ab der ersten Zeile in dieser Sprache geschrieben?
6	Hinweis aufs PDF	Existiert der Anmelde-Button und lebt das Ziel der Verlinkung?
7	Material-Link	Führt der Link zur beabsichtigten Produktseite (nicht zum falschen Produkt)?
8	Weg zur Beratung	Zeigt der Link tatsächlich auf die Beratungsseite?
9	Mobile Ansicht	Gibt es horizontales Scrollen (ragt etwas über den Rand)?

Entscheidend sind Punkt 3 und 7. Wenn die kanonische URL auf die Startseite oder einen anderen Artikel zeigt, wertet die Suchmaschine jene Seite als Original, und dein eigentlicher Artikel bekommt keine Anerkennung. Vertauschte Link-Ziele passieren besonders oft bei Artikeln, die per Copy-Paste entstanden sind.

Was die KI übernimmt und was du entscheidest

Wenn du das vermischst, baust du Unfälle. Also ziehe ich eine klare Linie.

Claude Code übernimmt alles, was sich mechanisch beurteilen lässt: die Seite öffnen, die Überschrift auslesen, das Link-Ziel abrufen, prüfen, ob das Bild angezeigt wird, das Layout in Mobilbreite kontrollieren. Das ist mühsam, wenn ein Mensch es macht, und weil es mühsam ist, lässt man es weg. Also macht die KI das jedes Mal.

Du entscheidest alles, was ein Urteil verlangt. Welcher Button in diesem Artikel der Star ist. Ob die Formulierungen natürlich klingen. Ob versehentlich ein altes Produkt verlinkt wird. Und die letzte Frage: “Darf dieser Artikel wirklich raus?” Wirfst du das der KI hin, erscheint ein Artikel, dessen Links zwar leben, dessen Inhalt aber daneben liegt.

Die Faustregel im Zweifel ist simpel: Was eindeutig bestimmbar ist, macht die KI; was mit Geschmack oder Strategie zu tun hat, der Mensch. Ob ein Link 200 zurückgibt, ist eindeutig, also KI. Welchen von drei Buttons du hervorhebst, ist Strategie, also Mensch.

Das fertige Prompt zum Kopieren

Diesen Text kannst du direkt in Claude Code einfügen. Ersetze nur Repository-Name und die zu prüfenden URLs durch deine eigenen.

Führe für jede der folgenden URLs einen Pre-Publish-Check aus.
Prüfe: dass die Seite mit 200 lädt, dass die große Überschrift mit dem
Artikeltitel übereinstimmt, dass die kanonische URL auf denselben Artikel
zeigt, dass das Hero-Bild angezeigt wird, dass der Text in der jeweiligen
Sprache verfasst ist, dass der Anmelde-Button fürs kostenlose PDF lebt,
dass der Material-Link zur beabsichtigten Produktseite führt, dass der
Link zur Beratungsseite korrekt ist und dass es in Mobilbreite kein
horizontales Scrollen gibt.

Berichte pro URL in einer Zeile, getrennt nach bestandenen und
durchgefallenen Punkten. Werte nicht schon "lädt mit 200" als bestanden.
Bei durchgefallenen Punkten nenne auch die vermutete Ursache und welche
Datei zu korrigieren ist.

Die letzten beiden Sätze sind der Kern. Hörst du bei “lädt mit 200 = OK” auf, übersiehst du genau den häufigsten Fehler: das vertauschte Link-Ziel. Lass durchgefallene Punkte immer getrennt berichten und die zu korrigierende Stelle gleich mitnennen, dann kannst du direkt mit der Reparatur weitermachen.

Das lauffähige Bewertungs-Skript

Den Teil, der die Ergebnisse zusammenfasst und mechanisch “darf raus oder nicht” zurückgibt, packe ich in Code. Dann schwankt es nicht von Mal zu Mal. Hier die Minimalversion für Node.js.

// Die neun Punkte, die vor dem Publish bestanden sein müssen
const requiredChecks = [
  "Seite lädt mit 200",
  "Große Überschrift stimmt mit Artikeltitel überein",
  "Kanonische URL zeigt auf denselben Artikel",
  "Hero-Bild wird angezeigt",
  "Text ist in der jeweiligen Sprache verfasst",
  "Anmelde-Button fürs kostenlose PDF lebt",
  "Material-Link führt zur beabsichtigten Produktseite",
  "Link zur Beratungsseite ist korrekt",
  "Kein horizontales Scrollen in Mobilbreite",
];

// "passed" enthält die Namen der bestandenen Punkte
function summarizeSmokeResult(passed) {
  const missing = requiredChecks.filter((check) => !passed.includes(check));
  return {
    ok: missing.length === 0,
    missing,
    nextAction: missing.length === 0 ? "Darf veröffentlicht werden" : "Erst korrigieren, dann erneut prüfen",
  };
}

// Beispiel: nur der Material-Link ist durchgefallen
const passed = requiredChecks.filter((c) => c !== "Material-Link führt zur beabsichtigten Produktseite");
const result = summarizeSmokeResult(passed);

console.log(result.ok ? "Publish OK" : "Publish NICHT OK");
console.log("Durchgefallen:", result.missing);
console.log("Nächster Schritt:", result.nextAction);

Lässt du das Skript laufen, erscheinen Publish NICHT OK, die Namen der durchgefallenen Punkte und der nächste Schritt. Fehlt auch nur ein Punkt, wird ok auf false gesetzt, sodass kein “passt schon ungefähr”-Publish durchrutscht. Du füllst das passed-Array einfach mit dem Ergebnis, das die KI über das obige Prompt geliefert hat.

Drei Situationen, in denen es wirklich half

1. Tage, an denen ich mehrere Artikel veröffentliche An Tagen, an denen drei Beiträge auf einmal rausgehen, wird die Prüfung schnell schlampig. Ich öffne jeden Artikel einzeln in Mobilbreite und scrolle bis Überschrift, Textanfang und in die Nähe des Anmelde-Buttons. Steht in einer nicht-englischen Version der Text noch auf Englisch, stoppe ich an dieser Stelle die Veröffentlichung. Gerade an hektischen Tagen wirkt die feste Liste.

2. Wenn ich nur den Button eines beliebten Artikels austausche Selbst wenn ich nur den End-Button eines viel gelesenen Artikels ändere, ist “such die zugehörigen Teile und reparier sie” viel zu weit gefasst. Vorher lege ich fest: welche Dateien angefasst werden dürfen, welche nicht, welche URLs zu prüfen sind und wohin jeder Link führen soll. Allein dadurch wird aus “fühlt sich gut an” ein “mit diesem Beweis kann ich veröffentlichen”.

3. Qualitätsprüfung mehrsprachiger Artikel Selbst wenn die Sprachangabe in den Einstellungen korrekt ist, ist ein Artikel nicht veröffentlichungsreif, solange der Fließtext auf Englisch stehen bleibt. Ich prüfe in jeder Sprache Überschrift, Textanfang und Button-Umgebung darauf, ob ein Leser dieser Sprache versteht, was er als Nächstes tun soll. Für deutsche Leser müssen die PDF-Erklärung, der Hinweis aufs Material und der Weg zur Beratung auf natürlichem Deutsch lesbar sein.

Typische Stolperfallen und wie du sie behebst

Stolperfalle 1: “fertig” melden, nur weil der lokale Build durchlief Ein erfolgreicher Build auf deinem Rechner garantiert nicht, dass die veröffentlichte Seite korrekt angezeigt wird. Die Lösung: prüfe nicht das “lokale Build-Ergebnis”, sondern das “echte Stück unter der öffentlichen URL”. Sag das auch der KI ausdrücklich: “Öffne die öffentliche URL und prüf dort.”

Stolperfalle 2: alle Anmelde-Buttons nebeneinander stellen Wenn PDF, Material A, Material B und Beratung gleich groß nebeneinander stehen, weiß der Leser nicht, was er drücken soll, und drückt am Ende gar nichts. Die Lösung: lege pro Artikel einen Star-Button fest und schiebe den Rest in dezente Nebenrollen.

Stolperfalle 3: der Link führt zum falschen Produkt “Kostenloses PDF” steht da, aber der Klick landet beim kostenpflichtigen Material — das passiert bei Copy-Paste-Artikeln dauernd. Die Lösung: lass die KI das Link-Ziel aus Prüfpunkt 7 immer abrufen und gleiche die Produkt-ID per Augenschein ab.

Stolperfalle 4: groß umbauen, ohne den Rückweg zu kennen Das Schlimmste ist, kurz vor dem Publish großflächig umzuschreiben und bei einem Fehler nicht mehr zurückzukönnen. Die Lösung: beschränke einen Arbeitsgang auf den Umfang, für den du vorab einen “falls es komisch wird, mach ich es so rückgängig”-Schritt bereithalten kannst. Eine Aufgabe, deren Rückweg du nicht aufschreiben kannst, ist für diesen Durchlauf zu groß.

Häufige Fragen

F. Die Zugriffe steigen, die Anmeldungen nicht. Was schaue ich zuerst an? A. Zuerst das Link-Ziel des Anmelde-Buttons und die Sprache des Texts. Die zwei häufigsten Ursachen: das Link-Ziel zeigt noch auf eine alte Produktseite, oder die Version für internationale Leser ist nicht lokalisiert. Das entspricht den Prüfpunkten 5, 6 und 7.

F. Muss ich das wirklich jedes Mal prüfen? Das nervt. A. Ja, jedes Mal. Genau deshalb machst du es nicht von Hand, sondern gibst das Prompt aus diesem Artikel an Claude Code und lässt es mechanisch erledigen. Lästige Prüfungen lässt der Mensch an hektischen Tagen weg. Und ausgerechnet an diesen Tagen passiert der Unfall.

F. Wenn ich auf einen Button reduziere, schrumpfen dann nicht die Eingänge zu anderen Produkten? A. Wichtiger als die Zahl der Eingänge ist, dass der Leser ohne Zögern einen drücken kann. Mehrere nebeneinander führen dazu, dass er sich nicht entscheidet und abspringt. Lege einen Star fest und setze ein bis zwei Hilfslinks natürlich in den Fließtext — das ist die richtige Balance.

F. Warum ist die kanonische URL so wichtig? A. Suchmaschinen werten die als canonical angegebene Seite als das “Original”. Zeigt sie auf einen anderen Artikel oder die Startseite, wird nicht dein geschriebener Artikel bewertet, sondern jene andere Seite, und das Ranking sammelt sich dort.

F. Wofür hebe ich das Prüf-Log auf? A. Um später nachvollziehen zu können, auf welcher Grundlage du veröffentlicht hast. Tritt ein Problem auf, kannst du leichter eingrenzen, ob es an Text, Button, Link oder Beratungsweg lag. Ohne Log musst du beim nächsten Mal bei null neu prüfen.

Halte das Geprüfte auf einer Seite fest

Eine kurze Notiz nach dem Publish macht die nächste Prüfung schlagartig leichter. Eine Form wie diese reicht völlig.

- Artikel: claude-code-revenue-smoke-test
- Veröffentlicht: 2026-06-14
- Geprüfte Belege: öffentliche URL, große Überschrift, Canonical-Angabe, Hero-Bild, Sprache des Texts, Link-Ziele der Buttons
- Star-Button: Material-Link (für Leser, die selbstständig vorangehen)
- Als Nächstes beobachten: Zugriffe, PDF-Anmeldungen, Material-Klicks, Übergänge zur Beratungsseite

Auch bei den Zahlen urteile ich nicht allein nach Zugriffen. Ich stelle Anmeldungen fürs kostenlose PDF, Material-Klicks und Übergänge zur Beratungsseite mit demselben Datum nebeneinander. Bei einem Einsteiger-Artikel sollten die PDF-Anmeldungen steigen, bei einem Artikel über Einstellungen und Berechtigungen die Material-Klicks — diese Hypothese gleiche ich mit den Zahlen ab. Mit dieser Gewohnheit wird aus dem täglichen Posten kein bloßes “Rausschicken”, sondern ein Mechanismus, der die Conversion-Pfade Stück für Stück verbessert.

Diese Linie zwischen “der Maschine überlassene Prüfung” und “vom Menschen getroffenem Urteil” gilt nicht nur beim Revenue-Check. Den Gesamtüberblick, wie Nicht-Techniker Claude Code nutzen, findest du in Claude Code für Nicht-Techniker, und kleine Kniffe, die deine tägliche Arbeit beschleunigen, in Claude Code Produktivitäts-Tipps. Damit du die Prüfung sauber an die KI delegierst, brauchst du präzise Prompts — dazu passt Fortgeschrittene Prompt-Techniken für Claude Code.

Übrigens kannst du die Grundlagen dafür, dass die KI Dateien liest und Links prüft, in den offiziellen Claude Docs nachschlagen. Wenn dir ein Verhalten verändert vorkommt, ist der Blick in die Primärquelle am Ende der schnellste Weg.

Was beim Selbsttest herauskam

Dieses Muster habe ich rund zwei Wochen auf meiner eigenen Seite laufen lassen. Ich wollte prüfen, ob die Neun-Punkte-Kontrolle vor dem Publish wirklich verlorene Conversions verringert.

Das Ergebnis: Probleme, die in der Zeit, als ich nur auf “Seite lädt mit 200” geachtet hatte, glatt durchgerutscht wären, wurden gleich mehrfach gefunden. Konkret zweimal der Fall, dass ich das Hero-Bild eines anderen Artikels mitschleppte, einmal ein Anmelde-Button, der auf ein altes Produkt zeigte, und einmal eine englische Version, deren Text ab der Mitte auf Deutsch stehen blieb. Alle wären unter “lädt mit 200” als bestanden durchgegangen.

Besonders gewirkt hat die Regel, pro Artikel auf einen Anmelde-Button zu reduzieren. Bei einem Artikel, in dem PDF, Material und Beratung gleich schwer nebeneinanderstanden, habe ich auf einen Star aufgeräumt — und die Klickrate des Buttons stieg sichtbar. Dass Leser eher handeln, wenn es weniger Optionen gibt, habe ich an den Zahlen gespürt.

Umgekehrt wurde klar: Von Hand hält man diese Prüfung nicht durch. Die ersten Tage machte ich es manuell und ließ es an einem hektischen Tag prompt ausfallen. Erst als ich es in Form von Prompt und Skript jedes Mal nach demselben Ablauf laufen ließ, setzte es sich endlich fest.

Die unscheinbare Prüfung vor dem Publish zu einem Mechanismus zu machen — das war die billigste Versicherung, um Zugriffe in Umsatz zu verwandeln. Wenn du das in den Blog-Betrieb deiner Firma oder den Publishing-Flow deines Teams einbauen willst, gestalten wir in der Schulung und Beratung gemeinsam ein Muster, das zu deinem echten Betrieb passt.