Review Browsertrix Crawler: Ia Mengarsipkan Apa yang Dilakukan Browser, Bukan Apa yang Tertulis di Kode

Browsertrix Crawler adalah crawler arsip dari Webrecorder: satu image Docker yang menjalankan Chromium asli lewat Puppeteer, merekam semua yang diambil browser tersebut, lalu menulisnya ke WARC — format standar arsip web — dan, kalau perlu, membundelnya ke paket WACZ lengkap dengan indeks, daftar halaman, dan log. Tujuan inilah yang bikin alat ini beda dari tool scraping yang sekilas mirip. Scraper biasanya bekerja untuk menarik data lalu membuang halaman begitu field yang dibutuhkan ketemu; archivist justru menyimpan kunjungan itu sendiri — byte, header, urutan kedatangannya — supaya halaman masih bisa dibuka lagi bahkan lama setelah situs berubah atau hilang. Webrecorder sudah lama menjaga lapisan infrastruktur web ini, termasuk format dan stack replay-nya, jauh sebelum pengarsipan jadi kategori produk, dan dipakai oleh library, redaksi berita, serta peneliti.

Saya menjalankan v1.14.0 di Docker terhadap fixture lokal yang berisi empat kelas endpoint yang sengaja dibuat berbeda, lalu menginstrumentasi kedua sisi crawl: record WARC untuk isi arsip dan penghitung hit di sisi server untuk permintaan nyata. Perbedaan yang paling berguna bukan sekadar statis versus dinamis. Browsertrix menangkap link yang dibuat saat runtime dan fetch() yang dipanggil halaman, tetapi tidak meminta dua URL literal yang ada di dalam fungsi JavaScript yang tidak pernah dipanggil.

File app.js yang dilink juga diarsipkan utuh, termasuk kedua path literal itu, tetapi tidak satu pun endpoint tersebut menghasilkan record respons, record request, atau hit server. Fungsi yang memuatnya memang tidak pernah dijalankan. Karena itu, artikel ini menilai Browsertrix sebagai pengarsip sesi browser, bukan sebagai inventaris semua URL yang disebut di source code.

Sebenarnya Browsertrix Crawler itu apa

Banyak orang datang dengan ekspektasi dapat scraper lalu pulang kecewa. Tidak ada bagian di pipeline default yang langsung memberi Anda CSV harga produk, dan berharap ada seperti berharap dashcam menulis laporan lalu lintas. Output-nya adalah rekaman sesi browsing yang bisa diputar ulang, dan semua keputusan desain berikutnya mengikuti tujuan itu.

Saya menguji v1.14.0 pada 27 Juli 2026: webrecorder/browsertrix-crawler:latest dengan digest sha256:9d6800a8…, dan crawl --version mengonfirmasi build-nya. Proyek ini berlisensi AGPL-3.0. Semua pengukuran dijalankan di Docker via Colima pada macOS arm64, melawan fixture lokal yang terkontrol; penghitung di sisi server memberi bukti yang independen dari log Browsertrix dan parsing arsip.

AGPL-3.0 perlu dibahas khusus. Copyleft yang kuat dengan ketentuan penggunaan lewat jaringan. Kalau Browsertrix Crawler akan dimasukkan ke produk komersial, bukan cuma dipakai sebagai tool mandiri, pastikan ada yang membaca lisensinya dengan benar sebelum rilis. Ini peringatan, bukan nasihat hukum.

Arsip merekam sesi, bukan source code

Fixture saya menyajikan empat jenis endpoint, sengaja dipisah karena pengarsip memperlakukannya sangat berbeda:

• Kelas A — <a href> biasa di HTML. Empat halaman plus rantai kedalaman tiga level. Crawler apa pun di dunia bisa menemukan ini.
• Kelas B — URL literal di dalam fungsi yang tidak pernah jalan. Dua path, /api/js-endpoint-7 dan /api/js-endpoint-8, tersimpan sebagai string di loadData() yang tidak pernah dipanggil dalam app.js yang terhubung.
• Kelas C — link yang dibangun saat runtime. Sebuah <a href> dirangkai dari fragmen di JavaScript ('endpoint' + (6 * 7)) lalu ditambahkan ke DOM. Path utuh /runtime-only/endpoint42 tidak pernah muncul sebagai byte yang disajikan.
• Kelas D — fetch() yang benar-benar dipanggil halaman. Path dirangkai dengan cara yang sama ('runtime-xhr-' + (33 * 3)), lalu diminta sungguh-sungguh saat halaman dimuat.

