Yandex öz prosesini dörd mərhələdə təsvir edir və problemin hansı mərhələyə aid olduğunu bilmək qeyri-müəyyən şikayəti həll oluna bilən problemə çevirir.
Mərhələ 1 — indeksləmə üçün skan etmə
Robot hansı saytların skan ediləcəyinə, nə qədər tez-tez və neçə səhifənin yoxlanılacağına qərar verir. Məlum səhifələrin siyahısı daxili və xarici keçidlərdən, sitemap-dən, Yandex Metrica məlumatlarından və robots.txtfaylından gəlir. 10 MB-dan böyük səhifələr indekslənmir.

Cavabların idarə edilməsi birmənalıdır:
200 OK— skan edildi.3XX— robot yönləndirmə hədəfini skan edir.4XXvə5XX— səhifə daxil edilmir və əgər əvvəllər axtarışda idisə, silinir.
Və bundan irəli gələn faydalı hiylə: əgər CMS xətası səbəbindən səhifə müvəqqəti olaraq işləmirsə, serveri bunun əvəzinə 429 cavab verməsi üçün tənzimləyin. 429 Robot kodu yoxlayır və səhifəni silmir. Lakin davamlı olaraq Yandex-ə serverin çətinlik çəkdiyini bildirir vəskan sürətini azaldır,
ona görə də bu, parametr deyil, sadəcə bir yaraqdır. HTTP/2 dəstəklənir

— daha sürətli yüklənmə və daha aşağı server yükü, baxmayaraq ki, Yandex bunun skan tezliyini və ya reytinqi dəyişmədiyini açıq şəkildə bildirir və HTTP/1.1 işləməyə davam edir.
Mərhələ 2 — indeksləşdirmə Robot məzmunu təhlil edir və saxlayır: description meta teqi,title , snippet üçün Schema.org işarələnməsi; noindex direktivi, səhifəni kənarda saxlayır;rel=”canonical”
, bir qrup üçün üstünlük verilən ünvanı elan edir; və mətn, şəkillər və video. Məzmun səhifələr arasında üst-üstə düşdükdə, onlar dublikat olur.
Mərhələ 3 və 4 Axtarış üçün uyğun səhifələrin məlumat bazası yığılır və nəticələr bundan yaradılır. Nəticələr müntəzəm olaraq yenilənir və bu yeniləmələr saytda heç nə dəyişmədən saytın mövqeyini dəyişə bilər
— bu da əksər “biz düşdük və heç nə dəyişmədi” suallarına düzgün cavabdır.
Model nə üçün vacibdir
Bunu necə tətbiq edirik
The 429 behaviour is the practical gift here: during a CMS incident it keeps pages in the index instead of letting them be dropped for 5XX responses, which turns a two-hour outage into a non-event rather than a two-week recovery. We put it in the incident runbook for every client with a fragile stack — and we take it out again once the incident ends, because sustained 429 costs crawl rate.
Əlaqəli xidmətlər