WordPress Entwickler in Dortmund

Dortmund ist eine Stadt, die ihre Identität mehrfach neu geschrieben hat. Dort, wo bis in die späten neunziger Jahre die Hochöfen der Hoesch- und Phönix-Werke standen, liegt heute der Phönix-See, und am gegenüberliegenden Ufer wächst seit Jahren ein IT- und Mittelstandsquartier. Das Technologiezentrum Dortmund (TZDO) am Eingang zum Wissenschaftspark gehört zu den ältesten und größten seiner Art in Deutschland, die TU Dortmund und die Fachhochschule Dortmund liefern Informatik- und Logistik-Absolventen für genau dieses Umfeld, und mit Wilo (Pumpen-Weltmarktführer in Hörde), Signal Iduna (Versicherungs-Konzernsitz an der B1), Dematic, KHS und der DHL-Drehkreuzlogistik am Flughafen sitzen Auftraggeber in der Stadt, deren digitale Strecken Compliance- und Lastanforderungen mitbringen, die ein Standard-Theme aus dem Marketplace nicht trägt.

Diese Seite beschreibt, was Senior-WordPress-Entwicklung in genau diesem Mix bedeutet: Code nach WordPress Coding Standards, BFSG-konforme Barrierefreiheit ab Juni 2025, deutsches Hosting und ein Lieferweg, der für Auditoren und für interne IT-Teams gleichermaßen lesbar bleibt.

#WordPress-Entwicklung für den Standort Dortmund

Die Auftraggeber aus dem Dortmunder Umfeld lassen sich grob in drei Profile aufteilen, und jedes davon legt einen anderen Schwerpunkt im WordPress-Stack fest. Erstens der industrielle und versicherungsnahe Mittelstand: Wilo, Signal Iduna, Dematic und Zulieferer aus dem Logistikkorridor zwischen Hafen, Westfalenhütte und Flughafen brauchen mehrsprachige Konzern- und Karriereseiten mit Single-Sign-On-Anbindung, einem geprüften Rechte- und Rollenkonzept und Lasttests vor Recruiting-Kampagnen. Zweitens das Forschungs- und Ausgründungs-Cluster rund um TU Dortmund, Fachhochschule und Fraunhofer IML mit seinen Logistik- und KI-Schwerpunkten; hier zählen sauber strukturierte Publikations- und Personenseiten, mehrsprachiges Routing und eine Anbindung an Identity-Provider der Hochschule. Drittens der klassische sächlich gesprochen westfälische Handel und Dienstleister von der Brückstraße bis zum Stadtteilzentrum in Hörde oder Aplerbeck, der einen verkaufenden Shop oder eine schlanke Lead-Site im deutschen Rechtsrahmen betreiben will.

Was alle drei verbindet: keiner sucht ein Theme mit ausgetauschtem Stadtnamen. Sie suchen einen Entwickler, der die konkrete technische Schuld benennt und sie nach WordPress-Standards abbaut, mit Dokumentation, die einen Wechsel des Dienstleisters überlebt.

#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 einen Entwickler zu brauchen
• WordPress Multisite für Versicherer, Konzerntöchter oder Fakultäten, die mehrere Marken oder Standorte aus einer Installation pflegen, mit zentralen Updates und getrennten Redaktionsrechten
• 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 einer WordPress-REST-API oder WPGraphQL-Schicht, dort sinnvoll, wo der redaktionelle Komfort von Gutenberg erhalten bleiben soll, die Auslieferung aber statisch und cache-freundlich erfolgen muss
• Barrierefreiheit nach WCAG 2.2 AA mit Blick auf das BarrierefreiheitsstaerkungsGesetz (BFSG), das seit Juni 2025 für E-Commerce und Dienstleistungen mit Verbraucherkontakt gilt: semantisches Markup, ARIA-Landmarks, Tastaturbedienung, Fokus-Management, automatisierte Checks in der CI
• Sicherheitsbaseline mit Blick auf NIS2: deutsches Hosting bei Hetzner, IONOS oder mittwald, Auftragsverarbeitungsverträge, dokumentierte Lieferkette der eingesetzten Plugins und ein Wiederherstellungs-Pfad, der getestet wurde, nicht nur geplant

#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. Wir setzen sie als Teil der Entwicklung um, nicht als Anhängsel:

• Impressumspflicht nach Digitale-Dienste-Gesetz und eine klare Datenschutzerklärung, eingebunden so, dass sie bei Theme-Updates nicht verloren gehen
• Widerrufsrecht und Pflichtinformationen im Bestellprozess, korrekt platziert vor dem zahlungspflichtigen Bestellbutton
• DSGVO und BDSG durchgängig, kombiniert mit TTDSG-konformem Cookie-Consent vor dem Laden von Drittanbieter-Skripten, dokumentierte Verarbeitungszwecke, Hosting in deutschen oder EU-Rechenzentren
• Bei Shops: eine Bezahlmischung, die zum westdeutschen Käuferverhalten passt. PayPal bleibt führend, Kauf auf Rechnung schließt fast gleichauf an und hat bei größeren Warenkörben die höchste Abschlussrate. Klarna, Apple Pay, Google Pay und SEPA-Lastschrift gehören in jeden ernsthaften Checkout. Wer noch giropay bewirbt, sollte wissen, dass das Verfahren Ende 2024 eingestellt wurde und der Nachfolger Wero seit 2025 schrittweise nachrückt
• Versand- und Retourenintegration für DHL als naheliegende Wahl wegen des Dortmunder Drehkreuzes, ergänzt um DPD und Hermes, mit Tracking-Anbindung im Kundenkonto
• Vertrauenssignale über Trusted Shops oder eKomi sowie strukturierter Feed-Export nach Idealo, statt händisch gepflegter Produktlisten

Diese Punkte sind keine Marketingfloskeln, sondern Implementierungsentscheidungen mit Fristen und Akzeptanzkriterien im Pflichtenheft.

#WooCommerce für den Dortmunder Mittelstand

Wenn aus der WordPress-Site ein Shop wird, verschiebt sich der Schwerpunkt vom Theme zur Korrektheit von Steuer-, Versand- und Rechtsprozessen. Im deutschen Kontext heißt das: differenzierte Mehrwertsteuersätze, korrekte Brutto-Preisauszeichnung, Versandkostenangaben vor Vertragsschluss und eine saubere Anbindung an die Buchhaltung über DATEV-Export oder eine direkte Schnittstelle zu Lexware, sevdesk oder Xentral. 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 Geschäftslogik in eigene, getestete mu-plugins statt in ein weiteres Drittanbieter-Plugin. Für die Anbindung an Warenwirtschaft und Versand gilt dasselbe Prinzip wie für jede Integration: eine dokumentierte Schnittstelle, klare Fehlerbehandlung und ein Wiederherstellungspfad, falls ein Drittsystem ausfällt. Bei einem Händler im Speditionsumfeld kann das heißen, dass eine Statusmeldung der Versandschnittstelle nicht den Checkout blockiert, sondern in eine Queue läuft und nachgezogen wird.

#So arbeiten wir an einem Dortmunder Projekt

Der Ablauf ist auf Nachvollziehbarkeit ausgelegt, eine Eigenschaft, die Auftraggeber aus dem versicherungs- und logistiknahen Umfeld 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, nicht mündlich geschätzt.
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.
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 gegen die BFSG-Kriterien. 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.

#Typische Aufträge aus dem Dortmunder Umfeld

Drei Muster tauchen hier regelmäßig auf:

• Migration weg vom Page Builder. Ein Mittelständler aus dem westfälischen Umfeld hat sich über Jahre mit Elementor oder WPBakery zugebaut, die Ladezeit am Phönix-See-Standort liegt nicht mehr in einem Bereich, der bei einem BVB-Heimspiel und gleichzeitigem Kampagnen-Push trägt. Wir überführen die Inhalte in native Gutenberg-Block-Patterns, ohne Live-Traffic oder Rankings zu beschädigen, und schulen die Redaktion auf den neuen Workflow.
• Konzern- oder Karriereseite mit System-Anbindung. Ein Versicherer oder Mittelständler mit Sitz in Dortmund will Stellenausschreibungen, Datenblätter und einen geschützten Bereich für externe Partner aus dem ERP oder dem Bewerber-Tracking-System heraus pflegen. Hier zählt eine saubere REST-Schnittstelle und ein Rechte- und Rollenkonzept, das auch einer internen Revision standhält.
• Skalierung für Lastspitzen. Eine Karriereseite, die rund um eine BVB-bezogene Sponsoring-Kommunikation oder eine Recruiting-Aktion plötzlich vier- oder fünfstellige gleichzeitige Besucher trägt. Wir konfigurieren Full-Page-Caching über Cloudflare, optimieren Datenbankindizes, prüfen die Object-Cache-Anbindung an Redis und fahren vorab Lasttests, statt am Tag der Veröffentlichung zu reagieren.

