Qué es app-ads.txt y dónde tiene que estar
El archivo en un párrafo, el formato de línea campo por campo, la regla sobre su ubicación que decide si todo funciona y qué hacer sin un sitio web.
app-ads.txt es un archivo de texto plano que enumera las empresas de publicidad autorizadas a vender el inventario de tu app. Está en /app-ads.txt del sitio web indicado en tu ficha de la tienda, y las redes lo descargan para comprobar que los vendedores están autorizados. Un subdominio de plataforma sirve: AdMob verifica archivos en subdominios de AppFoyer. Sin anuncios, no hace falta el archivo.
Hazlo en unos minutos
AppFoyer aloja las páginas de las que trata esta guía —política de privacidad, términos, soporte, eliminación de cuenta y app-ads.txt— en su propio subdominio, sin que necesites dominio ni servidor propios. Una app es gratis, y nada de lo que exige una tienda está nunca detrás de un muro de pago.
Comprobado el 12 de octubre de 2026. Las políticas de las tiendas cambian, a veces sin aviso. Todo lo que sigue enlaza la documentación oficial, y esa página —no esta— es la que manda. Si no coinciden, la tienda tiene razón. Esta guía está traducida del inglés; las citas de la documentación de las tiendas se mantienen en el inglés original.
app-ads.txt es un archivo de texto plano que enumera las empresas de publicidad autorizadas a
vender el inventario publicitario de tu app. Está en /app-ads.txt del sitio web que declaraste en
tu ficha de la tienda, y las redes publicitarias lo descargan para comprobar que quien ofrece tu
inventario está realmente autorizado por ti. Sin él, un comprador no tiene forma de confirmarlo, y
esa es toda la razón de ser del estándar.
Si no muestras anuncios en tu app, no necesitas este archivo en absoluto. Si los muestras, lleva unos diez minutos, y nueve de ellos se van en acertar con la ubicación, que es la única parte que falla con frecuencia.
Qué problema resuelve
El inventario publicitario se revende. Entre tu app y el anunciante hay exchanges, revendedores e
intermediarios, y hasta que existieron ads.txt y su hermano para apps no había una forma barata de
que un comprador distinguiera “esto es realmente el inventario de esa app” de “alguien dice que lo
vende”. El fraude funcionaba porque la afirmación no se podía verificar.
La solución es deliberadamente de baja tecnología: el publisher publica la lista de quién puede vender en su nombre, en una dirección que solo controla el publisher. Un comprador descarga el archivo y compara. Ese es todo el mecanismo, y es la razón por la que la dirección importa más que el contenido: un archivo que cualquiera podría haber puesto ahí no demostraría nada.
El formato de línea
Un vendedor autorizado por línea, tres campos obligatorios y uno opcional, separados por comas:
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0
| Campo | Significado |
|---|---|
google.com | El dominio del sistema publicitario: el dominio canónico de la propia red, no el tuyo. |
pub-0000000000000000 | Tu id de publisher en esa red. Cópialo de su dashboard. |
DIRECT o RESELLER | DIRECT si tienes un contrato directo con ellos; RESELLER si los autorizaste a revender. |
f08c47fec0942fa0 | Id opcional de la autoridad de certificación, cuando la red publica uno. |
Todo lo que va después de # es un comentario. Las líneas que empiezan por contact=, subdomain=,
inventorypartnerdomain= y similares son variables, no registros de vendedores, y se dejan como
están.
Dos errores explican la mayoría de los archivos rotos: una coma que falta, que hace que toda la línea no se pueda analizar, y pegar el id de publisher de otra persona sacado de un foro de soporte, lo que autoriza a un desconocido a vender tu inventario. El dashboard de cada red muestra la línea exacta que quiere: usa esa, no una plantilla.
Dónde tiene que estar: la parte que lo decide todo
El crawler no conoce tu nombre de paquete y no te busca por app. Lee la URL del sitio web del
desarrollador de tu ficha de la tienda y descarga /app-ads.txt en la raíz de ese dominio. Si la
URL de la ficha está mal, un archivo perfectamente correcto es invisible.
AdMob documenta las reglas de sondeo, y vale la pena leerlas una vez en lugar de adivinarlas:
- El directorio raíz significa “the directory following the top level domain” (el directorio que
sigue al dominio de nivel superior):
example.com/app-ads.txt, noexample.com/some/path/app-ads.txt. - Los crawlers “probe up to one subdomain level from the developer website when constructing an
app-ads.txt URL” (sondean hasta un nivel de subdominio a partir del sitio web del desarrollador al
construir una URL de app-ads.txt). Para una ficha que apunta a
support.help.example.com/game, el propio ejemplo de AdMob muestra que pruebahelp.example.com/app-ads.txtyexample.com/app-ads.txt. www.ym.están excluidos como ubicaciones de subdominio, así que se reducen al propio dominio.
Más allá de la dirección, la forma de servirlo tiene que ser correcta sin sorpresas: HTTP 200,
Content-Type: text/plain, sin redirección delante, sin inicio de sesión, sin JavaScript que lo
renderice, nada en robots.txt que lo bloquee. Un archivo que solo aparece tras una redirección de
http a https, o del dominio raíz a www, es un fallo común y completamente invisible.
Compruébalo como lo haría un crawler:
curl -i https://your-domain.example/app-ads.txt
Lo que quieres ver: 200 OK, text/plain, sin cabecera Location: y tus líneas en el cuerpo.
“Pero no tengo un sitio web”
Es el caso normal de un desarrollador indie, y es la razón de que tantas apps no tengan archivo.
El requisito es un hostname que controles y que sirva un archivo; no es un requisito tener un sitio de marketing, un dominio de empresa o una landing page. AdMob lo dice directamente: “If you don’t have a suitable website that allows the uploading of an app-ads.txt file at the root level, you can use Firebase Hosting to host your app-ads.txt file.” (Si no tienes un sitio web adecuado que permita subir un archivo app-ads.txt en el nivel raíz, puedes usar Firebase Hosting para alojar tu archivo app-ads.txt). El hosting en plataformas es lo previsto, no un apaño. La guía sin sitio web repasa las opciones.
Uses lo que uses, dos cosas tienen que cumplirse durante más tiempo que la semana del lanzamiento: la dirección tiene que seguir siendo la misma, porque está impresa en una ficha de la tienda en la que no volverás a pensar, y tiene que seguir sirviendo texto plano sin que se cuele una redirección delante la primera vez que alguien “mejore” la configuración.
Cuando cambias algo, no pasa nada de inmediato
Las redes publicitarias vuelven a rastrear según su propio calendario. AdMob indica que “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files” (AdMob puede tardar hasta 24 horas en rastrear y verificar tus archivos app-ads.txt), y otras redes son más lentas. Un archivo subido hace una hora que todavía aparece como no encontrado casi siempre es solo cuestión de tiempo; consulta la guía de «not found» antes de cambiar nada más.
Qué hace AppFoyer aquí
La página de tu app sirve app-ads.txt en su propio subdominio —texto plano, 200, sin redirección,
con las cabeceras que pide la especificación— y el editor valida cada línea mientras la escribes, así
que una coma que falta se detecta antes de que la vea un crawler. Tú pones ese subdominio como sitio
web del desarrollador en tu ficha de la tienda, un nivel por debajo de appfoyer.page.
AdMob lo verifica ahí: en octubre de 2026 informó “app-ads.txt file found and verified” (archivo app-ads.txt encontrado y verificado) para apps cuyo sitio web del desarrollador es una dirección de AppFoyer. Todavía no tenemos ningún resultado de rastreo propio de otras redes publicitarias.
Las fuentes oficiales
- Configurar app-ads.txt — Ayuda de AdMob. Las reglas del crawler y el ejemplo de subdominio citados arriba proceden de esta página.
- Especificación ads.txt / app-ads.txt — IAB Tech Lab. La propia especificación, y la autoridad en cuanto a la gramática de las líneas.