WooCommerce Entwickler in Dresden

WooCommerce-Entwicklung für Händler in Dresden, von der Elbe bis ins Umland von Silicon Saxony. Wir bauen und reparieren Online-Shops, die deutsche Zahlungs- und Versandgewohnheiten ernst nehmen und Updates überstehen, statt bei jedem Woo-Release zu brechen.

#WooCommerce-Entwicklung in Dresden

Dresden ist nicht nur Frauenkirche und Semperoper. Die Stadt ist das Herz von Silicon Saxony, dem größten Mikroelektronik-Cluster Europas, mit Infineon, GlobalFoundries, Bosch und ab 2027 dem ESMC-Werk von TSMC im Norden der Stadt. Rund um diese Fabs ist ein dichter Mittelstand aus Zulieferern, Maschinenbauern, Reinraumtechnik und spezialisiertem Handel gewachsen. Dazu kommen der gründergeprägte Bezirk Dresden-Neustadt, die Ausgründungen der TU Dresden und der Fraunhofer-Institute sowie ein klassischer sächsischer Einzelhandel, der online nachzieht. Diese Mischung prägt, welche Online-Shops in Dresden gebaut werden: technisch anspruchsvolle B2B-Kataloge neben markenstarken D2C-Shops.

Für all diese Händler gilt dasselbe: Der Shop muss in den deutschen Markt passen. Käufer in Sachsen erwarten Kauf auf Rechnung, PayPal und SEPA-Lastschrift, ein rechtssicheres Impressum, eine korrekte Widerrufsbelehrung und einen Checkout, der die Datenschutz-Grundverordnung (DSGVO) nicht nur im Cookie-Banner, sondern in der Architektur respektiert. Genau dort setzt unsere Arbeit an.

#Was wir für Dresdner Shops bauen

• Checkout-Flows, die deutsche Bezahlrealität abbilden: Kauf auf Rechnung als Standard-Erwartung, PayPal und PayPal Pay Later, Klarna, SEPA-Lastschrift, giropay und Kartenzahlung über Stripe oder Mollie, jeweils mit sauberer 3DS- und PSD2-Logik
• Versandkonfiguration für die typischen deutschen Carrier: DHL (Leipzig/Halle ist DHLs drittes globales Drehkreuz und liegt vor der Haustür), DPD und Hermes, mit Zonen, Gewichts- und Sperrgutregeln, Packstation-Adressen und Echtzeit-Sendungsverfolgung
• Anbindung an Warenwirtschaft und Buchhaltung im Mittelstand: DATEV-konforme Rechnungsexporte, Schnittstellen zu JTL-Wawi, plentymarkets oder Afterbuy und Produktdaten-Sync aus ERP-Systemen mit Konfliktlösung und Bestandsabgleich
• B2B-Funktionen für die Zulieferlandschaft rund um Silicon Saxony: kundenspezifische Netto-Preise und Staffelpreise, Mindestbestellmengen, Angebotsanfrage-Workflows, Freigabeprozesse und getrennte Geschäftskundenportale
• Abo- und Mitgliedschaftslogik mit wiederkehrender Abrechnung, dabei vorbereitet auf die ab 20. November 2026 greifende EU-Verbraucherkreditrichtlinie, die das 200-Euro-Limit für Buy-Now-Pay-Later beendet und für jede Ratenzahlung eine Bonitätsprüfung verlangt
• Mehrsprachige und mehrwährungsfähige Shops, wenn Dresdner Hersteller nach Tschechien, Polen oder in den DACH-Raum exportieren, mit WPML, lokalisiertem Checkout und korrekter Steuerzuordnung

#Der Markt in Dresden, und was er für den Shop bedeutet

