Web-Scraping von Sitemaps: URLs mit sicheren Grenzwerten ermitteln

Beginnen Sie mit dem Erfassungsziel. Wenn Sie Produktdetails benötigen, ist eine Liste von Seiten-URLs ein Zwischenergebnis. Sie müssen noch ermitteln, welche Adressen Produkte darstellen, die entsprechenden Seiten abrufen, Felder extrahieren und die resultierenden Datensätze validieren.

Eine Sitemap kann von der Website selbst deklariert oder direkt von ihrem Betreiber bereitgestellt werden. Ein herkömmlicher Dateiname ist ein nützlicher Anhaltspunkt, jedoch keine Garantie dafür, dass jede Website ihn verwendet. Behandeln Sie die Ermittlung der Sitemap-Adresse und die Berechtigung zur Erfassung ihres Inhalts als separate Fragestellungen.

Beim Web-Scraping von Sitemaps sollten Sie eine Warteschlange mit Kandidaten führen, anstatt jeden Speicherort sofort abzurufen. Speichern Sie, wo jede URL entdeckt wurde und welche Regel sie in die Seitenwarteschlange aufgenommen hat. Dies erleichtert später die Untersuchung eines umfangreichen Index oder eines unerwarteten Dokuments.

Verwechseln Sie die Veröffentlichungsabsicht nicht mit Vollständigkeit. Eine Website kann Seiten auslassen, veraltete Einträge veröffentlichen oder mehrere Sitemap-Sammlungen für unterschiedliche Inhalte pflegen. Ihr Erkennungsbericht sollte beschreiben, was die untersuchten Dokumente enthielten, und nicht behaupten, dass keine weiteren Seiten existieren.

Unterscheiden Sie außerdem einen fehlgeschlagenen Abruf von einer entfernten Seite. Ein vorübergehender Gateway-Fehler während der Erfassung sagt nichts Endgültiges darüber aus, ob der aufgeführte Inhalt noch existiert. Der Leitfaden zur Diagnose des Proxy-Status erklärt, warum Antwortkategorien Belege benötigen, bevor sie zu Schlussfolgerungen über die Quelle führen.

Halten Sie den anfänglichen Umfang klein genug, um ihn manuell zu prüfen. Eine einzige genehmigte Sitemap und einige repräsentative Seitentypen können Aufschluss darüber geben, ob diese Erkundungsmethode für die Aufgabe geeignet ist, bevor eine umfassende Durchsuchung Unstimmigkeiten verschleiert.

Die XML-Stammebene gibt Auskunft darüber, was das Dokument enthält. Ein urlset enthält Seiteneinträge; ein sitemapindex enthält Einträge, die auf Sitemap-Dokumente verweisen. Beide verwenden den Sitemaps-Namespace, und ihre erforderlichen loc Elemente unterschiedliche Aufgaben. Das Sitemaps-Protokoll definiert diese Strukturen.

XML-Namensräume spielen auch dann eine Rolle, wenn das sichtbare Tag einfach aussieht. Bei einem Standard-Namensraum identifiziert ein XML-Parser das Element anhand der Kombination aus Namensraum-URI und lokalem Namen. Bei der Suche nach bloßen url Elemente kann daher bei einer ansonsten gültigen Sitemap zu keinem Ergebnis führen.

Wählen Sie beim Web-Scraping von Sitemaps den spezifischen Strukturpfad aus, den Sie benötigen. Eine umfassende Suche nach jedem Element mit dem Namen loc kann Seitenpfade mit Sitemap-Verweisen oder Erweiterungs-Metadaten vermischen. Unterscheiden Sie den Hauptnamensraum von Bild-, Video-, Nachrichten- oder anderen Erweiterungen, anstatt jeden Namensraum wahllos zu entfernen.

Überlassen Sie die Entity-Escaping-Verarbeitung dem XML-Parser. Eine URL, die ein Abfragetrennzeichen enthält, kann & in XML und führt zu & im geparsten Text. Ersetzen Sie vor dem Parsen keine beliebigen Zeichenfolgen und dekodieren Sie URLs nicht wiederholt, bis sie Ihnen passend erscheinen.

Behalten Sie die ursprünglich ermittelte Adresse neben jeder von Ihnen angewandten Normalisierung bei. Die Normalisierung sollte bekannte Identitätsregeln umsetzen und nicht davon ausgehen, dass unterschiedliche Pfade oder Abfragezeichenfolgen gleichwertig sind. Eine URL-Liste wird erst dann zu einer nützlichen Eingabe, wenn ihre Interpretation im Einklang mit dem Quellvertrag und Ihrem Erfassungsbereich bleibt.

Speichern Sie diese Übung als sitemap_fixture.py und führen Sie sie mit Python 3 aus. Sie nutzt ausschließlich die Standardbibliothek, parst feste Unicode-Zeichenketten im Arbeitsspeicher und führt keine Netzwerkabfragen durch. Die Fixture klassifiziert einen Index und eine URL-Menge und überprüft anschließend, ob ein nicht zugehöriger Host abgelehnt wird.

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

Das Fixture lässt bewusst eine einzige exakte HTTPS-Autorität zu. Es folgt keinen Weiterleitungen, löst keine DNS-Einträge auf, dekomprimiert keine Daten und behauptet nicht, dass URL-Prüfungen auf Zeichenfolgenebene serverseitige Request-Forgery verhindern. Diese Kontrollen gehören in eine Produktions-Abrufschicht.

Die Deklarationsprüfung beschränkt sich zudem auf die bereits dekodierten Zeichenfolgen des Fixtures. Es handelt sich nicht um eine allgemeine XML-Firewall für beliebige Remote-Kodierungen. Verwenden Sie für nicht vertrauenswürdige Eingaben einen entsprechend konfigurierten Parser und Abrufbeschränkungen, anstatt diese Prüfung als vollständige Abwehrmaßnahme zu übernehmen.

Beachten Sie, dass lastmod als rohe Quellmetadaten beibehalten wird. Die Übung wandelt dies nicht in einen Nachweis dafür um, dass sich die Seite geändert hat, oder in einen Planungsbefehl. Die zweite Seite weist keinen Änderungswert auf, der sich von einem bekannten alten Zeitstempel unterscheidet.

Dieser kleine Test deckt die Interpretationsgrenzen beim Web-Scraping von Sitemaps ab: Stammklassifizierung, namensraumbewusste Pfade, Entitätsdekodierung, ein zulässiger Host und abgelehnte, fehlerhafte Strukturen. Behalten Sie diese Tests bei, wenn Sie den Transport hinzufügen, und fügen Sie dann separate Tests für die Weiterleitungs-, Größen- und Zielregeln des Transports hinzu.

Verwenden Sie separate Warteschlangen für Sitemap-Dokumente und Seitenkandidaten. Starten Sie die Dokumentenwarteschlange mit dem genehmigten Index, rufen Sie ein begrenztes Dokument ab und klassifizieren Sie es; platzieren Sie anschließend dessen untergeordnete Sitemap- oder Seitenorte am entsprechenden Zielort. Fügen Sie eine Seite nicht einfach deshalb als weitere Sitemap in die Warteschlange ein, weil beide URLs enthalten.

Verwalten Sie eine Liste der bereits besuchten Orte für Dokumentstandorte, damit wiederholte Verweise nicht zu endlosem Doppelarbeit führen. Wenn ein Anbieter unerwartete Indexverschachtelungen veröffentlicht, legen Sie fest, ob Ihr Collector diese ablehnt oder eine begrenzte Durchquerung unterstützt. Gehen Sie nicht davon aus, dass beliebige Verschachtelungen eine Garantie für die Portabilität des Protokolls sind.

Protokollgrenzen und Betriebsbudgets unterscheiden sich. Eine Standard-Sitemap erlaubt höchstens 50.000 URLs und 50 MB, genauer gesagt 52.428.800 Byte, im unkomprimierten Zustand. Sitemap-Indizes unterliegen zudem Eintrags- und Größenbeschränkungen. Die Komprimierung reduziert die Übertragungsgröße, ohne die Grenze für unkomprimierte Daten aufzuheben. Ihr Auftrag erfordert möglicherweise niedrigere Grenzwerte, um den Anforderungen an Speicher, Zeit und genehmigten Umfang gerecht zu werden.

Bei Web-Scraping-Sitemaps in großem Maßstab sollten Sie die übertragenen Bytes, die dekomprimierten Bytes, die Dokumente, die Einträge, die verstrichene Zeit und gegebenenfalls die Durchsuchungstiefe begrenzen. Eine kleine komprimierte Antwort kann nach der Dekomprimierung immer noch einen großen Datensatz ergeben. Setzen Sie die Grenzen bereits beim Einlesen und Dekomprimieren durch, nicht erst nach der Zuweisung des vollständig dekomprimierten Dokuments.

Protokollieren Sie abgelehnte und übersprungene Verweise. „Bereits besucht“ unterscheidet sich von „Host nicht zulässig“, „Dokument zu groß“ oder „XML konnte nicht geparst werden“. Diese Kategorien erklären, warum die Anzahl der gefundenen Seiten von der Anzahl der ursprünglich angetroffenen Einträge abweicht.

