Durante veinte años, extraer datos de páginas web significaba escribir selectores: encontrar el elemento, capturar el texto, corregirlo cuando el sitio cambia. Los grandes modelos de lenguaje ofrecen un trato distinto. Le das al modelo la página, describes los campos que quieres y obtienes datos estructurados de vuelta, sin selectores que escribir y ninguno que se rompa con un rediseño.
El trato es real, pero tiene un precio, una velocidad y un modo de fallo, y los tres merecen medirse antes de reconstruir un pipeline en torno a él. Así que los medimos. Este artículo presenta una prueba pequeña y honesta sobre páginas reales, lo que revelaron los fallos, lo que cuesta a escala y dónde encaja un modelo en un pipeline de extracción.
Conclusiones clave
- En 18 artículos de noticias reales, un modelo grande de Claude extrajo todos los titulares con exactitud, 17 de 18 fechas y 14 de 18 listas de autores, comparado con los datos estructurados propios de cada página.
- La mayoría de los “fallos” no fueron errores del modelo. En cada página donde los autores no coincidían, los datos estructurados contenían un marcador de posición genérico; en dos de ellas el modelo informó la firma que la página visible realmente mostraba.
- El modelo no inventó nada: todos los titulares y autores que devolvió aparecen en el texto de la página. Aun así cometió un error real, al nombrar a un fotógrafo como autor.
- Costó unos 1,9 céntimos por página al precio de lista y tardó una mediana de 2,4 segundos. Analizar datos estructurados cuesta casi nada y tarda milisegundos.
- Usa modelos donde los selectores son costosos de mantener, como muchas plantillas de sitio diferentes o campos sin fuente estructurada, y valida todo lo que devuelven.
Qué probamos
| Parámetro | Valor |
|---|---|
| Páginas | 18 artículos reales de las portadas de sección de un gran editor de noticias, recopilados el 28 de septiembre de 2026 |
| Entrada del modelo | El texto visible de la página, incluyendo navegación y otros elementos de la página, con un promedio de unos 8.700 caracteres |
| Campos | Titular, fecha de publicación tal como se muestra en la página y nombres de autores |
| Modelo | Claude Opus 5, con esfuerzo bajo, con un esquema JSON que restringe la salida |
| Clave de respuestas | Los propios datos estructurados JSON-LD de la misma página |
| Puntuación | El titular y la fecha deben coincidir exactamente; las listas de autores deben coincidir como conjuntos |
La clave de respuestas es deliberadamente el tipo de datos tratado en deja de analizar HTML: los datos estructurados que los editores incrustan para los motores de búsqueda. Normalmente son correctos. Como resultó, no siempre.
Resultados
| Medida | Resultado |
|---|---|
| Titular correcto | 18 de 18 |
| Fecha correcta | 17 de 18 |
| Autores correctos | 14 de 18 |
| Valores extraídos encontrados en el texto de la página | 18 de 18 titulares, 18 de 18 listas de autores |
| Tokens por página | unos 3.380 de entrada, 66 de salida |
| Latencia | mediana 2,4 s, rango 1,8 a 10,6 s |
| Coste de la ejecución | 0,33 $ al precio de lista, unos 1,9 céntimos por página |
Los fallos fueron la parte interesante
Las cifras de titulares subestiman al modelo y sobreestiman la clave de respuestas. Analizando cada discrepancia:
- Una columna de opinión. Los datos estructurados indicaban como autor un marcador de posición genérico de personal. La firma visible nombraba al columnista real. El modelo devolvió al columnista.
- Una noticia de agencia. Los datos estructurados volvían a dar el marcador de posición genérico; la firma visible decía “Staff and agencies”. El modelo devolvió lo que mostraba la página.
- Una página de suscripción a un boletín que se había colado en el conjunto. No mostraba ni autor ni fecha. Los datos estructurados aportaban de todos modos un autor genérico y una fecha; el modelo dejó ambos campos vacíos en lugar de inventarlos.
- Un reportaje fotográfico. Los datos estructurados daban el mismo marcador de posición genérico. La página atribuía las fotografías a un fotógrafo con nombre propio, y el modelo devolvió al fotógrafo como autor. Ese sí es un error genuino.
Así que, de las cuatro páginas con discrepancia, dos reflejaban que la clave de respuestas era menos precisa que la página visible, una fue el modelo negándose correctamente a adivinar, y una fue un error real. Eso cambia la pregunta que merece la pena hacerse. Los datos estructurados son una opción por defecto sólida, pero no son la verdad absoluta, y un modelo que lee la página visible puede detectar dónde se equivocan, igual que puede a veces malinterpretar lo que ve.
Lo que cuesta a escala
La prueba costó 0,33 $ por 18 páginas al precio de lista de Claude Opus 5 de 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida. Eso son unos 1,9 céntimos por página, lo que equivale aproximadamente a 18.600 $ por millón de páginas. La Batch API de Anthropic reduce a la mitad esos precios por token para trabajos que puedan esperar. Los modelos más pequeños son más baratos por token todavía, Claude Haiku 4.5 figura a 1 $ y 5 $, pero no los probamos aquí, y su precisión en tus páginas es algo que hay que medir, no dar por supuesto.
La latencia también importa. Una mediana de 2,4 segundos por página, con algunos valores atípicos ocasionales, resulta adecuada para monitorización y enriquecimiento, y una restricción real para el rastreo de gran volumen. Analizar JSON-LD o ejecutar selectores tarda milisegundos y no cuesta prácticamente nada más allá de la solicitud. Esos costes de extracción se suman a los costes de recopilación, por lo que el coste por registro limpio debería incluir ambos.
Cuándo usar cada opción
| Situación | Mejor enfoque |
|---|---|
| La página publica los campos en JSON-LD o JSON incrustado | Analizar los datos estructurados |
| Alto volumen de una o pocas plantillas de sitio | Selectores o datos estructurados, con validación |
| Muchos sitios distintos, cada uno con su propia plantilla | Un modelo, validado, posiblemente generando selectores que luego reutilizas |
| Campos que solo existen en prosa, como condiciones, elegibilidad o especificaciones | Un modelo |
| Los datos estructurados fallan la validación en una página | Un modelo como respaldo |
| Bajo volumen, alto valor, cambios frecuentes de diseño | Un modelo |
Los pipelines más sólidos combinan ambos. Analiza primero los datos estructurados, recurre a un modelo cuando falte un campo requerido o falle la validación, y registra qué método produjo cada registro, el mismo patrón de cadena de respaldo descrito para los datos estructurados. Cuando una sola plantilla de sitio cubre miles de páginas, también puede compensar hacer que un modelo proponga selectores una vez y ejecutar esos selectores de forma barata en cada página, con el modelo en espera para cuando se rompan.
Usar un modelo de forma segura
Cuatro prácticas convierten la extracción con modelos de impresionante en fiable.
Restringe la salida. Un esquema JSON hace que el modelo devuelva los campos y tipos que pediste; aun así comprueba el motivo de parada, ya que una respuesta rechazada o truncada no tiene nada que analizar. Indica al modelo que deje un campo vacío cuando la página no lo muestre; en nuestra prueba hizo exactamente eso.
Comprueba la fundamentación. Toda cadena extraída que debería aparecer en la página, como un nombre, un titular o el título de un producto, debería encontrarse en el texto de la página. Es una comprobación barata que detecta valores inventados. No detectará un nombre real atribuido al campo equivocado, como muestra el caso del fotógrafo, así que es un filtro, no una prueba.
Muestrea para revisión humana. Puntúa una pequeña muestra aleatoria cada semana frente a la lectura que hace una persona de la página, y haz seguimiento de la precisión por campo y por sitio a lo largo del tiempo.
Trata el texto de la página como entrada no fiable. Una página está escrita por otra persona. Usa los modelos sobre contenido web solo para extracción, nunca dejes que el contenido de la página desencadene acciones, y mantén las instrucciones del modelo separadas del contenido de la página.
Esta es la llamada de extracción que usamos, seguida de la comprobación de fundamentación:
import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();
const SCHEMA = {
type: "object",
properties: {
headline: { type: "string" },
date_published: { type: "string", description: "YYYY-MM-DD, as shown on the page" },
authors: { type: "array", items: { type: "string" } },
},
required: ["headline", "date_published", "authors"],
additionalProperties: false,
};
export async function extractArticle(pageText) {
const response = await client.beta.messages.create({
model: "claude-opus-5",
max_tokens: 2000,
betas: ["server-side-fallback-2026-07-01"],
fallbacks: "default",
output_config: { effort: "low", format: { type: "json_schema", schema: SCHEMA } },
messages: [{
role: "user",
content:
"Below is the visible text of a news article web page, including navigation and other page furniture. " +
"Extract the article's headline exactly as written, its publication date as shown on the page (YYYY-MM-DD), " +
"and the author names. Leave a field empty if the page does not show it.\n\n<page>\n" + pageText + "\n</page>",
}],
});
if (response.stop_reason === "refusal") return null;
const text = response.content.filter((b) => b.type === "text").map((b) => b.text).join("");
return { record: JSON.parse(text), usage: response.usage };
}
// Grounding check: every extracted string must actually appear in the page text.
export function grounded(record, pageText) {
const norm = (s) => s.replace(/[‘’]/g, "'").replace(/[“”]/g, '"').replace(/\s+/g, " ").toLowerCase();
const page = norm(pageText);
return {
headline: page.includes(norm(record.headline)),
authors: record.authors.every((a) => page.includes(norm(a))),
};
}La entrada importa tanto como el modelo. Un modelo solo puede extraer lo que la página realmente contiene, así que una página de bloqueo, un muro de consentimiento o una estructura vacía produce una extracción confiada del contenido equivocado. Valida lo que obtuviste antes de extraer de ello, tal como se explica en la tasa de fallo silencioso, y obtén datos del mercado cuya versión de la página necesites.
Los límites de esta prueba
Dieciocho páginas de un solo editor son una muestra pequeña, elegida para ser honesta más que definitiva. Los artículos de noticias también son un caso fácil: titulares claros, firmas visibles, fechas bien etiquetadas. Las páginas de productos con variantes, precios y disponibilidad, o las páginas en otros idiomas, se comportarán de manera distinta. Probamos un modelo con un nivel de esfuerzo. El método es sencillo de repetir en tus propias páginas, y tus propias páginas son el único punto de referencia que importa.
La conclusión
Un modelo que leyó la página acertó todos los titulares, no inventó nada, y en varios casos informó de la página con más fidelidad que los propios datos estructurados de la página. También atribuyó mal a un autor una vez, costó céntimos en lugar de fracciones de céntimo, y tardó segundos en lugar de milisegundos.
Eso lo convierte en una herramienta sólida para las partes de la extracción que los selectores manejan mal: muchas plantillas, campos solo en prosa y respaldos cuando fallan los datos estructurados. No es un sustituto de los datos estructurados donde estos existen. Analiza lo que publica la página, recurre a un modelo donde no lo haga, valida ambos, y registra cuál usaste.
Fuentes y referencias
- Anthropic, Precios. Precios del modelo y de la Batch API en el momento de la prueba.
- Schema.org, NewsArticle.
- Prueba realizada por Shifter el 28 de septiembre de 2026 sobre 18 artículos de noticias de acceso público, usando el código anterior.