Web scraping de mapas do site: descobrir URLs dentro de limites seguros

Comece pelo objetivo da recolha. Se precisar de detalhes sobre produtos, uma lista de URLs de páginas é um resultado intermédio. Ainda precisa de identificar quais os endereços que representam produtos, recuperar as páginas adequadas, extrair campos e validar os registos resultantes.

Um mapa do site pode ser declarado pelo próprio site ou fornecido diretamente pelo seu proprietário. Um nome de ficheiro convencional é uma boa opção, mas não é garantia de que todos os sites o utilizem. Trate a descoberta do endereço do mapa do site e a autorização para recolher o seu conteúdo como questões distintas.

Para a extração de mapas do site, mantenha uma fila de candidatos em vez de ir buscar imediatamente todos os endereços. Registe onde cada URL foi descoberto e qual a regra que permitiu a sua inclusão na fila de páginas. Isto facilita a investigação posterior de um índice abrangente ou de um documento inesperado.

Não confunda a intenção de publicação com a exaustividade. Um site pode omitir páginas, publicar entradas desatualizadas ou manter várias coleções de mapas do site para conteúdos diferentes. O seu relatório de descoberta deve descrever o que os documentos inspecionados continham, não afirmar que não existem outras páginas.

Distinga também uma recuperação falhada de uma página removida. Um erro temporário do gateway durante a descoberta não indica de forma conclusiva se o conteúdo listado ainda existe. O guia de diagnóstico do estado do proxy explica por que razão as categorias de resposta necessitam de provas antes de se tornarem conclusões sobre a fonte.

Mantenha o âmbito inicial suficientemente pequeno para permitir a inspeção manual. Um único mapa do site aprovado e alguns tipos de páginas representativos podem revelar se este método de descoberta se adequa à tarefa, antes que uma grande varredura oculte discrepâncias.

A raiz XML indica o que o documento contém. Um urlset contém entradas de páginas; um sitemapindex contém entradas que apontam para documentos de mapa do site. Ambos utilizam o espaço de nomes Sitemaps, e os seus loc têm funções diferentes. O protocolo Sitemaps define essas estruturas.

Os espaços de nomes XML são importantes mesmo quando a tag visível parece simples. Com um espaço de nomes predefinido, um analisador XML identifica o elemento utilizando em conjunto o URI do espaço de nomes e o nome local. A pesquisa por elementos url pode, por isso, não devolver nenhum resultado de um mapa do site que, de outra forma, seria válido.

Ao extrair dados de mapas do site, selecione o caminho estrutural específico de que necessita. Uma pesquisa abrangente por todos os elementos denominados loc pode misturar localizações de páginas com referências do mapa do site ou metadados de extensão. Distinga o espaço de nomes principal de extensões como imagem, vídeo, notícias ou outras, em vez de remover todos os espaços de nomes indiscriminadamente.

Deixe que o analisador XML trate da codificação de entidades. Um URL que contenha um separador de consulta pode aparecer com & no XML e gerar & no texto analisado. Não substitua cadeias de caracteres arbitrárias antes da análise nem descodifique repetidamente as URLs até que pareçam convenientes.

Preserve o endereço original descoberto a par de qualquer normalização que aplicar. A normalização deve implementar regras de identidade conhecidas, não presumir que diferentes caminhos ou cadeias de consulta sejam equivalentes. Uma lista de URLs só se torna uma entrada útil quando a sua interpretação se mantém consistente com o contrato de origem e o âmbito da sua recolha.

Guarde este exercício como sitemap_fixture.py e execute-o com Python 3. Utiliza apenas a biblioteca padrão, analisa cadeias Unicode fixas na memória e não realiza qualquer recuperação de dados da rede. O fixture classifica um índice e um conjunto de URLs, verificando depois se um host não relacionado é rejeitado.

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")

O fixture permite deliberadamente uma única autoridade HTTPS exata. Não segue redirecionamentos, não resolve DNS, não descomprime dados nem alega que as verificações de URL ao nível da cadeia de caracteres impedem a falsificação de pedidos do lado do servidor. Esses controlos pertencem a uma camada de recuperação de produção.

