Search & AI Intelligence

Pre-Deploy-SEO-Check — Regressionen vor dem Release erkennen

Ein Theme-Rebuild entfernt Ihre Canonical-Tags. Eine CMS-Migration fügt versehentlich noindex auf 40 Seiten ein. Ein Entwickler "räumt auf" in der Sitemap und entfernt 200 Produkte. Die meisten Teams merken es Wochen später, wenn der organische Traffic einbricht. Wir baseline Ihre Money-Pages vor dem Deploy, diffen sie danach und flaggen 19 spezifische Regressionen — 500 € pauschal, Lieferung innerhalb des Deploy-Fensters.

Check jetzt buchen Prüfungsumfang ansehen

Zuletzt aktualisiert: April 2026 Von Wilko Feye, StarkRank

Warum brechen Deployments SEO unbemerkt?

Visuelle Tests laufen durch, weil die Seite rendert. Funktionale Tests laufen durch, weil die Formulare absenden. Aber das Canonical-Tag ist verschwunden, das H1 hat sich geändert, das JSON-LD ist um 3 Schema-Typen geschrumpft und die Wortanzahl ist um 40% gesunken.

Rankings fallen in den nächsten 4-8 Wochen — bis jemand den Rückgang mit dem Deploy korreliert, ist das Release live und das Rollback-Fenster geschlossen.

Was überwacht der Pre-Deploy-SEO-Check?

19 Regeln laufen gegen jede baselined URL, gruppiert nach Schweregrad. Jede Regel erkennt ein spezifisches Regressions-Muster — kein generisches HTML-Diff. Der Regelkatalog deckt Title-Tags, Meta-Beschreibungen, H1s, Canonical-Tags, Robots-Meta-Direktiven, JSON-LD-Schema-Typen, hreflang-Alternativen, HTTP-Status, Wortanzahl-Schwellen, interne Link-Zählungen und Byte-Level-Content-Hashes ab.

Schweregrad	Regeln	Wann sie auslösen
CRITICAL	page_broke, noindex_added, title_lost	HTTP 4xx/5xx aufgetreten, Robots-Meta hat noindex erhalten oder Title-Tag vollständig entfernt. Deploy anhalten oder zurückrollen.
HIGH	title_changed, h1_changed, h1_lost, canonical_changed, redirect_now, nofollow_added, meta_desc_lost, word_count_drop_heavy (>30%), schema_type_lost, hreflang_lost	Signifikanter struktureller oder inhaltlicher Verlust. In der Regel blockieren — mit dem Team vor dem Fortsetzen klären.
MEDIUM	canonical_lost, meta_desc_changed, multiple_h1s, word_count_drop_moderate (10-30%), internal_links_drop (>50%)	Strukturelle Warnungen. Prüfen, aber nicht zwingend blockieren.
LOW	content_hash_changed	Bytes haben sich geändert, aber keine strukturelle Regel ausgelöst. Für Archiv-Integrität protokolliert, für Deploy-Gating ignoriert.

Warum ist ein Baseline/Diff-Workflow anders als ein gewöhnliches Audit?

Ein gewöhnliches Audit scannt Ihre Website einmal und sagt, was gerade kaputt ist — nützlich zur Diagnose, unbrauchbar für Regressionen. Der Pre-Deploy-Check erstellt einen Snapshot des Pre-Deploy-Zustands in einer SQLite-Datenbank, ruft die URLs nach dem Deploy erneut ab und diffed sie. Die Ausgabe ist nicht "Ihre Website hat diese Probleme" — sondern "diese 7 Dinge haben sich geändert, und 3 davon werden Rankings kosten".

Wann sollten Sie den Pre-Deploy-SEO-Check einsetzen?

Plattform-Migrationen, Theme-Rebuilds, CMS-Versions-Upgrades, Framework-Wechsel und interne Refactorings sind die 5 Szenarien, in denen SEO-Regressionen zum Deploy-Zeitpunkt am häufigsten auftreten. Diese Releases lohnen den Schutz durch eine Baseline.

Plattform-Migrationen

Shopify → Shopify Plus, WooCommerce → Shopify, Magento → Headless, WordPress → Webflow. Jede Migration überschreibt Templates, Canonicals und Schema-Injektions-Punkte.

