WordPress Entwickler in Hamburg

#Websites, die den Warenumschlag tragen: WordPress für Hafen, Handel und Medien

Hamburg lebt vom Umschlag. Container laufen über die Terminals in Waltershof, Kaffeekontore sitzen seit Generationen in der Speicherstadt, Speditionen disponieren entlang der A7, und zwischen Außenalster und Schanzenviertel produziert eine der dichtesten Medienlandschaften Europas Inhalte im Minutentakt. Beide Welten, Handel wie Medien, stellen an eine Website dieselbe nüchterne Frage: Trägt sie den laufenden Geschäftsbetrieb, oder ist sie Dekoration?

Für ein Importhaus mit vierstelligen Artikelzahlen und wechselnden Lieferzeiten ist die Website ein Arbeitsgerät. Einkäufer rufen abends Bestände ab, Disponenten prüfen Lieferfenster, skandinavische Abnehmer erwarten ihre Konditionen in eigener Währung. Ein gekauftes Marktplatz-Theme mit einem Dutzend zusammengewürfelter Plugins hält diese Dauerlast selten durch. Es wird langsam, es bricht bei Updates, und niemand kann im Fehlerfall sagen, welche der vielen Schichten gerade klemmt.

Erfahrene PHP-Entwickler sind an der Elbe knapp. Wer den Beruf beherrscht, sitzt häufig fest angestellt bei einem Verlag, einem E-Commerce-Konzern oder einer der großen Digitalagenturen. Kleinere Handelshäuser und Mittelständler bekommen davon wenig ab und behelfen sich mit Baukastenlösungen, deren Folgekosten erst im Betrieb sichtbar werden.

Genau diese Lücke füllen wir, als externes Senior-Entwicklungsteam auf B2B-Basis. Der Code liegt in Git, Abnahmen laufen über eine Testumgebung, jede Änderung ist dokumentiert und nachvollziehbar. Für Workshops, Prozessaufnahmen oder Schulungen kommen wir in die HafenCity, nach Altona oder dorthin, wo Ihr Team sitzt. Den Rest erledigen wir remote, asynchron und schriftlich, so wie es zu verteilten Teams zwischen Kontor und Terminal passt.

Vier Kundengruppen prägen die Hamburger Anfragen, die uns erreichen: Handelshäuser und Importeure mit B2B-Katalogen, Logistiker und maritime Dienstleister mit Portal- und Registerbedarf, Verlage und Content-Plattformen mit Reichweiten- und Abo-Modellen sowie Marken, die aus Hamburg heraus direkt nach Nordeuropa verkaufen.

#Reedereien, Makler, Zulieferer: Register und RFQ-Portale für die maritime Wirtschaft

Kaum eine Branche hat so strukturierte Daten wie die Schifffahrt, und kaum eine zeigt sie so selten ordentlich im Web. Für Reedereien, Schiffsmakler und maritime Zulieferer bauen wir Fachportale auf WordPress-Basis, die diese Daten nutzbar machen:

• Schiffs- und Ausrüstungsregister als Custom Post Types: IMO-Nummer, Baujahr, DWT, TEU, Tiefgang und Klassestatus als filterbare Felder statt als PDF-Friedhof.
• Datenblätter, die sich Interessenten selbst ziehen: automatisch generierte PDF-Exporte pro Schiff oder Komponente, immer auf dem Stand der Datenbank.
• RFQ-Strecken für Befrachtung, Reparatur und Bunkerdienste: mehrsprachige Anfrageformulare, deren Eingaben direkt im CRM des Vertriebsteams landen.
• Geschützte Bereiche für Crews und Inspektoren: rollenbasierte Zugriffe auf Zertifikate und Dokumente, mit verschlüsseltem Download und Ablaufdaten.

Solche Portale sind kein Marketing, sondern Infrastruktur. Entsprechend behandeln wir sie: mit Versionskontrolle, Testdaten und einem Wiederanlaufplan für den Fall der Fälle.

#Verkaufen nach Skandinavien: Shops für Norwegen, Schweden und Dänemark

