Paano Hanapin ang Lahat ng Pahina sa Isang Website (Kahit ang mga Na-delete)

Ilang pahina ba talaga ang mayroon sa aming site? Parang tanong na may database sa likod. Pero bihira itong totoo. Noong nakaraang taon, iginiit ng isang kliyente na may 400 pahina ang kanilang site. Ang sitemap ay nagsabing 1,900. Ang crawl ay nakatagpo ng 3,400. Ang index ng Wayback Machine CDX ay naglista ng 11,000 URL na naisilbi ng site, kalahati nito ay matagal nang na-delete. Apat na pinagmulan, apat na sagot, at lahat ay tama tungkol sa magkakaibang bagay.

Narito ang apat na paraan na ginagamit ko upang hanapin ang lahat ng pahina sa isang website, kung ano talaga ang saklaw ng bawat isa, at kung paano pagsamahin ang mga ito sa isang malinis na listahan na maaari mong aksyunan.

Bakit mahirap hanapin ang lahat ng pahina sa isang website

Walang master list maliban na lang kung ang CMS ay nag-iingat nito, at kahit ganoon, ang alam lang nito ay ang sarili nito. Ang mga tunay na site ay nag-iipon ng mga pahina na hindi kasama sa iisang imbentaryo: mga orphaned page na walang menu link, mga seksyong naiwan ng lumang migration, mga upload na minsang binanggit sa isang email campaign, mga faceted URL na nabubuo nang kusa, buong subdomain na itinayo noong 2016 at nakalimutan.

Bawat paraan ng pagtuklas ay nakakakita ng iba't ibang bahagi ng kaguluhang iyon. Ang sitemap ay ang sariling ulat ng CMS. Ang crawler ay nagmamapa ng link graph. Ang CDX index ng Wayback Machine ay naaalala ang kasaysayan. Ang Search Console ay nag-uulat kung ano talaga ang ipinakita ng Google sa mga user. Wala sa mga ito ang kumpleto; kapag pinagsama, malapit na ito.

Magpasya kung para saan ang listahan bago ito buuin. Ang imbentaryo para sa migration, SEO audit, at pag-recover ng patay na site ay nangangailangan ng parehong hilaw na materyal ngunit magkakaibang paglilinis.

Ang sitemap: pinakamabilis na paraan upang hanapin ang lahat ng pahina sa isang website

Magsimula sa /sitemap.xml. Kung ito ay 404, tingnan ang robots.txt para sa Sitemap: directive, maraming site ang naglalagay ng file sa kakaibang path. Ang WordPress core ay naghahatid ng /wp-sitemap.xml mula pa noong bersyon 5.5; ang Yoast at Rank Math ay bumubuo ng /sitemap_index.xml, na sumasanga sa mga child sitemap ayon sa uri ng post. Kunin ang index, pagkatapos ang bawat child.

Nililimitahan ng protocol ang bawat sitemap file sa 50,000 URL at 50 MB na hindi naka-compress, kaya ang malalaking site ay laging gumagamit ng mga index, huwag tumigil sa unang file na makita.

Ngayon ang mga babala, dahil ang mga sitemap ay nagsisinungaling sa pamamagitan ng pagkukulang. Ang sitemap ay naglilista lamang ng alam ng CMS: walang orphaned media upload, walang pahinang na-delete taon na ang nakalipas, walang legacy section na tumatakbo sa labas ng CMS, walang nabuo ng custom script sa /old-tools/. At sa mga hand-rolled o lumang sitemap, maging ang alam na listahan ay kathang-isip. Spot-check ang mga petsa ng lastmod laban sa mga pahinang kamakailan mong na-update; kung hindi magkatugma, huwag pagkatiwalaan ang anuman.

I-crawl ang site tulad ng gagawin ng Googlebot

