WordPress Entwickler in Düsseldorf

Düsseldorf ist als Landeshauptstadt Nordrhein-Westfalens ein Standort, an dem sich Konzernzentralen, eine ausgeprägte Messewirtschaft und eine der dichtesten japanischen Geschäftsgemeinschaften Europas auf engem Raum überlagern. Henkel an der Königsallee, Vodafone Deutschland im Vodafone-Campus, E.ON, Rheinmetall, Metro und Daimler Truck halten hier ihre Konzernsitze oder bedeutende Teilbereiche; gleichzeitig sitzen rund um die Immermannstraße und das Eko-Haus im Stadtteil Niederkassel mehrere hundert japanische Unternehmen, von Mitsubishi über Canon bis zu Trading Houses, die Düsseldorf seit den späten 1950er Jahren als europäischen Brückenkopf nutzen. Wer hier eine WordPress-Site betreibt, sei es ein B2B-Hersteller im Hafen, ein Modeunternehmen im Umfeld der CPD und der Schauen rund um die Modemesse, oder ein Aussteller auf der ProWein und der drupa, hat einen anderen Anforderungskatalog als ein durchschnittlicher Mittelständler.

Diese Seite beschreibt die Leistung dahinter: Senior-WordPress-Entwicklung für Düsseldorf, mit mehrsprachigen Architekturen, Custom-Gutenberg und einem Lieferweg, der die regulatorischen Vorgaben des deutschen Markts und die Eigenheiten des japanischen Geschäftspublikums ernst nimmt.

#WordPress-Entwicklung für den Standort Düsseldorf

Drei Auftraggebergruppen prägen das Düsseldorfer Bild, und sie stellen jeweils eigene Anforderungen an den WordPress-Stack. Da sind erstens die international ausgerichteten Konzern- und DAX-Häuser mit Sitz an der Königsallee, im Medienhafen oder am KAP1: Henkel, Vodafone, E.ON, Rheinmetall, Uniper, Metro. Sie betreiben in der Regel keine monolithische Konzernsite mit WordPress, aber sehr wohl Tochtermarken, Geschäftsbereichs-Microsites, Karriereportale und Kampagnen-Landings, bei denen WordPress die schnellste Lieferform bleibt. Zweitens der klassische rheinische Mittelstand und die Messekunden rund um Messe Düsseldorf am Stockumer Höfeweg, deren Sites zur ProWein, zur K, zur drupa, zur Boot oder zur Caravan Salon Lastspitzen aushalten und in einer halbjährlich getakteten Redaktionswelle gepflegt werden müssen. Und drittens die japanische Geschäftsgemeinschaft am Niederkasseler Eko-Haus und an der Immermannstraße: Unternehmen, die ihre europäischen Aktivitäten von Düsseldorf aus steuern und Sites brauchen, die japanische Mutter, deutsche Tochter und englischsprachiges Vertriebsumfeld unter einer einzigen Pflegeoberfläche zusammenbringen.

Was diese Gruppen verbindet: Keine sucht eine Vorlage mit ausgetauschtem Ortsnamen. Sie suchen einen Entwickler, der den realen Stack benennt, die Sprachstruktur sauber zieht und die deutschen Pflichten technisch korrekt umsetzt.

#Was im Leistungsumfang liegt

• Mehrsprachige Sites mit Polylang, WPML oder einer eigenen Locale-Architektur, ausgelegt auf DE/EN als Pflicht und optional JP und FR, mit hreflang, lokalisierten Slugs und getrennter Redaktion pro Sprache
• Eigene Block-Themes auf Basis von theme.json, Block-Patterns und Style-Varianten, damit Marketing- und Kommunikationsteams im Site-Editor ohne Entwickler-Eingriff arbeiten können
• Headless-Optionen mit Astro oder Next.js auf einer WordPress-Datenquelle, sinnvoll für Kampagnen-Microsites mit harten Performance-Zielen oder integrierten Komponenten aus einem bestehenden Design-System
• Custom-Gutenberg-Blöcke für wiederkehrende redaktionelle Bausteine, etwa Messetermine, Standortkarten oder Produkt-Datenblätter, statt jedem Wunsch ein weiteres Page-Builder-Plugin aufzudrücken
• REST-API- und WPGraphQL-Endpunkte für die Anbindung an SAP, Salesforce, HubSpot oder bestehende PIM-Systeme, mit Authentifizierung, Rate Limiting und dokumentiertem Wiederherstellungspfad
• BFSG-Umsetzung mit WCAG 2.2 AA: semantisches Markup, ARIA-Landmarks, Tastaturbedienung, Fokus-Management und automatisierte Checks in der CI, relevant für jeden B2C-Anbieter ab Juni 2025