Wer in Dresden einen Online-Shop betreibt, hat selten ein reines Werbeproblem. Häufiger ist es ein Vertrauens- und Konformitätsproblem. Deutsche Käufer brechen ab, wenn der Bezahlteil unvollständig wirkt: kein Kauf auf Rechnung, kein sichtbares Trusted-Shops-Siegel, eine Widerrufsbelehrung, die im Footer versteckt ist. Laut Statista hat PayPal in Deutschland eine sehr hohe Nutzung, und der Rechnungskauf bleibt eine der meistgenutzten Bezahlarten überhaupt. Ein Shop, der diese beiden Wege nicht sauber anbietet, verliert Umsatz, bevor das Marketing überhaupt greift.

Bei B2B-Händlern aus dem Halbleiter- und Maschinenbau-Umfeld sieht das Bild anders aus. Hier zählt nicht der hübsche Warenkorb, sondern dass der Shop Netto-Preise, projektbezogene Freigaben und die Anbindung an die interne Warenwirtschaft korrekt abbildet. Ein Beschaffungsverantwortlicher bei einem Zulieferer will eine Bestellung auslösen, die ohne manuelle Nacharbeit in die Buchhaltung läuft. Diese beiden Welten, schneller D2C-Checkout und integrationsschwerer B2B-Prozess, brauchen unterschiedliche technische Entscheidungen, auch wenn beide auf WooCommerce laufen.

Ein dritter Punkt ist saisonal: Mit den großen Industrieansiedlungen wächst die Kaufkraft in der Region, und viele lokale Marken (von der Manufaktur über den Spezialhandel bis zum Tourismusgeschäft rund um die Altstadt) skalieren ihren Online-Vertrieb erst jetzt ernsthaft. Wer aus einem gewachsenen, organisch erweiterten Shop kommt, hat oft eine Sammlung halb passender Plugins angehäuft, die sich gegenseitig blockieren. In solchen Fällen ist die erste Aufgabe nicht Neubau, sondern Aufräumen: Plugin-Last reduzieren, Datenmodell begradigen und die Bezahl- und Versandlogik wieder auf einen wartbaren Stand bringen.

#Technischer Aufbau

Unsere typische Basis: WooCommerce auf aktuellem PHP, Objekt-Caching über Redis, eine schnelle Produktsuche, ein CDN vor dem Shop und ein bewusst schlankes Theme statt eines überladenen Page-Builders. Zahlungen laufen über die jeweils passenden Gateways mit 3D Secure 2. Hintergrundprozesse wie Bestell-E-Mails, ERP-Sync und Rechnungserstellung laufen über den Action Scheduler, damit sie den Checkout nie blockieren. Anpassungen entstehen über Action- und Filter-Hooks in einem eigenen Plugin, nicht durch Eingriffe in den WooCommerce-Kern, denn der Shop eines Dresdner Händlers muss das nächste Woo-Update ohne Drama überleben.

#Wie ein Projekt abläuft

1. Audit und Bestandsaufnahme. Wir analysieren den bestehenden Shop oder das Vorhaben: Produktstruktur, Checkout, aktive Zahlungsarten, Versandzonen, Steuerregeln, vorhandene Integrationen und eine Lighthouse-Messung auf den meistbesuchten Produkt- und Kategorieseiten. Technische Schulden und schnelle Verbesserungen werden schriftlich dokumentiert, bevor Code entsteht.
2. Plan für Payment, Versand und Integration. Wir legen fest, welche Gateways aus deutscher Käufersicht Pflicht sind, wie Versand und DHL-Anbindung aussehen, wie die Warenwirtschaft angebunden wird und wo die Grenze zwischen Kern, Plugin-Code und Theme verläuft.
3. Umsetzung in Feature-Branches. Entwicklung nach den Coding Standards von WordPress und WooCommerce, mit Tests auf den Zahlungs- und Bestellpfaden, in nachvollziehbaren Iterationen mit lauffähigem Stand am Ende jedes Schritts.
4. QA gegen Testumgebung. Vollständiger Durchlauf auf einer produktionsnahen Testumgebung: Warenkorb, Checkout, Testzahlungen auf jedem Gateway, Rückerstattung, Kunden-E-Mails, Bestellbearbeitung im Admin. Erst danach geht es live.
5. Go-live und Übergabe. DNS, SSL, Cache-Warmup, Redirect-Prüfung und Monitoring. Nach dem Start bleiben wir in Bereitschaft für die erste kritische Phase und übergeben mit dokumentierten Runbooks für jedes Gateway.

