Anza na kurasa zilizokusudiwa na ushahidi unaoweza kutumika tena
Orodhesha kurasa za umma unazotaka wapataji wa utafutaji waone: bidhaa kuu, makala, makundi, na URL zilizohamishwa. Kwa kila moja, rekodi URL inayopendekezwa, jibu linalotarajiwa, uwezekano wa kuorodheshwa, template, mmiliki, na kipaumbele. Weka uzuri wa kuzuia kwa tofauti mahali pengine.
Chukua jibu la bila kuingia (unauthenticated), vichwa vya majibu (headers), njia za redirect, chanzo cha ukurasa, mtazamo uliotendeka (rendered view), hali ya viungo vya ndani, na hali ya ramani ya tovuti kwa URL za mfano. Chunguza kila template na muundo wa URL. Ushahidi una tarehe: mipangilio ya CDN, utoaji (deployment), tabaka la idhini, au utofautishaji inaweza kubadilika baadaye.
Homepage inayopita haiwezi kuthibitisha kwamba orodha, tofauti za bidhaa, au njia zilizolokalizishwa zipo sawa.
Hifadhi vichwa na ushahidi uliopangwa kwa tarehe ili ikamatikane kwa ajili ya kulinganisha matokeo na regression baadaye.
Fanya uwezekano wa kuorodheshwa (indexability) uamuzi makusudi
Uwezekano wa kuorodheshwa unamaanisha ukurasa unaweza kujumuishwa kwenye faharasa ya utafutaji; sio sawa na crawling au nafasi (ranking). Angalia maelekezo ya meta robots katika HTML na kichwa cha majibu cha X-Robots-Tag. Amri ya noindex inaambia injini za utafutaji zisifanye ukurasa uonyeshwe; X-Robots-Tag pia inatumika kwa faili zisizo za HTML kama PDF.
Kagua robots.txt kivyake. Crawler lazima iupate ukurasa ili kugundua amri ya noindex, hivyo kuzuia URL hiyo kunaweza kuzuia amri kuonekana. Angalia jibu lililotumwa kwa umma kwa sababu mipangilio ya CMS na bendera za mazingira inaweza kuongeza sheria. noindex si udhibiti wa upatikanaji: linda nyenzo nyeti kwa uthibitisho (authentication) na kupitia ukaguzi wa usalama unaofaa.
Tambua noindex, majibu ya kuhitaji kuingia (login responses), marejeo ya staging, na mali muhimu zilizozuiliwa kwenye kurasa zinazokusudiwa kuorodheshwa.
Kichwa cha majibu ya HTTP kinaweza kubeba amri hata pale ambapo hakuna kichwa cha HTML.
Fanya URL moja iwe pendwa na thabiti
Canonicalization inaonyesha URL inayopendekezwa kati ya toleo za nakala au toleo zinazofanana sana, kama HTTP na HTTPS, hosts tofauti, vigezo vya ufuatiliaji, vichujio, au kurasa za kuchapisha. Linganisha elementi ya canonical, viungo vya ndani, URL za sitemap, na mwelekeo wa redirect. Kwa ukurasa unaoweza kuorodheshwa, mara nyingi vinapaswa kutambua URL moja ya pekee.
Tumia redirect ya kudumu (server-side) wakati unachukua nafasi nakala. Google inaelezea redirects za kudumu na rel=canonical kama ishara zenye nguvu, wakati ujumuishaji kwenye sitemap ni dhaifu zaidi; ishara zenye muafaka zinaimarisha mapendeleo. Usitumie robots.txt kukamilisha au kuipa ukurasa moja canonicals zinazoingia kinyume. Canonical inayojirejea inasaidia kuonyesha toleo linalopendekezwa, lakini uchaguzi wa injini za utafutaji uko nje ya udhibiti wako.
Andika aina za badiliko, lengo linalopendekezwa, udhibiti unaohitajika, na mmiliki.
Jaribu uingizwaji wa zamani-kwa- mpya kabla ya uhamaji na weka mabadiliko yanayorejeshwa ya redirect tayari.
Kagua misimbo ya hali (status codes) na tabia za redirect
Msimbo wa hali unaambia vivinjari na crawlers kilichotokea. Kurasa muhimu za moja kwa moja zinapaswa kurudisha jibu lenye maana la 2xx lenye yaliyotarajiwa. Ukurasa usio na mbadilisho unaofaa unapaswa kurudisha 404 au 410 halisi; yaliyohamishwa yanapaswa kufika kwa mbadilisho wake karibu na muhimu. Ukurasa wa 200 unaoonyesha tu kosa unaweza kutambuliwa kama soft 404.
Rekodi kila hatua ya redirect. Google kwa ujumla inafuata hadi hatua 10 kwa crawling ya jumla, lakini minyororo ya redirect inaongeza ucheleweshaji na udhaifu. Google inatoa kwamba majibu ya 5xx na 429 yanaweza kupunguza muda wa crawling kwa muda na hitilafu za seva za kudumu zinaweza hatimaye kuondoa URL zilizoorodheshwa. Chunguza kushindwa kwa mara kwa mara na mmiliki wa uhandisi kupitia tabaka za maombi, CDN, origin, cache, utegemezi, na utoaji (deployment).
Hifadhi URL asili, hatua (hops), misimbo, URL ya mwisho na hali inayotarajiwa.
Ondoa sheria zinazozidiana za CMS, CDN, host, locale, au slash badala ya kuongeza hatua nyingine.
Thibitisha uandishi wa JavaScript na njia (routes)
Chunguza HTML ya awali na mtazamo uliotendeka kwa template muhimu. Thibitisha kuwa yaliyomo kuu, vichwa, viungo, canonical, maagizo ya robots, na hali vinapoonekana baada ya rendering. Google inaelezea hatua za crawl, render, na index tofauti na inasema yaliyomo yasiyoonekana katika HTML iliyotendeka hayawezi kuorodheshwa.
Tumia elementi za anchor zenye thamani za href kwa urambazaji. Njia zinazotegemea fragment pekee ambazo zina pakua yaliyomo tofauti si za kuaminiwa kwa ugunduzi. Omba moja kwa moja bidhaa, makala, na URL zilizo na vichujio zisizopo. Programu za upande wa mteja zinahitaji hali halisi ya hitilafu; Google inaelezea upangaji kwa 404 ya seva au kuongeza noindex kuepuka soft 404. Utoaji wa seva (server rendering) au prerendering unaweza kusaidia, lakini thibitisha jibu lililotumika.
Angalia HTML ya jibu, HTML iliyotendeka, na mtazamo wa kivinjari wa mwanadamu kwa tofauti muhimu.
Pendelea HTML ya chanzo; ikiwa JavaScript inaiweka, hakikisha kuna canonical moja isiyopingana.
Weka ramani za tovuti (sitemaps) na viungo vya ndani safi
Ramani ya tovuti ni ramani ya ugundaji, si amri ya kuorodheshwa. Jumuisha URL zilizo fanikiwa, zinazokusudiwa, na canonical zinazopendekezwa; ziondoe redirect, makosa, kurasa za noindex, nakala za vigezo, na URL zilizo langtikiwa. Google inashauri kutumia URL kamili za absolute na hutambua ujumuishaji wa sitemap kama dalili ya canonical, sio dhamana.
Thibitisha sitemap na uitambulishe na orodha ya kurasa zinazokusudiwa na urambazaji. Google inaelezea enkodingi ya UTF-8 na kikomo cha 50 MB bila kuchanganywa au URL 50,000 kwa sitemap. Kwa tovuti kubwa, gawanya katika vikundi vyenye maana na tumia index ya sitemap. Sasisha lastmod tu kwa mabadiliko makubwa, yanayothibitishwa ya ukurasa.
Chunguza tofauti muhimu kati ya URL zinazokusudiwa, mwandiko wa sitemap, na viungo vya ndani.
Angalia sitemap iliyotengenezwa na sampuli ya URL zilizoorodheshwa baada ya mabadiliko ya routing au CMS.
Pima utendaji na weka ukaguzi wa kawaida
Tumia data ya uwanja pale inapopatikana na udhibitiwa na upimaji wa maabara ili kuchunguza Vitu Muhimu vya Mtandao (Core Web Vitals): Largest Contentful Paint (LCP) kwa upakiaji, Interaction to Next Paint (INP) kwa uwiano wa majibu, na Cumulative Layout Shift (CLS) kwa utulivu wa mwonekano. Gawanya kwa aina ya ukurasa na kifaa kwa sababu wastani unaweza kuficha template yenye thamani kubwa iliyovunjika.
Fuata upungufu wa kasi au usiothabiti kupitia picha, CSS na JavaScript, vithibitisho vya vyenye upande wa tatu (third-party tags), fonti, embeds, na caching. Fanya mabadiliko moja yaliyo chaguliwa kisha angalia tena rendering na mtiririko wa watumiaji. Data ya uwanja inaonyesha watumiaji halisi; data ya maabara husaidia kuzalisha tena tatizo. Hakuna moja kati yao inayotabiri kila crawler au mgeni wa baadaye. Rudia ukaguzi mdogo wa regression baada ya utoaji hatari na ukaguzi mkubwa baada ya uhamaji au mabadiliko ya jukwaa.
Rekebisha makosa kwenye templates muhimu kwa mapato au zinazotumika sana kabla ya kupata alama ndogo mahali pengine.
Angalia tena jibu, canonical, yaliyotendeka, hali ya sitemap, na ushahidi wa utendaji unaohusiana kabla ya kufunga kazi.