Untuk kelas C dan D, path lengkapnya tidak muncul sebagai string kontigu di file yang disajikan. Hit di sisi server dan record respons membuktikan bahwa konstruksi runtime dan jalur request memang benar-benar terjadi pada fixture ini.

Apa yang tertangkap, dan apa yang tidak

Dua instrumen, dicek silang di setiap sel: record respons WARC (apa yang ada di arsip) dan penghitung hit sisi server yang dikunci pada (Host header, path) (apa yang benar-benar diminta). Keduanya cocok di semua titik.

Kelas C adalah yang membedakan browser sungguhan dari crawl statis. Ekstraksi link default membaca DOM yang sudah dirender (a[href]->href, menurut dokumentasi opsi umum), jadi link yang baru ada setelah JavaScript berjalan tetap akan di-queue, diambil, dan diarsipkan. Kelas D tertangkap karena alasan berbeda — halaman itu sendiri yang mengirim request, dan pengarsip berada di jalur jaringan sambil merekam apa pun yang lewat.

Ada batas jujur untuk kelas C: link saya disuntikkan secara sinkron saat page load. Link yang muncul belakangan, selama behaviors Browsertrix berjalan, adalah kasus terpisah, dan memang ada issue terbuka untuk itu — #723, "Links on pages that are discovered during behaviors are not extracted". Saya tidak menguji skenario itu, jadi saya tidak mengklaim apa pun tentangnya.

File-nya diarsipkan. Endpoint-nya tidak.

Untuk memastikan miss pada kelas B, saya perlu menelusuri WARC record demi record, bukan cuma melihat hitungan ringkas.

app.js memang ada di arsip — satu record respons, body JavaScript 222 byte — dan kedua literal kelas B muncul secara verbatim di dalamnya. Sementara itu, baik /api/js-endpoint-7 maupun /api/js-endpoint-8 tidak menjadi URI target pada satu pun record di seluruh file: nol record respons, nol record request. Masing-masing string literal itu hanya muncul sekali di seluruh arsip, dan keduanya berada di body tersimpan milik app.js.

Itu menyingkirkan penjelasan sederhana ("app.js tidak pernah di-fetch"). Pengarsip menyimpan file yang merujuk ke endpoint itu dan tidak pernah mengirim request ke sana, karena loadData() tidak pernah dipanggil. Default behaviors Browsertrix aktif — autoplay, autofetch, autoscroll, siteSpecific — dan autofetch juga tidak menyelamatkan mereka, yang masuk akal kalau Anda membaca apa yang dilakukan autofetch: ia mengejar img srcset, stylesheet, dan URL data-*, bukan literal string yang tersembunyi di badan fungsi.

Sebagai perbandingan di fixture yang sama, saya juga menjalankan Katana v1.6.1 sebagai katana -u <seed> -jc -silent -nc -d 4. Ringkasan discovery mentahnya mencatat hasil yang berlawanan pada dua kelas JavaScript yang sengaja dibuat itu:

Kedua perintah memakai fixture dan nama endpoint yang sama. Tabel ini bukan peringkat umum browser crawler versus crawler statis; tabel ini menunjukkan mengapa inventaris endpoint dan preservasi sesi butuh tes cakupan yang berbeda.

Kalimat "real browser, jadi menangkap semua yang dilakukan JavaScript" sering diulang di tulisan review. Itu berlebihan. Yang ditangkap adalah traffic yang dieksekusi. Kode yang hanya merujuk URL tanpa pernah memanggilnya tidak menghasilkan traffic, dan kalau tidak ada traffic, tidak ada record.

Body replay ada, dengan satu hal yang tidak saya cek

Untuk dua endpoint yang dibuat saat runtime, saya mengambil body respons HTTP yang diarsipkan dari WARC dan memverifikasi bahwa isinya adalah JSON yang disajikan: 206 byte untuk target link yang disuntikkan runtime, 201 byte untuk target fetch() runtime. Jadi itu bukan stub indeks yang menunjuk ke kosong — kontennya memang ada di arsip, dan itu jadi prasyarat supaya replay bisa menyajikannya.

Yang tidak saya lakukan adalah menyalakan pywb atau replayweb.page lalu merender arsip. Body tersimpan di arsip dan replay yang benar-benar dirender adalah dua klaim yang berbeda, dan pengujian ini hanya mencakup yang pertama. Perilaku replay, kontrol autentisitas, chain of custody, dan kelayakan sebagai bukti semuanya butuh validasi terpisah.

