WooCommerce Entwickler in Essen

Essen ist Konzernzentrale für E.ON, RWE und Brenntag (alle DAX) sowie für thyssenkrupp, HOCHTIEF und Evonik, dazu ALDI Nord, DEICHMANN, MEDION und Schenker. Wer in diesem Umfeld einen WooCommerce-Shop betreibt, verkauft selten an reine Laufkundschaft, sondern an Einkaufsabteilungen, Filialnetze und Beschaffungssysteme, die mit klaren Rechnungs-, Steuer- und Lieferprozessen rechnen. Genau für diese Anforderungen baue ich WooCommerce-Shops in Essen: belastbarer Checkout, saubere Gateway-Anbindung, deutsche Rechtskonformität und eine Architektur, die Woo-Updates übersteht.

Statt eines weiteren Optimierungs-Plugins steht am Anfang ein nüchterner Befund: Wo verliert der Bestellpfad Conversion, wo entsteht rechtliches Risiko, wo bremst eine über Jahre gewachsene Plugin-Landschaft die Produkt- und Kategorieseiten. Daraus wird eine Risikokarte, dann ein Umsetzungsplan mit messbaren Abnahmekriterien.

#WooCommerce-Entwicklung in Essen

#Was diese Seite konkret abdeckt

• Eigener Checkout-Flow, abgestimmt auf den deutschen Markt: Gast-Bestellung, Pflicht-Checkboxen für AGB und Widerrufsbelehrung, Express-Optionen (Apple Pay, Google Pay) und ein Bestellabschluss, der die rechtlich vorgeschriebene Reihenfolge einhält.
• Payment-Gateways, wie sie in Deutschland tatsächlich genutzt werden: Klarna (Rechnung und Ratenkauf), PayPal, SEPA-Lastschrift, giropay sowie Kartenzahlung über Stripe oder Mollie mit SCA/3DS, inklusive Webhook-Handling, Teilerstattung und Idempotenz auf jedem Pfad.
• Rechtssichere Grundlage statt Bastellösung: saubere Einbindung von Germanized for WooCommerce oder German Market für Grundpreisangaben, korrekte MwSt.-Ausweisung, Impressum nach DDG und eine Widerrufsbelehrung nach § 355 BGB, die im Checkout an der richtigen Stelle steht.
• B2B-Funktionalität für Beschaffung im Ruhrgebiet: rollenbasierte Netto-/Brutto-Preise, Mindestbestellmengen, Angebotsanfragen und Kundenkonten mit eigener Bestellhistorie für Geschäftskunden.
• Versandlogik mit deutschen Carriern: Zonen und Gewichts-/Maßregeln für DHL, DPD und Hermes, Versandetiketten und Sendungsverfolgung, angebunden an das bestehende Fulfilment.
• Anbindung an Warenwirtschaft und Marktplätze: Bestandssynchronisation zwischen WooCommerce, ERP/Lager und Feeds für Amazon, eBay und OTTO, mit Konfliktauflösung und nachvollziehbarem Audit-Log.

#Warum der lokale Markt die technischen Prioritäten setzt

In Essen treffen zwei Käufergruppen aufeinander, die unterschiedliche Anforderungen an einen Shop stellen. Auf der einen Seite die Konzern- und Filialwelt: ALDI Nord und DEICHMANN haben hier ihren Sitz, das Limbecker Platz zählt mit rund 70.000 m² Verkaufsfläche und über 200 Geschäften zu den größten innerstädtischen Einkaufszentren Deutschlands. Händler in diesem Umfeld brauchen Shops, die hohe Lastspitzen, strikte Markenvorgaben und Schnittstellen zu bestehenden Systemen aushalten.

Auf der anderen Seite eine wachsende Gründerszene rund um die Universität Duisburg-Essen. Deren Zentrum für Gründungen und Innopreneurship (GUIDE) und die Startup Factory RUHR (Teil der vom Bund geförderten BRYCK-Allianz) bringen junge Marken hervor, die schnell einen verkaufsfähigen Shop brauchen, ohne sich technische Schulden einzukaufen. Für diese Kunden zählt ein klarer Start: ein sauber konfigurierter Checkout, der von Tag eins rechtskonform ist, statt eines Themes mit Dutzenden ungenutzter Plugins.

