DomainLens

Навчання

Security headers SEO: HTTPS, HSTS, CSP і trust signals

Практичний гайд про security headers і SEO: як безпека повʼязана з позиціями, що робить кожен заголовок і як додати їх, не зламавши crawling.

Перевір сайт перед виправленнями

Запусти свіжий аудит DomainLens і використовуй звіт як список пріоритетів.

Запустити безкоштовний SEO-аудит

Як безпека насправді повʼязана з SEO

Будьмо точні: HTTPS — це легкий сигнал ранжування, який Google підтвердив, але більшість security headers взагалі не є факторами ранжування. Їхня SEO-релевантність непряма. Вони захищають довіру й цілісність твоїх сторінок, і — що важливіше — неправильна конфігурація безпеки може зламати рендеринг, заблокувати ресурси чи спричинити попередження браузера, які тихо коштують трафіку й конверсій.

Тож мета тут не гнатися за score. Це правильно налаштувати HTTPS, уникнути помилок конфігурації безпеки, що шкодять crawling і довірі користувачів, і додати захисні заголовки так, щоб вони ніколи не блокували Googlebot чи твої критичні ресурси.

Заголовки, що мають значення, і що вони роблять

  • HTTPS + валідний сертифікат: власне (незначний) сигнал ранжування й база для довіри користувачів і уникнення попередження «Не захищено».
  • HSTS (Strict-Transport-Security): змушує браузери використовувати HTTPS, закриваючи проміжок редиректу http→https; SEO-нейтральний, але добра гігієна.
  • Content-Security-Policy (CSP): обмежує, які ресурси можуть завантажуватись; потужний, але найімовірніше випадково зламає твої ж скрипти, стилі чи зображення.
  • X-Content-Type-Options: nosniff: зупиняє вгадування MIME-типу; для SEO нешкідливий, стандартна практика.
  • Referrer-Policy і X-Frame-Options: захист приватності й від clickjacking; SEO-нейтральні, але очікувані на добре зробленому сайті.

Як security headers ламають сторінки (і SEO)

Шкода SEO від конфігурації безпеки майже ніколи не про відсутній заголовок — вона про заголовок, налаштований надто агресивно.

  • Суворий CSP, що блокує легітимний скрипт чи стиль, тож сторінка рендериться зламано і для Googlebot, і для користувачів.
  • Mixed content: HTTPS-сторінка завантажує http://-зображення чи скрипт, що браузери блокують і що підриває захищений замочок.
  • HTTPS налаштований так, що і http, і https віддають 200 без редиректу — створюючи дубльовані URL.
  • Прострочений або невідповідний сертифікат, що спричиняє повноекранне попередження браузера й обвалює довіру.
  • Правила X-Frame-Options чи CSP для фреймів, що ламають легітимні embeds, на які ти покладаєшся.

Як додати заголовки, не зламавши crawling

  • Віддавай кожну сторінку через HTTPS із валідним сертифікатом і 301-редиректь усі http-URL на їхній https-еквівалент — один канонічний протокол.
  • Спершу виправ mixed content: онови кожен URL внутрішнього ресурсу на https, щоб нічого не блокувалось.
  • Розкочуй CSP спочатку в режимі report-only, стеж за звітами порушень і застосовуй жорстко лише коли підтвердив, що нічого легітимного не блокується.
  • Ніколи не давай security-заголовку блокувати JS чи CSS, потрібні Googlebot для рендера.
  • Додавай HSTS лише коли впевнений, що HTTPS стабільний усюди, бо його важко швидко відкотити.

Помилки, що шкодять позиціям через конфігурацію безпеки

  • Застосувати суворий CSP одразу в продакшн без report-only тестування, зламавши рендеринг на всьому сайті.
  • Мігрувати на HTTPS, але лишити внутрішні посилання, canonical і sitemaps на http.
  • Віддавати і http, і https без редиректу, розділяючи сигнали між дубльованими URL.
  • Вважати score security-заголовків SEO-метою й додавати заголовки, що ламають функціональність, заради зеленого бейджа.

Як перевірити свої заголовки

Перевір заголовки відповіді напряму (curl -I або вкладка Network у DevTools), підтверди, що http надійно редиректить на https, і скористайся Rendered HTML / URL Inspection, щоб пересвідчитись, що Googlebot усе ще може завантажити кожен ресурс. Стеж за порушеннями mixed-content і CSP у консолі браузера.

DomainLens позначає проблеми HTTPS, mixed content і security headers поруч із crawlability й рендерингом — тож заблокований ресурс чи зламаний редирект http→https спливає як частина технічного SEO сторінки, де він реально може впливати на індексацію, а не як окремий security-score.

Схожі ресурси