Website-Relaunch: wann er sich lohnt und wie bestehende Adressen erhalten bleiben

Die Software lässt sich nicht mehr aktualisieren. Jede PHP-Version bekommt zwei Jahre vollen Support, danach zwei Jahre nur noch Sicherheitsupdates. Für 8.2 endet der Sicherheitssupport am 31. Dezember 2026, und WordPress empfiehlt PHP 8.3 oder neuer. Das deutlichste Zeichen: Ihr Theme oder CMS läuft auf keiner unterstützten PHP-Version mehr, und niemand pflegt es. Wie Sie den Wechsel vorher testen, steht in unserem Leitfaden zu PHP 8.2.

Es gibt keine mobile Ansicht. Google indexiert und bewertet die mobile Version Ihrer Inhalte. Pflicht ist eine mobile Version nicht, Google empfiehlt sie aber dringend.

Niemand im Team kann Inhalte ändern. Braucht jedes neue Foto technische Hilfe, veraltet die Seite.

Die Seiten sind langsam, gemessen, nicht geschätzt. PageSpeed Insights zeigt Felddaten echter Besucher:innen aus den letzten 28 Tagen (Über PSI). Gute Werte beim 75. Perzentil: LCP innerhalb von 2,5 Sekunden, INP von höchstens 200 Millisekunden, CLS von höchstens 0,1. Der Lighthouse-Laborwert kann INP nicht messen. Bei Seiten mit wenig Besuch greift PSI auf Daten der ganzen Website zurück, und hat auch die ganze Website zu wenig Besuch, zeigt PSI gar keine Felddaten. Die Core Web Vitals fließen laut Google ins Ranking ein, aber Sie haben wahrscheinlich Wichtigeres zu tun, als nur der Suche wegen einen perfekten Wert anzustreben.

Der Aufbau passt nicht mehr zum Unternehmen. Neue Leistungen, eine zweite Sprache, weitere Standorte und ein Menü, das noch die Firma vom Start der Website beschreibt.

Zwei Prüfungen für heute: PageSpeed Insights für Ihre Startseite und die drei meistbesuchten Einstiegsseiten, und Ihre PHP-Version, in WordPress unter Werkzeuge > Website-Zustand > Bericht > Server oder im Hosting-Panel.

Ist die Software aktuell, funktioniert die Seite am Handy und bestehen die Core Web Vitals, überarbeiten Sie Texte und Fotos im bestehenden System. Die Adressen bleiben, und mit ihnen alles, was Google über sie weiß.

Googles Anleitung zum Migrieren einer Website sieht das ähnlich: Neue Domain, neues CMS und neues Layout gehen Sie besser nacheinander an. Die Search-Console-Hilfe warnt außerdem: Wer auf eine neue Domain übersiedelt und dabei Inhalte und Adressstruktur neu aufbaut, muss wahrscheinlich mit weniger Zugriffen rechnen.

Unsicher, was auf Sie zutrifft? Bei Wartung und Bugfixing sehen wir uns den Code zuerst kostenlos kurz an und sagen Ihnen ehrlich, ob Weitermachen oder Neubauen sinnvoller ist.

Googles Anleitung baut die Umstellung auf einer Zuordnung alter zu neuen Adressen auf. Die alten finden Sie:

• in Ihrer XML-Sitemap, laut Google wahrscheinlich mit Ihren wichtigsten Adressen;
• im Leistungsbericht der Search Console, Tab "Seiten", mit einem längeren Zeitraum als den voreingestellten drei Monaten, exportiert (der Export endet bei 1.000 Zeilen);
• im Bericht zur Seitenindexierung, dessen Beispiellisten bei 1.000 Adressen enden;
• im Bericht "Links" unter Externe Links > Meistverlinkte Seiten, einer Stichprobe mit höchstens 1.000 Zeilen;
• in Ihrer Webanalyse, bei Matomo unter Verhalten > Einstiegsseiten;
• in den Server-Logs;
• bei PDFs, Bildern und Downloads, die laut Google womöglich schon Besuche über die Suche oder Links bekommen.

Alles kommt in eine Tabelle: alte Adresse, Klicks, Links, neue Adresse, Status. Sortieren Sie nach Klicks: Die obersten Zeilen verdienen die meiste Sorgfalt.

Die beste Weiterleitung ist keine: Behält eine Seite ihren Inhalt, behält sie auch ihre Adresse. Für den Rest gelten die Regeln aus Googles Anleitung zum Migrieren einer Website und der Übersicht zu Weiterleitungen:

