WordPress Wartung & Support in Dresden

Laufende WordPress-Wartung und technischer Support für Unternehmen in Dresden und im Umland von Sachsen. Getestete Updates, tägliche Backups, Sicherheits- und Performance-Monitoring sowie ein dokumentiertes SLA, damit die Seite nach dem Launch nicht still verfällt.

#WordPress-Wartung und -Support in Dresden

Eine WordPress-Seite ist nach dem Launch nicht fertig. Plugins erhalten Updates, PHP-Versionen laufen aus, Schwachstellen werden veröffentlicht und Ladezeiten verschlechtern sich, wenn niemand hinsieht. Wartung bedeutet, diese Bewegung kontrolliert zu halten: jede Änderung erst im Testumgebung, dann mit dokumentiertem Rückweg in Produktion.

In Dresden sind die Auftraggeber selten nur klassische Marketing-Abteilungen. Zulieferer und Dienstleister rund um die Halbleiterindustrie, Ausgründungen aus der TU Dresden, Handwerk und Mittelstand, Tourismus rund um Altstadt und Frauenkirche, dazu öffentliche und kulturelle Einrichtungen. Diese Mischung prägt, worauf die Wartung priorisiert: Verfügbarkeit, nachvollziehbare Sicherheit und ein Betrieb, der ohne Vor-Ort-Termin remote läuft.

#Was die monatliche Wartung umfasst

• Getestete Updates von WordPress-Core, Plugins und Themes: erst im Testumgebung gegen die echten Inhalte geprüft, dann mit definiertem Rückweg in Produktion überführt
• Tägliche Backups mit 30 Tagen Aufbewahrung an einem vom Hosting getrennten Speicherort, plus regelmäßig getestete Wiederherstellung (ein Backup, das nie zurückgespielt wurde, ist kein Backup)
• Uptime- und PageSpeed-Monitoring mit Alarmierung, damit ein Ausfall nicht erst beim Anruf eines Kunden auffällt
• Malware-Scanning und eine Web Application Firewall, mit dokumentierter Reaktion bei einem bestätigten Vorfall
• Ein festes Kontingent kleiner Entwicklungsänderungen pro Monat (Textanpassungen, Bugfixes, kleinere Funktionskorrekturen) ohne separaten Angebotsprozess
• Monatlicher Statusbericht mit Metriken, durchgeführten Updates, offenen Risiken und Empfehlungen für den nächsten Zyklus

Für Onlineshops auf WooCommerce kommt eine zusätzliche Ebene hinzu, weil hier jede Stunde Ausfall direkt Umsatz kostet und die rechtlichen Anforderungen in Deutschland strenger sind als der WooCommerce-Standard.

#Der Standort Dresden und was er für die Wartung bedeutet

Dresden ist das Zentrum von Silicon Saxony, dem nach Verbandsangaben größten Mikroelektronik-Standort Europas: Jeder dritte in Europa gefertigte Chip stammt aus der Region. GlobalFoundries betreibt hier eine der größten Halbleiterfabriken des Kontinents, Infineon, Bosch und X-FAB haben Werke in der Umgebung, und die TU Dresden zählt als Exzellenzuniversität zu den forschungsstärksten Hochschulen Deutschlands. Diese Konzentration von Hightech bringt ein Umfeld mit, in dem Zulieferer, Beratungen, Personaldienstleister und Ausgründungen eine professionell betriebene Website schlicht voraussetzen.

Praktisch heißt das: Englischsprachige Karriere- und Produktseiten neben der deutschen Hauptsprache, sauberes hreflang-Routing, und Formulare, die ohne Reibung zu CRM- oder Bewerbermanagement-Systemen durchstellen. Bei mehrsprachigen Installationen (häufig WPML oder Polylang) sind es genau diese Übersetzungs-Plugins, die nach einem Core-Update am ehesten brechen, weshalb sie im Testumgebung zuerst getestet werden.

