Huge Data scrapen ohne Sperrenim großen Maßstab nicht gesperrt bleiben

Ein paar hundert Seiten von einer Website zu ziehen ist einfach. Ein paar Millionen zu ziehen ist ein anderes Problem, denn bei diesem Volumen ist das, was zwischen Ihnen und den Daten steht, nicht mehr das Parsen, sondern das Nichtgesperrtsein. Sites, die einem menschlichen Leser bereitwillig dienen, werden einen Client drosseln, herausfordern oder sperren, der tausende von Seiten pro Stunde von einer Adresse in einem starren Muster anfordert. Die Daten sind oft öffentlich, aber das Zugriffsmuster ist das, was Sie als auffällig kennzeichnet.

Dieser Leitfaden erklärt, warum große Scrapes gesperrt werden und was sie tatsächlich am Laufen hält: rotierende IP-Adressen, getaktete Anfragen, realistische Header senden, Seiten rendern, die einen Browser benötigen, nur die fehlgeschlagenen Anfragen wiederholen und für erfolgreiche Antworten bezahlen statt für verschwendete. Er schließt damit ab, wie eine verwaltete Scraping-API das alles in eine einzige Anfrage faltet, und mit einem kurzen Hinweis auf das verantwortungsvolle Sammeln von Daten.

Warum Websites große Scrapes sperren

Für eine Website ist ein menschlicher Besucher ein einzelner Client: eine IP-Adresse, die mit menschlicher Geschwindigkeit surft, eine Handvoll Seiten anklickt, mit dem Fingerabdruck eines normalen Browsers. Ein naiver Scraper sieht überhaupt nicht so aus. Er hämmert denselben Endpunkt von einer IP aus, viel schneller als eine Person lesen könnte, in einer vorhersehbaren Schleife, oft mit einem Standard-User-Agent, der ankündigt, dass es sich um ein Skript handelt. Jedes dieser Signale ist leicht zu erkennen, und zusammen sind sie unverkennbar.

Sites veröffentlichen auch ihre Präferenzen in einer robots.txt-Datei, die festlegt, was automatisierte Clients berühren sollten und was nicht und wie aggressiv. Zusätzlich setzen sie aktive Abwehrmechanismen ein: Rate-Limits pro Adresse, CAPTCHA-Herausforderungen, Login-Walls, Browser-Fingerprinting und Honeypot-Links, die vor menschlichen Augen verborgen sind, aber im HTML sichtbar sind, sodass sich jeder Client, der einem folgt, als Bot outet. Keiner dieser Abwehrmechanismen richtet sich gegen Menschen. Sie richten sich genau gegen das Verhalten, das ein unkonfigurierter Scraper erzeugt. Sperren zu vermeiden bedeutet also hauptsächlich, nicht wie das auszusehen, was diese Systeme zu fangen gebaut wurden. Die folgenden Abschnitte gehen die Techniken durch, die Sie dorthin bringen.

IP-Adressen rotieren

Das lauteste einzelne Signal, das Sie senden, ist Volumen von einer Adresse. Hundert Anfragen pro Minute von einer einzigen IP ist das einfachst mögliche Ding, das man mit einem Rate-Limit belegen kann, und sobald diese Adresse markiert ist, schlägt jede Anfrage davon fehl, egal wie sorgfältig der Rest Ihrer Einrichtung ist. Die Lösung besteht darin, Anfragen auf viele Adressen zu verteilen, damit keine einzelne eine verdächtige Last trägt.

Das ist es, was ein Proxy tut. Ein Proxy ist ein Gateway, das zwischen Ihrem Scraper und der Zielsite sitzt, sodass die Site die Adresse des Proxys sieht statt Ihrer. Ein rotierender Proxy geht weiter und ändert diese Adresse von Anfrage zu Anfrage, sodass ein Job, der eine Million Anfragen stellt, über einen großen Pool verteilt wird statt auf einer Identität konzentriert zu sein. Proxys gibt es auch in Varianten, die für das Sperren relevant sind: Rechenzentrum-Adressen sind schnell und günstig, aber leichter als nicht-residenziell zu erkennen, während residenzielle und mobile Adressen von echten Verbraucherverbindungen stammen und sich auf Sites mit aggressiven Abwehrmechanismen viel besser einmischen. Für einen tieferen Blick auf Rotationsstrategie, lesen Sie unseren Leitfaden zur Verwendung von rotierenden Proxys.

Anfragen takten und Rate-Limits respektieren

Selbst über viele IPs hinweg verrät Sie die Geschwindigkeit allein. Kein Mensch lädt dreißig Seiten pro Sekunde, also ist ein Scraper, der das tut, trivialerweise von echtem Traffic zu unterscheiden. Ihre Anfragen zu takten, bewusste Verzögerungen hinzuzufügen und die Lücken zwischen ihnen zu variieren lässt den Traffic organisch statt mechanisch aussehen.

Das Ziel ist eine Anfragerate, die die Zielsite ohne Belastung aufnehmen kann. Das ist sowohl das Richtige als auch das Wirksame: Ein gemessener Crawl ist weit weniger wahrscheinlich, ein Rate-Limit auszulösen oder eine Adresse zu sperren, als ein voller Sprint. Viele Sites signalisieren ihre Limits auch direkt durch Response-Header und Status-Codes, und ein wohlgesinnter Scraper liest diese Signale und hält inne, wenn er dazu aufgefordert wird. Behandeln Sie das Rate-Limit als eine Einschränkung, um die herum Sie entwerfen, nicht als ein Hindernis, das man überholt, und die meisten Drosselungsprobleme verschwinden.

Realistische Header senden

Jeder Browser sendet bei jeder Anfrage einen Satz von HTTP-Headern: einen User-Agent, der den Browser und das Betriebssystem identifiziert, akzeptierte Sprachen, Codierungen und mehr. Eine Standard-Scraping-Bibliothek sendet einen spärlichen, offensichtlich automatisierten Satz von Headern, manchmal einen User-Agent, der buchstäblich den HTTP-Client benennt. Sites lesen diese Header, und eine Anfrage, die nicht so aussieht, als käme sie von einem echten Browser, ist eine einfache Markierung.

Die Header zu matchen, die ein echter Browser sendet, und den User-Agent über einen Pool echter zu variieren statt für jede Anfrage einen einzelnen String wiederzuverwenden, lässt jede Anfrage einmischen. Header sollten auch intern konsistent sein: ein Accept-Language und ein User-Agent, die sich widersprechen, sind ihr eigener Verrat. Das Ziel ist, dass jede Anfrage nicht von einer unterscheidbar ist, die der Browser einer Person produzieren würde, sodass nichts in der Anfrage selbst sie heraushebt.

Seiten rendern, die JavaScript benötigen

Ein wachsender Anteil des Webs liefert seinen Inhalt nicht im anfänglichen HTML. Single-Page-Apps und dynamische Sites laden ein Skelett und rufen dann die echten Daten mit JavaScript im Browser ab und rendern sie. Eine einfache HTTP-Anfrage an eine dieser Seiten gibt fast nichts Nützliches zurück, weil der gewünschte Inhalt nie in der rohen Antwort existiert hat.

Das Scrapen dieser Sites bedeutet, eine echte Browser-Engine auszuführen, die das JavaScript der Seite ausführt und wartet, bis der Inhalt erscheint, bevor er extrahiert wird. Headless Browser erledigen das, zu dem Preis, schwerer und langsamer als einfache Anfragen zu sein, was bei Millionen davon relevant ist. Zu wissen, welche Seiten wirklich Rendering benötigen und welche alles in der ersten Antwort zurückgeben, ist das, was einen großen Job effizient hält, statt Browser-Zeit auf Seiten zu verbrennen, die es nie brauchten. Unsere Anleitung zum Crawlen von JavaScript-Websites behandelt, wann Rendering den Overhead wert ist.

Nur fehlgeschlagene Anfragen wiederholen

Im großen Maßstab wird immer ein gewisser Bruchteil der Anfragen fehlschlagen: ein vorübergehendes Timeout, eine temporäre Blockierung, ein langsamer Upstream. Die falsche Reaktion ist, den gesamten Job neu zu starten, was alles verschwendet, das bereits erfolgreich war, und die Last, die Sie auf das Ziel legen, verdoppelt. Die richtige ist, das Ergebnis jeder Anfrage zu verfolgen und nur die zu wiederholen, die fehlgeschlagen sind, idealerweise mit einem kurzen Backoff, damit ein kämpfender Endpunkt einen Moment zur Erholung bekommt.

