Web Scraping, das weiterläuft, wenn sich die Website ändert
Wir extrahieren Daten von Websites, die Ihnen keine API anbieten: Veranstaltungskalender, Kataloge, Preise, Anzeigen, Amtsblätter. Jede Quelle bekommt die Strategie, die sie braucht, einen Test, der sie alle paar Tage tatsächlich aufruft, und einen Alert an dem Tag, an dem sich ihr Design ändert, bevor jemand fehlende Daten bemerkt.
Web Scraping ist die automatisierte Extraktion von Daten, die auf Websites ohne API oder Download-Datei veröffentlicht sind. Bei Soamee bauen wir Scraper nach Maß in Node.js und TypeScript: Für jede Quelle wählen wir zwischen ihrer internen API, ihrem RSS-Feed, dem HTML, das der Server ausliefert, oder einem Headless-Browser mit Playwright. Alle Ergebnisse laufen durch denselben Normalisierer und landen in einem gemeinsamen Format und ohne Duplikate in Ihrer Datenbank. Wenn eine Website automatisierte Anfragen blockiert (403, CAPTCHAs, Sperren nach IP), integrieren wir Bright Data: Web Unlocker, Scraping Browser oder Residential Proxies. Jede Quelle hat einen Test gegen die echte Website, der alle paar Tage läuft, und einen E-Mail-Alert mit Diagnose, wenn er fehlschlägt.
Von der Quellenliste zu sauberen Daten in Ihrer Datenbank
Ein Scraper, der heute funktioniert, ist an einem Nachmittag geschrieben. Die Arbeit besteht darin, dass er in sechs Monaten noch läuft, mit dreißig Quellen, die sich jede in ihrem eigenen Tempo ändern.
Bestandsaufnahme und Machbarkeit pro Quelle
Bevor wir Code schreiben, prüfen wir jede Website: ob sie eine öffentliche oder interne API hat, ob es ein WordPress mit offenem /wp-json ist, ob sie die Daten per XHR lädt, was in ihrer robots.txt steht und ob sie automatisierte Anfragen blockiert. Heraus kommt ein Steckbrief pro Quelle mit Strategie, Risiken und Frequenz.
Eine Strategie pro Quellentyp
API, RSS, statisches HTML oder Headless-Browser hinter derselben Schnittstelle. Eine neue Quelle hinzuzufügen heißt meist, ihre Konfiguration (URL, Selektoren, Feld-Mapping) und ihren Test zu schreiben, ohne einen Scraper von Grund auf zu programmieren.
Normalisierung und Deduplizierung
Datumsangaben als Fließtext wie „vom 10. bis 28. Juni“, Preise als Text, eingebettetes HTML, dieselbe Kategorie unter fünf Namen. Alles läuft durch einen Normalisierer und wird mit einem eindeutigen Schlüssel aus Quelle und externer ID gespeichert. Ein erneuter Lauf aktualisiert also, statt zu duplizieren.
Websites mit Bot-Schutz
Für Quellen, die 403 oder CAPTCHA zurückgeben, integrieren wir Bright Data: Web Unlocker für HTTP-Anfragen, Scraping Browser für Seiten, die JavaScript brauchen, und Residential Proxies, wenn die IP das Problem ist. Nur bei diesen Quellen; alle anderen laufen direkt und verbrauchen kein Unblocking.
Queues, Retries und Planung
Jede Quelle ist ein Job in einer BullMQ-Queue auf Redis, mit eigener Frequenz, drei Wiederholungen mit exponentiellem Backoff und einem Protokoll pro Lauf: wie viele Einträge gefunden wurden, wie viele neu waren und wie lange es gedauert hat.
Smoke-Tests und Alerts
Ein Test pro Quelle, der alle drei Tage in der CI die echte Website aufruft, dazu Unit-Tests auf einem gespeicherten Snapshot der Antwort. Schlägt ein Lauf fehl, kommt eine E-Mail mit HTTP-Statuscode, einem Ausschnitt der Antwort und dem, was zuerst zu prüfen ist.
Vier Strategien, von der stabilsten zur fragilsten
Wir nehmen die erste Strategie der Liste, die die Quelle zulässt. Jede Stufe weiter unten kostet Geschwindigkeit und Stabilität, deshalb steigen wir nur ab, wenn die Quelle uns dazu zwingt.
| Strategie | Wann wir sie einsetzen | Kosten | Was kaputtgeht |
|---|---|---|---|
| Öffentliche oder interne API | Die Website lädt ihre Daten aus einem JSON: Open-Data-Portale, WordPress mit REST API, Event-Plugins, Endpoints, die im Network-Tab sichtbar sind | ~200 ms pro Anfrage | Schemaänderungen, selten |
| RSS / Atom | Die Quelle veröffentlicht einen Feed, und Titel, Link und Zusammenfassung reichen | ~200 ms pro Feed | Das Datum im Feed ist das Veröffentlichungsdatum, nicht das der Veranstaltung oder des Angebots |
| Statisches HTML | Der Inhalt steckt im HTML, das der Server ausliefert | Eine Anfrage pro Liste, plus eine pro Detailseite, wenn ein Feld fehlt | Die CSS-Selektoren, bei jedem Redesign |
| Headless-Browser | Mit JavaScript gerenderte Inhalte, Infinite Scroll, „Mehr laden“-Buttons oder Sperren gegen HTTP-Clients | 3-5 s pro Seite und 100-200 MB RAM pro Browser | Timeouts und das Browser-Binary in jeder Umgebung |
Was bei uns läuft
Zahlen aus einer Aggregationsplattform, die wir betreiben, mit sehr unterschiedlichen öffentlichen Quellen: Open-Data-Portale, WordPress, Drupal, React-Websites und handgebaute Seiten.
Quellen, jede mit ihrem Smoke-Test gegen die echte Website
Extraktionsstrategien hinter derselben Schnittstelle
zwischen zwei Durchläufen der Smoke-Tests in der CI
Wiederholungen mit exponentiellem Backoff, bevor ein Lauf als fehlgeschlagen gilt
Die häufigste Störung ist ein Redesign der Quelle. Der Smoke-Test erkennt sie spätestens nach drei Tagen. Für Websites, die automatisierte Anfragen blockieren, arbeiten wir mit Bright Data.
Integration mit Bright Data →Von der URL-Liste zum ersten Datensatz in Ihrer Datenbank
Zuerst eine Quelle jedes Typs, damit die echten Probleme früh auftauchen. Danach der Rest in Etappen.
Steckbrief pro Quelle
Wir prüfen jede Website, wählen die Strategie und notieren das Ungewöhnliche: Datumsformate, Paginierung, Sperren, Felder, die nur auf der Detailseite stehen.
Pilot pro Strategie
Wir setzen eine Quelle jedes Typs um, mit Unit-Test, Smoke-Test und Dokumentation. Dort zeigen sich die Probleme, die die Bestandsaufnahme nicht sieht.
Restliche Quellen
Mit dem validierten Modell ist jede neue Quelle meist Konfiguration plus ein Test. Quellen, die einen Browser oder Unblocking brauchen, kommen in eine eigene Etappe.
Betrieb
Planung, Alerts, Laufberichte und Wartung, wenn sich eine Quelle ändert. Wenn Sie den Betrieb lieber mit Ihrem Team übernehmen, dokumentieren wir alles Quelle für Quelle.
Häufige Fragen zu Web Scraping
Ist Web Scraping in Deutschland und der EU legal? +
Daten zu extrahieren, die ohne Zugangsbeschränkung veröffentlicht sind, ist gängige Praxis, aber es gibt drei Grenzen, die wir bei jeder Quelle prüfen: die Nutzungsbedingungen der Website, das Schutzrecht sui generis für Datenbanken (ein wesentlicher Teil einer fremden Datenbank darf nicht zur Weiterverwendung entnommen werden) und die DSGVO, wenn personenbezogene Daten betroffen sind. Bereiche hinter einem Login betreten wir nicht ohne Erlaubnis des Inhabers. In Zweifelsfällen empfehlen wir vor dem Start eine rechtliche Prüfung.
Was passiert, wenn die Website ihr Design ändert? +
Der Smoke-Test dieser Quelle schlägt beim nächsten Durchlauf fehl, spätestens nach drei Tagen, und ein Alert mit dem Fehler geht raus. Quellen über API oder RSS sind von Redesigns fast nie betroffen. Bei HTML oder Headless-Browser reicht es meist, die Selektoren in der Konfiguration der Quelle anzupassen, ohne Code zu deployen.
Wann braucht es Bright Data? +
Wenn die Website jedem automatisierten Client 403 zurückgibt, CAPTCHAs zeigt oder nach IP sperrt. Dann reicht ein eigener Headless-Browser nicht, weil die Sperre von der IP und vom Browser-Fingerprint abhängt. Wir aktivieren es nur bei den Quellen, die es brauchen; alle anderen laufen weiter direkt.
Wie oft werden die Daten aktualisiert? +
Jede Quelle hat ihre eigene Frequenz: stündlich für Preise oder Verfügbarkeit, einmal täglich für Veranstaltungskalender oder Kataloge, die sich wenig ändern. Es ist auch eine Frage der Rücksicht auf die Ursprungs-Website: Alle fünf Minuten etwas abzufragen, das sich einmal am Tag ändert, erzeugt nur Last.
In welchem Format bekomme ich die Daten? +
In Ihrer Datenbank, meist PostgreSQL, mit einem gemeinsamen Schema für alle Quellen, oder über eine REST API. Wir können auch regelmäßige CSV- oder JSON-Exporte erzeugen oder Änderungen per Webhook schicken.
Kann ich die Daten für ein KI-Modell nutzen? +
Ja, und das ist einer der häufigsten Einsätze: Die normalisierten Daten dienen als Grundlage für eine semantische Suche, ein RAG oder einen Agenten. Es gelten dieselben rechtlichen Grenzen wie bei jeder anderen Nutzung, und wir speichern zu jedem Datensatz die Ursprungs-URL und das Datum, damit sich die Quelle zitieren lässt.
Das könnte Sie auch interessieren
Schicken Sie uns Ihre Quellenliste
Senden Sie uns die URLs, von denen Sie Daten brauchen, und welche Felder Sie interessieren. Sie bekommen einen Steckbrief pro Quelle mit der Strategie, den Risiken und der Frequenz, die wir empfehlen.
Nennen Sie uns Ihre QuellenErzählen Sie uns Ihre Herausforderung. Wir schlagen die Lösung vor.
Unverbindlich. Innerhalb von 24 Stunden erhalten Sie ein Angebot mit Umfang, Zeitplan und Budget. Ohne Kleingedrucktes.