Дізнайтеся тут, що означають захисні заголовки, як вони працюють і чому вони важливі для безпеки вашого веб-сайту і того, чим ви також допомагаєте захистити свої SEO-заходи.
Стаття про захисні заголовки включає наступні теми:
Що таке захисні заголовки?
Захисні заголовки - це HTTP-заголовки, які використовуються на веб-сайтах та веб-застосунках для покращення безпеки та захисту від різних видів атак і вразливостей. Вони надають важливий рівень безпеки для захисту користувачів та даних від загроз.
Якщо ви замислюєтеся, чи вам це взагалі потрібно, ви можете використовувати онлайн-інструмент для перевірки поточного рівня безпеки. Це можливо на сайті securityheaders.com. Введіть туди свою URL.
Ймовірно, ви отримаєте результат D або F. Більшість веб-сайтів спочатку відзначаються погано, тому що безпека веб-сайтів зазвичай не є пріоритетом для більшості розробників і агентств у межах створення або редизайну веб-сайтів. Як втілити захисні заголовки (навіть якщо ви не розробник), ви дізнаєтеся нижче. Але зараз ви вже знаєте, що в цілому для вас існує потреба в діях.
Як працюють захисні заголовки?
Захисні заголовки це частина відповіді HTTP, яку веб-сервер надсилає в браузер, коли робиться запит на веб-сайт або веб-застосунок. Ці заголовки містять вказівки та інформацію, що повідомляє браузеру, як він повинен поводитися відносно безпеки та конфіденційності. Ось кілька важливих захисних заголовків та способи їх функціонування:
HTTP Strict Transport Security (HSTS)
HSTS змушує браузер встановлювати та утримувати з'єднання з веб-сайтом через HTTPS, щоб уберегти від атак посередником.
Багато веб-сайтів мають лише перенаправлення 301 з HTTP на HTTPS. Багато посилань на вміст веб-сайтів все ще створені як HTTP. Якщо хтось перейде за таким посиланням, спершу завантажиться сторінка через HTTP, а потім активується перенаправлення 301. Або якщо ви просто вводите лише ваш-домен.com в браузер, щоб зайти на веб-сайт, не вказуючи частину https, як це, напевно, робиться більшістю людей, існує можливість атаки посередником.
HSTS заважає атакуючому знизити з'єднання HTTPS до HTTP, що дозволяє атакуючому використовувати небезпечні перенаправлення. Таким чином, він змушує завантажувати через безпечне з'єднання HTTPS.
X-Content-Type-Options
Цей заголовок управляє тим, чи браузер намагається вгадати MIME-тип ресурсу, якщо вказаний тип неправильний. Він допомагає уникнути атак типу MIME-Spoofing, оскільки завантажуються лише стилі та скрипти з коректним MIME-типом. Пояснення: браузери можуть «пронюхувати», чи це текст, зображення (.png), відео (.mp4) або HTML, JavaScript та інші типи контенту, що можуть бути завантажені з веб-сайту.
Використання "X-Content-Type-Options: nosniff" - це важливий захисний захід, оскільки він допомагає уникнути певних векторів атак, таких як міжсайтовий скриптінг (XSS). У атаках XSS - див. також нижче - атакуючий може спробувати вставити шкідливий JavaScript-код у ресурс, такий як PDF, підставивши браузер, що це PDF, і викликавши його виконання як JavaScript, навіть якщо MIME-тип фактично вказує на щось інше, тут PDF.
Це має цілий ряд негативних наслідків для відвідувача веб-сайту, особливо при так званій атакі з "мертвою загрузкою", коли встановлюється шкідлива програма на комп'ютер відвідувача.
Використання "nosniff" є особливо важливим у поєднанні з іншими заходами безпеки, такими як політика безпеки контенту (CSP), для підвищення безпеки веб-застосунків та скорочення поверхні атак. Цей заголовок зазвичай включається в HTTP-відповіді для всіх ресурсів (наприклад, HTML-, JavaScript-, CSS-файлів) на веб-сайті.
X-Frame-Options
Цей заголовок забороняє показувати веб-сторінку в HTML-рамці або iframe, щоб запобігти атакам Clickjacking. Використання "X-Frame-Options" - це важливий захисний захід для запобігання атак Clickjacking, коли атакуючий намагається завантажити веб-сайт в невидиму рамку і зловживати клацаннями користувача. За допомогою цього заголовка власники веб-сайтів можуть контролювати спосіб вбудовування свого веб-сайту в рамки.
Зверніть увагу, що "X-Frame-Options" розглядається як застарілий метод запобігання Clickjacking. Сучасний підхід полягає у використанні заголовка "Політика безпеки контенту" (CSP), який також може запобігти Clickjacking та додатково покриває інші аспекти безпеки. Про це далі.
X-XSS-Protection
Цей заголовок вмикає або вимикає вбудований захист від XSS браузера.
Політика вказівника посилань
"Політика вказівника посилань" - це HTTP-заголовок, який відправляється веб-серверами для вказівки браузеру, як він має обробляти інформацію в полі "Вказівник" HTTP-запиту. "Вказівник" - це заголовок HTTP, який зазвичай вказує URL попередньої сторінки, з якої користувач переходить на поточну сторінку. "Політика вказівника" надає можливість власникам веб-сайтів контролювати передачу вказівникової інформації іншим веб-сайтам та захищати конфіденційність користувачів. Важливо для всіх, хто заробляє гроші в Інтернеті: політика вказівника не має впливу на партнерські посилання.
Політика безпеки контенту (CSP)
CSP-заголовки визначають, з яких джерел можна завантажувати ресурси (такі як скрипти, зображення та стилі). Це допомагає запобігти Cross-Site Scripting (XSS), впровадженню коду та іншим атакам.
Атаки по впровадженню коду на сторінках (XSS) створюються так, щоб вразити уразливість у вашій CMS або фреймворку, щоб завантажувати шкідливі скрипти на ваш веб-сайт, які потім вказівник вашого веб-сайту вивантажує у браузери відвідувачів. Ворота для атаки XSS може бути, наприклад, електронною формою, яка не розкодована таким чином, щоб приймати обмежений ввід. Погано зкодована форма може дозволяти інші ввідні данні, які в свою чергу можуть призвести до введення шкідливих файлів. Це, до речі, є ще однією причиною, чому ми, як агенція, додаємо багато проектів клієнтів повністю без контактної форми, оскільки вони майже завжди обходяться без неї.
Ви встановлюєте свій CSP-заголовок через своєрідний білий список доменів, які можуть узагальнено завантажувати ваш веб-сайт та які не можуть. Будь-який атакувальник, який завантажуватиме шкідливі скрипти з іншого сервера поза цією довіреною групою, буде заблокований. У грудні 2016 року політику безпеки контенту було розширено за допомогою CSP другого рівня, в якій були додані hash-source, nonce-source та п'ять нових директив. Від браузера очікується, що це не викличе проблем. На 11 вересня 2023 року CSP 2 сумісний з 95 відсотками всіх браузерів.
Створення політики безпеки контенту може бути сильним або слабким, залежно від того, як ви її налаштовуєте. У TutKit.com у нас реально найбільше часу зайняло налаштовування всіх заголовків, оскільки всі скрипти та ресурси повинні бути перелічені, щоб їх можна було додати до білого списку. Перевірку правильного включення ви можете виконати за допомогою securityheaders.com, з Mozilla Observatory та також з Google PageSpeed Insights в розділі Best Practices. Перевага сервісу Mozilla полягає в тому, що ваш URL одночасно тестується іншими зовнішніми тестовими інструментами. Якщо щось йде не так, ви можете здійснити додаткові дослідження тут.
Чому важливі безпекові заголовки?
Безпекові заголовки важливі, оскільки вони допомагають зменшити атаковану поверхню веб-сайтів і веб-застосунків та закривати відомі уразливості. Давши браузерам вказівки, як вони мають поводитися відносно безпеки, вони допомагають унеціймити різноманітні види атак або хоча б ускладнити їх. Це включає в себе атаки XSS, Clickjacking, MIME-Spoofing та інші проблеми безпеки.
Інтернет-магазини, які зберігають, передають або обробляють операції з кредитними картками, повинні відповідати вимогам стандарту PCI-DSS. Багато аудитів з PCI-DSS також перевіряють активовану HSTS (HTTP Strict Transport Security) та інші безпекові заголовки. Якщо ваш веб-сайт підпадає під вимоги стосовно відповідності PCI, тобто ви обробляєте платежі за кредитними картками, і ваш провайдер платежів очікує від вас сертифікацію PCI та ви маєте довести її через тест/аудит, включення безпекових заголовків стане для вас актуально.
Останнім важливим пунктом є забезпечення зручності для користувачів, що сприяє покращенню вашого SEO. Про це детальніше нижче.
Як реалізувати безпечні заголовки?
Реалізація безпечник заголовків, як правило, потребує зміни конфігурацій на рівні веб-сервера або веб-застосунку.
- Перш за все визначте потрібні безпечні заголовочки: Подумайте, які безпечні заголовки для вашого веб-сайту або веб-застосунку є найважливішими. Вибір залежить від ваших конкретних вимог та загроз. Якщо у вас є лише одно-сторінковий сайт без файлів cookie та контактних форм, заснований виключно на HTML, то ваш ризик нижчий, ніж у випадку магазину з файлами cookie, операціями з кредитними картками, даними клієнтів та CMS.
- Налаштуйте веб-сервер: Більшість безпечних заголовків можна додати, змінивши конфігурацію вашого веб-сервера. Наприклад, сервери Apache можуть конфігурувати заголовки в файлі .htaccess, тоді як Nginx використовується в конфігураційному файлі nginx.conf або sites-available.
- Встановіть заголовки у HTTP-відповіді: Заголовки повинні бути встановлені у HTTP-відповіді вашого веб-сайту або веб-застосунку. Це, як правило, можна здійснити за допомогою серверних модулів, скриптів або проміжного програмного забезпечення.
- Перевірка реалізації: Після того, як ви додали заголовки безпеки, ретельно перевірте ваш вебсайт або веб-додаток, щоб переконатися, що все працює так, як очікувалося. Існують також онлайн-інструменти, такі як Security Headers та Mozilla Observatory, які можуть проаналізувати конфігурацію безпеки вашого веб-сайту.
- Тримайте заголовки в актуальному стані: Регулярно відстежуйте та оновлюйте заголовки безпеки, щоб переконатися, що вони відповідають поточним найкращим практикам і захищені від нових загроз.
Точний спосіб реалізації заголовків безпеки може відрізнятися залежно від технології веб-сервера та платформи, тому рекомендується проконсультуватися з документацією вашого сервера та веб-додатку або, при необхідності, звернутися за професійною підтримкою. Нижче наведено інструкцію, як це можна зробити для серверів Apache і Nginx. На жаль, для не програмістів налаштування через плагін WordPress не таке просте як з серверною конфігурацією.
Додавання заголовків безпеки через .htaccess на серверах Apache
Додавання заголовків безпеки через файл .htaccess є поширеним методом поліпшення безпеки веб-сайту на сервері Apache. Файл .htaccess дозволяє встановлювати глобальні налаштування та конфігурації, включаючи заголовки безпеки. Нижче наведена покрокова інструкція, як можна додати заголовки безпеки через файл .htaccess:
Створення резервної копії: Зробіть резервну копію вашого веб-сайту та файлу .htaccess перед внесенням змін, щоб переконатися, що ви не призведете до намаганого втручання в роботу сайту.
Відкрийте файл .htaccess: Файл .htaccess зазвичай знаходиться в кореневій папці вашої установки WordPress. Ви можете відкрити його за допомогою текстового редактора, такого як Notepad++, Dreamweaver, PHP Storm або Visual Studio Code.
Додайте заголовки безпеки: Щоб додати заголовки безпеки, використовуйте інструкцію Header у файлі .htaccess. Ось кілька прикладів часто використовуваних заголовків безпеки та як їх додати:
Політика Безпеки Вмісту (CSP):
Параметри Типу Вмісту X-Content-Type-Options:
Параметри Фреймів X-Frame-Options:
Захист від XSS X-XSS-Protection:
Строга Політика Транспортної Безпеки (HSTS):
Політика Реферера Referrer-Policy:
Збережіть файл .htaccess: Після додавання потрібних заголовків безпеки збережіть файл .htaccess і завантажте його на ваш вебсервер, якщо це необхідно.
Перевірте конфігурацію: Переконайтеся, що ви не допустили синтаксичних помилок у файлі .htaccess, відвідавши сайт і спостерігаючи за можливими повідомленнями про помилки. Ви також можете використовувати онлайн-інструменти для перевірки ефективності ваших заголовків безпеки.
Перевірка вашого веб-сайту: Ретельно перевірте ваш веб-сайт, щоб переконатися, що всі функції працюють належним чином і що заголовки безпеки реалізують потрібні заходи безпеки.
Зверніть увагу, що додавання заголовків безпеки через файл .htaccess працює тільки на серверах Apache. Якщо ви користуєтеся іншим веб-сервером, таким як Nginx, вам потрібно редагувати відповідні конфігураційні файли для цього веб-серверу, щоб встановити заголовки безпеки. Далі більше в тексті...
Включення заголовків безпеки на серверах Nginx
Додавання заголовків безпеки в Nginx відбувається через конфігураційні файли Nginx, зазвичай в файлі з розширенням .conf. Нижче наведена покрокова інструкція, як можна включити заголовки безпеки в Nginx:
Робіть резервне копіювання: Перед внесенням змін у конфігурацію Nginx зробіть резервну копію конфігураційних файлів, щоб мати можливість повернутися до працюючої конфігурації у разі проблем.
Відкрийте файл конфігурації Nginx: Основний файл конфігурації Nginx зазвичай знаходиться в директорії, такій як /etc/nginx/ на системах Linux. Точна назва файлу може відрізнятися від системи до системи, але він зазвичай називається nginx.conf або default або sites-available для кожного сайту.
Використовуйте текстовий редактор або редактор командного рядка (такі як nano, vim або gedit), щоб відкрити конфігураційний файл. Для редагування файлу вам потрібні права Root або Superuser.
Додайте потрібні заголовки безпеки: Ви можете додати потрібні заголовки безпеки, скориставшись директивами add_header у вашу конфігурацію Nginx. Ось приклади деяких часто використовуваних заголовків безпеки:
Безпека контенту (CSP):
X-Content-Type-Options:
X-Frame-Options:
X-XSS-Protection:
Строга політика транспортної безпеки (HSTS) (Увага: Використовуйте лише, якщо ваш сайт завжди доступний через HTTPS):
Політика вказівника джерел:
Збережіть і закрийте файл конфігурації: Після додавання потрібних заголовків, збережіть файл конфігурації та закрийте його.
Перевірте зараз конфігурацію: Ви можете перевірити валідність конфігурації Nginx за допомогою команди nginx -t. Якщо конфігурація валідна, повідомлення про успішне виконання має з'явитися.
Запустіть або оновіть Nginx: Після перевірки конфігурації, запустіть або оновіть сервер Nginx, щоб нові заголовки були активовані. Ви можете перезапустити сервер за допомогою команди sudo service nginx restart (на Debian/Ubuntu) або sudo systemctl restart nginx (на системах на основі systemd).
Перевірте ваш сайт: Перевірте свій сайт, щоб переконатися, що всі функції працюють належним чином і що заголовки безпеки реалізують потрібні заходи безпеки.
Зверніть увагу, що конфігурація Nginx може відрізнятися від системи до системи, особливо якщо ви використовуєте кілька віртуальних хостів (блоків сервера) або складну конфігурацію. Тож переконайтеся, що ви редагуєте правильний конфігураційний файл, відповідний для вашого сайту.
Плагіни для WordPress для заголовків безпеки
Існують різні плагіни WordPress, які можуть допомогти вам встановити заголовки безпеки на вашому сайті WordPress. Ці плагіни спрощують впровадження заходів безпеки, навіть якщо у вас немає глибоких технічних знань.
Плагін "Headers Security Advanced & HSTS WP" спеціалізується на налаштуванні безпекових заголовків та строгої політики транспортної безпеки (HSTS) на сайтах WordPress. Він надає зручний спосіб налаштування цих заголовків та заходів безпеки.
https://de.wordpress.org/plugins/headers-security-advanced-hsts-wp/
Ось деякі інші плагіни WordPress, які можуть допомогти у налаштуванні заголовків безпеки:
- WP Security Headers: Цей плагін дозволяє налаштувати різні заголовки безпеки на вашому сайті WordPress. Він має зручний інтерфейс, який дозволяє настроювати заголовки, такі як Політика захисту контенту (CSP), Опції типу вмісту X та інші.
- HTTP Headers: HTTP Headers - це плагін WordPress, який дозволяє задавати різні HTTP-заголовки для більшої безпеки та конфіденційності. З його допомогою ви можете настроювати заголовки, такі як Параметри типу вмісту X, Захист від міжсайтової скриптінгу та Політика вказівника джерел.
- Security Headers: Цей плагін спеціалізується на налаштуванні Політики захисту контенту (CSP). Він надає простий спосіб налаштувати та настроїти політику CSP для вашого сайту.
- Easy Security Headers: Цей плагін пропонує простий спосіб активувати та налаштувати важливі заголовки безпеки в WordPress. Він включає заголовки, такі як Політика захисту контенту, Строга політика транспортної безпеки та Опції типу вмісту X.
Перш ніж використовувати плагін для налаштування заголовків безпеки в WordPress, переконайтеся, що він сумісний з вашою версією WordPress та версією PHP.
Заголовки безпеки для Headless CMS Strapi впровадити
Strapi - це популярна система управління контентом, яка базується на Node.js. Аналогічно до WordPress, і для Strapi є можливість впровадження заголовків безпеки. Однак в Strapi налаштування заголовків безпеки, як правило, здійснюється на більш глибокому рівні, оскільки це серверна програма. Ось кроки для встановлення заголовків безпеки в застосунку Strapi:
Використання проміжного рівня: В Strapi ви можете використовувати проміжні шари для встановлення HTTP-заголовків. Ви можете створити власний проміжний шар, який додасть потрібні заходи безпеки в HTTP-відповіді. Ось приклад, як це можна зробити:
1. Створіть файл, наприклад, security-headers.js, у своєму каталозі проміжних шарів
2. Встановіть потрібні заходи безпеки
3. Викличіть наступний крок проміжного прошарку
Реєстрація проміжного прошарку: Після створення проміжного прошарку вам потрібно зареєструвати його в файлі middleware.js вашого додатку Strapi, щоб забезпечити виконання при кожному HTTP-запиті.
Інші налаштування ...
Інші проміжні прошарки ...
Налаштування та тестування: Налаштуйте значення заголовків в проміжному прошарку відповідно до ваших вимог. Переконайтеся, що заголовки встановлені правильно, тестуючи додаток та використовуючи інструменти, такі як перевірка заголовків безпеки.
Перевірка конфігурації сервера: Помимо налаштування проміжного прошарку в Strapi, важливо також переконатися, що ваш веб-сервер (наприклад, Nginx або Apache), якщо він є, не встановлює суперечливих заголовків, які можуть переписати встановлені Strapi.
Конкретні реалізації можуть відрізнятися залежно від вашого налаштування Strapi та вашого серверу. Альтернативно можна використовувати config/app.js в Strapi CMS. Проте шлях через middleware дає вам більше контролю та гнучкості.
Ось як це виглядає на нашому сайті агентства 4eck-media.de, який використовує головний CMS Strapi:
Інструменти тестування Security Header та вразливостей сайтів
Якщо ви встановили заголовки безпеки, обов'язково протестуйте роботу вашого сайту з різними браузерами та кінцевими пристроями. Не забудьте також скористатися наступними двома інструментами тестування, щоб переконатися, що все підключено правильно:
- securityheaders.com => цей інструмент спеціалізується на заголовках безпеки. Див. знімок екрану вище.
- securityscan.getastra.com => цей інструмент тестує понад 140 вразливостей та заголовки безпеки.
На теперішній момент у нас є оцінка 90/100 для сайту tutkit.com у рамках перевірки безпеки за допомогою https://securityscan.getastra.com/:
Як бачите, є ще куди піднятися, незважаючи на те, що все в порядку. В нашому випадку це пов'язано з окремими модулями, які видають JavaScript інакше, ніж пропонують стандарти безпеки для найкращих практик використання. Починаючи з наступного основного оновлення нашого JavaScript-фреймворку vue.js та модулів Laraberg від TutKit.com, ми також звернемо на це увагу.
Чи мають Security Headers сенс для оптимізації пошуку (SEO)?
Існує взаємозв'язок між заголовками безпеки і SEO (оптимізація пошуку), хоча цей зв'язок є в основному непрямим.
Google заявив в травні 2020 року, що у 2021 році експертиза сторінки об'єднує сім різних факторів та утворює цілісне уявлення про якість в сприйнятті веб-сайту.
HTTPS та Safe Browsing є одними з основних чинників, які сприяють позитивним сигналам для експертизи сторінки. Використання HTTPS також було описано Google як фактор ранжування. Те ж саме стосувалося спочатку безпеки перегляду. У серпні 2021 року Google відмінив це і заявив, що безпека перегляду вже не враховується як фактор ранжування, оскільки багато власників веб-сайтів не мають вини за взлом сайту.
У PageSpeed Insights та тестах Lighthouse через інструменти розробника в Chrome ви побачите рекомендацію щодо безпечного перегляду. Тому можна припустити, що тема безпечного перегляду для SEO все ж таки не зовсім закрита:
Крім того, Google вагує вище веб-сайти, які дотримуються принципів EEAT, тобто їхні вміст, побудований за експертизою, досвідом, авторитетом та надійністю, перевірено. Надійність відноситься до надійності та вірогідності веб-сайту або веб-контенту. Google оцінює надійність на основі факторів, таких як конфіденційність, безпека та прозорість.
Який саме зв'язок має Security Headers з SEO, це може бути пояснено п'ятьма перевагами HTTP-заголовків для вашого веб-сайту та його відвідувачів:
- Довіра та безпека: Веб-сайт, що використовує захисні заголовки, сигналізує відвідувачам та пошуковим системам, що він турбується про безпеку своїх користувачів і даних. Це може зміцнити довіру користувачів до веб-сайту та знизити ризик безпекових проблем, таких як витоки даних та атаки зловмисників.
- Уникнення проблем безпеки: Захисні заголовки, такі як політика безпеки вмісту (CSP) та X-XSS-Protection, допомагають уникнути відомих порушень безпеки, таких як міжсайтовий скриптінг (XSS). Веб-сайти, що вразливі до проблем безпеки, можуть бути покарані пошуковими системами або відображати попередження для користувачів, що може негативно вплинути на SEO.
- Покращені часи завантаження: Деякі захисні заголовки, такі як HTTP Strict Transport Security (HSTS), можуть допомогти покращити час завантаження веб-сайту, оскільки вони змушують браузер підключатися через HTTPS. Швидке завантаження є важливим фактором для SEO, оскільки пошукові системи, такі як Google, враховують час завантаження як критерій рейтингування.
- Попередження від Clickjacking та Phishing: Захисні заголовки, такі як X-Frame-Options, можуть допомогти уникнути атак Clickjacking, коли вміст веб-сайту відображається в невидимому фреймі. Це може підвищити довіру користувачів до веб-сайту та зменшити ймовірність атаки phishing.
- HTTPS та ранжування: Хоча не прямо пов'язане з захисними заголовками, використання HTTPS (сприянням захисних заголовків, таких як HSTS) є важливим фактором SEO. Google вже в 2010 році оголосив, що HTTPS враховується як сигнал рангування, і веб-сайти з HTTPS можуть мати перевагу в SEO.
Використання захисних заголовків може, на мою думку, позитивно впливати на рангування в SEO веб-сайту, але вони не є єдиним критерієм, а лише дуже малою частиною загального рівня безпеки та SEO. Веб-сайт, який надає непотрібний вміст або недолічений досвід користувача, не покращить свій показник в результатах пошуку лише через додавання захисних заголовків. SEO - це складний процес, який враховує багато факторів, включаючи високоякісний вміст, гарний досвід користувача, оптимізацію для мобільних пристроїв та багато іншого. Проте захисні заголовки є важливою складовою для здобуття довіри користувачів та підвищення загальної безпеки веб-сайту, що в кінцевому підсумку може позитивно вплинути на рангування в SEO.
Або, в інших словах: якщо ваш веб-сайт заражено шкідливим ПЗ і Google повідомляє відвідувачам веб-сайту про попередження, це прямо впливає на вашу репутацію. Ваше рангування буде падати, а з ним усі ваші попередні успіхи в SEO. Як веб-мастер, ви також отримаєте повідомлення від Google про це через Консоль Пошуку. Ви також маєте змогу протестувати вашу веб-послугу на пошкодження від шкідливих програм тут.
Ми пишаємося тим, що ми на старті перевели наші захисні заголовки на найсучасніший рівень. І таким чином ми також увійшли в Зал слави:
Висновок: Впровадження захисних заголовків - це не ракетна наука і слід розглядати його при кожному запуску веб-сайту. Нажаль, багато веб-мастерів, агентств і експертів з SEO не мають його на увазі, тому було б добре, якби інструменти SEO включали запитання про HTTP-заголовки в свої аудити. Побачимо ... я вже звернувся з цим побажанням до керівництва SEOBILITY :-)