There's very little information about subdomain hijacking targeted towards SEOs, so here's my experience, everything I've learned since, and how I've integrated subdomain checks into my technical SEO audits.

The story that started it all

A couple of days into being promoted into a purely technical SEO role, I received this email: "Your site is being affected by a manual action: hacked content detected."

I rushed over to the Manual Action section in Search Console and it was flagging christmas.client.co.uk. A Christmas subdomain? I asked my manager and he had no idea what it meant, so it was up to me to sort it out. Being the silly billy I am, I clicked the subdomain to see what was on it.

Casino. Full casino website. On my client's domain.

Luckily, the client was responsive and we had the issue resolved in a couple of hours. But I've been fascinated by subdomain hijacking ever since... because what I found out is that this is happening constantly, at huge scale, and most SEOs have no idea it's their problem until it very much is.

What is subdomain hijacking?

Subdomain hijacking happens when a subdomain points to an external service that no longer exists, creating what's called a dangling DNS entry. If someone else sets up a project on that same service and claims the same name, they now control your subdomain and they can put whatever they want on it.

Here's the typical sequence of events:

In my client's case, it was a Christmas advent calendar campaign from seven years ago. A hacker found it and decided to make a quick buck using the free promotion and backlinks for their casino site.

Important: If you suspect a subdomain has been hijacked, do not visit it directly in your browser. Use DIG or a tool like URLScan.io to investigate without exposing yourself.

Why it's scarier than you think

This used to be a fairly niche risk, a patient attacker would manually find dangling DNS records and claim them one by one. That's changed. AI has made it trivially easy to automate attacks at scale. Last year I was spotting these constantly, and the case studies below will show you just how industrial this has become.

Here's what makes it particularly uncomfortable from an SEO perspective: you probably have clients whose subdomains are being actively monitored by attackers right now.

Platforms to be especially wary of:

Each of these has known takeover vulnerabilities documented publicly. There's a GitHub repository called can I take over XYZ that documents and tests new platforms

How does Google treat subdomains?

Google’s systems are sophisticated enough to understand the relationship between a subdomain and its parent domain, but they do not treat them as the same entity. Subdomains are processed as separate entities, meaning link equity, topical authority, and domain authority are not automatically shared with the root domain. This distinction is critical: years of authority built for the main domain won’t automatically transfer to a subdomain.

However, associations still matter. If the main site links to a hijacked subdomain such as through old campaign pages in the footer or outdated blog posts, it can inadvertently legitimise the attacker’s content in Google’s eyes, passing trust to a spammer. Additionally, a manual action on a hijacked subdomain may influence how Google perceives the broader domain, potentially affecting the entire site’s reputation.

While Google has not explicitly stated that subdomains rank worse, the lack of automatic authority sharing means they often start at a disadvantage compared to subdirectories, which directly inherit the root domain’s authority.

Do you actually need a subdomain?

This is the question I ask every client now. Because a huge chunk of subdomain hijacking risk comes from subdomains that never needed to exist in the first place.

Temporary campaign? Don't use a subdomain.

Google has been pretty clear that authority isn't inherited by subdomains, they're treated as separate entities. There are plenty of case studies showing that migrating a blog from blog.domain.com to domain.com/blog results in a traffic boost, just from consolidating signals onto the main domain. So the SEO case for subdomains is already weak in most scenarios.

When a subdomain might be justified:

When a subdomain is almost certainly the wrong call:

Every unnecessary subdomain is a future attack surface. And in my experience, clients often have no idea half of them exist.

Case studies

The pattern is always the same: subdomain created, service forgotten, DNS record left behind. The only thing that changes is the scale.

Case Study 01 - Consumer Platform

Tumblr

Tumblr's custom domain feature allowed users to point their own domains at Tumblr blogs. When those blogs were deleted or abandoned, the DNS records were often left in place. Attackers could create new Tumblr blogs and claim the dangling subdomains, inheriting control of whatever domain was pointing at them.

This is the textbook example because the mechanism is simple and it happened at scale — not one forgotten subdomain, but a systematic vulnerability in how the platform handled custom domains. It's the same mechanism your clients are exposed to.

Case Study 03 - .edu Domain, May 2026

Stanford University — weight loss drugs ranking as official Stanford content

Multiple subdomains under stanford.edu were hijacked and redirected to scam websites selling weight loss supplements. Targeted subdomains included one for a machine learning tool, one for a computer science course, and one for the Stanford Department of Public Safety.

These pages appeared as high-ranking results in Google. Gemini cited them as official Stanford content in AI Overviews for weight loss searches. The attack wasn't discovered by Stanford IT. It was found by a student journalist at the Stanford Daily.

"The attackers want to use the fact that this is coming from some very trusted domain like stanford.edu, and leverage that in order to boost their scammy content." - Stanford CS professor Emma Dauterman

Academic and government domains are prime targets because of their authority and because decentralised web hosting means poor DNS hygiene

⚡ Case Study 04 — The Brazilian Government. July 2025.

gov.br — 630,000 hijacked URLs.

630K
URLs generated across hijacked Brazilian government subdomains. Redirecting real users to gambling and scam sites.

Attackers built a full automated infrastructure: a Flask server, a MySQL database full of SEO keywords, and an HTML template cloned from a real gov.br page, complete with government branding, internal links, and JSON-LD structured data, so it looked completely legitimate to Google.