Beide Gruppen eint, dass ein langsamer oder rechtlich angreifbarer Shop in Essen unmittelbar Geld kostet, sei es durch abgebrochene Warenkörbe oder durch Abmahnrisiken bei fehlerhafter Widerrufsbelehrung. Mein Auftrag bleibt dabei eng: WooCommerce. Passt im Einzelfall eine andere Plattform besser, sage ich das schriftlich, statt das Projekt zu verbiegen.

#Technische Grundlinie

Die Anpassungen laufen über die dokumentierten Action- und Filter-Hooks von WooCommerce, nicht über Eingriffe in Kerndateien. Eigener Plugin-Code und Theme-Code bleiben getrennt, damit der Shop Woo- und WordPress-Updates übersteht. Im Hintergrund übernimmt der Action Scheduler längere Aufgaben (Etiketten, Sync-Läufe, Mails), Objekt-Caching über Redis entlastet wiederholte Abfragen, und ein CDN vor dem Shop fängt Lastspitzen ab. Die Grenze zwischen Woo-Kern, Plugin und Theme wird vor der ersten Codezeile festgelegt und im Runbook dokumentiert.

#Wie ein Projekt abläuft

1. Katalog- und Checkout-Audit: Aufnahme von Produkt-Taxonomie, Checkout-Flow, aktiven Gateways, Versandzonen, Steuerregeln und Integrationen, dazu eine Lighthouse- und Query-Monitor-Baseline auf den meistbesuchten Produkt- und Kategorieseiten.
2. Plan für Gateways, Versand und Recht: Festlegung der Zahlarten (Klarna, PayPal, SEPA, giropay, Karte), der deutschen Pflichtangaben und der Schnittstellen zu Warenwirtschaft und Fulfilment, schriftlich dokumentiert.
3. Umsetzung in Feature-Branches: Entwicklung nach den Coding Standards von WordPress und WooCommerce, mit Tests auf Zahlungs- und Bestellpfaden statt am Ende.
4. QA auf Bestellpfaden: End-to-End gegen eine produktionsnahe Testumgebung, Warenkorb über Zahlung mit Testkarten je Gateway, Erstattung, Kundenmail und Admin-Bearbeitung, inklusive Fehlerpfaden.
5. Start und Übergabe: DNS, SSL, Cache-Warmup, Redirect-Prüfung und Monitoring, danach eine Übergabe-Session mit Runbooks für jedes Gateway und jede nicht-triviale Integration.

#Typische Aufgaben aus Essen

• Ein über Jahre gewachsener Shop mit Dutzenden Plugins, dessen TTFB auf Kategorieseiten eingebrochen ist: hier folgt zuerst die Messung (WP-CLI-Profil, Query Monitor, autoloaded Options), dann die gezielte Entlastung, nicht das nächste Caching-Plugin.
• Ein Händler mit grenzüberschreitendem EU-Verkauf, der die OSS-Regelung sauber abbilden muss: korrekte MwSt.-Sätze pro Lieferland, konforme Rechnungen und eine nachvollziehbare Steuerlogik.
• Eine B2B-Anbindung an die Beschaffung eines größeren Kunden: rollenbasierte Preise, Freigabe-Workflows und ein Kundenkonto, das die geforderten Bestell- und Rechnungsdaten liefert.
• Ein Produkt mit hunderten Varianten und Konfigurator: ein eigener Produkttyp mit bedingter Logik und Echtzeit-Preisberechnung, der die SKU-Last verträgt, ohne die Seite zu bremsen.

#Migration und Sanierung bestehender Shops

