Authorized selling, on the big screen.

01Why CTV needs app-ads.txt

Television supply is valuable and comparatively opaque, which is precisely the combination spoofing thrives on. A bid request claiming to be your channel can reach buyers without your knowledge, and CTV CPMs make each forged impression expensive. The fix is the same spec as mobile: a text file at your developer domain listing authorized sellers. Buyers crawl it, platforms that enforce authorized selling filter against it, and the same enforcement applies: on Sky Boosts, TV bid requests are checked against the declarations before entering the auction.

02Where the file is discovered from

Each TV platform's developer portal exposes a developer website field, and that field starts the crawl. Where to set it:

• Google TV and Android TV: Play Console, the app's store listing. The website field behaves exactly as on mobile.
• Roku: the Roku developer portal, on the channel listing. Set it when the channel is published and re-verify after any republish.
• Amazon Fire TV: the Amazon developer console, in the app's catalog information.
• Samsung and LG: their respective seller portals; the field placement and naming differ per portal, and both are confirmed during CTV onboarding rather than guessed.

03Hosting the file

The requirement is identical to mobile: root of the domain, UTF-8 text/plain without BOM, served over HTTPS. Channel operators with no real website solve it the same way: put a minimal site on a domain you control. A single static page with the company name and the file beside it is enough; nobody is grading the design. What does not work: hosting on a platform page you do not control, or pointing the website field at a social profile.

04Multi-store consistency

One domain, many stores, one file: the bookkeeping is the actual work. Keep a record of every store listing you operate and the website field each one carries. When all fields point at one domain, one file covers the portfolio. When one store points at a legacy domain, that domain needs its own file or a redirect, and an audit will eventually find the gap. Review the mapping after every new channel launch and every store migration.

Worked example. An operator runs the same cooking channel on Google TV, Fire TV and Roku, under one company, examplemedia.com. The correct setup: all three store listings point their developer website fields at examplemedia.com, and one file at examplemedia.com/app-ads.txt authorizes every SSP the operator sells through, with one account ID per system. The failure modes this setup prevents: the Roku listing still pointing at the old studio domain from launch day; the Fire TV listing carrying a www subdomain that serves a different file than the apex; and the Google TV listing updated last quarter, whose republish quietly cleared the website field. Each of the three is a total authorization failure for one third of the channel's distribution, and none of them shows an error anywhere the operator would naturally look.

05Crawl behavior differences

What differs from mobile crawls: TV listings are sometimes fetched less frequently, so propagation after a file change can take longer than the daily cycle mobile buyers run; some platform portals cache the listing page itself; and several TV crawls resolve the website field literally, with no fuzzy matching, which turns a www versus apex inconsistency into a total miss. The practical response is to serve the file identically on both hostnames and let no redirect chain exceed one hop.

Canonicalization follows the app-ads.txt spec: www and m prefixes are stripped, but a genuine subdomain stays what it is. A listing pointing atapps.example.com is crawled at apps.example.com/app-ads.txt, and only if no file exists there does the verifier fall back to the parentexample.com file. If your channels point at a subdomain, that subdomain needs its own file.

06Verification

1. Fetch https://your-domain/app-ads.txt and the www variant directly. Expect instant plain text.
2. Check the website field on each TV platform portal against the domain, entry by entry, exactly as written.
3. Run the public checker on each store listing in your portfolio, per platform.
4. Re-run after republishes: platform portals have been known to clear fields on channel updates, which silently ends discovery.

07Common failures

• Empty website fields. The most common TV failure, because several platform flows do not require the field. Nothing resolves; buyers see an unverifiable channel.
• Redirect services. Website fields pointing through link shorteners or marketing redirectors break resolution or land somewhere that cannot carry the file.
• Per-store inconsistencies. Roku says www.example.com, Fire TV says example.co.uk, and neither carries the file. Consolidate to one domain.
• Cleared fields after updates. A republish that resets the website field ends discovery until someone notices fill move. Monitoring catches this; spot checks do not.

08For buyers

How a demand partner validates a TV supply path: resolve the channel's listing website field per platform, fetch app-ads.txt from that root, confirm the seller line against the account ID, cross-check the SSP's sellers.json for the same account, and read the schain node on the bid request as the live confirmation. That chain is the whole path. A partner that skips the first three steps is trusting the fourth, which is exactly what the chain exists to avoid.