WordPress Entwickler in Augsburg

WordPress-Entwicklung für Augsburger Unternehmen, von der Maschinenbau- und Mechatronik-Industrie am Lech bis zu den Gründerteams im aiti-Park: individuelle Themes, eigene Plugins und saubere Integrationen, die einen Plattformwechsel überdauern.

Die Stadt, in der Rudolf Diesel bei MAN den Dieselmotor erfand und in der Kuka heute Industrieroboter baut, hat ein technisches Selbstverständnis. Eine Website, die nach drei Jahren niemand mehr anfassen kann, passt nicht dazu.

#WordPress-Entwicklung in Augsburg

Augsburg ist Sitz von MAN Energy Solutions, dem Energieversorger Lechwerke (seit 1903), dem Roboterhersteller Kuka und einer dichten Zulieferer-Landschaft rund um Luft- und Raumfahrt (Premium Aerotec, MT Aerospace, SGL Carbon) und Faserverbund-Leichtbau. Dazu kommt mit dem Augsburg Innovationspark einer der größten Innovationsparks Europas und das benachbarte Technologiezentrum direkt neben der Universität Augsburg und der Hochschule Augsburg.

Diese Mischung prägt, wer in Augsburg WordPress-Entwicklung beauftragt: Industriezulieferer mit erklärungsbedürftigen Produkten, ingenieurnahe Dienstleister, Kanzleien und Steuerberater im Textilviertel, sowie Gründungen aus dem aiti-Park (seit 2002 als Public-Private-Partnership der Treiber der digitalen Wirtschaft in der Region). Sie alle brauchen weniger das nächste Page-Builder-Theme als Code, der mit dem Unternehmen mitwächst.

#Was wir liefern

• Eigene Block-Themes auf Basis von theme.json, Block-Patterns und Stilvarianten, damit Redaktionen im Site-Editor arbeiten können, ohne dass jede Layout-Änderung über die Entwicklung läuft
• Plugin-Entwicklung für die Geschäftslogik, die einen Theme-Wechsel überlebt: Custom Post Types für Produktkataloge, Maschinen-Datenblätter oder Referenzprojekte, REST-Endpunkte und Admin-Werkzeuge, sauber getrennt von der Darstellung
• WordPress Multisite für Unternehmen mit mehreren Standorten oder Marken in Schwaben, mit einer gemeinsamen Installation und getrennter Redaktion je Auftritt
• Integrationen mit CRM, ERP und Buchungssystemen über REST oder WPGraphQL, inklusive Authentifizierung, Rate Limiting und nachvollziehbarem Fehler-Logging
• DSGVO-konforme Umsetzung von Anfang an: Einwilligungsmanagement vor dem Laden von Drittanbieter-Skripten, vollständiges Impressum, Datenschutzerklärung und Verarbeitungsverzeichnis als fester Teil der Architektur
• WCAG 2.2 AA: semantisches Markup, ARIA-Landmarks, Tastaturbedienung, Fokus-Management und automatisierte Accessibility-Tests in der CI-Pipeline

#Industrie, Forschung und Gründerszene am Lech

Augsburg hat zwei Geschwindigkeiten, und beide stellen unterschiedliche Anforderungen an WordPress. Die etablierte Maschinenbau- und Mechatronik-Industrie, gewachsen aus der Textil- und Druckmaschinen-Tradition der Fugger-Stadt, braucht Websites, die technische Tiefe abbilden: strukturierte Produktdaten, mehrsprachige Auftritte für internationale Kundschaft, PDF-Datenblätter und Filterlogik über große Kataloge. Dafür sind Custom Post Types mit durchdachten Taxonomien das richtige Werkzeug, nicht ein überladenes Allzweck-Plugin.

