Extracción de datos de sitios web: un flujo de trabajo práctico con el DOM

Empieza por un único campo obligatorio, como el precio de venta actual. Analiza dónde se encuentra antes de elegir una herramienta. Puede estar presente en el código HTML inicial, insertado en el DOM tras la ejecución de JavaScript, dibujado en un lienzo o incluido en una exportación autorizada. Cada posibilidad cambia el método de recopilación más sencillo y fiable.

El «screen scraping» de sitios web no requiere una captura de pantalla. Si un precio es un nodo de texto dentro de la ficha de un producto, al extraer ese nodo se mantiene su relación con la ficha. Recortar ese mismo precio en una imagen supone un trabajo adicional: elegir el recorte, reconocer los caracteres, asociar el resultado con el producto correcto y detectar resultados dudosos.

Un analizador HTTP sigue siendo un buen punto de partida cuando el documento inicial contiene los campos necesarios. Nuestra guía sobre clientes HTTP en Python explica la capa de solicitud que precede al análisis. Un navegador resulta útil cuando la tarea de recopilación depende de la ejecución de la página o de interacciones permitidas, como seleccionar una pestaña.

Considera esta elección como un experimento. Recupera un ejemplo autorizado mediante el método más sencillo, compara sus campos con la página visible y documenta la diferencia. No recurras a la automatización del navegador simplemente porque un sitio utilice JavaScript en alguna parte. Por el contrario, una respuesta HTTP satisfactoria no garantiza que la respuesta incluya los datos deseados.

Conserva la representación de origen en los metadatos de salida. Un registro obtenido a partir de texto renderizado y otro inferido a partir de una imagen pueden tener requisitos de revisión diferentes, incluso cuando sus valores finales parezcan idénticos.

Anota qué significa cada fila. Para una observación de catálogo, un registro útil podría contener un identificador de producto de origen, el nombre que se muestra, el texto del precio sin procesar, la moneda, la URL de la página, la hora de la observación y la versión de extracción. Decide qué campos son obligatorios y cuáles pueden faltar legítimamente antes de ejecutar el navegador.

El «screen scraping» de sitios web se vuelve frágil cuando los selectores deciden el esquema de forma silenciosa. Un nodo de precio que falte no debería convertirse automáticamente en cero. Un precio etiquetado como «desde» no debería convertirse en un precio exacto sin conservar ese calificativo. Una ficha de producto que aparezca dos veces en carruseles distintos no debería crear automáticamente dos productos diferentes.

Conserva el texto sin procesar junto con los valores normalizados cuando la distinción sea relevante. Por ejemplo, almacena «1.249,00 €» como texto observado y deduce el importe numérico únicamente mediante una regla de configuración regional conocida. Adivinar las convenciones de puntuación puede convertir un precio válido en un valor erróneo por órdenes de magnitud. La observación sin procesar te permite corregir la transformación sin tener que volver a visitar la página.

Elige una identidad de registro independientemente del orden visual. Es preferible un ID de origen cuando la página lo proporciona en una representación permitida. Una URL canónica del producto puede servir cuando se comprenden sus reglas de identidad. La tercera ficha de la página no es una identidad estable, ya que la ordenación, las recomendaciones y los cambios en el inventario pueden desplazarla.

Define también el contexto de captura. La ventana de visualización, el idioma, la cuenta y los filtros seleccionados pueden afectar al resultado mostrado. Cuando intervenga una cuenta autorizada, gestiona explícitamente las cookies HTTP y la propiedad de la sesión. No compartas una sesión entre tareas de clientes no relacionadas simplemente porque ya funcione.

Una regla de aceptación útil se lee como una prueba: cada ficha aceptada tiene un ID y un nombre no vacíos, el texto del precio se conserva tal cual, los ID duplicados se clasifican y la ejecución registra si ha finalizado. Esto proporciona a los sitios web de «screen scraping» una condición de éxito observable más allá de «el script ha finalizado sin lanzar un error».

Este ejercicio crea dos productos ficticios tras un breve retraso asíncrono, marca el catálogo como listo y extrae registros estructurados. Instala Playwright en un proyecto desechable de Node.js, instala su navegador Chromium y guarda el JavaScript como un módulo ES, por ejemplo collect.mjs. El ejemplo no contiene ninguna solicitud de API, credenciales ni destino externo.