Viele Anfragen aus Essen drehen sich nicht um einen Shop auf der grünen Wiese, sondern um einen, der bereits läuft und an seine Grenzen stößt. Typisch ist ein Shop, der über mehrere Jahre und mehrere Agenturen gewachsen ist: ein schweres Theme mit eingebautem Page-Builder, ein Dutzend sich überlappende Plugins, eine Steuerkonfiguration, die niemand mehr vollständig erklären kann, und ein Checkout, der nach jedem WooCommerce-Update zickt. In solchen Fällen beginnt die Arbeit nicht mit einem Neubau, sondern mit einer Inventur: Welche Plugins greifen tatsächlich in den Bestellpfad ein, welche autoloaded Options blähen jeden Request auf, welche Anpassungen sitzen im Theme statt in einem Plugin und brechen damit beim nächsten Theme-Wechsel.

Aus dieser Inventur entsteht ein Plan, der zwischen drei Wegen unterscheidet: Reparatur an Ort und Stelle, schrittweise Migration der kritischen Logik in ein sauberes eigenes Plugin, oder ein kontrollierter Neuaufbau des Checkouts bei erhaltenem Katalog. Welcher Weg passt, hängt vom Risiko ab, nicht vom Wunsch nach einem Neuanfang. Produktdaten, Bestellhistorie, Kundenkonten und SEO-relevante URLs werden dabei als das behandelt, was sie sind: Geschäftswerte, die eine getestete Migration mit Redirect-Plan und Zurücksetzen brauchen, keine Nebensache.

#Headless und Storefront-Architektur

Für die meisten Händler in Essen ist klassisches serverseitiges WooCommerce die richtige Wahl: einfacher zu warten, näher an der Plattform, weniger bewegliche Teile. Eine entkoppelte Storefront (Headless) wird erst dann interessant, wenn ein konkreter Grund vorliegt, etwa eine bestehende App, ein sehr individuelles Frontend-Erlebnis oder eine bereits vorhandene Frontend-Mannschaft. In diesem Fall liefert WooCommerce die Daten über die REST-API oder eine gezielte Erweiterung, während Warenkorb, Zahlung und Bestellabwicklung im bewährten Woo-Kern bleiben. Die Entscheidung Headless oder klassisch wird schriftlich begründet, mit den Folgen für Wartung, Hosting und Team, statt sie als Standard zu verkaufen.

#Performance, weil sie hier direkt Umsatz ist

Auf Produkt-, Kategorie- und Checkout-Seiten zählt jede Zehntelsekunde, gerade bei mobilem Traffic aus dem Ruhrgebiet. Die Arbeit setzt an vier Stellen an: Asset-Auslieferung (responsive Bilder in WebP und AVIF, bereinigtes CSS, code-gesplittetes JavaScript), mehrstufiges Caching (Browser, CDN, Redis, Transients mit gezielter Invalidierung), Netzwerk (HTTP/3, Brotli, Preconnect) und Rendering (Critical CSS, Lazy Loading, schlanke Cart-Fragments). Jede Entscheidung wird vorher und nachher gemessen und in der Projektdokumentation als Baseline hinterlegt.

#Sicherheit und Konformität

Ein Shop in Deutschland muss zwei Dinge gleichzeitig erfüllen: technische Härtung und rechtliche Korrektheit. Auf der technischen Seite heißt das parametrisierte Datenbankabfragen gegen SQL-Injection, konsequentes Output-Escaping gegen Cross-Site-Scripting, Nonce-Prüfung bei Formularen, Rate Limiting an den Login-Endpunkten und eine an WordPress-Angriffsmuster angepasste Firewall-Regelung. Auf der rechtlichen Seite heißt das DSGVO-konforme Verarbeitung von Kunden- und Zahlungsdaten, eine korrekte Datenschutzerklärung, das vorgeschriebene Impressum nach DDG und eine Widerrufsbelehrung, die der Käufer im Checkout zum richtigen Zeitpunkt bestätigt.

#Häufige Fragen aus Essen

Wie binden Sie Zahlungsarten für den deutschen Markt ein? Für jedes Gateway dokumentiere ich die unterstützten Flows (Einmalzahlung, Ratenkauf bei Klarna, SEPA-Mandat, Erstattung, Teilerstattung, 3DS), die Testkarten- bzw. Testkonten-Matrix, die eingehenden Webhooks und die Idempotenz. Die QA fährt jeden aktiven Pfad gegen Testumgebung durch, inklusive Fehlerfälle.

