Suchmaschinen-Sichtbarkeit bei Relaunch und Wartung einer WordPress-Website steuern

Ein Relaunch oder eine längere Wartung ist für Suchmaschinen ein heikler Moment. Wer die Website in dieser Zeit falsch abschaltet, riskiert, dass Google eine leere Baustellenseite indexiert, Seiten als nicht gefunden wertet oder die neue Website wochenlang nicht auftaucht, weil im Relaunch-Stress ein Haken falsch gesetzt blieb. Der häufigste Fehler in der Praxis ist die WordPress-Option „Suchmaschinen davon abraten, diese Website zu indexieren“, die auf der Testumgebung richtig war und nach dem Livegang mit umzieht. Diese Anleitung zeigt, welches Signal in welcher Phase passt: Sichtbarkeit auf der Testumgebung, Statuscode 503 für kurze Wartungsfenster, Weiterleitungen beim Livegang und die Kontrolle danach.

Voraussetzungen

• WordPress: eine aktuelle Version, die Anleitung nutzt WordPress 7.1.2 und PHP 8.4.
• Rolle: Administrator im WordPress-Backend von Live-Website und Testumgebung.
• Zugriff: SFTP oder SSH für das Wartungs-Plugin in Schritt 3, WP-CLI für die Prüfbefehle, curl für Statuscodes.
• Testumgebung: eine Kopie der Website auf einer Subdomain oder lokal, siehe Staging-Umgebung für WordPress einrichten.
• Search Console: Zugriff auf die verifizierte Property der Domain.
• Backup: eine vollständige Sicherung von Dateien und Datenbank der Live-Website vor dem Umschalten.

Schritt 1: Die Signale kennen und richtig einsetzen

Suchmaschinen verstehen mehrere Signale, die sich in ihrer Wirkung stark unterscheiden. Wer sie verwechselt, richtet mehr Schaden an als mit gar keiner Maßnahme.

Signal	Wirkung	Passt für
noindex (Meta-Tag)	Seite wird aus dem Index entfernt, sobald Google sie erneut abruft	Testumgebung, nie die Live-Website
Statuscode 503 mit Retry-After	vorübergehend nicht verfügbar, Google versucht es später erneut	Wartungsfenster von Stunden, höchstens ein bis zwei Tage
Statuscode 301	Adresse ist dauerhaft umgezogen	geänderte URLs beim Relaunch
Passwortschutz	Crawler und Besucher sehen nur die Anmeldung	Testumgebung

Die Option unter Einstellungen > Lesen ist technisch ein noindex: WordPress setzt dann in jede Seite <meta name='robots' content='noindex, nofollow' /> und schaltet die XML-Sitemap ab, die dann mit 404 antwortet. Auf einer Live-Website entfernt das nach und nach alle Seiten aus der Suche. WordPress weist selbst darauf hin, dass es Sache der Suchmaschinen ist, dieser Bitte nachzukommen. Ein Schutz vor neugierigen Besuchern ist es also nicht.

Verifizieren: Sie haben für jede Phase Ihres Projekts festgelegt, welches Signal gilt: Testumgebung mit noindex und Passwort, Live-Website ohne noindex, Wartungsfenster mit 503.

Schritt 2: Die Testumgebung abschirmen

Die neue Website entsteht nicht auf der Live-Domain, sondern auf einer Kopie, etwa unter neu.ihre-firma.example. Aktivieren Sie dort unter Einstellungen > Lesen bei „Sichtbarkeit für Suchmaschinen“ die Option Suchmaschinen davon abraten, diese Website zu indexieren. Im Dashboard erscheint dann der Hinweis „Suchmaschinen abgewiesen“ als Erinnerung.

Verlassen Sie sich nicht allein darauf. Eine Testumgebung ohne Passwort wird trotzdem gefunden, etwa über Links in Mails oder Tickets, und noindex hält weder Besucher noch unhöfliche Crawler ab. Setzen Sie zusätzlich einen HTTP-Passwortschutz auf Serverebene; das Vorgehen zeigt Adminbereich mit IP-Freigabe und HTTP-Auth schützen sinngemäß für die ganze Website.

Sperren Sie die Testumgebung nicht zusätzlich per robots.txt mit Disallow: /. Laut Google darf eine Seite mit noindex nicht per robots.txt blockiert sein, sonst sieht der Crawler die Anweisung nicht, und die Adresse kann trotzdem in den Ergebnissen erscheinen.