Das hält einen großen Scrape sowohl effizient als auch sanft. Erfolgreiche Seiten werden verbucht und nie erneut abgerufen, Fehler werden isoliert und selbst wiederholt, und das Gesamtvolumen, das Sie der Site senden, bleibt nahe dem Minimum, das der Job tatsächlich erfordert. Ein so aufgebauter Job degradiert bei Teilausfällen elegant statt zu schlagen, was genau das ist, was Sie wollen, wenn ein Lauf Stunden und Millionen von URLs umfasst.

Nur für erfolgreiche Anfragen bezahlen

Es gibt eine wirtschaftliche Seite des Large-Scale-Scrapings, die leicht zu übersehen ist, bis die Rechnung kommt. Wenn Sie Ihre eigene Proxy-Flotte und Browser-Farm betreiben, zahlen Sie für jede Anfrage, die Sie senden, einschließlich derjenigen, die gesperrt werden, eine Zeitüberschreitung haben oder leer zurückkommen. Bei einem Millionen-Anfragen-Job mit einer nicht trivialen Fehlerrate ist diese Verschwendung echtes Geld, das für Daten ausgegeben wird, die Sie nie erhalten haben.

Ein Preismodell, das nur für erfolgreiche Antworten berechnet, dreht diesen Anreiz um. Die Kosten für fehlgeschlagene Anfragen liegen beim Anbieter, was sein Interesse mit Ihrem ausrichtet: Er ist motiviert, Ihre Erfolgsrate hoch zu halten, weil das das ist, wofür er abrechnet. Es macht einen großen Job auch einfacher zu budgetieren, da Sie für Ergebnisse statt Versuche bezahlen. Wenn Sie Scraping-Ansätze im Volumen vergleichen, ist diese Unterscheidung zwischen pro Anfrage und pro Erfolg bezahlen einer der größeren Posten.

Wie eine verwaltete Scraping-API das erledigt

Jede der obigen Techniken ist für sich genommen unkompliziert. Die Schwierigkeit besteht darin, sie alle zusammen, zuverlässig, über Millionen von Anfragen hinweg zu betreiben und sie am Laufen zu halten, wenn Zielsites ihre Abwehrmechanismen ändern. Das ist die Lücke, die eine verwaltete Scraping-API füllt. Statt selbst einen Proxy-Pool, eine Header-Rotationsschicht, eine Headless-Browser-Farm, eine Retry-Warteschlange und einen CAPTCHA-Löser zusammenzustellen und zu warten, senden Sie eine URL an einen einzigen Endpunkt und erhalten saubere Daten zurück.

Unter der Haube rotiert die API IP-Adressen über einen großen Pool, taktet und formt Anfragen so, dass sie menschlich aussehen, sendet realistische Header, rendert JavaScript-schwere Seiten mit einer echten Browser-Engine, wenn nötig, löst oder umgeht CAPTCHAs und wiederholt vorübergehende Fehler, alles bevor sie eine Antwort zurückgibt. Für Jobs, die zu groß sind, um synchron zu laufen, ermöglicht ein asynchroner Modus, URLs in Bulk einzureichen und Ergebnisse per Callback zu empfangen, wenn sie fertig sind, sodass Sie nicht Millionen von Verbindungen offen halten. Das Ergebnis ist, dass die Anti-Ban-Arbeit zum Problem von jemand anderem wird, und Sie Ihre Zeit mit den Daten statt mit der Infrastruktur verbringen. Für das breitere Bild des Ausführens von Jobs dieser Größe, lesen Sie unseren Leitfaden zu Large-Scale-Web-Scraping und die Best Practices für das Skalieren von Scraping-Projekten.

Verantwortungsvoll scrapen

Sperren zu vermeiden ist ein technisches Problem, aber es sitzt innerhalb eines ethischen. Scrapen Sie nur öffentliche Daten und prüfen Sie die Nutzungsbedingungen einer Site und ihre robots.txt, bevor Sie einen großen Job starten. Halten Sie Ihre Anfragerate vernünftig, damit Sie den Dienst nicht für die Menschen verschlechtern, für die er tatsächlich gebaut wurde, denn ein Crawl, der schwer genug ist, um eine Site zu belasten, ist sowohl unhöflich als auch kontraproduktiv. Wenn die von Ihnen gesammelten Daten irgendetwas Persönliches enthalten, behandeln Sie Vorschriften wie DSGVO und CCPA als harte Anforderungen, nicht als Nachgedanken: Sammeln Sie nur das, was Sie benötigen, aggregieren Sie wo möglich und erstellen Sie keine Profile von Einzelpersonen. Verantwortungsvolles Scrapen und unsperrbares Scrapen ziehen in dieselbe Richtung, weil das Verhalten, das Sie konform hält, in der Regel dasselbe Verhalten ist, das Sie davon abhält, wie ein missbräuchlicher Bot auszusehen.