import assert from 'node:assert/strict';
import { chromium } from 'playwright';

const browser = await chromium.launch();
try {
  const page = await browser.newPage();
  await page.setContent(`
    <main id="catalog" data-ready="false"></main>
    <script>
      setTimeout(() => {
        document.querySelector('#catalog').innerHTML =
          '<article data-id="p1"><h2>Desk lamp</h2>' +
          '<span class="price">EUR 24.00</span></article>' +
          '<article data-id="p2"><h2>Notebook</h2>' +
          '<span class="price">EUR 6.50</span></article>';
        document.querySelector('#catalog').dataset.ready = 'true';
      }, 30);
    </script>
  `);
  await page.locator('#catalog[data-ready="true"]').waitFor();
  const records = await page.locator('#catalog article').evaluateAll(
    cards => cards.map(card => ({
      id: card.getAttribute('data-id'),
      name: card.querySelector('h2')?.textContent?.trim() ?? '',
      priceText: card.querySelector('.price')?.textContent?.trim() ?? ''
    }))
  );
  assert.deepEqual(records, [
    { id: 'p1', name: 'Desk lamp', priceText: 'EUR 24.00' },
    { id: 'p2', name: 'Notebook', priceText: 'EUR 6.50' }
  ]);
  console.log(JSON.stringify(records, null, 2));
} finally {
  await browser.close();
}

Lo importante es el contrato de disponibilidad, no el retraso utilizado para simular el trabajo. El recopilador espera un atributo que indique que el elemento de prueba ha terminado de insertar sus registros. Nunca da por sentado que treinta milisegundos sean suficientes en un sitio web real. La aserción verifica el resultado completo, incluyendo el número de registros y sus asociaciones.

La API de página de Playwright documenta la configuración del contenido de la página, mientras que su API de localización documenta la evaluación de elementos coincidentes. La llamada de retorno se ejecuta en el contexto de la página y devuelve datos sin formato. Los propios objetos DOM del navegador no se convierten en registros duraderos de la aplicación.

Para el scraping de páginas web en la práctica, sustituye el fixture por la navegación a una página aprobada y sustituye su marcador de disponibilidad por pruebas específicas de esa página. Mantén el paso de validación. Una primera prueba negativa útil consiste en eliminar un elemento de precio y comprobar que tu validador de producción rechaza o pone en cuarentena la fila incompleta, en lugar de publicarla como un resultado normal.

El fixture es intencionadamente lo suficientemente sencillo como para entenderlo. No incluye programación, almacenamiento persistente ni un rastreador general. Nuestra guía más amplia sobre el scraping con Playwright proporciona contexto adicional sobre el flujo de trabajo del navegador cuando estés listo para ir más allá de una única extracción.

Una página puede terminar de cargar su documento antes de que lleguen sus datos útiles. También puede mantener abiertas las conexiones de red después de que los datos necesarios ya estén disponibles. El scraping de sitios web requiere una condición vinculada a la tarea de recopilación, como un encabezado de resultados más un indicador de carga completada, en lugar de una pausa arbitraria.

Para una acción interactiva, localiza el control mediante una propiedad estable y delimítalo a la región pertinente. Una página puede contener varios botones «Siguiente» en galerías de productos, resultados de búsqueda y contenido relacionado. Hacer clic en el primer texto que coincida no es prueba suficiente de que el recopilador haya avanzado en la lista prevista. Playwright recomienda utilizar atributos orientados al usuario y contratos explícitos en sus directrices de localización.

Distingue entre la disponibilidad de la acción y la integridad del conjunto de datos. Que un botón esté visible y se pueda pulsar no significa que estén presentes todas las filas de resultados. Tras el clic, verifica que el marcador de página resultante o el conjunto de registros haya cambiado y que se cumpla la condición de finalización específica de la página. Si mantienes la aplicación de origen, añadir un atributo de disponibilidad estable hace que este contrato sea comprobable.