Verifizieren: Auf der Testumgebung liefert wp option get blog_public den Wert 0, der Quelltext enthält noindex, nofollow, und ein Aufruf ohne Anmeldedaten endet mit 401 Unauthorized.

Schritt 3: Kurze Wartungsfenster mit Statuscode 503

Muss die Live-Website für die Umstellung kurz vom Netz, antworten Sie mit dem Statuscode 503 (Service Unavailable). Google empfiehlt das ausdrücklich statt einer Fehlerseite mit Status 200 oder einer 404, weil 503 eine vorübergehende Störung meldet. Mit dem Header Retry-After geben Sie an, wann es sich lohnt, wiederzukommen.

WordPress macht das bei Updates von selbst: Liegt die Datei .maintenance im Hauptverzeichnis, antwortet die ganze Website einschließlich /wp-admin/ mit 503 und Retry-After: 600. Für eigene Arbeiten ist das unpraktisch, weil Sie selbst ausgesperrt sind. Besser ist ein kleines Must-Use-Plugin in wp-content/mu-plugins/relaunch-wartung.php, das nur Besucher aussperrt:

<?php
/**
 * Plugin Name: Relaunch-Wartung (503 für Besucher)
 */
add_action( 'template_redirect', function () {
    if ( current_user_can( 'edit_posts' ) || is_robots() ) {
        return;
    }
    status_header( 503 );
    header( 'Retry-After: 3600' );
    nocache_headers();
    echo '<!DOCTYPE html><html lang="de"><meta charset="utf-8"><title>Wartung</title>'
        . '<h1>Wir sind gleich wieder da</h1><p>Die Website wird gerade überarbeitet.</p></html>';
    exit;
} );

Angemeldete Redakteure und Administratoren sehen die Website normal, alle anderen bekommen 503. Die Ausnahme is_robots() ist wichtig: Ohne sie antwortet auch die robots.txt mit 503. Laut Google stellt der Crawler dann in den ersten zwölf Stunden das Crawling der ganzen Website ein. nocache_headers() verhindert, dass ein Seiten-Cache die Wartungsseite speichert. Anmeldung und REST-API bleiben erreichbar. Entfernen Sie die Datei, sobald die Arbeiten fertig sind.

Planen Sie das Fenster knapp. Google nennt die Deaktivierung einer ganzen Website eine drastische Maßnahme und empfiehlt 503 höchstens für ein bis zwei Tage. Dauerhafte Serverfehler führen dazu, dass URLs aus dem Index fallen.

Verifizieren: curl -sI https://www.ihre-firma.example/ zeigt abgemeldet HTTP/1.1 503 Service Unavailable und Retry-After: 3600, curl -sI https://www.ihre-firma.example/robots.txt dagegen 200 OK.

Schritt 4: Livegang und Weiterleitungen

Beim Umschalten übernehmen Sie Dateien und Datenbank der Testumgebung auf die Live-Domain und ersetzen die Adressen mit wp search-replace, wie in Domain einer WordPress-Seite ändern beschrieben. Genau hier wandert die Option aus Schritt 2 mit, denn sie liegt als blog_public in der Datenbank. Setzen Sie sie unmittelbar nach dem Import zurück:

wp option get blog_public
wp option update blog_public 1

Ändern sich beim Relaunch Adressen, etwa weil /leistungen/webdesign/ nun /webdesign/ heißt, braucht jede alte Adresse eine 301-Weiterleitung auf die neue. Sonst verlieren Sie die Verlinkung von außen, und Besucher aus alten Suchergebnissen landen auf einer 404. Erstellen Sie die Liste der alten Adressen vor dem Relaunch, zum Beispiel aus der alten Sitemap, und pflegen Sie die Weiterleitungen wie in Weiterleitungen in WordPress sauber verwalten.

Verifizieren: wp option get blog_public gibt 1 aus, der Quelltext der Startseite enthält kein noindex, /wp-sitemap.xml antwortet mit 200, und alte Adressen leiten mit 301 auf die neuen weiter.

Schritt 5: Nach dem Relaunch kontrollieren

Reichen Sie in der Google Search Console die Sitemap der neuen Website ein und prüfen Sie einige wichtige Seiten mit dem URL-Prüftool. In den folgenden Wochen zeigt der Bericht zur Seitenindexierung, ob Seiten wegen eines noindex ausgeschlossen werden oder als nicht gefunden (404) auftauchen. Beides deutet auf eine vergessene Einstellung oder fehlende Weiterleitungen hin. Wie Sie die Berichte lesen, beschreibt Google Search Console mit WordPress verbinden.

