Перевірка HTTP-заголовків

Перевірка HTTP-заголовків сайту: що показує звіт

Інструмент надсилає на вказану адресу звичайний GET-запит (не HEAD), проходить редиректи — до 10 переходів — і показує заголовки фінальної відповіді. Сам ланцюжок редиректів у звіт не потрапляє: щоб побачити кожен перехід і його код, скористайтеся перевіркою редиректів.

Звіт має чотири частини: огляд (HTTP-статус, час відповіді, HTTPS чи HTTP, кількість заголовків і значення Server), блок «Заголовки безпеки», повний перелік «Усі заголовки відповіді» та блок «Кешування та продуктивність».

Запит надходить із User-Agent PromoPilot SEO Tools. Якщо сайт захищений WAF чи антибот-системою, можна побачити статус 403 або 503 і заголовки сторінки-заглушки замість справжньої відповіді. Тоді порівняйте результат із перевіркою через curl (команди нижче).

Як рахується оцінка безпеки

Зважайте: враховується лише наявність заголовка, а не його значення. Strict-Transport-Security: max-age=0 чи CSP з 'unsafe-inline' отримають повні бали, хоча майже нічого не захищають. А політика, надіслана як Content-Security-Policy-Report-Only, не зараховується зовсім — інструмент шукає точну назву заголовка. Тож після перевірки читайте значення: вони виводяться під кожним знайденим заголовком.

Які значення заголовків безпеки ставити

nginx

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

Пастка nginx: якщо всередині location є хоч один власний add_header, заголовки рівня server там не успадковуються. Типовий наслідок — заголовки є на головній, але зникають на статиці чи в окремому розділі. Перевірте кілька різних адрес.

Apache і .htaccess

<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

WordPress і Tilda

У WordPress заголовки найпростіше задати в .htaccess або конфігурації сервера; з коду теми — через хук send_headers і виклик header(), але тоді вони з’являться лише на сторінках, які обробляє PHP. На Tilda доступу до сервера немає: власні заголовки можна додати тільки через проксі перед сайтом, наприклад правилами зміни заголовків відповіді в Cloudflare.

Типові проблеми, які видно у звіті

• Один заголовок двічі. Якщо в переліку два X-Frame-Options чи два Cache-Control з різними значеннями, їх додають і CMS, і сервер (або сервер і CDN). Браузери тоді поводяться непередбачувано — залиште одне джерело.
• Версія ПЗ на виду. Server: nginx/1.18.0 чи X-Powered-By: PHP/7.4 підказують атакувальнику, які вразливості пробувати. У nginx версію ховає server_tokens off;, у PHP — expose_php = Off.
• HSTS на HTTP-адресі. Браузери приймають Strict-Transport-Security лише через HTTPS; у відповіді по HTTP він марний.
• Заголовки зникають на помилках. Без параметра always nginx не додає заголовки до відповідей 4xx і 5xx. Заразом перевірте неіснуючу адресу: вона має віддавати 404, а не 200.
• Кеш CDN. Заголовки на кшталт cf-cache-status, X-Cache і Age показують, чи віддано сторінку з кешу CDN, чи з вашого сервера.

Літерну оцінку від A до F за набором заголовків безпеки дає окремий інструмент — перевірка заголовків безпеки.

Заголовки кешування та стиснення

• HTML-сторінки зазвичай віддають із Cache-Control: no-cache або коротким max-age, щоб правки було видно одразу.
• Статика з хешем у назві файлу — Cache-Control: public, max-age=31536000, immutable.
• ETag і Last-Modified дають змогу відповідати 304 Not Modified. Google повідомляв, що його краулери підтримують такі умовні запити, — це заощаджує краулінговий бюджет великих сайтів.
• Content-Encoding: інструмент повідомляє серверу, що приймає стиснені відповіді, тож відсутність заголовка зазвичай означає, що HTML іде без gzip і Brotli. Детальніше — у перевірці стиснення.
• Vary: Accept-Encoding потрібен для стиснених відповідей, щоб CDN не віддав стиснену версію клієнтові без підтримки.

X-Robots-Tag та інші заголовки для SEO

Окремо інструмент їх не оцінює, але вони є в переліку «Усі заголовки відповіді»:

• X-Robots-Tag: noindex закриває сторінку від індексу так само, як meta robots, навіть якщо в HTML усе гаразд. Часта причина — правило з тестового середовища, випадково перенесене на робочий сервер. Про директиви — у статті про noindex і nofollow.
• Link: <…>; rel="canonical" — канонічна адреса для PDF та інших файлів без HTML.
• Content-Type з charset=utf-8 — без кодування у сніпеті можливі нечитабельні символи.
• Set-Cookie на кожній відповіді заважає кешуванню в CDN.

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

Які адреси сайту перевіряти

Заголовки задають правила сервера, CMS і CDN, тож на різних адресах вони часто відрізняються. Для повної картини проженіть п’ять-шість URL: головну, сторінку категорії, картку товару чи статтю, будь-який CSS-файл або зображення, PDF (якщо є) і свідомо неіснуючу сторінку. Розбіжності між ними і є переліком правок.

Перевірка заголовків через curl і DevTools

# Лише заголовки (HEAD-запит)
curl -I https://example.com/

# Заголовки звичайного GET із проходом усіх редиректів
curl -sSL -D - -o /dev/null https://example.com/

# Чи віддає сервер Brotli або gzip
curl -sI -H "Accept-Encoding: br, gzip" https://example.com/ | grep -i content-encoding

curl -I надсилає HEAD, а частина серверів і CDN відповідає на HEAD інакше, ніж на GET, тож за розбіжностей довіряйте другій команді. У браузері те саме видно в DevTools: Network → запит документа → Headers.

Якщо вам потрібна перевірка заголовків H1–H6 на сторінці, це інше завдання — структуру заголовків тексту покаже on-page перевірка сторінки.