Daneben steht der breite Dresdner Mittelstand: Handwerksbetriebe, Praxen, lokale Händler und der Tourismus. Für diese Seiten zählt weniger Skalierung als Stabilität, eine korrekte Telefon- und Öffnungszeiten-Darstellung, lokale Sichtbarkeit und ein rechtssicheres Impressum. Beide Welten lassen sich mit demselben Wartungsrahmen bedienen, nur mit unterschiedlichen Schwerpunkten.

#Deutsche Rechtslage als fester Teil der Wartung

Wartung in Deutschland ist nicht nur Technik, sondern auch laufende Konformität. Das gehört bei jedem Zyklus auf die Prüfliste:

• DSGVO und Einwilligung: Ein Consent-Banner, das Tracking und externe Skripte (Google Fonts lokal eingebunden, Maps, Analytics) erst nach Zustimmung lädt. Nach Plugin-Updates wird geprüft, dass keine neuen Skripte ungefragt vor der Einwilligung feuern.
• Impressumspflicht und Datenschutzerklärung: Bei jeder größeren Änderung wird kontrolliert, dass Pflichtangaben erreichbar bleiben und die Datenschutzerklärung die tatsächlich eingesetzten Dienste abbildet.
• Widerrufsrecht und Pflichtangaben im Shop: WooCommerce ab Werk erfüllt die deutschen Vorgaben nicht. In der Regel kommt Germanized (Vendidero) oder German Market zum Einsatz, für Grundpreisangabe, Widerrufsbelehrung, korrekte Steuer- und Versandkostenausweisung und die Button-Lösung. Diese Plugins sind eng an Core und WooCommerce gekoppelt und brauchen besonders sorgfältige Update-Tests.
• Barrierefreiheit nach BFSG: Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz von vielen Onlineshops und vertragsschließenden Websites eine barrierefreie Gestaltung auf Basis von WCAG 2.1 AA und der EN 301 549. Bei betroffenen Seiten gehören Kontrast, Tastaturbedienbarkeit des Checkouts und Screenreader-Tauglichkeit in die laufende Prüfung, ergänzt um eine Barrierefreiheitserklärung.
• Zahlarten: Deutsche Kundschaft erwartet im Shop Kauf auf Rechnung, Klarna, PayPal, SEPA-Lastschrift und giropay. Nach Updates der entsprechenden Payment-Plugins wird ein Test-Checkout je aktiver Zahlart durchgespielt, damit kein Bezahlweg still ausfällt.

Wer Vertrauenssignale wie ein Trusted-Shops-Siegel oder Händlerbund-Rechtstexte einsetzt, bekommt diese in den Update-Test eingebunden, damit ein Theme- oder Plugin-Wechsel die Einbindung nicht beschädigt.

#Onboarding einer bestehenden Seite

Eine bestehende Installation wird nicht blind in die Wartung übernommen. Den Anfang macht ein Audit: Plugin- und Theme-Inventar, Hosting- und PHP-Setup, Zustand der Backups, Sicherheitslage und eine Performance-Baseline per Lighthouse. Daraus entsteht eine priorisierte Befundliste, bevor die reguläre Kadenz beginnt.

Bei vernachlässigten Seiten ist der erste Monat oft mehr Sanierung als Wartung: veraltetes PHP, jahrelang nicht aktualisierte Plugins, defekte oder nie getestete Backups, manchmal bereits vorhandene Schadsoftware. Diese Punkte werden zuerst abgearbeitet, damit die Seite überhaupt auf einen wartbaren Stand kommt.

#Update-Zyklus in der Praxis

Jeder Update-Zyklus läuft nach demselben Muster, damit Risiko und Nachvollziehbarkeit kontrolliert bleiben:

1. Testumgebung-Spiegel: Die Produktionsseite wird in eine identische Testumgebung gezogen, inklusive echter Inhalte und Konfiguration.
2. Update und Prüfung: Core, Plugins und Themes werden im Testumgebung aktualisiert und gezielt getestet, mit besonderem Augenmerk auf Checkout, Formulare, Übersetzungs-Plugins und Page-Builder, also genau die Stellen, die nach Updates erfahrungsgemäß brechen.
3. Überführung mit Rückweg: Erst nach bestandener Prüfung geht das Update in Produktion, mit dokumentiertem Wiederherstellungs-Pfad, falls in der Live-Umgebung doch etwas auffällt.
4. Protokoll: Jeder Zyklus wird im Monatsbericht festgehalten, was aktualisiert wurde, was geprüft wurde und welche Entscheidungen getroffen wurden.

