Extracción de datos de mapas de sitio: descubre URL con límites seguros

Comienza por el objetivo de la recopilación. Si necesitas detalles de productos, una lista de URL de páginas es un resultado intermedio. Aún así, debes identificar qué direcciones representan productos, recuperar las páginas adecuadas, extraer campos y validar los registros resultantes.

Un mapa del sitio puede ser declarado por el propio sitio o facilitado directamente por su propietario. Un nombre de archivo convencional es una opción útil, pero no garantiza que todos los sitios lo utilicen. Trata el descubrimiento de la dirección del mapa del sitio y la autorización para recopilar su contenido como cuestiones independientes.

Para el web scraping de mapas del sitio, mantén una cola de candidatos en lugar de recuperar inmediatamente todas las ubicaciones. Almacena dónde se descubrió cada URL y qué regla la admitió en la cola de páginas. Esto facilita la investigación posterior de un índice amplio o de un documento inesperado.

No hay que confundir la intención de publicación con la exhaustividad. Un sitio web puede omitir páginas, publicar entradas obsoletas o mantener varias colecciones de mapas del sitio para contenidos diferentes. El informe de descubrimiento debe describir lo que contenían los documentos inspeccionados, no afirmar que no existen otras páginas.

Distinga también entre una recuperación fallida y una página eliminada. Un error temporal de la pasarela durante el descubrimiento no aporta nada concluyente sobre si el contenido enumerado sigue existiendo. La guía de diagnóstico del estado del proxy explica por qué las categorías de respuesta necesitan pruebas antes de convertirse en conclusiones sobre la fuente.

Mantén el alcance inicial lo suficientemente reducido como para inspeccionarlo manualmente. Un único mapa del sitio aprobado y unos pocos tipos de páginas representativos pueden revelar si este método de descubrimiento se adapta a la tarea antes de que un recorrido a gran escala oculte las discrepancias.

La raíz XML indica qué contiene el documento. Un urlset contiene entradas de página; un sitemapindex contiene entradas que apuntan a documentos de mapa del sitio. Ambos utilizan el espacio de nombres Sitemaps, y sus elementos loc tienen funciones diferentes. El protocolo Sitemaps define esas estructuras.

Los espacios de nombres XML son importantes incluso cuando la etiqueta visible parece sencilla. Con un espacio de nombres predeterminado, un analizador XML identifica el elemento utilizando conjuntamente el URI del espacio de nombres y el nombre local. Por lo tanto, la búsqueda de elementos url puede, por lo tanto, no arrojar ningún resultado en un mapa del sitio que, por lo demás, sería válido.

Al extraer datos de mapas de sitio, selecciona la ruta estructural específica que necesites. Una búsqueda amplia de todos los elementos denominados loc puede mezclar ubicaciones de páginas con referencias del mapa del sitio o metadatos de extensión. Distingue el espacio de nombres principal de las extensiones de imagen, vídeo, noticias u otras, en lugar de eliminar todos los espacios de nombres de forma indiscriminada.

Deja que el analizador XML se encargue de la codificación de entidades. Una URL que contenga un separador de consulta puede aparecer & en XML y generar & en el texto analizado. No sustituyas cadenas arbitrarias antes del análisis ni decodifiques repetidamente las URL hasta que te parezcan adecuadas.

Conserva la dirección original descubierta junto con cualquier normalización que apliques. La normalización debe aplicar reglas de identidad conocidas, no suponer que diferentes rutas o cadenas de consulta son equivalentes. Una lista de URL solo se convierte en una entrada útil cuando su interpretación se mantiene coherente con el contrato de origen y el alcance de tu recopilación.

Guarda este ejercicio como sitemap_fixture.py y ejecútalo con Python 3. Utiliza únicamente la biblioteca estándar, analiza cadenas Unicode fijas en memoria y no realiza ninguna recuperación de datos de la red. El fixture clasifica un índice y un conjunto de URL, y luego comprueba que se rechace un host no relacionado.

from urllib.parse import urlsplit
from xml.etree import ElementTree as ET

NS = "http://www.sitemaps.org/schemas/sitemap/0.9"
INDEX = f'''<sitemapindex xmlns="{NS}">
  <sitemap><loc>https://catalog.example/products.xml</loc></sitemap>
</sitemapindex>'''
URLS = f'''<urlset xmlns="{NS}">
  <url><loc>https://catalog.example/products/lamp</loc>
    <lastmod>2026-09-01</lastmod></url>
  <url><loc>https://catalog.example/products/book?lang=en&amp;view=full</loc></url>
</urlset>'''

def allowed_url(value):
    if not value or any(ord(char) <= 32 for char in value):
        raise ValueError("missing URL or control/space character")
    parts = urlsplit(value)
    if (parts.scheme != "https" or parts.netloc != "catalog.example"
            or parts.fragment):
        raise ValueError("URL outside fixture scope")
    return value

def parse_fixture(text):
    if len(text.encode("utf-8")) > 10_000:
        raise ValueError("fixture byte budget exceeded")
    upper = text.upper()
    if "<!DOCTYPE" in upper or "<!ENTITY" in upper:
        raise ValueError("declarations not accepted in this fixture")
    root = ET.fromstring(text)
    shapes = {
        f"{{{NS}}}urlset": ("pages", "url"),
        f"{{{NS}}}sitemapindex": ("sitemaps", "sitemap"),
    }
    if root.tag not in shapes:
        raise ValueError("unsupported root or namespace")
    kind, child = shapes[root.tag]
    entries = root.findall(f"{{{NS}}}{child}")
    if len(entries) > 10:
        raise ValueError("fixture entry budget exceeded")
    result = []
    for entry in entries:
        locations = entry.findall(f"{{{NS}}}loc")
        if len(locations) != 1:
            raise ValueError("expected exactly one location")
        location = allowed_url((locations[0].text or "").strip())
        modified = entry.findtext(f"{{{NS}}}lastmod")
        result = [*result, {"url": location, "lastmod_raw": modified}]
    return kind, result

kind, children = parse_fixture(INDEX)
assert kind == "sitemaps" and len(children) == 1
documents = {"https://catalog.example/products.xml": URLS}
kind, pages = parse_fixture(documents[children[0]["url"]])
assert kind == "pages" and len(pages) == 2
assert pages[0]["lastmod_raw"] == "2026-09-01"
assert pages[1]["url"].endswith("?lang=en&view=full")
for invalid in [
    URLS.replace("catalog.example", "other.example"),
    '<!DOCTYPE urlset><urlset/>',
    '<urlset><url><loc>https://catalog.example/x</loc></url></urlset>',
]:
    try:
        parse_fixture(invalid)
    except ValueError:
        pass
    else:
        raise AssertionError("invalid fixture accepted")
print("index classified; 2 page URLs parsed; rejection checks passed")

El fixture permite deliberadamente una única autoridad HTTPS exacta. No sigue redirecciones, no resuelve DNS, no descomprime datos ni afirma que las comprobaciones de URL a nivel de cadena impidan la falsificación de solicitudes del lado del servidor. Esos controles pertenecen a una capa de recuperación en producción.

La comprobación de la declaración también se limita a las cadenas ya descodificadas del fixture. No se trata de un cortafuegos XML general para codificaciones remotas arbitrarias. Utiliza un analizador configurado adecuadamente y límites de recuperación para entradas no fiables, en lugar de copiar esta comprobación como una defensa completa.

Obsérvese cómo lastmod se conserva como metadatos de origen sin procesar. El ejercicio no lo convierte en una prueba de que la página haya cambiado ni en un comando de programación. La segunda página no tiene valor de modificación, lo cual difiere de una marca de tiempo antigua conocida.

Esta pequeña prueba abarca los límites de interpretación en el rastreo de mapas de sitio web: clasificación raíz, rutas sensibles al espacio de nombres, decodificación de entidades, un único host permitido y estructuras malformadas rechazadas. Mantén esas pruebas al añadir el transporte y, a continuación, añade pruebas independientes para las reglas de redireccionamiento, tamaño y destino del transporte.

