WordPress Entwickler in Karlsruhe

Karlsruhe ist kein zufälliger Standort für anspruchsvolle Webprojekte. 1984 ging am Rechenzentrum der Universität Karlsruhe die erste E-Mail Deutschlands ein, entgegengenommen von Werner Zorn und seinem Team. Diese Stadt hat ein Verhältnis zur Informatik, das sich bis heute durchzieht, und Unternehmen hier erwarten von einem WordPress-Entwickler dasselbe technische Niveau, das ihre Region ausmacht.

Wir liefern Senior-WordPress-Entwicklung für Unternehmen in der TechnologieRegion Karlsruhe: eigene Themes, Plugins, Headless-Integrationen und sauber abgegrenzte Geschäftslogik, mit deutschem Rechts- und Marktkontext von Anfang an mitgedacht.

#WordPress-Entwicklung in Karlsruhe

Unternehmen zwischen KIT-Campus, Technologiepark und Innenstadt arbeiten in einem Umfeld, in dem rund 4.800 IT-Unternehmen, über zwei Dutzend Forschungseinrichtungen und etwa 10.000 Informatik-Studierende den Standard für digitale Arbeit setzen. Wer hier eine WordPress-Site betreibt, konkurriert nicht mit dem Bäcker um die Ecke, sondern steht neben Software-Häusern, die von Engineering-Qualität leben. Unsere WordPress-Entwicklung adressiert genau dieses Niveau: wartbarer Code, messbare Performance und ein Lieferweg, der einer Code-Review im CyberForum-Umfeld standhält.

#Was wir liefern

• Eigene Block-Themes auf Basis von theme.json, Full Site Editing und wiederverwendbaren Block-Patterns, die Ihre Redaktion ohne Entwicklereingriff pflegt
• Individuelle Gutenberg-Blöcke mit React, block.json-Metadaten, Transforms und InspectorControls für natives Editieren im Editor statt Shortcode-Wildwuchs
• REST-API- und WPGraphQL-Endpunkte für Headless-Frontends, mobile Apps und Integrationen mit Drittsystemen, inklusive Authentifizierung und Rate Limiting
• WCAG 2.2 AA als fester Bestandteil: semantisches Markup, ARIA-Landmarks, Tastaturnavigation, Focus-Management und automatisierte Accessibility-Tests in der CI
• Automatisierte Auslieferung mit GitHub Actions, Testumgebung mit Datenbank-Synchronisation und atomare Releases mit dokumentiertem Wiederherstellungspfad
• Rechtskonforme Shop-Architektur für den deutschen Markt, wenn WooCommerce Teil des Projekts ist (dazu unten mehr)

#Der Markt in Karlsruhe

Karlsruhe wurde bereits 2017 vom Bund als Digital Hub für angewandte Künstliche Intelligenz ausgezeichnet, koordiniert über die DIZ in enger Abstimmung mit dem FZI Forschungszentrum Informatik, dem CyberForum und dem KIT. Für unsere Arbeit heißt das konkret: Mandanten kommen häufig aus dem KI-, Industrie- und Energieumfeld (mit EnBW sitzt einer der drei größten Energieversorger Deutschlands direkt hier) und bringen Anforderungen mit, die ein Standard-Theme nicht trägt. Häufig sind das Datenschnittstellen zu internen Systemen, mehrsprachige Fachinhalte und Redaktionsprozesse, in denen wissenschaftliche und Marketing-Teams parallel publizieren.

Diese Kundschaft braucht keine Klick-zusammen-Website. Sie braucht eine WordPress-Basis, die sich versionieren, testen und übergeben lässt, und einen Entwickler, der bei der Architekturentscheidung schriftlich begründet, warum etwas im Plugin und nicht im Theme liegt.

#Technische Standards

Wir bauen auf bewährten Fundamenten: WordPress Core für das Content-Management, ACF Pro oder Meta Box für strukturierte Daten, ein SEO-Plugin für die technische Automatisierung und Redis Object Caching für die Performance. Individuelle Funktionalität lebt in mu-plugins mit korrektem Namespacing und Autoloading, damit sie einen Theme-Wechsel überlebt. Was als Feature die Darstellung überdauern soll, gehört nie ins Theme.

