Key Takeaways

• app-ads.txt must be hosted on the developer website listed in your app store metadata. This is the website URL shown on your Google Play or Apple App Store listing. DSP crawlers use this URL to locate the file.
• The file must be at the root path: https://developer-website.com/app-ads.txt. Not in a subfolder. Not at a custom path. The root, every time.
• Firebase Hosting is an accepted alternative if you don't have a website. Google explicitly supports Firebase as a hosting option for app-ads.txt, which is useful for indie developers without an existing web presence.
• One file covers all your apps. Every app that lists the same developer website URL in its app store metadata is covered by the same app-ads.txt file on that domain.
• The developer URL in the app store must match the hosting domain exactly. A mismatch between the store listing URL and where the file lives is the most common cause of verification failure.

---

Where to Host app-ads.txt Correctly

app-ads.txt hosting is simpler than it looks, but the margin for error is razor thin.

The file has one correct location: the root of the developer website listed in your app store metadata. Host it anywhere else and it doesn't exist as far as DSPs are concerned.

The confusion comes from the indirection. With web ads.txt, the file lives on the same domain that serves the ads. With app-ads.txt, the file lives on a separate website because apps don't have web domains. The app store listing bridges the gap by telling crawlers "this developer's website is at X, go check there."

This guide covers exactly where the file goes, the hosting options available, the common mistakes that cause verification failure, and how to handle edge cases.

The Hosting Rule

The rule is straightforward:

text
https://[developer-website-from-app-store]/app-ads.txt

If your Google Play listing shows https://coolstudio.com as the developer website, your file goes at:

text
https://coolstudio.com/app-ads.txt

If your App Store listing shows https://www.coolstudio.com as the Marketing URL, your file goes at:

text
https://www.coolstudio.com/app-ads.txt

The www matters. The protocol matters. DSP crawlers don't guess or try variations. They use the exact URL from the app store metadata, append /app-ads.txt, and fetch. If the response isn't HTTP 200 with plain text content, verification fails.

Hosting Options

Option 1: Your Existing Developer Website

