Von WordPress zu Hugo

Der Wendepunkt

Einen Website-Relaunch hatten wir nicht geplant. Es passierte, wie Geschichten über technische Schulden meistens laufen: Irgendwann merkst du, dass du mehr Zeit damit verbringst, die Infrastruktur am Laufen zu halten, als am eigentlichen Produkt zu arbeiten.

Unsere WordPress-Installation hatte über Jahre Plugins angesammelt – Sicherheitsscanner, Caching-Layer, SEO-Tools, Formular-Builder, Page-Builder – jeder davon eine Abhängigkeit, die aktualisiert und getestet werden musste und beim Update gelegentlich etwas anderes kaputt machte. Jeder Montagmorgen begann mit einer kleinen Anspannung: Was hat WordPress über Nacht automatisch aktualisiert, und hat es dabei etwas zerschossen?

Das war nicht nur ein Gefühl. Im letzten Jahr hatten wir wiederholt Ausfälle: ein veraltetes Plugin, das nicht mehr gepflegt wurde und mit einem PHP-Versions-Update in Konflikt geriet, eine Theme-Inkompatibilität, die das Kontaktformular für einen Tag ausser Betrieb nahm bevor wir es merkten, ein Caching-Plugin, das nach einem Content-Update veraltete Seiten auslieferte – und das erfuhren wir erst durch einen Kunden. Nichts davon war katastrophal. Aber jeder Vorfall kostete Zeit, die wir nicht hatten, und jeder war eine Erinnerung daran, dass wir Engineering-Kapazität damit verbrauchten, die Lichter brennen zu halten statt irgendetwas zu bauen.

Den letzten Anstoss gaben mehrere Dinge, die gleichzeitig zusammenkamen: Wir brauchten ein Redesign, wollten eine zweisprachige Website (Deutsch und Englisch mit sauberen URL-Strukturen), und wir dachten ernsthaft darüber nach, was es bedeutet, Souveränität im eigenen technischen Stack zu leben. Eine PHP-Anwendung mit einer MySQL-Datenbank bei einem Drittanbieter zu betreiben, mit einem halben Dutzend US-SaaS-Integrationen direkt im Seitenquelltext, passte zunehmend nicht mehr zu dem, was wir unseren Kunden erzählen.

Also haben wir das gemacht, was man eigentlich nie tun soll – wir haben von Grund auf neu gebaut.

Warum Hugo

Wir haben keinen breiten Marktvergleich gemacht. Wir wussten, dass wir einen Static Site Generator wollten, und haben uns schnell auf zwei Kandidaten eingeschränkt: Zola und Hugo.

Zola war der naheliegende erste Blick, weil wir es bereits für unser Developer Portal einsetzen – die technische Dokumentation und die API-Sandbox-Umgebung. Zola ist in Rust geschrieben, kommt als einzelne Binary und hat eine übersichtliche Template-Engine. Für das Developer Portal passt es gut, und wir behalten es dort: Die technische Komplexität der API-Sandbox-Integrationen macht einen Wechsel nicht lohnenswert.

Für die Marketing-Website haben wir uns aber letztlich für Hugo entschieden. Die ausschlaggebenden Faktoren waren das grössere Ökosystem an bestehenden Shortcode-Mustern zum Abschauen, der bessere Multilingual-Support out of the box und eine breitere Basis an Community-Beispielen für die komponentenreichen Marketing-Seiten, die wir bauen mussten. Beide sind ausgezeichnete Tools – die Wahl fiel auf das, was für diesen spezifischen Anwendungsfall besser passte, nicht auf eine grundlegende Schwäche von Zola.

Hugo ist ein Static Site Generator, geschrieben in Go. Du fütterst ihn mit Markdown-Dateien und Go-Templates, er gibt HTML aus. Keine Datenbank, keine PHP-Runtime, kein Plugin-Ökosystem zu verwalten. Die gesamte Website wird in Sekunden gebaut. Das Ergebnis ist ein Ordner mit statischen Dateien, den du überall ausliefern kannst.

Für eine Marketing- und Dokumentations-Website – was exolynk.com ist – ist das kein Kompromiss. Es ist eine bessere Architektur. Es gibt schlicht nichts anzugreifen, nichts zu patchen, nichts zu skalieren.

Die konkreten Gründe, die uns zu Hugo gebracht haben:

Performance ohne Aufwand. Statisches HTML, das von einem CDN-Edge ausgeliefert wird, ist per Default schnell. Keine Query-Optimierung, kein Caching-Plugin zu konfigurieren, keine PHP Cold Starts. Unsere Lighthouse-Scores haben sich drastisch verbessert, ohne dass wir etwas Besonderes getan hätten.