Page-Builder wie Elementor und WPBakery sowie schwere Plugin-Stacks sind die häufigste Ursache für Regressionen nach Updates, gerade in gewachsenen Mittelstands-Installationen. Deshalb wird kein Update direkt in Produktion eingespielt.

Zwei typische Fälle aus der Praxis machen den Unterschied deutlich. Erstens ein WooCommerce-Shop mit Germanized, einem Klarna-Plugin und über zwanzig weiteren Erweiterungen, bei dem ein scheinbar harmloses Update das Steuerverhalten an der Kasse verschiebt, sichtbar nur im Test-Checkout, nicht im Backend. Zweitens eine über Jahre gewachsene Elementor-Seite, deren Layout nach einem Theme-Update bricht, weil ein deaktiviertes, aber nie entferntes Plugin CSS überschrieb. Beide Fälle erkennt man im Testumgebung in Minuten, in Produktion dagegen erst, wenn Kundschaft oder Umsatz darunter leiden.

#Sicherheit und Vorfallreaktion

Die Sicherheits-Baseline umfasst HTTPS mit HSTS, abgesicherte Anmeldung mit Zwei-Faktor-Authentifizierung für Administratoren, regelmäßige Schwachstellen-Prüfung der eingesetzten Plugins, Malware-Scanning und eine vorgelagerte Web Application Firewall. Für Seiten, die personenbezogene Daten verarbeiten, kommt Privacy-by-Design hinzu: Datensparsamkeit, Auftragsverarbeitungsverträge mit Dienstleistern und ein dokumentiertes Löschkonzept.

Bei einem bestätigten Sicherheitsvorfall oder einem Produktionsausfall greift der SLA-Workflow: reagieren, eindämmen, Zeitachse und Ursache dokumentieren, bereinigen und, falls die Schadsoftware Suchergebnisse betroffen hat, eine erneute Überprüfung bei Google beantragen. Der Vorfall bleibt durch das Protokoll auditierbar, was im Streitfall oder gegenüber Datenschutzbehörden zählt.

#Performance und Core Web Vitals

Ladezeit ist in Deutschland nicht nur SEO-Thema, sondern auch Conversion-Thema, gerade bei Shops mit Black-Friday- oder Saison-Spitzen. Die Wartung hält die Core Web Vitals im Blick: Largest Contentful Paint über vorgeladene Hero-Bilder in modernen Formaten und sauberes Caching, Interaction to Next Paint über schlanke JavaScript-Last und Cumulative Layout Shift über feste Bildabmessungen und abgestimmtes Schrift-Laden.

Bei Managed Hosting wird serverseitiges Caching (etwa Redis und ein Reverse-Proxy) konfiguriert, PHP wird mit Kompatibilitätstest aktuell gehalten und die Datenbank wird regelmäßig von Ballast befreit, der sich über die Jahre ansammelt (verwaiste Transients, Post-Revisionen, Logtabellen ausgemusterter Plugins). Performance-Regressionen werden im Monitoring sichtbar und fließen in den nächsten Zyklus ein, statt unbemerkt zu bleiben.

#Lokale Sichtbarkeit in Dresden

Für Dresdner Betriebe mit Laufkundschaft oder lokalem Einzugsgebiet gehört lokale Auffindbarkeit zur Pflege: konsistente NAP-Daten (Name, Adresse, Telefon) über Website und Verzeichnisse, korrektes LocalBusiness-Markup nach Schema.org, eingebundene Öffnungszeiten und eine Anbindung an das Google-Unternehmensprofil. Bei mehreren Standorten in Sachsen wird die Struktur so gehalten, dass jede Filiale sauber indexiert wird, statt mit den anderen zu konkurrieren.

#Häufige Fragen aus Dresden