Ang crawler ay nagsisimula sa homepage at sinusundan ang bawat link na nakikita nito, katulad ng ginagawa ng search engine. Ang Screaming Frog ang karaniwang ginagamit sa industriya at libre hanggang 500 URL; ang Sitebulb ay mas madaling gamitin para sa mga audit; para sa ganap na kontrol, ang maliit na Python script na may requests at BeautifulSoup, o wget sa spider mode, ay walang bayad.

Nakikita ng crawling ang mga hindi nakikita ng sitemap: mga naka-paginate na archive na walang nagdagdag sa sitemap, mga pahina ng tag at kategorya, mga sirang link na tumuturo sa mga pahinang umiiral pa, mga redirect chain na sumusunog ng crawl budget.

Ang mga blind spot nito ay salamin ng sa sitemap. Kung walang nagli-link sa isang pahina, hindi ito mahahanap ng crawler. Ang mga menu na nire-render ng JavaScript ay nangangailangan ng headless browser o ang crawl ay titigil sa homepage. At ang faceted navigation, mga filter, kalendaryo, sort order, ay maaaring magpalobo ng isang 500-pahinang tindahan sa 500,000-URL na crawl trap; magtakda ng mga patakaran sa pagbubukod bago pindutin ang simula, hindi pagkatapos. Sa mga site na hindi mo pag-aari, panatilihing mababa ang concurrency at sundin ang robots.txt.

Ang Wayback CDX API: hanapin ang lahat ng pahina sa isang website, noon at ngayon

Ito ang paraan na halos walang gumagamit at ito ang nakakahanap ng pinakamarami. Ang CDX server ng Internet Archive ay maglilista ng bawat URL na na-capture nito para sa isang host, kasama ang mga pahinang na-delete isang dekada na ang nakalipas, na hindi makikita ng anumang live na paraan.

Isang curl command ang kumukuha ng buong imbentaryo:

curl "https://web.archive.org/cdx/search/cdx?url=example.com/*&output=text&fl=timestamp,original,statuscode&filter=statuscode:200&collapse=urlkey&from=2010&to=2020"

Ang mga parameter na mahalaga: ang collapse=urlkey ay nagde-duplicate ng paulit-ulit na capture ng parehong URL; ang filter=statuscode:200 ay nagtatanggal ng mga 404 at redirect; ang matchType=domain ay nagpapalawak ng saklaw sa mga subdomain; ang from at to ay nagtatakda ng mga taon. Para sa isang patay na site, ang window ng petsa na iyon ang kung saan naroon ang ginto.

Asahan ang dami. Ang isang matagal nang forum o tindahan ay maaaring magbalik ng milyun-milyong row, at ang ingay ng query-string, mga session ID, tracking parameter, ay nagpapalaki ng listahan. Ang API ay libre ngunit may rate limit, kaya maging matiyaga sa malalaking domain at hatiin ang malalaking pull sa taunang chunks.

Kung gusto mo ang sagot nang walang abala, pinapatakbo ng Restorix ang parehong index para sa libreng pagtatantya nito, i-paste ang isang domain at iuulat nito ang eksaktong bilang ng naka-archive na file at kabuuang laki sa ilang segundo, walang kinakailangang query.

Google Search Console: hanapin ang lahat ng pahina na ipinapakita ng iyong website sa Google

Para sa mga site na pag-aari mo, nagdaragdag ang Search Console ng isang dataset na wala sa iba: kung ano talaga ang na-index at naisilbi ng Google. I-verify ang pagmamay-ari, pagkatapos ay gamitin ang dalawang ulat.

• Ulat ng Performance, tab na Pages: bawat URL na nakakuha ng impression, nae-export. Nililimitahan ng web UI ang mga export sa 1,000 row; ang Search Analytics API ay lumalampas nang malayo doon, at ang bulk export sa BigQuery ay naghahatid ng buong dataset araw-araw.
• Ulat ng Indexing, Pages: indexed kumpara sa crawled-currently-not-indexed, na may mga sample URL, isang mabilis na pagtingin kung gaano karami sa site ang pinag-aabalahan pang panatilihin ng Google.

