Ir al contenido
Herramienta gratis Beta

Validador Ads.txt

Descarga o pega un ads.txt y verifica cada línea contra el sellers.json del SSP. Obtén scores de riesgo, informes públicos y un resumen de dominios ASI, sellers y resellers.

Esta herramienta está en beta: los resultados pueden cambiar mientras seguimos mejorándola.

1
2

Puedes pegar el archivo completo o solo las líneas que quieras comprobar.

Pega o descarga un ads.txt y pulsa Validar.

Últimos dominios comprobados

Informes públicos más recientes. Abre cualquier dominio para ver la validación línea a línea, scores de riesgo y contactos SSP.

Cómo funciona esta herramienta

  1. 1 Descarga o pega el ads.txt completo (o un subconjunto de líneas).
  2. 2 Normalizamos finales de línea y agrupamos filas por ASI (Advertising System Identifier).
  3. 3 Por cada ASI descargamos su sellers.json (con fallbacks CDN conocidos) y buscamos cada Seller ID.
  4. 4 Cada fila obtiene estado, flags opcionales y un risk score = suma de pesos de flags (acotado 0–1).
  5. 5 Las validaciones correctas se guardan como informe público indexable con la salud del ads.txt de ese dominio.

Preguntas frecuentes

¿Mi ads.txt es correcto? +

Un ads.txt correcto es público en https://tudominio.com/ads.txt, usa el formato IAB (ASI, seller_id, DIRECT|RESELLER[, TAG-ID]) y cada Seller ID existe en el sellers.json de ese ASI. Usa este Validador: filas verdes = verificadas; rojas/ámbar = hay que corregir (SID ausente, mismatch de relación/dominio o sellers.json inaccesible). Añade ownerdomain= si gestionas varios hostnames.

¿Cuántas líneas debe tener mi ads.txt? +

No hay un número mágico. Un sitio sano suele tener desde decenas hasta unos cientos de filas únicas ASI+SID+relación — no miles de duplicados. Más líneas ≠ más ingresos. Los compradores con SPO prefieren archivos cortos y exactos, con DIRECT reales y solo los RESELLER que autorizas a propósito. Si tienes 1.000+ líneas, audita duplicados y partners en desuso.

¿Cómo sé si mi ads.txt está optimizado? +

Optimizado significa: (1) sin duplicados ASI+SID+Rel, (2) cada SID verificado en sellers.json, (3) DIRECT solo si seller_type es PUBLISHER/BOTH, (4) TAG-ID donde el exchange lo exige (p. ej. Google), (5) ownerdomain/managerdomain coherentes, (6) los crawlers pueden descargarlo (usa Bot Probe). El risk score y “Descargar optimizado” te ayudan a llegar ahí.

¿Qué es SPO (Supply Path Optimization)? +

SPO es cómo los DSP y exchanges eligen el camino más limpio y eficiente hacia tu inventario, en lugar de pujar por todos los hops de reseller. Miran ads.txt + sellers.json + SupplyChain (schain) para ver quién es DIRECT vs RESELLER. Las rutas largas, ruidosas o no verificadas se penalizan o bloquean. Un ads.txt limpio es la base del SPO en el lado publisher.

¿Cómo usa el SPO el ads.txt y el sellers.json juntos? +

ads.txt es tu lista de autorización (“quién puede vender mi inventario”). sellers.json es el registro del SSP (“este seller_id es un publisher/intermediario real”). Los sistemas SPO cruzan ambos: si pones openx.com, 12345, RESELLER pero 12345 no existe o es confidential/passthrough, esa ruta parece arriesgada. El DIRECT verificado hacia un dominio publisher conocido puntúa mejor.

DIRECT vs RESELLER — ¿qué debo usar para SPO? +

Usa DIRECT solo si tienes relación directa con ese sistema publicitario y en su sellers.json el seller_type es PUBLISHER o BOTH. Usa RESELLER cuando autorizas a un intermediario a revender. Declarar DIRECT para una cuenta INTERMEDIARY (flag DIRECT_INTERMEDIARY) es una señal roja clásica de SPO y sube el riesgo en este validador.