Git als CMS. Jeder Content-Schnipsel, jedes Template, jede Konfigurationseinstellung lebt in einem Git-Repository. Branches, Reviews und Rollbacks funktionieren genauso wie bei unserem Anwendungscode. Es gibt keine “Datenbank-Sync”-Prozeduren mehr zwischen Umgebungen.

Mehrsprachigkeit richtig gemacht. Hugo unterstützt mehrsprachige Websites nativ. Deutscher Content liegt unter /de/, mit sauberen URLs wie /de/blog/ und /de/plattform/. Hreflang-Tags, Sprachumschaltung und sprachspezifische Navigation sind alle nativ integriert – kein Plugin, kein Workaround.

Keine laufende Security-Angriffsfläche. Bei WordPress erhielten wir täglich Benachrichtigungen über Dependency-Updates. Bei Hugo ist der Build-Output statisches HTML. Es gibt nichts zu aktualisieren auf der Server-Seite, und nichts, was durch den Web-Application-Layer ausgenutzt werden könnte.

Was wir gebaut haben

Die neue Website ist ein von Grund auf selbst gebautes Hugo-Theme – aber nicht in Isolation. Es ist Teil eines grösseren Design-System-Projekts, das parallel an drei Projekten gleichzeitig lief.

Ein Design System, zwei Produkte. Während wir die Website neu gebaut haben, haben wir gleichzeitig die Exolynk-Plattform-UI neu gestaltet. Anstatt diese als separate Projekte mit separaten Stylesheets zu behandeln, haben wir früh eine bewusste Entscheidung getroffen: ein gemeinsames Corporate Design entwickeln und das SCSS zentralisieren, sodass sowohl Plattform als auch Website aus derselben Quelle schöpfen. Jede künftige Brand-Änderung – Typografie, Farben, Spacing-Tokens – wird einmal geändert und propagiert sich automatisch auf beide. Das war nur möglich, weil wir das Website- und Plattform-Redesign gleichzeitig durchgeführt haben, was zusätzlichen Koordinationsaufwand bedeutete, aber im Nachhinein deutlich schwerer zu ergänzen gewesen wäre.

Die visuelle Identität dahinter wurde gemeinsam mit Silja von grafik100.ch entwickelt, die das neue Corporate Design leitete. Das Rebranding umfasste alles – Logo, Farbsystem, Typografie, Icon-Stil – und musste gleichzeitig für die Marketing-Website, die Anwendungs-UI und gedruckte Materialien funktionieren.

Birei: von Rust/Leptos-Komponenten zu einer Hugo-Library. Das UI-Komponentensystem, das wir für dieses Projekt entwickelt haben, heisst Birei. Es wurde ursprünglich als Set von Rust Leptos -Komponenten für die Exolynk-Plattform gebaut – interaktiv, typisiert, kompiliert. Für die Hugo-Website konnten wir diese Komponenten nicht direkt verwenden. Wir haben die Design-Sprache und Interaktionsmuster in eine parallele Implementierung portiert: HTML-Templates, Vanilla JavaScript und den gemeinsamen SCSS-Layer. Das Ergebnis ist eine Komponentenbibliothek, die auf beiden Oberflächen konsistent aussieht und sich gleich verhält, obwohl die zugrundeliegende Technologie vollständig unterschiedlich ist. Buttons, Formular-Inputs, Cards, Navigationselemente – dieselbe visuelle Komponente, zwei Laufzeitumgebungen.

Wir haben mit einem minimalen Go-basierten Hugo-Starter als Gerüst begonnen und dann das Birei-Theme darüber aufgebaut. Nichts vom Starter hat es unverändert in die Produktion geschafft; es war ein Ausgangspunkt für die Projektstruktur, kein Theme zum Anpassen.

Ein paar weitere Dinge, über die wir besonders froh sind:

Eine Komponentenbibliothek in Shortcodes. Hugo Shortcodes sind wiederverwendbare Content-Komponenten, die man direkt in Markdown einbetten kann. Wir haben eine ganze Library davon gebaut: Hero-Sections, Feature Cards, Vergleichstabellen, Testimonial-Slider, YouTube-Einbettungen mit datenschutzfreundlichem Lazy Loading, Timeline-Komponenten, animierte Tipp-Effekte. Eine neue Seiten-Section hinzufügen bedeutet einen Shortcode-Aufruf schreiben – kein Template bearbeiten, kein Kampf mit einem Page Builder.

