UrlEdge
回到部落格
2026年5月17日 UrlEdge Editorial3 min read

在 edge 提供驗證檔案：ads.txt、security.txt、AASA 與 assetlinks.json

有些檔案必須放在 root 或 /.well-known/。如果 CMS 或商店平台不方便，edge response 可以直接用正確的 status 和 Content-Type 提供它們。

root 與 .well-known 驗證檔案由 edge response layer 直接提供

驗證檔案真正麻煩的地方通常不是內容，而是 path。

ad ops 需要 root 下的 ads.txt。security 需要 /.well-known/security.txt。mobile 需要 apple-app-site-association。Android 需要 assetlinks.json。CMS、storefront 或 site builder 對一般頁面也許沒問題，但在這些特定 URL 上就容易出狀況。

結果就是，一個小檔案擋住廣告驗證、security disclosure、app link 或 migration。

如果你也在處理 Universal Links 或 Android App Links，可以一起看 Firebase 後如何配置 Universal Links 與 App Links。這篇只聚焦檔案提供方式。

root 與 .well-known 的問題

這些檔案很小，但驗證它們的平台通常很嚴格。

常見錯誤：

  • CMS 不允許 root file
  • /.well-known/ 被 app router 攔截
  • 檔案前面多了一層 redirect
  • Content-Type 不對
  • launch 後沒有人負責更新

edge 的價值在於，它可以在指定 path 上直接回應，而不用把整個網站改成基礎設施專案。

Edge response map for root and .well-known verification files

每個檔案都有不同任務

ads.txt 與 app-ads.txt

它們用於廣告透明度與授權 inventory。重點是容易被抓取：

  • 直接 path
  • 200 response
  • plain text
  • owner 清楚

如果放在 login、redirect 或 CMS fallback 後面，驗證可能失敗。

security.txt

security.txt 會告訴外界如何回報漏洞。很多團隊在 web、security、legal、platform 之間來回推託。

edge response 會讓 path、body、Content-Type、owner 變得清楚。

apple-app-site-association

Apple Universal Links 依賴 AASA 檔案在正確位置。檔案一旦出錯，團隊常常會先去 debug app，而不是檔案 delivery。

assetlinks.json

Android App Links 需要有效的 assetlinks.json。如果檔案缺失、過期，或被 site builder 改寫，domain verification 就會變得不穩定。

edge response 要做對什麼

它不需要聰明，只需要精準。

Verification file requirements for path, status code, content type, and owner

FileTypical path要求常見錯誤
ads.txt/ads.txt200, text, stable content放在 redirect 或 login 後面
app-ads.txt/app-ads.txt200, text, app inventory忘了 app 自己有 inventory
security.txt/.well-known/security.txt 或 /security.txt200, text, current contactroot path 沒有 owner
apple-app-site-association/.well-known/apple-app-site-association 或 /apple-app-site-association200, JSON, exact bodyContent-Type 或 path 錯誤
assetlinks.json/.well-known/assetlinks.json200, JSON, exact body被 CMS 改寫 route

如果平台要求不同的 exact path，就照它的文件來。重點是維持可驗證的 contract。

不要把這些檔案藏在 redirect 後面

對驗證檔案來說，直接回應通常更穩。

多一個 hop 就多一個 failure point。排查也會更難，因為昨天還通過、今天卻失敗的情況很常見。

只有在 consumer 明確接受 redirect 時才使用。否則直接提供即可。

先定 ownership

這些檔案常常在 launch 後被忘掉，所以很容易出問題。

實務上的分工：

  • ad ops 負責 ads.txt 與 app-ads.txt
  • mobile engineering 負責 AASA 與 assetlinks.json
  • security 或 platform 負責 security.txt
  • web/platform 負責 path、status、Content-Type

在 CMS 變更、rebrand 或 app 調整時，這種 ownership 很省時間。

一套可執行的流程

  1. 為每個檔案決定 exact path
  2. 定義 body 與 Content-Type
  3. 直接從 edge 提供
  4. 記錄 owner 與 review date
  5. 用真正 consumer 測試，而不是只在 browser 看

如果你不想為了幾個 root file 另外開 origin deploy，這種方式很合適。

UrlEdge 適合放在哪

UrlEdge 的 Custom Response Tool 可以直接從 edge 提供短文字或 JSON response。

適合：

  • origin 不擅長處理 root 或 .well-known
  • 需要直接 200
  • 需要控制 Content-Type 與 body
  • domain 已經在 UrlEdge 上做 redirects 或 routing

它不是 deep link stack 的全部替代品，只是移除檔案託管 friction。

FAQ

這些檔案一定要放在 origin 上嗎？

不需要。它們只要能在預期 path 被正確讀取即可。如果 origin 難以做到，edge delivery 很實用。

可以 redirect 嗎？

只有在驗證平台明確允許時才行。通常 direct response 更穩。

為什麼不交給 CMS？

很多 CMS 對頁面很強，但對 root 或 /.well-known/ 很弱。這正是要補的缺口。

這只跟 mobile app 有關嗎？

不是。AASA 與 assetlinks.json 與 app 有關，但 ads.txt、app-ads.txt 和 security.txt 與廣告和安全有關。

參考

不用動 origin 也能提供驗證檔案

把 root 與 .well-known 檔案放到 edge，保持 status、Content-Type 與 ownership 清楚。

查看 edge responses

相關文章

查看全部