Kein deutscher Standort liegt näher an den nordischen Märkten, und viele Hamburger Händler machen dort längst einen relevanten Teil ihres Umsatzes. Ein Shop, der Skandinavien ernst nimmt, braucht mehr als eine englische Übersetzung:

• Echte Sprachversionen für Norwegisch, Schwedisch und Dänisch mit eigenen URLs, hreflang-Auszeichnung und redaktionell gepflegten Texten statt maschinell befüllter Platzhalter.
• Preisdarstellung in NOK, SEK und DKK, inklusive der Sonderfälle: Norwegen ist kein EU-Mitglied, also gehören VOEC-Logik und korrekte Steuerausweisung in den Checkout und nicht in eine Fußnote.
• Zahlarten, die im Norden selbstverständlich sind: Vipps, Swish und MobilePay neben Karte und Rechnungskauf, angebunden über zertifizierte Gateways.
• Versandwege über Bring, PostNord und DHL mit Sendungsverfolgung im Kundenkonto und realistischen Lieferzeitangaben pro Zielland.

Die Reibungspunkte liegen erfahrungsgemäß nicht dort, wo sie im Angebot stehen. Fremdwährungspreise runden sich in der Anzeige anders als in der Rechnung, sobald Umrechnungskurse täglich nachgezogen werden. Retouren über die Grenze brauchen ein eigenes Etikett und einen eigenen Buchungsweg, sonst landet die Ware im Lager, ohne dass die Gutschrift ausgelöst wird. Und Zahlungsanbieter verhalten sich in der Sandbox regelmäßig anders als im Livebetrieb, weshalb wir jede Zahlart vor dem Launch mit echten Kleinstbeträgen durchspielen.

Dazu kommt der Teil, den Übersetzungswerkzeuge nicht abdecken: Produktnamen, Maßeinheiten und Lieferzusagen müssen im Nordmarkt genauso klingen, wie ein dortiger Einkäufer sie erwartet. Wir legen die Textfelder deshalb so an, dass eine muttersprachliche Redaktion sie ohne Entwicklerhilfe überschreiben kann, und trennen im Datenmodell sauber zwischen übersetzbaren Inhalten und Stammdaten, die für alle Märkte identisch bleiben.

#Großhandel im Login-Bereich: WooCommerce mit kaufmännischer Preislogik

Der Hamburger Großhandel verhandelt Konditionen individuell, und der Shop muss das abbilden können. Unsere B2B-Ausbauten für WooCommerce folgen der Logik des Kontors, nicht der eines Consumer-Shops. Nach der Anmeldung sieht jeder Abnehmer seine verhandelten Preise, seine Mengenstaffeln und sein Zahlungsziel. Gebinde, Paletten und Mindestabnahmen sind als Regeln hinterlegt, damit keine Bestellung durchrutscht, die logistisch keinen Sinn ergibt.

Dazu kommen die Werkzeuge, die Wiederbesteller wirklich nutzen: Schnellerfassung per Artikelnummer, CSV-Upload ganzer Bestelllisten, Bestellhistorie mit Nachbestellung in einem Schritt. Preise und technische Unterlagen bleiben hinter dem Login, damit weder Wettbewerber noch Preisportale mitlesen.

Wichtig ist dabei die Datenhaltung im Hintergrund. Kundengruppen, Preislisten und Rabattregeln gehören in eigene Tabellen und nicht in verstreute Meta-Felder, sonst wird jede Katalogseite zur Datenbanklast. Wir berechnen kundenindividuelle Preise vorab und legen sie im Object Cache ab, sodass auch ein Katalog mit mehreren tausend Positionen im Login-Bereich genauso schnell erscheint wie die öffentliche Übersicht.

#Anbindung an Speditionen und Versanddienstleister statt manueller Zettelwirtschaft

