WooCommerce Entwickler in Augsburg

Augsburg ist eine Industrie- und Ingenieurstadt, und genau das prägt die WooCommerce-Projekte, die hier entstehen. Zwischen KUKA, MAN Energy Solutions, Premium AEROTEC und einem dichten schwäbischen Mittelstand aus Maschinenbauern, Metallverarbeitern und Zulieferern verkaufen viele Augsburger Shops keine Lifestyle-Artikel, sondern Ersatzteile, technische Komponenten und Verschleißteile an andere Unternehmen. Diese Art von Shop hat andere Anforderungen als ein klassischer B2C-Onlineshop, und darauf richtet sich diese Seite aus.

#WooCommerce-Entwicklung in Augsburg

Ein typischer Augsburger Fall: Ein Familienbetrieb aus der Region, der seit Jahrzehnten Maschinen baut oder Bleche verarbeitet, will sein Ersatzteilgeschäft online stellen. Der Katalog hat 4.000 Artikel mit Maßvarianten, technischen Zeichnungen und kundenspezifischen Preisen, das ERP ist ein älteres Sage- oder DATEV-gekoppeltes System, und die Stammkunden bestellen seit Jahren per Telefon und Kauf auf Rechnung. Genau hier scheitern Template-Shops: Sie sind für Mode und Konsumgüter gebaut, nicht für einen B2B-Teilekatalog mit Netto-Preisen, Mengenstaffeln und Rechnungskauf. WooCommerce lässt sich auf diesen Fall sauber zuschneiden, wenn man die Logik über Hooks baut statt über ein überladenes Plugin-Bündel.

#Was wir für Augsburger Shops bauen

• Produktdaten-Synchronisation aus ERP- und Warenwirtschaftssystemen (Sage, DATEV-gekoppelte Lager, CSV-Feeds von Zulieferern) mit geplanter Abgleichung, Konfliktlösung bei Preis- und Bestandsänderungen und sauberer Behandlung von Artikeln mit langen Maßvarianten-Listen
• B2B-Logik für den schwäbischen Mittelstand: rollenbasierte Netto-Preise, kundenspezifische Preislisten, Mengenstaffeln, Mindestbestellmengen und ein Angebotsanfrage-Workflow für Teile, die nicht im Standardkatalog stehen
• Kauf auf Rechnung als erste Zahlungsart, weil B2B-Stammkunden in Deutschland selten mit Karte zahlen, ergänzt um SEPA-Lastschrift und die gängigen Gateways
• Versandlogik für sperrige und schwere Industriegüter: gewichts- und maßbasierte Zonentarife, Speditionsversand neben Paketdienst, DHL- und DPD-Anbindung mit Sendungsverfolgung
• WooCommerce REST-API-Erweiterungen, wenn der Katalog auch ein Außendienst-Tool, eine mobile Bestell-App oder ein angeschlossenes ERP bedienen muss
• DSGVO-konforme Auftrags- und Kundendatenverarbeitung, weil die Rechnungs- und Lieferdaten im B2B-Umfeld sensibel sind und in Deutschland ohnehin reguliert

#Der Markt in Augsburg

Augsburg ist Bayerns drittgrößte Stadt und ein traditionsreicher Industriestandort in der Region Schwaben. Die Stadt war im 19. Jahrhundert eines der führenden deutschen Zentren der Textilindustrie, und aus dieser Maschinenbau-Tradition sind Unternehmen wie KUKA (Industrieroboter), MAN Energy Solutions (Großmotoren) und Premium AEROTEC (Luftfahrtkomponenten) hervorgegangen. Rund um die Universität Augsburg und den Augsburg Innovationspark mit dem Technologiezentrum hat sich ein Cluster aus Leichtbau, Carbon- und Faserverbund, Mechatronik und Digitalisierung gebildet.

Für WooCommerce bedeutet das vor allem eines: Die spannenden Projekte sitzen im B2B-Bereich. Es sind die Zulieferer und Maschinenbauer aus dem Schwäbischen, die ihren Ersatzteil- und Komponentenvertrieb digitalisieren, sowie die mittelständischen Hersteller, die ihren Katalog vom PDF-Versand auf einen echten Shop umstellen. Daneben gibt es das übliche B2C-Geschäft (Manufaktur-Produkte, regionale Marken, Direktvertrieb), aber die technisch anspruchsvollen Aufträge entstehen dort, wo ein gewachsenes Industriegeschäft auf einen Onlineshop trifft.

#Zahlungsarten, die ein deutscher Shop wirklich braucht