Führen Sie einen Checkpoint durch, nachdem eine dauerhafte Ausgabe aufgezeichnet wurde. Wenn die Suchergebnisse getrennt vom Durchsuchungsstatus gespeichert werden, sollten Sie das Neustartverhalten so gestalten, dass ein Dokument sicher wiedergegeben werden kann. Die Deduplizierung sollte doppelte Warteschlangeneinträge verhindern, ohne dabei Änderungen an Metadaten zu verbergen, die für den Auftrag von Bedeutung sind.

Speichern Sie schließlich die Abrufzeit des Dokuments und den endgültigen genehmigten Speicherort. Andernfalls kann eine Weiterleitung oder ein geändertes Dokument dazu führen, dass zwei Durchläufe identisch erscheinen, obwohl sie tatsächlich unterschiedliche Eingaben geprüft haben.

Das Feld auf Seitenebene lastmod stellt die vom Herausgeber angegebene letzte Änderung dieser Seite dar. Es soll nicht den Zeitpunkt bezeichnen, zu dem der Sitemap-Generator ausgeführt wurde. Ein Änderungswert auf Indexebene bezieht sich stattdessen auf das Sitemap-Dokument. Eine Vermischung dieser Bedeutungen kann unnötige Seitenaktualisierungen auslösen oder dazu führen, dass relevante Seiten übersprungen werden.

Behalten Sie bei Sitemaps für das Web-Scraping den Rohwert bei und werten Sie ihn nur gemäß einer expliziten Datumsrichtlinie aus. Ein Datum ohne Uhrzeit ist weniger präzise als ein Zeitstempel. Ein fehlender oder fehlerhafter Wert sollte als unbekannt bleiben und nicht in das heutige Datum oder einen Standardwert umgewandelt werden, der Gewissheit impliziert.

Behandeln Sie den Wert als Hinweis auf die Priorität, bis die Quelle eine für Ihre Aufgabe nützliche Genauigkeit unter Beweis gestellt hat. Vergleichen Sie eine Stichprobe der angekündigten Änderungen mit tatsächlichen Seitenbeobachtungen. Ein vertrauenswürdiger Zeitstempel für redaktionelle Inhalte kann für sich häufig ändernde Aktienkurse immer noch zu ungenau sein.

In den Sitemap-Richtlinien von Google wird die Verwendung genauer lastmod Werte und besagt, dass priority und changefreq. Dies beschreibt das Verhalten von Google, stellt jedoch keine Anforderung dar, dass Ihr Collector dessen Zeitplanungsrichtlinie übernehmen muss. Machen Sie aus optionalen Metadaten des Herausgebers keine universelle Abrufanweisung.

Die HTTP-Validierung ist wiederum ein separates Thema. Der Entity-Tag oder der „Last-Modified“-Antwortheader eines Servers können gemäß den HTTP-Regeln bei der bedingten Abfrage eine Rolle spielen. Ein Sitemap-Datum ersetzt diese Validatoren nicht und garantiert auch keine 304 Antwort. RFC 9111 definiert die Cache-Aktualität und das Validierungsverhalten.

Behalten Sie für den Erfassungsbericht die Metadaten zur Quelländerung, den Zeitpunkt der Erkennung und den Zeitpunkt der Seitenbeobachtung separat bei. Sie geben Auskunft darüber, wann der Herausgeber eine Änderung meldet, wann Sie die Adresse gefunden haben und wann Sie die tatsächliche Darstellung beobachtet haben.

Nutzen Sie diese Unterscheidung bei der Planung. Die Priorisierung kürzlich bekannt gegebener Änderungen kann die Arbeitsreihenfolge verbessern, während eine regelmäßige Abgleichung fehlende oder unzuverlässige Datumsangaben abdeckt. Dokumentieren Sie diese Richtlinie, damit Nutzer verstehen, was „kürzlich aktualisiert“ wirklich bedeutet.

Das Parsen von XML und URLs berechtigt nicht dazu, eine Netzwerkanfrage zu stellen. Ein Ort kann außerhalb der zugelassenen Website liegen, Anmeldedaten enthalten, ein unerwartetes Schema verwenden oder eine Adresse erreichen, auf die vom Collector aus kein Zugriff erlaubt sein sollte. Behandeln Sie jeden entdeckten Ort als nicht vertrauenswürdige Eingabe für eine separate Zulassungsprüfung.

