Ad Network Detector

{{ 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-network detection is a public-page audit, not a revenue report. A publisher page can reveal advertising systems through script URLs, iframes, image beacons, inline calls, tag-manager output, and seller-file declarations. Those traces help operations, privacy, and revenue teams answer a narrower question before they open a full ad-server or consent-platform investigation: which known ad-tech partners are visible from this URL right now, and how strong is the evidence?

The same page can expose several kinds of evidence. A loaded ad script is usually stronger than a loose keyword in markup. An ads.txt seller row supports authorization context, but it does not prove that the seller served an impression on the checked page. A page tag without seller-file support can point to a missing seller declaration, a shared infrastructure trace, or a partner that is authorized through another domain. Reading those clues together prevents a single string match from becoming a false operational decision.

Supply-chain terminology matters because the file and the page answer different questions. ads.txt lets a domain owner declare which advertising systems may sell inventory for the site. DIRECT means the publisher has a direct seller-account relationship with that system, while RESELLER means an authorized intermediary is reselling inventory. sellers.json and SupplyChain data can add identity and path transparency, but a page-level detector only sees the public page response and the seller file it can fetch.

Common ad-network evidence types and their meaning
Evidence	What it can show	What it cannot prove alone
Script, iframe, or inline URL	A known ad partner or ad framework is visible in fetched page markup.	Whether the tag actually won auctions, served impressions, or fired after consent.
Inline keyword or markup trace	Ad-related configuration or dormant code may be present in the page body.	That the partner is active rather than mentioned in copied, delayed, or inactive code.
`ads.txt` seller row	The domain declares a seller domain, account ID, and relationship type.	That the checked page uses that seller, or that account ownership and contracts are correct.
Warning or fetch limit	The scan may have missed part of the public evidence.	That a zero-signal result means the site has no ad stack.

These checks are useful around tag-manager releases, consent-management changes, site migrations, ad-server account updates, and revenue drops that might be tied to demand access. They also help privacy reviews because public ad calls can indicate vendor relationships or data-sharing surfaces that need consent and contract review.

The main limit is visibility. Many tags appear only after consent, geography checks, lazy loading, client-side rendering, auction timing, or user interaction. A clean public fetch on one URL does not prove the whole site has no ad stack, and a detected partner does not prove revenue impact. The result is best used as a triage map before deeper browser, ad-server, analytics, or platform review.

How to Use This Tool:

Choose a public URL that represents the inventory or release you are reviewing. A live article, category page, product page, or landing page with normal ad placements usually gives better evidence than a login screen, sparse homepage, or staging URL.

Enter one Website URL. If several lines are pasted, only the first non-empty URL is scanned and the page warns that extra lines were ignored.
Leave Include ads.txt scan on when seller authorization matters. Turn it off only for a page-markup-only check.
Keep Follow redirects on for canonical hops, short links, and CDN routing. Disable it when you need the first response exactly as submitted.
Keep Validate TLS on for production reviews. Disable it only when the point of the test is a known certificate problem.
Adjust Timeout (ms) and Max page bytes when the result reports slow fetching or truncation. The accepted timeout range is 1,000 to 20,000 ms, and the page byte range is 50,000 to 1,500,000 bytes.
Set Remediation priority to coverage, privacy, or revenue so the Action Queue ranks follow-up work around the review goal.
Select Detect. Read Audit Snapshot first for final URL, status code, redirect count, fetch time, byte warnings, evidence count, and seller-file status.

Use Partner Detections for the ranked partner list, Signal Ledger for the exact evidence behind each detection, ads.txt Ledger for seller rows when available, and the chart tabs for score and supply-path summaries. If there are no detections, repeat the check on a page that is more likely to expose ad placements before treating the result as a clean signal.

Interpreting Results:

High confidence means a partner has strong evidence, several distinct evidence classes, or enough repeated observations to deserve operational review. Medium confidence reaches the pass threshold but should be checked against seller files, tag-manager inventory, or a rendered browser session. Low confidence is weak supporting evidence and should not be treated as a confirmed integration by itself.

How to interpret ad network detector result clues
Result clue	Likely meaning	What to verify next
Page + ads.txt	A known partner appears in the fetched page and a matching seller domain appears in the seller file.	Confirm account ID, relationship type, consent timing, placement ownership, and contract owner.
Page only	The page contains a known tag, call, URL, or keyword, but the parsed seller file does not map to that partner.	Check whether seller authorization is missing, stale, held on another host, or hidden behind a partner that is not in the signature map.
ads.txt only	The seller file declares a known advertising system, but the checked page did not expose matching page evidence.	Decide whether the row supports another section, dormant demand, future demand, or a stale partner that can be removed.
Warnings	Fetch errors, non-HTML content, truncation, seller-file unavailability, or no known signatures may have reduced evidence quality.	Fix the warning condition and rerun the same URL before using the output for revenue, privacy, or vendor decisions.

Detection Scoreboard ranks partners by score, so it is useful for triage but not a measure of revenue, spend, or impression volume. A high score can come from visible tag presence rather than business impact. Supply Path Mix separates direct, reseller, matched, and unmapped seller rows to show whether the seller file is lean, reseller-heavy, or weakly connected to the page evidence.

Zero detections should be read with caution. A server-side public fetch does not use your cookies, scroll the page, approve consent, run a full user session, or guarantee that delayed client-rendered ad code is present in the response body. When the result affects money, privacy, or vendor approval, compare the Signal Ledger with rendered browser evidence, ad-server reports, consent logs, and current seller-file ownership records.

Technical Details:

Ad-network detection is rule-based evidence scoring. The page pass reads the public response body and looks for known ad partner patterns in script sources, iframe sources, image sources, link targets, embedded URLs, inline script text, and markup. The seller-file pass reads ads.txt from the target host, with a host fallback between the bare domain and www form when that is relevant.

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. Each partner is matched through known URL fragments, inline keywords, and seller domains associated with that system.

Formula Core:

The confidence score adds the strongest weight for each distinct evidence class, a diversity bonus for multiple evidence classes, and a small density bonus for repeated observations. Repeated hits in the same class do not keep adding the full class weight.

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 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 context, but it can apply beyond the checked page.
Inline script keyword	2	Inline ad logic is meaningful, but shared names can appear in configuration or inactive code.
Image source, link target, or markup keyword	1	These traces are useful support but weak as standalone proof.

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 still needs manual review.
`< 4`	Low	Warning-level evidence that should not drive partner decisions by itself.

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 preserved for review.

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	Shown for human review because account ownership cannot be confirmed from page markup alone.
`DIRECT` or `RESELLER`	Used in the supply-path view to separate direct paths from reseller paths.
Certification authority ID	Kept when present so the row can be compared with platform or industry records.

Fetch boundaries shape the evidence. The page scan accepts public HTTP and HTTPS URLs on normal web ports, can follow up to six redirects, rejects private or local network targets, and caps the inspected response body at the selected byte limit. The seller-file 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 when very large files are encountered.

Privacy and Accuracy Notes:

The submitted public URL and scan settings are sent to Simplified Tools so the public page and, when enabled, the target site's public ads.txt location can be fetched and analyzed. The scan does not use your browser cookies, logged-in sessions, private dashboards, or ad-platform credentials.

Loopback hosts, private network addresses, link-local addresses, unsupported schemes, and non-web ports are blocked.
Client-rendered tags, consent-gated tags, lazy-load placements, geography-specific auctions, and user-interaction triggers can be missed.
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 truncation warnings are a reason to rerun with a larger byte limit or a more focused page sample.

Worked Examples:

A news article that loads Google Ad Manager tags and has a matching google.com seller row will usually produce a high-confidence Google Ad Manager / DoubleClick detection. The useful follow-up is 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 but no matching seller-file support needs a different review. Prebid.js may show that header bidding is present, while the demand partners behind it may require ad-server, bidder, or rendered auction evidence. The Action Queue should be read as a prompt to reconcile page evidence with authorization records.

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 mean stale partners remained authorized after a migration. The Supply Path Mix helps decide whether the seller file needs partner-by-partner cleanup, especially when reseller rows outnumber direct rows.

A timeout, redirect problem, non-HTML response, or truncation warning makes a zero-detection run weak evidence. Rerun after correcting 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 public 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, 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 indicates a direct seller-account relationship with the listed advertising system. RESELLER indicates that 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 seller relationship path 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.