#Der deutsche Rechts- und Zahlungsrahmen, technisch umgesetzt

Eine WordPress-Site für den deutschen Markt ist erst dann fertig, wenn sie die Pflichten erfüllt, an denen generische Vorlagen scheitern. In Düsseldorf kommt der Praxisdruck aus dem nahen Verkehr mit Konzern-Compliance-Abteilungen und mit japanischen Mutterhäusern, die deutsche Vorgaben oft strenger umsetzen als der Markt sie verlangt.

• Barrierefreiheitsstärkungsgesetz (BFSG): seit Juni 2025 Pflicht für B2C-Angebote und viele Mischmodelle. Wir setzen das nicht als Audit-Pflichtübung um, sondern als feste Linie im Component Layer und in der CI, mit Lighthouse- und axe-Checks pro Branch.
• DSGVO und TTDSG: Cookie-Consent vor dem Laden von Drittanbieter-Skripten, dokumentierte Verarbeitungszwecke, Hosting in deutschen oder EU-Rechenzentren bei Hetzner, IONOS oder mittwald. Für japanische Auftraggeber dokumentieren wir die Verarbeitungsdetails zusätzlich in einer englischen Version, weil die Tokyo-seitige Rechtsabteilung sie sonst nicht freigibt.
• NIS2: für wesentliche und wichtige Einrichtungen, häufig Henkel-Zulieferer, Energieversorger im E.ON-Umfeld oder kritische Logistik im Hafen, ist NIS2 auch für die Web-Infrastruktur relevant. Logging, Patch-Pflichten und Incident-Response müssen in Plugins und Hosting greifen.
• Impressum und Widerrufsrecht: korrekt platziert, eingebunden so, dass sie Theme-Updates überleben.

Bei Shops gehört dazu eine Bezahlmischung, die zum deutschen Käuferverhalten passt: PayPal, Klarna mit Rechnungskauf für höhere Warenkörbe, SEPA-Lastschrift, Kartenzahlung und Apple Pay sowie Google Pay. Der Wegfall von giropay Ende 2024 hat die Lücke teils zu Wero verschoben, teils zurück in den klassischen Rechnungskauf. Trusted Shops und eKomi sind die üblichen Vertrauenssiegel im DACH-Handel; Idealo-Feeds sind für Preisvergleich-affine Sortimente weiter ein Pflichtkanal.

#WooCommerce für den Düsseldorfer Mittelstand und Konzern

Im Düsseldorfer Umfeld ist WooCommerce selten der Hauptshop eines Konzerns, dafür sehr oft der Markenshop einer Tochter oder das Vertriebsfenster eines B2B-Bereichs. Der Schwerpunkt liegt dann auf der Korrektheit von Steuer-, Versand- und Rechtsprozessen: differenzierte Mehrwertsteuersätze, korrekte Brutto-Preisauszeichnung, Versandkostenangaben vor Vertragsschluss und eine saubere Anbindung an DATEV oder die jeweilige Konzernbuchhaltung. Wir halten die Plugin-Liste knapp, prüfen jede Erweiterung auf Wartungsstand und Performance-Last und verlagern wiederkehrende Geschäftslogik in eigene, getestete mu-plugins. Versanddienstleister-Anbindung an DHL, DPD und Hermes erfolgt über offizielle API-Pakete, nicht über Screen-Scraping-Brücken. Für japanische Auftraggeber spielt zusätzlich der reibungsfreie Wechsel zwischen Yen-, Euro- und teils US-Dollar-Auspreisung im Hintergrund eine Rolle, ohne dass der Käufer im Frontend Währungslogik zu sehen bekommt.