Machen Sie meinen Shop rechtssicher? Ich richte die technische Grundlage dafür ein, sauber eingebunden über Germanized for WooCommerce oder German Market, mit korrekter Checkout-Reihenfolge, Pflicht-Checkboxen und MwSt.-Ausweisung. Die abschließende Prüfung der konkreten Rechtstexte gehört in die Hand eines Anwalts oder eines spezialisierten Dienstes; ich sorge dafür, dass diese Texte technisch korrekt ausgeliefert werden.

Ändern Sie den WooCommerce-Kern? Nein. Anpassungen laufen über Hooks und eine saubere Trennung von Plugin und Theme, damit Updates den Shop nicht brechen.

Arbeiten Sie nur mit Unternehmen in Essen? Der Schwerpunkt liegt auf Essen und dem Ruhrgebiet, aber die Zusammenarbeit funktioniert genauso mit Kunden in ganz Deutschland und international.

#Härtung des Shops und Reaktion auf Sicherheitsvorfälle

Ein Shop mit Zahlungs-, Rechnungs- und Adressdaten ist ein lohnendes Ziel, und die meisten Vorfälle beginnen nicht mit einem Angriff auf den WordPress-Kern, sondern mit einer veralteten Erweiterung, einem geteilten Redaktionspasswort oder einem Schreibrecht, das nie hätte bestehen dürfen. Härtung ist deshalb Konfigurationsarbeit mit klaren Grenzen, kein Sicherheits-Plugin, das man einmal aktiviert.

Dateirechte und Schreibzugriff. Als Grundlinie gilt 755 für Verzeichnisse und 644 für Dateien, gesetzt über find mit der Option -type d beziehungsweise -type f und einer Weitergabe an xargs chmod. Die wp-config.php bekommt 640 oder 600, damit sie für andere Nutzer auf dem Server nicht lesbar ist. Der PHP-Prozess sollte nur dort schreiben dürfen, wo er es wirklich braucht: wp-content/uploads und das Cache-Verzeichnis. Plugin- und Theme-Verzeichnisse gehören nicht dazu, wenn der Code über Git und eine Pipeline ausgeliefert wird. Ergänzend wird die PHP-Ausführung im Upload-Verzeichnis auf Webserver-Ebene unterbunden, per location-Regel in nginx oder per .htaccess in Apache. Damit verliert eine hochgeladene Datei ihren Wert als Hintertür, selbst wenn sie es in den Upload-Ordner schafft.

Backend-Editor und Änderungen über den Admin abschalten. In der wp-config.php wird DISALLOW_FILE_EDIT auf true gesetzt, etwa über wp config set DISALLOW_FILE_EDIT true --raw. Damit verschwindet der Plugin- und Theme-Editor aus dem Backend, und ein übernommenes Administratorkonto kann nicht mehr in zwei Klicks PHP-Code in ein aktives Theme schreiben. Wo der Shop über eine Pipeline ausgerollt wird, kommt DISALLOW_FILE_MODS dazu: keine Installation, keine Aktualisierung, keine Löschung von Plugins über die Oberfläche. Updates laufen dann über wp plugin update in der Pipeline mit vorheriger Prüfung auf einer Testumgebung. Das ist eine bewusste Einschränkung für die Redaktion und gehört ins Runbook, sonst ruft beim ersten fehlenden Update-Button jemand an.

XML-RPC und REST für nicht angemeldete Nutzer begrenzen. xmlrpc.php wird in den meisten Shops nicht mehr gebraucht und lässt sich am Webserver oder in der WAF vollständig sperren; wird eine mobile App oder ein Dienst angebunden, der die Schnittstelle noch nutzt, bleibt der Filter xmlrpc_methods als feineres Werkzeug, um insbesondere die Multicall-Methode zu entfernen, mit der Anmeldeversuche gebündelt werden. Bei der REST-API ist eine pauschale Sperre für Gäste falsch: die WooCommerce Store API unter wc/store/v1 muss für nicht angemeldete Besucher erreichbar bleiben, sonst funktionieren Warenkorb und Block-Checkout nicht mehr. Sinnvoll ist eine Positivliste im Filter rest_authentication_errors, die Store-API und die für den Shop nötigen Routen offen lässt und den Rest für Gäste mit einem WP_Error beantwortet. Die Route wp/v2/users wird über rest_endpoints entfernt, ebenso die Umleitung über ?author=1, damit Anmeldenamen nicht öffentlich abfragbar sind. Die Schlüssel der REST-API von WooCommerce (wc/v3) werden pro Integration ausgestellt, auf Lesezugriff beschränkt, wo Schreibrechte nicht nötig sind, und laufen ausschließlich über HTTPS.

