Unser Standpunkt: Wir sind Geonode und verkaufen Proxys, die als Input für das Crawling dienen und nicht für die Listenverwaltung. Ehrlich gesagt kostet eine schlecht verwaltete Crawling-Liste weitaus mehr als ein schlecht ausgewählter Proxy-Tarif. Ein Crawler ohne URL-Normalisierung ruft dieselbe Seite Dutzende Male mit unterschiedlicher Reihenfolge der Abfrageparameter auf, und bei einer Abrechnung pro Gigabyte zahlen Sie für jeden einzelnen Aufruf. Ein Crawler ohne Budget läuft unendlich lange weiter und stellt Ihnen dies in Rechnung. Die Korrektur der Liste ist kostenlos; die Korrektur nach Erhalt der Rechnung ist es nicht. Dieser Abschnitt folgt weiter unten und ist es wert, als Erstes gelesen zu werden.
Was eine Crawl-Liste eigentlich ist
Drei Dinge, die oft miteinander verwechselt werden.
Die Startliste – der Ausgangspunkt. Eine Handvoll URLs oder eine vollständige Sitemap.
Die „Frontier“ – URLs, die entdeckt und in die Warteschlange gestellt, aber noch nicht abgerufen wurden. Dies ist die aktive Datenstruktur, in der alle Entwurfsentscheidungen zum Tragen kommen.
Die „Visited Set“ – URLs, die bereits abgerufen wurden und gespeichert werden, damit sie nicht erneut abgerufen werden.
Der Lebenszyklus ist eine Schleife: Man nimmt eine URL aus der „Frontier“, ruft sie ab, extrahiert Links, normalisiert diese, verwirft diejenigen, die bereits in der „Visited Set“ oder in der Warteschlange stehen, fügt den Rest zur „Frontier“ hinzu und markiert die URL als besucht. Dies wird wiederholt, bis die „Frontier“ leer ist oder das Budget aufgebraucht ist.
Im Grundzug einfach. Jeder Schritt birgt jedoch eine Feinheit, die dich einen Tag kosten kann, wenn du sie falsch machst.
Seeding: Woher die ersten URLs stammen
Geordnet nach dem jeweiligen Arbeitsaufwand.
Die Sitemap. Die beste verfügbare Quelle, da es sich um das eigene Verzeichnis der Website handelt und sie Zeitstempel im Format „lastmod“ enthält, die angeben, was sich geändert hat. Sie finden sie über die Anweisung „Sitemap:“ in der Datei „robots.txt“ und können die Sitemap-Indexdateien rekursiv verfolgen.
Ein Partner-Feed oder eine API. Falls es einen gibt, benötigen Sie möglicherweise gar kein Crawling.
Webarchive. Die CDX-API des Internet Archive liefert historische URLs für eine Domain, einschließlich Seiten, auf die von nirgendwo mehr verlinkt wird. Das kostet die Zielseite nichts und findet „verwaiste“ Seiten, die beim Crawling übersehen werden.
Suchoperatoren. Abfragen wie „site:“ bringen indexierte Seiten ans Licht und – was noch nützlicher ist – Subdomains, von denen Sie nichts wussten.
Kategorie- und Indexseiten. Für ein gezieltes Crawling ist es weitaus effizienter, von den spezifischen Listenseiten auszugehen, die für Sie von Interesse sind, als auf der Startseite zu beginnen und auf das Beste zu hoffen.
Die Startseite. Der letzte Ausweg und die Standardmethode, auf die die meisten zuerst zurückgreifen. Von einer einzigen URL auszugehen und alles durch Link-Traversierung zu entdecken, ist der langsamste Weg zu einer schlechten Abdeckung.
Wir haben die gesamte Quellhierarchie in „So finden Sie alle Seiten einer Website“ durchgesehen. Die Kurzfassung: Eine gute Startliste verwandelt ein Crawling in ein Abrufen.
URL-Normalisierung: Der Schritt, den jeder überspringt
Der wichtigste technische Aspekt eines Crawlers – und derjenige, der am häufigsten ausgelassen wird.
Ohne ihn sind dies fünf verschiedene URLs für Ihren besuchten Datensatz und eine Seite für den Server:
http://Example.com/Products
http://example.com/products
http://example.com/products/
http://example.com:80/products
http://example.com/products?utm_source=email
RFC 3986 definiert die Normalisierungen, die stets sicher sind.
Groß-/Kleinschreibungsnormalisierung. „Das Schema und der Host sind unabhängig von der Groß-/Kleinschreibung und sollten daher in Kleinbuchstaben normalisiert werden. Beispielsweise entspricht die URI <HTTP://www.EXAMPLE.com/>
der URI <http://www.example.com/>."
. Beachten Sie die Einschränkung: „Bei den anderen generischen Syntaxkomponenten wird davon ausgegangen, dass sie zwischen Groß- und Kleinschreibung unterscheiden, sofern dies nicht ausdrücklich durch das Schema anders definiert ist.“ Pfade unterscheiden zwischen Groß- und Kleinschreibung – wandeln Sie sie nicht in Kleinbuchstaben um.
Außerdem: „Die hexadezimalen Ziffern innerhalb eines Prozent-Kodierungs-Tripletts (z. B. %3a
im Vergleich zu %3A
) unterscheiden nicht zwischen Groß- und Kleinschreibung und sollten daher so normalisiert werden, dass Großbuchstaben verwendet werden.“
Normalisierung der Prozent-Kodierung. Der RFC bezeichnet dies als „eine häufige Ursache für Abweichungen zwischen ansonsten identischen URIs“, da „einige URI-Ersteller Oktette prozentkodieren, die keine Prozentkodierung erfordern“. Diese „sollten normalisiert werden, indem jedes prozentkodierte Oktett, das einem nicht reservierten Zeichen entspricht, dekodiert wird“.
Normalisierung von Pfadsegmenten. Entfernen Sie Segmente wie „.
“ und „..
“ durch Anwendung des Algorithmus „remove_dot_segments
“, da „einige eingesetzte Implementierungen fälschlicherweise davon ausgehen, dass eine Referenzauflösung nicht erforderlich ist, wenn die Referenz bereits eine URI ist“.
Schema-basierte Normalisierung. Der RFC nennt das kanonische Beispiel – diese vier sind äquivalent:
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
Ein leerer Pfad „sollte also zu einem Pfad von /
normalisiert werden“, und ein Standard- oder leerer Port „sollte durch schemabasierte Normalisierung entfernt werden“.
Über die Spezifikation hinaus sind drei Normalisierungen eher pragmatisch als streng sicher und sollten mit Bedacht angewendet werden:
Tracking-Parameter entfernen. utm_*
, fbclid
, gclid
, Sitzungskennungen. Diese verändern den Inhalt so gut wie nie und vermehren die Anzahl Ihrer URLs enorm. Führen Sie lieber eine Liste, anstatt zu raten.
Sortieren Sie die verbleibenden Abfrageparameter. ?a=1&b=2
und ?b=2&a=1
verweisen in der Regel auf dieselbe Seite. In der Regel – manche Anwendungen sind reihenfolgeabhängig, testen Sie daher anhand einer Stichprobe.
Entfernen Sie Fragmente. #section
ist clientseitig und erreicht den Server nie. Für Crawling-Zwecke können Sie diese immer getrost weglassen.
**Und beachten Sie rel="canonical"
.** Wenn eine Seite eine kanonische URL angibt, teilt Ihnen die Website damit mit, welche der verschiedenen Adressen die echte ist. Diese zu berücksichtigen, bedeutet kostenlose Deduplizierung, gestützt durch die Autorität der Website selbst.
Die Grenze: Warteschlangen-Design
Drei Eigenschaften entscheiden darüber, ob Ihr Crawler skalierbar ist.
Die Dublettenerkennung muss kostengünstig sein. Bevor Sie eine URL hinzufügen, prüfen Sie, ob diese bereits bekannt ist. Bei einer Million URLs ist ein linearer Scan unbrauchbar. Ein Hash-Set funktioniert bis zu einem gewissen Grad; darüber hinaus bietet ein Bloom-Filter eine Zugehörigkeitsprüfung in konstanter Zeit bei einem Bruchteil des Speicherbedarfs und einer geringen Falsch-Positiv-Rate – was bedeutet, dass Sie gelegentlich eine URL überspringen, die Sie noch nicht gesehen haben. Für die meisten Crawls ist dieser Kompromiss in Ordnung; wo Vollständigkeit zählt, sollten Sie den Filter durch einen exakten Speicher ergänzen.
Die Reihenfolge muss steuerbar sein. Eine einfache FIFO-Warteschlange sorgt für eine Breitensuche, was in der Regel gewünscht ist – sie erreicht frühzeitig eine breite Abdeckung und bleibt flach. Ein LIFO-Stack sorgt für eine Tiefensuche, die tief in einen Zweig vordringt und für das Crawlen einer Website selten nützlich ist. Eine Prioritätswarteschlange ermöglicht es Ihnen, nach beliebigen Kriterien zu ordnen; darauf wird im Folgenden eingegangen.
Der Status pro Host muss verfolgt werden. In der Praxis besteht die „Frontier“ nicht aus einer einzigen Warteschlange, sondern aus einer Warteschlange pro Host, sodass die Höflichkeitsgrenzen für jeden Host unabhängig voneinander gelten. Eine einzige globale Warteschlange mit einer globalen Ratenbegrenzung führt dazu, dass eine große Website alle anderen aushungert.
Die skalierbare Struktur besteht aus einer Reihe von Host-spezifischen Warteschlangen sowie einem Scheduler, der den nächsten Host auswählt, von dem Daten abgerufen werden können – wobei „zugelassen“ bedeutet, dass seit der letzten Anfrage an diesen Host genügend Zeit verstrichen ist.
Priorisierung
Welche URL soll als Nächstes abgerufen werden, wenn nicht alle abgerufen werden können?
Nach Tiefe. Seiten, die in der Baumstruktur weiter oben liegen, sind in der Regel wichtiger. Eine einfache und effektive Standardeinstellung.
Nach Pfadmuster. Wenn Sie Produktseiten möchten, priorisieren Sie URLs, die dem Muster /product/ entsprechen. Dies ist die Heuristik mit dem höchsten Ertrag für gezielte Crawls und zudem äußerst kostengünstig.
Nach „lastmod“. Aus der Sitemap. Rufen Sie die geänderten Seiten ab.
Nach Änderungshistorie. Bei wiederkehrenden Crawls werden Seiten, die sich zuvor häufig geändert haben, auch weiterhin häufig geändert.
Nach Anzahl der eingehenden Links. Seiten, auf die von vielen Stellen aus verlinkt wird, sind in der Regel bedeutender. Die Berechnung ist während eines Crawls aufwendig, lohnt sich aber bei großen Aufträgen.
Nach geschätztem Wert. Was auch immer Ihr tatsächliches Ziel ist. Wenn Sie Preise suchen, priorisieren Sie Seiten, die diese wahrscheinlich enthalten.
In der Praxis wird zum Zeitpunkt der Einreihung aus einigen dieser Signale eine kleine ganzzahlige Punktzahl berechnet, die als Schlüssel in einer Prioritätswarteschlange dient. Aufwändige Verfahren rechtfertigen selten ihre Komplexität; die Tiefe plus ein Bonus für Pfadmuster deckt die meisten Anforderungen ab.
Begrenzung: Budgets und Fallstricke
Ohne Begrenzung laufen manche Crawls unendlich lange. Das ist kein Randfall.
Maximale Tiefe. Links von Links von Links. Eine Tiefenbegrenzung von fünf oder sechs deckt fast jede reale Website-Struktur ab.
Maximale Seiten pro Host. Eine feste Zahl. Wenn diese erreicht ist, sollte der Crawl beendet und ein Bericht erstellt werden, anstatt fortzufahren.
Maximale Gesamtseitenzahl. Für den gesamten Auftrag.
Maximale Bandbreite. Insbesondere bei proxybasiertem Datenverkehr mit Datenvolumenbegrenzung, wo ein unbegrenzter Crawl eine unbegrenzte Rechnung bedeutet.
Musterausschluss. Kalender sind der klassische unendliche Raum – ein Link vom Typ „next month
“ generiert unendlich viele URLs. Facettierte Navigation in einem großen Katalog führt zu einer kombinatorischen Explosion. Schließen Sie diese anhand folgender Muster aus:
/calendar/
/?filter=
/*?sort=
Erkennung doppelter Inhalte. Erstellen Sie einen Hash des Hauptteils. Wenn hundert URLs identische Inhalte liefern, haben Sie einen generierten Bereich gefunden und nicht hundert einzelne Seiten.
Und behalten Sie die Entdeckungsrate im Auge. Der nützlichste einzelne Indikator: Verfolgen Sie die Anzahl neu entdeckter URLs pro abgerufener Seite. Auf einer endlichen Website sinkt dieser Wert stetig gegen Null. Bleibt er konstant oder steigt er an, generiert etwas URLs schneller, als Sie sie verarbeiten können – eine Falle, ein Kalender oder eine facettierte Explosion. Die absichtlichen Varianten haben wir in Honeypot-Fallen behandelt.
Planung von erneuten Crawls
Bei allem, was mehr als einmal ausgeführt wird, wird die Liste zu einem Zeitplan.
Nach Volatilität abstufen. Seiten, die sich stündlich ändern, müssen stündlich überprüft werden; Seiten, die sich einmal im Jahr ändern, hingegen nicht. Alles mit der Häufigkeit zu crawlen, die das volatilste Element erfordert, ist der häufigste Grund für überhöhte Kosten.
Verwenden Sie bedingte Anfragen. If-Modified-Since und If-None-Match wandeln ein erneutes Crawling in eine Reihe von „304 Not Modified“-Antworten um, die jeweils nur wenige hundert Byte kosten. Bei einem erneuten Crawling, bei dem die meisten Seiten unverändert sind, reduziert dies sowohl Ihre Kosten als auch die Auslastung des Zielservers um eine Größenordnung.
Passen Sie sich an Beobachtungen an. Wenn sich eine Seite in zehn Überprüfungen nicht geändert hat, überprüfen Sie sie seltener. Wenn sie sich in den letzten drei Überprüfungen geändert hat, überprüfen Sie sie häufiger. Ein einfacher multiplikativer Back-off reicht aus.
Erkennen Sie das Verschwinden von Seiten explizit. Seiten verschwinden, und Websites geben dies selten bekannt. Achten Sie entweder auf 404-Fehler oder wenden Sie eine Richtlinie an – eine URL, die in drei aufeinanderfolgenden Crawls nicht gefunden wurde, wird als inaktiv markiert. Ohne diese Maßnahme füllt sich Ihr Datensatz mit Einträgen, die nicht mehr existieren, was das Vertrauen schneller untergräbt als fehlende Einträge.
Speicherung und Skalierbarkeit
Ein Hinweis dazu, wann der In-Memory-Ansatz nicht mehr funktioniert.
Bis zu etwa hunderttausend URLs reichen Python-Sets und -Listen völlig aus. Man sollte es nicht übertreiben.
Bis zu einigen Millionen eignet sich eine lokale Datenbank – SQLite funktioniert gut – mit Indizes für den URL-Hash und den Abrufstatus. Persistenz bedeutet auch, dass ein abgestürzter Crawl fortgesetzt wird, anstatt neu zu starten, was wichtiger ist als die Leistung.
Darüber hinaus sind eine ordentliche Warteschlange und ein Schlüssel-Wert-Speicher erforderlich, wobei die Grenze nach Host partitioniert ist, sodass den Workern ganze Hosts zugewiesen werden können und die „Politeness“ auch ohne Koordination korrekt bleibt.
Zwei Entwurfsentscheidungen, die sich in jeder Größenordnung auszahlen:
Speichere den URL-Hash, nicht nur die URL. Vergleiche und Indizes auf einem Hash fester Länge sind ressourcenschonender und der Speicherbedarf ist geringer.
Speichere die Rohantwort, nicht nur das geparste Ergebnis. Wenn ein Parser ausfällt – und das wird er –, ist das erneute Parsen der vorhandenen Daten kostenlos, während ein erneutes Abrufen Bandbreite und Kundenvertrauen kostet.
Eine minimale Implementierung
Das Ganze in etwa vierzig Zeilen, um die einzelnen Komponenten zu veranschaulichen.
import time
from collections import deque, defaultdict
from urllib.parse import urlsplit, urlunsplit, parse_qsl, urlencode
TRACKING = {"utm_source", "utm_medium", "utm_campaign", "fbclid", "gclid"}
def normalise(url):
p = urlsplit(url)
host = p.hostname or ""
port = "" if p.port in (None, 80, 443) else f":{p.port}"
query = urlencode(sorted(
(k, v) for k, v in parse_qsl(p.query, keep_blank_values=True)
if k.lower() not in TRACKING
))
return urlunsplit((p.scheme.lower(), host + port, p.path or "/", query, ""))
class Frontier:
def __init__(self, delay=1.5, max_per_host=5000):
self.queues = defaultdict(deque)
self.seen = set()
self.next_ok = defaultdict(float)
self.counts = defaultdict(int)
self.delay, self.max_per_host = delay, max_per_host
def add(self, url, depth=0):
url = normalise(url)
if url in self.seen or depth > 5:
return False
host = urlsplit(url).hostname
if self.counts[host] >= self.max_per_host:
return False
self.seen.add(url)
self.counts[host] += 1
self.queues[host].append((url, depth))
return True
def next(self):
now = time.monotonic()
for host, q in self.queues.items():
if q and self.next_ok[host] <= now:
self.next_ok[host] = now + self.delay
return q.popleft()
return None
Darin lassen sich fünf Entwurfsentscheidungen erkennen, die jeweils einem der obigen Abschnitte entsprechen.
Die Normalisierung erfolgt unter add(), nicht zum Zeitpunkt des Abrufs. Die Deduplizierung ist nur dann korrekt, wenn die kanonische Form in die Menge der besuchten Seiten aufgenommen wird; eine spätere Normalisierung bedeutet also, dass bereits Duplikate gespeichert wurden.
Die Menge der besuchten Seiten wird beim Einreihen in die Warteschlange gefüllt, nicht bei Abschluss. Andernfalls wird eine URL, die auf zwanzig Seiten entdeckt wurde, zwanzig Mal in die Warteschlange gestellt, bevor der erste Abruf abgeschlossen ist.
Warteschlangen sind hostbezogen, und die „Politeness“ gilt pro Host. „next_ok“ protokolliert, wann jeder Host als Nächstes kontaktiert werden darf, sodass eine große Website die anderen nicht ausbremsen kann und die Verzögerung dort greift, wo sie hingehört.
Budgets werden bereits beim Eintrag durchgesetzt. Tiefen- und Host-bezogene Obergrenzen lehnen URLs ab, bevor sie Speicherplatz beanspruchen – das ist der Unterschied zwischen einem begrenzten Crawl und einem, der seine Grenze erst durch die Erschöpfung des Arbeitsspeichers erreicht.
„next()“ gibt „None“ zurück, anstatt zu blockieren. So bleibt es dem Aufrufer überlassen, zu entscheiden, ob er warten, andere Aufgaben erledigen oder den Vorgang beenden möchte – einen Scheduler, der innerhalb der Datenstruktur „schlummert“, kann man nicht instrumentieren.
Was hier bewusst fehlt, ist Persistenz, und das ist das Erste, was man für jede reale Anwendung hinzufügen muss. Ein abgestürzter Crawl, der von der Startliste aus neu gestartet werden muss, hat mehr als nur Zeit verloren; er hat alles erneut abgerufen, was Bandbreite und Kundenvertrauen kostet.
Instrumentierung der Liste
Was soll gemessen werden? Denn ein Crawl, der lediglich „abgerufene Seiten“ meldet, sagt fast nichts aus.
Größe der Frontier im Zeitverlauf. Sollte gegen Null tendieren. Ein Anstieg bedeutet unbegrenzte Entdeckung.
Entdeckungsquote. Neue URLs pro abgerufener Seite, wie oben.
Abrufergebnisse nach Status, pro Host. Aggregierte Zahlen verbergen, dass ein Host vollständig ausfällt.
Duplikatsrate. Wie viele der entdeckten URLs waren bereits bekannt? Eine hohe Rate nach der Normalisierung bedeutet, dass bei Ihrer Normalisierung etwas übersehen wurde.
Bytes pro nützlicher Seite. Die Zahl, die den Crawl mit der Rechnung verknüpft, und diejenige, die aufzeigt, dass ein Headless-Browser Megabytes an Bildern abruft, die Sie gar nicht benötigten.
Inhaltsüberprüfungen. Ob Seiten die erwarteten Marker enthalten. Ein Crawler, der 100 % Erfolg meldet, während er „soft-blocked“ Seiten zurückgibt, ist ein kostspieliger Fehler – und nur Inhaltsüberprüfungen erkennen dies.
Häufig gestellte Fragen
Was ist eine Crawl-Liste?
Die Menge der URLs, die ein Crawler besuchen will; sie besteht in der Regel aus einer Startliste, einer Grenze aus entdeckten, aber noch nicht abgerufenen URLs und einer Menge bereits besuchter URLs. Die Verwaltung dieser Grenze – Reihenfolge, Deduplizierung und Budgets – entscheidet maßgeblich darüber, ob ein Crawling-Vorgang abgeschlossen wird.
Wie normalisiere ich URLs für das Crawling?
Wandeln Sie das Schema und den Host in Kleinbuchstaben um, nicht jedoch den Pfad; wandeln Sie hexadezimale Ziffern in der Prozentkodierung in Großbuchstaben um; dekodieren Sie unnötige Prozentkodierungen; entfernen Sie Punktsegmente; lassen Sie Standardports weg; normalisieren Sie einen leeren Pfad zu /; entfernen Sie Fragmente und entfernen Sie bekannte Tracking-Parameter. RFC 3986 definiert alle Punkte bis auf die letzten beiden.
Was ist eine Crawl-Frontier?
Die Warteschlange der entdeckten URLs, die noch nicht abgerufen wurden. In der Praxis handelt es sich um eine Reihe von hostbezogenen Warteschlangen sowie einen Scheduler, der den nächsten Host auswählt, der unter Einhaltung der Höflichkeitsgrenzen in Frage kommt, da eine einzige globale Warteschlange dazu führen würde, dass eine große Website alle anderen aushungert.
Wie verhindere ich, dass mein Crawler endlos läuft?
Feste Obergrenzen: maximale Crawling-Tiefe, maximale Seitenanzahl pro Host und insgesamt sowie eine Bandbreitenbegrenzung. Fügen Sie Musterausnahmen für Kalender und facettierte Navigation hinzu und lösen Sie einen Alarm aus, wenn das Verhältnis von neu entdeckten URLs zu abgerufenen Seiten nicht mehr abnimmt.
Wie vermeide ich es, dieselbe Seite zweimal zu crawlen?
Normalisieren Sie URLs vor der Deduplizierung, da dieselbe Seite viele gültige Adressen haben kann. Prüfen Sie anschließend die Zugehörigkeit zu einer Menge besuchter Seiten – bei kleinem Umfang ein Hash-Set, bei großem Umfang ein Bloom-Filter oder eine Datenbank. Berücksichtigen Sie „rel="canonical"“, sofern Seiten dies angeben.
Wie oft sollte ich erneut crawlen?
So selten, wie es Ihre Anforderungen zulassen, gestaffelt danach, wie oft sich jede Seite tatsächlich ändert. Nutzen Sie „lastmod“ aus der Sitemap und bedingte Anfragen, damit unveränderte Seiten nur einen „304“ statt eines vollständigen Abrufs kosten. Alles mit der Häufigkeit der sich häufig ändernden Seiten zu crawlen, ist die häufigste Ursache für Verschwendung.
Was ist ein Bloom-Filter und brauche ich einen?
Ein probabilistischer Datensatz, der die Zugehörigkeit in konstanter Zeit mit sehr geringem Speicherbedarf ermittelt, wobei eine geringe Wahrscheinlichkeit für Fehlalarme besteht – das heißt, dass Sie gelegentlich eine URL überspringen, die Sie eigentlich noch nicht gesehen haben. Lohnt sich ab einigen Millionen URLs; darunter ist er unnötig, da ein einfacher Datensatz einfacher und exakter ist.
Wie stelle ich fest, dass Seiten entfernt wurden?
Achten Sie auf 404-Fehler und wenden Sie eine Richtlinie für Seiten an, die einfach nicht mehr erscheinen – markieren Sie beispielsweise eine URL als inaktiv, wenn sie in drei aufeinanderfolgenden Crawls nicht mehr gefunden wurde. Ohne diese Maßnahme sammelt sich im Datensatz Einträge an, die nicht mehr existieren, was das Vertrauen schneller untergräbt als Lücken.
Fazit
Das Crawlen ist größtenteils reine Verwaltungsarbeit. Das Abrufen der Daten ist dank Bibliotheken ein gelöstes Problem; die Entscheidung, was abgerufen werden soll, das Erkennen, dass man es bereits abgerufen hat, und das Wissen, wann man aufhören muss – darin liegt die eigentliche technische Herausforderung.
Drei Aspekte verdienen besondere Beachtung, die in keinem Verhältnis zu ihrem Schwierigkeitsgrad steht. Normalisierung, denn ohne sie ruft man dieselbe Seite unter einem Dutzend Adressen auf und bezahlt für jede einzelne – und RFC 3986 gibt genau an, welche Umformungen sicher sind. Budgets, denn manche URL-Räume sind tatsächlich unendlich groß, und ein Crawler ohne feste Grenzen wird darauf stoßen. Und die Erkennungsquote, denn sie ist eine einzige Zahl, die eine Falle, einen Kalender oder eine facettierte Explosion schon lange vor der Rechnung aufdeckt.
Dann sollten Sie gut vorgehen. Eine Sitemap verwandelt einen Crawl in einen Abruf der Änderungen, eine Archivabfrage bringt Seiten ans Licht, die durch Link-Traversierung niemals erreichbar wären, und beides kostet das Ziel nichts. Auf der Startseite zu beginnen und auf das Beste zu hoffen, ist der langsamste Weg zum unvollständigsten Ergebnis – und dennoch ist dies nach wie vor die Standardvorgehensweise.