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

Nach einer Migration von WordPress zu Astro wird Ihre Website schneller erstellt, lädt schneller und kostet weniger im Hosting. Haben sich dabei aber die Blog-URLs geändert – etwa von /post-slug/ zu /insights/post-slug –, entstehen wahrscheinlich SEO-Probleme, die erst Wochen später sichtbar werden, wenn Google die Website erneut vollständig gecrawlt hat.

Google Search Console beginnt dann, E-Mails mit Meldungen wie „Duplikat: Google hat eine andere kanonische Seite als der Nutzer bestimmt“ und „Nicht gefunden (404): Validierung fehlgeschlagen“ zu versenden. Ihre bestplatzierten Seiten durchlaufen möglicherweise unnötige Weiterleitungsschritte. Außerdem pflegen Sie womöglich unbemerkt zwei sich überschneidende Sitemaps.

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 Sie benötigen

SSH-Zugang zum Server (nginx-Konfiguration)
Zugang zu Google Search Console für Ihre Property
curl lokal installiert
Analysewerkzeug (wir verwenden selbst betriebenes Plausible)

Was damit behoben wird

Mehrstufige Weiterleitungsketten (2+ Weiterleitungen) werden auf einstufige 301-Weiterleitungen reduziert
Doppelte 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

Prüfen Sie, wie viele Weiterleitungen Ihre wichtigsten URLs durchlaufen. Endeten Ihre WordPress-URLs mit einem Schrägstrich, Ihre Astro-URLs jedoch nicht, besteht wahrscheinlich eine zweistufige Kette: Eine Weiterleitung entfernt den Schrägstrich, eine weitere ergänzt das neue Pfadpräfix.

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. Führen Sie den Test für Ihre fünf meistbesuchten Seiten durch – dort fallen zusätzliche Weiterleitungsschritte am stärksten ins Gewicht.

Gleichen Sie den Befund mit Ihren Analysedaten ab. Erscheint derselbe Artikel unter mehreren URL-Varianten (mit Schrägstrich, ohne Schrägstrich, mit neuem Präfix), bündeln Ihre Weiterleitungen die Seitenaufrufe nicht. Bei uns war der meistgelesene Artikel in Plausible auf drei URL-Varianten verteilt. Das war der Anlass für die oben beschriebene Prüfung der Weiterleitungen.

Schritt 2: nginx für einstufige Weiterleitungen konfigurieren

Die übliche nginx-Regel zum Entfernen abschließender Schrägstriche sieht so aus:

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

Sie entfernt den abschließenden Schrägstrich, berücksichtigt aber den geänderten Blogpfad nicht. Anschließend greift eine zweite Regel, die /slug auf /insights/slug weiterleitet. Das ergibt zwei Schritte.

Ersetzen Sie sie durch eine Regel, die Blogbeiträge berücksichtigt: Sie prüft, ob der Slug zu einem Blogbeitrag gehört, und leitet direkt zur endgültigen URL weiter:

# 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://www.yourdomain.com/insights/$slug;
    }
    return 301 https://www.yourdomain.com/$slug;
}
# Mehrteilige Pfade — nur den Slash entfernen
location ~ ^(.+)/$ { return 301 https://www.yourdomain.com$1; }

Die erste Regel behandelt Slugs auf der obersten Pfadebene, also Ihre alten WordPress-Blog-URLs. Sie prüft, ob eine passende Seite unter /insights/ existiert, und leitet direkt dorthin weiter. Bei anderen Pfaden auf der obersten Ebene entfernt dieselbe Regel den abschließenden Schrägstrich mit einer einzigen Weiterleitung; Pfade mit mehreren Segmenten werden von der zweiten, allgemeinen Regel erfasst. Prüfen Sie nach dem Deployment das Ergebnis:

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 Sie, ob mehr als eine Sitemap vorhanden ist. Ein häufiges Muster nach einer Migration: eine während des Umzugs manuell erstellte statische sitemap.xml und 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, pflegen Sie zwei Sitemaps, die auseinanderlaufen können. Prüfen Sie, auf welche robots.txt verweist:

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

Die Lösung: Löschen Sie die statische sitemap.xml aus Ihrem public/-Verzeichnis, verweisen Sie in robots.txt auf sitemap-index.xml und überlassen Sie alles Weitere Astros Integration. Neue Beiträge erscheinen bei jedem Build automatisch.

Prüfen Sie die statische Sitemap auch auf noindex-Seiten. Enthält Ihre sitemap.xml Seiten wie /legal oder /privacy-policy mit dem Tag <meta name="robots" content="noindex">, senden Sie widersprüchliche Signale an Google. 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

Öffnen Sie GSC und prüfen Sie zwei Bereiche: Properties und Sitemaps.

Properties: Haben Sie sowohl eine Domain-Property (sc-domain:yourdomain.com) als auch eine URL-Präfix-Property (https://www.yourdomain.com/), erhalten Sie doppelte Warnungen für dieselben Probleme. Sie dürfen beide beibehalten. Wenn die doppelten E-Mails jedoch stören, wählen Sie eine davon. Sind Ihre Subdomains separate Projekte, ist die URL-Präfix-Property übersichtlicher: Sie berichtet nur über URLs unter genau diesem Präfix, etwa auf Ihrem produktiven www-Host.

Sitemaps: Öffnen Sie Indexierung → Sitemaps. Entfernen Sie alle noch registrierten alten WordPress-Sitemaps (post-sitemap.xml, page-sitemap.xml, sitemap-post-type-product.xml usw.). Reichen Sie Ihre neue sitemap-index.xml als einzige Sitemap ein.

404-Validierung: Prüfen Sie unter Indexierung → Seiten → „Nicht gefunden (404)“, welche URLs aufgeführt sind. Alte WordPress-Pfade, die nicht mehr existieren und auch nicht mehr benötigt werden (WooCommerce-Produktseiten, Autorenseiten, Feed-URLs), verschwinden mit der Zeit aus dem Index. Sind es Blogbeiträge, die weitergeleitet werden sollten, müssen Sie Ihre nginx-Regeln aktualisieren. Klicken Sie nach der Korrektur auf „Fehlerbehebung überprüfen“, um ein erneutes Crawling auszulösen.

Schritt 5: Alles überprüfen

Führen Sie nach dem Deployment Ihrer Korrekturen diese Prüfungen durch:

# 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 braucht Google für die Aktualisierung?

Einstufige Weiterleitungen wirken bei neuen Crawls sofort. Sitemap-Änderungen werden innerhalb weniger Tage erfasst. Canonical-Konflikte, bei denen Google die alte URL der neuen vorzieht, brauchen länger. Google behandelt das Tag <link rel="canonical"> als Hinweis, nicht als verbindliche Anweisung. Hat die alte URL mehr Backlinks und historische Klickdaten, kann Google sie noch mehrere Wochen als kanonische URL wählen.

Saubere Weiterleitungen und eine einzige maßgebliche Sitemap geben Google das klarstmögliche Signal; eine konsolidierte GSC-Property macht die verbleibenden Berichte übersichtlicher. Bei uns gingen die Warnungen zu abweichenden kanonischen URLs innerhalb von zwei Wochen nach dem Deployment dieser Korrekturen erstmals zurück.

Wir führen solche Migrationen regelmäßig im Rahmen unserer WordPress-Optimierungen und -Migrationen durch. Bei SEO-Problemen nach einer Migration nehmen Sie Kontakt mit uns auf.