The fix, in one snippet
paypal.com.secure-login.ru -> the owner is secure-login.ru
www.paypal.com -> the owner is paypal.comIllustrative 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 splits the host into its registrable domain (using the Public Suffix List) and the labels to its left, then looks for brand tokens and dotted or hyphenated imitations of a brand domain (paypal-com, microsoft.online) in the subdomain labels and in the leading path segments. A brand in the subdomain when the registrable domain belongs to someone else is high severity; a brand only in the path is medium. Trust words alongside a brand (secure, login, verify, account) add weight. Limits: SaaS tenants and CDNs legitimately put a customer's brand in a subdomain (brand.zendesk.com, brand.sharepoint.com), so a list of known platforms lowers the severity for those; fan and support sites also mention brands. The registrable domain remains the thing to judge.
Why it matters
People read a URL from the left and stop at the first familiar word, and a mobile address bar shows only the first few dozen characters. The only part of a hostname that identifies who controls the site is the registrable domain, the label immediately before the public suffix; everything to its left is chosen freely by that owner. www.paypal.com.login-check.net belongs to whoever registered login-check.net. The trick works on everyone, and it works best on phones.
How to fix it
Find the owner by reading the host from the right: skip the public suffix (.com, .co.uk), and the next label is the registered domain. Chrome and Safari de-emphasise everything else in the address bar to help. If that domain is not the brand's, do not sign in, and report the link. Brands: keep sign-in on your own domain only, publish DMARC at enforcement, and monitor certificate transparency for hostnames that contain your name. Related: lookalike domains and subdomain depth. Guide: how to spot phishing.
Where this fits
Brand name used in a subdomain or path is check 2 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 Google Safe Browsing blocklist (critical), where google Safe Browsing lists this URL as phishing, malware or unwanted software. 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
Brand name used in a subdomain or path closes one route in. Immediately below it: Credentials or @ embedded in the URL, where the URL contains a user:password@ section before the host, a legacy syntax that phishers use to make an address begin with a trusted name; Internationalised (punycode) domain, where the domain contains internationalised (non-ASCII) characters encoded as punycode (xn--), which can make a lookalike address display as a trusted brand; Lookalike of a well-known brand domain, where the registered domain closely resembles a well-known brand's domain through a typo, an inserted character, a swapped letter or a plausible variant, but is not it.
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: Brand name used in a subdomain or path (high severity)
Scanner check id: url-brand-in-subdomainThe 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.