Zwischen Shop und Rampe liegt in vielen Häusern noch Handarbeit. Etiketten werden einzeln erzeugt, Sendungsnummern per Mail verteilt, Bestände in zwei Systemen parallel gepflegt. Wir ersetzen diese Handgriffe durch Schnittstellen zu DHL Geschäftskunden, DPD, UPS und Speditionspartnern: Labels entstehen beim Statuswechsel der Bestellung, Trackinglinks wandern automatisch ins Kundenkonto, Bestände gleichen sich mit der Warenwirtschaft ab.

Der unspektakuläre, aber entscheidende Teil ist die Fehlerbehandlung. Alle Schnittstellen laufen über Warteschlangen, damit ein kurzzeitig nicht erreichbares Fremdsystem keine Bestellung verliert. Fehlgeschlagene Aufrufe werden mit wachsendem Abstand wiederholt und nach mehreren Versuchen als Aufgabe im Backoffice sichtbar, statt still im Log zu verschwinden. Jede Übergabe bekommt eine eindeutige Kennung, sodass eine Sendung sich vom Auftrag bis zur Zustellung zurückverfolgen lässt. Belege für die Finanzbuchhaltung übergeben wir als strukturierten Export, ohne daraus ein eigenes Integrationsprojekt zu machen.

#Redaktionelle Workflows für Verlage und Medienhäuser

Wer in Hamburg Inhalte produziert, arbeitet gegen die Uhr. Ein Redaktionssystem muss deshalb weniger können und dafür verlässlicher: klare Rollen zwischen Volontariat, Ressortleitung und Schlussredaktion, ein Freigabeschritt vor der Veröffentlichung, geplante Erscheinungszeitpunkte und ein Sperrfrist-Status, der nicht durch einen unglücklichen Klick fällt.

Wir bilden das mit eigenen Beitragsstatus und Fähigkeiten im WordPress-Rollenmodell ab, statt jedem Redakteur Administratorrechte zu geben. Ergänzend richten wir ein:

• Bildredaktion mit Pflichtfeldern für Quelle, Credit und Alternativtext, damit Rechteangaben nicht am Erscheinungstag nachrecherchiert werden.
• Korrektur- und Transparenzhinweise als eigener Block, der Änderungen an veröffentlichten Artikeln sichtbar dokumentiert.
• Strukturierte Daten für Artikel, Autorenprofile und Live-Berichterstattung, damit Suchsysteme Urheberschaft und Aktualisierungszeitpunkt korrekt lesen.
• Eine Volltextsuche über das gesamte Archiv, die auch nach Ressort, Autor und Zeitraum filtert, ohne die Datenbank in die Knie zu zwingen.

Bei Archivmigrationen aus älteren Systemen ist der aufwendigste Teil selten der Text, sondern die Ordnung dahinter: Kategoriebäume, Autorenzuordnungen, alte URLs. Wir migrieren mit Prüfläufen auf einer Kopie, vergleichen Datensatzzahlen vor und nach dem Import und legen für jede geänderte Adresse eine Weiterleitung an, bevor die neue Version live geht.

#Paywall, Newsletter, Reichweite: Headless WordPress für hohe Frequenz

Verlage und Content-Plattformen haben andere Engpässe als Händler: hohe Artikelfrequenz, Lastspitzen bei Aufregerthemen und ein Abo-Funnel, der keine Sekunde Ladezeit verzeiht. Für diese Fälle trennen wir Redaktion und Auslieferung. Die Redaktion arbeitet weiter im gewohnten Block-Editor, ausgeliefert wird ein vorgerendertes Frontend auf Astro- oder Next.js-Basis über ein Edge-Netzwerk.

Der Effekt ist doppelt. Seiten kommen auch unter Last in konstant kurzer Zeit beim Leser an, und das Redaktionssystem selbst ist vom öffentlichen Netz entkoppelt, sodass Angriffe auf Login-Endpunkte ins Leere laufen. Paywall-Logik, Newsletter-Anmeldungen und Kampagnen-Landingpages docken über definierte API-Endpunkte an, statt als Plugin-Wildwuchs im Kernsystem zu wuchern.

