WordPress Wartung & Support in Essen

Laufende WordPress-Wartung für Unternehmen im Ruhrgebiet, mit Sitz im Blick auf Essen: getestete Updates, tägliche Backups, Sicherheits- und Performance-Monitoring sowie ein Support-Kanal mit dokumentierten Reaktionszeiten. Kein Relaunch-Paket, sondern verlässlicher Betrieb einer bestehenden Seite.

#WordPress-Wartung und -Support in Essen

Essen gilt als Energiehauptstadt Deutschlands: Mit E.ON, RWE und Brenntag sitzen hier drei DAX-Konzerne, dazu thyssenkrupp, HOCHTIEF und Evonik im MDAX sowie Häuser wie ALDI Nord, DEICHMANN und die FUNKE Mediengruppe. Dieses Umfeld prägt die Auftraggeber lokaler Dienstleister, Zulieferer und Mittelständler, deren WordPress-Seiten oft an konzernnahe Lieferketten, Recruiting-Portale oder B2B-Kataloge angeschlossen sind. Wartung heißt hier nicht nur “Updates einspielen”, sondern eine Seite betriebssicher halten, die im Hintergrund mit ERP-, Bewerber- oder Shop-Systemen verzahnt ist.

Der entscheidende Unterschied zu einem reinen Entwicklungsprojekt: Bei der Wartung übernehmen wir eine Seite, die schon läuft, oft mit gewachsener Plugin-Historie, mehreren Redakteuren und einer Update-Lücke. Der erste Monat ist deshalb selten ruhig.

#Was in der monatlichen Wartung steckt

• Updates für WordPress-Core, Plugins und Themes, zuerst auf einer Testumgebung-Kopie getestet, dann mit dokumentiertem Rückweg in die Produktion überführt, statt blind im Live-System zu aktualisieren
• Tägliche Backups mit 30 Tagen Aufbewahrung, getrennt vom Hosting gelagert, damit ein kompromittiertes Konto nicht zugleich die Sicherungen mitnimmt
• Uptime- und PageSpeed-Monitoring mit Benachrichtigung, sobald die Seite ausfällt oder die Antwortzeit über die vereinbarte Schwelle steigt
• Malware-Scanning und eine Web Application Firewall, abgestimmt auf typische WordPress-Angriffsmuster (Login-Bruteforce, anfällige Plugins, XML-RPC-Missbrauch)
• Ein fester Posten kleiner Entwicklungsänderungen pro Monat für Texte, Formulare oder Plugin-Anpassungen, ohne dass jede Kleinigkeit ein neues Angebot braucht
• Pflege der Betriebsdokumentation: ein knappes Runbook mit Hosting-Zugängen, DNS-Stand, Plugin-Inventar und Wiederherstellungs-Pfad

#Wer in Essen Wartung braucht, und warum

Die Universität Duisburg-Essen zählt mit ihren beiden Standorten rund 70.000 Studierende, dazu kommen die Folkwang Universität der Künste und die Hochschulen rund um die Zeche Zollverein, das UNESCO-Welterbe, das heute Design- und Kreativwirtschaft beherbergt. Aus diesem Umfeld stammen viele unserer typischen Wartungskunden: Praxen und Kanzleien aus dem starken Gesundheitssektor der Stadt, Handwerks- und Dienstleistungsbetriebe, Vereine, Bildungsträger und kleinere Online-Händler, die eine bestehende WordPress- oder WooCommerce-Seite zuverlässig betrieben haben wollen, ohne eigenes Technik-Team.

Diese Auftraggeber kommen selten, weil sie eine neue Seite wollen. Sie kommen, weil die alte Seite Aussetzer hat: eine Aktualisierung hat das Kontaktformular zerschossen, die Ladezeit ist auf dem Smartphone zäh geworden, oder ein Sicherheitsscan des Hosters hat angeschlagen. Wartung ist hier Risikoabbau, nicht Schmuck.