In Deutschland entscheidet die Zahlungsart über die Conversion. Kauf auf Rechnung gilt im B2B als selbstverständlich und auch im B2C als wichtigstes Vertrauenssignal, oft über Klarna oder einen Rechnungsdienstleister mit Bonitätsprüfung. Dazu kommen PayPal, SEPA-Lastschrift und Kreditkarte, und je nach Zielgruppe giropay. Für jedes aktive Gateway dokumentiere ich die unterstützten Abläufe (Einmalzahlung, Rückerstattung, Teilerstattung, 3-D-Secure), eine Testkarten- und Testkonten-Matrix, die eingehenden Webhooks und die Idempotenz-Behandlung, damit Doppelbuchungen ausgeschlossen sind. Die End-to-End-Prüfung läuft über Warenkorb, Checkout, Zahlung, Bestellung, Kunden-E-Mail, Admin-Bearbeitung und Erstattung auf jedem Gateway, inklusive der Fehlerpfade.

#Rechtliche Pflichten im deutschen E-Commerce

Ein in Augsburg betriebener Shop muss die deutschen Vorgaben erfüllen, und das ist Teil der Umsetzung, kein Nachgedanke. Dazu gehören ein vollständiges Impressum nach DDG, eine rechtssichere Widerrufsbelehrung mit Muster-Widerrufsformular, korrekte Preisangaben nach der Preisangabenverordnung (Grundpreis, Versandkosten, Umsatzsteuer ausgewiesen), eine DSGVO-konforme Datenschutzerklärung und ein Cookie-Consent-Banner, das vor dem Setzen nicht notwendiger Cookies tatsächlich einholt statt nur zu informieren. Für Shops, die Vertrauen aufbauen müssen, lässt sich ein Gütesiegel wie Trusted Shops technisch sauber einbinden, samt Käuferschutz und Bewertungsfunktion. Diese Punkte landen als Abnahmekriterien in der Spezifikation, damit sie zum Start nachweisbar erfüllt sind.

#Wie ich an einem bestehenden langsamen Shop arbeite

Viele Augsburger Anfragen drehen sich nicht um einen Neubau, sondern um einen über Jahre gewachsenen WooCommerce-Shop, der zu langsam geworden ist. Der Einstieg ist immer eine Messung: ein Lighthouse-Lauf auf den meistbesuchten Produkt-, Kategorie- und Checkout-Seiten, ein WP-CLI-Profil und Query Monitor, um die tatsächlichen Engpässe zu finden. Häufig sind es autoloaded Options, die mit jedem Request geladen werden, langsame Plugin-Queries ohne Index, ein überladenes Theme mit Page-Builder oder die Cart-Fragments, die bei jedem Seitenaufruf feuern. Diese Ursachen behebe ich einzeln und messbar, statt ein weiteres Caching-Plugin obendrauf zu setzen, das das Problem nur verdeckt.

#Wie wir arbeiten

Jedes Projekt in Augsburg folgt einem nachvollziehbaren Ablauf, der vorne ansetzt:

1. Analyse und Audit, ich sehe mir den bestehenden Shop, das ERP, die Produktdatenquelle und die Geschäftsziele an, dokumentiere die technische Schuld und definiere messbare Erfolgskriterien, bevor die erste Zeile Code entsteht.
2. Spezifikation, auf Basis des Audits beschreibe ich Architekturentscheidungen, die Grenze zwischen Woo-Kern, eigenem Plugin und Theme, die Gateway-Wahl, die Versandlogik und die Integrationen, mit Zeitplan und Meilensteinen. Sie geben den Plan frei, bevor es losgeht.
3. Umsetzung in Iterationen, gearbeitet wird in ein- bis zweiwöchigen Sprints mit lauffähigem Stand am Ende jeder Iteration. Erweiterungen laufen über Action- und Filter-Hooks, der WooCommerce-Kern bleibt unangetastet, damit der Shop Updates übersteht.
4. Qualitätssicherung, jedes Ergebnis durchläuft Code-Review, automatisierte Tests, browserübergreifend- und Barrierefreiheitsprüfung sowie Messung gegen die vereinbarten Performance-Budgets.
5. Testumgebung-Abnahme und Übergabe, Sie testen die komplette Lösung mit echten Daten auf einer produktionsnahen Testumgebung, geben den Start frei, und erhalten eine dokumentierte Übergabe mit Runbooks für jedes Gateway und jede nicht-triviale Integration.

#Technische Herausforderungen, die in Augsburg typisch sind

