Pemulihan Wayback Machine: 4 Jebakan dan Cara Menghindarinya

Wayback Machine membuat restorasi terlihat mudah: pilih tanggal, dapatkan kembali situs Anda. Lalu Anda membuka folder yang telah dipulihkan dan menemukan halaman parkir domain di tempat yang seharusnya beranda, setengah gambar mengembalikan 404, dan footer dari tahun 2011 di bawah halaman dari tahun 2017. Saya sudah cukup banyak membersihkan pemulihan yang gagal untuk mengetahui bahwa kegagalan dapat diprediksi. Empat jebakan yang sama merusak hampir setiap pemulihan Wayback Machine yang buruk, dan masing-masing membutuhkan waktu sekitar sepuluh menit untuk diperiksa agar bisa dicegah. Inilah yang salah, mengapa, dan cara menangkapnya sebelum Anda membayar apa pun.

Mengapa pemulihan Wayback Machine bisa salah

Arsip bukanlah cadangan dari situs Anda. Itu adalah tumpukan perayapan oportunistik: halaman yang berbeda ditangkap pada hari yang berbeda, beberapa aset dilewati sama sekali, beberapa tangkapan dipicu saat situs Anda rusak. Alat pemulihan hanya bisa bekerja dengan apa yang diambil oleh perayap. Sebagian besar bencana pemulihan berasal dari memperlakukan arsip seperti cermin sempurna dan melewatkan pemeriksaan di bawah ini.

Angka-angka membuat ini konkret. Pada satu pekerjaan klien, forum phpBB 2009 dengan sekitar 8.000 URL yang diarsipkan, enam bulan snapshot terbaru semuanya adalah tangkapan pengalihan yang mengarah ke penjual domain. Pemulihan dari tanggal terbaru default akan menghasilkan 8.000 salinan halaman untuk dijual. Data yang bagus ada di sana, dua tahun sebelumnya. Alatnya baik; pemilihan tanggal adalah segalanya.

Jebakan 1: Memulihkan halaman parkir

Domain kedaluwarsa, registrar memarkirkannya, dan Wayback Machine dengan senang hati merayapi halaman parkir. Dari tampilan kalender, tangkapan itu terlihat identik dengan yang bagus, lingkaran biru yang sama, stempel waktu yang sama. Petunjuknya baru terlihat saat Anda membuka snapshot: iklan di tempat konten Anda seharusnya, spanduk yang menawarkan domain untuk dijual, logo registrar di sudut.

Parkir sering kali mendarat pertama di beranda sementara halaman yang lebih dalam masih menampilkan konten asli, jadi melihat sekilas satu halaman tidak cukup. Saya pernah melihat pemulihan di mana beranda adalah halaman parkir dari tahun 2020 dan halaman tentang adalah konten asli tahun 2016, situs yang dipulihkan terbaca seperti catatan tebusan.

• Buka snapshot yang sebenarnya, bukan hanya thumbnail kalender, sebelum memilih tanggal
• Periksa beranda dan setidaknya dua halaman internal dari periode yang sama
• Jika snapshot terbaru diparkir, mundurlah di kalender ke tangkapan terakhir dengan desain asli Anda
• Pastikan snapshot menampilkan navigasi Anda, bukan peternakan tautan registrar

Jebakan 2: Rantai pengalihan dan lingkaran tangkapan

Saat sebuah situs mulai mengalihkan, domain lama ke domain baru, http ke https, non-www ke www, perayap mencatat pengalihan, bukan konten. Memulihkan dari tangkapan tersebut dan Anda mendapatkan halaman yang menunjuk ke halaman yang menunjuk ke halaman. Kasus klasik: tahun terakhir snapshot untuk situs yang bermigrasi domain tidak lain adalah tangkapan 301, dan konten berhenti diarsipkan pada hari migrasi terjadi.

Varian yang buruk adalah lingkaran pengalihan: halaman A mengalihkan ke halaman B, halaman B mengalihkan kembali ke A, dan perayap mengarsipkan kedua lompatan. Peramban menyerah setelah beberapa lompatan dan demikian pula pengunjung Anda.

Perbaikannya memiliki dua bagian. Pulihkan dari sebelum pengalihan dimulai, dan pertahankan aturan pengalihan yang disengaja yang aktif selama jendela yang Anda pilih, alih-alih rantai rusak yang direkam perayap. Di Restorix, opsi keep-301/302 melakukan hal itu, opsi ini mempertahankan pengalihan yang disengaja dan membuang yang tidak disengaja. Jika Anda memulihkan secara manual, grep HTML yang diunduh untuk pembungkus pengalihan archive.org sebelum mengunggah apa pun; mereka bersembunyi di tag meta refresh dan tautan kanonis.

Jebakan 3: Gambar hilang dan aset rusak

Perayap bersikap sopan. Mereka menghormati robots.txt, menyerah pada server lambat, dan melewatkan file yang melebihi batas ukuran. Gambar adalah korban pertama. Sebuah halaman dapat ditangkap dua puluh kali sementara gambar utamanya tidak pernah ditangkap. Anda juga akan kehilangan aset yang berada di balik perlindungan hotlink atau di subdomain CDN yang diabaikan perayap.

