Pag-download ng Buong Site mula sa Wayback Machine

Ang pag-save ng isang page mula sa Wayback Machine ay tumatagal ng dalawang minuto. Ang pag-save ng buong site ay ibang usapan, uri ng trabahong ubos ang buong weekend kung walang plano. Hindi iniimbak ng archive ang site mo bilang isang buo. Libo-libong hiwalay na captures ang hawak nito, bawat isa frozen sa sarili nitong crawl time, at ang pag-uugnay-ugnay nito pabalik bilang isang coherent na website ay kung saan nauubusan ng lakas ang karamihan. Tatalakayin ng gabay na ito ang mga problema na talagang sumisira sa whole-site downloads, at ang punto kung saan hindi na optional ang automation.

Bakit mas mahirap ang Wayback Machine site download kaysa sa isang page

Isang capture lang ang isang page. Ang site naman ay bawat URL na natagpuan ng crawler, bawat isa naka-archive sa sarili nitong iskedyul. Maaaring may 9,000 captures ang homepage mo. Ang shipping-returns page mo ay maaaring tatlo lang, at ang pinakabago ay maaaring 2017 pa. Kapag nag-download ka ng site mula sa Wayback Machine, nag-aassemble ka ng mosaic mula sa mga tiles na hindi talaga ginawa para magkasya nang magkakasama.

Mas lalong sumasama dahil sa assets. Ang logo ay isang capture. Ang stylesheet ay isa pa, posibleng mula sa ibang taon. Ang archive ay naghahatid ng bawat isa gamit ang rewritten URLs na tumutugma lang sa loob ng web.archive.org, kaya kapag kinopya mo lang ang site, masisira agad kapag binuksan mo locally. Nagpapatawad ang isang page sa mga kasalanang ito. Limang daang page ay nagpaparami nito.

I-mapa muna ang site bago mag-download ng kahit ano

Huwag magsimula sa wget. Magsimula sa CDX API at kunin ang buong inventory ng talagang hawak ng archive:

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

Sasabihin sa iyo ng isang request na iyon kung ilang unique URLs ang meron, aling sections ang na-crawl, at saan ang mga butas. Sa isang kamakailang trabaho, isang 2009 phpBB forum, nagpakita ang inventory ng 22,000 unique URLs. Siguro 1,400 lang sa mga iyon ang tunay na content. Ang iba ay session IDs, print-view duplicates, at calendar pages na hindi naman binabasa ng kahit sino.

Basahin ang inventory tulad ng isang contractor

• Bilangin ang URLs ayon sa directory. Ang malaking /images section ay nangangahulugang naitabi ang assets; ang manipis ay nangangahulugang hirap mamaya.
• Tingnan ang date spread bawat section. Kung tumigil ang blog mo noong 2016 pero tumatakbo ang homepage hanggang 2023, nadelink o nablock ang blog, hindi tinanggal.
• Maghanap ng mga junk patterns nang maaga: session parameters, reply-to forms, sort orders. Pinapalaki nito ang bilang at oras ng download mo.
• Tandaan ang MIME types. Maraming text/html na walang image entries ay nangangahulugang itinabi ng archive ang kalansay at nawala ang balat.

Kung gusto mo ang inventory nang hindi sumusulat ng kahit isang request, ipinapakita ng libreng estimate sa Restorix ang eksaktong bilang ng archived files at kabuuang laki para sa isang domain bago ka gumastos ng kahit ano. Nagbabago sa plano ang numerong iyon. Tatlong daang files ay isang DIY na hapon. Tatlumpung libo ay hindi.

Ang mga problema na sumisira sa Wayback Machine site download

Bawat item sa listahang ito ay nakasunog sa akin nang hindi bababa sa isang beses. Wala sa mga ito ay halata hangga't tatlong oras ka na sa download at walang saysay ang output.

• Kasaysayan ng robots.txt. Sa loob ng maraming taon tumanggi ang archive na mag-crawl o maghatid ng mga page na naka-block ng robots.txt. Kung mali ang configuration ng nakaraang owner, buong directory na lang ang wala sa archive, at walang tool na makakabuo nito.
• Host sprawl. Ang www.example.com, example.com, blog.example.com, at ang lumang CDN host ay magkakaibang capture sets. Ang prefix query sa isang host ay palihim na nawawala ang iba, at ganun din ang crawler script.
• http laban sa https. Kaparehong page sa parehong scheme ay naka-archive nang dalawang beses, minsan nang may magkakaibang assets. Piliin ang variant na may mas magandang coverage, hindi ang naalala mo.
• JavaScript-rendered pages. Itinabi ng crawler kung ano ang ma-execute nito sa crawl time. Ang isang 2019 React site ay maaaring bumalik bilang shell ng mga walang lamang div at ang tunay na content ay wala na.
• Timestamp drift. Ang mga file na naka-capture noong 2014, 2017, at 2021 na pinagsama sa isang site ay lumilikha ng sirang layout at hindi tugmang navigation. I-anchor lahat sa isang target date.
• Ang Wayback chrome. Kasama ng mga snapshot na normal na naihatid ang archive toolbar at rewritten links. Kunin gamit ang id_ suffix sa timestamp, o magplano na alisin ang chrome sa bawat file na i-save mo.

