> El server-side tagging no elimina el consentimiento de cookies. Qué cambia, mitos que debe evitar y cómo integrarlo con Consent Mode v2 cumpliendo el RGPD.
>
> Canonical: https://www.flowconsent.com/es/blog/server-side-tagging-cookies-consentimiento

[Herramientas de marketing](https://www.flowconsent.com/es/blog?category=tools)

# Server-side tagging y cookies: impacto en el consentimiento

Por FlowConsent · Publicado el 30 de marzo de 2026 · Actualizado el 1 de octubre de 2026 · 8 min de lectura

En resumen

El server-side tagging no elimina la obligación de consentimiento. Qué cambia realmente, mitos que debe evitar y cómo integrarlo con Consent Mode.

## Resumen

El server-side tagging traslada la recogida de datos del navegador del usuario a un servidor que usted controla. Esto le permite filtrar, anonimizar o bloquear datos antes de enviarlos a terceros (Google, Facebook, etc.), sortear los bloqueadores de anuncios y las restricciones de los navegadores (ITP de Safari, retirada de las cookies de terceros en Chrome) y ampliar la vida útil de las cookies propias. Sin embargo, el server-side tagging no elimina la obligación de consentimiento: si recoge datos personales, se aplican el RGPD y la Directiva ePrivacy, tanto si el tracking es client-side como server-side.

## ¿Qué es el server-side tagging?

El server-side tagging (etiquetado del lado del servidor) es un método de recogida de datos que traslada la ejecución de las etiquetas (scripts de seguimiento) desde el navegador del usuario a un contenedor de servidor gestionado por su organización. En lugar de que el navegador del usuario envíe los datos directamente a Google Analytics, Facebook u otros servicios de terceros, los datos pasan primero por su servidor, que decide qué transmitir, a quién y de qué forma.

En el modelo tradicional client-side (el modelo dominante hasta ahora), cada etiqueta de terceros se carga en el navegador del usuario. Esto significa que Google, Facebook y todos los demás servicios de terceros reciben los datos directamente del navegador, sin que usted pueda controlar con precisión lo que se transmite.

Con el server-side tagging, el navegador solo envía datos a su servidor (normalmente un subdominio de su propio dominio, como `analytics.yoursite.com`). Después, su servidor procesa esos datos y los redistribuye a los servicios de terceros mediante conexiones de servidor a servidor. Así tiene control total sobre los datos que salen de su infraestructura.

## ¿Por qué el server-side tagging gana terreno en 2026?

Varios factores convergen para convertir el server-side tagging en el nuevo estándar de recogida de datos.

### Restricciones de los navegadores

Safari (ITP) limita a 7 días las cookies creadas por JavaScript y bloquea las cookies de terceros desde 2020. La protección mejorada contra el rastreo de Firefox bloquea por defecto los scripts de seguimiento conocidos. Chrome empezó a restringir las cookies de terceros en 2025. Estas restricciones reducen la vida útil y la fiabilidad de las cookies client-side, lo que degrada la calidad de los datos de analítica y publicidad.

### Bloqueadores de anuncios

Más del 40 % del público tecnológico en Europa y Norteamérica utiliza bloqueadores de anuncios. Estas herramientas bloquean las etiquetas client-side (GTM, GA4, Meta Pixel) a partir de listas de dominios conocidos. El server-side tagging desplegado en un subdominio propio es invisible para estos bloqueadores, porque las peticiones parecen proceder de su propio dominio.

### Control de los datos

El server-side tagging le permite filtrar, anonimizar o eliminar datos antes de enviarlos a terceros. Por ejemplo, puede eliminar la dirección IP del usuario antes de enviar los datos a Google Analytics, o aplicar un hash a las direcciones de correo electrónico antes de transmitirlas a Facebook para las conversiones. Este control es un elemento clave del cumplimiento del RGPD (principio de minimización de datos).

Eliminar la dirección IP no resuelve, sin embargo, todas las dudas sobre la herramienta de Google, como explica nuestro análisis sobre [si Google Analytics es conforme al RGPD](https://www.flowconsent.com/es/blog/google-analytics-conforme-rgpd).

### Rendimiento del sitio

Cada etiqueta client-side carga un script en el navegador, lo que ralentiza la carga de la página. Al trasladar el procesamiento al servidor, disminuye el número de scripts en el navegador, lo que mejora la velocidad de carga y, por extensión, el SEO y la experiencia de usuario.

## ¿El server-side tagging elimina la obligación de consentimiento?

No. Es el mito más extendido y el más peligroso. El server-side tagging no elimina la obligación de consentimiento prevista en el RGPD y la Directiva ePrivacy.

La Directiva ePrivacy (artículo 5, apartado 3, transpuesto en Francia por el artículo 82 de la Ley de Protección de Datos) exige el consentimiento para cualquier acceso a información almacenada en el terminal del usuario o cualquier almacenamiento en él, salvo para las cookies estrictamente necesarias. Si su implementación server-side coloca cookies propias para identificar a los usuarios, el consentimiento es obligatorio.

El RGPD se aplica a cualquier tratamiento de datos personales. Las direcciones IP, los identificadores de cliente, los user agents y otra información transmitida en las peticiones HTTP constituyen datos personales según el RGPD. Aunque elimine las cookies, el mero hecho de recoger y procesar estos datos en su servidor constituye un tratamiento que requiere una base jurídica (consentimiento, interés legítimo, etc.).

En resumen: el server-side tagging cambia el «dónde» y el «cómo» de la recogida, no el «si». Sigue necesitando un [banner de cookies conforme](https://www.flowconsent.com/es/blog/banner-cookies-conforme-rgpd-guia) y una [CMP](https://www.flowconsent.com/es/blog/elegir-cmp-plataforma-gestion-consentimiento) para obtener el consentimiento antes de recoger datos no esenciales.

## Lo que el server-side tagging cambia realmente para el consentimiento

Aunque el server-side tagging no elimina la obligación de consentimiento, sí cambia de forma significativa cómo se aplica técnicamente el consentimiento.

### Aplicación del consentimiento en el servidor

En modo client-side, el bloqueo de etiquetas depende del navegador: la CMP debe impedir que los scripts se carguen antes del consentimiento. Si un script se carga de todos modos (error de configuración, problema de timing, caché), la cookie se coloca. En modo server-side, el consentimiento puede verificarse en el servidor antes de transmitir los datos a terceros. Esto constituye una capa de verificación adicional, más fiable que el bloqueo client-side por sí solo.

### Filtrado y anonimización de datos

El servidor puede eliminar o anonimizar datos personales antes de transmitirlos. Por ejemplo: eliminar la dirección IP antes del envío a GA4, aplicar un hash a los correos electrónicos para las API de conversión (Facebook CAPI, Google Enhanced Conversions) o eliminar parámetros de URL que contengan identificadores personales.

En el caso de Meta, nuestra guía sobre [Meta Pixel, cookies y cumplimiento del RGPD](https://www.flowconsent.com/es/blog/meta-pixel-cookies-rgpd-cumplimiento) explica cómo mantener el píxel bloqueado hasta que el visitante dé su consentimiento.

### Cookies propias con mayor vida útil

Las cookies definidas por el servidor (mediante cabeceras HTTP `Set-Cookie` en la respuesta) no están sujetas a las mismas restricciones que las cookies creadas por JavaScript. El ITP de Safari limita las cookies JavaScript a 7 días, pero las cookies server-side (creadas desde un subdominio propio) pueden tener una vida útil más larga. Esto mejora la calidad del seguimiento de los visitantes recurrentes, pero no cambia la obligación de consentimiento para estas cookies.

## Cómo integrar el server-side tagging con Consent Mode

[Consent Mode v2](https://www.flowconsent.com/es/blog/consent-mode-basico-vs-avanzado) funciona tanto en modo client-side como en modo server-side. En una arquitectura server-side, el flujo es el siguiente.

La CMP recoge el consentimiento en el lado del cliente (en el navegador). El estado del consentimiento se transmite al contenedor de servidor de GTM con cada evento. El contenedor de servidor comprueba el estado del consentimiento antes de transmitir datos a servicios de terceros. Si el consentimiento es «denied», los datos no se transmiten (modo básico) o se transmiten como pings anonimizados (modo avanzado).

Para la parte del cliente, la [documentación de Consent Mode v2 de FlowConsent](https://www.flowconsent.com/es/doc/google-consent-mode) explica cómo se fijan los valores predeterminados en «denied» antes de que se cargue cualquier etiqueta.

Esta arquitectura ofrece una doble verificación: la CMP bloquea los scripts en el lado del cliente y el servidor verifica el consentimiento antes de cada transmisión. Es la configuración más sólida para garantizar que los datos no salgan de su infraestructura sin consentimiento.

Para comprobar en la práctica que se respetan los rechazos, la [verificación de cumplimiento de FlowConsent](https://www.flowconsent.com/es/doc/compliance-verification) escanea sus páginas rechazando el consentimiento y conserva la prueba.

## Errores frecuentes (y cómo evitarlos)

**Creer que el server-side tagging elimina la necesidad de consentimiento.** Es falso. El RGPD y la Directiva ePrivacy se aplican tanto si el tracking es client-side como server-side. Solución: mantenga su banner de consentimiento y su CMP, incluso con una arquitectura server-side.

**Usar el server-side tagging para sortear los bloqueadores sin consentimiento.** Desplegar el tracking en un subdominio propio para sortear los bloqueadores de anuncios es técnicamente posible, pero hacerlo sin consentimiento supone recoger datos infringiendo el RGPD. Solución: sortear los bloqueadores de anuncios solo es legal para los usuarios que han dado su consentimiento.

**Olvidar que las cookies server-side también requieren consentimiento.** Una cookie colocada mediante una cabecera HTTP `Set-Cookie` desde su servidor sigue siendo una cookie según la Directiva ePrivacy. Si no es estrictamente necesaria, se requiere consentimiento. Solución: incluya las cookies server-side en su [política de cookies](https://www.flowconsent.com/es/blog/politica-de-cookies-rgpd-guia) y en la configuración de su CMP.

**No auditar los datos que transmite el servidor.** El server-side tagging le da el control, pero ese control no sirve de nada si no verifica lo que realmente se transmite. Solución: audite con regularidad los flujos de datos salientes de su contenedor de servidor para comprobar que los datos personales se filtran o anonimizan correctamente.

En el lado del navegador, una [auditoría completa de las cookies de su sitio](https://www.flowconsent.com/es/blog/auditoria-cookies-sitio-web-guia-completa) sigue siendo el punto de partida para saber qué se instala realmente en los dispositivos de sus visitantes.

**Subestimar la complejidad técnica.** El server-side tagging requiere un servidor (normalmente Google Cloud Run o AWS), configuración DNS (subdominio propio) y mantenimiento continuo. No es un plugin que se instala con un clic. Solución: prevea los recursos técnicos necesarios o trabaje con un proveedor especializado.

**Pensar que el server-side resuelve el problema de los datos que faltan.** El server-side tagging mejora la cobertura (menos interferencias de los bloqueadores de anuncios, cookies más duraderas), pero los usuarios que rechazan el consentimiento siguen siendo invisibles. Solución: combine el server-side tagging con una [tasa de consentimiento optimizada](https://www.flowconsent.com/es/blog/tasa-consentimiento-cookies-medir-mejorar) y el modelado de conversiones para maximizar la cobertura.

## Checklist: server-side tagging y cumplimiento en materia de cookies

1. El [banner de consentimiento](https://www.flowconsent.com/es/blog/banner-cookies-conforme-rgpd-guia) se mantiene incluso con una arquitectura server-side.
2. El estado del consentimiento se transmite del cliente al contenedor de servidor con cada evento.
3. El contenedor de servidor verifica el estado del consentimiento antes de cualquier transmisión a terceros.
4. Las cookies server-side (propias) están declaradas en la política de cookies.
5. Los datos personales (IP, correo electrónico, identificadores) se filtran o anonimizan en el servidor antes de enviarlos a terceros.
6. El subdominio propio está configurado (por ejemplo, analytics.yoursite.com) con los registros DNS correctos.
7. [Consent Mode v2](https://www.flowconsent.com/es/blog/consent-mode-basico-vs-avanzado) está implementado y sus señales se propagan al contenedor de servidor.
8. Una [auditoría de cookies](https://www.flowconsent.com/es/scan) confirma que no se colocan cookies no esenciales antes del consentimiento, incluidas las cookies server-side.
9. Los flujos de datos salientes del servidor se auditan con regularidad.
10. La documentación de la arquitectura técnica está actualizada en el registro de actividades de tratamiento.

## Conclusión

El server-side tagging es una evolución importante de la recogida de datos que ofrece más control, más resistencia frente a las restricciones de los navegadores y los bloqueadores de anuncios, y más capacidad para filtrar datos personales. Pero no cambia las reglas fundamentales del consentimiento: el RGPD y la Directiva ePrivacy se aplican tanto si el tracking es client-side como server-side.

La arquitectura ideal combina el server-side tagging con una CMP conforme y Consent Mode v2 para garantizar que el consentimiento se verifique tanto en el lado del cliente como en el del servidor. Es la configuración más sólida para conciliar cumplimiento y calidad de los datos.

Para comprobar que su sitio no coloca cookies antes del consentimiento, incluidas las cookies server-side, [haga un escaneo gratuito con FlowConsent](https://www.flowconsent.com/es/scan).

[Volver al blog](https://www.flowconsent.com/es/blog)

Compartir el artículo · [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.flowconsent.com%2Fes%2Fblog%2Fserver-side-tagging-cookies-consentimiento) · [X](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.flowconsent.com%2Fes%2Fblog%2Fserver-side-tagging-cookies-consentimiento)

Preguntas

## Preguntas frecuentes sobre este tema.

¿No encuentra su pregunta? Escríbanos, respondemos rápido.

[Escríbanos](https://www.flowconsent.com/es/demo)

### ¿El server-side tagging elimina la necesidad del consentimiento de cookies?

No. El RGPD y la Directiva ePrivacy se aplican tanto si el tracking es client-side como server-side. Si colocas cookies (aunque sean propias) o recoges datos personales (direcciones IP, identificadores), el consentimiento es obligatorio. El server-side tagging cambia cómo se recogen y transmiten los datos, no la obligación legal de obtener el consentimiento.

### ¿El server-side tagging sortea los bloqueadores de anuncios?

Técnicamente sí, porque las peticiones se envían a un subdominio propio (por ejemplo, analytics.yoursite.com) en lugar de a dominios de terceros conocidos por las listas de bloqueo. Sin embargo, esta elusión solo es legal para los usuarios que han dado su consentimiento. Usar el server-side tagging para rastrear a usuarios sin consentimiento sigue siendo una infracción del RGPD.

### ¿Consent Mode v2 funciona con el server-side tagging?

Sí. Consent Mode v2 funciona tanto en modo client-side como server-side. El estado del consentimiento se transmite del navegador al contenedor de servidor de GTM con cada evento. El servidor verifica el consentimiento antes de transmitir datos a terceros, lo que ofrece una doble verificación (cliente + servidor).

### ¿Las cookies server-side están sujetas a las mismas restricciones que las cookies JavaScript?

No. Las cookies creadas por el servidor mediante cabeceras HTTP Set-Cookie no están sujetas a las restricciones del ITP de Safari (que limita las cookies JavaScript a 7 días). Las cookies server-side creadas desde un subdominio propio pueden tener una vida útil más larga. Sin embargo, siguen sujetas a la obligación de consentimiento de la Directiva ePrivacy.

### ¿El server-side tagging mejora la calidad de los datos?

Sí, de varias formas. Reduce el impacto de los bloqueadores de anuncios (las peticiones propias no se bloquean), amplía la vida útil de las cookies (se pierden menos visitantes recurrentes) y permite filtrar o anonimizar los datos antes de enviarlos a terceros. Sin embargo, los usuarios que rechazan el consentimiento siguen siendo invisibles.

### ¿Es complejo implementar el server-side tagging?

Sí. Requiere un servidor (normalmente Google Cloud Run o AWS), configuración DNS para el subdominio propio, la configuración del contenedor de servidor de GTM y mantenimiento continuo. No es un plugin que se instala con un clic. Los costes de alojamiento suelen ser de 20 a 50 euros al mes para un sitio de tamaño medio.

Siga leyendo

## Para saber más.

[Todos los artículos](https://www.flowconsent.com/es/blog)

[Herramientas de marketing · 27 de marzo de 2026](https://www.flowconsent.com/es/blog/consent-mode-v2-google-ads-impacto-campanas)

### [Consent Mode v2 y Google Ads: impacto en tus campañas](https://www.flowconsent.com/es/blog/consent-mode-v2-google-ads-impacto-campanas)

[Consent Mode v2 cambia la medición de conversiones de Google Ads en Europa. Modo básico frente a avanzado, conversiones modeladas, ROAS: lo que implica para tus campañas.](https://www.flowconsent.com/es/blog/consent-mode-v2-google-ads-impacto-campanas)

[Leer el artículo ](https://www.flowconsent.com/es/blog/consent-mode-v2-google-ads-impacto-campanas)·

[Herramientas de marketing · 21 de mayo de 2026](https://www.flowconsent.com/es/blog/google-privacy-sandbox-consentimiento-cookies-terceros)

### [Google Privacy Sandbox: Impacto en el Consentimiento y las Cookies de Terceros](https://www.flowconsent.com/es/blog/google-privacy-sandbox-consentimiento-cookies-terceros)

[Chrome mantiene las cookies de terceros y Google ha retirado la mayoría de las API del Privacy Sandbox. Qué ha cambiado de verdad y por qué sus obligaciones de consentimiento siguen siendo las mismas.](https://www.flowconsent.com/es/blog/google-privacy-sandbox-consentimiento-cookies-terceros)

[Leer el artículo ](https://www.flowconsent.com/es/blog/google-privacy-sandbox-consentimiento-cookies-terceros)·

[Buenas prácticas · 9 de octubre de 2026](https://www.flowconsent.com/es/blog/que-es-plataforma-gestion-consentimiento-cmp)

### [¿Qué es una consent management platform (CMP)? Definición y funcionamiento](https://www.flowconsent.com/es/blog/que-es-plataforma-gestion-consentimiento-cmp)

[Una consent management platform (CMP) pide permiso a los visitantes antes de activar las cookies, aplica su decisión y guarda la prueba. Qué hace una CMP, por qué la exige la ley y cómo funciona.](https://www.flowconsent.com/es/blog/que-es-plataforma-gestion-consentimiento-cmp)

[Leer el artículo](https://www.flowconsent.com/es/blog/que-es-plataforma-gestion-consentimiento-cmp)

## Haga que su sitio cumpla la normativa hoy mismo.

Gratis hasta 25.000 sesiones al mes. Sin tarjeta de crédito, sin compromiso.

[Crear mi banner](https://app.flowconsent.com/auth/sign-up?utm_source=flowconsent.com\&utm_medium=referral\&utm_campaign=general) · [Escanear mi sitio](https://www.flowconsent.com/es/scan)
