Migration zu Next.js / Astro in Bremen

Sie betreiben in Bremen eine WordPress-Website und planen den Umzug auf Astro oder Next.js? Ob danach die Besucher aus der Suche weiter ankommen, entscheidet sich weniger am Framework als an einer Tabelle: jede alte Adresse, ein Ziel dafür, und eine Weiterleitung, die auf dem neuen Host tatsächlich als 301 oder 308 ausgeliefert wird. Auf dieser Seite beschreibe ich, wie ich diese Tabelle baue, wo die Regeln liegen und wie ich vorher und nachher messe. Ich arbeite allein, aus Gdynia, schriftlich und ohne Termine.

Foto: ROMWriter, CC BY-SA 3.0, Wikimedia Commons.

#Woher kommt die Liste der alten URLs?

Eine Sitemap allein reicht nicht, weil sie nur enthält, was Sie im Index haben wollen. Googles Umzugsleitfaden nennt als Quellen die Sitemaps, die meistbesuchten Seiten, den Links-Bericht der Search Console, das CMS und aktuelle Server-Logs. Auch Bilder, Videos, JavaScript und CSS gehören auf die Liste. Ich führe die Quellen in einer Tabelle zusammen und markiere pro Zeile, woher die Adresse stammt.

Ein Beispiel für die Lücken: Eine Produktseite, die nur noch von einem alten PDF-Datenblatt verlinkt wird, taucht im Crawl nicht auf, kann aber in den Logs und im Links-Bericht stehen. Fehlt sie in der Tabelle, bekommt sie auf dem neuen Host einen 404.

#Wie ordne ich jeder alten URL ein Ziel zu?

Google verlangt, jede alte Adresse ihrem neuen Ziel zuzuordnen und diese Zuordnung als Datenbank oder als Rewrite-Regeln zu führen. Ich führe sie als Tabelle mit vier Spalten: alte URL, neue URL, Aktion, Anmerkung. Die Aktion ist eine von vier:

• Gleich: Die Adresse bleibt, es braucht keine Regel. Das ist bei Seiten der Normalfall, deren Slug ich beibehalte.
• Verschoben: 301 oder 308 direkt auf die neue Adresse, ohne Zwischenschritt.
• Zusammengeführt: Mehrere alte Seiten gehen auf die eine neue Seite, die ihren Inhalt übernommen hat.
• Entfällt: 404 oder 410. Für Google sind beide Codes in der Wirkung gleich, wie die Dokumentation zu HTTP-Statuscodes festhält.

Drei Regeln aus Googles Leitfaden halte ich strikt ein. Erstens direkt auf das endgültige Ziel: Googlebot folgt laut Dokumentation bis zu zehn Weiterleitungen, empfohlen sind aber höchstens drei, möglichst weniger als fünf. Zweitens nicht viele alte Adressen auf die Startseite schicken, denn das kann als Soft 404 gewertet werden. Drittens auf der neuen Seite eine selbstreferenzierende Canonical-Angabe setzen, hreflang-Paare nachziehen und interne Links auf die neuen Adressen umstellen. Die Reihenfolge der Signale für die Canonical-Wahl nennt Google in der Anleitung zu doppelten URLs: Weiterleitungen sind ein starkes Signal, rel=canonical ebenfalls, die Sitemap nur ein schwaches.

Typische Zeilen bei WordPress sind die Kategorie- und Schlagwortarchive, die im neuen Projekt nicht mehr existieren, Autorenseiten, /?p=123-Kurzlinks, Anhangsseiten für Bilder und Adressen mit abweichendem Slash am Ende. Für jede dieser Gruppen entscheide ich einmal, ob sie ein Ziel bekommt oder entfällt, und schreibe die Entscheidung in die Anmerkung.

#Wo liegen die Weiterleitungen auf dem neuen Host?

Das hängt davon ab, wo das neue Frontend läuft. Die drei Fälle, die in Bremer Projekten üblich sind:

Cloudflare Pages. Die Datei _redirects im Build-Verzeichnis (bei Astro im Ordner public/) enthält pro Zeile eine Regel. Laut Cloudflare-Dokumentation gilt ohne Angabe der Code 302, ich schreibe deshalb immer 301 dazu:

/leistungen/webdesign/  /webdesign/  301
/blog/*  /magazin/:splat  301

Erlaubt sind 2.000 statische und 100 dynamische Regeln, jede höchstens 1.000 Zeichen lang. Bei mehr Regeln sieht Cloudflare Bulk Redirects vor. Redirects greifen nicht bei Anfragen, die eine Pages Function bearbeitet. Das gehört in die Prüfung, wenn ein Next.js-Projekt Functions nutzt.

Next.js. Der Schlüssel redirects in next.config.js liefert bei permanent: true den Statuscode 308, bei false den temporären Code 307. Laut Next.js-Dokumentation werden Weiterleitungen vor dem Dateisystem geprüft, also auch vor Dateien aus /public. Platzhalter wie /blog/:slug* decken ganze Bäume ab. Hat das Projekt viele Hundert Einzelregeln, lade ich sie aus der Mapping-Tabelle, statt sie von Hand zu pflegen.

Astro. Die Option redirects in astro.config kennt Einträge wie "/alt": "/neu". Der Standardstatus ist 301, aber laut Astro-Dokumentation wird er bei statischer HTML-Ausgabe nicht vom Server verwendet: Astro erzeugt dann eine HTML-Seite mit Meta-Refresh. Echte Statuscodes entstehen, wenn ein Adapter die Regeln in die Konfiguration des Hosts schreibt. Google behandelt einen sofortigen Meta-Refresh laut Weiterleitungs-Dokumentation als permanent, nennt serverseitige Weiterleitungen aber ausdrücklich als bevorzugte Lösung. Ich prüfe deshalb mit curl -I, ob die Antwort wirklich ein 301 ist und nicht eine 200-Seite mit Refresh.

Ein Detail betrifft alle drei: Cloudflare Pages leitet laut Dokumentation /kontakt.html auf /kontakt und /about/index.html auf /about/ um. Alte WordPress-Adressen mit .html oder ohne Slash am Ende gehören deshalb in den Test, nicht nur die Adressen mit Slug.

#Wie teste ich das Mapping vor dem Go-live?

Die Mapping-Tabelle ist zugleich die Testliste. Ein Skript ruft jede alte URL gegen die Staging-Umgebung ab, ohne Weiterleitungen automatisch zu folgen, und vergleicht Statuscode und Zieladresse mit der Tabelle. Es meldet Ketten, Schleifen, 404-Ziele und Weiterleitungen, die als 302 oder 307 ankommen. Dazu kommt die Prüfung der Parameter: ?utm_source= und ähnliche Anhänge dürfen die Weiterleitung nicht aushebeln.

Die Staging-Umgebung bleibt für Suchmaschinen gesperrt. Google rät, die robots.txt der Zielumgebung vorzubereiten und eine Liste der noindex-Regeln zu führen, die beim Start entfallen. Genau diese Liste gehört in die Abnahme: Ein noindex aus der Entwicklungsphase, das in die Produktion wandert, ist ein häufiger Fehler.

#Muss ich bei einem Domainwechsel mehr tun?

Ja, aber nur dann. Das Tool zur Adressänderung der Search Console ist für den Wechsel von einer Domain oder Subdomain auf eine andere gedacht. Es setzt 301-Weiterleitungen und Eigentümerrechte für beide Properties voraus. Für den Wechsel von HTTP auf HTTPS, von www auf non-www, bei einzelnen Seiten innerhalb derselben Website und beim Hostwechsel mit gleichen URLs ist es laut Google nicht vorgesehen. Die Weiterleitungen sollen nach der Dokumentation des Tools mindestens 180 Tage bestehen, der Umzugsleitfaden nennt generell mindestens ein Jahr. Ich halte mich an die längere Angabe.

Wechselt nur der Hoster und bleiben die Adressen gleich, gilt der Leitfaden für Umzüge ohne URL-Änderung: Die neue Umgebung vorher testen, den DNS-TTL mindestens eine Woche vor dem Umzug senken, die Verifizierung in der Search Console mitnehmen und den alten Server erst abschalten, wenn kein Traffic mehr ankommt.

#Was prüfe ich in der Search Console nach dem Start?

Die neue Sitemap kommt in die Search Console. Google empfiehlt außerdem, die Sitemap mit den alten Adressen während der Beobachtung eingereicht zu lassen, damit sich verfolgen lässt, wie die Zahl der indexierten alten URLs sinkt und die der neuen steigt. Warnungen zu Weiterleitungen in dieser alten Sitemap sind erwartet. In der neuen Sitemap stehen nur die Canonical-Adressen. Ein lastmod nutzt Google laut Sitemap-Dokumentation nur, wenn es konsequent stimmt, priority und changefreq ignoriert es. Ich setze deshalb nur ein lastmod, das an das echte Änderungsdatum der Inhalte gebunden ist.

Danach schaue ich auf vier Stellen:

1. Seitenindexierung: unerwartete Fehler, neue Soft-404-Meldungen, Adressen mit “Weiterleitung” in der Liste der nicht indexierten Seiten.
2. Sitemaps-Bericht: Verhältnis eingereichter zu indexierten URLs.
3. Leistungsbericht: Impressionen und Klicks der neuen Adressen.
4. URL-Prüfung: für einzelne Seiten, die nicht auftauchen, mit abgerufener Version und gewählter Canonical.

Dazu kommen die Server-Logs: Ruft der Googlebot die alten Adressen ab, und bekommt er dabei 301 statt 404 oder 5xx? Google nennt für mittelgroße Websites “einige Wochen oder mehr”, bis die neuen Adressen angezeigt werden, und erwartet zeitweilige Schwankungen im Ranking. Feste Crawl-Intervalle gibt es nicht. Ein Urteil nach zwei Tagen ist deshalb zu früh.

#Wie messe ich vorher und nachher?

Ich exportiere vor dem Umzug aus der Search Console Klicks und Impressionen pro Seite und pro Abfragegruppe für einen festen Zeitraum, dazu die Statuscodes aller Adressen aus dem Crawl. Nach dem Go-live wiederhole ich denselben Export mit gleicher Abgrenzung und vergleiche Seitengruppen (Startseite, Leistungen, Blog, Kontakt, Verzeichnisse) Woche für Woche. Einzelne Seiten dürfen schwanken; auffällig ist eine ganze Gruppe, die nicht zurückkommt. Dann gehe ich zuerst zu den Logs und zum Mapping, nicht zum Content.

Zusätzlich messe ich die Core Web Vitals. Die offiziellen Schwellen auf web.dev lauten: LCP bis 2,5 s, INP bis 200 ms und CLS bis 0,1, bewertet am 75. Perzentil, getrennt nach Mobil und Desktop. Ich nenne sie als Prüfmaßstab und verspreche keine Werte, die ich vor dem Umzug nicht gemessen habe. Zusagen wie “ohne Rankingverlust” gebe ich nicht: Ich kann sagen, was ich prüfe und messe, nicht, wie Google den Index neu bewertet.

#Was gilt für Bremer Unternehmen nach DDG und TDDDG?

Zwei Gesetze fallen bei jeder Migration an, weil sich Seitenaufbau und eingebundene Dienste ändern. Dazu gehört die Anbieterkennzeichnung nach § 5 DDG: Name, Anschrift, E-Mail-Adresse und weitere Angaben wie Register und Umsatzsteuer-Identifikationsnummer müssen leicht erkennbar, unmittelbar erreichbar und ständig verfügbar sein. Im neuen Frontend heißt das: Der Impressum-Link steht auf jeder Seite, und die alte Impressum-Adresse leitet auf die neue weiter, statt ins Leere zu laufen.

Die zweite Vorschrift ist § 25 TDDDG: Das Speichern von Informationen im Endgerät oder der Zugriff darauf ist nur mit Einwilligung zulässig, außer es ist unbedingt erforderlich, damit ein vom Nutzer ausdrücklich gewünschter digitaler Dienst bereitgestellt werden kann. Alte WordPress-Plugins setzen Cookies oft, ohne dass es auffällt. Bei der Inventur schreibe ich deshalb auch auf, welche Skripte und Dienste das neue Frontend lädt, und lade sie erst nach der Einwilligung. Die Datenschutzaufsicht für das Land Bremen ist die Landesbeauftragte für Datenschutz und Informationsfreiheit der Freien Hansestadt Bremen. Dort liegt auch das Beschwerdeformular, falls sich ein Besucher über die Seite beschwert.

#Checkliste für Ihre Migration

#Häufige Fragen

#Wie lange müssen die 301-Weiterleitungen bestehen bleiben?

Google nennt in seinem Umzugsleitfaden “generell mindestens ein Jahr” und empfiehlt, sie länger zu halten, wenn die alten Adressen noch Besucher bringen. Beim Tool zur Adressänderung gilt ein Mindestzeitraum von 180 Tagen. Ich plane die Regeln ohne Ablaufdatum ein.

#Reicht die Sitemap als Liste der alten URLs?

Nein. Eine Sitemap enthält nur das, was Sie im Index haben wollen. Google nennt zusätzlich die wichtigsten Seiten, den Links-Bericht der Search Console, das CMS und aktuelle Server-Logs, einschließlich Bilder, Videos, JavaScript und CSS. Aus diesen Quellen baue ich die Liste.

#Genügt bei Astro die redirects-Option, damit Google eine 301 sieht?

Bei statischer Ausgabe nicht von selbst. Astro schreibt dann eine HTML-Seite mit Meta-Refresh, der Statuscode wird vom Server nicht verwendet. Echte 301-Antworten entstehen mit einem Adapter oder mit einer Regeldatei des Hosts, etwa _redirects auf Cloudflare Pages.

#Brauche ich das Tool zur Adressänderung?

Nur bei einem Wechsel der Domain oder Subdomain. Bei einem reinen Systemwechsel unter derselben Domain, bei HTTP zu HTTPS, bei www zu non-www oder bei einem Hostwechsel mit gleichen URLs ist es laut Google nicht vorgesehen.

#Was muss nach der Migration bei Impressum und Cookies stimmen?

Die Anbieterkennzeichnung nach § 5 DDG muss leicht erkennbar, unmittelbar erreichbar und ständig verfügbar bleiben, und die Einwilligung nach § 25 TDDDG muss im neuen Frontend wieder funktionieren. Beides prüfe ich vor dem Go-live auf der Staging-Umgebung.

#Wie Sie mir den Einstieg leicht machen

Schreiben Sie mir über die Kontaktseite: die Adresse Ihrer Website, das CMS mit Version, Ihr Ziel, einen gewünschten Termin und eine Angabe, woher Ihr Traffic kommt. Mit Lesezugriff auf die Search Console sehe ich, welche Seiten Klicks bringen. Entwürfe für Layout und Grafik bringen Sie mit, ich setze sie technisch um. Die erste schriftliche Einschätzung ist kostenlos und enthält die Mapping-Tabelle als Vorlage. Mehr zum Vorgehen steht auf der Seite zur Migration zu Next.js und Astro und im Leitfaden zur Website-Migration. Soll das Redaktionssystem bleiben, hilft die Seite zur Headless-CMS-Entwicklung. Danach kümmert sich auf Wunsch die Wartung für Bremen um Updates und Backups.