Läuft die Wartung remote? Ja. Kommunikation über einen schriftlichen Ticket-Kanal mit monatlichem Statusbericht. Telefonate nur, wenn sie eine Entscheidung beschleunigen oder ein Vorfall im Detail durchgesprochen werden muss. Ein Vor-Ort-Termin in Dresden ist möglich, aber für laufende Wartung nicht nötig.

Können Sie einen vernachlässigten oder bereits gehackten Shop übernehmen? Ja. Das Onboarding-Audit identifiziert kritische Probleme, eine Bereinigung kommt vor die reguläre Kadenz. Bei einem aktiven Befall stehen Eindämmung und Wiederherstellung an erster Stelle.

Betreuen Sie auch Seiten außerhalb von Dresden? Ja. Der Schwerpunkt liegt auf Dresden und Sachsen, die Wartung läuft remote aber für Kunden in ganz Deutschland und im deutschsprachigen Raum.

Was ist mit dem BFSG, wenn mein Shop betroffen ist? Dann gehören Barrierefreiheits-Prüfungen (Kontrast, Tastaturbedienung, Screenreader) und die Pflege der Barrierefreiheitserklärung in den laufenden Zyklus, nicht als einmaliges Projekt, sondern als Teil jeder größeren Änderung.

#Transaktionsmails und Zustellbarkeit

Bestellbestätigungen und Formularmails gehören zur Wartung, nicht zum Marketing. Fällt eine Kaufbestätigung aus, meldet sich die Kundschaft im Support, storniert oder bestellt ein zweites Mal. Bleibt eine Kontaktanfrage im Spamordner liegen, verliert der Betrieb eine Anfrage, ohne es überhaupt zu merken. Anders als ein Ausfall der Website ist ein stiller Mailausfall nicht sichtbar, deshalb gehört der Versandweg in jeden Wartungszyklus, mit einem echten Testversand nach Updates an Core, Shop-Plugins oder Formular-Plugin.

Warum der Versand über die PHP-Mailfunktion im Spam landet. WordPress verschickt Mails über wp_mail(), das intern PHPMailer verwendet und ohne weitere Konfiguration an die PHP-Funktion mail() und damit an das lokale sendmail-Binary übergibt. Dabei fehlen genau die Signale, die empfangende Server heute prüfen: eine authentifizierte Einlieferung, eine kryptografische Signatur der Nachricht und ein Envelope-Absender, der zur sichtbaren Absenderdomain passt. Auf typischem Shared Hosting steht im Return-Path eine technische Serveradresse auf dem Hostnamen des Webservers, während im From-Header eine Adresse der eigenen Domain steht. Diese fehlende Ausrichtung ist der Hauptgrund für die Einstufung als Spam. Dazu teilt sich die ausgehende IP ihre Reputation mit allen anderen Konten auf demselben Server, und der Standardabsender aus wordpress@ plus Hostname existiert als Postfach meist gar nicht, sodass Antworten und Fehlermeldungen ins Leere laufen. Manche Hoster sperren ausgehende Verbindungen auf Port 25 ohnehin, dann verschwindet die Nachricht ohne sichtbaren Fehler.

SMTP oder Anbieter-API als Versandweg. Der saubere Weg führt über einen Dienst, der das Zustellen als Aufgabe hat. Technisch gibt es zwei Varianten. Bei SMTP hängt sich ein Plugin oder ein kleines Must-Use-Plugin in den Hook phpmailer_init und setzt Host, Port und Zugangsdaten, üblich sind Port 587 mit STARTTLS oder Port 465 mit implizitem TLS. Die Zugangsdaten gehören als Konstanten in die wp-config.php oder in Umgebungsvariablen, nicht in die Datenbank, sonst wandern sie bei jedem Datenbank-Export in Kopien und Testumgebungen mit. Bei der HTTP-API des Anbieters entfällt der SMTP-Handshake vollständig, gesperrte Ports spielen keine Rolle mehr und der Anbieter liefert pro Nachricht eine Message-ID sowie einen auswertbaren Fehlerstatus zurück. Für beide Varianten gilt: Absenderadresse auf der eigenen Domain, ein separates Reply-To auf ein echtes Postfach, und Testumgebungen bekommen entweder eigene Zugangsdaten mit Sandbox-Modus oder gar keinen Versand, damit ein Import von Produktionsdaten nicht versehentlich alte Bestellmails erneut verschickt.

