Website-Drift: Warum Websites kaputtgehen, obwohl niemand etwas geändert hat
Deine Website ist nach einem Update kaputt — oder funktioniert ganz ohne Update plötzlich nicht mehr? Das ist Website-Drift. „Wir haben nichts geändert“ ist der häufigste Satz im Website-Support — und er stimmt fast nie. Jemand oder etwas hat etwas geändert: Ein Auto-Update lief über Nacht, ein KI-Assistent hat eine Komponente umgeschrieben, ein Drittanbieter-Skript hat eine neue Version ausgeliefert, eine Firewall-Regel wurde verschärft. Dieser Leitfaden zeigt die zehn Ursachen für Website-Drift, die wir am häufigsten sehen, was sie jeweils kaputt machen und wie du sie erkennst, bevor es deine Kunden tun.
Was Website-Drift ist
Website-Drift ist der Abstand zwischen der Website, die du getestet hast, und der Website, die deine Besucher heute bekommen. Sie entsteht aus Änderungen, die niemand im Zusammenhang geprüft hat: hier ein Plugin-Update, dort eine CDN-Einstellung, ein Skript, das eine neuere Version von sich selbst lädt. Keine davon wirkt allein gefährlich, und die meisten werden automatisch eingespielt.
Drift zeigt sich selten als kompletter Ausfall. Die Startseite lädt weiter, also bleibt das Uptime-Monitoring grün. Kaputt geht ein Weg: der Warenkorb-Button, der nicht mehr reagiert, ein verschwundenes Checkout-Feld, eine Bestellbestätigung, die nicht mehr ankommt, ein Produktbild mit 404. Genau diese Fehler kosten Umsatz — und genau sie sieht ein einfacher Ping nicht.
Warum „niemand hat etwas angefasst“ fast nie stimmt
Eine moderne Website ist nicht eine einzige Software. Ein typischer WordPress-Shop besteht aus WordPress-Core, einem Theme, zwanzig bis fünfzig Plugins, einer PHP-Laufzeit, einem Webserver, einem Cache, einem CDN, einer Firewall, einem Zahlungsanbieter und einem Dutzend Drittanbieter-Skripten — jeweils von einem anderen Team gepflegt, jeweils mit eigenem Release-Rhythmus, viele davon mit automatischen Updates.
Eine Website, die mit KI-Tools oder einem modernen Framework gebaut wurde, sieht genauso aus: generierter Code, npm-Abhängigkeiten, Hosting-Standardeinstellungen, Edge-Konfiguration und externe APIs. Wenn etwas kaputtgeht, lautet die Frage nicht, ob sich etwas geändert hat, sondern welche dieser Schichten sich wann geändert hat. Die zehn Ursachen unten sind die Stellen, an denen du zuerst suchen solltest.
1. Updates von WordPress-Core, Plugins und Themes
Updates sind die größte einzelne Ursache für Website-Drift unter WordPress — hinter den meisten Meldungen „ein WordPress-Update hat meine Website kaputt gemacht“ steckt eines — und die meisten laufen unbeaufsichtigt: Kleinere Core-Releases werden automatisch installiert, und seit WordPress 5.5 können sich auch Plugins und Themes selbst aktualisieren. Ein Update, das für sich genommen in Ordnung ist, kann trotzdem mit einem anderen Plugin kollidieren, einen Hook ändern, auf den dein Theme angewiesen ist, oder die CSS-Klassen umbenennen, auf die deine Anpassungen zielen.
WooCommerce bringt eine eigene Falle mit: Themes überschreiben WooCommerce-Vorlagen, und wenn WooCommerce eine Vorlage aktualisiert, rendert weiter die veraltete Kopie deines Themes. Warenkorb oder Checkout können ein Feld oder eine Nonce verlieren, ohne dass auf der Seite ein Fehler erscheint. Die Lösung ist nicht, Updates abzuschalten — veraltete Plugins sind ein Sicherheitsrisiko —, sondern die wichtigen Wege — Checkout, Seitenstruktur und Layout — direkt nach jedem Update erneut zu testen. Genau das macht Relvato: Das WordPress-Plugin meldet jedes Plugin-, Theme- und Core-Update, sobald es passiert, und Relvato führt deine Checkout-, Visual- und Strukturprüfungen innerhalb von Minuten erneut aus.
2. KI-generierter Code und Vibe-Coding-Regressionen
KI-Coding-Tools ändern schnell und breit. Bittest du einen Assistenten, „das Anmeldeformular aufzuräumen“, benennt er vielleicht auch eine Route um, entfernt ein verstecktes Feld, das dein CRM brauchte, streicht das Tracking-Attribut, auf das deine Analyse angewiesen war, oder generiert eine Komponente komplett neu — ohne den Sonderfall, den du letzten Monat behoben hast. Tools wie Lovable, Bolt, v0 und Cursor können mit einem einzigen Prompt Dutzende Dateien umschreiben.
Das Ergebnis ist eine Regression, die gewollt aussieht: Der Code ist sauber, der Build läuft, die Seite rendert. Nichts stürzt ab; ein Button sendet einfach nicht mehr ab, oder ein Link zeigt auf eine verschobene Route. Code-Reviews finden einiges davon, aber nicht, was über einen ganzen Nutzerweg passiert. Deine wichtigsten Journeys nach jedem Push auf GitHub erneut auszuführen — nicht nur die Unit-Tests — bringt es ans Licht. Relvatos GitHub-App tut das bei jedem Push: Sie führt deine echten Nutzerwege im Browser erneut aus, sodass ein fehlendes Feld oder eine verschobene Route auffällt, bevor Kunden darauf stoßen.
3. Drittanbieter-Skripte und externe Ressourcen
Vieles, was deine Besucher ausführen, liegt nicht bei dir: Chat-Widgets, Zahlungs- und Betrugs-SDKs, Tag-Manager, Analyse, A/B-Test-Tools, Schriften, Karten, Bewertungs-Badges und Bilder auf einem CDN. Sie werden nach eigenem Zeitplan aktualisiert, und wenn du sie von der URL des Anbieters lädst, bekommst du die neue Version in dem Moment, in dem sie ausgeliefert wird — oder gar nichts, wenn sie eingestellt wird.
Der polyfill.io-Vorfall 2024 zeigte den Extremfall: Ein weit verbreitetes Skript wechselte den Besitzer und lieferte bösartigen Code an mehr als 100.000 Websites aus. Die alltäglichen Fälle sind leiser — ein Chat-Widget, das mobil den Checkout-Button verdeckt, ein Tag-Manager-Container, den jemand bearbeitet hat, ein veralteter SDK-Endpunkt, der einen Fehler liefert, ein gelöschtes Bild auf einem CDN. Achte auf unbehandelte JavaScript-Fehler, defekte externe Bilder und neue Skript-Quellen auf deinen wichtigsten Seiten.
4. Änderungen an Firewall, WAF und Bot-Schutz
Sicherheitsschichten ändern sich ohne Deploy: Eine Cloudflare-Regel wird verschärft, ein Hoster aktiviert Imunify360 oder strengere ModSecurity-Regeln, ein Sicherheits-Plugin aktualisiert seine Sperrliste, der Bot-Fight-Modus wird eingeschaltet. Jede dieser Änderungen kann anfangen, legitimen Verkehr zu prüfen oder zu blockieren — Zahlungs-Callbacks, Webhooks, API-Anfragen deiner eigenen App, Suchmaschinen und KI-Crawler oder echte Kunden mit VPN.
Solche Fehler sind von innen schwer zu sehen: Du bist angemeldet, auf der Allowlist oder hast eine vertrauenswürdige IP, also funktioniert für dich alles. Besucher sehen eine Seite „Please wait while your request is being verified“ oder einen 403. Wenn auch das Monitoring blockiert wird, sagt dir ein gutes Tool, welche Schicht es war — die CDN-Edge, die Server-Firewall des Hosters oder ein WordPress-Plugin —, denn jede wird an einer anderen Stelle behoben (so gibst du das Monitoring frei).
5. Änderungen an Hosting, PHP und Server
Hoster aktualisieren PHP-Versionen, ziehen Konten auf neue Server um, ändern Speicherlimits und tauschen die Webserver-Konfiguration — manchmal mit einer E-Mail, die du nicht gelesen hast. Jede PHP-Version erklärt Funktionen für veraltet oder entfernt sie, sodass ein Plugin, das gestern lief, plötzlich „Deprecated“-Hinweise über deine Seiten verteilt oder einen Fatal Error auslöst, der den Checkout durch den WordPress-Bildschirm „Es gab einen kritischen Fehler auf dieser Website“ ersetzt.
Umzüge bringen eigene Drift mit: ein anderer Serverpfad, eine fehlende PHP-Erweiterung, ein Cron, der nicht mehr läuft, sodass geplante E-Mails und Abo-Verlängerungen hängen bleiben, oder Dateirechte, die Uploads verhindern. Prüfe nach jeder Hosting-Änderung deine wichtigsten Seiten auf sichtbare PHP- und WordPress-Fehler und kontrolliere, ob Hintergrundjobs weiter abgearbeitet werden.
6. Cache- und CDN-Konfiguration
Caching ist unsichtbar, bis es das Falsche zwischenspeichert. Ein Full-Page-Cache oder eine CDN-Regel, die den Checkout, den Warenkorb oder eine angemeldete Seite speichert, kann die Sitzung eines Kunden an einen anderen ausliefern, einen leeren Warenkorb zeigen oder Anmeldung und Gutscheine für alle kaputt machen. Cloudflares automatische Plattform-Optimierungen und aggressive Cache-Regeln sind häufige Ursachen, wenn sie ohne Ausnahmen eingeschaltet werden.
Auch das Gegenteil passiert: Das Leeren des Caches nach einem Deploy legt eine langsame Seite offen, die dahinter versteckt war, oder eine Minifizierungs-Einstellung zerstört ein Skript. Weil der Fehler davon abhängt, wer die Seite zuerst aufgerufen hat, kann er kommen und gehen — deshalb braucht es einen echten Browser, der den tatsächlichen Kundenweg prüft — etwa einen Checkout mit Anmeldung oder den Login —, nicht nur einen Statuscode.
7. Alltägliche Inhalts- und Einstellungsänderungen
Nicht jeder Fehler kommt aus dem Code. Jemand benennt eine Seite um, und jeder Menülink auf die alte URL liefert jetzt 404. Ein Produkt wird gelöscht, und sein Bild verschwindet von drei Kategorieseiten. Das Häkchen „Suchmaschinen davon abhalten, diese Website zu indexieren“, das auf der Staging-Umgebung gesetzt war, ist nach dem Launch immer noch gesetzt. Der Gast-Checkout wird zum Testen deaktiviert und nie wieder aktiviert.
Diese Änderungen passieren im Admin-Bereich, oft durch Leute, die sie gar nicht als Änderungen an der Website sehen. Sie sind zugleich am leichtesten automatisch zu erkennen: defekte Links und Bilder auf wichtigen Seiten, ein unerwartetes noindex und ein Checkout, der Gäste plötzlich zur Anmeldung zwingt, sind alles eindeutige Prüfungen.
8. Dinge, die still ablaufen
Manche Fehler sind schon an dem Tag geplant, an dem du etwas einrichtest. SSL-Zertifikate laufen ab, wenn die automatische Verlängerung unbemerkt scheitert. Domains verfallen, wenn die hinterlegte Karte abläuft. API-Schlüssel und Zugangsdaten des Zahlungsanbieters werden erneuert oder widerrufen. Lizenzen für Premium-Plugins laufen aus, sodass das Plugin keine Sicherheits- und Kompatibilitäts-Updates mehr bekommt, mit denen der Rest deines Systems rechnet.
Ablauf ist die am leichtesten vermeidbare Drift, weil das Datum vorher bekannt ist. Das Gültigkeitsfenster des Zertifikats zu prüfen und die Zahlungsarten zu testen, die Kunden tatsächlich nutzen, macht aus einem überraschenden Ausfall eine Erinnerung.
9. Änderungen bei Zahlungs-, Versand- und API-Anbietern
Dein Checkout hängt von Diensten ab, die du nicht kontrollierst. Zahlungsanbieter stellen API-Versionen ein, ändern Webhook-Formate und verschärfen die Regeln zur starken Kundenauthentifizierung; Versand- und Steuerdienste ändern Tarife und Endpunkte; E-Mail-Anbieter passen Versandlimits und Authentifizierungsanforderungen an. Ein Zahlungsanbieter kann still aus dem Checkout verschwinden, weil sein Plugin jetzt eine neuere Einstellung verlangt.
Das Symptom ist meist teilweise: Die meisten Bestellungen laufen weiter, aber eine Zahlungsart fehlt, 3-D Secure scheitert bei manchen Karten, oder Bestellbestätigungen kommen nicht mehr an. Zu prüfen, ob jede erwartete Zahlungsart noch angeboten wird und ob Bestätigungs-E-Mails tatsächlich im Postfach ankommen, erkennt das, ohne echte Zahlungen auszulösen.
10. Sicherheitsvorfälle
Angreifer erzeugen Drift absichtlich und versuchen, sie unsichtbar zu halten. Ein verwundbares Plugin wird ausgenutzt, um einen Karten-Skimmer in den Checkout einzuschleusen, eine Backdoor-Datei landet im Upload-Ordner, eine Theme-Vorlage wird verändert, oder ein Kundenkonto wird still zum Administrator befördert. Die Website funktioniert weiter — genau darum geht es.
Um das zu erkennen, brauchst du einen Vergleich mit einem bekannten, sauberen Stand: Core- und Plugin-Dateien gegen ihre offiziellen Prüfsummen, die Dateien deines Themes gegen eine freigegebene Baseline, die Liste der Administratoren gegen die erwartete und die externen Quellen, die im Checkout Skripte laden, gegen die freigegebenen. Kombiniere das mit einem Schwachstellen-Scan, damit du patchst, bevor die Lücke ausgenutzt wird — nicht danach.
Wie du Drift erkennst, bevor es deine Kunden tun
Das Muster ist bei allen zehn Ursachen dasselbe: Etwas außerhalb deines Review-Prozesses hat sich geändert, und ein Weg für Nutzer ist kaputtgegangen, ohne dass du einen Fehler bemerkst. Geplante Prüfungen helfen, lassen aber eine Lücke zwischen der Änderung und dem nächsten Lauf. Am wirksamsten ist es, direkt nach den Änderungen erneut zu prüfen, die Drift verursachen — ein Plugin-, Theme- oder Core-Update, ein Push in dein Repository, eine Konfigurationsänderung — und für alles andere einen festen Rhythmus beizubehalten.
Genau darauf ist Relvato ausgelegt. Unter WordPress meldet das Plugin Updates, sobald sie passieren, und Relvato führt die Prüfungen erneut aus, die betroffen sein könnten: Checkout- und Login-Wege, visuelle Regression und Strukturdrift, Fehler- und Linkprüfungen sowie Datei- und Theme-Integrität. Auf jedem Stack macht ein Push in ein verbundenes GitHub-Repository dasselbe. Wenn eine Firewall die Prüfungen blockiert, nennt Relvato die Schicht, damit du weißt, wo du es freigeben musst, und freigegebene Baselines sorgen dafür, dass gewollte Änderungen nicht doppelt alarmieren.
Die 10 Ursachen für Website-Drift im Überblick
| Ursache | Was sich verändert | Typisches Symptom | Wie du es erkennst |
|---|---|---|---|
| WordPress-Updates | Core, Plugins, Themes, WooCommerce-Vorlagen | Fehlendes Checkout-Feld, Plugin-Konflikt, verändertes Layout | Checkout-, Visual- und Strukturprüfungen nach jedem Update |
| KI-generierter Code | Komponenten, Routen, Formulare, Tracking-Attribute | Button sendet nicht mehr ab, verschobene Route, fehlendes Feld | Wichtige Journeys bei jedem Push erneut ausführen |
| Drittanbieter-Skripte | Widgets, SDKs, Tag-Manager, CDN-Ressourcen | JavaScript-Fehler, blockierte Buttons, defekte Bilder, neue Skript-Quellen | Fehlerprüfung, defekte Links, Prüfung der Skript-Quellen |
| Firewall und WAF | CDN-Regeln, Server-Firewall, Sicherheits-Plugins | Prüfseiten, 403-Fehler, blockierte Webhooks und Crawler | Prüfungen, die die blockierende Schicht benennen |
| Hosting und PHP | PHP-Version, Server, Cron, Erweiterungen | Deprecated-Hinweise, Bildschirm für kritische Fehler, hängende Jobs | Fehlerprüfung und Prüfung der Hintergrundjobs |
| Cache und CDN | Seiten-Cache, Cache-Regeln, Minifizierung | Leerer Warenkorb, kaputte Anmeldung, vermischte Sitzungen | Checkout- und Login-Journeys im echten Browser |
| Inhalte und Einstellungen | Seiten, Menüs, Produkte, Indexierungs- und Checkout-Einstellungen | 404-Links, fehlende Bilder, noindex, Gast-Checkout aus | Prüfungen für defekte Links, SEO und Checkout |
| Ablaufende Dinge | SSL, Domains, API-Schlüssel, Lizenzen | Zertifikatswarnungen, Ausfälle, fehlende Updates | SSL-Ablauf- und Zahlungsarten-Prüfungen |
| Zahlungs- und API-Anbieter | Zahlungs-APIs, Webhooks, E-Mail-Versand | Fehlende Zahlungsart, gescheitertes 3-D Secure, keine Bestätigungs-E-Mail | Prüfungen für Zahlungsarten und E-Mail-Zustellung |
| Sicherheitsvorfälle | Core- und Theme-Dateien, Admins, Checkout-Skripte | Skimmer im Checkout, fremder Admin, eingeschleuste Backdoor | Datei- und Theme-Integrität, Admin-Liste, Schwachstellen-Scan |
FAQ zu Website-Drift
Was ist Website-Drift?
Website-Drift ist der schleichende Unterschied zwischen der Website, die du zuletzt getestet hast, und der Website, die Besucher jetzt bekommen — verursacht durch Änderungen, die niemand im Zusammenhang geprüft hat: automatische Updates, Drittanbieter-Skripte, Hosting- und Firewall-Änderungen, Inhaltsänderungen. Meist geht dabei ein Weg kaputt, etwa Checkout oder Registrierung, statt dass die ganze Website ausfällt.
Warum ist meine Website kaputt, obwohl ich nichts geändert habe?
Weil etwas anderes etwas geändert hat. Die häufigsten Ursachen sind automatische Updates von WordPress-Core, Plugins oder Themes, ein Drittanbieter-Skript mit neuer Version, ein Hosting- oder PHP-Upgrade, eine geänderte Firewall- oder CDN-Regel oder ein abgelaufenes Zertifikat bzw. ein abgelaufener API-Schlüssel. Prüfe, was in den Stunden vor dem Problem aktualisiert oder geändert wurde.
Sollte ich WordPress-Auto-Updates abschalten, um Drift zu verhindern?
In der Regel nicht. Veraltete Plugins sind einer der Hauptwege, über die Websites kompromittiert werden — Updates abzuschalten tauscht also Drift gegen ein Sicherheitsrisiko. Sicherer ist es, weiter zu aktualisieren und die wichtigen Wege — Checkout, Anmeldung, Formulare — direkt nach jedem Update automatisch erneut zu testen.
Wie erkenne ich Fehler durch KI-generierten Code?
Behandle jede KI-gestützte Änderung wie einen Deploy: Führe die echten Nutzerwege aus, nicht nur den Build. Prüfungen, die Seitenstruktur und Screenshots mit einer freigegebenen Baseline vergleichen, finden fehlende Felder und verschobene Buttons — und wenn sie bei jedem Push in dein Repository laufen, fällt die Regression auf, bevor Nutzer sie bemerken.
Wie oft sollte eine Website geprüft werden?
Direkt nach Änderungen und zusätzlich in einem festen Rhythmus. Ereignisgesteuerte Prüfungen erkennen Drift Minuten nach einem Update oder Deploy; ein täglicher oder wöchentlicher Zeitplan deckt Änderungen ab, die du nicht kommen siehst, etwa ein ablaufendes Zertifikat oder ein Update eines Drittanbieter-Skripts.