Monitoreo de SERP a escala después de num=100

El desafío

Si tu equipo desarrolla rastreadores de posiciones, paneles de SEO o herramientas de inteligencia competitiva, 2026 arruinó tu economía unitaria. Google retiró silenciosamente el parámetro de URL num=100 en Google Search este año, el truco que todo scraper de SERP utilizaba para obtener 100 resultados en una sola request. Ahora la misma cobertura requiere diez requests en lugar de una.

Ese es el costo evidente. Los costos ocultos son peores.

El seguimiento de posiciones solo funciona cuando ves la SERP que vería un usuario real en el país, la región y la ciudad correctos. Una palabra clave que está en la posición #4 en Londres puede estar en la #11 en Edimburgo y en la #19 en Belfast. Paquetes locales de 3 resultados, carruseles de compras, cajas de noticias, paneles de conocimiento, AI Overviews. Cada elemento de la SERP cambia según la geografía y el dispositivo. (Scrape.do calculó que el texto de AI Overview apareció en aproximadamente el 36% de las consultas a principios de 2026). Si tu scraper se enruta a través de un proxy en la ciudad equivocada, tus datos de ranking son una ficción contada con seguridad.

Por lo tanto, un producto de SERP defendible en 2026 necesita tres elementos coordinados: una request que parezca un navegador real a nivel de red, un proxy ubicado en la ciudad exacta que intentas monitorear y la capacidad de renderizar JavaScript cuando Google decide cargar la mitad del resultado del lado del cliente. Si falta cualquiera de los tres, tus datos se degradan en silencio.

El enfoque de FourA

El cuello de botella al scrapear SERPs a escala no es la request. Es el enrutamiento.

La mayoría de los pipelines internos comienzan con un pool fijo de proxies y tratan la consulta como la variable. Con la segmentación geográfica de Google, ocurre lo contrario. La consulta es lo que tienes. El proxy es lo que debes resolver bien.

Hemos visto a varios equipos estructurar esto sobre FourA de la siguiente manera:

Proxy Finder mantiene un pool activo de proxies validados mediante pruebas de disponibilidad recientes y etiquetados con país, región, ciudad y ASN. Cuando una request necesita provenir de Mánchester, Boston o São Paulo, Proxy Finder selecciona un proxy ubicado físicamente allí y activo en la última comprobación. La selección ocurre antes de la descarga, no durante el proceso. Para saber más sobre por qué importa esta capa de enrutamiento, consulta nuestro artículo sobre Smart Proxy Routing.
Single gestiona la obtención de la SERP. Para resultados orgánicos estándar, el HTML sin procesar es suficiente. Configura unblocker: true y la request incluirá una firma de navegador actualizada sin que tengas que averiguar qué firma está validando Google esa semana. Detallamos lo que hace este flag a nivel de red en nuestra publicación sobre Web Unblocker.
Browser procesa las SERPs donde el contenido crítico aparece tras ejecutar JavaScript. AI Overviews, paquetes de compras expandidos, contenido de paneles de conocimiento o bloques locales fijos de 3 resultados. La misma URL, el mismo objetivo: la request simplemente se ejecuta en una sesión de navegador completa y devuelve la página renderizada en su totalidad. (Además de capturas de pantalla, que te salvan el día cuando un líder de SEO pregunta por qué tu panel indica #3 pero él ve #6 en su navegador).

Una sola llamada contra la API con enrutamiento de proxies:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

Son tres responsabilidades separadas con claridad: trabajo de proxy con geolocalización correcta (Proxy Finder), la request en sí misma (Single) y renderizado de JavaScript cuando lo necesitas (Browser). Tu código no carga con la lógica de salud del proxy ni adivina qué IP sigue viva a las 3:00. Ese es problema de alguien más.

Y almacena cada response indexada por (keyword, location, device, timestamp). Esa es la verdadera unidad de certeza para el rank tracking. No "clasificamos aquí para esta keyword hoy", sino "clasificamos aquí para esta keyword, desde esta ciudad, en este dispositivo, en este minuto exacto". Sin ese nivel de atribución, los datos de dos días pueden contradecirse silenciosamente y no tendrás forma de saber cuál era el correcto. Los equipos de SEO que monitorean verticales protegidos ya se enfrentan a esto. También hemos escrito sobre cómo la detección de bots se volvió conductual, lo que añade un cuarto eje (continuidad de sesión) para los sitios que analizan la secuencia de requests en lugar de señales por request.

Resultados

Un rank tracker que monitorea 5.000 keywords en 12 ciudades, dos veces al día, requería unas 120.000 requests diarias bajo el antiguo esquema de num=100. Ahora ronda los 1,2 millones, por simple cálculo de paginación (escenario ilustrativo basado en benchmarks de la industria).

Los equipos que migraron este flujo a un stack de tres productos suelen reportar:

40-60% de reducción en el costo por request frente a gestionar su propio pool de proxies, principalmente porque dejaron de pagar por la rotación forzada de proxies, IPs caídas y las horas de ingeniería dedicadas a mantener la rotación.
La precisión de ubicación a nivel de ciudad pasa de ~70% a más del 95%, ya que Proxy Finder filtra por ciudad y verifica el estado activo en la última comprobación antes de entregar el proxy.
Sin rutas especiales para AI Overviews. Una keyword que se obtiene mediante Single puede promoverse a Browser sin reescribir el pipeline. El contrato es idéntico: ingresa la URL, sale la response.

No necesitas nada de esto para diez keywords y una laptop. Pero lo necesitas en cuanto el pipeline monitorea decenas de miles de keywords en múltiples países, tus clientes actualizan el dashboard a las 9:00 del lunes y los rankings deben ser reales.

Conclusión clave

La parte difícil del monitoreo de SERP dejó de ser la request hace mucho tiempo. Se convirtió en el enrutamiento. ¿Desde la ciudad de quién estás haciendo el fetch? ¿Sigue viva esa IP? ¿Google devolvió el layout que vería un usuario real en esa ubicación, o la versión vacía que entregan cuando detectan un scraper?

Si eres un equipo de SEO que ejecuta rank tracking en un stack de desarrollo propio, la pregunta para 2026 no es si debes scrapear Google. Ya lo haces. La pregunta es si tu infraestructura puede seguir generando rankings confiables cuando las reglas cambian sin previo aviso, y cuánto tiempo de tu equipo de ingeniería estás dispuesto a invertir para mantenerla funcionando así.