Seorang spesialis SEO memulai audit teknis situs besar — dan setelah 10 menit, Screaming Frog mulai mengeluarkan 403 Forbidden atau 429 Too Many Requests. Server perlindungan mengira crawler sebagai bot penyerang dan memblokir alamat IP. Hasilnya — audit harus dimulai ulang, dan klien harus dijelaskan mengapa laporan tertunda. Masalah ini dapat diselesaikan dengan pengaturan proxy yang tepat untuk crawler — mari kita bahas bagaimana caranya.
Mengapa situs memblokir Screaming Frog saat audit
Screaming Frog, Sitebulb, JetOctopus, dan Netpeak Spider secara teknis bekerja seperti bot mesin pencari: mereka dengan cepat menjelajahi ribuan URL secara berurutan, mengunduh HTML, CSS, JS, dan gambar, memeriksa pengalihan dan kode status. Dari sudut pandang perlindungan situs (Cloudflare, Qrator, DDoS-Guard, WAF bawaan hosting), ini terlihat seperti aktivitas mencurigakan — terlalu banyak permintaan dari satu IP dalam waktu singkat.
Pemblokiran sering terjadi saat audit:
- toko online besar di infrastruktur mirip Wildberries dengan perlindungan parsing sendiri;
- situs di belakang Cloudflare dengan mode "Under Attack" diaktifkan atau tingkat Keamanan yang tinggi;
- portal dengan konten dinamis, di mana setiap permintaan menghasilkan beban pada server (pencarian, filter, daftar produk);
- situs pesaing yang Anda analisis bukan dari domain Anda sendiri — mereka tidak memiliki alasan untuk mempercayai IP Anda.
Kesulitan tambahan: jika agensi memiliki satu IP statis kantor, dan audit situs dilakukan secara teratur (beberapa klien per hari), IP ini cepat masuk dalam daftar hitam sistem perlindungan. Setelah itu, tidak hanya audit saat ini yang diblokir, tetapi juga audit mendatang dari alamat yang sama — bahkan untuk situs yang sebelumnya dibuka tanpa masalah.
Cara mengenali pemblokiran berdasarkan kode respons
Sebelum mengubah pengaturan proxy, penting untuk memahami apa yang sebenarnya terjadi. Screaming Frog menunjukkan kode respons di kolom Kode Status — dari situ mudah untuk menentukan penyebab penghentian crawling.
| Kode Respons | Apa artinya | Apa yang harus dilakukan |
|---|---|---|
| 403 Forbidden | IP diblokir oleh perlindungan situs | Ganti IP, kurangi kecepatan crawling |
| 429 Too Many Requests | Melebihi batas permintaan dalam satuan waktu | Kurangi jumlah thread, tambahkan jeda |
| 503 Service Unavailable | Server kelebihan beban atau perlindungan bot diaktifkan | Ganti User-Agent, gunakan IP residensial |
| Tidak ada respons / Timeout | IP dalam daftar hitam, permintaan tidak sampai | Penggantian penuh proxy pool |
Jika dalam laporan muncul satu dan sama kode di ribuan URL secara berurutan — ini hampir selalu pemblokiran berdasarkan IP, bukan masalah nyata dari situs. Memeriksa hipotesis ini sangat mudah: buka URL yang bermasalah di browser biasa dari IP yang sama. Jika halaman terbuka dengan normal, tetapi Screaming Frog mendapatkan 403 — masalahnya ada pada crawler, bukan pada situs.
Proxy mana yang cocok untuk crawling SEO
Pemilihan jenis proxy tergantung pada tugas: audit sekali untuk situs Anda, pemantauan reguler pesaing, atau pemindaian marketplace yang dilindungi. Mari kita bahas tiga jenis utama dan penerapannya untuk crawler.
| Jenis Proxy | Kecepatan | Risiko Pemblokiran | Kapan digunakan |
|---|---|---|---|
| Proxy data center | Tinggi | Sedang-tinggi di situs yang dilindungi | Audit situs sendiri tanpa perlindungan ketat |
| Proxy residensial | Sedang | Rendah | Audit pesaing, situs di belakang Cloudflare, marketplace |
| Proxy mobile | Sedang-rendah | Minimal | Perlindungan paling agresif, audit titik yang jarang |
Untuk sebagian besar audit teknis reguler, keseimbangan optimal diberikan oleh proxy residensial — mereka menggunakan alamat IP nyata dari penyedia, sehingga perlindungan situs menganggap permintaan crawler sebagai lalu lintas pengguna biasa. Ini sangat penting jika Anda menganalisis bukan domain Anda sendiri, tetapi situs pesaing atau marketplace dengan sistem anti-bot yang ketat.
Proxy data center tetap menjadi pilihan yang baik ketika Anda mengaudit situs Anda sendiri dan dapat menambahkan rentang IP ke daftar putih di tingkat WAF atau Cloudflare sebelumnya — maka kecepatan pemindaian akan maksimal tanpa risiko pemblokiran.
Pengaturan langkah demi langkah proxy di Screaming Frog
Screaming Frog mendukung proxy "out of the box", pengaturannya hanya memerlukan beberapa menit:
- Buka program dan pergi ke menu Configuration → System → Proxy.
- Centang Use Proxy Server for All Traffic.
- Masukkan alamat dan port proxy server yang diperoleh dari penyedia.
- Jika proxy memerlukan otorisasi dengan nama pengguna dan kata sandi — masukkan di jendela pop-up saat permintaan pertama.
- Tekan OK dan restart crawling untuk menerapkan pengaturan.
Nuansa penting: Screaming Frog di versi gratis dan berbayar hanya dapat bekerja dengan satu proxy server pada satu waktu melalui antarmuka bawaan. Jika Anda memerlukan rotasi IP secara langsung (relevan saat memindai dari 50.000 halaman), gunakan proxy dengan penggantian IP otomatis di sisi penyedia — ini diatur bukan di crawler itu sendiri, tetapi di dasbor layanan proxy, di mana interval penggantian IP ditentukan (misalnya, setiap 10 menit atau pada setiap permintaan baru).
Skema ini mengurangi beban dari satu alamat: crawler terus bekerja dengan satu port, sementara IP di belakangnya berubah secara otomatis, dan situs tidak melihat frekuensi permintaan yang tidak normal dari satu alamat tertentu.
Pengaturan kecepatan dan thread untuk situs besar
Bahkan dengan proxy yang berfungsi, pengaturan kecepatan crawling yang terlalu agresif dapat memicu pemblokiran. Di Screaming Frog, ini diatur di bagian Configuration → Speed. Nilai yang disarankan untuk situs dengan 100.000 halaman:
- Max Threads: 2–5 untuk situs yang dilindungi, 10–15 untuk situs tanpa perlindungan ketat;
- Max URI/s: batasi 2–3 permintaan per detik pada awal, secara bertahap tingkatkan sambil memantau kode respons;
- Custom User-Agent: di bagian Configuration → HTTP Header, gunakan User-Agent dari browser nyata alih-alih "Screaming Frog SEO Spider" standar, jika situs memblokir crawler berdasarkan header;
- Respect robots.txt / crawl-delay: perhatikan direktif Crawl-delay jika ada — mengabaikannya sering mengakibatkan banned di level server.
Untuk situs dengan perlindungan agresif terhadap bot, juga berguna untuk mengaktifkan mode JavaScript Rendering hanya di tempat yang benar-benar diperlukan (situs SPA di React/Vue) — rendering JS secara signifikan meningkatkan beban pada server dan meningkatkan kemungkinan pemblokiran saat crawling melalui satu IP.
Rotasi IP saat memindai 100.000+ halaman
Semakin besar situs, semakin penting untuk mendistribusikan beban secara tepat antara alamat IP. Untuk audit skala besar, dua skema bekerja:
Rotasi berdasarkan waktu. IP berubah secara otomatis setiap 5–15 menit terlepas dari jumlah permintaan. Cocok untuk crawling yang merata dan berkepanjangan, ketika pemindaian berlangsung selama beberapa jam.
Rotasi berdasarkan permintaan. Setiap permintaan HTTP baru dikirim dari IP baru dari pool. Mode ini memberikan perlindungan maksimal terhadap pemblokiran, tetapi dapat mengganggu kerja yang benar dengan otorisasi berbasis cookie atau parameter sesi situs — untuk audit teknis murni (pengumpulan kode status, pengalihan, meta-tag) ini tidak kritis.
Untuk agensi yang melakukan audit paralel beberapa situs klien, masuk akal untuk membagi pool IP berdasarkan proyek — ini mencegah situasi di mana pemblokiran di satu domain "secara tidak sengaja" menyebar ke reputasi IP saat bekerja dengan situs lain.
Tip praktis: sebelum audit besar, jalankan crawling uji pada 500–1000 URL dengan pengaturan kecepatan dan proxy saat ini. Jika selama waktu itu tidak muncul kesalahan 403/429, Anda dapat dengan aman memperbesar pemindaian ke seluruh situs.
Checklist sebelum memulai audit
- ✅ Proxy terhubung dan diuji untuk ketersediaan (pemeriksaan melalui curl atau browser terpisah);
- ✅ Max Threads dan Max URI/s diatur secara konservatif untuk percobaan pertama;
- ✅ User-Agent diatur dengan benar, tidak mencurigakan bagi WAF;
- ✅ Respect robots.txt diaktifkan, jika situs jelas meminta untuk mematuhi Crawl-delay;
- ✅ JavaScript Rendering diaktifkan hanya jika benar-benar diperlukan;
- ✅ Rotasi IP diatur untuk volume situs dari 20.000–30.000 halaman;
- ✅ Penyimpanan progres crawling diaktifkan (Configuration → Save Crawl) untuk mengantisipasi putusnya sesi;
- ✅ Untuk audit marketplace dan portal yang dilindungi, pilih proxy residensial atau mobile alih-alih data center.
Kesalahan umum saat crawling melalui proxy
Kecepatan terlalu tinggi di awal. Para spesialis sering langsung mengatur maksimum thread, berharap dapat mempercepat audit. Akibatnya, perlindungan situs bereaksi sangat cepat, dan hanya dalam beberapa menit seluruh pool proxy terdaftar dalam daftar hitam.
Satu IP statis untuk semua proyek klien. Jika agensi menggunakan data center proxy yang sama untuk puluhan audit dalam sebulan, reputasi IP ini cepat jatuh — sistem perlindungan dari berbagai situs saling bertukar data tentang alamat yang mencurigakan melalui basis data bersama (misalnya, Reputasi IP Cloudflare).
Pengabaian geo-targeting. Jika situs yang diaudit diatur untuk wilayah tertentu (misalnya, toko online Rusia dengan pemblokiran geo untuk lalu lintas luar negeri), penggunaan proxy dengan IP dari negara lain akan memicu pembatasan akses — bahkan tanpa crawling yang agresif.
Kurangnya pemantauan selama proses. Setelah menjalankan crawling selama beberapa jam, para spesialis sering tidak memeriksa kode respons sementara. Akibatnya, mereka hanya menemukan masalah setelah selesai, ketika setengah dari laporan terdiri dari kesalahan pemblokiran, bukan data nyata tentang situs.
Kesimpulan
Pemblokiran saat audit teknis di Screaming Frog hampir selalu diselesaikan dengan kombinasi tiga faktor: jenis proxy yang tepat, kecepatan crawling yang wajar, dan rotasi IP yang cerdas. Untuk situs sendiri tanpa perlindungan ketat, cukup dengan proxy data center yang ditambahkan ke daftar putih. Untuk audit pesaing, marketplace, dan situs di belakang Cloudflare, diperlukan IP yang terlihat seperti lalu lintas pengguna biasa.
Jika Anda secara teratur mengaudit domain orang lain atau platform yang dilindungi, kami merekomendasikan untuk memulai dengan proxy residensial — mereka mengurangi risiko pemblokiran di sistem anti-bot yang paling agresif. Untuk tugas spesifik di sumber daya yang paling dilindungi, pertimbangkan proxy mobile, dan untuk audit besar infrastruktur sendiri, proxy data center tetap menjadi solusi yang baik dan cepat.