Links bei Website-Änderungen im Rahmen einer Migration analysieren

Erstellen Sie die Redirect-Map vor dem Launch

Die Redirect-Map ist der Teil einer Migration, der oft unterschätzt wird. Die Ziel-URLs sind am wichtigsten. Bevor Sie die Linkdaten nach einer Migration analysieren, müssen die alten URLs ein klares Ziel haben, da dies die Adressen sind, auf die Ihre Links bereits zeigen.

Eins-zu-Eins ist besser als ein Dump auf die Startseite

Das Senden von Hunderten unzusammenhängender alter URLs auf die Startseite sagt Suchmaschinen und Besuchern wenig aus. Relevanz ist der Maßstab. Ordnen Sie jede hochwertige alte URL ihrer nächsten neuen Seite zu und leiten Sie den Rest auf eine Sektion, die noch zum Thema passt.

Exportieren Sie die alten URLs mit ihren Statuscodes zuerst. Bewahren Sie diese Datei sicher auf. Diese Datei ist die Checkliste und zeigt, welche Seiten die Links erhalten haben.

Wenn eine Seite keine nahe Entsprechung hat, notieren Sie dies in der Map und leiten Sie sie auf die nächstgelegene Sektion mit einer Notiz. Leere Zellen verbergen Entscheidungen. Eine leere Zelle in der Tabelle ist eine Entscheidung, die niemand getroffen hat.

Ketten vor dem Launch auflösen

Ein Redirect, der zwei frühere Regeln durchläuft, bevor er die neue Seite erreicht, fügt Verzögerung und Risiko hinzu. Ketten entstehen leicht, wenn eine zweite Migration auf der ersten aufbaut, also prüfen Sie die Map vor jedem Wechsel, anstatt anzunehmen, dass sie noch sauber ist. Jeder zusätzliche Hop kostet. Fordern Sie jede alte URL einmal nach dem Wechsel ab und bestätigen Sie, dass sie mit einem einzigen Hop antwortet.

Beheben Sie es früh. Lösen Sie Ketten in der Map selbst auf, nicht Seite für Seite nach dem Launch, damit die Liste kurz bleibt.

Die Pfade, die noch funktionieren, beibehalten

Die Änderung der URL-Struktur bei einem Redesign ist der am leichtesten vermeidbare Verlust. Jede Änderung an einem Pfad ist auch eine Änderung an jedem Link, der darauf zeigt, und diese Links liegen außerhalb Ihrer Kontrolle. Behalten Sie, was funktioniert. Wenn ein Pfad noch funktioniert, behalten Sie ihn und ändern Sie nur das, was die Migration erfordert.

Weniger Redirects, weniger Fehler. Jeder Pfad, den Sie beibehalten, ist ein Link, der überhaupt keinen Redirect benötigte.

Ein beibehaltener Pfad bedeutet, dass die alten Anchor-Zeilen weiterhin auf etwas Nützliches zeigen, was weniger Aufwand für den Wiederaufbau im Sheet bedeutet. Weniger Wiederaufbau später.

Was danach zu erwarten ist

Sie leisten die Schwerstarbeit, und ein 301-Redirect von alter zu neuer URL lässt die alten Links weiterarbeiten. Einen Redirect pro alter URL ohne Kette dazwischen zu halten, ist der einfachste Weg, den Wert jedes Links intakt zu halten. Redirects. Ketten mit drei oder vier Hops verlangsamen Crawler und sollten am besten aufgelöst werden.

Anchor-Text ändert sich nicht, wenn eine URL zieht, weil der Text auf der verlinkenden Seite lebt. Was sich ändert, ist die Ziel-URL-Anzahl: Ihre Top-Seiten-Tabelle zeigt, wie der alte Host verblassen und der neue über einige monatliche Updates aufsteigen wird. Ziele verschieben sich langsam.

