Ad Network Detector

Ad Stack Snapshot

{{ summaryTitle }} · {{ findingsCount === 1 ? 'network detection' : 'network detections' }} across {{ categoryCount }} {{ categoryCount === 1 ? 'category' : 'categories' }}

{{ statusBadgeText }} HTTP {{ responseCode }} {{ fetchMs }} ms High {{ highConfidenceCount }} Top {{ topCategoryLabel }} ads.txt {{ matchedSellerCount }}/{{ adsTxtSellerCount }} matched Evidence {{ evidenceCount }}

{{ findingsWithAdsTxtEvidenceCount }} detections backed by ads.txt · {{ sellerMatchRateText }}

Website URL:

Enter one public HTTP/HTTPS page URL; only the first non-empty line is scanned.

Ignored {{ extraLineIgnored }} extra line(s). Only the first non-empty URL is scanned in this tool.

Preset target:

Choose Custom before typing your own target; presets are generic public smoke-test pages.

Include ads.txt scan:

Leave on for publisher inventory reviews; turn off for page-only script evidence.

Follow redirects:

Use for short links and CDN redirects; disable to inspect only the submitted URL.

Validate TLS:

Keep on for production audits; turn off only when reviewing a known certificate fault.

Timeout (ms):

Accepted range: 1000-20000 ms; raise for slow origins or lower for fast-failure tests.

Max page bytes:

Accepted range: 50000-1500000 bytes; higher values catch later markup but cost time.

Remediation priority:

Options: coverage quality, privacy governance, or revenue integrity.

Field	Value	Copy
{{ row.label }}	{{ row.value }}
No metrics available.

Network	Category	Confidence	Score	Evidence	Supply Path	Sources	Sample	Copy
{{ row.network }}	{{ row.categoryLabel }}	{{ row.confidenceLabel }}	{{ row.score }}	{{ row.evidenceCount }}	{{ row.supplyPathLabel }}	{{ row.sources }}	{{ row.evidence }}
No known ad-network signals were detected.

Network	Source	Pattern	Value	Copy
{{ row.network }}	{{ row.source }}	{{ row.pattern }}	{{ row.value }}
No evidence available.

Priority	Action	Why now	First move	Cadence	Focus	Copy
{{ row.priority }}	{{ row.action }}	{{ row.reason }}	{{ row.next_step }}	{{ row.cadence }}	{{ row.focus }}
No remediation recommendations available.

Seller Domain	Account ID	Type	Alignment	Cert Authority	Matched Networks	Copy
{{ row.seller_domain }}	{{ row.account_id \|\| '—' }}	{{ row.relationship \|\| '—' }}	{{ row.alignmentLabel }}	{{ row.cert_authority_id \|\| '—' }}	{{ row.matched_networks \|\| '—' }}
No ads.txt seller rows were captured.

No scored detections are available for the scoreboard.

No ads.txt seller rows are available for the supply-path chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Ad monetization leaves a visible trail on most public web pages. A publisher might load Google Ad Manager, Prebid, Amazon Publisher Services, an exchange tag, a native recommendation widget, a retargeting script, or several of these at once. Those partners can appear in script URLs, iframe sources, image beacons, inline JavaScript, and ordinary page markup. A single trace is rarely enough to prove the whole advertising setup, but it can point to the partners that deserve closer review.

The second half of the picture is authorization. For web inventory, ads.txt is the public file where a publisher declares which advertising systems may sell its inventory. Each usable seller row names an advertising system domain, a publisher account ID, a relationship type such as DIRECT or RESELLER, and sometimes a certification authority ID. Buyers and ad platforms use those rows to reduce domain spoofing and unauthorized resale, but the file does not prove that a partner is active on every page.

That distinction matters during ad-stack audits. A tag on the page without a matching seller row can indicate a missing authorization record, a partner configured through another route, or a false match from shared ad-tech infrastructure. A seller row without page evidence can be harmless if the partner is authorized for other sections of the site, but it can also be stale inventory that no longer belongs in the file. The useful question is not only "which network appears?" but "what kind of evidence supports it, and does the public seller record agree?"

Page evidence: Visible tags, URLs, and inline calls found in the fetched HTML for one public URL.
Seller evidence: Rows in ads.txt that map an advertising system domain to a publisher account and relationship type.
Supply-path clue: Whether a detected partner is page-only, seller-file-only, or supported by both kinds of evidence.

Ad-network evidence path from page markup through page signals and ads.txt rows to audit action

Ad-stack checks are especially useful before and after tag-manager changes, consent-management releases, site migrations, ad-server account changes, or a revenue drop that seems tied to demand access. They are also useful for privacy reviews because page-level ad calls can indicate data-sharing surfaces that need consent, vendor-list, or contract review.

The important limit is that public-page evidence is a snapshot, not a full ad-operations report. Many ad tags fire only after consent, geography, device type, auction state, lazy loading, or user interaction. A clean result on one URL does not prove the whole site has no visible advertising stack, and a seller row in ads.txt does not prove that the partner served an impression on the checked page.

How to Use This Tool:

Start with a public page that represents the inventory you care about. A live article, category page, or product page usually gives better evidence than a login screen, dashboard, staging URL, or sparse homepage.

Enter one Website URL. If you paste several lines, only the first non-empty URL is scanned and the rest are ignored.
Leave Include ads.txt scan on when you need seller authorization context. Turn it off only when you want a page-markup pass without seller-file review.
Keep Follow redirects on for canonical URL hops, short links, and CDN routing. Turn it off when you need to inspect the first response exactly as requested.
Keep Validate TLS on for production audits. Disable it only when you are intentionally testing a site with a known certificate problem.
Adjust Timeout and Max page bytes if the result warns about slow fetching or truncation. Larger byte limits can find later markup, but they can also make the scan slower.
Set Remediation priority to coverage, privacy, or revenue so the Action Queue ranks follow-up work around the review goal.

Read the Audit Snapshot first for status, final URL, response code, redirect count, byte limit warnings, evidence count, and ads.txt status. Then use Partner Detections for the partner list, Signal Ledger for the exact evidence, Action Queue for next steps, and the chart tabs for a quick score and seller-mix view.

If the check fails or returns no detections, verify that the URL is public, uses HTTP or HTTPS on a normal web port, and does not depend on your browser login. For a zero-signal run, try a page with real ad placements before deciding that the site has no visible advertising stack.

Interpreting Results:

High confidence means the detected partner has strong evidence, several evidence classes, or enough repeated observations to treat it as a serious lead. Medium confidence starts at the pass threshold and usually deserves manual review. Low confidence is weak evidence, not a confirmed integration.

How to interpret ad network detector result fields
Result clue	What it usually means	What to verify next
Page + ads.txt	Partner evidence appears in the fetched page and a matching seller domain appears in `ads.txt`.	Confirm the account ID, relationship type, contract owner, and whether the partner may fire before consent.
Page only	The page contains a known tag, call, or URL pattern, but no matching seller row was found in the parsed seller file.	Check whether the partner is authorized through another domain, missing from `ads.txt`, or only a faint shared-infrastructure trace.
ads.txt only	The seller file authorizes a known advertising system, but the checked page did not expose matching page evidence.	Decide whether the row supports other pages, future demand, or a stale partner that can be removed.
Warnings	Fetch issues, non-HTML content, truncation, ads.txt unavailability, or no known signatures may have reduced evidence quality.	Fix the warning condition, rerun the same URL, and compare the evidence count before opening tickets.

The Detection Scoreboard ranks the top detected partners by score, so it is useful for triage but not proof of revenue importance. A high score can come from tag visibility rather than impression volume. The Supply Path Mix separates matched and unmapped seller rows by relationship type, which helps distinguish direct-seller coverage from reseller-heavy files.

A false sense of certainty is the main risk. Public HTML checks can miss tags injected after consent, delayed auctions, geo-specific demand, or client-rendered placements. When the result affects revenue, privacy, or vendor approvals, compare the Signal Ledger with ad-server reports, tag-manager inventory, consent logs, or a rendered browser audit.

Technical Details:

Ad-network detection here is a rule-based comparison between fetched page evidence and declared seller evidence. The page pass inspects the public response body for script sources, iframe sources, image sources, link targets, URLs embedded inside inline scripts, inline script text, and general markup. The seller pass reads ads.txt from the checked host, with a fallback between the bare host and www host when appropriate.

The recognized partner set covers common ad-serving, header-bidding, exchange, native-ad, retargeting, measurement, and video-ad systems. Examples include Google AdSense, Google Ad Manager / DoubleClick, Amazon Publisher Services, Prebid.js, Media.net, Criteo, Taboola, Outbrain, PubMatic, OpenX, Magnite / Rubicon, Index Exchange, Sovrn / Lijit, Xandr / AppNexus, Teads, AdRoll, and PubNative / Verve Group. The matcher looks for known URL fragments, inline keywords, and seller domains associated with those systems.

Formula Core:

The confidence score combines distinct evidence classes, an evidence-diversity bonus, and a small density bonus for repeated observations. Repeated hits in the same class do not keep adding the full class weight; they mainly affect the density bonus.

score = \sum_{s \in S} w (s) + b_{d} + \min (2, ⌊ \frac{n}{3} ⌋)

In the formula, S is the set of distinct evidence classes found for one partner, w(s) is the class weight, b_d is 2 when three or more classes appear, 1 when two classes appear, and 0 otherwise, and n is the total evidence count for that partner.

Evidence weights used for ad network confidence scoring
Evidence class	Weight	Reason for the weight
Script source, iframe source, or inline URL	4	A loaded ad script, frame, or embedded URL is a strong page-level signal.
`ads.txt` seller row	3	A seller declaration supports authorization, but it may apply beyond the checked URL.
Inline script keyword	2	Inline ad logic is meaningful, but shared names can appear in configuration or dormant code.
Image source, link target, or markup keyword	1	These traces are useful support but are weak by themselves.

Confidence boundaries for ad network detections
Score range	Confidence label	Status behavior
`>= 8`	High	Pass-level detection with strong supporting evidence.
`4-7`	Medium	Pass-level detection that needs review before operational decisions.
`< 4`	Low	Warning-level evidence that should not be treated as confirmed partner activity.