#So arbeiten wir an einem Düsseldorfer Projekt

Der Ablauf ist auf Nachvollziehbarkeit ausgelegt, ein Wert, den Auftraggeber sowohl aus dem deutschen Konzernumfeld als auch aus japanischen Mutterhäusern 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. Die technische Schuld wird schriftlich dokumentiert, mit Quellenbezug auf konkrete Theme- und Plugin-Dateien.
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 WCAG 2.2 AA. Erst danach geht etwas live.
5. Start und Übergabe. DNS, TLS, Redirect-Prüfung, Cache-Warmup, Monitoring. Nach dem Start bleiben wir in Bereitschaft, danach folgt eine Übergabe-Session mit schriftlichem Runbook und, wenn nötig, einer japanischen oder englischen Begleitversion für die Mutterabteilung.

#Typische Aufträge aus dem Düsseldorfer Umfeld

Drei Muster tauchen hier regelmäßig auf:

• Marken- oder Tochter-Site eines Konzerns mit Sitz an der Königsallee oder im Medienhafen. Die Konzern-IT betreibt eine Headless-Plattform für die Hauptmarke; eine neue Tochter oder eine Kampagne braucht in wenigen Wochen eine eigene, mehrsprachige Site, die im gleichen Design-System bleibt und an dieselben Analytics- und Consent-Stränge angeschlossen ist. Wir liefern WordPress als Content-Backend und entweder ein Block-Theme oder ein Astro/Next.js-Frontend, das die vorhandenen Tokens und Komponenten weiterverwendet.
• Messebegleitende Microsite zur ProWein, drupa oder Caravan Salon. Eine Site, die einige Wochen vor und während der Messe Lastspitzen mit Tausenden gleichzeitigen Besuchern trägt, mehrsprachige Terminanmeldungen ermöglicht und nach der Messe ohne Folgekosten in einen Archivmodus geht. Hier zählen Full-Page-Caching über Cloudflare, vorab gefahrene Lasttests und eine klar dokumentierte Stilllegungs-Pflicht.
• Japanisch-deutsch-englische Mittelstandssite an der Immermannstraße oder in Niederkassel. Drei Sprachen, drei Redaktionsverantwortungen, ein zentrales Asset- und Bildrechte-Management. Wir entkoppeln Übersetzung von Layout, sodass Tokyo-Texte nicht jedes Mal das deutsche Template mitschleppen, und richten eine Freigabekette ein, die mit den realen Schichten in Düsseldorf und Tokio (UTC+9, sieben bis acht Stunden Versatz) funktioniert.

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.

#Performance als harter Conversion-Faktor

Geschwindigkeit ist messbar und ranking-relevant, weil Google die Core Web Vitals in die Page-Experience-Bewertung einbezieht. Im Düsseldorfer Umfeld kommt ein zweites Argument hinzu: Konzernportale werden häufig aus Nicht-DACH-Standorten besucht, etwa aus japanischen Mutterhäusern oder aus französisch- und englischsprachigen Vertriebsregionen. Eine träge Site wirkt sich dann nicht nur auf Rankings, sondern auf interne Akzeptanz aus.

• Assets: responsive Srcsets in WebP und AVIF, Critical CSS inline für den sichtbaren Bereich, JavaScript per Code-Splitting nur dort geladen, wo es gebraucht wird
• Caching: mehrstufig über Browser-Cache, Cloudflare-CDN, Redis-Object-Cache und Transients mit gezielter Invalidierung
• Netzwerk: HTTP/3 mit QUIC, Brotli-Kompression, Preconnect- und DNS-Prefetch-Hints für externe Schriften und CDN-Ressourcen
• Rendering: Lazy Loading für Bilder und Iframes, asynchrones Laden nicht-kritischer Stylesheets

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, Datenschutz und NIS2

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. Für Sites, die personenbezogene Daten verarbeiten, kommt eine DSGVO-konforme Architektur hinzu: Auftragsverarbeitungsverträge, dokumentierte Verarbeitungszwecke und Privacy-by-Design.