Consent-bewusste Analytics. Wir haben Google Analytics durch eine selbst gehostete Umami -Instanz auf EU-Infrastruktur ersetzt. Umami ist Open-Source, cookie-frei und speichert keine personenbezogenen Daten. Wir lassen Google Analytics vorübergehend parallel laufen – um die Konsistenz der Traffic-Daten nach der Migration zu validieren – aber es wird entfernt, sobald wir sicher sind, dass die Zahlen vergleichbar sind. Ab dann bleiben alle Analytics-Daten auf unserer eigenen Infrastruktur.

Ein datenschutzkonformer Cookie-Consent-Flow. Schweizer Besucher (erkannt über die Zeitzone) sehen die Website sofort ohne Consent-Banner, im Einklang mit dem Schweizer DSG. Nicht-Schweizer Besucher sehen einen Consent-Banner, bevor Tracking geladen wird. Die Implementierung läuft vollständig in Vanilla JavaScript ohne Drittanbieter-Consent-Library.

Kontaktformular ohne externe Dienste. Unser Kontaktformular sendet an einen PHP-Handler auf demselben Server, der Mails über unseren eigenen SMTP verschickt. Kein Formspree, kein HubSpot-Formular, keine Daten, die durch einen US-SaaS-Layer geleitet werden. Spam-Schutz wird durch ein Honeypot-Feld und eine Timing-Heuristik gehandhabt – kein CAPTCHA erforderlich.

Cal.com Buchungs-Integration. Der “Meeting buchen”-Button auf der ganzen Website öffnet ein Modal, das Cal.com in einem iFrame lädt – aber erst, wenn der Besucher tatsächlich klickt, nicht bei jedem Seitenaufruf.

Mehrsprachige Website-Suche ohne Such-Dienst. Wir haben eine Volltextsuche auf Basis von Pagefind integriert – eine Open-Source-Library, die während des npm run build-Schritts das gebaute HTML crawlt und einen binären Such-Index erzeugt. Das Ergebnis ist ein Cmd+K-Suchmodal, das offline funktioniert, sowohl englischen als auch deutschen Content abdeckt und weder ein Algolia-Konto, noch einen Elasticsearch-Cluster, noch Drittanbieter-JavaScript auf der Seite benötigt. Der gesamte Index wird neben den statischen Dateien auf demselben Server ausgeliefert.

Live-Plattformstatus im Footer. Ein kleiner farbiger Indikator im Footer zeigt den aktuellen Betriebsstatus der Exolynk-Plattform, live abgerufen von unserer Uptime Kuma -Monitoring-Instanz. Kein Seitenneuladen erforderlich – er aktualisiert sich nach dem Laden via nicht-blockierendem requestIdleCallback-Fetch. Anerkennung, wo sie hingehört: Wir haben dieses Muster auf der Website von Nine Internet Solutions AG entdeckt, die ebenfalls kürzlich von WordPress zu Hugo migriert sind und ihre Erfahrungen grosszügig mit uns geteilt haben. Ihr Beitrag ist sehr lesenswert, wenn du einen ähnlichen Schritt planst – und ihre SEO-Erfahrungen nach der Migration haben uns nützliche Orientierung gegeben, was zu erwarten ist.

Die Zahlen

Einige konkrete Daten aus dem fertigen Build:

Die Performance-Werte stammen aus einem WebPageTest-Vergleich am selben Tag, am selben Teststandort.

Der Total Load Time-Balken (9,4 s vs. 1,3 s) macht das Diagramm etwas schief – aber darum geht es ja.

Der Vollständigkeit halber: Hier sind die PageSpeed Insights-Werte im Vergleich – separat vom WebPageTest-Lauf gemessen:

WordPress (vorher)

Hugo (nachher)

Ein Hinweis zur Build-Zeit: 24 Sekunden sind länger als das “baut in Millisekunden”, das man in den meisten Hugo-Tutorials liest. Unser Build führt sha512-Integrity-Fingerprinting über alle Assets durch, verarbeitet Bilder und generiert 215 Redirect-Stub-Seiten zusätzlich zum eigentlichen Content. Für einen Produktions-Build, den man einmal vor dem Deployment ausführt, ist das in Ordnung. Der lokale Dev-Server mit inkrementellen Rebuilds ist für Content-Änderungen weiterhin nahezu sofort fertig.

Die 215 Redirect-Aliase sind der konkret sichtbare Preis der Redirect-Archäologie. Jede alte WordPress-URL bekommt eine Weiterleitung zu ihrem neuen Äquivalent, die Hugo als kleinen HTML-Stub am alten Pfad generiert. Kein Plugin nötig, keine URL-für-URL-.htaccess-Akrobatik – nur eine Zeile im Frontmatter.

