WooCommerce Entwickler in Karlsruhe

Karlsruhe gilt laut einer Studie der EU-Kommission als einer der stärksten IKT-Standorte Europas, direkt hinter München, Paris und London. In der Stadt und der TechnologieRegion sind rund 4.200 Software- und IKT-Unternehmen ansässig, von IONOS über Größen wie EnBW und dm bis zu hunderten kleinerer Software- und Handelsbetriebe. Für einen WooCommerce-Shop heißt das zweierlei: Die technische Messlatte ist hoch, und der Wettbewerb um Aufmerksamkeit im Netz ist real. Genau hier setzen wir an.

#WooCommerce-Entwicklung in Karlsruhe

Wir bauen und sanieren WooCommerce-Shops für Händler in Karlsruhe und der TechnologieRegion: Hersteller mit B2B-Katalog, Einzelhändler mit zweitem Online-Standbein, KIT- und FZI-nahe Ausgründungen, die ihr erstes Produkt direkt verkaufen wollen. Der gemeinsame Nenner ist selten ein neues Theme. Es ist ein Shop, der rechtssicher sein muss, deutsche Zahlarten sauber abrechnen soll und unter Last nicht einbricht.

Ein deutscher WooCommerce-Shop ist nie nur die Standardinstallation. Ohne Erweiterung fehlen die Pflichtangaben, die das deutsche Recht verlangt: Grundpreisangabe nach Preisangabenverordnung, korrekt verlinkte Widerrufsbelehrung, die nach BGB §355 in Textform mit der Bestellbestätigung zugehen muss, Bestätigungs-Checkbox für AGB und Widerruf im Checkout sowie eine MwSt-konforme Rechnung. In der Praxis lösen wir das mit Germanized oder German Market und prüfen anschließend jeden Bestellpfad gegen die tatsächlichen Texte, statt uns auf die Plugin-Standardeinstellung zu verlassen.

#Was wir für Karlsruher Shops konkret umsetzen

• Rechtssicherer Checkout für den deutschen Markt: Grundpreisangabe, Widerrufsbelehrung in Textform, AGB- und Widerruf-Bestätigung, doppelte Preisanzeige inklusive und exklusive Steuer, abgesicherte Bestellbestätigungsmail
• Integration der hierzulande erwarteten Zahlarten: Klarna (Rechnung und Ratenkauf), PayPal, SEPA-Lastschrift sowie Kartenzahlung über Stripe oder Mollie, jeweils mit Webhook-Handling und Abgleich der Bestellzustände
• Versandlogik für DHL, DPD und Hermes: Versandzonen, Gewichts- und Maßstaffeln, Aufpreis für Sperrgut, Click-and-Collect für Händler mit Ladengeschäft in der Innenstadt oder in Durlach
• Trusted-Shops-Anbindung samt Käuferschutz und Bewertungswidget, weil dieses Vertrauenssignal im deutschen Handel weiterhin Conversion bringt
• Anbindung an Warenwirtschaft und Buchhaltung: Produkt- und Bestandssynchronisation mit ERP-Systemen, CSV-Lieferantenfeeds und Schnittstellen wie JTL oder DATEV-Export für den Steuerberater
• B2B-Funktionen für Hersteller in der Region: kundengruppenbasierte Netto-Preise, Mindestbestellmengen, Angebotsanfrage statt Sofortkauf und ein eigener Bereich für Geschäftskunden
• Erweiterung der WooCommerce REST API für Headless-Storefronts, mobile Apps oder Kassensysteme, wenn der Shop über die klassische Theme-Auslieferung hinauswachsen soll

#Warum die Marktlage in Karlsruhe den Anspruch verändert

Karlsruhe hat eine ungewöhnlich dichte Tech-Infrastruktur. Das KIT und das FZI Forschungszentrum Informatik bringen Jahr für Jahr Informatik-Absolventen und Ausgründungen hervor, das CyberForum e.V. vernetzt als großes regionales Hightech-Unternehmernetzwerk über tausend Mitglieder, und Gründerzentren wie die Technologiefabrik Karlsruhe haben hunderte Unternehmen begleitet. Wer hier einen Shop betreibt, hat es entweder mit technisch versierten Kunden zu tun oder mit Wettbewerbern, die ihre Plattform ernst nehmen.

