Eine GitHub-Suche nach „amazon scraper“ wirft rund 3.515 Repositories aus. Filtert man auf Repos, die in den letzten sechs Monaten gepusht wurden, bleiben gerade einmal 727 – knapp 20 %. Der Rest: aufgegebene Tutorials, veraltete Wrapper und Skripte, die in dem Moment stehen blieben, als Amazon seine Abwehr hochfuhr.
Ich habe reichlich Zeit damit verbracht, Amazon-Scraper-Repos zu durchforsten, GitHub-Issues zu lesen und Community-Threads auf Reddit und Stack Overflow zu verfolgen. Das Muster wiederholt sich: Jemand stößt auf ein populäres Repo, investiert eine Stunde ins Setup, startet es einmal – und steht sofort vor einer Wand aus CAPTCHAs oder 503-Fehlern. Amazons Anti-Bot-Strategie sieht 2026 völlig anders aus als noch vor zwei Jahren: TLS-Fingerprinting, Verhaltensanalyse und der aggressive Einsatz von CAPTCHAs haben das alte Rezept „User-Agents rotieren und das Beste hoffen“ praktisch wertlos gemacht. Dieser Leitfaden zeigt die Best Practices, die wirklich zählen, wenn du verlässliche Amazon-Daten aus einem GitHub-Repo ziehen willst – und was zu tun ist, wenn dein Scraper bricht (nicht: falls).
Was ist ein Amazon Scraper auf GitHub – und warum scheitern so viele?
Ein Amazon-Scraper-Repo auf GitHub ist typischerweise ein Open-Source-Skript – meist auf Basis von Python, Node.js oder Scrapy –, das strukturierte Daten von Amazon-Seiten herauszieht. Die Zielfelder sind vertraut: Produkttitel, Preis, ASIN, Bewertung, Anzahl der Rezensionen, Verfügbarkeit, Verkäuferinfos, Suchergebnis-Kacheln und Rezensionstexte.
Die Architektur ist meist überschaubar:
- Ein HTTP-Client oder ein Headless Browser lädt die Seite.
- Ein HTML- oder JSON-Parser zieht die Felder heraus.
- Die Daten landen als CSV, JSON oder in einer Datenbank.
Grob lassen sich die Repos in vier Gruppen einteilen:
- Leichtgewichtige Python-Bibliotheken (etwa amzpy)
- Scrapy-Spider (etwa amazon-python-scrapy-scraper)
- Browser-Automatisierer mit Selenium oder Playwright
- API-Wrapper-Projekte, die in Wahrheit nur Frontends für einen kommerziellen Scraping-Dienst sind (etwa oxylabs/amazon-scraper)
Das Ausfallmuster ist vorhersehbar. Die meisten Repos brechen, weil:
- Amazon das Seitenlayout oder einzelne HTML-Fragmente umbaut
- Amazon statt echter Inhalte einen 503 oder ein CAPTCHA ausliefert
- der TLS- und HTTP-Fingerprint des Scrapers nicht mehr nach Browser aussieht
- Abweichungen bei Locale, Sprache oder Headern Misstrauen wecken
- der Maintainer nach der Lösung seines ursprünglichen, eng gefassten Anwendungsfalls weiterzieht
Viele Sterne und „gerade noch lauffähig“ sind zwei völlig verschiedene Dinge. In dem Audit für diesen Artikel wirkten nur etwa drei von acht weit verbreiteten Repos im Jahr 2026 eindeutig aktiv.
Mach 2026 einen Frische-Check, bevor du irgendein Amazon-Scraper-Repo klonst
Bei Amazon ist dieser Schritt wichtiger als bei den meisten anderen Zielen. Amazons Schutzmechanismen ändern sich schneller als bei einer typischen E-Commerce-Seite, sodass ein Repo, das auf einer schlichten Firmenwebsite anstandslos läuft, auf Amazon schon nach wenigen Wochen unbrauchbar sein kann. Trotzdem empfehlen die meisten „best amazon scraper github“-Listen Repos, ohne zu prüfen, ob sie überhaupt noch funktionieren. Nutzer verlieren dadurch stundenlang Zeit mit kaputten Tools.
So prüfst du, ob ein GitHub-Repo noch lebt
Bevor du etwas mit git clone holst, geh diese Punkte durch:
- Datum des letzten Commits: Alles, was älter als 6 Monate ist, ist bei Amazon ein klares Warnsignal.
- Offene Issues und Reaktionsquote: Durchsuche den Issues-Tab nach „captcha“, „503“, „blocked“ und „not working“. Häufen sich solche Meldungen, ohne dass der Maintainer reagiert, lass besser die Finger davon.
- Zustand der Abhängigkeiten: Öffne
requirements.txtoderpackage.json. Veraltete Bibliotheken (etwa altesrequestsohne moderne TLS-Unterstützung) sind ein Alarmzeichen. - Abdeckung der Amazon-Seitentypen: Beherrscht das Repo Produktseiten, Suchergebnisse und Rezensionen? Oder nur einen Typ?
- Anti-Bot-Ansatz: Fest verdrahtete Header ohne Proxy-Unterstützung sind ein Ansatz von 2023 – der 2026 nicht mehr lange trägt.
Frische-Checkliste für Amazon-Scraper auf GitHub
| Frischesignal | Was prüfen | Warnsignal 🚩 |
|---|---|---|
| Datum des letzten Commits | Commit-Feed oder Repo-Push-Datum | Älter als 6 Monate |
| Offene Issues | Issues-Tab — nach „captcha“, „503“, „blocked“ filtern | Wiederholte Ausfälle ohne Antwort des Maintainers |
| Gesundheit der Abhängigkeiten | requirements.txt / package.json | Veraltete Bibliotheken, keine moderne TLS-Strategie |
| Amazon-Seitenabdeckung | README + Codebeispiele | Unterstützt nur einen Seitentyp (z. B. Produktseiten, aber nicht Suche oder Rezensionen) |
| Anti-Bot-Ansatz | Quellcode, Proxy-Konfiguration | Nur hart codierte Header und UA-Strings |
| Wartungsmodell | Ist es ein echter Scraper, ein Tutorial oder ein kommerzieller API-Wrapper? | Repo ist in Wahrheit nur ein Frontend für einen bezahlten Dienst |
Was das Audit tatsächlich gezeigt hat
Ich habe acht weit verbreitete Amazon-Scraper-Repos nach diesen Kriterien geprüft. Das Ergebnis ist ernüchternd:
| Repo / Tool | Sterne | Signal des letzten Commits | Umfang | Status 2026 | Hinweise |
|---|---|---|---|---|---|
| oxylabs/amazon-scraper | ~2.872 | 2026-04-02 | Verwalteter Scraper-API-Wrapper | Aktiv, aber nicht DIY | Aktuell, aber in Wahrheit ein Frontend für einen Managed Service |
| omkarcloud/amazon-scraper | ~214 | 2026-02-25 | Verwaltete API für Suche, Details, Rezensionen | Aktiv, aber nicht DIY | Gute Abdeckung, aber ein API-Produkt, kein roher Scraper |
| theonlyanil/amzpy | ~110 | 2026-02-26 | Leichtgewichtige Python-Bibliothek | Aktiv | Der klarste direkte GitHub-Scraper mit curl_cffi |
| philipperemy/amazon-reviews-scraper | ~134 | 2024-11-21 | Nur Rezensionen | Eingeschränkt, aber nutzbar | Alt und sehr auf Rezensionen fokussiert |
| python-scrapy-playbook/amazon-python-scrapy-scraper | ~74 | Letzter Commit 2023; Repo gepusht 2024-08-20 | Scrapy-Spiders + Proxy-Middleware | Tutorial-Niveau, alternd | Gut zum Lernen, aber kein fertiger 2026-Stack |
| drawrowfly/amazon-product-api | ~744 | 2022-11-13 | Node-CLI für Suche, Details, Rezensionen | Hohes Risiko | Große Abdeckung, aber die Wartung ist zu alt |
| tducret/amazon-scraper-python | ~881 | 2020-10-13 | Suche nach CSV | Für 2026 tot | Historisch beliebt, heute klar veraltet |
| scrapehero-code/amazon-scraper | ~432 | 2020-06-21 | Such-/Produkt-Tutorial | Für 2026 tot | Praktisch Archivmaterial |
Die öffentlichen Issues erzählen dieselbe Geschichte. drawrowfly/amazon-product-api hat ein Issue mit dem Titel „All requests receive captcha response.“ Bei theonlyanil/amzpy findet sich „Doesn't seem to be working.“ Der Scraper von python-scrapy-playbook fragt nach „Bypass Amazon protection.“ Das sind keine exotischen Sonderfälle, sondern genau die ersten Hürden, an denen Nutzer hängen bleiben.
Der Anti-Ban-Plan: So vermeidest du Sperren mit einem Amazon-Scraper von GitHub
Geblockt zu werden ist der größte Schmerzpunkt für alle, die ein Amazon-Scraper-Projekt von GitHub einsetzen. Allgemeine Ratschläge wie „nutze Proxies und rotiere User-Agents“ greifen längst zu kurz. Amazons Anti-Bot-Stack für 2025–2026 umfasst TLS-Fingerprinting, Verhaltensanalyse und den aggressiven Einsatz von CAPTCHAs. Du brauchst einen mehrschichtigen Ansatz.
TLS-Fingerprinting: Warum dich simples requests in Schwierigkeiten bringt
Das ist eine der am häufigsten übersehenen Anti-Ban-Techniken. TLS-Fingerprinting läuft so: Öffnet dein Skript eine sichere Verbindung zu Amazon, verrät schon das Verhalten beim Handshake einiges über den Client – angebotene Cipher Suites, Reihenfolge der Extensions, HTTP/2-Einstellungen. Browser nutzen relativ feste TLS- und HTTP/2-Parameter, und genau solche Kombinationen lassen sich mit Verfahren wie JA3 und Akamai HTTP/2 Fingerprints identifizieren.
Normales requests und gewöhnliches httpx können Header kopieren, aber nicht das Chrome-ähnliche TLS- und HTTP/2-Verhalten. Amazon merkt den Unterschied.
curl_cffi setzt genau hier an. Es bietet Browser-Impersonation – unterstützt werden unter anderem chrome136, safari184 und firefox133 –, sodass der TLS-Fingerprint deines HTTP-Clients wie der eines echten Browsers wirkt. Die Doku warnt ausdrücklich davor, zufällige JA3-Strings zu erzeugen: Browser-Fingerprints sind pro Version weitgehend fest, und zufälliger Unsinn fällt leichter auf als ein kopierter, echter Fingerprint.
Auch die Community-Daten passen ins Bild. Ein Reddit-Thread zu curl_cffi + Amazon bestätigt, dass der impersonate-Parameter hilft, weil er Browser-Profile rotiert und Header sauber abstimmt. Ein weiterer Reddit-Thread berichtet, dass Amazon Clients anhand des TLS-Fingerprints „nach ungefähr ein oder zwei Monaten“ blockiert. Ein Stack-Overflow-Thread fragt sogar direkt, ob Amazon python-requests fingerprintet (Spoiler: ja).
Wenn du also weiterhin normales requests als ersten Amazon-Client einsetzt, ändere diese Annahme zuerst – noch vor jeder anderen Optimierung.
Proxy-Rotation richtig gemacht (nicht einfach nur „Proxies nutzen“)
Bei Proxies geht es nicht darum, möglichst oft zu rotieren, sondern darum, Sitzungen glaubwürdig wirken zu lassen.
Residential oder Datacenter: Datacenter-Proxies sind günstiger, aber leichter zu erkennen. Residential-Proxies kosten mehr, lassen sich für Amazon aber deutlich schwerer markieren. Bright Datas Residential-Preise starten im Pay-as-you-go bei 4,00 $/GB und sinken bei größeren Plänen auf 3,50 $/GB. Oxylabs Residential beginnt bei 6 $/GB. Amazon zählt klar zu den „anspruchsvollen Zielen“, bei denen Residential-Proxies den Aufpreis wert sind.
Rotation pro Anfrage oder pro Sitzung: Hier liegen die meisten Tutorials daneben. Den Proxy bei jeder Anfrage zu wechseln, während Cookies und Header gleich bleiben, wirkt eher weniger menschlich als mehr. Das sicherere Muster:
- Suche → Produkt → Rezensionen möglichst innerhalb derselben Sticky Session durchlaufen
- Sitzungen wechseln, wenn du eine neue Suchreise beginnst, nicht bei jeder Anfrage
- zwischen Sitzungen rotieren, nicht zufällig innerhalb einer einzelnen Browsing-Session
Ein Reddit-Kommentar merkte an, dass normale ISP-IPs auf beliebten E-Commerce-Seiten spürbar schlechter abschnitten als mobile IPs. Ein anderer Thread berichtete von Sperren trotz rotierender User-Agents und Residential-Proxies – eine gute Erinnerung daran, dass Proxies allein nicht reichen.
Anfrage-Taktung, Backoff und Rate Limiting
Amazons 503-Seiten sind kein Zufall. Sie sind Rückmeldung.
Ein Stack-Overflow-Beitrag zum Scraping von über 500 ASINs berichtete, dass der 503 immer an derselben Stelle auftrat – etwa bei ASIN 101 – sogar mit Pausen. Das Muster ist alt, die Lehre aktuell: Reines Volumen von einer IP oder einem Fingerprint wird irgendwann abgefangen.
Bewährte Taktung für DIY-Scraper von GitHub:
- Zufällige Verzögerungen zwischen Anfragen (keine festen, erkennbaren Intervalle)
- 2 bis 5 Sekunden zwischen öffentlichen Produktanfragen bei einfachen HTTP-Clients
- Exponentielles Backoff nach 503 oder CAPTCHA – also schrittweise zurückfahren statt sofort erneut versuchen
- Niedrigere Parallelität, als du zu brauchen glaubst
- Fail-open-Logging statt enger Retry-Schleifen
Die meisten Amazon-Scraper-Repos auf GitHub bringen kein Rate Limiting mit. Das musst du selbst ergänzen.
Header-Orchestrierung: mehr als nur User-Agent-Strings
Amazon prüft den gesamten Header-Satz, nicht nur den User-Agent.
Ein realistischer Browser-Header-Satz sollte enthalten:
User-AgentAcceptAccept-LanguageAccept-EncodingSec-CH-*-Hinweise, wo sinnvoll- ein Verbindungsverhalten, das zum gewählten Browser-Profil passt
Die Header müssen zur Marketplace-Locale passen. Ein Reddit-Nutzer, der 10 Amazon-Länderversionen scrapt, stellte fest, dass dieselbe Bot-Konfiguration nur in einigen Ländern erkannt wurde; ein anderer Kommentar verwies auf regionsabhängige Header wie Accept-Language.
Die Regel: Header, TLS-/Browser-Profil und Proxy-Geografie dürfen sich nicht widersprechen. Schicke keine Chrome-Header mit einer Firefox-UA. Kombiniere keinen US-Proxy mit Accept-Language: de-DE.
CAPTCHA-Behandlung: wann lösen, wann zurückfahren
Ein CAPTCHA bedeutet, dass Amazon bereits Verdacht geschöpft hat. Es zu lösen setzt deinen Vertrauenswert nicht zurück.
Für einzelne, seltene CAPTCHA-Fälle:
- Das PyPI-Paket
amazoncaptchaist ein reiner Python-Solver für Amazon-Text-CAPTCHAs, auch wenn die jüngste Version von Mai 2023 stammt – behandle es als taktisches Hilfsmittel, nicht als Dauerstrategie - 2Captcha führt Amazon Captcha mit 0,45 $ pro 1.000 Lösungen
Für wiederholte CAPTCHA-Schleifen:
- nicht weiter lösen, sondern den Abstand vergrößern
- wiederholte CAPTCHAs heißen, die Sitzung ist verbrannt – das Lösen stellt weder Fingerprint noch Sitzungsverlauf oder IP-Reputation wieder her
- ballen sich CAPTCHAs nach Proxy-Subnetzen, liegt das Problem in der Netzwerkschicht, nicht im Parser
Wann du wirklich einen Headless Browser brauchst – und wann nicht
Der falsche Reflex ist, für alles gleich Playwright zu starten.
Gute Browser-Anwendungsfälle:
- Suchergebnisse, die JavaScript-Rendering oder locale-abhängigen Zustand brauchen
- Rezensions-Flows, die auf Login- oder Anmeldeseiten umleiten
- Workflows, bei denen Cookies und Browser-Kontext wichtiger sind als reines Tempo
Schlechte Browser-Anwendungsfälle:
- normale öffentliche Produktseiten
- statische Produktdetail-Extraktion, für die ein browserähnlicher HTTP-Client genügt
- groß angelegte Massenerfassung, bei der Recheneffizienz zählt
Starte mit dem leichtesten Client, der funktioniert. Ein Reddit-Thread zum Scraping im großen Maßstab beschreibt die Reihenfolge: erst requests, dann curl_cffi – und erst dann ein vollständiger Browser, wenn die leichteren Wege scheitern. Headless Browser sind für das Scraping von Amazon-Produktseiten spürbar langsamer und ressourcenhungriger als HTTP-Clients.
Anti-Ban-Entscheidungsmatrix für Amazon-Scraper-Projekte von GitHub
| Szenario | Empfohlener Ansatz | Warum |
|---|---|---|
| Öffentliche Produktseiten (kleiner Umfang) | curl_cffi + Sticky Residential Session | Günstigster Weg, der trotzdem wie ein Browser wirkt |
| Suchergebnisseiten | Erst curl_cffi, Playwright nur bei Rendering- oder State-Problemen | Suche ist zustandsbehafteter und stärker lokalisierungsabhängig |
| Rezensionen (Login erforderlich) | Browser-Modus mit echten Cookies/Sitzung | Login- und dynamische Review-Flows sind mit reinem HTTP schwerer nachzubilden |
| Großer Umfang (5k+ täglich) | Managed Scraper API, Unlocker oder No-Code-Plattform | Reiner DIY-GitHub-Code wird dann zum Infrastrukturproblem |
Wenn dein Amazon-Scraper-Projekt von GitHub bricht: Leg dir einen No-Code-Plan B zu
Jeder erfahrene Scraper hat einen Plan B.
Amazon-Updates zerlegen früher oder später jedes GitHub-Repo – und das im ungünstigsten Moment. Für E-Commerce-Teams heißt ein kaputter Scraper: verpasste Preisänderungen, veraltete Wettbewerbsdaten und Lücken in den Dashboards.
Viele, die nach „amazon scraper github“ suchen, sind in Wahrheit Business-Anwender – E-Commerce-Operations, Marketer, FBA-Researcher –, die Programmierlösungen ausprobiert haben, weil ihnen keine bessere Option begegnet ist. Auch Amazons offizielle Product Advertising API sorgt in Foren für spürbaren Frust: eingeschränkter Zugang, begrenzte Daten und Registrierungsanforderungen, die viele Händler nicht erfüllen können.
Warum Amazon-Scraper von GitHub ständige Pflege brauchen
Das Audit weiter oben macht es deutlich:
- veraltete Repos sammeln immer mehr Fehlerberichte, ohne dass etwas gefixt wird
- „funktionierende“ Repos sprechen im README inzwischen offen über Anti-Bot-Maßnahmen
- Community-Threads drehen sich zunehmend um TLS-Fingerprints, CAPTCHA-Schleifen und Proxy-Qualität – nicht mehr um CSS-Selektoren
Für Business-Anwender ist dieser Pflegeaufwand der eigentliche versteckte Kostenpunkt. Das Repo ist kostenlos. Deine Debugging-Zeit um 2 Uhr nachts ist es nicht.
Thunderbit als praktische Alternative fürs Amazon-Scraping
Thunderbit bringt eine Amazon-Products-Scraper-Vorlage mit, die Titel, Preis, ASIN, Bewertung, Marke, Verfügbarkeit, Versandherkunft und die Original-URL herauszieht – ganz ohne Code.
So sieht das in der Praxis aus:
- Scraping in 2 Klicks, statt Python-Umgebungen, Abhängigkeiten und Proxy-Konfigurationen aufzusetzen
- sofort einsatzbereite Amazon-Vorlage – kein KI-Overhead, einfach Extraktion mit 1 Klick
- Browser-Scraping-Modus für Seiten mit Login-Pflicht (etwa Review-Seiten, die Nutzer von GitHub-Scrapern zur Verzweiflung bringen)
- Cloud-Scraping für öffentliche Produktseiten in hoher Geschwindigkeit (50 Seiten auf einmal)
- kostenloser Export nach Google Sheets, Airtable, Notion und Excel – nicht nur CSV/JSON
- geplanter Scraper für laufendes Preis-Monitoring
- KI passt sich Layout-Änderungen an – kein Wartungsaufwand für dich
Amazon-Scraper von GitHub gegen Thunderbit: ein ehrlicher Vergleich
| Faktor | GitHub-Scraper (z. B. AmzPy) | Thunderbit |
|---|---|---|
| Einrichtungszeit | 15–60 Min. (Python, Abhängigkeiten, Proxies) | ~2 Min. (Chrome-Erweiterung installieren) |
| Wartung | Du behebst Brüche selbst | KI passt sich Layout-Änderungen an |
| Anti-Bot-Behandlung | DIY (Proxies, Header, TLS) | Integriert (Cloud- und Browser-Modus) |
| Review-Scraping (eingeloggt) | Komplexes Sitzungsmanagement | Browser-Scraping-Modus |
| Datenexport | Nur CSV/JSON | Sheets, Airtable, Notion, Excel, CSV, JSON |
| Planung | DIY (cron, Airflow usw.) | Integrierter geplanter Scraper |
| Anpassbarkeit | Höher | Geringer |
| Kosten | Kostenlos (plus Proxy-Kosten) | Kostenlose Stufe verfügbar; kreditbasiert |
Der ehrliche Trade-off: GitHub-Repos bieten mehr Anpassbarkeit, Thunderbit mehr Verlässlichkeit. Zählt für dein Team Verfügbarkeit mehr als Flexibilität, ist der No-Code-Weg meist die vernünftigere Wahl.
Best Practices für geplantes und wiederkehrendes Amazon-Scraping
Die meisten Amazon-Scraper-Projekte auf GitHub sind auf Einmal-Läufe ausgelegt, doch echte Business-Fälle – Preisüberwachung, Bestandsverfolgung, Wettbewerbsanalyse – brauchen wiederkehrende Scrapes. GitHub-Repos bringen Scheduling fast nie nativ mit, also bastelt man sich Cron-Jobs, Airflow oder n8n-Workflows zusammen.
DIY-Scheduling für Amazon-Scraper von GitHub
Das minimale Setup für wiederkehrende Läufe:
- Cron-Job unter Linux oder macOS, der das Skript nach Zeitplan startet
- Append-only-Logs, damit sich Fehler im Nachhinein nachvollziehen lassen
- Deduplizierung über ASIN + Zeitstempel, damit keine doppelten Daten landen
- Fehleralarme (zur Not eine E-Mail bei einem Exit-Code ungleich null), damit du merkst, wenn ein Lauf um 3 Uhr nachts scheitert
Für komplexere Teams:
- n8n für leichte Workflow-Automatisierung (taucht in Community-Threads oft auf)
- Airflow für schwerere geplante Pipelines
- datenbankgestützter Zustand, wenn du Diffs und Historie brauchst
Die wichtigste Best Practice ist nicht der Scheduler selbst, sondern das State Management. Halte den letzten erfolgreichen Lauf, den letzten ASIN-Satz, geänderte Preise und fehlgeschlagene URLs nach.
Einfacheres Scheduling mit Thunderbit
Mit Thunderbits Scheduled Scraper beschreibst du das Intervall in normalem Deutsch, gibst die URLs ein und klickst auf „Planen“. Die KI übersetzt die natürliche Sprache in einen Cron-Plan – ohne technisches Setup. Für nicht-technische E-Commerce-Teams, die Preise oder Produktstarts der Konkurrenz im Blick behalten, senkt das den operativen Aufwand spürbar.
Best Practices für wiederkehrende Amazon-Scrapes
Diese gelten unabhängig vom eingesetzten Tool:
- nach ASIN + Zeitfenster deduplizieren – dasselbe Produkt nicht pro Lauf doppelt speichern
- Preise als Zahlen speichern, nicht als Rohstrings – das spart späteren Bereinigungsaufwand
- einen Scrape-Zeitstempel an jede Zeile hängen – für Trendanalysen unverzichtbar
- Deltas verfolgen, nicht nur den aktuellen Zustand – „Preis seit letzter Woche um 12 % gefallen“ ist nützlicher als „Preis ist 24,99 $“
- bei relevanten Änderungen alarmieren – 15 % Preisrückgang bei einem Wettbewerber ist eine Meldung wert, 0,5 % Schwankung sind Rauschen
- über die Datenspeicherung nachdenken – Flat Files reichen für kleine Läufe; bei 5k+ ASINs pro Tag lohnt sich eine Datenbank oder eine Cloud-Spreadsheet-Lösung
Vergleich der Ausgabequalität: Was die Amazon-Scraper-Ansätze von GitHub wirklich liefern
Niemand vergleicht die tatsächliche Ausgabequalität der Amazon-Scraper-Repos auf GitHub. Nutzer legen großen Wert auf Datenqualität – „welches Tool liefert die saubersten, vollständigsten Daten?“ –, müssen aber jedes Repo selbst klonen und testen. Dieser Abschnitt schließt die Lücke.
Was beliebte GitHub-Repos tatsächlich herausziehen – und was ihnen fehlt
Auf Basis von README-Beispielen, öffentlichen Beispielen und dokumentierten Ausgabeformaten:
| Ansatz | Was klar extrahiert wird | Häufige Lücken / Kompromisse |
|---|---|---|
| amzpy | Titel, Preis, Währung, Bild-URL, Bewertungen, Rezensionen, Varianten, ASIN | Auf Produktseiten ausgerichtet; weniger umfangreich bei vollständigen Rezensionen/Specs |
| tducret/amazon-scraper-python | CSV mit Titel, Bewertung, Rezensionsanzahl, Produkt-URL, Bild-URL, ASIN | Veraltet, auf Listings fokussiert, schwache Anti-Bot-Story |
| python-scrapy-playbook scraper | Suchergebnisse, Produktseiten, Rezensionen, CSV/JSON-Pipelines | Tutorial-Niveau; verlässt sich auf externe Proxy-Middleware; mehr Nacharbeit wahrscheinlich |
| omkarcloud/amazon-scraper | Suche, Kategorie, Details, Top-Rezensionen, viele Bilder/Videos/Specs | Kein roher Scraper — es ist ein verwalteter API-Dienst |
| Thunderbit Amazon template | Titel, Preis, ASIN, Marke, Bewertung, Rezensionen, Verfügbarkeit, Versandherkunft, Anreicherung über Unterseiten | Weniger Code-Kontrolle als bei eigenen Skripten |
Vergleichstabelle der Ausgabequalität
| Datenfeld | AmzPy | Scrapy-basiertes Repo | Selenium-Repo | Thunderbit |
|---|---|---|---|---|
| Produkttitel | ✅ | ✅ | ✅ | ✅ |
| Preis (numerisch) | ⚠️ String | ✅ | ⚠️ String | ✅ (Zahlentyp) |
| Bewertung | ✅ | ✅ | ✅ | ✅ |
| Anzahl der Rezensionen | ❌ | ✅ | ✅ | ✅ |
| ASIN | ✅ | ✅ | ✅ | ✅ |
| Produktbilder | ❌ | ⚠️ nur Thumbnail | ✅ | ✅ (hochauflösend, exportierbar) |
| Inhaltsstoffe/Specs | ❌ | ❌ | ❌ | ✅ (über Unterseiten-Scraping + KI) |
| Export nach Sheets/Airtable | ❌ | ❌ | ❌ | ✅ kostenlos |
Warum Datenformatierung für Business-Anwender zählt
Unsaubere Daten erzeugen versteckte Mehrarbeit. Selbst ein erfolgreicher Scraper kann im Betrieb scheitern, wenn:
- Preise als Strings mit Währungssymbol statt als saubere Zahlen abgelegt werden
- fehlende Werte uneinheitlich sind (leerer String vs. null vs. „N/A“)
- Bilder nur in geringer Auflösung vorliegen
- Rezensionen oder Specs vor der Analyse erst nachbearbeitet werden müssen
Für E-Commerce-Operations-Teams wirken saubere Daten direkt auf Analysetempo und Entscheidungen. Thunderbits KI formatiert Daten nach Typ – Zahlen als Zahlen, Daten als Daten, URLs als URLs – sodass sie sofort einsatzbereit sind. GitHub-Repos unterscheiden sich hier stark, und die Bereinigungszeit summiert sich schnell.
Schnellreferenz: Best-Practice-Checkliste für Amazon-Scraper auf GitHub
- Vor dem Klonen das Datum des letzten Commits prüfen. Älter als sechs Monate ist bei Amazon ein klares Warnsignal.
- Issues nach „captcha“, „503“, „blocked“ und „not working“ durchsuchen, bevor du mit dem Setup beginnst.
curl_cffioder einen anderen Browser-imitierenden HTTP-Client bevorzugen statt einfachemrequests.- Header, TLS-Profil, Sprache und Proxy-Geografie konsistent halten – keine Widersprüche.
- Sticky Sessions für Browsing-Flows nutzen, nicht blind bei jeder Anfrage rotieren.
- Zufällige Taktung und exponentielles Backoff ergänzen.
- Wiederholte CAPTCHAs als verbrannte Sitzung behandeln, nicht als Rätsel, das man mit Gewalt löst.
- Headless Browser nur einsetzen, wenn HTTP-Clients die Seite nicht zuverlässig reproduzieren können.
- Checkpoints und Zustand speichern, damit sich fehlgeschlagene Läufe sicher fortsetzen lassen.
- Einen Fallback parat haben – ob verwaltete API oder No-Code-Tool wie Thunderbit.
Rechtliche und ethische Aspekte beim Amazon-Scraping 2026
Ein paar Punkte, die du kurz kennen solltest.
Amazons Haltung ist restriktiv und wird zunehmend strenger. Die deutlichsten Signale:
- Amazons eigene Hilfeseiten liefern inzwischen eine 403-Seite mit dem Hinweis: „To discuss automated access to Amazon data please contact api-services-support@amazon.com.“
- Amazons robots.txt sperrt eine breite Palette dynamischer Pfade rund um Rezensionen, Profile, Wunschlisten und Angebotslisten.
- Amazons Unterlassungsaufforderung vom 31. Oktober 2025 an Perplexity wendet sich ausdrücklich gegen verdeckten oder getarnten Agentenzugriff, das Umgehen von Sicherheitsmaßnahmen und das fälschliche Ausgeben eines Agenten als Google Chrome. Amazon hat dazu auch eine öffentliche Stellungnahme veröffentlicht.
- Ende 2025 weitete Amazon weitere Bot-Sperren gegen OpenAI-Crawler aus.
Das praktische Risiko steigt deutlich, sobald du von öffentlichen Produktseiten zu authentifizierten Flows, getarnter Automatisierung oder großvolumiger kommerzieller Extraktion übergehst. Das ist keine Rechtsberatung – kläre deinen konkreten Fall mit deinem eigenen Legal-Team.
Kernaussagen: zuverlässige Amazon-Daten ohne Sperre
In der Reihenfolge ihrer Wichtigkeit:
- Vor dem Klonen prüfen. Geh davon aus, dass die meisten GitHub-Treffer veraltet sind, Tutorials oder Wrapper um kommerzielle APIs.
- Zuerst die Netzwerkschicht verbessern. TLS-Fingerprinting und Session-Kohärenz wiegen schwerer als HTML-Selektoren.
- Sticky Residential Sessions nutzen, kein zufälliges Proxy-Chaos. Zwischen Sitzungen rotieren, nicht innerhalb einer Sitzung.
- Anfragen wie ein Nutzer takten, nicht wie ein Stresstest. Zufällige Verzögerungen und exponentielles Backoff sind Pflicht.
- Isolierte CAPTCHAs lösen, dauerhaft angegriffene Sitzungen beenden. Kein Brute-Force gegen einen verbrannten Fingerprint.
- Einen Fallback haben. Amazon ändert mitten in der Woche etwas, und dein GitHub-Scraper bricht. Ein gepflegtes No-Code-Tool wie Thunderbit oder eine Managed API hält deine Datenpipeline am Laufen, während du debuggst.
- Die Ausgabequalität priorisieren. Saubere, typisierte Daten sparen nachgelagert mehr Zeit als ein schneller, aber chaotischer Scraper.
Wenn dir Verlässlichkeit wichtiger ist als Anpassbarkeit, bietet Thunderbit eine gepflegte Alternative – wirf einen Blick auf die Amazon-Products-Scraper-Vorlage oder die Tutorials auf dem Thunderbit-YouTube-Kanal. Entwickler, die volle Kontrolle wollen, können GitHub-Repos natürlich weiter nutzen – aber nur mit den Anti-Ban- und Wartungspraktiken aus diesem Leitfaden.
FAQs
Ist es legal, Amazon-Produktdaten mit einem GitHub-Scraper zu scrapen?
Amazons Nutzungsbedingungen beschränken die automatisierte Datenerfassung, und Amazon setzt das aktiv mit Unterlassungsaufforderungen und technischen Gegenmaßnahmen durch – besonders 2025–2026. Das Scraping öffentlich zugänglicher Produktdaten bewegt sich in einer Grauzone; Scraping hinter einem Login oder das Tarnen deines Bots als echter Browser ist deutlich riskanter. Das ist keine Rechtsberatung – kläre deinen konkreten Anwendungsfall mit deinem Legal-Team.
Wie oft brechen Amazon-Scraper-Repos auf GitHub?
Häufig. Amazon ändert Seitenlayouts, fügt neue Anti-Bot-Schichten hinzu und mottet Endpunkte regelmäßig ein. In dem Audit für diesen Artikel waren nur etwa 3 von 8 weit verbreiteten Repos im Jahr 2026 klar funktionsfähig. Selbst „funktionierende“ Repos haben oft offene Issues zu CAPTCHAs und 503-Fehlern. Rechne damit, dein Setup alle paar Wochen bis Monate zu aktualisieren oder zu debuggen.
Welcher ist 2026 der beste Amazon Scraper auf GitHub?
Es gibt keinen eindeutigen Sieger – es hängt von Anwendungsfall und technischem Komfort ab. Für einen leichten, direkten Python-Scraper zählt amzpy zu den aktuelleren Optionen. Für breitere Abdeckung über eine verwaltete API taugt omkarcloud/amazon-scraper, ist aber nicht wirklich DIY. Nutze die Frische-Checkliste aus diesem Artikel, um jedes Repo vorab selbst einzuschätzen.
Kann Thunderbit Amazon ohne Code scrapen?
Ja. Thunderbits Amazon-Products-Scraper-Vorlage zieht Produkttitel, Preis, ASIN, Bewertung, Marke, Verfügbarkeit und mehr mit einem Klick heraus. Sie unterstützt den Browser-Scraping-Modus für Seiten mit Login-Pflicht, Cloud-Scraping für öffentliche Seiten in hoher Geschwindigkeit, geplantes Scraping für wiederkehrende Jobs sowie den kostenlosen Export nach Google Sheets, Airtable, Notion und Excel. Den Einstieg findest du, indem du die Thunderbit Chrome Extension installierst.
Wie vermeide ich eine IP-Sperre beim Scraping von Amazon?
Setz auf einen mehrschichtigen Ansatz: (1) wechsle von einfachem requests zu einem TLS-imitierenden Client wie curl_cffi, (2) nutze Residential-Proxies mit Sticky Sessions statt zufälliger Datacenter-Rotation, (3) ergänze zufällige Taktung und exponentielles Backoff, (4) halte deinen gesamten Header-Satz konsistent mit Browser-Profil und Marketplace-Locale, und (5) behandle wiederholte CAPTCHAs als Signal, die Sitzung zu beenden, nicht als Rätsel zum endlosen Lösen. Mehr Details liefert die Anti-Ban-Entscheidungsmatrix weiter oben.
