Сървърът не предоставя датата на документа

Когато добавяте сайт или отделни страници за индексиране, някои търсачки (по-специално „Яндекс“) дават съобщение: „Внимание! Сървърът не показва датата на документа, поради което датата за него няма да бъде показана в търсенето резултати. " .
Но след няколко седмици виждате, че сайтът е индексиран и присъства в „SERP“ на търсачките, а усещането, че „нещо не е наред в датското кралство“, постепенно изчезва. И напразно!
Проблемът остава и въпреки липсата на изразени външни прояви, последиците от него могат да бъдат доста сериозни и тогава ще бъде много трудно да се разбере откъде е започнало всичко.

Ето какво пише самият Яндекс за това:
Колко критично е, че сървърът ми не издава последната модификация? Опитах се да настроя, но нищо не излезе.

Първо, резултатите от търсенето няма да показват датата до страниците на вашия сайт и когато се сортират по дата, сайтът няма да бъде видим за повечето потребители. На второ място, роботът няма да може да получи информация дали страницата на сайта е актуализирана от последното индексиране и тъй като броят на страниците, получени от робота от сайта за едно посещение, е ограничен, променените страници ще бъдат преиндексирани по-малко често.

2. Откъде идва тази Последна промяна

Преди това, когато сайтовете бяха създадени в чист HTML и страниците им бяха СТАТИЧНИ, този проблем не възникна. Факт е, че уеб сървър, например Apache, обработва изпратените заглавки сам и връща правилния заглавие с Последно модифициран (време, когато документът е последно променен). Сега по-често те създават DYNAMIC страници: SSI, CGI скриптове, PHP, Perl. И уеб сървърът не поема проблема Последно модифициран за страници, които счита за динамични. Това е съвсем логично от гледна точка на уеб сървър: съдържанието, предоставено на потребителя, всъщност се създава по време на достъпа до страницата, следователно дата на модификация на самия файл скрипт или SSI страница губи своето практическо значение.

Можете, разбира се, да конфигурирате уеб сървъра така, че да обработва и дава дата на модификация на действителния скрипт на динамична страница, както и за статични html страници, а в Интернет има препоръки за това как да се приложи това на практика . например,
за SSI документи („анализирани от сървъра“):
В зависимост от настройките за хостинг, уеб сървърът на Apache ще издаде Последно модифициран в случай, че е посочена директивата "XBitHack full" (например във файла .htaccess), а атрибутът "изпълним" за групата е зададен за файла, до който се осъществява достъп (например с командата "chmod g + x име на файл ", изпълнено в Unix-черупка).
Или директивата „RemoveHandler .htm .html“ се добавя към файла .htaccess - тя премахва всички асоциации с това разширение от сървъра (например обработка на SSI команди). В резултат на това сървърът започва да изпраща датата на документите, но спира да изпълнява SSI директиви в този файл.
за PHP скриптове: за скриптове на PERL: #!/usr/local/bin/perl
използвайте POSIX qw (strftime);
my $ LM = strftime "% a,% e% b% Y% H:% M:% S GMT", gmtime (time ());
print "Последна промяна: $ LM";
Но преди да правите такива неща, най-добре е първо да разберете какво е Последно модифициран и защо е необходимо?

3. Какво е кеш от страна на клиента?

Клиентският кеш позволява на браузъра да не заявява повторно страницата, когато я опреснява или извиква отново, а да изиска само датата на нейното изменение и ако уеб сървърът потвърди, че страницата не се е променила, покажете я от кеша си . Това ви позволява значително да спестите трафик при навигация в сайта и драстично да увеличите скоростта на зареждане на страниците - вместо повторно изпращане на страницата, има размяна на малки заглавки, СТОТИНИ в пъти по-малки по размер!
Спецификацията на протоколите HTTP/1.0 и особено HTTP/1.1 предоставя гъвкава възможност за кеширане както от браузъра на страниците от страна на клиента, така и от междинните прокси сървъри.

Клиентският кеш се реализира по 2 начина:

един. Мета HTML тагове. Например следните редове деактивират кеширането на браузъра:
Има обаче някои недостатъци и "опасности" на този метод: - Ако тагът не е съществувал, когато страницата е била поискана от браузъра за първи път, но се появява по-късно, например при модифициране на файл, браузърът може да остане блажено невежи и използвайте собствени кеширани копия на оригиналната страница.
- Прокситата, които кешират уеб страници, изобщо не изследват съдържанието на HTML документ. Вместо това те разчитат само на уеб сървъра, от който идват документите, и HTTP протокола. Ако сървърът изпраща заглавки неправилно, уеб браузърът може да помисли, че не трябва да кешира страницата, но прокси сървърът между браузъра и вашия уеб сървър може да не знае това - и ще продължи да изпраща на клиента същата остаряла страница.
** Netscape версия 6 или по-малко не се справя много добре с заглавката "Pragma: no-cache". Следователно най-добрият подход е да се използват HTTP заглавки. Например, използвайки функцията за заглавие PHP, можете да приложите пример, еквивалентен на горните два мета маркера като този:

2. HTTP заглавки, изпратени както от клиент, така и от сървър.
Протоколът HTTP/1.0 предоставя следната възможност за управление на кеша от страна на клиента:
- Издаване на Last-Modified заглавка в отговор на заглавката If-Modified-Since на клиента

Освен това може да издаде заглавка като „Изтича: петък, 10 февруари 2006 12:35:29 GMT', което ако датата, посочена в него, е по-малка от текущата - деактивира кеширането, ако е повече - активира.

Протоколът HTTP/1.1 допълнително въведе още една функция за управление на кеша:
- Издаване на заглавка 'ETag' в отговор на заглавката на клиента 'If-None-Match'
Освен това HTTP/1.1 може да използва заглавката за изпращане на „уеб сървър“Контрол на кеша: max-age = 600', което казва, че до 600 секунди браузърът на клиента може да счита страницата непроменена и дори да поиска датата на нейното изменение.
Директивата HTTP/1.0 може да се използва и със заглавното поле 'Изтича: петък, 10 февруари 2006 12:35:29 GMT„което, когато се дава бъдеща дата, означава, че страницата може да бъде кеширана (освен ако не е посочено друго в полето за заглавие Cache-Control, като„Контрол на кеша: няма магазин').

Ако пренебрегнете тази възможност за управление на CACHE от страна на клиента: - Вашият сайт ще отнеме много повече време за зареждане, което, разбира се, ще отблъсне някои клиенти от сайта;
- Клиентите ще получат допълнителни разходи за входящ трафик;
- Ще получите допълнително натоварване на уеб сървъра, който ще формира и изпраща всички страници наново;
- Ще получите допълнителен входящ трафик;
- Ще получите роботи за търсене, които ще се проявят с голям брой страници на сайта и ще бъдат изразени в бавното им индексиране и повторно индексиране. Например робот на Yandex не индексира веднага целия сайт и след това се връща отново, за „друга порция“ и проверява какво се е променило. И сайтът му отговаря - „и аз имам всички 10 000 страници, и всички - нови“. Дори ако отнема 2 секунди, за да заредите страница, отнема 6 часа, за да заредите 10 000 страници! И когато Yandex Robot види, че „новите“ страници са същите като тези, които се съхраняват в неговия индекс, той няма да индексира бързо такъв сайт.
И ако имате уеб камера, снимките на която се актуализират на всеки няколко минути - какъв е смисълът да изпращате същата снимка на клиента, ако тя не се е променила?

Ако ще бъдете погрешно управлява CACHE от страна на клиента (издава неверни данни) - възможна е ситуация, когато съдържанието на сайта наистина се промени и клиентът ще го вземе от своя CACHE за дълго време.
Следователно: или не правете нищо, или, ако го направите, много внимателно!

4. Управление на кеша от страна на клиента

If-Modified-Since - Последна промяна:
За да управлява CACHE от страна на клиента, спецификацията на протокола HTTP/1.0 осигурява следния механизъм: при достъп до страница браузърът на клиента, ако такава страница е в кеша си, изпраща заглавката на сървъра: If-Modified -От: Вторник, 30 март 2004 13: 57:13 GMT, къде „Вторник, 30 март 2004 г. 13:57:13 GMT“ датата на документа от кеша на браузъра. Сървърът трябва да сравни тази дата с "последната промяна" на датата на документа и ако документът не се е променил, върнете заглавката: HTTP/1.0 304 Не е модифициран, без да изпраща самата страница. Браузърът „извежда“ страница от кеша и я показва на Клиента. Ако документът се е променил, тогава сървърът трябва да върне заглавката:

HTTP/1.0 200 OK
Последна промяна: 30 април 2005 г. 16:07:23 GMT "и след това прехвърлете самата модифицирана страница. Браузърът актуализира кеша за тази страница и запомня новата дата на нейната" последна модификация ". По този начин времето и трафикът за" прехвърляне "на страницата се запазва в клиента, ако тя не се е променила и натоварването на сървъра намалява.

