Hace un año, se podía obtener los resultados de Google con una sola solicitud GET con el parámetro num=100 — cien resultados llegaban en HTML puro. En 2026, eso ya no funciona: Google ha eliminado el acceso sin JavaScript, ha reducido a cien resultados por página y ha añadido un bloque AI Overviews, que se renderiza de forma asíncrona y no es visible desde todas las IP. Vamos a analizar cómo recolectar SERP en estas nuevas condiciones, dónde están las trampas ocultas y por qué la elección del tipo de proxy se ha vuelto más importante que el propio scraper.
Para quién es esta guía
El scraping de resultados de búsqueda (SERP scraping) no se trata solo de posiciones SEO. Hoy en día, se utiliza por:
- Especialistas y agencias de SEO — monitorean la orgánica, los fragmentos destacados, "La gente también pregunta", los resultados locales y si el sitio ha aparecido en AI Overviews.
- Analistas de mercado — observan a quién cita Google en los bloques de IA para consultas comerciales y cómo cambia la primera página de los competidores.
- Equipos de IA y datos — recolectan SERP como fuente de datos para sistemas RAG, entrenamiento de modelos y verificación de hechos.
Todos comparten un problema: Google en 2026 distingue activamente el tráfico automático del tráfico humano, y sin la infraestructura adecuada, la recolección de datos se rompe en las primeras decenas de consultas.
Qué ha cambiado: tres golpes de Google a los scrapers
Para que la guía sea honesta, empecemos por qué las instrucciones antiguas ya no funcionan.
Enero de 2025 — SearchGuard. Google lanzó un sistema de desafíos de JavaScript: una solicitud HTTP normal a través de requests o httpx ahora recibe no HTML, sino una página de desafío. Sin la ejecución de JavaScript, no se puede ver la salida — el scraping directo "a la cara" falla instantáneamente.
Septiembre de 2025 — fin de num=100. Google eliminó el parámetro que devolvía 100 resultados por solicitud. Ahora, el top-100 son diez solicitudes separadas con paginación. Para un monitoreo profundo, esto significa un aumento literal de diez veces en el número de solicitudes (y, por ende, en la carga sobre los proxies y el presupuesto).
Diciembre de 2025 — presión legal. El 19 de diciembre de 2025, Google presentó una queja DMCA contra SerpApi, afirmando que SearchGuard es un "mecanismo de protección técnica" (technological protection measure), y su elusión está sujeta a normas anti-elusión. El precedente aún no se ha resuelto, pero establece el tono: el scraping gris de Google se vuelve más costoso tanto técnica como legalmente.
Es importante señalar que la API de Búsqueda Personalizada de Google se está descontinuando: a los clientes existentes se les ha dado un plazo de migración hasta el 1 de enero de 2027. Es decir, la alternativa "legal" también se está reduciendo.
La principal novedad en los resultados — AI Overviews
AI Overviews (anteriormente SGE) son resúmenes generados por IA en la parte superior de los resultados con enlaces a las fuentes. Para el scraping, este es el elemento más complicado de 2026 por tres razones.
Son muchos. Según datos de Ahrefs, los AI Overviews aparecen en aproximadamente el 30% de las consultas; estimaciones más recientes (Olostep) indican hasta un 48% de todas las consultas y hasta un 80% de las informativas. Ignorar este bloque significa recolectar una imagen incompleta de los resultados.
Se renderizan de forma asíncrona. El bloque existe en tres estados: llega directamente en HTML (raramente), se carga a través de JavaScript segundos después de la página principal (el caso más común) o no aparece en absoluto. En la carga diferida, la respuesta HTTP cruda contiene un contenedor vacío — el contenido se carga más tarde, y el scraper debe esperar (en la práctica, alrededor de 8 segundos en la automatización del navegador).
No son visibles desde todas las IP. Este es el punto clave que silencian las guías antiguas: Google considera a los usuarios móviles como la audiencia prioritaria para la búsqueda de IA. En la práctica, esto significa que con IP de centro de datos, AI Overview a menudo no se entrega en absoluto, mientras que la misma consulta a través de un operador móvil devuelve el bloque completo. Incluso los principales agregadores reconocen la incompletud: SerpApi a principios de 2026 afirmaba tener alrededor del 68% de detección exitosa de AI Overviews.
Desglose paso a paso: cómo recolectar SERP en 2026
- Defina el volumen. Hasta ~100 consultas al día se pueden manejar con su propia automatización de navegador. De 100 a 10,000 — ya se necesita un scraper gestionado o SERP-API. Más de 10,000 al día sin infraestructura empresarial con lotes y webhooks no es viable. Esto determina todo el stack posterior.
- Reúna la URL correcta. El endpoint básico es /search, parámetros clave: q (consulta, codificación de URL), hl (idioma de la interfaz), gl (país de resultados), start (paginación: start=10 — segunda página, start=20 — tercera, y así sucesivamente). Recuerde: num=100 ya no funciona, la profundidad se acumula solo a través de la paginación.
- Utilice renderizado en navegador. Dado que no hay resultados sin JavaScript, el stack básico es Playwright o Selenium con Chromium sin cabeza. Asegúrese de eliminar los marcadores de automatización (bandera --disable-blink-features=AutomationControlled), de lo contrario, el anti-bot detectará el navegador gestionado por las propiedades de navigator.
- Espere AI Overview. Después de cargar la página, no tome el DOM de inmediato: deje que el networkidle se estabilice y espere la carga del bloque (referencia — hasta 8 segundos). La presencia del bloque se determina más confiablemente por el texto del encabezado "AI Overview", en lugar de por las clases CSS — estas son dinámicas en Google y cambian (los condicionales Kevs9, Y3BBE hoy son unos, mañana serán otros).
- Parsee por estructura, no por clases. Tome la orgánica por las etiquetas de encabezado (h3) y semántica, no por nombres de clases frágiles. De los resultados de 2026, están disponibles: resultados orgánicos, fragmentos destacados, "La gente también pregunta", consultas relacionadas, gráfico de conocimiento, paquete local, publicidad y citas dentro de AI Overview.
- Rote IP y reduzca la velocidad. Establezca pausas realistas entre consultas (4–12 segundos) y cambie IP aproximadamente cada 5 minutos, variando ciudad/operador. Un ritmo demasiado uniforme y una sola IP son el camino más rápido hacia el captcha.
Trampas ocultas
- AI Overview "vacío". Si toma el DOM inmediatamente después de la carga, el bloque diferido estará vacío — y usted concluirá que no existe. Siempre considere la espera y la verificación repetida.
- Sesiones de una sola vez para la carga diferida. Algunos API tienen una clave de sesión para cargar AI Overview diferido que es de un solo uso y vive alrededor de 60 segundos — no cuente con reutilizarla más tarde.
- Ahorro falso en el centro de datos. Las IP de centro de datos baratas capturan captcha ya en 5–10 consultas y además no muestran AI Overviews. El ahorro se convierte en datos incompletos y tiempo perdido.
- Selectores frágiles. Si se apega a los nombres de las clases CSS, el scraper fallará en el próximo rediseño de los resultados. Manténgase con el texto y la estructura.
- Huella uniforme de consultas. User-Agent, tiempos y encabezados idénticos en todos los flujos revelan un botnet. Diversifique la huella digital tanto como la IP.
Qué tipo de proxy elegir
En 2026, son los proxies, no el scraper, los que determinan si verá los resultados completos. Vamos a desglosarlo por tareas.
Proxies móviles — para AI Overviews y las consultas más "pesadas". Dado que Google entrega bloques de IA principalmente a la audiencia móvil, las IP reales de operadores (T-Mobile, Verizon, Vodafone y similares) activan AI Overview de manera más estable y soportan notablemente más — según observaciones, 50–200 consultas antes de que aparezca la fricción frente a 5–10 en el centro de datos. Además, la IP CGNAT móvil comparte una dirección con cientos de abonados vivos, por lo que Google teme bloquearla. Si su tarea es recolectar específicamente AI Overviews o monitorear SERP más protegidos, comience con proxies móviles.
Proxies residenciales — caballo de batalla para orgánica y volumen. Para recolectar resultados normales, posiciones, fragmentos destacados y paquetes locales, las IP residenciales (direcciones de proveedores domésticos) ofrecen la mejor relación calidad-precio y éxito. Son difíciles de distinguir de un usuario real, y la rotación permite escalar la recolección sin disparos desde una sola dirección. La opción óptima, cuando AI Overview no está en el foco, sino que son importantes el volumen y la geografía, son proxies residenciales con rotación.
Centro de datos — solo para pruebas preliminares. Rápido y barato, pero contra Google en 2026, vive solo unas pocas consultas y no ve bloques de IA. Es adecuado para depurar la lógica del scraper, no para recolección en producción.
Si no está seguro de qué elegir para una tarea específica, comience con el análisis de proxies residenciales frente a proxies móviles en 2026: allí se detalla dónde cada tipo ahorra dinero y dónde — datos.
Conclusión
El scraping de Google en 2026 ha dejado de ser una tarea de "escribir un scraper". SearchGuard obligó a renderizar JavaScript, la eliminación de num=100 ha multiplicado por diez el número de solicitudes, y AI Overviews ha añadido un bloque que es visible principalmente desde IP móviles y se carga con retraso. Técnicamente, todo es resoluble: automatización de navegador, scraping por estructura, pausas razonables y rotación. Pero el fundamento sobre el que se sostiene la integridad y estabilidad de la recolección son los proxies correctos: móviles para AI Overviews y consultas protegidas, residenciales para orgánica y volumen. Comience con el tipo de proxy para su tarea — y el scraper dejará de tropezar con el captcha.
```