curl -sS -D - -o /dev/null "$OLD_URL"

Weiterleitungen folgen und Antwortheader aller Stationen anzeigen

curl -sS -L -D - -o /dev/null "$OLD_URL"

Endgültigen Status und endgültige Adresse zur Dokumentation ausgeben

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

Im Abnahmeprotokoll sollten die erste Antwort, die Zieladresse, die endgültige Antwort und der Seiteninhalt gemeinsam festgehalten werden. Welche Art von Regel für einen dauerhaften Umzug verwendet wird, muss die technisch verantwortliche Person anhand der tatsächlichen Bereitstellungsumgebung bestätigen. Die bloße Beobachtung im Browser, dass „anscheinend weitergeleitet wurde“, reicht als Ergebnis nicht aus.

Unnötige Weiterleitungsketten, Rückleitungen auf alte Adressen, Weiterleitungen auf Testdomains und nicht vorhandene Zielseiten sollten als Hindernisse für den Livegang definiert werden. Besonders wichtig ist, nicht nur die Regeln für die Startseite zu prüfen und dabei Artikel- oder Produktdetailseiten zu übersehen.

## 5. Wie lassen sich Seiteninhalte und Canonical-Angaben gemeinsam abnehmen?

Dass eine Adresse geöffnet werden kann, ist nur die Mindestanforderung. Es empfiehlt sich, aus jeder Seitenvorlage repräsentative Seiten auszuwählen und zu prüfen, ob Seitentitel, Hauptüberschrift, Hauptinhalt, alternative Bildtexte, interne Links und Kontakt- beziehungsweise Beratungsbuttons vollständig vorhanden sind. So wird vermieden, dass nach dem Import nur noch die äußere Seitenhülle übrig bleibt.

Canonical-Angaben können als Prüfpunkt für die kanonische Adresse dienen, sollten aber nicht als Ersatz für die Behebung sämtlicher Migrationsprobleme betrachtet werden. Bei der Abnahme ist die von der Seite angegebene kanonische Adresse zu dokumentieren und mit der im Projekt festgelegten produktiven Seite abzugleichen. Besonders zu prüfen sind Angaben, die noch auf die alte Domain, eine Vorschaudomain oder eine inhaltlich unpassende Seite verweisen.

Bei mehrsprachigen Websites müssen zusätzlich die Zuordnungen zwischen den Sprachversionen geprüft werden. Eine chinesischsprachige Produktseite sollte nicht durch eine Massenersetzung auf die englische Startseite verlinken. Sprachumschaltung, Links in der Fußzeile und empfohlene Links im Hauptinhalt müssen durch tatsächliches Anklicken getestet werden.

Gleichzeitig sind die wesentlichen Informationen vor und nach der Migration zu vergleichen. Preisbedingungen, Leistungsumfang, Nachweise zu Referenzen und Kontaktdaten dürfen beim Austausch der Vorlagen nicht versehentlich verloren gehen. Bei Seiten, auf die der Vertrieb angewiesen ist, sollten auch die fachlich Verantwortlichen an der Abnahme beteiligt werden, statt ausschließlich die Entwicklung die technischen Antworten prüfen zu lassen.

## 6. Was ist bei der Sitemap zu prüfen? Zuerst mit der Liste der produktiven Seiten abgleichen

Zunächst sollte eine „Liste der produktiven Seiten, die öffentlich zugänglich und über Suchmaschinen auffindbar sein sollen“ erstellt und anschließend mit der generierten Sitemap abgeglichen werden. Die bloße Erstellung einer XML-Datei bedeutet nicht, dass die Prüfung abgeschlossen ist.

Besonders wichtig sind folgende Punkte:

- Gehören die Adressen in der Sitemap zur produktiven Domain und zur produktiven Umgebung?
- Sind die neuen Pfade nach der Migration wie geplant enthalten?
- Haben sich gelöschte, weiterhin weiterleitende oder noch nicht zur Veröffentlichung vorgesehene Adressen eingeschlichen?
- Stimmen die in der Sitemap aufgeführten Seiten mit den auf den Seiten angegebenen kanonischen Adressen überein?
- Fehlen ganze Bereiche, etwa Sprachverzeichnisse, paginierte Artikellisten oder Produktkategorien?
- Ist eindeutig festgelegt, wer die Sitemap aktualisiert und erneut veröffentlicht?