Die zweite Geschwindigkeit kommt aus dem Innovationspark, dem Technologiezentrum und dem aiti-Park: Ausgründungen aus der Universität Augsburg und der Hochschule, oft im Umfeld von Industrie 4.0, Leichtbau, Embedded Systems und Umwelttechnik. Diese Teams wollen schnell live gehen, später aber nicht von einem Theme eingemauert sein, das keine API kennt. Hier liefern wir bewusst schlank: ein eigenes Block-Theme, klare Schnittstellen, und die Option, das Frontend später headless vor WordPress zu setzen, wenn die Produktwebsite und die App-Landingpage zusammenwachsen.

Was beide Gruppen verbindet: In einer Stadt, deren Wirtschaftsförderung Industrie 4.0 und vernetzte Systeme zum Leitmotiv erklärt hat, fällt eine träge, schlecht wartbare Website auf. Genau hier setzt der Anspruch an die WordPress-Entwicklung an.

#Theme von Grund auf oder bestehendes erweitern

Die Entscheidung fällt anhand von Kosten gegen technische Schulden, nicht danach, was spannender zu bauen ist.

Ein Neubau startet bei uns meist mit einem eigenen Block-Theme auf den Editor-APIs. Übernommene Augsburger Projekte, häufig ein über Jahre gewachsenes Elementor- oder Divi-Setup, brauchen dagegen oft ein gezieltes Refactoring statt einer Neuentwicklung: die Inhalte bleiben, aber die Template-Hierarchie, der Asset-Prozess und die Plugin-Grenzen werden geordnet. Wenn ein vorhandenes Theme viel individuelle Logik enthält, deren Portierung sich nicht lohnt, sagen wir das schriftlich, statt aus Prinzip neu zu bauen.

#Unser Arbeitsprozess

Jedes Augsburger Projekt läuft über einen strukturierten Prozess, der Risiken reduziert und Transparenz schafft:

1. Analyse und Audit, wir prüfen die bestehende Architektur, Content-Struktur, Analytics-Daten und Geschäftsziele, dokumentieren technische Schulden und definieren messbare Abnahmekriterien, bevor die erste Zeile Code entsteht.
2. Architektur und Lieferumfang, wir legen fest, was ins Theme und was ins Plugin gehört, wo Custom Post Types sinnvoll sind und welche Integrationen anstehen, als schriftliche Abwägung, nicht als Glaubensentscheidung.
3. Entwicklung in Feature-Branches, Umsetzung nach WordPress Coding Standards mit Code-Review auf jedem Branch, i18n-fähigen Texten und serverseitig gerenderten Blöcken dort, wo es zählt.
4. QA und Testumgebung, die vollständige Lösung läuft auf einer produktionsidentischen Testumgebung; Sie prüfen mit echten Inhalten, verifizieren Integrationen und geben den Start frei.
5. Start und Übergabe, wir übernehmen DNS, SSL, Cache-Warmup und Redirect-Prüfung, liefern ein schriftliches Runbook und bleiben nach dem Start in Bereitschaft.

#Typische Aufgaben aus Augsburg

Diese Anfragen erreichen uns aus der Region regelmäßig:

• Migration von Elementor oder Divi zu Gutenberg und Full Site Editing, ohne den vorhandenen Traffic oder die Suchsichtbarkeit zu verlieren, mit Schulung der Redaktion auf Block-Patterns
• Strukturierte Produkt- und Maschinen-Kataloge für Industriezulieferer: Custom Post Types, gefilterte Übersichten, Datenblatt-Downloads und mehrsprachige Varianten für Exportmärkte
• Performance-Sanierung überladener Installationen: Wir prüfen die installierten Plugins, ersetzen schwere Abhängigkeiten durch schlanken Custom-Code, ordnen das Caching und senken die Zahl der Datenbankabfragen pro Seitenaufruf deutlich
• Security-Hardening für Auftritte mit Formular- oder Bewerberdaten: Content-Security-Policy-Header, Abschaltung von XML-RPC, Zwei-Faktor-Authentifizierung im Backend und eine vorgelagerte Web Application Firewall

#WooCommerce und Zahlungen im deutschen Markt