Ein wiederkehrendes Muster im Ruhrgebiet: Eine Seite wurde vor Jahren von einer regionalen Agentur oder einem freiberuflichen Entwickler gebaut, der Kontakt ist inzwischen abgebrochen, und niemand traut sich mehr an die Updates, aus Angst, etwas zu zerstören. Die Folge ist eine Installation, die zwei Jahre kein Core-Update gesehen hat, mit Plugins, deren Hersteller teils gar nicht mehr existieren. Solche Seiten sind nicht reif für einen Relaunch, sie brauchen zuerst eine kontrollierte Übernahme: einen Stand, von dem aus man wieder gefahrlos aktualisieren kann.

#Deutsche Rechtslage als Daueraufgabe, nicht als Einmal-Häkchen

Eine deutsche Geschäftsseite ist rechtlich anspruchsvoller als ein reines Blog, und genau diese Anforderungen verschieben sich mit jedem Plugin-Update. Wartung in Deutschland bedeutet, diese Punkte dauerhaft im Blick zu behalten:

• Impressum und Datenschutzerklärung müssen erreichbar und aktuell bleiben. Wenn ein neues Tracking- oder Marketing-Plugin dazukommt, ändert sich die Datenschutzerklärung mit, sonst entsteht eine Abmahnlücke.
• DSGVO-konformes Consent-Management: Cookie-Banner und Tag-Loader müssen so eingebunden sein, dass nicht-essenzielle Skripte erst nach Einwilligung laden. Nach jedem Update prüfen wir, ob Plugins eigenmächtig wieder Skripte vor dem Consent feuern.
• Widerrufsrecht und Rechtstexte im Shop-Kontext (etwa über Trusted Shops Legal Services aus Köln eingebundene Texte) müssen mit der tatsächlichen Bestellstrecke übereinstimmen, gerade nach WooCommerce-Updates, die den Checkout umbauen.
• Zahlungswege: Für Shops im Ruhrgebiet sind PayPal, Klarna, SEPA-Lastschrift und giropay die Regel. Ihre Plugins und API-Schnittstellen brauchen Pflege, sonst brechen nach einem Core-Update still Zahlungen ab, ein Fehler, der erst im Umsatzbericht auffällt.

Diese Themen sind kein Beiwerk. In Deutschland ist ein vernachlässigtes Cookie-Setup oder ein veraltetes Impressum ein konkretes Abmahnrisiko, und genau solche Lücken reißen Updates immer wieder auf.

#Wie ein neues Wartungsprojekt startet

1. Bestandsaufnahme, wir nehmen die laufende Installation auf: Plugin- und Theme-Inventar, PHP- und WordPress-Version, Hosting-Setup, Zustand der Backups, offene Sicherheitswarnungen und eine Performance-Baseline mit Lighthouse und echten Feld-Werten.
2. Risikoliste, aus dem Audit entsteht eine priorisierte Liste: veraltetes PHP, Plugins ohne Update seit Jahren, fehlende oder ungetestete Backups, DSGVO-Lücken im Consent, Performance-Bremsen. Sie sehen, was dringend ist und was warten kann.
3. Stabilisierung im ersten Monat, wir richten Monitoring und getestete Backups ein, fahren den ersten Update-Zyklus über Testumgebung und schließen die kritischsten Befunde. Der erste Monat einer übernommenen Seite enthält in der Regel mehr Reparatur als Routine.
4. Monatliche Kadenz, danach läuft der feste Rhythmus: getestete Updates, Backups, Scans, Performance-Check und ein knapper Statusbericht mit dem, was passiert ist, was aufgefallen ist und welche Risiken offen bleiben.

#Probleme, die wir in der Praxis übernehmen