Zwei-Faktor-Anmeldung für Redaktion und Buchhaltung. Ein zweiter Faktor ist für jedes Konto Pflicht, das Bestellungen sieht, nicht nur für Administratoren. TOTP nach RFC 6238 ist die praktikable Grundlinie, WebAuthn mit Passkeys die stärkere Variante, weil sie an die Domain gebunden ist und Phishing-Seiten damit ins Leere laufen. SMS als zweiter Faktor bleibt außen vor. Parallel dazu müssen die Rollen aufgeräumt werden: die Buchhaltung braucht Zugriff auf Bestell- und Rechnungsdaten, also eine eigene Rolle mit edit_shop_orders und Leserechten auf Berichte, aber ohne manage_woocommerce und ohne install_plugins. Sitzungen werden über den Filter auth_cookie_expiration verkürzt, weil zwei Wochen Gültigkeit bei “Angemeldet bleiben” für ein Konto mit Zugriff auf Kundendaten zu lang sind. Integrationen bekommen eigene Application Passwords, die einzeln widerrufen werden können, statt eines geteilten Kontos.

WAF und Rate Limiting an Login und Kasse. Begrenzungen gehören an den Netzwerkrand, nicht in PHP: Wenn der Anfragestrom erst WordPress startet, ist die Last bereits entstanden. Für wp-login.php und xmlrpc.php ist eine Regel pro IP sinnvoll, die nach wenigen fehlgeschlagenen Versuchen pro Minute blockiert, mit ansteigender Sperrdauer bei Wiederholung; der genaue Schwellenwert wird an der gemessenen Grundlast kalibriert, damit Filialteams mit gemeinsamer Ausgangs-IP nicht ausgesperrt werden. Die Kasse braucht eine eigene Regel. Kartentester bestellen dort in schneller Folge günstige Artikel, um gestohlene Kartennummern zu prüfen, und treffen dabei ?wc-ajax=checkout, ?wc-ajax=update_order_review und die Store-API-Route für den Checkout. Sichtbar wird das an vielen abgelehnten Zahlungen aus wenigen Netzen, an wiederholten Kartennummern mit gleicher BIN und an einer plötzlich abweichenden Quote zwischen Zahlungsversuchen und abgeschlossenen Bestellungen. Gegenmaßnahmen sind Rate Limiting pro IP und pro Sitzung, Bot-Erkennung am Netzwerkrand, eine Begrenzung der Zahlungsversuche pro Warenkorb, eine Obergrenze für die Einlöseversuche bei Gutscheincodes und ein Prüfmechanismus wie Turnstile, der erst bei Verdacht greift, statt jeden Käufer auszubremsen. Bei den Gateways selbst werden Regeln für Betrugserkennung und 3DS-Erzwingung aktiviert, damit die Abwehr nicht allein auf dem Shop liegt.

Anzeichen einer Kompromittierung. Es gibt eine überschaubare Reihe von Signalen, die regelmäßig geprüft werden sollte: neue Konten mit Administrator- oder Shop-Manager-Rolle ohne zugehörige Freigabe, unbekannte geplante Aufgaben in wp cron event list, Abweichungen bei wp core verify-checksums und wp plugin verify-checksums --all, PHP-Dateien im Upload-Verzeichnis, unerwartete Dateien in mu-plugins, geänderte Werte der Optionen siteurl und home, obfuskierter Code mit eval und base64_decode in Theme-Dateien sowie kürzlich veränderte Dateien, die sich über find mit der Option -mtime und einen Abgleich gegen den Git-Stand herausziehen lassen. Zwei Muster sind für Shops besonders relevant. Erstens Cloaking: Besucher mit Suchmaschinen-Referrer werden auf Spam-Domains umgeleitet, während der eingeloggte Betreiber eine saubere Seite sieht. Zweitens ein Skimmer im Checkout, also ein zusätzliches Inline-Skript oder eine fremde Domain im Zahlungsformular, das Karten- und Adressdaten mitschneidet; ein Blick in die geladenen Ressourcen der Kassenseite und eine Content-Security-Policy mit Berichtsfunktion machen so etwas sichtbar.