Elige la extracción de texto de forma deliberada. MDN describe `innerText` como sensible a la apariencia renderizada, mientras que `textContent` lee el texto del nodo sin tener en cuenta ese renderizado. Ninguno de los dos constituye una definición automática del campo de negocio. Extrae información de un elemento de precio específico en lugar de leer una ficha completa y esperar separar las etiquetas más tarde.

Por ejemplo, una ficha puede contener el precio actual, un precio tachado, texto sobre la entrega y una etiqueta de accesibilidad oculta. Una extracción de texto amplia puede combinar los cuatro. Decide si el registro necesita el precio actual mostrado, el precio original o ambos, y luego utiliza campos y localizadores con nombres distintos.

Cuando falle un selector, muéstralo de forma visible. Evita una cadena de alternativas que se amplíe gradualmente hasta encontrar texto no relacionado. Al extraer datos de sitios web mediante screen scraping, es más fácil corregir un error claro de campo faltante que una ejecución correcta llena de valores plausibles pero incorrectos.

Diez fichas correctas de la primera página siguen constituyendo un conjunto de datos incompleto cuando la tarea requiere toda la categoría. Define una condición de parada antes de introducir un bucle. En el caso de las páginas paginadas, eso podría ser un indicador documentado de la última página o un control «Siguiente» desactivado. Para una interfaz de «cargar más» aprobada, podría ser un marcador de fin explícito.

El screen scraping de sitios web con desplazamiento infinito requiere un cuidado especial, ya que algunas listas virtualizan su contenido. Reutilizan un pequeño grupo de nodos DOM a medida que el lector se desplaza por una colección más amplia. Por lo tanto, contar los elementos que se encuentran actualmente en el documento puede subestimar el número de registros que han aparecido, y tomar una única instantánea final del DOM puede hacer que se pierdan registros anteriores.

Recopila cada lote una vez que se cumpla su condición de disponibilidad, utilizando la identidad de la fuente para deduplicar las observaciones. Realiza un seguimiento de los ID ya aceptados, del último marcador de navegación y del número de intentos consecutivos que no han generado nuevos ID. Trata un límite de falta de progreso como una parada de protección con un estado «incompleto», a menos que la fuente también proporcione una condición de fin fiable.

Utiliza un trabajo delimitado incluso cuando la interfaz parezca interminable. Establece un número máximo de páginas, un tiempo transcurrido y un recuento de registros adecuados para la tarea. Registra qué límite puso fin a la ejecución. «Se detuvo tras alcanzar el límite de páginas configurado» y «se llegó a la última página de la fuente» tienen significados diferentes para los usuarios posteriores.

Guarda puntos de control después de que los datos aceptados se hayan almacenado de forma duradera. Si un proceso falla entre la recopilación y la persistencia, reanudar desde un cursor que se guardó demasiado pronto puede omitir registros. Reproducir una página es más seguro cuando tu destino deduplica según una identidad estable y una política de observación.

En el caso de un catálogo cambiante, la exhaustividad también es temporal. Los elementos pueden desplazarse entre páginas mientras la ejecución está activa. Registra la ventana de recopilación y evita calificar la salida como una instantánea exacta, a menos que la fuente ofrezca esa garantía. Un trabajo de observación diario puede resultar útil sin pretender describir un estado instantáneo.

Estos límites convierten el «screen scraping» de sitios web, que antes era una simple macro del navegador, en un proceso de recopilación cuyos límites pueden explicarse y comprobarse.

Una captura de pantalla es una prueba útil cuando la presentación visual forma parte de la cuestión en sí misma. Puede mostrar un precio que falta, un cuadro de diálogo inesperado o un diseño que ya no se ajusta al contrato de extracción. Playwright admite capturas de páginas y elementos a través de su interfaz de capturas de pantalla.

El OCR es una transformación independiente que se aplica a esa imagen. Considéralo cuando la información autorizada solo esté realmente disponible en forma de píxeles —como texto dibujado en un lienzo— y no exista una representación estructurada adecuada. No lo utilices para resolver problemas de acceso ni para eludir la denegación de acceso de un sitio web. Detente y resuelve los problemas de permisos o acceso a través del propietario.