• Datenbank, die über Jahre zugewachsen ist: Auf einer alten Seite stapeln sich Post-Revisionen, abgelaufene Transients und aufgeblähte Autoload-Optionen. Wir räumen auf, bauen Indizes neu und senken so die Antwortzeit, ohne die Inhalte anzutasten.
• Gehackte Installation: Bei einer kompromittierten Seite trennen wir den Schadcode, schließen die genutzte Schwachstelle, setzen alle Zugänge neu, stellen aus einem sauberen Backup wieder her und reichen, falls nötig, einen Überprüfungsantrag bei Google ein.
• Update, das etwas zerschossen hat: Wenn ein Plugin-Konflikt nach einer Aktualisierung das Frontend oder den Checkout bricht, ist genau dafür die Testumgebung-Kopie da: testen, Konflikt isolieren, erst dann live gehen, und im Ernstfall sofort zurückrollen.
• Schleichend abbrechende Zahlungen: Bei einem WooCommerce-Shop kann ein Update der PayPal- oder Klarna-Anbindung dazu führen, dass einzelne Bestellungen ohne Fehlermeldung nicht abgeschlossen werden. Wir prüfen die Zahlungsstrecke nach jedem relevanten Update mit einer Testbestellung, statt darauf zu warten, dass der Umsatzbericht eine Lücke zeigt.
• PHP-Versionssprung beim Hoster: Deutsche Hoster zwingen regelmäßig auf eine neue PHP-Version. Eine alte Seite, die das nicht verträgt, geht dabei in den Wartungsmodus oder zeigt weiße Seiten. Wir testen die Kompatibilität vorab auf Testumgebung und passen Themes oder Plugins an, bevor der Hoster umschaltet.

#Was Wartung realistisch bewirkt

Wir versprechen keine Wunderzahlen. Was eine saubere Wartung tatsächlich bringt: Updates verursachen keine bösen Überraschungen mehr, weil sie vorher getestet werden. Ausfälle werden bemerkt, sobald sie passieren, nicht erst, wenn ein Kunde anruft. Ein Sicherheitsvorfall lässt sich aus einem geprüften Backup zurückholen, statt die Seite neu aufzubauen. Und die Ladezeit bleibt unter Kontrolle, weil sie monatlich gemessen wird, statt schleichend zu verfallen.

Geschwindigkeit ist dabei kein Selbstzweck. Eine träge mobile Seite kostet im Handel messbar Conversions, und auf den Smartphones in Essener Innenstadt-WLAN und im Ruhrgebiets-Mobilfunk zählt jede gesparte Hundertstelsekunde. Deshalb gehört Performance in jeden Monatsbericht.

#Warum Auftraggeber in Essen mit uns arbeiten

Sie sprechen direkt mit der Person, die an der Seite arbeitet, ohne eine Kette aus Projektmanagern dazwischen. Anfragen laufen über einen schriftlichen Ticket-Kanal, sodass jede Entscheidung nachvollziehbar dokumentiert ist, ergänzt um Telefonate nur dann, wenn sie eine Entscheidung wirklich beschleunigen.

Wir arbeiten remote, was im Ruhrgebiet kein Nachteil ist: Hosting, DNS und WordPress lassen sich vollständig aus der Ferne betreuen, und die schriftliche Spur ist im Zweifel wertvoller als ein Vor-Ort-Termin. Bei Bedarf stimmen wir uns trotzdem nach Essener Geschäftszeiten ab.

Die Abrechnung der Wartung erfolgt monatlich, der Umfang wird vorab schriftlich festgehalten. Die konkrete Höhe ergibt sich aus Größe und Zustand der Seite und wird individuell ermittelt.

#Performance-Arbeit im Wartungsbetrieb

Performance ist in der laufenden Pflege kein einmaliges Projekt, sondern eine wiederkehrende Kontrolle. Konkret bedeutet das:

• Assets: Bilder als WebP oder AVIF mit passenden responsive Größen, damit alte Medienbibliotheken nicht jede Seite ausbremsen; CSS und JavaScript werden entschlackt und gezielt geladen.
• Caching: mehrstufig über Browser-Cache, ein CDN (in der Regel Cloudflare), einen Objekt-Cache (Redis, sofern das Hosting es erlaubt) und sauber invalidierte Transients.
• Netzwerk: HTTP/3, Brotli-Kompression und Preconnect-Hinweise für die wichtigsten Drittquellen wie Zahlungs- oder Schriftanbieter.
• Rendering: kritisches CSS inline, verzögertes Laden nicht-kritischer Stile, Lazy Loading für Bilder und eingebettete Inhalte.

