Проверить корректность HTTP-заголовков

Зачем проверять HTTP-заголовки

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

На практике заголовки — одна из самых недооценённых областей технического SEO. Владельцы сайтов сосредоточены на контенте, мета-тегах и ссылках, а HTTP-заголовки остаются на настройках по умолчанию. В лучшем случае они не мешают, в худшем — создают проблемы, которые трудно диагностировать без целенаправленной проверки.

Я включаю проверку HTTP-заголовков в каждый техаудит. Это занимает 15-20 минут, но позволяет обнаружить проблемы, которые другие специалисты пропускают.

Пошаговая инструкция

Шаг 1. Узнайте, какие заголовки отдаёт ваш сервер

Первый шаг — увидеть текущие заголовки. Есть несколько способов.

Через curl в командной строке:

curl -I https://vash-sajt.ru/

Флаг -I запрашивает только заголовки (HEAD-запрос). Вы увидите набор строк вида:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=3600
x-robots-tag: noindex
strict-transport-security: max-age=31536000

Для проверки конкретной страницы замените URL. Для проверки редиректов используйте curl -IL — покажет цепочку перенаправлений с заголовками каждого шага.

Через DevTools в браузере:

1. Откройте сайт, нажмите F12 → вкладка «Network».
2. Обновите страницу (F5).
3. Кликните на первый запрос (документ HTML).
4. В панели справа перейдите на вкладку «Headers».
5. Раздел «Response Headers» — это заголовки, которые отдаёт сервер.

Через Screaming Frog:

Просканируйте сайт. На вкладке «Internal» для каждого URL можно посмотреть заголовки ответа через нижнюю панель → «HTTP Headers». Удобно для массовой проверки: можно экспортировать заголовки всех страниц в таблицу.

Шаг 2. Проверьте Content-Type

Заголовок Content-Type сообщает браузеру и роботу, что за тип контента передаётся и в какой кодировке. Для HTML-страниц правильное значение:

Content-Type: text/html; charset=UTF-8

Проблемы, если заголовок неправильный:

• Отсутствует charset: браузер пытается угадать кодировку. На русскоязычных сайтах это приводит к кракозябрам вместо текста.
• Неправильная кодировка: сайт в UTF-8, а заголовок говорит windows-1251 — символы отображаются некорректно.
• Неправильный тип: JSON-ответ API с Content-Type: text/html или HTML-страница с Content-Type: application/json — браузер обработает контент неверно.

В WordPress Content-Type обычно настраивается автоматически. Проверьте, что значение корректное для всех типов страниц: основные страницы, RSS-ленты, XML-sitemap, REST API.

Шаг 3. Проверьте X-Robots-Tag

Заголовок X-Robots-Tag — аналог мета-тега robots, но на уровне HTTP. Он особенно полезен для файлов, которые не содержат HTML: PDF, изображения, XML, JSON.

X-Robots-Tag: noindex, nofollow

Проверьте, что X-Robots-Tag не установлен случайно на важных страницах. Я встречал случаи, когда хостинг-провайдер или CDN добавляли X-Robots-Tag: noindex на весь сайт — и весь сайт вылетал из индекса. Такое бывает после миграции или настройки Cloudflare.

Где имеет смысл использовать X-Robots-Tag:

• PDF-файлы с внутренними документами — чтобы не попали в индекс.
• Изображения, которые не должны индексироваться отдельно.
• API-эндпоинты и служебные JSON-ответы.

В Nginx настройка для PDF:

location ~* \.pdf$ {
    add_header X-Robots-Tag "noindex, nofollow";
}

В Caddy:

@pdf path *.pdf
header @pdf X-Robots-Tag "noindex, nofollow"

Шаг 4. Настройте Cache-Control

Заголовок Cache-Control определяет, как браузер и промежуточные кеши (CDN, прокси) должны кешировать ресурс. Правильное кеширование критично для производительности.

Для статических ресурсов (CSS, JS, изображения):