Capture produksi butuh acceptance test yang lebih luas

Fixture ini menjawab satu pertanyaan sempit dengan jelas: apakah link runtime yang sinkron dan request yang dipanggil halaman berubah menjadi traffic jaringan dan record arsip? Pekerjaan preservasi produksi biasanya punya lebih banyak cara gagal sambil tetap menghasilkan WACZ yang valid.

Mulailah dari replay. Buka paket itu di sistem replay yang benar-benar akan dipakai koleksi, lalu bandingkan sekumpulan halaman tetap dengan referensi saat capture. Periksa teks yang dirender, gambar, gaya, navigasi, dan interaksi apa pun yang penting bagi rekaman. Lalu cek panel jaringan browser replay untuk subresource yang hilang. Sebuah body respons bisa ada di WARC, tetapi replay tetap gagal karena rewriting, indeks, timing, origin, atau dependensi tidak selaras. Review ini tidak menyeberang ke batas itu.

Perilaku dinamis layak punya fixture sendiri. Link kelas C di sini muncul sinkron saat page load. Aplikasi nyata bisa menampilkan konten setelah timer, scroll, penutupan consent, perubahan route, custom element, atau rangkaian API yang panjang. Tanam satu target yang diketahui di balik tiap perilaku yang Anda andalkan dan verifikasi baik hit server maupun body yang diarsipkan. Default behaviors Browsertrix berguna sebagai input untuk tes itu, bukan bukti bahwa semua state yang tertunda sudah tercapai. Issue #723 sangat relevan kalau link muncul selama behaviors, bukan saat eksekusi halaman awal.

Capture yang diautentikasi menambah pertanyaan sesi. Pastikan status login masuk ke profil browser, bertahan melalui navigasi yang diperlukan, dan tidak bocor ke koleksi yang seharusnya terisolasi. Uji refresh token dan alur logout. Kalau arsip berisi material pribadi atau sensitif, uji juga kontrol akses dan retensi untuk file hasilnya sebagai bagian dari rencana acceptance yang sama. Capture yang secara teknis lengkap tetap bisa ditangani dengan salah setelah pengumpulan.

Service worker, media streaming, WebSocket, unduhan, frame lintas origin, dan signed URL masing-masing layak mendapat halaman representatif kalau memang penting untuk target. Fixture sebelas halaman ini tidak menjelaskan apa-apa tentang mereka. Ia juga tidak membuktikan bagaimana crawler bertingkah saat sebuah halaman aktif selama menit-menit tertentu, mengirim request setelah jendela settle biasa, atau membutuhkan gesture pengguna. Hindari menjadikan "real Chromium" sebagai klaim cakupan serba mencakup; definisikan perilaku browser yang harus dipertahankan koleksi Anda dan buat masing-masing bisa diamati.

Terakhir, simpan bukti yang dibutuhkan untuk mendiagnosis miss. Simpan digest image dan perintah yang persis, log Browsertrix, daftar halaman, indeks, checksum WARC/WACZ, bukti request di sisi server bila tersedia, dan manifest ground-truth kecil. Untuk capture berulang, catat waktu, konfigurasi, dan environment bersama artefaknya. Rekaman itu tidak otomatis membuatnya sah secara hukum, tetapi membuat klaim teknis bisa direproduksi dan memperlihatkan apakah perbedaan belakangan berasal dari target, crawler, atau stack replay.

Berapa biaya fixture berbody kecil ini dalam byte

Fixture ini hanya menyajikan beberapa ratus byte per halaman, jadi rasio overhead-nya tidak boleh diproyeksikan ke situs yang penuh aset. Dalam batas sempit itu, saya mengukur komposisi arsip, bukan hanya ukuran akhirnya:

Jumlah per jenis dan total byte tersedia di publik capture-summary.json; porsi memakai total konten record 17.024 byte sebagai penyebut.

Pada run body kecil ini, record request lebih berat daripada konten respons, dan byte request plus urn:pageinfo: sekitar 2,1× payload respons. Itu menggambarkan campuran record pada fixture ini, bukan rasio WARC umum.

Di disk, selama tiga run terisolasi:

Mengambil nilai median, muncul empat rasio:

Dan di dalam WACZ itu sendiri:

Baris terakhir itulah yang paling mengejutkan saya. Hampir sepertiga paket arsip, pada crawl kecil, adalah catatan crawl itu sendiri, bukan web-nya.

