Как HTTP-заголовки веб-сервера могут влиять на SEO и как автоматически это проверить

При продвижении сайта как-то незаслуженно мало уделяют внимания HTTP-заголовкам. А ведь от них напрямую зависит:

Разберём далее каждую особенность подробнее.

Годы идут а за последние 25 лет с момента появления Всемирной паутины сайтов World Wide Web принципиально проблема быстрой загрузки не изменилась. В 90-е годы мы с трудом скачивали страницы на модемах. Сейчас, конечно, в среднем контент стал грузиться существенно быстрее. Но скорость загрузки во-первых важна для поисковиков и влияет на оценку того же Google Page Speed, а во-вторых мы по-прежнему сталкиваемся с перегруженными каналами, серверами, плохой сотовой связью или удалением от вышек. И для таких случаев имеет принципиальное отличие грузить 1Мб или 0.5Мб. Загрузить страницу за 20 или за 5 обращений к серверу.

На скорость загрузки страницы влияют:

Отлично, если сервер поддерживает HTTP/2, тогда всё передаётся в рамках одного соединения. А в HTTP/1.1 для загрузки каждого файла браузер устанавливает новое соединение с сервером. На странице может подключаться ещё 20 картинок, JS-файлов, CSS-файлов, шрифтов, что в сумме притормозит загрузку и отображение контента.

Весь текстовый контент должен сжиматься сервером, то есть архивироваться. При этом алгоритм сжатия должен использоваться тот, который поддерживает клиент.

Весь статический контент сайта, который не меняется должен выдаваться с заголовками ETag, Cache-Control: max-age. Потому что когда посетитель перейдёт на вторую страницу сайта, то браузер не должен заново грузить картинки, JS, CSS, шрифты. Браузер должен взять это из кэша. А чтобы браузер взял эти файлы из кэша, ему нужно сообщить уникальный ETag этих файлов и сколько браузер может брать их из кэша. Как правило, это год или месяц. Через месяц или год браузер переспросит сервер If-None-Match, а не изменились ли эти файлы. Если не изменились, то сервер должен ответить 304 Not Modified. А если изменились, то выдать новые.

От корректности данных заголовков зависит скорость загрузки. Представьте, что сервер не выдаёт ETag, но выдаёт Cache-Control. Или выдаёт ETag, но не говорит сколько можно хранить кэш. А иногда веб-сервера выдают полную муть, что кешировать нельзя ничего и никогда. Или на запрос If-None-Match выдаёт всегда контент.

Безопасности уделяется всё больше и больше внимания. За последние несколько лет почти исчезли сайты без SSL-сертификатов. Поисковики ниже ранжируют http чем защищённые сайты с https. Браузеры ранжируют даже сертификаты и подсвечивают самые надёжные зеленым цветом.

Но даже имея самый крутой SSL-сертификат. Вы рискуете нарваться на смешанный контент, который приведёт к тому, что тот же Яндекс не присвоит вашему сайту значок SSL (защищённое соединение) и будет думать про него, что он небезопасный. Происходит это потому что на странице вашего сайта подключаются какие-то файлы по протоколу http, а не https.

Тут нам на помощь придут заголовки:

Strict-Transport-Security принудительно заставит браузер запрашивать файлы по протоколу https, а даже если в коде будет что-то типа img src=http://…

Content-Security-Policy просто запретит браузеру подгружать данные по незащищённому http.

Content-Security-Policy имеет массу других полезных опций, он ограничивает список внешних ресурсов с которых страница сайта может подгружать данные. Одним из самых прекрасных свойств этого заголовка является запрет встроенных стилей и встроенных javascript. Хорошая разработка должна разделять отдельно HTML, CS и JS по разным файлам и не устраивать помойку в коде и страницах.

Когда я столкнулся с настройкой этого заголовка оказалось, что Яндекс.Метрика и чат Usedesk нарушают этот заголовок и используют inline стили. Usedesk морозились и в результате они отказались от нас, а мы от них. А Яндекс.Метрика молодцы! Приняли мои замечания и поправили код Яндекс.Метрики. Благо я даже подсказал им и конкретные строки на которые браузер ругается и как именно поправить. Саня, я тебе говорил, что РИФ говно, статьи надо писать. Там за день 500 человек мимо стенда пройдут, а тут 5000 прочтут. Давно уже никто не бухает. И бухая ничего не продашь. Давай вноси правки.

Часто сервер не выдаёт данный заголовок вообще или выдаёт неправильно. Возможно поисковый робот и не обращает на это внимания. Заходит он раз в день на сайт, получает абсолютно тот же контент, что и днём ранее и годом ранее, и при этом север утверждает, что контент был модифицирован только что. Ну и кому такое должно понравиться?

Данный заголовок сообщает от каких других заголовков зависит отдаваемый контент. Например, он зависит от Content-Encoding.

Поисковики Яндекс и Google ранжируют контент в зависимости от языка пользователя. Если сайт использует устаревшую кодировку на каких-то страницах, например, windows-1251 или KOI8-R или ещё какую-то кодировку, которая однозначно говорит о языке, но при этом сам сервер в заголовке всем страницам выдаёт принудительно UTF8, то это вызовет проблемы. Причём браузер может в некоторых нестыковках и автоматически отобразить страницу корректно. Раньше в браузерах было переключение кодировки для этих целей, но с переходом на UTF8 проблема исчезла. Однако, её остаются сайты со старыми кодировками и нужно для них проверять, чтобы кодировки в заголовках ответа веб-сервера совпадали с кодировками страниц.

Там ещё много параметров. Наверное вы уже утомились читать, а проверять это всё руками вообще сложная задача. Поэтому есть сервис для автоматической проверки HTTP-заголовков онлайн, который проанализирует заголовки, проверит как сервер реагирует на заголовки HTTP-запроса и выдаст рекомендации, что стоит поправить.