Ein Relaunch ist abgenommen, die Agentur hat den Testserver abgeschaltet, und trotzdem führt Google Ihre Blogartikel unter staging.ihre-firma.de, ftp.ihre-firma.de oder einer nackten Server-IP. Genau diesen Fall schilderte am 23. Oktober 2026 ein Seitenbetreuer auf r/DoSEO und r/TechSEO: Google hatte Beiträge unter einer FTP-Subdomain indexiert, der Entwickler hatte die Subdomain entfernt, die URLs standen weiter in den Suchergebnissen. Nach einer Viertelstunde antwortete John Mueller von Google. Das System dahinter spielt keine Rolle, ob WordPress, Shopify mit eigener Domain, ein Headless-Frontend oder eine statische Seite.
Die Reihenfolge, die funktioniert: zuerst prüfen, was der alte Hostname heute ausliefert, dann die passende Property in der Search Console anlegen, zuletzt die Signale der Hauptdomain stärken. Alle Fristen in diesem Artikel stammen aus der Dokumentation von Google Search Central.
Warum Google die Website unter der ftp- oder Staging-Subdomain indexiert
Der Fragesteller hatte die URL-Prüfung sauber ausgewertet. Die FTP-Adresse war indexiert, Crawling erlaubt, Abruf erfolgreich. Die Entsprechung auf www war Google unbekannt, ohne verweisende Sitemap und ohne verweisende Seite. Das entscheidende Detail:
Der vom Nutzer angegebene kanonische Link zeigte auf die FTP-URL selbst. Die von Google ausgewählte kanonische URL war ebenfalls die FTP-URL.
(u/Gullible-Winter294, r/DoSEO, 23. Oktober 2026, eigene Übersetzung)
Dazu kommt es, wenn drei Dinge zusammentreffen. Ein DNS-Eintrag (ftp, staging oder ein Wildcard) zeigt auf denselben Server wie die Live-Seite. Der Webserver beantwortet diesen Namen mit der Live-Seite, weil sie der Standard-Virtual-Host ist. Und das Template erzeugt den Canonical-Tag aus dem Hostnamen der Anfrage statt aus einer festen Basis-URL, also erklärt sich jede Kopie selbst zum Original. Google sieht zwei identische Seiten, die beide Original sein wollen, und wählt eine davon aus.
Was liefert die alte Subdomain heute: so prüfen Sie es
Der wichtigste Hinweis im Thread betraf die Diagnose:
Prüfen Sie zuerst, was eine alte HTTPS-URL jetzt tatsächlich zurückgibt: Ein DNS-Fehler ist kein 404.
(u/inevidimka, r/DoSEO, 23. Oktober 2026, eigene Übersetzung)
Zwei Befehle reichen:
dig +short ftp.example.com
curl -sI https://ftp.example.com/blog/beispielartikelBleibt dig leer, löst der Name nicht mehr auf. Kommt eine IP zurück, zeigt curl, ob Sie eine 200 mit der vollen Seite, eine 404 oder 410, eine Weiterleitung oder einen TLS-Fehler erhalten, weil das Zertifikat den Namen nicht abdeckt. Testen Sie mehrere URLs, die Google tatsächlich anzeigt. Googles Anleitung zu DNS- und Netzwerkfehlern nutzt dig genauso, um A-, CNAME- und NS-Einträge zu prüfen.
“Der Entwickler hat die Subdomain entfernt” kann jeden dieser Zustände bedeuten. Am häufigsten ist der gelöschte Virtual Host bei stehendem DNS-Eintrag. Dann antwortet die Standardseite des Servers, meist die Live-Seite, und das Problem beginnt von vorn.
Entfernt ein 404 oder 410 die URLs aus Google
Ja. Die Dokumentation zu HTTP-Statuscodes sagt, dass bereits indexierte URLs mit 4xx-Code aus dem Index entfernt werden. Alle 4xx außer 429 behandelt Google gleich, 404 und 410 wirken also identisch, und die Crawl-Häufigkeit sinkt schrittweise.
Ein DNS-Fehler führt auf anderem Weg zu einem ähnlichen Ergebnis. Google behandelt DNS-Fehler, Zeitüberschreitungen und abgebrochene Verbindungen wie 5xx-Serverfehler, und laut DNS-Anleitung verschwinden nicht erreichbare indexierte URLs innerhalb weniger Tage aus dem Index. In beiden Fällen muss Google die URL erst wieder abrufen, daher die Wartezeit. Ein Kommentar nannte eine Zahl:
Google deindexiert, sobald es den 404-Fehler sieht. Das Deindexieren kann bis zu 3 Monate dauern
(u/KindlyConnection4420, r/DoSEO, 23. Oktober 2026, eigene Übersetzung)
Google veröffentlicht keine solche Frist. Die URL fällt beim nächsten Crawl, und eine unwichtige URL auf einem toten Host wartet darauf mitunter länger. Drei Monate sind eine Erfahrung, keine Regel.
Alte Subdomain per 301 auf die Hauptdomain weiterleiten
Liegen dieselben Artikel auf der Hauptdomain, ist die seitengenaue Weiterleitung die bessere Reparatur. Mueller nannte sie als Alternative zum Entfernen:
Alternativ: DNS auf einen Server zeigen lassen, auf dem Sie alle URLs per 301 auf www weiterleiten können, und optional in der Search Console eine Adressänderung einreichen.
(u/johnmu, r/TechSEO, 23. Oktober 2026, eigene Übersetzung)
Googles Anleitung zur Kanonisierung stuft Weiterleitungen als starkes Signal ein, dass das Ziel kanonisch werden soll. Außerdem übernimmt die Weiterleitung Links auf den falschen Host. In der Praxis gilt:
- Der Name muss auflösen und ein dafür gültiges Zertifikat haben, sonst bleibt der Crawler am TLS-Fehler hängen und sieht das 301 nie.
- Jede URL auf ihr Gegenstück leiten. Alles auf die Startseite zu schicken verschenkt das Signal pro Seite.
- Die Weiterleitungen stehen lassen. Die Anleitung zum Website-Umzug nennt in der Regel mindestens ein Jahr, das Tool zur Adressänderung verlangt mindestens 180 Tage.
Bei einer mittelgroßen Website dauert es laut derselben Anleitung einige Wochen oder länger, bis Google die neuen URLs statt der alten zeigt.
Gelöschte Subdomain in der Search Console bestätigen
Muellers Antwort begann mit “per DNS bestätigen” (eigene Übersetzung). Das Tool zum Entfernen und die URL-Prüfung funktionieren nur für URLs in einer Property, deren Inhaber Sie sind, und ein Host, der nichts mehr ausliefert, kann keine HTML-Bestätigungsdatei bereitstellen. Eine Domain-Property wird über einen DNS-Eintrag (TXT oder CNAME) bestätigt und umfasst alle Subdomains und die Protokolle http, https und ftp. Bestätigen Sie example.com als Domain-Property, dann fallen ftp.example.com, staging.example.com und jede vergessene Subdomain darunter, mit oder ohne Webserver.
Der Seitenbericht dieser Property zeigt alle Hosts gemeinsam, so finden Sie weitere verirrte Namen im Index.
Ganze Subdomain mit dem Tool zum Entfernen ausblenden
Das Tool zum Entfernen in der Search Console kann alle URLs mit einem bestimmten Präfix ausblenden. Mit https://ftp.example.com/ erfassen Sie den ganzen Host. Die Google-Hilfe stellt klar, dass ein Präfix auf staging weder www noch die Domain ohne www betrifft. Zur Dauer schreibt die deutsche Hilfeseite:
Ein erfolgreicher Ausschluss gilt nur für ca. sechs Monate. Danach können die Inhalte wieder in den Google-Suchergebnissen erscheinen.
Laut Googles Anleitung zum Entfernen von Seiten greift der Antrag innerhalb eines Tages. Grenzen laut derselben Hilfeseite:
- Das Tool blendet Ergebnisse aus, stoppt aber weder das Crawling noch entfernt es etwas dauerhaft. Dauerhaft wirken erst 404 oder 410, ein Passwort oder noindex.
- Liefert die URL beim Antrag bereits 404 oder 502/503, geht Google von einer gelöschten Seite aus und lässt den Antrag auslaufen.
- Google rät davon ab, das Tool zur Wahl der richtigen Version einer Website zu nutzen, weil es alle Varianten einer URL ausblenden kann. Bei einer separaten Subdomain begrenzt die Präfix-Regel dieses Risiko, bei www gegen ohne www lassen Sie es.
Sinnvoll ist das Tool, wenn die falschen URLs heute schaden: eine Testkopie mit Probepreisen, ein Dev-Host mit halbfertigen Seiten, eine IP-Adresse in den Ergebnissen. Für einen doppelten Blog auf ftp., der ohnehin ein 301 oder 404 bekommt, reicht Muellers letzter Satz: Wenn die URLs nicht mehr funktionieren, fallen sie von selbst heraus (eigene Übersetzung).
Warum robots.txt auf dem alten Host schadet
Ein Disallow: / auf dem Testhost bewirkt das Gegenteil. Die noindex-Dokumentation sagt, dass eine per robots.txt gesperrte Seite nicht abgerufen wird, ihr noindex also unsichtbar bleibt und sie weiter in den Ergebnissen erscheinen kann. Die Kanonisierungsanleitung ergänzt, dass Google gesperrte URLs ohne Inhalt indexieren kann. Beide Google-Seiten zum Entfernen nennen robots.txt ausdrücklich als ungeeignete Methode. Lassen Sie den Host crawlbar, bis 301, 404 oder noindex gelesen wurden.
So kommen die URLs der Hauptdomain in den Index
Das Entfernen des falschen Hosts indexiert den richtigen nicht automatisch. Die www-URLs des Fragestellers hatten keine Sitemap und keine verweisende Seite, Google hatte also keinen Grund, sie abzurufen. Korrigieren Sie die Signale auf der Live-Seite:
- Canonical aus einer festen Basis-URL erzeugen, damit Seiten auf www immer www angeben, egal welcher Name sie ausgeliefert hat.
- Die URLs der Hauptdomain in die Sitemap der Live-Property aufnehmen. Google nennt das ein schwaches Signal, aber Signale addieren sich.
- Interne Links, hreflang und Open-Graph-URLs auf den Haupthost prüfen.
- Einige www-URLs in der URL-Prüfung live testen und für die wichtigsten die Indexierung beantragen.
Laut Kanonisierungsanleitung wirken die Methoden stärker, wenn man sie kombiniert. Weiterleitung vom alten Host, korrektes Canonical auf dem neuen und Sitemap ergeben die Zielkombination. Ist der falsche Host nach einem Plattformwechsel aufgetaucht, behandeln unser Migrationsservice und der Beitrag, warum Google Domainmigrationen zurücksetzt, die Weiterleitungsliste. Den Seitenbericht zur Erfolgskontrolle erklärt der Leitfaden zu Search Console und Indexing API.
Welche Lösung passt: Entscheidungstabelle
| Was der alte Hostname liefert | Was zu tun ist | Dauer laut Google |
|---|---|---|
| 200 mit gleichem Inhalt | Jede URL per 301 auf ihr Gegenstück, Basis-URL des Canonicals korrigieren | Einige Wochen oder länger bei mittelgroßen Websites; Weiterleitungen mindestens ein Jahr |
| 404 oder 410 | Stehen lassen, Sitemap der Hauptdomain sicherstellen | Entfernung beim nächsten Crawl; keine feste Frist |
| DNS-Fehler (Name löst nicht auf) | Stehen lassen; CNAME auf fremde Dienste löschen | Innerhalb weniger Tage nach dem fehlgeschlagenen Abruf |
| TLS-Fehler auf dem alten Host | Gültiges Zertifikat und 301 oder DNS-Eintrag löschen | Für TLS-Fehler nennt Google keine Frist; ohne DNS-Eintrag wird daraus ein DNS-Fehler (wenige Tage) |
| Inhalte, die sofort weg müssen (Preise, Testdaten) | Domain-Property per DNS, Präfix entfernen, dauerhafte Lösung | Binnen eines Tages ausgeblendet, für ca. sechs Monate |
| Alter Host per robots.txt gesperrt | Sperre aufheben, damit Google 404, 301 oder noindex sieht | Hängt vom nächsten Crawl ab |
Staging- und Dev-Hosts aus Google heraushalten
- Passwortschutz auf jedem Nicht-Produktionshost. Laut Googles Anleitung zur Kontrolle geteilter Inhalte hält ein Passwort Inhalte aus der Suche heraus und entfernt sie mit der Zeit, falls sie schon erscheinen. HTTP-Basic-Auth auf Server oder CDN funktioniert mit jedem System.
- Header
X-Robots-Tag: noindexauf Testhosts. Die Spezifikation zu X-Robots-Tag erlaubt die Regel als HTTP-Header, damit gilt sie auch für PDFs und Bilder. Setzen Sie ihn in der Serverkonfiguration des Hostnamens, nicht in der Anwendung, damit eine Datenbankkopie von Staging auf Live ihn nicht mitnimmt. - DNS-Eintrag zusammen mit dem Host löschen. Ein CNAME auf einen nicht mehr genutzten Dienst ist der klassische Fall einer Subdomain-Übernahme: MDN beschreibt, wie ein Angreifer den verwaisten Namen beim Anbieter registriert und unter Ihrer Subdomain eigene Inhalte veröffentlicht.
- Wildcard-DNS nur bei echtem Bedarf. Die Cloudflare-Dokumentation erklärt, dass
*für jeden Namen ohne eigenen Eintrag antwortet. Zusammen mit einem Standard-Virtual-Host liefert dann jeder Tippfehler Ihre Live-Seite aus. - Unbekannte Hostnamen am Server abweisen, mit 404 oder geschlossener Verbindung im Standard-Virtual-Host.
Die Serverkonfiguration für Passwort und noindex-Header zeigt unsere Staging-Anleitung. Ein Website-Check umfasst die Prüfung von DNS-Einträgen und indexierten Hostnamen, und die laufende Wartung hält diese Liste nach jedem Server- oder Agenturwechsel aktuell.