#Probleme, mit denen Dresdner Händler zu uns kommen

• Der Checkout ist langsam oder bricht ab. Häufig liegt es an Cart-Fragments, einem schweren Theme oder zu vielen synchron geladenen Gateway-Skripten. Wir messen den echten Engpass und beheben ihn, statt ein weiteres Optimierungs-Plugin zu stapeln.
• Kauf auf Rechnung und SEPA fehlen oder funktionieren halb. Wir richten die in Deutschland erwarteten Bezahlwege sauber ein, inklusive Fehlerpfaden, Webhooks und Idempotenz, damit Doppelbuchungen ausgeschlossen sind.
• Die Buchhaltung passt nicht zum Shop. DATEV-Export, korrekte Rechnungsnummern, MwSt.-Logik und der innergemeinschaftliche EU-Handel über das OSS-Verfahren werden so konfiguriert, dass die Steuerberatung nicht jeden Monat nacharbeiten muss.
• Rechtliche Unsicherheit. Impressum, Widerrufsbelehrung, Preisangabenverordnung und DSGVO-konformes Einwilligungsmanagement gehören in die Shop-Architektur, nicht in eine nachträgliche Bastelei.

#Was Sie als Ergebnis erwarten können

Wir vereinbaren die Erfolgskriterien vor Projektbeginn schriftlich, statt mit erfundenen Prozentwerten zu werben. Üblich sind: spürbar schnellere Produkt- und Kategorieseiten mit optimierter Bildauslieferung in WebP und AVIF, ein Checkout, der die in Deutschland erwarteten Bezahlarten vollständig und stabil anbietet, sowie eine belastbare Infrastruktur für die Lastspitzen rund um Black Friday und das Weihnachtsgeschäft. Jede Kennzahl wird vor und nach der Umsetzung gemessen und in der Projektdokumentation festgehalten.

#Warum Händler in Dresden mit uns arbeiten

Wir sind seit Jahren aktiv in der WordPress- und WooCommerce-Community und bauen mit den Werkzeugen, über die andere nur lesen. Wir haben WooCommerce-Shops unterschiedlicher Größe und Lastprofile gebaut und kennen den Unterschied zwischen einem Shop, der gut aussieht, und einem, der in der deutschen Bezahlrealität wirklich konvertiert. Jede Architektur-Entscheidung wird begründet und dokumentiert, damit Ihr Team den Shop danach selbst weiterführen kann.

#Sicherheit und DSGVO-Konformität

Unsere Sicherheits-Baseline gilt für jedes Projekt: HTTPS mit HSTS, eine Content Security Policy gegen XSS, Schwachstellen-Scanning der Abhängigkeiten in der CI, Zwei-Faktor-Authentifizierung für alle Admin-Konten und getestete Backups. Da ein Shop personenbezogene Daten verarbeitet, gehört die DSGVO in die Architektur: ein Einwilligungsmanagement, das vor dem Setzen nicht-essenzieller Cookies greift, Auftragsverarbeitungsverträge mit allen Dienstleistern, Datensparsamkeit im Checkout und nachvollziehbare Löschkonzepte. Trusted-Shops-Anbindung und rechtssichere Pflichttexte (Impressum, Widerrufsbelehrung, AGB) werden technisch sauber eingebunden, nicht nur ins Theme kopiert.

#Performance-Engineering

Geschwindigkeit ist im Wettbewerb ein harter Faktor, gerade wenn ein Shop gegen Amazon-Gewohnheiten ankämpft. Unser Ansatz für WooCommerce in Dresden:

• Asset-Optimierung: responsive Bilder in WebP und AVIF, bereinigtes und routenweise gesplittetes CSS, Tree-Shaking und Code-Splitting beim JavaScript.
• Caching-Architektur: mehrstufig vom Browser-Cache über das CDN bis zum Objekt-Cache (Redis) und intelligent invalidierten Transients.
• Netzwerk-Optimierung: HTTP/3, Brotli-Kompression, gezielte Preconnect- und DNS-Prefetch-Hints.
• Rendering-Optimierung: Critical CSS inline, asynchrone Stylesheets, Lazy Loading von Bildern und Iframes.

Jede Entscheidung wird gemessen, der Vorher-Nachher-Stand dokumentiert und als Baseline beigelegt.

#Häufige Fragen aus Dresden

Bauen Sie auch B2B-Shops für Zulieferer im Silicon-Saxony-Umfeld? Ja. Netto-Preise, kundenspezifische Preislisten, Freigabeprozesse und die Anbindung an JTL-Wawi, plentymarkets oder ein ERP gehören zu unserem Standardrepertoire.

Können Sie einen bestehenden, langsamen Shop übernehmen? Ja. Wir beginnen mit einem Audit aus Lighthouse-, WP-CLI-Profil- und Query-Monitor-Lauf, finden den realen Engpass und beheben ihn gezielt, statt den Shop neu zu bauen, wo es nicht nötig ist.

Arbeiten Sie nur mit Unternehmen aus Dresden? Nein. Der Schwerpunkt liegt auf Sachsen und dem deutschen Markt, aber wir arbeiten deutschlandweit und für Exporteure auch grenzüberschreitend. Gerade Hersteller aus dem Großraum Dresden, deren Märkte bis Tschechien und Polen reichen, profitieren von einem Shop, der mehrere Sprachen, Währungen und Steuerlogiken sauber trennt.

Wie gehen Sie mit der neuen BNPL-Regulierung um? Ab dem 20. November 2026 fällt durch die EU-Verbraucherkreditrichtlinie das bisherige 200-Euro-Limit für Buy-Now-Pay-Later weg, jede Ratenzahlung wird kreditprüfungspflichtig. Wir konfigurieren Klarna und PayPal Pay Later so, dass die geänderten Anforderungen am Checkout korrekt greifen, ohne dass dabei die Conversion unnötig leidet.

#Lokaler Kontext, am Thema WooCommerce orientiert

Der Bezug zu Dresden und Silicon Saxony ist kein Dekor, sondern entscheidet über technische Prioritäten: Ein B2B-Zulieferer braucht eine andere Checkout- und Integrationslogik als ein D2C-Shop aus der Neustadt, und beide brauchen die deutsche Bezahl- und Rechtsbasis. Wir halten die Seite und das Projekt bei WooCommerce: klare Ist-Analyse, schriftliche Annahmen, messbare Abnahmekriterien und ein nachvollziehbarer Lieferweg.

#Große Kataloge und viele Varianten technisch beherrschen

Variable Produkte sind der häufigste Grund, warum eine Produktseite in einem gewachsenen Katalog langsam wird. WooCommerce speichert jede Ausprägung als eigenen Beitrag vom Typ product_variation, mit eigenem Preis, eigenem Bestand, eigener SKU und eigenen Attributwerten. Führt ein Zulieferer eine Dichtung in acht Durchmessern, sechs Werkstoffen und drei Härtegraden, ergeben sich allein für diesen einen Artikel 144 Variationen in der Datenbank. Beim Aufbau der Produktseite ruft der Kern WC_Product_Variable::get_available_variations() auf und lädt dafür jede Variation als vollständiges Objekt samt Metadaten. Der PHP-Speicherbedarf steigt linear mit der Variantenzahl, und der komplette Variationsdatensatz landet als JSON im Markup. Damit wächst das HTML-Dokument, der Largest Contentful Paint rutscht über die Schwelle von 2,5 Sekunden und die Interaction to Next Paint über 200 Millisekunden, sobald der Käufer die erste Auswahl trifft.