Für die Praxis bedeutet das: Ein Shop, der drei Sekunden zum Laden braucht oder dessen Checkout an einer fehlenden Pflichtangabe scheitert, fällt in diesem Umfeld schneller auf. Die meisten Anfragen, die uns aus der Region erreichen, kommen nicht von Neugründungen, sondern von Händlern mit einem über Jahre gewachsenen Shop, der inzwischen langsam, schwer wartbar oder abmahngefährdet geworden ist. Dort beginnt die Arbeit mit Aufräumen, nicht mit Neubau.

#Technische Grundlage

Wir setzen WooCommerce auf aktuellem PHP mit Objekt-Cache (Redis) ein, ergänzen die Produktsuche bei großen Katalogen über eine dedizierte Such-Engine und nutzen für Hintergrundarbeit wie Bestandssync oder Versandlabels den Action Scheduler statt blockierender Prozesse. Zahlungsabwicklung läuft über die jeweilige Gateway-Bibliothek mit 3D-Secure-2-Pflicht (SCA) gemäß PSD2. Anpassungen entstehen grundsätzlich über Action- und Filter-Hooks und ein eigenes Plugin, nie durch Eingriffe in den WooCommerce-Kern, damit Plattform-Updates den Shop nicht zerlegen.

#Wie ein Projekt abläuft

1. Bestandsaufnahme und Audit, wir sichten den bestehenden Shop: Produkt-Taxonomie, Checkout-Strecke, aktive Zahlarten, Versandzonen, Steuerregeln, Plugin-Last und eine Lighthouse-Baseline auf den meistbesuchten Produkt- und Kategorieseiten. Parallel prüfen wir die rechtlichen Pflichtangaben, da hier in gewachsenen Shops die häufigsten Lücken sitzen.
2. Spezifikation, auf Basis des Audits entsteht ein konkreter Plan mit Architekturentscheidungen, Gateway- und Versandwahl, Integrationsgrenzen und der klaren Trennlinie zwischen Woo-Kern, eigenem Plugin und Theme. Sie geben den Plan frei, bevor entwickelt wird.
3. Umsetzung in Feature-Branches, nach den Coding Standards von WordPress und WooCommerce, mit Tests auf den Zahlungs- und Bestellpfaden.
4. Prüfung auf Testumgebung, die vollständige Lösung läuft auf einer produktionsnahen Testumgebung. Sie testen mit echten Inhalten, wir spielen jeden Bestellpfad mit Testkarten und Testbestellungen durch.
5. Go-live und Übergabe, DNS, SSL, Cache-Warmup, Redirect-Prüfung und Monitoring; danach bleiben wir für die ersten Tage nach dem Start für sofortige Korrekturen erreichbar.

#Häufige Probleme, die wir lösen

Diese drei Themen tauchen in Karlsruher Shops immer wieder auf:

• Abmahnrisiko durch fehlerhaften Checkout, etwa fehlende Grundpreise, eine nicht in Textform zugestellte Widerrufsbelehrung oder unklare Versandkostenangaben. Wir bringen die Pflichtangaben in Ordnung und dokumentieren, welche Texte wo greifen.
• Steuer im grenzüberschreitenden EU-Handel, wir konfigurieren die automatische Steuerberechnung und das OSS-Verfahren für Verkäufe in andere EU-Länder, damit die Rechnung pro Zielland korrekt ausfällt.
• Komplexe Produkte mit vielen Varianten, etwa konfigurierbare Industrieteile oder Bündel. Wir bauen eigene Produkttypen mit bedingter Logik und Live-Preisberechnung, die auch bei vielen Kombinationen nicht ins Stocken geraten.

#Was am Ende messbar ist