Für Auftraggeber im NIS2-Geltungsbereich, häufig Industrie- und Energie-Zulieferer im Düsseldorfer und Niederrhein-Umfeld, prüfen wir zusätzlich die Anforderungen an Logging, Patch-Management und Incident-Response auf der Web-Infrastruktur. Das ist keine reine Hosting-Frage, sondern reicht in die Plugin-Auswahl und in die Update-Routinen hinein.

#Lokale Sichtbarkeit in Düsseldorf

Eine gute Site nützt nichts, wenn die Zielgruppe in Düsseldorf, im Rheinland und in den angeschlossenen Auslandsmärkten 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, Event für Messeauftritte), 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 Düsseldorf und benachbarte Standorte am Niederrhein
• Hreflang und locale-getrennte Metadaten für Auftraggeber, die von Düsseldorf aus deutschsprachige, englischsprachige, französischsprachige und japanischsprachige Märkte bedienen, ein häufiger Fall im konzern- und exportnahen Umfeld

#Die REST-API und Headless nüchtern betrachtet

Headless wird in Düsseldorfer Ausschreibungen häufig als Qualitätsmerkmal genannt, bevor jemand geprüft hat, ob der konkrete Anwendungsfall es überhaupt trägt. Die Trennung von Redaktion und Auslieferung ist kein Selbstzweck, sie verschiebt Komplexität an eine andere Stelle. Am Anfang steht deshalb die Frage, ob diese Komplexität an der neuen Stelle leichter zu beherrschen ist als an der alten.

Wann Headless wirklich trägt. Es gibt vier Muster, bei denen sich die Entkopplung rechnet. Erstens: Ein Konzern betreibt bereits ein Design-System als React- oder Web-Component-Bibliothek, und die Tochter-Site soll dieselben Komponenten verwenden, statt sie im PHP-Theme nachzubauen. Zweitens: Ein Inhaltsbestand wird an mehr als eine Oberfläche ausgeliefert, etwa Website, Messe-Terminal und App, und WordPress ist die redaktionelle Quelle für alle drei. Drittens: Es gilt ein hartes Performance-Budget an den Core-Web-Vitals-Schwellen (LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1), auch für Abrufe aus Japan und anderen asiatischen Märkten, und ein statisch vorgerendertes Frontend am Edge löst das zuverlässiger als ein PHP-Rendering mit Full-Page-Cache. Viertens: Die Redaktion soll auf einem Host arbeiten, der öffentlich gar nicht erreichbar ist, was in Sicherheitsprüfungen von Konzern-IT-Abteilungen regelmäßig verlangt wird.

Wann Headless nur Komplexität hinzufügt. Bei einer Site, die Inhalte an genau eine Oberfläche ausliefert, deren Layout von der Redaktion im Site-Editor verändert werden soll und deren Traffic ein normaler Full-Page-Cache trägt, gewinnt die klassische WordPress-Auslieferung. Bezahlt wird die Entkopplung mit zwei Codebasen, zwei Abhängigkeitsbäumen, zwei Deploy-Wegen und einem Frontend, das jede Layout-Änderung als Entwicklungsaufgabe behandelt statt als Redaktionsaufgabe. Wer serverseitig gerenderte Blöcke einsetzt, also register_block_type mit render_callback und ServerSideRender im Editor, muss die Darstellungslogik im Frontend-Framework ein zweites Mal implementieren. Aus einem Custom-Block werden dann zwei Artefakte, die auseinanderlaufen können.