• Große Industriekataloge mit Hunderten Maßvarianten je Artikel, gelöst über individuelle Produkttypen mit bedingter Logik und serverseitiger Preisberechnung, statt über Tausende einzelner Produkt-Datensätze, die den Shop ausbremsen
• ERP-Anbindung an Systeme, die nie für E-Commerce gedacht waren, gelöst über eine saubere Sync-Schicht mit Konfliktbehandlung und Protokollierung, damit Bestand und Preise verlässlich bleiben
• Steuer- und Rechnungslogik im grenzüberschreitenden EU-Handel, gelöst über korrekte Umsatzsteuer-Behandlung, das OSS-Verfahren und konforme Rechnungserzeugung pro Bestellung

#Performance-Engineering

Geschwindigkeit zahlt direkt auf den Umsatz ein, gerade bei B2B-Shops, deren Einkäufer unter Zeitdruck bestellen. Mein Vorgehen für WooCommerce in Augsburg:

• Asset-Optimierung, Bilder als responsive Srcsets in WebP und AVIF, CSS bereinigt und routenweise gesplittet, kritisches CSS inline, JavaScript per Tree Shaking reduziert und über dynamische Imports geladen.
• Caching-Architektur, mehrstufig: Browser-Cache, CDN, Objekt-Cache (Redis) und Datenbankabfrage-Cache über Transients mit gezielter Invalidierung bei Preis- und Bestandsänderungen.
• Netzwerk-Optimierung, HTTP/3 mit QUIC, Brotli-Kompression, Preconnect- und DNS-Prefetch-Hinweise sowie Ressourcen-Priorisierung.
• Datenbank und Backend, Indizes auf die tatsächlich genutzten Meta-Queries, Entlastung der autoloaded Options und Reduktion der Cart-Fragment-Aufrufe.

Jede Entscheidung wird vorher und nachher gemessen und in die Projektdokumentation aufgenommen.

#Sicherheit und Konformität

Jeder Shop bekommt eine feste Sicherheits-Baseline: erzwungenes HTTPS mit HSTS, Content-Security-Policy-Header gegen XSS, Schwachstellen-Scan der Abhängigkeiten in der CI, Zwei-Faktor-Authentifizierung für Admin-Konten und getestete Backups. Da B2B-Shops Rechnungs-, Liefer- und Bonitätsdaten verarbeiten, sind DSGVO-konformes Einwilligungsmanagement, Auftragsverarbeitungsverträge mit eingebundenen Dienstleistern und eine Datensparsamkeit von Beginn an Pflicht, nicht Kür. Für laufend betreute Shops gibt es regelmäßige Sicherheitsreviews mit Abhängigkeits- und Zugriffs-Audit.

#Fragen, die uns Augsburger Unternehmen stellen

Können Sie unser bestehendes ERP anbinden? In den meisten Fällen ja. Entscheidend ist, welche Schnittstelle das System bietet (API, Export-Datei, Datenbankzugriff) und wie oft synchronisiert werden muss. Ich dokumentiere die Sync-Richtung, die Konfliktregeln bei Preis- und Bestandsänderungen und die Fehlerbehandlung, bevor die Integration gebaut wird.

Funktioniert Kauf auf Rechnung im Shop? Ja, und im B2B-Kontext ist das oft die wichtigste Zahlungsart. Je nach Risiko wird sie an eine Bonitätsprüfung gekoppelt oder für freigeschaltete Stammkunden direkt erlaubt. Die Logik dafür gehört zur rollenbasierten Kundenverwaltung.

Wie lange dauert ein Projekt? Das hängt vom Umfang, der Datenbereitschaft und der Integrationskomplexität ab. Ein überschaubarer Shop ist in einigen Wochen erledigt, ein B2B-Katalog mit ERP-Anbindung und individueller Preislogik braucht länger. Einen belastbaren Zeitplan gibt es nach der Analysephase, nicht vorher.

Was kostet die Umsetzung? Die Preisgestaltung ist individuell und richtet sich nach dem in der Spezifikation festgelegten Umfang. Sie erhalten eine nachvollziehbare Aufschlüsselung, bevor die Arbeit beginnt, und Umfangsänderungen werden offen mit ihren Folgen besprochen.

#Lokale Sichtbarkeit für Augsburger Shops

