Verifizierungsdateien am Edge ausliefern: ads.txt, security.txt, AASA und assetlinks.json

Das Schwierige an Verifizierungsdateien ist selten der Inhalt. Das Schwierige ist der Pfad.

ads.txt muss im Root liegen. security.txt wird unter /.well-known/ erwartet. iOS braucht apple-app-site-association. Android braucht assetlinks.json. Ein CMS, Shopsystem oder Website-Builder kann für normale Seiten gut funktionieren und trotzdem genau diese Pfade schlecht abbilden.

Dann blockiert eine kleine Datei einen Launch: Ad Ops wartet auf ads.txt, Security auf Kontaktinformationen, Mobile auf App Links, SEO auf den finalen Domain-Switch.

Wenn Sie an Universal Links oder Android App Links arbeiten, gehört Universal Links und App Links nach Firebase einrichten daneben. Dieser Artikel behandelt die Dateiauslieferung selbst.

Das Root-Path-Problem

Verifizierungsdateien sind klein, aber streng.

Typische Fehler:

das CMS erlaubt keine Root-Dateien
/.well-known/ wird von der App geroutet oder überschrieben
ein Redirect wird eingefügt
der Content-Type passt nicht
nach dem Launch weiß niemand, wer die Datei aktualisiert

Die Edge-Schicht ist hier nützlich, weil sie exakt auf einen Pfad antworten kann, ohne den Rest der Website umzubauen.

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

Jede Datei hat einen anderen Vertrag

`ads.txt` und `app-ads.txt`

Diese Dateien dienen der Anzeigen-Transparenz und Inventar-Kontrolle. Sie sollten direkt abrufbar sein:

stabiler Pfad
200 OK
Plain Text
klare Verantwortung für Updates

Ein Redirect, Login-Gate oder CMS-Fallback kann dazu führen, dass ein Prüfsystem die Datei nicht akzeptiert.

`security.txt`

security.txt soll klar zeigen, wie Sicherheitsmeldungen eingereicht werden können. In deutschen Unternehmen fällt diese Datei oft zwischen Web, Security, Legal und Plattformteam.

Eine Edge-Response macht die Zuständigkeit einfacher: Pfad, Body, Content-Type und Owner sind Teil der Regel.

`apple-app-site-association`

Apple Universal Links hängen davon ab, dass die AASA-Datei an der erwarteten Stelle sauber ausgeliefert wird. Wenn sie fehlt oder umgeleitet wird, wirkt das App-Opening zufällig, obwohl der eigentliche Fehler in der Dateibereitstellung liegt.

`assetlinks.json`

Android App Links brauchen eine gültige assetlinks.json. Wenn diese Datei veraltet, nicht erreichbar oder durch den Website-Builder verändert wird, kann Android die Domain nicht zuverlässig verifizieren.

Was die Edge-Response richtig machen muss

Die Antwort muss nicht clever sein. Sie muss präzise sein.

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

Datei	Typischer Pfad	Anforderung	Häufiger Fehler
`ads.txt`	`/ads.txt`	`200`, Text, stabiler Inhalt	hinter Redirect oder Login
`app-ads.txt`	`/app-ads.txt`	`200`, Text, App-Inventar	App-Inventar vergessen
`security.txt`	`/.well-known/security.txt` oder `/security.txt`	`200`, Text, aktuelle Kontakte	Root-Pfad gehört niemandem
`apple-app-site-association`	`/.well-known/apple-app-site-association` oder `/apple-app-site-association`	`200`, JSON-Inhalt, exakter Body	falscher Content-Type oder Pfad
`assetlinks.json`	`/.well-known/assetlinks.json`	`200`, JSON, exakter Body	Site-Builder schreibt Route um

Wenn eine Plattform einen anderen exakten Pfad verlangt, folgen Sie der Plattform. Wichtig ist, dass der Vertrag prüfbar bleibt.

Verifizierungsdateien nicht hinter Redirects verstecken

Für diese Dateien ist direkt meist besser als elegant.

Ein zusätzlicher Hop ist eine weitere Fehlerstelle. Er macht auch Debugging schwerer, wenn eine Prüfung gestern bestanden hat und heute fehlschlägt.

Nutzen Sie Redirects nur, wenn der prüfende Dienst sie ausdrücklich akzeptiert und der Pfadvertrag erhalten bleibt. Sonst liefern Sie direkt aus.

Ownership festlegen

Diese Dateien driften, weil nach Launch niemand mehr zuständig ist.

Ein praktikables Modell:

Ad Operations besitzt ads.txt und app-ads.txt
Mobile Engineering besitzt AASA und assetlinks.json
Security oder Platform besitzt security.txt
Web/Platform besitzt Pfadverhalten, Status und Content-Type

Bei einem Relaunch, Rebrand oder CMS-Wechsel ist diese Ownership oft wertvoller als die Datei selbst.

Ein einfaches Betriebsmodell

exakten Pfad je Datei festlegen
Body und Content-Type versionieren
Datei direkt am Edge ausliefern
Owner und Review-Zyklus dokumentieren
mit dem tatsächlichen Consumer testen, nicht nur im Browser

Das passt besonders dann, wenn Root-Dateien nicht jedes Mal ein Origin-Deploy oder ein Ticket beim Website-Team brauchen sollen.

Wo UrlEdge passt

Mit dem Custom Response Tool kann UrlEdge kleine Text- oder JSON-Antworten direkt am Edge ausliefern.

Das ist sinnvoll, wenn:

das CMS Root- oder .well-known-Pfade nicht sauber erlaubt
eine direkte 200-Antwort nötig ist
Content-Type und Body kontrolliert werden müssen
die Domain ohnehin in UrlEdge für Redirects oder Routing liegt

UrlEdge ersetzt damit nicht die App-Link-Implementierung selbst. Es entfernt die Dateihürde, die viele Launches unnötig blockiert.

FAQ

Müssen diese Dateien auf dem Origin liegen?

Nein. Sie müssen unter dem erwarteten Pfad korrekt erreichbar sein. Wenn der Origin das nicht sauber kann, ist Edge-Auslieferung praktikabel.

Darf ich diese Dateien weiterleiten?

Nur wenn der prüfende Dienst das akzeptiert. Direktes Ausliefern ist meist robuster.

Warum nicht im CMS ablegen?

Viele CMS sind gut für Seiten, aber schlecht für Root- und .well-known-Pfade. Genau diese Lücke schließt die Edge-Schicht.

Ist das nur für Mobile Apps?

Nein. AASA und assetlinks.json gehören zu Apps, aber ads.txt, app-ads.txt und security.txt betreffen Ads und Security.

Kern-Routing

Intelligente Regeln

Sicherheit & Monitoring

Utilities & Prüfungen

Starten Sie kostenlos

Unternehmen & Community

Recht & Compliance

Dokumentation

Verifizierungsdateien am Edge ausliefern: ads.txt, security.txt, AASA und assetlinks.json

Das Root-Path-Problem