A verificação da declaração também se limita às cadeias de caracteres já descodificadas pelo fixture. Não se trata de uma firewall XML geral para codificações remotas arbitrárias. Utilize um analisador devidamente configurado e limites de recuperação para entradas não confiáveis, em vez de copiar esta verificação como uma defesa completa.

Repare como lastmod é mantido como metadados de origem em bruto. O exercício não o converte numa prova de que a página foi alterada nem num comando de agendamento. A segunda página não apresenta qualquer valor de modificação, o que difere de um carimbo de data/hora antigo conhecido.

Este pequeno teste abrange os limites de interpretação na extração de mapas de sites (sitemaps): classificação de raiz, caminhos sensíveis ao espaço de nomes, descodificação de entidades, um anfitrião permitido e estrutura malformada rejeitada. Mantenha esses testes ao adicionar o transporte e, em seguida, adicione testes separados para as regras de redirecionamento, tamanho e destino do transporte.

Utilize filas separadas para documentos de mapa do site e páginas candidatas. Inicie a fila de documentos com o índice aprovado, recupere e classifique um documento delimitado e, em seguida, coloque as localizações dos mapas do site ou das páginas secundárias no destino apropriado. Não coloque uma página na fila como se fosse outro mapa do site simplesmente porque ambos contêm URLs.

Mantenha um conjunto de locais visitados para as localizações dos documentos, para que as referências repetidas não provoquem trabalho repetido indefinidamente. Se um fornecedor publicar um aninhamento de índices inesperado, defina se o seu coletor o rejeita ou suporta uma percussão delimitada. Não presuma que o aninhamento arbitrário seja uma garantia do protocolo portátil.

Os limites do protocolo e os orçamentos operacionais são diferentes. Um mapa do site padrão permite, no máximo, 50 000 URLs e 50 MB, especificamente 52 428 800 bytes, quando não comprimido. Os índices dos mapas do site também têm limites de entradas e de tamanho. A compressão reduz o tamanho da transferência sem remover o limite não comprimido. A sua tarefa pode necessitar de limites mais baixos para se adequar à sua memória, tempo e âmbito aprovado.

Para a extração de mapas do site em grande escala, limite os bytes transferidos, os bytes descomprimidos, os documentos, as entradas, o tempo decorrido e a profundidade de percurso, quando aplicável. Uma resposta comprimida pequena pode ainda assim produzir um corpo de dados grande após a expansão. Aplique limites durante a leitura e a descompressão, e não apenas após a alocação do documento expandido completo.

Registe as referências rejeitadas e ignoradas. «Já visitado» é diferente de «host não permitido», «documento demasiado grande» ou «não foi possível analisar o XML». Essas categorias explicam por que razão a contagem de páginas descobertas difere do número de entradas inicialmente encontradas.

Efetue um ponto de verificação após o registo de uma saída duradoura. Se os resultados da descoberta forem armazenados separadamente do estado de percurso, conceba um comportamento de reinício que permita reproduzir um documento com segurança. A deduplicação deve impedir entradas duplicadas na fila sem ocultar alterações nos metadados que sejam relevantes para a tarefa.

Por fim, guarde a hora de recuperação do documento e a localização final aprovada. Caso contrário, um redirecionamento ou um documento alterado pode fazer com que duas execuções pareçam idênticas, quando, na realidade, inspecionaram entradas diferentes.

O campo ao nível da página lastmod representa a última modificação declarada pelo editor dessa página. Não se destina a indicar a hora em que o gerador do mapa do site foi executado. Um valor de modificação ao nível do índice refere-se, em vez disso, ao documento do mapa do site. Misturar esses significados pode desencadear atualizações desnecessárias da página ou ignorar páginas relevantes.

No caso de mapas de site obtidos por web scraping, preserve o valor bruto e analise-o apenas de acordo com uma política de data explícita. Uma data sem hora é menos precisa do que um carimbo de data/hora. Um valor em falta ou malformado deve permanecer desconhecido, não se transformando na data de hoje nem num valor predefinido que implique certeza.

Trate o valor como uma indicação de prioridade até que a fonte tenha demonstrado uma precisão útil para a sua tarefa. Compare uma amostra das alterações anunciadas com observações reais das páginas. Um carimbo de data/hora fiável para conteúdo editorial pode ainda ser demasiado impreciso para valores de ações que mudam frequentemente.

