Сървърът не предоставя датата на документа
Когато добавяте сайт или отделни страници за индексиране, някои търсачки (по-специално „Яндекс“) дават съобщение: „Внимание! Сървърът не показва датата на документа, поради което датата за него няма да бъде показана в търсенето резултати. " .
Но след няколко седмици виждате, че сайтът е индексиран и присъства в „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 на клиента