В допълнение към това, съгласно спецификацията HTTP/1.0, заедно с полето на заглавката Последна промяна: 30 април 2005 г. 16:07:23 GMT, сървърът може да предаде заглавката: „Изтича: 30 април 2005 г. 20:07:23 GMT“, което информира браузъра на клиента, че преди 30 април 2005 20:07:23 GMT тази страница няма да се промени и можете да я покажете от техния КЕШ без да изпълнявате заявката „If-Modified-Since:“. към сървъра. Пълният отговор на сървъра ще изглежда така: HTTP/1.0 200 OK
Последна промяна: 30 април 2005 г. 16:07:23 GMT "
Изтича: 30 април 2005 г. 20:07:23 GMT "и/или хедър"Контрол на кеша: максимална възраст'(появява се в HTTP/1.1), където max-age - след колко секунди ще изтече копието на документа, записан в кеша на браузъра: Cache-Control: max-age = 600 "- копието ще изтече след 10 минути от времето на заявката (виж * - други директиви Cache-Control). 1. 'Контрол на кеша: максимална възраст„замества“Изтича:„ако се използват заедно.
2. Сървърът Apache автоматично издава и презаписва директивата Изтича: На 'Изтича: 1 януари 1970 г.„ако директивата не е включена в httpd.conf или .htaccess“CharsetOverride Изтича Изкл', позволявайки това поведение на сървъра САМО, ако самата страница не показва поле в заглавката Изтича:.

If-None-Match - ETag:
Спецификацията на протокола HTTP/1.1 осигурява допълнителна, по-гъвкава възможност за управление на кеш паметта от страна на клиента, която може да се извърши едновременно и ОТДЕЛНО от „Ако е променено от - последно променено“, това е замяна на заглавка ETag. Ако браузърът на клиента поддържа обмена на заглавки ETag, тогава в заявка до сървъра той може да изпрати заглавката: If-None-Match: "1c9113-1be2-40697cb9 където 1c9113-1be2-40697cb9 и има ETag - уникален хеш на документа, съхраняван в CACHE на браузъра. Този идентификатор се генерира от сървъра и се изпраща заедно със страницата. Най-често срещаният вариант е md5 ().
В отговор на заглавието "Ако-няма-съвпадение:" 1c9113-1be2-40697cb9 ", сървърът проверява промяната на страницата с дадения ETag и ако не се е променил, връща отговора:

HTTP/1.1 304 Не е модифициран
ETag: "1c9113-1be2-40697cb9", тоест връща същата стойност на ETag с код 304 и не предава самата страница. Ако страницата се е променила, тогава отговорът на сървъра: HTTP/1.1 200 OK
ETag: "2b3412-3af4-67812ac6", т.е. изпраща се нов ETag и след това се предава нова страница, която заедно с ETag браузърът съхранява в кеша си.

ETag може да бъде "строг" (два документа имат едни и същи ETags само ако съвпадат побитово) или "слаб" (два документа имат еднакви ETags, ако са еднакви по съдържание, но могат да се различават в незначителни подробности). За файл "строг" ETag може да бъде, например, неговият хеш md5, а за динамична страница, "небрежен" ETag може да бъде хеш md5 на основното му съдържание (с изключение на дизайна и банерите).
Силната заглавка на ETag има формата "Таг на обекта", докато небрежният ETag има формат "Етикет на обекта": ETag: "2b3412-3af4-67812ac6" Пример за не-строг ETag:
ETag: W/"2b3412-3af4-67812ac6"

Трябва също да се отбележи, че спецификацията на протокола HTTP/1.1 позволява на клиента да изпраща заявки до сървъра за проверка на ETag в следните формати: If-None-Match: *, което означава "всеки ETag", и във формат: If-None-Match: "string1", "string2", "stringN", което означава проверка на целия списък с ETags.

По този начин, използвайки ETag, можете да осигурите по-гъвкав механизъм за управление на кеша от страна на клиента, тъй като можете да позволите на браузъра да показва страницата от кеша, ако на страницата са настъпили незначителни промени, например само банери са променени.

5. Вземане на решение от сървъра за обновяване на страницата

Когато сървърът реши да издаде отговор за промяна на страницата, е необходимо да се вземе предвид проверката Ако е променено-от за коректност - ако Ако е променено-от Повече ▼ текущо време, трябва да дадете документ с „200 ОК“. По принцип таблицата на решението от сървъра, което решава коя заглавка да бъде издадена в различни случаи и комбинации Ако е променено-от и Ако-няма-съвпадение, както следва: