TL;DR
The Problem: Website security (Cloudflare, Sucuri, WAFs) blocks ad verification bots like IAS and DoubleVerify, causing 50%+ revenue drops.
Why It Matters: Blocked verification = CPM drops from $12 to $4, fill rates plummet 85% to 45%, costing you $50,000+ annually.
The Fix: Whitelist ad verification bots AND search engines in your WAF. Takes 10 minutes. Revenue recovers in 2-4 weeks.
For Cloudflare Users: Security → WAF → Custom rules → Create whitelist rule that allows: IAS (ias-, integralads), DoubleVerify (doubleverify, dv-), MOAT (moatbot), Google bots (adsbot-google, mediapartners-google, google-adwords, googlebot), Bing (bingbot), Amazon (amazonbot), Criteo (criteobot), Quantcast (quantcastbot), The Trade Desk (ttd-content), Facebook (facebookexternalhit), Apple (applebot), and Adbeat (adbeat). Set action to “Skip Bot Fight Mode.”
Keep reading for: Complete copy-paste expression, step-by-step instructions for all security platforms, and verification steps.
You wake up, grab your coffee, and check your ad dashboard like you do every morning. Your heart sinks.
Revenue is down 50%. Maybe more.
Yesterday you were earning $600/day from your ad networks. Today? $300. And you have no idea why.
Your traffic is fine. Your content hasn’t changed. The ads are still showing on your pages. But something is very, very wrong with your earnings.
Here’s what probably happened: Your website security is blocking the very bots that determine how much advertisers pay you.
If you’re running Cloudflare, Sucuri, or another web application firewall to protect your site from attacks, there’s a good chance it’s also blocking legitimate ad verification bots.
These aren’t the bad bots you want to stop. These are the bots that:
When these verification bots get blocked, advertisers can’t verify your inventory. And when they can’t verify it, they either:
The worst part? You’ll never get a notification this is happening. Your security system silently blocks these bots in the background, and your ad revenue quietly evaporates.
Tired of dealing with this yourself? That's exactly what we handle.
See our plans →Let’s talk about what’s really happening behind the scenes when ad verification bots get blocked.
Advertisers pay premium rates for “viewable” impressions. When IAS (Integral Ad Science), DoubleVerify, or MOAT can’t access your site to measure viewability, your score drops to zero. Or worse—your inventory gets marked as “unverified.”
Translation: Instead of $15 CPM for verified inventory, you’re getting $3 CPM for unverified. Same traffic. Same ads. 80% less revenue.
Premium advertisers won’t bid on unverified inventory. When your verification bots are blocked, those high-paying advertisers disappear from your auctions. You’re left with:
One publisher reported their AdSense fill rate dropped from 85% to 42% after their WAF started blocking Google’s Mediapartners bot.
“We’ve detected issues accessing your site for verification purposes…”
These emails start friendly. But if the problem continues, some networks will:
Let’s say you’re running a content site with 500,000 monthly pageviews:
Before blocking verification bots:
After blocking verification bots:
That’s an $4,200/month loss. Over $50,000 per year. From the same traffic.
Here’s what makes this so insidious: the revenue drop doesn’t happen immediately when you implement security rules.
You might add bot protection on June 1st. Everything looks fine for weeks. Then around June 20th, revenue suddenly drops. Why?
By the time you notice the revenue drop, you’ve forgotten about that security rule you added three weeks ago. You’re looking in all the wrong places for the problem.
You open a ticket with your ad network: “Why did my revenue drop?”
Their response: “Your traffic looks normal. We don’t see any issues on our end.”
You open a ticket with Cloudflare: “Is something blocking my ads?”
Their response: “Your site is loading fine. Ads are displaying correctly.”
Everyone’s right. And everyone’s wrong. The ads ARE displaying to human visitors. But the verification bots can’t see them. Nobody’s looking at the right logs to diagnose the actual problem.
Good news: This problem is completely fixable. Usually in less than 10 minutes.
The solution is to create a targeted security rule that allows legitimate ad verification bots while still blocking malicious traffic. Here’s exactly how to do it.
You need to whitelist these specific bot services based on the ad networks you’re running:
Essential for Everyone:
Add if You’re Running These Networks:
If you’re using Cloudflare, here’s your complete solution:
Navigate to: Security → WAF → Custom rules → Create rule
Rule name: Allow Ad Verification Services
Expression:
(lower(http.user_agent) contains "ias-") or
(lower(http.user_agent) contains "integralads") or
(lower(http.user_agent) contains "doubleverify") or
(lower(http.user_agent) contains "dv-") or
(lower(http.user_agent) contains "moatbot") or
(lower(http.user_agent) contains "adsbot-google") or
(lower(http.user_agent) contains "mediapartners-google") or
(lower(http.user_agent) contains "google-adwords") or
(lower(http.user_agent) contains "amazonbot") or
(lower(http.user_agent) contains "criteobot") or
(lower(http.user_agent) contains "quantcastbot") or
(lower(http.user_agent) contains "ttd-content") or
(lower(http.user_agent) contains "facebookexternalhit") or
(lower(http.user_agent) contains "applebot") or
(lower(http.user_agent) contains "adbeat") or
(lower(http.user_agent) contains "googlebot") or
(lower(http.user_agent) contains "bingbot")
Action: Skip → Select “Bot Fight Mode” (or whatever bot protection you have enabled)
Priority: Set to 1 (highest priority)
Deploy the rule.
Sucuri: Contact support to add these user agents to your whitelist
Wordfence: Settings → Firewall → Whitelisting → Add user agent patterns
ModSecurity: Add custom rules to allow these user agents in your configuration
Server-level (nginx/Apache): Update your configuration to allow these specific bots
The principle is the same across all platforms: Allow traffic from these specific user agent strings while maintaining protection against everything else.
After implementing your whitelist, check your security logs for the next 48 hours:
Common user agents you should now see in your logs:
ias-va/3.3 (Integral Ad Science viewability)ias-or/2.1 (IAS operations robot)Mediapartners-Google (AdSense matching)AdsBot-Google (Google Ads quality)CriteoBot/0.1 (Criteo crawler)Revenue won’t recover instantly. Here’s the typical timeline:
24-48 hours: Verification bots can successfully crawl your site again
3-7 days: New verification data propagates through ad networks
7-14 days: Viewability scores update, CPM rates begin improving
2-4 weeks: Fill rates normalize as premium advertisers return to auctions
Most publishers see partial recovery within a week and full recovery within a month.
You might be thinking: “Wait, isn’t allowing bots a security risk?”
No. Here’s why this approach is actually more secure:
You’re only allowing specific, identified bot services. Not “all bots.” Your security system still blocks:
Ad verification bots identify themselves clearly and consistently. They’re not trying to hide. This makes them easy to whitelist accurately.
These bots are literally checking to make sure YOU get paid properly. Blocking them is like locking your accountant out of your financial records.
Every major publisher whitelists these services. The New York Times does it. BuzzFeed does it. Your competitors are definitely doing it.
If you ever suspect an issue, you can disable the rule in seconds. No permanent changes to your security posture.
Yes, technically. But:
The risk is minimal. The revenue impact of blocking them is massive.
They can’t. The entire point of verification is to see your site exactly as a real user would. If they used special IP addresses or authentication tokens that bypass security, the verification would be meaningless.
No. Ad verification bots visit infrequently:
You’re talking about maybe 0.01% of your total traffic. It’s completely negligible.
Your security company isn’t looking at your ad revenue dashboard. They’re optimized for maximum security, not maximum business results.
The question isn’t “is this perfectly secure?” (nothing is). The question is “does the business benefit outweigh the minimal security risk?”
In this case, the answer is overwhelmingly yes.
These are real outcomes from publishers who implemented ad verification whitelisting:
Educational content site (500K monthly visits):
Recipe blog (1.2M monthly visits):
Tech news site (300K monthly visits):
The pattern is consistent: massive revenue recovery within 2-3 weeks of properly whitelisting ad verification bots.
Every day you wait costs you money. If your revenue is down and you’re running any kind of bot protection or web application firewall, this is likely your problem.
Here’s your action plan:
Today:
This Week:
Next 2-4 Weeks:
Pro tip: Set a calendar reminder for 30 days out to compare your before/after revenue. When you see the results, you’ll wish you’d done this sooner.
If you’re running website security that blocks bots, and your ad revenue has mysteriously dropped, you’re almost certainly blocking the verification bots that determine how much you get paid.
The solution takes 10 minutes to implement. The revenue recovery can be worth tens of thousands of dollars per year.
Your choice is simple:
The security risk of Option B is minimal. The financial risk of Option A is catastrophic.
What’s it going to be?
If you’re not comfortable editing WAF rules yourself, here are your options:
DIY Route:
Hire Help:
The Nuclear Option: If revenue continues to drop and you can’t figure it out, temporarily disable bot protection entirely for 48 hours. If revenue immediately recovers, you’ve confirmed the diagnosis. Then you can properly implement the whitelist.
Don’t let over-aggressive security settings kill your business. Protect your site AND your revenue.