Pelanggar terburuk adalah gambar latar yang direferensikan dari file CSS. HTML halaman diarsipkan dengan baik, stylesheet diarsipkan dengan baik, dan foto 400 KB yang ditunjuk stylesheet tidak, sehingga halaman dipulihkan dengan ruang abu-abu di tempat desain dulu berada. Anda baru menyadarinya saat membuka situs yang dipulihkan, kecuali Anda memeriksanya terlebih dahulu.

• Periksa manifes file untuk status tangkapan per file alih-alih menganggap gambar ada
• Harapkan celah di folder /uploads/ pada situs dengan banyak gambar dan alokasikan waktu untuk mencari pengganti
• Terima bahwa apa pun di balik login, formulir POST, atau rendering JavaScript tidak ada dalam arsip sama sekali
• Periksa secara acak lima gambar pada snapshot yang diarsipkan sebelum memutuskan tanggal

Tidak ada alat pemulihan yang dapat memulihkan file yang tidak pernah ditangkap arsip. Yang dilakukan alat yang baik adalah menunjukkan celah di awal, Restorix menghasilkan manifes JSON/SQLite yang mencantumkan setiap file dan statusnya, sehingga Anda menemukan lubang di estimasi, bukan setelah penerapan.

Jebakan 4: Stempel waktu campuran di seluruh halaman

Perayap sering mengunjungi beranda Anda dan jarang mengunjungi halaman dalam Anda. Pulihkan seluruh situs dan beranda mungkin dari Maret 2019 sementara halaman harga dari Oktober 2015. Hasilnya terbaca seperti situs yang dikelola oleh penjelajah waktu: harga lama, staf yang pergi, footer hak cipta yang tidak konsisten dari halaman ke halaman.

Seorang klien pernah memulihkan situs restoran dan dengan bangga meluncurkannya, dengan menu 2014, halaman reservasi 2017, dan beranda 2019 yang mengumumkan koki yang telah pergi tiga tahun sebelumnya. File-file itu semuanya asli. Campuran itulah masalahnya.

Gunakan pemilihan rentang tanggal untuk membatasi pemulihan ke jendela yang koheren. Untuk situs brosur, enam hingga dua belas bulan biasanya cukup. Untuk forum atau toko, terima penyebaran pada utas lama dan halaman produk tetapi tetapkan halaman arahan utama ke era yang sama. Kemudian jalankan cari-dan-ganti pada petunjuk yang jelas: tahun, harga, nomor telepon, nama staf.

Saat pemulihan Wayback Machine adalah alat yang salah

Terkadang arsip tidak memiliki situs Anda. Jika robots.txt memblokir perayap, jika seluruh situs berada di balik login, atau jika situs dibangun setelah perayapan terakhir dan mati muda, tidak ada yang bisa dipulihkan. Periksa kalender sebelum merencanakan hal lain. Saat arsip kosong, opsi realistis Anda adalah salinan cache web dari beberapa halaman kunci, cadangan lama dari host atau pengembang sebelumnya, atau membangun kembali dari awal dengan konten apa pun yang dapat Anda selamatkan.

Pemulihan juga merupakan alat yang salah saat Anda hanya membutuhkan satu halaman. Menyimpan satu halaman dari arsip secara manual membutuhkan dua menit; pemulihan penuh untuk mendapatkan seluruh situs yang berfungsi kembali.

Cara memeriksa snapshot sebelum pemulihan Wayback Machine

1. Buka snapshot dan klik melalui tiga tingkat navigasi
2. Lihat sumber dan cari pembungkus web.archive.org yang perlu dihilangkan
3. Pastikan lima gambar acak dimuat dari salinan yang diarsipkan
4. Bandingkan tanggal tangkapan beranda dengan tanggal tangkapan halaman dalam
5. Verifikasi snapshot adalah situs Anda, bukan halaman parkir, bukan perusakan peretasan, bukan pengalihan
6. Catat URL dengan stempel waktu lengkap sehingga alat pemulihan menggunakan tepat tangkapan yang Anda periksa

Lima menit pemeriksaan lebih baik daripada memulihkan 9.000 file yang salah. Atau lewati kerja manual: jalankan estimasi gratis di layanan ini dan itu menunjukkan jumlah file yang diarsipkan tepat, ukuran total, dan harga tetap untuk tanggal yang Anda pilih sebelum Anda membayar. Jika jumlahnya terlihat salah, 12 file untuk situs yang Anda ingat memiliki ratusan halaman, itu adalah arsip yang memberi tahu Anda bahwa snapshot lebih tipis dari yang terlihat.

Daftar periksa pemulihan Wayback Machine

Cetak atau biarkan terbuka di tab. Setiap item memakan waktu kurang dari dua menit, dan setiap item yang dilewati adalah pemulihan yang mungkin harus Anda bayar dua kali. Jika Anda ingin melakukan daripada memeriksa, panduan memulai cepat mencakup pemulihan itu sendiri langkah demi langkah.

Setiap pemulihan buruk yang saya perbaiki gagal pada pemilihan snapshot, bukan pada unduhan. Arsip memberi tahu Anda apa yang dimilikinya, bacalah sebelum Anda membelinya.