Magsimula sa mga inaasahang pahina at napapagamit na ebidensya
Ilista ang mga pampublikong pahina na gusto mong makita ng mga naghahanap: mga pangunahing produkto, artikulo, kategorya, at mga inilipat na URL. Para sa bawat isa, itala ang ginustong URL, inaasahang tugon, indexability, template, may-ari, at prayoridad. Panatilihin ang lehitimong exclusions na hiwalay.
Kumuha ng hindi naka-authenticate na tugon, headers, redirect path, source ng pahina, rendered view, estado ng internal-links, at estado ng sitemap para sa mga representative na URL. Sampolan ang bawat template at pattern ng URL. Ang ebidensya ay may petsa: ang setting ng CDN, deployment, consent layer, o personalization ay maaaring magbago nito mamaya.
Ang pumapasa na homepage ay hindi nagpapatunay na gumagana ang listings, variant ng produkto, o localized routes.
Panatilihin ang may petsang headers at rendered na ebidensya para maikumpara ang mga pag-aayos at mga regresyon mamaya.
Gawing sinadya ang indexability
Ang indexability ay nangangahulugang maaaring isama ang isang pahina sa search index; hindi ito kapareho ng crawling o pagraranggo. Suriin ang meta robots directives sa HTML at ang X-Robots-Tag sa mga HTTP response header. Ang noindex directive ay nagsasabi sa mga search engine na huwag ipakita ang isang pahina; ang X-Robots-Tag ay naaangkop din sa mga non-HTML na file tulad ng PDF.
Suriin ang robots.txt nang hiwalay. Kailangan ma-access ng crawler ang isang pahina para makita ang noindex directive, kaya ang pag-block sa URL na iyon ay maaaring pumigil sa direktibang makita. Suriin ang naka-deploy, pampublikong tugon dahil ang mga setting ng CMS at environment flags ay maaaring magdagdag ng mga patakaran. Ang noindex ay hindi access control: protektahan ang sensitibong materyal gamit ang authentication at angkop na pagsusuri sa seguridad.
I-flag ang noindex, login responses, mga sanggunian sa staging, at na-block na mahahalagang assets sa mga pahinang inaasahang mai-index.
Maaaring maglaman ang HTTP response header ng direktiba kahit wala mang HTML head.
Gawing iisa ang ginustong URL
Ang canonicalization ay tumutukoy sa ginustong URL sa pagitan ng mga duplicate o napakalapit na bersyon, tulad ng HTTP at HTTPS, magkakaibang host, tracking parameter, filters, o print pages. Ihambing ang canonical element, internal links, sitemap URL, at redirect destination. Para sa isang indexable na pahina, normal na dapat nilang tukuyin ang iisang absolute preferred URL.
Gumamit ng permanent server-side redirect kapag tinatanggal ang isang duplicate. Inilarawan ng Google ang permanent redirects at rel=canonical bilang malalakas na senyales, habang ang pagsama sa sitemap ay mas mahina; ang magkakahanay na senyales ay nagpapalakas ng preference. Huwag gamitin ang robots.txt para mag-canonicalize o magbigay ng nagkakumpitensyang canonicals. Nakakatulong ang self-referencing canonical upang ipahayag ang ginustong bersyon, ngunit ang pagpili ng search engine ay nananatiling wala sa iyong kontrol.
Idokumento ang mga variant, ang ginustong target, ang kinakailangang kontrol, at isang may-ari.
Subukin ang old-to-new mappings bago ang migration at panatilihing may handang reversible redirect change.
Suriin ang mga status code at pag-uugali ng redirect
Nagsasabi ang mga status code sa mga browser at crawler kung ano ang nangyari. Dapat magbalik ang mahahalagang live na pahina ng makabuluhang 2xx response na may inaasahang nilalaman. Ang isang pahina na walang kaukulang kapalit ay dapat magbalik ng tunay na 404 o 410; ang inilipat na nilalaman ay dapat makarating sa pinakamalapit at pinaka-makabuluhang kapalit. Ang 200 na pahina na nagpapakita lamang ng error ay maaaring tratuhin bilang soft 404.
I-record ang bawat redirect hop. Karaniwang sinusunod ng Google hanggang 10 hops para sa pangkalahatang web crawling, ngunit nagdaragdag ang mga chain ng latency at fragility. Sinasabi ng Google na ang 5xx at 429 responses ay pansamantalang maaaring pabagalin ang crawling at ang persistent server errors ay maaaring sa huli tanggalin ang mga naka-index na URL. Siyasatin ang paulit-ulit na kabiguan kasama ang engineering owner sa application, CDN, origin, cache, dependency, at deployment layers.
I-save ang original URL, hops, codes, final URL at inaasahang estado.
Alisin ang magkapatong na CMS, CDN, host, locale, o slash rules sa halip na magdagdag ng isa pang hop.
I-validate ang JavaScript rendering at mga ruta
Suriin ang parehong initial HTML at isang rendered view para sa mga pangunahing template. Kumpirmahin ang pangunahing nilalaman, headings, links, canonical, robots directives, at estado pagkatapos ng rendering. Inilarawan ng Google ang magkakahiwalay na crawl, render, at index phases at sinasabi na ang nilalamang hindi makikita sa rendered HTML ay hindi maaaring ma-index.
Gumamit ng anchor elements na may href values para sa navigation. Hindi mapagkakatiwalaan para sa pagkakatuklas ang mga fragment-only routes na naglo-load ng magkakaibang nilalaman. Direktang i-request ang mga hindi umiiral na produkto, artikulo, at filtered URLs. Kailangan ng client-side applications ng totoong error state; dinodokumento ng Google ang pag-route sa server 404 o pagdagdag ng noindex para maiwasan ang soft 404s. Makakatulong ang server rendering o prerendering, ngunit i-verify ang naka-deploy na tugon.
Suriin ang response HTML, rendered HTML, at ang human browser view para sa mahahalagang pagkakaiba.
Mas piliin ang source HTML; kung sinet ng JavaScript, tiyaking may iisang non-conflicting canonical.
Panatilihing malinis ang sitemaps at internal links
Ang sitemap ay isang mapa ng pagkakatuklas, hindi isang utos ng pag-index. Isama ang matagumpay, inaasahan, at preferred canonical URLs; i-exclude ang redirects, errors, noindex pages, parameter duplicates, at mga protektadong URL. Inirerekomenda ng Google ang fully qualified absolute URLs at itinuturing ang pagsama sa sitemap bilang isang canonical hint, hindi garantiya.
I-validate ang sitemap at ihambing ito sa intended-index list at navigation. Dinodokumento ng Google ang UTF-8 encoding at limitasyong 50 MB uncompressed o 50,000 na URL kada sitemap. Para sa mas malalaking site, hatiin sa kapaki-pakinabang na grupo at gumamit ng index. I-update ang lastmod lamang para sa makabuluhan at napapatunayang pagbabago sa pahina.
Siyasatin ang makabuluhang pagkakaiba sa pagitan ng intended URLs, sitemap entries, at internal links.
Suriin ang generated sitemap at isang sample ng nakalistang URL pagkatapos ng routing o CMS changes.
Sukatin ang performance at i-institutionalize ang audit
Gumamit ng field data kapag available at controlled lab testing para siyasatin ang Core Web Vitals: Largest Contentful Paint para sa pag-load, Interaction to Next Paint para sa responsiveness, at Cumulative Layout Shift para sa visual na katatagan. Hatiin ayon sa uri ng pahina at device dahil maaaring itago ng averages ang isang sirang high-value template.
I-trace ang mabagal o hindi matatag na delivery sa pamamagitan ng images, CSS at JavaScript, third-party tags, fonts, embeds, at caching. Gumawa ng isang nasusukat na pagbabago, pagkatapos suriin muli ang rendering at user flows. Ang field data ay nagpapakita ng totoong karanasan ng mga gumagamit; tumutulong ang lab data sa reproduksyon. Wala sa dalawa ang nagpo-predict ng bawat hinaharap na crawler o bisita. Ulitin ang nakatutok na regression check pagkatapos ng mapanganib na release at isang mas buong audit pagkatapos ng migrations o platform changes.
Ayusin ang mga pagkabigo sa revenue-critical o madalas gamitin na mga template bago ang maliliit na pagtaas sa score sa ibang lugar.
Suriin muli ang response, canonical, rendered content, estado ng sitemap, at kaugnay na performance evidence bago isara.