As orientações do Google sobre o mapa do site explicam a sua utilização de lastmod e afirma que ignora priority e changefreq. Isso descreve o comportamento do Google, não uma exigência de que o seu coletor copie a sua política de agendamento. Não transforme metadados opcionais do editor numa instrução universal de recolha.

A validação HTTP é, mais uma vez, um aspeto à parte. A etiqueta de entidade de um servidor ou o cabeçalho de resposta «last-modified» podem participar na recuperação condicional ao abrigo das regras HTTP. A data de um mapa do site não substitui esses validadores nem garante uma 304 resposta. A RFC 9111 define a atualidade da cache e o comportamento de validação.

Para o relatório de recolha, mantenha separadamente os metadados de modificação da fonte, a hora de descoberta e a hora de observação da página. Estes indicam quando o editor declara uma alteração, quando encontrou o endereço e quando observou a representação efetiva.

Utilize essa distinção ao planear. Dar prioridade a alterações anunciadas recentemente pode melhorar a ordem do trabalho, enquanto a reconciliação periódica abrange datas em falta ou não fiáveis. Documente essa política para que os utilizadores compreendam o que «atualizado recentemente» significa realmente.

A análise de XML e a análise de URLs não concedem permissão para efetuar um pedido de rede. Um local pode apontar para fora do site aprovado, conter credenciais, utilizar um esquema inesperado ou aceder a um endereço que não deveria ser acessível a partir do coletor. Trate cada local descoberto como uma entrada não confiável, sujeita a uma verificação de admissão separada.

A documentação de análise de URLs do Python adverte explicitamente que as funções de análise não validam as entradas. Uma divisão bem-sucedida em esquema e nome de anfitrião não constitui, portanto, uma decisão de segurança. Aplique uma política explícita para esquemas, anfitriões, portas, informações de utilizador e âmbito.

A falsificação de pedidos do lado do servidor torna-se relevante quando um serviço automatizado acede a destinos influenciados por entradas externas. Mantenha os controlos de destino no limite real da rede, incluindo redirecionamentos e endereços resolvidos. Uma lista de nomes de anfitriões autorizados, por si só, não abrange todos os cenários de DNS ou redirecionamento, e a validação de um salto não autoriza o seguinte.

Ao extrair mapas do site (sitemaps) da Web, evite reencaminhar credenciais da solicitação original para um anfitrião recém-descoberto. Alguns editores utilizam acordos de alojamento entre sites suportados, mas o seu coletor deve ativar apenas os acordos que tiver aprovado explicitamente. Uma referência externa não constitui uma instrução para expandir automaticamente o âmbito da recolha.

O XML não confiável acrescenta outro limite. A expansão de entidades, o acesso a recursos externos e o comportamento de tokens de grande dimensão dependem do analisador e da sua configuração. A documentação de segurança do XML em Python resume os riscos e destaca a importância da versão do analisador subjacente. Não presuma que todas as bibliotecas XML partilham as mesmas predefinições.

Utilize defesas de analisador atuais e adequadas, juntamente com limites de tamanho e de execução. Rejeite características de documentos não suportadas, em vez de ativar a resolução de entidades externas para permitir a análise de um ficheiro. Classifique um mapa do site malformado como uma falha de descoberta, com um diagnóstico sanitizado que ajude o proprietário da fonte a investigar.

Estes controlos são complementares. A análise sensível ao espaço de nomes evita confusões estruturais; a política de URLs controla os destinos; a aplicação de regras de rede verifica a ligação; e os limites de recursos restringem o trabalho. Nenhum deles pode substituir com segurança todos os outros.

No final da percussão, relate o que foi inspecionado e por que razão o trabalho foi interrompido. Inclua contagens de documentos, páginas candidatas aceites, duplicados, destinos rejeitados, falhas de análise e interrupções por limite de orçamento. Uma contagem elevada de URLs, por si só, não demonstra uma descoberta completa ou correta.

