SEO-Probleme nach einer WordPress-zu-Astro-Migration beheben: Weiterleitungsketten, Sitemaps und GSC-Bereinigung

Nach einer Migration von WordPress zu Astro baut die Website schneller, lädt schneller und ist günstiger im Betrieb. Aber wenn sich die Blog-URLs während der Migration geändert haben — zum Beispiel von /post-slug/ zu /insights/post-slug — gibt es wahrscheinlich SEO-Probleme, die erst Wochen später sichtbar werden, wenn Google das Recrawling abgeschlossen hat.

Google Search Console beginnt dann, E-Mails über „Duplikat, Google hat anderen canonical als Nutzer gewählt" und „Nicht gefunden (404) – Validierung fehlgeschlagen" zu versenden. Die am besten rankenden Seiten verlieren möglicherweise Link-Equity durch unnötige Weiterleitungsschritte. Und es könnten unbemerkt zwei Sitemaps gleichzeitig aktiv sein, die miteinander konkurrieren.

Diese Anleitung erklärt, wie man diese Probleme findet und behebt. Wir sind bei unserer eigenen WordPress-zu-Astro-Migration auf all diese Probleme gestoßen und haben die Lösungen hier dokumentiert.

Was man benötigt

SSH-Zugang zum Server (nginx-Konfiguration)
Google Search Console-Zugang für die eigene Property
curl lokal installiert
Analytics-Tool (wir nutzen self-hosted Plausible)

Was damit behoben wird

Mehrstufige Weiterleitungsketten (2+ Weiterleitungen) werden auf einstufige 301-Weiterleitungen reduziert
Konkurrierende Sitemaps werden zu einer einzigen, automatisch generierten Quelle zusammengeführt
noindex-Seiten werden aus der Sitemap entfernt
Veraltete GSC-Properties und alte WordPress-Sitemaps werden bereinigt
Canonical-Konflikte zwischen alten und neuen URL-Strukturen werden aufgelöst

Schritt 1: Weiterleitungsketten diagnostizieren

Zunächst prüfen, wie viele Weiterleitungsschritte die wichtigsten URLs durchlaufen. Wenn WordPress-URLs einen Trailing Slash hatten und Astro-URLs keinen, entsteht wahrscheinlich eine zweistufige Kette: Eine Weiterleitung entfernt den Slash, eine weitere fügt das neue Pfad-Präfix hinzu.

curl -sL -w "Hops: %{num_redirects}, Final: %{http_code}, URL: %{url_effective}\
" \
  -o /dev/null "https://yourdomain.com/old-post-slug/"

Zeigt die Ausgabe Hops: 2, liegt eine Weiterleitungskette vor. Diesen Test für die fünf meistbesuchten Seiten durchführen — dort ist der Verlust von Link-Equity am folgenreichsten.

Den Befund mit den Analytics-Daten abgleichen. Wenn derselbe Artikel unter mehreren URL-Varianten auftaucht (mit Slash, ohne Slash, mit neuem Präfix), konsolidieren die Weiterleitungen den Traffic nicht. Bei uns war der meistgelesene Artikel in Plausible auf drei URL-Varianten aufgeteilt — ein klares Zeichen für das Kettenproblem.

Schritt 2: nginx für einstufige Weiterleitungen konfigurieren

Die Standard-nginx-Regel zum Entfernen von Trailing Slashes sieht so aus:

location ~ ^(.+)/$ { return 301 $1; }

Diese entfernt den Trailing Slash, kennt aber die geänderte Blog-Pfadstruktur nicht. Die Anfrage trifft dann eine zweite Regel, die /slug auf /insights/slug weiterleitet. Zwei Schritte.

Ersetzen durch eine blog-bewusste Regel, die prüft, ob der Slug zu einem Blogbeitrag gehört, und direkt zur finalen URL weiterleitet:

# Blog-Slugs mit Trailing Slash — einstufig zu /insights/
location ~ ^/([^/]+)/$ {
    set $slug $1;
    if (-f /usr/share/nginx/html/insights/$slug/index.html) {
        return 301 https://yourdomain.com/insights/$slug;
    }
    return 301 https://yourdomain.com/$slug;
}
# Mehrteilige Pfade — nur den Slash entfernen
location ~ ^(.+)/$ { return 301 $1; }

Die erste Regel behandelt Slugs auf Root-Ebene (also die alten WordPress-Blog-URLs). Sie prüft, ob eine passende Seite unter /insights/ existiert, und leitet direkt dorthin weiter. Nicht-Blog-Pfade fallen durch zur generischen Slash-Entfernung. Nach dem Deployment verifizieren:

curl -sL -w "Hops: %{num_redirects}\
" -o /dev/null \
  "https://yourdomain.com/your-top-post-slug/"
# Erwartet: Hops: 1

Schritt 3: Sitemaps konsolidieren