Utiliza colas separadas para los documentos del mapa del sitio y las páginas candidatas. Inicia la cola de documentos con el índice aprobado, recupera y clasifica un documento delimitado y, a continuación, coloca las ubicaciones de los mapas del sitio secundarios o de las páginas en el destino adecuado. No añadas una página a la cola como si fuera otro mapa del sitio simplemente porque ambos contengan URL.

Mantén un conjunto de elementos visitados para las ubicaciones de los documentos, de modo que las referencias repetidas no provoquen un trabajo repetitivo indefinidamente. Si un proveedor publica un anidamiento de índices inesperado, define si tu recopilador lo rechaza o admite un recorrido delimitado. No des por sentado que el anidamiento arbitrario es una garantía del protocolo portátil.

Los límites del protocolo y los presupuestos operativos son distintos. Un mapa del sitio estándar permite como máximo 50 000 URL y 50 MB, concretamente 52 428 800 bytes, sin comprimir. Los índices de los mapas del sitio también tienen límites de entradas y de tamaño. La compresión reduce el tamaño de la transferencia sin eliminar el límite sin comprimir. Es posible que tu tarea requiera límites más bajos para ajustarse a su memoria, tiempo y alcance aprobado.

Para el rastreo web de mapas de sitio a gran escala, limita los bytes transferidos, los bytes descomprimidos, los documentos, las entradas, el tiempo transcurrido y la profundidad de recorrido, cuando proceda. Una respuesta comprimida pequeña puede seguir generando un cuerpo de gran tamaño tras su expansión. Aplica los límites durante la lectura y la descompresión, no solo tras asignar el documento expandido completo.

Registra las referencias rechazadas y omitidas. «Ya visitada» es diferente de «host no permitido», «documento demasiado grande» o «no se ha podido analizar el XML». Esas categorías explican por qué el recuento de páginas descubiertas difiere del número de entradas encontradas inicialmente.

Establece un punto de control tras haber registrado una salida duradera. Si los resultados del descubrimiento se almacenan por separado del estado de recorrido, diseña un comportamiento de reinicio que permita reproducir un documento de forma segura. La deduplicación debe evitar entradas duplicadas en la cola sin ocultar los cambios en los metadatos que son relevantes para el trabajo.

Por último, conserva la hora de recuperación del documento y la ubicación final aprobada. De lo contrario, una redirección o un documento modificado podrían hacer que dos ejecuciones parecieran idénticas cuando, en realidad, han inspeccionado entradas diferentes.

El campo a nivel de página lastmod representa la última modificación de esa página indicada por el editor. No se supone que signifique la hora en que se ejecutó el generador del mapa del sitio. Un valor de modificación a nivel de índice se refiere, en cambio, al documento del mapa del sitio. Mezclar esos significados puede provocar actualizaciones innecesarias de páginas u omitir otras relevantes.

En el caso de los mapas de sitio obtenidos mediante web scraping, conserva el valor sin procesar y analízalo únicamente siguiendo una política de fechas explícita. Una fecha sin hora es menos precisa que una marca de tiempo. Un valor que falte o esté mal formado debe permanecer como desconocido, no convertirse en la fecha de hoy ni en un valor por defecto que implique certeza.

Trata el valor como una indicación de prioridad hasta que la fuente haya demostrado una precisión útil para tu tarea. Compara una muestra de los cambios anunciados con las observaciones reales de las páginas. Una marca de tiempo fiable para el contenido editorial puede seguir siendo demasiado imprecisa para los valores bursátiles que cambian con frecuencia.

La guía de Google sobre mapas de sitio explica su uso de lastmod y afirma que ignora priority y changefreq. Eso describe el comportamiento de Google, no un requisito de que tu recopilador copie su política de programación. No conviertas los metadatos opcionales del editor en una instrucción de obtención universal.

La validación HTTP vuelve a ser independiente. La etiqueta de entidad de un servidor o el encabezado de respuesta «last-modified» pueden participar en la recuperación condicional según las reglas de HTTP. La fecha de un mapa del sitio no sustituye a esos validadores ni garantiza una 304 respuesta. El RFC 9111 define la vigencia de la caché y el comportamiento de validación.