Wenn ein Augsburger Auftritt einen Shop bekommt, zählen die Eigenheiten des deutschen E-Commerce. Wir richten WooCommerce mit den hier erwarteten Zahlarten ein: SEPA-Lastschrift, Kauf auf Rechnung, PayPal, Klarna und giropay, abgestimmt auf das Kaufverhalten in Bayerisch-Schwaben. Dazu kommt die rechtssichere Pflicht-Ausstattung des deutschen Markts: korrekt eingebundene AGB, Widerrufsbelehrung mit Muster-Formular, vollständige Grundpreis- und Versandkostenangaben sowie ein belastbarer Bestellabschluss nach dem Button-Lösung-Prinzip. Wo Vertrauenssignale gefragt sind, integrieren wir Trusted Shops sauber, ohne die Ladezeit aufzublähen.

#Sicherheit und DSGVO

Jedes Projekt erfüllt eine feste Sicherheits-Baseline: HTTPS mit HSTS, Content-Security-Policy gegen XSS, Schwachstellen-Scanning der Abhängigkeiten in der CI, Zwei-Faktor-Authentifizierung für alle Admin-Konten und getestete Backups.

Für Augsburger Auftritte, die personenbezogene Daten verarbeiten, ist die DSGVO kein nachträglicher Aufsatz, sondern Teil der Architektur: Einwilligung vor dem Laden von Tracking- oder Karten-Diensten, Auftragsverarbeitungsverträge mit allen Dienstleistern, ein Verarbeitungsverzeichnis und Privacy by Design. Für laufend betreute Kunden führen wir regelmäßige Sicherheitsreviews durch, inklusive Zugriffs-Audit und Abgleich mit der aktuellen Rechtslage.

#Performance-Engineering

Core Web Vitals sind keine reine Metrik, sie beeinflussen Ranking und Nutzererfahrung direkt. Augsburger Projekte legen wir so aus, dass sie die Schwellen von Google deutlich unterschreiten:

• Largest Contentful Paint niedrig halten über einen optimierten Critical Rendering Path, vorgeladene Hero-Bilder in WebP oder AVIF, Edge-Caching und statische Auslieferung wo möglich
• Interaction to Next Paint klein halten über minimale JavaScript-Hydration, entkoppelte Event-Handler und sauberes Laden externer Skripte
• Cumulative Layout Shift vermeiden über feste Bildabmessungen, abgestimmte Font-Fallbacks mit font-display:swap und reservierten Platz für nachladende Inhalte

Diese Werte überwachen wir kontinuierlich über Lighthouse CI in der Pipeline und über Real User Monitoring. Eine Regression löst einen Alert aus und blockiert die Auslieferung.

#Fragen, die uns Augsburger Unternehmen stellen

Was passiert, wenn sich die Anforderungen während des Projekts ändern? Änderungen sind eingeplant. Der sprintbasierte Prozess erlaubt Anpassungen zwischen den Iterationen; wir besprechen die Auswirkung auf Zeitplan und Aufwand transparent und passen den Plan nach Ihrer Freigabe an.

Wie lange dauert ein typisches Projekt? Das hängt von Umfang, Content-Bereitschaft und Integrationstiefe ab. Eine Unternehmenswebsite ist oft in einigen Wochen umsetzbar; ein WooCommerce-Shop oder ein mehrsprachiger Industriekatalog braucht länger. Einen belastbaren Zeitplan liefern wir nach der Analysephase.

Was kostet das? Die Abrechnung erfolgt nach Aufwand und Leistungsumfang, die Kalkulation ist individuell. Sie bekommen vor Projektbeginn eine schriftliche Aufstellung, keine pauschalen Listenpreise.

Was unterscheidet Sie von einer klassischen Agentur in Augsburg? Sie bekommen direkte Senior-Entwicklung, dokumentierte technische Abwägungen und messbare Abnahmekriterien, ohne Vendor-Lock-in und ohne proprietäre Frameworks. Der Fokus liegt auf WordPress-Entwicklung, nicht auf einem breiten Relaunch-Paket.

Wie handhaben Sie mehrsprachige Websites? Für die exportorientierte Augsburger Industrie ist Mehrsprachigkeit Standard. Wir prüfen Sprachrouting, hreflang, übersetzte Metadaten und die redaktionelle Zuständigkeit je Sprache und halten die Umsetzung im vereinbarten Umfang.

