SerpApi añade salida en Markdown y recorta un 74% los tokens de una búsqueda
La misma consulta que en JSON consumía 24.723 tokens baja a 6.435 al pedir la respuesta en Markdown, y a 1.298 con un filtro de campos. Las cifras son del proveedor.
SerpApi, el servicio que extrae resultados de buscadores y los devuelve en JSON, ha añadido una salida en Markdown pensada para agentes de IA. La compañía mide un recorte notable: una búsqueda de "coffee" que en JSON ocupaba 24.723 tokens pasa a 6.435 al pedir la misma respuesta en Markdown, un 74% menos. Si además se restringe el conjunto de campos, la cifra baja hasta 1.298 tokens.
Conviene tener claro de dónde salen los números: son del propio proveedor, no de un tercero que haya replicado la prueba ni de un benchmark independiente.
Qué se cae por el camino
El formato conserva el contenido informativo y elimina o reformatea aquello que infla el recuento sin aportar nada al razonamiento del modelo. Fuera quedan los enlaces de seguimiento interno, del estilo serpapi_link o serpapi_amazon_link, que existen para encadenar consultas dentro del propio sistema; los iconos y miniaturas, útiles para pintar una interfaz pero no para que un LLM entienda el resultado; y los metadatos anidados, con objetos de paginación, arrays por resultado y campos repetidos entre secciones.
También desaparece la separación entre título y enlace, que en JSON son claves distintas acompañadas de displayed_link y snippet. Markdown lo funde en una sola línea con el enlace nativo, y el conjunto se aplana en tablas, frontmatter YAML y enlaces en línea.
Cómo se activa
Hay tres vías para pedirlo: añadir output=md a la llamada que ya haces, usar el endpoint /search.md en lugar de /search, o enviar la cabecera Accept: text/markdown. Según la documentación del formato Markdown, está disponible en las más de 100 APIs del servicio sin coste adicional, y devuelve frontmatter YAML, tablas y enlaces nativos. Para apretar más, json_restrictor (o --fields en la CLI) permite elegir claves concretas en el servidor y recortar el payload antes de que cruce la red.
Markdown no sirve para todo. Está pensado para que lo lea un modelo, no para código que espera tipos exactos. Si tu pipeline consume precios como enteros, coordenadas, valoraciones como float o arrays estructurados para procesarlos después, JSON sigue siendo la opción. El ejemplo que pone la casa: un resultado de Naver Shopping en JSON expone price, old_price y coupon_price como enteros y rating como float, además de los campos reviews y stores. Para un motor de precios eso es justo lo que quieres; para un agente que solo resume los productos más destacados, esas claves sobran. Los datos de origen y los créditos consumidos son los mismos, solo cambia la forma.
El consejo práctico es medir en lugar de fiarse del porcentaje: coge una consulta que ya ejecutes, pídesela en Markdown, cuenta tokens y vuelve a contar con json_restrictor. El ahorro real depende de tu flujo y de qué campos usas de verdad. Todo el material del que sale esto es documentación comercial del proveedor y no hay una demostración pública sobre pipelines ajenos.
