What ads.txt means
Ads.txt is a public text file through which a website publisher declares the advertising systems and seller accounts authorized to sell its digital advertising inventory. The name refers to authorized digital sellers. Buyers and intermediaries can inspect the declaration when evaluating whether a selling relationship is consistent with the publisher's stated authorization.
The file addresses a specific supply-chain question: who is authorized to sell this inventory? It does not certify that every impression is genuine, viewable, suitable, or effective. It also does not create an advertising placement or replace the publisher's commercial agreements. A correct file is one part of a transparent programmatic setup, not a complete advertising-quality solution.
For a publisher, the practical responsibility is to keep the declaration accurate, reachable, and aligned with real relationships. Copying a large list from another website can authorize accounts that have nothing to do with the publisher and defeat the purpose of the file.
Understand the problem the declaration addresses
Digital advertising can involve several parties between the publisher and the final buyer. A buyer receiving an inventory claim needs a way to check whether the represented selling account has the publisher's authorization. Without a clear declaration, it is harder to distinguish legitimate relationships from unsupported claims about access to a property.
Ads.txt makes that authorization statement publicly inspectable. The publisher controls the declaration associated with its website, while buyers and platforms can compare offered inventory with the listed relationships. This adds useful evidence to supply-chain evaluation, but it does not eliminate the need for other checks.
Consider a hypothetical publisher, Northfield Journal, that works with two selling partners. Its file should reflect those actual arrangements and the relevant account identifiers supplied through verified channels. A third company asking to be added should provide a clear business reason and evidence of the relationship. The request is an authorization decision, not merely a harmless technical line to paste into a file.
Read the basic fields in a seller record
A basic seller record contains the advertising system's domain, the relevant seller account identifier, and the relationship type, with an optional certification-authority identifier. The fields are comma-separated. A fictional illustrative record is: exchange.example, publisher-123, DIRECT. The domain and identifier here are examples, not values to copy into a live file.
The advertising-system domain identifies the system involved in the selling relationship. The account identifier must match the account used within that system. A small typo can make an otherwise plausible-looking record refer to the wrong account or fail to match the offered inventory.
Treat each field as meaningful. Do not replace an identifier with a company name because it looks more readable, or assume that two similarly named accounts are interchangeable. Obtain the exact authorized record from a verified partner source and confirm it against the business relationship. Human-readable internal notes can explain the record, but the public declaration needs the correct technical values.
Distinguish DIRECT from RESELLER accurately
The relationship field distinguishes whether the publisher directly controls the listed account on the advertising system or has authorized another entity to control that account and resell its inventory. DIRECT and RESELLER describe that account relationship. They are not simple quality grades, and DIRECT does not automatically mean a transaction has no other technical participants.
Choose the value based on the actual arrangement, not on which label sounds more desirable to buyers. If the publisher does not control the account, marking it DIRECT can misrepresent the relationship. Conversely, a legitimate reseller relationship should be described accurately rather than omitted merely because it adds an intermediary.
Ask the partner to explain the account ownership and authorization if there is uncertainty. Keep the explanation in the internal record so future operators do not reinterpret the label from memory. Accurate relationship classification makes the declaration useful; a file that uses the same label for every partner without checking the underlying arrangement creates avoidable ambiguity.
Collect records through a controlled intake process
Create an inventory of active selling relationships before editing the file. For each partner, record the business owner, verified contact, relevant property, account identifier, requested record, and reason for authorization. Include any reseller relationships that are genuinely part of the agreed setup, but do not accept an unexplained bulk list simply because a partner says it is standard.
Verify requests through a trusted channel. A message claiming to come from a partner can be mistaken, outdated, or unauthorized. Cross-check with the established account or contact when the change is material. The process should be proportionate, but publishing authority should not depend on whoever happens to send the latest spreadsheet.
Separate commercial approval from technical validation. A syntactically valid line can still authorize an inappropriate account. Conversely, an approved relationship can be entered incorrectly. Both checks are needed. Keep a short change record identifying who approved the relationship, who implemented the record, and when it should be reviewed.
Publish the file where crawlers can retrieve it
For a typical website setup, the file is made available at the site's root ads.txt path, such as https://publisher.example/ads.txt. It should be served as readable plain text rather than a styled page, login screen, or application error. The public response is what matters, not merely the presence of a file somewhere in the content-management interface.
Website architecture can complicate publication. A single-page application may return its normal HTML shell for an unknown path, making the URL appear reachable while the content is wrong. Redirects, host variations, access controls, and caching can also affect what a crawler receives. Confirm the actual response after deployment.
Follow the applicable technical rules for complex domain or subdomain arrangements rather than improvising from a simple example. If several teams manage different properties, document which file controls which inventory and who owns updates. A clear ownership map prevents one site's deployment from accidentally removing or replacing another team's authorization records.
Validate content and delivery separately
Check the syntax of each record, including the number of fields, relationship value, and account identifier. Inspect duplicates and contradictory entries. A duplicate may be harmless repetition, but it can also signal that several teams are maintaining different versions of the same relationship. Resolve the underlying ownership problem rather than merely deleting lines until a validator is quiet.
Then check delivery. Retrieve the public URL in a clean context, inspect the status and response body, and confirm that the deployed content matches the approved file. Test relevant host variations and any intended redirects. A valid local file does not help buyers if the production server returns an error or an unrelated page.
Finally, compare the record with partner-side information where available. Syntax validation cannot prove that the account exists, that the publisher controls it, or that the authorization is commercially appropriate. A complete validation process combines file structure, public accessibility, and relationship verification instead of treating a green technical check as the entire job.
Work through an authorization cleanup example
Suppose a publisher's internal review finds twelve public records. Six belong to active direct accounts, three belong to approved reseller relationships, two are exact duplicates, and one belongs to a former partner whose authorization has ended. The team should confirm these classifications before making changes, then remove the duplicates and the obsolete authorization under its change process.
The resulting nine active records do not automatically prove that the supply chain is perfect. They simply represent a more accurate declaration based on the verified relationships. The review should also confirm account identifiers, relationship types, and public delivery. Keep the previous version so an accidental removal can be investigated and reversed promptly.
Monitor partner feedback after publication. A legitimate partner may reveal that an apparently obsolete record still supports an agreed route, in which case the commercial facts need resolution. Do not restore a line solely to silence a warning. Determine whether the relationship remains authorized, then update the declaration and internal register consistently.
A useful review note might state that the former partner was removed because its agreement ended on a recorded date, with confirmation from the commercial owner. That explanation is more durable than a commit message saying cleaned up file. If revenue changes afterward, the team can assess whether the intended relationship ended or whether an unintended route was affected. Clear records make troubleshooting faster without preserving obsolete authorization indefinitely out of fear of changing anything.
Connect ads.txt with broader supply-chain evidence
Ads.txt is one part of an ecosystem of transparency information. Sellers.json provides information about seller accounts in advertising systems, while transaction-level supply-chain information can describe participating intermediaries. These mechanisms address related questions from different positions in the chain. Consistency between them can support investigation of who is selling what through which route.
A publisher's authorization should therefore be reviewed alongside the partner's representation of the account where relevant. An unexpected mismatch is a reason to ask for clarification, not an automatic conclusion that a partner is fraudulent. Differences can arise from errors, outdated records, organizational changes, or more serious issues.
Use the combined evidence to make a documented decision. If the team cannot explain an account or intermediary, pause the change request or investigate the active relationship with the responsible partner. The goal is a supply chain that can be understood and verified, rather than a collection of files that appear individually well formatted but contradict one another.
Troubleshoot missing or outdated status reports
An advertising platform may not immediately reflect a newly published file. Crawling, caching, and processing can introduce delay, and different systems can update at different times. First verify the public response directly. If it is wrong, waiting for a status refresh will not solve the problem.
If the public file is correct, confirm that the platform is checking the intended domain and account identifier. Review host redirects, access restrictions, and deployment history. A record for the wrong account can be perfectly readable yet still fail the platform's check. Keep timestamps and examples of the actual response to make partner support more efficient.
Avoid repeatedly changing correct records merely because a dashboard has not updated. Each unnecessary edit creates another version to reconcile. Follow the partner's documented refresh and support process, while monitoring for actual delivery impact. Distinguish a stale status display from a confirmed authorization mismatch so the response remains proportional to the evidence.
Maintain the file as relationships change
Assign a named owner and a backup. Review the declaration when a partner is added, removed, merged, or changes the relevant account arrangement. Also include it in site-migration and domain-change checklists. A carefully maintained advertising setup can be disrupted if a redesign stops serving the file correctly.
Keep the public file and internal register connected. Each record should have an explanation of why it exists and who can confirm it. Periodic reviews should focus on active authorization, not simply whether the file still loads. A line can remain technically valid long after the commercial relationship has ended.
Use version history and a repeatable deployment process. Small text files are easy to edit, but they can have material operational consequences. A reviewable change and a known rollback path reduce mistakes without making routine maintenance cumbersome. The simplest sustainable process is one that operators can actually follow whenever a relationship changes.
Understand what ads.txt does not establish
An authorized selling account can still offer inventory with poor viewability, unsuitable context, or weak campaign performance. Ads.txt does not certify attention, eliminate every form of fraud, or guarantee revenue. Buyers should continue to evaluate delivery quality, commercial terms, and business outcomes through the appropriate methods.
The file also does not replace contracts or grant unlimited rights beyond the actual relationship. Treat it as a public declaration that must reflect agreed authorization. Publishing a record should not become a shortcut around questions about who may sell inventory and under what conditions.
For websites that do not sell advertising inventory, the need for a file depends on their actual arrangements and platform requirements. Do not add arbitrary records simply because a generic audit suggests that every website needs them. Establish whether there is a relevant advertising relationship, then follow the appropriate setup. Accurate scope is more useful than completing a checklist without understanding its purpose.
Frequently asked questions
Is ads.txt the same as robots.txt?
No. Robots.txt communicates crawling instructions for participating crawlers, while ads.txt declares authorized advertising sellers. The files serve different purposes and use different formats. Adding an advertising account to robots.txt does not authorize it through ads.txt, and an ads.txt record does not control search crawling. Keep ownership and validation appropriate to each file rather than treating all root-level text files as interchangeable.
Should I copy another publisher's ads.txt file?
No. Its records identify that publisher's relationships and accounts, which may not be yours. Copying them can create inaccurate authorizations and fail to include your actual account identifiers. Collect the required records from your verified partners, confirm the commercial relationships, and validate the deployed file. Examples are useful for understanding structure, but live values must come from your own setup.
Does DIRECT mean there are no intermediaries?
Not necessarily. It describes the publisher's relationship to the listed account on the advertising system. The broader transaction can still involve other technical or commercial participants. Use the label according to the actual account-control relationship and inspect other supply-chain information when evaluating the complete route. Treating DIRECT as a universal guarantee of a short or superior path oversimplifies its meaning.
Why can a platform still report a missing file after publication?
The public response may be incorrect, the platform may be checking a different host or account, or its crawl and processing state may not yet reflect the change. Verify the actual URL and contents first, then follow the platform's update process. Do not assume every warning is just a delay, but avoid repeatedly editing a correct file without evidence of a content problem.
Does a valid ads.txt file prevent all ad fraud?
No. It supports verification of declared selling authorization, which addresses a specific part of supply-chain transparency. Other problems, including invalid traffic, unsuitable placements, and poor delivery quality, require additional controls. A valid file is useful evidence about a relationship, not a blanket guarantee about every impression. Buyers and publishers should keep those separate responsibilities visible.
How often should the file be reviewed?
Review it whenever selling relationships or relevant account details change, and include it in periodic operational checks and website migrations. The appropriate routine cadence depends on how often the setup changes. Each record should have an owner who can explain why it remains authorized. A file that loads successfully can still be outdated, so review the business facts as well as technical accessibility.
Related terms
- App-ads.txt: the companion authorization mechanism for app inventory, with discovery and implementation considerations suited to applications rather than ordinary website inventory.
- Sellers.json: information published by advertising systems about seller accounts, useful for checking identities and relationships alongside a publisher's authorization declaration.
- Ad exchange: a transaction service connecting demand and supply, whose relevant seller accounts may appear in a publisher's authorization records.
- Supply-side platform: a publisher-facing system for offering inventory, often involved in the selling relationships that need accurate documentation.
- Ad fraud: deceptive activity affecting advertising, of which unauthorized inventory representation is only one concern addressed by transparency efforts.
- Programmatic advertising: automated advertising transactions, where clear seller authorization helps participants evaluate the legitimacy of offered inventory.