Jede dieser Änderungen wird vorher und nachher gemessen und im Bericht festgehalten, damit der Effekt belegbar bleibt, statt Behauptung zu sein.

#Häufige Fragen aus Essen

Was passiert, wenn ein Update etwas kaputtmacht? Genau das soll die Testumgebung-Kopie verhindern. Jedes Update wird zuerst dort getestet; bricht etwas, geht es nie live. Falls in der Produktion doch ein Problem auftaucht, rollen wir auf den letzten geprüften Stand zurück.

Übernehmt ihr auch eine vernachlässigte Seite? Ja. Die Auditphase findet die kritischen Punkte (veraltetes PHP, anfällige Plugins, kaputte Backups, Malware) und macht daraus eine Behebungsliste, bevor die reguläre Wartung startet.

Läuft ihr nur remote? Ja. Kommunikation über einen Ticket-Kanal mit monatlichem Statusbericht; Telefonate nur, wenn sie eine Entscheidung freigeben oder einen Vorfall durchgehen.

Wie wird abgerechnet? Laufende Wartung monatlich, Umfang vorab schriftlich fixiert. Die Höhe wird individuell nach Größe und Zustand der Seite ermittelt.

#SEO und Sichtbarkeit als Teil der Pflege

Suchsichtbarkeit ist im Wartungsbetrieb vor allem eine Frage der Stabilität: Eine Seite, die nicht ausfällt, schnell lädt und keine kaputten Weiterleitungen ansammelt, verliert keine Rankings durch Technik. Wir achten deshalb auf saubere Indexierbarkeit, gültiges Schema.org-Markup für lokale Geschäftsangaben und darauf, dass Updates keine Canonical- oder Redirect-Ketten zerstören. Für Essener Betriebe mit lokalem Bezug zählt vor allem, dass Öffnungszeiten, Standort und Kontaktdaten technisch korrekt ausgezeichnet bleiben, damit sie in der lokalen Suche und in KI-Antworten verlässlich auftauchen.

#Plugin-Hygiene und technische Schulden

Der Plugin-Ordner ist das Kontobuch der technischen Schulden einer WordPress-Seite. Eine Installation, die seit Jahren läuft, sammelt Erweiterungen an, die jemand für eine einzelne Kampagne, ein Formular oder einen Datenimport installiert und danach nie wieder angefasst hat. Deshalb beginnt jede Übernahme mit einem Inventar, und zwar nicht als Bildschirmfoto der Plugin-Liste, sondern als Tabelle mit Herkunft, Lizenz, letzter Aktualisierung und nachgewiesener Verwendung. wp plugin list --fields=name,status,version,update,auto_update --format=csv liefert die Rohdaten in einem Durchlauf, die Herkunft trägt man von Hand nach. Genau diese Spalte entscheidet später darüber, wer ein Update überhaupt liefern kann.

Drei Herkunftsklassen, drei verschiedene Risiken. Plugins aus dem Verzeichnis auf wordpress.org lassen sich gegen die dort hinterlegten Prüfsummen abgleichen: wp plugin verify-checksums --all meldet jede Datei, die von der ausgelieferten Version abweicht, und deckt damit sowohl Schadcode als auch nachträgliche Handanpassungen auf. Kommerzielle Plugins aktualisieren sich über die API des Herstellers, und der Lizenzschlüssel liegt in wp_options. Läuft die Lizenz aus, endet die Update-Versorgung, meist ohne auffällige Meldung im Backend. Ins Inventar gehören deshalb Lizenzinhaber, Konto und Verlängerungsstand, nicht nur der Plugin-Name. Die dritte Klasse ist die unangenehme: Code, den irgendwann jemand per FTP in wp-content/plugins gelegt hat, ohne Autor, ohne Slug im Verzeichnis, häufig mit einer Versionsnummer, die sich seit der ersten Ablage nicht geändert hat. Prüfsummen greifen hier nicht. Solcher Code ist kein Plugin im Sinne der Wartung, sondern Teil der Codebasis: Er gehört in die Versionskontrolle, braucht eine Kompatibilitätsprüfung gegen die aktuelle PHP-Version und einen benannten Verantwortlichen, sonst blockiert er jeden PHP-Sprung des Hosters.

