Our Disavow File Was Covering the Wrong Half of Our Domain

September 13, 2026 · 7 min read

In August we wrote about the mass backlink spam campaign that hit this site. We diagnosed it, built a disavow file with 425 spam domains, submitted it through Search Console, and moved on to rebuilding real citations. As far as we knew, that part was handled.

Three weeks later, a question we almost did not bother answering turned up the fact that most of those spam links were pointing at a version of our own site that the disavow file never covered. Here is what we found, what we had gotten wrong, and how to check your own site for the same thing in about five minutes.

The Question That Started It

Google Search Console lets you register a site in two ways. A Domain property covers everything: example.com, www.example.com, http, https, and every subdomain. A URL-prefix property covers only URLs that begin with exactly the address you typed. Same site, very different scope.

Ours was a URL-prefix property for https://www.jlmedia.agency/. That sounds harmless — it is the address we publish everywhere. The question was simply what that difference meant in practice. Chasing it down turned up three problems stacked on top of each other.

Problem One: Both Hostnames Were Serving the Whole Site

A site should answer on one hostname and redirect the other. Ours answered on both:

$ curl -sI https://jlmedia.agency/
HTTP/2 200

$ curl -sI https://www.jlmedia.agency/
HTTP/2 200

Two complete, independently reachable copies of the same site. Google has to decide which one is real, and any ranking signal that lands on one does not automatically benefit the other.

Problem Two: No Canonical Tag Anywhere

The usual backstop for duplicate hostnames is a canonical tag telling Google which version is authoritative. We had none — not on one page, on any page.

The cause was a small gap in our own build. The site declares a metadataBase, which sets the base URL used for absolute links in metadata, and it is easy to assume that also produces a canonical tag. It does not. Without an explicit canonical declaration, the framework emits no <link rel="canonical"> at all. Our build was technically correct and silently missing the one tag that would have settled the question.

Google's own data said so plainly. The URL Inspection tool, for a page last crawled three weeks earlier, reported: User-declared canonical: None.

Problem Three: The Spam Was Pointing at the Uncovered Half

A disavow file lives inside one Search Console property and applies to that property. Ours was attached to the www version. So the question became: which hostname were the spam links actually aimed at?

Running our backlink tool against the bare apex in exact-URL mode, rather than against the whole domain, answered it. The apex alone had 366 backlinks from 336 referring domains — essentially the entire spam campaign, sitting on the one version of the site our disavow file did not cover.

The Part We Got Wrong

This is the uncomfortable half of the story. Earlier the same day, we had pulled the Links report in Search Console and found only seven external links to the site, all from a single client's domain. We read that as encouraging news: Google is not counting the spam at all.

That conclusion was worthless, and for exactly the reason above. The Links report belongs to the www property, and a www property cannot see links pointing at the apex. The report was not telling us Google ignores the spam. It was telling us nothing, in a way that looked like good news.

Worth keeping in mind generally: when a report comes back reassuring, check that it was actually in a position to see the thing you are worried about.

The Fix, and Why the Order Matters

The repair itself is ordinary — canonical tags, a redirect, and the disavow file applied where the links actually are. But the sequence is not optional.

1. Disavow the uncovered hostname first. We registered properties for the apex and submitted the same 425 domains there before touching anything else.
2. Add a self-referencing canonical to every page, pointing at the hostname you intend to keep.
3. Only then redirect the apex to www with a permanent redirect that preserves the path.

Do those last two before the first and you spend a window forwarding several hundred spam domains straight into the hostname that was clean, with nothing in place to disavow them there. The redirect is the right move; it is just the last one.

A Wrinkle Worth Knowing About

The obvious fix for a scope problem is a Domain property, which covers every hostname at once. We created one — and it verified automatically, because the DNS record was already in place from an earlier setup.

It does not solve this particular problem. Open the Disavow Links tool, select a Domain property, and Google tells you: Domain properties are not supported at this time. The disavow tool still requires URL-prefix properties. If your spam is spread across hostname variants, you need a property for each variant you care about and the file uploaded to each one. We ended up with four.

How to Check Your Own Site in Five Minutes

• Request both hostnames. Visit your site with and without the www. If neither redirects to the other, you are serving two copies.
• View source and search for rel="canonical". If it is missing, nothing is telling Google which version wins.
• Check which property holds your disavow file. Open the Disavow Links tool and look at each property separately — a file uploaded to one does not apply to the others.
• Point your backlink tool at the exact apex URL, not the whole domain, and compare the referring domain count to the sitewide number. If most of them sit on one hostname, that is the hostname your cleanup has to cover.
• Check the last crawl date in URL Inspection and whether Google reports a user-declared canonical. Its answer beats your assumption about what your site emits.

This Is Not Only a Spam Problem

Strip the spam out of this story and the duplicate-hostname issue still costs you. Every link someone builds to the wrong version, every signal Google has to guess about, every page competing with its own twin — that is ordinary ranking potential leaking away at a site with no spam anywhere near it. The spam is what made us look. The split would have been quietly expensive either way.

Getting Started

If your site is technically healthy and still not ranking, the reason is often something structural like this rather than anything visible on the page. That is the kind of diagnosis we do. Get in touch for a free audit, or read more about our approach to local SEO.