Código anti adblock: ejemplos, 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 aqui un snippet ejecutable a proposito. El metodo en si no es ningun secreto: crear un elemento invisible cuyo nombre de clase coincide con una entrada de una lista de filtros publica como EasyList, esperar un momento y comprobar si un bloqueador lo ha ocultado. El problema es justo que es publico y estatico. Un nombre de clase fijo y conocido es lo primero que un mantenedor de listas copia en una regla, y a partir de ahi la comprobacion 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 aqui 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 comprobacion cosmetica no ve. En la practica es fragil: 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 peticion se detiene en el motor del navegador antes de que tu codigo se ejecute, asi que la senal es facil 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 mostrados 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 deben generarse en tiempo de ejecución desde un prefijo aleatorio. Las URLs de sonda deben alojarse en tu propio origen, no en un endpoint de red publicitaria pública, y deben servir un asset conocido cuya ausencia sea la señal.

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 tiempo. Una petición bloqueada de forma nativa resuelve con una curva de tiempo diferente a la de un error de red genuino. Medir esa diferencia de tiempo entre múltiples peticiones sonda, combinada con una comprobación de payloads de redirección noop, 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 cubre qué señales específicas sobreviven a MV3 en la práctica y cómo combinarlas en un conjunto que no depende de ningún comportamiento de bloqueador concreto. Si estás evaluando si construir o comprar el stack completo, la comparación de adblock killer lo deja claro.

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 en cada carga de página 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.

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.