• Jede alte Adresse führt zur inhaltlich nächsten neuen.
• Richten Sie dauerhafte Weiterleitungen am Server ein, also 301 oder 308. Bei einer vorübergehenden 302 oder 307 zeigt Google weiter die alte Adresse in den Suchergebnissen.
• Leiten Sie direkt zur endgültigen Adresse weiter. Googlebot folgt bis zu 10 Weiterleitungen hintereinander. Wo sich eine Kette nicht vermeiden lässt, nennt Google aber höchstens 3 als Idealwert.
• Schicken Sie nicht viele alte Adressen auf die Startseite. Google schreibt dazu: "Das kann Nutzer verwirren und als soft 404-Fehler gewertet werden." Seiten, die Sie zu einer zusammengelegt haben, dürfen alle dorthin führen.
• Was wegfällt, antwortet mit 404 oder 410, auf einer Fehlerseite mit Aussehen und Navigation Ihrer Website. Eine freundliche "Nicht gefunden"-Seite mit Status 200 ist ein Soft 404, und solche Seiten schließt Google aus der Suche aus.

Drei Zeilen für eine erfundene Website:

Am Server wird aus jeder alten Adresse eine Zeile Konfiguration. Auf Apache-Hosting gehören die Zeilen in die Datei .htaccess im Hauptverzeichnis der Website. Bei WordPress setzen Sie sie über # BEGIN WordPress, denn WordPress überschreibt jede Änderung zwischen seinen Markierungen. Die nginx-Zeilen gehören in den server-Block der Website und brauchen Zugriff auf die Serverkonfiguration:

Redirect permanent "/webdesign.html" "https://www.example.at/leistungen/websites"
Redirect permanent "/team/buero.html" "https://www.example.at/ueber-uns/team"
Redirect permanent "/team/verkauf.html" "https://www.example.at/ueber-uns/team"
Redirect gone "/aktion-2019.html"

