Definiere eine Aufgabe und eine verantwortliche Person
Beschreibe vor der Suche das Besucher‑ oder Mitarbeiterergebnis in einem Satz. Prüfe dann, ob WordPress, das Theme, Hosting‑Kontrollen oder ein bestehendes Plugin diese Aufgabe bereits erfüllt. Füge kein zweites Werkzeug allein wegen Oberfläche oder Feature‑Liste hinzu.
Notiere für jedes zugelassene Plugin dessen Besitzer, Einsatzorte, zentrale Einstellungen, verknüpfte Konten oder API‑Schlüssel und eine Bedingung für die Entfernung. Die verantwortliche Person überwacht Hinweise und testet Änderungen. So wird eine Installationshistorie zum Abhängigkeitsregister.
Liste die Seiten, Formulare, Editor‑Workflows oder Back‑Office‑Prozesse auf, die es ändern kann.
Vermeide doppelte Analytics, Caching, Formulare, Pop‑ups oder Optimierungsfunktionen, sofern nicht dokumentiert.
Überprüfe neue und wirkungsstarke Plugins nach dem Start und im regulären Wartungsrhythmus.
Kandidaten vor der Aktivierung bewerten
Nutze den Bildschirm "Plugins > Installieren" und das WordPress Plugin Directory als Startpunkte. WordPress zeigt Autor, Benutzerbewertung, Zeitpunkt der letzten Aktualisierung, Kompatibilität und einen Link zu Details. Lies Dokumentation, Release‑Notes, Support‑Optionen und Datenschutzinformationen. Wende dieselbe Sorgfalt bei Plugins an, die gekauft oder anderweitig heruntergeladen wurden.
Prüfe, ob der Maintainer unterstützte WordPress‑ und PHP‑Versionen, was das Plugin ändert und wie man ein Sicherheitsproblem meldet, erklärt. WordPress.org kann ein Verzeichnis‑Plugin wegen eines Sicherheitsproblems entfernen, ersetzt jedoch nicht deine eigene Bewertung und Wartung.
Lehne einen Kandidaten ab, wenn Core, Theme, Host oder vorhandene Funktionalität die Anforderung bereits erfüllt.
Vergleiche die angegebenen Anforderungen mit deiner Live‑Umgebung, dem aktiven Theme und kritischen Plugins.
Bewertungen können Muster zeigen, sind aber kein Code‑Audit.
Zugriffe, Daten und externe Dienste kartieren
Beschreibe vor der Freigabe, was das Plugin ändert, welche Informationen es sammelt oder speichert, wohin diese Informationen gehen, wer die Integration verwaltet und was passiert, wenn ein Dienst nicht verfügbar ist oder entfernt wird. Notiere auch Browser‑Skripte, iframes, Webhooks, API‑Schlüssel und Service‑Accounts.
Die WordPress‑Datenschutzrichtlinien fordern Plugin‑Autoren auf, Vorschläge für den Datenschutzhinweis zu liefern, wenn ihr Plugin Nutzerdaten sammelt, verwendet, speichert oder an Dritte weitergibt. Nutze das, um die Erklärung des Anbieters zu prüfen, nicht als automatische Rechtskonformität. Bei Zahlungen, Gesundheitsdaten, sensiblen personenbezogenen Daten oder regulierten Aufgaben hole vor der Freigabe qualifizierte Prüfungen zu Datenschutz, Sicherheit, Zahlungsabwicklung und Recht ein.
Verwende nur die Rollen, Konten, Scopes und Schlüssel, die nötig sind; entferne alte Zugänge, wenn Personen oder Werkzeuge wechseln.
Halte Datenkategorien, Empfänger, Aufbewahrungs‑Kontrollen und Löschschritte fest.
Kompatibilität in einer geschützten Staging‑Kopie testen
Staging ist eine getrennte Testkopie, mit der Änderungen vor der Produktion geprüft werden. Nutze sie für ein neues Plugin oder wirkungsstarke Änderungen. Schütze sie, vermeide nach Möglichkeit echte Kundendaten und blockiere Live‑E‑Mails, Zahlungen oder Webhooks.
Teste betroffene Abläufe: öffentliche Seiten, Formulare, Anmeldungen, Veröffentlichung, Suche und Warenkorb/Checkout, wo relevant. Prüfe anschließend Fehlerprotokolle und Site Health. Site Health zeigt Plugin‑Versionen, Ersteller und Auto‑Update‑Einstellungen. Staging kann nicht jede Produktionsbedingung reproduzieren.
Aktualisiere oder führe jeweils nur ein wirkungsstarkes Plugin ein, damit Regressionen leichter einzugrenzen sind.
Teste als Besucher und als Editor oder Administrator, der den betroffenen Workflow nutzt.
Dokumentiere die vorherige Version, erwartetes Verhalten, Fehler und die Freigabeentscheidung.
Leistung messen und eine risikobasierte Update‑Politik anwenden
Vergleiche repräsentative Seiten vor und nach der Änderung mit derselben Testmethode. Untersuche Seitengröße, Netzwerk‑Anfragen, Browser‑Fehler und die unterstützte Interaktion. WordPress empfiehlt, Plugins selektiv zu deaktivieren, um die Serverleistung zu messen, wenn ein Plugin verdächtigt wird. Verlasse dich nicht allein auf ein Administrations‑Screen oder einen einzigen synthetischen Score.
Google’s web.dev beschreibt, wie Third‑Party‑JavaScript Netzwerkaufwand erhöhen, das Rendering verzögern und Datenschutz, Sicherheit sowie Seitenverhalten beeinflussen kann. Prüfe redundante Skripte und Anbieter. WordPress unterstützt per‑Plugin Auto‑Updates und sendet Benachrichtigungen, aber geplante Updates hängen von WordPress Cron ab. Überprüfe, dass beides funktioniert. Kontrollierte Auto‑Updates können für niedrig wirkende, verstandene Plugins mit Backups und Verifikation passen. Stage und explizite Freigabe für Checkout, Authentifizierung, Einwilligungen oder benutzerdefinierte Integrationen. Das sind risikobasierte Entscheidungen, keine universellen Kategorien.
Benennen, wer Hinweise liest, Sicherheitsänderungen bewertet und Ausnahmen genehmigt.
Bei wirkungsstarken Änderungen Release‑Notes und Kompatibilität vor dem Test prüfen.
Dokumentiere, warum ein Update aufgeschoben wurde, dessen Besitzer, Schutzmaßnahmen und das Überprüfungsdatum.
Sorgfältig sichern, zurückrollen und entfernen
Bestätige vor einem Update oder einer Entfernung, die die Seite beeinträchtigen könnte, ein aktuelles Backup, dessen Speicherort, Wiederherstellungsberechtigung und die erste Zurückroll‑Aktion. WordPress empfiehlt, vor Updates Backups zu erstellen und sagt, ein Backup kann wiederhergestellt werden, wenn ein Upgrade Probleme verursacht. Teste die Wiederherstellung auf einer sicheren Kopie, wenn das Risiko es erfordert.
Wenn ein Plugin nicht mehr benötigt wird, vergewissere dich, dass kein Workflow davon abhängt, sichere erforderliche Aufzeichnungen und widerrufe verbundene Schlüssel oder Webhooks. Deaktiviere und lösche es dann über den Plugins‑Bildschirm. Die Bereinigung ist pluginabhängig, also folge der Dokumentation und verifiziere das Ergebnis. Deaktivierung ist keine vollständige Entfernung: inaktive Plugins bleiben installiert, bis sie gelöscht werden.
Wisse, ob du es deaktivieren, die vorherige Version wiederherstellen, eine Einstellung korrigieren oder ein vollständiges Backup zurückspielen musst.
Teste nach dem Zurückrollen betroffene Abläufe, Zugangsdaten, Cache‑Verhalten und Administration erneut.