Theme-Rebuilds

Das Wechseln eines Themes ersetzt typischerweise jedes H1, jedes Meta-Template und jeden Schema-Block. Inhalte bleiben; Markup ändert sich vollständig.

CMS-Versions-Upgrades

Große WordPress-, Shopify- oder Drupal-Upgrades können das Standardverhalten der Robots-Meta-Handhabung ändern oder Plugin-injizierte Schemata brechen.

Framework-Wechsel

Wechsel von Next.js zu Remix, von SSR zu SSG, von Gatsby zu Astro. Änderungen am Rendering-Modus betreffen, was Crawler tatsächlich sehen.

Interne Refactorings

Änderungen an der Sitemap-Logik, an der URL-Struktur, an der Canonical-Strategie. Entwicklergetriebene Refactorings enthalten selten eine SEO-Prüfung.

Wie integriert sich der Check in CI/CD?

Das Skript liefert Exit-Code 0 bei Erfolg und Exit-Code 1 bei CRITICAL-Befunden — so können Sie Ihre Deploy-Pipeline automatisch anhalten. Es ist einbindbar in jedes shellfähige Deploy-System (GitHub Actions, GitLab CI, CircleCI, Vercel).

Optional aktivieren Sie einen wöchentlichen Monitoring-Modus, um stille CMS-Drift zwischen Deploys aufzudecken (Plugin-Updates, Content-Edits, Theme-Anpassungen).

Was erhalten Sie beim Pre-Deploy-SEO-Check?

Baseline-Snapshot — SQLite-Datenbank, portabel, deckt bis zu 30 URLs im 500-Euro-Paket ab
Diff-Bericht (Markdown) — Befunde gruppiert nach CRITICAL / HIGH / MEDIUM / LOW mit exakten Alt → Neu-Werten pro Regel
JSON-Export — maschinenlesbare Befunde für CI-Integration, Slack-Alerts oder nachgelagerte Werkzeuge
Page-Drift-Skript + URL-Liste — damit Ihr Team den Check bei nachfolgenden Deployments ohne Zusatzkosten erneut ausführen kann
Walkthrough-Call — 30 Minuten zur Durchsicht der Befunde, Priorisierung von Fixes und Entscheidung über Deploy-Gate-Integration

Preise

Wie viel kostet der Pre-Deploy-SEO-Check?

500 € pauschal für bis zu 30 URLs, einzelnes Deploy-Fenster. Inklusive sind Baseline, Diff, Markdown-Bericht, JSON-Export und der 30-minütige Walkthrough-Call. Größere URL-Mengen (30-100 URLs) kosten 10 € pro URL über der Basis. Beim Bündeln mit einer Plattform-Migration erhalten Sie 50% Rabatt.

Pre-Deploy-SEO-Check

Einzelnes Deploy-Fenster

· Bis zu 30 URLs
· Baseline + Diff
· 19-Regel-Erkennung
· Exit-Code 1 bei CRITICAL
· JSON-Befunde-Export
· 30-Min Walkthrough-Call
· Skript-Handover

500 €

Check buchen

Migrations-Bundle

50% Rabatt mit Migration

· Alle Features des Standard-Checks
· Für Plattform-Migrationen und Theme-Rebuilds
· Skaliert mit Migrations-Umfang
· Gebucht mit Replatforming-Auftrag

250 €

Bundle anfragen

Laufendes Monitoring

Für Teams, die kontinuierlich deployen (wöchentlich+), bieten wir einen Monitoring-Retainer zu 250 €/Monat mit unbegrenzten Baseline/Diff-Läufen, Slack-Integration und wöchentlichen Drift-Berichten.

Ablauf

Wie läuft der Auftrag ab?

Typischerweise innerhalb von 2-3 Werktagen um Ihr Deploy-Fenster herum. Wir liefern den Diff-Bericht binnen 2 Stunden nach Deploy-Abschluss.

Scope-Call

20-minütiger Call zur Bestätigung des Deploy-Fensters, der URL-Liste und ob für Ihren Stack JavaScript-Vorrendering nötig ist.

URL-Liste finalisieren

Wir stimmen die genauen zu baselineden URLs ab. Für SPAs führen wir ein Screaming-Frog-Vorrendering durch.

Baseline-Lauf

