Der dritte Relaunch in vier Jahren, jedes Mal mit neuen Adressen, jedes Mal ohne Weiterleitungen. Was an Sichtbarkeit entstanden war, beginnt danach wieder bei null — und niemand im Team verbindet das eine mit dem anderen, weil zwischen Ursache und Wirkung sechs Wochen liegen.
In jungen Berliner Unternehmen ist das der Regelfall und nicht die Ausnahme. Die Website wird umgebaut, sobald sich Positionierung, Produkt oder Zielgruppe ändern, und das geschieht in den ersten Jahren häufig. Jeder dieser Umbauten ist inhaltlich begründet. Technisch hinterlässt er dieselbe Spur: Adressen, die es nicht mehr gibt, und eine Domain, die aus Sicht der Suchmaschine ihre Vergangenheit verloren hat.
Zwischen „veröffentlicht" und „auffindbar" liegen drei getrennte Vorgänge. Keiner meldet sich, wenn er ausbleibt, und in diesem Umfeld scheitern regelmäßig alle drei gleichzeitig.
Was ein Umbau kostet, wenn niemand die Adressen mitnimmt
Eine Adresse, die seit zwei Jahren existiert, aus mehreren Quellen verlinkt ist und regelmäßig besucht wird, ist ein Vermögenswert. Sie ohne Weiterleitung durch eine neue zu ersetzen, bedeutet, diesen Wert abzuschreiben — und zwar nicht teilweise, sondern vollständig.
Die Verzögerung ist das eigentliche Problem. Der Umbau geht an einem Donnerstag live, alles funktioniert, das Team feiert. Sechs Wochen später sinken die Zugriffe, und da niemand mehr an den Relaunch denkt, wird die Ursache im Markt gesucht, in der Saison oder im Wettbewerb. Eine Liste der alten Adressen mit ihren Zugriffszahlen, angelegt vor dem Umbau, verhindert diese Diskussion vollständig — und sie kostet eine halbe Stunde. Wer sie nicht hat, kann sechs Wochen später nicht einmal nachweisen, dass überhaupt etwas verloren ging, weil die Vergleichsgrundlage mit den alten Adressen verschwunden ist.
Was der Browser zeigt und ein Crawler nicht bekommt
Die zweite Ursache liegt in der Bauweise. Moderne Oberflächen setzen die Seite häufig erst im Browser zusammen: Das Grundgerüst kommt an, ein Skript lädt den Inhalt nach, die Navigation entsteht aus einer Konfigurationsdatei. Für einen Besucher ist das schnell und angenehm. Im ausgelieferten Quelltext kann trotzdem nichts weiter stehen als eine Überschrift und ein Ladehinweis.
Wo bei jungen Unternehmen die Adressen verschwinden
Vier Fälle, die in Berlin fast immer gemeinsam auftreten — und keiner davon ist ein Inhaltsproblem.
- Inhalt wird erst im Browser aufgebaut. Steht der Text nicht im ausgelieferten Quelltext, existiert er für die Auffindbarkeit nicht. Ob die Seite im Browser gut aussieht, spielt dabei keine Rolle.
- Vorschauumgebungen bleiben erreichbar. Jeder Entwicklungszweig erzeugt eine eigene Adresse, und in vielen Aufbauten sind diese öffentlich abrufbar. Eine vollständige Kopie der Website konkurriert dann mit dem Original.
- Der Blog liegt auf einer eigenen Subdomain. Aus Bequemlichkeit bei der Einrichtung gewählt, und dauerhaft getrennt von der Vergangenheit der Hauptdomain. Bei einer jungen Domain ist das eine teure Trennung.
- Relaunch ohne Weiterleitungen. Der wirksamste Einzelverlust. Alles, was an Verweisen und Vergangenheit entstanden war, hängt an den alten Adressen und bleibt dort.
Die zweite Zeile verdient besondere Aufmerksamkeit, weil sie unbemerkt bleibt. Eine öffentlich erreichbare Vorschauumgebung ist eine exakte Kopie der Website — und wo sie zufällig älter ist oder mehr Verweise trägt, kann sie diejenige sein, die aufgenommen wird. Auszuschließen ist sie mit einer Zeile in der Konfiguration, und zwar von derjenigen Person, die ohnehin die Auslieferung verantwortet. Wichtig ist dabei, die Einstellung in der Umgebungsdefinition zu setzen und nicht je Vorschau von Hand: Wer sie einmalig auf eine bestehende Umgebung anwendet, hat sie bei der nächsten neu angelegten wieder verloren, und genau diese nächste entsteht in einem wachsenden Team binnen Tagen.
Eine Adresse zu melden ist keine Aufnahme
Der Gewinn ist real und auf einen Punkt beschränkt: Die Adresse muss nicht mehr gefunden werden. Nach einem Umbau, bei dem hunderte neue Adressen gleichzeitig entstehen, ist das erheblich — vorausgesetzt, die Weiterleitungen stehen bereits, sonst meldet man Adressen an, deren Vorgänger niemand mitgenommen hat.
Nach einem geordneten Umbau
Weiterleitungen stehen, Inhalte werden ausgeliefert, neue Adressen sind bekannt zu machen.
- Verkürzt die Entdeckung um Tage bis Wochen
- Gilt auch für geänderte Bestandsseiten
Gegen fehlende Weiterleitungen
Wo die alte Adresse ins Leere läuft, ändert die Meldung der neuen nichts an dem, was verloren ging.
- Erst umleiten, dann melden
- Sonst wird Kontingent verbraucht
Der Indexing Hub und die Zahlen, die den Plan bestimmen
Zuständig dafür ist im Semalt-Arbeitsbereich der Indexing Hub: Adressen werden entgegengenommen, weitergegeben und ihr Verbleib aufgezeichnet, wobei erkennbar bleibt, wo etwas hängt. Seine Mengenbegrenzungen lassen sich nicht verhandeln und gehören deshalb in den Ablaufplan eines Umbaus, nicht in dessen Nachbetrachtung.
| Funktion | Wofür beim Umbau | Wo es endet |
|---|---|---|
| Einzeln melden und verfolgen | die Handvoll Seiten, an denen Anfragen hängen | Tagesgrenze von tausend je Konto |
| Als Paket übergeben | den Umbau, mit allem, was neu entstanden ist | höchstens zehntausend pro Durchgang |
| Kartensätze einreichen | was das System selbst erzeugt hat | Verschachtelung bis Ebene drei, tausend Dateien je Auftrag |
| Über IndexNow weiterreichen | geänderte Produktangaben, neue Preisseiten | informiert; verpflichtet niemanden |
Für ein Unternehmen mit achtzig Seiten ist keine dieser Grenzen je relevant. Relevant werden sie am Tag eines Umbaus, wenn mehrere hundert Adressen gleichzeitig neu entstehen und jemand sämtliche Bereiche zugleich einstellen möchte. Nach Bereichen gestaffelt kommt dieselbe Kapazität weiter, und die Protokolle bleiben lesbar — was zählt, sobald etwas schiefgeht.
Eine Zahl aus dieser Aufstellung verdient bei häufigen Umbauten besondere Beachtung: die Auflösungstiefe von drei Ebenen. Automatisch erzeugte Kartensätze verschachteln sich von selbst — eine Sammelkarte je Bereich, darunter je Sprachfassung, darunter die Dateien. Damit ist die Grenze erreicht, und was tiefer liegt, wird nicht mehr vollständig aufgelöst. Bemerkt wird das erst, wenn ein ganzer Bereich fehlt, während der Rest der Website normal funktioniert — und in einem Team, das ohnehin zwischen zwei Umbauten steht, wird diese Beobachtung leicht dem letzten Umbau zugeschrieben statt der Kartenstruktur. Die laufenden Zähler im Arbeitsbereich trennen die beiden Ursachen innerhalb einer Woche.
Das Protokoll ist der Teil, der die Arbeit spart
Adressen zu übergeben ist in zehn Minuten erledigt. Interessant wird es danach: Für jede einzelne wird festgehalten, zu welchem Zeitpunkt ein Bot erschien, mit welchem Ergebnis er zurückkam, und im Fehlerfall die konkrete Begründung. Parallel laufen drei Zählwerke — abgeschickt, aufgefunden, gescheitert.
| Befund im Protokoll | Bedeutung | Zuständigkeit |
|---|---|---|
| Tagelang kein Besuch | bekannt, aber ohne Verweis von einer besuchten Seite | Redaktion — zwei interne Verweise |
| Bot da, Fehler zurückgegeben | Kette von Weiterleitungen, Zeitüberschreitung oder eine Sperre | Entwicklung — Ticket mit dem konkreten Status |
| Bot da, Seite nicht behalten | inhaltlich zu dünn oder von einer anderen kaum zu unterscheiden | Produkt — die Angaben ergänzen, die nur intern vorliegen |
| Erst drin, dann draußen | Monate ohne Änderung, Zugriffe oder Verweise | Redaktion — jährliche Aktualisierung |
Die dritte Spalte ist in einem jungen Unternehmen der eigentliche Nutzen, weil dort selten jemand vollständig zuständig ist. Ein Befund ohne Adressat bleibt liegen. Ein Befund, der auf Redaktion, Entwicklung oder Produkt zeigt, wird in der nächsten Wochenplanung aufgenommen — und zwei der vier Zeilen erreichen die Entwicklung gar nicht.
Bemerkenswert ist, wie unterschiedlich die vier Zeilen im Aufwand liegen. Verlinken kostet zehn Minuten, ein Ticket an die Entwicklung einen halben Tag Wartezeit, eine inhaltliche Ergänzung eine Woche. Ohne Protokoll wählt man zwischen diesen drei Aufwänden nach Gefühl und trifft dabei etwa so oft das Richtige wie beim Münzwurf — was in einem Team mit knapper Kapazität teurer ist als in einem großen Haus, weil jede falsch gewählte Aufgabe eine richtige verdrängt.
Vier Fälle, die in Berlin regelmäßig auftreten
Der Relaunch ohne Umleitungen
Neue Adressstruktur, alte Adressen ersatzlos entfernt. Alles, was an Vergangenheit bestand, bleibt bei den alten.
- Seitengenau umleiten, nicht auf die Startseite
- Liste vor dem Umbau exportieren
Die offene Vorschauumgebung
Eine vollständige zweite Fassung der Website, erreichbar und gelegentlich mit eigener Kartendatei.
- Eine Zeile in der Konfiguration
- Vierteljährlich nachsehen, nicht einmalig
Der Blog auf eigener Subdomain
Aus Bequemlichkeit gewählt und dauerhaft von der Vergangenheit der Hauptdomain getrennt.
- Ein Unterverzeichnis erbt deutlich mehr
- Wechselseitige Verweise mildern es
Die dreimal umgeschriebene Startseite
Bei jeder Neupositionierung ersetzt, ohne dass eine der Fassungen lange genug bestand, um Wirkung zu entfalten.
- Unterseiten stabil halten
- Positionierung oben, Fachinhalt unten
Alle vier zeigen sich als Aufnahmeproblem und sind keines. Wiederholtes Melden hilft daher nicht. Welche Struktur überhaupt tragfähig ist, entscheidet sich vorher; welche Seite welchen beschreibenden Begriff führen soll, klärt die Keyword-Recherche, und welche Angaben je Kundengruppe fehlen, zeigt die Branchenübersicht.
Vier Zusagen, die vor dem Livegang schriftlich vorliegen
Alle vier kosten vor dem Umbau Minuten und danach Wochen.
- Jede alte Adresse bekommt einen benannten Nachfolger. Nicht „wir leiten um", sondern eine Zuordnungstabelle. Ohne sie entsteht am Umbautag die Sammelumleitung auf die Startseite, die technisch zählt und wirtschaftlich nichts rettet.
- Der Inhalt steht im ausgelieferten Quelltext. Eine Zusage, die im Framework eine Einstellung ist und im Nachhinein eine Umbaurunde. Sie gehört in dieselbe Absprache wie die Weiterleitungen.
- Vorschauumgebungen sind ausgeschlossen. In der Umgebungskonfiguration und nicht von Hand, damit jede künftig entstehende Vorschau die Einstellung erbt.
- Die Kartendatei entsteht im Auslieferungsprozess. Wird sie separat gepflegt, ist sie nach zwei Umbauten veraltet, und niemand bemerkt es über Monate.
Der Wert dieser vier Punkte liegt darin, dass sie an den Auslieferungsprozess gebunden sind und nicht an eine Person. Ein Ablauf, der davon abhängt, dass jemand nach dem Umbau an die Meldung denkt, hält genau so lange wie die Beschäftigung dieser Person — und scheitert danach stillschweigend, was die unangenehmste aller Fehlerarten ist.
Die Abfolge, die einen Umbau übersteht
- Vor dem Umbau exportieren. Sämtliche Adressen mit Zugriffen aus neunzig Tagen. Ohne diese Liste lässt sich hinterher nicht feststellen, was verloren ging — und die Diskussion darüber dauert länger als der Export.
- Seitengenau umleiten. Jede alte Adresse auf ihren inhaltlichen Nachfolger, nicht sämtliche auf die Startseite. Eine Sammelumleitung auf die Startseite ist technisch eine Umleitung und wirtschaftlich ein Totalverlust.
- Auslieferung prüfen. Eine Unterseite ohne Skript abrufen und im Quelltext nachsehen, ob Text und Navigationsverweise dort stehen.
- Vorschauumgebungen ausschließen. In der Umgebungskonfiguration, damit jede neu entstehende Vorschau die Einstellung erbt. Von Hand ausgeschlossen hält es bis zur nächsten Umgebung.
- Dann melden. Ein Vorgang über den Hub, Weitergabe aktiv, nach Bereichen gestaffelt.
- Nach zwei bis sieben Tagen das Protokoll lesen. Und je nach Befund verlinken, als Ticket weitergeben oder ergänzen — nicht nach Vermutung entscheiden.
Der erreichte Stand steht anschließend neben Zugriffen und Platzierungen im Semalt-Dashboard, sodass eine nicht aufgenommene Seite auffällt, bevor weitere Arbeit hineinfließt. Bei größeren Umbauten kommt die Kartenübergabe hinzu: Datei oder Adresse übergeben, verschachtelte Karten werden bis zu drei Ebenen aufgelöst, bis zu tausend Karten je Auftrag, zwei Aufträge gleichzeitig, zwanzig in der Warteschlange.
Ein Punkt, der in jungen Unternehmen für Diskussionen sorgt: Wer trägt diese vier Zusagen? Die Antwort lautet in aller Regel nicht Marketing, sondern derjenige, der den Auslieferungsprozess verantwortet — und das ist genau der Grund, warum sie so oft ausbleiben. Marketing kennt die Folgen und hat keinen Zugriff; die Entwicklung hat Zugriff und kennt die Folgen nicht. Diese Lücke schließt kein Werkzeug, sondern ein Satz in der Definition dessen, was ein fertiger Umbau überhaupt ist.
In der Praxis genügt eine Zeile in der Abnahmeliste: Umbau gilt als abgeschlossen, wenn die Zuordnungstabelle vorliegt, die Vorschauumgebungen ausgeschlossen sind und die Kartendatei aus dem Auslieferungsprozess stammt. Drei Bedingungen, die niemand bestreitet, sobald sie geschrieben sind, und die vorher jedes Mal aufs Neue vergessen werden. Wie sich der erreichte Stand danach überprüfen lässt, zeigen die SEO-Werkzeuge.
Der teuerste Weg, einen Umbau zu verlieren
An dieser einen Stelle entscheidet sich, ob die vorangegangene Arbeit überhaupt jemand zu sehen bekommt. Bleibt eine frisch verfasste Fachseite außen vor, ist ihr Beitrag null. Ein Verweis, der auf eine nicht aufgenommene Adresse zeigt, ist Aufwand ohne Gegenleistung — und bei einer jungen Domain, die ohnehin wenige Verweise hat, ist das besonders bitter.
Aus diesem Grund liegen Meldewerkzeug, Kampagnensteuerung und Auswertung nebeneinander. In My SEO stehen Begriffsauswahl, Verweisaufbau, Seitenempfehlungen und Aufnahmestand nebeneinander; zu jedem neuen Verweis erscheinen Autoritätswert und Besucheraufkommen der tragenden Seite. Der Nutzen klingt gering und ist es nicht: Eine fehlende Seite fällt auf, solange noch niemand Budget in Verweise darauf gesteckt hat.
Aufnahmestand nach dem Umbau prüfen
Fragen aus Entwicklung und Marketing
Unsere Seite wird im Browser zusammengesetzt. Ist das ein Ausschlusskriterium?
Kein Ausschlusskriterium, aber auch nichts, was man dauerhaft umgeht. Zwei Dinge sind zu trennen: ob der Text im ausgelieferten Quelltext steht und ob die Navigationsverweise dort stehen. Nur Text ist handhabbar, weil sich Seiten einzeln melden und aus Fließtext heraus verlinken lassen. Fehlt beides, ist es eine echte Sperre — und die Behebung ist meist eine Einstellung im Framework und kein Neubau.
Wir bauen zweimal im Jahr um. Was ist das Minimum?
Zwei Dinge, beide vor dem Umbau: der Export der Adressen mit Zugriffen aus neunzig Tagen und die Zusage, dass jede dieser Adressen seitengenau umgeleitet wird. Alles andere lässt sich nachholen; diese beiden nicht. Eine Sammelumleitung auf die Startseite zählt dabei nicht als Umleitung — sie ist technisch eine und wirtschaftlich ein Verlust.
Blog auf Subdomain oder im Unterverzeichnis?
Bei einer jungen Domain fast immer im Unterverzeichnis, weil es die Vergangenheit der Hauptdomain mitnutzt — und wo diese Vergangenheit ohnehin knapp ist, sollte man sie nicht auf zwei Anfangspunkte aufteilen. Die Subdomain wird meist gewählt, weil das Blogsystem sie leichter einrichtet, und das ist ein Betriebsargument, kein Sichtbarkeitsargument. Wo sie bereits besteht, mildern wechselseitige Verweise den Abstand, ohne ihn zu schließen.
Bringt es etwas, dieselbe Adresse mehrfach zu melden?
Nichts. Eine wiederholte Übermittlung derselben Adresse trägt kein zusätzliches Gewicht. Kommt tagelang kein Bot vorbei, zeigt in aller Regel keine besuchte Seite auf diese Adresse. Zwei interne Verweise von Seiten mit eigenen Zugriffen und eine Woche Geduld führen zuverlässiger zum Ziel — und beides kostet keine Entwicklungszeit.
Wie bekommen wir das in die Entwicklungsplanung?
Mit Nachweis statt mit Einschätzung. Ein Auszug aus dem Protokoll mit den betroffenen Adressen, dem zurückgegebenen Status und Zeitstempeln ist ein Fehlerbericht und bekommt eine Ticketnummer. Die Bemerkung, die Website sei schlecht auffindbar, ist eine Einschätzung und bekommt eine freundliche Antwort. Beide beschreiben denselben Befund, und nur der erste landet in einer Iteration.
Kann eine aufgenommene Seite wieder verschwinden?
Ja, und bei jungen Domains besonders schnell. Seiten ohne Zugriffe, ohne interne Verweise und ohne Änderung werden zurückgestuft. Wirksam ist nicht erneutes Melden, sondern Pflege: einmal jährlich aktualisieren, aus neuen Beiträgen darauf verlinken, und bei jeder Neupositionierung die Adresse behalten, statt eine neue anzulegen.