Google indexed your site under the wrong subdomain: how to clean it up

On 23 October 2026 a site manager posted the same question to r/DoSEO and r/TechSEO: Google had indexed blog posts under ftp.example.com instead of www.example.com, the developer had removed the FTP subdomain from the server, and the FTP URLs were still in search results. The thread got an answer from John Mueller of Google within fifteen minutes. The case is common. The host can be ftp., staging., dev., a bare server IP or a subdomain left over from an old setup, and the platform does not matter: WordPress, Shopify with a custom domain, a headless frontend or a static site can all end up indexed under the wrong name.

This guide covers what actually controls the cleanup: what the old hostname returns today, which Search Console property can see it, and which Google signals move the main domain back into the index. Every timeline below comes from Google Search Central documentation.

#Why Google indexed the site under an ftp or staging subdomain

The original poster did the diagnosis well. URL Inspection showed the FTP URL as indexed, with crawling allowed and a successful fetch. The main-domain twin was “unknown to Google”, with no referring sitemap and no referring page. The detail that explains the rest:

The user-declared canonical pointed to the FTP URL itself. Google-selected canonical was also the FTP URL.

(u/Gullible-Winter294, r/DoSEO, 23 October 2026)

Three conditions produce this. A DNS record such as ftp, staging or a wildcard points at the same server as the live site. The web server answers that hostname with the live site, often because it is the default virtual host. And the site builds its canonical tag from the hostname in the request instead of a configured base URL, so every copy declares itself canonical. Google then has two identical pages, each claiming to be the original, and picks one of them.

#How to check what the old subdomain returns now

Before choosing a fix, find out what Google gets when it recrawls. One of the replies made the point that matters most:

First check what an old HTTPS URL actually returns now: DNS failure isn’t a 404.

(u/inevidimka, r/DoSEO, 23 October 2026)

Two commands answer it:

dig +short ftp.example.com
curl -sI https://ftp.example.com/blog/sample-article

If dig returns nothing, the name no longer resolves. If it returns an IP, curl shows whether you get a 200 with the full page, a 404 or 410, a redirect, or a TLS error because the certificate does not cover that hostname. Run it against several URLs Google actually shows, not only the home page. Google’s DNS and network errors guide uses dig the same way to check A, CNAME and NS records.

“The developer removed the subdomain” can mean any of these states. A deleted virtual host with the DNS record still in place usually means the server’s default site answers, which is the original problem in a new form.

#Does a 404 or 410 remove URLs from Google

Yes. Google’s HTTP status code documentation says that URLs already indexed and returning a 4xx code are removed from the index. All 4xx codes except 429 are treated the same, so 404 and 410 behave alike, and crawl frequency for those URLs gradually decreases.

A DNS failure is a different path with a similar end. Google treats DNS errors, timeouts and connection resets like 5xx server errors, and the DNS guide states that “already indexed URLs that are unreachable will be removed from Google’s index within days”. Both routes need a recrawl first, and that is where the waiting comes from. A reply in the thread put a number on it:

Google will deindex once it sees 404 error. Deindex can take upto 3 months

(u/KindlyConnection4420, r/DoSEO, 23 October 2026)

Google publishes no such figure. The removal happens when Google recrawls the URL, and a low-priority URL on a dead host can wait a while for that. Treat three months as one person’s experience, not a rule.

#Should you 301 the old subdomain to the main domain

If the same articles live on the main domain, a page-to-page redirect is the better repair. inevidimka suggested keeping the old hostname reachable with valid HTTPS and permanent redirects. John Mueller listed it as the alternative to removal:

Alternatively: Change DNS to point at a site where you can do an all-URL 301 redirect to www, optionally submit a change of address request in Search Console.

(u/johnmu, r/TechSEO, 23 October 2026)

Google’s canonicalization guide ranks redirects as a strong signal that the target should become canonical. A redirect also carries over whatever links point at the wrong host. Three practical conditions:

• The hostname must resolve and serve a certificate valid for it, or the crawler stops at the TLS error before it sees the 301.
• Map each URL to its own counterpart. Sending everything to the home page throws away the page-level signal.
• Keep the redirects. Google’s site move guide says “generally at least 1 year”, and the Change of Address tool asks for at least 180 days when you use it.

The same guide warns that for a medium-sized site it can take “a few weeks or more” for Google to show the new URLs instead of the old ones.