Ein technisch sauberer Shop nützt nur, wenn die Zielgruppe in Augsburg und der Region Schwaben ihn findet. Dazu gehört eine solide technische SEO-Basis (saubere URLs, XML-Sitemaps, korrekte Heading-Hierarchie, strukturierte Daten für Produkt, Organisation und lokale Geschäftsdaten), grüne Core Web Vitals, ein gepflegtes Google-Unternehmensprofil mit konsistenter Adresse, und für Hersteller, die über Augsburg hinaus in den DACH-Raum oder die EU verkaufen, hreflang und locale-spezifische Metadaten. SEO ist von der ersten Architekturentscheidung an mitgedacht, nicht nachträglich aufgesetzt.

#Wie Zahlung, Versand und Warenwirtschaft ineinandergreifen

Die Auswahl der Zahlungsarten ist weiter oben beschrieben, hier geht es um die Anbindungen dahinter. Ein Shop besteht in Deutschland nicht nur aus Katalog und Checkout, sondern aus vier Systemen, die zusammenspielen müssen: Zahlung, Versand, Warenwirtschaft und Buchhaltung. Jedes davon bringt eigene Pflichtfelder, eigene Fehlerpfade und eine eigene Vorstellung davon, wann eine Bestellung als bezahlt gilt. Genau an diesen Nahtstellen entstehen die Störungen, die im Support als “Bestellung ist verschwunden” oder “Rechnung fehlt im Steuerbüro” ankommen.

Jede Zahlungsart bringt einen eigenen Ablauf mit, nicht nur ein Häkchen im Backend. SEPA-Lastschrift braucht eine Gläubiger-Identifikationsnummer, eine eindeutige Mandatsreferenz je Kunde, den revisionssicher gespeicherten Mandatstext und eine Vorabankündigung, deren Frist im Mandat selbst festgelegt ist. Dazu gehört ein Ablauf für Rücklastschriften: Kommt die Buchung zurück, muss die Bestellung wieder in einen offenen Status fallen, der Kunde eine Aufforderung erhalten und die Buchhaltung die Rückbelastung sehen. PayPal trennt Autorisierung und Einzug, was bei Vorbestellungen und Teillieferungen relevant wird, und meldet den Abschluss über eigene Ereignisse zurück. Klarna führt eine zweite Bestellverwaltung auf Anbieterseite, in der Einzug, Teileinzug und Storno separat ausgelöst werden, üblicherweise beim Versand und nicht bei der Bestellung. Kreditkarte bringt 3-D-Secure 2 mit, also einen Zwischenschritt beim ausgebenden Institut, dessen Abbruch keinen Fehlerzustand im Shop erzeugen darf, sondern eine Zahlung, die der Kunde erneut anstoßen kann. Für jede aktive Zahlungsart gehören diese Abläufe samt Ablehnungsgründen ins Runbook, sonst bleibt dem Support nur Raten.

Versanddienstleister und Abholpunkte gehören in die Adresslogik, nicht in ein Zusatzfeld. Eine DHL Packstation ist keine Straßenadresse: Sie braucht die Postnummer des Empfängers und die Stationsnummer im Adressfeld, und beides muss vor der Erzeugung des Versandetiketts validiert werden, weil der Dienstleister sonst die Sendung ablehnt. DPD Pickup und Hermes PaketShop kennen jeweils eigene Kennungen für den Abholort. Die Checkout-Felder dafür kommen über den Filter woocommerce_checkout_fields dazu, die Validierung über woocommerce_after_checkout_validation. Ebenso wichtig ist der umgekehrte Fall: Für sperrige Industriegüter, die per Spedition auf Palette gehen, darf ein Abholpunkt gar nicht erst wählbar sein. Das lässt sich über woocommerce_package_rates lösen, indem unpassende Versandarten anhand von Gewicht, Maßen und Zielart aus der angebotenen Auswahl entfernt werden, bevor der Kunde eine unmögliche Kombination bestätigt. Versandetikett und Sendungsnummer laufen dann automatisiert: Die Trackingnummer wird als Bestell-Metadatum gespeichert und in die Versandbestätigung eingesetzt, damit niemand Nummern von Hand aus einem Dienstleisterportal kopiert.