Pengukuran ini stabil: payload respons identik byte per byte di ketiga run (5.339 B setiap kali), sementara WARC.gz dan WACZ bervariasi di bawah 0,4%.

Rasio itu tidak bisa langsung dipakai untuk halaman nyata dengan gambar, font, dan bundle script besar. Namun poin strukturnya tetap sama: record request dan page-info menciptakan overhead yang tidak bergantung pada ukuran payload. Ukur sampel yang representatif sebelum merencanakan storage produksi; jangan kalikan rasio fixture 10× dengan estimasi korpus.

Setup, dan disk yang perlu Anda siapkan

Begitu Docker atau Colima terpasang dan berjalan, setup khusus Browsertrix cukup docker pull webrecorder/browsertrix-crawler:latest, lalu docker run … crawl --url … --generateWACZ. Image-nya sudah membawa Chromium, jadi tidak perlu browser terpisah atau environment Python.

Biaya dari kenyamanan itu, pada run yang diukur di sini:

Container adalah tempat friksi terjadi, dan garis download-plus-unpack itulah biaya bundling browser. Saya menjalankannya dengan --shm-size 1g, dan karena fixture saya berada di host sementara crawl berjalan di container, saya butuh --add-host=host.docker.internal:host-gateway serta fixture yang dibind ke 0.0.0.0, bukan loopback. Kalau Anda meng-crawl internet publik, langkah jaringan itu bisa dilewati sepenuhnya, tetapi jika Anda mengarsipkan sesuatu di mesin sendiri atau host staging internal, sisihkan waktu satu sore untuk itu.

Direktori output adalah baris yang paling mudah diremehkan. Proyeksikan pertumbuhan itu ke crawl nyata dan rencanakan storage sebelum mulai, bukan setelah disk penuh pukul 3 pagi.

Startup browser kemungkinan memberi kontribusi yang cukup besar pada crawl 28–30 detik untuk hanya sebelas halaman, tetapi saya tidak mengisolasi startup dari waktu navigasi atau packaging. Tidak ada kesimpulan throughput per halaman yang bisa diambil dari run ini.

Merencanakan storage tanpa menyalahgunakan rasio fixture

Cara yang paling berguna untuk menentukan ukuran koleksi adalah empiris. Pilih halaman yang mewakili distribusi target yang sebenarnya: shell aplikasi tipis, landing page berat gambar, unduhan dokumen, artikel panjang, dan tampilan terautentikasi kalau itu termasuk scope. Capture setiap kelas dengan behaviors dan setting packaging yang memang akan dipakai. Ukur payload respons, WARC, WACZ, indeks, log, sisa profil browser, dan workspace sementara apa pun yang masih ada selama run. Pemakaian disk puncak sama pentingnya dengan ukuran bundle akhir kalau packaging sesaat menyimpan beberapa salinan sekaligus.

Pisahkan komponen tetap dan variabel. Image container 3,51 GB adalah overhead deployment yang bisa dipakai bersama oleh banyak capture pada satu worker. Record request, record page-info, indeks, dan daftar halaman tumbuh seiring aktivitas crawl. Body respons sangat bergantung pada target, sedangkan log bergantung pada durasi run dan verbosity. Retensi dan replikasi kemudian menggandakan koleksi akhir secara terpisah dari perilaku crawl. Model kapasitas yang menyatukan semuanya menjadi “byte per halaman” akan rapuh.

Kompresi dan deduplikasi juga perlu konten yang representatif. Payload respons fixture ini identik byte per byte di tiga run, tetapi itu tidak menggambarkan halaman dengan iklan yang berubah, timestamp, respons yang dipersonalisasi, atau URL aset yang terus berubah agar tidak di-cache. Kalau capture berulang adalah bagian dari program, ukur capture berurutan pada halaman yang sama dan inspeksi record revisit, jangan berasumsi halaman yang tampak tidak berubah akan terdeduplikasi dengan baik. Demikian juga, uji apakah log dan indeks direplikasi pada level yang sama dengan payload preservasi.

Secara operasional, pasang ambang peringatan sebelum koleksi dimulai. Pantau ruang kosong, pertumbuhan per koleksi, packaging yang gagal, dan ukuran profil browser atau direktori sementara. Jalankan latihan restore dari WACZ yang disimpan, bukan cuma lewat checksum. Rasio di atas berguna karena menunjukkan komponen apa saja yang ada; sampel yang representatif-lah yang memberi tahu seberapa besar komponen itu untuk situs Anda.