Der erste Hebel ist der Schwellenwert für das Nachladen der Variationen. Der Filter woocommerce_ajax_variation_threshold liegt im Standard bei 30. Oberhalb dieses Werts holt das Variationsformular die passende Ausprägung per AJAX nach, statt alles vorab auszuliefern. In großen Katalogen ist es fast immer richtig, diesen Wert zu senken, statt ihn anzuheben, denn der Käufer wählt ohnehin nur eine Kombination. Der zweite Hebel ist der Preis-Cache: die Preisspanne eines variablen Produkts wird als Transient abgelegt, dessen Schlüssel über woocommerce_get_variation_prices_hash gebildet wird. Wer diesen Hash mit kundenindividuellen Preisen anreichert, wie es B2B-Plugins gern tun, erzeugt pro Kunde und Produkt eine eigene Zeile in wp_options. Ein Katalog mit fünfstelliger Variantenzahl und mehreren hundert Preisgruppen sprengt so die Options-Tabelle, und automatisch mitgeladene Optionen verlangsamen jede einzelne Anfrage. Die Gegenmaßnahmen sind eine kontrollierte Invalidierung über wc_delete_product_transients(), ein persistenter Objekt-Cache in Redis statt der Datenbank und ein regelmäßiges Aufräumen abgelaufener Transients.

Attribute und Filter gehören in Lookup-Tabellen, nicht in Meta-Abfragen. Eine Filterleiste, die über meta_query auf wp_postmeta sucht, erzeugt pro Filterkriterium einen zusätzlichen JOIN auf eine Tabelle, die in einem großen Shop schnell Millionen Zeilen hat. Der Index auf meta_key und einem Präfix von meta_value hilft dabei nur begrenzt, und bei drei aktiven Filtern und zusätzlicher Sortierung nach Preis wird die Abfrage zum Engpass der Kategorieseite. Richtig ist die Kombination aus globalen Attributen als Taxonomien mit dem Präfix pa_, der Produktattribut-Lookup-Tabelle wc_product_attributes_lookup und der Meta-Lookup-Tabelle wc_product_meta_lookup. Die Attribut-Tabelle beantwortet die Filterung über eine Taxonomie-Spalte und die Produkt-ID und hält zusätzlich fest, ob ein Term am Produkt oder an einer Variation hängt und ob er lieferbar ist. Damit lassen sich Lagerfilter und Zählwerte für die Facettennavigation berechnen, ohne für jede Kachel den Bestand nachzuschlagen. Die Meta-Lookup-Tabelle liefert Mindest- und Höchstpreis, Bestandsstatus, Bewertungsdurchschnitt und Verkaufszahl als eigene Spalten, also genau die Felder, nach denen sortiert wird. Aktiviert wird die Attribut-Tabelle in den WooCommerce-Einstellungen, der Neuaufbau läuft über die Werkzeuge im Bereich Status als Hintergrundprozess. Nach jedem größeren Import gehört eine Konsistenzprüfung dazu, sonst zeigt die Filterleiste Produkte an, die es in dieser Kombination nicht mehr gibt. Ob die Arbeit wirkt, messen wir an der Auslieferungszeit der Kategorieseite, erhoben mit curl über die Option -w und die Variable time_starttransfer, jeweils mit und ohne aktive Filter.

