Leitfaden 02 · Journal

Vor jedem SEO-Schreibzugriff gehört ein echter Dry-run

Warum eine Textwarnung keine Vorschau ersetzt und welche Felder ein Dry-run für CMS-Änderungen, interne Links oder Webmaster-Aktionen liefern muss.

Evidenz
Implementierungsleitfaden
Review
Quellengeprüfter Agentenentwurf
Spezifikation
2026-07-28
Geprüft
22.8.2026

Ein Agent kann eine vernünftig klingende Änderung vorschlagen und trotzdem das falsche Ziel, eine veraltete Revision oder zu viele Seiten treffen. Deshalb reicht die Frage „Soll ich fortfahren?“ nicht.

Ein echter Dry-run führt dieselben Prüfungen wie der spätere Schreibzugriff aus, beendet den Ablauf aber vor der Wirkung.

Was die Vorschau zeigen muss

Für eine CMS-Änderung gehören Zielsystem, Seite, aktuelle Revision und ein konkreter Diff in die Vorschau. Für eine Sitemap-Einreichung sind Property, Sitemap-URL und überprüfter Eigentumsbezug nötig. Für interne Links braucht es Quellseite, Zielseite, Einbauort und Anchor.

Zusätzlich nennt der Dry-run:

  • die verwendete Identität und Rolle,
  • den nötigen Schreib-Scope,
  • betroffene Objekte und maximale Menge,
  • Konflikte seit der Analyse,
  • erwartete externe Wirkung,
  • Rückroll- oder Korrekturweg.

Die Freigabe bindet genau diese Vorschau

Zwischen Dry-run und Ausführung können sich Seiten oder Berechtigungen ändern. Deshalb sollte die Freigabe an einen kurzen, eindeutigen Plan-Hash oder eine Revision gebunden sein. Ändert sich der Plan, ist eine neue Zustimmung nötig.

So verhindert das System, dass eine kleine freigegebene Korrektur später als allgemeine Publishing-Erlaubnis weiterverwendet wird.

Warum V1 read-only bleiben darf

Ein Produkt muss Schreibzugriffe nicht anbieten, nur weil MCP Tools unterstützt. Ein belastbarer read-only Einstieg kann bereits viel Wert liefern: Daten lesen, Evidenz bündeln, Chancen priorisieren und einen überprüfbaren Plan vorbereiten.

Publishing kann später folgen – mit einem eigenen Berechtigungs-, Freigabe- und Incident-Vertrag.

Auch der Dry-run braucht negative Tests

Die Vorschau ist nur belastbar, wenn sie ungültige Ziele und veraltete Zustände erkennt. Vor dem Rollout sollten deshalb mindestens ein fremder Workspace, eine fehlende Schreibrolle, eine zwischenzeitlich geänderte Seitenrevision und eine Mengenüberschreitung getestet werden.

Wichtig ist außerdem, dass der Dry-run keine versteckte Teilwirkung hat. Er darf keinen Entwurf veröffentlichen, keinen wiederkehrenden Job aktivieren und keine kostenpflichtige Folgeoperation starten, nur um die Vorschau zu berechnen. Wenn schon die Planung externe Kosten verursacht, müssen diese ebenfalls vorab begrenzt und ausgewiesen werden.

Nach der Ausführung wird der genehmigte Plan mit dem tatsächlichen Ergebnis verglichen. Abweichungen, übersprungene Objekte und fehlgeschlagene Teilschritte gehören in die Antwort. So ist die Zustimmung nicht bloß ein Dialogelement, sondern eine prüfbare Grenze zwischen Vorschlag und Wirkung.

Quellenregister

Primärquellen für diesen Stand

  1. Model Context Protocol: The 2026-07-28 SpecificationBeobachtet 22.8.2026 · Stateless core, discovery, routing headers, cache metadata, authorization, tasks and deprecations.