Serper.dev: una fuente de datos de Google para automatizar análisis SEO

Cuando un proyecto SEO necesita consultar cientos o miles de búsquedas, abrir Google manualmente deja de ser una opción. Serper.dev ofrece una API que devuelve resultados de Google en JSON y permite controlar país, idioma, ubicación, número de resultados y paginación. La propuesta es sencilla: enviar una consulta y recibir una fotografía estructurada de la SERP en aproximadamente uno o dos segundos.

No es una base de datos de palabras clave ni sustituye a Google Search Console. Es una fuente de observación de resultados públicos: sirve para saber qué aparece, en qué posición, con qué tipo de resultado y con qué cambios a lo largo del tiempo.

Qué es Serper.dev

Serper.dev es un proveedor de API para resultados de Google. En la portada presenta endpoints separados para:

• Search: resultados orgánicos, anuncios, snippets, preguntas relacionadas, búsquedas relacionadas y, cuando aparece, knowledge graph.
• Images, videos y news: resultados visuales, vídeos y noticias con sus títulos, enlaces, fuentes y fechas disponibles.
• Maps y places: negocios y lugares con datos locales, coordenadas o identificadores de lugar según la consulta.
• Shopping: productos, precios, tiendas y enlaces de compra.
• Scholar y patents: publicaciones académicas y patentes.
• Autocomplete: sugerencias que ayudan a descubrir cómo formula la gente una búsqueda.

La respuesta no tiene un esquema idéntico para todas las consultas. Google activa módulos distintos según la intención, por lo que el sistema debe tratar como opcionales campos como knowledgeGraph, peopleAlsoAsk, localPack o shopping.

Qué datos se pueden sacar

En una consulta web típica interesa guardar, como mínimo:

query | gl | hl | location | captured_at | position | title | link | snippet

También conviene conservar el JSON completo y extraer, cuando existan:

• posición y tipo de resultado (orgánico, anuncio, vídeo, noticia, local, featured snippet);
• título, URL, dominio visible y snippet;
• sitelinks y breadcrumbs;
• preguntas de “People Also Ask” y búsquedas relacionadas;
• datos del knowledge graph;
• searchParameters, página solicitada y cualquier token de paginación;
• tiempo de respuesta, código HTTP y coste en créditos de la petición.

Con Images, News, Maps, Places, Shopping, Scholar y Patents el modelo es el mismo: guardar la consulta, el contexto geográfico/lingüístico, la fecha y el resultado bruto antes de crear tablas derivadas. Esa copia permite reprocesar el histórico si cambia nuestro modelo de análisis.

Una llamada mínima

La API utiliza una clave en la cabecera X-API-KEY y recibe un cuerpo JSON. Este ejemplo consulta resultados en España y en español:

curl https://google.serper.dev/search \
  -H 'X-API-KEY: TU_CLAVE' \
  -H 'Content-Type: application/json' \
  -d '{
    "q": "mejor CRM para pequeñas empresas",
    "gl": "es",
    "hl": "es",
    "num": 10,
    "page": 1
  }'

gl fija el país, hl el idioma, num el número de resultados y page la página. Para análisis local se puede añadir una ubicación más concreta según el endpoint. Es importante registrar esos parámetros: una misma keyword con otro país, idioma o ciudad no representa la misma SERP.

Qué montaría para SEO

1. Rank tracker reproducible

Una tabla de keywords, mercados y dispositivos puede alimentar una captura diaria o semanal. El pipeline normal sería:

1. leer las keywords activas;
2. consultar Serper con gl, hl, location, num y page definidos;
3. identificar el dominio propio y los competidores;
4. guardar posición, URL, tipo de SERP y JSON original;
5. comparar contra la captura anterior.

El resultado no debe llamarse “posición absoluta en Google”. Es la posición observada bajo unos parámetros concretos y en un momento concreto. La personalización, la ubicación y la volatilidad de la SERP pueden cambiar el resultado.

2. Monitor de competidores

Para cada consulta se puede construir un conjunto de dominios visibles en el top 10 o top 100. Después podemos calcular frecuencia de aparición, páginas que compiten para varias keywords, cambios de URL y nuevos entrantes. Esto ayuda a descubrir competidores reales en buscador, no solo los que aparecen en un listado comercial.

3. Minería de intención y features

La presencia de preguntas, vídeos, noticias, mapas, shopping o un featured snippet es una señal de intención. Un clasificador sencillo puede etiquetar cada keyword como informacional, transaccional, local o navegacional y recomendar el formato de contenido adecuado.

4. Descubrimiento de long tail

Autocomplete, People Also Ask y related searches son buenas semillas para ampliar un mapa de contenidos. Las sugerencias se deben tratar como ideas de consulta, no como volumen de búsquedas. Para priorizarlas habría que cruzarlas con Search Console, Google Ads Keyword Planner u otra fuente de demanda.

5. SEO local

Maps y Places permiten observar negocios, categorías, reseñas visibles, dirección, teléfono, rating y señales de presencia local cuando la respuesta las incluye. Un dashboard puede detectar cambios en el local pack, fichas que aparecen para una categoría y huecos geográficos. No conviene confundir estos datos con una auditoría completa de Google Business Profile.

6. News, Shopping y contenido vertical

Una tienda puede seguir precios, marcas y competidores en Shopping; un medio puede vigilar qué fuentes entran en News; un equipo de contenidos puede descubrir qué vídeos dominan una consulta. Estos módulos son especialmente útiles si el proyecto no compite solo en resultados orgánicos azules.

Arquitectura de datos que usaría

Separaría la captura de la interpretación. Una tabla de hechos podría ser:

serp_capture
  id, query, gl, hl, location, page, captured_at,
  endpoint, http_status, response_ms, credits_used, raw_json

serp_result
  capture_id, result_type, position, title, url, domain,
  snippet, date, place_id, price, rating

raw_json es deliberado: los módulos de Google aparecen y desaparecen, y una tabla rígida se rompería con facilidad. Un job posterior normaliza solo los campos que el dashboard necesita. Para evitar costes y falsos cambios, usaría una huella del JSON, deduplicación por consulta/contexto/fecha y reintentos con backoff ante errores 429 o 5xx.

Coste y límites: lo que vigilaría

Serper anuncia un modelo prepago sin suscripción mensual. En la página consultada, el paquete Starter es de 50.000 créditos por 50 dólares, Standard de 500.000 por 375 dólares, Scale de 2,5 millones por 1.250 dólares y Ultimate de 12,5 millones por 3.750 dólares; los créditos tienen una validez anunciada de seis meses y las cifras no incluyen impuestos. También ofrece 2.500 consultas de prueba sin tarjeta para empezar.

La cuota por segundo depende del paquete: la portada indica 50, 100, 200 y 300 consultas por segundo, respectivamente. Los créditos se descuentan cuando se recibe una respuesta correcta. Antes de presupuestar un rank tracker hay que multiplicar keywords × mercados × dispositivos × páginas × frecuencia y añadir margen para reintentos.

La propia página indica que la mayoría de respuestas llegan en 1–2 segundos, aunque algunas pueden tardar más. Eso hace viable un workflow en lote, pero no justifica lanzar miles de peticiones sin control de concurrencia.

Integrarlo en n8n

Un workflow sencillo tendría un Schedule Trigger, un nodo que lee keywords desde Airtable/CSV/PostgreSQL, un HTTP Request a https://google.serper.dev/search, un nodo Code para extraer dominios y features, y finalmente una escritura en la base de datos. Añadiría una rama de error para registrar el cuerpo de respuesta, reintentar de forma limitada y avisar cuando el saldo o el rate limit sea insuficiente.

Para un MVP del proyecto DataPortfolio probaría con 50 keywords, España, español, una consulta semanal y top 10. Mediría cobertura, cambios de intención y coste real antes de ampliar frecuencia o mercados.

Límites y uso responsable

Serper entrega resultados de Google, no una licencia para republicar contenido ajeno. Guardaría solo los datos necesarios, respetaría las condiciones del proveedor y evitaría presentar snippets, reseñas o precios como información permanente. Los resultados pueden cambiar por hora, ubicación, idioma, personalización, pruebas de Google y disponibilidad de cada módulo.

Tampoco usaría Serper como única fuente para decisiones críticas. Para rendimiento propio, Search Console y analítica first-party son más apropiadas; para volumen y dificultad de keywords hacen falta fuentes especializadas. Serper encaja como capa de observación SERP y como automatizador de consultas a escala.

Conclusión

Serper.dev es interesante cuando el dato que necesitamos es qué muestra Google ahora y queremos obtenerlo de forma programática. Sus endpoints permiten construir rank tracking, inteligencia competitiva, mapas de intención, monitorización local y proyectos verticales de noticias, vídeo o shopping con una arquitectura relativamente ligera.

La recomendación es empezar pequeño: definir exactamente el contexto de cada consulta, conservar el JSON original, normalizar después y validar el coste con una muestra. Con ese modelo, Serper puede convertirse en una pieza útil de un stack SEO sin confundirse con Search Console, una herramienta de keyword research o una base de datos histórica de posiciones.

Enlaces: Serper.dev · Playground · Google Search API