Para el informe de recopilación, conserva por separado los metadatos de modificación de la fuente, la hora de descubrimiento y la hora de observación de la página. Estos datos indican cuándo el editor notifica un cambio, cuándo encontraste la dirección y cuándo observaste la representación real.

Utiliza esa distinción a la hora de programar. Dar prioridad a los cambios anunciados recientemente puede mejorar el orden de trabajo, mientras que la conciliación periódica cubre las fechas que faltan o que no son fiables. Documenta esa política para que los usuarios comprendan qué significa realmente «actualizado recientemente».

El análisis de XML y el análisis de URL no otorgan permiso para realizar una solicitud de red. Una ubicación puede apuntar fuera del sitio autorizado, contener credenciales, utilizar un esquema inesperado o llegar a una dirección a la que el recopilador no debería tener acceso. Trata cada ubicación descubierta como una entrada no fiable sujeta a una comprobación de admisión independiente.

La documentación sobre análisis de URL de Python advierte explícitamente de que las funciones de análisis no validan las entradas. Por lo tanto, una división correcta entre esquema y nombre de host no constituye una decisión de seguridad. Aplica una política explícita para esquemas, hosts, puertos, información de usuario y ámbito.

La falsificación de solicitudes del lado del servidor cobra relevancia cuando un servicio automatizado recupera destinos influenciados por entradas externas. Mantén los controles de destino en el límite real de la red, incluyendo redireccionamientos y direcciones resueltas. Una lista de host permitidos por sí sola no cubre todos los escenarios de DNS o redireccionamiento, y validar un salto no autoriza el siguiente.

Al extraer mapas de sitio (sitemaps) de la web, evita reenviar las credenciales de la solicitud original a un host recién descubierto. Algunos editores utilizan acuerdos de alojamiento entre sitios compatibles, pero tu recopilador solo debe habilitar los acuerdos que haya aprobado explícitamente. Una referencia externa no es una instrucción para ampliar automáticamente el alcance de la recopilación.

El XML no fiable añade otro límite. La expansión de entidades, el acceso a recursos externos y el comportamiento ante tokens de gran tamaño dependen del analizador y de su configuración. La documentación sobre seguridad XML de Python resume los riesgos y destaca la importancia de la versión del analizador subyacente. No des por sentado que todas las bibliotecas XML comparten los mismos valores predeterminados.

Utiliza medidas de protección del analizador adecuadas y actualizadas, junto con límites de tamaño y de tiempo de ejecución. Rechaza las características de los documentos no compatibles en lugar de habilitar la resolución de entidades externas para que se pueda analizar un archivo. Clasifica un mapa del sitio mal formado como un fallo de descubrimiento, con un diagnóstico depurado que ayude al propietario de la fuente a investigar.

Estos controles son complementarios. El análisis sintáctico sensible al espacio de nombres evita la confusión estructural; la política de URL controla los destinos; la aplicación de normas de red comprueba la conexión; y los límites de recursos restringen el trabajo. Ninguno puede sustituir de forma segura a todos los demás.

Al final del recorrido, informa de lo que se ha inspeccionado y por qué se detuvo el trabajo. Incluye el recuento de documentos, las páginas candidatas aceptadas, los duplicados, los destinos rechazados, los fallos de análisis y las interrupciones por presupuesto. Un gran número de URL por sí solo no demuestra que el descubrimiento sea completo o correcto.

Comprueba una muestra de las URL admitidas con tu esquema de destino. Las páginas de productos, categorías, búsqueda y editoriales pueden coexistir en un mismo conjunto de mapas del sitio. Define una regla de enrutamiento para cada tipo relevante y mantén los tipos no relacionados fuera de la cola de extracción, en lugar de permitir que sus campos faltantes contaminen las métricas de validación de registros.

