Servir les fichiers de vérification à l’edge: ads.txt, security.txt, AASA et assetlinks.json

Le plus pénible avec les fichiers de vérification n’est pas le contenu. C’est le chemin.

Une régie ou une équipe ad ops demande ads.txt à la racine. L’équipe sécurité veut security.txt sous /.well-known/. L’équipe mobile a besoin de apple-app-site-association. Android exige assetlinks.json. Et votre CMS, votre storefront ou votre site builder peut être excellent pour les pages tout en étant mauvais sur ces URLs précises.

Résultat : une petite URL bloque une recette, une campagne, une validation app ou une migration.

Si vous travaillez sur Universal Links ou Android App Links, gardez Configurer Universal Links et App Links après Firebase à portée. Ici, le sujet est plus étroit : servir les fichiers correctement.

Le problème des chemins root et .well-known

Ces fichiers sont petits, mais les consommateurs sont stricts.

Erreurs fréquentes :

le CMS ne permet pas de fichier à la racine
/.well-known/ est capturé par le routeur applicatif
une redirection s’insère avant le fichier
le Content-Type est incorrect
personne ne sait qui doit maintenir le fichier après le lancement

L’edge aide parce qu’il peut répondre directement sur le chemin demandé, sans transformer tout le site en chantier infrastructure.

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

Chaque fichier a un rôle différent

`ads.txt` et `app-ads.txt`

Ces fichiers servent à la transparence publicitaire et au contrôle de l’inventaire. Ils doivent être simples à récupérer :

chemin direct
réponse 200
contenu texte stable
propriétaire connu

Un redirect, une page de login ou une route CMS peut suffire à faire échouer une vérification.

`security.txt`

security.txt indique comment contacter l’organisation pour une vulnérabilité. Dans beaucoup d’équipes, le sujet est partagé entre sécurité, juridique, web et plateforme.

Une réponse edge force les bonnes questions : quel chemin, quel corps, quel Content-Type, quel propriétaire ?

`apple-app-site-association`

Les Universal Links d’Apple dépendent d’un fichier AASA disponible exactement là où iOS l’attend. Quand ce fichier est mal servi, les équipes déboguent parfois l’app alors que le problème vient de l’URL.

`assetlinks.json`

Android App Links exige un assetlinks.json valide. S’il est absent, modifié par le site builder ou servi au mauvais endroit, la vérification de domaine devient instable.

Ce que la réponse edge doit réussir

La réponse n’a pas besoin d’être sophistiquée. Elle doit être exacte.

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

Fichier	Chemin typique	Exigence	Erreur fréquente
`ads.txt`	`/ads.txt`	`200`, texte, contenu stable	fichier derrière une redirection ou un login
`app-ads.txt`	`/app-ads.txt`	`200`, texte, inventaire app	oublier que l’app a son propre inventaire
`security.txt`	`/.well-known/security.txt` ou `/security.txt`	`200`, texte, contacts à jour	personne ne possède le root path
`apple-app-site-association`	`/.well-known/apple-app-site-association` ou `/apple-app-site-association`	`200`, JSON, corps exact	mauvais Content-Type ou mauvais chemin
`assetlinks.json`	`/.well-known/assetlinks.json`	`200`, JSON, corps exact	route réécrite par le CMS

Si une plateforme demande un chemin exact différent, suivez sa documentation. L’important est que le contrat reste vérifiable.

Éviter les redirections pour ces fichiers

Pour les fichiers de vérification, direct vaut souvent mieux que malin.

Une chaîne de redirection ajoute une panne possible. Elle complique aussi l’enquête lorsque la vérification réussit un jour et échoue le lendemain.

N’utilisez une redirection que si le service consommateur l’accepte clairement. Sinon, servez le fichier directement.

Rendre l’ownership explicite

Ces fichiers dérivent parce qu’ils ne ressemblent pas à un vrai produit.

Un modèle simple :

ad ops possède ads.txt et app-ads.txt
mobile engineering possède AASA et assetlinks.json
sécurité ou plateforme possède security.txt
web/platform possède les chemins, statuts et Content-Type

Lors d’un rebranding, d’une migration CMS ou d’un changement d’app, cette ownership évite plusieurs jours d’allers-retours.

Un mode opératoire fiable

choisir le chemin exact pour chaque fichier
définir le corps et le Content-Type
servir directement depuis l’edge
documenter l’owner et la date de revue
tester avec le consommateur réel, pas seulement dans un onglet de navigateur

C’est particulièrement utile quand une équipe ne veut pas créer un pipeline de déploiement séparé pour quelques fichiers root.

Où UrlEdge intervient

Le Custom Response Tool d’UrlEdge peut servir des réponses texte ou JSON courtes depuis l’edge.

C’est utile si :

l’origin gère mal les chemins root ou .well-known
une réponse directe 200 est attendue
le Content-Type doit être contrôlé
le domaine utilise déjà UrlEdge pour ses redirects ou règles de routing

Ce n’est pas une solution magique pour toute la stack deep link. C’est une façon propre de retirer le blocage lié aux fichiers.

FAQ

Ces fichiers doivent-ils vivre sur l’origin ?

Non. Ils doivent être disponibles au chemin attendu. Si l’origin ne sait pas le faire proprement, l’edge est une bonne alternative.

Peut-on rediriger ces fichiers ?

Seulement si le service qui vérifie les accepte. En général, une réponse directe est plus robuste.

Pourquoi ne pas laisser le CMS gérer ?

Beaucoup de CMS sont bons pour les pages et mauvais pour la racine ou /.well-known/. C’est précisément le décalage à corriger.

Est-ce réservé aux applications mobiles ?

Non. Les fichiers AASA et assetlinks.json concernent les apps, mais ads.txt, app-ads.txt et security.txt concernent la publicité et la sécurité.

Routage de base

Règles intelligentes

Sécurité et surveillance

Utilitaires et vérificateurs

Commencez à créer gratuitement

Entreprise et communauté

Juridique et conformité

Documentation

Servir les fichiers de vérification à l’edge: ads.txt, security.txt, AASA et assetlinks.json

Le problème des chemins root et .well-known