KI-gestützte Entwicklung

Wir möchten ehrlich sein: Dieses Rewrite passierte in einem komprimierten Zeitrahmen, zum Teil weil wir Claude Code während des gesamten Projekts eingesetzt haben.

Das verdient eine differenzierte Betrachtung. KI-unterstützte Entwicklung für ein Projekt wie dieses ist wirklich nützlich – und in spezifischen Bereichen wirklich begrenzt.

Wo es uns wesentlich beschleunigt hat:

• Aufbau und Iteration von Go-Templates, die eine ungewöhnliche Syntax haben und von sofortigem Feedback profitieren
• Schreiben und Debuggen der mehrsprachigen Konfiguration, Hreflang-Setup und Redirect-Regeln für die alten WordPress-URLs
• Implementierung der JavaScript-lastigen Komponenten (Consent-Banner, Modal, Lazy Loading) ohne stundenlange Browser-Kompatibilitätsprobleme
• Erkennung von TOML-Konfigurations-Scoping-Bugs (Hugos Config-Datei hat strenge Regeln zur Key-Reihenfolge relativ zu Section-Headern – subtile Bugs, die leicht zu übersehen und nervig zu debuggen sind)

Wo menschliches Urteilsvermögen alles war:

• Entscheiden, welchen Content wir behalten, überarbeiten oder komplett streichen
• Architektonische Entscheidungen zur Komponentenstruktur treffen
• Den eigentlichen Marketing-Text schreiben – KI-Entwürfe brauchen erhebliche Überarbeitung, damit sie nach einer spezifischen Unternehmenssprache klingen
• Erkennen, wenn eine von der KI vorgeschlagene “Lösung” technisch clever, aber der falsche Ansatz für die Gesamtarchitektur war

Der Workflow, der am besten funktionierte: Claude Code für die Implementierungsschicht nutzen, bei Entscheidungen zu Struktur und Content fest am Steuer bleiben. Wenn wir die KI beides treiben liessen, wurde es inkonsistent.

Die unschönen Dinge, die niemand erwähnt

Jeder “wir sind zu Hugo migriert”-Post klingt, als wäre alles sauber gelaufen. Unserer war es nicht.

Redirect-Archäologie. Unsere alte WordPress-Website hatte Jahre von URL-Strukturänderungen, Post-Umbenennungen und Plugin-generierten Pfaden angesammelt. Die 301-Redirect-Liste für die .htaccess aufzubauen war wirklich mühsam – URLs aus der Google Search Console ziehen, mit dem WordPress-Export abgleichen, Sonderfälle manuell prüfen.

Das FTP-Deploy-Problem. Unser Hosting läuft auf einem CloudLinux-Setup, bei dem das FTP-Chroot System-Verzeichnisse (/lib, /lib64) als Symlinks im FTP-Root exponiert. Als wir einen Asset-Ordner namens lib/ deployt haben, konnte der FTP-Client ihn lautlos nicht schreiben – der System-Symlink blockierte es. Die Assets sind schlicht nicht auf dem Server gelandet. Das zu diagnostizieren hat länger gedauert, als wir zugeben möchten. Die Lösung war, das Verzeichnis in vendor/ umzubenennen und die System-Verzeichnisse zur Deploy-Ausschlussliste hinzuzufügen.

SMTP-Debugging durch Nginx-Timeouts. Das Einrichten des SMTP-Relays für das Kontaktformular über Google Workspace hat eine Kaskade von Problemen ausgelöst: falsche Port/Verschlüsselungs-Kombinationen, PHPs standardmässiger 300-Sekunden-SMTP-Timeout, der von Nginxs 60-Sekunden-Upstream-Timeout abgebrochen wurde bevor ein Fehler zurückgegeben wurde, ein App-Passwort mit wörtlichen Leerzeichen, die verbatim an Googles AUTH-LOGIN-Endpunkt gesendet wurden. Jedes davon war einzeln diagnostizierbar; sie in Folge zu entdecken, während ein 502 Bad Gateway die einzige Fehlermeldung war, war weniger spassig.

SEO während der Migration. Das war das, was uns nachts beschäftigt hat. Eine Live-Website zwischen Plattformen zu verschieben, trägt immer ein Ranking-Risiko – besonders bei URL-Strukturänderungen im mehrsprachigen Content. Was wir gemacht haben: alle Redirects vor dem Go-Live aufsetzen, die neue Sitemap sofort bei der Google Search Console einreichen und die Suchperformance in den ersten Wochen genau beobachten. Die kurze Antwort: keine nennenswerten Einbrüche. Wenn überhaupt, haben die Performance-Verbesserungen einen positiven Effekt auf Core Web Vitals-Signale gehabt.