Aufgegebene Plugins erkennen, ohne nur auf das Datum zu starren. Die Signale sind kumulativ. Im readme.txt steht ein Tested up to, das mehrere Hauptversionen zurückliegt. Der Header Requires PHP nennt eine Mindestversion, die Jahre hinter dem zurückliegt, was deutsche Hoster heute ausliefern. Im Supportforum stehen unbeantwortete Anfragen. Die Verzeichnisseite meldet, dass das Plugin geschlossen wurde, was bei einer Sicherheitslücke oder einem Richtlinienverstoß passiert und im WordPress-Backend selbst nicht sichtbar wird. Dazu kommen Aufrufe von Funktionen, die der Core inzwischen als veraltet markiert hat. Ein kleines Plugin, das genau einen Hook registriert, kann dagegen lange unverändert korrekt bleiben. Das Kriterium ist deshalb nie das Datum allein, sondern das Datum in Verbindung mit der Angriffsfläche: Verarbeitet die Erweiterung Uploads, Formulareingaben, Benutzerkonten, Zahlungen oder eigene REST-Routen, wiegt ein stiller Hersteller schwer. Ergänzt sie nur ein Feld im Backend, wiegt er wenig.

Funktionsüberschneidungen kosten doppelt. Typische Doppelungen auf gewachsenen Seiten: zwei Caching-Schichten, die einander bei der Invalidierung in die Quere kommen, zwei SEO-Plugins, die beide Meta-Description und Canonical schreiben, zwei Weiterleitungsverwalter, die zusammen Schleifen bauen, ein Bildoptimierer neben der bereits im Theme eingebauten Variante, ein Sicherheits-Plugin neben der Firewall des Hosters. Die Symptome sind im Quelltext ablesbar: doppelte Meta-Tags, widersprüchliche Canonical-Angaben, Weiterleitungsketten, ein Cache, der nach Redaktionsänderungen nicht leer wird. Die Auflösung ist immer dieselbe Reihenfolge: festlegen, welches Plugin die Zuständigkeit für den Bereich behält, Daten aus dem anderen exportieren, migrieren, erst dann entfernen.

Der Einfluss der Plugin-Anzahl auf die Antwortzeit. Die Zahl selbst ist keine brauchbare Kennzahl, entscheidend ist, was die Erweiterungen bei jedem einzelnen Aufruf tun. Jedes aktive Plugin lädt mindestens seine Hauptdatei, registriert Hooks und legt oft autogeladene Optionen an, dazu eigene Cron-Events, REST-Routen und Handler auf admin-ajax.php. Autoload ist dabei der unterschätzte Posten: Der gesamte Bestand autogeladener Optionen wird bei jedem Seitenaufruf aus der Datenbank geholt und deserialisiert, egal ob eine Seite ihn braucht. Wächst dieser Bestand in den Bereich mehrerer hundert Kilobyte, zahlt jeder Aufruf mit. Gemessen wird das serverseitig als TTFB, in der Praxis mit curl und der Ausgabeoption -w, die den Wert time_starttransfer liefert, ergänzt um Query Monitor für Abfragen pro Aufruf und die langsamsten Hook-Callbacks. Erst diese Zuordnung erlaubt eine Aussage wie “ein Plugin verantwortet den größten Teil der Serverzeit”, statt pauschal die Liste zu kürzen. Für die Feldwerte gilt weiterhin die Core-Web-Vitals-Schwelle von 2,5 Sekunden für LCP und 200 Millisekunden für INP, aber ein aufgeblähter Autoload ist ein Serverproblem und wird auch nur dort gelöst.