Rule Core:

The seller-file parser ignores blank lines and comments, then reads comma-separated rows with at least three fields. The advertising system domain is lowercased, the relationship type is normalized to uppercase, and the optional certification authority ID is kept when present.

ads.txt row fields used during ad network review
ads.txt field	How it affects the audit
Advertising system domain	Matched against known seller domains for each recognized partner.
Publisher account ID	Displayed for human review because account ownership cannot be confirmed from page markup alone.
`DIRECT` or `RESELLER`	Used in the seller-mix view to separate direct paths from reseller paths.
Certification authority ID	Preserved when present so the row can be compared with platform or industry records.

Fetch limits also affect what can be proven. The public page scan accepts ordinary HTTP and HTTPS web URLs, follows up to six redirects when enabled, rejects private or local network targets, and caps the inspected response body at the selected byte limit. The ads.txt scan follows a shorter redirect path, has its own response-size limit, parses up to 5,000 seller rows, and displays up to 1,000 rows in the result when very large files are encountered.

Privacy and Accuracy Notes:

The submitted public URL and scan settings are sent to Simplified Tools for public-page retrieval and analysis. The check contacts the target page and, when enabled, the target site's public ads.txt location. It does not use your browser cookies, logged-in sessions, private dashboards, or ad-platform credentials.

Private network hosts, loopback addresses, link-local addresses, non-web ports, and unsupported schemes are blocked.
Client-rendered tags, consent-gated tags, delayed lazy-load placements, and geography-specific auctions can be missed because the check focuses on fetched public HTML.
ads.txt alignment is domain-based. It does not validate sellers.json identity, OpenRTB SupplyChain objects, publisher account ownership, or contract status.
Very large pages or seller files can be truncated, so treat truncation warnings as a reason to rerun with a larger byte limit or a narrower page sample.

Worked Examples:

A news article that loads Google Ad Manager tags and has a matching google.com seller row will often produce a high-confidence Google Ad Manager / DoubleClick detection. In that case, the follow-up is usually to confirm the publisher account ID, consent timing, and placement ownership rather than to prove that Google appears at all.

A page with Prebid.js evidence and no matching seller-file support is a different case. Prebid itself may be visible as a header-bidding framework, while the demand partners behind it may require separate review in the ad server, bidder configuration, or rendered auction logs. The Action Queue should be read as a prompt to reconcile page evidence with authorization records, not as an automatic accusation of misconfiguration.

A seller file with many reseller rows and little page evidence can be legitimate for a large publisher with multiple demand paths. It can also be a sign that stale partners remain authorized after a migration. The Supply Path Mix helps decide whether the file needs partner-by-partner cleanup, especially when reseller rows outnumber direct rows.

A fetch that returns no detections after a timeout, redirect warning, or truncation warning is not a reliable clean bill. Rerun the same URL after fixing the warning, then compare the Audit Snapshot evidence count and Signal Ledger before closing the review.

FAQ:

Does this measure revenue, fill rate, or ad quality?

No. It detects page-level ad-network signals and seller-file alignment. Revenue, fill, viewability, auction participation, and ad quality require ad-server, SSP, bidder, or analytics reports.

Why did it find a partner in ads.txt that is not on the page?

An ads.txt row authorizes selling for the domain, but it does not prove that the partner is active on the checked URL. The row may support another section of the site, dormant demand, or a future integration.

Why did it find a page partner with no ads.txt match?

The page can expose a tag or shared ad-tech URL even when the seller file does not contain a mapped seller domain. Review the Signal Ledger, then compare the partner with contracts, ad-server setup, and the current seller file.

Why are there no detections on a site that definitely runs ads?

The checked URL may not load ads in the fetched HTML, or ads may appear only after consent, scrolling, client-side rendering, geography checks, or auction timing. Try a representative content URL and inspect warnings before trusting a zero-signal result.

What does DIRECT versus RESELLER mean?

DIRECT means the publisher has a direct account relationship with the listed advertising system. RESELLER means another authorized seller is reselling the publisher's inventory through that system.

Glossary:

ads.txt: A public Authorized Digital Sellers file used by web publishers to declare which advertising systems may sell their inventory.
Advertising system domain: The exchange, supply-side platform, or ad system domain listed at the start of an ads.txt seller row.
DIRECT: An ads.txt relationship type indicating that the publisher directly controls the listed seller account.
RESELLER: An ads.txt relationship type indicating that another authorized entity resells the publisher's inventory.
Signal Ledger: The evidence list showing which partner, evidence class, pattern, and value contributed to each detection.
Supply path: The chain of seller relationships used to sell an ad opportunity, often reviewed through page evidence, ads.txt, sellers.json, and SupplyChain data.

References:

Ads.txt - Authorized Digital Sellers, IAB Tech Lab.
Ads.txt 1.1 Implementation Guide, IAB Tech Lab.
Sellers.json Supply Chain Transparency, IAB Tech Lab.
Create ads.txt/app-ads.txt in Ad Manager, Google Ad Manager Help.
Authorized Digital Sellers, Google Display & Video 360 Help.