Parser Menghasilkan Kolom Kosong, Proxy Tidak Terlibat: Cara Memperbaiki Drift Layout

Parser telah beroperasi selama enam bulan, dan hari ini baris kosong masuk ke dalam basis data. Pikiran pertama — diblokir, perlu mengganti proxy. Anda mengganti pool, meningkatkan kualitas IP, membayar untuk yang residensial daripada data center — tetapi kolom tetap kosong. Karena penyebabnya bukan pemblokiran: situs telah pindah ke tata letak baru, dan pemilih CSS Anda tidak lagi terhubung ke apa pun.

Ini adalah jenis kerusakan yang paling mahal, karena ia diam. Pemblokiran terlihat segera: 403, captcha, pengalihan. Penyimpangan tata letak tidak menjatuhkan apa pun — HTTP 200, halaman diterima, lalu lintas dibayar, tetapi hasilnya None. Mari kita bahas bagaimana membedakan keduanya dalam lima menit dan bagaimana menghentikan penulisan ulang pemilih secara manual setelah setiap desain ulang.

Siapa yang Membutuhkan Ini

Panduan untuk mereka yang menjalankan parser dalam produksi lebih dari satu sprint: pemantauan harga pesaing, pengumpulan ulasan, agregasi lowongan, pengunduhan harian untuk analitik. Jika Anda menjalankan skrip sekali dan membuangnya — penyimpangan tata letak tidak akan menjadi masalah bagi Anda. Jika skrip berjalan secara cron selama berbulan-bulan, ini adalah artikel utama Anda untuk biaya pemeliharaan.

Skala masalah ini tidak dibuat-buat. Menurut analisis GroupBWT, perubahan struktural yang tidak terkelola pada situs memberikan sekitar 40–60% biaya berulang untuk pemeliharaan scraper dalam proyek besar. Di beberapa sektor, 10–15% crawler memerlukan perbaikan setiap minggu — karena pergeseran DOM, fingerprinting, dan throttling endpoint. Dengan kata lain, perbaikan pemilih bersaing dalam biaya dengan menghindari anti-bot, tetapi perhatian yang diberikan jauh lebih sedikit.

Situasi latar belakang tidak baik: dalam laporan Apify "State of Web Scraping 2026" 65,8% responden meningkatkan penggunaan proxy, 58,3% melaporkan peningkatan biaya proxy tahun ke tahun, dan lebih dari 62% — peningkatan total biaya infrastruktur, terutama karena perlindungan dari bot yang semakin ketat. Dalam konteks ini, membakar lalu lintas yang dibayar pada halaman yang tidak menghasilkan apa-apa adalah sangat menyedihkan.

Langkah 1. Membedakan Pemblokiran dari Penyimpangan Tata Letak

Diagnosis memerlukan beberapa menit dan dilakukan secara berurutan — jika tidak, Anda bisa dengan mudah "memperbaiki" kerusakan yang salah.

1. Periksa kode respons dan ukuran tubuh. 403, 429, 503, pengalihan ke halaman verifikasi atau tubuh 2–5 KB — ini adalah anti-bot. HTTP 200 dan halaman penuh dengan ukuran 200–800 KB — situs telah membiarkan Anda, masalahnya bukan pada proxy.
2. Simpan HTML mentah ke disk dan buka dengan mata Anda. Bukan di debugger, tetapi di browser. Jika produk/ulasan/harga ada, tetapi parser tidak melihatnya — ini adalah penyimpangan tata letak.
3. Cari teks yang diperlukan dengan pencarian di file. Ada di HTML, tetapi tidak dapat diakses melalui pemilih Anda — markup telah berubah. Tidak ada sama sekali — konten dimuat oleh skrip, memerlukan mesin browser, bukan permintaan HTTP.
4. Bandingkan dengan pengunduhan sukses sebelumnya. Bandingkan HTML lama dan baru dari URL yang sama: biasanya segera terlihat kelas pembungkus baru, blok yang dipindahkan, atau penggantian id dengan data-*.
5. Periksa apakah situs memberikan versi halaman yang berbeda. Ini akan dibahas secara terpisah di bawah, karena di sini proxy memang berperan.

Jika setelah poin ketiga diagnosisnya adalah "markup telah bergeser", mengganti proxy tidak ada gunanya. Anda memerlukan parser yang dapat menemukan elemen, bahkan ketika pemilihnya sudah tidak valid.

Langkah 2. Apa Itu Pemilih Adaptif

Idenya sederhana: alih-alih terikat pada string .product-card > h3.title, perpustakaan sekali menyimpan "potret" elemen yang diperlukan, dan pada pemanggilan berikutnya mencari elemen yang paling mirip dengan potret ini di halaman.

Ini paling praktis diimplementasikan dalam Scrapling — kerangka kerja Python terbuka oleh Karim Shoair. Proyek ini diluncurkan pada Oktober 2024 dan pada September 2026 telah mengumpulkan lebih dari 78.000 bintang di GitHub; rilis terakhir pada saat penulisan adalah v0.4.15 dari 23 Agustus 2026, dan komit dilakukan setiap hari. Diperlukan Python 3.10+.

