WordPress Entwickler in Frankfurt

Frankfurt am Main ist kein durchschnittlicher Wirtschaftsstandort, sondern der Finanzplatz, an dem die Europäische Zentralbank, die Deutsche Bundesbank, Deutsche Bank, Commerzbank und KfW ihren Sitz haben. Wer in diesem Umfeld eine WordPress-Site betreibt, sei es als Tochter eines Bankhauses, als Logistikdienstleister am Frankfurt Airport, als Aussteller auf dem Messegelände oder als FinTech-Startup im TechQuartier am Platz der Republik, arbeitet in einer regulatorischen Dichte, die generische Agenturen unterschätzen. DORA, BFSG, DSGVO, NIS2 und die Aufsicht durch BaFin und Bundesbank wirken bis in das CMS hinein, das die Marketingabteilung pflegt.

Diese Seite beschreibt die Leistung dafür: Senior-WordPress-Entwicklung für Frankfurt am Main, mit Code nach WordPress Coding Standards, Barrierefreiheit nach WCAG 2.2 AA und einem Lieferweg, der vor einer BaFin-orientierten internen Revision genauso bestand hat wie vor dem Kommunikationsteam des Auftraggebers.

#WordPress-Entwicklung für den Standort Frankfurt am Main

Die Auftraggeber in Frankfurt lassen sich grob in vier Profile gliedern, und jedes profil stellt andere Anforderungen an den WordPress-Stack. Banken, Versicherungen, Asset-Manager und ihre Dienstleister im Bankenviertel und im Westend brauchen mehrsprachige Marketing-Sites, die sauber von den regulierten Produktstrecken getrennt sind, dazu Karriereportale, Investor-Relations-Bereiche und Ad-hoc-Veroeffentlichungsstrukturen. Die Logistik- und Luftfracht-Akteure rund um Frankfurt Airport, von Lufthansa Cargo über DB Schenker bis zu mittelständischen Spediteuren, verlangen Sites, die mit Buchungs- und Tracking-Backends sprechen. Die Messe- und Verlagskunden im Umfeld von Messe Frankfurt brauchen Veranstaltungs-Sites und Ausstellerportale, die zyklischen Lastspitzen von Light + Building, Buchmesse und Christmasworld standhalten. Und das FinTech- und Startup-Umfeld rund um TechQuartier, Frankfurt School of Finance und Goethe-Universität braucht schnelle Marketing-Surfaces, die vor einem regulierten Produkt-Backend sauber funktionieren.

Was diese Profile verbindet: keines sucht eine Vorlage mit ausgetauschtem Ortsnamen. Sie suchen einen Entwickler, der die konkrete technische Schuld benennt und sie nach WordPress-Standards abbaut, mit Wissen um die regulatorische Realität einer Stadt, in der jeder zweite groessere Kunde mittelbar unter BaFin-Aufsicht steht.

#Was im Leistungsumfang liegt

• Eigene Block-Themes auf Basis von theme.json, Block-Patterns und Style-Varianten, damit Redaktionen im Site-Editor arbeiten können, ohne bei jedem Layoutwunsch eine Entwicklerin zu brauchen
• WordPress Multisite für Banken- und Konzerngruppen mit mehreren Marken aus einer Installation, inklusive zentraler Updates, getrennter Redaktionsrechte und mandantenfaehigem Asset-Handling
• Strukturierte Inhaltsmodelle mit Advanced Custom Fields oder Meta Box, Custom Post Types und Taxonomien, die einen Theme-Wechsel überdauern, weil sie im Plugin liegen, nicht im Theme
• Headless-Frontends mit Astro oder Next.js auf einem WordPress-Backend, sinnvoll für mehrsprachige Konzern-Sites mit hartem Performance-Budget und differenzierter Caching-Strategie
• REST-API- und WPGraphQL-Endpunkte für mobile Apps oder die Anbindung an bestehende ERP-, CRM- und Buchungssysteme, mit Authentifizierung, Rate Limiting und schriftlicher API-Vertragsdokumentation
• Barrierefreiheit nach WCAG 2.2 AA, seit Juni 2025 für B2C-Anbieter durch das BFSG verbindlich: semantisches Markup, ARIA-Landmarks, Tastaturbedienung, Fokus-Management, automatisierte Checks in der CI