Erfolg definieren wir vor Projektbeginn gemeinsam. Statt pauschaler Versprechen vereinbaren wir konkrete, prüfbare Ziele, zum Beispiel:

• spürbar höhere Abschlussquote im Checkout durch verschlankte Formulare, Express-Zahlarten und einen funktionierenden Gast-Checkout
• kürzere Ladezeiten auf Produkt- und Kategorieseiten durch optimierte Bildauslieferung, Lazy-Loading unterhalb des sichtbaren Bereichs und vorgeladene kritische Ressourcen
• ein höherer durchschnittlicher Bestellwert über sinnvoll platzierte Cross-Sell- und Bundle-Vorschläge im Warenkorb

Welche Kennzahl im Vordergrund steht, hängt vom Shop ab. Ein Hersteller mit wenigen, teuren Aufträgen misst anders als ein Einzelhändler mit hohem Bestellvolumen.

#Migration und Ablösung von Altsystemen

Ein häufiger Anlass in Karlsruhe ist nicht der erste Shop, sondern der Wechsel weg von einem System, das nicht mehr passt. Das reicht von einer veralteten Shopware- oder Magento-Installation, deren Pflege zu teuer geworden ist, bis zu einem WooCommerce-Shop, in dem über Jahre Plugin auf Plugin gestapelt wurde, bis niemand mehr weiß, welche Erweiterung welche Funktion liefert. In beiden Fällen beginnt die Arbeit mit einer Bestandsanalyse: Welche Daten müssen erhalten bleiben (Produkte, Kunden, Bestellhistorie, SEO-relevante URLs), welche Funktionen sind tatsächlich im Einsatz und welche lassen sich gefahrlos abschalten.

Beim Datenumzug achten wir besonders auf zwei Dinge, die im Tagesgeschäft oft untergehen. Erstens die Weiterleitungen: Alte Produkt- und Kategorie-URLs müssen sauber per 301 auf die neuen Adressen zeigen, sonst verliert der Shop über Nacht Rankings, die über Jahre aufgebaut wurden. Zweitens die Steuer- und Buchhaltungsanbindung: Bestellnummernkreise, Rechnungslayout und der Export für den Steuerberater müssen nach der Migration genauso funktionieren wie vorher, damit die Buchhaltung keinen Bruch erlebt. Diese Punkte gehören für uns in die Spezifikation, nicht in eine nachträgliche Fehlerliste.

#Sicherheit und Datenschutz

Jeder Shop bekommt eine belastbare Sicherheitsbasis: erzwungenes HTTPS mit HSTS, Content-Security-Policy-Header gegen XSS, Abhängigkeits-Scanning in der CI, Zwei-Faktor-Anmeldung für Admin-Konten und getestete Backups. Da ein Shop personenbezogene Daten verarbeitet, gehört DSGVO-Konformität von Anfang an dazu: ein Consent-Management, das Klarna-, PayPal- und Tracking-Dienste erst nach Einwilligung lädt, Auftragsverarbeitungsverträge mit den eingesetzten Dienstleistern und eine Privacy-by-Design-Architektur. Für Kunden in laufender Betreuung prüfen wir Zugriffe und Abhängigkeiten regelmäßig nach.

#Performance, die im Wettbewerb zählt

Core Web Vitals sind in einem dichten Markt wie Karlsruhe kein Selbstzweck, sie entscheiden über Sichtbarkeit und Conversion. Wir richten WooCommerce-Projekte darauf aus, die Schwellenwerte von Google nicht nur zu erreichen, sondern komfortabel zu unterbieten:

• Largest Contentful Paint, über einen schlanken kritischen Renderpfad, vorgeladene Hero-Bilder in modernen Formaten (WebP/AVIF) und Edge-Caching
• Interaction to Next Paint, über minimale JavaScript-Hydration, entzerrte Event-Handler und kontrolliertes Laden externer Skripte wie Zahlungs- und Tracking-Code
• Cumulative Layout Shift, über feste Bildabmessungen, abgestimmte Schrift-Fallbacks und reservierten Platz für dynamische Inhalte wie Warenkorb-Fragmente