SPF, DKIM und DMARC in einfachen Worten. Die drei Einträge im DNS beantworten drei verschiedene Fragen. SPF ist ein TXT-Eintrag auf der Domain, der auflistet, welche Server für diese Domain einliefern dürfen, in der Form v=spf1 gefolgt von include-Angaben des Anbieters und einem abschließenden -all. Geprüft wird die Domain des Return-Path, nicht die sichtbare Absenderadresse, und die Auswertung darf höchstens zehn DNS-Nachschläge auslösen, weshalb angesammelte include-Ketten alter Dienstleister ausgemistet gehören. DKIM ist eine Signatur: Der Versanddienst signiert Kopf- und Inhaltsteile der Nachricht mit einem privaten Schlüssel, der öffentliche Schlüssel liegt im DNS unter einem Selektor vor _domainkey. Der Empfänger rechnet die Signatur nach und erkennt so, dass die Nachricht unterwegs nicht verändert wurde. DKIM überlebt im Gegensatz zu SPF auch eine Weiterleitung. DMARC verbindet beides: Ein TXT-Eintrag auf _dmarc legt fest, was passieren soll, wenn weder SPF noch DKIM zur Domain im From-Header passen, mit der Richtlinie p=none, p=quarantine oder p=reject. Der sinnvolle Ablauf startet mit p=none und einer rua-Adresse für die aggregierten Berichte, wertet einige Berichtszyklen aus, findet dabei die vergessenen Absender (Newsletter-Tool, Buchhaltungssoftware, Bewerbermanagement) und verschärft die Richtlinie erst danach. Google und Yahoo verlangen seit Februar 2024 von Massenversendern SPF, DKIM und einen DMARC-Eintrag sowie eine Abmeldung mit einem Klick bei Werbemails, was den Druck auch auf kleinere Absender erhöht hat. Transaktionsmails und Newsletter laufen am besten über getrennte Subdomains, damit Beschwerden über Werbemails die Zustellung von Bestellbestätigungen nicht mit nach unten ziehen.

Warteschlangen, damit der Versand keine Seitenaufrufe blockiert. Standardmäßig läuft der Versand mitten im Seitenaufruf. Beim Kaufabschluss heißt das: Die Kundschaft wartet auf den SMTP-Handshake, und wenn der Mailserver langsam antwortet oder die Verbindung in eine Zeitüberschreitung läuft, bleibt die Bestellabschluss-Seite stehen oder bricht ab, obwohl die Bestellung längst in der Datenbank steht. Die Lösung ist Entkopplung. Die Nachricht wird beim Auslösen nur in eine Warteschlange geschrieben und von einem Hintergrundprozess abgearbeitet, in WooCommerce-Umgebungen üblicherweise über den bereits vorhandenen Action Scheduler. Damit dieser Prozess zuverlässig läuft, wird WP-Cron vom Seitenaufruf gelöst: DISABLE_WP_CRON in der wp-config.php auf true setzen und stattdessen ein Systemcron einrichten, das minütlich wp cron event run --due-now ausführt. Auf Seiten mit wenig Verkehr ist das ohnehin die einzige Möglichkeit, überhaupt planbar Aufgaben auszuführen. Fehlgeschlagene Versuche werden mit wachsendem Abstand wiederholt, und was nach den definierten Versuchen weiterhin scheitert, landet in einer Fehlerliste, die im Monatsbericht auftaucht, statt lautlos verworfen zu werden. Meldungen des Anbieters über Rückläufer und Beschwerden schreiben in dieselbe Auswertung zurück, damit dauerhaft unzustellbare Adressen sichtbar werden.

Fehlende Bestell- und Formularmails diagnostizieren. Die Diagnose folgt der Kette von der Auslösung bis zum Posteingang, Schicht für Schicht, weil jede Schicht anders repariert wird.

