Anti-adblock for WordPress: detection, setup and recovery

WordPress powers a large share of the ad-supported web, from small blogs to mid-sized publications. Most of those sites monetise through display advertising, and a meaningful slice of their audience runs an ad blocker. Every blocked pageview is inventory that was requested by the reader but never earned anything.

The loss is invisible by default. Your ad network reports impressions that were served, not the ones that were blocked before they could load. A WordPress dashboard shows traffic, not lost revenue. Without a detection layer you simply cannot see the gap, so it never gets addressed.

Adding an anti-adblock script is the first step to making that gap visible: from the first day, it counts how many of your visitors block ads. On many WordPress sites that number is higher than the owner expects, particularly in tech, gaming and news niches.

An anti-adblock script should load as early and as reliably as your ad tags do. The cleanest place is the document head, so detection runs before the recovery decision needs to be made. On WordPress you have three sensible options.

The first, and the one we recommend for most site owners, is the official WordPress plugin, AntiAdBlockCore on WordPress.org. Install it, open Settings › AntiAdBlock Core, connect your account and approve the security code: the plugin verifies your domain and adds the script to the head of every page, whatever your theme, with no code to paste and nothing to redo after a theme update. With first-party delivery, preselected when you connect, the script starts once the DNS record the plugin shows you is active.

The second option is placing the tag by hand, for headless front ends or page builders that serve their own HTML: copy it from the plugin's Get code button (then set Insertion to Manual so it does not load twice) or from your dashboard, and paste it inside the head, as high as you can. In a classic theme that means header.php, inside a child theme so a theme update cannot overwrite it.

The third option, for sites with a custom or block-based theme, is to hook into wp_head from a small custom plugin or a code-snippets plugin. Whichever you choose, the goal is the same: one async script tag in the head, loaded on every page. AntiAdBlock Core ships exactly one such tag, loaded async, so it never blocks your page from rendering.

An anti-adblock script does not replace your ad network and does not conflict with it. AdSense, Mediavine and Ezoic all serve ads through their own tags; the detection script runs next to them, works out whether the visitor is blocking ads and, if so, shows your notice. The two layers are independent.

There is one rule worth respecting with all three networks: do not use anti-adblock to serve their ads to blocked users in a way that violates their policies. The safe pattern is to detect the blocker and show your own notice asking the visitor to allow ads on your site, rather than trying to force network ads past the block. With AntiAdBlock Core that notice is a wall by default: it explains that ads fund the site, shows the steps for the visitor's blocker and checks again as soon as they allow the site. If you use AdSense, show one notice only: keep its ad blocking recovery message as a draft and use the AntiAdBlock Core notice, which covers desktop and mobile.

Ezoic and Mediavine sites in particular tend to have a more complex tag setup, often with lazy-loaded ad units. A detection script that runs in the head leaves those units and their loading order alone, so it coexists with lazy loading cleanly. Detection and ad rendering are not racing each other.

The most common mistake is placing the script in the footer or loading it after a long chain of other deferred scripts. By then the recovery decision is late and the user may have already left. Keep the detection script in the head and async. On WordPress the usual cause is a caching or optimization plugin that delays or combines JavaScript: the official plugin keeps its tag out of the JavaScript optimization of WP Rocket, LiteSpeed Cache, W3 Total Cache, Autoptimize, SiteGround Optimizer, Perfmatters and Flying Press; if you paste the tag by hand without the plugin, exclude it yourself.

The second mistake is a recovery experience that feels hostile. A wall that accuses the reader, hides why it is there or gives no clear way back to the content pushes people away. The wall itself is not the problem: an on-brand notice that explains ads fund the site, shows the exact steps for the reader's blocker and lets them in as soon as they allow the site recovers far more revenue than a message they can close and forget.

On consent: a good anti-adblock script should set no tracking cookies and build no visitor profiles. AntiAdBlock Core keeps only daily totals per site in its statistics, with no visitor identifiers, and sets no tracking cookies. To count recoveries it keeps a few timestamps with no identifier on your own domain, for 30 days at most, so list them in your cookie policy and decide, under the rules that apply to you, whether your consent tool has to cover them. The official plugin also adds suggested text to the WordPress Privacy Policy Guide. You still manage consent for the ad network as you already do.

Once the script is live, the first number to watch is your ad-block rate: the share of pageviews where a blocker was detected. This is your baseline: it tells you how large the opportunity is.

The second is recoveries: visitors who allow ads on your site after seeing the notice. Your dashboard shows both on every plan and turns recoveries into estimated revenue at the CPM you set; the Max and Business plans add the breakdown by type of blocking and by audience. The plugin's settings page shows this month's detections and recoveries too.

Give any change at least one to two weeks before judging it. Ad-block rates vary by day of week and by traffic source, so you need a reasonable sample of visits. Treat it as iterative: once the notice is live, read your ad-block rate and your recoveries and, if your plan lets you write your own message, refine its wording. WordPress makes the deployment trivial; the discipline is in measuring patiently.

For a broader update on which anti-adblock approaches hold up on modern browsers, including Chrome's MV3 blockers that affect WordPress sites like any other, our guide on what changed after Manifest V3 covers what has moved on since classic WordPress snippets were written. If you want to go beyond detection and build a full recovery funnel on WordPress, how to block adblock on your website covers the implementation decisions that apply across any CMS.