| Where to Look | What You Are Checking | What a Hit Likely Means |
|---|---|---|
| Page source (with JavaScript disabled) | Script tags, iframes, ad codes pointing to domains that are not yours | Injected client-side script, often the first visible sign |
| Remote scanner (SiteCheck) | Blocklisted domains, suspicious redirects, and known injection signatures | Confirmed malicious resource loading on your pages |
| ads.txt at your domain root | Authorization lines you did not add | Someone is routing your ad inventory or revenue to an account that is not yours |
| Theme files and database (functions.php, mu-plugins, wp_options) | Code you did not write, especially self-restoring entries | Server-side compromise with persistence built in |
| Search Console Security Issues | Google’s own flags for hacked or harmful content | Google has already detected a problem that visitors may be seeing |
How to Detect Adware Injection on Your Website
A reader messages you to say your site tried to give them a virus warning. Another sends a screenshot of double-underlined ad links pasted through your article text, links you never added and cannot find anywhere on the page yourself. You open the page and see nothing wrong.
Then you check your earnings and notice they slipped last week, even though your traffic held steady.
That gap, between what your visitors see and what you see, is where adware injection lives. Someone is putting ads, redirects, or fake warnings on your pages that you never placed, and it’s earning money for someone who isn’t you.
You are paying for it in trust, in user experience, and sometimes in the ad revenue that should have been yours.
Finding it is the hard part. Injected ads are built to stay hidden from the one person most likely to remove them: you. This guide is for publishers who want a reliable way to confirm whether their site has been hit, work out where the injection is coming from, and read the signals that point to the answer.
Contents
Key takeaways
- Strange ads, redirects, and links you never placed come from one of three places: your site is hacked, the visitor’s browser has adware, or a cloaked ad slipped through a weak ad source. Each is found differently.
- Test by trying to reproduce it. Open your site on a clean device and a different connection, like mobile data. If everyone sees it, it is on your site. If only some do, it is the visitor’s device or a cloaked ad.
- Check your
ads.txtfile first. In one case found by the security firm Sucuri, attackers rewrote it to insert their own ad account and skim the revenue. It takes a minute to read. - Your site is the part you control and can fix: view source with scripts off, run a scanner, check your theme files and database, and watch Google Search Console for security flags.
- Cloaked ads only show under set conditions, so they are hard to reproduce, and the network you run matters. Strict moderation, before and during a campaign, plus anti-cloaking, keeps them off your pages.
What Injected Ads Actually Look Like on a Site
Many publishers meet this problem through a complaint: a visitor reports a full-screen ad that reopens when closed. Someone on mobile gets bounced to an app store page they never tapped. A reader sees a fake “your device is infected” banner with your logo above it. From their side, it reads the same: your site did this.
Behind those symptoms lie a few mechanisms; the term for this category is adware.
In a publisher context, adware is any code that displays, redirects, or replaces advertising for someone else’s benefit without your consent.
It can be a script injected into your pages. It can be an extension running in a visitor’s browser. It can be a single advertiser’s creative that behaves differently in review and in the wild.
The reason the category gets underestimated is that the three mechanisms look identical to the person complaining, but they need completely different responses. Treating “adware on my site” as a single problem is how publishers end up cleaning files when the issue is in a visitor’s browser, or blaming a visitor when the issue is a tampered theme file.
The First Question: Is It Your Site, the Visitor’s Device, or an Ad?
Before you touch a single file, answer one question: Can you reproduce the bad behavior? The answer sorts the problem into one of three buckets, each with a different owner.
- If you can reproduce
If the injected ad or redirect shows up for everyone, on a clean device and with a different internet connection (mobile data or another location via VPN), it is almost certainly on your site. Server-side injection does not care who the visitor is. It renders the same way every time, which means you can see it too once you look the right way.
- If you cannot reproduce
If you cannot reproduce it on a clean machine, but specific visitors keep hitting it, the problem is likely on their side. Adware on a visitor’s device, usually a browser extension, injects ads into whatever page that person loads, including yours. You did nothing to cause it, and there is no file on your server to clean. This is the case most likely to be misdiagnosed.
- Only appears under certain conditions
The third bucket is the trickiest. The behavior is real, it comes through your ad slot, but it only appears under certain conditions: on mobile but not desktop, for visitors arriving from search but not direct, in one country but not another.
That selective behavior is the signature of a cloaked ad, an ad that shows clean content during review and swaps in something else for a slice of real users. HUMAN’s explainer on ad cloaking describes the technique in detail.
Where Is the Injection Coming From?
One test sorts the problem, and tells you who owns the fix.
Visitors report injected ads, pop-ups, or forced redirects
Can you reproduce it on a clean device + different connection?
Yes → It’s your site
Server-side injection
It renders the same for everyone, so you can see it and clean it.
- View source with JavaScript off
- Scan with SiteCheck / VirusTotal
- Read your ads.txt line by line
- Check theme files + database
- Check Search Console security issues
You own the fix
No → Conditional?
Cloaked ad through an ad source
Shows only on mobile, only from search, or only in certain countries. Clean in review, harmful in the wild.
- Invisible during moderation
- Hard to trigger yourself
- Depends on how strictly the source moderates
The ad source’s moderation owns the fix
No & not conditional
Adware on the visitor’s device
A browser extension injects ads into every page that visitor loads, including yours.
- Follows the user across sites
- No server-side fix exists
- Document the pattern, reassure readers
Largely out of your reach
This sorting step matters because it tells you where to spend your time. The next three sections walk through each bucket in turn.
Detecting Injection on Your Own Site
This is the bucket you control, so start here whenever the behavior reproduces.
Website compromise is common enough that it should be your first suspicion: Sucuri’s scanner detected 822,651 websites infected with malware during 2024, and ad and redirect injections were a large share of that.
Begin with the page source. Open your page, view the raw HTML, and look for script tags, iframes, or ad codes you do not recognize, especially ones pointing to domains that are not yours.
A useful trick is to disable JavaScript and reload. Injected scripts often hide behind obfuscation that only unpacks when the page runs, so comparing the static source against the rendered page can surface code that appears out of nowhere.
Then run a remote scan. Sucuri’s free SiteCheck loads your site the way a visitor would, and flags scripts served from blocklisted domains, suspicious redirects, and known injection patterns.
A remote scanner can still miss an injection that only shows up for certain visitors, so a clean result is reassuring but not the final word. Pair it with a look at Google’s Safe Browsing status for your domain and a VirusTotal check on any URL you are unsure about.
Now check the file that rarely gets checked: your ads.txt. This is the file at your domain root that lists the ad accounts authorized to sell your inventory.
A 2025 campaign documented by Sucuri as “ad-jacking” did something clever and quiet: it injected the attacker’s own AdSense code into compromised sites. It rewrote each site’s ads.txt to keep the attacker’s ad network authorized, so the attacker collected the revenue instead of the publisher.
Open your ads.txt and confirm every line is one you added. Any entry you do not recognize is a red flag. If you work with an ad network, you should be able to match each authorization line to one that the network gave you to add. The IAB Tech Lab specification for ads.txt explains how the file is meant to be structured.
On a CMS like WordPress, the injected code usually lives in a handful of predictable places. The same Sucuri investigation found it in the theme’s functions.php file, in the mu-plugins directory, and stored in the wp_options table, so it could regenerate itself even after a file-level cleanup.
A more recent Sucuri case from October 2025 described third-party scripts loading across a site that the owner never installed. If your own scan turns up something, assume it may have more than one hiding spot.
Finally, let Google tell you what it sees. The Search Console Security Issues report flags hacked content, malware, unwanted software, and social-engineering pages, and Google emails verified site owners when it detects a problem. If you have not verified your site in Search Console, do that today. It is one of the few systems that watches your site from the outside and tells you directly.
Read these together. A clean remote scan plus a strange ads.txt line plus a Search Console flag is a far stronger signal than any one of them alone.
When the Problem Is on the Visitor’s Side
Sometimes you do everything above, and your site comes back clean, but the complaints keep arriving. This is the case publishers find most frustrating, because the cause sits on a device you will never touch.
Adware that runs in a visitor’s browser, most often as an extension, injects ads into every page that person visits. Your site is just one of them. The visitor sees ads layered over your content, or a redirect when they click, and they blame the site they were on, which is you. You cannot reproduce it on a clean machine because the code is not on your server. It travels with the visitor.
What you can do is confirm the pattern and respond well. If reports cluster around users who describe the same extension, the same browser, or the same “deal finder” or “coupon” tool, that points to device-side adware rather than your site. A short help-page note that explains the difference, and suggests the reader audit their browser extensions, protects your reputation without claiming a fix you cannot deliver.
The clearest sign is consistency: device-side adware follows the user across sites, so a reader who sees it on your pages is likely to see it everywhere.
Your reach ends here. You can spot the pattern and reassure your readers, but removing the adware is something only the visitor can do, on their own device.
When the Ad Itself Is Cloaked, and Why Your Network Choice Sets How Often It Happens
The third bucket is the ad that passes review and then misbehaves for a slice of real users. This is the risk that rides in through barely vetted ad sources: the kind that will run almost any campaign for quick money and never check it again.
Picture a publisher monetizing through one of them. An advertiser submits a clean landing page, gets approved, and then uses cloaking to serve a fake virus alert only to mobile visitors arriving from search, in two or three countries. Desktop looks fine. The publisher’s own checks look fine. A real subset of readers gets hit, and the source that placed the ad does nothing about it.
That selective behavior is the whole point of cloaking, and it is why this bucket resists the reproduction test.
The clean version is what you and the moderators see. The harmful version is reserved for users who match the attacker’s filter. From your dashboard, the only hints are indirect: a spike in complaints from one platform or country, a bounce rate jump on mobile, or readers describing a redirect you cannot trigger yourself.
This is where the network whose tag sits on your site does most of the work, long before you ever see a symptom. Every serious ad platform prohibits malware, scareware, and deceptive ads in its policy.
What separates them is enforcement: how thoroughly each one reviews campaigns, how fast it catches new tricks, and whether it keeps watching after a campaign goes live.
Cloaking specifically is defeated by moderation that does not stop at the first review.
Monetag, for example, describes its approach to publisher protection as a full-time policy team that reviews each campaign before and during its run, a defined reject list that includes malware, scareware, and fake tech support, 24/7 automated anti-fraud and malware tools, and an in-house anti-cloaking tool that monitors destination URLs across the whole life of a campaign, not just at submission.
The practical point for detection is this: if your site is clean and the bad behavior is conditional, the fix is not on your server. It belongs to whoever is moderating the ads on your pages. On a strict feed, cloaked ads are caught at review or pulled mid-campaign before most of your readers ever see them. That is the protection you choose when you decide whose tag goes on your site.
Three Sources of Injected Ads, and How Each One Renders
Match what you observe to the right source before you start cleaning.
You can act on this
Your Site
Who sees it
Everyone, every time
Where it shows
In your page source
Clean device
Still there
Detect by
View source, scan, ads.txt, files
You own the fix
Mostly out of reach
Visitor’s Device
Who sees it
Only affected visitors
Where it shows
Their browser, across all sites
Clean device
Cannot reproduce
Detect by
Clustered reports, same tool/extension
Reassure and document
Network’s job
Cloaked Ad
Who sees it
Only under set conditions
Where it shows
Mobile, from search, certain GEOs
Clean device
Hard to reproduce
Detect by
Indirect: complaint + bounce spikes
The ad source’s moderation owns the fix
First test for all three: try to reproduce it on a clean device and a different internet connection.
A Detection Routine You Need to Keep Your Profits Safe
The checks above become a routine once you stop treating them as one-time emergencies.
Start with reproduction. Open your site on a device and network you do not normally use, ideally on mobile and from a search result rather than a bookmark, since that is the path cloaked ads target. If nothing odd appears, log out and try again, as some injections skip logged-in admins by design.
If the behavior reproduces, work your own site top to bottom: view source with JavaScript disabled, run SiteCheck, read your ads.txt line by line, check your theme files and database for code you did not add, and look at the Search Console Security Issues report.
If the behavior does not reproduce but reports persist, gather details from the affected readers (device, browser, extensions, country, how they arrived) and use them to distinguish device-side adware from a cloaked ad.
Keep a baseline so anomalies stand out. Note your normal earnings range, your normal bounce rate by device, and your normal complaint volume.
Injected ads and revenue diversion show up as drift against that baseline before anyone files a complaint. A week where earnings fall while traffic holds is worth an ads.txt check on its own.
And keep your foundation tight, because much server-side injection enters through a known door. Keep your CMS, themes, and plugins updated, use strong, unique admin passwords with two-factor authentication, remove plugins and themes you do not use, and avoid nulled or pirated themes, which are a frequent source of malware.
Key Takeaways for Publishers
Start every investigation with the reproduction test. It sorts the problem into your site, the visitor’s device, or a cloaked ad faster than any tool, and it tells you who owns the fix before you waste time in the wrong place.
Treat your own site as the part you control and can clean: view source with scripts off, scan remotely, read your ads.txt, check theme files and the database, and verify your site in Search Console so Google can warn you directly.
Accept that two of the three sources are not yours to clean. Device-side adware leaves with the visitor, and cloaked ads are caught upstream by moderation. For those, your leverage is reading the signals correctly and choosing an ad source whose enforcement actually keeps them off your pages.
Frequently Asked Questions
How do I know if injected ads are coming from my site or from the visitor’s browser?
Try to reproduce the behavior on a clean device and a network you do not normally use. If the bad ad or redirect shows up for you, too, it is on your site, and you can fix it. If you cannot reproduce it, but specific visitors keep hitting it, the cause is usually adware in their browser, which travels with them across every site they visit, not just yours.
Why would my ad earnings drop if my traffic is steady?
One documented cause is ads.txt tampering. Attackers who compromise a site can insert their own ad account into your ads.txt and inject their ad code, so impressions on your pages pay them instead of you. Read your ads.txt and confirm every authorization line is one you added. Unexplained revenue drift against steady traffic is a strong reason to check.
What is the fastest single check I can run right now?
Open your ads.txt file at yourdomain.com/ads.txt and read it line by line. It takes a minute, it is where revenue-diverting injection hides, and many publishers never look at it. After that, run your domain through Sucuri SiteCheck and check the Search Console Security Issues report.
A visitor said my site gave them a virus warning, but I see nothing wrong. What do I do?
First, reproduce it on a clean device, logged out, on mobile, and from search. If you cannot trigger it, the warning was probably a cloaked ad shown only to certain users, or adware on that visitor’s own device. Gather details from the visitor (device, browser, country, how they arrived) to tell the two apart, and if it points to an ad, flag it to whoever moderates the ads on your site.
Does the ad network I use actually affect how often this happens?
For cloaked ads, yes. Every legitimate platform bans malicious ads in policy, so the real difference is enforcement: whether campaigns are reviewed before and during their run, whether there is active anti-cloaking, and how fast bad campaigns are pulled. A feed with strict, ongoing moderation keeps conditional bad ads off your pages that a loosely moderated source would let through.
