Relaunch nach Bauplan: 95 Änderungen im ersten Lauf, keine einzige im zweiten

Wenn das Befüllen über den Termin entscheidet

Bei einem Relaunch entscheidet selten die Technik über den Termin. Das Design steht, die Vorlagen sind gebaut – und dann beginnt der Teil, den niemand gern plant: Dutzende Seiten anlegen, Texte aus Dokumenten übertragen, jede Seite in der zweiten Sprache noch einmal, Seitentitel und Beschreibungen für Suchmaschinen eintragen. Das ist Fleißarbeit, und Fleißarbeit hat eine unangenehme Eigenschaft: Am Ende weiß niemand sicher, ob wirklich alles drin ist.

Wir begleiten derzeit zwei Relaunches auf TYPO3 – für ein Hotel und für einen Dienstleister. Beide Websites sind noch nicht live, beide entstehen auf einer Vorschau-Adresse neben der bestehenden Seite. In beiden Projekten pflegen wir Seitenbaum und Inhalte nicht von Hand ein. Wir beschreiben sie als Bauplan, den ein Werkzeug einspielt – und der sich gegen die Unterlagen des Kunden prüfen lässt. Dieser Beitrag zeigt am Beispiel des Hotels, wie das funktioniert, was es bringt und wo es an Grenzen stößt.

Die Herausforderung

Der Kunde hatte über den Sommer außerordentlich gründlich vorgearbeitet. Was bei uns ankam, war vollständig – aber verteilt auf mehrere Dokumente in unterschiedlicher Form:

• Die Struktur aus einer Tabelle. Seitenname und Ebene in einer Spalte, Hinweise für die Umsetzung in einer zweiten, dazu je Seite der Verweis auf eine bestehende Seite, an der sich der Aufbau orientieren soll.
• Die deutschen Texte aus einem PDF, gestaltet und mit Seitenzahlen.
• Die englischen Texte aus einer zweiten Tabelle – ein Tabellenblatt je Seite.
• 57 Zeilen Seitentitel und Beschreibungen für Suchmaschinen, in Deutsch und Englisch. Die Bezeichnungen dieser Zeilen lauteten anders als die Seitennamen in der Strukturtabelle.
• Bestehende Adressen sollten bleiben. Wo eine neue Seite ein Gegenstück auf der heutigen Website hat, soll sie deren Adresse übernehmen, damit keine Weiterleitungsketten entstehen und keine Platzierungen bei Google verloren gehen.
• Der Kunde arbeitet mit. Die Redaktion pflegt im selben System bereits Bilder ein, während wir noch Seiten befüllen.

Von Hand ist das machbar. Aber jede spätere Korrekturrunde – eine verschobene Seite, ein geänderter Text, ein nachgeliefertes Bild – wäre dann wieder Handarbeit, und jede Handarbeit eine neue Gelegenheit, etwas zu übersehen.

Unsere Lösung

1. Der Seitenbaum als Bauplan

Statt Seiten im Redaktionssystem anzuklicken, haben wir die Unterlagen des Kunden in eine Beschreibung überführt, die in der Versionsverwaltung liegt: jede Seite mit Titel in beiden Sprachen, Adresse, Seitentitel und Beschreibung für Suchmaschinen, Position im Baum und dem Verweis auf ihre Referenzseite. Ein Werkzeug liest diese Beschreibung und legt die Seiten an – über dieselbe Schnittstelle, die auch das Redaktionssystem selbst benutzt, nicht mit direkten Eingriffen in die Datenbank.

Drei Eigenschaften machen daraus mehr als ein Importskript:

• Jede Seite hat einen festen Schlüssel. Das Werkzeug erkennt eine Seite beim nächsten Lauf wieder, statt sie doppelt anzulegen, und schreibt nur die Felder, die tatsächlich abweichen. Ändert sich im Bauplan die übergeordnete Seite, wird die Seite verschoben – ihre Adresse bleibt dabei unverändert.
• Zuordnungen stehen ausdrücklich im Bauplan. Welche Zeile der Suchmaschinen-Tabelle zu welcher Seite gehört, wird nicht zur Laufzeit erraten, sondern einmal festgelegt und ist nachlesbar.
• Der Bauplan lässt sich gegen die Quellen prüfen. Ein eigener Prüfbefehl vergleicht ihn mit den beiden Tabellen des Kunden: Keine Zeile bleibt unzugeordnet, alle Texte stimmen überein.