Was diese Fälle eint: Der Auftrag bleibt beim Thema WordPress-Entwicklung. Taucht in der Analyse ein anderer Stack auf, der wirklich besser passt, etwa ein Headless-Setup mit Sanity oder ein Storefront in Shopware, 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.

#Performance und Core Web Vitals

Geschwindigkeit ist messbar und ranking-relevant, weil Google die Core Web Vitals in die Page-Experience-Bewertung einbezieht. 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
• Netzwerk: HTTP/3 mit QUIC, Brotli-Kompression, Preconnect- und DNS-Prefetch-Hints, sinnvoll besonders für mobile Nutzer im LTE-Bereich entlang der B1 und der A40
• Rendering: Lazy Loading für Bilder und Iframes, asynchrones Laden nicht-kritischer Stylesheets, Intersection-Observer-basierte Animations-Trigger

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

Die Sicherheits-Baseline gilt unabhängig von der Branche: HTTPS mit HSTS-Preloading, 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 regelmäßig getestete Backups. Für Auftraggeber im Umfeld von Versicherern, KRITIS-nahen Versorgern oder größeren Mittelständlern wird die NIS2-Richtlinie zu einem Pflichtkapitel: dokumentierte Lieferkette der WordPress-Plugins, nachweisbare Patch-Zyklen, Incident-Response-Runbook und ein Audit-Logging, das nicht in der WordPress-Datenbank verbleibt.

Für Sites, die personenbezogene Daten verarbeiten, kommt eine DSGVO- und BDSG-konforme Architektur hinzu: Auftragsverarbeitungsverträge mit dem Hoster, dokumentierte Verarbeitungszwecke und Privacy-by-Design im Plugin-Stack. Für Auftraggeber mit laufender Betreuung führen wir regelmäßige Sicherheits- und Zugriffsreviews durch.

#Lokale Sichtbarkeit in Dortmund und im westfälischen Markt

Eine gute Site nützt nichts, wenn die Zielgruppe in Dortmund, im westlichen Sauerland und im Ruhrgebiet 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, Person), eingebunden über Frontmatter und Komponenten statt von Hand kopierter JSON-LD-Blöcke
• Lokale Optimierung mit Google-Business-Profil, NAP-Konsistenz zwischen Impressum, Branchenbüchern und Maps sowie standortbezogenes Markup für Dortmund und benachbarte Stadtteile wie Hörde, Aplerbeck oder Hombruch
• Hreflang und locale-getrennte Metadaten für Auftraggeber, die von Dortmund aus deutsch-, englisch- und polnischsprachige Märkte bedienen, ein häufiger Fall im logistik- und exportnahen Umfeld

#Mehrsprachigkeit und Lokalisierung

Mehrsprachigkeit ist eine Architekturentscheidung, kein Plugin-Kauf. Wer von Dortmund aus Logistik, Maschinenbau oder Versicherungsdienstleistungen vertreibt, bedient regelmäßig deutsch-, englisch- und polnischsprachige Zielgruppen aus einer Installation heraus. Die Frage lautet deshalb nicht zuerst WPML oder Polylang, sondern: Wie viele Sprachen kommen dauerhaft dazu, wer übersetzt (interne Redaktion, Agentur, maschinelle Vorübersetzung mit Lektorat), müssen Produktdaten oder nur redaktionelle Inhalte mehrsprachig sein, und soll jede Sprachversion dieselbe Seitenstruktur haben? Aus diesen vier Antworten folgt die Technik, nicht umgekehrt.

#WPML und Polylang im Vergleich

