Et GitHub-søk på "amazon scraper" gir rundt 3 515 repositorier. Snevrer du inn til repoer som har fått push de siste seks månedene, er du nede på omtrent 727 — knapt 20 %. Resten? Forlatte veiledninger, utdaterte wrappere og skript som sluttet å virke i det øyeblikket Amazon strammet inn forsvarene sine.
Jeg har brukt mye tid på å grave i Amazon-scraper-repoer, lese GitHub-issues og følge tråder på Reddit og Stack Overflow. Mønsteret er konsekvent: noen finner et populært repo, bruker en time på å sette det opp, kjører det én gang og møter en vegg av CAPTCHA-er eller 503-feil. Amazons anti-bot-linje i 2026 er ikke den samme som for bare to år siden — TLS-fingeravtrykk, atferdsanalyse og aggressiv CAPTCHA-bruk har gjort den gamle taktikken med å "rotere user agents og håpe på det beste" nesten verdiløs. Denne guiden tar for seg beste praksis som faktisk betyr noe hvis du vil hente pålitelige Amazon-data fra et GitHub-repo, og hva du bør gjøre når (ikke hvis) scraperskriptet ditt ryker.
Hva er en Amazon-scraper på GitHub (og hvorfor feiler så mange)?
Et Amazon-scraper GitHub-repo er vanligvis et åpen kildekode-skript — ofte basert på Python, Node.js eller Scrapy — som henter strukturert data fra Amazon-sider. Datapunktene er velkjente: produkttittel, pris, ASIN, vurderinger, antall anmeldelser, tilgjengelighet, selgerinformasjon, søkeresultatkort og anmeldelsestekst.
Arkitekturen er som regel ganske enkel:
- En HTTP-klient eller en headless browser henter siden.
- En HTML- eller JSON-parser trekker ut feltene.
- Dataene lagres i CSV, JSON eller en database.
Repoer faller vanligvis i fire kategorier:
- Lette Python-biblioteker (f.eks. amzpy)
- Scrapy-spidere (f.eks. amazon-python-scrapy-scraper)
- Browser-automatisering med Selenium eller Playwright
- API-wrapper-prosjekter som egentlig er front-end for en kommersiell scraping-tjeneste (f.eks. oxylabs/amazon-scraper)
Feilmønsteret er forutsigbart. De fleste repoer slutter å virke fordi:
- Amazon endrer sidelayouten eller HTML-fragmentene sine
- Amazon serverer en 503 eller CAPTCHA i stedet for ekte innhold
- Scraperens TLS- og HTTP-fingeravtrykk ikke lenger ser nettleseraktig ut
- Uoverensstemmelser i språk, lokasjon eller headere vekker mistanke
- Vedlikeholderen går videre etter å ha løst sitt opprinnelige, smale behov
Mange stjerner og "fungerer akkurat nå" er to veldig forskjellige ting. I gjennomgangen jeg gjorde til denne artikkelen, så bare rundt tre av åtte mye synlige repoer tydelig aktive ut i 2026.
Kjør en ferskhetskontroll for 2026 før du kloner noe Amazon Scraper GitHub-repo
Dette steget er viktigere for Amazon enn for de fleste andre mål. Amazons forsvar endrer seg raskere enn på en typisk nettbutikk, så et repo som fungerer fint på en enkel brosjyreside kan bli verdiløst på Amazon i løpet av noen uker. Likevel anbefaler de fleste lister over "beste amazon scraper github" repoer uten å sjekke om de faktisk fortsatt virker. Brukere kaster bort timer på å sette opp ødelagte verktøy.
Slik sjekker du om et GitHub-repo fortsatt lever
Før du git clone-er noe som helst, gå gjennom disse sjekkene:
- Dato for siste commit: Alt eldre enn 6 måneder er et tydelig varselsignal på Amazon.
- Åpne issues vs. svarrate: Søk i Issues-fanen etter "captcha", "503", "blocked" og "not working." Hvis slike rapporter hoper seg opp uten svar fra vedlikeholderen, gå videre.
- Avhengighetshelse: Åpne
requirements.txtellerpackage.json. Utdatert bibliotekbruk (f.eks. gammelrequestsuten moderne TLS-håndtering) er et rødt flagg. - Dekning av Amazon-sidetyper: Klarer repoet produktsider, søkeresultater OG anmeldelser? Eller bare én av dem?
- Anti-bot-tilnærming: Hardkodede headere uten proxy-støtte er en tilnærming fra 2023 som ikke overlever 2026.
Sjekkliste for ferskhet i Amazon Scraper GitHub
| Fershetssignal | Hva du skal sjekke | Rødt flagg 🚩 |
|---|---|---|
| Dato for siste commit | Commit-feeden eller dato for repo-push | Eldre enn 6 måneder |
| Åpne issues | Issues-fanen — filtrer på "captcha", "503", "blocked" | Gjentatte feil uten svar fra vedlikeholderen |
| Avhengighetshelse | requirements.txt / package.json | Utdaterte biblioteker, ingen moderne TLS-strategi |
| Amazon-dekning | README + kodeeksempler | Håndterer bare én sidetype (f.eks. produktsider, men ikke søk eller anmeldelser) |
| Anti-bot-tilnærming | Kildekode, proxy-konfigurasjon | Bare hardkodede headere og UA-strenger |
| Vedlikeholdsmodell | Er det en ekte scraper, en veiledning eller en kommersiell API-wrapper? | Repoet er egentlig bare front-end for en betalt tjeneste |
Hva kontrollen faktisk avdekket
Jeg sjekket åtte mye synlige Amazon-scraper-repoer opp mot disse kriteriene. Resultatet er nedslående:
| Repo / verktøy | Stjerner | Signal om siste commit | Omfang | Status i 2026 | Merknader |
|---|---|---|---|---|---|
| oxylabs/amazon-scraper | ~2 872 | 2026-04-02 | Administrert scraper-API-wrapper | Lever, men ikke DIY | Oppdatert, men dette er egentlig en front-end til en administrert tjeneste |
| omkarcloud/amazon-scraper | ~214 | 2026-02-25 | Administrert API for søk, detaljer, anmeldelser | Lever, men ikke DIY | God dekning, men det er et API-produkt, ikke en rå scraper |
| theonlyanil/amzpy | ~110 | 2026-02-26 | Lett Python-bibliotek | Lever | Den tydeligste direkte GitHub-scraperen som bruker curl_cffi |
| philipperemy/amazon-reviews-scraper | ~134 | 2024-11-21 | Bare anmeldelser | Smal, men brukbar | Gammel og veldig anmeldelsesspesifikk |
| python-scrapy-playbook/amazon-python-scrapy-scraper | ~74 | Siste commit 2023; repo pushet 2024-08-20 | Scrapy-spidere + proxy-mellomvare | Veiledningsnivå, aldrende | Nyttig for læring, ikke en ferdig 2026-stack |
| drawrowfly/amazon-product-api | ~744 | 2022-11-13 | Node CLI for søk, detaljer, anmeldelser | Høy risiko | Bred dekning, men vedlikeholdet er for gammelt |
| tducret/amazon-scraper-python | ~881 | 2020-10-13 | Søk til CSV | Død for 2026 | Historisk populær, tydelig utdatert |
| scrapehero-code/amazon-scraper | ~432 | 2020-06-21 | Veiledning for søk/produkt | Død for 2026 | I praksis arkivmateriale |
De offentlige issue-trådene forteller samme historie. drawrowfly/amazon-product-api har en issue med tittelen "All requests receive captcha response." theonlyanil/amzpy har "Doesn't seem to be working." python-scrapy-playbook sin scraper har "Bypass Amazon protection." Dette er ikke obskure yttertilfeller — det er de første problemene brukerne møter.
Anti-utelukkelsesstrategien: Slik unngår du å bli blokkert med en Amazon-scraper fra GitHub
Å bli blokkert er den største smerten for alle som bruker et amazon scraper github-prosjekt. Generelle råd som "bruk proxyer og roter user agents" er ikke lenger nok. Amazons anti-bot-stack for 2025–2026 inkluderer TLS-fingeravtrykk, atferdsanalyse og aggressiv CAPTCHA-bruk. Du trenger en lagdelt tilnærming.
TLS-fingeravtrykksmatching: Hvorfor vanilje-requests får deg utestengt
Dette er en av de mest oversette anti-ban-teknikkene. TLS-fingerprinting fungerer slik: Når skriptet ditt åpner en sikker forbindelse til Amazon, kan serveren se mye om klienten ut fra hvordan den "hilser" — hvilke cipher suites som tilbys, rekkefølgen på utvidelser, og HTTP/2-innstillingene. Nettlesere bruker relativt faste TLS- og HTTP/2-innstillinger, og kombinasjonene kan identifiseres gjennom teknikker som JA3 og Akamai HTTP/2-fingeravtrykk.
Vanlig requests og typiske httpx-oppsett kan kopiere headere, men de kopierer ikke Chrome-lignende TLS- og HTTP/2-atferd. Amazon ser forskjellen.
curl_cffi løser dette direkte. Det tilbyr nettleser-etterligning — støttede mål inkluderer chrome136, safari184 og firefox133 — slik at HTTP-klientens TLS-fingeravtrykk matcher en ekte nettleser. Dokumentasjonen advarer eksplisitt mot å generere tilfeldige JA3-strenger: nettleserfingeravtrykk er stort sett faste per versjon, og tilfeldig tull er lettere å oppdage enn et kopiert, ekte fingeravtrykk.
Data fra fellesskapet støtter dette. En Reddit-tråd om curl_cffi + Amazon bekrefter at impersonate-argumentet er nyttig fordi det roterer nettleserprofiler og holder headerne i synk. En annen Reddit-tråd sier at Amazon blokkerer klienter basert på TLS-fingeravtrykk "etter omtrent en måned eller to." En Stack Overflow-tråd spør spesifikt om Amazon fingerprinter python-requests (spoiler: ja).
Hvis du fortsatt bruker vanlig requests som førstevalg for Amazon, bør du oppdatere den antakelsen før du oppgraderer noe annet.
Slik gjør du proxy-rotasjon riktig (ikke bare "bruk proxyer")
Poenget med proxyer er ikke å rotere så mye som mulig. Poenget er å få øktene til å se troverdige ut.
Residential vs. datacenter: Datacenter-proxyer er billigere, men lettere å oppdage. Residential-proxyer koster mer, men er mye vanskeligere for Amazon å flagge. Bright Data-priser for residential-proxyer starter på $4,00/GB pay-as-you-go, ned til $3,50/GB på større planer. Oxylabs residential starter på $6/GB. Amazon hører hjemme i kategorien "sofistikert mål", der residential-proxyer er verdt premiumprisen.
Per forespørsel vs. per økt-rotasjon: Her bommer de fleste veiledninger. Å rotere proxy ved hver forespørsel mens cookies og headere forblir konstante kan se mindre menneskelig ut, ikke mer. Det tryggere mønsteret:
- Behold søk → produkt → anmeldelse i samme sticky session der det er mulig
- Bytt økt når du starter en ny søkereise, ikke ved hver forespørsel
- Roter mellom økter, ikke tilfeldig inne i én nettlesingsøkt
En Reddit-kommentator bemerket at vanlige ISP-IP-er ikke presterte i nærheten av like bra som mobil-IP-er på populære nettbutikker. En annen tråd rapporterte blokkering selv med roterende user agents og residential-proxyer — en god påminnelse om at proxyer alene ikke er nok.
Forespørselstakt, backoff og rate limiting
Amazons 503-sider er ikke tilfeldig uflaks. De er tilbakemelding.
Et Stack Overflow-innlegg om scraping av mer enn 500 ASIN-er rapporterte en 503 på nøyaktig samme punkt hver gang, rundt ASIN 101, selv med pauser. Mønsteret er gammelt, men lærdommen er aktuell: rå volum fra én IP eller ett fingeravtrykk utløser til slutt forsvarsmekanismer.
Beste praksis for taktstyring i DIY GitHub-scrapers:
- Tilfeldiggjorte pauser mellom forespørsler (ikke faste intervaller, som er enkle å oppdage)
- 2 til 5 sekunder mellom offentlige produktforespørsler for enkle HTTP-klienter
- Eksponentiell backoff etter 503 eller CAPTCHA — trekk deg gradvis tilbake i stedet for å prøve umiddelbart igjen
- Lavere samtidighet enn du tror du trenger
- Feilåpen logging i stedet for tette retry-løkker
De fleste amazon scraper github-repoer mangler innebygd rate limiting. Du må legge det til selv.
Header-orchestrering: Mer enn bare User-Agent-strenger
Amazon sjekker hele header-settet, ikke bare User-Agent.
Et realistisk nettleser-header-sett bør inkludere:
User-AgentAcceptAccept-LanguageAccept-EncodingSec-CH-*-hint når det er passende- Forbindelsesatferd som er konsistent med valgt nettleserprofil
Headerne bør matche markedsplassens lokalitet. En Reddit-bruker som scrapes 10 Amazon-lokasjoner fant at samme bot-oppsett bare ble oppdaget i noen lokasjoner, og en annen kommentator pekte på regionsrelaterte headere som Accept-Language.
Regelen er: headere, TLS-/nettleserprofil og proxy-geografi skal ikke motsi hverandre. Ikke send Chrome-headere med en Firefox-UA. Ikke bruk en amerikansk proxy med Accept-Language: de-DE.
CAPTCHA-håndtering: Når du skal løse dem, og når du skal trekke deg tilbake
Å møte en CAPTCHA betyr at Amazon allerede er mistenksom. Å løse den nullstiller ikke tillitspoengene dine.
Ved isolerte CAPTCHA-hendelser med lav frekvens:
amazoncaptchaer en PyPI-pakke i ren Python for å løse Amazons tekst-CAPTCHA-er, men nyeste utgivelse er fra mai 2023 — se på den som et taktisk verktøy, ikke en varig strategi- 2Captcha oppgir Amazon Captcha til $0,45 per 1 000 løsninger
Ved gjentatte CAPTCHA-løkker:
- Slutt å løse dem og begynn å trekke deg tilbake
- Gjentatte CAPTCHA-er betyr at økten er brent — løsning av dem gjenoppbygger ikke tillit i fingeravtrykket, øktshistorikken eller IP-ryktet
- Hvis CAPTCHA-ene klumper seg per proxy-subnett, er problemet nettverkslaget, ikke parseren
Når du faktisk trenger en headless browser (og når det er overkill)
Feil instinkt er å kjøre Playwright til alt.
Gode brukstilfeller for browser:
- Søkeresultater som er avhengige av JavaScript-rendering eller lokasjonsavhengig tilstand
- Anmeldelsesflyter som videresender til innloggings- eller sign-in-sider
- Arbeidsflyter der cookies og nettleserkontekst er viktigere enn rå fart
Dårlige brukstilfeller for browser:
- Vanlige offentlige produktsider
- Statisk uttrekk av produktdetaljer der en nettleserlignende HTTP-klient er nok
- Storskala massehenting der beregningseffektivitet betyr noe
Start med den letteste klienten som fungerer. En Reddit-tråd om scraping i stor skala beskrev progresjonen: start med requests, deretter curl_cffi, og gå først til en full browser når de lettere alternativene feiler. Headless browsers er merkbart tregere og mer ressurskrevende enn HTTP-klienter for scraping av Amazon-produktsider.
Beslutningsmatrise mot blokkering for Amazon Scraper GitHub-prosjekter
| Scenario | Anbefalt tilnærming | Hvorfor |
|---|---|---|
| Offentlige produktsider (små volum) | curl_cffi + sticky residential session | Billigste vei som fortsatt ser nettleseraktig ut |
| Søkeresultatsider | curl_cffi først, Playwright bare hvis rendering eller tilstand bryter HTTP | Søk er mer tilstandsstyrt og lokalitetsfølsomt |
| Anmeldelser (krever innlogging) | Browser-modus med ekte cookies/økt | Innlogging og dynamiske anmeldelsesflyter er vanskeligere å emulere med ren HTTP |
| Storskala (5k+ per dag) | Administrert scraper-API, unlocker eller no-code-plattform | Ren GitHub-kode blir alene et infrastrukturproblem |
Når Amazon Scraper GitHub-prosjektet ditt ryker: Ha en no-code-plan B
Alle erfarne scrapers har en plan B.
Amazon-oppdateringer kommer før eller siden til å knekke ethvert GitHub-repo på verst tenkelige tidspunkt. For e-handelsteam betyr en ødelagt scraper tapte prisendringer, utdaterte konkurrentdata og hull i dashbordene.
Mange som søker på "amazon scraper github" er egentlig forretningsbrukere — e-handelsdrift, markedsførere, FBA-researchere — som prøvde kodebaserte løsninger fordi de ikke fant bedre alternativer. Forumdata viser også reell frustrasjon med Amazons offisielle Product Advertising API: restriktiv tilgang, begrenset data og registreringskrav mange selgere ikke kan oppfylle.
Hvorfor GitHub Amazon-scrapere trenger konstant vedlikehold
Gjennomgangen over gjør dette konkret:
- Utdaterte repoer hoper opp feilrapporter uten fiks
- "Fungerende" repoer omtaler nå åpent anti-bot-tiltak i README-en
- Fellesskapstråder handler stadig mer om TLS-fingeravtrykk, CAPTCHA-løkker og proxy-kvalitet — ikke CSS-selektorer
For forretningsbrukere er denne vedlikeholdsbyrden den virkelige skjulte kostnaden. Repoet er gratis. Tiden du bruker på feilsøking klokken 02.00 er det ikke.
Thunderbit som et praktisk alternativ til Amazon-scraper
Thunderbit tilbyr en Amazon Products Scraper-mal som henter ut tittel, pris, ASIN, vurderinger, merke, tilgjengelighet, fraktopprinnelse og original URL — uten at du skriver kode.
Slik ser det ut i praksis:
- 2-klikk-scraping i stedet for å sette opp Python-miljø, avhengigheter og proxy-konfigurasjoner
- Umiddelbar Amazon-mal — ingen AI-overhead, bare ekstraksjon med ett klikk
- Browser scraping-modus for sider som krever innlogging (som anmeldelsessider som frustrerer GitHub-scraper-brukere)
- Cloud scraping for offentlige produktsider i høy hastighet (50 sider om gangen)
- Gratis eksport til Google Sheets, Airtable, Notion og Excel — ikke bare CSV/JSON
- Planlagt scraper for løpende prisovervåkning
- AI tilpasser seg layoutendringer — ingen vedlikeholdsbyrde for deg
GitHub Amazon-scraper vs. Thunderbit: Ærlig sammenligning
| Faktor | GitHub-scraper (f.eks. AmzPy) | Thunderbit |
|---|---|---|
| Oppsettstid | 15–60 min (Python, avhengigheter, proxyer) | ~2 min (installer Chrome-utvidelsen) |
| Vedlikehold | Du fikser feilene | AI tilpasser seg layoutendringer |
| Håndtering av anti-bot | Gjør-det-selv (proxyer, headere, TLS) | Innebygd (cloud + browser-modus) |
| Anmeldelsesscraping (innlogget) | Kompleks øktshåndtering | Browser scraping-modus |
| Dataeksport | Bare CSV/JSON | Sheets, Airtable, Notion, Excel, CSV, JSON |
| Planlegging | Gjør-det-selv (cron, Airflow osv.) | Innebygd planlagt scraper |
| Tilpasning | Høyere | Lavere |
| Kostnad | Gratis (pluss proxykostnader) | Gratis nivå tilgjengelig; kredittbasert |
Den ærlige avveiningen: GitHub-repoer gir mer tilpasning; Thunderbit gir mer pålitelighet. Hvis teamet ditt bryr seg mer om oppetid enn fleksibilitet, er no-code-veien som regel det mer rasjonelle valget.
Beste praksis for planlagt og gjentakende Amazon-scraping
De fleste amazon scraper github-prosjekter er laget for engangskjøringer, men reelle forretningsbehov — prisovervåkning, lageroppfølging, konkurrentanalyse — krever gjentatte scraping-kjøringer. GitHub-repoer har nesten aldri innebygd planlegging, så brukerne må sy sammen cron-jobber, Airflow eller n8n-arbeidsflyter.
DIY-planlegging for GitHub Amazon-scrapere
Det minste brukbare oppsettet for gjentakelse:
- Cron-jobb på Linux eller macOS for å kjøre skriptet etter en tidsplan
- Kun-tilføyingslogger slik at du kan feilsøke feil i ettertid
- Deduplisering etter ASIN + tidsstempel slik at du ikke lagrer duplikatdata
- Varsling ved feil (selv en enkel e-post ved ikke-null avslutning) så du vet når en kjøring ryker klokken 03.00
For mer komplekse team:
- n8n for lettvekts automatisering av arbeidsflyt (nevnes ofte i fellesskapstråder)
- Airflow for tyngre planlagte pipelines
- Tilstandsdata i database hvis du trenger differanser og historikk
Det viktigste beste praksis-poenget er ikke planleggeren i seg selv — det er tilstandshåndtering. Spor siste vellykkede kjøring, siste ASIN-sett, endrede priser og mislykkede URL-er.
Planlegging gjort enklere med Thunderbit
Thunderbits planlagte scraper lar deg beskrive intervallet i vanlig språk, legge inn URL-er og klikke "Schedule." AI-en gjør naturlig språk om til en cron-plan — uten teknisk oppsett. For e-handelsteam uten utviklere som overvåker priser eller konkurrenters produktlanseringer, er det en tydelig reduksjon i operasjonell friksjon.
Beste praksis for gjentakende Amazon-scrapes
Disse gjelder uansett hvilket verktøy du bruker:
- Dedupliser etter ASIN + tidsvindu — ikke lagre samme produkt to ganger per kjøring
- Lagre priser som tall, ikke rå strenger — sparer opprydding senere
- Legg til scraping-tidsstempel på hver rad — du trenger dem til trendanalyse
- Spor endringer, ikke bare nåtilstand — "prisen falt 12 % siden forrige uke" er mer nyttig enn "prisen er $24,99"
- Varsle ved meningsfulle endringer — en konkurrent som senker prisen med 15 % er verdt et varsel; en svingning på 0,5 % er støy
- Tenk gjennom datalagring — flate filer fungerer for små kjøringer; for 5 000+ ASIN-er daglig bør du vurdere database eller skybasert regneark
Kvalitet side om side: Hva hver Amazon Scraper GitHub-tilnærming faktisk returnerer
Ingen sammenligner faktisk utdata-kvalitet på tvers av amazon scraper github-repoer. Brukere bryr seg veldig om datakvalitet — "hvilket verktøy gir de reneste og mest komplette dataene" — men må klone og teste hvert repo selv. Denne delen fyller det gapet.
Hva populære GitHub-repoer faktisk henter ut (og hva de bommer på)
Basert på README-eksempler, offentlige eksempler og dokumenterte utdataformater:
| Tilnærming | Hva den tydelig henter ut | Vanlige mangler / avveininger |
|---|---|---|
| amzpy | Tittel, pris, valuta, bilde-URL, vurderinger, anmeldelser, varianter, ASIN | Produktside-orientert; mindre rik på fullstendige anmeldelser/spesifikasjonsseksjoner |
| tducret/amazon-scraper-python | CSV med tittel, vurdering, antall anmeldelser, produkt-URL, bilde-URL, ASIN | Utdatert, listefokusert, svak anti-bot-historie |
| python-scrapy-playbook scraper | Søkeresultater, produktsider, anmeldelser, CSV/JSON-pipelines | Veiledningsnivå; avhengig av ekstern proxy-mellomvare; mer opprydding sannsynlig |
| omkarcloud/amazon-scraper | Søk, kategori, detaljer, toppanmeldelser, mange bilder/videoer/spesifikasjoner | Ikke en rå scraper — det er en administrert API-tjeneste |
| Thunderbit Amazon-mal | Tittel, pris, ASIN, merke, vurdering, anmeldelser, tilgjengelighet, fraktopprinnelse, beriking av undersider | Mindre kontroll på kodenivå enn egendefinerte skript |
Sammenligningstabell for utdata-kvalitet
| Datafelt | AmzPy | Scrapy-basert repo | Selenium-repo | Thunderbit |
|---|---|---|---|---|
| Produkttittel | ✅ | ✅ | ✅ | ✅ |
| Pris (numerisk) | ⚠️ streng | ✅ | ⚠️ streng | ✅ (talltype) |
| Vurdering | ✅ | ✅ | ✅ | ✅ |
| Antall anmeldelser | ❌ | ✅ | ✅ | ✅ |
| ASIN | ✅ | ✅ | ✅ | ✅ |
| Produktbilder | ❌ | ⚠️ bare miniatyr | ✅ | ✅ (høy oppløsning, kan eksporteres) |
| Ingredienser/spesifikasjoner | ❌ | ❌ | ❌ | ✅ (via scraping av undersider + AI) |
| Eksport til Sheets/Airtable | ❌ | ❌ | ❌ | ✅ gratis |
Hvorfor dataformatting betyr noe for forretningsbrukere
Rotete data skaper skjult arbeid. Selv en vellykket scraper kan være en driftsmessig fiasko hvis:
- Prisene er strenger med valutasymboler i stedet for rene tall
- Manglende verdier er inkonsistente (tom streng vs. null vs. "N/A")
- Bildene bare er miniatyrbilder med lav oppløsning
- Anmeldelsesfelt eller spesifikasjoner må etterbehandles før analyse
For e-handelsdrift påvirker rene data direkte analysehastighet og beslutningstaking. Thunderbits AI formaterer data etter type — tall som tall, datoer som datoer, URL-er som URL-er — så det er klart til bruk med en gang. GitHub-repoer varierer mye på dette punktet, og tiden til opprydding vokser raskt.
Hurtigreferanse: Sjekkliste for beste praksis for Amazon Scraper GitHub
- Sjekk dato for siste commit før du kloner. Eldre enn seks måneder er et tydelig varselsignal på Amazon.
- Søk i issues etter "captcha", "503", "blocked" og "not working" før oppsett.
- Foretrekk
curl_cffieller en annen HTTP-klient som etterligner nettleser fremfor vanligrequests. - Hold headere, TLS-profil, språk og proxy-geografi konsistente — ingen motsigelser.
- Bruk sticky sessions for nettlesingsflyter; ikke roter blindt ved hver forespørsel.
- Legg til tilfeldig tempo og eksponentiell backoff.
- Behandle gjentatte CAPTCHA-er som en brent økt, ikke en nøtt du skal brute-force.
- Bruk headless browsers bare når HTTP-klienter ikke kan gjenskape siden pålitelig.
- Lagre sjekkpunkter og tilstand slik at mislykkede kjøringer kan gjenopptas trygt.
- Ha en fallback-plan — enten det er en administrert API eller et no-code-verktøy som Thunderbit.
Juridiske og etiske hensyn ved Amazon-scraping i 2026
Et par ting det er verdt å kjenne til, kort fortalt.
Amazons linje er restriktiv og blir stadig mer så. De tydeligste signalene:
- Amazons egne hjelpesider returnerer nå en 403-side som sier: "To discuss automated access to Amazon data please contact api-services-support@amazon.com."
- Amazons robots.txt nekter en lang rekke dynamiske stier, anmeldelsesstier, profilstier, ønskelister og tilbudslister.
- Amazons cease-and-desist-brev til Perplexity datert 31. oktober 2025 protesterer eksplisitt mot skjult eller forkledd agenttilgang, omgåelse av sikkerhetstiltak og å feilidentifisere en agent som Google Chrome. Amazon kom også med en offentlig uttalelse om hendelsen.
- Amazon har utvidet bot-blokkeringene mot OpenAI-crawlere i slutten av 2025.
Den praktiske risikoen er tydelig høyere når du går fra offentlige produktsider til autentiserte flyter, forkledd automatisering eller kommersiell ekstraksjon i stort volum. Dette er ikke juridisk rådgivning — ta kontakt med ditt eget juridiske team for din konkrete situasjon.
Viktige læringspunkter: Slik får du pålitelige Amazon-data uten å bli blokkert
I rekkefølge etter betydning:
- Gjennomfør kontroll før du kloner. Anta at de fleste GitHub-treff er utdaterte, veiledninger eller wrappere rundt kommersielle API-er.
- Oppgrader nettverkslaget først. TLS-fingeravtrykk og øktkonsistens betyr mer enn HTML-selektorer.
- Bruk sticky residential sessions, ikke tilfeldig proxy-kaos. Roter mellom økter, ikke inne i dem.
- Tempoer forespørsler som en bruker, ikke en stresstest. Tilfeldige pauser og eksponentiell backoff er ikke forhandlingsbart.
- Løs isolerte CAPTCHA-er; pensjoner gjentatte utsatte økter. Ikke brute-force et brent fingeravtrykk.
- Ha en fallback. Amazon kommer til å endre noe midt i uken, og GitHub-scraperen din vil ryke. Et vedlikeholdt no-code-verktøy som Thunderbit eller en administrert API kan holde datapipelinen i gang mens du feilsøker.
- Prioriter utdata-kvalitet. Rene, typede data sparer mer tid nedstrøms enn en rask, men rotete scraper.
Hvis du vil ha pålitelighet fremfor tilpasning, tilbyr Thunderbit et vedlikeholdt alternativ — sjekk ut Amazon Products Scraper-malen eller se veiledninger på Thunderbit YouTube-kanalen. Utviklere som vil ha full kontroll kan absolutt bruke GitHub-repoer — men bare med anti-ban- og vedlikeholdspraksisen som er dekket i denne guiden.
Vanlige spørsmål
Er det lov å scrape Amazon-produktdata med en GitHub-scraper?
Amazons vilkår for bruk begrenser automatisert datainnsamling, og Amazon har aktivt håndhevet dette gjennom cease-and-desist-brev og tekniske mottiltak (særlig i 2025–2026). Scraping av offentlig tilgjengelige produktdata befinner seg i en gråsone; scraping bak innlogging eller å utgi boten for å være en ekte nettleser innebærer høyere risiko. Dette er ikke juridisk rådgivning — snakk med det juridiske teamet ditt om ditt konkrete brukstilfelle.
Hvor ofte slutter Amazon-scraper GitHub-repoer å virke?
Ofte. Amazon endrer sidelayout, legger til nye anti-bot-lag og avvikler endepunkter jevnlig. I gjennomgangen til denne artikkelen var det bare omtrent 3 av 8 mye synlige repoer som tydelig fungerte i 2026. Selv repoer som "fungerer" har ofte åpne issues om CAPTCHA-er og 503-feil. Regn med at du må feilsøke eller oppdatere oppsettet ditt hver noen uker til måneder.
Hva er den beste Amazon-scraperen på GitHub i 2026?
Det finnes ingen enkel vinner — det kommer an på brukstilfelle og teknisk komfort. For en lett, direkte Python-scraper er amzpy ett av de mer aktuelle alternativene. For bredere dekning via en administrert API fungerer omkarcloud/amazon-scraper, men det er ikke ekte DIY. Bruk ferskhetssjekklisten fra denne artikkelen til å vurdere ethvert repo selv før du satser på det.
Kan Thunderbit scrape Amazon uten koding?
Ja. Thunderbits Amazon Products Scraper-mal henter ut produkttittel, pris, ASIN, vurderinger, merke, tilgjengelighet og mer med ett enkelt klikk. Den støtter browser scraping-modus for sider som krever innlogging, cloud scraping for offentlige sider i høy hastighet, planlagt scraping for gjentakende jobber og gratis eksport til Google Sheets, Airtable, Notion og Excel. Du kommer i gang ved å installere Thunderbit Chrome-utvidelsen.
Hvordan unngår jeg at IP-en min blir bannet når jeg scraper Amazon?
Bruk en lagdelt tilnærming: (1) bytt fra vanlig requests til en TLS-etterlignende klient som curl_cffi, (2) bruk residential-proxyer med sticky sessions i stedet for tilfeldig rotasjon av datacenter-proxyer, (3) legg til tilfeldig tempo og eksponentiell backoff, (4) hold hele header-settet konsistent med nettleserprofilen og markedsplassens lokalitet, og (5) behandle gjentatte CAPTCHA-er som et signal om å pensjonere økten, ikke som et puslespill du skal løse i det uendelige. For mer detaljer, se beslutningsmatrisen mot blokkering tidligere i artikkelen.
