Seiten nach Site-Migration nicht indexiert: Kompletter Recovery-Guide
Deine Site-Migration lief im Browser reibungslos, aber Google tut sich schwer, deine neuen URLs zu erkennen. Verstehe das kritische 90-Tage-Fenster und behebe die Redirect-, Canonical- und Verifizierungs-Probleme, die die Post-Migrations-Indexierung blockieren.
In dieser Anleitung
Site-Migrationen gehören zu den riskantesten Operationen in SEO. Egal ob du zu einer neuen Domain wechselst, deine URL-Struktur änderst, von HTTP zu HTTPS migrierst, CMS-Plattformen wechselst oder mehrere Sites zu einer konsolidierst, die Migration stört fundamental Googles Verständnis deiner Site. Seiten, die jahrelang indexiert waren, können plötzlich aus den Suchergebnissen verschwinden. Neue URLs, die alte ersetzen sollen, bleiben in der Crawl-Warteschlange stecken. Rankings fallen über alle Bereiche ab, während Google deine gesamte Site in ihrer neuen Form neu bewertet.
Die ersten 90 Tage nach einer Migration sind kritisch. Während dieser Zeit crawlt Google deine Site aktiv neu, verarbeitet Redirects, bewertet neue URLs und entscheidet, ob die neue Site-Struktur dieselbe Indexierungs-Abdeckung und Rankings wie die alte verdient. Fehler in diesem Fenster können in Monaten verlorenen Traffics resultieren. Aber selbst gut ausgeführte Migrationen erleben häufig Indexierungs-Lücken, bei denen manche Seiten auf der neuen Site nicht indexiert sind, während ihre alten URL-Gegenstücke aus dem Index entfernt wurden.
Post-Migrations-Indexierungs-Probleme unterscheiden sich von normalen Indexierungs-Problemen, weil sie einen Übergang zwischen zwei Zuständen umfassen. Google muss gleichzeitig das Entfernen alter URLs und das Hinzufügen neuer verarbeiten, Autorität von alten Seiten zu neuen Seiten über Redirects übertragen und sein bestehendes Verständnis des Inhalts deiner Site mit der neuen Struktur in Einklang bringen. Das erzeugt Gelegenheiten für Verwirrung, ausgelassene Signale und Indexierungs-Lücken, die im normalen Site-Betrieb nicht auftreten.
Dieser Guide behandelt die spezifischen Indexierungs-Probleme, die während und nach Site-Migrationen auftreten, die Diagnose-Schritte zur Identifizierung und die Lösungen, um sie schnell zu beheben und Traffic-Verluste während der Übergangszeit zu minimieren.
Das kritische 90-Tage-Post-Migrations-Fenster
Googles Reaktion auf eine Site-Migration entfaltet sich über etwa 90 Tage, obwohl die genaue Zeitachse je nach Site-Größe, Crawl-Frequenz und Umfang der Änderungen variiert. Das Verständnis dieser Zeitachse hilft, Erwartungen zu setzen und zu identifizieren, wann Indexierungs-Verzögerungen normal sind versus wann sie auf ein Problem hindeuten.
In den ersten ein bis zwei Wochen nach der Migration beginnt Google, die Änderungen zu entdecken. Hast du 301-Redirects von alten zu neuen URLs eingerichtet, trifft Google während seines normalen Crawls deiner alten URLs auf diese Redirects. Jeder Redirect sagt Google, dass die alte URL permanent zu einem neuen Ort umgezogen ist. Google verarbeitet diese Redirects und beginnt, die neuen URLs zu seiner Crawl-Warteschlange hinzuzufügen. Während dieser Phase siehst du eine Mischung aus alten und neuen URLs in den Suchergebnissen, was normal ist.
In den Wochen zwei bis vier intensiviert Google das Crawling der neuen URLs. Hast du eine neue Sitemap mit der neuen URL-Struktur eingereicht und die neue Domain in der Google Search Console verifiziert, beschleunigt Google seine Erkundung der neuen Site. Du solltest sehen, wie sich das Verhältnis von alten zu neuen URLs im Index zu neuen URLs verschiebt. Manche alten URLs erscheinen noch in Suchergebnissen, da Google noch nicht alle Redirects gecrawlt und verarbeitet hat.
In den Wochen vier bis acht sollte der Großteil des Übergangs abgeschlossen sein. Die meisten alten URLs sollten ordentlich weiterleiten, die meisten neuen URLs indexiert sein und die Rankings sollten sich auf oder nahe am Vor-Migrations-Niveau stabilisieren. Sind die Rankings deutlich niedriger als zuvor, kann es Redirect-Probleme, Inhalts-Änderungen oder technische Probleme auf der neuen Site geben, die Qualitätssignale beeinflussen.
In den Wochen acht bis zwölf festigt sich Googles Vertrauen in die neue Site. Alle verbleibenden alten URLs, die noch indexiert sind, sollten verarbeitet werden. Die Rankings sollten sich auf das Vor-Migrations-Niveau erholen, vorausgesetzt die Migration wurde korrekt ausgeführt. Sind bestimmte Seiten zu diesem Zeitpunkt immer noch nicht indexiert, haben sie individuelle Probleme, die gezieltes Troubleshooting brauchen.
Während dieses gesamten 90-Tage-Fensters vermeide weitere größere Änderungen an deiner Site. Gestalte die neue Site nicht neu, strukturiere URLs nicht erneut um und ändere keine Inhalte erheblich. Jede zusätzliche Änderung setzt Teile von Googles Bewertungs-Prozess zurück und verlängert die Recovery-Zeitachse. Behandle die 90 Tage nach der Migration als Stabilisierungs-Phase, in der deine einzigen Änderungen Fixes für migrations-bezogene Probleme sein sollten.
301-Redirect-Ketten, -Schleifen und Mapping-Lücken
Die Redirect-Implementierung ist der wichtigste Faktor bei der Post-Migrations-Indexierung. Jede alte URL, die Rankings, Traffic oder Backlinks hatte, muss zur relevantesten Seite auf der neuen Site weiterleiten. Fehler in der Redirect-Implementierung sind verantwortlich für die Mehrheit der Post-Migrations-Indexierungs-Fehler.
Redirect-Ketten treten auf, wenn ein Redirect auf einen anderen Redirect zeigt, der wiederum auf einen anderen zeigt. Zum Beispiel leitet http://old-domain.com zu https://old-domain.com weiter, das zu https://new-domain.com/page weiterleitet. Google kann Redirect-Ketten folgen, aber jeder Hop in der Kette führt Latenz ein und kann etwas Link-Equity verlieren. Google hat gesagt, dass es vollen PageRank durch einen einzelnen 301-Redirect überträgt, war aber weniger klar bei Ketten. Best Practice ist, Ketten auf maximal zwei Hops zu minimieren und idealerweise direkte Ein-Hop-Redirects von jeder alten URL zu ihrem finalen Ziel zu implementieren.
Redirect-Schleifen treten auf, wenn URL A zu URL B weiterleitet und URL B zurück zu URL A. Das verhindert, dass Google jemals eine finale Ziel-Seite erreicht, und resultiert in einem Crawl-Fehler. Schleifen treten häufig auf, wenn HTTP zu HTTPS weiterleitet und die HTTPS-Version auch eine Redirect-Regel hat, die bestimmte Pfade zurück zu HTTP sendet, oder wenn www- und non-www-Redirects miteinander in Konflikt geraten. Teste die Redirect-Implementierung mit einem Redirect-Ketten-Checker-Tool, das dem vollen Redirect-Pfad für jede URL folgt.
Mapping-Lücken sind alte URLs, die keinen Redirect zu einer neuen URL haben. Wenn Google eine alte URL crawlt und einen 404-Fehler statt eines Redirects empfängt, entfernt es diese URL aus dem Index. Existiert die äquivalente Seite auf der neuen Site, wurde aber nicht im Redirect-Plan gemappt, hat Google keine Möglichkeit, die Autorität der alten Seite mit der neuen Seite zu verbinden. Die neue Seite muss die Indexierung von Grund auf neu verdienen und verliert alle angesammelten Ranking-Signale.
Um Mapping-Lücken zu identifizieren, vergleiche deine vollständige Liste alter indexierter URLs (Export aus Google Search Console vor der Migration oder aus einem Vor-Migrations-Crawl) gegen deine Redirect-Mapping-Datei. Jede alte URL ohne entsprechenden Redirect ist eine Lücke. Für alte URLs, die keine direkte Entsprechung auf der neuen Site haben, leite sie zur relevantesten Eltern-Seite oder Kategorie um, statt sie 404 werden zu lassen. Ein Redirect zu einer einigermaßen relevanten Seite ist aus Link-Equity-Perspektive immer besser als ein 404.
Nach der Migration überwache die Google Search Console auf Crawl-Fehler bei alten URLs. Ein Spike bei 404-Fehlern auf alten URL-Mustern deutet auf fehlende Redirects hin. Prüfe die 404-Fehlerliste regelmäßig während der ersten 90 Tage und füge Redirects für hoch-Traffic- oder hoch-autoritative alte URLs hinzu, die Fehler zurückgeben.
Google-Search-Console-Verifizierung und Sitemap-Management
Die richtige Google-Search-Console-Konfiguration ist kritisch für die Post-Migrations-Indexierung. Umfasst deine Migration eine Domain-Änderung, URL-Struktur-Änderung oder Protokoll-Änderung, braucht dein Search-Console-Setup spezifische Updates, um Google zu helfen, den Übergang korrekt zu verarbeiten.
Für Domain-Migrationen (old-domain.com zu new-domain.com) brauchst du sowohl die alte als auch die neue Domain in der Google Search Console verifiziert. Entferne nicht die alte Domain-Property. Du brauchst sie, um zu überwachen, wie Google den Übergang von alten URLs verarbeitet, und um das Adressänderungs-Tool zu nutzen. Navigiere in der Search-Console-Property der alten Domain zu Einstellungen und nutze das Adressänderungs-Feature, um Google formal zu benachrichtigen, dass die Site zur neuen Domain umgezogen ist. Das beschleunigt Googles Verarbeitung der Domain-Änderung und hilft, Ranking-Signale während des Übergangs zu erhalten.
Verifiziere die neue Domain sofort nach der Migration als Domain-Property in der Search Console. Reiche eine neue XML-Sitemap mit allen neuen URLs ein. Die neue Sitemap sollte nur die neue URL-Struktur listen. Schließe keine alten URLs in die neue Sitemap ein. Ist deine alte Sitemap noch auf der alten Domain zugänglich, lass sie vorübergehend an Ort und Stelle. Google crawlt die alte Sitemap, trifft auf Redirects für jede URL und folgt ihnen zu den neuen URLs, was bei der Entdeckung hilft.
Für URL-Struktur-Änderungen auf derselben Domain (zum Beispiel das Ändern von /blog/post-title zu /articles/post-title), reiche eine aktualisierte Sitemap mit den neuen URL-Mustern ein. Nutze das URL-Prüftool, um ein erneutes Crawlen deiner wichtigsten neuen URLs anzufordern. Google sollte die URL-Änderungen durch Redirects während normalen Crawls entdecken, aber Sitemap-Einreichung beschleunigt den Prozess.
Für HTTP-zu-HTTPS-Migrationen füge die HTTPS-Version deiner Domain in der Search Console hinzu und verifiziere sie, falls noch nicht geschehen. Reiche eine neue Sitemap mit HTTPS-URLs ein. Google verarbeitet HTTPS-Migrationen generell glatt, aber überwache die Indexierung von HTTPS-URLs in den folgenden Wochen, um sicherzustellen, dass sie HTTP-URLs im Index ersetzen.
Ein häufiger Fehler ist das Einreichen einer Sitemap mit alten URLs von der neuen Site. Auditiere nach der Migration deine Sitemap, um sicherzustellen, dass jede URL, die sie enthält, eine gültige, nicht weiterleitende URL auf der neuen Site ist. Eine Sitemap, die alte URLs oder weiterleitende URLs referenziert, sendet gemischte Signale an Google und kann die Indexierung deiner neuen URL-Struktur verzögern.
Inhalts- und Template-Änderungen, die die Post-Migrations-Indexierung beeinflussen
Viele Site-Migrationen umfassen mehr als nur eine URL-Änderung. Sie fallen oft mit einem Redesign, CMS-Wechsel, Inhalts-Umstrukturierung oder Template-Update zusammen. Diese inhalts-level Änderungen können unabhängig Indexierungs-Probleme verursachen, die die URL-Migrations-Herausforderungen verstärken.
Wenn ein CMS-Wechsel ändert, wie Seiten gerendert werden, kann er JavaScript-Rendering-Probleme einführen, die zuvor nicht existierten. Hast du von einem serverseitig gerenderten CMS wie WordPress zu einem JavaScript-Framework wie React oder Vue migriert, können Seiten, die zuvor serverseitig gerendert waren, jetzt clientseitig gerendert sein. Google muss jetzt warten, bis seine JavaScript-Rendering-Warteschlange Seiten verarbeitet, die er zuvor aus dem initialen HTML indexieren konnte. Das allein kann die Indexierungs-Zeitachse für jede Seite um Tage verlängern.
Template-Änderungen können die interne Verlinkungs-Struktur deiner Site verändern. Ein neues Design mit anderer Navigation, anderen Sidebar-Widgets, anderen Footer-Links oder anderen Bereichen mit verwandtem Inhalt ändert, welche Seiten welche anderen Seiten verlinken. Wurden wichtige interne Links während des Redesigns entfernt, können manche Seiten auf der neuen Site verwaisen, selbst wenn sie auf der alten Site starke interne Verlinkung hatten. Crawle deine neue Site und vergleiche den internen Link-Graph mit der alten Site, um Seiten zu identifizieren, die interne Link-Unterstützung verloren haben.
Inhalts-Änderungen während der Migration, selbst gut gemeinte, können die Indexierung beeinflussen. Hast du Seitentitel umgeschrieben, Seiten kombiniert oder gespalten, Inhalts-Bereiche hinzugefügt oder entfernt oder Überschriften-Strukturen geändert, bewertet Google diese als neuen Inhalt, statt sie als aktualisierte Versionen alten Inhalts zu erkennen. Erhebliche Inhalts-Änderungen können dazu führen, dass Google die Qualität der Seite von Grund auf neu bewertet, statt die Autorität der alten Seite durch den Redirect zu übertragen.
Der sicherste Migrations-Ansatz trennt die URL-Migration von der Inhalts-/Design-Migration. Migriere zuerst die URLs und Redirects, ohne Inhalt oder Templates zu ändern. Lass Google die URL-Änderung verarbeiten und die Indexierung über vier bis sechs Wochen stabilisieren. Nimm dann schrittweise Design- und Inhalts-Änderungen vor. Dieser gestaffelte Ansatz macht es einfach, Probleme zu diagnostizieren, weil du genau weißt, welche Änderung welche Wirkung verursacht hat. Alles auf einmal zu tun, macht Troubleshooting nahezu unmöglich, weil URL-Probleme, Inhalts-Probleme und technische Probleme alle ineinander verflochten sind.
Schritt-für-Schritt-Anleitung
Verifiziere die Redirect-Implementierung für alle alten URLs
Exportiere die vollständige Liste indexierter URLs deiner alten Site (aus einem Vor-Migrations-Crawl oder Search-Console-Export). Teste jeden Redirect mit einem Bulk-Redirect-Checker-Tool. Verifiziere, dass jede alte URL mit einem 301 (nicht 302) zur korrekten neuen URL weiterleitet. Identifiziere und behebe Redirect-Ketten (mehr als ein Hop), Redirect-Schleifen (zirkuläre Redirects) und Mapping-Lücken (alte URLs, die 404 zurückgeben). Priorisiere die Behebung von Redirects für Seiten mit dem meisten Traffic, den meisten Backlinks und den stärksten Rankings. Jeder fehlende oder kaputte Redirect ist ein verlorenes Ranking-Signal.
Richte die Google Search Console für die neue Site ein
Verifiziere die neue Domain oder URL-Struktur in der Google Search Console als Domain-Property. Behalte die alte Domain-Property aktiv. Migrierst du Domains, nutze das Adressänderungs-Tool in der Search-Console-Property der alten Domain, um Google vom Umzug zu benachrichtigen. Reiche eine neue XML-Sitemap an die neue Property ein, die nur die neue URL-Struktur enthält. Verifiziere, dass die Sitemap innerhalb von 48 Stunden nach Einreichung erfolgreich von Google gelesen wurde. Prüfe auf Sicherheitsprobleme oder manuelle Maßnahmen auf der neuen Property, die die Indexierung blockieren könnten.
Auditiere die neue Sitemap auf Genauigkeit
Lade deine neue Sitemap herunter und verifiziere jede URL darin. Jede URL sollte einen 200-Statuscode zurückgeben, nicht zu einer anderen URL weiterleiten und keinen noindex-Tag tragen. Gleiche die Sitemap mit deiner vollständigen Liste der Seiten auf der neuen Site ab, um sicherzustellen, dass keine Seiten fehlen. Entferne aus der Sitemap alle URLs, die weiterleiten oder Fehler zurückgeben. Generiert dein CMS die Sitemap automatisch, verifiziere, dass es für die neue URL-Struktur konfiguriert wurde und nicht weiterhin alte URL-Muster generiert. Reiche die bereinigte Sitemap an die Google Search Console ein.
Prüfe auf technische Blocker auf der neuen Site
Verifiziere, dass die robots.txt der neuen Site das Crawlen aller wichtigen Seiten erlaubt. Prüfe, dass keine globalen noindex-Tags aus der Staging- oder Entwicklungs-Umgebung übrig geblieben sind. Viele CMS-Plattformen wenden noindex auf Staging-Umgebungen an, und diese Einstellung kann nach der Migration zur Produktions-URL persistieren. Teste das Rendering der neuen Site, indem du das URL-Prüftool auf fünf bis zehn Seiten in verschiedenen Bereichen nutzt. Verifiziere, dass Seiteninhalt korrekt rendert und keine JavaScript- oder Ressourcen-Lade-Fehler verhindern, dass Google den Inhalt sieht. Prüfe die SSL-Zertifikats-Gültigkeit, wenn du zu HTTPS migrierst.
Überwache den Indexierungs-Übergang in der Search Console
Beginnend sofort nach der Migration überwache den Seiten-Bericht in der Google Search Console für sowohl die alte als auch die neue Property täglich für die ersten zwei Wochen, dann wöchentlich für die folgenden zehn Wochen. Verfolge die Anzahl indexierter Seiten auf der neuen Property (sollte steigen), die Anzahl indexierter Seiten auf der alten Property (sollte sinken), die Anzahl der Crawl-Fehler auf beiden Properties und alle neuen „nicht indexiert“-Gründe, die erscheinen. Erstelle eine Tabelle, die diese Metriken über die Zeit verfolgt, sodass du Trends und Stillstände im Übergangs-Prozess identifizieren kannst.
Fordere Indexierung für hochpriorisierte neue URLs an
Identifiziere deine Top-50 bis 100 wichtigsten Seiten (meister Traffic, höchster Umsatz, meiste Backlinks) und verifiziere, dass sie auf den neuen URLs indexiert sind. Für solche, die noch nicht indexiert sind, nutze das URL-Prüftool, um die Indexierung einzeln anzufordern. Für größere Sites mit Hunderten oder Tausenden wichtiger Seiten nutze IndexBolt, um neue URLs in Massen für schnellere Indexierung einzureichen. Priorisiere Seiten, die vor der Migration starke Rankings hatten, da das die Seiten sind, bei denen verzögerte Indexierung die höchste geschäftliche Auswirkung hat.
Untersuche und behebe persistente Indexierungs-Lücken nach 30 Tagen
Nach 30 Tagen hat jede Seite, die noch nicht auf der neuen URL indexiert ist, wahrscheinlich ein spezifisches Problem über den normalen Migrations-Übergang hinaus. Prüfe für jede nicht indexierte Seite: Funktioniert der Redirect von der alten URL korrekt? Gibt die neue URL einen 200-Statuscode zurück? Ist der Inhalt auf der neuen URL erheblich derselbe wie der auf der alten URL? Gibt es neue Canonical-, noindex- oder Rendering-Probleme auf der neuen URL? Erhält die Seite interne Links von anderen indexierten Seiten auf der neuen Site? Behebe jedes Problem einzeln und reiche zur Indexierung erneut ein. Seiten, die nach 60 Tagen ohne identifizierbare technische Probleme noch nicht indexiert sind, brauchen möglicherweise Inhalts-Verbesserung, um aktuelle Qualitäts-Schwellen zu erfüllen.
Häufige Probleme und wie du sie behebst
Alte URLs erscheinen Monate nach der Migration noch in Suchergebnissen
Ursache: Google hat die Redirects für diese URLs noch nicht gecrawlt und verarbeitet. Das ist häufig bei alten URLs, die vor der Migration selten gecrawlt wurden, oder bei Sites mit sehr großer URL-Anzahl. Es kann auch darauf hindeuten, dass die Redirects 302 (temporär) statt 301 (permanent) zurückgeben, was Google dazu veranlasst, die alte URL im Index zu behalten, während es den Redirect als temporär behandelt.
Lösung: Verifiziere, dass Redirects 301 (permanent) statt 302 (temporär) sind. Nutze das URL-Prüftool in der Search-Console-Property der alten Domain, um ein erneutes Crawlen persistenter alter URLs anzufordern, was Google zwingt, auf den Redirect zu treffen und ihn zu verarbeiten. Nutzt du das Adressänderungs-Tool, verifiziere, dass es korrekt konfiguriert ist. Für große Sites nutze IndexBolt, um die neuen URLs direkt einzureichen, was die neuen Seiten parallel zur Redirect-Verarbeitung dem Index hinzufügt.
Neue URLs zeigen nach der Migration als „Gecrawlt – zurzeit nicht indexiert“
Ursache: Google hat die neuen URLs gecrawlt, aber festgestellt, dass sie die Qualitäts-Schwelle für die Indexierung nicht erfüllen. Das kann passieren, wenn die Migration erhebliche Inhalts-Änderungen umfasste, wenn das neue Template weniger Inhalt als das alte bietet (zum Beispiel durch Entfernen von Sidebar-Inhalt oder Bereichen mit verwandten Beiträgen), oder wenn Googles Qualitäts-Bewertung der neuen Site niedriger ist als die der alten Site aufgrund technischer Probleme wie langsamer Seiten-Geschwindigkeit oder Rendering-Problemen.
Lösung: Vergleiche den Inhalt auf der neuen URL mit der gecachten Version der alten URL. Identifiziere, welcher Inhalt entfernt oder geändert wurde. Stelle einzigartigen Inhalt wieder her, der während der Migration entfernt wurde. Prüfe Seitengeschwindigkeit und Core Web Vitals auf der neuen Site, da signifikante Performance-Verschlechterung Qualitätssignale beeinflussen kann. Verifiziere, dass interne Verlinkung von der Navigation der neuen Site diese Seiten erreicht. Ist der Inhalt äquivalent, reiche die URLs über IndexBolt ein, um Google zu einer Neubewertung zu drängen.
Massiver Spike bei 404-Fehlern in der Search Console nach der Migration
Ursache: Alte URLs, die Google zuvor crawlte, geben jetzt 404 zurück, weil keine Redirects für sie implementiert wurden. Das passiert häufig, wenn das Redirect-Mapping unvollständig war und nur die wichtigsten Seiten statt aller alten URLs abdeckte. Es passiert auch, wenn der alte Server oder das alte Hosting offline genommen wird, bevor Google die Migration vollständig verarbeitet hat.
Lösung: Auditiere die 404-Fehlerliste in der Search Console für die alte Domain-Property. Priorisiere die Implementierung von Redirects für 404-URLs, die erheblichen Traffic, Backlinks oder Rankings hatten (gegen deine Vor-Migrations-Daten prüfen). Für URLs ohne Traffic oder Backlinks ist ein 404 akzeptabel, da Google sie natürlich aus dem Index entfernt. Halte das Hosting und die Redirect-Konfiguration der alten Domain mindestens sechs Monate nach der Migration aktiv, um sicherzustellen, dass Google Zeit hat, alle Redirects zu verarbeiten. Schalte das Hosting der alten Domain nicht vorzeitig ab.
Rankings sind nach der Migration erheblich gesunken und erholen sich nicht
Ursache: Obwohl nicht streng ein Indexierungs-Problem, begleiten Ranking-Rückgänge während der Migration oft Indexierungs-Probleme. Häufige Ursachen sind Redirect-Ketten, die Link-Equity verdünnen, fehlende Redirects für Seiten mit Backlinks, erhebliche Inhalts-Änderungen, die Google weniger günstig bewertet, langsamere Seitengeschwindigkeit auf der neuen Site, Mobile-Usability-Probleme auf dem neuen Design und Verlust strukturierter Daten oder Rich Results, die Klickraten auf der alten Site trieben.
Lösung: Führe einen umfassenden Vergleich zwischen alter und neuer Site durch. Prüfe die Redirect-Ketten-Tiefe und behebe Ketten länger als ein Hop. Verifiziere, dass alle Seiten mit Backlinks direkte Redirects haben. Vergleiche Core Web Vitals zwischen alter und neuer Site. Vergleiche die Implementierung strukturierter Daten. Vergleiche Mobile Usability. Behebe jedes Defizit. Ist die neue Site technisch solide und inhaltlich äquivalent, erholen sich Rankings typischerweise innerhalb von 60 bis 90 Tagen, während Googles Vertrauen in die neue Site sich aufbaut. Persistente Ranking-Rückgänge über 90 Tage hinaus deuten auf einen substanziellen Qualitäts-Unterschied hin, der untersucht werden muss.
Seiten gleichzeitig auf alten und neuen URLs indexiert
Ursache: Google ist im Übergangs-Prozess, hat aber den Redirect für diese Seiten noch nicht vollständig verarbeitet. Das führt dazu, dass derselbe Inhalt auf zwei URLs im Index erscheint, was Ranking-Verwirrung und Traffic-Aufteilung zwischen alten und neuen URLs verursachen kann. Es löst sich typischerweise innerhalb von vier bis sechs Wochen natürlich auf, kann aber bestehen bleiben, wenn Redirects als 302 statt 301 implementiert sind.
Lösung: Verifiziere, dass alle Redirects 301 (permanent) sind. Nutzt du 302-Redirects, ändere sie sofort auf 301. Nutze das URL-Prüftool, um sowohl die alte als auch die neue URL zu prüfen. Zeigt die alte URL als indexiert mit einem Redirect, verarbeitet Google sie, hat den Übergang aber noch nicht abgeschlossen. Das ist während der ersten Wochen normal. Bleibt es über sechs Wochen bestehen, fordere ein erneutes Crawlen der alten URL an, um Google zu zwingen, den Redirect zu verarbeiten. Stelle sicher, dass Canonical-Tags auf neuen URLs selbstreferenzierend sind (auf sich selbst zeigen) und nicht auf alte URLs.
Profi-Tipps
Lass eine Site-Migration nicht Monate an SEO-Fortschritt auslöschen. IndexBolt reicht deine neuen URLs direkt bei Google ein, beschleunigt den Übergang von alt zu neu und minimiert die Indexierungs-Lücke. Reiche deine vollständige Liste neuer URLs sofort nach der Migration ein und lass deine neuen Seiten in Stunden statt Wochen indexieren, statt darauf zu warten, dass Google jeden Redirect verarbeitet.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Wie lange sollte eine vollständige Site-Migration aus Googles Sicht dauern?+
Die meisten Site-Migrationen sind innerhalb von 60 bis 90 Tagen von Google vollständig verarbeitet. Während der ersten zwei Wochen siehst du eine Mischung aus alten und neuen URLs im Index. Bei Woche vier sollten die meisten neuen URLs indexiert sein und die meisten alten URLs weiterleiten. Bei Woche acht sollte der Übergang erheblich abgeschlossen sein, mit nur Randfällen übrig. Sehr große Sites (Millionen Seiten) können länger brauchen, weil Googles Crawl-Kapazität endlich ist. Hat deine Migration sich nicht innerhalb von 90 Tagen erheblich abgeschlossen, gibt es wahrscheinlich technische Probleme (kaputte Redirects, blockiertes Crawling oder Rendering-Probleme), die untersucht werden müssen.
Sollte ich 301- oder 302-Redirects für eine Site-Migration nutzen?+
Immer 301-Redirects (permanent) für Site-Migrationen nutzen. 301-Redirects sagen Google, dass der Umzug permanent ist, was Google dazu veranlasst, Ranking-Signale zur neuen URL zu übertragen und schließlich die alte URL aus dem Index zu entfernen. 302-Redirects (temporär) sagen Google, dass der Umzug rückgängig gemacht werden könnte, was Google dazu veranlasst, die alte URL im Index zu behalten und die Autorität nicht vollständig zu übertragen. Während Google gesagt hat, dass es lang bestehende 302s schließlich ähnlich wie 301s behandelt, vermeidet die Nutzung von 301 von Anfang an Verzögerungen und Mehrdeutigkeit. Der einzige Grund, 302 zu nutzen, ist, wenn der Redirect wirklich temporär ist und du planst, die alte URL wiederherzustellen.
Ich migriere von HTTP zu HTTPS. Muss ich trotzdem all diese Schritte machen?+
Ja, obwohl HTTP-zu-HTTPS-Migrationen der einfachste Typ sind und Google sie am reibungslosesten handhabt. Du musst trotzdem 301-Redirects von allen HTTP-URLs zu ihren HTTPS-Äquivalenten implementieren, deine Sitemap auf HTTPS-URLs aktualisieren, die HTTPS-Property in der Google Search Console verifizieren und Canonical-Tags auf HTTPS aktualisieren. Der Hauptvorteil einer HTTPS-Migration ist, dass Google sie aktiv fördert, sodass die Verarbeitung tendenziell schneller ist. Die meisten HTTPS-Migrationen sind innerhalb von drei bis vier Wochen vollständig verarbeitet. Allerdings gelten dieselben Redirect-Mapping-, Sitemap- und Überwachungs-Anforderungen.
Was passiert mit meinen Backlinks, wenn ich zu einer neuen Domain migriere?+
Backlinks zu deiner alten Domain übertragen weiterhin Wert an deine neue Domain über 301-Redirects, aber es gibt einen gewissen Wert-Verlust im Prozess. Google hat bestätigt, dass 301-Redirects den Großteil des Link-Equity übertragen, aber der genaue Betrag wird nicht offengelegt. Manche SEO-Studien legen einen Verlust von 10-15 % pro Redirect-Hop nahe. Um die Backlink-Wert-Erhaltung zu maximieren, implementiere direkte Ein-Hop-301-Redirects von jeder alten URL zu ihrem neuen Äquivalent. Für deine wichtigsten Backlinks (von den autoritativsten Domains) erwäge, die verlinkende Site zu kontaktieren und sie zu bitten, den Link direkt auf deine neue URL zu aktualisieren und den Redirect komplett zu umgehen.
Kann ich meine Site in Phasen migrieren, einen Bereich nach dem anderen?+
Phasen-Migration ist möglich, fügt aber Komplexität hinzu. Eine Sektion nach der anderen zu migrieren (zum Beispiel zuerst /blog/, dann /products/, dann den Rest) bedeutet, dass Google mehrere Runden von Änderungen statt einer umfassenden Änderung verarbeiten muss. Der Vorteil ist, dass es den Blast-Radius eventueller Fehler begrenzt. Geht etwas mit der Blog-Migration schief, sind deine Produktseiten unberührt. Der Nachteil ist, dass die gesamte Migrations-Zeitachse länger ist und das Verwalten von Redirects komplexer wird, wenn manche Bereiche auf der neuen Struktur sind, während andere noch auf der alten sind. Für die meisten Sites ist eine einzige gut geplante Migration einem Phasen-Ansatz vorzuziehen.