¿Qué es una web reader API? Entra una URL, sale Markdown legible

¿Qué hace una web reader API, paso a paso?

Realiza cinco tareas que todo pipeline de página a texto necesita, en una sola llamada:

1. Comprobar el permiso. Un lector cuidadoso consulta el robots.txt del sitio para su propio nombre y para todos los robots antes de obtener nada.
2. Obtener la página. Descarga el HTML, sigue las redirecciones y se detiene al alcanzar un timeout.
3. Renderizar cuando haga falta. Si el HTML es un cascarón vacío rellenado por JavaScript, carga la página en un navegador headless y lee el resultado.
4. Extraer el contenido principal. Un paso al estilo readability localiza el artículo o el cuerpo de la documentación y descarta el mobiliario de la página que lo rodea.
5. Convertir y describir. Escribe el contenido como Markdown y añade metadatos: título, autor, fecha de publicación, idioma y recuento de palabras.

Quien llama recibe un objeto JSON con el Markdown dentro. Un modelo puede leerlo de una vez, o un pipeline puede dividirlo en fragmentos para un almacén vectorial.

¿Por qué necesitan los modelos Markdown en lugar de HTML?

Porque la mayor parte de una página HTML no es contenido. Los menús, las etiquetas script, el código de seguimiento y el marcado de maquetación usan tokens que un modelo debe leer y que tú debes pagar. Markdown conserva las partes que aportan significado: encabezados, listas, tablas, enlaces y énfasis.

Cloudflare puso un ejemplo concreto cuando lanzó su función "Markdown for Agents" el 12 de febrero de 2026: una página pasó de 16.180 tokens como HTML a 3.150 tokens como Markdown, alrededor de un 80 % menos. Los resultados varían según la página, pero la dirección es la misma en la mayoría de las páginas de artículos y documentación.

¿En qué se diferencia una web reader API de una API de scraping?

Una API de scraping devuelve lo que envió el servidor; un lector devuelve lo que leería una persona. Las API de scraping están hechas para obtener páginas a escala, a menudo para extraer campos concretos como precios o nombres de productos, y normalmente devuelven HTML en bruto o JSON estructurado que tú defines.

Una web reader es más acotada y más opinionada. Decide cuál es el contenido principal, elimina el resto y escribe texto limpio. Es la herramienta adecuada cuando el siguiente consumidor es un modelo de lenguaje, un índice de búsqueda o una persona que lee un resumen. Es la herramienta equivocada cuando necesitas cada campo de una cuadrícula de productos; para eso quieres el HTML completo o una extracción basada en un esquema.

¿En qué se diferencia de una API de búsqueda?

Una API de búsqueda responde "¿qué páginas hablan de esto?"; un lector responde "¿qué dice esta página?". La búsqueda devuelve una lista de URLs con títulos y fragmentos para una consulta. Un lector toma una de esas URLs y devuelve su texto completo.

Los agentes suelen encadenar las dos: buscar para encontrar páginas candidatas y luego leer las tres o cuatro mejores para responder con citas. Mantener los pasos separados te permite elegir cuántas páginas leer, lo que ahorra tokens y créditos.

¿Puedo usar herramientas de código abierto en lugar de una API?

Sí, y muchos equipos empiezan así. Readability de Mozilla extrae el contenido principal de una página en un contexto de navegador; Trafilatura hace la extracción en Python; MarkItDown de Microsoft convierte documentos, incluidos PDF, a Markdown; Crawl4AI combina el rastreo (crawl) y la salida en Markdown.

La librería es la parte fácil. Ejecutarla en producción implica alojar navegadores headless para páginas con JavaScript, comprobar robots.txt, gestionar timeouts, redirecciones y conjuntos de caracteres, convertir PDF y mantenerlo todo parcheado. Una API merece la pena cuando prefieres pagar por página en lugar de operar esa maquinaria; una librería merece la pena cuando los volúmenes son estables y tienes tiempo para operarla.

¿Cómo cobran las web reader API?

En 2026 son habituales tres modelos de facturación. Los planes basados en créditos cobran un número fijo de créditos por página: la página de precios de Firecrawl, consultada el 22 de octubre de 2026, cuenta 1 crédito por página rastreada y 4 créditos extra por página para su formato JSON. La facturación basada en tokens cobra por el texto devuelto: Jina Reader factura así desde el 6 de mayo de 2025 y da 10 millones de tokens gratis a cada clave nueva. Los planes mensuales reinician sus créditos en cada ciclo, mientras que los packs de prepago los conservan.

WebReaderAPI usa créditos de prepago que no caducan: 1 crédito = 1 página leída sin navegador; 2 créditos cuando la página necesita un navegador para renderizar JavaScript. Una solicitud que falla, o que el robots.txt de un sitio rechaza, no se cobra. 10.000 páginas cuestan 3,75 US$ y la tarifa baja a 0,07 US$/1K páginas en 5.000.000 de páginas, a fecha de octubre de 2026.

¿Qué debería comprobar antes de elegir una web reader API?

Pruébala con veinte URLs tuyas y fíjate en seis cosas:

• Calidad de la extracción. ¿El Markdown conserva el artículo y descarta el resto, incluidas tablas y bloques de código?
• JavaScript. ¿Las páginas construidas en el navegador vuelven con texto, y cuánto cuesta el renderizado?
• PDF. ¿Se admiten, y cómo se cuentan las páginas?
• Decisiones de los propietarios del sitio. ¿El servicio respeta robots.txt y las preferencias de IA declaradas, y lo indica en su documentación?
• Fallos. ¿Se cobran las páginas fallidas y rechazadas?
• Control del presupuesto. ¿Puedes limitar la longitud de cada página, y caducan los créditos?

Nuestra comparación de precios de web reader API pone a los principales proveedores uno al lado del otro con fechas.