Diese Prüfung findet auch, was in den Unterlagen fehlt. Für vier Seiten – darunter die AGB und die Datenschutzerklärung – enthielt die Tabelle keine Angaben für Suchmaschinen. Die Felder blieben leer und standen auf einer Liste für den Kunden, statt mit einem ausgedachten Text gefüllt zu werden. Dasselbe gilt für Widersprüche zwischen zwei Dokumenten: Eine Zimmerkategorie hieß in der englischen Seitenübersicht anders als im englischen Seitentitel. Wir haben beides so übernommen, wie es geliefert wurde, und die Frage gestellt, welche Bezeichnung gelten soll.

Zwei Tage nach Eingang der Unterlagen stand der vollständige Seitenbaum in der Vorschau: 65 Seiten, jede in Deutsch und Englisch, mit Hauptnavigation und Fußbereich. Die alten Adressen sind erhalten, wo es ein Gegenstück gibt, und es wurde keine einzige Weiterleitung erzeugt.

2. Jede Seite nach einem Vorbild

Für die Inhalte gilt dasselbe Prinzip, nur eine Ebene tiefer: Je Seite gibt es eine Beschreibung ihrer Bausteine. Die Regeln dafür sind bewusst streng.

• Kein Layout wird erfunden. Jede Seite entsteht nach dem Vorbild der Referenzseite, die der Kunde in seiner Strukturtabelle genannt hat – gleiche Bausteine, gleiche Reihenfolge, neue Texte.
• Texte werden wörtlich übernommen. Deutsch aus dem PDF, Englisch aus dem Tabellenblatt der jeweiligen Seite.
• Nichts wird maschinell übersetzt. Fehlt in einem Tabellenblatt ein Text, steht er auf einer offenen Liste und nicht im Inhalt.
• Bilder sind zunächst Platzhalter und werden getauscht, sobald das Bildmaterial vorliegt.

In der Qualitätssicherung wird jede Seite gegen die Quelle gelesen: Überschrift für Überschrift, Zelle für Zelle. Weil der Inhalt als Beschreibung vorliegt, lässt sich dieser Vergleich vor dem Einspielen führen – am Text selbst und nicht an einer fertig geklickten Seite.

3. Der zweite Lauf als Beweis

Der entscheidende Schritt kommt nach dem Einspielen: Das Werkzeug läuft ein zweites Mal. Es vergleicht den Bauplan erneut mit dem, was im System steht, und meldet jede Abweichung. Findet es keine, ist der Stand vollständig.

Die 95 Änderungen der Seitengruppe – eine Übersichtsseite mit drei Unterseiten, jeweils in zwei Sprachen – setzten sich aus 79 neu angelegten und 16 aktualisierten Einträgen zusammen. Vor jedem echten Lauf steht ein Probelauf, der dieselbe Liste zeigt, ohne etwas zu schreiben. Stimmen Probelauf und echter Lauf nicht überein oder meldet der zweite Lauf noch Änderungen, wird angehalten und nachgesehen, nicht nachgebessert.

Meldet der zweite Lauf nichts mehr, ist der Stand vollständig – ohne dass jemand Seite für Seite nachzählen muss.

Dieselbe Eigenschaft macht spätere Korrekturen ungefährlich. Ändert der Kunde einen Text oder soll eine Seite an eine andere Stelle im Baum, wird der Bauplan angepasst und erneut eingespielt. Der Probelauf zeigt dann genau diese eine Änderung – und nichts sonst.

4. Prüfen, bevor geschrieben wird

Ein Werkzeug, das Inhalte schreibt, muss sich selbst überprüfen lassen. Zwei Stellen sind uns bei der Durchsicht aufgefallen, beide bevor sie Folgen hatten.

Inhalt, den niemand sehen würde. Im zweiten Relaunch, der nach demselben Muster entsteht, gibt es Ordner, die keine Seiten sind: einer liefert die Einträge eines Menüs, ein anderer dient als Ablage für Beiträge. Eine Vorprüfung meldet, wenn eine Inhaltsbeschreibung auf einen solchen Ordner zeigt – die Bausteine würden angelegt und nirgends angezeigt. Eine Ausnahme braucht es für den Ordner, dessen Inhalt im Fußbereich erscheint. Beim Gegenlesen stellte sich heraus, dass diese Ausnahme zu großzügig formuliert war und auch die anderen Ordner durchgelassen hätte. Betroffen war nichts, die Prüfung wurde trotzdem auf den einen Ordner eingeengt, der tatsächlich angezeigt wird.

Ein Probelauf, der doch etwas anlegte. Der Probelauf verspricht, nichts zu schreiben. In einem Sonderfall hielt er das nicht: War in einem Text eine Datei verlinkt, die zwar auf dem Server lag, dem System aber noch nicht bekannt war, wurde sie beim Nachschlagen im Dateiverzeichnis des Systems eingetragen – auch im Probelauf. Für die betroffenen Seiten spielte das keine Rolle, weil alle verlinkten Dateien bereits bekannt waren. Wir haben es eigens nachgezogen: Der Probelauf kündigt den Eintrag jetzt nur noch an, der echte Lauf nimmt ihn vor, und beide melden dieselbe Zahl an Änderungen.