Los mapas de sitio obtenidos mediante web scraping resuelven el descubrimiento de direcciones, no la representación de páginas. Si las páginas seleccionadas solo exponen datos tras la ejecución del navegador, la guía de screen scraping explica cómo elegir una condición de disponibilidad y extraer los campos representados. No des por sentado que un mapa de sitio garantiza contenido HTML estático.

Conserva la procedencia a lo largo de ese traspaso. Un registro de página debe conservar la URL descubierta, la fuente del mapa del sitio, la hora de observación y la versión de extracción, cuando sea pertinente. Las direcciones redirigidas o canónicas necesitan una política de identidad explícita, en lugar de una sustitución no documentada.

La guía del flujo de trabajo de recopilación automatizada vincula el descubrimiento con el procesamiento duradero, los reintentos y la entrega. Mantén esas etapas observables para que una interrupción en la recuperación no haga que parezca que el analizador de mapas del sitio ha devuelto menos entradas.

Antes de escalar, prueba una referencia a un documento duplicado, una URL rechazada, un archivo XML mal formado y un presupuesto agotado. El resultado útil no es simplemente que el script se detenga. Debe detenerse con una clasificación que explique qué parte del alcance de descubrimiento previsto sigue sin resolverse.

• Utiliza mapas del sitio obtenidos mediante web scraping para crear una cola de candidatos; a continuación, valida los destinos y extrae los registros de las páginas en etapas separadas.
• Analiza la raíz y el espacio de nombres de forma deliberada para que no se mezclen las referencias del mapa del sitio, las ubicaciones de las páginas y los datos de las extensiones.
• Aplica comprobaciones de tamaño que tengan en cuenta el protocolo, junto con presupuestos operativos más estrictos, incluyendo los bytes descomprimidos y el trabajo total de recorrido.
• Conserva lastmod como metadatos del editor; distíngelos del momento del descubrimiento, el momento de la observación y los validadores HTTP.
• Mantén la admisión de URL, los controles de destino de red, las defensas XML y los informes de integridad de forma que se puedan probar de manera independiente.

Sí. El protocolo permite más de un índice de mapa del sitio. Para los mapas del sitio de rastreo web, descubre o recibe el conjunto aprobado en lugar de dar por sentado que encontrar un único índice identifica todos los mapas del sitio. Mantén la procedencia de cada documento de partida y define si sus resultados se combinan en un único ámbito de recopilación o se informan por separado.

No de forma automática. Los parámetros de consulta pueden identificar el idioma, el contenido u otra variante significativa. Elimínalos solo si existe una regla de identidad verificada para esa fuente. Conserva la URL descubierta para que sea posible una corrección posterior y comprueba que cualquier normalización no agrupe registros distintos ni altere la representación recuperada.

No. Una dirección incluida en la lista es una señal de descubrimiento, no una prueba de que un motor de búsqueda pueda indexarla o vaya a hacerlo. Siguen aplicándose otras condiciones relativas a la página y al acceso. Para la recopilación de datos, verifica la respuesta real y el contenido requerido, en lugar de interpretar la presencia en el mapa del sitio como una garantía de disponibilidad o idoneidad.

El rastreo de mapas de sitio funciona mejor cuando el descubrimiento sigue siendo una etapa diferenciada y cuantificable. Clasifica el documento, analiza el espacio de nombres adecuado, conserva los metadatos de la fuente y admite solo aquellos objetivos que se ajusten a la política de recopilación. A continuación, informa tanto de los candidatos descubiertos como de los motivos por los que algunas partes del recorrido quedaron incompletas.

Empieza con el entorno local y amplía los límites de uno en uno. Añade una recuperación limitada antes de los archivos de gran tamaño, la verificación del destino antes de las referencias externas y un progreso duradero antes de un recorrido de larga duración. Conserva los casos de prueba que muestren un fallo claro cuando se traspasen esos límites.

Cuando la cola de páginas aprobadas esté lista, evalúa la API de scraper de WebScrapingAPI para la etapa de recuperación. Conserva tu propia procedencia de descubrimiento y los registros de comprobación, de modo que el conjunto de datos resultante explique tanto de dónde proceden sus URL como lo que se observó realmente.