Die drei Wege zum Scraping: Überblick
Browser-Extensions und No-Code Web Scraper versprechen Start in Minuten: Punkt-und-Klick-Oberfläche, fertige Templates, Export nach Excel. Cloud-Dienste wie Apify oder Bright Data bieten vorgefertigte Scraper für populäre Seiten als Abo. Custom-Entwicklung bedeutet, dass ein Programmierer oder Studio einen Scraper speziell für die Zielseite schreibt – entweder intern oder als Auftrag.
Die Wahl hängt davon ab, wie oft sich die Zielseite ändert, ob sie Bot-Schutz einsetzt, wie viele Datensätze gebraucht werden und wer das Werkzeug bedienen soll. Eine falsche Entscheidung kostet schnell mehr Zeit und Geld als der vermeintlich teurere Weg von Anfang an.
Browser-Extensions: schnell, aber manuell
Extensions wie Web Scraper, Data Miner oder ParseHub Free laufen im eigenen Browser. Man klickt Felder an, definiert Listen und startet die Sammlung. Die Daten landen als CSV auf der Festplatte. Kostenlos bis ca. 500 Zeilen pro Lauf, darüber hinaus kostenpflichtige Versionen verfügbar.
Vorteil: kein Server nötig, keine Programmierung, funktioniert sofort für einfache Tabellen und Listen. Nachteil: läuft nur, solange der Browser offen ist; jede Änderung der Website erfordert manuelle Anpassung; bei mehreren tausend Zeilen wird der Browser träge oder stürzt ab. Für regelmäßige Updates unpraktisch.
No-Code-Plattformen: geführte Automation
Tools wie Octoparse, ParseHub Pro oder Apify bieten Cloud-Ausführung, Zeitplanung und visuelle Editoren. Man baut Workflows per Drag-and-Drop, die Plattform führt den Scraper auf eigenen Servern aus und liefert Daten per API oder Webhook.
Stärke: kein Hosting, eingebaute Proxy-Rotation, einfache Wartung für Standard-Seiten. Schwäche: begrenzte Anpassbarkeit bei Login-Flows, CAPTCHA oder komplexer JavaScript-Logik; Templates brechen, wenn die Zielseite redesignt wird, und die Plattform liefert kein automatisches Fix – der Nutzer muss den Workflow neu konfigurieren.
Wo No-Code Scraper Tools an Grenzen stoßen
No-Code-Lösungen scheitern typischerweise an vier Punkten: Bot-Schutz, Authentifizierung, Skalierung und laufende Wartung. Die Plattformen werben mit Einfachheit, verschweigen aber, dass viele reale Websites gezielt gegen automatisierte Zugriffe abgesichert sind.
Bot-Schutz und CAPTCHA
Große Portale setzen Cloudflare, DataDome oder reCAPTCHA ein. No-Code-Tools bieten zwar Proxy-Rotation, aber keine Anpassung der Browser-Fingerprints oder des Request-Timings. Ergebnis: Der Scraper wird nach wenigen Seiten blockiert oder liefert leere Ergebnisse. Manche Plattformen verkaufen CAPTCHA-Solving als Add-on – bei täglichen Läufen summiert sich das schnell.
Websites blockieren Scraper aus verschiedenen Gründen: Serverlast, Wettbewerbsschutz, Datenmonetarisierung. Ein Custom-Scraper kann Request-Header, Cookies und Pausen so anpassen, dass er wie normaler Traffic aussieht; ein No-Code-Tool läuft mit Standard-Einstellungen, die jeder Bot-Schutz erkennt.
Login und Sitzungsverwaltung
Sobald Daten hinter einem Login liegen – Preise im B2B-Bereich, Bestellhistorie, interne Verzeichnisse – wird es kompliziert. No-Code-Plattformen erlauben zwar einfache Formulareingaben, versagen aber bei Zwei-Faktor-Authentifizierung, OAuth-Flows oder Session-Tokens, die nach jeder Anfrage rotieren. Die eigene Zugangsberechtigung zu verwenden ist rechtlich unbedenklich; fremde Accounts zu nutzen oder Logins zu automatisieren, die in den AGB verboten sind, ist riskant und kann gegen § 202a StGB (Ausspähen von Daten) verstoßen.
Skalierung und Kosten pro Datensatz
No-Code-Abos rechnen nach Laufzeit oder Requests ab. Wer täglich 50.000 Datensätze von mehreren Quellen sammelt, zahlt schnell hohe monatliche Gebühren – plus Setup-Zeit für jeden neuen Workflow. Ein Custom-Scraper kostet in der Entwicklung mehr, verursacht im Betrieb aber nur Server- und Wartungskosten bei normaler Last.
Beispiel: Tägliches Monitoring von 20 Marktplätzen mit je 2.500 Produkten. No-Code-Plattform: 20 Workflows à 15 Minuten Setup, laufende Abo-Kosten, manuelle Anpassung bei jeder Layout-Änderung. Custom: einmalige Entwicklungskosten, danach automatische Läufe und zentrale Wartung für alle 20 Quellen.
Custom-Scraper: wann sich Entwicklung lohnt
Ein maßgeschneiderter Scraper ist Code, der genau eine Aufgabe erfüllt: Daten von bestimmten Seiten holen, validieren und in ein definiertes Format bringen. Er läuft auf einem eigenen Server oder als Cloud-Funktion, verwendet spezialisierte Bibliotheken (Playwright, Puppeteer, Scrapy) und kann jede Logik abbilden, die ein Mensch im Browser ausführen würde.
Entwicklung lohnt sich bei: regelmäßigem Bedarf (wöchentlich oder häufiger), Seiten mit Schutz oder komplexer Struktur, mehreren Quellen, die einheitlich verarbeitet werden sollen, und wenn die Daten direkt in bestehende Systeme (CRM, Datenbank, Automatisierungs-Workflows) fließen müssen.
Vorteile gegenüber No-Code
- Volle Kontrolle über Request-Timing, Header, Cookies und Fehlerbehandlung – der Scraper passt sich dem Schutz der Seite an, nicht umgekehrt
- Automatische Wartung möglich: Wenn die HTML-Struktur sich ändert, kann der Scraper auf alternative Selektoren ausweichen oder Warnungen senden
- Direkte Integration: Daten gehen per API oder Webhook in Echtzeit ins Zielsystem, ohne manuelle Exports
- Skalierung: Ein Scraper kann parallel hunderte Seiten verarbeiten, ohne dass jede einzeln konfiguriert werden muss
- Eigentum: Der Code gehört dem Auftraggeber, keine Abhängigkeit von einer Plattform, die den Dienst einstellen oder Preise erhöhen kann
Typische Entwicklungskosten
Ein Scraper für eine einzelne Website ohne Login und mit Standard-Schutz benötigt 3–7 Tage Entwicklungszeit. Mit komplexem JavaScript-Rendering, Pagination oder Login steigt der Aufwand auf 1–2 Wochen. Danach fallen Wartungskosten an: 10–15 % des Projektpreises pro Monat für Fixes bei Layout-Änderungen und Server-Monitoring, oder man übernimmt die Wartung intern.
Fertige Scraper für über 5.400 Websites bieten eine Zwischenlösung: weniger Entwicklungszeit als Custom, aber anpassbar an individuelle Felder und Output-Formate. Ein neuer Scraper ist in 2–5 Werktagen betriebsbereit, Preis ab 229 € für einmalige Exporte bis 10.000 Datensätze oder ab 129 € monatlich für wöchentliche Updates inklusive Wartung.
Scraping-as-a-Service: extern betreute Datensammlung
Manche Studios und Agenturen bieten Scraping als laufenden Service: Der Kunde definiert, welche Daten er braucht, der Anbieter entwickelt und betreibt den Scraper, liefert die Daten nach Zeitplan und kümmert sich um Wartung. Das Modell ähnelt einem Abo, beinhaltet aber individuelle Anpassung statt vorgefertigter Templates.
Vorteil: kein internes Know-how nötig, keine Server-Verwaltung, garantierte Lieferung auch bei Website-Änderungen. Nachteil: laufende Kosten, und der Scraper bleibt meist Eigentum des Anbieters – wechselt man den Dienstleister, muss die Lösung neu gebaut werden.
Sinnvoll, wenn internes Scraping-Know-how fehlt, das Datenvolumen überschaubar ist (unter 100.000 Datensätze monatlich) und man bereit ist, langfristig zu zahlen. Wer plant, die Datensammlung später intern zu übernehmen, sollte im Vertrag klären, ob der Code ausgehändigt wird.
Total Cost of Ownership: Rechenbeispiel über 12 Monate
Szenario: Ein E-Commerce-Unternehmen will täglich Preise und Verfügbarkeit von 5.000 Produkten bei zehn Wettbewerbern überwachen. Jeder Wettbewerber betreibt einen eigenen Webshop, keine API verfügbar, leichter bis mittlerer Bot-Schutz. Ziel: Daten in eine interne Datenbank, Alarm bei relevanten Preisänderungen.
Option 1: No-Code-Plattform
- Setup: 10 Workflows à 20 Minuten, intern = ca. 3 Stunden Arbeitszeit
- Laufende Abo-Kosten für die nötige Laufzeit und Requests
- Wartung: Bei jeder Website-Änderung (im Schnitt 2× pro Jahr pro Seite) 30 Minuten Anpassung = 20 Anpassungen × 0,5 h = 10 Stunden intern
- CAPTCHA-Solving: zusätzliche Kosten bei Bedarf
Problem: Zwei der Wettbewerber führen Cloudflare-Schutz ein, das No-Code-Tool wird blockiert. Zusätzliches Add-on für Residential Proxies erhöht die monatlichen Kosten deutlich. Zeit für Trial-and-Error kommt hinzu.
Option 2: Custom-Entwicklung
- Entwicklung: 10 Scraper, alle Seiten mit allen Schutzmaßnahmen, einheitliche API
- Server: monatliche VPS- und Proxy-Kosten
- Wartung: 10–15 % der Entwicklungskosten jährlich (inklusive Fixes bei allen Layout-Änderungen innerhalb 48 Stunden)
Höhere Anfangsinvestition, aber nach 18 Monaten günstiger als No-Code. Die Lösung gehört dem Unternehmen, kann intern erweitert werden und läuft ohne monatliche Plattform-Gebühr weiter.
Option 3: Scraping-as-a-Service
- Setup: einmalige Kosten (alle zehn Quellen, gehostete Lösung, Dashboard)
- Laufendes Abo mit monatlicher Gebühr
Mittlere Kosten, kein interner Aufwand, aber der Code bleibt beim Anbieter. Bei Vertragswechsel oder Insolvenz des Dienstleisters muss neu entwickelt werden.
Rechtliche Stolpersteine und Wartungsaufwand
Technisch funktionierender Scraper heißt nicht automatisch rechtlich sauberer Scraper. Web Scraping ist in Deutschland grundsätzlich legal, solange öffentlich zugängliche Daten gesammelt werden, keine Zugangssperren umgangen werden und die Daten nicht gegen Urheberrecht oder Datenbankschutzrecht (§§ 87a ff. UrhG) verstoßen. Personenbezogene Daten unterliegen der DSGVO – Name, Adresse, E-Mail dürfen nur mit Rechtsgrundlage verarbeitet werden.
No-Code-Tools prüfen nicht, ob eine Zielseite in ihren AGB Scraping verbietet oder ob die gesammelten Daten weiterverwendet werden dürfen. Die Plattform haftet nicht, der Nutzer schon. Vor jedem Scraping-Projekt sollte geprüft werden: Sind die Daten öffentlich? Verbieten die AGB automatisierte Zugriffe ausdrücklich? Werden personenbezogene Daten gesammelt, und wenn ja, wozu? Bei Unsicherheit Anwalt für IT-Recht oder Datenschutzbeauftragten hinzuziehen.
Wartung: der unterschätzte Kostenfaktor
Websites ändern sich. Ein Relaunch, neue CSS-Klassen, umbenannte Felder oder geändertes JavaScript brechen den Scraper. No-Code-Nutzer müssen den Workflow händisch reparieren – oft ohne Vorwarnung, weil die Plattform die Seite nicht überwacht. Bei zehn Quellen und durchschnittlich drei Änderungen pro Jahr sind das 30 manuelle Eingriffe.
Custom-Scraper können defensiv programmiert werden: mehrere Selektoren als Fallback, automatische Benachrichtigung bei unerwarteten Strukturen, Unit-Tests gegen gespeicherte HTML-Snapshots. Ein gutes Studio bietet Wartungsverträge, die Fixes innerhalb von 48 Stunden garantieren – der Kunde bekommt weiterhin Daten, ohne sich um Details zu kümmern.
Wer intern entwickelt, sollte mindestens 10 % der Entwicklungszeit pro Jahr für Wartung einplanen. Ein Scraper, der 40 Stunden Entwicklung gekostet hat, braucht etwa 4 Stunden jährlich für Updates – vorausgesetzt, die Zielseiten ändern sich moderat.
Entscheidungs-Checkliste: welches Werkzeug passt
Die Wahl hängt von sechs Faktoren ab: Häufigkeit, Datenmenge, Komplexität der Zielseite, internes Know-how, Budget und strategischer Bedeutung der Daten.
- Einmalige oder seltene Sammlung (alle paar Monate), unter 5.000 Datensätze, einfache Tabellen ohne Login → Browser-Extension oder No-Code-Free-Tier reicht aus
- Regelmäßig (wöchentlich), mittlere Menge (5.000–50.000 Datensätze), moderate Struktur, kein starker Bot-Schutz → No-Code-Plattform mit Abo ist praktikabel, wenn Wartungsaufwand akzeptabel ist
- Täglich oder Echtzeit, große Menge (über 50.000), mehrere Quellen, mittlerer bis starker Bot-Schutz → Custom-Scraper amortisiert sich innerhalb eines Jahres
- Login erforderlich, komplexes JavaScript, CAPTCHA, Cloudflare → Custom-Entwicklung oder spezialisierter Service, No-Code scheitert meist
- Strategisch wichtig (Pricing, Wettbewerbsanalyse, Kerndaten für Geschäftsmodell) → Custom oder Service mit SLA, um Ausfallrisiko zu minimieren
- Intern kein Entwickler verfügbar, kein Server-Know-how → Scraping-as-a-Service oder fertiger Scraper mit Wartung buchen
Hybride Ansätze sind möglich: Start mit No-Code für schnellen Proof-of-Concept, dann Umstieg auf Custom, sobald das Datenvolumen oder die Anforderungen steigen. Wichtig ist, die Grenzen jeder Option realistisch einzuschätzen, bevor man monatelang an eine Plattform gebunden ist, die nicht liefern kann.
Wie Kodrana bei der Werkzeugwahl hilft
Wir bieten beide Wege: Fertige Scraper für über 5.400 Websites, die in 2–5 Tagen einsatzbereit sind, und Custom-Entwicklung für individuelle Anforderungen. Vor der Entscheidung prüfen wir kostenlos, welchen Schutz die Zielseite einsetzt und ob ein fertiger Scraper ausreicht oder Custom nötig ist. Eine Testlieferung von 50–100 Datensätzen zeigt, ob Struktur und Qualität stimmen – ohne Vorabzahlung.
Fertige Exporte starten ab 229 € für bis zu 10.000 Datensätze, Abo-Modelle mit wöchentlichen oder täglichen Updates ab 129 € monatlich inklusive Wartung innerhalb von 48 Stunden bei Website-Änderungen. Custom-Projekte bekommen ein Festpreisangebot vor Start, 50 % Anzahlung und den Rest nach Abnahme, wöchentliche Demos während der Entwicklung. Anfrage per Telegram @kodrana oder über das Formular auf der Seite.
FAQ
Kann ein No-Code Web Scraper Cloudflare-geschützte Seiten sammeln?
Die meisten No-Code-Plattformen scheitern an modernem Bot-Schutz wie Cloudflare oder DataDome, weil sie Standard-Browser-Fingerprints verwenden. Manche bieten Add-ons für Residential Proxies oder CAPTCHA-Solving, was aber die Kosten erhöht und nicht immer zuverlässig funktioniert. Custom-Scraper können Request-Header, Timing und Cookies so anpassen, dass sie Bot-Schutz umgehen, ohne gegen AGB zu verstoßen.
Wie lange dauert die Entwicklung eines Custom-Scrapers?
Für eine einzelne Website ohne Login und mit Standardschutz 3–7 Tage. Mit komplexem JavaScript-Rendering, Login-Flow oder mehreren Seitentypen 1–2 Wochen. Fertige Scraper aus einem Katalog sind oft in 2–5 Werktagen verfügbar, weil die Grundstruktur bereits existiert und nur an die spezifischen Felder angepasst wird.
Was passiert, wenn die Zielseite ihr Layout ändert?
Bei No-Code-Tools muss der Nutzer den Workflow manuell reparieren – die Plattform überwacht Layout-Änderungen nicht. Bei Custom-Scrapern mit Wartungsvertrag kümmert sich der Entwickler oder das Studio um Fixes, meist innerhalb von 48 Stunden. Gut programmierte Scraper verwenden mehrere Selektoren als Fallback und senden Warnungen, bevor sie komplett ausfallen.
Ist es legal, Preise von Wettbewerbern automatisiert zu sammeln?
Ja, sofern die Daten öffentlich zugänglich sind und keine Zugangssperren umgangen werden. Viele Websites verbieten Scraping in ihren AGB, was zivilrechtliche Folgen haben kann, aber nicht automatisch strafrechtlich relevant ist. Personenbezogene Daten (Namen, Adressen) unterliegen der DSGVO und dürfen nur mit Rechtsgrundlage verarbeitet werden. Vor größeren Projekten empfiehlt sich eine rechtliche Prüfung durch einen Anwalt für IT-Recht.
Wann lohnt sich ein Scraping-Abo statt einmaliger Entwicklung?
Wenn die Daten regelmäßig aktualisiert werden müssen (täglich oder wöchentlich), man keine Server-Infrastruktur betreiben möchte und Wartung extern bleiben soll. Abo-Modelle inklusive Wartung sind sinnvoll für fortlaufende Preisüberwachung, Bestandsaktualisierungen oder Marktanalysen. Einmalige Exporte reichen für Ad-hoc-Recherchen, Datensatz-Aufbau oder seltene Analysen.