• Hat WordPress überhaupt versucht zu senden? Ein Mail-Protokoll, das Empfänger, Betreff, Header und Rückgabewert speichert, beantwortet das sofort. Ergänzend liefert der Hook wp_mail_failed die Fehlermeldung von PHPMailer. Ein schneller Test von der Kommandozeile: wp eval "var_dump( wp_mail( '[email protected]', 'Zustelltest', 'Testinhalt' ) );". Kommt hier false zurück, liegt das Problem in WordPress oder im Versandweg, nicht beim Empfänger.
• Wurde das Ereignis ausgelöst? WooCommerce verschickt Bestellmails an Statusübergängen. Wird ein Status per Datenbank oder Import direkt gesetzt, feuert kein Übergang und damit keine Mail. Auch ein deaktivierter Mailtyp in den WooCommerce-Einstellungen oder ein Filter auf den Empfänger der Händlerbenachrichtigung erklärt fehlende Nachrichten, ohne dass technisch etwas kaputt ist. Die Protokolle im Bereich WooCommerce, Status zeigen zusätzlich Fehler aus den Zahlungserweiterungen.
• Hat der Anbieter die Nachricht angenommen und zugestellt? Im Dashboard des Versanddienstes stehen die Zustände angenommen, zugestellt, abgelehnt und als Spam gemeldet. Wichtig ist die Unterdrückungsliste: Nach einem harten Bounce oder einer Beschwerde wird eine Adresse gesperrt, und spätere Nachrichten an dieselbe Adresse werden verworfen, ohne dass in der Website eine Fehlermeldung erscheint.
• Was sagt die empfangene Nachricht? Im Quelltext einer angekommenen Mail steht die Zeile Authentication-Results mit den Ergebnissen für spf, dkim und dmarc. Steht dort ein Fehlschlag, liegt die Ursache bei den DNS-Einträgen, nicht in WordPress. Bei Firmenkunden mit Microsoft 365 oder Google Workspace lohnt zusätzlich der Blick in die Quarantäne des Postfachs und in serverseitige Regeln, denn dort landen korrekt authentifizierte Nachrichten ebenfalls, wenn eine Transportregel greift.
• Stimmt die Empfängerseite? Formular-Plugins schicken an eine im Formular hinterlegte Adresse, die nach einem Personalwechsel oft nicht mehr existiert. Ein Abgleich der Empfängeradressen aller Formulare und der Adresse aus wp option get admin_email gehört einmal pro Zyklus auf die Liste.

Für Dresdner Auftraggeber ist das keine Randnotiz. Wer Zulieferer oder Dienstleister im Umfeld der Halbleiterindustrie und der TU Dresden ist, schreibt an Empfänger mit streng konfigurierten Unternehmenspostfächern, in denen eine unsignierte Nachricht schlicht in der Quarantäne endet. Wer Gastronomie, Handwerk oder Tourismus rund um die Altstadt betreibt, schreibt an Freemail-Adressen, deren Filter auf Reputation und Beschwerdequote reagieren. Beide Fälle profitieren von derselben Grundlage: eigener Versanddienst, saubere DNS-Einträge, entkoppelte Warteschlange und ein Protokoll, das im Zweifel belegt, wann welche Nachricht an wen ausgeliefert wurde.

#Zusammenarbeit starten

Der erste Schritt ist das Onboarding-Audit der bestehenden WordPress- oder WooCommerce-Installation. Daraus entstehen eine Befundliste, ein Vorschlag für die monatliche Kadenz und ein SLA mit dokumentierten Reaktionszeiten. Die Vergütung richtet sich nach Umfang und Risiko der Installation und wird individuell bestimmt.

WPPoland betreut WordPress-Seiten seit 2007, von einfachen Unternehmensauftritten bis zu WooCommerce-Shops unter deutschem Recht. Für Unternehmen in Dresden bedeutet das einen technischen Partner, der den Code versteht, die deutsche Rechtslage mitdenkt und die Seite nach dem Launch dauerhaft betriebsfähig hält.