If-modified-since sorğu başlığı Googlebot-a səhifənin son ziyarətindən bəri dəyişib-dəyişmədiyini yoxlamağa imkan verir və heç bir yeniləmə olmadıqda HTTP 304 Not Modified statusunu alır. Bu mexanizm serverin bütün səhifə məzmununu yenidən göndərməsinin qarşısını alır ki, bu da əhəmiyyətli dərəcədə bant genişliyinə və emal resurslarına qənaət edir. Bu protokolu tətbiq etməklə siz axtarış sistemlərinin məhdud krol büdcələrini artıq məlumatlara deyil, ən cari və dəyərli məzmununuza yönəltmələrini təmin edirsiniz.
Googlebot bir URL-i ziyarət etməyə qərar verdikdə, saytınızı başa düşmək üçün həmişə tam HTML gövdəsini yükləməyə ehtiyac duymur. Veb serveriniz şərti sorğuları dəstəkləmək üçün konfiqurasiya edilibsə, o, kroler tərəfindən təmin edilən zaman damğasını aşkar edə və dərhal cavab verə bilər. Bu handshake, verilənlər bazanıza və tətbiq məntiqinizə lazımsız yükü qarşısını alan, aparatınızın daha çox eyni vaxtda istifadəçi sorğularını idarə etməsinə imkan verən səmərəli veb arxitekturanın fundamental aspektidir.
304 statusu saytınız üçün niyə vacibdir?
Axtarış sistemi botu saytınızı ziyarət etdikdə, HTML, CSS və şəkilləri yükləmək üçün server resurslarını istehlak edir. Səhifə dəyişdirilməyibsə, tam cavab göndərmək səmərəsizdir. 304 status kodundan istifadə etmək resursun eyni qaldığını bildirir və krolerə keşlənmiş versiyasına etibar etməyi tapşırır.
Bant genişliyinə qənaət etməkdən əlavə, 304 cavabı tam 200 OK ötürülməsindən əhəmiyyətli dərəcədə sürətlidir. Serverin backend skriptlərini icra etməsinə və ya verilənlər bazasını sorğulamasına ehtiyac olmadığı üçün gediş-gəliş vaxtı minimuma endirilir. Gecikmənin bu azalması, Googlebot-un vaxt məhdudiyyətləri səbəbindən sorğunu tərk edə biləcəyi böyük inventarları olan saytlar üçün həyati əhəmiyyət kəsb edir.
Tipik yüksək trafikli mühitdə, həddindən artıq tam səhifə sorğuları serverin doymasına səbəb ola bilər. Statik məzmun yoxlamalarını veb server səviyyəsinə yükləməklə, tətbiq səviyyəsinin artıq sorğularla yüklənməsinin qarşısını alırsınız. Bu səmərəlilik krolerin yeni, dəyişdirilmiş səhifələri daha sürətli kəşf etməsi üçün yer yaradır.
- Məzmun generasiyasını atlayaraq server CPU və yaddaş istifadəsinin azaldılması.
- Yüksək trafikli veb saytlar üçün bant genişliyi istehlakının azaldılması.
- Googlebot-un yeni səhifələri daha tez kəşf etməsinə imkan verən daha sürətli krol ötürmə qabiliyyəti.
- Həddindən artıq sorğu həcmi səbəbindən server tərəfində xətaların aşağı ehtimalı.
Googlebot if-modified-since başlığını necə istifadə edir?
Googlebot səhifələrinizin son dəyişdirilmə tarixini izləyir. Sonrakı ziyarətlər zamanı o, son uğurlu krolun zaman damğasını ehtiva edən if-modified-since başlığını göndərir. Serveriniz daha sonra bu zaman damğasını faktiki fayl dəyişikliyi tarixi ilə müqayisə edir.
Məntiq sadədir: əgər resursun Last-Modified zaman damğası sorğudakı tarixdən daha yenidirsə, server yeni məzmunla 200 OK göndərir. Tarixlər eynidirsə və ya fayl daha köhnədirsə, server 304 statusu qaytarır. Bu yoxlama veb server səviyyəsində, çox vaxt tətbiq səviyyəsi sorğunu emal etməzdən əvvəl baş verir.
Bu qarşılıqlı əlaqə serverinizin zaman damğalarını dəqiq saxlamaq və müqayisə etmək qabiliyyətindən çox asılıdır. Əgər serveriniz bu başlıqları həmişə görməməzlikdən gəlmək üçün səhv konfiqurasiya edilibsə, siz effektiv şəkildə Googlebot-u dəyişməyən səhifələri yenidən emal etməyə məcbur edirsiniz ki, bu da krol büdcənizin pis istifadəsidir.
Server tərəfi məntiq tələbləri
Serveriniz bu başlığı düzgün oxumaq üçün konfiqurasiya edilməlidir. Fayl təqdim olunan tarixdən bəri yenilənməyibsə, server boş gövdə ilə 304 cavab kodu qaytarır. Fayl dəyişibsə, o, yenilənmiş məzmunla birlikdə tam 200 OK statusunu qaytarmağa davam edir.
Alien Road bu texnologiyanı necə tətbiq edir
Alien Road-da biz server tərəfi keşləmənin və şərti sorğuların nəzərdə tutulduğu kimi işlədiyini təsdiqləmək üçün dərin texniki auditlər aparırıq. Googlebot sorğularının statik və ya dəyişməyən məzmun üçün 304 cavabları alıb-almadığını görmək üçün server loqlarını yoxlayırıq. Tipik bir işdə biz serverlərin başlığı görməməzlikdən gəldiyi və tam yükləmələri məcbur etdiyi, resursları israf etdiyi səhv konfiqurasiyaları müəyyən edirik. Daha sonra biz tərtibatçılara səmərəliliyi artırmaq üçün server cavab məntiqini yeniləmək üçün xüsusi təlimatlar veririk.
Elektron ticarət müştəriləri ilə işləyərkən, biz tez-tez məhsul səhifələrinin hər gün tamamilə yenidən krol edildiyini görürük. Düzgün ETag və Last-Modified başlıqlarını aktivləşdirməklə, biz bu xüsusi səhifələr üçün verilənlər bazasındakı yükü əhəmiyyətli dərəcədə azaldırıq. Biz bu təkmilləşdirmələri 304-ün 200 cavabına nisbətini izləmək üçün server giriş loqlarını təhlil edərək izləyirik və Googlebot-un vaxtını statik səhifələrə deyil, təzə yeniləmələrə sərf etməsini təmin edirik.
Prosesimiz daxili diaqnostik skriptlərdən istifadə edərək canlı səhifələrin cavab başlıqlarını yoxlamağı əhatə edir. Daha sonra biz idarə olunan şəraitdə serverin davranışını müşahidə etmək üçün if-modified-since başlığını simulyasiya edirik. Bu, Googlebot ziyarət etdikdə gözlənilən 304 statusunu almasını təmin edir, optimallaşdırmamızın aktiv olduğunu və nəzərdə tutulan səmərəliliyi təmin etdiyini təsdiqləyir.
İcrada ümumi tələlər hansılardır?
Səhv server vaxtı parametrləri uğursuzluğun ən tez-tez rast gəlinən səbəbidir. Server saatınız sürüşərsə və ya krolerin gözlədiyindən fərqli vaxt qurşağından istifadə edərsə, müqayisə məntiqi uğursuz olur. Bundan əlavə, bəzi məzmun idarəetmə sistemləri bu başlıqları hər sorğuda dəyişən dinamik parametrlərlə əvəz edir ki, bu da 304 statusunu qaytarmağı qeyri-mümkün edir.
Digər bir ümumi xəta, tərtibatçılar hər səhifə yüklənməsində sənəd dəyişikliyini tetikleyen ‘cari vaxt’ ekranı və ya sessiyaya əsaslanan kukilərin yoxlanılması kimi dinamik elementləri daxil etdikdə baş verir. Səhifənin faktiki məzmunu eyni olsa belə, bu kiçik dinamik əlavələr serverin səhifəni dəyişdirilmiş kimi qəbul etməsinə səbəb ola bilər və hər dəfə tam 200 OK cavabını məcbur edə bilər.
Biz tez-tez yük balanslaşdırıcılarının və ya CDN konfiqurasiyalarının başlıqları mənşə serverinə çatmazdan əvvəl ləğv etdiyi problemləri görürük. Bütün infrastrukturunuzun, kənardan backend-ə qədər, bu şərti sorğu başlıqlarını qorumaq və yerinə yetirmək üçün konfiqurasiya edildiyindən əmin olmaq vacibdir.
Googlebot krol vaxtı aşımı problemləri serveriniz müəyyən vaxt çərçivəsində sorğuya cavab verə bilmədikdə baş verir və bu, natamam indeksləşdirməyə gətirib çıxarır.
Google Search Central
Server başlıqlarınızı necə yoxlamaq olar?
Serverinizin davranışını əl ilə yoxlamaq üçün curl kimi komanda xətti alətlərindən istifadə edə bilərsiniz. Başlıq daxil olmaqla bir səhifə tələb edərək, infrastrukturunuz tərəfindən qaytarılan cavab kodunu yoxlaya bilərsiniz. Bu, serverinizin canlı trafik məlumatlarına ehtiyac duymadan şərti sorğunu düzgün şərh etdiyini təsdiqləyir.
Bu diaqnostik addım istehsala dəyişikliklər etməzdən əvvəl vacibdir. Yerli olaraq sınaqdan keçirməklə, canlı saytınızda krol davranışında geniş yayılmış problemlərə səbəb ola biləcək təsadüfi səhv konfiqurasiyaların qarşısını alırsınız.
- Terminalınızda ‘curl -I -H “If-Modified-Since: ” ‘ işlədin.
- Cavab kodunun 200 əvəzinə 304 olduğunu yoxlayın.
- Content-Length başlığının 304 cavabında sıfır olduğunu və ya buraxıldığını təsdiqləyin.
- Heç bir əlavə dinamik başlığın keş yoxlama məntiqini ləğv etmədiyinə əmin olun.
Bu həftə haradan başlamaq lazımdır
Ən tez-tez krol edilən səhifələri müəyyən etmək üçün son 48 saat üçün server loqlarınızı nəzərdən keçirin. Bu yüksək həcmli səhifələrə 304 tətbiqi sınaqları üçün prioritet verin. Əgər serveriniz hazırda dəyişməyən səhifələr üçün 200 qaytarırsa, şərti sorğu idarəetməsini aktivləşdirmək üçün infrastruktur komandanızla məsləhətləşin. Bu sadə düzəliş çox vaxt əhəmiyyətli sayt arxitekturası dəyişiklikləri tələb etmədən kiçik krol büdcəsi məhdudiyyətlərini həll edir.