If you already have a website for your studio or company, host app-ads.txt there. Upload the file to the web root (the same directory as your homepage's index.html).

Pros: Uses infrastructure you already maintain. Consistent developer brand.

Setup: Upload via FTP, SSH, or your CMS file manager.

Option 2: Firebase Hosting

Google's developer documentation/app-ads) explicitly recommends Firebase Hosting as an option for developers who don't have a website. Firebase Hosting has a free tier and serves static files at the root path.

Setup:

1. Create a Firebase project
2. Initialize Firebase Hosting in a local directory
3. Place app-ads.txt in the public/ directory
4. Deploy with firebase deploy
5. Your file is served at https://your-project.web.app/app-ads.txt
6. Use https://your-project.web.app as your developer URL in the app store

Pros: Free, fast, and SSL-enabled by default. Good for indie developers.

Cons: Firebase URL format (your-project.web.app) looks less professional than a custom domain.

Option 3: Static Site Hosting (Netlify, Vercel, GitHub Pages)

Any static hosting platform that serves files at the root path works.

Netlify: Drop app-ads.txt in your site root. Deploy. File is available at https://yoursite.netlify.app/app-ads.txt or your custom domain.

Vercel: Place app-ads.txt in the public/ directory of your project. Deploy.

GitHub Pages: Add app-ads.txt to the repository root. Enable GitHub Pages. File is served at https://yourusername.github.io/app-ads.txt (or custom domain).

Option 4: WordPress or Other CMS

If your developer website runs on WordPress:

• Upload app-ads.txt via FTP to the WordPress root directory (same folder as wp-config.php)
• Or use an ads.txt management plugin that also supports app-ads.txt

For other CMS platforms (Squarespace, Wix, Ghost), check if the platform lets you upload files to the root directory. Some managed platforms restrict root access, in which case you may need to use a custom domain with a separate hosting service for the file.

What NOT to Do

Don't host app-ads.txt inside your app. The file must be on a website. App bundles, app resources, and in-app storage aren't accessible to web crawlers.

Don't host it on a CDN subdomain. cdn.coolstudio.com/app-ads.txt is not the same as coolstudio.com/app-ads.txt. Unless the CDN subdomain is the exact developer URL in your app store listing, crawlers won't find it.

Don't host it in a subfolder. coolstudio.com/files/app-ads.txt won't be found. The path must be the root: coolstudio.com/app-ads.txt.

Don't use a URL shortener. Setting your developer URL to a bit.ly link or similar redirect service breaks the direct path that crawlers expect.

Don't point to the app store listing itself. Setting your developer URL to your Google Play or App Store page creates a circular reference. The crawler goes to the app store, gets the developer URL, goes back to the app store, finds no app-ads.txt.

One File, Multiple Apps

A single app-ads.txt file covers every app that lists the same developer website URL.

If you publish five games and they all show https://coolstudio.com in their app store listings, one file at coolstudio.com/app-ads.txt covers all five.

This means the file must include entries for every ad network used across all of your apps. If App A uses AdMob and Unity Ads, and App B uses AdMob and AppLovin, the app-ads.txt file needs entries for all three networks.

When you need separate files:

If you publish apps under different developer entities with different websites (e.g., coolstudio.com for games and cooltools.com for utilities), each website needs its own app-ads.txt file containing entries for the apps that point to it.

Domain Matching: The Number One Failure Point

The developer URL in the app store must exactly match the domain where app-ads.txt is hosted. This includes:

Protocol: HTTPS is required. HTTP URLs may not be accepted by app stores, and crawlers expect HTTPS.

Subdomain: coolstudio.com and www.coolstudio.com are treated as different domains by crawlers. If your app store lists www.coolstudio.com but your file is only at coolstudio.com/app-ads.txt, verification fails.

Path: If your developer URL in the store includes a path (e.g., https://coolstudio.com/games), some crawlers will check https://coolstudio.com/app-ads.txt (stripping the path to the root domain) while others may check the path first. For safety, always host the file at the root of the domain, regardless of the path in the developer URL.

Trailing slashes: Some systems store https://coolstudio.com/ and https://coolstudio.com differently. Be consistent across your app store listing and your hosting configuration.

SSL/HTTPS Requirements

Your developer website must have a valid SSL certificate.

DSP crawlers use HTTPS to fetch app-ads.txt. If the certificate is expired, self-signed, or misconfigured, the TLS handshake fails and the file is unreachable.

Check these specifics:

• Certificate covers the correct domain. If your site uses a wildcard cert (*.coolstudio.com), it covers www.coolstudio.com but not coolstudio.com (the bare domain). Make sure your cert covers the exact domain form in your app store listing.
• Certificate isn't expired. Set up renewal monitoring.
• Certificate chain is complete. Some hosting providers require you to upload intermediate certificates. A broken chain causes verification failure on some crawlers even if browsers show the site as secure.

Redirect Handling

Minimal redirects are acceptable:

• http://coolstudio.com/app-ads.txt → https://coolstudio.com/app-ads.txt (HTTP to HTTPS) is fine.
• coolstudio.com/app-ads.txt → www.coolstudio.com/app-ads.txt (domain normalization) is fine if the www version is your canonical domain.

Problematic redirects:

• Redirect chains of 3+ hops
• Redirects to a completely different domain
• Redirects that require JavaScript rendering to resolve (some CDN challenge pages)
• Redirects that lead to a login page or CAPTCHA

Verification After Hosting

After uploading, verify the complete chain:

1. Go to your app's public store listing (Google Play or App Store). Click the developer website link. Confirm it takes you to the correct domain.
2. Append `/app-ads.txt` to that domain in your browser. Verify you see the raw text content.
3. Check HTTP headers with curl -I https://your-developer-url.com/app-ads.txt. Confirm HTTP 200 and text/plain content type.
4. Test from outside your network. Internal DNS or development environments can show different results than what external crawlers see.
5. Wait 24 hours and check verification status in your primary ad network dashboard (e.g., AdMob).

Frequently Asked Questions

Can I use a custom domain with Firebase Hosting?

Yes. Firebase supports custom domains. If you want coolstudio.com instead of your-project.web.app, configure a custom domain in the Firebase console and update your app store listing accordingly.

What if my hosting provider doesn't allow files at the root?

Some managed platforms (Shopify for apps, some website builders) restrict root directory access. Options: use a different hosting provider for your developer website, use Firebase Hosting, or configure a DNS-level redirect from your custom domain to a hosting platform that supports root file access.

Can multiple developer accounts share the same app-ads.txt file?

Only if they share the same developer website. Each app's store listing specifies a developer URL. If two different developer accounts both point to coolstudio.com, the single file at coolstudio.com/app-ads.txt covers apps from both accounts. This is valid and common for studios with multiple developer accounts.

How quickly do hosting changes propagate?

If you update the file on your server, the change is immediate on your server. DSPs will see the change on their next crawl cycle (24-72 hours). If you change the developer URL in the app store, Google Play typically reflects the change within hours. Apple App Store may take longer if the metadata change goes through review.

Does the file need to be publicly indexed by search engines?

No. The file just needs to be publicly accessible via HTTPS. You can add /app-ads.txt to your robots.txt disallow rules for search engines if you prefer, but make sure the disallow doesn't affect DSP crawlers. In practice, most publishers leave it accessible to all crawlers.