Time Wayback Machine: Mga Snapshot, Timestamp, at mga Gap sa Pag-capture

Lahat ay tinatawag itong time machine, at tumatak ang pangalan dahil ang karanasan ay talagang parang paglalakbay sa panahon: mag-type ng URL, pumili ng taon, panoorin ang patay na website na muling bumuhay. Ngunit nasisira ang pagkakatulad sa sandaling kailangan mo ng partikular. Ang tunay na time machine ay maglalagay sa iyo sa eksaktong segundo na hiniling mo. Ang isa na ito ay maglalagay sa iyo saanman nandoon ang crawler, anumang araw na napuntahan nito.

Kapag naintindihan mo kung paano talaga nire-record ng time Wayback Machine ang nakaraan, mga capture, kalendaryo, timestamp, at ang mga pagitan, humihinto ka na sa paghuhula at nagsisimulang basahin ito parang instrumento. Ang gabay na ito ang manual ng may-ari.

Ano ang Talagang Ini-record ng Time Wayback Machine

Hindi tuloy-tuloy ang pag-record ng Wayback Machine. Kumukuha ito ng discrete na capture: nagre-request ang crawler ng URL, ini-store ang response, HTML, mga larawan, stylesheet, script, at tini-timestamp ito ayon sa petsa at oras ng pagbisita. Para sa URL na iyon, ang kasaysayan ay umiiral lamang sa mga sandaling iyon. Ang lahat ng nasa pagitan ay inference.

Kahanga-hanga ang sukat, daan-daang bilyong capture pabalik noong 1996, ngunit hindi pantay. Ang isang major news homepage ay maaaring ma-capture ng maraming beses sa isang araw. Ang maliit na business site ay maaaring makatanggap ng apat na pagbisita sa isang taon. Ang pahinang nasa likod ng login ay zero, kailanman. Ituring ang bawat URL bilang sarili nitong timeline na may sariling density.

Ang strip sa itaas ng anumang naka-archive na pahina ay isang bar chart ng mga capture bawat taon. Ang matataas na bar ay nangangahulugang madalas dumaan ang crawler. Ang patag o nawawalang taon ay nangangahulugang hindi ito dumaan, at ang mga dahilan ay karaniwang matutuklasan kapag alam mo kung saan titingin.

Pagbasa ng Timeline at Calendar View

Buksan ang anumang URL at makakakuha ka ng dalawang instrumento. Ipinapakita ng year strip ang bilang ng capture bawat taon. Mag-click ng taon at makakakuha ka ng kalendaryo: labindalawang buwang araw, may bilog, may wala. Ang mga bilog ay may dalang impormasyon na karamihan ay iski-skip lang.

Mabilis na nagpapakita ng halaga ang mga kulay. Isang taon ng asul na sinusundan ng isang buwan ng pula na sinusundan ng berde ay nagkukwento: nasira ang site, pagkatapos nagsimulang mag-redirect, madalas sa isang pahina ng naka-park na domain o isang hindi natapos na redesign. Kung hinahanap mo ang huling malusog na bersyon ng site, gusto mo ang huling bahagi ng asul bago magbago ang mga kulay.

Isang beses, sinubaybayan ko ang WooCommerce store ng isang kliyente sa ganitong paraan: solid asul hanggang 2019, kalat na pula noong Marso 2020, ang hack, pagkatapos mga berde na redirect sa isang domain-for-sale lander. Kumuha ng sarili ang restore target: huling bahagi ng Pebrero 2020, ang huling dense na asul na buwan bago sumama ang lahat.

Pag-decode ng Timestamp sa isang Time Wayback Machine Snapshot

Ang bawat capture URL ay may 14-digit na timestamp: /web/20150309142312/https://example.com/. Basahin ito bilang taon, buwan, araw, oras, minuto, segundo, dito, 2:23 PM noong Marso 9, 2015. Maaari mong i-edit ang mga digit na iyon nang manu-mano, at palaging ginagawa ito ng mga power user: palitan ang petsa, at i-serve ng archive ang capture na pinakamalapit sa sandaling hiniling mo.

1. Ang timestamp ay oras ng pag-crawl, hindi oras ng pag-publish. Ang isang 2015 capture ng artikulong isinulat noong 2011 ay nagsasabi pa ring 2015.
2. Lahat ay UTC. Ang capture na naka-stamp na 23:58 ay nangyari dalawang minuto bago mag-hatinggabi GMT, anuman ang sabihin ng iyong lokal na orasan.
3. Ang mga file sa parehong pahina ay maaaring magdala ng iba't ibang timestamp. Ang archive ay nagtatahi ng bawat asset mula sa pinakamalapit nitong capture, kaya ang HTML at mga larawan ng isang pahina ay maaaring magkalayo ng ilang araw.
4. Ang nearest-match ay may dalawang gilid. Humingi ng petsang walang capture at makakakuha ka ng pinakamalapit, na maaaring buwan ang layo sa isang sparse na timeline. Palaging suriin ang aktwal na timestamp ng na-load.

Bakit Nagkakaroon ng Capture Gap (at Ano ang Ipinagsasabi Nito)

Ang mga gap ang pamantayan, hindi ang eksepsiyon, at may mga dahilan na karaniwang maaari mong pangalanan.

• Popularidad. Ang dalas ng pag-crawl ay medyo sumusunod sa kung gaano kalinked at kabisita ang site. Ang mga hindi kilalang site ay bihirang ma-crawl.
• Robots.txt. Sa loob ng maraming taon, pinanatili ng isang disallow rule ang crawler sa labas, at ang mga lumang exclusion request ay maaari pa ring magtago ng buong domain.
• Downtime. Kung down ang site nang dumating ang crawler, makakakuha ka ng pulang bilog o wala talagang capture.
• JavaScript rendering. Ang mga pahinang nagbu-build ng content sa client-side ay karaniwang na-capture na walang laman.
• Mga login at paywall. Ang anumang nasa likod ng authentication ay invisible sa crawler.
• Mga gap sa pagmamay-ari. Ang isang expired na domain na naka-park sa loob ng isang taon ay lumilikha ng kalendaryo ng redirect at error capture.

Basahin nang diagnostiko, ang mga gap ay data. Ang isang two-year na butas sa kung hindi man ay dense na timeline ay karaniwang nangangahulugang pagbabago sa robots, nag-expire na domain, o mahabang outage, lahat ay worth malaman bago mo bilhin ang domain na iyon o maniwala sa kasaysayan na iyon.

Isang Kronolohikal na Workflow para sa Pagsisiyasat ng Site

1. Magsimula sa dulo. Hanapin ang huling malulusog na asul na capture, pagkatapos lumakad pabalik taon-taon hanggang lumitaw ang content na hinahanap mo.
2. Mag-sample sa pagitan. Sa isang dense na timeline, suriin muna ang isang capture bawat quarter; mag-zoom in lang sa mga buwan kung saan may pagbabago.
3. Bantayan ang mga discontinuity. Ang biglaang redesign, pagbabago ng URL structure, o alon ng redirect capture ay nagmamarka ng boundary, ang mas lumang content ay maaaring nasa ilalim ng ibang URL.
4. Mag-verify lampas sa homepage. Buksan ang lima o sampung pangunahing interior na pahina sa napiling era. Ang homepage capture ay hindi nagpapatunay ng kahit ano tungkol sa iba pang bahagi ng site.
5. I-record ang eksaktong capture URL at timestamp habang nagpapatuloy. Ang "nasa 2012 lang" ay hindi isang citation, at hindi rin isang restore target.

Isang 2009 phpBB forum na gusto ng isang kliyente. Ipinakita ng timeline ang dense na capture mula 2010 hanggang 2013, isang redesign noong 2014 na giniba ang thread URL, at isang naka-park na domain mula 2016. Ang sweet spot ay 2012–2013: kumpletong thread, gumaganang attachment, pre-spam. Ang dalawang oras ng kronolohikal na pagbasa ay nakasave ng isang linggo ng pag-restore ng maling era.

Kulang ang Time Wayback Machine

Dalawang mahihirap na limitasyon ang umaabang sa mga tao. Una, ang archive ay nagpapakita ng pahina nang isa-isa, sa browser, walang download button para sa buong site, at ang pag-rebuild ng anumang mas malaki sa dose-dosenang pahina sa pamamagitan ng kamay ay pahirap. Pangalawa, ang ilang bagay ay hindi kailanman na-capture: mga database-driven feature, search function, cart, anumang hindi nakikita ng crawler.

Ang solusyon sa unang limitasyon ay isang dedicated na restore tool. Ang website restore platform ay kumukuha ng bawat naka-archive na file para sa isang site sa isang date range na pipiliin mo, eksaktong ibinibigay ng iyong pagbasa ng timeline, at ini-rebuild ito bilang gumaganang site. Ang free estimate ay nag-uulat ng eksaktong bilang ng naka-archive na file, kabuuang laki, at naka-lock na presyo bago mo gastusin ang kahit ano; nagbabayad ka bawat na-restore na file, at ang unang file ay libre.

Kung ikaw ay nag-aalinlangan sa pagitan ng dalawang era, patakbuhin ang free estimate sa parehong date range at ihambing ang bilang ng file, isang murang paraan upang makita kung aling panahon ang pinakamahusay na sakop ng archive. Kapag nagsimula ka na, ipinapakita ng restore dashboard ang live progress na file-by-file.