#How to verify a deleted subdomain in Search Console

Mueller’s first words were “Verify with DNS”. The Removals tool and URL Inspection only work for URLs in a property you own, and a host that no longer serves files cannot host an HTML verification file. A Domain property is verified with a DNS record (TXT or CNAME) and covers every subdomain and the http, https and ftp protocols. Verify example.com as a Domain property and ftp.example.com, staging.example.com and any forgotten subdomain fall under it, with or without a web server behind them.

The same Domain property also shows the Pages report across all hosts at once, which is the quickest way to find other stray hostnames in the index.

#How to remove an entire subdomain with the Removals tool

The Removals tool has a “Remove all URLs with this prefix” option. Enter https://ftp.example.com/ and every URL on that host is hidden. Google’s help page is explicit that this stays on the subdomain: blocking https://staging.domain “will not block www.domain or https://domain.com”. Google’s removal guide says requests take effect within a day.

Four limits from the same page:

• A request lasts about six months. After that the URLs can return if nothing else changed.
• The tool hides results. It does not stop crawling and does not remove anything permanently. The permanent part is a 404 or 410, a password, or noindex.
• If the URL already returns 404 or 502/503 when you file the request, Google assumes the page is gone and lets the request expire.
• Google says not to use it to get the right version of a site indexed, because it can hide all versions of a URL. On a separate subdomain that risk is limited by the prefix rule above. Do not try it on www versus non-www.

So the tool is worth it when the wrong URLs cause damage today: a staging copy with test prices, a dev host with half-built pages, an IP address showing in results. For a duplicate blog on ftp. that will 301 or 404 anyway, Mueller’s last line applies: “If the URLs no long work, they’ll drop out on their own.”

#Why robots.txt on the old host makes it worse

Putting Disallow: / on the staging host backfires. Google’s noindex documentation says a page blocked by robots.txt is never fetched, so its noindex rule is never seen, and the page can still appear in results. The canonicalization guide adds that Google may index URLs disallowed in robots.txt without their content. Both Google removal pages list robots.txt as the method not to use. Leave the host crawlable until the 301, 404 or noindex has been read.

#How to get the main domain URLs indexed instead

Removing the wrong host does not by itself index the right one. The poster’s main-domain URLs had no referring sitemap and no referring page, so Google had no reason to fetch them. Fix the signals on the live site:

• Generate the canonical from a configured base URL, so www.example.com pages declare www.example.com whatever hostname served them.
• List the main-domain URLs in the XML sitemap submitted in the live property. Google calls sitemap inclusion a weak signal, and signals stack.
• Check that internal links, hreflang and Open Graph URLs use the main host, not a relative path that inherits the wrong one.
• Run a live test in URL Inspection on a few main-domain URLs and request indexing for the most important ones.

Google’s canonicalization guide says the methods “can stack and thus become more effective when combined”. A redirect from the old host plus a correct canonical on the new one plus the sitemap is the combination to aim for. If the wrong host appeared after a platform change, our migration service and the article on why Google reverts domain migrations cover the redirect map. The Search Console and Indexing API guide explains the Pages report used to track progress.

#Which fix fits your case: decision table

#How to keep staging and dev hosts out of Google

• Password-protect non-production hosts. Google’s guide to controlling what you share says password protection keeps content out of Search and eventually removes it if it already appears. HTTP basic auth at the server or CDN works on any platform.
• Send X-Robots-Tag: noindex on every non-production host. The robots meta and X-Robots-Tag specification allows the rule as an HTTP header, so it covers PDFs and images too and survives a theme or template change. Set it in the server or CDN config for the hostname, not in the application, so a database copy from staging to production cannot carry it to the live site.
• Remove DNS records when you remove the host. A CNAME pointing at a service you no longer use is the classic subdomain takeover setup: MDN describes an attacker claiming the abandoned name at the provider and publishing their own content on your subdomain.
• Avoid wildcard DNS unless you need it. Cloudflare’s wildcard record documentation explains that * answers for every name that has no record of its own. Combined with a default virtual host, any typo or invented subdomain serves your live site.
• Make the live server reject unknown hostnames. A default virtual host that returns 404 or closes the connection for unlisted names stops the duplicate at the source.

Our staging workflow guide shows the server configuration for basic auth and the noindex header. A website check includes a sweep of DNS records and indexed hostnames, and a maintenance plan keeps that list current after every server or agency change.