Mekanisme pencarian adaptif diatur seperti ini. Ketika Anda memanggil pemilih dengan auto_save=True, Scrapling menyimpan jejak elemen:

• nama tag, teks, dan semua atribut beserta nilainya;
• nama tag tetangga;
• jalur menuju elemen — hanya berdasarkan nama tag;
• tag, atribut, dan teks induk.

Jejak disimpan dalam basis data lokal SQLite dan dikunci dengan pasangan "domain + identifikasi". Domain diambil dari URL halaman (atau ditentukan dengan parameter adaptive_domain), dan identifikasi secara default adalah string pemilih itu sendiri — atau milik Anda sendiri, jika Anda mengirimkan identifier=.

Ketika tata letak berubah dan pemilih biasa mengembalikan kekosongan, panggilan dengan adaptive=True mengangkat jejak yang disimpan dan menjalankannya di semua elemen halaman, menghitung penilaian kesamaan yang kabur — hingga urutan atribut. Elemen dengan kecocokan tertinggi dikembalikan.

Ini sangat murah. Menurut tolok ukur resmi proyek, pengambilan data memerlukan 1,99 ms dibandingkan 2,01 ms untuk Parsel/Scrapy, 22,93 ms untuk PyQuery, 80,57 ms untuk Selectolax, dan 1541 ms untuk BeautifulSoup dengan lxml. Pencarian adaptif untuk elemen yang mirip — 2,46 ms dibandingkan 13,3 ms untuk AutoScraper. Jadi, asuransi dari desain ulang menambah sekitar dua milidetik pada permintaan di tengah latensi jaringan yang mencapai ratusan milidetik.

Langkah 3. Menginstal dan Mengaktifkan

Instalasi tergantung pada apakah Anda memerlukan browser:

1. pip install scrapling — hanya parser, tanpa bagian jaringan. Cukup jika Anda mendapatkan HTML dengan kode Anda sendiri.
2. pip install "scrapling[fetchers]", kemudian scrapling install — menambahkan fetchers dan mengunduh browser dengan dependensi.
3. Tambahan: [ai] — server MCP, [rag] — pembungkus untuk RAG, [shell] — konsol interaktif, [all] — semuanya sekaligus. Ada gambar siap pyd4vinci/scrapling.

Selanjutnya — dua pengujian. Yang pertama pada tata letak kerja langsung menyimpan jejak, yang kedua sudah dapat bertahan dari desain ulang:

1. Pengujian acuan. Buat objek Selector dengan adaptive=True dan pastikan untuk mengirimkan url — jika tidak, domain akan pergi ke kunci "default", dan jejak dari berbagai situs akan tercampur. Panggil pemilih yang diperlukan dengan auto_save=True.
2. Pengujian tempur. Pemilih yang sama, tetapi dengan adaptive=True. Selama markup utuh, jalur biasa akan berfungsi. Ketika rusak — pencarian kesamaan akan diaktifkan.
3. Catat perbedaan. Momen ketika pemilih biasa memberikan kekosongan, sementara yang adaptif menemukan sesuatu — ini adalah sinyal "situs telah pindah", dan harus terlihat dalam pemantauan, bukan ditelan diam-diam.

Detail penting tentang penulisan ulang: penyimpanan tidak terakumulasi. Pengulangan auto_save untuk pasangan "domain + identifikasi" yang sama akan menimpa jejak sebelumnya. Oleh karena itu, acuan diambil dari halaman yang sudah benar, bukan dalam siklus di seluruh pool URL.

Langkah 4. Proxy: Di Mana Mereka Sebenarnya Berperan

Kita mulai dengan bahwa penyimpangan tata letak bukan tentang proxy. Ini benar setengahnya, dan setengah lainnya memerlukan biaya.

Situs dapat memberikan markup yang berbeda karena keluaran proxy. Lokasi, bahasa, dan negara mengubah pola halaman: urutan blok yang berbeda, kelas yang berbeda, format harga dan tanggal yang berbeda. Ini bukan hipotesis — di Scrapling ada perbaikan yang menunjukkan: dalam versi 0.4.12 dari StealthyFetcher dihapus paksa lokal en-US, karena lokal yang dipaksakan bertentangan dengan geo nyata dan merusak perilaku. Dari sini, aturan kerja: ambil jejak acuan dari geo yang sama di mana Anda kemudian mengumpulkan data. Jejak yang diambil melalui IP Jerman akan kurang cocok dengan halaman yang diperoleh melalui IP Brasil — dan Anda akan mendapatkan alarm palsu "situs telah mengganti tata letak".

Konsekuensi praktis:

• Jika pool multinasional — pisahkan jejak melalui adaptive_domain, menetapkan kunci seperti "domain + negara". Jika tidak, satu entri di SQLite akan terus ditimpa oleh versi dari berbagai geo.
• Untuk skenario panjang, pertahankan satu negara dan satu sesi untuk seluruh tugas. Cara mengaturnya, dijelaskan secara rinci dalam materi tentang sesi lengket dan kapan menggunakannya.
• A/B testing dan peluncuran bertahap memberikan dua tata letak langsung di satu domain. Di sini pencarian adaptif sangat berguna: ia akan mengambil elemen dari kedua cabang, sementara pemilih yang kaku akan secara acak memberikan kekosongan pada setengah permintaan.

Menetapkan proxy di Scrapling dapat dilakukan di semua level. Untuk permintaan HTTP cepat, Fetcher dan AsyncFetcher memiliki parameter proxies. Untuk sesi, ada ProxyRotator, yang menerima daftar alamat — ia dimasukkan ke dalam FetcherSession. Sesi browser DynamicSession dan StealthySession menerima proxy di tingkat sesi, agar IP tidak berubah di tengah skenario.

Satu lagi hal yang menghemat baik pool maupun saraf, muncul di versi 0.4.12 — AutoThrottle: perpustakaan secara otomatis menyesuaikan jeda antara permintaan dengan respons server, menggandakan penundaan saat pemblokiran, dan menghormati header Retry-After. Ini adalah perilaku yang membedakan pengumpulan yang hati-hati dari pengulangan yang naif yang menyebabkan pemblokiran.

Perangkap

• Jangan komit SQLite dengan jejak di git. Ini secara langsung diperingatkan dalam dokumentasi. Juga, jangan gunakan auto_save di halaman dengan data pribadi — teks dan atribut elemen akan masuk ke jejak.
• Pencarian adaptif bukan pengganti pemantauan. Ia akan mengembalikan elemen "paling mirip", tetapi yang paling mirip tidak selalu benar. Jika situs menukar harga dengan diskon dan harga tanpa diskon, kesamaan tinggi, tetapi datanya salah. Lakukan pemeriksaan pada rentang nilai dan proporsi kolom kosong dalam pengunduhan.
• Kerusakan diam lebih mahal daripada yang keras. Selama pemilih diam-diam memberikan None, pipeline terus berjalan di halaman dan membakar lalu lintas yang dibayar. Tentang apa yang sebenarnya dikenakan biaya satu gigabyte yang tidak menghasilkan data, ada analisis terpisah — mengapa harga proxy per GB salah.
• Jejak menjadi tua. Setelah desain ulang yang terkonfirmasi, ambil jejak acuan lagi, jika tidak, perbaikan situs berikutnya akan dianggap sudah dari potret yang usang, dan akurasi akan menurun.
• Jika konten tidak ada di HTML sama sekali — adaptivitas tidak akan membantu, Anda memerlukan fetcher berbasis browser. Dalam 0.4.15, tab browser mulai digunakan kembali di antara permintaan, dan metode close_pages() menutupnya secara paksa; di sana juga diperbaiki masalah hang dalam mode headless dan solusi Turnstile tidak lagi tergantung pada lokal browser.

Jenis Proxy Apa yang Harus Diambil untuk Tugas Ini

Pemilihan ditentukan bukan oleh parser, tetapi oleh situs target:

• Proxy Data Center — untuk situs tanpa anti-bot yang serius: dokumentasi, registri pemerintah, katalog terbuka, RSS, dan CSV feeds (untuk yang terakhir di 0.4.13 ditambahkan XMLFeedSpider dan CSVFeedSpider dengan pembongkaran otomatis gzip). Murah dan cepat, dan stabilitas markup di sini biasanya lebih tinggi.
• Proxy Residensial — untuk marketplace, agregator, dan segala sesuatu yang mempersonalisasi hasil berdasarkan geo. Di sinilah sangat penting untuk mengambil jejak acuan dan mengumpulkan data dari satu negara, jika tidak, Anda akan memperbaiki bukan kerusakan, tetapi geografi Anda sendiri.
• Proxy Seluler — ketika situs memberikan pola seluler dan perlu diparsing apa adanya, atau ketika kepercayaan pada IP lebih penting daripada biaya per gigabyte.

Singkatnya

Kolom kosong dalam pengunduhan adalah dua diagnosis berbeda dengan perawatan yang berbeda. Pertama, periksa kode respons dan HTML mentah: jika halaman datang utuh, tidak perlu mengganti proxy, tetapi markup telah bergeser. Pemilih adaptif Scrapling menutup kelas kerusakan ini dalam beberapa milidetik per permintaan — simpan jejak pada tata letak kerja, aktifkan adaptive=True dalam pertempuran, dan catat momen pemicu sebagai sinyal tentang desain ulang. Dan pertahankan geo stabil: setengah dari "desain ulang mendadak" dalam praktiknya ternyata adalah versi bahasa lain dari halaman yang datang karena perubahan negara keluaran.

Jika geo yang stabil dan sesi yang dapat diprediksi adalah apa yang kurang dari parser Anda, lihat proxy residensial ProxyCove: pilihan negara, sesi lengket, dan pembayaran untuk lalu lintas yang benar-benar digunakan.