Bei Warenwirtschaft und Buchhaltung muss feststehen, welches System den Vorrang hat. Vor der ersten Zeile Integrationscode wird pro Datenfeld festgelegt, welches System führt: Bestand und Einkaufspreise kommen typischerweise aus JTL-Wawi oder Xentral, Stammdaten und Bilder oft aus dem Shop, Kundendaten je nach Vertriebsstruktur aus dem einen oder anderen System. Führt die Warenwirtschaft ein Feld, wird es in WooCommerce schreibgeschützt oder zumindest sichtbar als “aus der Warenwirtschaft übernommen” markiert, sonst überschreibt der nächste Abgleich eine Handkorrektur und niemand versteht, warum. Auf der Buchhaltungsseite bedeutet DATEV-Anbindung mehr als eine CSV-Datei: Erlöskonten und Debitoren müssen auf den verwendeten Kontenrahmen abgebildet werden, üblicherweise SKR03 oder SKR04, dazu kommen die passenden Steuerschlüssel für Inlandsumsatz, innergemeinschaftliche Lieferung, Reverse-Charge und das OSS-Verfahren. Für den einfacheren Fall genügt die API von lexoffice, über die Rechnung und Zahlungszuordnung direkt angelegt werden. Technisch läuft der Abgleich als Warteschlange über den Action Scheduler statt innerhalb eines einzelnen Seitenaufrufs, WP-Cron wird auf einen echten Systemcron umgestellt und die Läufe sind über wp action-scheduler run und die Protokolle nachvollziehbar. Jede externe Belegnummer wird als Bestell-Metadatum gespeichert, damit ein wiederholter Lauf keine zweite Rechnung erzeugt.

Der Bestellstatus wird von der Server-zu-Server-Benachrichtigung gesetzt, nie von der Rückkehr auf die Bestätigungsseite. Die Rückleitung des Kunden aus der Banking-App oder vom Zahlungsanbieter ist ein Komfortweg, kein Zahlungsnachweis. Sie fällt aus, wenn der Kunde den Tab schließt, das Mobilnetz beim Wechsel zwischen App und Browser abbricht, ein Werbeblocker die Weiterleitung stoppt oder der Kunde die Zurück-Taste drückt. Wird der Status daran gehängt, entstehen bezahlte Bestellungen ohne Bestellung im Shop und unbezahlte Bestellungen, die als abgeschlossen gelten. Richtig ist ein eigener Endpunkt, den der Zahlungsanbieter direkt aufruft: Signatur oder HMAC prüfen, Bestellung über die Transaktionskennung laden, den Abschluss über payment_complete setzen und erst danach HTTP 200 zurückgeben. Die Verarbeitung muss idempotent sein, weil Anbieter dieselbe Benachrichtigung mehrfach zustellen, und sie muss mit vertauschter Reihenfolge umgehen können: Trifft die Meldung ein, bevor die Bestellung geschrieben wurde, ist ein 5xx die richtige Antwort, damit der Anbieter erneut zustellt. Sitzungsdaten und Cookies dürfen in diesem Endpunkt keine Rolle spielen, denn der Aufruf kommt von einem Server, nicht vom Browser des Kunden. Dazu gehört Betriebsarbeit: Der Endpunkt wird vom Seiten-Cache ausgenommen und darf nicht hinter einer Bot-Abwehr oder einer Cloudflare-Sicherheitsprüfung liegen, jeder Aufruf landet über WC_Logger in den WooCommerce-Protokollen, und ein Abgleichlauf meldet Bestellungen, die zu lange in einem offenen Zahlungsstatus hängen, zur manuellen Prüfung. Auch die Bestandsreduzierung hängt an diesem Punkt und nicht am Seitenaufruf, sonst räumt ein abgebrochener Checkout Lagerbestand ab, der nie verkauft wurde. Die Bestätigungsseite zeigt in dieser Architektur einen Zwischenstand und den Hinweis, dass die Bestätigung per E-Mail folgt, was fachlich korrekt ist und den Support entlastet.

#Wann ein WooCommerce-Projekt in Augsburg startet

Diese Seite bleibt beim Thema WooCommerce. Wenn in der Analyse eine andere Plattform sinnvoller wäre, sage ich das schriftlich, statt das Projekt zu erzwingen. Das Ergebnis ist immer ein klarer Plan: was geändert wird, was bleiben kann, was gemessen wird und was später kommt. Für Augsburger Unternehmen heißt das ein Shop, der zum vorhandenen ERP passt, die deutschen Rechtspflichten erfüllt, die richtigen Zahlungsarten anbietet und Woo-Updates übersteht.

Wenn Sie Ihren Ersatzteil- oder Komponentenvertrieb online stellen, einen gewachsenen Shop entlasten oder eine Migration auf eine wartbare Architektur planen, ist der erste Schritt ein Gespräch über Ihre Ziele, Ihr ERP und Ihre Rahmenbedingungen. Kein Verkaufsgespräch, sondern technische Beratung.