Understanding Subdomain Takeovers: A Practical Guide for SEOs
Subdomain hijacking isn’t a common topic in SEO discussions, yet it can have a direct and damaging effect on rankings. This write-up shares my own experience with the issue, along with the process I now follow to check for vulnerable subdomains during technical audits.
A Quick Background
Not long after moving from a general SEO role into a purely technical position, I received a dreaded notification in Search Console:
“Manual action applied — hacked content detected.”
The flagged URL was a forgotten holiday promotion hosted at christmas.client.co.uk. My manager had no idea what it was, neither did I. After some digging (and a bit of frantic Googling), I realised it was an old campaign subdomain left to decay. It had since been repurposed by someone else to push spammy content.
Fortunately, the client was responsive and technically savvy, and we were able to remove the problem within hours. But the incident made me wonder: how many other neglected subdomains might be lurking unnoticed, ready for takeover?
What Actually Happened
A subdomain takeover occurs when the DNS record points to a third-party service (e.g., GitHub Pages, Heroku, AWS, etc.) and that service is no longer in use, but the DNS entry still exists.
An attacker can claim the abandoned resource on that platform and instantly serve their own content under your subdomain.
In my case, the old “advent calendar” microsite had been heavily promoted years earlier. When it was abandoned, the DNS remained active, creating an opportunity for exploitation. The hijacker capitalised on the subdomain’s existing authority and backlinks, using it to advertise a casino site.
This is far from rare. Similar incidents have affeced government portals, big brands, and even high-authority sites that AI models often trust blindly.
Why SEOs Should Care
You’re not expected to be a cybersecurity specialist. But compromised subdomains can trigger manual actions, pass authority to malicious sites, and undo months or years of optimisation work. Many vulnerabilities come from legacy projects that no one remembers setting up.
Google treats subdomains as separate properties in many respects, yet links between them can still transfer authority. If a neglected subdomain is hacked and your main site links to it, you’re essentially vouching for the attacker’s content. This is why periodic subdomain checks should be part of your technical audit routine.
Investigation Process
Discover existing subdomains
Use tools like ViewDNS or DNSDumpster. Be aware of lookup limits; if a client has dozens or hundreds of subdomains, it’s worth flagging the potential for legacy or unused assets.
Identify hosting platforms
Check hosting with tools like WhatCMS or Google’s dig command. Also, avoid visiting a compromised link directly.
Assess vulnerability
Compare hosting platforms against known takeover-prone services such as AWS (Elastic Beanstalk/S3), GitHub Pages, Heroku, Shopify, Ghost, Microsoft Azure, Agile CRM, WordPress.com, and JetBrains services. Use ViewDNS to find subdomains, Wappalyzer to profile them, and match results with publicly available vulnerability lists.
If You Find a Vulnerable Subdomain
If it’s tied to one of the high-risk platforms and is unused (or planned for shutdown), coordinate with whoever manages DNS to remove or repoint the record. While SEOs aren’t directly responsible for server configurations, making stakeholders aware of both the security and SEO implications often helps get the issue prioritised.
I’m not a penetration tester — just a technical SEO who’s encountered this enough times to see the value in proactive checks. Including this step in audits can save headaches later.
Real-World Example: EY.com
A recent example, shared by Michael Curtis on LinkedIn, involved an EY subdomain hosted via Microsoft Azure. The Azure resource was deleted, but the DNS entry remained.
An attacker registered a new Azure app with the same hostname previously used by EY’s subdomain. Because the DNS still pointed there, they were able to serve explicit content under EY’s trusted domain.
This isn’t a “hack” in the traditional sense but an opportunistic use of abandoned DNS entries. The attacker didn’t breach internal systems; they simply claimed an unguarded name and inherited the traffic and trust that came with it.