WPML bringt einen kompletten Übersetzungs-Workflow mit. Die Zuordnung der Sprachversionen liegt in eigenen Tabellen wie wp_icl_translations und wp_icl_strings. Die Module String Translation, Translation Management und der Advanced Translation Editor decken Übersetzerrollen, Auftragsvergabe, Translation Memory und die Anbindung externer Übersetzungsdienste ab. Die Kompatibilität mit Drittanbieter-Plugins wird über eine wpml-config.xml im Plugin- oder Theme-Verzeichnis gesteuert, in der festgelegt wird, welche Custom Post Types, Taxonomien, Meta-Felder und Optionen übersetzbar sind. Der Preis dafür ist Gewicht: mehr Tabellen, mehr Joins, eine spürbare Last im Admin bei Installationen mit vielen registrierten Strings und eine Lizenz, die laufend verlängert werden muss.

Polylang ist schlanker und näher am WordPress-Kern. Die Sprache wird als Taxonomie an Beiträgen und Termen geführt, Übersetzungen sind eigenständige Objekte mit einer Verknüpfung untereinander. Die kostenlose Version deckt Beiträge, Seiten, Kategorien, Schlagwörter, Menüs und Widgets ab; die Pro-Version ergänzt unter anderem übersetzte Slugs, das Duplizieren von Inhalten in andere Sprachen und die Sprachbehandlung in der REST-API. Für Shops ist zusätzlich Polylang for WooCommerce nötig. Für Entwickler ist die API überschaubar: pll_register_string() für eigene Optionstexte, pll__() und pll_e() für die Ausgabe, pll_current_language() und pll_get_post() für Logik in Templates. Was fehlt, ist der Auftrags- und Übersetzerworkflow.

Die Auswahlregel, die wir anwenden: Übersetzen externe Dienstleister oder ein verteiltes Team mit Freigabeschritten, gewinnt WPML, weil der Workflow sonst per E-Mail und Tabellen nachgebaut wird. Pflegt eine kleine Redaktion zwei bis drei Sprachen selbst, gewinnt Polylang, weil weniger Abstraktion weniger Wartung bedeutet. Laufen die Sprachversionen redaktionell wirklich auseinander, also eigene Seitenstruktur, eigene Marken, eigenes Team pro Land, ist WordPress Multisite mit einer Site je Sprache oft ehrlicher als jedes Übersetzungs-Plugin, um den Preis von mehreren zu pflegenden Installationen. Die Entscheidung wird als Architecture Decision Record festgehalten, weil ein späterer Wechsel des Übersetzungs-Plugins immer eine Datenmigration und eine URL-Migration bedeutet.

#Inhalte übersetzen und Plugin-Oberflächen übersetzen sind zwei Aufgaben

Redaktionelle Inhalte laufen über das Übersetzungs-Plugin, Code-Strings über Gettext. Jeder Text, der im Theme oder in einem eigenen Plugin fest im PHP steht, gehört in __(), esc_html__(), _x() oder _n(), mit einer Textdomain, die exakt dem Verzeichnis-Slug entspricht. Eigene Plugins laden ihre Übersetzungen über load_plugin_textdomain(), Themes über load_theme_textdomain(). Die Vorlagen erzeugt wp i18n make-pot, und seit WordPress 6.5 lohnt zusätzlich wp i18n make-php, weil die daraus entstehenden Dateien mit der Endung .l10n.php schneller geladen werden als die klassischen .mo-Dateien. Wer eine Textdomain zu früh registriert, also vor dem Hook init, bekommt seit WordPress 6.7 die Meldung zu _load_textdomain_just_in_time ins Debug-Log; das ist kein kosmetischer Hinweis, sondern ein Zeichen dafür, dass Übersetzungen an dieser Stelle unvollständig greifen können. Sprachdateien des Kerns und der Plugins werden über wp language core install de_DE und wp language plugin update --all gepflegt, nicht per manuellem Upload in wp-content/languages, weil manuelle Kopien beim nächsten Update stillschweigend verschwinden.

Ebenfalls in dieselbe Aufgabe gehören die Übersetzung von E-Mail-Vorlagen (Bestellbestätigung, Passwort-Reset, Formular-Autoresponder), die Beschriftungen von Formularfeldern und Fehlermeldungen, die Texte in Cookie-Consent und Datenschutzhinweisen sowie die Alt-Texte von Bildern. Genau diese Ebene wird bei Übersetzungsprojekten regelmäßig vergessen, weil sie im Frontend erst auftaucht, wenn ein Nutzer sie auslöst.

