Website-Relaunch ohne Rankingverlust: Checkliste für KMUWebsite Relaunch Without Ranking Loss: SME Checklist
Ein Relaunch ist für Google ein Umzug: Mit sauberem URL-Mapping, 301-Weiterleitungen, geschütztem Staging und konsequenter Nachkontrolle vermeiden Sie vermeidbare Rankingverluste.To Google, a relaunch is a site move: clean URL mapping, 301 redirects, protected staging and disciplined follow-up checks help you avoid preventable ranking losses.
Ein Relaunch fühlt sich nach Neubeginn an: neues Design, neue Texte, vielleicht ein neues CMS. Für Google ist es aber ein Umzug. Jede Adresse, die bisher Besucher gebracht hat, muss erkennbar an ihrem neuen Platz ankommen. Passiert das nicht, verlieren Sie Sichtbarkeit, die sich über Jahre aufgebaut hat. Diese Checkliste folgt dem Ablauf, den Google in der Dokumentation zu Website-Umzügen beschreibt, und übersetzt ihn für Unternehmen mit überschaubarer Seitenzahl.
Was sich beim Relaunch wirklich ändert
Bevor Sie planen, klären Sie, welche Art von Umzug vorliegt. Ein neues Design auf denselben URLs ist ein kleines Risiko. Ein neues CMS mit anderer Pfadstruktur oder ein Wechsel der Domain ist ein großes. Google rät in der Dokumentation ausdrücklich, nur eine Sache auf einmal zu ändern, etwa Domain, CMS oder Layout, und größere Umzüge in verkehrsschwache Zeiten zu legen.
| Änderung | Risiko | Was Sie zusätzlich brauchen |
|---|---|---|
| Nur Design und Texte, URLs bleiben gleich | gering | Titel, Überschriften, interne Links und Tracking prüfen |
| Neues CMS, neue URL-Struktur | hoch | Vollständiges URL-Mapping und 301-Weiterleitungen |
| Wechsel von HTTP auf HTTPS | mittel | Weiterleitungen aller Varianten, aktualisierte Canonicals und Sitemap |
| Neue Domain | hoch | Weiterleitungen plus Umzug der Domain in der Search Console (Adressänderung) |
Wenn Sie Domain, CMS und Struktur gleichzeitig wechseln wollen, trennen Sie das in Etappen. Fällt der Traffic danach ab, wissen Sie sonst nicht, welche Änderung der Auslöser war.
Schritt 1: Bestandsaufnahme und URL-Mapping
Das Mapping ist eine Tabelle: links jede alte URL, rechts die neue URL, die denselben Zweck erfüllt. Google empfiehlt, die alten URLs aus der Sitemap, aus Server-Logs und aus der Analytics-Auswertung zusammenzutragen. So finden Sie auch Seiten, die in keinem Menü mehr auftauchen, aber noch Besucher oder Backlinks haben.
Ergänzen Sie die Liste um die Seiten, die in der Search Console die meisten Klicks und Impressionen haben, und um alle URLs mit externen Links. Letztere sind besonders wertvoll. Wer die Anleitung zur Einrichtung der Search Console noch nicht umgesetzt hat, sollte das vor dem Relaunch tun, damit Daten für den Vorher-nachher-Vergleich vorliegen.
Eine Beispielrechnung mit angenommenen Zahlen: Ihre alte Website hat 120 URLs. 70 davon haben ein direktes Gegenstück auf der neuen Seite, 25 werden zusammengelegt, 15 entfallen ersatzlos und 10 sind Parameter- oder Testseiten. Das Mapping sieht dann etwa so aus:
| Alte URL (Beispiel) | Neue URL (Beispiel) | Aktion |
|---|---|---|
| /leistungen/seo-beratung.html | /leistungen/seo | 301 auf direkte Entsprechung |
| /team-2019 | /team | 301 auf zusammengelegte Seite |
| /aktion-sommer-2021 | keine | 404 oder 410, kein Ersatz |
| /blog/artikel-123 | /blog/titel-des-artikels | 301, Inhalt unverändert übernommen |
Die Zeile mit dem 404 ist kein Versehen. Google schreibt, dass URLs, die es auf der neuen Seite nicht mehr gibt, einen korrekten 404- oder 410-Status liefern sollen. Eine Seite ohne Nachfolger gehört nicht auf die Startseite umgeleitet, nur damit die Fehlerliste kürzer aussieht. Besucher landen dort an einer Stelle, die ihre Frage nicht beantwortet.
Schritt 2: Staging absichern, bevor etwas durchsickert
Die neue Website entsteht auf einer Testumgebung. Damit diese nicht in der Google-Suche auftaucht, gibt es zwei saubere Wege: ein Passwortschutz oder ein noindex-Hinweis im HTML (<meta name="robots" content="noindex">) bzw. im HTTP-Header (X-Robots-Tag: noindex). Google beschreibt beides in der Dokumentation zum Blockieren der Indexierung.
Der verbreitete Irrtum betrifft die robots.txt. Sie steuert, was Crawler abrufen dürfen, und ist laut Google ausdrücklich kein Mittel, eine Seite aus der Suche herauszuhalten. Schlimmer noch: Damit ein noindex wirkt, darf die Seite nicht per robots.txt gesperrt sein, denn sonst sieht Googlebot die Anweisung nie. Auch ein Passwortschutz ist robuster als ein reiner noindex, weil er die Testversion für alle Unbefugten unzugänglich macht.
Der zweite Teil dieses Schritts ist die häufigste Panne beim Go-live: Der Schutz bleibt aktiv. Google rät, schon vor dem Start eine Liste der URLs anzulegen, bei denen die noindex-Regeln entfernt werden müssen. Setzen Sie diesen Punkt als eigene Zeile in die Go-live-Checkliste, mit Namen des Verantwortlichen.
Schritt 3: 301-Weiterleitungen richtig umsetzen
Für den Umzug empfiehlt Google serverseitige, permanente Weiterleitungen, also 301 oder 308. Sie signalisieren, dass das Ziel die kanonische Adresse sein soll. Temporäre Varianten wie 302 oder 307 sagen das Gegenteil: Google folgt dem Link, behält aber die alte URL als maßgebliche Adresse im Blick. Für einen dauerhaften Umzug ist das die falsche Aussage.
Drei Punkte entscheiden in der Praxis über die Qualität:
- Eine Weiterleitung pro alter URL, direkt aufs Ziel. Googlebot folgt zwar bis zu zehn Weiterleitungen in Folge. Die Dokumentation empfiehlt aber, Ketten kurz zu halten, ideal höchstens drei und weniger als fünf. Bei Ihrem Relaunch sollte keine einzige nötig sein.
- Keine JavaScript-Weiterleitungen. Google empfiehlt sie nur, wenn serverseitige Lösungen nicht möglich sind, weil das Rendering scheitern kann und die Weiterleitung dann unbemerkt bleibt.
- Laufzeit planen. Google empfiehlt, Weiterleitungen so lange wie möglich beizubehalten, generell mindestens ein Jahr. Aus Nutzersicht ist unbegrenzt sinnvoll, solange externe Links auf die alten Adressen zeigen.
Wie Sie die Regeln technisch anlegen, hängt vom System ab: in der .htaccess oder der Servereinrichtung, über ein Redirect-Plugin im CMS oder auf Hosting-Ebene. Entscheidend ist, dass Sie die Liste nach dem Einspielen vollständig testen, nicht nur Stichproben. Bei einigen hundert URLs lässt sich das mit einem Crawler oder einem einfachen Skript automatisiert prüfen.
Schritt 4: Sitemap, Search Console und interne Links
Auf der neuen Website gehört eine aktuelle XML-Sitemap ins Stammverzeichnis. Google nennt dafür klare Regeln: nur kanonische URLs aufnehmen, vollständige absolute Adressen verwenden, höchstens 50.000 URLs oder 50 MB unkomprimiert pro Datei und ein lastmod, das echten Änderungen entspricht. Reichen Sie die Sitemap in der Search Console ein, nachdem die Weiterleitungen aktiv sind. Die alte Sitemap kann danach entfallen.
Verifizieren Sie alte und neue Website in der Search Console, inklusive aller Varianten (mit und ohne www, HTTP und HTTPS). Nur bei einem Wechsel der Domain oder Subdomain gibt es die Adressänderung. Für HTTP auf HTTPS oder einen reinen CMS-Wechsel auf derselben Domain gibt es sie nicht.
Unterschätzt wird das Aufräumen im eigenen Haus. Interne Links sollen direkt auf die neuen URLs zeigen und nicht über Weiterleitungen laufen. Canonical-Tags und gegebenenfalls hreflang-Angaben müssen auf die neuen Adressen verweisen. Wenn die Seite Standortdaten ausgibt, prüfen Sie auch das LocalBusiness-Schema, denn dort stehen oft noch alte URLs. Externe Links aktualisieren Sie, wo es geht: bei Verzeichnissen, Partnern und im eigenen Profil. Beim Google Business Profile ist es zum Beispiel die Website-URL, die nachgezogen werden muss.
Go-live-Checkliste für den Starttag
Wenn die Vorbereitung steht, ist der Starttag überschaubar. Gehen Sie diese Liste in genau dieser Reihenfolge durch:
- Passwortschutz und noindex von der Testumgebung auf der Live-Seite entfernt, robots.txt auf Live-Stand geprüft.
- Alle Weiterleitungen aktiv und getestet, inklusive Varianten mit und ohne www sowie HTTP auf HTTPS.
- Gelöschte Seiten liefern 404 oder 410, keine Fehlerseiten mit Status 200 (Soft 404).
- Neue Sitemap eingereicht, Canonicals und interne Links zeigen auf die neuen URLs.
- Tracking läuft: Messung und Zielvorhaben funktionieren, siehe Conversion-Tracking mit GA4.
- Kontaktformular, Terminbuchung und Telefonnummer mit einer Testanfrage geprüft.
- Ladezeit auf Mobilgeräten stichprobenartig gemessen, mehr dazu im Beitrag zur Ladezeit-Verbesserung.
Das Soft-404-Thema ist kein Randfall. Google erklärt, dass eine Seite mit Status 200 und Fehlerinhalt in der Search Console als Soft 404 auftaucht, während ein echter 404 sauber aus dem Index verschwindet. Viele Baukästen und Themes liefern bei nicht gefundenen Seiten eine freundliche Seite mit Statuscode 200. Das lässt sich in wenigen Minuten testen und gehört in jede Abnahme.
Nachkontrolle: Was in den ersten Wochen zu tun ist
Nach dem Start beginnt die Phase, in der viele Relaunches aus dem Blick geraten. Dabei ist genau jetzt Aufmerksamkeit wichtig. Laut Google dauert es bei mittelgroßen Websites einige Wochen oder länger, bis die neuen URLs die alten in den Ergebnissen ersetzen. Vorübergehende Schwankungen im Ranking sind daher normal und kein Beweis für einen Fehler.
Prüfen Sie in dieser Zeit regelmäßig:
- Seitenindex-Bericht: Er zeigt, welche URLs indexiert sind und warum andere nicht, etwa „Seite mit Weiterleitung“, „Nicht gefunden (404)“ oder „durch noindex ausgeschlossen“. Die Zahl indexierter Seiten sollte schrittweise steigen.
- Leistungsbericht: Vergleichen Sie Klicks und Impressionen für Ihre wichtigsten Seiten und Suchbegriffe mit den Werten vor dem Start.
- Crawling-Fehler: Serverfehler, falsche Weiterleitungen oder blockierte Ressourcen sofort beheben.
- Backlinks und Verzeichnisse: Sobald Sie Partner erreichen, tauschen Sie Links gegen die neuen URLs.
Rechnen Sie nicht mit sofortiger Normalisierung, und greifen Sie bei kleinen Ausschlägen nicht hektisch ein. Sinnvoll ist ein fester Rhythmus: täglich in der ersten Woche, danach wöchentlich über etwa zwei Monate, wobei Sie nur dann eingreifen, wenn ein konkreter Fehler sichtbar ist. Wer das nicht intern leisten kann, bekommt es als laufende Betreuung, etwa über Care & Growth.
Wann das nicht passt oder nicht reicht
Eine Checkliste ersetzt keine Prüfung im Einzelfall. Drei Situationen verlangen mehr Aufwand, als dieser Beitrag leisten kann. Bei sehr großen Websites, etwa Shops mit tausenden Produkten, braucht es Regeln statt Einzellisten und eine Logfile-Auswertung. Bei mehrsprachigen Auftritten kommen hreflang-Verweise hinzu, die ebenfalls umziehen müssen. Und wenn die alte Website bereits eine Penalty, Spam oder einen Hackerangriff hinter sich hat, sollten Sie das zuerst klären, bevor Sie etwas umziehen.
Außerdem gilt: Kein Verfahren garantiert, dass Rankings exakt gleich bleiben. Auch ein sauberer Umzug kann sich auf Platzierungen auswirken, etwa weil neue Texte, neue Seitenstrukturen oder schnellere Ladezeiten Google ein anderes Bild geben. Ziel ist, vermeidbare Verluste auszuschließen. Was Sie über die Qualität des neuen Auftritts gewinnen, ist ein eigenes Thema.
Wie TRIUM mit dem Thema umgeht
Bei einem neuen Webauftritt nach der 369-Methode beginnt es mit einem Audit der bestehenden Seite, es folgt eine Demo vor der Umsetzung, und beim Launch wird die Seite ab der ersten Stunde beobachtet. Bei einem Relaunch ordnen wir die URL-Bestandsaufnahme dem Audit zu, die Weiterleitungen der Umsetzung und die Nachkontrolle dem Monitoring. Mehr zu unserem Vorgehen finden Sie unter Webdesign Wien. Wenn Sie erst einmal wissen möchten, wie Ihre aktuelle Seite dasteht, hilft der kostenlose Website-Check für KMU. Für einen geplanten Relaunch können Sie im kostenlosen Erstgespräch klären, welche Risiken in Ihrem Fall bestehen.
Häufige Fragen
Brauche ich 301-Weiterleitungen, wenn alle URLs gleich bleiben?
Nein, wenn sich wirklich keine Adresse ändert, sind keine nötig. Prüfen Sie das aber mit einem Crawl der alten und neuen Seite, denn kleine Änderungen wie ein Schrägstrich am Ende, Großbuchstaben oder eine Dateiendung zählen als andere URL.
Soll ich alle alten URLs auf die Startseite weiterleiten?
Nein. Leiten Sie jede Seite auf die inhaltlich passende neue Seite. Für Seiten ohne Nachfolger ist ein 404 oder 410 der korrekte Status, wie Google in der Dokumentation zu Website-Umzügen beschreibt.
Wie lange muss ich Weiterleitungen behalten?
Google empfiehlt, sie so lange wie möglich zu behalten, generell mindestens ein Jahr. Aus Nutzersicht ist es sinnvoll, sie unbegrenzt zu belassen, solange externe Links auf die alten Adressen zeigen.
Genügt es, die Testseite per robots.txt zu sperren?
Nein. Die robots.txt ist laut Google kein Mittel, Seiten aus der Suche herauszuhalten. Verwenden Sie Passwortschutz oder noindex, und beachten Sie, dass ein noindex nur wirkt, wenn die Seite nicht per robots.txt gesperrt ist.
Wann brauche ich die Adressänderung in der Search Console?
Nur bei einem Wechsel von Domain oder Subdomain. Für einen Wechsel von HTTP auf HTTPS oder einen CMS-Wechsel auf derselben Domain ist sie laut Google nicht vorgesehen.
Wie lange dauert es, bis sich Rankings nach dem Relaunch stabilisieren?
Google nennt für mittelgroße Websites einige Wochen oder länger, für große noch länger. Eine feste Garantie gibt es nicht, und Ihr Ergebnis hängt von Größe, Qualität der Umsetzung und Wettbewerb ab.
Hinweis: Dieser Beitrag ist allgemeine Information und keine Rechts- oder Einzelfallberatung. Er gibt den Stand der zitierten Google-Dokumentation wieder, die sich ändern kann.
Quellen
- Site move with URL changes, Google Search Central, Stand 20.08.2026
- Redirects and Google Search, Google Search Central, Stand 14.04.2026
- Block Search indexing with noindex, Google Search Central, Stand 10.12.2025
- Introduction to robots.txt, Google Search Central, Stand 10.12.2025
- Build and submit a sitemap, Google Search Central, abgerufen am 03.10.2026
- HTTP status codes, network and DNS errors, Google Search Central, Stand 04.02.2026
- Page indexing report, Google Search Console Hilfe, abgerufen am 03.10.2026
A relaunch feels like a fresh start: new design, new copy, maybe a new CMS. To Google it is a move. Every address that has brought visitors so far has to arrive recognisably at its new home. If that does not happen, you lose visibility that took years to build. This checklist follows the process Google describes in its documentation on site moves and translates it for businesses with a manageable number of pages.
What really changes in a relaunch
Before you plan anything, work out what kind of move you are dealing with. A new design on the same URLs is a small risk. A new CMS with a different path structure, or a change of domain, is a big one. Google advises changing only one thing at a time (domain, CMS or layout) and scheduling larger moves for quieter traffic periods.
| Change | Risk | What you additionally need |
|---|---|---|
| Design and copy only, URLs stay the same | low | Check titles, headings, internal links and tracking |
| New CMS, new URL structure | high | Complete URL mapping and 301 redirects |
| Switch from HTTP to HTTPS | medium | Redirects for all variants, updated canonicals and sitemap |
| New domain | high | Redirects plus the domain move in Search Console (Change of Address) |
If you want to change domain, CMS and structure all at once, split it into stages. Otherwise you will not know which change caused a drop.
Step 1: Inventory and URL mapping
The mapping is a table: every old URL on the left, the new URL that serves the same purpose on the right. Google recommends collecting the old URLs from your sitemap, server logs and analytics. That also turns up pages that are no longer in any menu but still have visitors or backlinks.
Add the pages with the most clicks and impressions in Search Console, and every URL that has external links. The latter are especially valuable. If you have not yet followed the guide to setting up Search Console, do it before the relaunch so you have data for a before-and-after comparison.
An example calculation with assumed numbers: your old website has 120 URLs. 70 have a direct counterpart on the new site, 25 are merged, 15 are dropped without replacement and 10 are parameter or test pages. The mapping then looks roughly like this:
| Old URL (example) | New URL (example) | Action |
|---|---|---|
| /services/seo-consulting.html | /services/seo | 301 to the direct equivalent |
| /team-2019 | /team | 301 to the merged page |
| /summer-offer-2021 | none | 404 or 410, no replacement |
| /blog/article-123 | /blog/article-title | 301, content carried over unchanged |
The row with the 404 is not an oversight. Google says URLs that no longer exist on the new site should return a proper 404 or 410 status. A page with no successor should not be redirected to the homepage just to make the error list shorter. Visitors end up somewhere that does not answer their question.
Step 2: Secure staging before anything leaks
The new site is built on a test environment. To keep it out of Google, there are two clean options: password protection, or a noindex instruction in the HTML (<meta name="robots" content="noindex">) or in the HTTP header (X-Robots-Tag: noindex). Google describes both in its documentation on blocking indexing.
The common misunderstanding concerns robots.txt. It controls what crawlers may fetch and, according to Google, is explicitly not a way to keep a page out of search. Worse, for noindex to work the page must not be blocked by robots.txt, because otherwise Googlebot never sees the instruction. Password protection is also sturdier than noindex alone.
The second half of this step covers the most frequent go-live mishap: the protection stays on. Google advises preparing a list of the URLs where noindex rules must be removed before the move starts. Give this its own line in the go-live checklist, with a named owner.
Step 3: Implement 301 redirects properly
For a move, Google recommends server-side permanent redirects, meaning 301 or 308. They signal that the target should be the canonical address. Temporary variants such as 302 or 307 say the opposite: Google follows the redirect but does not treat the target as the canonical one. For a permanent move, that is the wrong message.
Three points decide quality in practice:
- One redirect per old URL, straight to the target. Googlebot follows up to ten redirects in a row. The documentation nevertheless recommends keeping chains short, ideally no more than three and fewer than five. In your relaunch, none should be necessary.
- No JavaScript redirects. Google recommends them only if server-side options are not possible, because rendering can fail and the redirect then goes unnoticed.
- Plan the duration. Google recommends keeping redirects for as long as possible, generally at least one year. From a user's point of view, indefinitely makes sense as long as external links point to the old addresses.
You can create the rules in .htaccess, the server configuration, a CMS redirect plugin or at hosting level. What matters is that you test the full list after deploying it, not just samples. A crawler or a simple script automates this.
Step 4: Sitemap, Search Console and internal links
The new website needs a current XML sitemap in the root directory. Google sets clear rules: include only canonical URLs, use fully qualified absolute addresses, stay within 50,000 URLs or 50 MB uncompressed per file, and use a lastmod that reflects real changes. Submit the sitemap in Search Console once the redirects are active. The old sitemap can be dropped afterwards.
Verify both the old and the new site in Search Console, including all variants (with and without www, HTTP and HTTPS). The Change of Address tool exists only for a change of domain or subdomain. It does not apply to HTTP to HTTPS or to a plain CMS switch on the same domain.
Housekeeping on your own site is often underestimated. Internal links should point directly at the new URLs rather than running through redirects. Canonical tags and, where used, hreflang annotations must point to the new addresses. If the site outputs location data, check your LocalBusiness schema too, since it often still contains old URLs. Update external links where you can: in directories, with partners and in your own profile. In your Google Business Profile, for example, the website URL has to be updated.
Go-live checklist for launch day
If the preparation is done, launch day is manageable. Work through this list in exactly this order:
- Password protection and noindex removed from the live site, robots.txt checked against the live state.
- All redirects active and tested, including the variants with and without www and HTTP to HTTPS.
- Deleted pages return 404 or 410, not error pages with status 200 (soft 404).
- New sitemap submitted, canonicals and internal links point to the new URLs.
- Tracking works: measurement and goals are firing, see conversion tracking with GA4.
- Contact form, appointment booking and phone number verified with a test enquiry.
- Mobile load time spot-checked, more in the article on improving load time.
The soft 404 issue is not an edge case. Google explains that a page with status 200 and error content shows up in Search Console as a soft 404, whereas a real 404 drops cleanly out of the index. Many themes serve a friendly page with status 200 for URLs that are not found. Testing takes minutes and belongs in every acceptance check.
Follow-up: what to do in the first weeks
After launch comes the phase in which many relaunches fall out of view. Attention matters most right now. According to Google, it takes a few weeks or more for medium-sized sites before the new URLs replace the old ones in results. Temporary ranking fluctuations are therefore normal and not proof of a mistake.
During this time, check regularly:
- Page indexing report: It shows which URLs are indexed and why others are not, for example "Page with redirect", "Not found (404)" or "Excluded by noindex tag". The number of indexed pages should rise step by step.
- Performance report: Compare clicks and impressions for your most important pages and queries against the values from before launch.
- Crawl errors: Fix server errors, wrong redirects and blocked resources immediately.
- Backlinks and directories: As soon as you reach partners, swap links for the new URLs.
Do not react frantically to small swings. A fixed rhythm works well: daily in the first week, then weekly for about two months, intervening only when a concrete error is visible. If you cannot do this in-house, you can get it as ongoing support, for example through Care & Growth.
When this does not fit or is not enough
A checklist does not replace a case-by-case review. Three situations need more effort than this article can cover. Very large sites, such as shops with thousands of products, need rules instead of individual lists and a log file analysis. Multilingual sites add hreflang references, which have to move as well. And if the old website has already been through a penalty, spam or a hack, deal with that first before you move anything.
No method guarantees that rankings stay exactly the same. Even a clean move can affect positions, for instance because new copy or page structures give Google a different picture. The goal is to rule out avoidable losses.
How TRIUM handles this
For a new website built with the 369 method, the process starts with an audit of the existing site, followed by a demo before implementation, and after launch the site is monitored from the first hour. In a relaunch we assign the URL inventory to the audit, the redirects to implementation and the follow-up checks to monitoring. You will find more on our approach at web design in Vienna. If you first want to know where your current site stands, the free website check for small businesses helps. For a planned relaunch, you can use the free introductory call to clarify which risks apply in your case.
Frequently asked questions
Do I need 301 redirects if all URLs stay the same?
No, if truly no address changes, none are needed. Verify that with a crawl of the old and new site, though, because small changes such as a trailing slash, capital letters or a file extension count as a different URL.
Should I redirect all old URLs to the homepage?
No. Redirect each page to the new page that matches its content. For pages without a successor, a 404 or 410 is the correct status, as Google describes in its documentation on site moves.
How long do I need to keep redirects?
Google recommends keeping them as long as possible, generally at least one year. From a user's perspective it makes sense to leave them in place indefinitely as long as external links point to the old addresses.
Is blocking the test site in robots.txt enough?
No. According to Google, robots.txt is not a mechanism for keeping pages out of search. Use password protection or noindex, and note that noindex only works if the page is not blocked by robots.txt.
When do I need the Change of Address tool in Search Console?
Only when you change domain or subdomain. According to Google, it is not intended for a switch from HTTP to HTTPS or a CMS change on the same domain.
How long until rankings settle after a relaunch?
For medium-sized sites Google cites a few weeks or more, and longer for large ones. There is no firm guarantee, and your result depends on size, quality of execution and competition.
Note: This article is general information and not legal or case-specific advice. It reflects the state of the cited Google documentation, which may change.
Sources
- Site move with URL changes, Google Search Central, as of 20 Aug 2026
- Redirects and Google Search, Google Search Central, as of 14 Apr 2026
- Block Search indexing with noindex, Google Search Central, as of 10 Dec 2025
- Introduction to robots.txt, Google Search Central, as of 10 Dec 2025
- Build and submit a sitemap, Google Search Central, accessed 3 Oct 2026
- HTTP status codes, network and DNS errors, Google Search Central, as of 4 Feb 2026
- Page indexing report, Google Search Console Help, accessed 3 Oct 2026
Möchten Sie das für Ihr Unternehmen umsetzen?Want this for your business?
In einem kostenlosen 30-Minuten-Gespräch zeigen wir Ihnen, wo bei Ihnen der größte Hebel liegt. Passende Leistung: Webdesign Wien.In a free 30-minute call we show you where your biggest lever is. Related service: Webdesign Wien.
Termin buchenBook a call Demo anfragenRequest a demo