Query strings, pagination, at iba pang URL traps

Dito tahimik na sumasablay ang whole-site downloads: sa query strings. Sa archive, ang /shop?cat=shoes at /shop?cat=hats ay magkaibang URL na may magkakaibang captures. Ganun din ang?page=2 at?page=200. Isang WooCommerce store ng kliyente na ginawa ko ay may 4,000 archived URLs at 90 lang na tunay na produkto. Ang iba ay filter combinations, sort orders, at tracking parameters.

Mekanikal ang strategy. Kunin ang CDX list, i-group ang URLs ayon sa path bago ang question mark, at magdesisyon kung aling parameters ang may content. Product IDs at pagination: itago. Session IDs, UTM tags, at filter permutations: tanggalin. Kung mali sa isang direksyon, mawawala ang tunay na pages. Kung mali sa kabilang direksyon, sampung beses ang junk na madownload at babayaran mo sa oras.

Kapag may butas ang Wayback Machine site download mo

Ang nawawalang assets ay panuntunan, hindi eksepsyon. Maghintay ng mga butas sa:

• Mga lazy-loaded at JavaScript-injected images na hindi naitrigger ng crawler
• CSS background images at web fonts na naka-reference mula sa loob ng stylesheets
• Video at audio files, na hindi consistent na naka-capture ng archive
• Fonts at icons na na-load sa pamamagitan ng third-party kits na nangangailangan ng live API key
• Kahit anong naihatid mula sa third-party domain, ad network, o nasa likod ng login

Para sa bawat butas, limitado ang options mo: sumubok ng mga kalapit na timestamp, subukin ang www at non-www o http at https variants, o tanggapin ang pagkawala at i-regenerate ang asset. Dito pinapatunayan ng manifest ang halaga nito. Nagbibigay ang Restorix ng JSON o SQLite file manifest sa bawat restore, kaya ang pag-alam kung aling files ang nawawala ay nagiging filter query na lang sa halip na buong hapon ng pag-click sa mga page.

Kailan titigil sa pag-script at mag-automate

Magmath nang tapat. Ang isang matibay na download script para sa magulong site ay isang weekend para gawin at i-debug, dagdag pa ang mga oras ng reruns kapag ni-throttle ka ng archive.org sa file 8,000 ng 9,000. Tapos magsisimula pa ang buong pangalawang proyekto: pag-alis ng Wayback rewrites, pag-ayos ng internal links, pagpili ng canonical host, pag-deploy, at pag-test.

May sentido ang automation sa sandaling kailangan na gumana ulit ang site sa halip na umiral lang sa disk mo. Hinahawakan ng website restoration tool ang download, cleanup, at deploy sa isang trabaho: bayad per restored file, libre ang unang file, nakalock ang presyo sa oras ng estimate, at may automatic refund sa balance mo kapag may sumablay. May sentido pa rin ang DIY route para sa maliliit na site, research pulls, at mga taong talagang nag-eenjoy sa puzzle. Ginawa ko na ang dalawang route nang mas maraming beses kaysa sa kaya kong bilangin, at ang breakeven point ay mas maaga kaysa sa inaasahan ng mga tao, karaniwan sa pangalawang rerun pa lang.

Mula sa na-download na files patungo sa gumaganang site

1. Alisin ang Wayback toolbar at i-rewrite ang bawat archive.org URL pabalik sa relative path.
2. Pumili ng isang canonical host, www o non-www, at i-redirect ang isa pa.
3. I-convert ang internal links sa HTTPS bago mag-deploy kahit saan na modern.
4. Tanggalin ang patay na third-party scripts: lumang analytics, ad tags, at social widgets na nagpapadala ng data pabalik.
5. Mag-deploy, tapos i-click through ang top 50 pages na bukas ang browser network tab para mahuli kung ano pa ang nagbabalik ng 404.

Dalawang bagay ang laging sumasablay sa yugtong ito: contact forms at search. Parehong umaasa sa server code na hindi naman naka-capture ng archive. Palitan ang forms ng hosted form service o plain mailto link, at palitan ang site search ng static index o search-engine scoped box.

Isinasama ng Restorix ang lahat ng ito sa restore options: relative internal links, HTTPS conversion, analytics stripping, one-click deploy sa SSH, FTP, o S3, at maliit na kasamang CMS para manatiling editable ang restored site. Gawin manually o hayaan ang serbisyo; pareho lang ang checklist. Ang oras lang ang nagkakaiba.