Construí un punto de referencia de extracción de contenido web de 2,000 páginas. Esto es lo que encontré.

Tras las filtraciones de la API de Google en 2024, empecé a ver las señales de posicionamiento de otra manera. No lo de siempre, como las etiquetas de título y los backlinks, sino las señales más profundas. Cosas como contentEffort, Originality, TopicalCoherence. El tipo de señales que Google usa para determinar si una página tiene sustancia genuina o es solo ruido bien formateado.

Estaba investigando un sitio y noté algo interesante: sus páginas puntuaban bien en casi todos los ejes de calidad que se me ocurrían. Buena estructura de encabezados. Puntos de datos originales por doquier. Contenido que se construía sobre sí mismo en lugar de repetir las mismas palabras clave. Una fuerte coherencia temática en todo el sitio. No solo estaba bien escrito, sino que estaba bien estructurado a nivel de HTML.

Eso me hizo pensar. En un mundo donde los LLM pueden producir prosa competente sobre cualquier tema en segundos, ¿qué es lo que realmente diferencia a las páginas web? La capacidad de escritura se está acercando a un coste cero. El conocimiento experto se está mercantilizando. Entonces, ¿qué le queda a Google para posicionar?

Mi respuesta: no cambiará mucho fundamentalmente. Seguirán siendo los enlaces, la autoridad temática de un sitio, y después de eso — los datos originales, la experiencia personal y las señales de calidad estructural que son difíciles de falsificar a escala. Las páginas que ganarán serán las que tengan datos propios genuinos, experiencia real y estructuras de contenido que reflejen una profundidad real, y no relleno basado en plantillas.

Quería medir esto. A escala. En todo el SERP.

El Problema de la Extracción

Extraer contenido limpio de un solo sitio es fácil con la similitud de Jaccard y plantillas, pero la web es un lugar desordenado, e intentar hacerlo desde 10 sitios diferentes en la primera página de un SERP es otro tipo de problema. Y para analizar señales de calidad de contenido en miles de páginas de la competencia, primero necesitas extraer el contenido real de cada página. ¿Suena simple? Solo hay que tomar el texto del artículo, ¿verdad?

Es simple, si cada página es una entrada de blog. Trafilatura, Readability, Newspaper — todos hacen un buen trabajo en páginas de artículos estándar. Dale una entrada de WordPress o un artículo de noticias y te devolverán texto limpio, el 90%+ de las veces.

Pero la web no son solo artículos. Mezcla contenido informativo con un diseño de página de destino — una página de características de SaaS, una página de descripción de producto, un sitio de documentación — y estas herramientas empiezan a fallar. Fueron construidas para artículos, y aplican heurísticas de extracción de artículos a todo.

Necesitaba extraer contenido de:

• Páginas de producto donde la descripción vive en un blob JSON-LD, no en el DOM visible
• Páginas de servicio/landing donde el contenido está repartido en 10 elementos <section> diferentes — hero, características, testimonios, precios, FAQ
• Hilos de foros donde los mensajes de usuario SON el contenido, pero los extractores los filtran porque coinciden con patrones de texto repetitivo como class="comment"- Páginas de documentación donde necesitaba la documentación real, no la navegación de la barra lateral
• Páginas de colección/categoría donde el único texto significativo es un párrafo sobre una cuadrícula de productos

Y lo necesitaba en markdown — con encabezados, enlaces, tablas, texto en negrita conservados — porque eso es lo que analizo para las señales de SEO. Un volcado de texto plano pierde la información estructural que más importa.

Lo que Empezó como un Puerto se Convirtió en Algo Más Grande

Comenzó como un rápido puerto a Rust de Trafilatura, la excelente librería de extracción en Python de Adrien Barbaresi. Necesitaba velocidad — procesar miles de páginas a través de un pipeline de Python era un cuello de botella — y Rust cumplía con el requisito.

Pero cuando empecé a probar en diferentes tipos de páginas, me encontré con el mismo problema: la extracción única para todos no funciona en la web moderna. Una página de producto necesita un manejo diferente al de un hilo de foro. Una página de destino de SaaS necesita un manejo diferente al de la documentación de una API.

Así que añadí clasificación de tipo de página. Luego, perfiles de extracción específicos por tipo. Luego una puntuación de confianza para saber cuándo la extracción era probablemente basura y necesitaba un segundo paso. Luego un modo de salida en markdown. Luego un clasificador ML cuando las heurísticas basadas en reglas llegaron a su límite.

El resultado es rs-trafilatura — una librería de extracción de contenido web en Rust que clasifica las páginas en 7 tipos y aplica estrategias de extracción específicas por tipo. Procesa páginas en 44ms de media. Devuelve markdown con encabezados, enlaces, tablas y formato conservados.

Pero para saber si todo esto realmente funcionaba, necesitaba un benchmark. Y ahí es donde comenzó la verdadera madriguera de conejo.

Por qué los Benchmarks Existentes no Sirven

Cuando busqué un benchmark para evaluar mi extractor, encontré:

• ScrapingHub (2019): 181 páginas. Todas artículos.
• CleanEval (2007): 797 páginas. De la era pre-HTML5.
• Google-Trends (2017): 180 páginas.
• L3S-GN1 (2010): 621 artículos de noticias.

Cada benchmark era o pequeño, viejo, o solo de artículos. En artículos, todos los extractores parecen geniales — todos obtienen F1 > 0.90. Es como evaluar el rendimiento de un coche en una carretera recta y concluir que todos son igual de buenos.

La pregunta interesante no es "¿puedes extraer una entrada de blog?" — sino "¿puedes manejar el 40-50% de la web que no es una entrada de blog?".

Nadie estaba midiendo eso.

Construyendo el Benchmark

Así que construí el Benchmark de Extracción de Contenido Web (WCXB). Tomó bastante más tiempo del que esperaba.

2,008 páginas de 1,613 dominios en 7 tipos de página:

Tipo de Página	Cantidad	Lo que Prueba
Artículo	1,050	La línea base — blogs, noticias, editoriales
Servicio	224	Páginas de destino, páginas de características de SaaS, marketing
Foro	164	Hilos de discusión, preguntas y respuestas, publicaciones de comunidad
Producto	147	Descripciones de productos, especificaciones, precios
Colección	151	Páginas de categoría, cuadrículas de productos
Listado	139	Índices de contenido, catálogos de cursos
Documentación	133	Documentación de API, tutoriales, referencias técnicas

Cada página tiene una anotación de verdad fundamental completa — título, autor, fecha, contenido principal completo como texto plano, además de arrays de fragmentos "debe incluir" y "no debe incluir" que prueban los límites del contenido. El enfoque de evaluación estuvo muy influenciado por el estudio comparativo de Bevendorff et al. en SIGIR 2023 — su hallazgo de que "el rendimiento es bastante dependiente del género" fue una motivación directa para este benchmark. He intentado igualar su nivel de rigor mientras amplío el alcance a tipos de página que su conjunto de datos combinado no cubría.

El proceso de anotación fue... complejo. Borrador asistido por LLM, luego cuatro revisiones usando agentes Claude Opus para verificar y corregir problemas de calidad, seguido de mi propia revisión manual. Escaneos automáticos de calidad. Revisión adversarial donde investigaba cada archivo en el que mi extractor no coincidía con la verdad fundamental.

Dividí el conjunto de datos en un conjunto de desarrollo de 1,497 páginas y un conjunto de prueba retenido de 511 páginas con distribuciones de tipo de página igualadas. El conjunto de prueba nunca se tocó durante el desarrollo — así que cuando evalúo en él, los resultados son genuinos.

Todo se lanza bajo CC-BY-4.0: GitHub | Zenodo (DOI: 10.5281/zenodo.19316874) | HuggingFace. Y espero que mi pequeña contribución a la comunidad ayude a alguien.

Lo que Muestran los Resultados

Ejecuté 12 sistemas de extracción en WCXB — 10 basados en heurística y 2 neuronales (basados en LLM). Esta es la imagen general:

Sistema	F1	Tipo	Velocidad
rs-trafilatura	0.859	Heurístico + ML	44ms/página
MinerU-HTML (0.6B)	0.827	Neuronal (A100)	1,570ms/página
Trafilatura	0.791	Heurístico	94ms/página
dom-smoothie	0.762	Heurístico	27ms/página
ReaderLM-v2 (1.5B)	0.741	Neuronal (A100)	10,410ms/página

Pero los números generales ocultan la historia real. Esto es lo que pasa cuando lo desglosas por tipo de página:

Tipo de Página	rs-trafilatura	MinerU-HTML	Trafilatura	Readability
Artículo	0.932	0.928	0.926	0.825
Documentación	0.931	0.838	0.888	0.736
Servicio	0.843	0.824	0.763	0.604
Foro	0.792	0.794	0.585	0.466
Colección	0.713	0.506	0.553	0.445
Listado	0.704	0.710	0.589	0.496
Producto	0.670	0.619	0.567	0.407

En artículos, todos están dentro de 1-3 puntos entre sí. ¿En foros? Una diferencia de 33 puntos. ¿En colecciones? 27 puntos. ¿En productos? 26 puntos.

Esto es lo que los benchmarks solo de artículos ocultan. Pruebas en artículos de noticias, todo parece bien. Pruebas en la diversidad real de la web, y aparecen las grietas.

El Hallazgo Sorprendente sobre los LLMs

Esperaba que los extractores neuronales/basados en LLM — MinerU-HTML y ReaderLM-v2 — manejaran mejor la diversidad de tipos de página que los sistemas heurísticos. Están entrenados en datos diversos, entienden el contexto, deberían generalizar.

No lo hacen.

MinerU-HTML (un modelo de 0.6B ajustado ejecutándose en una GPU A100) obtiene 0.928 en artículos — casi igualando a los sistemas heurísticos. Pero en colecciones baja a 0.506. En productos, 0.619. En foros, 0.794.

