Best Practice Web Scraping di 2026: Panduan Praktisi
Setelah membangun dan memelihara 15 scraper produksi yang melayani lebih dari 3,100 pengguna dengan tingkat keberhasilan >99%, berikut praktik-praktik yang benar-benar penting.
Arsitektur: Berpikir dalam Pipeline, Bukan Script
Kesalahan terbesar yang sering saya lihat adalah memperlakukan scraping sebagai proses satu langkah. Scraper produksi adalah pipeline data:
- Penemuan URL — menemukan apa yang perlu di-scrape (sitemap, halaman kategori, pencarian, API)
- Eksekusi Request — mengambil data dengan retry dan rotasi yang tepat
- Parsing — mengekstrak field terstruktur dari response mentah
- Normalisasi — membersihkan, memvalidasi, dan menstandardisasi output
- Storage — dikirim ke dataset, database, atau sistem downstream
Setiap langkah harus bisa diuji dan di-retry secara independen. Saat Sephora mengubah layout halaman produknya, hanya langkah 3 yang perlu diperbarui — sisa pipeline-nya tetap stabil.
Selalu Utamakan API Dibanding HTML Parsing
Sebelum menulis satu pun CSS selector, cek dulu apakah situsnya punya:
- API publik — endpoint terdokumentasi yang mengembalikan JSON
- API private — panggilan XHR/fetch yang terlihat di browser DevTools
- Endpoint GraphQL — makin umum ditemukan, sering dengan introspection aktif
- JSON tertanam —
__NEXT_DATA__,window.__INITIAL_STATE__, atau JSON-LD di dalam HTML
Respons API terstruktur, ber-versi, dan jauh lebih stabil dibanding layout HTML. Sephora scraper saya mengonversi setiap URL web menjadi panggilan API — belum pernah rusak sekalipun akibat redesign frontend.
Strategi Proxy: Sesuaikan dengan Proteksinya
Tidak semua situs butuh residential proxy. Berikut kerangka keputusan saya:
| Level Proteksi | Jenis Proxy | Contoh Situs |
|---|---|---|
| Tidak ada / Basic | Datacenter | Sebagian besar toko Shopify, situs kecil |
| Rate limiting | Datacenter berotasi | E-commerce menengah, situs konten |
| Fingerprinting | Residential | Sephora, Farfetch, brand besar |
| WAF tingkat lanjut | Residential + TLS fingerprint | Akamai, Cloudflare Enterprise |
Insight kuncinya: biaya proxy naik seiring level proteksi. Jangan buang-buang uang untuk residential proxy pada situs yang cuma memeriksa reputasi IP. Shopify scraper saya bekerja baik dengan datacenter proxy karena proteksi default Shopify minimal.
Manajemen Sesi Adalah Segalanya
Perbedaan antara tingkat keberhasilan 60% dan 99% biasanya terletak pada manajemen sesi:
- Rotasi sesi, bukan cuma IP — IP baru dengan cookie yang sama terlihat mencurigakan
- Panaskan sesi (warm up) — kunjungi homepage sebelum mengakses halaman produk
- Hormati rate limit — 5 concurrent request lebih baik daripada 50 yang malah diblokir
- Exponential backoff — retry 1s, 2s, 4s, 8s, bukan retry langsung
Sephora EU scraper saya mengelola guest token dengan refresh otomatis dan exponential backoff. Scraper ini mempertahankan sesi persisten yang menyerupai pola browsing asli.
Normalisasi Output Anda
Data hasil scraping mentah itu berantakan. Normalisasi semuanya:
Harga
Simpan sebagai integer (sen, bukan dolar). $29.99 menjadi 2999. Ini menghindari error presisi floating-point yang bisa merusak data finansial di tahap selanjutnya. Setiap scraper e-commerce saya memakai konvensi ini.
URL
Selalu simpan absolute URL, jangan pernah relative path. Resolve URL-nya pada saat ekstraksi.
Tanggal
ISO 8601 (2026-04-01T00:00:00Z), selalu dengan timezone. Jangan pernah menyimpan tanggal dalam format locale tertentu.
Teks
Hapus whitespace berlebih, normalisasi Unicode, dan tentukan kebijakan penanganan HTML (hapus tag vs. pertahankan formatting).
Error Handling: Bersiaplah untuk Kegagalan
Scraper produksi gagal terus-menerus — pertanyaannya adalah seberapa graceful kegagalannya. Pendekatan saya:
1Request fails (network error, timeout, 4xx/5xx)
2 → Retry with exponential backoff (up to 5 attempts)
3 → Rotate session/proxy on retry
4 → Log failure with full context if all retries exhausted
5 → Continue processing remaining URLs (don't crash the batch)
Lacak tingkat keberhasilan per pola URL. Jika halaman /category/* tiba-tiba turun di bawah 90% keberhasilan, kemungkinan besar situsnya mengubah sesuatu — Anda akan menyadarinya sebelum pengguna melapor.
Monitor dan Alert
Scraper tanpa monitoring adalah scraper yang tinggal menunggu waktu untuk gagal secara diam-diam. Lacak:
- Success rate per run dan per pola URL
- Jumlah output — penurunan tiba-tiba berarti ada yang rusak
- Kualitas data — field null, nilai tak terduga, pelanggaran skema
- Biaya — pemakaian proxy, waktu compute, storage
Semua Apify Actor saya mengekspos metrik-metrik ini. Saat tingkat keberhasilan menurun, saya mendapat notifikasi dalam hitungan jam — seringkali sebelum ada pengguna yang menyadarinya.
Mulai Sederhana, Tambahkan Kompleksitas
Setiap scraper yang saya bangun dimulai dari hal paling sederhana yang bisa berfungsi:
- HTTP + Cheerio dulu (paling cepat, paling murah)
- Tambahkan fingerprinting hanya jika diblokir
- Tambahkan browser rendering hanya jika JavaScript diperlukan
- Tambahkan rotasi proxy hanya jika kena rate limit
Ulta scraper saya murni Cheerio — tidak perlu browser. Universal Web Printer saya memakai Playwright karena harus me-render JavaScript. Tool yang tepat untuk pekerjaan yang tepat.
Ini bukan prinsip teoretis — semuanya diambil dari pengalaman menjalankan scraper produksi yang memproses jutaan request. Jika Anda butuh scraper custom yang dibangun dengan praktik-praktik ini, mari bicara.