#Der deutsche Rechts- und Aufsichtsrahmen, technisch umgesetzt

Eine WordPress-Site für den Frankfurter Markt ist erst dann fertig, wenn sie die Pflichten erfüllt, an denen generische Vorlagen scheitern. Wir setzen sie als Teil der Entwicklung um, nicht als Anhängsel:

• Impressumspflicht nach Digitale-Dienste-Gesetz und ein rechtssicheres Datenschutz-Layout, eingebunden so, dass es bei Theme-Updates nicht verloren geht
• DSGVO und TTDSG durchgängig: Cookie-Consent vor dem Laden von Drittanbieter-Skripten, dokumentierte Verarbeitungszwecke, Auftragsverarbeitungsvertraege, Hosting bei Hetzner, IONOS, mittwald oder vergleichbaren deutschen Anbietern statt nachträglich aufgesetzter Banner
• BFSG seit 28. Juni 2025 für private B2C-Anbieter: barrierefreie Bedienoberflächen, dokumentierte Konformitaetserklaerung und ein definierter Pfad zur Beschwerdebearbeitung
• DORA für Bank-Drittparteien seit dem 17. Januar 2025: dokumentierte Incident-Response, Logging-Strategie und Vertragsklauseln nach Art. 30, dazu Vorbereitung auf die BaFin-Audits, die laut Bundesbank ab 2026 systematisch greifen
• Bei Shops: eine Bezahlmischung, die zum deutschen Kaeuferverhalten passt. PayPal bleibt führend, SEPA-Lastschrift, Klarna und Kartenzahlung gehören in jeden ernsthaften Checkout, und Trusted-Shops-Siegel oder eKomi-Bewertungen lassen sich sauber einbinden. Wer noch giropay nutzt, sollte wissen, dass das Verfahren Ende 2024 eingestellt wurde und Wero die Nachfolge antritt

Diese Punkte sind keine Marketingfloskeln, sondern Implementierungsentscheidungen mit Fristen und Akzeptanzkriterien, die im Vertrag stehen.

#WooCommerce und Headless-Commerce im Frankfurter Mittelstand

Wenn aus der Site ein Shop wird, verschiebt sich der Schwerpunkt vom Theme zur Korrektheit von Steuer-, Versand- und Rechtsprozessen. Im deutschen Kontext heisst das: differenzierte Mehrwertsteuersaetze, korrekte Brutto-Preisauszeichnung, Versandkostenangaben vor Vertragsschluss und eine saubere Anbindung an die Buchhaltung. WooCommerce trägt das, sofern die Erweiterungen mit Bedacht gewählt und nicht wahllos gestapelt werden. Wir halten die Plugin-Liste knapp, prüfen jede Erweiterung auf Wartungsstand und Performance-Last und verlagern wiederkehrende Geschaeftslogik in eigene, getestete mu-plugins statt in ein weiteres Drittanbieter-Plugin.

Für die Anbindung an Warenwirtschaft, DHL- oder DPD-Versand und Idealo-Feeds gilt dasselbe Prinzip wie für jede Integration: eine dokumentierte Schnittstelle, klare Fehlerbehandlung und ein Wiederherstellungspfad, falls ein Drittsystem ausfällt.

#So arbeiten wir an einem Frankfurter Projekt

Der Ablauf ist auf Nachvollziehbarkeit ausgelegt, ein Wert, den Auftraggeber aus dem Banken- und Aufsichtsumfeld sofort wiedererkennen.