Prüfen, ob mehr als eine Sitemap vorhanden ist. Ein häufiges Muster nach Migrationen: eine statische sitemap.xml, die während des Umzugs manuell erstellt wurde, plus eine automatisch generierte sitemap-index.xml aus Astros @astrojs/sitemap-Integration.

# Beide prüfen
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1

Geben beide 200 zurück, konkurrieren zwei Sitemaps miteinander. Prüfen, welche die robots.txt referenziert:

curl -s "https://yourdomain.com/robots.txt" | grep -i sitemap

Die Lösung: die statische sitemap.xml aus dem public/-Verzeichnis löschen, in der robots.txt auf sitemap-index.xml verweisen und Astros Integration alles übernehmen lassen. Neue Beiträge erscheinen dann bei jedem Build automatisch.

Außerdem die statische Sitemap auf noindex-Seiten prüfen. Wenn die sitemap.xml Seiten wie /legal oder /privacy-policy enthält, die das Tag <meta name="robots" content="noindex"> tragen, werden widersprüchliche Signale an Google gesendet. Die automatisch generierte Sitemap von @astrojs/sitemap lässt sich mit Filterregeln konfigurieren, um diese Seiten korrekt auszuschließen.

Schritt 4: Google Search Console bereinigen

In der GSC zwei Dinge prüfen: Properties und Sitemaps.

Properties: Sind sowohl eine Domain-Property (sc-domain:yourdomain.com) als auch eine URL-Prefix-Property (https://www.yourdomain.com/) vorhanden, erhält man doppelte Warnungen für dieselben Probleme. Eine davon wählen. Wenn Subdomains separate Projekte sind, ist die URL-Prefix-Property sauberer — sie meldet nur den Traffic der Produktionsumgebung.

Sitemaps: Unter Indexierung → Sitemaps alle alten WordPress-Sitemaps entfernen, die dort noch registriert sind (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml usw.). Die neue sitemap-index.xml als einzige Sitemap einreichen.

404-Validierung: Unter Indexierung → Seiten → „Nicht gefunden (404)" prüfen, welche URLs aufgelistet sind. Handelt es sich um alte WordPress-Pfade, die nicht mehr existieren und auch nicht existieren sollen (WooCommerce-Produktseiten, Autorenprofile, Feed-URLs), werden sie mit der Zeit aus dem Index entfernt. Sind es Blogbeiträge, die eine Weiterleitung haben sollten, müssen die nginx-Regeln angepasst werden. Nach dem Beheben der Weiterleitungen auf „Korrektur validieren" klicken, um ein erneutes Crawling auszulösen.

Schritt 5: Alles überprüfen

Nach dem Deployment der Korrekturen diese Checks durchführen:

# 1. Weiterleitungsketten aufgelöst
curl -sL -w "Hops: %{num_redirects}, URL: %{url_effective}\
" \
  -o /dev/null "https://yourdomain.com/your-top-post/"
# Erwartet: Hops: 1, URL endet auf /insights/your-top-post

# 2. robots.txt verweist auf generierte Sitemap
curl -s "https://yourdomain.com/robots.txt" | grep sitemap
# Erwartet: sitemap-index.xml

# 3. Alte statische Sitemap gibt 404 zurück
curl -sI "https://yourdomain.com/sitemap.xml" | head -1
# Erwartet: 404

# 4. Generierte Sitemap gibt 200 zurück
curl -sI "https://yourdomain.com/sitemap-index.xml" | head -1
# Erwartet: 200

# 5. Non-www leitet auf www weiter
curl -sI -o /dev/null -w "%{http_code} %{redirect_url}\
" \
  "https://yourdomain.com/insights"
# Erwartet: 301 https://www.yourdomain.com/insights

Wie lange dauert es, bis Google nachzieht

Einstufige Weiterleitungen wirken sofort bei neuen Crawls. Sitemap-Änderungen werden innerhalb weniger Tage übernommen. Die Canonical-Verwirrung — bei der Google die alte URL gegenüber der neuen bevorzugt — braucht länger zur Auflösung. Google behandelt das <link rel="canonical">-Tag als Hinweis, nicht als verbindliche Anweisung. Wenn die alte URL mehr Backlinks und historische Klickdaten hat, kann Google sie noch wochenlang als canonical bevorzugen.

Die Kombination aus sauberen Weiterleitungen, einer einzigen autoritativen Sitemap und einer konsolidierten GSC-Property gibt Google das klarstmögliche Signal. In unserem Fall begannen die „Duplikater canonical"-Warnungen innerhalb von zwei Wochen nach dem Deployment dieser Korrekturen zurückzugehen.

Wir führen solche Migrationen regelmäßig im Rahmen unserer WordPress-Performance- und Migrationsarbeit durch. Bei Problemen nach einer Migration nehmen Sie gerne Kontakt auf.