Die Python-Dokumentation zur URL-Analyse warnt ausdrücklich davor, dass Analysefunktionen Eingaben nicht validieren. Eine erfolgreiche Aufteilung in Schema und Hostname ist daher keine Sicherheitsentscheidung. Wenden Sie eine explizite Richtlinie für Schemata, Hosts, Ports, Benutzerinformationen und den Geltungsbereich an.

Serverseitige Request-Forgery wird relevant, wenn ein automatisierter Dienst Ziele abruft, die durch externe Eingaben beeinflusst werden. Halten Sie Zielkontrollen an der tatsächlichen Netzwerkgrenze aufrecht, einschließlich Weiterleitungen und aufgelöster Adressen. Eine Whitelist für Hostnamen allein deckt nicht jedes DNS- oder Weiterleitungsszenario ab, und die Validierung eines Hops autorisiert nicht den nächsten.

Vermeiden Sie beim Web-Scraping von Sitemaps die Weitergabe von Anmeldedaten aus der ursprünglichen Anfrage an einen neu entdeckten Host. Einige Anbieter nutzen unterstützte Cross-Site-Hosting-Vereinbarungen, doch Ihr Collector sollte nur solche Vereinbarungen zulassen, die er ausdrücklich genehmigt hat. Ein externer Verweis ist keine Anweisung, den Erfassungsumfang automatisch zu erweitern.

Nicht vertrauenswürdiges XML stellt eine weitere Grenze dar. Die Entitätsauflösung, der Zugriff auf externe Ressourcen und das Verhalten bei großen Tokens hängen vom Parser und dessen Konfiguration ab. Die Python-XML-Sicherheitsdokumentation fasst die Risiken zusammen und weist auf die Bedeutung der zugrunde liegenden Parser-Version hin. Gehen Sie nicht davon aus, dass alle XML-Bibliotheken dieselben Standardeinstellungen verwenden.

Verwenden Sie aktuelle, geeignete Parser-Schutzmaßnahmen in Verbindung mit Größen- und Ausführungsbudgets. Lehnen Sie nicht unterstützte Dokumentmerkmale ab, anstatt die Auflösung externer Entitäten zu aktivieren, um das Parsen einer Datei zu ermöglichen. Stufen Sie eine fehlerhafte Sitemap als Erkennungsfehler ein und fügen Sie eine bereinigte Diagnose hinzu, die dem Eigentümer der Quelle bei der Untersuchung hilft.

Diese Kontrollmaßnahmen ergänzen sich. Namespace-bewusstes Parsen verhindert strukturelle Verwechslungen; URL-Richtlinien steuern die Ziele; Netzwerküberwachung prüft die Verbindung; und Ressourcenbudgets schränken den Arbeitsaufwand ein. Keine dieser Maßnahmen kann die anderen sicher ersetzen.

Berichten Sie am Ende der Durchquerung, was überprüft wurde und warum der Vorgang abgebrochen wurde. Geben Sie dabei die Anzahl der Dokumente, akzeptierte Seitenkandidaten, Duplikate, abgelehnte Ziele, Parsing-Fehler und Budget-Abbrüche an. Eine hohe URL-Anzahl allein ist kein Beweis für eine vollständige oder korrekte Erfassung.

Prüfen Sie die zugelassenen URLs anhand Ihres Zielschemas. Produkt-, Kategorie-, Such- und redaktionelle Seiten können in einem Sitemap-Satz nebeneinander existieren. Definieren Sie für jeden relevanten Typ eine Routing-Regel und halten Sie nicht relevante Typen aus der Extraktionswarteschlange fern, anstatt zuzulassen, dass ihre fehlenden Felder die Metriken zur Datensatzvalidierung verfälschen.

Das Web-Scraping von Sitemaps löst das Problem der Adresserfassung, nicht das der Seitenwiedergabe. Wenn die ausgewählten Seiten Daten erst nach der Ausführung im Browser offenlegen, erklärt der Leitfaden zum Screen-Scraping, wie man eine Bereitschaftsbedingung wählt und gerenderte Felder extrahiert. Gehen Sie nicht davon aus, dass eine Sitemap statischen HTML-Inhalt garantiert.

Bewahren Sie die Herkunftsinformationen bei dieser Übergabe. Ein Seitendatensatz sollte die ermittelte URL, die Sitemap-Quelle, den Beobachtungszeitpunkt und gegebenenfalls die Extraktionsversion enthalten. Umgeleitete oder kanonisierte Adressen erfordern eine explizite Identitätsrichtlinie und keinen undokumentierten Ersatz.