#Datums-, Zahlen- und Währungsformate

Formate sind Teil der Lokalisierung, nicht der Optik. Für Datumsangaben ist wp_date() die richtige Wahl, weil es die Zeitzone aus wp_timezone() übernimmt und die Ausgabe an das aktive Locale bindet; date_i18n() bleibt für Altcode bestehen, taugt aber nicht als Standard für neue Arbeit. Zahlen laufen über number_format_i18n() statt über PHP-eigene Formatierung mit fest verdrahteten Trennzeichen, denn Deutsch schreibt 1.234,56, Englisch 1,234.56 und Polnisch setzt ein Leerzeichen als Tausendertrenner. Das Datumsformat selbst unterscheidet sich ebenso: TT.MM.JJJJ im Deutschen gegen das amerikanische Muster mit vorangestelltem Monat, was bei Terminseiten und Blogarchiven zu echten Fehlinterpretationen führt.

Im Shop hängt daran mehr als die Darstellung. In WooCommerce steuern die Einstellungen für Dezimal- und Tausendertrennzeichen sowie die Position des Währungssymbols die Ausgabe global, deshalb wird pro Sprache über die Filter woocommerce_price_format, wc_get_price_decimal_separator und wc_get_price_thousand_separator nachgesteuert. Wichtiger als die Zeichensetzung ist die Rechtslage: Für Verbraucher im deutschen Markt werden Endpreise brutto mit Hinweis auf Versandkosten ausgewiesen. Eine englische Sprachversion desselben Shops, die dieselben Artikel netto zeigt, ist kein Übersetzungsdetail, sondern ein Rechtsfehler. Wo eine Währungsumschaltung gewünscht ist, gehört ein fester Umrechnungs- oder Preislisten-Ansatz in die Anforderungen, damit Preise nicht bei jedem Kursausschlag springen. Adress- und Telefonfelder, die Reihenfolge von Vor- und Nachname sowie die Formulierung der Anrede stehen in derselben Liste der Abnahmekriterien.

#hreflang und Canonical korrekt setzen

hreflang entscheidet, welche Fassung eine Suchmaschine welchem Nutzer zeigt, Canonical entscheidet, welche Fassung überhaupt in den Index kommt. Die Regeln sind knapp und werden trotzdem oft verletzt: Jede URL listet alle Sprachvarianten auf, sich selbst eingeschlossen. Die Angaben müssen wechselseitig sein, denn wenn die englische Seite auf die deutsche verweist, die deutsche aber nicht zurück, wird die Angabe ignoriert. URLs stehen absolut mit Protokoll und Host, nicht relativ. Sprachcodes folgen ISO 639-1, die optionale Region folgt ISO 3166-1 alpha-2, also de-DE, de-AT, en-GB und pl-PL; ein Code wie en-UK existiert nicht und wird verworfen. Für die Auswahl- oder Weiterleitungsseite kommt x-default dazu. Die Ausgabe erfolgt entweder im Kopfbereich des Dokuments oder als xhtml:link-Einträge in der XML-Sitemap, aber nur in einer Variante, damit sich beide nicht widersprechen. Das Canonical-Tag jeder Sprachversion zeigt auf sich selbst und niemals auf die deutsche Ausgangsfassung.

Die typischen Fehler, durch die am Ende nur eine Sprachversion indexiert wird:

• Vererbtes Canonical. Die Übersetzung wird als Kopie erzeugt, das manuell gesetzte Canonical-Feld aus Yoast oder Rank Math wandert mit und zeigt weiter auf die deutsche URL. Ergebnis: Die anderen Sprachen werden als Duplikat gewertet und verschwinden aus dem Index.
• Automatische Sprachweiterleitung. Eine Weiterleitung nach IP-Adresse oder Browsersprache schickt einen Crawler, der überwiegend aus den USA anfragt und meist ohne Sprachpräferenz im Kopf der Anfrage arbeitet, dauerhaft in ein und dieselbe Fassung. Die übrigen Sprachversionen bleiben dabei unerreichbar, egal wie sauber hreflang gesetzt ist. Die Sprachwahl gehört in einen crawlbaren Link mit Statuscode 200, nicht in eine Weiterleitung, und schon gar nicht in eine cookie-abhängige Logik, die ein Crawler nie durchläuft.
• Sprachumschalter ohne echten Link. Ein Auswahlfeld oder ein rein per JavaScript geschalteter Umschalter ohne href hinterlässt keinen Pfad, dem ein Crawler folgen kann.
• Übersetzungen nur als Query-Parameter. Sprachversionen unter einem Parameter statt in einem Verzeichnis sind fragiler, besonders wenn Parameter in Caching-, CDN- oder Robots-Regeln abgeschnitten werden.
• Nicht übersetzte Slugs. Eine englische Seite unter einem deutschen Pfadsegment ist kein Fehler im technischen Sinn, kostet aber Relevanz und verwirrt beim Linkaufbau. Übersetzte Slugs setzen bei Polylang die Pro-Version voraus.
• Rückfall auf die Startseite. Fehlt eine Übersetzung und leitet das Plugin auf die Startseite der Zielsprache weiter, entsteht ein Soft-404-Muster über viele URLs. Sauberer ist, den Sprachumschalter nur für tatsächlich vorhandene Übersetzungen anzuzeigen.
• Sitemap nur in der Standardsprache. Wenn die generierte XML-Sitemap die übersetzten URLs nicht enthält, dauert das Auffinden entsprechend lang, besonders bei tief liegenden Seiten.
• Mitgeschleppte Staging-Einstellung. Wurde eine Sprachversion aus einer Testumgebung übernommen, kommt die Suchmaschinen-Sperre gelegentlich mit und bleibt unbemerkt, weil niemand die neue Sprache in der Search Console prüft.
• Unlektorierte Maschinenübersetzung. Ungeprüfte Ausgaben liefern in allen Sprachen denselben dünnen Text und erzeugen zusätzlich Fehler bei Fachbegriffen, die im Logistik- und Maschinenbaukontext teuer werden.

Geprüft wird das vor der Abnahme, nicht Monate danach. Zum Prüfumfang gehören ein Crawl mit hreflang-Auswertung über alle Sprachverzeichnisse, ein Abruf mit curl und der Option -I ohne gesetztes Cookie, um Weiterleitungen und Statuscodes zu sehen, ein zweiter Abruf mit curl und der Option -A, der einen Crawler-User-Agent vortäuscht und damit die automatische Sprachweiterleitung entlarvt, die URL-Prüfung in der Search Console je Sprachversion und ein Abgleich der indexierten URL-Anzahl pro Sprachverzeichnis. Diese Prüfungen stehen als Abnahmekriterien im Pflichtenheft, damit Mehrsprachigkeit ein überprüfbares Lieferergebnis ist und keine Absichtserklärung.

#Häufige Fragen aus Dortmund

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? 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 Unternehmenswebsite liegt oft bei wenigen Wochen, ein Shop mit deutscher Zahlungs- und Rechtsabwicklung deutlich darüber, ein mehrsprachiges Konzern-Projekt mit ERP-Anbindung 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.

#WordPress in weiteren Städten

Mittelständler im Rhein-Ruhr-Gebiet mit Niederrhein-Niederlassungen nutzen oft dieselbe WordPress-Architektur wie unsere WordPress-Entwicklung in Düsseldorf.

Im Ruhrgebiet arbeiten viele Organisationen mit Filialnetzen über Essen und Bochum hinweg - vergleichbar mit unserer WordPress-Entwicklung in Essen und WordPress-Entwicklung in Bochum.

OWL-Niederlassungen nutzen oft dieselbe Architektur wie unsere WordPress-Entwicklung in Bielefeld und WordPress-Entwicklung in Münster.

Logistikunternehmen mit Standorten in Niedersachsen vergleichen Portal-Architekturen häufig mit unserer WordPress-Entwicklung in Hannover.

Hidden Champions im Bergischen Land mit Standorten zwischen Düsseldorf und dem Ruhrgebiet vergleichen Portal-Architekturen häufig mit unserer WordPress-Entwicklung in Wuppertal.

#Nächster Schritt

Bereit, Ihr WordPress-Vorhaben in Dortmund 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 am Phönix-See, Migration auf moderne Block-Architektur für einen Mittelständler in Hörde oder laufende Betreuung einer Karriereseite mit Sitz im Wissenschaftspark: Der erste Schritt ist immer dieselbe ehrliche Bestandsaufnahme.