- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как интернет-магазину продуктов питания за год увеличить количество заказов в 4 раза. Кейс
После сильного падения трафика из-за некорректного переезда сайта
TRINET.Group
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Ведь одно дело контент - это, скажем, статья на странице.
А другое html код, в который эта статья облечена.
Html шаблон может меняться очень часто если я там рисую какое-нибудь общее для всех страниц значение - скажем курс акции.
Или вообще постоянно меняться, если шаблон персонифицирован.
Из w3 читаем (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), что каг бэ Last-modified должен меняться с изменением объекта (некоторой сущности, о которой идет речь).
Что понимать под объектом? У меня объект статья в бд, а значит нельзя ли притянуть за уши " ... For database gateways, it may be the last-update time stamp of the record ..."
Хотя отдаю я конечно же объект страницу.
Что отдавать? дату и время изменения статьи или html кода?
Что лучше для гугла?
Мое мнение - отдавайте дату обновления контента.
Страницы, конечно. Вы же не хотите, чтобы пользователи получали устаревший HTML-код из кеша?
Страницы, конечно. Вы же не хотите, чтобы пользователи получали устаревший HTML-код из кеша?
Безусловно!
Но, ведь для управления кешированием существуют и другие заголовки - Expires, Cache-control.
Это то и смущает!
Ведь можно поставить старый Last-modified и рядом "Expires: мгновенно". И тогда браузер не всасет ее в кеш. Не должен.
Может быть гугл хотел бы, чтобы мы так управляли кешированием :-)))
Но, ведь для управления кешированием существуют и другие заголовки - Expires, Cache-control.
1. Для управления кэшированием на стороне клиента существует только заголовки LastModified и ETAG (изменение несущественной части контента страницы). Все остальные заголовки не позволяют нормально управлять кэшированием.
2. Роботы Google и Яндекс поддерживают LastModified, и игнорируют остальные заголовки, связанные с кэшированием.
3. Просто отдавать LastMidified недостаточно - надо обрабатывать запросы If-Modified-Since и If-None-Match и грамотно возвращать статус код "304 Not modified" или "200 OK". Иначе кэширования на стороне клиента не будет.
Если Вы плохо понимаете как и на что надо отдавать LastModified - лучше этого не делать, тк в случае ошибки можно поиметь проблемы с переиндексацией страниц.
PS: Отдавать на If-Modified-Since текущую дату можно, но это бессмысленно.
Наверное, сначала понять, что нужно - управлять кэшированием в браузере, или получить хорошее индексирование ПС. :)
Для страницы существует общее название "документ". Это совокупность байтиков, которую сервер отдает в ответ на запрос URI. Делить ее на "код" и "контент" не нужно, все это "тело сообщения" по HTTP. Отсюда и ответ: привязывайте время модификации к тому, что изменилось позже, не ошибетесь.
Наверное, сначала понять, что нужно - управлять кэшированием в браузере, или получить хорошее индексирование ПС. :)
Для страницы существует общее название "документ". Это совокупность байтиков, которую сервер отдает в ответ на запрос URI. Делить ее на "код" и "контент" не нужно, все это "тело сообщения" по HTTP. Отсюда и ответ: привязывайте время модификации к тому, что изменилось позже, не ошибетесь.
Робот-индексатор Яндекса, в плане кэширования, ведёт себя так же, как и браузер
- неизменившиеся страницы он не загружает
- добросовестно присылает дату загрузки страницы, имеющейся у него в индексе
За один заход индексатор Яндекса читает ограниченное количество страниц, поэтому грамотно отдавая LastModified Вы существенно улучшите индексацию новых и переиндексацию изменившихся страниц сайта.
Делить страницу на код и контент (по умному - заголовки и тело документа) - нужно, поскольку контент (тело документа) отдается не всегда и не на все http-запросы, а заголовки с http status-кодом надо отдавать всегда.
Ниже - сегодняшние логи робота Яндекса при переиндексировании сайта. У меня за день робот запрашивает до 2500 страниц, выбирая новые, и отсеивая неизменившиеся с кодом "304 Not Found".
PS: При статус коде 304 контент страницы не посылается, так же как и при 301/302 редиректе.
PPS: Тема LastModified для сайтов в 200 страниц не актуальна - и так всё переиндесируется.
В Last-modified должны быть изменения при ЛЮБЫХ изменениях на странице.
Делить страницу на код и контент (по умному - заголовки и тело документа) - нужно, поскольку контент (тело документа) отдается не всегда и не на все http-запросы, а заголовки с http status-кодом надо отдавать всегда.
Вообще-то, ваш сайт отдаст заголовок (на запрос GET) независимо от того, делите ли вы страницу на заголовки и тело. А уж на код/контент точно делить не надо для last-modified.
Вообще-то, ваш сайт отдаст заголовок (на запрос GET) независимо от того, делите ли вы страницу на заголовки и тело. А уж на код/контент точно делить не надо для last-modified.
У метода GET, кроме основной, есть ещё 2 модификации:
-условный GET" ("conditional GET")
-частичный GET ("partial GET")
Сможете сказать, какие заголовки должна отдать страница и какой контент послать на каждый из трех вариантов GET?
Мне интересно, как Вы будете присылать тело сообщения (message-body) при "partial GET" - что, всю страницу сайта юзеру отошлёте?
Кроме GET, в спецификации HTTP1.1 ещё 6 методов обращения к серверу. Возьмте HEAD:
Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать в ответе тело сообщения (message-body). (CopyRight W3.org)
Всё еще настаиваете, что не надо отделять "мух от котлет", в смысле "код от контента"?
Странно, что Вы пытаетесь определить "как правильно отдавать заголовки HTTP" методом дискуссии, когда на это тему есть RFC 2616. Кому в лом читать английский, устаревший RFC 2068 на руском можно посмотреть, там мало что изменилось.
PS: Заголовок - это не то, что написано на странице сайта в секции <head></head>, хотя некоторые мета-тэги модифицируют отправляемые веб-сервером заголовки HTTP.
В основном HTTP-заголовки отдаёт вев-сервер, а не сайт, поскольку управлять заголовками большинство вебмастеров не умеет и не заморачивается. И веб-сервер обрабатывает заголовки http (какие сможет и как сумеет), за них.
У метода GET, кроме основной, есть ещё 2 модификации:
-условный GET" ("conditional GET")
-частичный GET ("partial GET")
Сможете сказать, какие заголовки должна отдать страница и какой контент послать на каждый из трех вариантов GET?
Мне интересно, как Вы будете присылать тело сообщения (message-body) при "partial GET" - что, всю страницу сайта юзеру отошлёте?
Вы о чем-то другом со мной пытаетесь спорить. Я, как веб-мастер, ничего не отдаю на запрос GET, более того, я даже не сильно могу это контролировать (за исключением значений и наличия некоторых заголовков). На запрос GET, какой бы он ни был правильно ответит Апач (или другой веб-сервер). И во всех моих предыдущих сообщениях я утверждал, что нельзя отделять код сайта от его контента. Апачу нет смысла знать, где код, а где контент, чтобы правильно отдавать заголовки.
Кроме GET, в спецификации HTTP1.1 ещё 6 методов обращения к серверу. Возьмте HEAD:
Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН возвращать в ответе тело сообщения (message-body). (CopyRight W3.org)
Он и не вернет. При чем здесь отделение контента от кода и разный Last-Modified для каждого?
Всё еще настаиваете, что не надо отделять "мух от котлет", в смысле "код от контента"?
Да, Last-Modified не должен быть разным для кода и контента одной страницы. Я все еще утверждаю, что Last-Modified должен быть один для одной страницы.
Странно, что Вы пытаетесь определить "как правильно отдавать заголовки HTTP" методом дискуссии, когда на это тему есть RFC 2616. Кому в лом читать английский, устаревший RFC 2068 на руском можно посмотреть, там мало что изменилось.
Боюсь, что для RFC 2616 хтмл-код и конент внутри этого кода - одно и то же.
PS: Заголовок - это не то, что написано на странице сайта в секции <head></head>, хотя некоторые мета-тэги модифицируют отправляемые веб-сервером заголовки HTTP.
В основном HTTP-заголовки отдаёт вев-сервер, а не сайт, поскольку управлять заголовками большинство вебмастеров не умеет и не заморачивается. И веб-сервер обрабатывает заголовки http (какие сможет и как сумеет), за них.
Кэп?