Verificatiebestanden aan de edge serven: ads.txt, security.txt, AASA en assetlinks.json
Sommige bestanden moeten in de root of onder /.well-known/ staan. Als CMS of shopplatform dat lastig maakt, kan een edge response ze direct met de juiste status en Content-Type serveren.
Het lastige aan verificatiebestanden is zelden de inhoud. Het lastige is het pad.
Ad ops wil ads.txt in de root. Security wil security.txt onder /.well-known/. Mobile heeft apple-app-site-association nodig. Android heeft assetlinks.json nodig. Een CMS, shopplatform of sitebuilder kan prima zijn voor normale pagina’s en toch juist op deze URLs stuklopen.
Daarom blokkeert een klein bestand soms een hele launch.
Als je ook met Universal Links of Android App Links bezig bent, houd dan Universal Links en App Links instellen na Firebase erbij. Dit artikel gaat over het serveren van de bestanden zelf.
Het root- en .well-known-probleem
Deze bestanden zijn klein, maar de systemen die ze controleren zijn streng.
Typische fouten:
- het CMS ondersteunt geen rootbestand
/.well-known/wordt door de router opgepakt- er verschijnt een redirect vóór het bestand
- de Content-Type klopt niet
- niemand is eigenaar van het bestand na launch
De edge is handig omdat die exact op het juiste pad kan antwoorden zonder de rest van de site te verbouwen.
Elk bestand heeft een andere taak
ads.txt en app-ads.txt
Deze bestanden zorgen voor advertentietransparantie en inventory control. Ze moeten makkelijk te lezen zijn:
- direct pad
200response- plain text
- duidelijke owner
Als ze achter login, redirect of CMS-fallback staan, kan verificatie mislukken.
security.txt
security.txt laat zien hoe kwetsbaarheden gemeld kunnen worden. In veel organisaties ligt de verantwoordelijkheid verspreid over web, security, legal en platform.
Een edge response maakt path, body, Content-Type en owner expliciet.
apple-app-site-association
Apple Universal Links hangen af van een AASA-bestand op de juiste plek. Als dat bestand faalt, zoeken teams vaak in de app terwijl het probleem in de bestandslevering zit.
assetlinks.json
Android App Links heeft een geldig assetlinks.json nodig. Als dat ontbreekt, verouderd is of door de sitebuilder wordt herschreven, wordt domeinvalidatie instabiel.
Wat de edge response goed moet doen
Het hoeft niet slim te zijn. Het moet precies zijn.
| Bestand | Typisch pad | Vereiste | Veelgemaakte fout |
|---|---|---|---|
ads.txt | /ads.txt | 200, tekst, stabiele inhoud | achter redirect of login plaatsen |
app-ads.txt | /app-ads.txt | 200, tekst, app inventory | vergeten dat apps een eigen inventory hebben |
security.txt | /.well-known/security.txt of /security.txt | 200, tekst, actuele contactinfo | root zonder owner |
apple-app-site-association | /.well-known/apple-app-site-association of /apple-app-site-association | 200, JSON, exact body | verkeerde Content-Type of pad |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, exact body | route laten herschrijven door CMS |
Als een platform een ander exact pad vraagt, volg dan de documentatie daarvan. Het punt is dat het contract verifieerbaar blijft.
Verstop deze bestanden niet achter redirects
Voor verificatie is direct meestal beter.
Een extra hop geeft extra foutkans. Het maakt debuggen ook lastiger wanneer een verificatie gisteren nog werkte en vandaag niet meer.
Gebruik redirect alleen als de consumer dat expliciet accepteert. Anders serveer je het bestand direct.
Maak ownership expliciet
Deze bestanden raken vaak zoek omdat niemand er na launch echt eigenaar van voelt.
Een praktisch model:
- ad ops beheert
ads.txtenapp-ads.txt - mobile engineering beheert AASA en
assetlinks.json - security of platform beheert
security.txt - web/platform beheert pad, status en Content-Type
Bij CMS-wissel, rebrand of app-migratie voorkomt dat veel terugvalwerk.
Een werkbaar proces
- kies het exacte pad voor elk bestand
- definieer body en Content-Type
- serveer direct aan de edge
- documenteer owner en review date
- test met de echte consumer, niet alleen in de browser
Dit is vooral handig wanneer je geen extra deploy-flow wilt opzetten voor een paar rootbestanden.
Waar UrlEdge past
De Custom Response Tool van UrlEdge kan kleine tekst- of JSON-responses direct vanaf de edge serveren.
Dat is handig wanneer:
- het origin root of
.well-knownslecht ondersteunt - je een directe
200nodig hebt - Content-Type en body gecontroleerd moeten worden
- het domein al in UrlEdge zit voor redirects of routing
Het vervangt de deep-link implementatie niet. Het haalt de frictie uit bestandshosting.
FAQ
Moeten deze bestanden op het origin staan?
Nee. Ze moeten bereikbaar zijn op het verwachte pad. Als het origin dat niet netjes doet, is edge-serving een praktisch alternatief.
Mag ik deze bestanden redirecten?
Alleen als de verifier dat accepteert. Direct serveren is meestal robuuster.
Waarom niet door het CMS laten doen?
Veel CMS’en zijn goed voor pagina’s, maar slecht voor root en /.well-known/. Precies dat gat moet je opvangen.
Is dit alleen voor apps?
Nee. AASA en assetlinks.json horen bij apps, maar ads.txt, app-ads.txt en security.txt horen bij ads en security.
Referenties
Serveer verificatiebestanden zonder origin deploy
Publiceer root- en .well-known-bestanden aan de edge met correcte status, Content-Type en ownership.
Bekijk edge responsesGerelateerde artikelen
Alles bekijken
www, apex en wildcard forwarding zonder SEO-schade
Hostnormalisatie lijkt simpel totdat root, www, subdomeinen, paden en query strings elk een eigen regel krijgen. Een duidelijke policy houdt de canonieke URL stabiel.
Link firewall voor paid en affiliate verkeer: bot, proxy en slechte clicks filteren
Niet elke slechte click is fraude, maar elke slechte click kan budget, attributie en partnerreports verstoren. Een link firewall bepaalt wat er gebeurt voordat verkeer de bestemming bereikt.