The Day Google Served Celebrity Gossip on Our Subdomain

I was pulling Search Console data to write an SEO plan. The expected queries showed up: resume grader, resume score, the college majors cluster. Then, in the list of our most-shown pages, sandwiched between legitimate results, Google was serving pages like “FGTeeV Lexi’s real age revealed” and “5 feet tall or 5 feet short, what’s the real Sammy Davis Jr. height” under staging.rezscore.com.

We do not publish celebrity gossip. We definitely do not publish it on staging.

Two hundred pages we never wrote

Filtering the Search Console page report to the staging subdomain returned more than 200 indexed URLs, all under a single path prefix, all the same species of clickbait: YouTuber net worth reveals, funeral home obituaries, whether you should refrigerate Crisco. Some of them were ranking in the top ten for their queries and collecting real impressions, every one of them wearing our domain name.

The next check took ten seconds and explained everything. The DNS record for the staging subdomain pointed at an IP address that was neither of our production machines, and the machine behind it did not respond at all. It was an address in a cloud provider’s pool, left over from a staging droplet we had deleted years ago.

Deleting a server does not delete the DNS record that points to it.

How the squatting works

This class of problem has a name: a dangling DNS record, and the attack it enables is a subdomain takeover. The mechanics are almost boring:

1. You provision a cloud box, point a subdomain at its IP, and later delete the box. The IP goes back into the provider’s pool. The DNS record stays.
2. Someone else provisions boxes from the same pool. Sooner or later they hold an IP that some forgotten subdomain still points to. There are people who do this systematically, cycling through addresses and checking which hostnames resolve to them.
3. Now they serve whatever they want under your hostname. Search engines see a subdomain of an established domain, with the trust and crawl priority that implies, and index it.

The squatter gets rankings they could never earn on a fresh domain, because they are borrowing your reputation. You get a gossip farm on your search profile. By the time we found ours, the box had already gone dark again, but the pages were still sitting in the index, still surfacing for searches, still attributed to us.

The part that stings is the timing. We had spent a year watching our main category keyword slide down the rankings and assumed ordinary competitive pressure. For at least part of that period, Google’s picture of our domain included a couple hundred pages about YouTubers’ heights. I cannot prove how much that cost us, and search engines are opaque about domain-level quality signals. But “one of this site’s subdomains is a spam farm” is not a signal anyone wants in their file.

The cleanup, and what else fell out of it

The fix for the takeover itself is one line: delete the DNS record. Only a human with registrar access could do that, and it was done the day after discovery. Once the hostname stopped resolving, the indexed pages began dropping out; a week later the subdomain’s impressions were effectively zero.

But the investigation had put us in an auditing mood, so we opened the sitemaps report next. That is where the second forgotten mess was waiting: 108 stale sitemap submissions still registered with Google across our properties. Two sitemaps from 2018 for a retired jobs subdomain, each still declaring 1,317 errors on every crawl. A hundred numbered sitemap files on two other subdomains, each claiming about 4,000 URLs, from a bulk submission nobody remembered making. A sitemap index for the legacy version of the main site. Google had been dutifully re-fetching all of it for years, building its picture of us partly out of garbage.

Deleting a sitemap submission is reversible and does not deindex anything, so this part was safe to automate: a short script against the Search Console API listed every submission on every property we control, deleted the graveyard, and left exactly two live sitemaps standing.

The checklist

Everything above was findable in under an hour with tools we already had. If you run anything with more than one subdomain, the same hour is probably worth spending:

1. List your DNS records and check each one against infrastructure you actually run. Any record pointing at an IP or CNAME you cannot account for is a takeover waiting to happen, or one that already happened.
2. Open Search Console’s page report and filter by each subdomain, including the ones you think are dead. You are looking for pages you did not write.
3. Open the sitemaps report on every property. Old submissions do not expire on their own; they sit there feeding the crawler stale URLs until someone deletes them.
4. When you kill a box, kill its DNS record in the same commit, ticket, or breath. The record is the part that outlives the server, and it is the part that gets you.

Since the cleanup, the category keyword that had been sliding for a year has climbed back from the middle of page two to the edge of page one. I am careful about attribution, because we changed several things in the same fortnight. But the spam is gone, the graveyard is empty, and the trend reversed. I will take the correlation.