Claude-Code-Verifikationsbeleg: Build, öffentliche URL, CTA und Screenshots prüfen

Warum ein Verifikationsbeleg nötig ist

Claude Code kann Artikel, Produktseiten und Links sehr schnell ändern. Das Risiko liegt nicht darin, dass Dateien geändert werden. Riskant ist der Moment, in dem ein plausibler Diff wie ein fertiger Release wirkt. Für öffentliche Inhalte mit PDF-Download, Gumroad-Produkt oder Beratungsanfrage reicht ein lokaler Build nicht aus. Die öffentliche URL kann noch alt sein, der CTA kann auf das falsche Produkt zeigen, und eine übersetzte Schaltfläche kann auf dem Smartphone umbrechen.

Ein Verifikationsbeleg ist eine kurze Beweisnotiz. Er hält fest, welche Dateien geändert wurden, warum sie geändert wurden, welcher Befehl lief, welche öffentliche URL geöffnet wurde, welcher CTA geprüft wurde, welche Screenshots vorliegen und welches Restrisiko bleibt. Das ist keine Bürokratie. Es ist der kleinste Arbeitsnachweis, mit dem die nächste Session nicht aus Erinnerung rekonstruieren muss, was wirklich geprüft wurde.

Der Ablauf passt gut zur Build-Fehler-Triage, zur Review-Workflow-Checkliste und zum Permission-Audit. Die erste hilft bei fehlschlagenden Befehlen, die zweite bei breiten Änderungen, die dritte bei zu großen Agentenrechten.

Vorlage für den Verifikationsbeleg

Kopieren Sie diese Vorlage in einen PR-Kommentar, eine Release-Notiz oder den letzten Prompt an Claude Code. Wichtig ist, Beobachtungen zu schreiben, nicht Stimmungen. “Sieht gut aus” ist kein Beweis. “npm.cmd run build war erfolgreich”, “die öffentliche Seite enthält das erwartete h1” und “der CTA öffnet Gumroad” sind Beweise.

Verification Receipt

Scope:
- changed files:
- user-facing behavior:
- out of scope:

Diff summary:
- what changed:
- why it changed:
- what should not change:

Proof commands:
- git status --short:
- git diff --stat:
- npm.cmd run build:

Public URL checks:
- article URL:
- expected h1:
- canonical:
- no fallback page:

Revenue and CTA checks:
- free PDF CTA:
- Gumroad product link:
- consultation link:
- thanks page or next step:

Screenshot checks:
- desktop screenshot:
- mobile screenshot:
- visible CTA:
- text overflow or broken layout:

Remaining risk:
- risk 1:
- risk 2:
- risk 3:

Die Zeile “out of scope” verhindert, dass eine Artikelverbesserung nebenbei zur Navigation-, Paket- oder Layoutänderung wird. Die Zeile “what should not change” schützt slug, canonical, Autor, Veröffentlichungsdatum, Produktlinks und Beratungspfad. Diese Dinge sind im sichtbaren Text schnell übersehen, haben aber große Wirkung.

Konkretes Beispiel: Build, URL, CTA und Screenshots

Beginnen Sie lokal. Prüfen Sie, ob nur die erwarteten Dateien geändert wurden, betrachten Sie die Diff-Größe und führen Sie dann den Build aus. Unter Windows ist npm.cmd oft die robustere Schreibweise.

git status --short
git diff --stat
cd site
npm.cmd run build

Danach kommt die öffentliche URL. HTTP 200 reicht nicht. Eine Fallback-Seite kann ebenfalls 200 liefern. Suchen Sie nach seitenspezifischen Zeichenketten: h1, eine eindeutige Passage aus dem Artikel und Begriffe aus CTA oder Produktpfad.

const checks = [
  {
    url: "https://claudecode-lab.com/de/blog/claude-code-verification-receipt-workflow/",
    mustInclude: ["Claude-Code-Verifikationsbeleg", "Vorlage", "Gumroad"],
  },
  {
    url: "https://claudecode-lab.com/en/products/",
    mustInclude: ["Claude Code", "Products"],
  },
  {
    url: "https://claudecode-lab.com/de/training/",
    mustInclude: ["Beratung"],
  },
];

for (const check of checks) {
  const res = await fetch(check.url, { redirect: "follow" });
  const html = await res.text();
  const missing = check.mustInclude.filter((text) => !html.includes(text));
  console.log(check.url, res.status, missing.length === 0 ? "ok" : `missing: ${missing.join(", ")}`);
}

Zum Schluss folgt die visuelle Prüfung. Text kann vorhanden sein, obwohl ein Button zu lang ist, ein Codeblock die Seite verbreitert oder der letzte CTA auf Mobile nicht mehr gut lesbar ist. Mit Playwright lassen sich Desktop und Mobile als Beleg speichern.

import { chromium } from "playwright";
import { mkdir } from "node:fs/promises";

const outDir = "tmp-verification/claude-code-verification-receipt-workflow";
await mkdir(outDir, { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1440, height: 1100 } });
await page.goto("https://claudecode-lab.com/de/blog/claude-code-verification-receipt-workflow/", {
  waitUntil: "networkidle",
});
await page.screenshot({ path: `${outDir}/desktop-de.png`, fullPage: true });