#Unser Arbeitsprozess

Jedes Projekt in Karlsruhe folgt einem strukturierten Ablauf, der Risiken früh sichtbar macht:

1. Analyse und Audit. Wir lesen den bestehenden WordPress-Code: Theme-Struktur, eigene Plugins, Integrationen, Hosting-Grenzen sowie eine Accessibility- und Performance-Baseline. Technische Schulden werden dokumentiert, bevor die erste Zeile Code entsteht.
2. Technische Spezifikation. Auf Basis des Audits entsteht eine Spezifikation mit Architekturentscheidungen, Plugin-Grenzen, Integrationspunkten und Abnahmekriterien. Sie genehmigen den Plan vor Entwicklungsbeginn.
3. Entwicklungssprints. Wir arbeiten in ein- bis zweiwöchigen Iterationen mit einem testbaren Ergebnis am Ende jedes Sprints. Sie sehen den Fortschritt früh und können Prioritäten verschieben, ohne das Projekt zu entgleisen.
4. Qualitätssicherung. Jedes Arbeitsergebnis durchläuft Code-Review, automatisierte Tests, browserübergreifend-Prüfung, Accessibility-Scan und Performance-Messung gegen ein definiertes Budget, bevor es auf Testumgebung geht.
5. Übergabe und Support. Nach der Stabilisierung folgt der laufende Support mit lebendiger Dokumentation, einem Architecture Decision Record für nicht-offensichtliche Entscheidungen und einer Übergabe-Session.

#E-Commerce und WooCommerce für den deutschen Markt

Wird aus dem Projekt ein Onlineshop, beginnt die eigentliche Arbeit nicht beim Warenkorb, sondern beim deutschen Recht. Ein WooCommerce-Shop ohne korrektes Impressum, ohne separate Widerrufsbelehrung nach §355 BGB und ohne DSGVO-konforme Datenschutzerklärung ist abmahngefährdet, bevor die erste Bestellung eingeht. Wir richten Shops daher von Beginn an mit einem Rechtssicherheits-Plugin wie WooCommerce Germanized oder German Market ein, das Preisangabenverordnung, Grundpreise, Lieferzeiten und die korrekte Reihenfolge im Checkout abbildet.

Bei den Zahlarten orientieren wir uns an deutschem Käuferverhalten, nicht an einer internationalen Standardliste. Der Kauf auf Rechnung über Klarna oder PayPal hat hierzulande die höchste Conversion, gerade bei Warenkörben über individuelles Angeboto, und gehört in deutschen Shops fast immer dazu. Giropay ist Ende 2024 eingestellt worden und wird durch Wero abgelöst, dessen E-Commerce-Anbindung gerade erst anläuft. Wir installieren also keine veralteten Giropay-Plugins, sondern setzen auf das, was heute trägt: Rechnung, Lastschrift, PayPal und Kreditkarte über einen Anbieter wie Klarna oder einen klassischen Payment-Gateway. Ein Trusted-Shops-Siegel binden wir ein, wenn der Mandant es führt, weil es im DACH-Raum nachweislich auf die Kaufentscheidung einzahlt.

#Typische Herausforderungen, die wir lösen

Unternehmen in der Region kommen regelmäßig mit diesen Themen auf uns zu:

• Mehrsprachige Content-Workflows für Mandanten, die aus Karlsruhe heraus internationale Märkte bedienen: wir konzipieren Websites mit WPML oder Polylang, setzen korrekte Hreflang-Tags und bauen Redaktionsprozesse, die Übersetzungen synchron halten
• Lastspitzen bei Produkt-Launches und Messen: wir konfigurieren Full-Page-Caching über Cloudflare oder Varnish, optimieren Datenbankindizes und fahren Lasttests, bevor die Kampagne live geht
• Performance-Verlust durch Plugin-Überfrachtung: wir prüfen den Plugin-Bestand, ersetzen schwere Abhängigkeiten durch schlanken Custom-Code und senken die Zahl der Datenbankabfragen pro Seite spürbar