Compare as URLs aceites com o seu esquema de destino. Páginas de produto, categoria, pesquisa e editoriais podem coexistir num único conjunto de mapas do site. Defina uma regra de encaminhamento para cada tipo relevante e mantenha os tipos não relacionados fora da fila de extração, em vez de permitir que os seus campos em falta contaminem as métricas de validação de registos.

Os sitemaps de web scraping resolvem a descoberta de endereços, não a renderização de páginas. Se as páginas selecionadas exibirem dados apenas após a execução no navegador, o guia de screen scraping explica como escolher uma condição de prontidão e extrair campos renderizados. Não presuma que um sitemap garante conteúdo HTML estático.

Preserve a proveniência ao longo desse processo de transferência. Um registo de página deve reter o URL descoberto, a fonte do mapa do site, a hora da observação e a versão de extração, quando relevante. Os endereços redirecionados ou canonicizados necessitam de uma política de identidade explícita, em vez de uma substituição não documentada.

O guia do fluxo de trabalho de recolha automatizada liga a descoberta ao processamento duradouro, às tentativas de repetição e à entrega. Mantenha essas etapas observáveis para que uma falha na recuperação não faça com que o analisador do mapa do site pareça ter devolvido menos entradas.

Antes de escalar, teste uma referência a um documento duplicado, um URL rejeitado, um ficheiro XML malformado e um orçamento esgotado. O resultado útil não é apenas que o script pare. Deve parar com uma classificação que explique que parte do âmbito de descoberta pretendido permanece por resolver.

• Utilize mapas do site obtidos por web scraping para criar uma fila de candidatos e, em seguida, valide os destinos e extraia os registos das páginas em etapas separadas.
• Analise a raiz e o espaço de nomes de forma deliberada, para que as referências do mapa do site, as localizações das páginas e os dados de extensão não se misturem.
• Aplique verificações de tamanho sensíveis ao protocolo, a par de orçamentos operacionais mais rigorosos, incluindo bytes descomprimidos e trabalho total de percurso.
• Preserve lastmod como metadados do editor; distinga-os do tempo de descoberta, do tempo de observação e dos validadores HTTP.
• Mantenha a admissão de URLs, os controlos de destino de rede, as defesas XML e os relatórios de integridade testáveis de forma independente.

Sim. O protocolo permite mais do que um índice de mapa do site. No caso de mapas do site obtidos por web scraping, identifique ou receba o conjunto aprovado, em vez de partir do princípio de que a localização de um único índice identifica todos os mapas do site. Mantenha a proveniência de cada documento inicial e defina se os respetivos resultados são combinados num único âmbito de recolha ou comunicados separadamente.

Não automaticamente. Os parâmetros de consulta podem identificar o idioma, o conteúdo ou outra variante significativa. Remova-os apenas ao abrigo de uma regra de identidade verificada para essa fonte. Preserve o URL descoberto para que seja possível uma correção posterior e verifique se qualquer normalização não agrupa registos distintos nem altera a representação recuperada.

Não. Um endereço listado é um sinal de descoberta, não uma prova de que um motor de busca possa ou venha a indexá-la. Aplicam-se ainda outras condições relativas à página e ao acesso. Para a recolha de dados, verifique a resposta efetiva e o conteúdo necessário, em vez de interpretar a presença no mapa do site como uma garantia de disponibilidade ou adequação.

A extração de mapas do site funciona melhor quando a descoberta permanece uma fase distinta e mensurável. Classifique o documento, analise o namespace correto, mantenha os metadados da fonte e aceite apenas alvos que se enquadrem na política de recolha. Em seguida, relate tanto os candidatos descobertos como as razões pelas quais partes da percussão permaneceram incompletas.

Comece com a configuração local e alargue um limite de cada vez. Adicione a recuperação delimitada antes de ficheiros de grande dimensão, a imposição do destino antes de referências externas e o progresso sustentável antes de uma percorreção de longa duração. Mantenha os casos de teste que mostram uma falha clara quando esses limites são ultrapassados.

Quando a fila de páginas aprovadas estiver pronta, avalie a API Scraper da WebScrapingAPI para a fase de recuperação. Mantenha a sua própria proveniência de descoberta e registe as verificações, para que o conjunto de dados resultante explique tanto a origem dos seus URLs como o que foi efetivamente observado.