Ad Network Detector

Advertising technology often leaves several kinds of public evidence on a publisher page. A script may load from an ad-serving domain, an inline configuration may name a header-bidding library, and the site's ads.txt file may declare companies authorized to sell inventory. No single clue tells the whole story, but the clues become useful when they agree.

Page evidence answers a deployment question: which recognized partner signatures appear in the fetched response? Ads.txt answers a different supply-chain question: which seller domains and account relationships the publisher has declared publicly. A tag can appear without an aligned seller row, and a seller row can remain after the corresponding page integration has been removed. Those mismatches deserve review, not an automatic conclusion about fraud or misconfiguration.

DIRECT

The publisher directly controls the seller account identified in the ads.txt row.

RESELLER

Another entity controls the seller account and resells the publisher's inventory.

Detection confidence

A weight derived from the kinds and diversity of matching page or ads.txt evidence. It is not a probability.

A server-side fetch sees the public response returned for one URL at one moment. It does not run the page as a browser, accept consent dialogs, scroll, wait for lazy loading, sign in, or reproduce a particular geography and cookie history. Client-rendered, consent-gated, auction-time, and personalized tags may therefore be absent even when they appear in a real session.

The reverse mistake is also possible. A recognizable string in markup can come from documentation, dormant configuration, a tag manager container, or code that never executes. Strong evidence combines multiple independent sources. Low-confidence evidence is a lead to verify in browser developer tools, tag-management records, consent configuration, and commercial ownership records.

Ad-network detection is most useful after a tag release, publisher migration, consent change, unexplained revenue shift, or routine seller-file review. It cannot measure impressions, fill, auction participation, revenue, consent compliance, or contract validity. Those require runtime and organizational evidence beyond a public page snapshot.

How to Use This Tool:

Choose a representative public page and decide whether the review needs page signatures alone or page-to-ads.txt alignment.

1. Enter one Website URL. Use a page that normally carries the advertising experience under review, not just a home page that may have a different tag set.
2. Select Page + ads.txt for a supply-path review or Page only for a narrower tag inventory. The ads.txt option checks the seller file associated with the final page host.
3. Choose a Review focus. Coverage, privacy, and revenue use the same scan evidence but order and phrase follow-up actions differently.
4. Keep redirects and TLS validation enabled for ordinary checks. Disable either only when the redirect response or a known certificate fault is the object of the investigation.
5. Adjust the timeout or response cap only for a slow or unusually large public page. A truncated result is reported because signatures beyond the cap may be missed.
6. Run the check, then read the partner evidence and seller alignment before acting on the ranked follow-up list. Resolve fetch warnings and weak detections first.

Interpreting Results:

Strong partner evidence found means at least one detection reached the high-confidence band. Partner evidence needs review means detections exist but none reached that band. No recognized partner signals means this response contained no signature in the current rule set; it does not prove that the site carries no advertising.

• High confidence starts at a score of 8, medium at 4, and low below 4. Read the sources and sample evidence because the score is a rule-based strength indicator, not a percentage likelihood.
• A page-only detection has no matching ads.txt source in this scan. Verify whether that partner needs an ads.txt declaration before calling the row stale or unauthorized.
• An unmapped seller row did not match a recognized partner domain. It may be stale, indirect, unsupported by the current signature library, or valid for inventory not visible on the selected page.
• Warnings about redirects, content type, truncation, seller-file availability, or slow fetching reduce confidence in completeness. Rerun with a better target or confirm the page in a real browser.

Technical Details:

The scan retrieves one HTTP or HTTPS response on port 80 or 443. Redirect destinations are checked again, and local, private, loopback, link-local, and other non-public address targets are rejected. The response body is inspected as text; scripts are not executed.

Lookup Core:

Recognized partners are matched against script, iframe, image, link, and inline URL sources plus selected inline-script and markup keywords. When ads.txt is enabled, valid rows are parsed into seller domain, account identifier, relationship, and optional certification-authority identifier. Seller domains are compared with the public domain associations in the partner rule set.

Formula Core:

Each distinct evidence-source type contributes its strongest configured weight once. The score then adds a small bonus for source diversity and evidence density.

S is the confidence score, w_s is the weight for each distinct source type, and E is the number of matched evidence items. The diversity bonus D is 0 for one source type, 1 for two, and 2 for three or more. Scores of at least 8 are high confidence; scores from 4 through 7 are medium; scores below 4 are low.

Rule Core:

The review queue is deterministic. No recognized detection prompts a representative-page check. High-confidence findings add a focus-specific baseline, consent, or ownership action. Page-only findings add an ads.txt reconciliation when seller-file review is enabled. Missing or unmapped seller evidence, scan warnings, and fetches over 2,500 milliseconds add their own follow-ups. When at least half of the detections are medium or low confidence, uncertain evidence is prioritized for resolution.

The page response can be capped from 50,000 through 1,500,000 bytes and the timeout from 1,000 through 20,000 milliseconds. Up to 100 classified partner findings and 1,000 seller rows are carried into the result. These bounds keep the report manageable; they are also completeness limits for unusually large pages or seller files.

Privacy and Accuracy Notes:

The submitted public URL and request settings are sent to a remote service, which fetches the page and optional ads.txt file. The result describes that single public response and remains subject to provider reachability, DNS changes, redirects, TLS state, geography, and page variation.

• Do not submit intranet names, private addresses, authenticated URLs, or URLs containing secrets. Private and local network targets are blocked, but the submitted URL itself is still transmitted for the check.
• Disabling TLS validation can retrieve evidence from a host with a certificate fault, but it also removes identity assurance for that fetch. Treat the response as diagnostic only.
• Ads.txt alignment is based on seller-domain associations. It does not prove account ownership, sellers.json identity, contract status, or live auction participation.
• A clean result is not a privacy or consent audit. Verify real browser requests, consent-mode behavior, tag-manager versions, and regional conditions when those questions matter.

Worked Examples:

References:

• Ads.txt — Authorized Digital Sellers, IAB Tech Lab, updated January 15, 2024.
• Ads.txt 1.1 Implementation Guide, IAB Tech Lab, August 2022.