Authentifizierung für schreibende Zugriffe. Lesende Endpunkte sind der einfache Teil. Sobald ein Formular, eine Terminanmeldung oder eine Integration in die REST-API schreibt, entscheidet sich die Sicherheit der Site an drei Details. Erstens am permission_callback in register_rest_route: er muss eine echte current_user_can-Prüfung enthalten, niemals __return_true. Ein Endpunkt ohne Prüfung ist ein offener Schreibzugang, unabhängig davon, wie unauffällig die Route heißt. Zweitens am Authentifizierungsverfahren: Cookie-Authentifizierung funktioniert nur zusammen mit einem wp_rest-Nonce und nur bei gleicher Herkunft, also gleichem Schema, gleicher Domain und gleichem Port, was bei einem Headless-Aufbau mit getrennten Domains entfällt. Für Maschine-zu-Maschine-Zugriffe sind Application Passwords (seit WordPress 5.6 im Core) der Standardweg, für längere Sitzungen aus einem entkoppelten Frontend ein JWT- oder OAuth-Verfahren mit kurzer Gültigkeit und Rotation. Drittens an der Begrenzung: Rate Limiting im Reverse Proxy oder in Cloudflare, ein technischer Benutzer je Integration statt eines geteilten Admin-Kontos, und der Entzug einzelner Application Passwords, ohne dass der Mensch dahinter sein eigenes Passwort wechseln muss. Jeder schreibende Endpunkt bekommt außerdem ein args-Schema mit validate_callback und sanitize_callback, sonst wandert die Validierung in die Geschäftslogik und wird dort vergessen.

Zwischenspeicherung auf API-Ebene. Eine REST-Antwort wird ohne Zutun nicht zwischengespeichert, jeder Aufruf kostet einen vollen WordPress-Bootstrap. Drei Ebenen greifen ineinander: ein Objekt-Cache über Redis für die Datenbankabfragen darunter, ein HTTP-Cache mit Cache-Control und stale-while-revalidate auf den lesenden Routen, gesetzt über den Filter rest_post_dispatch, und ETag-Unterstützung, damit unveränderte Antworten mit Status 304 enden. Die Invalidierung hängt an save_post, transition_post_status und deleted_post, nicht an einer Zeitspanne, sonst sehen Redakteure ihre Änderung erst nach Ablauf des Fensters. Zwei Stellschrauben senken die Last spürbar, bevor überhaupt zwischengespeichert wird: Der Parameter _fields reduziert die Antwort auf die tatsächlich benötigten Felder, und _embed gehört bewusst gesetzt statt pauschal, weil es zusätzliche Abfragen auslöst. Für Listen gilt die Obergrenze von 100 Einträgen je Seite; wer mehr braucht, blättert über X-WP-TotalPages weiter, statt die Grenze anzuheben. Die Wirkung misst man an der Zeit bis zum ersten Byte, etwa mit curl, der Option -w und der Variablen time_starttransfer, einmal kalt und einmal warm abgefragt.

Vorschau und Redaktionsablauf, der am häufigsten übersehene Punkt. In einem klassischen Theme ist die Vorschau eine Selbstverständlichkeit. Im Headless-Aufbau ist sie eine eigene Entwicklungsaufgabe, und sie fällt in Angeboten regelmäßig unter den Tisch. Der Vorschau-Link von WordPress zeigt auf das Backend, nicht auf das entkoppelte Frontend; Entwürfe liegen im Status draft und sind über die REST-API nur mit Authentifizierung erreichbar; Cookies mit SameSite-Beschränkung werden über die Domaingrenze hinweg nicht mitgesendet. Praktikabel ist eine eigene Vorschau-Route im Frontend, die ein kurzlebiges, signiertes Token entgegennimmt, die Inhalte serverseitig mit einem technischen Konto abruft und die Seite ohne Zwischenspeicherung ausliefert, dazu ein über preview_post_link umgeleiteter Vorschau-Button, damit die Redaktion ihren gewohnten Weg behält. Dazu kommen zwei weitere Abläufe: Geplante Beiträge wechseln über WP-Cron in den Status publish, ohne dass ein statisch gebautes Frontend davon erfährt, also braucht es einen Webhook auf transition_post_status, der den Neuaufbau der betroffenen Seiten auslöst. Und Revisionen, Freigabeketten und rollenbasierte Sichtbarkeit müssen im Frontend dieselbe Semantik behalten wie im Backend, sonst sieht ein Freigeber etwas anderes als der spätere Besucher. Bei einer dreisprachigen Redaktion mit deutscher, englischer und japanischer Verantwortung multipliziert sich das: Die Vorschau muss je Sprachversion funktionieren, sonst wird die Freigabe über die Zeitverschiebung hinweg zur Rückfrageschleife.

