Ein Website-Relaunch geht gut aus, wenn jede alte URL auf ihre neue Entsprechung führt, Google die neue Website ohne Sperren crawlen kann und jemand alte und neue Adressen über Wochen getrennt beobachtet. Google kündigt vorübergehende Schwankungen an. Bei einer mittelgroßen Website kann es einige Wochen oder länger dauern, bis die neuen URLs erscheinen. Diese Anleitung folgt dem Ablauf: Welche Art von Umzug hast du, was sagt Google, was sicherst du vorher, wie baust du die Weiterleitungen, und was prüfst du am Starttag und danach?
Fristen und Regeln stammen aus der Google-Dokumentation, abgerufen am 5. November 2026. Was unsere eigene Einschätzung ist, steht als solche dabei, und die Beispiele mit Daten sind erfunden.
Was sich je nach Relaunch ändert
Hinter „Relaunch“ oder „Migration“ stecken mehrere Vorhaben. Zuerst zählt die Frage, ob sich die URLs ändern, die Nutzer sehen. Davon hängt fast alles Weitere ab.
| Art der Änderung | Ändern sich URLs? | Tool zur Adressänderung | Wo es schiefgehen kann |
|---|---|---|---|
| Domainumzug | Ja | Ja, für alle bestätigten Varianten der alten Domain | Vergessene Varianten (www, Subdomains), Weiterleitungen auf URLs, die es nicht gibt |
| HTTP zu HTTPS | Ja | Nein, Google erkennt das selbst | robots.txt der HTTPS-Version, interne Links, die noch auf HTTP zeigen |
| Neue Struktur oder neue Pfade auf derselben Domain | Ja | Nein | Lückenhafte URL-Liste, Weiterleitungsketten |
| CMS-Wechsel | Je nachdem, ob sich Pfade ändern | Nein, außer die Domain wechselt auch | Vorlagen ohne Titel oder ohne Inhalt im HTML, Sperren aus der Testumgebung |
| Hosting- oder CDN-Wechsel bei gleichen URLs | Nein | Nein, dafür gibt es eine eigene Anleitung | Kapazität des neuen Servers, DNS, altes Hosting zu früh abgeschaltet |
Die letzte Spalte fasst die Fehler aus der Google-Anleitung und die Risiken der jeweiligen Änderung zusammen. Eine Statistik ist das nicht.
Stehen mehrere Änderungen an, rät Google, sie nacheinander zu machen: erst die Domain, dann das Layout. Je mehr du mischst, desto schwerer erkennst du, was einen Einbruch ausgelöst hat. Google warnt außerdem, dass ein Umzug zusammen mit neuen Inhalten und neuer Struktur wahrscheinlich Traffic kostet, weil Google die einzelnen Seiten neu bewerten muss.
Was Google selbst dazu sagt
Zum Relaunch kursiert viel Rat aus zweiter Hand. Die folgenden Aussagen helfen in jeder Projektrunde, weil sie die üblichen Streitfragen beantworten. Sie stammen aus Googles Anleitung zum Umzug mit URL-Änderungen, Stand 20. August 2026.
- Dauer: Bei mittelgroßen Websites kann es einige Wochen oder länger dauern, bis Google die neuen URLs zeigt, bei großen noch länger. Das Tempo hängt vor allem von der Zahl der URLs und der Geschwindigkeit des Servers ab.
- Wann der Umzug fertig ist: Googlebot muss jede URL der alten und der neuen Website mindestens einmal besuchen. Der Umzug läuft URL für URL, ein Stichtag für die ganze Website existiert nicht.
- Linkkraft: Laut Google führen 301 und andere dauerhafte Weiterleitungen nicht zu einem Verlust von PageRank.
- Wie lange Weiterleitungen bleiben: so lange wie möglich, in der Regel mindestens ein Jahr. Aus Nutzersicht könne man sie dauerhaft behalten.
- Art der Weiterleitung: dauerhaft und serverseitig, wenn technisch möglich, also etwa 301 oder 308. Clientseitige Lösungen sind der letzte Ausweg.
- Ketten: Googlebot folgt bis zu 10 Sprüngen, Google rät aber zum direkten Weg ans Ziel oder, falls das nicht geht, idealerweise zu höchstens 3.
- Startseite: Leite nicht viele alte URLs auf ein einziges unpassendes Ziel wie die Startseite. Das kann Nutzer verwirren und als Soft 404 gewertet werden.
- Alles auf einmal oder in Teilen: Kleine und mittlere Websites sollen laut Google alle URLs gleichzeitig umziehen. Große können in Abschnitten vorgehen, am besten zuerst mit einem Teil, der sich wenig ändert.
- Zeitpunkt: Hat dein Traffic saisonale oder wöchentliche Täler, dann in einem davon.
- Last: Nach dem Umzug crawlt Google die neue Website stärker als sonst, weil die Abrufe der alten URLs dazukommen. Der Server muss das aushalten.
Das Tool zur Adressänderung in der Search Console ist nur für den Wechsel von einer Domain oder Subdomain zu einer anderen gedacht, und erst, nachdem die Weiterleitungen aktiv sind. Für HTTP zu HTTPS, für www und ohne www auf derselben Domain und für neue Pfade innerhalb der Domain ist es nicht vorgesehen. Beim Domainwechsel verlangt Google die Anfrage für alle bestätigten Varianten der alten Domain, auch für ungenutzte. Weniger bekannt ist diese Warnung: Umzüge nicht verketten, also nicht von A nach B und direkt von B nach C, und möglichst nicht mehrere Websites auf einmal zusammenlegen.
Bevor du etwas änderst: die Bestandsaufnahme
Das Redirect-Mapping wird nur so gut wie die URL-Liste, aus der es entsteht. Beim einfachen Domainwechsel kann eine allgemeine Regel genügen. Sobald sich Pfade ändern, brauchst du die vollständige Liste. Google rät, mit den wichtigen URLs zu beginnen, und nennt diese Quellen. Die rechte Spalte ist unsere Ergänzung:
| Quelle | Was sie liefert | Was ihr entgeht |
|---|---|---|
| Sitemaps | Die URLs, die du als wichtig gemeldet hast | Alte Seiten, die noch Besuche bekommen, aber nicht mehr gemeldet sind |
| Server-Logs | Was wirklich abgerufen wurde, auch von Googlebot, samt Bildern | URLs ohne Abruf im gewählten Zeitraum. Der Zeitraum sollte deine Saison abdecken |
| Webanalyse | Die URLs mit dem meisten Traffic | Alles ohne Tag: abgelehnte Einwilligung, Dateien, Bots |
| Links in der Search Console | Seiten mit internen und externen Links | Links, die der Bericht nicht aufführt |
| CMS | Alles, was veröffentlicht ist | Alte URLs, die es nicht mehr gibt, die aber noch aufgerufen werden |
Google erinnert an etwas, das leicht untergeht: Bilder, Videos, PDFs, JavaScript und CSS haben ebenfalls URLs und müssen genauso umziehen. Ein Bild oder ein PDF kann selbst Traffic oder Links haben.
Was du heute sichern solltest
- Search Console exportieren, nach Seiten und Suchanfragen, für den längsten verfügbaren Zeitraum, bevor der Umzug beginnt. Das ist deine Vergleichsbasis. Der Leistungsbericht zeigt standardmäßig drei Monate, stell den Zeitraum also um.
- Titel, Beschreibungen und H1 jeder wichtigen URL sichern, damit du nach einem Einbruch siehst, was sich geändert hat.
- Strukturierte Daten und hreflang-Angaben sichern, falls vorhanden. Beim Vorlagenwechsel gehen sie leicht verloren.
- Festhalten, welche Seiten du nicht verlieren darfst: die, die verkaufen, die Links haben und die eine bestimmte Anfrage beantworten. Diese Liste ist dein Abschlusstest, wichtiger als jeder Gesamtwert.
- Die Liste der Websites sichern, die auf deine alten URLs verlinken. Google rät, sie aufzuheben und die Betreiber später um neue Links zu bitten, zuerst bei den Links mit den meisten Besuchen.
In dieser Phase entscheidest du auch, welche Inhalte nicht mitkommen. Was du löschst, soll laut Google 404 oder 410 liefern. Hast du Inhalte auf einer neuen Seite zusammengeführt, darfst du dorthin weiterleiten. Eine Seite mit Links oder eigenen Suchanfragen zu entfernen, ohne ihre Daten anzusehen, ist eine Entscheidung, die man leicht trifft, ohne es zu merken.
Das Redirect-Mapping
Hier entscheidet sich ein großer Teil des Ergebnisses. Google schreibt, dass es häufig Weiterleitungen auf falsche oder nicht vorhandene URLs sieht. Die Regel klingt einfach: Jede alte URL führt direkt auf ihre Entsprechung. Schwierig wird es, wenn es keine genaue Entsprechung gibt.
Wenn es keine Entsprechung gibt
Google zieht zwei klare Grenzen: nicht massenhaft auf ein unpassendes Ziel leiten, und 404 oder 410 für das, was wegfällt. Dazwischen nutzen wir diese Reihenfolge. Sie ist unsere Einschätzung, keine Google-Regel:
- Direkter Nachfolger. Dieselbe Seite oder das Modell, das sie ersetzt.
- Nächste Kategorie. Gibt es das Produkt oder den Artikel nicht mehr, die Unterkategorie, in der es stand, sofern Besucher dort etwas Gleichwertiges finden.
- Oberkategorie. Nur, wenn sie die Suche noch beantwortet.
- 410. Gibt es nichts anzubieten, sag das eindeutig.
Die Startseite gehört nicht auf diese Liste.
Warum Namensähnlichkeit täuscht
Bei Tausenden URLs ohne Entsprechung liegt es nahe zu automatisieren: die Wörter des alten Slugs mit den neuen vergleichen und den ähnlichsten nehmen. Für Vorschläge taugt das. Als Entscheidung scheitert es auf eine bestimmte Art. Ein erfundenes Beispiel aus einem Ersatzteil-Shop:
| Alte URL | Ähnlichster Kandidat | Problem |
|---|---|---|
/bremsbelaege-modell-x6-vorne | /schutzblech-vorne-modell-x6 | Modell und Position stimmen, das Teil ist ein anderes |
/reifen-8-zoll-schwarz | /reifen-10-zoll-schwarz | Fast gleich, aber eine andere Größe |
/ladegeraet-modell-2 | /ladegeraet-modell | Das „-2“ wegzuschneiden wirkt wie Aufräumen, hier gehört es zum Namen |
Modell und Position sind in beiden Slugs gleich, nur die Warenart unterscheidet sie. Ein Ähnlichkeitsmaß behandelt alles gleich. So nutzt du die Automatisierung, ohne dich täuschen zu lassen:
- Warenart-Konflikte ausschließen. Nennen beide URLs eine Warenart und passen die nicht zusammen, fällt der Kandidat weg, egal wie hoch der Wert ist.
- Größen-Konflikte ausschließen. Zwei verschiedene Maße sind zwei verschiedene Produkte.
- In drei Listen trennen: sicher, unsicher, ohne Kandidat. Unsicheres prüft ein Mensch, oder es bleibt bei 410.
- Das Ziel lesen. Status 200 heißt, dass die Seite lebt, nicht, dass sie die richtige ist. Slugs altern, während sich Produkte ändern. Vergleiche mit dem echten Seitentitel.
Welcher Statuscode
| Lage | Code | Was Google macht |
|---|---|---|
| Die Seite ist dauerhaft umgezogen | 301 oder 308 | Wertet es als Signal, dass das Ziel kanonisch sein soll, und zeigt das Ziel in den Ergebnissen |
| Vorübergehende Änderung | 302 oder 307 | Zeigt weiter die Ausgangs-URL in den Ergebnissen |
| Inhalt ohne Ersatz gelöscht | 404 oder 410 | Entfernt bereits indexierte URLs aus dem Index und crawlt nach und nach seltener |
| „Gibt es nicht“-Seite mit Status 200 | Vermeiden | Die Search Console kann sie als Soft 404 melden |
Eine versehentliche 302 beim Umzug führt dazu, dass Google weiter die alte URL zeigt. Prüfe also den Code und nicht nur, ob die Weiterleitung funktioniert. Gibt es Weiterleitungen aus einem früheren Relaunch, stell sie direkt auf das neue Ziel um, damit keine Kette entsteht.
Testumgebung und Abnahme
Vor dem Start prüfst du die neue Website so, wie Googlebot sie sieht. Google rät zu gründlichen Tests und nennt Details, die teure Fehler verhindern:
- Sperren aus der Testumgebung. Sperrst du das Crawling während der Entwicklung, bereite die endgültige robots.txt schon vor. Nutzt du noindex, führe eine Liste der URLs, bei denen es wegmuss. Das Vergessen dieser Sperren nennt Google unter den typischen Fehlern.
- noindex und robots.txt zusammen wirken nicht. Damit Google ein noindex sieht, darf die Seite nicht per robots.txt gesperrt sein. Ist sie gesperrt, kann sie trotzdem in den Ergebnissen erscheinen.
- Canonical. Jede neue URL braucht ein Canonical auf sich selbst. Ein möglicher Vorlagenfehler: Es zeigt noch auf die Testumgebung oder die alte Domain.
- hreflang. Bei mehreren Sprachen müssen die Angaben auf die neuen URLs zeigen. Jede Fassung nennt sich selbst und alle anderen. Verweisen zwei Seiten nicht aufeinander, ignoriert Google die Tags.
- Interne Links. Stelle sie mit demselben Mapping auf die neue URL um. Eine funktionierende Weiterleitung ist kein Grund, von der eigenen Website aus auf sie zu verlinken.
- Inhalt im HTML. Hängt die neue Website an JavaScript, vergleiche, was der Server liefert und was nach dem Rendern dasteht. Die Einzelheiten stehen in unserem Beitrag zu JavaScript SEO.
- Search Console. Bestätige die Varianten der alten und der neuen Website und prüfe, ob die Bestätigung den Umzug übersteht. Gibt es eine Disavow-Datei, rät Google, sie auch für die neue Property hochzuladen.
- Frisch gekaufte Domain. Prüfe auf manuelle Maßnahmen und entfernte URLs des Vorbesitzers.
Das Mapping gegen echte Daten testen
Zehn Weiterleitungen von Hand zu prüfen, sagt über ein Mapping mit zehntausend Einträgen wenig. Sicherheit gibt ein Skript, das die ganze Liste alter URLs abläuft und je URL prüft:
- ob der erste Sprung den geplanten Code liefert,
- ob das Ziel mit einem Sprung erreicht wird,
- ob das Ziel 200 liefert,
- ob der Titel des Ziels der erwartete ist,
- ob das Ziel kein noindex trägt und sein Canonical auf sich selbst zeigt.
Status und Inhalt sind zwei verschiedene Tests: Eine Seite kann 200 liefern und leer sein oder eine Fehlermeldung zeigen. Teste außerdem Stichproben mit Parametern, mit und ohne Endschrägstrich und mit Großbuchstaben, falls die alte Website welche hatte. Läuft die Testumgebung auf einer anderen Domain, darf das Skript nur diese ersetzen.
Der Starttag
Wähle einen Zeitpunkt mit wenig Traffic, zu dem danach Leute verfügbar sind. Wir würden nicht direkt vor einem Wochenende starten, weil erste Fehler schnell sichtbar werden und jemand sie beheben können muss. Die Reihenfolge lehnt sich an Google an. Schritt 8 und die Spalte mit den Zuständigen sind unsere Ergänzung:
| Schritt | Was passiert | Wer prüft |
|---|---|---|
| 1 | Weiterleitungen auf dem Server aktivieren | Entwicklung |
| 2 | Sperren entfernen: endgültige robots.txt und noindex-Liste | SEO |
| 3 | Canonical und Robots-Meta in den wichtigsten Vorlagen prüfen | SEO |
| 4 | Skript gegen die ganze URL-Liste laufen lassen | SEO und Entwicklung |
| 5 | Wichtige URLs mit dem URL-Prüftool testen | SEO |
| 6 | Adressänderung einreichen, falls die Domain wechselt | Inhaber der Search-Console-Property |
| 7 | Neue Sitemap einreichen, alte griffbereit halten | SEO |
| 8 | Kauf, Formular und Tracking auf der neuen Website testen | Fachabteilung |
| 9 | Anzeigen und Profile auf die neue URL umstellen | Marketing |
| 10 | Server-Logs prüfen: Fehler und Besuche von Googlebot | Entwicklung |
Zur Sitemap sagt die Anleitung zweierlei: Die neue einreichen, weil das die Entdeckung beschleunigt, und die alte kannst du dann entfernen. Im Abschnitt zur Beobachtung schlägt sie vor, beide einzureichen, um zu sehen, wie die eine fällt und die andere steigt. Praktisch ist es, die alte einige Wochen als Messgerät zu nutzen. Warnungen dort, dass die URLs weiterleiten, sind laut Google normal.
Die ersten 30 Tage
Google rechnet mit Schwankungen. Schwierig ist, sie von einem Fehler zu unterscheiden. Die Grundregel: Sieh dir alte und neue URLs getrennt an. In der Summe kann ein Relaunch mit Problemen tagelang stabil wirken.
| Was du beobachtest | Was zu erwarten ist | Was ein Alarm ist |
|---|---|---|
| Indexierte Seiten je Sitemap | Die alte sinkt gegen null, die neue steigt | Die neue steigt auch nach mehreren Wochen nicht |
| Suchanfragen in der Search Console | Neue URLs bekommen nach und nach Impressionen und Klicks | Eine wichtige Anfrage verschwindet, ohne dass ihre neue URL sie übernimmt |
| Fehler „Nicht gefunden“ | Einzelne URLs, die niemand zugeordnet hat | Ungewöhnlich viele, ein Zeichen für falsche Weiterleitungen |
| Server-Logs | Mehr Crawling durch Googlebot als vorher | 5xx-Fehler: Google drosselt dann das Crawling |
| Traffic in der Webanalyse | Sinkt bei alt, steigt bei neu | Sinkt bei beiden zugleich |
| Seiten, die du nicht verlieren darfst | Sie erfüllen weiter ihre Aufgabe und verkaufen | Eine davon verschwindet oder verliert deutlich Klicks |
Die Fristen sind kein Versprechen. Google spricht von Wochen, bis bei kleinen und mittleren Websites die meisten Seiten umgezogen sind, genauer wird es nicht. Der Vergleich mit der Vorwoche am ersten Tag sagt deshalb wenig. Vergleiche mit demselben Zeitraum davor, trenne Marke und Nicht-Marke und denk an die Saison.
Der Fehler, nur zu messen, was die Search Console meldet
Ein Fehlerbericht zeigt nur, was Google schon versucht hat. Scheitert das Mapping bei URLs, die Google selten crawlt, kann es Wochen ohne Hinweis dauern. Lass das Skript also weiter die ganze Liste ablaufen, statt nur die gemeldeten URLs zu prüfen. Die Server-Logs zeigen zudem, wer die alten URLs noch aufruft. Sind es Menschen, kommen sie über Links oder Lesezeichen, und das ist neben Googles Empfehlung ein weiterer Grund, die Weiterleitungen zu behalten.
Wenn etwas schiefgeht
- Zuerst das Mechanische prüfen: noindex, robots.txt, Canonical und Weiterleitungsziele. Eine vergessene Sperre ist in Minuten behoben, und solange sie besteht, ist alles andere nebensächlich.
- Einzelne Seiten vergleichen mit der Sicherung: Titel, Inhalt, interne Links.
- Zurückrollen nur als letzter Ausweg. Bei einem schweren Fehler und noch verfügbarer alter Website kann ein frühes Zurückrollen weniger schaden als Reparieren im laufenden Betrieb. Das ist unsere Einschätzung. Sobald Google einen Teil verarbeitet hat, ist das Zurückrollen selbst wieder ein Umzug.
Sonderfälle
Shop-Wechsel
Hier ändern sich oft besonders viele URLs auf einmal, mit Filtern, Varianten und Produktbildern. Entscheide vor dem Mapping, was mit Artikeln ohne Bestand und mit ausgelaufenen Produkten passiert, und nutze dann die Reihenfolge von oben. Filter-URLs brauchen eine eigene Entscheidung: Waren sie indexiert und hatten Traffic, gehören sie ins Mapping. Teste vor dem Start den ganzen Kauf und auch die Bilder, denn sie haben eigene URLs.
Mehrsprachige Websites
Ordne jede Sprache getrennt zu und prüfe, ob die Übersetzung auf ihre übersetzte Entsprechung führt. Englisch landet leicht versehentlich auf Deutsch. hreflang-Angaben gelten gegenseitig, ein Fehler in einer Sprache kann die Verbindung zu den anderen kappen. Wird es zu aufwendig, alle Paare zu pflegen, verarbeitet Google laut eigener Aussage weiter die Paare, die aufeinander verweisen.
Wechsel auf ein JavaScript-Framework
Prüfe vor dem Start, ob Inhalte und wichtige Tags im HTML des Servers stehen. Dieser Umzug verbindet zwei Risiken, Googles Rat zu einer Änderung nach der anderen wiegt hier also besonders schwer. Die Diagnose steht in unserem Beitrag zu JavaScript SEO.
Hosting-Wechsel ohne URL-Änderung
Hier gibt es keine Weiterleitungen. Google nennt diese Schritte: Website kopieren und testen, prüfen, ob Googlebot die neue Infrastruktur erreicht, die TTL der DNS-Einträge senken, die DNS umstellen und das alte Hosting erst abschalten, wenn niemand es mehr nutzt, auch Googlebot nicht. Das zeigen dir seine Logs.
Wann du dir Hilfe holen solltest
Einen Wechsel von HTTP zu HTTPS auf einer kleinen Website schaffst du mit der Google-Anleitung. Ein zweiter Blick lohnt sich, wenn viele URLs keine direkte Entsprechung haben, wenn Domain und CMS zugleich wechseln, wenn das Geschäft am organischen Traffic hängt oder wenn niemand die Server-Logs auswerten kann. Dann prüfen wir den Plan in unserem Service für den SEO-Relaunch.
Häufige Fragen
Wie lange dauert es, bis Google einen Relaunch verarbeitet hat?
Eine genaue Zahl nennt Google nicht. Bei mittelgroßen Websites spricht es von einigen Wochen oder länger, bis die neuen URLs erscheinen, bei großen von mehr. Es hängt von der Zahl der URLs und der Servergeschwindigkeit ab. Fertig ist der Umzug, wenn Googlebot alle alten und neuen URLs mindestens einmal besucht hat.
Wie lange muss ich eine 301-Weiterleitung behalten?
Laut Google so lange wie möglich, in der Regel mindestens ein Jahr, damit es alle Signale übertragen kann. Für Nutzer könne man sie dauerhaft behalten. Weiterleitungen kosten Ladezeit, aktualisiere also deine eigenen Links und die externen Links mit den meisten Besuchen.
Verliere ich durch eine 301-Weiterleitung Linkkraft?
Google sagt, dass 301 und andere dauerhafte Weiterleitungen keinen Verlust von PageRank verursachen. Das garantiert aber keine Positionen. Änderst du zugleich Inhalte, Struktur oder interne Links, bewertet Google die Seiten möglicherweise neu, und ein Rückgang kommt dann von diesen Änderungen.
Kann ich alles auf die Startseite weiterleiten?
Davon rät Google ab. Viele URLs auf ein einziges unpassendes Ziel wie die Startseite zu leiten, kann Nutzer verwirren und als Soft 404 gelten. Hast du Inhalte wirklich auf einer anderen Seite zusammengeführt, kannst du dorthin leiten. Gibt es sie nicht mehr, liefere 404 oder 410.
Brauche ich bei HTTPS das Tool zur Adressänderung?
Nein. Google schreibt, das Tool sei für den Wechsel von Domain oder Subdomain gedacht und erkenne den Wechsel von HTTP zu HTTPS selbst. Auch für www und ohne www auf derselben Domain oder für neue Pfade ist es nicht vorgesehen. Die Weiterleitungen brauchst du in all diesen Fällen trotzdem.
Sollte ich in Phasen oder auf einmal umziehen?
Für kleine und mittlere Websites empfiehlt Google den Umzug auf einmal, weil seine Systeme ihn dann schneller erkennen. Große können abschnittsweise vorgehen, um Probleme leichter zu finden. Wenn möglich, beginne mit einem Abschnitt, der sich wenig ändert. Er zeigt aber nicht zuverlässig, was bei der ganzen Website passiert.
Quellen
Abgerufen am 5. November 2026. Wir verlinken die englische Fassung der Entwicklerdokumentation, weil die deutsche maschinell übersetzt ist.
- Google Search Central: Umzug mit URL-Änderungen (Stand 20.08.2026, englisch)
- Search-Console-Hilfe: Tool zur Adressänderung
- Google Search Central: Hosting-Wechsel ohne URL-Änderung (englisch)
- Google Search Central: Weiterleitungen und die Google-Suche (englisch)
- Google: HTTP-Statuscodes und Crawling (englisch)
- Google Search Central: noindex (englisch)
- Google Search Central: lokalisierte Versionen und hreflang (englisch)
- Search-Console-Hilfe: Leistungsbericht
Begriffe zum Weiterlesen: Redirect 301, 302-Weiterleitung, Weiterleitungskette, Soft 404, Canonical-Tag, hreflang, noindex und Logfile-Analyse.
Wie dieser Artikel entstanden ist
Die erste Fassung dieses Artikels stammt vom März 2026. Im November 2026 wurde er mit KI-Unterstützung vollständig neu geschrieben, anhand der oben verlinkten Google-Dokumentation, und vor der Veröffentlichung geprüft. Die Beispiele mit URLs sind erfunden, und was als eigene Einschätzung markiert ist, stammt nicht von Google.