5. Was der Kunde selbst gesetzt hat, bleibt

Die heikelste Frage an ein solches Werkzeug lautet: Was passiert, wenn die Redaktion im selben System weiterarbeitet? Ein Bauplan, der bei jedem Lauf alles auf seinen Stand zurücksetzt, wäre für den Kunden eine Zumutung.

Der erste Fall kam schneller als erwartet. Vor einem Lauf meldete der Probelauf sieben Änderungen, die mit der anstehenden Seite nichts zu tun hatten: Der Kunde hatte auf sieben Seiten im Redaktionssystem selbst eine Kategorie gesetzt, und das Werkzeug hätte sie auf den Wert aus dem Bauplan zurückgestellt. Der Lauf wurde ausgelassen, das Werkzeug angepasst. Danach zeigte der Probelauf genau eine Änderung – die erwartete.

Der zweite Fall betraf Bilder. Der Kunde lieferte die Bilder der Startseite und schrieb dazu, einen Teil davon habe er bereits selbst eingesetzt: acht Bilder, mit eigenen Bildausschnitten für Desktop und Smartphone. Für das Werkzeug gilt seither eine einfache Regel: Zeigt ein Bildplatz ein Bild der Redaktion, gehört er der Redaktion – mit Bild, Ausschnitt, Titel und Link.

Auch hier hat die Qualitätssicherung die erste Fassung zurückgegeben. Benannte der Kunde eines seiner Bilder um, warnte das Werkzeug fälschlich vor einem fehlenden Bild; entfernte er ein Bild aus einer Bildfolge, hätte der nächste Lauf es wieder angelegt. Beides ist behoben: Ein entferntes Bild bleibt entfernt, ein hinzugefügtes bleibt stehen.

• 6 neue Bilder aus der Lieferung eingesetzt
• 12 Änderungen im Lauf, je Bild eine pro Sprache
• 16 Bildplätze des Kunden unverändert

Die 16 Einträge des Kunden haben wir vor und nach dem Lauf Zeile für Zeile verglichen. Sie waren identisch, einschließlich der Bildausschnitte.

Eine Ausnahme bleibt: Leert die Redaktion einen solchen Baustein vollständig, sieht er für das Werkzeug aus wie neu und wird beim nächsten Lauf wieder befüllt. Wer ihn nicht mehr zeigen möchte, blendet ihn aus, statt ihn zu leeren.

Das Ergebnis

• Der Seitenbaum stand zwei Tage nach Eingang der Unterlagen in der Vorschau – 65 Seiten in zwei Sprachen, mit Seitentiteln und Beschreibungen für Suchmaschinen.
• Vollständigkeit ist belegt, nicht behauptet: Der zweite Lauf meldet keine Änderungen, und der Bauplan stimmt nachprüfbar mit den Dokumenten des Kunden überein.
• Lücken und Widersprüche in den Unterlagen werden sichtbar und landen als Frage beim Kunden statt als Vermutung im Text.
• Bestehende Adressen bleiben erhalten, ohne eine einzige Weiterleitung.
• Korrekturrunden sind keine Fehlerquelle mehr: Bauplan ändern, Probelauf ansehen, einspielen.
• Die Arbeit der Redaktion bleibt unberührt – eigene Bilder und Bildausschnitte werden nicht überschrieben.

Der Bauplan hat auch Grenzen. Er ersetzt weder die Abnahme durch den Kunden noch den Blick auf die fertige Seite. Dass ein Bild auf dem Tablet zu hoch gerät oder ein Text neben einem Bild nicht mittig steht, erkennt kein Abgleich von Texten; solche Punkte haben wir am Bildschirm gefunden, auf Desktop, Tablet und Smartphone. Und einmalige Arbeit bleibt es: Die Unterlagen müssen zunächst in den Bauplan überführt werden. Das lohnt sich bei vielen gleichartigen Seiten, mehreren Sprachen und absehbaren Korrekturrunden – bei einer Handvoll Seiten ist Handarbeit schneller.

Fazit

Planbar wird ein Relaunch nicht dadurch, dass das Befüllen schneller geht, sondern dadurch, dass sein Stand jederzeit überprüfbar ist. Liegen Struktur und Inhalte als Bauplan vor, lassen sie sich mit den Unterlagen des Kunden vergleichen, wiederholt einspielen und nach jeder Korrektur erneut bestätigen. Abnahme und der Blick aufs Smartphone bleiben nötig – sie finden dann aber auf einem Stand statt, auf den sich beide Seiten verlassen können.