Posisi kami, seperti yang telah kami nyatakan: kami adalah Geonode dan kami menjual proxy, yang merupakan produk yang menjadi tujuan utama sebagian besar artikel tentang topik ini. Jika diurutkan secara jujur, proxy berada di urutan keenam, sedangkan lima hal di atasnya bersifat gratis. Pengaturan kecepatan, identifikasi, caching, mematuhi Retry-After, dan membaca robots.txt akan mencegah lebih banyak pemblokiran daripada rotasi alamat apa pun, karena hal-hal tersebut mengatasi alasan sebenarnya mengapa situs memblokir crawler — beban dan ketidakpastian — bukan sekadar gejalanya. Proksi benar-benar membantu mengatasi satu masalah spesifik, yang akan dibahas nanti. Jika Anda mengandalkan proksi terlebih dahulu, Anda akan menghabiskan uang dan tetap diblokir.
Mengapa Crawler Sebenarnya Diblokir
Empat penyebab, disusun berdasarkan frekuensi dari yang tertinggi hingga terendah.
Frekuensi. Anda mengirimkan terlalu banyak permintaan dalam waktu yang terlalu singkat. Ini adalah penyebab yang paling umum, dan sepenuhnya berada di bawah kendali Anda. Sebuah situs tidak tahu atau tidak peduli siapa Anda ketika memutuskan bahwa tiga puluh permintaan per detik dari satu alamat merupakan masalah.
Ketidakpastian. Lonjakan lalu lintas, upaya ulang akibat kesalahan, merayapi halaman yang sama berulang kali, serta mengikuti ruang URL yang tak terbatas. Beban yang tidak dapat direncanakan oleh situs lebih buruk daripada beban yang dapat direncanakan.
Anonimitas. Klien tak teridentifikasi yang menghasilkan lalu lintas tak terjelaskan adalah masalah yang harus dihentikan. Klien yang teridentifikasi adalah keputusan yang harus diambil, dan seringkali keputusannya adalah mengizinkannya.
Sinyal identitas. Jenis alamat, sidik jari TLS, komposisi header. Hal-hal ini nyata, dan berada di urutan terakhir dalam daftar ini karena hal-hal tersebut terutama penting setelah sebuah situs telah memutuskan bahwa mereka tidak menginginkan otomatisasi yang tidak teridentifikasi — dan karena hal-hal tersebut adalah yang paling sulit untuk diubah secara jujur.
Perhatikan bahwa tiga dari empat poin tersebut berkaitan dengan perilaku. Fokus industri pada poin keempat merupakan fungsi dari apa yang paling mudah dijual, bukan dari apa yang paling sering menyebabkan pemblokiran.
Mulailah dengan Tidak Perlu Melakukan Crawling
Langkah yang memberikan hasil terbaik, namun paling sering diabaikan.
Periksa apakah ada API. Banyak situs yang menyediakan API, dan API tersebut stabil, terstruktur, serta resmi. Melakukan crawling pada situs yang menawarkan API berarti mengerjakan lebih banyak hal untuk hasil yang lebih buruk.
Periksa apakah ada feed mitra atau afiliasi. Seluruh industri — lowongan kerja, properti, ritel, perjalanan — menerbitkan feed massal khusus untuk agregator, karena agregator mengirimkan lalu lintas ke mereka. Tanyakan sebelum Anda membangun. Jumlah situs yang menjawab ya ternyata cukup mengejutkan.
Periksa apakah ada peta situs (sitemap). Peta situs memberi Anda daftar URL beserta cap waktu lastmod, sehingga Anda hanya mengambil konten yang berubah, bukan semuanya.
Periksa apakah ada data terstruktur yang tertanam. JSON-LD dalam blok <script type="application/ld+json"> dirancang agar dapat dibaca mesin, tetap utuh meski situs dirancang ulang, dan sudah ada di halaman yang akan Anda ambil.
Periksa apakah data tersebut ada di tempat lain. Kumpulan data publik, arsip, atau dokumen resmi.
Setiap hal di atas menghilangkan masalah penghambat tersebut, bukan sekadar meredamnya. Kebiasaan refleks untuk membuat crawler terlebih dahulu adalah kebiasaan yang paling merugikan di bidang ini, dan itulah mengapa kami menempatkan bagian ini sebelum pembahasan teknis apa pun. Kami telah membahas hierarki sumber secara lengkap dalam cara menemukan semua halaman di sebuah situs web.
Baca Aturannya Dulu
robots.txt kini telah menjadi standar, RFC 9309, dan mematuhinya dengan benar merupakan bentuk kepatuhan sekaligus demi kepentingan sendiri.
Bagian-bagian yang penting secara operasional: pencocokan dilakukan berdasarkan spesifisitas, bukan urutan — aturan pencocokan terpanjang yang berlaku; respons 5xx berarti penolakan total, bukan "lanjutkan"; 404 berarti tidak ada pembatasan; dan berkas tersebut harus diperbarui setidaknya setiap 24 jam, bukan hanya diambil sekali saat startup.
Gunakan parser yang terawat. Aturan spesifisitas dan normalisasi pengkodean persentase keduanya mudah salah, dan crawler yang salah membaca berkas tersebut adalah crawler yang mengira dirinya patuh padahal sebenarnya tidak. Kami telah membahas detailnya di cara membaca berkas robots.txt.
Kemudian, baca ketentuan layanan. robots.txt bukanlah otorisasi — RFC secara tegas menyatakan hal tersebut — dan sebuah situs mungkin melarang akses otomatis terlepas dari apa yang diizinkan oleh berkas tersebut. Mengetahui hal ini sebelum memulai lebih baik daripada menemukannya dalam surat pemberitahuan.
Atur Kecepatan dengan Tepat
Langkah teknis yang paling bermanfaat, sekaligus yang paling hemat biaya.
Satu permintaan setiap satu hingga dua detik per domain merupakan pengaturan default yang wajar. Kurangi frekuensinya untuk situs kecil, dan jangan tingkatkan tanpa bukti bahwa server tujuan dapat menoleransinya.
Patuhi nilai Crawl-delay jika robots.txt menetapkan nilai tersebut. Ini merupakan ekstensi, bukan bagian dari standar, dan mematuhinya tidak memerlukan biaya apa pun serta menunjukkan itikad baik.
Tambahkan variasi waktu (jitter). Permintaan pada interval yang tepat-tepat teratur merupakan pola yang tidak dihasilkan oleh manusia. Mengacak interval antara, misalnya, 1,0 dan 2,5 detik akan menghilangkan pola tersebut tanpa biaya.
Batasi koneksi bersamaan per domain, bukan secara global. Delapan permintaan bersamaan yang tersebar di delapan domain dianggap sopan. Delapan permintaan terhadap satu domain tidak.
Lakukan crawling selama jam-jam sepi jika memungkinkan. Toleransi situs lebih rendah saat sibuk, dan tugas yang dijalankan semalaman tidak membebani Anda biaya tambahan.
Dan perluas jendela waktu Anda sebelum menambah kapasitas. Ini adalah cara pandang ulang yang paling berguna: lima puluh ribu halaman yang tersebar selama dua puluh empat jam membutuhkan sekitar dua koneksi bersamaan; lima puluh ribu halaman yang sama dalam dua jam membutuhkan dua puluh koneksi. Jika tidak ada yang bergantung pada penyelesaian tugas secara cepat — dan biasanya memang tidak ada — jadwal adalah tuas termurah yang Anda miliki. Kami telah menguraikan perhitungannya dalam berapa banyak proxy yang Anda butuhkan.
Identifikasi Diri Anda
Terkadang bertentangan dengan intuisi, namun selalu efektif.
User-Agent: AcmePriceBot/1.2 (+https://acme.example.com/bot)
Sebuah nama, versi, dan URL tempat orang lain dapat mengetahui siapa Anda dan cara menghubungi Anda. Tiga manfaat, semuanya nyata:
**robots.txt
dapat menghubungi Anda secara spesifik.** Aturan disesuaikan dengan token produk, sehingga sebuah situs dapat memberikan izin kepada crawler Anda yang tidak diberikan kepada semua orang. Hal itu tidak mungkin terjadi jika Anda anonim.
Operator dapat menghubungi Anda alih-alih memblokir Anda. Hal ini terjadi lebih sering daripada yang diperkirakan orang, dan ini merupakan hasil yang jauh lebih baik daripada baru menyadari adanya pemblokiran tiga minggu kemudian.
Hal ini mendukung permintaan akses. "Kami adalah crawler yang diidentifikasi sebagai AcmePriceBot; inilah yang kami kumpulkan dan alasannya" adalah percakapan yang bisa membawa hasil.
Alternatifnya — string Chrome yang disalin — justru menciptakan kontradiksi alih-alih penyamaran, karena user agent browser pada koneksi yang sidik jari TLS dan set header-nya jelas bukan milik browser justru lebih mudah dikenali daripada pengakuan yang jujur. Kami telah membahas hal itu dalam mengatur user agent khusus dengan curl.
Cache dan Gunakan Permintaan Bersyarat
Langkah yang mengurangi beban tanpa mengurangi cakupan.
Jangan pernah mengambil sumber daya yang sama dan tidak berubah dua kali. Simpan apa yang telah Anda ambil, beserta nilai ETag dan Last-Modified-nya, lalu kirimkan permintaan bersyarat:
curl -sS -H 'If-None-Match: "abc123"' https://example.com/page
Sebuah 304 Not Modified hanya memakan beberapa ratus byte, bukan satu halaman penuh. Pada proses perayapan ulang di mana sebagian besar halaman tidak berubah, hal ini mengurangi tagihan bandwidth Anda dan beban server target hingga satu orde besar.
Gunakan lastmod dari peta situs untuk menentukan halaman mana yang perlu diambil. Sebuah situs dengan lima puluh ribu halaman, di mana dua ratus di antaranya berubah hari ini, berarti proses perayapan hanya mencakup dua ratus halaman, bukan lima puluh ribu halaman.
Simpan respons mentah. Saat parser mengalami gangguan, lakukan parsing ulang terhadap data yang sudah ada daripada mengambilnya kembali. Hal ini menghemat biaya sekaligus merupakan bentuk keramahan.
Hapus duplikat URL dengan benar. Normalisasikan tanda garis miring akhir, urutan parameter kueri, huruf besar-kecil nama host, dan hapus parameter pelacakan. Crawler yang tidak melakukan normalisasi akan mengunjungi halaman yang sama berkali-kali dan terlihat seperti klien yang jauh lebih berat daripada yang sebenarnya.
Tangani Kesalahan Sesuai Petunjuk Server
Server memberi tahu Anda apa yang harus dilakukan. Membaca petunjuk tersebut adalah cara yang benar sekaligus cara tercepat untuk kembali beroperasi.
429 Too Many Requests didefinisikan dalam RFC 6585 sebagai indikasi "bahwa pengguna telah mengirimkan terlalu banyak permintaan dalam jangka waktu tertentu ('pembatasan laju')". Respons tersebut "DAPAT menyertakan header Retry-After yang menunjukkan berapa lama harus menunggu sebelum membuat permintaan baru".
503 Service Unavailable berarti server "saat ini tidak dapat memproses permintaan karena kelebihan beban sementara atau pemeliharaan terjadwal", dan server "DAPAT mengirimkan bidang header Retry-After... untuk menyarankan jangka waktu yang sesuai bagi klien untuk menunggu".
Retry-After dapat berupa tanggal HTTP atau jumlah detik, sesuai RFC 9110 — Retry-After: 120 berarti tunggu dua menit.
Perilaku yang benar saat menerima kode status 429 atau 503:
Hentikan permintaan ke domain tersebut. Bukan memperlambat, tetapi benar-benar menghentikan, setidaknya selama interval yang ditentukan.
Jika tidak ada Retry-After, lakukan penundaan secara eksponensial dengan titik awal yang cukup longgar.
Kurangi laju steady-state Anda setelahnya, karena Anda baru saja diberi tahu bahwa laju tersebut terlalu tinggi.
Jangan pernah mencoba ulang secara langsung. Mencoba ulang saat berada dalam batasan laju adalah cara bagaimana pembatasan sementara menjadi pemblokiran permanen, dan ini adalah kesalahan paling umum yang disebabkan oleh diri sendiri dalam proses crawling.
Perhatikan juga bahwa RFC 6585 menyatakan "respons dengan kode status 429 TIDAK BOLEH disimpan oleh cache" — sehingga lapisan cache tidak akan melindungi Anda dari mengulangi kesalahan tersebut.
Kapan Proxy Benar-Benar Berguna
Produk kami sendiri, dijelaskan seakurat mungkin.
Proxy berguna ketika: Anda telah mengoptimalkan kecepatan koneksi namun masih membutuhkan throughput yang tidak dapat dipenuhi oleh satu alamat saja; Anda perlu mengakses konten khusus wilayah, di mana tujuannya adalah agar terlihat seolah-olah berasal dari suatu tempat; Anda menjalankan crawler terdistribusi dan ingin agar crawler tersebut terlihat seperti klien terpisah, bukan satu mesin dengan banyak thread; atau alamat yang Anda gunakan memiliki reputasi buruk tanpa kesalahan dari pihak Anda.
Proxy tidak membantu jika: Anda bergerak terlalu cepat — laju yang sama dari lebih banyak alamat tetap sama, dan kini Anda telah menandai sebuah pool alih-alih satu alamat. Juga tidak membantu jika pola permintaan Anda teridentifikasi melalui sidik jari TLS atau komposisi header, karena informasi tersebut tetap menyertai Anda. Juga tidak membantu jika sebuah situs memiliki ketentuan yang melarang akses otomatis, yang tidak dapat diatasi hanya dengan menggunakan lebih banyak alamat.
Jenis mana: pusat data untuk sebagian besar kegiatan crawling, karena harganya jauh lebih murah dan halaman publik biasanya tidak memerlukan lebih dari itu — layanan kami mulai dari $0,14/GB. Naikkan ke jaringan perumahan, mulai dari $0,79/GB, hanya jika pusat data terbukti gagal atau jika Anda memerlukan geolokasi jaringan konsumen. Angka-angka dari halaman harga kami, diperiksa pada September 2026.
Biaya yang sering mengejutkan orang: browser headless. Browser mengunduh setiap gambar, font, dan skrip, sehingga penggunaan bandwidth meningkat sekitar satu orde besar dibandingkan dengan HTTP mentah. Jika sebuah halaman tidak memerlukan JavaScript, jangan render halaman tersebut — dan jika memerlukan, blokir jenis sumber daya yang tidak Anda butuhkan.
Membedakan Hard Block dan Soft Block
Mode kegagalan yang paling merugikan, karena tidak terlihat seperti kegagalan.
Hard block menghasilkan kode status 403, halaman tantangan, atau penolakan koneksi. Jelas, mencolok, dan dapat segera ditangani.
Pemblokiran lunak mengembalikan kode status 200 dengan konten yang berkurang: jumlah item lebih sedikit, kolom yang dihilangkan, data usang, atau halaman umum alih-alih halaman spesifik. Metrik tingkat keberhasilan Anda tetap di 99%, sementara kualitas data Anda menurun secara diam-diam. Inilah respons yang lebih umum dari situs-situs canggih, justru karena hal ini menghabiskan anggaran Anda tanpa memberi tahu apa pun.
Waspadai hal ini secara eksplisit:
Periksa konten, bukan status. Cari penanda yang diketahui stabil di halaman tersebut dan anggap ketidakhadirannya sebagai kesalahan. Periksa jumlah. Jika halaman kategori tidak pernah memiliki kurang dari dua puluh item, anggap kurang dari dua puluh sebagai kegagalan. Segmentasikan metrik berdasarkan target. Dua belas target pada 99% dan satu pada 40% akan menghasilkan rata-rata yang terlihat sehat. Bandingkan secara berkala dengan browser. Unduh satu halaman secara manual dan bandingkan perbedaannya dengan apa yang diterima crawler Anda.
Ini adalah pola kegagalan diam-diam yang sama seperti yang kami jelaskan dalam mengapa pengujian proxy penting, dan inilah alasan mengapa "kami diblokir selama tiga minggu dan tidak menyadarinya" merupakan kategori insiden yang nyata.
Kapan Harus Berhenti
Bagian yang paling tidak diminati oleh penyedia layanan proxy untuk ditulis.
Ketika ketentuan melarangnya. Beberapa situs menyatakan hal ini secara eksplisit dan menegakkannya. Mencari jalan pintas untuk menghindari larangan yang dinyatakan adalah keputusan yang memiliki konsekuensi di luar aspek teknis.
Ketika Anda diminta untuk berhenti. Permintaan langsung dari operator situs mengakhiri pembahasan ini.
Ketika upaya yang dikeluarkan melebihi nilainya. Jika Anda harus merombak pendekatan Anda setiap dua minggu, biaya yang dikeluarkan untuk data tersebut lebih besar daripada nilainya. Itu adalah kesimpulan bisnis, bukan kegagalan teknis.
Ketika ada jalur yang sah. Sebuah API, feed, atau kumpulan data berlisensi. Membayar untuk akses yang disahkan seringkali lebih murah daripada waktu pengembangan yang dihabiskan untuk menghindarinya, dan hal itu tidak akan mengalami gangguan.
Ketika situs tersebut telah memasang perangkap. Perangkap (tarpits) dan labirin buatan dirancang agar biaya yang Anda keluarkan lebih besar daripada biaya yang ditanggung situs — mereka menyajikan konten yang disimpan dalam cache sementara Anda membayar per gigabyte dan per jam komputasi. Ketidakseimbangan ini disengaja dan tidak akan teratasi dengan usaha.
Tanyakan terlebih dahulu. Sebuah email yang menjelaskan siapa Anda, apa yang Anda butuhkan, dan dalam volume berapa, seringkali menyelesaikan masalah ini lebih efektif daripada yang dibayangkan dalam diskusi, dan hal itu menghasilkan akses yang tetap berfungsi.
Pertanyaan Lainnya
Mengapa crawler saya terus-menerus diblokir?
Biasanya karena batas frekuensi. Terlalu banyak permintaan dalam waktu singkat dari satu alamat adalah penyebab paling umum—jauh melebihi penyebab lainnya—dan hal ini sepenuhnya berada di bawah kendali Anda. Pola yang tidak terprediksi, upaya ulang setelah terjadi kesalahan, serta identifikasi anonim menjadi penyebab sebagian besar kasus lainnya.
Seberapa cepat saya bisa melakukan crawling pada sebuah situs web?
Mulailah dengan satu permintaan setiap satu hingga dua detik per domain, dan tingkatkan kecepatan hanya jika ada bukti bahwa situs target dapat menoleransinya. Patuhi batas waktu (Crawl-delay) jika robots.txt menetapkan batas tersebut. Jika Anda membutuhkan throughput yang lebih tinggi, memperluas jendela waktu (time window) lebih hemat dan aman daripada meningkatkan jumlah permintaan bersamaan (concurrency).
Apakah proxy mencegah Anda diblokir?
Hanya untuk pemblokiran berdasarkan alamat. Jika Anda terlalu cepat, laju yang sama dari lebih banyak alamat tetap dianggap laju yang sama dan kini akan menandai seluruh kumpulan alamat. Jika pola permintaan Anda teridentifikasi melalui sidik jari TLS atau header, pola tersebut akan tetap mengikuti Anda terlepas dari alamat yang digunakan.
Apakah saya harus merotasi user agent?
Tidak. Rotasi acak dalam satu sesi akan membuat klien tampak seolah-olah mengganti browser di tengah kunjungan, yang justru menimbulkan ketidakkonsistenan daripada penyamaran. Satu user agent yang jujur dengan URL kontak akan lebih jarang diblokir daripada skema rotasi apa pun.
Apa yang harus saya lakukan saat mendapatkan kode status 429?
Hentikan permintaan ke domain tersebut dan tunggu setidaknya selama yang ditentukan oleh header Retry-After. Tanpa header tersebut, kurangi frekuensi permintaan secara eksponensial dari titik awal yang cukup longgar, lalu kurangi laju permintaan stabil Anda — Anda baru saja diberi tahu bahwa laju tersebut terlalu tinggi. Jangan pernah mencoba lagi secara langsung.
Bagaimana cara mengetahui apakah saya sedang diblokir secara lunak?
Periksa konten, bukan kode status. Cari penanda yang diketahui stabil di setiap halaman, pastikan jumlah item sesuai harapan, pisahkan metrik keberhasilan berdasarkan target, bukan secara agregat, dan bandingkan secara berkala halaman yang di-crawl dengan halaman yang diakses melalui browser.
Apakah merayapi situs web legal?
Hal ini bergantung pada yurisdiksi, ketentuan situs, data apa yang terlibat, dan apa yang Anda lakukan dengannya. Mematuhi robots.txt, mengidentifikasi crawler Anda, dan menjaga laju perayapan tetap wajar merupakan praktik umum, dan tidak ada yang mengesampingkan ketentuan layanan atau hak cipta. Mintalah nasihat untuk hal-hal yang bersifat komersial.
Apa hal paling efektif yang bisa saya lakukan?
Perlambat prosesnya, dan periksa apakah Anda benar-benar perlu melakukan crawling. Penggunaan API, feed mitra, atau peta situs (sitemap) dengan cap waktu lastmod akan menghilangkan masalah tersebut, bukan sekadar meredamnya — dan jika crawling benar-benar diperlukan, mengatur kecepatan akan mencegah pemblokiran lebih efektif daripada semua langkah lain yang digabungkan.
Kesimpulan
Kerangka pemikiran yang membuat hal ini dapat diatasi adalah bahwa pemblokiran merupakan respons terhadap beban dan ketidakpastian, bukan terhadap identitas. Situs-situs tidak keberatan dibaca; mereka keberatan dibombardir oleh sesuatu yang tidak dapat mereka rencanakan dan tidak dapat mereka hubungi.
Hal ini menempatkan langkah-langkah efektif dalam urutan yang berlawanan dengan yang umumnya dijelaskan dalam kebanyakan artikel. Periksa apakah Anda benar-benar perlu melakukan crawling, karena API atau feed mitra dapat menghilangkan masalah ini sepenuhnya. Baca robots.txt dan patuhi pedoman tersebut dengan benar, termasuk bagian tentang pencocokan spesifisitas dan arti kode 5xx sebagai perintah berhenti. Atur kecepatan Anda dan tambahkan jitter. Identifikasi diri Anda dengan nama dan URL kontak. Lakukan caching secara agresif dan gunakan permintaan bersyarat agar Anda tidak pernah mengambil ulang data yang tidak berubah. Lakukan apa yang dianjurkan di Retry-After.
Semua itu gratis, dan akan mencegah lebih banyak pemblokiran daripada pembelian infrastruktur apa pun. Proksi membantu mengatasi masalah yang nyata dan lebih spesifik — throughput yang melebihi batas alamat tunggal, serta konten yang berbeda berdasarkan wilayah — dan tidak membantu hal lain dalam daftar ini.
Dan perhatikan bagian terakhir ini. Situs yang telah menetapkan ketentuan, menerapkan pembatasan, atau meminta Anda untuk berhenti telah memberi tahu Anda sesuatu, dan alternatif selain mencoba mengelabui sistem tersebut biasanya lebih murah dan selalu lebih tahan lama.