Unduh Seluruh Situs dari Wayback Machine

Menyimpan satu halaman dari Wayback Machine hanya butuh dua menit. Menyimpan seluruh situs adalah pekerjaan yang sama sekali berbeda, jenis pekerjaan yang bisa menghabiskan akhir pekan jika Anda melakukannya tanpa persiapan. Arsip tidak menyimpan situs Anda sebagai satu paket rapi. Arsip menyimpan ribuan tangkapan terpisah, masing-masing membeku pada waktu perayapannya sendiri, dan menyatukannya kembali menjadi satu situs web yang utuh adalah titik di mana kebanyakan orang macet. Panduan ini membahas jebakan yang sebenarnya merusak pengunduhan seluruh situs, serta titik di mana otomatisasi tidak lagi bisa dihindari.

Mengapa mengunduh situs dari Wayback Machine lebih sulit daripada satu halaman

Satu halaman adalah satu tangkapan. Satu situs adalah setiap URL yang pernah ditemukan perayap, masing-masing diarsipkan sesuai jadwalnya sendiri. Beranda Anda mungkin memiliki 9.000 tangkapan. Halaman pengiriman-pengembalian Anda mungkin hanya punya tiga, dan yang terbaru mungkin berasal dari tahun 2017. Saat Anda mengunduh situs dari Wayback Machine, Anda sedang menyusun mosaik dari kepingan yang memang tidak dirancang untuk saling menyatu.

Aset memperburuk keadaan. Logo adalah satu tangkapan. Stylesheet adalah tangkapan lain, mungkin dari tahun yang berbeda. Arsip menyajikan masing-masing dengan URL yang telah ditulis ulang yang hanya berfungsi di dalam web.archive.org, sehingga salinan situs yang mentah akan langsung rusak saat dibuka secara lokal. Satu halaman bisa memaafkan kesalahan ini. Lima ratus halaman akan melipatgandakannya.

Petakan situs sebelum mengunduh apa pun

Jangan mulai dengan wget. Mulailah dengan CDX API dan tarik inventaris lengkap dari apa yang sebenarnya disimpan arsip:

web.archive.org/cdx/search/cdx?url=example.com/*&matchType=prefix&output=json&collapse=urlkey&filter=statuscode:200

Satu permintaan itu memberi tahu Anda berapa banyak URL unik yang ada, bagian mana yang telah dirayapi, dan di mana letak celahnya. Pada proyek terbaru, sebuah forum phpBB tahun 2009, inventaris menunjukkan 22.000 URL unik. Mungkin hanya 1.400 di antaranya yang merupakan konten asli. Sisanya adalah ID sesi, duplikat tampilan cetak, dan halaman kalender yang tidak pernah dibaca siapa pun.

Baca inventaris seperti seorang kontraktor

• Hitung URL berdasarkan direktori. Bagian /images yang besar berarti aset masih selamat; bagian yang tipis berarti akan menyusahkan nanti.
• Periksa sebaran tanggal per bagian. Jika blog Anda berhenti di tahun 2016 tetapi beranda berlanjut hingga 2023, blog tersebut kemungkinan diputus tautannya atau diblokir, bukan dihapus.
• Cari pola sampah sejak awal: parameter sesi, formulir balas, urutan pengurutan. Pola ini akan membengkakkan jumlah URL dan waktu unduhan Anda.
• Perhatikan tipe MIME. Banyaknya text/html tanpa entri gambar berarti arsip hanya menyimpan kerangka dan kehilangan tampilannya.

Jika Anda ingin melihat inventaris tanpa menulis satu pun permintaan, estimasi gratis di Restorix menampilkan jumlah file yang diarsipkan secara tepat dan total ukuran untuk sebuah domain sebelum Anda mengeluarkan biaya. Angka itu mengubah rencana. Tiga ratus file adalah pekerjaan sore hari secara mandiri. Tiga puluh ribu file bukan.

Jebakan yang merusak pengunduhan situs dari Wayback Machine

Setiap poin dalam daftar ini pernah membuat saya frustrasi setidaknya sekali. Tidak ada yang terlihat jelas sampai Anda sudah tiga jam mengunduh dan hasilnya tidak masuk akal.

• Riwayat robots.txt. Selama bertahun-tahun, arsip menolak merayapi atau menyajikan halaman yang diblokir oleh robots.txt. Jika pemilik sebelumnya salah mengonfigurasinya, seluruh direktori mungkin sama sekali tidak ada di arsip, dan tidak ada alat yang bisa memunculkannya.
• Penyebaran host. www.example.com, example.com, blog.example.com, dan host CDN lama adalah set tangkapan yang berbeda. Permintaan awalan pada satu host akan melewatkan yang lain secara diam-diam, begitu pula dengan skrip perayap.
• http versus https. Halaman yang sama di bawah kedua skema tersebut diarsipkan dua kali, terkadang dengan aset yang berbeda. Pilih varian dengan cakupan lebih baik, bukan yang Anda ingat.
• Halaman yang dirender JavaScript. Perayap hanya menyimpan apa yang bisa dieksekusi pada saat perayapan. Situs React tahun 2019 mungkin kembali sebagai cangkang div kosong dengan konten aslinya hilang.
• Pergeseran timestamp. File yang ditangkap pada tahun 2014, 2017, dan 2021 yang disatukan menjadi satu situs akan menghasilkan tata letak rusak dan navigasi yang tidak cocok. Kaitkan semuanya ke satu tanggal target.
• Elemen antarmuka Wayback. Tangkapan yang disajikan secara normal menyertakan bilah alat arsip dan tautan yang ditulis ulang. Ambil dengan akhiran id_ pada timestamp, atau bersiaplah untuk menghapus antarmuka tersebut dari setiap file yang Anda simpan.

Query string, paginasi, dan jebakan URL lainnya

Query string adalah tempat pengunduhan seluruh situs sering gagal secara diam-diam. Bagi arsip, /shop?cat=shoes dan /shop?cat=hats adalah URL berbeda dengan tangkapan berbeda. Begitu pula ?page=2 dan ?page=200. Toko WooCommerce klien yang pernah saya tangani memiliki 4.000 URL yang diarsipkan dan hanya 90 produk asli. Sisanya adalah kombinasi filter, urutan pengurutan, dan parameter pelacakan.

Strateginya bersifat mekanis. Tarik daftar CDX, kelompokkan URL berdasarkan jalur sebelum tanda tanya, dan tentukan parameter mana yang membawa konten. ID produk dan paginasi: simpan. ID sesi, tag UTM, dan permutasi filter: buang. Salah langkah di satu sisi dan Anda kehilangan halaman asli. Salah di sisi lain dan Anda mengunduh sampah sepuluh kali lipat serta membayarnya dengan waktu berjam-jam.

Saat pengunduhan situs dari Wayback Machine Anda kembali dengan celah

Aset yang hilang adalah hal yang biasa, bukan pengecualian. Bersiaplah untuk celah pada:

• Gambar yang dimuat secara lazy dan disuntikkan JavaScript yang tidak pernah dipicu perayap
• Gambar latar CSS dan font web yang direferensikan dari dalam stylesheet
• File video dan audio, yang hanya diarsipkan secara tidak konsisten oleh arsip
• Font dan ikon yang dimuat melalui kit pihak ketiga yang memerlukan kunci API aktif
• Apa pun yang disajikan dari domain pihak ketiga, jaringan iklan, atau di balik halaman login

Untuk setiap celah, pilihan Anda terbatas: coba timestamp berdekatan, coba varian www dan non-www atau http dan https, atau terima kehilangannya dan buat ulang aset tersebut. Di sinilah manifest menunjukkan nilainya. Restorix menyertakan manifest file JSON atau SQLite dengan setiap pemulihan, sehingga mengetahui file mana yang hilang cukup dengan kueri filter, bukan menghabiskan sore hari mengklik halaman satu per satu.

Kapan harus berhenti menulis skrip dan beralih ke otomatisasi

Hitung dengan jujur. Skrip unduhan yang andal untuk situs yang berantakan membutuhkan akhir pekan untuk dibuat dan di-debug, ditambah berjam-jam pengulangan saat archive.org membatasi kecepatan Anda pada file ke-8.000 dari 9.000. Kemudian proyek kedua dimulai: menghapus penulisan ulang Wayback, memperbaiki tautan internal, memilih host kanonik, melakukan deployment, dan pengujian.

Otomatisasi masuk akal saat situs perlu berfungsi kembali, bukan sekadar tersimpan di disk Anda. layanan ini menangani pengunduhan, pembersihan, dan deployment dalam satu proses: bayar per file yang dipulihkan, file pertama gratis, harga dikunci saat estimasi, dan pengembalian dana otomatis ke saldo Anda jika terjadi kegagalan. Jalur mandiri masih masuk akal untuk situs kecil, pengambilan data riset, dan orang yang benar-benar menikmati teka-teki ini. Saya telah melakukan kedua jalur ini lebih banyak kali daripada yang bisa saya hitung, dan titik impas datang lebih cepat dari yang diperkirakan orang, biasanya sekitar pengulangan kedua.

Dari file yang diunduh ke situs yang berfungsi

1. Hapus bilah alat Wayback dan tulis ulang setiap URL archive.org kembali ke jalur relatif.
2. Pilih satu host kanonik, www atau non-www, dan alihkan yang lainnya.
3. Konversi tautan internal ke HTTPS sebelum melakukan deployment di platform modern apa pun.
4. Hapus skrip pihak ketiga yang tidak aktif: analitik lama, tag iklan, dan widget sosial yang masih mencoba menghubungi server aslinya.
5. Lakukan deployment, lalu klik melalui 50 halaman teratas dengan tab jaringan browser terbuka untuk menangkap apa pun yang masih mengembalikan 404.

Dua hal yang selalu gagal pada tahap ini: formulir kontak dan pencarian. Keduanya bergantung pada kode server yang tidak pernah ditangkap arsip. Ganti formulir dengan layanan formulir terhosting atau tautan mailto biasa, dan ganti pencarian situs dengan indeks statis atau kotak pencarian yang dibatasi mesin pencari.

Restorix memasukkan semua ini ke dalam opsi pemulihan: tautan internal relatif, konversi HTTPS, penghapusan analitik, deployment satu klik ke SSH, FTP, atau S3, serta CMS kecil bawaan agar situs yang dipulihkan tetap dapat diedit. Lakukan secara manual atau biarkan layanan yang mengerjakannya; daftar periksanya sama saja. Hanya waktu yang berbeda.