Cómo funciona realmente el scraping de SERP en 2026 (después de que Google eliminó num=100 y requirió JavaScript)
Dos cambios silenciosos — JavaScript obligatorio y la eliminación del parámetro num=100 — reescribieron la economía del scraping de búsqueda. Aquí está lo que realmente cambió, por qué tu rastreador de posiciones se rompió y cómo recopilar datos de SERP de manera confiable en 2026.
Si tu rastreador de posiciones se quedó en silencio repentinamente a finales de 2025, o tu scraper casero de Google comenzó a devolver páginas vacías, no lo imaginaste. En el transcurso de nueve meses, Google hizo dos cambios que, individualmente, parecían un mantenimiento menor y, juntos, reescribieron silenciosamente la economía del scraping de búsqueda. Esta es una guía práctica sobre lo que realmente cambió, por qué rompió tantas herramientas a la vez y cómo recopilar datos de SERP de manera confiable en 2026 sin quemar tu infraestructura — o tus IPs.
Cambio uno: Google hizo JavaScript obligatorio
El 17 de enero de 2025, Google comenzó a requerir JavaScript para usar Google Search. Si lo desactivas, obtienes un mensaje corto — "Activa JavaScript para seguir buscando" — en lugar de resultados. Un portavoz de la compañía dijo a TechCrunch que el objetivo era "proteger mejor nuestros servicios y usuarios de bots y formas de abuso y spam en evolución", y confirmó que menos del 0.1% de las búsquedas provienen de usuarios con JavaScript desactivado.
Esa cifra del 0.1% es reveladora. Con aproximadamente 8.5 mil millones de búsquedas al día, una décima parte de un por ciento sigue siendo millones de solicitudes — y una parte desproporcionada de ellas nunca fueron humanos en absoluto. Eran rastreadores de posiciones, rastreadores SEO y scrapers baratos golpeando la versión ligera, sin JavaScript de la página de resultados. Search Engine Journal confirmó la lectura directamente: Google está requiriendo JavaScript para bloquear bots y scrapers, incluidas herramientas SEO.
Habilitar JavaScript nos permite proteger mejor nuestros servicios y usuarios de bots y formas de abuso y spam en evolución, y proporcionar la información más relevante y actualizada.
La consecuencia práctica: la era de analizar Google obteniendo una URL y ejecutando una expresión regular sobre HTML estático ha terminado. Los resultados ahora se ensamblan del lado del cliente. Si tu scraper no puede ejecutar JavaScript, no ve una página degradada — no ve ninguna página.
Cambio dos: la muerte de num=100
El segundo cambio fue más pequeño en apariencia y mayor en impacto. Alrededor del 11 de septiembre de 2025, Google deshabilitó el parámetro de URL &num=100 — la pequeña bandera que indicaba a Search que devolviera 100 resultados en una sola página en lugar de los 10 predeterminados. Durante una década fue la columna vertebral del seguimiento profundo de posiciones: una solicitud, cien posiciones.
Cuando desapareció, las matemáticas se invirtieron de la noche a la mañana. Para ver los 100 mejores resultados ahora necesitas hasta diez solicitudes paginadas en lugar de una. Keyword Insights puso el costo de manera contundente el día que sucedió.
Google ha eliminado el parámetro n=100 de SERP. En lugar de 1 solicitud para 100 resultados de SERP, ahora se necesitan 10 solicitudes (10 veces el costo). Esto impacta nuestro módulo de rankings. Estamos revisando opciones y actualizaremos la plataforma pronto.
El efecto dominó también afectó a Google Search Console. A partir del 10 de septiembre, los equipos de SEO vieron caer bruscamente las impresiones de escritorio mientras que la posición promedio parecía mejorar. La teoría del analista Brodie Clark — ampliamente discutida pero nunca confirmada por Google — es que una gran parte de esas impresiones anteriores nunca fueron humanas: eran bots cargando páginas de 100 resultados a través de num=100, cada una registrando diez veces las impresiones que una página normal haría. Elimina el parámetro, y las impresiones fantasma desaparecen con él. Es una interpretación comunitaria, no una explicación oficial, pero encaja exactamente con el momento.
Por qué esto rompió tantas herramientas a la vez
La mayoría de las herramientas de SERP se construyeron sobre dos suposiciones que fueron verdaderas durante años y ahora son falsas: que Google serviría HTML utilizable sin JavaScript, y que podrías obtener 100 resultados por solicitud. Elimina ambos en el mismo año y los modos de falla se acumulan:
- Los fetchers estáticos devuelven páginas en blanco o de desafío en lugar de resultados.
- Los recolectores basados en paginación necesitan 10 veces el volumen de solicitudes para la misma cobertura, lo que significa 10 veces el ancho de banda del proxy y 10 veces la superficie de bloqueo.
- Más solicitudes desde los mismos rangos de IP activan los sistemas anti-bot más rápido, por lo que las tasas de éxito caen exactamente cuando el volumen necesita aumentar.
- Las líneas base de Search Console cambiaron, por lo que los paneles históricos ya no comparan de manera similar.
Como lo enmarcó el ingeniero de SEO Ryan Jones, la ola agresiva de scraping — gran parte de ella ahora alimentando productos de IA — es precisamente lo que empujó a Google a contraatacar, rompiendo verificadores de posiciones y scrapers de SERP como daño colateral. Las herramientas no fallaron porque estuvieran mal escritas. Fallaron porque el terreno se movió.
Cómo se ve el scraping de SERP confiable en 2026
La nueva línea base tiene tres elementos no negociables. Si falta alguno, tu tasa de éxito colapsa bajo carga.
1. Ejecutar JavaScript — pero solo cuando sea necesario
Debido a que los resultados se ensamblan del lado del cliente, necesitas un cliente que ejecute JavaScript para las páginas que lo demandan. Pero iniciar un navegador sin cabeza para cada solicitud es lento y costoso. El patrón eficiente es intentar primero una obtención ligera con huella digital TLS real y escalar a una renderización completa del navegador solo cuando la página realmente te desafía. La mayoría de las solicitudes nunca necesitan el navegador; las que lo necesitan lo obtienen automáticamente.
2. Rotar salidas residenciales con huellas digitales de navegador reales
Las IPs de centros de datos y las huellas digitales de clientes HTTP predeterminadas son el camino más rápido hacia un CAPTCHA. Las solicitudes deben llegar desde IPs residenciales, llevando la huella digital TLS y de encabezado de un navegador genuino como Chrome. Cuando una salida es marcada, rotar a una nueva generalmente elimina el bloqueo sin ningún cambio en la solicitud misma — que es exactamente cómo un recolector resiliente se recupera de una página de "tráfico inusual" en lugar de morir en ella.
3. Analizar en datos estructurados, no HTML bruto
El marcado de Google cambia constantemente, y después de num=100 el diseño es más fragmentado, no menos. Mantener tus propios selectores contra un objetivo en movimiento es un trabajo de tiempo completo. Un endpoint de SERP estructurado que devuelve JSON limpio — resultados orgánicos, anuncios, compras, paneles de conocimiento, People Also Ask, AI Overviews — aísla tu pipeline de cada cambio cosmético en el lado de Google.
El patrón en práctica
En lugar de mantener navegadores, grupos de proxies y analizadores tú mismo, entregas una consulta a un endpoint que hace los tres y devuelve resultados estructurados limpios. Con la QuantumProxies SERP API, una sola solicitud autenticada maneja la ejecución de JavaScript, la rotación residencial y el análisis por ti:
curl --location --request GET \
"https://app.quantumproxies.io/api/v1/serp/google/search?q=best+running+shoes&cc=us" \
--header "Authorization: Bearer YOUR_API_KEY"La respuesta es JSON, no HTML — resultados orgánicos con posiciones, anuncios, unidades de compras, el gráfico de conocimiento, People Also Ask y AI Overviews donde estén presentes. No hay navegador sin cabeza que cuidar, ni selector que reparar cuando Google reorganiza la página, y la paginación se maneja para que no estés reconstruyendo manualmente lo que num=100 solía darte gratis. Cuando una salida activa una página anti-bot, el servicio reintenta en una IP residencial nueva automáticamente — el mismo comportamiento de rotación para recuperarse que mantiene viva una pipeline bajo carga real.
Si prefieres ver la forma completa de solicitud y respuesta antes de escribir cualquier código, la documentación interactiva de SERP API en https://quantumproxies.io/serp-api/docs te permite ejecutar una consulta en vivo y copiar fragmentos listos para cURL, Python, JavaScript, PHP, Go y Ruby.
La conclusión
El scraping de SERP no se volvió más difícil de una manera vaga e incremental — cambió de forma dos veces en un año. JavaScript ahora es obligatorio, por lo que necesitas un cliente real. num=100 se ha ido, por lo que la cobertura profunda cuesta un orden de magnitud más en solicitudes, lo que significa que la calidad de tu capa de proxy y la inteligencia de tu lógica de escalamiento ahora importan más que el volumen bruto de solicitudes. Los equipos que aún recopilan datos limpios de SERP a escala en 2026 no son los que envían más solicitudes. Son los que envían solicitudes más inteligentes — capaces de JavaScript, con huellas digitales residenciales y estructuradas desde el primer byte.