Ang natatanging halaga ay ang data ng impression: mga pahinang naabot ng tunay na mga user, kasama ang mga orphan na walang nagli-link. Kung ang isang nakalimutang landing page ay nakakakuha pa rin ng tatlumpung click sa isang buwan, isasama ito sa listahan ng pananatilihin. Nag-aalok ang Bing Webmaster Tools ng parehong mga ulat kung mahalaga sa iyo ang trapiko mula sa Bing.

Pagsamahin, alisin ang duplicate, at linisin ang listahan

Apat na pinagmulan, apat na format, ang pagsasama-sama ang kung saan lumilitaw ang halaga. Ilagay ang lahat sa isang CSV, pagkatapos ay i-normalize bago alisin ang duplicate, o ang parehong pahina ay lilitaw nang anim na beses sa anim na pagkukunwari.

Ang mga pagkukunwaring iyon ay hindi haka-haka. Ang isang tunay na pahina ng produkto ay maaaring lumitaw bilang https://www.example.com/page/?utm_source=newsletter, http://example.com/page, example.com/page/#comments, example.com/page?fbclid=abc123, www.example.com/page/index.html, at EXAMPLE.com/page, anim na row, isang dokumento. Ang case, protocol, www, parameter, fragment, at default na filename ay kailangang bumagsak sa iisang canonical form bago magkaroon ng saysay ang pag-aalis ng duplicate. Laktawan ito at ang iyong 11,000-URL na imbentaryo ay talagang 6,000 URL na nakasuot ng costume.

• Gawing lowercase ang hostname; ganap na alisin ang mga fragment (#section).
• Tanggalin ang mga tracking parameter: utm_*, fbclid, gclid, ref. Pagbukud-bukurin ang natitirang query parameter.
• Pumili ng isang kumbensyon sa trailing-slash at ipatupad ito.
• I-collapse ang protocol at www variants sa iyong canonical form.

Pagkatapos alisin ang duplicate, uriin ang bawat URL: live 200, nagre-redirect, 404 ngayon ngunit naka-archive, o tuluyang nawala. Ang ikatlong bucket, na-delete ngunit naroroon sa data ng CDX, ang siyang nakakalimutan at pinagsisisihan ng mga migration. Isang dalawampung-linyang Python script ang humahawak ng lahat ng ito para sa karamihan ng mga site; ang mga spreadsheet ay nakakayanan hanggang ilang libong URL.

Mabilis na paghahambing ng apat na pinagmulan:

Nahanap mo na ang bawat pahina, ano na ngayon

Para sa isang migration, ang listahan ay nagiging iyong redirect map: bawat URL na may impression sa Search Console o capture sa data ng CDX ay makakakuha ng 301 patungo sa pinakamalapit nitong modernong katumbas. Para sa isang SEO audit, inilalantad ng mga column ng crawl at index ang mga manipis na seksyon at crawl trap. Pareho itong ilang hapon ng tapat na trabaho.

Kung ang listahan ay para sa isang patay na site na gusto mong ibalik, laktawan ang manu-manong pag-rebuild. Ibinabalik ng ang aming tool sa pag-restore ang buong bagay mula sa Wayback Machine: ipinapakita ng libreng pagtatantya ang eksaktong bilang ng file at laki na may naka-lock na presyo, nagbabayad ka bawat na-restore na file na ang una ay libre, at ang mga opsyon sa paglilinis ay nagtatanggal ng lumang analytics, ginagawang relative ang mga link, at mina-minify ang mga asset. Ang resulta ay nade-deploy sa iyong hosting sa isang click, o nai-export bilang XML, CSV, o JSON na may buong file manifest kung gusto mo ang hilaw na materyal sa halip. Alinmang paraan, ang enumeration work na ginawa mo ay nagsasabi sa iyo nang eksakto kung ano ang dapat na nilalaman ng isang mahusay na restore.