Wenn sich die Zahl der Sitemap-Einträge ändert, sollte nach der Ursache gefragt werden: Wurden Inhalte planmäßig zusammengeführt, oder liegt ein Importfehler beziehungsweise eine falsche Filterbedingung vor? Es empfiehlt sich, Dateikopien von vor und nach der Migration aufzubewahren, um sie Eintrag für Eintrag vergleichen zu können.

Die Sitemap ist nur ein Teil der Migrationsabnahme. Auch nach dem Einreichen müssen die Erreichbarkeit, die Inhalte und die spätere Entwicklung einzelner Seiten geprüft werden. Daraus dürfen keine Zusagen zu Indexierung, Rankings oder Besucherzahlen abgeleitet werden.

## 7. Was ist in der Search Console vor und nach dem Livegang zu prüfen?

![7. Was ist in der Search Console vor und nach dem Livegang zu prüfen?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

Vor dem Livegang sollte sichergestellt werden, dass das Team auf die relevanten Website-Properties zugreifen kann und die Berechtigungen der zuständigen Personen beim Ausscheiden des bisherigen Dienstleisters nicht verloren gehen. Wichtige Einstiegsseiten, Suchanfragen, Klicks und Impressionen vor der Migration sollten zusammen mit dem Beobachtungsdatum dokumentiert werden, um einen Ausgangspunkt für spätere Vergleiche zu schaffen.

Nach dem Livegang empfiehlt es sich, die folgenden Punkte in dieser Reihenfolge zu prüfen und zu dokumentieren:

1. **Property und Berechtigungen**: Wird gerade die Website-Property betrachtet, die von dieser Migration betroffen ist, und haben die Verantwortlichen weiterhin Zugriff?
2. **Repräsentative URLs**: Crawling, Indexierungsstatus und Angaben zur kanonischen Adresse wichtiger Seiten prüfen und dabei historische Aufzeichnungen von späteren Veränderungen unterscheiden.
3. **Sitemap**: Eingereichte Sitemap, Verarbeitungsstatus und zugehörige Hinweise abgleichen. Bei Auffälligkeiten anschließend die tatsächliche Datei untersuchen.
4. **Seitenprobleme**: Auffälligkeiten nach Verzeichnis und Vorlage ordnen, statt nur auf die Gesamtzahl zu schauen.
5. **Leistung**: Suchanfragen, Klicks und Impressionen anhand alter Seiten und ihrer jeweiligen neuen Entsprechungen vergleichen, nicht nur anhand der Startseite.

Wenn gleichzeitig die Domain gewechselt wird, ist gesondert zu prüfen, ob die Verfahren zur Adressänderung für die eigene Migration geeignet sind. Ein Wechsel des Website-Baukastens unter derselben Domain darf nicht mit einer Migration auf eine andere Domain gleichgesetzt werden.

Bei Problemen sollten Seitenadresse, angezeigter Hinweis, Beobachtungszeitpunkt und Ergebnis des erneuten Tests im selben Ticket festgehalten werden. Seiten sollten nicht allein aufgrund eines einzelnen Screenshots gelöscht und Regeln nicht deshalb wiederholt geändert werden.

## 8. Wie sollten Abnahme und Zurücksetzen am Tag des Livegangs organisiert werden?

Es empfiehlt sich, den Livegang in Vorbereitung, Umstellung, erneute Tests und Beobachtung zu gliedern. In der Vorbereitungsphase werden wichtige Inhaltsänderungen eingefroren, Seitendaten und Konfigurationen gesichert und die notwendigen Zugriffsmöglichkeiten auf die alte Website weiterhin sichergestellt.

Nach der Umstellung werden zuerst die entscheidenden geschäftlichen Abläufe getestet: Einstieg über eine alte Adresse, Lesen der Produktbeschreibung, Absenden des Formulars, Empfang der Benachrichtigung und Nachverfolgung durch den Vertrieb. SEO-Prüfungen und Prüfungen der Lead-Erfassung sollten parallel erfolgen, damit nicht zwar die Seite erreichbar ist, aber niemand die Anfragen erhält.

Bedingungen, die den Livegang verhindern, sollten im Voraus vereinbart werden. Dazu zählen beispielsweise nicht erreichbare wichtige Produktseiten, zahlreiche alte Einstiegsadressen ohne vorgesehenes Ziel, produktive Seiten mit weiterhin aktiven Einschränkungen der Testumgebung oder ein ausgefallener Kontaktprozess. In solchen Fällen entscheidet die verantwortliche Person über Reparatur oder Zurücksetzen, statt während des Livegangs noch über die Maßstäbe zu streiten.

Auch für das Zurücksetzen sollte es eine Arbeitsanweisung geben: Wer darf es ausführen, welche Konfigurationen müssen wiederhergestellt werden und wie wird der Erfolg der Wiederherstellung bestätigt? Erst am Migrationstag festzustellen, dass die alte Website bereits gelöscht wurde oder die Zugriffsrechte auf das Konto beim bisherigen Dienstleister nicht mehr gültig sind, ist zu vermeiden.

## 9. Wie lassen sich Veränderungen nach der Migration systematisch untersuchen?

Zuerst sollten reproduzierbare technische und inhaltliche Probleme untersucht werden, bevor die allgemeine Entwicklung der Suchleistung diskutiert wird. Eine mögliche Reihenfolge lautet: Sind die Seiten erreichbar? Führen alte Einstiegsadressen zum richtigen Ziel? Sind die Inhalte vollständig? Wurden interne Links aktualisiert? Stimmen Sitemap und Seitenangaben überein?

Beim Datenvergleich sollten die alte und die neue Adresse derselben geschäftlich relevanten Seite gemeinsam betrachtet werden. Wer nur die Historie der neuen Adresse betrachtet, übersieht leicht die Daten vor der Migration. Wer ausschließlich auf die Gesamtsummen der Website schaut, kann dagegen Verluste in einem wichtigen Verzeichnis übersehen.

Zusätzlich sollten zeitgleiche Änderungen an Werbung, die Bearbeitung oder Löschung von Inhalten, saisonale Aktionen und Anpassungen der Analysekonfiguration dokumentiert werden, damit nicht jede Veränderung dem Plattformwechsel zugeschrieben wird. Es empfiehlt sich, pro Durchgang nur eine klar abgegrenzte Gruppe von Problemen zu beheben und die Ergebnisse der erneuten Tests festzuhalten. So wird vermieden, dass sich mehrere Änderungen überlagern und die Ursachen anschließend nicht mehr zuzuordnen sind.

Es gibt keine einheitliche Erholungsfrist, die für alle Websites gilt. Für die Migrationsabnahme kann ein interner Rhythmus zur Nachprüfung festgelegt werden. Dieser sollte jedoch nicht als Zusage über die Verarbeitungsdauer von Suchmaschinen dargestellt werden.

## 10. Wie sollte bei der Auswahl einer KI-Website-Plattform nach Migrationsfunktionen gefragt werden?

Die Erstellung neuer Seiten und die Übernahme einer bestehenden Website sind zwei unterschiedliche Abnahmeaufgaben. Die [offizielle Website von we0](https://we0.ai/zh) beschreibt die Anforderungsformulierung in natürlicher Sprache, die Website-Erstellung mit mehreren Agenten, visuelle Anpassungen und die Bereitstellung unter einer Domain. Unternehmen können anhand dessen die Art der Website-Erstellung bewerten. Dennoch sollten sie sich die Beibehaltung alter Pfade, die Konfiguration von Weiterleitungen und die Testverfahren nach der Migration separat vorführen lassen, statt anzunehmen, dass diese Aufgaben automatisch erledigt werden.

Als Referenz für eine andere Produktkategorie beschreibt die [offizielle Website von Readdy](https://readdy.ai/zh) Codeexport, Domain-Hosting sowie Werkzeuge für SEO und GEO. Bei der Beschaffung sollte weiter nachgefragt werden: Wer pflegt nach dem Export die Bereitstellungskonfiguration? Wer verwaltet die Pfadregeln? Wer untersucht Auffälligkeiten? Funktionsbezeichnungen ersetzen keine schriftliche Festlegung der Projektverantwortlichkeiten.

Der [Vorstellungsartikel zu Wanxiaozhi in der Alibaba Cloud Developer Community](https://developer.aliyun.com/article/1773673) behandelt die dialogbasierte Website-Erstellung und den Bereitstellungsprozess. Die Seite weist jedoch darauf hin, dass der Inhalt von Nutzern beigesteuert wurde. Der Beitrag eignet sich, um dem Team Anwendungsszenarien der Website-Erstellung zu erläutern. Er sollte nicht als Zusage des Anbieters zum Umfang der Migrationsleistungen in diesem Projekt betrachtet werden.

Es empfiehlt sich, die infrage kommende Plattform oder den Umsetzungspartner eine kleine Auswahl tatsächlicher alter Seiten demonstrieren zu lassen, bevor über Beschaffung und Livegang entschieden wird. Die Demonstration sollte verschiedene Vorlagen und Fehlerfälle abdecken und nicht nur die Erstellung einer neuen Startseite zeigen.

## Häufige Fragen

### Ist eine Migrationscheckliste auch nötig, wenn nur die Website-Plattform, nicht aber die Domain gewechselt wird?

Ja. Es empfiehlt sich zu prüfen, ob Pfade, Hauptinhalte, Seitenangaben, interne Links und der Kontaktprozess konsistent bleiben. Eine unveränderte Domain bedeutet nicht, dass alle Ergebnisse der Bereitstellung automatisch dem ursprünglichen Plan entsprechen.

### Können sämtliche alten Seiten auf die Startseite weitergeleitet werden?

Als Standardlösung ist das nicht zu empfehlen. Zuerst sollte für jede alte Seite geprüft werden, ob eine inhaltlich passende neue Zielseite vorhanden ist. Gibt es keinen Ersatzinhalt, muss die vorgesehene Behandlung ebenfalls ausdrücklich dokumentiert werden, statt fehlende Inhalte durch eine Weiterleitung auf die Startseite zu verdecken.

### Ist die Migration mit dem Einreichen der Sitemap abgeschlossen?

Nein. Zusätzlich müssen alte Einstiegsadressen getestet, wichtige Seiten geprüft und geschäftlich relevante Abläufe abgenommen werden. Außerdem sind Statusänderungen in der Search Console fortlaufend zu dokumentieren. Das Einreichen ersetzt keine tatsächlichen Aufruftests.

## Zugehörige Werkzeuge

- **URL-Zuordnungstabelle**: Verwaltung alter Pfade, neuer Pfade, der vorgesehenen Behandlung und der Verantwortlichen.
- **curl**: Untersuchung von Antwortheadern, Weiterleitungsabläufen und endgültigen Adressen.
- **Google Search Console**: Zusammenstellung von Prüfprotokollen zu Website-Status und Suchleistung.
- **Browser-Entwicklerwerkzeuge**: Erneute Tests des Seitenladens, der Links und der Formularanfragen.

## Weiterführende Links

- [we0: Website-Erstellung, Seitenanpassung und Bereitstellungsprozess](https://we0.ai/zh)
- [Readdy: Einführung in Website-Erstellung, Codeexport und Werkzeuge für den laufenden Betrieb](https://readdy.ai/zh)
- [Alibaba Cloud Developer Community: Einführung in Anwendungsszenarien der KI-Website-Erstellung mit Wanxiaozhi](https://developer.aliyun.com/article/1773673)

## Zusammenfassung

Bei der Abnahme nach einem Wechsel der Website-Plattform geht es nicht nur um die neue Website, sondern um den vollständigen Weg vom bisherigen Einstieg über neue Inhalte bis zur Kontaktaufnahme. Zuerst wird eine URL-Zuordnungstabelle erstellt. Anschließend werden Weiterleitungen, Seiteninhalte, Sitemap und geschäftliche Abläufe getestet. Abschließend erfolgt die fortlaufende Untersuchung mithilfe der Search Console. Die Fähigkeiten der Plattform sollten anhand tatsächlicher Seiten demonstriert und bestätigt werden. Die Verantwortlichkeiten für die Migration und die Bedingungen für ein Zurücksetzen sind hingegen vor dem Livegang schriftlich festzulegen.