Это стандартная настройка Nginx - я не думаю, что его разрабатывают чайники из-за которых миллионы сайтов выпадают из индекса.
google.com отдает Expires: -1.
medium.com отдает Expires: Thu, 09 Sep 1999 09:09:09 GMT / сайт в индексе более 5 лет.
Я проверил самые популярные сайты, которые я использую, ни один из них, не отдает положительный expires.
Мои личные проекты в индексе более 5 лет, все отдают отрицательный Expires.
Я просто не лезу что-то менять там, где ничего не понимаю, по первому совету на форуме и ВСЕ ОТЛИЧНО.
(что и другим советую)
Единственный документ от Google по запросу "google expires header", говорит, что expires будет проигнорирован, если браузер поддерживает HTTP/1.1 и выше плюс предоставлен другой новый валидатор кеша (ETag, Last-modified/Cache-control).
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching
На данный момент, все поисковые системы следуют HTTP/1.1.
Сайт автора темы предоставляет заголовок Cache-control (no-store - не хранить, не кешировать).
Соответственно, отрицательный expires (то же самое, что и no-store) не меняет поведение браузеров и ботов поддерживающих HTTP/1.1 и установлен Nginx только для обратной совместимости с HTTP/1.
Я и правда не понимаю, откуда столько негатива.
Я просто обратил внимание на то, что это может быть полезно мне и другим, которые в будущем прочитают тему.
Было бы отлично, если бы вы расставили точки над и, сославшись на упомянутый документ.
У меня все сайты на стандартной настройке Nginx из репозитория Ubuntu LTS.
Все в индексе и страницы быстро заходят, не вылетают.
У всех Nginx отдает Expires прошлое время.
Можно ссылку на источник написанного?
К сожалению, я не встречал такой информации.
Если Google действительно рекомендует корректировать Expires на нулевой или положительный, я думаю, буду в будущем следовать рекомендациям.
Я понимаю, что следующая рекомендация это чисто мое предположение и не имеет ничего общего с текущей практикой СЕО.
Не судите строго, просто описываю то, как вижу я алгоритм PR со стороны здравого смысла.
Я думаю, что те, кто создают алгоритмы поисковых систем, прекрасно понимают, что анкорные ссылки это в большинстве случаев установленные совместно с акцептором ссылки, с согласованными ключами и порой даже контекстом (контентом, статей), в котором они размещаются - пресс-релизы, спонсорские ссылки.
В то время, когда рекомендации пользователей это в большинстве случаев безанкорные ссылки обтекающие действительно хорошо описывающими ссылку ключами - посты на блогах, форумах, комментарии, описание на youtube видео, практически все, где пользователь может разместить ссылку.
(не стоит отдельно говорить о сковзных ссылках - взломы, ссылки из бесплатных тем и плагинов для CMS)
Безусловно, понижать сайты за желание его создателя немного улучшить ранжирование или прорекламировать его на других ресурсах это плохая идея.
Но я думаю, что обтекающий текст и контекст вместе с безанкорными ссылками это очень хорошая и безопасная идея для продвижения. А главное может действительно принести целевой трафик, если размещать ссылки на обсуждаемых страницах форумов, постов, а не в теле какой-то не посещаемой старой статьи.
Естественно, Google не станет заявлять, что он не учитывает анкорные ссылки или всегда учитывает безанкорные - потому, что вы понимаете, к чему это приведет...
Я думаю, что продвижение свободными безанкорными ссылками, безанкорными ссылками в пресс-релизах должно быть основной стратегией продвижения. Если речь идет о коммерческом проекте, нужно создать псевдо-истории об услугах с упоминанием бренда, отзывы или просто обсуждать ту или иную услугу представленную на сайте, цену, срок, если не хотите публиковать липу.
В то время, покупка анкорных ссылок должна иметь цель - завлечение аудитории из других доноров, например, информационных сайтов, ежели для СЕО.
Если анкорная ссылка не может принести трафик, я бы не ставил такую ссылку.
XPraptor, это скорее просчет Google. Если он уж и отправляет такое письмо, то следовало бы указывать, как отличаются страницы.
Как вариант, можно установить Яндекс Метрику и просмотреть пару сессий через вебвизор.
Вы можете просмотреть проблемную страницу, как Googlebot в Google Webmaster - Сканирование - Посмотреть как Googlebot - введите адрес страницы и установите галочку "запросить прорисовку".
Дальше перейдите к результату.
В результате будет два скриншота - левый, как видит Googlebot сайт и правый - как видят его пользователи.
Попробуйте найти отличия или элементы, которых не должно быть.
Если это не поможет, вы можете сравнить исходный код страницы, который получает Googlebot с тем, что вы получаете в своем браузере через функцию сравнения текстовых файлов в текстовом редакторе.
Нет, это стандартная настройка веб-сервера Nginx, которая говорит браузеру, что он всегда должен запрашивать новую версию страницы, а не кешировать ее (дополнение к no-cache, must-revalidate).
Учитывая распространенность данного заголовка, это не должно негативно влиять на сканирование Googlebot.
Однако, на стороне хостинга этот параметр могут изменить или убрать по вашему желанию.
Это сродни микро оптимизации и никак не ускоряет скорость первичной загрузки сайта, а именно этот параметр самый критичный для поведенческих факторов.
А вот проблем в разработке доставить может.
Заголовок Expires на не наступившую дату, говорит браузеру, что он может использовать локальный файл из кеша без валидации по заголовкам "Last-modified/Etag).
Соответственно, чтобы обновить дизайн/скрипты, нужно менять имя файла (дописывая, например, ?v=2.0 к адресу). При этом, старые файлы из кеша не будут удалены до наступления даты из expires (?v=0, ?v=1 будут существовать вместе с ?v=2.0), засоряя при этом диск пользователя.
В противном случае, вам нужно будет нажимать Ctrl+Shift+R при каждом изменении файлов на сайте (css, js).
Пользователь может получать новый HTML (который не кешируется), но при этом старые CSS/JS из кеша - как результат, может плыть верстка, бажить формы отправки и другие проблемы.
Именно поэтому, из коробки ни Apache httpd, ни Nginx не используют этот "мегаполезный" заголовок для отдачи статического контента.
Потери производительности близко 20 мс на целый сайт (учитывая, что соединение устанавливается раз на хост благодаря keep-alive) при повторном обращении к файлам.
На скорость первичной загрузки абсолютно никак не влияет.
Подробно о кешировании
https://jakearchibald.com/2016/caching-best-practices/
Согласен.
Я вообще не понимаю, зачем веб-мастера показывают свою статистику всем (размещая графические счетчики).
Это типа потешить эго - в случае, если на счетчике от 10k или сказать пользователю - "этот сайт не авторитетный, его никто не читает" - если на счетчике 10?
Можно подумать адреса типа /zamena-bitogo-stekla выглядят лучше.
В случае со стандартной разметкой URL (?param=value) легче вводить новые параметры в CMS.
Также можно отключить сканирование страниц с определенным параметром в URL в Google Webmaster Tools - Crawl - URL Param
или очищать определенные параметры с помощью Clean-param в Яндекс.
Я думаю, что будущее за Share API / Opengraph-url / Canonical.
Apple уже сделал шаг в пользу этого прятая полный URL-адрес в адресной строке на Safari.
https://developers.google.com/web/updates/2016/10/navigator-share
Лично для меня, тенденция спамить ключевыми словами в URL отвратительная - это тенденцию используют почти на всех низкосортных сайтах.
Однако, все авторитетные сайты, которые я читаю, не используют ЧПУ.
В поиск эти страницы могут попасть, если скажем добавить на них ссылок.
Но какой смысл в этом? По каким запросам должна выдавать поисковая система эти страницы?
По "Демонтаж зданий и сооружений в Краснодаре"?
Оценивайте шансы вашего сайта реально.
Главная страница получает выше уровень доверия со стороны поисковых систем.
Соответственно, даже 2000 символов на внутренней странице могут быть не в индексе, когда 100 символов на главной в индексе.
Вам стоит смотреть в сторону посадочных страниц.
В этом случае, вы можете создать и 2000 символов описание своих услуг с перечислением НЧ и специфичной для вашего сайта информации. В этом случае, без дополнительной раскрутки, у вас будет шанс получить топ хотя бы по брендовым и низко-конкурентным запросам.
Тем-более у вас в статусе стоит "Web дизайнер" - наверное, вы уже имели опыт с дизайном посадочных страниц.