Dokumentasikan asumsi itu di samping estimasi kapasitas dan tinjau ulang setelah pilot crawl.

Disiplin scope, diuji dengan dua kontrol

Crawler arsip yang kebablasan adalah risiko operasional yang nyata — Anda bisa berakhir dengan masalah hukum sekaligus tagihan storage. Homepage saya menaut ke http://outofscope.test:<port>/page/out, hostname berbeda yang mengarah ke fixture yang sama, jadi hit dengan Host header itu akan membuktikan fetch di luar scope tanpa traffic internet publik.

Baris kedua itulah yang membuat baris pertama bermakna. Pada any, link itu diakses dua kali, jadi memang bisa dijangkau — angka nol pada scope prefix default benar-benar disiplin scope, bukan link yang kebetulan tidak terlihat crawler. Ada laporan terbuka tentang kunjungan di luar scope pada konfigurasi lain, #788, yang tidak saya reproduksi pada scope prefix default di fixture ini. Layak diketahui keberadaannya; tidak layak kalau saya mengaku melihatnya.

Robustness-nya biasa saja, dalam arti yang baik. Route yang mengembalikan HTTP 500 dan dead link sama-sama diminta, crawl selesai bersih dengan WARC dan WACZ yang valid, dan dead link disimpan sebagai record revisit yang dideduplikasi, bukan membuat semuanya gagal.

Kelebihan dan kekurangan

Kelebihan

• Menangkap link DOM yang disuntikkan saat runtime dan panggilan fetch() yang dipicu halaman — keduanya terkonfirmasi di arsip dan di sisi server, pada path yang tidak muncul sebagai literal di mana pun.
• HTML statis dan traversal kedalaman lengkap: 4/4 link, 3/3 rantai kedalaman, tanpa miss.
• Setelah Docker/Colima berjalan, satu docker run menghasilkan WARC dan WACZ; Chromium sudah ada di dalam image.
• Scope default prefix bekerja tanpa fetch di luar scope; any meluas sesuai dokumentasi, jadi knob-nya memang melakukan apa yang dikatakannya.
• Output-nya adalah arsip berbasis standar (WARC, dibundel sebagai WACZ dengan indeks CDX dan daftar halaman), bukan blob proprietary.
• Arsip nyaris deterministik: payload byte-identical di tiga run, ukuran di disk bervariasi di bawah 0,4%.
• Perilaku gagal yang bersih: route 500 dan broken link tidak membatalkan crawl.

Kekurangan

• Literal URL di JavaScript yang tidak dieksekusi tidak akan ditemukan (0/2), meskipun file yang memuatnya diarsipkan. Itu benar secara desain, tapi tetap celah cakupan nyata kalau tujuan Anda adalah discovery endpoint.
• Jejaknya berat: pull ~1 GB, 3,51 GB di disk, dan direktori output yang cepat membesar.
• Overhead byte cukup besar pada halaman kecil — request plus record pageinfo melebihi payload aktual, dan sekitar 30% WACZ adalah crawl log.
• AGPL-3.0 berarti ada pekerjaan kepatuhan yang serius kalau di-embed secara komersial.
• Bukan tool structured data. Tidak ada schema, tidak ada pemetaan field, tidak ada baris rapi di akhir.
• Throughput per halaman memang sedang-sedang saja, karena setiap halaman lewat browser sungguhan.

Siapa yang sebaiknya memakainya, dan siapa yang tidak

Browsertrix ditujukan untuk tim yang artifact wajibnya adalah arsip resource yang diambil browser, bukan baris data hasil ekstraksi. Dalam fixture ini, body respons yang di-fetch saat runtime hadir di WARC dan dibundel ke WACZ. Library, redaksi berita, dan peneliti adalah kandidat pengguna yang masuk akal, tetapi adopsi produksi tetap harus menguji replay yang dirender, autentikasi, service worker, alur consent, perilaku tertunda, aset streaming, kontrol retensi, dan kebutuhan penanganan bukti apa pun secara terpisah.

Jangan pakai ini kalau yang Anda butuhkan sebenarnya data. Kalau targetnya adalah "ambil semua produk dan harga dari 400 halaman ini ke spreadsheet," pengarsip adalah jalan yang aneh menuju hasil itu — Anda akan mengarsipkan gigabyte data lalu tetap harus menulis kode ekstraksi terhadap file WARC. Jangan pakai juga kalau Anda sedang memetakan permukaan API aplikasi, karena hasil kelas B dengan jelas menunjukkan bahwa parser JavaScript statis bisa menemukan endpoint yang tidak pernah disentuh Browsertrix. Dan kalau Anda alergi pada Docker atau bekerja di tempat image 3,5 GB sudah jadi masalah, ini bukan tool yang akan menyesuaikan diri untuk Anda.