Vor Ihrem Deploy führen wir den Baseline-Befehl gegen Staging oder Produktion aus. Ausgabe ist eine SQLite-Datenbank.

Deploy-Fenster

Ihr Team veröffentlicht das Release nach dem üblichen Zeitplan.

Diff-Lauf + Bericht

Wir rufen die URLs nach dem Deploy erneut ab und erzeugen den Markdown-Bericht plus JSON-Export innerhalb von 2 Stunden nach Deploy-Abschluss.

Walkthrough-Call

30-minütige Besprechung zu Befunden, Rollback-Entscheidungen und optionaler CI/CD-Integration.

FAQ

Welche Fragen stellen Kunden am häufigsten?

Wie unterscheidet sich der Check von Screaming Frog oder einem gewöhnlichen SEO-Audit?

Screaming Frog crawlt Ihre Website und erzeugt einen Snapshot — es kennt keinen Pre-Deploy- versus Post-Deploy-Zustand. Der Pre-Deploy-Check speichert eine Baseline und diffed dagegen, sodass die Ausgabe "diese 7 Dinge haben sich geändert" lautet statt "Ihre Website hat diese Probleme". Setzen Sie beides ein: Screaming Frog zur initialen Entdeckung, den Pre-Deploy-Check als Deploy-Gate.

Funktioniert das bei JavaScript-lastigen Websites?

Nicht nativ — der Check parst statisches HTML über selectolax. Für SPAs, clientseitig gerenderte Next.js-Seiten oder jede Website, die Inhalte clientseitig hydratisiert, führen wir zuvor ein Screaming-Frog-JavaScript-Vorrendering durch, um statische HTML-Snapshots zu erzeugen.

Kann unser Dev-Team den Check nach dem initialen Auftrag selbst ausführen?

Ja — der Auftrag beinhaltet das page_drift.py-Skript, Ihre URL-Liste und eine Dokumentation der Baseline/Diff-Befehle. Ihr Team kann den Check bei jedem folgenden Deploy ohne Zusatzkosten ausführen. Der Walkthrough deckt die CI/CD-Integration ab.

Wie viele URLs sollten wir baselinen?

15 bis 30 URLs sind der ideale Umfang für das 500-Euro-Paket. Wählen Sie Ihre wertvollsten Seiten: Startseite, umsatzstärkste Seiten, Top-10-organische-Landing-Pages nach Search-Console-Klicks und alle URLs, die sich im Deploy gezielt ändern. Für größere Websites 10 € pro URL über 30.

Was passiert, wenn ein CRITICAL-Befund mitten im Deploy auslöst?

Das Skript endet mit Exit-Code 1 und stoppt Ihre CI/CD-Pipeline, falls es in die Deploy-Kette eingebunden ist. Sie rollen zurück, beheben und deployen erneut oder überstimmen den Block bei einem False Positive. Der Markdown-Bericht nennt URL, Regel und Alt-Neu-Werte, sodass die Entscheidung Minuten dauert.

Ist der Check idempotent — können wir den Diff mehrfach ausführen?

Ja. Der Diff-Befehl ruft die URLs erneut ab und vergleicht jedes Mal gegen die gespeicherte Baseline. Sie können ihn direkt nach dem Deploy ausführen, eine Stunde später, einen Tag später, eine Woche später — die Baseline bleibt, bis Sie explizit re-baselinen.

Wie verhält sich der Check zum AISO-Check?

Verschiedene Zwecke. Der AISO-Check prüft auf KI-Suche-Readiness (kann ChatGPT Sie zitieren?) — er ist diagnostisch. Der Pre-Deploy-Check erkennt Regressionen zwischen zwei Zuständen — er ist ein Deploy-Gate. Nutzen Sie den AISO-Check zur Diagnose von KI-Suche-Lücken, den Pre-Deploy-Check zum Schutz vor stillen SEO-Regressionen während Releases.

Bereit, Ihr nächstes Deploy abzusichern?

Der günstigste Zeitpunkt, eine SEO-Regression zu erkennen, ist vor dem Release. Der teuerste ist 6 Wochen später. 500 € pauschal, geliefert im Deploy-Fenster, 19 spezifische Regressionen erkannt.

Check jetzt buchen Migrations-Bundle