1. Analyse und Codebase-Audit. Bevor eine Zeile Code entsteht, prüfen wir die bestehende Installation: Theme-Struktur, eingesetzte Plugins, Integrationen, Hosting-Grenzen sowie eine Baseline für Performance und Barrierefreiheit. Bei Bank-Drittparteien gleichen wir das Logging und die Incident-Response gegen DORA Art. 17 ab und dokumentieren die technische Schuld schriftlich.
2. Architektur und Lieferform. Wir entscheiden, was im Theme und was im Plugin lebt, wie das Inhaltsmodell aussieht und woran die Abnahme gemessen wird. Diese Abwägung wird als Architecture Decision Record festgehalten, nicht als Glaubenssatz.
3. Umsetzung in Feature-Branches. Implementierung nach WordPress Coding Standards, i18n-fähige Texte, barrierefreies Markup, serverseitig gerenderte Blöcke dort, wo es zählt, und Code-Review auf jedem Branch.
4. QA gegen Testumgebung. Regressionschecks, Lighthouse- und Core-Web-Vitals-Ziele, Accessibility-Scan nach BFSG-Massgabe. Erst danach geht etwas live.
5. Start und Uebergabe. DNS, TLS, Redirect-Prüfung, Cache-Warmup, Monitoring. Nach dem Start bleiben wir in Bereitschaft, danach folgt eine Uebergabe-Session mit schriftlichem Runbook und definierten Eskalationswegen.

#Typische Aufträge aus dem Frankfurter Umfeld

Vier Muster tauchen hier regelmaessig auf:

• Trennung von Marketing-WordPress und reguliertem Produkt-Backend. Eine Privatbank betreibt eine Marketing-Site auf WordPress, das Online-Banking läuft auf einem völlig anderen Stack. In der Praxis wachsen die beiden Welten zusammen: Single-Sign-On-Aufrufe, gemeinsame Suche, geteilte Cookie- und Consent-Logik. Wir trennen die Schichten sauber, dokumentieren die Schnittstelle und halten die DORA-relevanten Pfade ausserhalb des CMS.
• Lufthansa-Cargo- und Logistik-Surfaces am Flughafen. Eine Spedition oder ein Cargo-Dienstleister braucht eine Marketing- und Lead-Site, die über REST mit dem Tracking-System spricht. Hier zählt eine saubere Schnittstelle und ein Rechte- und Rollenkonzept, das auch eine Audit-Prüfung übersteht.
• Aussteller- und Eventportale für Messe Frankfurt. Eine Veranstaltungsseite trägt zu Light + Building im März 2026 oder Buchmesse im Oktober Lastspitzen, die den jahresdurchschnittlichen Traffic um Groessenordnungen überschreiten. Wir konfigurieren Full-Page-Caching über Cloudflare, optimieren Datenbankindizes und fahren vorab Lasttests gegen realistische Such- und Buchungspfade.
• FinTech-Startups mit hartem Performance-Budget. Ein Startup aus dem TechQuartier, das 2024 als FinTech Hub Frankfurt anerkannt wurde, will ein WordPress-Marketing-Surface vor einem regulierten Produkt-Backend, mehrsprachig, mit Headless-Frontend und sauberen Vanity-URLs für Investor-Pitches.

Was diese Fälle eint: Der Auftrag bleibt beim Thema WordPress-Entwicklung. Taucht in der Analyse ein anderer Stack auf, der wirklich besser passt, sagen wir das schriftlich, statt unbemerkt das Thema zu wechseln. Das Ergebnis ist immer ein klarer Plan: was geändert wird, was bleiben kann, was gemessen wird und was später kommt.

#Blockeditor, eigene Blöcke und ihre Wartungskosten

Die erste Frage lautet nie, wie ein eigener Block gebaut wird, sondern ob es ihn überhaupt braucht. Der Blockeditor kennt drei Abstufungen, und sie unterscheiden sich vor allem darin, wer den Pflegeaufwand später trägt. Ein Block-Pattern, registriert über register_block_pattern oder als Markup-Datei im Verzeichnis patterns des Themes, ist reine Redaktionshilfe: Die Redaktion fügt es ein, die Blöcke entkoppeln sich sofort vom Original, und niemand muss Code pflegen. Ein synchronisiertes Muster, seit WordPress 6.3 der Nachfolger der wiederverwendbaren Blöcke und im Post-Typ wp_block gespeichert, ändert alle Einbindungen gleichzeitig und eignet sich für Pflichtangaben, Risikohinweise oder wiederkehrende Kontaktbloecke, die an einer Stelle korrigiert werden müssen. Ein eigener Block mit block.json und register_block_type ist die teuerste Variante und nur dann gerechtfertigt, wenn die Ausgabe Daten braucht, die kein vorhandener Block liefert: ein Ergebnis aus einer REST-Abfrage, eine Berechnung, eine Rechteabfrage oder eine Struktur, die redaktionell nicht frei bleiben darf.

