Bloqueo de anuncios en Safari: qué debe saber un editor

Safari no incorpora un bloqueador de anuncios propio como hacen algunos navegadores. En su lugar ofrece una plataforma para extensiones Content Blocker, y el bloqueo de anuncios que experimenta tu audiencia viene de apps que el usuario instala, AdGuard for Safari, Wipr y 1Blocker están entre las más comunes. Para un editor, el punto práctico es que el adblock en Safari es opcional y lo impulsan apps, pero donde está presente lo aplica el propio navegador.

El mecanismo es la API WKContentRuleList, y es declarativo en lugar de dinámico. Un content blocker entrega a WebKit una lista de reglas, patrones que bloquear, ocultar o forzar a HTTPS, y WebKit compila esas reglas y las aplica de forma nativa mientras la página carga. La extensión nunca ve las peticiones de red individuales y no puede ejecutar JavaScript para decidir, petición a petición, qué bloquear. Esto es conceptualmente muy parecido al modelo declarativeNetRequest de Manifest V3 de Chrome, donde es el navegador, no la extensión, quien hace la coincidencia.

Esa arquitectura tiene consecuencias directas para la detección. Como el bloqueo ocurre dentro de WebKit y no en el JavaScript de la página, un content blocker de Safari deja pocos de los efectos secundarios en tiempo de ejecución que los scripts anti adblock clásicos se construyeron para cazar. Lo que sí deja son rastros a nivel de red: peticiones que fallan, activos publicitarios que nunca cargan y las curvas de tiempo que esos fallos producen. Un editor que entiende esa distinción ya va por delante de la mayoría de la detección genérica.

El modo Lector de Safari suele confundirse con el bloqueo de anuncios, pero es algo completamente distinto. El modo Lector es una función que invoca el usuario y que reduce una página de artículo a su texto e imágenes esenciales, eliminando la navegación, las barras laterales y, como efecto secundario, los anuncios. No es un content blocker, no usa listas de filtros y solo se aplica a páginas que Safari reconoce como artículos, y solo cuando el lector decide activarlo.

El impacto en los ingresos es real pero acotado. Cuando un visitante lee tu artículo en modo Lector, tus espacios publicitarios no se renderizan, así que no se registra ninguna impresión para esa visita. A diferencia de un content blocker, sin embargo, el modo Lector es por página y por visita: el lector lo dispara de forma deliberada y no persiste como una capa de bloqueo siempre activa en todo tu sitio.

A efectos de detección conviene mantener el modo Lector mentalmente separado de los content blockers. Una página renderizada en modo Lector es un DOM recortado, no una petición de red bloqueada, así que las señales difieren. La parte mayor y más constante de los ingresos perdidos en Safari viene de los content blockers instalados, no del modo Lector, y un editor debería dimensionar ambos problemas por separado en lugar de juntarlos.

Intelligent Tracking Prevention, o ITP, es la parte de Safari que más confunde a los editores. ITP está activado por defecto y restringe las cookies de terceros y el rastreo entre sitios usando heurísticas en el dispositivo. Es una función de privacidad orientada a cómo se sigue a los visitantes a través de los sitios, y es realmente potente, pero es importante ser preciso sobre lo que hace y lo que no hace.

ITP no bloquea el espacio publicitario. Un anuncio servido a un usuario de Safari con ITP activo sigue renderizándose y sigue contando como impresión. Lo que ITP degrada es todo lo que rodea a la segmentación y la medición: las cookies de terceros se particionan o caducan, los identificadores entre sitios se rompen y las ventanas de atribución se reducen. El resultado es que esa misma impresión vale menos, porque es más difícil de segmentar y de medir, no que la impresión desaparezca.

Mantener clara esta distinción importa para el diagnóstico. Si tus CPM de Safari están flojos pero tus recuentos de impresiones parecen sanos, ese patrón apunta a ITP erosionando la segmentación, no al adblock retirando inventario. Si las impresiones en sí faltan en Safari, eso apunta a content blockers o al modo Lector. Tratar ITP como si fuera un bloqueador de anuncios lleva a los editores a perseguir la solución equivocada.

En iPhone y iPad, los content blockers son la forma principal de bloquear anuncios, y eso convierte al Safari móvil en una categoría propia. iOS no permite el modelo de extensiones completo al estilo de escritorio, así que la API Content Blocker es en la práctica la vía autorizada para el bloqueo de anuncios en la plataforma. Un lector que quiere bloquear anuncios en su iPhone instala una app de content blocker, y a partir de ahí Safari aplica sus reglas en cada página.

Para muchos editores esto es una porción de tráfico grande y valiosa. El Safari móvil concentra una audiencia móvil considerable, y tiende hacia un público técnico y consciente de la privacidad en los nichos, tecnología, noticias, videojuegos, donde el bloqueo de anuncios ya es más común de partida. Subestimar el Safari móvil significa subestimar una parte significativa de tu inventario bloqueado.

La conclusión para la detección es que no puedes tratar Safari como una idea de última hora de escritorio. El mismo mecanismo declarativo WKContentRuleList se ejecuta en iOS, así que las señales a nivel de red que funcionan en el Safari de escritorio funcionan también en el móvil, pero el volumen de bloqueo se concentra ahí. Medir tu tasa de adblock en Safari sin separar el móvil del escritorio normalmente subestimará dónde se sitúa de verdad la pérdida.

Como los content blockers de Safari son declarativos, la estrategia de detección refleja la que funciona para el Manifest V3 de Chrome. El bloqueo ocurre por debajo de la página, así que el cebo cosmético de DOM, crear un elemento con una clase de aspecto publicitario y comprobar si fue ocultado, es poco fiable por sí solo. Lo que sobrevive es la capa de red: una petición a una ruta de anuncios conocida que falla, un activo publicitario que nunca resuelve y los tiempos distintivos de una petición bloqueada de forma nativa frente a una lenta o genuinamente rota.

Por eso un script de un solo vector encaja mal con Safari. El cebo solo cosmético produce falsos negativos frente a un bloqueador WKContentRuleList, que es el peor desenlace para un editor: el bloqueador está presente, los ingresos se han ido y el script no informa de nada. Las señales de redirección y de cebo de red, en cambio, siguen activándose porque observan el resultado del bloqueo en lugar de depender de que el bloqueador haga algo visible en JavaScript.

El ensemble multi-señal de AntiAdBlock Core está construido justo para esto. Pondera las señales a nivel de red y de tiempo que el modelo declarativo de Safari deja atrás, vota entre vectores para que ninguna sonda fallida decida el veredicto por sí sola, y se mantiene al día frente a las principales listas de filtros para que la cobertura siga a las listas que incluyen los content blockers de Safari. El resultado es una detección que aguanta en todo Safari, incluido el móvil, sin depender de los trucos cosméticos que este navegador en concreto derrota, y el plan gratuito cubre las primeras 10.000 detecciones al mes, así que puedes medir tu exposición real en Safari antes de decidir qué hacer al respecto.

El modelo de extensión de red de Safari lo hace resistente a algunos enfoques de detección. Para una comparación entre navegadores de lo que el stack de detección completo necesita cubrir, la guía del adblock killer explica cómo la detección multivector maneja las diferencias entre Safari, Brave y Chrome. Para técnicas a nivel JavaScript que se aplican en todos los navegadores, detectar adblock con JavaScript 2026 cubre los bloques básicos.