Por qué tu script anti adblock casero acaba siendo esquivado

Casi todo editor que ha intentado gestionar el bloqueo de anuncios por su cuenta conoce el patrón. Escribes o copias un pequeño fragmento de detección, funciona, ves aparecer el mensaje de recuperación y pasas a otra cosa. Una o dos semanas después, sin que nada cambie por tu parte, deja de detectar a nadie en silencio.

Esto no es mala suerte ni es un error en tu código. Es el resultado predecible de cómo funciona el ecosistema del bloqueo de anuncios. El anti adblock casero no es un problema de escribir una vez; es una contienda adversaria continua, y un fragmento estático está en el bando perdedor de ella por diseño.

Entender por qué convierte un misterio frustrante en una decisión clara de construir o comprar. Los modos de fallo de abajo no son casos extremos, son el ciclo de vida normal de un script casero.

Las listas de filtros de los bloqueadores, EasyList, EasyPrivacy y las listas suplementarias de uBlock y AdGuard, las mantienen comunidades activas. No solo bloquean anuncios; también bloquean scripts anti adblock conocidos. Cuando un script de detección se aloja en una URL o ruta predecible, esa URL acaba añadida a una lista.

Una vez la URL de tu script está en una lista de filtros pública, el bloqueador simplemente impide que cargue. Tu código de detección nunca se ejecuta, así que nunca informa de nada, y desde tu panel todo parece correcto, no hay detecciones porque el propio detector está bloqueado. Esto puede pasar a los pocos días de que un script casero reciba algo de tráfico.

Una firma estática es por tanto un diseño que se sabotea a sí mismo. Cualquier cosa fija, un nombre de archivo constante, un nombre de variable constante, un id de DOM constante, es algo que una lista de filtros puede atacar de forma permanente. La única respuesta duradera es hacer que la superficie se mueva, cosa que un fragmento hecho a mano casi nunca hace.

El script casero típico usa una sola señal: crea un elemento cebo con una clase con aspecto de anuncio como ad-banner, espera y comprueba si el elemento fue ocultado. Este enfoque de un solo vector tiene dos debilidades que se suman.

Primero, es trivial de derrotar. A un bloqueador solo le hace falta no ocultar ese cebo concreto, o a una lista de filtros solo le hace falta reconocerlo e ignorarlo, y la única señal devuelve un falso negativo para siempre. Con un vector no hay respaldo; cuando falla, la detección falla por completo.

Segundo, no sobrevive al Manifest V3. Como cubrimos en nuestras guías de MV3, uBlock Origin Lite bloquea sobre todo en la capa de red mediante declarativeNetRequest y hace poco ocultamiento cosmético en sus modos bajos. Una comprobación de cebo solo cosmética no ve nada. Un script casero construido en torno a un único cebo de DOM es por tanto ciego ante una porción grande y creciente de bloqueadores reales.

Las listas de filtros se actualizan constantemente, a menudo varias veces al día. Un motor de detección que vaya a seguir funcionando tiene que actualizarse con ellas, ajustando sus sondas a medida que aparecen nuevas reglas. Un script casero no se reentrena; está congelado en el momento en que lo tocaste por última vez, mientras las listas que tiene que vencer se mueven cada día.

El filtrado cosmético lo empeora. Más allá de bloquear peticiones de red, los bloqueadores aplican reglas cosméticas que ocultan elementos por selector. Si tu mensaje de recuperación usa una clase o un id predecible, una lista de filtros puede simplemente ocultar también tu overlay de recuperación, así que incluso en las pageviews donde la detección funciona, el usuario nunca ve el mensaje. El bloqueador ha filtrado tu respuesta además de los anuncios.

Defenderse de esto exige un trabajo que un fragmento no hace: rotar selectores, reentrenar las sondas contra las últimas deltas de las listas y verificar que el propio overlay de recuperación se renderizó. AntiAdBlock Core reentrena sus heurísticas cada noche contra las deltas de EasyList, uBlock y AdGuard precisamente porque un detector que no se mueve se queda atrás en cuestión de días.

Una capa de detección que aguante necesita tres cosas que a un fragmento casero le faltan estructuralmente. La primera es un cebo aleatorizado y por petición: los elementos cebo, las rutas y los identificadores deben diferir en cada carga de página, para que no haya una firma fija que una lista de filtros pueda capturar. Un objetivo en movimiento no puede listarse de forma permanente.

La segunda es la ofuscación y una superficie de entrega no predecible, ofuscación de código a nivel de AST y entrega de script firmada y anclada al dominio, para que el propio script no pueda identificarse y bloquearse trivialmente por URL. La tercera es la votación por ensemble: muchos vectores de detección independientes cuyos resultados se combinan, de modo que ninguna señal derrotada por sí sola hunda la detección. AntiAdBlock Core ejecuta 11 de esos vectores por este motivo.

Este es el cálculo real de construir frente a comprar. Un script casero es barato de escribir una vez y caro para siempre, porque mantenerlo eficaz significa seguir continuamente los cambios de las listas de filtros, rotar firmas y mantener varios vectores, un compromiso de ingeniería continuo que la mayoría de editores no puede dotar de personal. Comprar un motor mantenido traslada ese mantenimiento adversario a un proveedor cuyo único trabajo es ir por delante. El planteamiento honesto no es fragmento frente a producto; es un fragmento puntual frente a una defensa mantenida, en movimiento y multivector.

Para una imagen concreta de cómo es la alternativa, las guías sobre scripts anti-adblock killer y la actualización de anti-adblock scripts 2026 explican el enfoque multi-vector: qué buscar en cualquier sustitución y cómo compararlo con tu tasa de detección actual.