Für wen das ist
Betreiber und kleine Teams, deren WordPress-Website oder WooCommerce-Shop live ist und für das Geschäft zählt und die keine Plugins mehr zum Ausprobieren haben: ein Theme, das wegen des Page Builders darunter langsam lädt, ein Checkout, der bei manchen Zahlungsarten fehlschlägt, ein Produktimport, der die Website lahmlegt, ein Hack, der immer wiederkommt.
Ich baue WordPress-Websites seit meinen Freelance-Jahren, und diese Website ist eine davon: ein Theme ohne Page Builder und ohne SEO-Plugin, mit vier Sprachen, strukturierten Daten und einem Kontaktformular im Theme selbst. WooCommerce-Shops bekommen dasselbe Engineering, das ich bei Magento anwende: den Request-Pfad lesen, an der Quelle beheben, eine Staging-Kopie halten.
Typische Situationen
- Die Website ist bei den Core Web Vitals rot, und der Page Builder ist der Grund, aber ein Neubau des Themes wirkt zu groß.
- WooCommerce-Bestellungen schlagen bei einer Zahlungsart fehl, oder der Bestand wird nach einem starken Tag negativ.
- Ein Produktimport oder eine Synchronisation mit einem ERP oder Marktplatz dupliziert Produkte oder lässt still Preise fallen.
- Dreißig Plugins, drei davon verwaist, und niemand weiß, welches die Website ausbremst.
- Die Website wurde gehackt, mit einem Plugin bereinigt und einen Monat später erneut infiziert.
- Ein mehrsprachiges Setup, in dem Übersetzungen, hreflang und Sitemap nicht mehr zusammenpassen.
Was ich liefere
- Eigene Themes ohne Page Builder: blockbasiert, schnell, mit dem Design in CSS und strukturierten Daten, Sitemap und Meta-Tags im Theme statt in Plugins.
- WooCommerce-Checkout-, Zahlungs- und Versandarbeit: Gateway-Integrationen, Stripe, Bestellstatus-Abläufe und Webhook-Empfänger, die mit Duplikaten und Wiederholungen zurechtkommen.
- Importe und Synchronisationen mit ERPs, Marktplätzen und Feeds, die vor dem Schreiben validieren und jeden Lauf protokollieren.
- Performance entlang des Request-Pfads: Caching, PHP-FPM, Datenbankabfragen, Bilder, Schriften und die Plugins, die auf jeder Seite feuern, vorher und nachher gemessen.
- Sicherheitsbereinigung nach einem Vorfall: den Einstiegspunkt finden, Backdoors und fremde Benutzer entfernen, härten, und eine Backup- und Wiederherstellungsroutine, die getestet ist.
- Eigene Plugins, wenn das Verzeichnis nichts Passendes hat, geschrieben, um Core- und WooCommerce-Updates zu überstehen.
Wie es abläuft
Die Website so lesen, wie ein Request sie sieht. Plugins, Theme, Queries, Caching, der Server und die Logs. Das erste Ergebnis ist eine Liste von Ursachen mit Belegen, nach Wirkung geordnet, und eine Notiz dazu, welche Plugins tragen und welche gehen können.
An der Quelle beheben, auf einer Staging-Kopie. Theme- und Plugin-Änderungen gehen in die Versionskontrolle und werden vor dem Release auf einer Kopie mit echten Inhalten getestet, mit einem Rückweg.
Ausrollen, dann aufschreiben. Monitoring läuft während des Releases; danach ein kurzes Dokument dazu, was sich geändert hat, worauf zu achten ist und wie die Update-Routine ab jetzt aussieht.