Häufig gestellte Fragen

Warum sperren Websites Scraper, wenn die Daten öffentlich sind?

Die Sperrung betrifft selten die Daten und fast immer das Zugriffsmuster. Ein Scraper, der tausende von Seiten pro Stunde von einer IP-Adresse, mit Maschinengeschwindigkeit, in einer vorhersehbaren Schleife anfordert, sieht überhaupt nicht wie ein menschlicher Besucher aus, und dieses Verhalten ist das, was Anti-Bot-Systeme zu fangen gebaut wurden. Öffentliche Daten, die mit einer menschenähnlichen Rate von variierenden Adressen angesehen werden, ziehen weit weniger Aufmerksamkeit auf sich als dieselben Daten, die in industriellem Volumen von einer einzigen Identität gezogen werden.

Was ist die wichtigste Einzeltechnik, um nicht gesperrt zu werden?

IP-Adressen rotieren, weil Volumen von einer Adresse das lauteste und am leichtesten zu erkennende Signal ist, das ein Scraper sendet. Anfragen über einen großen Pool zu verteilen, insbesondere residenzielle oder mobile Adressen auf aggressiven Sites, verhindert, dass eine einzige Identität eine verdächtige Last trägt. Das gesagt, funktioniert Rotation am besten in Kombination mit Taktung und realistischen Headern, da Geschwindigkeit und offensichtliche automatisierte Fingerabdrücke Sie immer noch markieren werden, selbst über viele IPs hinweg.

Wie schnell kann ich scrapen, ohne gesperrt zu werden?

Es gibt keine universelle Zahl, weil jede Site ihre eigenen Limits setzt, aber das Prinzip ist, bei einer Rate zu bleiben, die das Ziel bequem aufnehmen kann, und die Lücken zwischen Anfragen zu variieren, damit der Traffic organisch aussieht. Viele Sites kommunizieren ihre Limits durch Response-Header und Status-Codes, also lesen Sie diese Signale und halten Sie inne, wenn Sie dazu aufgefordert werden. Ein gemessener Crawl, der Rate-Limits respektiert, ist weit weniger wahrscheinlich, gedrosselt zu werden, als einer, der sprintet.

Brauche ich immer einen Headless Browser, um im großen Maßstab zu scrapen?

Nein, und Sie sollten einen vermeiden, wo Sie können, weil Rendering schwerer und langsamer als eine einfache Anfrage ist, was über Millionen von Seiten relevant ist. Sie benötigen eine Browser-Engine nur für Sites, die ihren Inhalt mit JavaScript laden, nachdem das anfängliche HTML ankommt. Seiten, die alles in der ersten Antwort zurückgeben, können mit einfachen Anfragen gescrapt werden, sodass der effiziente Ansatz darin besteht, nur die Seiten zu rendern, die es wirklich erfordern.

Was bedeutet "nur für erfolgreiche Anfragen bezahlen"?

Es ist ein Preismodell, bei dem Sie für Antworten berechnet werden, die tatsächlich die angeforderten Daten zurückgeben, nicht für Anfragen, die gesperrt werden, eine Zeitüberschreitung haben oder leer zurückkommen. Bei einem großen Job mit einer realen Fehlerrate ist dieser Unterschied erheblich, da Sie nicht für Daten bezahlen, die Sie nie erhalten haben. Es richtet auch den Anreiz des Anbieters mit Ihrem aus, weil er nur verdient, wenn Ihre Anfragen erfolgreich sind.

Wie hilft eine Scraping-API im Vergleich zur Erstellung eines eigenen Scrapers?

Eine verwaltete API betreibt Rotation, Taktung, Header-Management, JavaScript-Rendering, CAPTCHA-Verarbeitung und Retries hinter einem einzigen Endpunkt, sodass Sie eine URL senden und saubere Daten zurückerhalten statt jede dieser Schichten selbst aufzubauen und zu warten. Sie passt sich auch an, wenn Zielsites ihre Abwehrmechanismen ändern, was bei einer selbst gemachten Einrichtung laufende Arbeit ist. Für sehr große Jobs ermöglicht ein asynchroner Modus, URLs in Bulk einzureichen und Ergebnisse per Callback zu sammeln statt Millionen von Verbindungen offen zu halten.