Edit ads.txt and app-ads.txt from WordPress
Ads.txt & App-ads.txt Editor serves /ads.txt and /app-ads.txt virtually through dedicated rewrite rules, with an autosaving textarea for each file directly inside the WordPress admin.
- Edit ads.txt and app-ads.txt without FTP or a file manager.
- Content autosaves 900ms after you stop typing.
- Detects an existing physical file and warns before editing.
- Serves plain text, or a normal 404 when a file is left empty.
Leave empty to leave this file unserved (returns a normal 404).
What does this ads.txt editor do?
Ads.txt & App-ads.txt Editor is a WordPress ads.txt editor built into TheOneWP: when the ads_txt module is active, TOWP_Ads_Txt registers two rewrite rules that route /ads.txt and /app-ads.txt to a virtual handler on template_redirect. Each file's content is stored in its own option and edited from a settings textarea that autosaves through a nonce-protected AJAX action, following the format defined by the IAB Tech Lab ads.txt specification. An empty saved value falls through to WordPress's normal 404 handling instead of serving a blank file, and the ads.txt editor is disabled with a warning when a physical file already exists in the WordPress root.
Without an ads.txt editor, updates mean FTP
Programmatic advertising relies on ads.txt and app-ads.txt staying accurate, yet WordPress ships with no built-in ads.txt editor to manage either file.
Ad network entries change often
Demand partners add or update authorization lines periodically, and a stale ads.txt can affect how buyers evaluate a site's inventory in programmatic auctions.
WordPress core has no built-in hook for it
Unlike robots.txt, WordPress does not serve ads.txt or app-ads.txt virtually, so updating them normally means editing a file directly in the site's root through FTP or a hosting file manager.
A built-in ads.txt editor for WordPress
This ads.txt editor reuses the same rewrite-rule approach as an XML sitemap, routing both file requests to a plain-text response built from a saved WordPress option, formatted according to Google's ads.txt guide.
Dedicated rewrite rules
^ads\.txt$ and ^app-ads\.txt$ are registered with top priority and mapped to a dedicated query variable.
Autosaving textarea
Each file has its own textarea; typing triggers a debounced autosave 900 milliseconds after the last keystroke.
Physical file awareness
If a real ads.txt or app-ads.txt already exists in the WordPress root, the editor is disabled and a warning explains that the web server will serve that file instead.
Practical file controls in a single module
Every capability of this ads.txt editor below is present in the supplied PHP class, settings renderer, AJAX handler and activation logic.
Rewrite-rule based delivery
add_rewrite_rule() maps /ads.txt and /app-ads.txt to index.php with a dedicated query var, resolved on template_redirect at priority 1.
Independent, non-autoloaded options
Each file's content is stored in its own option, updated with autoload disabled, separate from the plugin's general settings blob.
Debounced autosave
Content is saved automatically 900ms after the last keystroke, and again on blur if a save is still pending.
Empty means unserved
When a file's saved content is empty, the request falls through to WordPress's normal 404 handling instead of serving a blank file.
Physical file detection
file_exists() checks the WordPress root for a real ads.txt or app-ads.txt file; if found, the corresponding textarea is disabled with an explanatory notice.
Plain-text response
A matched request receives a text/plain response with nocache_headers() and the saved content, trimmed to a single trailing newline.
Where a virtual editor helps most
The module supports sites that need to publish and update authorized-seller records without touching the server's file system.
Sites running programmatic ads
Maintain ads.txt entries for demand partners directly from wp-admin as authorized sellers change.
Sites with a companion mobile app
Manage app-ads.txt alongside ads.txt when both a website and a mobile app need authorized-seller declarations.
Hosts without easy file access
Update either file without FTP, SFTP or a hosting control panel's file manager.
Turn a manual file edit into a repeatable workflow
The module combines virtual serving, autosaving and conflict detection without requiring server file access.
Focused checks with bounded overhead
The verified implementation only acts on matching requests and avoids unnecessary rewrite flushes.
Early exit on unrelated requests
maybe_serve_file() returns immediately whenever the towp_ads_txt query var is unset, so unrelated front-end requests are unaffected.
Non-autoloaded content
Both saved file contents are stored with autoload disabled, keeping them out of WordPress's automatic option loading on unrelated requests.
Conditional rewrite flush
Rewrite rules are only flushed when a transient flag signals they changed, avoiding a full flush on every admin page load.
Restricted saving and validated input
The code includes an explicit capability check, an AJAX nonce, sanitized textarea content and a restricted file selector.
Administrator-only saving
The AJAX save handler requires the manage_options capability before writing any content.
Nonce verification
check_ajax_referer() validates a dedicated towp_ads_txt_save nonce before the save handler processes the request.
Sanitized textarea content
Submitted content passes through sanitize_textarea_field() before being stored in either option.
Restricted file selector
The AJAX handler only accepts ads or app_ads as the target file key, rejecting any other value before saving.
Built around native WordPress rewrite and template hooks
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
add_rewrite_rule()
Both files are matched with 'top' priority, ahead of WordPress's default rewrite rules.
template_redirect
The virtual response is produced on the front end through the standard template_redirect hook rather than a custom endpoint.
Physical file precedence
If a real ads.txt or app-ads.txt exists in the WordPress root, typical web server rewrite conditions serve that file directly and the virtual version is not reached.
This ads.txt editor versus common alternatives
Compare the verified Ads.txt & App-ads.txt Editor implementation with typical combinations of FTP uploads, theme edits or single-purpose plugins.
| Capability | TheOneWP Ads.txt & App-ads.txt Editor | Other common solutions |
|---|---|---|
| Virtual file serving | No physical file required; served through rewrite rules from a saved option | Usually requires uploading a real ads.txt file via FTP |
| Editing location | Edited directly in wp-admin with autosave | May require a separate plugin, theme editor or hosting file manager |
| app-ads.txt support | Same editor and rewrite approach covers both files | Frequently limited to ads.txt only |
| Conflict handling | Detects an existing physical file and disables editing with a warning | May silently be overridden by, or ignore, an existing file |
| Empty-file behaviour | Falls through to a normal 404 instead of serving a blank file | Behaviour varies by implementation |
| Administration | One TheOneWP settings panel with nonce-protected AJAX autosave | May require separate tools or manual file edits |
Publish ads.txt and app-ads.txt in four steps
Check for conflicting physical files before relying on the virtual editor.
Enable the module
Activate Ads.txt & App-ads.txt Editor from the TheOneWP Utility settings tab.
Check for a physical file
Confirm no physical ads.txt or app-ads.txt already exists in the WordPress root; remove it if the virtual editor should take effect.
Add authorized-seller entries
Type one entry per line for each file, following the standard ads.txt / app-ads.txt line format.
Let it autosave and verify
Stop typing to trigger the autosave, then open each file's URL to confirm the expected content is served.
Publish authorized-seller records without conflicts
A virtual ads.txt is effective only when the WordPress root does not already contain a competing physical file.
Remove any physical file first
A physical ads.txt or app-ads.txt in the WordPress root is served by the web server before this module's virtual version is ever reached.
Keep entries current
Review authorized-seller lines periodically in this ads.txt editor, since outdated entries can affect how demand partners evaluate the site's inventory against the IAB Tech Lab specification.
Verify the served output
Open /ads.txt and /app-ads.txt directly after saving to confirm the plain-text response matches what was entered.
Leave a file empty intentionally when unused
An empty saved value returns a normal 404 rather than an empty file, which is the expected state for a file you are not ready to publish.
Avoid assumptions that break delivery
The module has a defined scope and depends on how the WordPress root and web server are configured.
Leaving an old physical file in place
A leftover ads.txt file in the WordPress root keeps being served by the web server even after content is entered in the editor.
Expecting an instant save
Content is autosaved on a short debounce after typing stops, or on blur; navigating away immediately after a keystroke can interrupt an unsent save.
Assuming app-ads.txt is optional for app-only inventory
Ads.txt and app-ads.txt are evaluated independently by demand partners, so a mobile app's inventory should not rely solely on the website's ads.txt entries.
Ads.txt & App-ads.txt Editor FAQ
These answers are derived from the verified class, settings renderer, AJAX handler and activation logic.
What does this ads.txt editor do?
This ads.txt editor serves /ads.txt and /app-ads.txt virtually through dedicated rewrite rules, with each file's content stored in its own WordPress option and edited from an autosaving textarea in wp-admin.
Do I need to create physical ads.txt or app-ads.txt files?
No. Content is served virtually from a saved WordPress option. A physical file only matters if one already exists, since the web server serves that one instead.
What happens if I leave a file empty?
An empty saved value is treated as not configured: the request falls through to WordPress's normal 404 handling instead of returning a blank file.
How often does the editor save my changes?
Changes are saved automatically about 900 milliseconds after you stop typing, and again on blur if a save is still pending.
What happens if a physical ads.txt already exists on my server?
The editor detects the physical file with file_exists(), disables the corresponding textarea and shows a notice explaining that the web server will serve that file directly.
Does the module support app-ads.txt as well as ads.txt?
Yes. Both files use the same rewrite-rule approach and the same editor interface, with content stored in two separate options.
Who can edit ads.txt and app-ads.txt content?
The AJAX save handler requires the manage_options capability and verifies a dedicated nonce before storing any submitted content.
Is the saved content sanitized before it is stored?
Yes. Submitted text passes through sanitize_textarea_field() before being written to the corresponding option.
Where is the ads.txt content stored?
Each file has its own dedicated, non-autoloaded WordPress option, keeping ads.txt and app-ads.txt content independent of each other.
Does enabling this module require a manual permalink flush?
A flush is scheduled automatically the first time one is needed and applied on the next admin_init call, rather than being triggered on every page load.
Stop editing ads.txt over FTP.Manage it from wp-admin instead.
Use this ads.txt editor to serve, edit and autosave both authorized-seller files from one protected administration screen.