Der Leitfaden zum automatisierten Erfassungsworkflow verbindet die Erkennung mit dauerhafter Verarbeitung, Wiederholungsversuchen und Bereitstellung. Halten Sie diese Phasen beobachtbar, damit ein Abrufausfall nicht den Anschein erweckt, der Sitemap-Parser habe weniger Einträge zurückgegeben.

Testen Sie vor der Skalierung einen Fall mit doppelter Dokumentreferenz, eine abgelehnte URL, eine fehlerhafte XML-Datei und ein erschöpftes Budget. Das nützliche Ergebnis ist nicht nur, dass das Skript stoppt. Es sollte mit einer Klassifizierung stoppen, die erklärt, welcher Teil des beabsichtigten Erfassungsumfangs ungelöst bleibt.

• Verwenden Sie durch Web-Scraping gewonnene Sitemaps, um eine Kandidatenwarteschlange aufzubauen, und validieren Sie anschließend die Ziele sowie extrahieren Sie Seitendatensätze in separaten Phasen.
• Analysieren Sie die Root-Ebene und den Namensraum gezielt, damit Sitemap-Verweise, Seitenpfade und Erweiterungsdaten nicht vermischt werden.
• Setzen Sie protokollspezifische Größenprüfungen neben strengeren operativen Budgets durch, einschließlich dekomprimierter Bytes und des gesamten Durchlaufaufwands.
• Behalten Sie lastmod als Metadaten des Herausgebers; unterscheiden Sie diese von Erkennungszeitpunkt, Beobachtungszeitpunkt und HTTP-Validatoren.
• Stellen Sie sicher, dass URL-Zulassung, Netzwerkzielkontrollen, XML-Schutzmaßnahmen und Vollständigkeitsberichte unabhängig voneinander testbar sind.

Ja. Das Protokoll erlaubt mehr als einen Sitemap-Index. Bei Sitemaps für das Web-Scraping sollten Sie den genehmigten Satz ermitteln oder empfangen, anstatt davon auszugehen, dass das Auffinden eines einzigen Indexes alle Sitemaps identifiziert. Behalten Sie die Herkunftsangaben für jedes Ausgangsdokument bei und legen Sie fest, ob deren Ergebnisse in einem Sammlungsumfang zusammengefasst oder separat gemeldet werden.

Nicht automatisch. Abfrageparameter können Sprache, Inhalt oder andere aussagekräftige Varianten identifizieren. Entfernen Sie sie nur, wenn für diese Quelle eine verifizierte Identitätsregel vorliegt. Behalten Sie die ermittelte URL bei, damit eine spätere Korrektur möglich bleibt, und prüfen Sie, dass eine eventuelle Normalisierung keine unterschiedlichen Datensätze zusammenfasst oder die abgerufene Darstellung verändert.

Nein. Eine aufgeführte Adresse ist ein Erkennungsmerkmal, kein Beweis dafür, dass eine Suchmaschine sie indexieren kann oder wird. Es gelten weiterhin andere Seiten- und Zugriffsbedingungen. Überprüfen Sie bei der Datenerfassung die tatsächliche Antwort und den erforderlichen Inhalt, anstatt das Vorhandensein in der Sitemap als Garantie für Verfügbarkeit oder Eignung zu interpretieren.

Das Web-Scraping von Sitemaps funktioniert am besten, wenn die Erkennung eine eigenständige, messbare Phase bleibt. Klassifizieren Sie das Dokument, analysieren Sie den richtigen Namensraum, behalten Sie die Metadaten der Quelle bei und lassen Sie nur Ziele zu, die der Erfassungsrichtlinie entsprechen. Berichten Sie anschließend sowohl über die gefundenen Kandidaten als auch über die Gründe, warum Teile der Durchquerung unvollständig blieben.

Beginnen Sie mit der lokalen Testumgebung und erweitern Sie die Grenzen schrittweise. Fügen Sie eine begrenzte Datenabfrage vor großen Dateien, eine Zielüberprüfung vor externen Verweisen und einen dauerhaften Fortschrittsbericht vor einer lang andauernden Durchquerung hinzu. Behalten Sie die Testfälle bei, die einen eindeutigen Fehler anzeigen, wenn diese Grenzen überschritten werden.

Sobald die genehmigte Seitenwarteschlange bereit ist, prüfen Sie die Scraper-API der WebScrapingAPI für die Abrufphase. Behalten Sie Ihre eigene Herkunftsnachverfolgung und Protokollierungsprüfungen bei, damit der resultierende Datensatz sowohl Aufschluss darüber gibt, woher die URLs stammen, als auch darüber, was tatsächlich beobachtet wurde.