Поизучал я множество разных сайтов, в итоге есть 2 варианта, по которым работают сайты:
1. Не отдают Last-Modified вообще.
2. Отдают Last-Modified, но дата и время для всех буквально страниц одинаковые и отчетливо видно, что у всех один принцип отдачи данного заголовка - время обращения минус некий интервал времени. Причем такая ситуация касается даже таких страниц как контакты, обр. связь, как оплатить, реквизиты и т.п. Т.е. они отдают постоянно новый Last-Modified даже для таких понятно не меняющихся страниц.
Таким образом имеем, что при 1 варианте робот будет хаотично брать некий пул страниц сайта и сам определять изменились ли они или нет. Т.е. на ускорение или какое-либо улучшение индексации мы повлиять не можем.
При 2 варианте робот обращается к страницам сайта и видит, что они все изменены и робот начинает все эти страницы переиндексировать в рамках выбранного пула страниц. При таком варианте получается, что мы можем повлиять на индексацию - заставить (наверное) робота переиндексировать выбранные им страницы, но это никак не улучшает и тем более не ускоряет индексацию сайта роботом, т.к. по сути мы не выделяем реально нужные для переиндексации страницы.
Так можно прийти к выводу, что данный заголовок имеет смысл отдавать только в случае его идеальной настройки, т.е. только тогда, когда был изменен контент или структура страниц сайта. Но если учесть, что для динамических страниц это нереально трудно реализуемо (т.к. нужно отслеживать не только контент из БД, но и инфу из множества php файлов, которые участвуют в генерации одной страницы), то как мне кажется лучше доверить проверку изменений роботу, а разработчику или сеошнику уделить свое внимание другим не менее важным темам по оптимизации сайта.
P.S.
Ни на одном сайте из проверки 304 Not Modified найден не был.
Для настройки идеально правильной отдачи Last-Modified как я понял подойдет наверное хранение какого-нибудь хэша, который в следствии и нужно затем проверять, но как-то это очень...
На качество индексации влияет далеко не только Last-Modified, это не панацея.
Всем спасибо за помощь, все понял.
Нафига? - Пытался сделать по уму, но не выходит каменный цветок.
Т.е. я выбрал правильный путь и не стоит завивать этим вопросом себе голову?
У вас как я понял идет отслеживание специального поля таблиц БД. Я такой вариант видел, но не стал пробовать, т.к.
1. Не весь контент берется из БД, т.е. в большей степени заголовок будет правильным, но не на 100% для всего сайта.
2. На сайте большое кол-во страниц - карточек товаров и идет постоянное обновление цен, т.е поле с датой изменения строки таблицы будет тоже постоянно меняться. Из-за этого как мне кажется все сводится к нулю, т.к. робот будет видеть также гигантское кол-во обновленных страниц и будет индексировать их как и раньше из-за своих ограничений по числу стр. на одну индексацию.
У меня был прописан вот такой код
header("Last-Modified: ".gmdate("D, d M Y H:i:s",time())."GMT");
По какой причине?
Сори за пропажу, выходные...
Страниц в поиске ~1500
Дата проставляется правильно, и такая дата будет у многих сайтов.
Хелп яндекса говорит, что лучше надо для улучшения индексации, но при отсутствии данного заголовка робот сам пытается определить изменения страницы. Суть сего заголовка - не отдавать страницы без изменений, чтобы робот смог успеть переиндексировать остальные с изменениями.
Индексация в целом идет нормально, но хочется все по уму сделать.
1970 год - это как я понял отсчет начала эпохи юних, но почему именно она, так и не понял, эта же дата у многих сайтов. Пробывал несколько разных вариантов, максимум добивался почему-то 14 года, хотя это тоже не верно.
Просто проблема в том, что контент сайта является динамическим и вот как его изменение измерять мне пока не в домек...
Т.е. пока я понял, что отказ от этого заголовка пока является лучшим вариантом?
Я тоже посмотрел как у монстров сделано, поэтому и решил просто убрать его.
Я понимаю, что настроить его будет правильней, но как это реализовать я пока недокумекал, если есть реальные примеры, буду рад увидеть. И опять же - стоит ли овчинка выделки...
Лично я настроил . на конце, но тут есть свой подводный камень с 404 кодом сервера - если сделан запрос к несуществующей странице без слэша, то идет сначала редирект на слэш, а только потом 404, что не критично, но не хорошо.
Попробовал сегментировать тоже, результата не дало, т.к. результаты очень размазаны, да и при проверке по техническим параметрам пользователя все в норме с сайтом. Посмотрел еще раз вебвизор и наблюдаю тупо загрузку страницы и все, причем даже для переходов из поиска. Может ли это все-таки глючить сама метрика, т.е. она засчитывает посещение в 0-1 секунды, а пользователь на самом деле дальше ходит себе спокойно по сайту?
С этим все гуд.
Тут тоже все в порядке.
Даже если были бы такие проблемы, то все равно они не объясняют например нулевые посещения, т.е. в 0 сек. Опять же, вебвизор лишний раз подтверждает, что проблем с версткой и скоростью загрузки отсутствует.
Если разрешит ТС, то тоже хочу присоединиться к решению такой же проблемы.
В последнее время достаточно большой процент подобных коротких посещений. Доля отказов 16-17% по метрике и аналиксу, причем львиная доля этих отказов и кроется в таких коротких по времени посещениях. Также сложилось мнение, что это не глюк метрик, т.к. вебвизор показывает эти посещения так же, т.е. люди заходят на страницы сайты и через несколько секунд (1-19) посещение завершено.
Хотелось бы услышать мнения гуру...