#Langfristige Wartbarkeit und Übergabe

Wir schreiben Code, den andere Entwickler weiterführen können. Zu jedem Projekt gehören lebendige Dokumentation für Redaktion und Entwicklung, Code-Review-Spuren auf jedem Branch, ein schriftliches Architecture Decision Record für nicht offensichtliche Entscheidungen und eine Übergabe-Session zum Abschluss.

Danach kann das Projekt zu Ihrem internen Team wechseln oder in die optionale laufende Betreuung übergehen, mit derselben Dokumentation und denselben Service-Zusagen. Kein künstliches Festhalten an proprietären Strukturen.

#Lokale SEO und Sichtbarkeit in Augsburg

Sichtbarkeit in Augsburg ist mehr als Keyword-Platzierung. Wir verankern SEO in der technischen Architektur:

Crawlbarkeit und Indexierung, saubere interne Verlinkung, klare Heading-Hierarchie und korrekte Sitemaps, damit Suchmaschinen die Inhalte effizient erfassen.

Strukturierte Daten, passendes Schema.org-Markup je Seitentyp, von LocalBusiness für den Augsburger Standort bis Product für Shop- und Katalogseiten.

E-E-A-T-Signale, nachvollziehbare Autorenangaben, eine Über-uns-Seite mit echter Firmenhistorie und Referenzen mit konkreten Ergebnissen statt Schlagworten.

Generative Engine Optimization, mit dem Wachstum von Google AI Overviews, ChatGPT und Perplexity strukturieren wir Inhalte maschinenlesbar: klare Entitäten, faktische Aussagen und zitierte Quellen, damit Ihr Unternehmen auch in KI-Antworten zu Augsburger Anbietern auftaucht.

#Anwendungssicherheit im Code: Eingabe, Datenbank, Rechte und Ausgabe

Eine Sicherheits-Baseline aus HSTS, Web Application Firewall und Zwei-Faktor-Authentifizierung schützt die Umgebung, nicht den eigenen Code. Die Fehler, die WordPress-Projekte tatsächlich kompromittieren, entstehen fast immer an vier Stellen: ungeprüfte Eingaben, per Verkettung zusammengebautes SQL, fehlende Nonce- oder Rechteprüfung bei Ajax- und REST-Aktionen und Ausgabe ohne Escaping. Für Augsburger Auftritte ist das kein Randthema, denn dort laufen Bewerbungsformulare mit Anhängen, Angebotsanfragen aus dem Maschinenbau-Umfeld und Händler- oder Serviceportale hinter einem Login.

Erst validieren, dann bereinigen. Validierung beantwortet die Frage, ob ein Wert überhaupt zulässig ist; Bereinigung bringt ihn in die erwartete Form. Beides gehört zusammen und in dieser Reihenfolge. Vor jeder Bereinigung steht wp_unslash, weil WordPress die Superglobals mit Slashes versieht. Danach folgt der typgerechte Filter: sanitize_text_field für einzeilige Freitexte, sanitize_textarea_field für mehrzeilige, sanitize_email für Adressen, sanitize_key für Options- und Metaschlüssel, absint für IDs, esc_url_raw für URLs, die gespeichert werden, und wp_kses_post für Felder, in denen Redaktionen bewusst HTML setzen dürfen. Werte aus einer festen Menge (Auswahlfelder, Sortierparameter, Statuswerte) prüfen wir mit in_array und striktem Vergleich gegen eine Positivliste, statt sie nur durch einen Textfilter zu schicken. Bei Uploads zählt nicht die Endung im Dateinamen, sondern das Ergebnis von wp_check_filetype_and_ext und die erlaubten MIME-Typen; die Datei selbst wandert über wp_handle_upload in den Uploads-Ordner, nicht über eigenes Verschieben mit selbst gebautem Pfad.

