Serve Verification Files at the Edge: ads.txt, security.txt, AASA, and assetlinks.json

The annoying part of verification files is not the file itself. It is the path.

One team needs ads.txt at the root. Another needs security.txt under /.well-known/. Mobile wants apple-app-site-association. Android wants assetlinks.json. A CMS, storefront, or website builder may be perfectly fine for most pages and still be terrible at serving those exact URLs.

That is why these files keep turning into release blockers. The site is live. The content is live. The verification file is not where the platform expects it, so the workflow stops.

If your app routing work is already tied to Universal Links or App Links, keep How to Set Up Universal Links and App Links After Firebase nearby. This article is about the files themselves, not the full deep-link stack.

The root-path problem

Verification files are small, but they are picky.

Some are meant for ad platforms. Some are meant for security disclosure. Some are meant for app association. All of them depend on a predictable path and a predictable response.

The common failure modes are boring:

• the CMS does not allow root files
• the platform rewrites the path
• a redirect chain gets inserted
• the file is served with the wrong type
• ownership is unclear after the first launch

The edge is useful here because it can return the exact response the consumer expects without turning the rest of the site into an infrastructure project.

Each file has a different job

ads.txt and app-ads.txt

These files are for ad transparency and inventory control. They need to be easy for crawlers and ad systems to fetch.

Keep them simple:

• direct path
• direct 200 response
• plain text body
• one owner for updates

If the file is buried behind app routing or a CMS quirk, the check can fail even when the rest of the site looks fine.

security.txt

security.txt exists so people can find the right contact for security disclosure.

It is one of those files that should be obvious to serve and still ends up in limbo because nobody owns the root path. A clean edge response avoids that. It also makes it easier to keep the contact details current without asking the web team to rework the origin every time the disclosure process changes.

apple-app-site-association

Apple Universal Links depend on this file being available where Apple expects it. If the file is wrong, installed-app opening becomes inconsistent and the team starts debugging the wrong layer.

assetlinks.json

Android App Links rely on a valid assetlinks.json. If the file is unavailable, outdated, or served in a confusing way, the OS cannot verify the association cleanly.

What the edge response has to get right

The edge layer does not need to be clever. It needs to be precise.

If a platform needs a different exact path, use that. The point is not to force one pattern everywhere. The point is to keep each contract readable by the system that checks it.

Do not hide verification files behind redirects

For these files, direct is usually better than clever.

A redirect chain adds another place for the request to break. It also adds confusion when someone later asks why a verification check passed on one day and failed the next.

Use a redirect only when the consumer accepts it and the path contract still holds. Otherwise, serve the file directly.

That matters even more on platforms where the origin is constrained. If you already know the origin cannot serve the right path cleanly, an edge response layer is the cleaner place to own it.

Make ownership explicit

These files drift because nobody feels responsible for them after launch.

Give each file an owner and a review rule:

• ad operations own ads.txt
• app or mobile engineering owns apple-app-site-association
• Android app engineering owns assetlinks.json
• security or platform owns security.txt
• whoever ships the site owns the path behavior

That sounds obvious until the first CMS change or rebrand. Then it becomes the difference between a five-minute fix and a week of chasing teams.

A practical operating pattern

The simplest pattern is:

1. decide which exact path each file should use
2. define the exact body and content type
3. serve it directly from the edge
4. keep the owning team in the loop
5. test the file with the actual consumer, not just a browser tab

This is a good fit for teams that do not want to turn root-file delivery into a separate deployment path.

When UrlEdge fits

UrlEdge's custom response tool exists for cases like this. It can serve raw edge responses for files and small assets that need a predictable URL and a predictable response.

That is useful when:

• the origin platform makes root files awkward
• you need a direct 200 response at a fixed path
• the file should not depend on a separate deploy
• the same domain already handles redirects and routing logic

It is not a magic fix for deep app association problems. It is a clean way to remove the file-hosting friction that keeps blocking the rest of the launch.

FAQ

Do these files need to live on the origin?

No. They need to be available at the expected path. If the origin cannot do that cleanly, edge delivery is a practical alternative.

Should I redirect verification files?

Usually no. Serve them directly when you can. Redirects add failure points and make debugging harder.

Why not let the CMS handle them?

Many CMS platforms are fine for page content and awkward for root or /.well-known/ paths. That is the mismatch this article is trying to remove.

Is this just for mobile apps?

No. It covers app association files, but also ad inventory and security disclosure files that live outside the normal content workflow.

References

• RFC 9116: security.txt
• Apple: Supporting Universal Links in Your App
• Android Developers: Verify Android App Links
• IAB Tech Lab: ads.txt
• UrlEdge Custom Response Tool