Import und Aktualisierung mehrerer tausend Positionen laufen über eine Warteschlange, nie über eine einzelne Anfrage. Der klassische Fehler ist ein Cronjob, der eine CSV mit fünftausend Zeilen in einem Durchlauf verarbeitet und am PHP-Zeitlimit mitten im Katalog abbricht, mit halb aktualisierten Preisen. Der Ablauf, den wir stattdessen aufsetzen, sieht anders aus: Die Quelldatei oder der ERP-Export wird zuerst nur eingelesen und in Pakete von 50 bis 200 Positionen zerlegt. Jedes Paket wird als eigene Aufgabe über den Action Scheduler eingeplant, mit as_enqueue_async_action() für den sofortigen Lauf oder as_schedule_single_action() für ein Zeitfenster außerhalb der Hauptlast, jeweils mit einer eigenen Gruppe, damit sich Importläufe im Admin trennen lassen. Abgearbeitet wird die Warteschlange über einen Systemcron, der wp action-scheduler run mit Begrenzung auf Gruppe und Stapelgröße aufruft, nicht über WP-Cron, das vom Besucherverkehr abhängt. Innerhalb eines Pakets schalten wir die Term-Zählung mit wp_defer_term_counting( true ) ab und stellen sie am Ende des Laufs wieder her, sonst wird nach jeder Zuordnung die komplette Taxonomie neu gezählt. Für jede Position wird ein Prüfwert über die relevanten Felder gebildet und mit dem gespeicherten Wert verglichen, sodass unveränderte Artikel gar nicht erst geschrieben werden. Das reduziert die Schreiblast auf die tatsächlich geänderten Zeilen, und der nächtliche Lauf bleibt auch bei wachsendem Katalog planbar. Fehlerhafte Positionen werden je SKU protokolliert und übersprungen, statt den gesamten Lauf abzubrechen. Wer über die REST-Schnittstelle importiert, arbeitet mit dem Batch-Endpunkt für Produkte und beachtet, dass die Anzahl der Elemente pro Anfrage über woocommerce_rest_batch_items_limit begrenzt ist.

Bestandsführung wird kritisch, sobald mehrere Kanäle gleichzeitig verkaufen. Verkauft ein Händler parallel im eigenen Shop, über einen Marktplatz und im Ladengeschäft in der Altstadt, konkurrieren mehrere Systeme um denselben Lagerbestand. Der technische Kernfehler ist das Muster Lesen, Rechnen, Schreiben: Wer den Bestand in PHP ausliest, eins abzieht und den neuen Wert zurückschreibt, verliert bei gleichzeitigen Bestellungen Buchungen. Richtig ist die atomare Änderung über wc_update_product_stock() mit der Operation für Verringerung oder Erhöhung, die den Wert direkt in der Datenbank verrechnet. Dazu kommen vier organisatorische Festlegungen, die wir vor dem Code schriftlich klären. Erstens: Welches System führt den Bestand je Artikelgruppe, das ERP oder der Shop? Zweitens: Wie lange hält eine unbezahlte Bestellung Ware zurück? Gesteuert wird das über die Option woocommerce_hold_stock_minutes, im Standard 60 Minuten. Drittens: Werden Änderungen per Webhook gemeldet oder in festen Intervallen abgeholt? Jede Meldung trägt dabei eine Idempotenzkennung und einen Zeitstempel, damit ein verspätet eintreffendes älteres Paket keinen neueren Stand überschreibt. Viertens: Was passiert bei Unterdeckung, also Rückstandsbestellung, Sperrung des Artikels oder Umschaltung auf Anfrage?

Dazu gehört ein Abgleichlauf außerhalb der Geschäftszeiten, der den vollständigen Bestandsstand beider Systeme vergleicht und Abweichungen protokolliert, statt sie stillschweigend zu überschreiben. Ergänzend prüfen wir vor der Bestellauslösung erneut die Verfügbarkeit im Warenkorb, damit ein Käufer nicht bezahlt, was in der Zwischenzeit ein anderer Kanal verkauft hat. Für welche dieser Bausteine ein Shop Bedarf hat, entscheiden Katalogtiefe, Kanalanzahl und Bestellvolumen, und der Aufwand wird individuell kalkuliert.

#Projekt in Dresden starten

Wenn Sie in Dresden oder Umgebung WooCommerce-Entwicklung brauchen, melden Sie sich für ein unverbindliches Erstgespräch. Wir sehen uns Ihre Situation an, klären Ziele, Zeitrahmen und Rahmenbedingungen und geben eine ehrliche Einschätzung. Die Preisgestaltung ist individuell und richtet sich nach Umfang und Integrationstiefe. Jedes gute Projekt beginnt mit klarer Kommunikation und gemeinsamen Erwartungen.