El desafío
Si su equipo desarrolla rastreadores de rankings, dashboards de SEO o herramientas de inteligencia competitiva, el año 2026 rompió su 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 extraer 100 resultados en un solo request. Ahora, la misma cobertura requiere diez requests en lugar de uno.
Ese es el costo obvio. Los costos ocultos son peores.
El seguimiento de rankings solo funciona cuando se ve la SERP que vería un buscador real en el país, región y ciudad correctos. Una palabra clave que se posiciona en el puesto #4 en Londres podría estar en el #11 en Edimburgo y en el #19 en Belfast. Bloques locales de 3, carruseles de compras, cajas de noticias, paneles de conocimiento, AI Overviews. Cada función de la SERP cambia según la geografía y el dispositivo. (Scrape.do midió que el texto de AI Overview aparecía en aproximadamente el 36% de las consultas a principios de 2026). Si su scraper se enruta a través de un proxy en la ciudad equivocada, sus datos de ranking son una ficción contada con total seguridad.
Por lo tanto, un producto de SERP sólido en 2026 necesita tres cosas que funcionen en conjunto: un request que parezca un navegador real a nivel de red, un proxy que resida en la ciudad exacta que intenta monitorear y la capacidad de renderizar JavaScript cuando Google decide cargar la mitad del resultado en el lado del cliente. Si falla cualquiera de las tres, sus datos se degradarán silenciosamente.
El enfoque de FourA
El cuello de botella en el scraping de SERP a escala no es el request. Es el enrutamiento.
La mayoría de los pipelines de desarrollo propio comienzan con un pool de proxies fijo y tratan la consulta como la variable. Con la segmentación geográfica de Google, es al revés. La consulta es lo que ya tiene. El proxy es lo que debe configurar correctamente.
Hemos visto a equipos estructurar esto sobre FourA de una manera similar a esta:
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 un request debe provenir de Mánchester, Boston o São Paulo, Proxy Finder elige uno que realmente resida allí y que estuviera activo en la última verificación. La selección ocurre antes de la obtención de datos, no durante ella. Para obtener más información sobre por qué es importante esa capa de enrutamiento, consulte nuestro artículo sobre Enrutamiento inteligente de proxies.
Single se encarga de la obtención de la SERP en sí. Para resultados orgánicos estándar, el HTML sin procesar es más que suficiente. Establezca
unblocker: truey el request superará las barreras anti-bot a nivel de handshake sin necesidad de que usted sepa qué firma está verificando Google esa semana. Analizamos detalladamente lo que hace este parámetro a nivel de red en nuestra publicación sobre Web Unblocker.Browser maneja las SERP donde el contenido crítico aparece después de que se ejecuta JavaScript. AI Overviews, paquetes de compras expandidos, contenido de paneles de conocimiento, bloques locales de 3 fijos. Mismo URL, mismo objetivo, el request simplemente se ejecuta a través de una sesión de navegador completa y devuelve la página completamente renderizada. (Además de capturas de pantalla, que le salvarán el día en que un líder de SEO le pregunte por qué su dashboard indica el puesto #3 pero ellos ven el #6 en su navegador).
Una sola llamada a la API enrutada por proxy:
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"] }
}
}
}'
Eso representa tres tareas separadas de forma limpia: el trabajo de proxy con geolocalización correcta (Proxy Finder), el request en sí (Single) y el renderizado de JavaScript cuando lo necesita (Browser). Su código no tiene que cargar con la lógica de estado del proxy ni adivinar qué IP sigue activa a las 3 a. m. Eso es problema de alguien más.
Y almacene cada response indexada por (keyword, location, device, timestamp). Esa es la verdadera unidad de verdad para el seguimiento de rankings. No "nos posicionamos aquí para esta palabra clave hoy", sino "nos posicionamos aquí para esta palabra clave, desde esta ciudad, en este dispositivo, en este minuto". Sin ese nivel de atribución, los datos de dos días pueden contradecirse silenciosamente y usted no tendrá forma de saber cuál era el correcto. Los equipos de SEO que monitorean verticales protegidos ya están lidiando con esto. También hemos escrito sobre cómo la detección de bots se volvió conductual, lo que añade un cuarto eje (la continuidad de la sesión) para los sitios que analizan la secuenciación de los requests en lugar de las señales por request.
Resultados
Un rastreador de rankings que monitoreaba 5,000 palabras clave en 12 ciudades, dos veces al día, realizaba unos 120,000 requests diarios bajo el antiguo régimen de num=100. Ahora esa cifra se acerca a los 1.2 millones, por simple matemática de paginación (un escenario ilustrativo basado en referencias de la industria).
Los equipos que migraron a esta estructura de tres productos suelen reportar:
- Una reducción del 40-60% en el costo por request en comparación con la gestión de su propio pool de proxies, principalmente porque dejaron de pagar por la rotación de proxies, IPs inactivas y las horas de ingeniería necesarias para mantener la rotación.
- Una precisión de ubicación a nivel de ciudad que pasa de ~70% a más del 95%, debido a que Proxy Finder filtra por ciudad y verifica la disponibilidad en el último control antes de entregar el proxy.
- Sin rutas especiales para AI Overviews. Una palabra clave que se obtiene a través de Single puede promoverse a Browser sin necesidad de reescribir el pipeline. El contrato es idéntico: entra un URL, sale un response.
No necesita nada de esto para diez palabras clave y una laptop. Pero lo necesitará una vez que el pipeline esté monitoreando decenas de miles de palabras clave en varios países, sus clientes actualicen el dashboard a las 9 a. m. del lunes y los rankings tengan que ser reales.
Conclusión clave
La parte difícil del monitoreo de SERP dejó de ser el request hace mucho tiempo. Ha sido el enrutamiento. ¿Desde la ciudad de quién está realizando la obtención de datos? ¿Está activa esa IP? ¿Google devolvió el diseño que un buscador real en esa ubicación vería de verdad, o el diseño vacío que muestran cuando detectan un scraper?
Si usted es un equipo de SEO que ejecuta el seguimiento de rankings en un stack desarrollado por usted mismo, la pregunta para 2026 no es si debe hacer scraping a Google. Ya lo hace. La pregunta es si su infraestructura puede seguir generando rankings confiables cuando las reglas cambian sin previo aviso, y cuánto de su equipo de ingeniería está dispuesto a dedicar para mantenerla funcionando de esa manera.