Google está precargando tus anuncios. Por qué importa
Google está precargando tus anuncios. Por qué importa
Cómo el Private Prefetch Proxy de Chrome elimina la IP del usuario en una quinta parte de tus clics de pago, y qué supone eso para las herramientas en las que confías para detectar el fraude.
Resumen
Una parte creciente del tráfico que llega a las landing pages de tus campañas de Google Ads nunca procede de una persona. Procede de Google.
Cuando alguien hace una búsqueda en Google, Chrome precarga con frecuencia la landing page del anuncio en el que es más probable que haga clic, antes de que el clic se produzca. Además, enruta esa petición a través de un proxy operado por Google que oculta la dirección IP real del usuario. En los logs, la visita aparece como procedente de la propia red de Google (en nuestro caso, normalmente el sistema autónomo AS15169) y lleva el identificador de clic del anuncio.
Se trata de infraestructura legítima de Google, no de fraude. Pero tiene una consecuencia indeseada: en la cuenta que analizamos, aproximadamente el 20% de los clics facturados pasó por este mecanismo de precarga, y en torno al 60% de esos clics precargados nunca llegamos a ver la dirección IP real del usuario. El clic se sirvió desde la caché local de Chrome, así que la navegación real nunca llegó a tocar nuestro servidor.
Es un problema real de transparencia y de verificación, y debilita las herramientas antifraude basadas en el navegador de las que dependen la mayoría de los anunciantes.
En definitiva: la precarga afecta ya a una parte significativa del tráfico de Google Ads, y la mayoría de las herramientas antifraude estándar apenas tienen visibilidad sobre ella. En última instancia, esas herramientas bloquean los clics inválidos excluyendo la IP del visitante en Google Ads, y un clic precargado llega desde una IP de Google, con la IP del usuario oculta. En Fáktica Analytics abordamos el problema de otra manera: trabajamos directamente con los datos y los logs de servidor de cada cliente, en lugar de entregar a todos el mismo script genérico. Y no dependemos del bloqueo de IPs: para nosotros, las direcciones IP son solo una herramienta más entre muchas.
¿Qué es la precarga (prefetching)?
La precarga (prefetching o preloading) es una funcionalidad de rendimiento del navegador. Su único propósito es la velocidad. Cuando haces una búsqueda en Google, Chrome intenta predecir qué resultado o anuncio es más probable que abras y descarga esa página por adelantado. Así, si haces clic, la página aparece casi al instante.
Eso trae consigo un problema de privacidad. Si Chrome descargara la página directamente desde tu dispositivo, el servidor de destino vería tu dirección IP antes de que hubieras decidido visitarlo, y sabría que estás a punto de entrar. Para evitar esa filtración, Chrome enruta la precarga a través del Private Prefetch Proxy, un proxy CONNECT operado por Google. El servidor de destino nunca ve tu IP. Solo ve la de Google.
Así que, en un log de servidor, un clic de anuncio precargado tiene este aspecto:
- La petición viene de una dirección IP de Google (en nuestro caso, normalmente AS15169), no de la del usuario.
- Normalmente lleva el user-agent del navegador real (un Chrome auténtico y actualizado).
- Solicita la URL completa de la landing page, incluidos el identificador de clic gclid/gbraid y los UTM.
- El clic humano real, si se produce, a menudo se sirve directamente desde la caché local de Chrome, sin una segunda petición a tu servidor.
Dicho de otro modo: el clic en el anuncio y la precarga comparten el mismo identificador, pero puede que la visita que realmente puedes ver e inspeccionar nunca llegue.
Lo que dice Google
Google presenta esto exclusivamente como una funcionalidad de rendimiento y privacidad, y en sus propios términos esa descripción es correcta. La documentación de Chrome para desarrolladores describe el Private Prefetch Proxy como una forma de acelerar las navegaciones salientes desde la Búsqueda de Google. Empezó a desplegarse con Chrome 103 en Android y, según la documentación, mejora esas navegaciones en torno a un 30% en la mediana. Google también deja claro que el proxy está diseñado para que el servidor de destino no pueda ver la dirección IP del usuario hasta que este navega realmente.
Google ha hecho además una segunda afirmación, más específica. En una publicación de Chrome for Developers fechada el 12 de febrero de 2025, explicaba cómo la Búsqueda de Google precarga las páginas de resultados y afirmaba que evita deliberadamente los anuncios. Según esa publicación, la Búsqueda enumera explícitamente las URL de los resultados para no «precargar otras URL, como las de los anuncios». Sobre el papel, por tanto, el mecanismo de precarga documentado de la Búsqueda de Google está diseñado para precargar resultados de búsqueda excluyendo las URL de los anuncios.
Eso no es lo que muestran nuestros logs. El tráfico de precarga que vemos llega a landing pages de pago: todas las peticiones llevan un identificador de clic de anuncio. Y llega con la firma exacta del private prefetch proxy (la propia red de Google, una IP anonimizada) que Google documenta para los resultados orgánicos.
Puedes comprobarlo tú mismo sin tocar un solo log de servidor. Haz una búsqueda en Google desde Chrome en escritorio y abre las Chrome DevTools. En el panel Application → Speculative loads, Chrome muestra todas las URL que la página le ha indicado precargar o prerenderizar mediante la Speculation Rules API. Las URL de landing pages de anuncios aparecen en esa lista con regularidad. Lo puedes ver en las capturas de abajo, donde la página pide al navegador que cargue el destino de un anuncio antes de que el usuario haya hecho clic en nada (fíjate en los parámetros gclid, gad_source y gbraid de la URL).
Compruébalo en directo. Arriba: las propias DevTools de Chrome (Application → Speculative loads) en una página de resultados de Google. La URL del anuncio de autoeurope.es, con su gclid incluido, ya está precargada y «lista para la siguiente navegación». Abajo: el resultado patrocinado al que pertenece esa URL, en la misma búsqueda «car rental chicago».
Fuera cual fuera la intención declarada en febrero de 2025, los anuncios se están precargando a gran escala, y cada vez más.
El mensaje práctico que suelen recibir los anunciantes es alguna versión de «ese tráfico de tus logs es solo infraestructura de Google; no son clics que te estén cobrando, así que ignóralo».
Y, en sentido estricto, es cierto: una precarga no es, por sí misma, un clic facturable. Lo que ese planteamiento omite es el efecto posterior. El mismo mecanismo que protege la privacidad del usuario elimina también la señal más útil que tienen los anunciantes para validar su propio tráfico: la IP real del visitante. Y la elimina en una parte significativa de los clics que sí les facturan. La propia documentación de Google señala directamente este efecto secundario: como Chrome no realiza ninguna consulta DNS observable para una página precargada, puede que el filtrado de contenidos a nivel de red no funcione como debería en esas navegaciones. Lo que el usuario gana en privacidad, el anunciante lo pierde en visibilidad.
Fuentes: documentación de Google — Proxy privado de carga previa en Chrome para administradores de red, el Proxy privado de carga previa en Chrome, y la publicación del 12 de febrero de 2025 Cómo usa la Búsqueda de Google las reglas de especulación.
Lo que vemos en nuestros logs
Analizamos cinco meses de logs de servidor (abril–agosto de 2026) de una cuenta de anunciante, limitándonos al tráfico de pago de Google. Es decir, todas las peticiones etiquetadas como source / medium = google / cpc y con un identificador de clic gclid. Dentro de ese tráfico de pago, una parte grande y creciente no llega desde un usuario, sino desde la propia Google (AS15169):
La porción de AS15169 tiene una huella inconfundible: el 99,97% era Chrome, repartido entre escritorio y Android, con versiones naturales y actualizadas, no un user-agent fijo de bot. Es exactamente la firma de la precarga de landing pages de anuncios, no la de un rastreo genérico.
Si lo comparamos con los clics que Google facturó en el mismo periodo, el titular es este: aproximadamente 1 de cada 5 clics facturados (≈20%) había pasado por precarga. El resto no, en gran medida porque iOS/Safari no usa el proxy de precarga de Chrome y no todas las impresiones se precargan. La precarga es una capa de transporte que afecta a una minoría aleatoria de tus clics de pago, no a todos.
Nota: esto hace que la ausencia de precarga no tenga ningún valor como señal de fraude. La mayoría de los clics legítimos no tienen precarga. No tratamos la «ausencia de precarga» como algo sospechoso, y nadie debería hacerlo.
¿Cuándo empezó esto?
No siempre fue así. Si miramos más atrás, el tráfico de precarga desde Google hacia esas mismas landing pages era residual hasta finales de 2025, con unos pocos cientos de peticiones por trimestre. Luego se disparó:
El aumento de la precarga no es crecimiento de tráfico. Los clics en anuncios se mantienen estables mientras las peticiones de precarga de Google pasan de 180 a 10.275 por trimestre. Fuente: Fáktica Analytics.
La pregunta obvia es si esto simplemente acompaña a un aumento de la publicidad: más impresiones, más clics y, por tanto, más de todo, precarga incluida. No es así. En exactamente el mismo periodo, en las mismas campañas de Búsqueda de Google, el volumen de anuncios se mantuvo estable. Las impresiones se movieron en una franja de aproximadamente 85.000–137.000 por trimestre, y los clics en una de aproximadamente 3.600–5.200. Terminan el T2 de 2026 casi exactamente donde empezaron en el T1 de 2024. La precarga, en cambio, pasó de una media de 227 peticiones por trimestre entre el T1 de 2024 y el T2 de 2025 a 10.165 por trimestre en el T1–T2 de 2026. Eso supone un aumento de unas 45 veces, frente a unos clics prácticamente estables.
Datos de Google Ads: Tipo de campaña = Búsqueda; Red = Búsqueda de Google (únicamente). El gráfico termina en el T2 de 2026, el último trimestre completo. Como referencia, la precarga solo en julio de 2026 (T3 de 2026 parcial) ya fue de 4.573.
El patrón se divide en tres fases. Durante 2024 y el primer semestre de 2025, la precarga era un nivel base residual, de unos pocos cientos de peticiones por trimestre. En el T3–T4 de 2025 se disparó, pasando de menos de 300 a más de 6.000 en dos trimestres. A lo largo de 2026 se ha asentado en una nueva normalidad por encima de 10.000 por trimestre. Y todo ello mientras tu audiencia real seguía siendo del mismo tamaño.
Sea cual sea la causa exacta (un despliegue más amplio, más cobertura de Android/Chrome, criterios de elegibilidad más amplios), esto se ha convertido en una característica habitual del tráfico de búsqueda de pago prácticamente en el último año. Y no hay ningún cambio en tu inversión ni en tu alcance que lo explique.
Merece la pena detenerse en estas fechas. Cuando Google publicó el 12 de febrero de 2025 su descripción de la precarga como «solo resultados orgánicos, sin anuncios», era básicamente exacta: hasta mediados de 2025, la precarga de landing pages de anuncios era residual. Dejó de ser exacta ese mismo año. En el T4 de 2025, justo el tráfico que esa publicación dice que Google evita se había multiplicado hasta miles de peticiones por trimestre, y no ha dejado de crecer desde entonces.
Si auditaste por última vez el tráfico de tus anuncios antes de mediados de 2025 y concluiste que la precarga era despreciable, esa conclusión ya está desfasada.
Por qué importa: transparencia, verificación y control del fraude
Aquí está el quid de la cuestión. De los clics facturados que pasaron por la precarga, en torno al 60% no dejó ningún rastro del usuario. Google facturó el clic, Chrome sirvió la página desde su caché precargada y nuestro servidor nunca registró una petición desde la IP real del usuario. Podemos ver que se cobró un clic, pero no podemos ver de forma independiente quién lo hizo, desde dónde ni en qué red.
Para dejar claro qué es esto y qué no es:
- No es una prueba de fraude. En nuestro análisis, este tráfico servido desde caché y sin IP era, de forma abrumadora, búsqueda de marca de alta intención desde escritorio. Es exactamente el perfil de clics legítimos con los que la precarga funciona mejor y a los que luego vuelve invisibles. Un bot de centro de datos no puede fabricar una precarga: la activa Chrome en la propia página de resultados de Google y sale desde una IP de Google. La precarga no es un canal que el fraude pueda aprovechar para colarse.
- Es una pérdida de verificabilidad. En aproximadamente una quinta parte de tus clics de pago, y en torno al 60% de esa quinta parte, se te pide que aceptes la facturación por confianza. La única señal que usarías para comprobarla (la IP y la red del usuario) se ha eliminado en origen.
Durante la mayor parte de la historia, la validación del tráfico publicitario se ha basado en una premisa: el tráfico que llega a mi página lleva la IP real del visitante, así que puedo clasificarlo (residencial o centro de datos, humano o bot, geografía esperada o anomalía). La precarga rompe esa premisa en una parte creciente del tráfico de pago. No estás ante un fraude que no puedes ver; estás ante una legitimidad que ya no puedes confirmar. Y, alrededor de ese tráfico, hay mucho ruido real de scrapers desde centros de datos que hay que separar antes de poder sacar cualquier conclusión con seguridad.
La conclusión no es «confía menos en Google». Es «la visibilidad desde el navegador ya no es suficiente». La única forma de cerrar esa brecha es conciliar a nivel de log, por identificador de clic, con lo que Google ha facturado realmente.
Qué supone esto para ClickCease, Lunio y otras herramientas antifraude de clics
La mayoría de los productos antifraude comerciales (ClickCease, Lunio y el resto de esa categoría) funcionan de forma bastante parecida. Se sitúan en la ruta del clic, mediante una etiqueta JavaScript en tu landing page o una redirección de seguimiento a través de los propios servidores del proveedor. Capturan la IP real del visitante y las señales del dispositivo, y las puntúan. Si la visita parece fraudulenta, añaden esa IP a tu lista de exclusión de IPs de Google Ads para que no pueda volver a costarte dinero.
La precarga debilita ese modelo de dos formas concretas y estructurales:
- Ceguera de origen. Cuando un clic se sirve desde la caché de precarga de Chrome (buena parte de ese ~60% mencionado arriba), el punto de detección de la herramienta puede no ver nunca una nueva petición con la IP del usuario. Ese punto de detección es una etiqueta en tu landing page o una redirección a través de los servidores del proveedor en el momento del clic. La precarga llegó desde la IP de Google y la navegación real se sirvió en local. La herramienta, sencillamente, nunca ve al visitante que se supone que debe evaluar.
- La exclusión de IPs no puede actuar. Una petición precargada llega desde una IP de Google, no desde la del usuario. Las listas de exclusión de IPs operan sobre la IP del usuario. Así que un clic que llega de esta forma es, por definición, inmune al bloqueo por IP: no hay IP de usuario que bloquear.
Dos matices. Primero, la precarga no es en sí misma un vector de fraude: un bot no puede provocarla. Segundo, el efecto es limitado, por ahora. Solo un ~20% de los clics facturados pasa por precarga, así que el ~80% de tu tráfico de pago sigue siendo plenamente visible para estas herramientas. Pero ese «por ahora» tiene mucho peso en la frase. Ese límite lo mueve Google. Igual que la precarga se disparó en el T4 de 2025, nada impide otro salto que amplíe el punto ciego de la noche a la mañana.
Aun así, la conclusión es difícil de evitar: la detección desde el navegador tiene un punto ciego estructural y permanente que no puede cerrar por sí sola. Los clics que no puede ver son, por definición, aquellos en los que su señal principal (la IP del usuario) se eliminó antes de que la etiqueta llegara a ejecutarse. Detectar lo que ocurre dentro del navegador no sirve para un tráfico que se resolvió antes de que el navegador llegara a tu página. Esa cobertura solo se consigue conciliando los logs de servidor con los datos de facturación de Google.
Dónde entra Fáktica Analytics
Esta es exactamente la brecha que Fáktica Analytics existe para cerrar.
No dependemos de una etiqueta en el navegador que solo ve los clics que Google le deja ver. Trabajamos a partir de tus logs de servidor en bruto y los conciliamos clic a clic con lo que Google ha facturado realmente. Después separamos de forma forense el tráfico legítimo de la actividad inválida real, incluidos los clics precargados y servidos desde caché ante los que las herramientas de navegador se quedan ciegas. Así es como los «clics que me piden que dé por buenos» vuelven a ser «clics que puedo verificar».
Ayudamos a los anunciantes en todo el ciclo:
Si un ~20% de tus clics de pago llega con su origen borrado, estás tomando decisiones de presupuesto, y de fraude, con información parcial. Podemos enseñarte lo que hay realmente en tus logs.
