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ó.

const bait = document.createElement('div');
bait.className = 'adsbox ad-banner';
bait.style.cssText = 'height:1px;width:1px;position:absolute;';
document.body.appendChild(bait);

setTimeout(() => {
  const hidden =
    bait.offsetHeight === 0 ||
    bait.offsetWidth === 0 ||
    !document.body.contains(bait);
  document.body.removeChild(bait);
  if (hidden) console.log('Bloqueador detectado');
}, 150);

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.

// Sonda fetch, detecta bloqueo a nivel de red
fetch('https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js', {
  method: 'HEAD',
  cache: 'no-store',
  mode: 'no-cors',
}).then(() => {
  // Petición exitosa, probablemente sin bloqueador
}).catch(() => {
  // Petición fallida, probablemente bloqueada
});

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 anti-adblock script 2026 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 script anti-adblock killer lo deja claro.

El código anti adblock robusto tiene tres propiedades que ningún enfoque de snippet único puede proporcionar. Primero, varios vectores independientes: combinar una comprobación de cebo de DOM, una sonda fetch de red y una huella de tiempo significa que ninguna regla de filtro o scriptlet único puede derrotar a los tres a la vez.

Segundo, aleatorización. Los nombres de clase del cebo, las rutas de las sondas y los identificadores de variables deben diferir en cada carga de página. Generarlos desde un prefijo aleatorio criptográfico en la inicialización elimina cualquier objetivo fijo que una regla de filtro pueda coincidir.

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. AntiAdBlock Core ejecuta 11 vectores que votan reentrenados cada noche contra las deltas de listas de filtros en vivo, precisamente porque el mantenimiento adversario es el coste real de hacer esto correctamente.