#Sicherheit und DSGVO-Konformität

Jedes Projekt erfüllt eine klare Sicherheits-Baseline, unabhängig von der Branche: HTTPS-Erzwingung 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 regelmäßig getestete Backups. Für Sites, die personenbezogene Daten verarbeiten, gehört in Deutschland mehr dazu als eine Cookie-Box: ein DSGVO-konformes Consent-Management, Auftragsverarbeitungsverträge mit allen Dienstleistern und eine Privacy-by-Design-Architektur, die nur erhebt, was wirklich gebraucht wird. Bei Mandanten mit laufender Betreuung prüfen wir das quartalsweise erneut, weil sich sowohl Bedrohungslage als auch Rechtsprechung bewegen.

#Performance-Engineering

Geschwindigkeit ist auch in einem technikaffinen Markt wie Karlsruhe ein Wettbewerbsvorteil, weil Ladezeit direkt auf Absprung und Conversion wirkt. Unser Ansatz für WordPress-Projekte:

• Asset-Optimierung. Bilder laufen durch einen Build-Prozess, der responsive Srcsets in WebP und AVIF erzeugt. CSS wird bereinigt, routenweise gesplittet und für den sichtbaren Bereich inline eingebettet. JavaScript wird per Tree Shaking reduziert und über dynamische Imports geladen.
• Caching-Architektur. Mehrstufig: Browser-Cache, CDN (Cloudflare), Application-Cache (Redis) und ein Datenbankabfrage-Cache über Transients mit gezielter Invalidierung.
• Netzwerk-Optimierung. HTTP/3 mit QUIC, Brotli-Kompression, Preconnect-Hints und Ressourcen-Priorisierung.
• Rendering-Optimierung. Critical-CSS-Inlining, asynchrones Laden von Stylesheets, Lazy Loading von Bildern und Iframes.

Jede Entscheidung ist messbar. Wir erfassen Core Web Vitals (LCP, INP, CLS) vor und nach der Umsetzung, dokumentieren die Auswirkung und legen die Baselines in die Projektdokumentation.

#Warum Unternehmen in Karlsruhe mit uns arbeiten

Sie sprechen direkt mit einem Senior-Entwickler, nicht mit einem Projektmanager, der Nachrichten weiterreicht, und nicht mit einem Junior, der auf Ihrem Projekt lernt. Die Person, die Ihnen die Architektur erklärt, ist die Person, die den Code schreibt.

Wir bauen WordPress-Lösungen seit 2007 und haben jedes große Core-Update mitgemacht. Wir sagen offen, wo WordPress die richtige Wahl ist und wo eine Headless-Architektur oder ein anderer Stack das bessere Ergebnis bringt. Wenn die Analyse ergibt, dass ein anderer Weg sinnvoller ist, schreiben wir das auf, statt das Thema zu wechseln.

#Fragen, die uns Unternehmen in Karlsruhe stellen

Was passiert, wenn sich die Anforderungen während des Projekts ändern? Änderungen sind eingeplant. Der sprintbasierte Prozess erlaubt Umfangsanpassungen zwischen den Iterationen. Wir besprechen die Auswirkung auf Zeitplan und Aufwand transparent, holen Ihre Freigabe ein und passen den Plan an.

Was unterscheidet das von einer generischen Webagentur? Der Leistungsumfang dreht sich um WordPress-Entwicklung, nicht um ein breites Relaunch-Paket. Sie bekommen Senior-Engineering, dokumentierte technische Abwägungen, messbare Abnahmekriterien und einen Lieferweg, der die Performance dieser Site ins Zentrum stellt.

Wie sind die Konditionen? Die Abrechnung ist projektbezogen, üblicherweise mit Anzahlung, Zwischenstand und Schlusszahlung; laufende Betreuung läuft monatlich. Die Vergütung ist eine individuelle Kalkulation auf Basis von Umfang und Komplexität, festgehalten im Projektvertrag vor Beginn.

