Código anti adblock: patrones, errores habituales y qué aguanta de verdad

El código anti adblock más copiado es el cebo de DOM: un elemento del DOM con un nombre de clase que parece un anuncio, comprobado tras un breve retraso para ver si el bloqueador lo ocultó o eliminó.

No publicamos aquí un snippet ejecutable a propósito. El método en sí no es ningún secreto: crear un elemento invisible cuyo nombre de clase coincide con una entrada de una lista de filtros pública como EasyList, esperar un momento y comprobar si un bloqueador lo ha ocultado. El problema es justo que es público y estático. Un nombre de clase fijo y conocido es lo primero que un mantenedor de listas copia en una regla, y a partir de ahí la comprobación devuelve 'sin bloqueador' en silencio para cada visitante que lleve esa lista.

Esto funciona contra los bloqueadores que aplican filtrado cosmético, ocultando elementos por selector de clase. Para un blog básico que quiere un recuento aproximado, es una primera sonda razonable. Pero falla en silencio en más casos de los que detecta, que es el tipo de fallo más peligroso.

Un segundo patrón común es la sonda fetch: cargar una URL que parece un recurso de una red publicitaria y tratar el fallo de red como evidencia de un bloqueador.

Tampoco incluimos aquí una sonda ejecutable. La idea es pedir una ruta que parece publicitaria y tratar el fallo como un bloqueador, lo que detecta bloqueadores a nivel de red que una comprobación cosmética no ve. En la práctica es frágil: la ruta de la sonda es otra firma fija y listable, un simple 404 o un proxy corporativo se parece a un bloqueo real y produce falsos positivos, y con Manifest V3 la petición se detiene en el motor del navegador antes de que tu código se ejecute, así que la señal es fácil de malinterpretar.

Las sondas fetch alcanzan a los bloqueadores que operan en la capa de red. Pero la tasa de falsos positivos es significativa: una conexión lenta, un fallo de CDN o una política de seguridad del navegador pueden activar la rama catch sin que haya ningún bloqueador presente. Y si la URL concreta que sondeas sale de la lista de filtros, la sonda devuelve falsos negativos para siempre mientras sigue pareciendo que funciona.

Todos los patrones descritos arriba comparten la misma debilidad estructural: son estáticos. El nombre de clase adsbox, la URL pagead2.googlesyndication.com, el nombre de variable detectAdBlock, cualquier cosa fija y pública es algo que un mantenedor de listas de filtros puede copiar en una regla. EasyList, uBlock Origin y las listas suplementarias de AdGuard contienen reglas dirigidas a patrones de código anti adblock conocidos.

Una vez que la clase cebo de tu código o la URL de sonda está en una lista de filtros, la evasión es permanente hasta que la cambies. El bloqueador o bien oculta el cebo de una forma que el código no reconoce, o ignora el elemento por completo, o bloquea la URL de la sonda antes de que el fetch resuelva. El código sigue ejecutándose, pero el resultado es siempre negativo.

La solución práctica es no usar nunca un valor fijo y reconocible como señal de detección. Los nombres de clase del cebo no deben ser fijos ni predecibles. Las URLs de sonda no deben apuntar a un endpoint de red publicitaria pública ni depender de un dominio externo ya marcado.

El Manifest V3 de Chrome reemplazó el bloqueo dinámico webRequest por declarativeNetRequest, donde el navegador aplica un conjunto fijo de reglas en la capa de red. uBlock Origin Lite está construido por completo sobre este modelo. Desde la perspectiva del JavaScript de la página, el bloqueo ocurre por debajo de cualquier evento observable: no se lanza onerror, no hay promise rechazada, no hay mutación del DOM, solo una petición que resuelve instantáneamente sin datos.

Una comprobación de cebo de DOM no detectará a un bloqueador declarativeNetRequest si el bloqueador usa reglas de red en lugar de filtros cosméticos. Una sonda fetch no resolverá en catch() porque el bloqueo no provoca un error de red visible en JavaScript. Ambos patrones fallan en esta clase de bloqueador, que es ahora el segmento de más rápido crecimiento.

Lo que sí sobrevive a MV3 es el comportamiento. Una petición bloqueada de forma nativa se comporta de forma diferente a un error de red genuino. Leer esa diferencia entre múltiples peticiones sonda, combinada con heurísticas MV3, da una señal que es única para los bloqueadores MV3 y sobrevive a su falta de efectos secundarios visibles en JavaScript.

La guía de qué es un script anti adblock explica por qué una detección que sobrevive a MV3 en la práctica funciona como un conjunto que no depende de ningún comportamiento de bloqueador concreto. Si estás valorando si hacer tu propio script o contratarlo, la guía del script antiadblock 2026 lo explica.

Una detección que aguanta necesita propiedades que ningún snippet único puede dar, y construirlas por tu cuenta es un compromiso de ingeniería continuo, no un pegado puntual. Tiene que combinar varias comprobaciones independientes para que ninguna regla de filtro la tumbe entera de golpe, y tiene que seguir funcionando a medida que cambian las listas.

También tiene que no presentar ninguna firma fija y pública que una lista de filtros pueda capturar, porque todo lo estático y reconocible acaba listado y deja de funcionar en silencio. Mantener esa superficie impredecible no es algo que haga un snippet de copiar y pegar.

Tercero, mantenimiento. El código anti adblock no es software de escribir-una-vez. Las listas de filtros se actualizan a diario, salen nuevas versiones de bloqueadores y aparecen regularmente nuevas contramedidas de scriptlets. Un snippet que pegas hoy detectará una fracción cada vez menor de bloqueadores el mes que viene sin un solo error visible. Ese mantenimiento continuo es el coste real, y por eso a la mayoría de publishers les compensa apuntar una sola línea de código a un servicio mantenido como AntiAdBlock Core en lugar de cargar ellos con la carrera armamentística. Si estás comparando proveedores, la página de software de recuperación de adblock explica los dos tipos, redes gestionadas de reparto de ingresos y scripts de detección, y qué esperar de cada uno.

Antes de decidirte por un enfoque, conviene saber cómo se saltan los bloqueadores los scripts de detección, porque eso determina cuánto aguanta tu código.