Richten Sie außerdem eine Überwachung ein, die nicht nur die Erreichbarkeit prüft, sondern auch auf noindex im Quelltext der Startseite achtet. Viele Monitoring-Dienste können nach einem Text suchen. Das fängt auch den Fall ab, dass Monate später jemand die Testumgebung zurückspielt.

Ein Relaunch ist ein Moment, die laufende Pflege neu zu ordnen: Updates, Backups und die Kontrolle nach Änderungen. Wer das nicht selbst im Kalender halten möchte, kann es abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und sichert die Website wöchentlich auf externen Speicher; zum Einstieg gehört eine einmalige Analyse der Homepage.

Verifizieren: Die Sitemap ist in der Search Console als erfolgreich verarbeitet markiert, und die Zahl der indexierten Seiten bleibt in den Wochen nach dem Relaunch stabil oder steigt.

Typische Fehler

• Nach dem Relaunch verschwindet die Website aus Google. blog_public steht noch auf 0. Im Dashboard zeigt WordPress „Suchmaschinen abgewiesen“. Option zurücksetzen, Sitemap erneut einreichen.
• Baustellenseite mit Status 200. Ein Coming-Soon-Plugin liefert die Wartungsseite mit Status 200 aus, Google indexiert dann den Platzhaltertext. Prüfen Sie den Status mit curl -sI und stellen Sie auf 503 um.
• Auch die Administratoren sehen nur die Wartungsseite. Die Datei .maintenance liegt noch im Hauptverzeichnis. Entfernen Sie sie; Hintergründe in Wartungsmodus in WordPress beheben.
• Die Testumgebung steht in den Suchergebnissen. Sie war per robots.txt gesperrt statt per noindex und Passwort. Setzen Sie beides, geben Sie robots.txt frei und beantragen Sie die Entfernung in der Search Console.
• Die Wartungsseite bleibt nach dem Ende im Cache. Ein Seiten-Cache oder CDN hat die Antwort gespeichert. Cache leeren und die Wartungsseite künftig mit nocache_headers() ausliefern.

Häufige Fragen

Wie lange darf eine Website im Wartungsmodus bleiben?

Google empfiehlt 503 für höchstens ein bis zwei Tage. Dauert die Umstellung länger, lassen Sie die alte Website online und schalten erst um, wenn die neue fertig ist.

Brauche ich ein Coming-Soon-Plugin?

Nur, wenn es den Status 503 sendet und angemeldete Benutzer durchlässt. Das Must-Use-Plugin aus Schritt 3 erfüllt beides mit wenigen Zeilen und ohne zusätzliche Abhängigkeit.

Verliere ich beim Relaunch Rankings?

Schwankungen in den ersten Wochen sind üblich. Dauerhafte Verluste entstehen meist durch fehlende Weiterleitungen, gelöschte Inhalte oder ein vergessenes noindex.

Testumfang

Wir haben das Ganze auf einer Testinstallation mit WordPress 7.1.2 durchgespielt. Mit abgeschalteter Sichtbarkeit bekam jede Seite ein „noindex“, und die Sitemap verschwand. Auffällig war, dass ohne eigene Ausnahme auch die robots.txt mit 503 antwortete, deshalb haben wir sie in den Code aufgenommen. Wie Google auf ein echtes Wartungsfenster reagiert, konnten wir auf der nicht öffentlichen Installation nicht beobachten, hier stützen wir uns auf Googles Dokumentation.

Fazit

Für die Sichtbarkeit in Suchmaschinen zählt beim Relaunch vor allem, das richtige Signal zur richtigen Zeit zu senden: noindex und Passwort auf der Testumgebung, 503 für kurze Wartungsfenster, 301 für geänderte Adressen und direkt nach dem Livegang die Kontrolle von blog_public. Wenn Sie Updates, Backups und die Kontrolle nach solchen Umstellungen nicht selbst übernehmen möchten, können Sie sie an die WordPress-Wartung abgeben.

Weiterführende Anleitungen und Quellen

• Staging-Umgebung für WordPress einrichten
• robots.txt in WordPress richtig konfigurieren
• Weiterleitungen in WordPress sauber verwalten
• Google Search Central: Website vorübergehend pausieren oder deaktivieren
• Google Search Central Blog: Umgang mit geplanten Ausfallzeiten
• Google Search Central: Indexierung mit noindex blockieren
• Google Search Central: So interpretiert Google die robots.txt-Spezifikation
• Code-Referenz: status_header()