Vorbereitete Statements statt zusammengesetztem SQL. Jede eigene Abfrage über $wpdb läuft durch $wpdb->prepare mit Platzhaltern: %s für Zeichenketten, %d für Ganzzahlen, %f für Gleitkommazahlen und seit WordPress 6.2 %i für Tabellen- und Spaltennamen. Der Platzhalter steht dabei nicht in Anführungszeichen, prepare setzt sie selbst. Variable Teile, für die es keinen Platzhalter gibt, etwa eine dynamische IN-Liste, erzeugen wir aus einem typisierten Array und übergeben sie mit passender Platzhalter-Anzahl an prepare, niemals per String-Verkettung. esc_sql ist kein Ersatz für prepare, sondern nur ein Baustein; bei Teilstring-Suchen kommt zusätzlich $wpdb->esc_like dazu. Tabellennamen kommen aus $wpdb->prefix, nicht hartkodiert als wp_. Und wo WP_Query, get_posts oder die Meta-API dieselbe Aufgabe lösen, gewinnt die API: sie ist nicht nur sicherer, sie nutzt auch den Objekt-Cache, den eine handgeschriebene Abfrage umgeht.

Nonce und Rechteprüfung sind zwei getrennte Prüfungen. Ein Nonce belegt, dass die Anfrage aus dem eigenen Formular und aus der laufenden Sitzung stammt, also gegen Cross-Site Request Forgery. Über Berechtigungen sagt er nichts. Im Formular steht wp_nonce_field mit einer eigenen, sprechenden Action, serverseitig prüfen check_admin_referer oder wp_verify_nonce. Bei Admin-Ajax nutzen wir check_ajax_referer mit gesetztem Abbruch-Parameter, damit die Verarbeitung bei einem ungültigen Token endet und nicht weiterläuft. Ein Handler am Hook wp_ajax_nopriv_ ist ein bewusst öffentlicher Endpunkt: dort gehört nichts hin, was Daten schreibt oder fremde Datensätze liest. Erst danach folgt die Rechteprüfung mit current_user_can, und zwar auf eine Capability, nicht auf einen Rollennamen: edit_posts, manage_options oder objektbezogen edit_post mit der konkreten ID. Bei REST-Routen ist permission_callback in register_rest_route verpflichtend; __return_true ist ausschließlich für wirklich öffentliche Leserouten vertretbar, Schreibrouten prüfen Capability und Objektbesitz. Angemeldete Aufrufe schicken den Nonce im Header X-WP-Nonce mit der Action wp_rest. Meta-Felder, die im Editor oder über die REST-API sichtbar sein sollen, registrieren wir mit register_post_meta samt sanitize_callback, auth_callback und explizitem Schema, statt sie einfach auf show_in_rest zu stellen.

Escaping gehört an die Ausgabe, spät und kontextabhängig. Bereinigung beim Speichern ersetzt kein Escaping beim Ausgeben, weil derselbe Wert später in unterschiedlichen Kontexten landet. Für Text zwischen Tags nehmen wir esc_html, für Attributwerte esc_attr, für Links und Bildquellen esc_url, für Formularfelder esc_textarea und für redaktionelles HTML wp_kses_post oder ein eigenes, enges Tag-Set über wp_kses. Daten, die an JavaScript übergeben werden, laufen über wp_json_encode und wp_add_inline_script oder wp_localize_script, nicht als eingebettete Zeichenkette im Markup. Übersetzte Strings gehen über esc_html__, esc_attr__ oder esc_html_e, damit auch Übersetzungen kein Markup einschleusen können. Serverseitig gerenderte Blöcke folgen denselben Regeln: Attribute aus dem Editor sind Nutzereingaben und werden im render_callback genauso escaped wie alles andere.