await page.setViewportSize({ width: 390, height: 1200 });
await page.screenshot({ path: `${outDir}/mobile-de.png`, fullPage: true });

await browser.close();
console.log(`screenshots saved to ${outDir}`);

Sehen Sie sich in den Screenshots den ersten Viewport, den ersten Codeblock, einen Abschnitt in der Mitte und den finalen CTA an. Deutsche Texte werden oft länger als englische. Gerade deshalb gehören Umbrüche, Buttonbreiten und Listenabstände in den Beleg.

Fall 1: Einen dünnen Artikel ausbauen

Wenn ein Artikel zu dünn ist, geht es nicht darum, Fülltext zu produzieren. Der Artikel muss die Suchabsicht erfüllen. Bei diesem Thema bedeutet das: eine klare Erklärung des Verifikationsbelegs, eine kopierbare Vorlage, echte Build-Befehle, eine öffentliche URL-Prüfung, CTA-Kontrolle, Screenshots und konkrete Fehlerfälle.

Der Beleg zur Verbesserung sollte die neuen Abschnitte, interne Links, externe Links, Codeblöcke und Restrisiken nennen. Er sollte außerdem prüfen, ob der kommerzielle Pfad natürlich bleibt. Erst das kostenlose PDF für die tägliche Routine, dann Gumroad für Vorlagen und Setup, dann Beratung, wenn Teamregeln für Deployment, Review und Umsatzpfade nötig werden.

Fall 2: CTA oder Produktlink ändern

Ein CTA wirkt klein, beeinflusst aber Downloads, Käufe und Beratungsanfragen. Schreiben Sie im Beleg nicht nur “CTA geändert”. Notieren Sie Buttontext, href, Titel der Zielseite und die erwartete nächste Aktion.

Beim kostenlosen PDF prüfen Sie, ob der Nutzen klar ist und die Folgeseite passt. Bei Gumroad prüfen Sie Produktname, Beginn der Beschreibung und Übereinstimmung mit dem Artikelversprechen. Bei Beratung prüfen Sie, ob der Übergang logisch ist. In einem Claude-Code-Artikel ist Beratung sinnvoll, wenn es um Teamregeln, Rechte, Review-Prozesse und Veröffentlichungsrisiken geht.

Fall 3: Mehrsprachige Artikel veröffentlichen

Mehrsprachige Inhalte brauchen eigene Prüfung. Englisch passt vielleicht in eine Zeile, Deutsch oder Spanisch nicht. Eine wörtliche Übersetzung von “verification receipt” kann ohne Erklärung wie ein Zahlungsbeleg klingen. Jede Sprache sollte eine natürliche Einleitung, eine verständliche Vorlage, reale Fehlerbeispiele und einen passenden Weg zu Ressourcen oder Beratung haben.

Screenshots zeigen diese Probleme schneller als Quelltext. Man sieht lange Buttons, enge Listen, breite Codeblöcke und CTA-Abschnitte, die zu werblich wirken. Für Inhalte mit Umsatzbezug sind das keine kosmetischen Details.

Häufige Fehler und Gegenmaßnahmen

Erster Fehler: HTTP 200 als Veröffentlichung werten. Prüfen Sie h1, canonical und eine eindeutige Passage aus dem Artikel.

Zweiter Fehler: Beim Build stoppen. Der Build beweist Kompilierbarkeit, nicht die Aktualität der Produktion.

Dritter Fehler: Nur prüfen, ob ein Link existiert. Der Zielort gehört zum Nutzerverhalten.

Vierter Fehler: Keine Screenshots speichern. Ohne Bild wird die mobile Prüfung später zur Behauptung.

Fünfter Fehler: Claude Code nur “bitte prüfen” sagen. Geben Sie die Vorlage vor und verlangen Sie Befehle, URLs, CTA, Screenshots und Restrisiken.

Von Ressourcen zu Gumroad und Beratung

Allein arbeitend beginnen Sie am besten mit dem kostenlosen Claude-Code-Cheatsheet. Es stabilisiert Befehle und tägliche Prüfgewohnheiten. Wenn dieselben Prompts wiederkehren, helfen die Prompt-Vorlagen und der Setup Guide, CLAUDE.md, Hooks und Berechtigungen wiederholbar zu machen.

In einem Team wird Verifikation zur Betriebsregel. Wer prüft die öffentliche URL? Wo liegen Screenshots? Welche CTAs gelten als Umsatzpfad? Welche Fehler blockieren Veröffentlichung? Eine Beratung ist hier kein Fremdkörper, sondern der Schritt, diese Regeln vor dem nächsten kritischen Release zu entwerfen.

• Kostenloses Claude-Code-Cheatsheet
• 50 Claude-Code-Prompt-Vorlagen
• Claude Code Setup Guide
• Produkte
• Beratung

Was ich für diesen Artikel geprüft habe

Ich habe lokale Prüfung, öffentliche URL, CTA und Screenshots in eine Belegstruktur gebracht. Praktisch bedeutet das: Der Artikel sagt nicht nur, dass man prüfen soll, sondern zeigt, welche Beweise nötig sind. Gleichzeitig bleibt der Leserpfad erhalten: kostenloses PDF, Gumroad-Material und Beratung für Teams mit wiederkehrenden Veröffentlichungsrisiken.