The fix, in one snippet
a.b.c.d.login.example-security.help -> example-security.helpIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
The checker counts the labels to the left of the registrable domain, using the Public Suffix List so that a.b.example.co.uk counts two rather than three. Three or more is low severity, five or more is medium. It also flags hosts longer than about sixty characters, labels that look random (hexadecimal or high-entropy strings, typical of per-recipient tracking hostnames) and labels that imitate a full address (www-paypal-com). Limits: cloud and enterprise hostnames are legitimately deep (host.region.service.cloud.example.com), so the threshold is a heuristic and the severity is kept low.
Why it matters
With wildcard DNS a phisher can generate a fresh hostname for every message (k7f2a.track.example.tld), which defeats block lists that work at hostname level and lets the kit record exactly who clicked. Depth also pushes the registrable domain beyond the visible part of a mobile address bar, so the victim sees only the brand-like labels at the front, and a long host makes the address harder to read even on a desktop. Unique hostnames per recipient further complicate reporting, because the address one person reports is not the address the next person receives. Anyone reading links on a phone is the primary target; mail and chat clients that shorten displayed links make it worse.
How to fix it
Identify the registrable domain by reading from the right and ignore everything to its left; judge that domain with the other findings, especially registration date and lookalike. Do not sign in on a domain you do not recognise regardless of what the subdomains say. Related: brand in subdomain. Guide: how to spot phishing.
Where this fits
Excessive subdomain depth is check 11 of 13 that the phishing url checker runs under url and phishing indicators, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits URL uses a raw IP address as host (medium), where the link points to a bare IP address instead of a domain name, which legitimate consumer services almost never do. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Excessive subdomain depth closes one route in. Immediately below it: Top-level domain heavily abused for phishing, where the domain ends in a top-level domain that is disproportionately used for phishing and spam, usually because registrations there are free or very cheap; URL shortener hides the destination, where the link goes through a URL-shortening service, so the real destination is hidden until you click.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Excessive subdomain depth (low severity)
Scanner check id: url-excessive-subdomainsThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