Wie lange dauert ein typisches Projekt? Das hängt von Umfang, Content-Bereitschaft und Integrationstiefe ab. Eine Unternehmenswebsite liegt meist im Bereich weniger Wochen, ein rechtssicherer WooCommerce-Shop deutlich darüber, komplexe Projekte mit mehreren Integrationen und Mehrsprachigkeit entsprechend länger. Einen belastbaren Zeitplan liefern wir in der Spezifikationsphase.

#Lokale SEO und Sichtbarkeit in Karlsruhe

Eine gut gebaute Site nützt nur, wenn Ihre Zielgruppe in der Region sie findet. Deshalb gehört SEO-Architektur von der ersten Skizze an dazu:

• Technische Grundlagen. Saubere URL-Strukturen, XML-Sitemaps, Canonical Tags, korrekte Heading-Hierarchie und strukturierte Daten nach Schema.org (LocalBusiness, Organization, Product, FAQ).
• Lokale Suche. Anbindung an das Google Business Profile, lokales Schema mit Karlsruher Adresse und konsistente NAP-Daten über alle Verzeichnisse.
• Core Web Vitals. Google bezieht Page-Experience-Signale in die Bewertung ein, deshalb ist jede Site auf stabile Werte ausgelegt.
• Mehrsprachige SEO. Für Mandanten, die von Karlsruhe aus mehrere Märkte bedienen, setzen wir Hreflang, locale-spezifische URLs und eigene Metadaten pro Sprache.

#Übernahme eines WordPress-Projekts vom Vorgänger

Nicht jedes Projekt beginnt auf der grünen Wiese. Häufig geht es um eine bestehende Installation, deren Entwickler nicht mehr erreichbar ist oder deren Agentur gewechselt wurde. Für diesen Fall haben wir einen festen Ablauf, weil die teuersten Fehler bei einer Übernahme in den ersten Tagen passieren, lange bevor jemand Code schreibt.

Zugänge kommen vor dem Code. Bevor eine Zeile gelesen wird, klären wir schriftlich, wer welche Schlüssel hält: Domain-Registrar samt Auth-Code, DNS-Verwaltung (häufig Cloudflare), Hosting-Konto mit SSH- oder SFTP-Zugang, Datenbank-Zugangsdaten, ein WordPress-Konto mit der Rolle Administrator, das Git-Repository samt Branch-Historie, der Auslieferungs-Zugang, die Lizenzen für kommerzielle Plugins wie ACF Pro, WPML oder WooCommerce-Erweiterungen, der SMTP- oder Transaktionsmail-Dienst, die Zugänge zu Zahlungsanbieter und Warenwirtschaft sowie Search Console und Analytics-Property. Lizenzen sind dabei ein eigener Punkt: Code lässt sich kopieren, ein Lizenzschlüssel wird auf ein Konto ausgestellt und muss übertragen oder neu erworben werden, sonst laufen Updates still ins Leere und eine Sicherheitslücke bleibt offen, obwohl der Hersteller sie längst geschlossen hat. In Karlsruhe prägen Forschung, Energiewirtschaft und Industrie das Umfeld, also Organisationen mit eigener IT-Abteilung und geregelter Rechtevergabe. Deshalb planen wir den Zugangsschritt als eigenen Vorgang mit benanntem Ansprechpartner und Freigabeweg, nicht als Nebensatz beim Projektstart. Fehlt ein Zugang dauerhaft, steht das als offener Punkt im Ergebnis, weil ein Audit ohne Serverzugriff blinde Flecken behält: Cronjobs, Mailversand, Serverkonfiguration und tatsächliche Backup-Stände sind von außen nicht prüfbar.