Geprüft wird in der Pipeline, nicht im Kopf. In phpcs.xml.dist konfigurieren wir die WordPress Coding Standards so, dass die sicherheitsrelevanten Sniffs als Fehler gelten und nicht als Warnung: WordPress.Security.EscapeOutput, WordPress.Security.ValidatedSanitizedInput, WordPress.Security.NonceVerification, WordPress.DB.PreparedSQL und WordPress.DB.PreparedSQLPlaceholders. Dazu kommt statische Analyse mit PHPStan und WordPress-Stubs auf einem festgelegten Level sowie composer audit für die Abhängigkeiten. Jeder Pull Request läuft gegen diese Prüfungen, ein neuer Verstoß blockiert den Merge, statt in einem Backlog zu verschwinden. Ebenso gehört die PHP-Version dazu: nur aktiv unterstützte Zweige bekommen Sicherheitspatches, Projekte laufen deshalb auf PHP 8.2 oder neuer.

Fremde Plugins vor dem Produktiveinsatz durchsehen. Die Zahl der aktiven Installationen ist kein Qualitätsnachweis. Wir schauen zuerst auf das Datum der letzten Aktualisierung, die Angabe „getestet bis”, unbeantwortete Support-Threads und darauf, ob das Plugin überhaupt ein öffentliches Repository hat. Danach sehen wir in den Code: Vorkommen von eval, base64_decode, extract, unserialize auf Nutzerdaten, direkte Zugriffe auf $_GET und $_POST ohne Bereinigung, $wpdb->query mit verkettetem SQL, Handler am Hook wp_ajax_nopriv_ mit Schreibzugriff und REST-Routen mit permission_callback auf __return_true. wp plugin verify-checksums zeigt Abweichungen vom Stand im Plugin-Verzeichnis und damit händisch gepatchte oder manipulierte Dateien. Bekannte Schwachstellen gleichen wir gegen eine Schwachstellen-Datenbank ab, bevor das Plugin auf die Produktivumgebung darf. Sogenannte nulled Premium-Plugins aus inoffiziellen Quellen kommen grundsätzlich nicht ins Projekt, weil dort regelmäßig Hintertüren mitgeliefert werden. Das Ergebnis der Durchsicht ist eine von drei Entscheidungen: einsetzen, durch eine gepflegte Alternative ersetzen oder die benötigte Funktion als schlanken eigenen Code bauen. Die Begründung landet im Architecture Decision Record, damit beim nächsten Update nachvollziehbar bleibt, warum diese Abhängigkeit im Projekt ist.

Und wenn doch etwas passiert. Der Ablauf steht vorher fest: Zuständigkeiten benennen, betroffene Zugänge sperren, Salts und Schlüssel in wp-config.php neu setzen, Anwendungspasswörter widerrufen, Nutzerkonten und Rollen auditieren, dann aus einem geprüften Backup nach der 3-2-1-Regel wiederherstellen. Wichtig ist, dass die Wiederherstellung vorher einmal geprobt wurde, sonst ist das Backup nur eine Annahme. Reaktionszeiten, Eskalationsweg und Rufbereitschaft regelt der Wartungsvertrag, nicht ein Versprechen auf einer Website.

#WordPress in weiteren Städten

Für Unternehmen mit Werft- oder Hafenbezug in Norddeutschland und bayerischem Produktionsstandort ist unsere WordPress-Entwicklung in Bremen ein sinnvoller Vergleichspunkt.

Für Unternehmen mit bayerischem und baden-württembergischem Produktionsstandort ist unsere WordPress-Entwicklung in Stuttgart ein sinnvoller Vergleichspunkt.

Franken-Standorte vergleichen Redaktions-Workflows häufig mit unserer WordPress-Entwicklung in Nürnberg.

#Starten Sie Ihr Projekt in Augsburg

Bereit, Ihre Anforderungen zu besprechen? Wir bieten ein kostenfreies Erstgespräch, in dem wir Ihre aktuelle Einrichtung prüfen, Möglichkeiten benennen und einen praktischen Fahrplan skizzieren. Kein Verkaufsgespräch, sondern technische Beratung.

Ob Neubau eines Block-Themes, Migration weg von einem überladenen Page-Builder oder laufende technische Betreuung, der erste Schritt ist immer derselbe: ein Gespräch über Ihre Ziele, Ihren Stack und Ihre Rahmenbedingungen am Standort Augsburg.