ads.txt declara vendedores autorizados por un dominio; sellers.json ayuda a identificar sus cuentas y schain representa los intermediarios de una solicitud OpenRTB. Son controles complementarios: contrasta los archivos con contratos y con el recorrido de la puja. Los IDs que aparecen aquí son de ejemplo.
Leer una línea ads.txt sin confundir sus campos
Publica el archivo en la raíz del dominio que vende el inventario, por ejemplo https://dominio.example/ads.txt. Una línea clásica tiene cuatro campos separados por comas. pub-0000000000000000 es un ID ficticio: usa el valor exacto de tu cuenta o código autorizado.
| Columna | Ejemplo | Interpretación | Comprobación |
|---|---|---|---|
| 1. Dominio del sistema | google.com | Dominio del sistema publicitario que controla la cuenta del vendedor. | Debe corresponder al sistema que recibe la solicitud. |
| 2. ID de vendedor | pub-0000000000000000 | Identificador de la cuenta en ese sistema. | Compararlo carácter por carácter con el ID del editor. |
| 3. Relación | DIRECT o RESELLER | Describe si el editor controla la cuenta o autoriza a un revendedor. | Confirmarlo con el contrato y la configuración real. |
| 4. TAG-ID | f08c47fec0942fa0 | Identificador de autoridad de certificación, cuando el sistema lo publica. | En la entrada estándar de Google, verifica el valor oficial. |
Ejemplo de línea de Google. El ID de ceros es ficticio y debe reemplazarse antes de publicar:
# ID de publisher ficticio: reemplazar con el ID propio
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0DIRECT declara una cuenta de vendedor controlada por el editor o propietario del inventario; RESELLER identifica una cuenta autorizada de un tercero. Confirma la relación con el contrato: no uses DIRECT para aparentar una autorización. El TAG-ID es opcional en la sintaxis general; Google muestra f08c47fec0942fa0.
IAB Tech Lab 1.1 añade registros de contexto como OWNERDOMAIN=editor.example y MANAGERDOMAIN=gestor.example. No son columnas de vendedor: publícalos solo si describen propiedad o gestión reales.
Antes de añadir una línea, confirma el dominio del sistema, el ID exacto y la relación con el proveedor. Cada fila debe corresponder a una cuenta autorizada vigente; no copies publisher IDs de otros sitios ni publiques el marcador de ceros del ejemplo. Si un mismo proveedor declara cuentas distintas, conserva las filas separadas y documenta para qué inventario sirve cada una.
Cómo se cruza con sellers.json y SupplyChain
La pareja sistema + seller ID de ads.txt autoriza una cuenta. El comprador busca ese ID en el sellers.json del sistema y revisa su tipo, nombre, dominio y confidencialidad. Un vendedor confidencial puede no mostrar nombre; la ausencia no demuestra fraude.
El tipo ayuda a interpretar la relación: PUBLISHER identifica al propietario del inventario, INTERMEDIARY a una entidad intermediaria y BOTH a quien actúa en los dos papeles. Comprueba siempre junto a qué sistema se publica ese seller ID: el mismo texto de ID en dos exchanges no identifica una única entidad global.
La cadena de OpenRTB suele ir en source.ext.schain: contiene versión, indicador complete y nodos ordenados. Cada nodo incluye asi (sistema), sid (seller ID en ese sistema) y hp (si participa en el pago). Compara cada pareja sistema/ID con el registro publicado por esa entidad.
{
"source": {
"ext": {
"schain": {
"ver": "1.0",
"complete": 1,
"nodes": [
{"asi": "exchange.example", "sid": "seller-42", "hp": 1}
]
}
}
}
}Este nodo es ficticio: no lo copies en producción. En una cadena con varios intermediarios, el orden refleja el flujo de venta. complete=1 afirma que se incluye toda la cadena; un valor cero indica que la cadena declarada no está completa. hp=1 describe el pago, no la calidad o aprobación del partner.
Si recibes muestras de bid requests, conserva varias de distintos formatos y dominios. Compara la secuencia de asi y sid con la documentación del SSP y el archivo sellers.json del dominio de cada nodo. Una página estática no ve por sí sola el recorrido completo de una subasta gestionada servidor a servidor; pide la muestra al proveedor cuando no tengas acceso a logs.
El cruce final comprueba que el dominio, la autorización, la identidad y los nodos describen la misma ruta. Un seller ID puede ser válido en un sistema e inválido en otro: compara siempre el dominio y el ID juntos.
Auditar revendedores y mantener el archivo
Exporta del panel la lista de SSP, exchanges, redes y gestores autorizados por dominio. Registra sistema, seller ID, relación, contrato, responsable y URL sellers.json; compara esa matriz con las líneas públicas y los nodos schain disponibles. Los proveedores cerrados o sustituidos suelen dejar registros antiguos que necesitan explicación.
- Separa cada sitio o subdominio que vende inventario.
- Normaliza las líneas activas y marca filas duplicadas o sin propietario.
- Confirma con cada partner dominio, seller ID y relación autorizada.
- Busca el ID en el sellers.json correspondiente y anota si está oculto.
- Solicita muestras de schain para las rutas de puja que no puedas explicar.
- Registra fecha, evidencia y responsable de cada cambio, incluida la retirada de una línea.
No elimines un revendedor porque no aparezca su nombre: puede ser confidencial o usar otra razón social. Pide al partner el dominio, ID y relación; retira una línea solo cuando confirmes que ya no está autorizada. Una entrada desconocida no debe añadirse para “completar” el archivo.
Tras modificar el archivo, solicita la lectura pública y no te limites a comprobar una copia local. Ejemplo con curl:
curl -sS -L --max-redirs 5 -D headers.txt \
-o ads.txt https://editor.example/ads.txt
head -n 12 headers.txt
sed -n '1,80p' ads.txtEl dominio del comando es ficticio. Verifica URL final, estado y cuerpo anónimo desde fuera; una copia local o una ruta con sesión no demuestra que un rastreador pueda leerla. Para comparar inventario, consulta la API de AdSense; para revisar exposición y acceso, auditoría y seguridad, o la integración de etiquetas.
Diagnóstico de rastreo HTTP, redirecciones y caché
| Señal | Comprobación | Acción de diagnóstico |
|---|---|---|
404 | GET de la ruta raíz exacta y revisión de mayúsculas, alias www y rewrites. | Publicar el archivo en el document root correcto, no dentro de una carpeta temática. |
403 o 406 | Revisar WAF, reglas anti-bot, autenticación y logs del servidor para GET anónimo. | Permitir el recurso público sin relajar globalmente las reglas de seguridad. |
| Redirecciones múltiples | Seguir la cadena con -L y registrar cada Location. | Dejar una ruta HTTPS estable y comprobar que la respuesta final es el texto esperado. |
| Contenido anterior | Comparar fecha, Age, ETag y el cuerpo del origen/CDN. | Invalidar caché de esa ruta y volver a consultar después de propagar el cambio. |
5xx o timeout | Repetir desde otra red y revisar disponibilidad del origen y del CDN. | Resolver el error de servidor; no crear copias divergentes en www y raíz. |
La respuesta debe ser pública, legible como texto y no depender de cookies o JavaScript. Si el CDN mantiene contenido antiguo, compara Age, ETag y cuerpo; invalida esa ruta y vuelve a consultarla tras propagarse el cambio. Guarda las cabeceras del comando y confirma que el último estado es 200, que el tipo de contenido es texto y que no estás leyendo una página HTML de error con apariencia de archivo.
Errores frecuentes en producción y diagnóstico
- ID incorrecto: compara publisher ID y formato exactos con la cuenta y el código del sitio.
- Campos desplazados: conserva comas y orden; el TAG-ID va después de DIRECT o RESELLER.
- Relación falsa: valida DIRECT o RESELLER con contrato y propietario antes de cambiar la línea.
- Seller no encontrado: consulta el sellers.json del sistema correcto y revisa confidencialidad antes de acusar fraude.
- schain incoherente: contrasta asi, sid y orden de nodos con el flujo documentado por el SSP.
- Estado no actualizado: revisa host, redirección, caché y lectura pública; después solicita una nueva comprobación en AdSense.
Preguntas frecuentes
¿El TAG-ID es obligatorio en todos los sistemas?
No. La sintaxis general lo contempla como opcional; Google publica f08c47fec0942fa0 para su línea.
¿Puedo publicar un ID ficticio?
No. Sustituye el marcador por el ID real antes de publicar la declaración.
¿sellers.json demuestra que toda la cadena es válida?
No. Identifica cuentas; ads.txt autoriza vendedores y schain describe la ruta. Contrasta las tres fuentes y los acuerdos.
¿Qué hago si AdSense no actualiza el estado?
Vuelve a verificar contenido y caché desde la URL pública y usa la opción de actualización si aparece en tu cuenta.