Eine häufige Überraschung ist, die alte Plattform zu früh zu löschen. Nicht tun. Squarespace, Wix und ähnliche Hosts halten oft die Redirect-Regeln, sodass das Kündigen des Plans diese entfernen kann und die Links dann in eine Sackgasse zeigen, bis Sie die Regeln woanders wieder aufbauen.

Hreflang und Canonical-Tags verdienen ebenfalls einen Blick. Fehler sind häufig. Nach einer CRA-zu-Next.js-Migration haben Sites beispielsweise oft Canonical-Tags, die mit ihren hreflang-Sätzen nicht übereinstimmen, und Links verteilen sich auf zwei Versionen einer Seite.

Wenn die Zahlen nach der Migration nicht übereinstimmen, prüfen Sie die Fehlerbehebungs-Tabelle, bevor Sie annehmen, dass Links verloren gegangen sind. Ein monatliches Update allein erklärt viele Lücken. Lücken sind oft ein Timing-Problem.

Erwarten Sie den ersten sauberen Vergleich etwa zwei monatliche Updates nach dem Launch, und notieren Sie das Datum jedes Updates in Ihrem Sheet, damit ein flacher Monat nicht mit einem steckengebliebenen verwechselt wird. Geben Sie ihm Zeit. Ahrefs oder Semrush können die Lücke mit frischeren Crawls füllen, wenn Sie eine Zwischenbewertung benötigen.

Beobachten Sie, was ohne Launch-Ankündigung zieht

Ein Launch-Tag hat eine Checkliste, aber mehrere Probleme treten später und leise auf. Sie zeigen sich in den Zeilen und im Index, lange nachdem das Team zu anderen Aufgaben gewechselt hat. Sie sind leicht zu übersehen.

Noindex, das mit einem Staging-Build mitzieht

Eine Staging-Kopie, die aus den Suchergebnissen gehalten wurde, kann ihre Einstellungen in die Live-Site übernehmen. Prüfen Sie die Robots-Meta-Tags und jeden Noindex-Header beim ersten Crawl, und stichprobenartige Seiten aus jedem Abschnitt, nicht nur die Startseite. Stichproben aus jedem Abschnitt.

Vorlagen brechen zuerst. Wenn ein ganzer Abschnitt nach dem Launch aus dem Index fällt, schauen Sie sich seine Vorlage an, bevor Sie sich den Inhalt ansehen.

Screenshots helfen ebenfalls. Bewahren Sie eine Kopie der Robots-Einstellungen aus dem Staging-Build auf. Wenn etwas aus dem Index fällt, dauert der Vergleich der beiden Einstellungen nur Minuten statt eines ganzen Nachmittags.

Fragment-Links, die indexiert werden

Sprunglinks wie ein Inhaltsverzeichnis-Anker können als separate URLs in den Suchergebnissen erscheinen. Suchmaschinen falten diese normalerweise in die Hauptseite zusammen, aber wenn sie es nicht tun, kann derselbe Inhalt unter mehreren Adressen erscheinen. Sie teilen Signale von der Hauptseite weg und können in einem Coverage-Bericht wie doppelte Seiten aussehen. Hash-URLs vermehren sich leise.

Eine Version, eine Adresse. Ein Canonical-Tag, das auf eine Adresse verweist, während die Sitemap eine andere auflistet, sendet gemischte Signale, und der Bericht zeigt den Fehler an. Legen Sie eine kanonische Version jeder Seite fest und bestätigen Sie, dass die Sitemap dieselbe Version auflistet.

Prüfen Sie den Coverage-Bericht nach dem Launch auf URLs mit einem Hash darin, denn das sind diejenigen, die sich leise vermehren. Hashes sind der Übeltäter.

Eine Subdomain wird zur Hauptdomain

Das Verschieben einer Site von einer Staging-Subdomain auf die Hauptdomain bringt eigene Duplikate mit, da beide Versionen eine Zeit lang erreichbar bleiben können. Entscheiden Sie sich vor dem Launch für den canonical Host. Wählen Sie den Host früh.

