Ein Systemwechsel ist der Punkt, an dem eine Website am meisten verlieren kann: Inhalte, Sichtbarkeit oder beides. Beides ist vermeidbar, aber nicht durch Technik, sondern durch Vorbereitung.
Was tatsächlich Arbeit macht
Nicht das, was man erwartet. Die Inhalte selbst sind meist das kleinere Problem.
| Aufgabe | Aufwand | Risiko bei Auslassung |
|---|---|---|
| Inhalte übertragen | mittel | Verlust einzelner Texte |
| Design neu bauen | hoch | keines, nur Kosten |
| Adressen festlegen | gering | hoch |
| Weiterleitungsplan | mittel | sehr hoch |
| Funktionen ersetzen | variabel | Prozess bricht |
| Formulare neu einrichten | gering | Anfragen kommen nicht an |
| Rechtstexte anpassen | gering | rechtliches Risiko |
| Barrierefreiheit prüfen | mittel | rechtliches Risiko |
| Alte Version sichern | gering | Verlust nicht rekonstruierbar |
Die Zeilen mit hohem Risiko sind die mit geringem Aufwand. Das ist die eigentliche Erkenntnis: Was schiefgeht, ist selten das Aufwendige.
Vorbereitung: die Bestandsaufnahme
1. Vollständige Adressliste. Aus Sitemap, aus einem Crawler und aus den Serverlogs. Die Logs sind wichtig, weil sie Adressen enthalten, die in keiner Sitemap stehen und trotzdem aufgerufen werden.
2. Die Seiten mit Besuchern. Aus der Search Console die Adressen mit Impressionen und Klicks der letzten zwölf Monate. Diese Liste ist die Prioritätenliste.
3. Externe Verweise. Welche Adressen werden von außen verlinkt? Jede braucht ein Ziel, unabhängig von ihren Besucherzahlen.
4. Inhalte sichern. Texte, Bilder, Dokumente vollständig als Dateien. Auch das, was im neuen Konzept nicht vorgesehen ist.
5. Funktionen auflisten. Jedes Formular, jede Buchungslogik, jeder Mitgliederbereich, jede Schnittstelle. Für jede die Frage: Was ersetzt sie im neuen System?
6. Referenzwerte messen. Ladezeit, Suchanfragen, Besucherzahlen. Ohne Vorher-Wert lässt sich nach dem Umschalten nichts beurteilen.
Inhalte übertragen: je nach Quelle
Aus WordPress oder einem anderen CMS: Es gibt einen Export. Bei einem Wechsel auf ein anderes CMS oft mit Import-Werkzeug, bei einem Wechsel auf einen statischen Build mit Umwandlung in Markdown. Bilder und Dokumente liegen in einem Verzeichnis und lassen sich vollständig mitnehmen.
Aus einem Baukasten: Meist kein Gesamtexport. Der Weg ist manuell: jede Seite öffnen, Text kopieren, Bilder herunterladen. Bei dreißig Seiten sind das mehrere Arbeitstage. Wenn Originalbilder fehlen, weil nur die vom Baukasten verkleinerten Versionen vorliegen, ist das ein zusätzliches Problem.
Aus einer nicht mehr erreichbaren Seite: Das Internet Archive ist die Quelle. Es liefert Struktur und Texte, aber unvollständig und ohne Originalbilder. Als Grundlage brauchbar, als vollständige Quelle nicht.
Der Weiterleitungsplan
Eine Tabelle: alte Adresse, neue Adresse, Status. Das ist der wichtigste Teil der Migration.
Regeln:
- Jede alte Adresse zeigt auf das inhaltlich nächstliegende Ziel, nicht pauschal auf die Startseite
- Dauerhafte Weiterleitung mit Statuscode 301, nicht temporär
- Keine Ketten. Alt zeigt direkt auf neu
- Groß- und Kleinschreibung, Schrägstrich am Ende und Parameter mitabdecken
- Entfallene Inhalte bekommen das thematisch passende Ziel
- Dauerhaft bestehen lassen. Weiterleitungen sind keine Übergangsmaßnahme
Die Zahl der Zeilen ist kein Zeichen schlechter Planung. Eine gewachsene Seite mit 200 Adressen braucht 200 Zeilen.
Adressen: so viel wie möglich behalten
Jede beibehaltene Adresse ist eine, die nicht weitergeleitet werden muss und bei der kein Signal verloren geht. Adressen zu ändern, weil die neue Struktur logischer wäre, ist der häufigste selbst verursachte Schaden bei einer Migration.
Wenn Adressen sich ändern müssen, etwa weil das neue System eine andere Struktur erzwingt, dann einmal richtig: eine Struktur, die die nächsten fünf Jahre trägt. Siehe Seitenstruktur und URLs.
Ablauf
- Testumgebung, vollständig für Suchmaschinen gesperrt, am besten zusätzlich passwortgeschützt
- Struktur bauen, dann Inhalte übertragen, dann gestalten
- Adressen einfrieren. Ab hier ändert sich keine mehr
- Weiterleitungen anlegen und einzeln prüfen
- Funktionen einrichten und testen, insbesondere Formulare mit echtem Versand
- Rechtstexte auf die neuen Dienste anpassen
- Barrierefreiheit prüfen, vor dem Umschalten
- Ladezeit gegen den Referenzwert prüfen
- Umschalten, nicht am Freitagnachmittag
- Sperre entfernen. Der häufigste teure Einzelfehler ist eine mitgenommene Indexierungssperre
- Sitemap einreichen, alte ersetzen
- Vier Wochen beobachten
Die vollständige Prüfliste steht in Launch-Checkliste, die Nachbeobachtung in Relaunch planen.
Die Lehre für neue Projekte
Drei Gewohnheiten machen jeden späteren Wechsel um ein Vielfaches billiger, kosten nichts und werden fast nie eingehalten:
- Domain im eigenen Konto registrieren, nie über den Dienstleister oder den Baukasten
- Texte parallel in einem Dokument führen, außerhalb des Systems
- Originalbilder in einem eigenen Ordner behalten, unverkleinert
Damit wird ein Systemwechsel von einem Datenverlust zu einer Fleißarbeit.