Headless ist dabei kein Selbstzweck. Für eine Redaktion mit wenigen Beiträgen pro Woche ist ein gut gecachtes klassisches Theme die günstigere und wartungsärmere Wahl, und das sagen wir auch. Der Aufwand lohnt sich, wenn Artikelfrequenz, Lastspitzen und ein eigenes Abo-Modell zusammenkommen.

#Barrierefreiheit nach BITV 2.0 und Barrierefreiheitsstärkungsgesetz

Hamburg hat viele publikumsnahe Angebote: Kultur- und Verkehrsbetriebe, Bäderland und Messeauftritte, dazu Abo-Strecken der Verlage und Verbraucher-Shops. Für öffentliche Stellen gilt die BITV 2.0, für Verbraucherangebote im elektronischen Geschäftsverkehr seit Sommer 2025 das Barrierefreiheitsstärkungsgesetz. Der gemeinsame technische Nenner ist die europäische Norm EN 301 549, die im Kern auf WCAG 2.1 Stufe AA verweist.

Barrierefreiheit lässt sich nicht als Skript nachrüsten. Overlay-Widgets, die per JavaScript Kontraste umfärben und Vorlesefunktionen anbieten, ändern nichts daran, dass ein Bestellformular ohne Feldbeschriftung für einen Screenreader stumm bleibt. Wir setzen deshalb am Markup an:

• Überschriftenhierarchie und Landmarken kommen aus den Block-Vorlagen, sodass eine korrekte Struktur der Normalfall ist und nicht das Ergebnis von Disziplin.
• Jedes Formularfeld hat eine sichtbare Beschriftung, Fehlermeldungen stehen am Feld und werden für Screenreader angekündigt, nicht nur rot eingefärbt.
• Die gesamte Bestellstrecke ist ohne Maus bedienbar, mit sichtbarem Fokus, sinnvoller Reihenfolge und einem Sprunglink zum Hauptinhalt.
• Kontraste prüfen wir auf den echten Hintergründen, auch über Bildern und in dunklen Varianten, statt nur die Farbwerte der Designvorlage zu vergleichen.
• Videos bekommen Untertitel, Tabellen bekommen Kopfzellen, und dekorative Grafiken bleiben leer ausgezeichnet, damit sie nicht vorgelesen werden.

Geprüft wird in drei Durchgängen: automatisiert im Build gegen die üblichen Regelsätze, danach ein Durchlauf allein mit der Tastatur und zuletzt ein Test mit Screenreader auf den kritischen Strecken. Für öffentliche Stellen erstellen wir zusätzlich die Erklärung zur Barrierefreiheit samt uwagi-Mechanismus. Das Ziel formulieren wir im Projektplan verbindlich: keine offenen Verstöße gegen WCAG 2.1 AA auf Startseite, Kategorie, Detailseite, Formular und Checkout.

#Ein Theme, das nur Ihre Marke kennt

Marktplatz-Themes wollen jedem gefallen und schleppen deshalb Ballast für alle mit: Slider-Bibliotheken, Icon-Fonts, Layout-Optionen, die nie jemand aktiviert. Wir gehen den umgekehrten Weg und bauen pro Projekt ein eigenes Block-Theme auf Basis des Full Site Editing mit zentraler theme.json. Geladen wird nur, was die Seite tatsächlich rendert.

Für die Redaktion entstehen Synced Patterns: markenkonforme Bausteine für Landingpages, Produktreihen oder Fachbeiträge, aus denen neue Seiten in Minuten zusammengesetzt sind, ohne dass jemand CSS anfassen muss. Auf jQuery und ähnliche Altlasten verzichten wir, modernes CSS und schlanke ES-Module reichen aus und altern deutlich besser.

#Core Web Vitals im Shop, gemessen an echten Nutzern

Google bewertet Seiten nach dem, was echte Nutzer erleben, festgehalten im Chrome User Experience Report. Laborwerte aus einem Test-Tool sind dafür nur ein Näherungswert. Im E-Commerce sitzen die Probleme fast immer an denselben drei Stellen.

