Optistream hat zwölf maßgeschneiderte WordPress-Plugins in einer einzigen Codebasis zusammengeführt, ohne dabei das SEO für eine seiner tausend öffentlichen Seiten zu beeinträchtigen.

Warum die Zusammenführung entscheidend war

Eine typische WordPress-Seite endet oft mit einer Handvoll Plugins; eine größere gleicht einer Werkstatt voller Kabel, von denen jedes summt, aber keines einfach auszustecken ist. Die Website von Optistream nutzte zwölf maßgeschneiderte Plugins, die Streamer-Profile, Esports-Teams und Spieldaten verwalteten. Diese Plugins generierten tausend indexierbare Seiten. Die URLs intakt zu halten, war nicht verhandelbar – jede Änderung hätte die Migration gefährdet.

Wie das alte Setup aussah

Die zwölf Plugins befanden sich jeweils in einem eigenen Ordner, registrierten ihren eigenen Custom Post Type und hängten sich an unterschiedlichen Stellen in WordPress ein. Die Probleme häuften sich:

  • Hooks und Assets waren verstreut, was es schwierig machte, vorherzusagen, welcher Code wann ausgeführt wurde.
  • Die Routing-Logik war in vielen separaten Dateien verteilt, sodass eine einzige URL von mehreren Plugins beeinflusst werden konnte.
  • CSS-Dateien wurden in unvorhersehbarer Reihenfolge geladen, was zu Style-Konflikten führte.
  • Das Debugging erforderte das Öffnen von zwölf verschiedenen Verzeichnissen – ein enormer Zeitfresser für jeden Entwickler.

Das Ziel war nicht, die Anzahl der Dateien zu reduzieren, sondern dem gesamten System einen einheitlichen Lebenszyklus und einen zentralen Ort für das Dependency-Management zu geben.

Wie die Migration geplant wurde

Das Team betrachtete die öffentliche Schnittstelle – URLs, Templates und Metadaten – als einen Vertrag, der nicht gebrochen werden durfte. Alles, was sich im Frontend ändern würde, wäre ein Fehlschlag gewesen. Mit dieser Regel im Hinterkopf entwarfen sie eine Checkliste, die nach jedem Schritt abgearbeitet werden musste.

1. Die öffentlichen Verträge auflisten

Jeder URL-Pfad wurde zusammen mit seinem Post Type, dem Rewrite-Slug, der Template-Datei und den darauf angewiesenen Meta-Keys dokumentiert. Diese Tabelle wurde zum Regelwerk: Wenn sich eine URL nach dem Verschieben eines Moduls änderte, wurde die Migration rückgängig gemacht.

2. Einen einfachen Loader bauen

Es wurde eine winzige Bootstrap-Datei erstellt. Jedes ehemalige Plugin registriert nun eine einzelne „Content Domain“ über einen vorhersehbaren Funktionsnamen. Der Loader macht nichts Komplexes – er reicht gerade aus, um das richtige Modul bei Bedarf in WordPress zu laden. Einfachheit macht Fehler offensichtlich.

3. Die Daten schützen

Das Umbenennen von Meta-Keys hätte eine Code-Änderung in eine Datenmigration verwandelt und unnötiges Risiko hinzugefügt. Die alten Keys blieben unberührt; neue Helper-Funktionen kapseln sie ein und halten das Datenbank-Schema stabil.

4. CSS-Verantwortlichkeiten klären

Styling-Konflikte wurden durch drei Maßnahmen gelöst:

  • Modul-CSS-Dateien werden mit hoher Priorität enqueued, damit sie zuletzt geladen werden.
  • Alle Selektoren sind auf eine eindeutige Wrapper-Klasse für jedes Modul beschränkt (scoped).
  • filemtime() wird beim Enqueuing verwendet, um den Browser-Cache zu umgehen (cache busting), falls sich ein Stylesheet ändert.

5. Eine sichere Schleife verwenden

Die Migration erfolgte Modul für Modul. Nachdem ein Modul verschoben worden war, überprüfte das Team die Post-Type-Registrierung, das Routing und das mobile Layout, bevor das nächste Modul angefasst wurde. Die ursprünglichen Plugins blieben installiert, aber inaktiv, was einen sofortigen Rollback ermöglichte.

Produktions-Checkliste

Nach jedem Modul-Austausch überprüfte das Team:

  • Jede URL des Content-Typs liefert einen 200 HTTP-Status zurück.
  • Der Canonical-URL-Header stimmt mit der ursprünglichen URL überein.
  • Seitentitel und Meta-Beschreibungen sind unverändert.
  • Alle Bilder werden ohne defekte Links geladen.
  • Es tritt kein horizontaler Überlauf auf mobilen Bildschirmen auf.
  • Die Browser-Konsole zeigt null JavaScript- oder CSS-Fehler an.

Erst wenn die Checkliste vollständig abgearbeitet war, deaktivierte das Team das alte Plugin dauerhaft.

Was das neue Plugin liefert

Das resultierende Einzel-Plugin verkleinert die Codebasis nicht; es macht lediglich die Grenzen sichtbar. Alle zwölf Funktionsbereiche teilen sich nun einen Lebenszyklus, einen Satz Hooks und einen zentralen Ort für das Dependency-Management. Das neue Plugin hat das System nicht kleiner gemacht. Es hat die Grenzen sichtbar gemacht. Das erwies sich als nützlicher, als einfach nur weniger Plugins zu haben.

Risiken und Gegenargumente

Der Fall Optistream zeigt, dass ein disziplinierter „Contract-First“-Ansatz und ein schrittweiser Rollout die Risiken unter Kontrolle halten können.

Worauf man als Nächstes achten sollte

Wenn Sie eine ähnliche Konsolidierung in Erwägung ziehen, beginnen Sie mit diesen zwei Säulen:

  1. URL-Stabilität – Erstellen Sie eine Map für jeden öffentlichen Pfad, bevor Sie die erste Zeile Code schreiben.
  2. Datenstabilität – Vermeiden Sie das Umbenennen von Datenbankfeldern, es sei denn, Sie sind auf eine vollständige Migration vorbereitet.

Bauen Sie von dort aus einen winzigen Loader, halten Sie das CSS „scoped“ und verschieben Sie die Module eines nach dem anderen, während Sie eine strikte Produktions-Checkliste abarbeiten.