Diese Werte überwachen wir über Lighthouse in der Auslieferung und über Real User Monitoring; eine Regression blockiert die Auslieferung.

#Fragen aus der Region

Macht ihr unseren bestehenden Shop rechtssicher, oder nur Neubauten? Beides. Ein häufiger Auftrag ist genau das: Ein gewachsener WooCommerce-Shop soll auf die deutschen Pflichtangaben gebracht werden, ohne dass dabei Bestellhistorie oder Anpassungen verloren gehen. Wir prüfen Grundpreisangabe, Widerrufstextform, Checkout-Bestätigungen und Rechnungslayout und bringen das in Ordnung.

Welche Zahlarten solltet ihr für einen deutschen Shop einbauen? Das hängt von der Zielgruppe ab. Im deutschen Markt erwarten viele Kunden Kauf auf Rechnung über Klarna, dazu PayPal, SEPA-Lastschrift und Kartenzahlung. Welche Kombination sich rechnet, klären wir an Ihren tatsächlichen Bestelldaten, nicht pauschal.

Arbeitet ihr nur mit Unternehmen aus Karlsruhe? Nein. Der Schwerpunkt liegt auf Karlsruhe und der TechnologieRegion, aber wir betreuen Händler in ganz Deutschland. Die rechtlichen und zahlungsseitigen Anforderungen sind bundesweit dieselben.

#Technischer Umfang

Diese Seite bleibt beim Thema WooCommerce-Entwicklung. Der Umfang folgt der Leistung im Titel: Ist-Analyse, Risikokarte, Umsetzungsprioritäten, Abnahmekriterien und Prüfung nach dem Start. Taucht in der Analyse eine andere Plattform oder ein anderes Framework auf, ist das Projektkontext und kein Grund für einen Themenwechsel. Das Ergebnis bleibt ein klarer Plan: was geändert werden muss, was bleiben kann, was gemessen wird und was später kommt.

#Lokale Sichtbarkeit in Karlsruhe

Sichtbarkeit im Karlsruher Markt entsteht nicht durch Keyword-Streuung, sondern durch eine saubere technische Basis. Wir sorgen dafür, dass Suchmaschinen den Shop effizient crawlen und indexieren, hinterlegen passendes Schema.org-Markup für Produkte, Angebote und Bewertungen, damit Rich Results greifen, und strukturieren Inhalte so, dass Erfahrung, Fachwissen und Vertrauenswürdigkeit erkennbar werden. Mit dem Wachstum KI-gestützter Suche (Google AI Overviews, ChatGPT, Perplexity) achten wir zusätzlich auf maschinenlesbare, faktische Inhalte mit klaren Entity-Bezügen, damit ein Karlsruher Shop auch in KI-generierten Antworten auftaucht.

#Übernahme eines bestehenden Shops

Eine Übernahme beginnt nicht im Code, sondern bei den Zugängen. Bei einem gewachsenen Shop liegt das Wissen selten an einer Stelle: Das Hosting hat ein früherer Dienstleister eingerichtet, die Domain steht bei einem Registrar, auf den niemand im Haus Zugriff hat, und das Klarna-Konto läuft auf die persönliche Adresse eines Mitarbeiters, der das Unternehmen längst verlassen hat. Bei Händlern in der TechnologieRegion kommt oft ein zweiter Punkt dazu: Es gibt interne Entwickler, die den Shop teilweise selbst angefasst haben, aber keine Dokumentation. Deshalb steht am Anfang eine Zugangsliste, die vollständig sein muss, bevor irgendjemand etwas ändert.