Vor dem eigenen Block stehen zwei billigere Werkzeuge. Block-Variationen über registerBlockVariation setzen Voreinstellungen und Attribute für einen Core-Block, ohne dass ein eigener save-Handler entsteht. Die Block Bindings API, seit WordPress 6.5 im Core, verbindet Attribute von Core-Blöcken direkt mit Post-Meta oder einer eigenen Quelle. Damit fällt ein grosser Teil der Fälle weg, für die früher ein eigener Block registriert wurde, etwa ein Absatz, der einen gepflegten Feldwert ausgibt. Erst wenn beides nicht trägt, lohnt sich @wordpress/create-block als Startpunkt und @wordpress/scripts als Build-Kette.

Blockvorlagen halten die Redaktion in der Spur, ohne sie zu entmündigen. Für Custom Post Types lässt sich über die Eigenschaft template bei der Registrierung eine feste Startstruktur setzen, ergänzt um template_lock mit dem Wert all für unveränderliche Bereiche oder insert für Bereiche, in denen umsortiert, aber nichts hinzugefügt werden darf. Innerhalb eigener Blöcke leisten allowedBlocks und templateLock auf der InnerBlocks-Ebene dasselbe. In einem Umfeld wie Frankfurt am Main, wo Freigabeprozesse zwischen Marketing, Recht und Compliance laufen und mehrere Sprachfassungen parallel gepflegt werden, ist das der Unterschied zwischen einer Seite, die nach der zwanzigsten Bearbeitung noch dem abgenommenen Layout entspricht, und einer, die es nicht mehr tut. Die Templates eines Block-Themes liegen in templates und parts als HTML-Dateien und gehören in die Versionskontrolle, damit Aenderungen aus dem Site-Editor nachvollziehbar bleiben und nicht nur als Datenbankeintrag existieren.

Gestaltungsvorgaben gehören in theme.json, nicht in verstreutes CSS. Mit WordPress 6.6 kam Schema-Version 3 der Datei; sie bündelt unter settings die Palette (settings.color.palette), die Schriftgroessen (settings.typography.fontSizes), die Abstandsskala (settings.spacing.spacingScale) und appearanceTools, während styles die Voreinstellungen setzt und styles.blocks einzelne Blocktypen gezielt überschreibt. Wer verhindern will, dass in Beiträgen eigene Farbwerte auftauchen, setzt settings.color.custom und settings.color.customGradient auf false; das hält die Kontrastwerte stabil, die für WCAG 2.2 AA und damit für die BFSG-Konformität nachgewiesen werden müssen. Zusätzliche Blockstile registriert register_block_style serverseitig, sodass sie in der Seitenleiste erscheinen und nicht über das Feld für zusätzliche CSS-Klassen von Hand gepflegt werden.

Die Wartungskosten eines eigenen Blocks entstehen erst nach dem Launch. WordPress veröffentlicht in der Regel mehrere Major-Releases pro Jahr, und mit ihnen wandern Editor-Pakete, Hooks und Markup-Konventionen weiter. Bei einem clientseitig gespeicherten Block vergleicht der Editor bei jedem Laden das gespeicherte Markup mit der Ausgabe der save-Funktion. Ändert sich diese Ausgabe, meldet der Editor ungültigen Inhalt, und der einzige saubere Ausweg ist ein gepflegtes deprecated-Array mit der alten Attributdefinition und der alten save-Funktion. Genau deshalb ist serverseitiges Rendering über die Eigenschaft render in block.json oder einen render_callback für die meisten Geschaeftsfaelle die günstigere Wahl: Es gibt kein gespeichertes Markup, das ungültig werden kann, die Ausgabe folgt immer dem aktuellen PHP-Code, und Suchmaschinen sehen den fertigen Inhalt ohne JavaScript. Dafür muss die Caching-Strategie mitgedacht werden, weil dynamische Blöcke in das Full-Page-Caching eingreifen.