ReaderLM-v2 (1.5 mil millones de parámetros — un modelo más grande) lo hace incluso peor: 0.417 en colecciones, 0.463 en productos. Y en listados, MinerU-HTML de hecho supera ligeramente a rs-trafilatura (0.710 vs 0.704) — es el único tipo de página donde el enfoque neuronal gana.

Estos sistemas neuronales fueron entrenados predominantemente en contenido tipo artículo. Han aprendido a extraer artículos muy bien. No han aprendido a manejar páginas de producto donde el contenido vive en JSON-LD, o páginas de servicio donde el contenido está distribuido en una docena de secciones del DOM, o foros donde los elementos class="comment" SON el contenido. Vale la pena notar que el equipo de MinerU-HTML construyó un benchmark interno más grande (WebMainBench, 7,809 páginas) pero, que yo sepa, el conjunto de datos completo no se ha publicado — solo está disponible un subconjunto de evaluación de 100 páginas. Sin acceso a la distribución de sus datos de entrenamiento, es difícil decir si este sesgo hacia artículos está incorporado en el conjunto de entrenamiento o en la arquitectura.

Un modelo más grande tampoco ayuda. ReaderLM-v2 con 1.5B obtiene puntuaciones más bajas que MinerU-HTML con 0.6B en cada tipo de página.

La lección: el enfoque de "lanzar un LLM" funciona para artículos pero no resuelve el problema de la diversidad. Para eso, necesitas extracción consciente del tipo — saber qué tipo de página estás viendo y ajustar tu estrategia en consecuencia.

Lo que Esto Significa para el Análisis SEO

Volviendo a donde empecé — analizando señales de calidad de contenido en los SERPs — este trabajo me dio tres cosas:

1. Extracción confiable en todos los tipos de página. Ahora puedo extraer contenido estructurado y limpio de páginas de producto, páginas de servicio, documentación, foros — no solo artículos. Esto importa porque los SERPs para consultas comerciales están llenos de páginas que no son artículos.

2. Salida en Markdown con la estructura conservada. Encabezados, enlaces, tablas, texto en negrita — todas las señales estructurales que importan para el análisis SEO. Puedo medir la profundidad de la jerarquía de encabezados, patrones de enlaces internos, proporciones de contenido frente a texto repetitivo, y coherencia estructural a escala.

3. Una puntuación de confianza para la calidad de la extracción. Cuando el extractor no está seguro de haber obtenido buen contenido (SPAs, diseños inusuales, mucho JavaScript), me lo dice. Puedo dirigir esas páginas a un pipeline diferente — o simplemente marcarlas para revisión manual.

Para los flujos de trabajo de análisis SEO — donde busco puntos de datos originales, investigación propia y señales de experiencia de primera mano en el contenido de la competencia — la extracción limpia es el fundamento sobre el que se construye todo lo demás. No puedes medir la originalidad del contenido si estás midiendo texto repetitivo.

Usando este pipeline, he hecho investigaciones interesantes sobre cómo las señales de calidad de contenido se correlacionan con las posiciones. Puntué 44,000 resultados de SERP en esfuerzo de contenido, originalidad y coherencia temática — esto es lo que encontré.

Trabajo en Progreso

Debo ser honesto — aunque el benchmark está terminado y publicado, rs-trafilatura aún necesita trabajo. La extracción de páginas de producto (F1 = 0.670) y páginas de colección (0.713) son áreas donde no estoy satisfecho con los resultados. El clasificador ML hace un trabajo decente con un 87% de precisión, pero los tipos de página minoritarios — listados, servicios — son donde más lucha. También está la extracción de títulos por mejorar, y el pipeline de salida en markdown necesita otra pasada en tablas y bloques de código.

Todo este proyecto ha sido un trabajo de amor. Lo que comenzó como un rápido puerto a Rust por velocidad se convirtió en meses de trabajo de anotación, experimentación con ML e infraestructura de benchmark. Pero estoy feliz de compartirlo. Si ayuda a alguien a construir un mejor extractor, o salva a un equipo de construir su propio conjunto de evaluación desde cero, entonces valió la pena el esfuerzo.

Pruébalo Tú Mismo

El benchmark es de código abierto. Si estás construyendo o evaluando herramientas de extracción de contenido:

• Sitio web del benchmark: webcontentextraction.org — tabla de posiciones, metodología, descargas
• Conjunto de datos: GitHub | HuggingFace | Zenodo
• rs-trafilatura: crates.io | PyPI — Rust o Python
• Guías de integración: rs-trafilatura + Crawl4AI | rs-trafilatura + Spider-rs | rs-trafilatura + Scrapy | rs-trafilatura + Firecrawl
• Artículo: preimpresión en arXiv (próximamente)

Si eres un SEO que trabaja con análisis de contenido a escala, o construyes pipelines RAG, o entrenas LLMs con datos web — este benchmark te mostrará dónde está fallando realmente tu pipeline de extracción.

La web no son solo artículos. Tus benchmarks de extracción tampoco deberían serlo.