El «screen scraping» de sitios web mediante OCR requiere una política de incertidumbre. Los caracteres similares, la puntuación decimal, el texto recortado y el bajo contraste pueden alterar el resultado. Una cadena que supere un analizador numérico básico puede seguir representando un precio erróneo. Mantén juntos la región relevante de la imagen, el texto reconocido, la versión de la transformación y cualquier señal de confianza disponible.

Revisa los campos de alto impacto comparándolos con una restricción independiente. Una cantidad monetaria reconocida podría necesitar tanto una etiqueta de moneda conocida como un formato razonable. Un identificador de producto podría tener una longitud fija o una suma de comprobación. Estas comprobaciones pueden detectar algunos errores, pero no demuestran que un resultado plausible coincida con la imagen original.

En el caso de las capturas de pantalla utilizadas como material de depuración, recorta la región relevante y limita su conservación. El acceso autorizado a una página no significa que todos los detalles visibles de la cuenta deban formar parte de un archivo de diagnóstico permanente. Registra el motivo por el que se capturó la imagen, restringe el acceso y elimínala cuando la investigación ya no la necesite.

El mismo cuidado se aplica a las instantáneas HTML: pueden aparecer campos ocultos y contenido específico de la cuenta incluso cuando la captura de pantalla parezca inofensiva. Almacena solo las pruebas mínimas necesarias para reproducir el problema de extracción.

• Inspecciona la representación de origen antes de seleccionar una herramienta. El HTML inicial, el DOM renderizado y los píxeles de las imágenes requieren estrategias de extracción y validación diferentes.
• Asegúrate de que la preparación describa los datos que necesitas y valida el registro extraído completo, en lugar de limitarte a comprobar que una acción del navegador se ha realizado con éxito.
• Define la identidad, la finalización de la paginación, los tiempos de los puntos de control y los estados de ejecución incompleta antes de ampliar un recopilador más allá de una página.
• Conserva las observaciones sin procesar cuando la normalización pueda alterar el significado. Utiliza capturas de pantalla de forma selectiva y aplica reglas de revisión explícitas a los resultados del OCR.

Sí. Una extensión puede ayudar a inspeccionar una página o probar una pequeña idea de extracción antes de crear un colector programado. Evalúa su comportamiento en cuanto al acceso a los datos y la exportación antes de instalarla en un navegador autenticado. Un prototipo manual satisfactorio sigue necesitando entradas reproducibles, validación y responsabilidad operativa antes de convertirse en un trabajo de producción fiable.

Por lo general, mantén el idioma original en el registro sin procesar y traduce en un paso aparte. La traducción altera la observación y puede complicar las comparaciones entre ejecuciones. Almacena el idioma de origen, el resultado traducido y la versión de la transformación por separado, de modo que una corrección en la traducción no requiera volver a visitar la página de origen.

Proporciona el contrato de extracción, un pequeño conjunto de pruebas aprobado, el resultado esperado y ejemplos de fallos clasificados. Incluye quién tiene acceso a la fuente y qué tareas posteriores consumen el resultado. El siguiente responsable del mantenimiento debería poder reproducir una extracción que supere las pruebas y reconocer una ejecución incompleta sin depender del historial del navegador del autor original.

El primer hito útil en la extracción de datos de sitios web es un registro validado con procedencia conocida. Empieza por ahí y, a continuación, añade la navegación, la persistencia y la programación solo cuando sus condiciones de éxito sean igualmente claras. Deberías poder explicar de dónde procede cada campo, por qué la página estaba lista y qué provocó que la ejecución se detuviera.

Antes de una implementación más amplia, simula un campo que falte, una página repetida y un cambio en la fuente que no genere nuevos registros. Confirma que estos escenarios dan lugar a clasificaciones explícitas en lugar de informes de éxito vacíos. Este pequeño conjunto de fallos suele revelar si tu flujo de trabajo tiene un contrato de datos real o solo una secuencia de acciones del navegador.

Si la gestión de la infraestructura del navegador se convierte en el factor que limita tu flujo de trabajo de recopilación autorizado, evalúa la API de navegador de WebScrapingAPI para el control de navegadores alojados. Mantén tu esquema de registros, tus reglas de disponibilidad y tu validación al margen de la elección de la infraestructura, de modo que sigan siendo revisables a medida que el sistema crezca.