Kalkulieren Sie den Bestand, nicht die Neuentwicklung. Wir führen pro Projekt eine Liste der eigenen Blöcke mit Zweck, Datenquelle und Verantwortlichkeit und prüfen sie bei jedem groesseren WordPress-Update. Getestet wird gegen mehrere WordPress-Versionen über wp-env, die Editor-Interaktion über Playwright-basierte End-to-End-Tests, dazu ein Abgleich der Abhängigkeiten aus den @wordpress-Paketen mit den Skript-Handles, die der Core ausliefert. Blöcke, die nur auf einer einzigen Seite eingesetzt werden und keine dynamischen Daten brauchen, wandern bei dieser Durchsicht zurück in ein Muster. Die Rechnung ist einfach: Jeder eigene Block, den die Site nicht mehr braucht, ist ein Wartungsposten weniger über die nächsten WordPress-Versionen hinweg.

#Performance als Standortvorteil

Geschwindigkeit ist messbar und ranking-relevant, weil Google die Core Web Vitals in die Page-Experience-Bewertung einbezieht. Auf Sites mit Buchungs- oder Tracking-Logik ist sie zugleich ein direkter Umsatzfaktor. Unser Vorgehen pro Projekt:

• Assets: responsive Srcsets in WebP und AVIF, Critical CSS inline für den sichtbaren Bereich, JavaScript per Code-Splitting und dynamischen Imports nur dort geladen, wo es gebraucht wird
• Caching: mehrstufig über Browser-Cache, Cloudflare-CDN, Redis-Object-Cache und Transients mit gezielter Invalidierung, abgestimmt auf die Caching-Konflikte, die personalisierte Bereiche und Cookie-Consent typischerweise erzeugen
• Netzwerk: HTTP/3 mit QUIC, Brotli-Kompression, Preconnect- und DNS-Prefetch-Hints
• Rendering: Lazy Loading für Bilder und Iframes, asynchrones Laden nicht-kritischer Stylesheets, serverseitig gerenderte Blöcke für alles, was Suchmaschinen sehen sollen

Jede Entscheidung wird vorher und nachher gemessen und in der Projektdokumentation hinterlegt. Wir nennen keine pauschalen Prozentversprechen, sondern die konkrete Veränderung an Ihrer Baseline.

#Sicherheit, DORA und NIS2 in der Praxis

Die Sicherheits-Baseline gilt unabhängig von der Branche: HTTPS mit HSTS, Content-Security-Policy gegen XSS, Schwachstellen-Scanning der Abhängigkeiten in der CI, Zwei-Faktor-Authentifizierung für Admin-Zugänge, deaktiviertes XML-RPC und getestete Backups. Bei Auftraggebern aus dem Finanzsektor kommen die DORA-spezifischen Pflichten dazu: ein dokumentierter Incident-Response-Prozess mit Klassifizierung nach Art. 18 DORA, Logging-Aufbewahrung und definierte Meldewege an die BaFin. Bei Unternehmen, die als wichtige Einrichtungen unter NIS2 fallen, etwa groessere Logistiker am Flughafen, erweitern wir die Liste um Lieferkettensicherheit und dokumentierte Patch-Fenster.

Für Sites, die personenbezogene Daten verarbeiten, kommt eine DSGVO-konforme Architektur hinzu: Auftragsverarbeitungsvertraege, dokumentierte Verarbeitungszwecke und Privacy-by-Design. Für Auftraggeber mit laufender Betreuung führen wir regelmaessige Sicherheits- und Zugriffsreviews durch.

#Lokale Sichtbarkeit in Frankfurt am Main

Eine gute Site nützt nichts, wenn die Zielgruppe in Frankfurt und im Rhein-Main-Gebiet sie nicht findet. Wir bauen die SEO-Architektur von Anfang an ein:

• Saubere URL-Struktur, XML-Sitemaps, Canonical-Tags und korrekte Heading-Hierarchie
• Strukturierte Daten nach Schema.org (Organization, LocalBusiness, Service, FAQ), eingebunden über Frontmatter und Komponenten statt von Hand kopierter JSON-LD-Blöcke
• Lokale Optimierung mit Google-Business-Profil, NAP-Konsistenz und standortbezogenem Markup für Frankfurt am Main, inklusive Differenzierung gegenüber Offenbach, Eschborn und Bad Homburg im Umland
• Hreflang und locale-getrennte Metadaten für Auftraggeber, die von Frankfurt aus deutsch-, englisch- und französischsprachige Märkte bedienen, ein häufiger Fall im Banken- und Messeumfeld

#Häufige Fragen aus Frankfurt

Neues Theme oder bestehendes erweitern? Beides möglich. Neubauten starten meist als eigenes Block-Theme auf den Editor-APIs; übernommene Projekte brauchen häufiger ein gezieltes Refactoring von Template-Hierarchie und Asset-Pipeline. Die Entscheidung fällt nach Kosten gegen Schuld, nicht danach, was spannender zu bauen ist.

Gutenberg/FSE oder klassisches PHP-Theme? Voreinstellung für Neubauten ist ein Block-Theme mit Full Site Editing, weil dorthin der WordPress-Editor geht. Klassische Themes behalten ihren Platz, wenn viel individuelle Logik portiert werden müsste oder die Redaktion mit dem klassischen Editor besser arbeitet.

Was unterscheidet das von einer generischen Agentur am Mainufer? Der Umfang dreht sich um WordPress-Entwicklung, nicht um ein breites Relaunch-Paket. Sie sprechen direkt mit der Senior-Entwicklerin oder dem Senior-Entwickler, die den Code schreiben, nicht mit einer Projektmanagerin, die Nachrichten weiterleitet, und nicht mit einem Junior, der auf Ihrem Projekt lernt.

Wie lange dauert ein Projekt? Das hängt von Umfang, Content-Bereitschaft und Integrationstiefe ab. Eine Unternehmenswebsite liegt oft bei wenigen Wochen, ein DORA-relevantes Banking-Marketing-Surface deutlich darüber, ein mehrsprachiges Konzernprojekt mit Systemanbindung entsprechend länger. Einen belastbaren Zeitplan liefern wir nach dem Audit.

Wie ist die Preisgestaltung? Die Kalkulation ist individuell und richtet sich nach Umfang und Integrationsaufwand. Alle Konditionen werden vor Projektbeginn schriftlich im Vertrag festgehalten.

Konzern-Standorte am Niederrhein vergleichen Mehrsprachigkeit und BFSG-Pflichten häufig mit unserer WordPress-Entwicklung in Düsseldorf.

Rhein-Main-Standorte in Wiesbaden und Mannheim nutzen oft dieselbe WordPress-Architektur wie unsere WordPress-Entwicklung in Wiesbaden und WordPress-Entwicklung in Mannheim.

Bundesnahe Konzernportale am Rhein vergleichen Mehrsprachigkeit häufig mit unserer WordPress-Entwicklung in Bonn.

Technologie-Standorte am Oberrhein vergleichen Shop-Architekturen häufig mit unserer WordPress-Entwicklung in Karlsruhe.

#Nächster Schritt

Bereit, Ihr WordPress-Vorhaben in Frankfurt am Main zu besprechen? Den Einstieg bildet ein Gespräch über Ziele und Rahmenbedingungen sowie eine Prüfung Ihrer aktuellen Einrichtung. Kein Verkaufsgespraech, sondern technische Beratung von Entwicklern, die seit 2007 mit WordPress arbeiten. Ob Neubau, Migration auf moderne Block-Architektur, BFSG-Nachrüstung eines Bestandsshops oder laufender Support für ein Banking-Marketing-Surface unter DORA-Aufsicht: Der erste Schritt ist immer dieselbe ehrliche Bestandsaufnahme.