Serwowanie plików weryfikacyjnych na edge: ads.txt, security.txt, AASA i assetlinks.json
Niektóre pliki muszą żyć w root albo pod /.well-known/. Jeśli CMS lub sklep to utrudniają, edge response może je serwować z poprawnym statusem i Content-Type.
Najtrudniejsze w plikach weryfikacyjnych rzadko jest ich treści. Najtrudniejszy jest path.
Ad ops chce ads.txt w root. Security chce security.txt pod /.well-known/. Mobile potrzebuje apple-app-site-association. Android potrzebuje assetlinks.json. CMS, sklep albo site builder mogą działać dobrze dla zwykłych stron, a jednocześnie psuć właśnie te URL-e.
W efekcie mały plik blokuje launch, walidację appki albo migrację.
Jeśli pracujesz też nad Universal Links albo Android App Links, trzymaj pod ręką Jak skonfigurować Universal Links i App Links po Firebase. Ten artykuł dotyczy samego serwowania plików.
Problem root i .well-known
Te pliki są małe, ale systemy, które je sprawdzają, bywają bardzo sztywne.
Typowe błędy:
- CMS nie pozwala na plik w root
/.well-known/przechwytuje router- przed plikiem pojawia się redirect
- Content-Type jest zły
- nikt nie jest ownerem pliku po launch
Edge pomaga, bo może odpowiedzieć dokładnie na wymaganym path, bez przebudowy całej strony.
Każdy plik ma inną rolę
ads.txt i app-ads.txt
Te pliki służą transparentności reklam i inventory control. Muszą być łatwe do odczytu:
- bezpośredni path
- odpowiedź
200 - prosty tekst
- jasny owner
Jeśli plik siedzi za loginem, redirectem albo CMS fallback, walidacja może się wysypać.
security.txt
security.txt pokazuje, jak zgłaszać podatności. W wielu firmach odpowiedzialność rozmywa się między web, security, legal i platform.
Edge response wymusza jasność: path, body, Content-Type i owner.
apple-app-site-association
Universal Links Apple zależą od poprawnie serwowanego AASA. Gdy plik nie działa, zespoły często debugują appkę, choć problem leży w delivery pliku.
assetlinks.json
Android App Links potrzebuje poprawnego assetlinks.json. Jeśli plik znika, jest stary albo zostaje przepisany przez site builder, weryfikacja domeny staje się niestabilna.
Co musi zrobić dobrze edge response
Nie musi być sprytny. Musi być dokładny.
| Plik | Typowy path | Wymóg | Częsty błąd |
|---|---|---|---|
ads.txt | /ads.txt | 200, tekst, stabilna treść | wrzucenie za redirect albo login |
app-ads.txt | /app-ads.txt | 200, tekst, app inventory | zapomnienie, że app ma własny inventory |
security.txt | /.well-known/security.txt albo /security.txt | 200, tekst, aktualny kontakt | root bez ownera |
apple-app-site-association | /.well-known/apple-app-site-association albo /apple-app-site-association | 200, JSON, dokładny body | zły Content-Type albo path |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, dokładny body | route przepisywany przez CMS |
Jeśli platforma wymaga innej dokładnej ścieżki, trzymaj się dokumentacji tej platformy. Chodzi o zachowanie weryfikowalnego kontraktu.
Nie chowaj tych plików za redirectami
Dla weryfikacji direct zwykle jest lepsze.
Każdy dodatkowy hop to kolejny punkt awarii. Trudniej też wyjaśnić, czemu weryfikacja przeszła wczoraj, a dziś nie.
Użyj redirect tylko wtedy, gdy consumer to jawnie akceptuje. W innym przypadku serwuj plik bezpośrednio.
Ustal ownership
Te pliki psują się, bo po starcie nikt już nie czuje się za nie odpowiedzialny.
Praktyczny model:
- ad ops ma
ads.txtiapp-ads.txt - mobile engineering ma AASA i
assetlinks.json - security albo platform ma
security.txt - web/platform ma path, status i Content-Type
Przy rebrandzie, zmianie CMS albo migracji appki oszczędza to sporo czasu.
Prosty proces
- wybierz dokładny path dla każdego pliku
- zdefiniuj body i Content-Type
- serwuj bezpośrednio z edge
- udokumentuj ownera i review date
- testuj z prawdziwym consumerem, nie tylko w przeglądarce
To szczególnie dobre, gdy nie chcesz tworzyć osobnego deploy flow dla kilku plików root.
Gdzie pasuje UrlEdge
Custom Response Tool w UrlEdge może serwować krótkie odpowiedzi tekstowe lub JSON bezpośrednio z edge.
To przydatne, gdy:
- origin słabo obsługuje root albo
.well-known - potrzebujesz bezpośredniego
200 - Content-Type i body muszą być kontrolowane
- domena już używa UrlEdge do redirectów lub routing rules
Nie zastępuje to pełnej implementacji deep link. Po prostu usuwa friction z hostingu plików.
FAQ
Czy te pliki muszą być na origin?
Nie. Muszą być dostępne pod oczekiwanym path. Jeśli origin nie umie tego zrobić dobrze, edge jest praktycznym rozwiązaniem.
Czy można je redirectować?
Tylko jeśli verifier to akceptuje. Direct response jest zwykle bardziej stabilny.
Dlaczego nie zostawić tego CMS-owi?
Wiele CMS-ów dobrze obsługuje strony, ale słabo root i /.well-known/. To właśnie ta luka.
Czy to tylko dla aplikacji?
Nie. AASA i assetlinks.json dotyczą app, ale ads.txt, app-ads.txt i security.txt dotyczą reklamy i bezpieczeństwa.
Źródła
Serwuj pliki weryfikacyjne bez deploya origin
Publikuj pliki root i .well-known na edge z poprawnym statusem, Content-Type i ownership.
Zobacz edge responsesPowiązane artykuły
Zobacz wszystko
www, apex i wildcard forwarding bez psucia SEO
Normalizacja hosta wygląda na prostą, dopóki root, www, subdomeny, ścieżki i query stringi dostają własne reguły. Jasna policy utrzymuje kanoniczny URL w stabilnym stanie.
Link firewall dla ruchu paid i afiliacyjnego: boty, proxy i słabe kliknięcia
Nie każde słabe kliknięcie to fraud, ale każde słabe kliknięcie może zepsuć budżet, atrybucję i raport partnera. Link firewall decyduje, co dzieje się zanim ruch dotrze do celu.