Ein Host, überall. Wenn sich ein Host an einer Stelle ändert, an einer anderen aber nicht, kann die ältere Version monatelang Links sammeln, ohne dass es jemand bemerkt. Halten Sie dann die Sitemap, die Canonical-Tags und alle hreflang-Sätze auf diesen einen Host gerichtet.

Do-Follow-Links, die zu verschwinden scheinen

Nach einem Redesign können die Do-Follow-Zeilen in einem Tool stark zurückgehen, und die erste Vermutung ist, dass die Links weg sind. Vergleichen Sie die alten Top-Seiten mit den neuen, bevor Sie diese Vermutung akzeptieren, und prüfen Sie dann, ob jede alte Adresse jetzt korrekt weiterleitet. Prüfen Sie, bevor Sie in Panik geraten.

Beheben Sie das zuerst. Ein Link, der auf der verlinkenden Seite noch existiert, aber auf eine tote Adresse zeigt, ist der Fall, den Sie zuerst beheben sollten.

Legen Sie das Datum früh fest. Geben Sie dem Team ein festes Datum für den Vergleich, damit niemand täglich den Pull neu ausführt und Rauschen als Neuigkeit liest.

Zusammenarbeit mit einem Entwickler während der Migration

Der Großteil der Redirect-Arbeit fällt auf einen Entwickler, und das Monitoring fällt auf den, der das Sheet liest. Das Aufschreiben der Aufteilung als kurze Tabelle mit einem Namen in jeder Zelle reicht oft aus, um zu verhindern, dass zwei Personen dieselbe Aufgabe übernehmen. Teilen Sie diese Rollen auf dem Papier vor dem Launch, damit niemand annimmt, dass der andere beobachtet. Rollen brauchen Namen.

Geben Sie dem Entwickler eine Map, keine Aufgabenliste

Eine Aufgabenliste sagt einem Entwickler, was zu tun ist, während eine Map zeigt, welche alte Adresse wohin geht. Senden Sie die Eins-zu-Eins-Tabelle mit den Statuscodes und dem Grund für jede Zeile, damit Randfälle eine Entscheidung statt einer Schätzung erhalten. Entscheidungen sind besser als Schätzungen.

Testpläne kommen zuerst. Bitten Sie um einen kurzen Testplan, der mit den alten Adressen aus der Top-Seiten-Datei beginnt.

Vereinbaren Sie, wer die monatliche Datei liest

Der erste saubere Vergleich kommt etwa zwei Updates nach dem Launch, und die Datei benötigt einen Leser. Die erste Auswertung nach dem Launch ist meist verrauscht, und ein Leser, der das weiß, wird nicht auf einen einzelnen ungewöhnlichen Monat reagieren. Nennen Sie diese Person, den Tag, an dem sie sie öffnet, und das Sheet, in das das Ergebnis geht. Jemand muss die Verantwortung übernehmen.

Daten klären die Frage. Das Notieren des Update-Datums neben jeder Datei verwandelt die Sorge um einen steckengebliebenen Index in eine einfache Tatsache über den Kalender. Ein flacher Monat ist leicht als steckengeblieben zu missdeuten, es sei denn, jemand notiert die Update-Daten.

Bitten Sie diese Person, eine Zeile pro Update zu schreiben, auch wenn sich nichts geändert hat, damit die Datei eine lückenlose Aufzeichnung behält. Eine Zeile jedes Mal.

Planen Sie den Rollback vor dem Launch

Wenn der neue Host einen kritischen Pfad beschädigt, benötigt das Team einen vorher getesteten Rückweg. Schreiben Sie die Schritte auf, einschließlich wer den Schalter umlegen kann und wie sich die Redirects verhalten, während er rückgängig gemacht wird. Üben Sie es vor dem Launch.

Schreiben Sie den Rollback auf. Ein Rollback, der nur im Kopf einer Person existiert, ist kein Plan.