Servir archivos de verificación en el edge: ads.txt, security.txt, AASA y assetlinks.json
Algunos archivos deben vivir en la raíz o bajo /.well-known/. Si tu CMS o tienda no los maneja bien, una respuesta edge puede servirlos con status y Content-Type correctos.
Lo difícil de un archivo de verificación rara vez es el contenido. Lo difícil es la ruta.
Ad ops necesita ads.txt en la raíz. Seguridad pide security.txt bajo /.well-known/. Mobile necesita apple-app-site-association. Android necesita assetlinks.json. Un CMS, ecommerce o site builder puede funcionar bien para páginas normales y aun así fallar en esas rutas exactas.
Así una campaña, una app, una integración de anuncios o una migración queda bloqueada por un archivo pequeño.
Si trabajas con Universal Links o Android App Links, deja cerca Cómo configurar Universal Links y App Links después de Firebase. Este artículo se enfoca en servir los archivos.
El problema de root y .well-known
Los archivos son pequeños, pero las plataformas que los verifican suelen ser estrictas.
Errores comunes:
- el CMS no permite archivos en la raíz
/.well-known/queda capturado por el router- aparece un redirect antes del archivo
- el Content-Type es incorrecto
- nadie es dueño del archivo después del lanzamiento
El edge ayuda porque puede responder directamente sobre la ruta exacta, sin rediseñar todo el sitio.
Cada archivo tiene un trabajo distinto
ads.txt y app-ads.txt
Sirven para transparencia publicitaria e inventario autorizado. Deben ser fáciles de leer por plataformas y crawlers:
- ruta directa
- respuesta
200 - texto plano
- owner claro
Si el archivo queda detrás de login, redirect o fallback del CMS, una verificación puede fallar.
security.txt
security.txt indica cómo reportar vulnerabilidades. En equipos con web, seguridad, legal y agencias, esta responsabilidad suele quedar difusa.
Una respuesta edge obliga a dejar claros ruta, cuerpo, Content-Type y owner.
apple-app-site-association
Universal Links de Apple dependen de que AASA esté disponible donde iOS espera. Si el archivo falla, el equipo puede terminar depurando la app cuando el problema está en la entrega del archivo.
assetlinks.json
Android App Links necesita un assetlinks.json válido. Si falta, está desactualizado o el builder lo reescribe, la verificación de dominio se vuelve inestable.
Qué debe hacer bien la respuesta edge
No necesita ser compleja. Necesita ser exacta.
| Archivo | Ruta típica | Requisito | Error común |
|---|---|---|---|
ads.txt | /ads.txt | 200, texto, contenido estable | ponerlo detrás de redirect o login |
app-ads.txt | /app-ads.txt | 200, texto, inventario app | olvidar que la app tiene inventario propio |
security.txt | /.well-known/security.txt o /security.txt | 200, texto, contacto vigente | root path sin owner |
apple-app-site-association | /.well-known/apple-app-site-association o /apple-app-site-association | 200, JSON, cuerpo exacto | Content-Type o ruta incorrecta |
assetlinks.json | /.well-known/assetlinks.json | 200, JSON, cuerpo exacto | route rewrite del CMS |
Si una plataforma pide otra ruta exacta, usa esa. El punto es mantener el contrato verificable.
No escondas estos archivos detrás de redirects
Para verificación, directo suele ser mejor.
Un hop adicional agrega otro punto de falla. También vuelve difícil explicar por qué una validación pasó ayer y hoy no.
Usa redirect solo si el consumidor lo acepta explícitamente. De lo contrario, sirve el archivo directamente.
Define ownership
Estos archivos se rompen porque nadie los siente propios después del primer release.
Un modelo práctico:
- ad ops posee
ads.txtyapp-ads.txt - mobile engineering posee AASA y
assetlinks.json - seguridad o plataforma posee
security.txt - web/platform posee rutas, status y Content-Type
Cuando cambias CMS, dominio o app, esa claridad evita días de ida y vuelta.
Flujo operativo
- decidir la ruta exacta de cada archivo
- definir cuerpo y Content-Type
- servir directo desde el edge
- documentar owner y fecha de revisión
- probar con el consumidor real, no solo en un navegador
Esto sirve especialmente cuando no quieres abrir un deploy del sitio para un archivo root.
Dónde encaja UrlEdge
El Custom Response Tool de UrlEdge puede servir respuestas texto o JSON desde el edge.
Es útil cuando:
- el origin no maneja bien root o
.well-known - necesitas un
200directo - Content-Type y cuerpo deben ser controlados
- el dominio ya usa UrlEdge para redirects o routing
No reemplaza toda la implementación de deep links. Quita la fricción de hosting de archivos.
FAQ
¿Deben vivir estos archivos en el origin?
No. Deben estar disponibles en la ruta esperada. Si el origin no puede hacerlo bien, el edge es una alternativa práctica.
¿Puedo redirigirlos?
Solo si la plataforma que verifica lo acepta. Una respuesta directa suele ser más robusta.
¿Por qué no dejarlo al CMS?
Muchos CMS manejan bien páginas, pero mal rutas root o /.well-known/. Esa es la brecha.
¿Esto es solo para apps?
No. AASA y assetlinks.json son de apps, pero ads.txt, app-ads.txt y security.txt son de publicidad y seguridad.
Referencias
Sirve archivos de verificación sin tocar el origin
Publica archivos root y .well-known desde el edge con status, Content-Type y owner definidos.
Explorar respuestas edgeArtículos relacionados
Ver todo
www, dominio raíz y wildcard forwarding sin romper SEO
Normalizar el host parece simple hasta que raíz, www, subdominios, rutas y query strings obedecen reglas distintas. Una policy clara mantiene estable la URL canónica.
Link firewall para tráfico paid y afiliados: bots, proxys y clics malos
No todo clic malo es fraude, pero todo clic malo puede costar presupuesto, atribución o comisiones. Un link firewall decide qué debe pasar antes de que el tráfico llegue al destino.