Der Betreuungsaufwand danach. Nach dem Start betreut man zwei Systeme statt eines. WordPress braucht weiterhin Core-, Plugin- und PHP-Pflege; das Frontend hängt zusätzlich am Lebenszyklus seiner Node-Version und seiner Framework-Abhängigkeiten, die schneller altern als WordPress-Plugins. Build-Fehler werden zu einem Ausfallgrund, den es vorher nicht gab: Ein fehlerhafter Inhalt kann den Build stoppen, also muss die Auslieferung auf den letzten erfolgreichen Build zurückfallen können. Die 3-2-1-Regel für Backups gilt für beide Seiten, Datenbank und Uploads auf der WordPress-Seite, Build-Artefakte und Konfiguration auf der Frontend-Seite, und der Wiederherstellungspfad muss beide zusammen wieder in einen konsistenten Stand bringen. Die Überwachung braucht zwei Blickwinkel: die Verfügbarkeit der API und die Erfolgsquote der Builds und der ausgelösten Neuaufbauten. Wer diesen Aufwand nicht dauerhaft tragen will, ist mit einem gut gebauten Block-Theme besser bedient. Deshalb halten wir die Headless-Entscheidung in einem dokumentierten Architekturentscheid (Architecture Decision Record) mit Begründung und Gegenargument fest, und der Umfang der laufenden Betreuung inklusive Reaktionszeiten wird im Wartungsvertrag geregelt, nicht auf einer Angebotsfolie angedeutet.

#Häufige Fragen aus Düsseldorf

Wir haben eine japanische Muttergesellschaft, die Tokyo-seitig freigibt. Wie läuft das praktisch? Wir liefern die schriftliche Architektur- und Sicherheitsdokumentation zusätzlich auf Englisch, mit klarer Begriffsabbildung auf die deutschen Pflichten (BFSG, DSGVO, TTDSG). Freigabezyklen takten wir so, dass der UTC+9-Versatz nicht zu einer Wartezeit von ganzen Tagen wird, sondern die Sprints jeweils mit einem Stand übergeben werden, der auch ohne Rückfrage einen Tag lang sinnvoll bleibt.

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. Klassische Themes behalten ihren Platz, wenn viel individuelle Logik portiert werden müsste oder die Redaktion mit dem klassischen Editor besser arbeitet, etwa bei langjährig gewachsenen Konzern-Tochter-Sites mit eigenen Editor-Workflows.

Was unterscheidet das von einer generischen Agentur in Düsseldorf? Der Umfang dreht sich um WordPress-Entwicklung, nicht um ein breites Relaunch-Paket. Sie sprechen direkt mit dem Senior-Entwickler, der den Code schreibt, nicht mit einem Projektmanager, der 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 Tochter- oder Kampagnensite liegt oft bei wenigen Wochen, eine mehrsprachige Konzernanbindung mit ERP-Schnittstelle deutlich darüber. 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 Finanzplatz vergleichen Mehrsprachigkeit und DORA-Pflichten häufig mit unserer WordPress-Entwicklung in Frankfurt am Main.

Rhein-Ruhr-Konzerne im Ruhrgebiet vergleichen Mehrsprachigkeit häufig mit unserer WordPress-Entwicklung in Dortmund und WordPress-Entwicklung in Essen.

Bundesnahe Standorte am Mittelrhein vergleichen Mehrsprachigkeit häufig mit unserer WordPress-Entwicklung in Bonn.

#Nächster Schritt

Bereit, Ihr WordPress-Vorhaben in Düsseldorf zu besprechen? Den Einstieg bildet ein Gespräch über Ziele und Rahmenbedingungen sowie eine Prüfung Ihrer aktuellen Einrichtung. Kein Verkaufsgespräch, sondern technische Beratung von Entwicklern, die seit 2007 mit WordPress arbeiten. Ob Neubau, Migration auf moderne Block-Architektur, Headless-Aufsatz für eine Konzern-Tochter oder laufender Support für eine japanisch-deutsch-englische Mittelstandssite: Der erste Schritt ist immer dieselbe ehrliche Bestandsaufnahme.