Die Sicherung entsteht außerhalb der Produktion. Der erste technische Schritt ist ein vollständiger, wiederherstellbarer Stand, der nicht auf demselben Server liegt wie das Produktivsystem. Die Datenbank ziehen wir über wp db export mit den Optionen --add-drop-table und --single-transaction, damit der Dump konsistent ist und der spätere Import nicht an Resten einer alten Struktur scheitert. Die Dateien holen wir über rsync, inklusive wp-content/uploads, wp-config.php, .htaccess und, soweit zugänglich, der Serverkonfiguration. Danach folgen wp core verify-checksums, Prüfsummen der Archive über sha256sum und der Teil, den die meisten auslassen: ein echter Rückspielversuch auf einer leeren Umgebung. Ein Backup, das nie eingespielt wurde, ist eine Vermutung, kein Sicherungsstand. Als Zielbild gilt die 3-2-1-Regel: drei Kopien, zwei verschiedene Systeme oder Medien, eine davon außerhalb der Produktivumgebung. Erst wenn dieser Stand steht und nachweislich startet, fassen wir überhaupt etwas an.

Der Klon läuft mit gesperrter Indexierung. Geprüft und getestet wird auf einer Kopie, nie auf der Produktion. Auf dem Klon setzen wir wp option update blog_public 0, wissen aber, dass diese Option nur die robots.txt schreibt und damit eine Bitte formuliert, keine Sperre. Dazu kommt deshalb HTTP Basic Auth auf Serverebene und ein X-Robots-Tag: noindex im Antwort-Header, damit weder Crawler noch versehentlich geteilte Links eine zweite indexierbare Fassung derselben Inhalte erzeugen. Die URL-Umstellung läuft über wp search-replace, zuerst mit --dry-run, dann mit --precise und --all-tables-with-prefix, weil Adressen in serialisierten Theme- und Plugin-Optionen stecken und eine naive Textersetzung dort die Längenangaben zerlegt. Anschließend schalten wir die Außenwirkung ab: Transaktionsmails auf einen Catch-all oder ganz deaktiviert, Zahlungsschnittstellen in WooCommerce in den Testmodus, externe Schnittstellen auf Testschlüssel, DISABLE_WP_CRON in der wp-config.php und ein manueller Cron-Aufruf nur dort, wo ein Test ihn braucht. Ohne diesen Schritt verschickt eine Kopie Rechnungen an echte Kunden oder schreibt Testbestellungen in ein produktives Warenwirtschaftssystem.

Was das Audit prüft. Auf dieser Kopie läuft eine Prüfung, die immer dieselben Bereiche abdeckt, damit Ergebnisse zwischen Projekten vergleichbar bleiben:

• Integrität des Kerns. wp core verify-checksums und wp plugin verify-checksums decken veränderte Core- und Repository-Dateien auf. Kommerzielle Plugins vergleichen wir gegen das Original-Archiv des Herstellers. Drop-ins wie object-cache.php, advanced-cache.php und db.php sowie der Inhalt von mu-plugins werden einzeln gelesen, weil dort Code liegt, den die Plugin-Übersicht im Backend gar nicht oder nur unvollständig anzeigt.
• Versionsstand. PHP-Version der Umgebung, WordPress-Version, wp plugin list --update=available und wp theme list. Alles unterhalb einer noch mit Sicherheitsupdates versorgten PHP-Version ist ein eigener Befund, weil dort Lücken offen bleiben. PHP 8.1 hat den Support Ende 2025 verlassen, sinnvoll ist deshalb mindestens 8.2, besser 8.3 oder 8.4.
• Codequalität. PHPCS mit den WordPress Coding Standards, mit besonderem Blick auf WordPress.DB.PreparedSQL: direkte Aufrufe von $wpdb->query ohne prepare, fehlende Maskierung der Ausgabe über esc_html, esc_attr oder wp_kses_post, fehlende Nonce-Prüfungen über check_admin_referer und fehlende Rechteprüfungen über current_user_can. Jeder Treffer wird mit Datei und Zeile notiert, nicht als Sammelwert.
• Datenmodell. Umfang der automatisch geladenen Optionen über wp option list --autoload=on, abgelaufene Transients, Größe von wp_postmeta, verwaiste Meta-Einträge und die Zahl der Revisionen. Eine aufgeblähte Options-Tabelle wird bei jedem einzelnen Seitenaufruf geladen und ist in gewachsenen Installationen eine der häufigsten Ursachen für eine schlechte Server-Antwortzeit.
• Laufzeitverhalten. Query Monitor auf dem Klon zeigt Abfragen pro Seitenaufruf, langsame Queries und Hooks mit auffälliger Laufzeit. Die Server-Antwortzeit messen wir mit curl über die Option -w und die Variable time_starttransfer. Die Nutzerwerte halten wir gegen die bekannten Schwellen: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1.
• Sicherheit und Konten. wp user list --role=administrator wird gegen die tatsächliche Personenliste des Mandanten gehalten, dazu Dateirechte, DISALLOW_FILE_EDIT, vergessene Kopien der wp-config.php im Webroot, erreichbare debug.log-Dateien und offene Verzeichnislisten.
• Recht und Betrieb. Bei Shops: Impressum, Widerrufsbelehrung, Preisangaben, Grundpreise und Checkout-Reihenfolge, dazu Consent-Management und Auftragsverarbeitungsverträge. Beim Betrieb: existiert ein Repository, gibt es einen reproduzierbaren Auslieferungs-Weg, gibt es eine Testumgebung, laufen Backups automatisiert und wurden sie jemals zurückgespielt.