Der größte Inhalt einer Kategorieseite ist meist das erste Produktbild, das erst nach dem Ausliefern des Stylesheets angefordert wird. Wir geben ihm eine feste Größe, laden es mit hoher Priorität und verzichten für den sichtbaren Bereich auf verzögertes Laden. Die Reaktionszeit auf Eingaben leidet an Filterleisten und Warenkorb-Fragmenten, die bei jedem Klick den Server befragen. Wir beantworten Filter serverseitig aus vorbereiteten Abfragen und schalten Warenkorb-Aktualisierungen ab, wo sie nichts anzeigen. Und Layoutsprünge entstehen durch nachgeladene Banner, Bewertungssterne und Einwilligungsdialoge, für die kein Platz reserviert wurde.

Dazu kommt die Infrastruktur: serverseitiges Caching, Redis als Object Cache für datenbanklastige Filterseiten, Bilder in AVIF und eine Auslieferung über ein Edge-Netzwerk, von der auch Besucher aus Oslo oder Göteborg profitieren. Als Zielgrößen halten wir im Projektplan fest: Hauptinhalt der Kategorieseite unter einer Sekunde sichtbar, Reaktion auf Eingaben im Checkout unter 200 Millisekunden, Layoutverschiebung unter 0,1. Gemessen wird nach dem Launch weiter, mit echten Nutzerdaten statt einer einmaligen Momentaufnahme.

#Ein typisches Projekt aus dem Hamburger Handel

Damit Sie einschätzen können, wie so etwas konkret aussieht, hier ein typisches Projektprofil, wie es uns in Hamburg regelmäßig begegnet: ein Importeur mit mehreren tausend Artikeln, gewachsenem Shop auf einem Multi-Purpose-Theme, händisch gepflegten Preislisten für Stammkunden und wachsendem Skandinavien-Geschäft.

Der Fahrplan dafür beginnt mit einer technischen Aufnahme, inklusive Messung der realen Ladezeiten und einer Sicherheitsdurchsicht. Dann folgen ein neues, schlankes Block-Theme und ein B2B-Login mit kundenindividuellen Konditionen. Anschließend kommen die nordischen Sprachversionen samt Währungen und Zahlarten, zuletzt die Versandanbindung.

Als Ziele vereinbaren wir dabei typischerweise: Hauptinhalt unter einer Sekunde sichtbar, Bestellstrecke vollständig per Tastatur bedienbar, kein manueller Etikettendruck mehr im Tagesgeschäft und Preispflege durch die Vertriebsabteilung ohne Entwicklerbeteiligung. Was davon in welchem Sprint kommt, steht im Projektplan, den Sie vor Beauftragung sehen.

#Redaktionsschulung an der Elbe

Nach dem Launch schulen wir Ihr Team an den eigenen Inhalten, per Video-Call oder vor Ort, mit schriftlichen Leitfäden und kurzen Tutorial-Videos. Ziel ist, dass Marketing und Redaktion neue Seiten aus den vorbereiteten Patterns selbst bauen und uns nur noch für echte Entwicklung brauchen. Zur Schulung gehört auch der Umgang mit Alternativtexten und Überschriften, weil Barrierefreiheit sonst mit dem ersten selbst gebauten Beitrag wieder verloren geht.

#Gefunden werden von Altona bis Harburg

Für Anbieter mit regionalem Einzugsgebiet zählt das Local Pack: strukturierte LocalBusiness-Daten mit konsistenten Namens- und Adressangaben, Landingpages für die relevanten Bezirke von Eimsbüttel über Wandsbek bis Bergedorf und mobile Ladezeiten, die auch unterwegs im Hamburger Netz kurz bleiben. Ergänzend markieren wir Leistungen und häufige Fragen mit Schema.org-Auszeichnung, damit auch KI-gestützte Suchsysteme die Inhalte sauber zuordnen und zitieren können.

#Betrieb, Hosting und Wartung nach dem Launch