¿Por qué importa el TAG-ID / certification authority? +

El 4.º campo opcional (TAG-ID) vincula la línea a una autoridad de certificación (p. ej. el de Google f08c47fec0942fa0). Algunos compradores lo exigen para confianza y para cruzar con sellers.json. Faltar el TAG-ID donde el partner lo espera puede debilitar la preferencia SPO aunque el SID exista.

¿Qué es schain y qué tiene que ver con ads.txt? +

El SupplyChain Object (schain) viaja en el bid request listando cada hop desde el publisher hasta el vendedor final. Los compradores comparan nodos del schain con ads.txt/sellers.json. Si un hop aparece en schain pero no está autorizado en ads.txt — o está como DIRECT incorrectamente — los algoritmos SPO descartan o descuentan esa ruta. Alinea ads.txt con cómo vendes de verdad.

¿Debo quitar líneas de SSP que ya no uso por SPO? +

Sí, si ya no trabajas con ese partner. Los RESELLER en desuso abren puertas que se pueden abusar y diluyen la calidad del path. Quédate solo con DIRECT activos y resellers intencionados. Revalida tras limpiar para que sellers.json siga coincidiendo.

¿Qué comprueba técnicamente el Validador Ads.txt? +

Cada línea accionable se agrupa por ASI. Descargamos el sellers.json de ese SSP (URL canónica + fallbacks CDN), buscamos el Seller ID, comparamos relación vs seller_type, recogemos flags y calculamos risk = suma de pesos (0–1). Comentarios y ownerdomain/managerdomain son metadatos, no filas de inventario.

¿Cómo se calcula el risk score? +

Suma de pesos de flags, entre 0 y 1. Pesos: DECLARED_NOT_IN_SELLERS_JSON 0.40, DIRECT_INTERMEDIARY 0.35, CONFIDENTIAL / NO_SELLERS_JSON 0.30, DOMAIN_MISMATCH / RESELLER_INTERMEDIARY 0.25, UNKNOWN_SSP / MISSING_NAME 0.20, PASSTHROUGH 0.15, RESELLER_ONLY / NO_TAG_ID 0.10, DUPLICATED / SELLERS_JSON_UNAVAILABLE 0.05. Verde ≈ 0–0.14, amarillo ≈ 0.15–0.39, naranja ≈ 0.40–0.69, rojo ≈ 0.70+.

¿Por qué sellers.json puede estar “unavailable” si el dominio existe? +

Muchos SSP bloquean IPs de datacenter, limitan rate o sirven sellers.json en un CDN. Probamos la URL IAB y fallbacks (p. ej. AppNexus en acdn.adnxs.com). Un 502/403 significa que no pudimos leer el registro ahora — no es “falta el SID”. Por eso SELLERS_JSON_UNAVAILABLE pesa solo 0.05.

¿Un ads.txt mal puede bajar mis ingresos? +

Sí. Faltan DIRECT y bloqueas demanda legítima; DIRECT/RESELLER incorrectos o SID no verificados hacen que los compradores tiren paths bajo SPO; un ads.txt inalcanzable hace que los crawlers nunca te autoricen. Primero reachability (Bot Probe), luego corrección (Validador), luego higiene (Safe Add Lines / export optimizado).

¿Por qué guardáis un informe público por cada búsqueda? +

Para compartir una URL de lo comprobado. Cada publisher tiene un informe estable e indexable en /tools/adstxt/report/{slug-del-dominio} (p. ej. /tools/adstxt/report/rtve-es). Revalidar el mismo dominio actualiza esa página en lugar de crear duplicados.

¿Cuáles son los límites gratis? +

Visitantes anónimos: 2 validaciones de archivo completo cada 2 horas. Después pedimos email de empresa (no Gmail/Outlook/Yahoo). Combinamos cookie, fingerprint e IP para que borrar el storage no resetee la cuota.