Cache-Control: public, max-age=31536000, immutable

Это означает: кешировать на год, ресурс не изменится. Работает, если при обновлении файла меняется его имя или хеш в URL (style.v2.css или style.css?ver=2).

Для HTML-страниц:

Cache-Control: public, max-age=3600, must-revalidate

Кешировать на 1 час, затем перепроверить. Для динамических страниц (корзина, личный кабинет):

Cache-Control: no-store, no-cache, must-revalidate

Не кешировать — каждый запрос идёт на сервер.

Проверка в Nginx:

location ~* \.(css|js|jpg|jpeg|png|gif|webp|svg|woff2|woff)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
    add_header Cache-Control "public, max-age=3600, must-revalidate";
}

В Caddy:

@static path *.css *.js *.jpg *.jpeg *.png *.gif *.webp *.svg *.woff2
header @static Cache-Control "public, max-age=31536000, immutable"

PageSpeed Insights проверяет кеширование статических ресурсов. Если заголовок Cache-Control отсутствует или установлен на короткий срок — вы получите предупреждение «Serve static assets with an efficient cache policy».

Шаг 5. Настройте HSTS (Strict-Transport-Security)

HSTS — заголовок, который заставляет браузер всегда использовать HTTPS для вашего сайта. После первого визита браузер запоминает, что сайт работает только по HTTPS, и все последующие запросы автоматически направляются по защищённому протоколу — без редиректа с HTTP.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Что значит каждый параметр:

• max-age=31536000 — помнить настройку 1 год (в секундах).
• includeSubDomains — распространить на все поддомены.
• preload — разрешить включение в HSTS Preload List браузеров (Chrome, Firefox и др.).

Зачем для SEO: HSTS убирает редирект HTTP → HTTPS. Без HSTS каждый запрос по HTTP проходит через 301-редирект — это лишние миллисекунды и лишнее обращение к серверу. С HSTS браузер сразу идёт на HTTPS.

Настройка в Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

В Caddy HSTS включается автоматически при использовании автоматического HTTPS.

Важно: включайте HSTS только если вы уверены, что весь сайт работает по HTTPS корректно. После включения откатить назад сложно — браузеры будут принудительно использовать HTTPS указанное время (max-age). Начните с малого значения (max-age=300 — 5 минут) и увеличивайте постепенно.

Шаг 6. Проверьте заголовки безопасности

Заголовки безопасности не влияют на SEO напрямую, но влияют на доверие к сайту, а Яндекс учитывает безопасность как один из факторов качества.

X-Content-Type-Options:

X-Content-Type-Options: nosniff

Запрещает браузеру «угадывать» тип контента. Без этого заголовка браузер может интерпретировать текстовый файл как JavaScript — потенциальная уязвимость.

X-Frame-Options:

X-Frame-Options: SAMEORIGIN

Запрещает встраивание вашего сайта во фрейм на чужих сайтах. Защита от кликджекинга.

Referrer-Policy:

Referrer-Policy: strict-origin-when-cross-origin

Контролирует, какую информацию о реферере передавать при переходе на другие сайты. Баланс между конфиденциальностью и отслеживанием переходов в аналитике.

Permissions-Policy (замена Feature-Policy):

Permissions-Policy: camera=(), microphone=(), geolocation=()

Запрещает сайту доступ к камере, микрофону, геолокации. Если ваш сайт их не использует — закройте.

Шаг 7. Проверьте заголовки для конкретных типов ресурсов

Разные типы ресурсов требуют разных заголовков:

Изображения:

• Правильный Content-Type: image/webp, image/jpeg, image/png.
• Длительное кеширование: Cache-Control: public, max-age=31536000.

Шрифты:

• Content-Type: font/woff2, font/woff.
• CORS-заголовок для кроссдоменной загрузки: Access-Control-Allow-Origin: *. Без него шрифты с CDN могут не загружаться.
• Длительное кеширование.