Wie ein Plugin sicher aus der Produktion genommen wird. Deaktivieren ist in Sekunden umkehrbar, Löschen nicht, und genau daran orientiert sich der Ablauf:

1. Verwendungsnachweis führen. Inhalte nach Shortcodes und Blöcken absuchen, Theme, Child-Theme und mu-plugins per grep nach Funktionsaufrufen des Plugins durchsuchen, wp cron event list auf registrierte Aufgaben prüfen und die REST-Routen ansehen. Ein Plugin ohne sichtbares Backend kann trotzdem eine Schnittstelle bedienen.
2. Datenbestand klären. Eigene Tabellen, Optionen, Postmeta-Schlüssel, Taxonomien und Uploads notieren, bevor irgendetwas passiert. Manche Deinstallationsroutinen räumen alles ab, andere lassen alles liegen. Beides muss man vorher wissen.
3. Auf der Testumgebung deaktivieren und die kritischen Abläufe durchgehen: Startseite, Formularversand, Login, Checkout, Suchergebnisse. Parallel das PHP-Fehlerprotokoll mitlesen, denn ein fehlender Funktionsaufruf zeigt sich dort früher als im Frontend.
4. In der Produktion nur deaktivieren, nicht löschen, mit frischem Backup davor: wp plugin deactivate plugin-slug. Der Zeitpunkt liegt außerhalb der Umsatzspitzen, bei Essener B2B-Seiten also nicht am Vormittag eines Werktags, wenn Einkauf und Bewerber die Seite nutzen.
5. Beobachtungsfenster einhalten. Die Länge regelt der Wartungsvertrag. Beobachtet werden Fehlerprotokoll, Monitoring, eingehende Formularnachrichten und Bestellungen, nicht nur der Augenschein auf der Startseite.
6. Erst danach entfernen, mit wp plugin uninstall plugin-slug, damit die Deinstallationsroutine überhaupt läuft. Bleibt Datenmüll zurück, wird er gezielt beseitigt statt pauschal per Aufräum-Plugin.
7. Nachlauf abschließen. Permalinks neu schreiben, verwaiste Cron-Events entfernen, abgelaufene Transients mit wp transient delete --expired löschen, Objekt- und CDN-Cache leeren und Weiterleitungen für URLs setzen, die das Plugin erzeugt hatte.
8. Im Runbook dokumentieren, mit Datum, Grund, Ersatzlösung und dem Ort des Backups. Ohne diesen Eintrag installiert die nächste Person das Plugin in einem halben Jahr erneut.

Bei Auftraggebern im Ruhrgebiet hängt an einzelnen Plugins oft ein Arbeitsablauf im Unternehmen: ein Bewerbungsformular, das im Personalbereich landet, ein Produktkatalog, der aus einer Warenwirtschaft gespeist wird, ein Preisblatt für Geschäftskunden. Deshalb gehört zu jedem Entfernungsvorschlag eine benannte Ansprechperson auf Kundenseite, die bestätigt, dass die Funktion tatsächlich niemand mehr nutzt. Technische Prüfung allein reicht dafür nicht aus.

#Projekt in Essen besprechen

Schreiben Sie uns, welche Seite betreut werden soll und wo es aktuell klemmt. Jede Zusammenarbeit beginnt mit der Bestandsaufnahme, daraus folgt ein klarer Wartungsumfang mit Reaktionszeiten und monatlichem Bericht.

Wir arbeiten seit 2007 mit WordPress, haben die großen Versionssprünge mitgemacht und betreuen Seiten in ganz Europa, vom kleinen lokalen Auftritt bis zum WooCommerce-Shop mit angebundenen Zahlungs- und Versanddiensten.