Then came the cloaking:

  • Googlebot was served rich, keyword-stuffed fake government pages, fully rendered HTML designed to rank.
  • Real users who clicked through from search were redirected to gambling and betting sites.

Google's crawler saw one thing. Humans got another.

"This campaign was not improvised. It was deliberately built to exploit trust at scale. The goal was not to break into systems. It was to control visibility." — Hunt.io

The investigation was only possible because the threat intelligence firm Hunt.io stumbled across an exposed server that had left its directory open. The Brazilian government's own cybersecurity incident response team was notified and the investigation is ongoing.

If the Brazilian government had 630,000 URLs hijacked without anyone noticing — what's sitting on your clients' domains right now?

How to audit your clients' subdomains

Here's what I do.

Step 1: Find all subdomains

I built a tool (available on GitHub) that lets you paste in a domain and discover all its subdomains. You’ll just need a free API key from DNSDumpster, and it will reveal every subdomain that has ever existed for that domain.

Step 2: Check what each subdomain is pointing at

Use Google's DIG tool to look up the DNS records for each subdomain. You're looking for CNAME records pointing to third-party services. Then use Wappalyzer or WhatCMS to identify what platform it's actually hosted on.

Step 3: Cross-reference with known vulnerable platforms

Check each subdomain's hosting platform against the "can I take over XYZ" GitHub repository, maintained by security researchers. It lists which platforms have known takeover vulnerabilities. Azure, GitHub Pages, Heroku, and AWS S3 are frequently on there.

Step 4 — Flag anything suspicious to the client

Give your client a list of every subdomain that:

In my experience, the most common response is "oh, that shouldn't exist anymore!" followed by either quick action or a concerning silence. I've found complete copies of old sites, forgotten dev environments, and in one memorable case, a full clone of an entire ecommerce store that had been migrated two years prior...

A word on "that's not our department"

I gave a client a detailed list of vulnerable subdomains. Their response was that subdomains were nothing to do with their team, handled by a different department, out of their hands. Two months later, one of those subdomains was hijacked. Guess which team had to deal with the fallout? My client, of course. They couldn't do anything before the hack because "it wasn't their department". It absolutely was their problem after.

Make sure your clients understand: this will become your problem regardless of who "owns" the subdomain internally. Get buy-in before something happens, not after.

Help! I've found a vulnerable subdomain

Finding it before an attacker does is the best possible outcome. Here's what to do:

What to do if it actually happens

If you discover a subdomain has already been taken over, here's the response sequence:

Don't visit the compromised URL directly in your browser.

FAQs

A dangling DNS record is a DNS entry (usually a CNAME) that points to an external service that no longer exists or is no longer claimed. For example, if your client set up a subdomain pointing to a Heroku app, then deleted the Heroku app, the CNAME record in their DNS still points to Heroku — but there's nothing there anymore. An attacker can create a new Heroku app with the same name and inherit control of the subdomain.

Not always — it depends on what the attacker does with the subdomain. In my original case it triggered a hacked content manual action. But in sophisticated campaigns like the Brazilian government attack, the attackers used cloaking — showing clean content to Google while redirecting real users to scam sites. That can fly under the radar for a long time without triggering a manual action, which is actually more dangerous because nobody notices.

Two reasons. First, they have enormous domain authority built up over decades, which makes their subdomains incredibly valuable for SEO poisoning — if a page on stanford.edu ranks, Google AI Overviews will cite it as authoritative. Second, these organisations tend to have decentralised web hosting: lots of departments, research groups, and student projects spinning up subdomains with limited central oversight, meaning DNS hygiene is often poor and old records stick around long after the project has ended.

For most mid-size agency clients you don't need continuous automated monitoring — that's more of an enterprise concern. What you do need is visibility. Know what subdomains exist, and make sure there's a process so that when a service is switched off, the DNS record is removed at the same time. The real risk isn't subdomains that are actively in use — it's the ones that quietly stop being used while the DNS record hangs around.

In more sophisticated attacks, cloaking is layered on top of subdomain hijacking to make the campaign harder to detect. Googlebot is served legitimate-looking, keyword-rich content designed to rank. Real users who click through are immediately redirected to gambling or scam sites. Google crawls and indexes the clean-looking content, ranks it on the hijacked domain's authority, and never sees what real users experience. It's exactly what was happening in the Brazilian government attack at 630,000 URL scale.

The most commonly exploited platforms are those that allow you to register a named endpoint mapping to a custom domain:

  • Microsoft Azure (App Service, Static Web Apps) — as in the EY case
  • AWS (S3 static hosting, Elastic Beanstalk)
  • GitHub Pages
  • Heroku
  • Shopify (custom storefronts)
  • Fastly
  • Tumblr (custom domains)

The "can I take over XYZ" GitHub repository is the most up-to-date reference for which platforms are currently vulnerable and how.

Document your findings and flag them in writing regardless. The moment a subdomain gets hijacked, the "not our department" line disappears very quickly — because the manual action and the reputational damage absolutely become your problem. Push to get the information in front of whoever actually manages DNS, even if that means escalating through your contact. And make sure you have a paper trail showing you raised it.

Attackers run scripts that continuously scan DNS records for high-authority domains, looking for CNAMEs that resolve to "unclaimed" or "not found" responses from cloud platforms. AI-assisted tooling has made this fast and cheap to run at scale, which is why the volume of these attacks has increased so significantly. The Brazilian government campaign used automation to generate and manage 630,000 URLs from a single server.