Das Ergebnis ist eine Risikoliste in drei Stufen. Aus dem Audit wird kein Fließtext-Gutachten, sondern eine sortierte Liste mit drei klar getrennten Dringlichkeiten. Stufe eins: sofort zu behandeln, weil ein Schaden bereits möglich ist. Dazu zählen bekannte Schwachstellen in aktiven Plugins, Administrator-Konten ohne Zuordnung zu einer realen Person, fehlende oder nie geprüfte Backups und rechtliche Lücken im Checkout. Stufe zwei: geplant im ersten gemeinsamen Arbeitszyklus, weil der Befund heute funktioniert, aber beim nächsten Core- oder PHP-Update bricht. Typisch sind Aufrufe entfernter PHP-Funktionen, ein seit Jahren nicht mehr gepflegtes Plugin, Geschäftslogik in der functions.php des Themes und Code, der nur auf dem Server liegt und in keinem Repository steht. Stufe drei: bewusst akzeptiert und schriftlich festgehalten, mit einem definierten Zeitpunkt für die erneute Bewertung.

Jeder Eintrag trägt fünf Angaben: Befund, Beleg (Datei und Zeile oder die Ausgabe des jeweiligen Befehls), Auswirkung im Betrieb, Aufwandsschätzung als Spanne und die verantwortliche Seite. Eine Sammelkategorie für Reste gibt es nicht, weil dort erfahrungsgemäß genau die Punkte landen, die später teuer werden. Die Aufwandsschätzung führt in eine individuelle Kalkulation, nicht in einen Pauschalposten. Für die Einträge aus Stufe eins regelt der Wartungsvertrag, in welcher Form und Frist reagiert wird. Am Ende der Übernahme steht eine strukturierte Übergabe an Ihr Team und ein schriftliches Betriebshandbuch, in dem Zugänge, Auslieferungs-Weg, Backup-Plan und die offenen Punkte aus Stufe zwei und drei so festgehalten sind, dass die nächste Person sie ohne Rückfrage lesen kann.

Automotive- und IT-Auftraggeber zwischen Oberrhein und Neckar vergleichen Architekturen häufig mit unserer WordPress-Entwicklung in Stuttgart.

Rhein-Neckar-Standorte vergleichen Portal-Architekturen häufig mit unserer WordPress-Entwicklung in Mannheim.

Schwaben-Standorte in Bayern vergleichen Shop-Architekturen häufig mit unserer WordPress-Entwicklung in Augsburg.

#Starten Sie Ihr Projekt in Karlsruhe

Sprechen Sie mit uns darüber, wie WordPress-Entwicklung Ihr Unternehmen in Karlsruhe weiterbringt. Jede Zusammenarbeit beginnt mit einem gründlichen Verständnis der Anforderungen und führt zu einem klaren Angebot mit definierten Arbeitsergebnissen, Zeitplan und individueller Kalkulation. Wir bauen WordPress-Lösungen seit 2007, mitten in einer Region, die das Internet in Deutschland mit auf den Weg gebracht hat.