location = /webdesign.html    { return 301 https://www.example.at/leistungen/websites; }
location = /team/buero.html   { return 301 https://www.example.at/ueber-uns/team; }
location = /team/verkauf.html { return 301 https://www.example.at/ueber-uns/team; }
location = /aktion-2019.html  { return 410; }

Redirect gone und return 410 antworten mit der schlichten Fehlerseite des Servers. Für Ihre eigene Seite ergänzen Sie ErrorDocument 410 /404.html (Apache) bzw. error_page 410 /404.html; (nginx), mit einer statischen Seite im Aussehen Ihrer Website.

1. Die Weiterleitungen gehen mit der neuen Website online. Bei kleinen und mittleren Websites empfiehlt Google, alle Adressen auf einmal umzustellen statt Bereich für Bereich.

2. Entfernen Sie noindex-Regeln und robots.txt-Sperren aus der Entwicklungszeit, sobald die Weiterleitungen online gehen. In WordPress nehmen Sie dazu unter Einstellungen > Lesen bei "Sichtbarkeit für Suchmaschinen" das Häkchen heraus. Laut Google können solche Reste verhindern, dass die neue Website vollständig indexiert wird.

3. Interne Links, Menüs und Schaltflächen zeigen direkt auf die neuen Adressen, denn jede Weiterleitung kostet Ladezeit.

4. Jede Seite bekommt ein Canonical-Tag auf sich selbst, mit absoluter Adresse.

5. Zweisprachige Websites passen hreflang an: Jede Sprachversion nennt sich selbst und alle anderen mit vollständiger Adresse, und verweisen zwei Seiten nicht gegenseitig aufeinander, ignoriert Google die Angaben. Der Kopf unserer Leistungsseite für Websites:

   htmlKopieren

   <link rel="canonical" href="https://www.blax.at/de/digital/websites">
   <link rel="alternate" hreflang="en" href="https://www.blax.at/digital/websites">
   <link rel="alternate" hreflang="de" href="https://www.blax.at/de/digital/websites">
   <link rel="alternate" hreflang="x-default" href="https://www.blax.at/digital/websites">

6. Testen Sie jede Zeile. curl -sI <alte Adresse> prüft eine einzelne Adresse. Für die ganze Liste schreiben Sie pro Zeile eine vollständige alte Adresse in alte-adressen.txt, etwa https://www.example.at/webdesign.html, und starten:

   bashKopieren

   while IFS= read -r alt || [ -n "$alt" ]; do
     alt=${alt%$'\r'}   # Windows-Zeilenende aus dem Tabellen-Export entfernen
     printf '%s  ' "$alt"
     curl -s -o /dev/null -L -w '%{http_code} %{num_redirects} %{url_effective}\n' "$alt"
   done < alte-adressen.txt

   Seiten, die ihre Adresse behalten haben, sollten 200 0 zeigen, verschobene 200 1 am richtigen Ziel, entfernte 404 0 oder 410 0. Zwei oder mehr Sprünge sind eine Kette, ein 404 nach einer Weiterleitung ist eine falsche Zeile. Einzelne Adressen zeigt das URL-Prüftool der Search Console so, wie Google sie sieht.

7. Reichen Sie die neue XML-Sitemap in der Search Console ein, und eine Zeit lang auch die alte: Deren Zahl indexierter Seiten sinkt gegen null, während die der neuen steigt. Die Warnungen zur alten Sitemap nennt Google normal. Danach entfernen Sie die alte.

Das Tool zur Adressänderung brauchen Sie nur beim Wechsel auf eine andere Domain oder Subdomain, nicht für den Wechsel von http auf https, mit oder ohne www oder für neue Pfade auf derselben Domain.

Laut Google müssen Sie während der Umstellung mit vorübergehenden Schwankungen bei den Platzierungen rechnen. Beobachten Sie:

• den Bericht zur Seitenindexierung auf Sprünge bei "Nicht gefunden (404)" und "Soft 404-Fehler". Laut Google kommt es häufig vor, dass Weiterleitungen auf Adressen zeigen, die es gar nicht gibt. Nach einer Korrektur klicken Sie auf "Fehlerbehebung überprüfen", die Prüfung dauert meist bis zu etwa zwei Wochen;
• den Sitemaps-Bericht auf Fehler;
• den Leistungsbericht: Klicks auf alte Adressen sollten sinken, auf neue steigen.

Aktualisieren Sie Ihre Profil-Links und Werbekampagnen, und bitten Sie die Websites, die Ihnen die meisten Besuche bringen, auf die neue Adresse zu verlinken.

Google rät, die Weiterleitungen möglichst lange beizubehalten, generell mindestens ein Jahr. Aus Sicht der Besucher:innen legt Google nahe, sie unbefristet zu behalten. Nach einem Domainwechsel behalten Sie die alte Domain noch mindestens ein Jahr, damit sie niemand kauft und missbraucht. Und zum Linkwert: Laut Google kosten 301 und andere dauerhafte Weiterleitungen keinen PageRank.

Unsere Nuxt-App lieferte die englischen Seiten früher doppelt aus, unter / und unter /en, und beantwortete auch /contact/ und /CONTACT, jeweils als eigene Seite. Unser altes hreflang schickte Crawler sogar weiter auf /de/en/..., und dort kam ein 404.

Heute schickt eine Server-Middleware jede Variante mit einer einzigen 301 zur kanonischen Adresse: Das Präfix /en und der Schrägstrich am Ende fallen weg, Großbuchstaben werden zu Kleinbuchstaben, alles in einem Durchgang, und /de/en/... wird zu /de/.... Alte Adressen der früheren WordPress- und statischen Websites wie /home und /contact-us haben eigene 301-Regeln, samt deutschen Gegenstücken wie /de/contact-us. Die Schleife aus Schritt 3 am 4. November 2026:

https://www.blax.at/CONTACT  200 1 https://www.blax.at/contact
https://www.blax.at/en/contact/  200 1 https://www.blax.at/contact
https://www.blax.at/home  200 1 https://www.blax.at/
https://www.blax.at/comments/feed  404 0 https://www.blax.at/comments/feed
http://blax.at/Contact/  200 3 https://www.blax.at/contact

Die letzte Adresse ist in Protokoll, Host und Pfad falsch und braucht deshalb drei Sprünge. Das ist noch im Rahmen von Googles Idealwert von höchstens 3. Varianten, die sich nur im Pfad unterscheiden, brauchen einen Sprung.

Die Search Console listet außerdem noch Überbleibsel der WordPress-Website, die früher auf blax.at lief, als 404, etwa /comments/feed und wp-emoji-release.min.js. Für sie gibt es keinen Nachfolger, also ist 404 die richtige Antwort. Wären es Inhaltsseiten gewesen, hätten wir ihre Platzierungen verloren: Google entfernt indexierte Adressen, die mit 4xx antworten, aus dem Index.

Wir bauen Unternehmenswebsites in WordPress oder Nuxt: schnell geladen, einfach von Ihrem Team zu pflegen und für Suchmaschinen strukturiert. Dass nach einem Relaunch jede Platzierung bleibt, wo sie ist, kann niemand ehrlich versprechen, und wir tun es auch nicht. Schicken Sie uns über das Kontaktformular die Adresse Ihrer heutigen Website und was Sie daran stört.

Reichen vielleicht neue Inhalte, beginnen Sie mit dem kostenlosen Website-Check. Wir sehen uns an, was jeder im Netz sehen kann, auch veraltete Software, und binnen 3 Werktagen bekommen Sie die 5 wichtigsten Befunde schriftlich. Oder rufen Sie uns an unter +43 7235 233 85, Montag bis Freitag 8:00 bis 15:00 Uhr, am Wochenende 9:00 bis 12:00 Uhr.