XML-sitemap:

• Content-Type: application/xml или text/xml.
• Короткий кеш или без кеша — sitemap должен обновляться при добавлении новых страниц.

API-ответы (REST API WordPress):

• Content-Type: application/json.
• X-Robots-Tag: noindex — JSON-ответы не должны индексироваться.

Шаг 8. Выполните массовую проверку

После настройки проверьте заголовки на выборке URL разных типов:

1. Главная страница.
2. Страница услуги / товара.
3. Статья блога.
4. Страница категории.
5. CSS-файл.
6. JS-файл.
7. Изображение (JPG/WebP).
8. XML-sitemap.
9. PDF-файл (если есть).
10. 404-страница.

Для каждого URL проверяйте через curl -I или DevTools. Создайте таблицу: URL, Content-Type, Cache-Control, X-Robots-Tag, HSTS, заголовки безопасности. Отметьте, что настроено, а что требует исправления.

Для массовой проверки можно использовать онлайн-сервис securityheaders.com — он анализирует заголовки безопасности и выставляет оценку от A+ до F.

Типичные ошибки

• X-Robots-Tag: noindex на всём сайте. Бывает после переезда на новый сервер, включения staging-режима или настройки CDN. Сайт полностью вылетает из индекса. Проверяйте заголовки после любых серверных изменений — это первое, что нужно проверить.
• Отсутствие кеширования статики. Без Cache-Control браузер запрашивает CSS, JS и изображения при каждом визите. Сайт грузится медленнее, PageSpeed показывает низкие оценки. Настройте кеширование на год для статических ресурсов с версионированием файлов.
• Cache-Control: no-cache на HTML-страницах. Обратная крайность — запретить кеширование вообще. Для динамических страниц (корзина) — правильно. Для статичных информационных страниц — расточительство. Кешируйте HTML на 1-24 часа с must-revalidate.
• HSTS с большим max-age без тестирования. Если включить HSTS с max-age в год, а потом обнаружить проблему с SSL — сайт будет недоступен для пользователей, которые уже получили заголовок. Начинайте с max-age=300 и увеличивайте только убедившись, что HTTPS работает стабильно.
• Отсутствие X-Content-Type-Options: nosniff. Без этого заголовка браузер может неправильно интерпретировать тип файла. Добавьте его глобально — это одна строка в конфигурации сервера, и она никогда не мешает.
• Конфликт заголовков сервера и плагина. Nginx добавляет Cache-Control: 1 год, а WP Super Cache — Cache-Control: 1 час. Результат непредсказуем. Убедитесь, что заголовки задаются в одном месте — либо на сервере, либо в приложении.
• Не проверять заголовки после обновлений. Обновление WordPress, смена темы, установка CDN, миграция на новый хостинг — любое из этих событий может изменить HTTP-заголовки. Сделайте проверку заголовков частью чеклиста после каждого значимого изменения.

Что проверить в итоге

• Все HTML-страницы отдают Content-Type: text/html; charset=UTF-8.
• X-Robots-Tag не установлен на страницах, которые должны индексироваться. На служебных ресурсах (PDF, API) — установлен noindex.
• Статические ресурсы (CSS, JS, изображения, шрифты) имеют Cache-Control с длительным сроком (не менее 30 дней, рекомендую 1 год).
• HTML-страницы имеют адекватный Cache-Control: не слишком долгий (чтобы обновления доходили) и не отключённый (чтобы не нагружать сервер).
• Заголовок Strict-Transport-Security установлен для HTTPS-сайтов.
• Заголовки безопасности настроены: X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy.
• Шрифты с CDN отдают заголовок Access-Control-Allow-Origin.
• Нет конфликтующих заголовков между сервером, CDN и плагинами кеширования.
• Оценка на securityheaders.com — не ниже B (идеально A/A+).
• Проверка выполнена для разных типов ресурсов: HTML, CSS, JS, изображения, XML-sitemap, PDF.