Vorgehen im Ernstfall. Die Reihenfolge entscheidet. Zuerst Beweise sichern, also ein vollständiges Abbild von Dateien und Datenbank plus Webserver-, PHP- und WAF-Logs wegschreiben, bevor irgendetwas bereinigt wird, sonst lässt sich der Einstiegspunkt später nicht mehr bestimmen. Dann eindämmen: Wartungsmodus oder Sperrung der schreibenden Pfade, alle Sitzungen über wp user session destroy --all beenden, Passwörter und Application Passwords zurücksetzen, Salts in der wp-config.php neu erzeugen, Gateway-Schlüssel und WooCommerce-REST-Keys rotieren. Danach wiederherstellen, und zwar aus einem Stand vor dem Vorfall statt per Handreinigung, weshalb Sicherungen nach der 3-2-1-Regel vorliegen müssen: drei Kopien, zwei verschiedene Medien, eine ausgelagert und schreibgeschützt. Bestellungen und Kundendaten, die nach dem Sicherungszeitpunkt entstanden sind, werden getrennt und geprüft nachgezogen. Erst wenn die Ursache behoben ist, also die veraltete Erweiterung, die gestohlenen Zugangsdaten oder das zu weit gefasste Schreibrecht, geht der Shop zurück in den Betrieb. Die Nachbereitung wird schriftlich festgehalten, mit den daraus folgenden Änderungen an Rollen, Auslieferung und Regelwerk. Welche Reaktions- und Erreichbarkeitszeiten dabei gelten, regelt der Wartungsvertrag.

Meldepflicht nach DSGVO. Werden personenbezogene Daten betroffen, greift Art. 33 DSGVO: Der Verantwortliche meldet die Verletzung der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Für ein Unternehmen mit Sitz in Essen ist das die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen. Bei voraussichtlich hohem Risiko kommt nach Art. 34 die Benachrichtigung der betroffenen Personen dazu; ein Skimmer, der Zahlungs- und Adressdaten abgreift, fällt in aller Regel darunter. Auch Verletzungen, die nicht gemeldet werden, sind nach Art. 33 Abs. 5 zu dokumentieren. Wer als Dienstleister am Shop arbeitet, ist Auftragsverarbeiter und meldet einen erkannten Vorfall unverzüglich an den Verantwortlichen, nicht selbst an die Behörde. Damit diese Meldung überhaupt inhaltlich möglich ist, braucht es vorher zwei Dinge: eine Protokollierung mit ausreichender Aufbewahrungsdauer, aus der sich Umfang und Kreis der Betroffenen ableiten lassen, und einen Auftragsverarbeitungsvertrag mit Hoster, Zahlungsdienstleister und Wartungsdienstleister, in dem die Meldewege benannt sind. Beides wird beim Aufsetzen des Shops geklärt und nicht am Tag des Vorfalls.

#WordPress in weiteren Städten

Ruhrgebiets-Shops mit B2B-Bestellportalen und Carrier-Anbindung ähneln technisch oft Projekten aus unserer WordPress-Entwicklung in Duisburg.

#Starten Sie Ihr Projekt in Essen

Wenn Ihr Unternehmen in Essen einen WooCommerce-Shop neu bauen, sanieren oder erweitern will, beginnen wir mit einer unverbindlichen Bestandsaufnahme: aktuelle Situation, Ziele, technische und rechtliche Anforderungen. Daraus entsteht eine ehrliche Einschätzung dessen, was nötig ist, mit schriftlichen Annahmen und messbaren Abnahmekriterien. Die Vergütung ist projektabhängig und wird individuell kalkuliert.