Otorisasi dan retensi

Kontrol scope tidak memberikan otorisasi. Tetapkan host yang diizinkan, retensi, dan akses arsip sebelum crawling, terutama ketika capture permanen bisa memuat data pribadi. Tes prefix/any menunjukkan bahwa perubahan konfigurasi mengubah jangkauan jaringan; itu tidak menentukan jangkauan mana yang legal untuk koleksi tertentu.

Review terkait: aspek hukum web scraping dan pengarsipan.

Alternatif berdasarkan output yang dibutuhkan

Pilih berdasarkan artifact. Browsertrix menargetkan preservasi dalam WARC/WACZ. Library otomasi browser seperti Playwright memberi Anda halaman yang bisa diprogram, tetapi packaging capture tetap harus Anda urus sendiri. Crawler untuk discovery endpoint menginventarisasi URL, sementara tool ekstraksi mengembalikan teks atau record terstruktur. Kategori-kategori ini bisa sama-sama memakai browser, tetapi menyelesaikan pekerjaan yang berbeda.

Review terkait: review Heritrix.

Pengungkapan: Thunderbit adalah produk penerbit dan tidak diuji dalam fixture Browsertrix ini. Produk tersebut termasuk kategori ekstraksi terkelola, menghasilkan teks halaman atau data terstruktur, bukan arsip berbasis standar. Review ini hanya mendukung batas output, bukan klaim perbandingan performa atau kemampuan.

Coba Thunderbit untuk Ekstraksi Data Web

Putusan akhir

Gunakan Browsertrix Crawler ketika output yang dibutuhkan adalah capture WARC/WACZ dan Chromium yang dikontainerisasi cocok dengan deployment Anda. Pada fixture ini, record arsip dan hit server sepakat untuk DOM runtime yang sinkron dan fetch yang dipanggil halaman, scope prefix default mengecualikan host kedua, dan route gagal tidak menghalangi terbentuknya arsip yang valid.

Sebelum dipakai di produksi, validasi replay, perilaku tertunda, sesi terautentikasi, service worker, komposisi storage pada halaman representatif, dan kewajiban lisensi. Batas yang diuji di sini lebih sempit: referensi kode yang tidak pernah dieksekusi tidak menghasilkan request maupun record arsip untuk targetnya, walaupun script yang memuatnya tetap dipertahankan.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apa bedanya WARC dan WACZ di sini? WARC berisi request, respons, dan record terkait yang ditangkap. WACZ membungkus WARC bersama indeks, daftar halaman, metadata, dan log untuk distribusi serta tooling replay. Review ini memeriksa keduanya, tetapi tidak merender replay.

Bagaimana cara memperkirakan storage? Ukur halaman yang representatif dan simpan komposisi penuh WACZ, termasuk log dan indeks, di sampel. Rasio dalam artikel ini berasal dari body respons yang sangat kecil, jadi tidak cocok dikalikan dengan jumlah URL produksi.

Apakah tool ini akan keluar dari situs yang saya tuju? Tidak pada setelan default, menurut pengujian saya. Dengan --scopeType prefix, link ke hostname lain di-fetch nol kali; saat diubah ke --scopeType any, link itu di-fetch dua kali, yang membuktikan link tersebut memang bisa dijangkau dan angka nol pada default benar-benar disiplin scope. Ada laporan upstream terbuka tentang kunjungan di luar scope pada konfigurasi lain yang tidak saya reproduksi pada default, jadi cek setelan scope Anda sendiri, jangan berasumsi.

Apa yang harus saya uji sebelum mengklaim fidelity replay? Muat WACZ di sistem replay yang akan dipakai dan bandingkan halaman yang dirender, interaksi, serta subresource yang dibutuhkan terhadap capture live atau referensi. Keberadaan body di WARC memang perlu, tetapi tidak otomatis membuktikan replay yang dirender.

Apakah Browsertrix mengubah halaman arsip menjadi baris data terstruktur? Tidak. Output-nya adalah paket arsip, bukan tabel field terpilih. Kalau deliverable Anda adalah produk, harga, kontak, atau skema lain, Anda masih butuh tahap ekstraksi setelah capture — atau tool lain yang output utamanya adalah data terstruktur.