Ein Shop, der Bestellungen trägt, braucht einen Betrieb, der nicht vom Zufall abhängt. Gehostet wird auf NVMe-Infrastruktur in deutschen Rechenzentren, mit täglichen verschlüsselten Sicherungen auf getrennten Systemen und einem Wiederherstellungsablauf, der einmal geprobt wurde und nicht nur im Handbuch steht. Updates von Kern, Plugins und Themes laufen zuerst auf der Testumgebung, mit automatisierten Prüfungen der wichtigsten Strecken, bevor sie produktiv gehen.

Beim Datenschutz halten wir es hanseatisch nüchtern: so wenig Datenerhebung wie möglich, Schriften und Skripte vom eigenen Server, Formulare fragen nur ab, was der Prozess braucht. Wer ohne Einwilligungsbanner auskommen will, bekommt eine cookie-freie Messung auf eigener Infrastruktur.

#Wann ein dedizierter Entwickler zu viel wäre

Nicht jedes Vorhaben rechtfertigt Individualentwicklung. Eine Kanzlei oder Praxis, die eine ruhige Website mit fünf Seiten braucht, fährt mit einem gut konfigurierten Standard-Theme und einem Wartungsvertrag besser, und wir sagen das im Erstgespräch.

Anders sieht es aus, sobald Systeme miteinander reden müssen, ein Login-Bereich individuelle Konditionen abbilden soll, Ladezeiten messbar Umsatz kosten, gesetzliche Anforderungen an Barrierefreiheit greifen oder ein über Jahre gewachsenes Konstrukt aus mehreren Agentur-Generationen saniert werden muss. Dann entscheidet Erfahrung darüber, ob ein Projekt Wochen oder Monate braucht.

#Communities im DACH-Raum

Öffentliche Community-Verzeichnisse und Meetup-Links. Wir betreiben keine eigenen Offline- oder Event-Landingpages - diese Listen verweisen auf bestehende DACH-Communities.

#WordPress-Communities und Verzeichnisse

Externe Community-Links (Meetup, WordCamp, Landesverbände). Keine eigenen Offline- oder Event-Landingpages von WPPoland.

• DACH Meetup-Verzeichnis (de.wordpress.org)
• WordPress Meetup Pro (global)
• WordCamp Central
• WP Switzerland
• WordPress Meetup Berlin
• WordPress Meetup München
• WordPress Meetup Hamburg
• WordPress Meetup Köln
• WordPress Meetup Leipzig
• WordPress Meetup Dortmund
• Düsseldorf WooCommerce Meetup

#TYPO3-Communities und Verzeichnisse

Offizielle TYPO3-Kalender, User Groups und Barcamps im DACH-Raum - ebenfalls nur Drittquellen.

• TYPO3 Events Calendar
• TUG Directory (User Groups)
• TYPO3camp München
• TYPO3camp RheinRuhr
• TYPO3camp Berlin
• TYPO3camp Mitteldeutschland
• TYPO3camp Stuttgart
• TUG München (T3MUC)
• TUG Berlin (T3B)

#Weitere Standorte im Norden

Über Hamburg hinaus betreuen wir Auftraggeber in ganz Norddeutschland und bundesweit:

• WordPress Entwickler Bremen
• WordPress Entwickler Hannover
• WordPress Entwickler Münster
• WordPress Entwickler Dortmund
• WordPress Entwickler Berlin
• WordPress Entwickler Köln

#So läuft die Zusammenarbeit ab

Verträge schließen wir auf B2B-Basis mit klaren Abnahmekriterien. Während des Projekts sehen Sie jeden Stand auf der Testumgebung, nach Abschluss gehören Ihnen Quellcode, Nutzungsrechte und Dokumentation vollständig. Wer danach nicht selbst warten will, bucht unseren Wartungsservice für Hamburg dazu.

Schreiben Sie uns mit ein paar Sätzen zum Vorhaben, zum bestehenden System und zum Zeitrahmen. Sie bekommen eine Einschätzung zur Machbarkeit, die offenen Fragen, die vorher geklärt sein müssen, und einen Vorschlag für die ersten beiden Meilensteine.