El cloaking del lado del servidor es un filtro que toma la decisión en el servidor de tu sitio: la petición del visitante llega al hosting, el código PHP le pregunta al servicio de filtrado quién está delante y, solo tras la respuesta, entrega al navegador la oferta o una página neutral. El cloaking en el navegador funciona de otra manera: la página ya se está cargando, y una etiqueta JS en su <head> oculta el contenido, revisa la visita y muestra la variante que corresponde.
Ambos esquemas resuelven la misma tarea (descartar bots, escáneres, spy tools y tráfico no objetivo), pero ven la visita desde lados distintos y fallan de forma distinta. La instalación paso a paso está en el artículo cómo conectar un cloaker; aquí hablamos de arquitectura: qué pasa por dentro, dónde están los puntos fuertes de cada método y dónde los débiles.
Server-side cloaking: el recorrido de la petición
El camino de la visita en el esquema de servidor:
- El visitante hace clic en el anuncio y el navegador pide
tu-sitio.com. - La petición llega a tu servidor, y el primero en responder es el archivo PHP, no la landing.
- El archivo pasa al servicio los datos de la petición: IP, cabeceras, parámetros del enlace.
- El servicio revisa la visita y devuelve una decisión.
- El servidor entrega al navegador la oferta o la White Page. Hasta ese momento, el navegador no ha recibido ni un byte de la página.
La propiedad clave es que la página no llega al visitante antes de la decisión. El bot no tiene nada que guardar, el bloqueador de anuncios no tiene nada que recortar y un internet lento no tiene nada que mostrar antes de tiempo.
Cloaking en el navegador: cómo funciona la etiqueta JS
En el esquema del navegador, el orden es el inverso:
- El navegador pide la página, y tu hosting se la entrega a todos por igual.
- En la primera línea del
<head>está la etiqueta: se carga antes que todo lo demás y oculta la página. - La etiqueta recoge señales del navegador y las envía al servicio.
- Si llega la decisión «oferta», la página se muestra. Si es «White Page» o no hay decisión, el visitante se va a la página neutral.
La ventaja de este esquema es la sencillez: la etiqueta se pega en cualquier página en la que tengas acceso al <head>, incluso en un creador de sitios sin servidor propio. La desventaja es que el HTML de la landing ya está físicamente en el navegador. La etiqueta lo oculta, pero no puede «no entregarlo».
Qué ve cada cloaker de la visita
La diferencia principal entre las arquitecturas es el conjunto de señales.
| Señal | Servidor | Navegador |
|---|---|---|
| IP, proveedor, red, país por dirección | Sí | Sí, a través del servicio |
| User-Agent, idioma, referer, cabeceras de la petición | Sí | Sí |
| Parámetros del enlace: fbclid, gclid, ttclid, UTM | Sí | Sí |
| Si el cliente ejecuta JavaScript | No | Sí |
| Zona horaria e idioma del navegador | No | Sí |
| Señales de automatización (webdriver, headless) | En parte, por las cabeceras | Sí |
| Pantalla, plataforma, propiedades del navegador | No | Sí |
| Movimientos del ratón y toques | No | Sí |
| Tiempo pasado en la página | No | Sí |
El servidor ve la petición; el navegador, el entorno en el que se ejecuta esa petición. Un bot simple desde un centro de datos lo atrapan los dos. Un navegador automatizado con un proxy doméstico y el User-Agent correcto, el servidor no lo distingue de una persona por una sola petición: lo delata el comportamiento de JavaScript, como una zona horaria que no coincide con el país de la dirección, rastros de automatización o la falta de movimientos. Sobre estas señales, los artículos navegadores headless y huella digital y VPN, proxies e IP de centros de datos.
Híbrido: decisión en el servidor más página de comprobación
Por eso, el esquema puramente de servidor es en la práctica menos habitual de lo que parece. El filtro de servidor decide al instante si la petición lo deja claro, y en los casos dudosos entrega una breve página de comprobación: ejecuta JavaScript, recoge las señales del navegador y vuelve a pedir la decisión. Para una persona son fracciones de segundo de espera; para un bot simple, un callejón sin salida.
En ArtisanClo, el archivo PHP funciona justo así: si las reglas del flujo exigen JavaScript o un tiempo mínimo en la página, el visitante ve una página de espera y se revisa de nuevo. En cambio, al conectar con el filtro para Keitaro o la pasarela para Binom no hay página de comprobación: la decisión se toma solo por la red y las señales de la petición, así que ahí no actúan ni la comprobación de JavaScript ni el tiempo en la página.
Velocidad: dónde se pierden los milisegundos
Cualquier filtro añade a la carga el tiempo de la decisión. La diferencia está en dónde.
- El esquema de servidor añade una petición desde tu hosting al servicio antes de entregar el primer byte. La velocidad depende de la conectividad del hosting: un buen servidor en un centro de datos responde rápido; un hosting compartido saturado frena la landing y la comprobación.
- El esquema del navegador añade la carga del script y una petición desde el navegador del visitante. En internet móvil se nota más, pero la página se va cargando en paralelo: tras la decisión no hay que descargarla de nuevo.
- La página de comprobación añade espera a propósito. Actívala donde la fuente justifique el rigor, no en todas partes por defecto.
En la práctica, una landing con una decena de scripts de analítica e imágenes pesadas pierde más tiempo que con cualquiera de los métodos de filtrado. Optimizar la página suele aportar más que elegir arquitectura.
Fiabilidad: cómo se comporta el cloaker ante fallos
La tolerancia a fallos es donde más divergen las arquitecturas.
Si la etiqueta JS no cargó
La etiqueta es un script externo. Si no lo dejó pasar la red, un filtro corporativo o un bloqueador, la página simplemente no se oculta y la ven todos, incluidos bots y spy tools. Aquí el fallo es «abierto». Si la etiqueta cargó pero no hay decisión, manda al visitante a la White Page: un fallo «cerrado».
Si el servicio no respondió al servidor
El método de servidor espera la respuesta un tiempo limitado. En ArtisanClo, el archivo PHP espera hasta 4 segundos y, si se pierde la conexión, atiende las visitas durante un día con la última respuesta recibida: los visitantes con identificador de clic publicitario van a la oferta y el resto, a la White Page. Una visita que llegue antes de la primera respuesta recibirá un error 503. El filtro para Keitaro y la pasarela para Binom tienen un límite de 3 segundos, tras el cual la visita va a la White Page.
Si se cae el hosting
Aquí ambos esquemas son iguales: la landing vive en tu servidor, y el filtro no levantará un servidor caído. El servicio responde de la decisión; tú, de la disponibilidad de la página y del certificado.
| Situación | Etiqueta JS | Archivo PHP |
|---|---|---|
| Script bloqueado por el camino | Todos ven la página | No aplica |
| El servicio no respondió | White Page | Funciona con la última respuesta hasta un día |
| Sin conexiones salientes desde el hosting | No afecta | Error 503, carga lenta |
| Firewall de aplicaciones del hosting (WAF) | No suele afectar | Puede cortar las peticiones de comprobación |
Caché, CDN y proxies: los enemigos silenciosos del cloaking de servidor
El esquema de servidor cuenta con que cada petición llegue al archivo PHP. Tres cosas lo impiden.
- La caché de páginas. Un plugin de caché, la caché del hosting o una CDN entregan una copia guardada sin pedir la decisión. Como resultado, todos ven la misma página: la que quedó en caché. La landing con filtro hay que excluirla de la caché. A la etiqueta le afecta menos la caché del HTML: el script de la copia se ejecutará igualmente en el navegador, si la copia se hizo después de instalarlo.
- Un proxy delante del sitio. Si el hosting pone su propio proxy delante del servidor, el archivo PHP ve la dirección del proxy en lugar de la del visitante, y el filtro evalúa tu servidor, no a las personas. La señal: todas las visitas del registro tienen la misma IP. Se soluciona pasando la dirección real (configuración de real IP) o usando Cloudflare como proxy, cuyas cabeceras entiende el archivo.
- La caché de la decisión. Para no preguntar al servicio en cada recarga, la decisión de un visitante puede guardarse poco tiempo. En ArtisanClo, con el archivo PHP, hasta un minuto, así que tras cambiar el flujo comprueba en una ventana de incógnito nueva.
El análisis de estas y otras averías está en el artículo el cloaker no funciona.
Lo que solo puede hacer el esquema de servidor
Hay posibilidades que al código del navegador le son físicamente inaccesibles.
- Un código de respuesta en lugar de una página. El servidor puede responder 403 o 404, como una dirección cerrada. La etiqueta no puede cambiar el código de respuesta: en su lugar quedará una página vacía.
- El modo sombra. Todos los visitantes van a la oferta y el registro muestra a quién habría descartado el filtro. Así se prueba una regla nueva sin perder tráfico.
- El modo «Tracker». El filtro no corta a nadie: solo cuenta clics, conversiones y dinero y marca los bots en los informes. Encaja con el tráfico que necesita registro y no filtrado; más detalles en el artículo tracker para marketing de afiliados.
En ArtisanClo, el modo sombra y el modo «Tracker» funcionan con el archivo PHP, el filtro de Keitaro o la pasarela de Binom; con la etiqueta JS, el flujo filtra como un cloaker normal.
Actualizaciones y mantenimiento
Otra diferencia que no se recuerda enseguida: quién se encarga de que el código del sitio esté al día.
- La etiqueta JS se carga desde el servicio en cada visita. Cuando el servicio mejora las comprobaciones del navegador, todos los sitios con la etiqueta reciben la nueva versión automáticamente; no tienes que cambiar nada.
- El archivo PHP está en tu hosting y no se actualiza solo. La lógica de las comprobaciones y las bases de bots viven del lado del servicio, así que el trabajo principal del filtro mejora sin ti, pero las funciones nuevas del propio archivo exigen sustituirlo. En ArtisanClo lo avisa un banner, «Estás usando un archivo antiguo», con la lista de lo que tu versión actual no sabe hacer.
En ambos casos, la configuración del flujo se guarda en la cuenta, no en el código del sitio. Si cambias los países, el rigor o la White Page, los cambios actúan desde la siguiente visita, sin volver a subir el archivo ni pegar de nuevo la etiqueta.
Aparte, conviene recordar los permisos. El archivo PHP se ejecuta en tu servidor, así que descárgalo solo desde la cuenta del servicio y no lo edites a mano: un archivo «mejorado» sacado de un chat o un foro puede hacer cualquier cosa en tu hosting.
Cloaker PHP o etiqueta JS: qué elegir
| Tu situación | Qué encaja |
|---|---|
| Creador de sitios sin acceso al servidor | Etiqueta JS |
| Hosting propio con PHP | Archivo PHP |
| WordPress | El plugin, que instala el mismo método de servidor |
| Necesitas registro sin filtrado o probar reglas en modo sombra | Archivo PHP |
| El tráfico ya pasa por Keitaro o Binom | El filtro o la pasarela del tracker: ver Keitaro y cloaking |
| El hosting prohíbe las conexiones salientes | Etiqueta JS |
En pocas palabras: la etiqueta se instala más rápido; el método de servidor es más fiable y da más modos. La configuración del filtrado no depende de la arquitectura: se guarda en el flujo, y el método de conexión se puede cambiar sin tocar las reglas. La comparación con los scripts caseros, que también suelen llamarse «cloaker PHP», está en el artículo cloaker en la nube o script propio.
Consejo. Elijas el esquema que elijas, después de instalarlo abre el enlace del anuncio en incógnito y busca tu visita en el registro de clics. El motivo de la decisión te dirá enseguida si el filtro ve la IP real, si la comprobación funciona y si la caché no está entregando una copia antigua.
Filtrado en el servidor y reglas de las plataformas
La arquitectura no cambia el lado legal. Las plataformas publicitarias prohíben mostrar al sistema de revisión de anuncios algo distinto de lo que verá el usuario, da igual si lo decide el servidor o el navegador. El beneficio honesto de cualquier esquema es descartar bots, clics fraudulentos, spy tools y geos no objetivo, tener estadísticas limpias y llevar las cuentas del dinero. Más detalles en el artículo cloaker para marketing de afiliados.
En resumen
- El cloaking del lado del servidor decide antes de entregar la página: no depende de los bloqueadores y permite códigos de respuesta, el modo sombra y el modo «Tracker», pero exige PHP, conexiones salientes y cuidado con la caché y los proxies.
- El cloaking en el navegador se instala en cualquier
<head>y ve señales inaccesibles para el servidor, pero el HTML de la página ya está en el navegador y un script que no carga no oculta nada. - Lo mejor de ambos mundos lo da la decisión en el servidor con página de comprobación: la red y la petición las mira el servidor, y el comportamiento y el entorno, un breve JavaScript en el navegador.
- Las condiciones, posibilidades y la composición de los planes están en las páginas de funciones y de planes.
