Requests ad blockers stop: links and resources on EasyList
A resource on an EasyList domain never loads for a visitor running a blocker. squirrel reports each one with what it is.
What a blocked request is
EasyList’s network rules stop requests to advertising and tracking hosts. A visitor running uBlock Origin, AdBlock or a browser with built-in blocking never fetches them, so whatever the resource does never happens for that visitor.
The consequence depends on what it is. An advertising pixel not firing means missing revenue data. A conversion tag not firing means the conversion is not recorded. And when something essential to the page has ended up on a blocked host, the page itself breaks for a share of visitors that is large in some audiences and small in others.
What squirrel checks
The rule is site-wide and reads a result the cloud blocklist service produced before the rules ran, matched server-side against the full EasyList rules. It emits one check per finding, all named blocked-links:
- Skipped when no result is available. Message:
Ad-blocker link check skipped, with a readable skip reason. - Pass when nothing matched. Message:
No links or resources match EasyList ad-blocking rules. - Warn once per match, up to
maxMatchesToReportand always at least one, so a misconfigured0does not drop the finding. Message:Blocked by ad blockers: static.ads-twitter.com — X/Twitter ad pixel — https://static.ads-twitter.com/uwt.js (1 page), naming the vendor where the registrable domain is recognised and falling back to the bare hostname where it is not, with a page count when the source pages are known. Severity warning, weight 2.
The three blocking rules share one blocklist check per audit.
Images and scripts inside <noscript> are not sent for matching: a browser with scripting enabled never fetches them, so no blocker sees them either. Links inside <noscript> still are. See content inside noscript.
How to fix it
Move anything the page needs off a blocked host. For measurement, a first-party or server-side collector may reduce blocking, though it is not a guarantee: filters can match a first-party endpoint too, and server-side forwarding cannot recover an event whose browser request never left. For advertising, the finding is a description of your audience rather than a defect.
Check what each match actually is before acting. The report names the vendor for the domains it recognises, which is usually enough to tell an ad pixel from something the page depends on.
| Rule ID | adblock/blocked-links |
| Category | Blocking → Ad blocking |
| Scope | Site-wide |
| Severity | warning |
| Weight | 2/10 |
Options
| Option | Type | Default | Description |
|---|---|---|---|
maxMatchesToReport | number | 10 | Maximum blocked links to report in detail |
Configuration example
[rule_options."adblock/blocked-links"]
maxMatchesToReport = 25Enable / disable
Disable this rule
[rules]
disable = ["adblock/blocked-links"]Disable all blocking rules
[rules]
disable = ["adblock/*"]Enable only this rule
[rules]
enable = ["adblock/blocked-links"]enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.
Related rules
- adblock/privacy-blocked: the tracker half, matched against EasyPrivacy.
- adblock/element-hiding: elements hidden by cosmetic filters rather than blocked.
- security/third-party-cookies: the same hosts seen from the privacy side.
- analytics/gtm-present: the measurement that may be blocked.
Blocking findings ship in every audit next to the SEO, performance and agent experience rules. See Fix SEO issues with AI for how an agent works through a report.
References
Check your site
Run squirrel audit https://example.com and open the Blocking section of the report. Each blocked resource is listed with what it is and where it appeared. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.