Pencarian GitHub untuk "amazon scraper" menghasilkan sekitar 3.515 repositori. Kalau dipersempit ke repo yang di-push dalam enam bulan terakhir, jumlahnya turun jadi sekitar 727 — nyaris 20%. Sisanya? Tutorial yang ditinggalkan, wrapper yang sudah basi, dan skrip yang berhenti bekerja begitu Amazon memperketat pertahanannya.
Saya sudah menghabiskan banyak waktu menelusuri repo Amazon scraper, membaca issue di GitHub, dan mengikuti diskusi komunitas di Reddit serta Stack Overflow. Polanya konsisten: seseorang menemukan repo populer, menghabiskan satu jam untuk menyiapkannya, menjalankannya sekali, lalu mentok di CAPTCHA atau error 503. Sikap anti-bot Amazon di 2026 jelas berbeda dari dua tahun lalu — TLS fingerprinting, analisis perilaku, dan penerapan CAPTCHA yang agresif membuat playbook lama seperti "rotasi user agent dan berharap yang terbaik" hampir tidak berguna. Panduan ini membahas praktik terbaik yang benar-benar penting kalau Anda ingin mendapatkan data Amazon yang andal dari repo GitHub, dan apa yang harus dilakukan saat, bukan kalau, scraper Anda rusak.
Apa Itu Amazon Scraper di GitHub (dan Mengapa Banyak yang Gagal)?
Repo Amazon scraper GitHub biasanya berupa skrip open-source — umumnya berbasis Python, Node.js, atau Scrapy — yang mengekstrak data terstruktur dari halaman Amazon. Target datanya sudah familiar: judul produk, harga, ASIN, rating, jumlah ulasan, ketersediaan, info penjual, kartu hasil pencarian, dan teks ulasan.
Arsitekturnya biasanya sederhana:
- Client HTTP atau browser headless mengambil halaman.
- Parser HTML atau JSON mengekstrak field.
- Data disimpan ke CSV, JSON, atau database.
Repo umumnya terbagi ke dalam empat kelompok:
- Pustaka Python ringan (mis. amzpy)
- Scrapy spider (mis. amazon-python-scrapy-scraper)
- Otomasi browser Selenium atau Playwright
- Proyek wrapper API yang sebenarnya hanya front-end untuk layanan scraping komersial (mis. oxylabs/amazon-scraper)
Pola kegagalannya bisa ditebak. Sebagian besar repo rusak karena:
- Amazon mengubah tata letak halaman atau fragmen HTML
- Amazon menampilkan 503 atau CAPTCHA alih-alih konten asli
- TLS dan HTTP fingerprint scraper tidak lagi tampak seperti browser
- Ketidaksesuaian locale, bahasa, atau header memicu kecurigaan
- Maintainer lanjut ke hal lain setelah menyelesaikan kasus pakai mereka yang sempit
Jumlah bintang yang tinggi dan status "masih bisa dipakai" adalah dua hal yang sangat berbeda. Dalam audit yang saya lakukan untuk artikel ini, hanya sekitar tiga dari delapan repo yang banyak muncul terlihat jelas masih aktif di 2026.
Lakukan Audit Kesegaran 2026 Sebelum Anda Meng-clone Repo Amazon Scraper GitHub Apa Pun
Langkah ini jauh lebih penting untuk Amazon dibanding target lain. Sikap pertahanan Amazon berubah lebih cepat daripada situs ecommerce biasa, jadi repo yang bekerja baik di situs brosur bisa jadi tidak berguna di Amazon hanya dalam beberapa minggu. Namun, sebagian besar daftar "best amazon scraper github" merekomendasikan repo tanpa memeriksa apakah masih berfungsi. Pengguna akhirnya membuang waktu berjam-jam menyiapkan alat yang rusak.
Cara Memeriksa Apakah Repo GitHub Masih Hidup
Sebelum Anda git clone apa pun, jalankan pemeriksaan berikut:
- Tanggal commit terakhir: Apa pun yang lebih tua dari 6 bulan adalah tanda bahaya besar untuk Amazon.
- Issue terbuka vs. tingkat respons: Cari tab Issues untuk "captcha," "503," "blocked," dan "not working." Kalau laporan-laporan itu menumpuk tanpa balasan maintainer, tinggalkan.
- Kesehatan dependency: Buka
requirements.txtataupackage.json. Library yang sudah usang (misalnyarequestslama tanpa penanganan TLS modern) adalah tanda merah. - Cakupan tipe halaman Amazon: Apakah repo menangani halaman produk, hasil pencarian, DAN ulasan? Atau cuma satu?
- Pendekatan anti-bot: Header yang di-hardcode tanpa dukungan proxy adalah pendekatan era 2023 yang tidak akan bertahan di 2026.
Checklist Kesegaran Amazon Scraper GitHub
| Sinyal Kesegaran | Yang Perlu Dicek | Tanda Bahaya 🚩 |
|---|---|---|
| Tanggal commit terakhir | Feed commit atau tanggal push repo | Lebih tua dari 6 bulan |
| Issue terbuka | Tab Issues — filter "captcha," "503," "blocked" | Kerusakan berulang tanpa balasan maintainer |
| Kesehatan dependency | requirements.txt / package.json | Library usang, tidak ada strategi TLS modern |
| Cakupan halaman Amazon | README + contoh kode | Hanya menangani satu tipe halaman (mis. halaman produk, tapi bukan pencarian atau ulasan) |
| Pendekatan anti-bot | Kode sumber, konfigurasi proxy | Hanya header dan string UA yang di-hardcode |
| Model pemeliharaan | Apakah ini scraper asli, tutorial, atau wrapper API komersial? | Repo sebenarnya cuma front-end untuk layanan berbayar |
Apa yang Benar-Benar Ditemukan dari Audit
Saya memeriksa delapan repo Amazon scraper yang banyak muncul berdasarkan kriteria ini. Hasilnya cukup mengejutkan:
| Repo / Tool | Stars | Sinyal Commit Terakhir | Ruang Lingkup | Status 2026 | Catatan |
|---|---|---|---|---|---|
| oxylabs/amazon-scraper | ~2.872 | 2026-04-02 | Wrapper API scraper terkelola | Masih hidup, tapi bukan DIY | Segar, tetapi ini sebenarnya front-end ke layanan terkelola |
| omkarcloud/amazon-scraper | ~214 | 2026-02-25 | API terkelola untuk pencarian, detail, ulasan | Masih hidup, tapi bukan DIY | Cakupan bagus, tetapi ini produk API, bukan scraper mentah |
| theonlyanil/amzpy | ~110 | 2026-02-26 | Pustaka Python ringan | Masih hidup | Scraper GitHub langsung yang paling jelas memakai curl_cffi |
| philipperemy/amazon-reviews-scraper | ~134 | 2024-11-21 | Hanya ulasan | Sempit tapi masih bisa dipakai | Tua dan sangat spesifik untuk ulasan |
| python-scrapy-playbook/amazon-python-scrapy-scraper | ~74 | Commit terakhir 2023; repo di-push 2024-08-20 | Scrapy spider + proxy middleware | Level tutorial, menua | Berguna untuk belajar, bukan stack 2026 siap pakai |
| drawrowfly/amazon-product-api | ~744 | 2022-11-13 | CLI Node untuk pencarian, detail, ulasan | Risiko tinggi | Cakupan luas, tapi pemeliharaannya terlalu lama |
| tducret/amazon-scraper-python | ~881 | 2020-10-13 | Pencarian ke CSV | Mati untuk 2026 | Populer secara historis, jelas sudah basi |
| scrapehero-code/amazon-scraper | ~432 | 2020-06-21 | Tutorial pencarian/produk | Mati untuk 2026 | Praktis sudah jadi arsip |
Issue publik menunjukkan cerita yang sama. drawrowfly/amazon-product-api punya issue berjudul "All requests receive captcha response." theonlyanil/amzpy punya "Doesn't seem to be working." scraper milik python-scrapy-playbook punya "Bypass Amazon protection." Ini bukan kasus pinggiran yang langka — justru ini hal pertama yang dihadapi pengguna.
Playbook Anti-Ban: Cara Menghindari Pemblokiran dengan Amazon Scraper dari GitHub
Terblokir adalah masalah terbesar bagi siapa pun yang memakai proyek amazon scraper github. Saran umum seperti "pakai proxy dan rotasi user agent" sudah tidak cukup. Stack anti-bot Amazon 2025-2026 mencakup TLS fingerprinting, analisis perilaku, dan penerapan CAPTCHA yang agresif. Anda butuh pendekatan berlapis.
Pencocokan TLS Fingerprint: Mengapa requests Biasa Bisa Membuat Anda Diblokir
Ini salah satu teknik anti-ban yang paling sering diabaikan. Cara kerja TLS fingerprinting seperti ini: ketika skrip Anda membuka koneksi aman ke Amazon, server bisa mengetahui banyak hal tentang client dari cara ia "bersalaman" — cipher suite yang ditawarkan, urutan extension, pengaturan HTTP/2. Browser memakai pengaturan TLS dan HTTP/2 yang relatif tetap, dan kombinasi itu bisa diidentifikasi melalui teknik seperti JA3 dan fingerprint HTTP/2 Akamai.
requests biasa dan setup httpx standar bisa menyalin header, tetapi tidak menyalin perilaku TLS dan HTTP/2 seperti Chrome. Amazon bisa membedakannya.
curl_cffi mengatasi ini secara langsung. Library ini menyediakan impersonasi browser — target yang didukung termasuk chrome136, safari184, dan firefox133 — sehingga fingerprint TLS HTTP client Anda cocok dengan browser asli. Dokumennya secara eksplisit memperingatkan agar tidak membuat string JA3 acak: fingerprint browser biasanya tetap per versi, dan kebisingan acak lebih mudah dideteksi daripada fingerprint asli yang disalin.
Data komunitas cocok dengan ini. Sebuah thread Reddit tentang curl_cffi + Amazon mengonfirmasi bahwa argumen impersonate berguna karena mengganti profil browser dan menjaga header tetap selaras. Thread Reddit lain menyebut Amazon memblokir client berdasarkan fingerprint TLS "setelah sekitar satu atau dua bulan." Sebuah thread Stack Overflow secara spesifik menanyakan apakah Amazon sedang memfingerprint python-requests (spoiler: ya).
Kalau Anda masih memakai requests biasa sebagai client Amazon utama, ubah asumsi itu sebelum meng-upgrade hal lain apa pun.
Rotasi Proxy yang Benar (Bukan Sekadar "Pakai Proxy")
Tujuan proxy bukan untuk merotasi sesering mungkin. Tujuannya adalah membuat sesi terlihat meyakinkan.
Residential vs. datacenter: Proxy datacenter lebih murah tetapi lebih mudah dideteksi. Proxy residential lebih mahal tetapi jauh lebih sulit ditandai Amazon. Harga residential Bright Data mulai dari $4.00/GB pay-as-you-go, turun ke $3.50/GB untuk paket yang lebih besar. Residential Oxylabs mulai dari $6/GB. Amazon masuk kategori target "canggih" di mana proxy residential layak dibayar lebih.
Rotasi per request vs. per session: Di sinilah kebanyakan tutorial salah. Merotasi proxy di setiap request sambil mempertahankan cookie dan header yang sama justru bisa terlihat kurang manusiawi, bukan lebih. Pola yang lebih aman:
- Pertahankan alur pencarian → produk → ulasan pada sticky session yang sama jika memungkinkan
- Ganti session saat memulai perjalanan pencarian baru, bukan di setiap request
- Rotasi antar sesi, bukan secara acak di dalam satu sesi browsing
Salah satu komentator Reddit menyebut IP ISP biasa tidak sebaik IP seluler pada situs ecommerce populer. Thread lain melaporkan tetap diblokir meski memakai rotasi user agent dan proxy residential — pengingat yang bagus bahwa proxy saja tidak cukup.
Pengaturan Laju Request, Backoff, dan Rate Limiting
Halaman 503 Amazon bukan sekadar nasib buruk acak. Itu adalah umpan balik.
Sebuah posting Stack Overflow tentang scraping lebih dari 500 ASIN melaporkan error 503 muncul di titik yang sama setiap kali, sekitar ASIN 101, bahkan dengan jeda tidur. Polanya memang lama, tetapi pelajarannya tetap relevan: volume mentah dari satu IP atau fingerprint pada akhirnya akan memicu pertahanan.
Pengaturan laju terbaik untuk scraper GitHub DIY:
- Jeda acak antar request (bukan interval tetap, karena mudah dideteksi)
- 2 hingga 5 detik antar request produk publik untuk client HTTP sederhana
- Exponential backoff setelah 503 atau CAPTCHA — mundur secara bertahap alih-alih langsung mencoba lagi
- Concurrency lebih rendah daripada yang Anda kira perlu
- Logging fail-open alih-alih loop retry yang ketat
Sebagian besar repo amazon scraper github tidak punya rate limiting bawaan. Anda perlu menambahkannya sendiri.
Orkestrasi Header: Lebih dari Sekadar String User-Agent
Amazon memeriksa seluruh set header, bukan hanya User-Agent.
Set header browser yang realistis harus mencakup:
User-AgentAcceptAccept-LanguageAccept-EncodingSec-CH-*hint jika sesuai- Perilaku koneksi yang konsisten dengan profil browser yang dipilih
Header harus cocok dengan locale marketplace. Salah satu pengguna Reddit yang scraping 10 locale Amazon menemukan setup bot yang sama hanya terdeteksi di beberapa locale, sementara komentator lain menunjuk ke header terkait wilayah seperti Accept-Language.
Aturannya: header, profil TLS/browser, dan geografi proxy tidak boleh saling bertentangan. Jangan kirim header Chrome dengan UA Firefox. Jangan pakai proxy AS dengan Accept-Language: de-DE.
Menangani CAPTCHA: Kapan Diselesaikan vs. Kapan Mundur
Munculnya CAPTCHA berarti Amazon sudah curiga. Menyelesaikannya tidak akan mengatur ulang skor kepercayaan Anda.
Untuk kejadian CAPTCHA terisolasi dan berfrekuensi rendah:
- Paket PyPI
amazoncaptchaadalah solver CAPTCHA teks Amazon pure-Python, meski rilis terbarunya dari Mei 2023 — anggap sebagai alat taktis, bukan strategi jangka panjang - 2Captcha mencantumkan Amazon Captcha seharga $0.45 per 1.000 solve
Untuk loop CAPTCHA berulang:
- Berhenti mencoba solve dan mulai mundur
- CAPTCHA berulang berarti session sudah terbakar — menyelesaikannya tidak akan membangun ulang kepercayaan pada fingerprint, riwayat session, atau reputasi IP
- Jika CAPTCHA menumpuk per subnet proxy, masalahnya ada di layer jaringan, bukan parser
Kapan Sebenarnya Anda Butuh Headless Browser (dan Kapan Itu Berlebihan)
Insting yang salah adalah menjalankan Playwright untuk semuanya.
Kasus bagus untuk browser:
- Hasil pencarian yang bergantung pada rendering JavaScript atau state yang tergantung locale
- Alur ulasan yang mengarah ke halaman login atau sign-in
- Workflow di mana cookie dan konteks browser lebih penting daripada kecepatan mentah
Kasus buruk untuk browser:
- Halaman produk publik biasa
- Ekstraksi detail produk statis saat client HTTP yang mirip browser sudah cukup
- Pengambilan massal skala besar di mana efisiensi komputasi penting
Mulailah dengan client paling ringan yang masih bekerja. Salah satu thread Reddit tentang scraping skala besar menjelaskan progresinya: mulai dari requests, lalu curl_cffi, dan baru pakai browser penuh kalau opsi yang lebih ringan gagal. Browser headless jauh lebih lambat dan lebih boros resource dibanding client HTTP untuk scraping halaman produk Amazon.
Matriks Keputusan Anti-Ban untuk Proyek Amazon Scraper GitHub
| Skenario | Pendekatan yang Direkomendasikan | Alasannya |
|---|---|---|
| Halaman produk publik (skala kecil) | curl_cffi + sticky residential session | Jalur termurah yang tetap terlihat seperti browser |
| Halaman hasil pencarian | curl_cffi dulu, Playwright hanya jika rendering atau state merusak HTTP | Pencarian lebih stateful dan sensitif terhadap locale |
| Ulasan (login diperlukan) | Mode browser dengan cookie/session asli | Alur login dan ulasan dinamis lebih sulit ditiru dengan HTTP mentah |
| Skala besar (5 ribu+ per hari) | Managed scraper API, unlocker, atau platform no-code | Kode GitHub DIY saja berubah menjadi masalah infrastruktur |
Saat Proyek Amazon Scraper GitHub Anda Rusak: Siapkan Rencana Cadangan No-Code
Setiap scraper berpengalaman punya Plan B.
Update Amazon pada akhirnya akan merusak repo GitHub mana pun di waktu yang paling tidak tepat. Bagi tim ecommerce, scraper yang rusak berarti perubahan harga terlewat, data pesaing yang basi, dan celah di dashboard.
Banyak orang yang mencari "amazon scraper github" sebenarnya adalah pengguna bisnis — tim operasional ecommerce, marketer, peneliti FBA — yang mencoba solusi coding karena tidak menemukan opsi yang lebih baik. Data forum juga menunjukkan frustrasi nyata terhadap Product Advertising API resmi Amazon: akses yang ketat, data terbatas, dan persyaratan pendaftaran yang tidak bisa dipenuhi banyak penjual.
Mengapa Amazon Scraper GitHub Membutuhkan Pemeliharaan Konstan
Audit di atas membuat ini jelas:
- Repo yang basi menumpuk laporan kerusakan tanpa perbaikan
- Repo yang "masih jalan" sekarang terbuka membahas langkah anti-bot di README
- Thread komunitas makin sering berputar di TLS fingerprint, loop CAPTCHA, dan kualitas proxy — bukan selector CSS
Bagi pengguna bisnis, beban pemeliharaan itulah biaya tersembunyi yang sebenarnya. Repo-nya gratis. Waktu Anda untuk debugging jam 2 pagi tidak gratis.
Thunderbit sebagai Alternatif Praktis untuk Amazon Scraper
Thunderbit menawarkan template Amazon Products Scraper yang mengekstrak judul, harga, ASIN, rating, brand, ketersediaan, asal pengiriman, dan URL asli — tanpa menulis kode.
Seperti apa praktiknya:
- Scraping 2 klik vs. menyiapkan environment Python, dependency, dan konfigurasi proxy
- Template Amazon instan — tanpa overhead AI, cukup ekstraksi 1 klik
- Mode browser scraping untuk halaman yang memerlukan login (seperti halaman ulasan yang membuat frustrasi pengguna scraper GitHub)
- Cloud scraping untuk halaman produk publik dengan kecepatan tinggi (50 halaman sekaligus)
- Ekspor gratis ke Google Sheets, Airtable, Notion, Excel — bukan hanya CSV/JSON
- Scheduled scraper untuk pemantauan harga berkelanjutan
- AI menyesuaikan perubahan layout — tanpa beban pemeliharaan pada Anda
Amazon Scraper GitHub vs. Thunderbit: Perbandingan Jujur
| Faktor | Scraper GitHub (mis. AmzPy) | Thunderbit |
|---|---|---|
| Waktu setup | 15–60 menit (Python, dependency, proxy) | ~2 menit (instal ekstensi Chrome) |
| Pemeliharaan | Anda memperbaiki kerusakan | AI menyesuaikan perubahan layout |
| Penanganan anti-bot | DIY (proxy, header, TLS) | Bawaan (mode cloud + browser) |
| Scraping ulasan (login) | Manajemen session yang kompleks | Mode browser scraping |
| Ekspor data | Hanya CSV/JSON | Sheets, Airtable, Notion, Excel, CSV, JSON |
| Penjadwalan | DIY (cron, Airflow, dll.) | Scheduled scraper bawaan |
| Kustomisasi | Lebih tinggi | Lebih rendah |
| Biaya | Gratis (plus biaya proxy) | Tersedia paket gratis; berbasis kredit |
Trade-off jujurnya: repo GitHub menawarkan lebih banyak kustomisasi; Thunderbit menawarkan lebih banyak keandalan. Kalau tim Anda lebih peduli pada uptime daripada fleksibilitas, jalur no-code biasanya pilihan yang lebih rasional.
Praktik Terbaik untuk Scraping Amazon Terjadwal dan Berulang
Sebagian besar proyek amazon scraper github dibangun untuk sekali jalan, tetapi use case bisnis nyata — pemantauan harga, pelacakan inventaris, analisis pesaing — membutuhkan scrape berulang. Repo GitHub hampir tidak pernah menyertakan penjadwalan secara native, sehingga pengguna harus merangkainya sendiri lewat cron job, Airflow, atau workflow n8n.
Penjadwalan DIY untuk Amazon Scraper GitHub
Setup minimal untuk scraping berulang:
- Cron job di Linux atau macOS untuk menjalankan skrip sesuai jadwal
- Log append-only agar Anda bisa men-debug kegagalan setelah kejadian
- Dedup berdasarkan ASIN + timestamp supaya Anda tidak menyimpan data duplikat
- Peringatan kegagalan (bahkan email sederhana saat exit code bukan nol) agar Anda tahu saat run rusak pada jam 3 pagi
Untuk tim yang lebih kompleks:
- n8n untuk otomasi workflow ringan (sering disebut di thread komunitas)
- Airflow untuk pipeline terjadwal yang lebih berat
- State berbasis database jika Anda butuh diff dan histori
Praktik terbaik utamanya bukan scheduler itu sendiri — melainkan manajemen state. Lacak run sukses terakhir, set ASIN terakhir, perubahan harga, dan URL yang gagal.
Penjadwalan Dibuat Lebih Sederhana dengan Thunderbit
Scheduled scraper Thunderbit memungkinkan Anda menjelaskan interval dalam bahasa Inggris biasa, memasukkan URL, lalu klik "Schedule." AI mengubah bahasa alami menjadi jadwal cron — tanpa setup teknis. Bagi tim ecommerce non-engineering yang memantau harga atau peluncuran produk pesaing, itu adalah pengurangan beban operasional yang signifikan.
Praktik Terbaik untuk Scrape Amazon Berulang
Ini berlaku apa pun alat yang Anda gunakan:
- Dedup berdasarkan jendela ASIN + timestamp — jangan simpan produk yang sama dua kali per run
- Simpan harga sebagai angka, bukan string mentah — menghemat pembersihan di tahap berikutnya
- Tambahkan timestamp scrape ke setiap baris — Anda akan membutuhkannya untuk analisis tren
- Lacak delta, bukan hanya state saat ini — "harga turun 12% sejak minggu lalu" lebih berguna daripada "harga $24,99"
- Berikan peringatan untuk perubahan yang bermakna — harga pesaing turun 15% layak diberi notifikasi; fluktuasi 0,5% hanyalah noise
- Pikirkan soal penyimpanan data — file datar cukup untuk run kecil; untuk 5 ribu+ ASIN per hari, pertimbangkan database atau spreadsheet cloud
Kualitas Output Berdampingan: Apa yang Sebenarnya Dihasilkan Tiap Pendekatan Amazon Scraper GitHub
Tidak ada yang membandingkan kualitas output nyata antar repo amazon scraper github. Pengguna sangat peduli pada kualitas data — "alat mana yang menghasilkan data paling bersih dan paling lengkap" — tetapi harus meng-clone dan menguji tiap repo sendiri. Bagian ini mengisi celah itu.
Apa yang Sebenarnya Diekstrak oleh Repo GitHub Populer (dan Apa yang Terlewat)
Berdasarkan sampel README, contoh publik, dan format output yang didokumentasikan:
| Pendekatan | Apa yang Jelas Diekstrak | Kekurangan / Trade-off Umum |
|---|---|---|
| amzpy | Judul, harga, mata uang, URL gambar, rating, ulasan, varian, ASIN | Berorientasi halaman produk; kurang kaya untuk bagian ulasan/spec lengkap |
| tducret/amazon-scraper-python | CSV dengan judul, rating, jumlah ulasan, URL produk, URL gambar, ASIN | Basi, fokus pada listing, cerita anti-bot lemah |
| scraper python-scrapy-playbook | Hasil pencarian, halaman produk, ulasan, pipeline CSV/JSON | Level tutorial; bergantung pada proxy middleware eksternal; kemungkinan perlu lebih banyak pembersihan |
| omkarcloud/amazon-scraper | Pencarian, kategori, detail, ulasan teratas, banyak gambar/video/specs | Bukan scraper mentah — ini layanan API terkelola |
| Template Amazon Thunderbit | Judul, harga, ASIN, brand, rating, ulasan, ketersediaan, asal pengiriman, enrichment subpage | Kontrol level kode lebih sedikit dibanding skrip kustom |
Tabel Perbandingan Kualitas Output
| Field Data | AmzPy | Repo Berbasis Scrapy | Repo Selenium | Thunderbit |
|---|---|---|---|---|
| Judul produk | ✅ | ✅ | ✅ | ✅ |
| Harga (numerik) | ⚠️ string | ✅ | ⚠️ string | ✅ (tipe number) |
| Rating | ✅ | ✅ | ✅ | ✅ |
| Jumlah ulasan | ❌ | ✅ | ✅ | ✅ |
| ASIN | ✅ | ✅ | ✅ | ✅ |
| Gambar produk | ❌ | ⚠️ hanya thumbnail | ✅ | ✅ (resolusi penuh, bisa diekspor) |
| Bahan/spesifikasi | ❌ | ❌ | ❌ | ✅ (via scraping subpage + AI) |
| Ekspor ke Sheets/Airtable | ❌ | ❌ | ❌ | ✅ gratis |
Mengapa Format Data Penting bagi Pengguna Bisnis
Data yang berantakan menciptakan kerja tersembunyi. Bahkan scraper yang berhasil pun bisa menjadi kegagalan operasional jika:
- Harga berupa string dengan simbol mata uang alih-alih angka bersih
- Nilai kosong tidak konsisten (string kosong vs. null vs. "N/A")
- Gambar hanya thumbnail beresolusi rendah
- Field ulasan atau spesifikasi perlu diproses lagi sebelum dianalisis
Bagi tim operasional ecommerce, data yang bersih berdampak langsung pada kecepatan analisis dan pengambilan keputusan. AI Thunderbit memformat data berdasarkan tipe — angka sebagai angka, tanggal sebagai tanggal, URL sebagai URL — sehingga siap dipakai langsung. Repo GitHub sangat bervariasi di area ini, dan waktu pembersihannya cepat sekali menumpuk.
Referensi Cepat: Checklist Praktik Terbaik Amazon Scraper GitHub
- Periksa tanggal commit terakhir sebelum meng-clone. Lebih tua dari enam bulan adalah tanda bahaya besar untuk Amazon.
- Cari issue untuk "captcha," "503," "blocked," dan "not working" sebelum setup.
- Utamakan
curl_cffiatau HTTP client lain yang meniru browser dibandingrequestsbiasa. - Jaga konsistensi header, profil TLS, bahasa, dan geografi proxy — jangan saling bertentangan.
- Gunakan sticky session untuk alur browsing; jangan rotasi setiap request secara membabi buta.
- Tambahkan pacing acak dan exponential backoff.
- Anggap CAPTCHA berulang sebagai session yang sudah terbakar, bukan teka-teki yang harus dipecahkan dengan brute force.
- Gunakan browser headless hanya ketika client HTTP tidak bisa mereproduksi halaman dengan andal.
- Simpan checkpoint dan state agar run yang gagal bisa dilanjutkan dengan aman.
- Punya rencana cadangan — entah itu managed API atau alat no-code seperti Thunderbit.
Pertimbangan Hukum dan Etika untuk Scraping Amazon di 2026
Ada beberapa hal yang patut diketahui, singkat saja.
Sikap Amazon bersifat restriktif dan makin ketat. Sinyal terkuatnya:
- Halaman bantuan milik Amazon sekarang menampilkan halaman 403 yang menyatakan: "Untuk membahas akses otomatis ke data Amazon, silakan hubungi api-services-support@amazon.com."
- robots.txt Amazon melarang berbagai path dinamis, ulasan, profil, wishlist, dan offer-listing.
- Surat cease-and-desist Amazon tanggal 31 Oktober 2025 kepada Perplexity secara eksplisit menolak akses agen yang terselubung atau disamarkan, penghindaran langkah keamanan, dan salah identifikasi agen sebagai Google Chrome. Amazon juga mengeluarkan pernyataan publik tentang insiden tersebut.
- Amazon telah memperluas pengecualian bot terhadap crawler OpenAI pada akhir 2025.
Risiko praktisnya jelas lebih tinggi saat Anda beralih dari halaman produk publik ke alur terautentikasi, otomasi yang disamarkan, atau ekstraksi komersial bervolume tinggi. Ini bukan nasihat hukum — konsultasikan dengan tim legal Anda sendiri untuk situasi spesifik Anda.
Poin-Poin Utama: Mendapatkan Data Amazon yang Andal Tanpa Diblokir
Urut menurut tingkat kepentingan:
- Audit sebelum clone. Anggap sebagian besar hasil GitHub sudah basi, tutorial, atau wrapper untuk API komersial.
- Perkuat dulu layer jaringan Anda. TLS fingerprinting dan koherensi sesi lebih penting daripada selector HTML.
- Gunakan sticky residential session, bukan kekacauan proxy acak. Rotasi antar sesi, bukan di dalam sesi.
- Atur laju request seperti manusia, bukan stress test. Jeda acak dan exponential backoff itu wajib.
- Selesaikan CAPTCHA yang terisolasi; hentikan session yang terus-menerus ditantang. Jangan brute-force fingerprint yang sudah terbakar.
- Punya fallback. Amazon akan mengubah sesuatu di tengah minggu, dan scraper GitHub Anda akan rusak. Alat no-code terpelihara seperti Thunderbit atau managed API bisa menjaga pipeline data tetap hidup sementara Anda debugging.
- Utamakan kualitas output. Data yang bersih dan bertipe menghemat waktu downstream lebih banyak daripada scraper cepat tapi berantakan.
Kalau Anda menginginkan keandalan daripada kustomisasi, Thunderbit menyediakan alternatif yang terpelihara — lihat template Amazon Products Scraper atau tonton tutorial di Thunderbit YouTube Channel. Developer yang ingin kontrol penuh tetap bisa memakai repo GitHub — tetapi hanya dengan praktik anti-ban dan pemeliharaan yang dibahas di panduan ini.
FAQ
Apakah legal melakukan scraping data produk Amazon dengan scraper GitHub?
Syarat dan Ketentuan Amazon membatasi pengumpulan data otomatis, dan Amazon secara aktif menegakkannya lewat surat cease-and-desist dan tindakan teknis (terutama pada 2025-2026). Scraping data produk yang dapat diakses publik berada di area abu-abu; scraping di balik login atau menyamarkan bot Anda sebagai browser asli membawa risiko lebih tinggi. Ini bukan nasihat hukum — konsultasikan dengan tim legal Anda untuk kasus penggunaan spesifik.
Seberapa sering repo Amazon scraper GitHub rusak?
Sering. Amazon mengubah tata letak halaman, menambahkan lapisan anti-bot baru, dan menghentikan endpoint secara berkala. Dalam audit untuk artikel ini, hanya sekitar 3 dari 8 repo yang banyak muncul yang benar-benar berfungsi di 2026. Bahkan repo yang "masih jalan" sering punya issue terbuka tentang CAPTCHA dan error 503. Bersiaplah untuk melakukan troubleshooting atau memperbarui setup setiap beberapa minggu hingga beberapa bulan.
Apa Amazon scraper terbaik di GitHub pada 2026?
Tidak ada satu pemenang tunggal — semuanya tergantung use case dan kenyamanan teknis Anda. Untuk scraper Python yang ringan dan langsung, amzpy adalah salah satu opsi yang lebih mutakhir. Untuk cakupan yang lebih luas lewat API terkelola, omkarcloud/amazon-scraper berfungsi tetapi bukan benar-benar DIY. Terapkan checklist kesegaran dari artikel ini untuk mengevaluasi repo apa pun sebelum Anda berkomitmen.
Apakah Thunderbit bisa scraping Amazon tanpa coding?
Ya. Template Amazon Products Scraper Thunderbit mengekstrak judul produk, harga, ASIN, rating, brand, ketersediaan, dan lainnya hanya dengan satu klik. Alat ini mendukung mode browser scraping untuk halaman yang memerlukan login, cloud scraping untuk halaman publik dengan kecepatan tinggi, scheduled scraping untuk tugas berulang, dan ekspor gratis ke Google Sheets, Airtable, Notion, dan Excel. Anda bisa mulai dengan memasang Thunderbit Chrome Extension.
Bagaimana cara menghindari IP saya diblokir saat scraping Amazon?
Gunakan pendekatan berlapis: (1) ganti dari requests biasa ke client yang meniru TLS seperti curl_cffi, (2) gunakan proxy residential dengan sticky session daripada rotasi datacenter acak, (3) tambahkan pacing acak dan exponential backoff, (4) jaga agar seluruh set header konsisten dengan profil browser dan locale marketplace, dan (5) anggap CAPTCHA berulang sebagai sinyal untuk mengakhiri session, bukan teka-teki yang harus dipecahkan tanpa batas. Untuk detail lebih lanjut, lihat matriks keputusan anti-ban di bagian sebelumnya dalam artikel ini.