• Server und Auslieferung: SSH oder SFTP, Hosting-Panel, Datenbankzugriff, Git-Repository, CI-Pipeline, DNS beim Registrar
• WordPress selbst: ein eigenes Administratorkonto pro Person mit eigener Zwei-Faktor-Anmeldung, keine geteilten Sammelkonten
• Zahlungsanbieter: Dashboard-Zugang bei Stripe, PayPal, Klarna oder Mollie, jeweils mit eigener Rolle, dazu die Übersicht der hinterlegten Webhook-Endpunkte und aller aktiven API-Schlüssel
• Versanddienstleister: DHL Geschäftskundenportal, DPD und Hermes, samt Abrechnungsnummern, Retourenportal und den Zugangsdaten, die im Shop für die Labelerzeugung hinterlegt sind
• Umsysteme: Warenwirtschaft, Buchhaltungs-Export, Transaktionsmailversand, CDN, Consent-Tool, Trusted Shops, Analytics und Tag-Verwaltung

Zugänge werden dokumentiert, nicht nur eingesammelt. Zu jedem Eintrag gehören der Eigentümer, die vergebene Rolle, der Ort, an dem der Schlüssel verwendet wird, und der Zeitpunkt, zu dem er gewechselt werden muss. Am Ende der Übernahme entsteht daraus die Gegenliste: Welche Zugänge des früheren Dienstleisters werden entzogen, welche API-Schlüssel und Webhook-Signaturschlüssel werden neu erzeugt. Bei Zahlungsanbietern ist der Schlüsselwechsel der Grundsatz und nicht die Ausnahme, weil alte Schlüssel erfahrungsgemäß in alten Repositories, Exporten und Sicherungen weiterleben.

#Sicherung außerhalb der Produktion

Vor der ersten Änderung steht eine Sicherung, die nicht auf demselben Server liegt. Praktisch heißt das die 3-2-1-Regel: drei Kopien der Daten, abgelegt auf zwei verschiedenen Speichermedien, davon eine Kopie außerhalb der Produktionsumgebung. Der Datenbank-Dump entsteht über wp db export mit gesetzten Drop-Table-Anweisungen, das Dateisystem über ein Archiv von wp-content samt Uploads, dazu eine Prüfsumme je Artefakt. Eine Sicherung zählt erst, wenn sie einmal zurückgespielt wurde. Genau das passiert beim Aufbau der Testumgebung, und es ist zugleich der erste Beweis, dass der Dump vollständig ist: Kollation, JSON-Spalten und die Tabellen des High-Performance Order Storage müssen nach dem Import genauso dastehen wie im Original.

#Klon mit Testmodus und abgefangenem Mailversand

Der Klon ist erst brauchbar, wenn er nach außen nichts mehr auslösen kann. Diese Schritte laufen immer, bevor jemand den Shop öffnet:

• Adressen umgestellt über wp search-replace, mit der Option --precise und ausgenommener Spalte guid, danach wp option update home und wp option update siteurl
• Indexierung abgeschaltet über wp option update blog_public 0, dazu eine HTTP-Basisauthentifizierung auf Serverebene, damit die Testumgebung nicht in den Suchindex rutscht
• Zahlung im Testmodus: Live-Schlüssel gegen Sandbox-Schlüssel getauscht, Webhook-Endpunkte auf den Klon umgestellt, damit keine Rückmeldung mehr am Produktivshop landet
• Mailversand abgefangen: wp_mail auf einen lokalen Testposteingang umgeleitet, sodass Bestellbestätigungen, Rechnungen und Passwort-Mails sichtbar, aber nicht zustellbar sind
• Hintergrundprozesse gestoppt: WP-Cron auf den Klon begrenzt, offene Aufgaben im Action Scheduler gesichtet, Labelerzeugung und Bestandssync gegen die produktiven Umsysteme abgeschaltet
• Datensparsamkeit: Kundendaten pseudonymisiert, soweit der Test sie nicht braucht; Struktur, Bestellzustände und Nummernkreise bleiben erhalten

Freigegeben ist die Umgebung erst, wenn eine Testbestellung durchläuft, das Gateway im Sandbox-Modus antwortet und die Bestätigungsmail nachweislich im Testposteingang liegt statt im Postfach eines echten Kunden.

#Was das Audit prüft

Das Audit läuft auf dem Klon, nicht auf dem Live-Shop. Geprüft wird in sechs Blöcken:

• Codestand: wp core verify-checksums und wp plugin verify-checksums decken veränderte Kern- und Plugin-Dateien auf, letzteres nur für Erweiterungen aus dem WordPress-Verzeichnis; dazu Must-use-Plugins, Drop-ins wie object-cache.php und advanced-cache.php, der Umfang der Theme-eigenen functions.php und direkte Datenbankabfragen, die am WooCommerce-CRUD vorbeigehen
• Datenbank: automatisch geladene Optionen (autoload), die WordPress im Website-Zustand ab 800 KB meldet, verwaiste Postmeta, abgelaufene Transients, der Speicherort der Bestellungen (High-Performance Order Storage oder weiterhin die Beitragstabelle), Tabellen-Engine und Kollation
• Bestellpfade: aktive Gateways gegen die tatsächlich abgerechneten Zahlarten, Zustellprotokoll und Fehlversuche der Webhooks, Steuerklassen und OSS-Konfiguration, Rechnungsnummernkreise, Pflichtangaben im Checkout
• Performance: TTFB gemessen mit curl über die Option -w und den Platzhalter time_starttransfer, Query Monitor auf Produkt-, Kategorie- und Warenkorbseite, Trefferquote des Objekt-Caches und die Core-Web-Vitals-Schwellen (LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1)
• Sicherheit: PHP-Version gegen den laufenden Support-Zeitraum, Plugins ohne Aktualisierung oder mit eingestellter Entwicklung, Administratorkonten ohne Zweitfaktor, Dateirechte, offene XML-RPC- und REST-Endpunkte, Schlüssel in versionierten Dateien
• Betrieb: Gibt es einen dokumentierten Wiederherstellungspfad? Wann wurde die letzte Sicherung zurückgespielt und geprüft? Wo läuft der Cron? Wer wird bei einer Störung benachrichtigt?

#Die Risikoliste als Ergebnis

Am Ende der Übernahme steht keine Sammlung von Screenshots, sondern eine sortierte Risikoliste. Jeder Eintrag nennt den Fund, den betroffenen Pfad oder Dateinamen, die technische Auswirkung, eine Aufwandsklasse und die Empfehlung. Sortiert wird in vier Stufen:

• Blocker: Punkte mit Umsatz- oder Rechtsfolge, etwa ein Gateway ohne funktionierendes Webhook-Handling, eine Widerrufsbelehrung, die nicht in Textform zugeht, oder eine Sicherung, die sich nicht zurückspielen lässt
• Hoch: veränderte Kerndateien, ein aufgegebenes Plugin mitten im Bestellpfad, eine PHP-Version außerhalb des Supports
• Mittel: Bremsen wie überfüllte automatisch geladene Optionen, unkontrolliert nachgeladene Warenkorb-Fragmente, fehlende moderne Bildformate
• Niedrig: Aufräumarbeit ohne akutes Risiko, etwa Tabellenreste längst entfernter Plugins

Die Liste ist Entscheidungsgrundlage, nicht Rechnung. Sie legt fest, was sofort passiert, was in ein Wartungsfenster gehört und was bewusst liegen bleiben darf. Der Aufwand je Punkt wird individuell kalkuliert, weil er vom Zustand des Shops abhängt und nicht von einer Pauschale. Reaktionszeiten bei Störungen regelt der Wartungsvertrag; die Risikoliste bestimmt allein die Reihenfolge, in der die gefundenen Punkte abgearbeitet werden.

#Projekt starten

Sie wollen Ihren WooCommerce-Shop in Karlsruhe neu aufsetzen, sanieren oder rechtssicher machen? Den ersten Schritt machen wir in einem Erstgespräch: aktuellen Stand prüfen, Lücken benennen, einen praktischen Fahrplan skizzieren. Kein Verkaufsgespräch, sondern technische Beratung. Die Wartung im Anschluss ist optional, die Wahl bleibt bei Ihnen.

Die Konditionen richten sich nach Umfang und Zustand des Shops; Sie erhalten eine individuelle Einschätzung statt einer Pauschale.