Was wir anders machen würden

Früher mit der Redirect-Liste beginnen. Wir haben unterschätzt, wie viel Zeit eine ordentliche Redirect-Archäologie beansprucht. Das sollte eine der ersten Aufgaben sein, nicht eine der letzten.

Die Deploy-Pipeline vorher auf einer Staging-Domain testen. Das FTP-Chroot-Problem wäre früher aufgefallen, wenn wir einen vollständigen Deploy-Probelauf auf einer Test-Subdomain gemacht hätten. Wir hatten Staging für den Content, aber nicht für die vollständige Deploy-Toolchain.

Dem zweisprachigen Content mehr Zeit geben. Zwei Sprachversionen jeder Seite parallel zu pflegen bedeutet ungefähr doppelte Content-Arbeit. Wir sind mit einigen DE-Seiten live gegangen, die dünner waren als die EN-Entsprechungen. Das ist in Ordnung – es ist besser als zu verzögern – aber von Anfang an mehr Zeit für den deutschen Content einzuplanen, hätte den Launch sauberer gemacht.

Die Migration als Repositionierungsmoment

Eine Sache haben wir nicht erwartet: Der Neuaufbau der Website hat uns gezwungen, Entscheidungen zur Content-Architektur zu treffen, die wir aufgeschoben hatten.

Die alte WordPress-Website wurde gebaut, als Exolynk sich breiter als Full-Service-Digitalisierungspartner positionierte. Im Laufe der Zeit zeigte das Produkt und das Markt-Feedback klar in eine andere Richtung: Der Kern dessen, was wir tun, ist eine Low-Code-Plattform für vernetzte, souveräne Geschäftsdaten. Das ist es, was Kunden kaufen, und das ist es, was wir klar kommunizieren müssen.

Eine Migration ist ein natürlicher Forcing Function für diese Art von Überdenken. Wenn du Content Datei für Datei verschiebst statt auf “alles exportieren” zu klicken, triffst du explizite Entscheidungen über jede Seite: behalten, überarbeiten oder streichen. Wir haben behalten, was zur neuen Positionierung passte, überarbeitet was aktualisiert werden musste, und Content gestrichen der entweder veraltet war oder die Botschaft verwässerte.

Das Ergebnis ist eine Website, die nicht nur schneller und günstiger zu betreiben ist – sie ist fokussierter. Die Navigation ist um Plattform-Funktionen und Use Cases aufgebaut statt um Service-Kategorien. Der Blog behandelt Themen, die für unser tatsächliches Publikum relevant sind. Und die Sprache ist klarer, weil wir sie von Grund auf neu schreiben mussten statt etwas Vorhandenes zu bearbeiten.

Wenn du eine Migration machst: Nutze sie. Portiere nicht einfach deinen alten Content. Behandle es als den redaktionellen Audit, den du schon lange machen wolltest.

Fazit

Das neue exolynk.com ist schneller, günstiger zu betreiben, einfacher zu pflegen und besser ausgerichtet auf das, was wir als Unternehmen vertreten. Die WordPress-Version benötigte laufende Aufmerksamkeit, nur um funktional zu bleiben. Die Hugo-Version benötigt Aufmerksamkeit nur, wenn wir etwas ändern wollen.

Für ein Team, das Software baut, ist die Fähigkeit, die Website wie ein Software-Projekt zu behandeln – mit Branches, Reviews und Deployments – keine kleine Verbesserung der Lebensqualität. Es ist eine andere Art zu arbeiten.

Wenn du eine WordPress-Website für ein B2B-Produkt betreibst und merkst, dass du mehr Zeit mit Plugin-Hygiene verbringst als mit Content, lohnt sich der Migrationsaufwand. Die Reibung ist frontal geladen und real. Die Wartungsruhe auf der anderen Seite ist es auch.

Was kommt als Nächstes: Die Website war nur der erste Schritt. Unser Developer Portal – die technische Dokumentation und die API-Sandbox-Umgebung – läuft derzeit auf Zola und steht als Nächstes zur Überarbeitung an. Wir werden separat darüber schreiben, wenn es fertig ist. Stay tuned.

Fragen zur Migration, unserem Hugo-Setup oder wie wir spezifische technische Herausforderungen gelöst haben? Meld dich bei uns – wir teilen gerne, was funktioniert hat.