Здравствуйте, уважаемые читатели моего блога!

В этой статье я хочу рассказать Вам о том, как я составляю заголовки для своего блога. В частности, мы поговорим о мета тэгах «title» и h2-h6.

Правильное составление заголовка для сайта — это важнейшее мероприятие, которому необходимо уделить самое пристальное внимание перед публикацией каждого поста! Давайте поговорим об этом более подробно.

Важность мета тэгов title, h2-h6

Для того чтобы понять насколько важны заголовки страниц сайта, давайте введем в строку поиска Яндекса любой поисковый запрос, например, «Правильный title», вот что мы увидим:

Страницы, представленные в ТОП-3 в самом начале своих заголовках, содержат именно эту ключевую фразу!

Конечно, это правило работает не всегда, но все же…

Сразу же после публикации поста и его индексации поисковыми системами можно увидеть его в выдаче, введя в строку поиска полный заголовок Вашей страницы, особенно если он грамотно составлен и уникален (об этом более подробно я расскажу ниже).

Отсюда следует, что именно заголовок страницы является определяющим фактором ранжирования страниц в выдаче поисковых систем, поэтому нужно очень тщательно подходить к его составлению.

Иногда поисковики пытаются самостоятельно составить заголовок, но это происходит вследствие того, что ключевые слова, содержащиеся в тексте поста, в заголовке отсутствуют, что не очень хорошо сказывается на поисковом продвижении блогов и сайтов.

Поисковые системы — это роботы, которым нужно обозначить тему Вашего поста, а лучший способ сделать это — указать поисковые запросы в заголовке поста.

Заголовки бывают нескольких типов — это title, h2, h3, h4, h5, h5, h6.

Тэги h2-h6 распределяются по важности, их еще называют подзаголовки.

Обычно на многих CMS тэг title формируется из заголовка поста (в моем случае тэг h2), который вы видите в самом начале поста.

Однако, на мой взгляд, title (то, что мы видим на вкладке браузера) лучше всего указывать вручную. Для этого на своем блоге я использую плагин поисковой оптимизации All in SEO Pack, который позволяет помимо title страницы указать ее описание и подобранные ключевые слова (фразы).

Плагин «All in SEO Pack» можно настроить различными способами, однако, на мой взгляд, самым правильным будет вариант, где сначала идет заголовок страницы, затем название интернет ресурса. В моем случае это выглядит так:

Это дело задается в настройках плагина вот таким образом:

Проверить правильность указания тэгов title и h2-h6 можно в исходном коде страницы, нажав комбинацию клавиш Ctrl+U на клавиатуре.

Как составить правильный заголовок сайта?

Теперь давайте поговорим о правилах составления title, которые помогут Вам сделать так, чтобы страницы Ваших сайтов занимали достойные места в выдаче поисковых систем.

1. Длина заголовка

Заголовок не должен быть слишком длинным или коротким. Максимальная длина не должна превышать 70 символов, а минимальную рекомендуется делать не менее 50 знаков. Лично я на своем блоге всегда стараюсь найти золотую середину. Например, титл этого поста содержит 65 символов с пробелами и 57 без них.

2. Уникальность тайтла

Перед тем, как составлять титл поста я смотрю поисковую выдачу и стараюсь составить уникальное название для своей страницы, которого нет на других ресурсах, представленных в результатах поисковой выдаче.

Кроме того, абсолютно все заголовки страниц Вашего интернет ресурса должны отличаться друг от друга! Страниц с одинаковыми названиями быть не должно!

Проверить наличие одинаковых тайтлов можно при помощи инструментов для вебмастеров Google в разделе «Оптимизация HTML».

В моем случае имеется 5 страниц с одинаковым title, на этих страницах представлены кроссворды, которые не участвуют в поиске.

Все заголовки и подзаголовки на страницах лучше делать отличными друг от друга. Например, этот пост имеет отличающиеся тэги title, h2 и h3.

3. Релевантность и ключевые слова

Самый важный момент SEO оптимизации сайта при составлении заголовка страницы сайта. В названии каждой страницы необходимо указать ключевые слова, по которым продвигается страница. Особенно это касается высокочастотных запросов, которые следует написать в самом начале title, затем уже можно прописать фразы, имеющие более низкую частотность.

Название страницы должно точно отражать ее содержание, то есть тайтл должен быть релевантен тексту поста.

4. Другие советы

При составлении названий страниц старайтесь использовать синонимы к используемым ключевым словам, разбавляйте их. Другими словами, не стоит повторять одни и те же слова в названии страницы несколько раз.

Старайтесь по возможности исключать из title знаки препинания и стоп слова.

Стремитесь придумать оригинальное и притягивающее название для своих страниц, это, в совокупности с favicon для сайта и отображением авторства в Google, повысит интерес пользователей и они будут охотнее переходить к Вам на сайт.

Этого можно добиться путем противоречия установившимся понятиям, например, мой пост «Внутренняя перелинковка мешает продвижению сайтов» яркий тому пример!

НОВОСТИ:

На блоге Евгения Щербинина опубликовано интервью со мной, ознакомиться с ним можно по этой ссылке.

На этом у меня все. Как Вам статья?

С уважением, Александр Бобрин

Поделись с друзьями:

Обратите внимание:

Похожие статьи

Правильный заголовок для сайта — рекомендации по составлению Title сайта

Приветствую Вас на блоге inetsovety.ru. В этой статье я хочу описать, как правильно составить заголовок сайта. Еще заголовок сайта называют title (тайтл).

Зачем нужно правильно составлять заголовок сайта? Во-первых, заголовок сайта показывается в результатах поисковой выдачи и, если заголовок хороший, то он привлечет внимание пользователя, и он зайдет на Ваш сайт.

Не допускается использовать в заголовке простое перечисление ключевых слов через запятую. Такой заголовок будет отталкивать людей, да и в глазах поисковых систем сайту не добавится авторитета.

Но просто красивый заголовок, ориентированный на пользователей тоже не подойдет. Так как не следует забывать о поисковых роботах, для которых заголовок сайта, служит одним из критериев ранжирования сайта.

Вывод один: нужно так изощриться, чтобы составить заголовок, устраивающий поисковых роботов и привлекающий пользователей.

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

Дальше нужно подумать по каким бы ключевым словам Вы стали искать свой сайт. После этого проверить популярность каждого из ключевых запросов в wordstat.yandex. Подробнее о том,  как подбирать ключевые слова.

Длина заголовка должна быть до 70 символов. В заголовке должен содержаться ключевой запрос, с популярностью 1000-10000 запросов в месяц. Еще лучше, когда в заголовке содержится ключевой запрос, который содержит в себе несколько запросов, один из которых высокочастотный, а другие среднечастотные.

К примеру, мы создаем сайт на тему заработка. Берем ключевой запрос «как заработать в интернете» — он является ВЧ и запрашивается 68000 раз в месяц. Но для заголовка можно его дополнить и составить заголовок в таком виде: Как заработать в интернете без вложений. Запрос «заработать в интернете без вложений» запрашивается 13000 раз. Таким образом, мы составили заголовок, состоящий из двух ключевых слов.

В завершение хочется сказать, что отнеситесь к составлению заголовка серьезно, ведь от этого будут зависеть позиции Вашего сайта в результатах поисковой выдачи. Собственно нужно правильно подбирать не только заголовок сайта, но и заголовки каждой статье, подробнее читайте здесь об оптимизации статьи.

С уважением, Виктория – блог inetsovety.ru

HTTP-заголовки для ответственного разработчика / Mail.ru Group corporate blog / Habr

Разработчики соединяют людей.
Разработчики помогают людям.
Разработчики дают людям возможности.

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

HTTP — протокол передачи гипертекста

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

Сервер отвечает запрашиваемым ресурсом, но также отправляет заголовки ответа, содержащие информацию о ресурсе или самом сервере.

Request:
GET https://the-responsible.dev/
Accept: text/html,application/xhtml+xml,application/xml
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,de;q=0.7
...

Response:
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Date: Mon, 11 Mar 2019 12:59:38 GMT
...
Response Body

Сеть должна быть безопасной

Если вы сегодня разрабатываете для веба, то не просто пишете код. Сегодня в веб-разработке над одним сайтом работает много людей. Возможно, вы также используете много открытого исходного кода. Кроме того, для маркетинговых целей вы можете включить несколько сторонних скриптов. Сотни людей предоставляют код, запущенный на вашем сайте. И разработчикам приходится работать в подобных реалиях.

Можно ли доверять всем этим людям и всему исходному коду?

Я не думаю, что следует доверять какому-либо стороннему коду. К счастью, есть способы защитить свой сайт и сделать его более безопасным. Кроме того, такие инструменты, как helmet могут быть полезны, например, для экспресс-приложений.

Если вы хотите проанализировать, сколько стороннего кода запускается на вашем сайте, можно посмотреть в панели разработчика или попробовать Request Map Generator.

HTTPS и HSTS — убедитесь, что ваше соединение безопасно

К счастью, сегодня сертификаты TLS бесплатны; HTTPS стал стандартом, и браузеры предоставляют передовые функции только для защищенных соединений, и даже отмечают веб-сайты, не относящиеся к HTTPS, как небезопасные, что способствует внедрению этого протокола. К сожалению, мы не всегда в безопасности, когда находимся в интернете. Когда кто-то хочет открыть сайт, он не вводит протокол в адресную строку (и почему вообще должен?). Это приводит к созданию незашифрованного HTTP-запроса. Безопасно работающие сайты перенаправляют пользователя на HTTPS. Но что если кто-то перехватит первый незащищенный запрос?

Вы можете использовать заголовки ответа HSTS (HTTP Strict Transport Security), чтобы сообщить браузерам, что ваш сайт работает только через HTTPS.

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

Вы можете настроить, как долго этот параметр должен оставаться активным (max-age в секундах), если захотите потом снова использовать HTTP. Если вы хотите включить поддомены, то можете настроить это с помощью includeSubDomains.

Если вы хотите сделать всё возможное, чтобы браузер никогда не запрашивал ваш сайт по HTTP, можете также задать указатель preload и отправить ваш сайт в глобальный список. Если конфигурация HSTS вашего сайта соответствует минимальному max-age в один год и активна для поддоменов, он может быть включен во внутренний список браузер для сайтов, работающих только через HTTPS.

Задумывались ли вы когда-нибудь, почему вы больше не можете использовать в своем браузере через HTTP локальные переменные среды, такие как my-site.dev? Причина именно в этом внутреннем списке — .dev автоматически включаются в этот список, поскольку в феврале 2019 года он стал настоящим доменом верхнего уровня.

Заголовок HSTS не только делает ваш сайт немного безопаснее, но и ускоряет его работу. Представьте себе, что кто-то заходит по медленному мобильному соединению. Если первый запрос сделан через HTTP только для получения перенаправления, то пользователь может несколько секунд ничего не видеть на экране. А с помощью HSTS вы можете сэкономить эти секунды, и браузер автоматически будет использовать HTTPS.

CSP — четко укажите, что разрешено на вашем сайте

Content-Security-Policy: upgrade-insecure-requests

Однако CSP касается не только используемого протокола. Он предлагает детальные способы определения того, какие ресурсы и действия разрешены на вашем сайте. Вы можете, например, указать, какие скрипты должны выполняться или откуда загружать изображения. Если что-то не разрешено, браузер блокирует это действие и предотвращает потенциальные атаки на ваш сайт.

На момент написания статьи для CSP существовало 24 различных варианта конфигурации. Они варьируются от скриптов через таблицы стилей вплоть до сервис-воркеров.

Вы можете найти полный обзор на MDN.

Используя CSP, вы можете указать, что должен включать ваш сайт, а что нет.

Content-Security-Policy: default-src 'self'; script-src 'self' just-comments.com www.google-analytics.com production-assets.codepen.io storage.googleapis.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: images.contentful.com images.ctfassets.net www.gravatar.com www.google-analytics.com just-comments.com; font-src 'self' data:; connect-src 'self' cdn.contentful.com images.contentful.com videos.contentful.com images.ctfassets.net videos.ctfassets.net service.just-comments.com www.google-analytics.com; media-src 'self' videos.contentful.com videos.ctfassets.net; object-src 'self'; frame-src codepen.io; frame-ancestors 'self'; worker-src 'self'; block-all-mixed-content; manifest-src 'self' 'self'; disown-opener; prefetch-src 'self'

Чтобы избежать взлома вашего сайта, CSP также предоставляет режим только для отчетов.

Content-Security-Policy-Report-Only: default-src 'self'; ... report-uri https://stefanjudis.report-uri.com/r/d/csp/reportOnly

Оба заголовка, Content-Security-Policy и Content-Security-Policy-Report-Only, также предлагают способ определения конечной точки для отправки сообщения о нарушении и регистрации информации (report-uri). Вы можете настроить сервер регистрации и использовать отправленную информацию журнала для настройки правил CSP, пока он не будет готов к отправке.

Рекомендуемый процесс выглядит так: сначала запустите CSP в режиме отчета, проанализируйте входящие нарушения с реальным трафиком, и только тогда, когда не будет обнаружено нарушений ваших контролируемых ресурсов, включите его.

Если вы ищете сервис, который мог бы помочь вам справиться с этими журналами, то рекомендую Report URI, он мне очень помогает.

Общее внедрение CSP

Сеть должна быть доступной

И дело не только во впечатлении. Люди платят различные суммы за трафик в зависимости от места проживания. Представьте себе, вы создаете сайт для больницы. Информация на нём может иметь решающее значение и спасти жизни людей. Если страница на сайте больницы имеет размер 5 Мб, то она не только будет медленно работать, но и может оказаться слишком дорогой для тех, кто больше всего в ней нуждается. Цена пяти мегабайтов трафика в Европе или США ничтожна по сравнению с ценой в Африке. Разработчики несут ответственность за доступность веб-страниц для всех. Эта ответственность включает в себя предоставление правильных ресурсов, выбор правильных инструментов (действительно ли вам нужен JS-фреймворк для лендинга?) и недопущение запросов.

Cache-Control — избегайте запросов на неизменные ресурсы

Cache-Control: max-age=30, public

Однако, если посетители обновляют страницу, браузеры всё равно повторно проверяют её, включая ссылки на ресурсы, чтобы убедиться, что кэшированные данные всё ещё действительны. Серверы отвечают заголовком 304, сигнализируя, что кэшированные данные пока действительны, или заголовком 200 при передаче обновленных данных. Это позволяет сохранить переданные данные, но не обязательно сделанные запросы.

Именно здесь вступает в игру функция immutable.

Immutable — никогда не запрашивать ресурс дважды

Эти уникальные файлы потенциально могут храниться в кэше вечно, включая ситуацию, когда пользователь обновляет страницу. Функция immutable может запретить браузеру повторную проверку ресурса в определенный промежуток времени. Это очень важно для объектов с контрольными суммами, и помогает избежать повторных проверочных запросов.

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

Accept-Encoding — максимальное сжатие (до минимума)

Отдавая ресурсы, разработчики должны позаботиться о том, чтобы отправлять как можно меньше данных. Для текстовых ресурсов, таких как HTML, CSS и JavaScript, сжатие играет важную роль в экономии передаваемых данных.

Самым популярным методом сжатия сегодня является GZIP. Серверам хватает мощности для сжатия текстовых файлов на лету и предоставления сжатых данных при запросе. Но GZIP уже не самый лучший вариант.

Если вы взглянете на создаваемые браузером запросы текстовых файлов, таких как HTML, CSS и JavaScript, и проанализируете заголовки, то найдете среди них accept-encoding.

Accept-Encoding: gzip, deflate, br

Этот алгоритм сжатия был создан с учетом небольшого размера файлов. Если вы попробуете сжать файл вручную на вашем локальном устройстве, то обнаружите, что Brotli действительно сжимает лучше, чем GZIP.

Вы, возможно, слышали, что сжатие Brotli выполняется медленнее. Причина в том, что Brotli имеет 11 режимов сжатия, и по умолчанию выбирается тот, при котором получаются файлы наименьшего размера, что удлиняет процедуру. GZIP, с другой стороны, имеет 9 режимов, и по умолчанию выбирается тот, при котором учитывается как скорость сжатия, так и размера файла. В результате режим Brotli по умолчанию непригоден для сжатия «на лету», но если изменить режим, то можно добиться сжатия небольших файлов с той же скоростью, что и у GZIP. Вы можете использовать его для сжатия на лету и рассматривать как потенциальную замену GZIP для поддерживающих браузеров.

Кроме того, если вы хотите максимально экономить файлы, то можете забыть о динамическом сжатии и предварительно сгенерировать оптимизированные GZIP-файлы с помощью файлов zopfli и Brotli для их статического обслуживания.

Если вы хотите прочитать больше о сжатии Brotli и его сравнении с GZIP, сотрудники компании Akamai провели обширное исследование на эту тему.

Accept и Accept-CH — обслуживайте индивидуальные ресурсы для пользователя

Accept — обслуживание изображений правильного формата

Accept: image/webp, image/apng, image/*,*/*;q=0.8

Используя этот заголовок запроса, разработчики могут передавать изображение webp, даже если браузер запросил image.jpg, в результате чего размер файла будет меньше. Дин Хьюм написал хорошее руководство о том, как это применять. Очень круто!

Accept-CH — обслуживание изображений правильного размера

Вы можете активировать подсказки, добавив мета-элемент:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink">
<meta http-equiv="Accept-CH-Lifetime" content="86400">

Accept-CH: Width, Viewport-Width
Accept-CH-Lifetime: 100

Например, для получения дополнительной информации, такой как ширина изображения на стороне сервера, вы можете снабдить свои изображения атрибутом sizes, чтобы дать браузеру дополнительную информацию о том, как эти изображения будут выглядеть.

<!-- this images is laid over the full width | 100 viewport width -->
<img src="/img/header.jpg" alt="">

Имея поддерживаемый формат и размеры изображения, вы можете отправлять адаптированные данные без необходимости записывать ненадежные элементы изображений и обращать внимание только на формат и размер файлов, как показано ниже.

<picturе>
  <!-- serve WebP to Chrome, Edge, Firefox and Opera -->
  <source
    media="(min-width: 50em)"
   
    srcset="/image/thing-200.webp 200w, /image/thing-400.webp 400w,
        /image/thing-800.webp 800w, /image/thing-1200.webp 1200w,
        /image/thing-1600.webp 1600w, /image/thing-2000.webp 2000w"
    type="image/webp">
  <source
   
    srcset="/image/thing-crop-200.webp 200w, /image/thing-crop-400.webp 400w,
        /image/thing-crop-800.webp 800w, /image/thing-crop-1200.webp 1200w,
        /image/thing-crop-1600.webp 1600w, /image/thing-crop-2000.webp 2000w"
    type="image/webp">
 <!-- serve JPEG to others -->
  <sоurce
    media="(min-width: 50em)"
   
    srcset="/image/thing-200.jpg 200w, /image/thing-400.jpg 400w,
        /image/thing-800.jpg 800w, /image/thing-1200.jpg 1200w,
        /image/thing-1600.jpg 1600w, /image/thing-2000.jpg 2000w">
  <sоurce
   
    srcset="/image/thing-crop-200.jpg 200w, /image/thing-crop-400.jpg 400w,
        /image/thing-crop-800.jpg 800w, /image/thing-crop-1200.jpg 1200w,
        /image/thing-crop-1600.jpg 1600w, /image/thing-crop-2000.jpg 2000w">
  <!-- fallback for browsers that don't support picture -->
  <img src="/image/thing.jpg">
</picturе>

Однако нужно учитывать, что не следует создавать изображения для любой ширины просто потому, что у вас есть точная ширина изображения. Отправка изображений для определенного диапазона размеров (image-200, image-300, ...) помогает использовать CDN-кэширование и экономит время вычислений.

Кроме того, с такими современными технологиями, как service worker’ы, вы даже можете перехватывать и изменять запросы прямо в клиенте, чтобы обслуживать лучшие файлы изображений. С включенными клиентскими подсказками service worker’ы получают доступ к информации о макетах, и в сочетании с API изображений, как, например, Cloudinary, вы можете настроить url изображения прямо в браузере для получения картинок надлежащего размера.

Если вы ищете более подробную информацию о клиентских подсказках, можете ознакомиться со статьями Джереми Вагнера или Ильи Григорика на эту тему.

Сеть должна быть бережной

Preload — сокращение времени ожидания

Приведу пример: если вы добавите на сайт таблицу стилей, браузеры не будут ничего показывать, пока она не загрузится. Пока на экране ничего не отображается, браузер продолжает анализировать HTML в поисках других ресурсов для запрашивания. После загрузки и парсинга таблицы стилей в ней могут оказаться ссылки на другие важные ресурсы, такие как шрифты, которые тоже могут быть запрошены. Этот процесс может увеличить время загрузки страницы для ваших посетителей.

Используя Rel=preload вы можете дать браузеру информацию о том, какие ресурсы будут запрошены в ближайшее время.

Можете предварительно загрузить ресурсы через HTML-элементы:

<link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin="anonymous">

Link: </font.woff2>; rel=preload; as=font; no-push

Для оптимальной предварительной загрузки ресурсов и понимания всех конфигураций я рекомендую обратить внимание на следующие материалы:

Feature-Policy — не раздражайте других

Не требуйте разрешение при загрузке страницы. Разработчики должны относиться с уважением и не создавать сайты, раздражающие посетителей. Люди просто кликают на все окна с разрешениями. Если мы не используем их правильно, то сайты и разработчики теряют доверие, а новые блестящие функции — свою привлекательность.

Но что, если ваш сайт обязательно должен включать много стороннего кода, и все эти скрипты запускают множество диалоговых окон с разрешением? Как убедиться, что все включённые скрипты ведут себя правильно?

Именно здесь в игру вступает заголовок Feature-Policy. С его помощью вы можете указать, какие функции разрешены, и ограничить всплывающие диалоговые окна с разрешениями, которые могут быть вызваны сторонним кодом, исполняемым на вашем сайте.

Feature-Policy: vibrate 'none'; geolocation 'none'

<iframe allow="camera 'none'; microphone 'none'">

Вы можете найти полный обзор на MDN.

Глядя на список выше, вы можете вспомнить о самом раздражающем моменте — push-уведомлениях. Оказалось, что применение Feature-Policy для push-уведомлений сложнее, чем ожидалось. Если вы хотите узнать больше, можете подписаться на соответствующую тему на GitHub.

Благодаря feature policy можете быть уверены, что вы и сторонние ресурсы не превратите ваш сайт в гонку за разрешениями, которая, к сожалению, уже стала привычной для многих сайтов.

Сеть должна быть для всех

Я знаю, что создание отличного сайта сегодня — очень сложная задача. Разработчики должны учитывать дизайн, устройства, фреймворки, и да… заголовки тоже играют определённую роль. Надеюсь, эта статья даст вам некоторые идеи, и вы будете учитывать безопасность, доступность и уважительность в ваших следующих веб-проектах, потому что это именно те факторы, которые делают сеть по-настоящему отличным местом для всех.

Ненужные HTTP-заголовки / Habr

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В то же время есть много чрезвычайно популярных заголовков, которые вообще не новые и не очень полезные. Мы можем это доказать с помощью HTTP Archive, проекта под управлением Google и спонсируемого Fastly, который каждый месяц при помощи WebPageTest скачивает 500 000 сайтов и выкладывает результаты в BigQuery.

Вот 30 самых популярных заголовков ответов по данным HTTP Archive (на основе количества доменов в архиве, которые выдают каждый заголовок), и примерная оценка полезности каждого из них:

Тщеславие (server, x-powered-by, via)

Server: apache
X-Powered-By: PHP/5.1.1
Via: 1.1 varnish, 1.1 squid

RFC7231 позволяет включать в ответ сервера заголовок Server, указывая конкретный софт на сервере, который используется для выдачи контента. Чаще всего это строка вроде «apache» или «nginx». Хотя заголовок разрешён, он не обязательный и не особо ценный для разработчиков или конечных пользователей. Тем не менее, сегодня это третий по популярности серверный HTTP-заголовок в интернете.

X-Powered-By — самый популярный заголовок из тех, что не определены никаким стандартом, и у него похожая цель: обычно он указывает платформу приложений, на которой работает сервер. Самые популярные ответы включают в себя «ASP.net», «PHP» и «Express». Опять же, это не несёт никакой ощутимой пользы и просто занимает место.

Возможно, более спорным можно считать Via. Его обязан (по RFC7230) добавлять в запрос каждый прокси, через который проходит запрос — для идентификации прокси. Это может быть имя хоста прокси, но чаще общий идентификатор вроде «vegur», «varnish» или «squid». Удаление (или не добавление) такого заголовка может привести к циклу переадресации прокси. Но интересно, что он также добавляется в ответ на обратном пути к браузеру — и здесь выполняет просто информационную функцию: никакие браузеры ничего не с ним делают, поэтому достаточно безопасно избавиться от него, если хотите.

Устаревшие стандарты (P3P, Expires, X-Frame-Options, X-UA-Compatible)

P3P: cp="this is not a p3p policy"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge

P3P — забавная штучка. Я понятия не имел, что это такое. Ещё забавнее, что одно из самых распространённых содержаний заголовка P3P — «Это не правило P3P». Ну так это оно или нет?

Тут история восходит к попытке стандартизировать машиночитаемые правила приватности. Были разногласия по поводу того, как отображать данные в браузерах, и только один браузер реализовал поддержку этого заголовка — Internet Explorer. Но даже в нём P3P не имел никакого визуального эффекта для пользователя; он просто должен был присутствовать, чтобы разрешить доступ к сторонним кукам во фреймах. Некоторые сайты даже установили правила несоблюдения P3P, как в примере выше, хотя делать так весьма сомнительно.

Нечего и говорить, что чтение сторонних куков вообще обычно плохая идея, так что если вы этого не делаете, то вам и не нужно устанавливать заголовок P3P!

Expires просто невероятно популярен с учётом того, что Cache-Control имеет преимущество перед Expires уже в течение 20 лет. Если заголовок Cache-Control содержит директиву max-age, то любой заголовок Expires в том же ответе игнорируется. Но огромное количество сайтов устанавливает оба этих заголовка, а Expires чаще всего ставят на дату Thu, 01 Dec 1994 16: 00: 00 GMT, чтобы контент не кэшировался. Конечно, ведь проще всего копипастнуть дату из спецификаций.

Но просто незачем это делать. Если у вас заголовок Expires с датой из прошлого, просто замените его на:

Cache-Control: no-store, private

(no-store — слишком строгая директива не записывать контент в постоянное хранилище, так что вы можете предпочесть no-cache ради лучшей производительности, например, для навигации назад/вперёд или возобновления «спящих» вкладок в браузере)

Некоторые инструменты проверки сайтов посоветуют добавить заголовок X-Frame-Options со значением ‘SAMEORIGIN’. Он говорит браузерам, что вы отказываетесь отдавать контент во фрейм на другом сайте: как правило, это хорошая защита от кликджекинга. Но того же эффекта можно достигнуть другим заголовком с более последовательной поддержкой и более надёжным поведением:

Content-Security-Policy: frame-ancestors 'self'

Здесь есть дополнительная выгода, потому что заголовок CSP вы всё равно должны отдавать по иным причинам (о них позже). Вероятно, в наше время можно обойтись без X-Frame-Options.

Наконец, ещё в IE9 компания Microsoft представила «режим совместимости», который отображал страницу с помощью движка IE8 или IE7. Даже в нормальном режиме браузер думал, что для правильного рендеринга может понадобиться более ранняя версия движка. Эти эвристики не всегда работали корректно, и разработчики могли переопределить их, используя заголовок или метатег X-UA-Compatible. Фактически, это стало стандартной частью многих фреймворков вроде Bootstrap. Сейчас этот заголовок практически бесполезен: очень мала доля браузеров, которые понимают его. И если вы активно поддерживаете сайт, то очень маловероятно, что на нём используются технологии, которые запустят режим совместимости.

Данные для отладки (X-ASPNet-Version, X-Cache)

X-Cache: HIT
X-Request-ID: 45a336c7-1bd5-4a06-9647-c5aab6d5facf
X-ASPNet-Version: 3.2.32
X-AMZN-RequestID: 0d6e39e2-4ecb-11e8-9c2d-fa7ae01bbebc

На самом деле, эти «неизвестные» заголовки не выдумали разработчики. Обычно это артефакты использования определённых серверных фреймворков, софта или сервисов конкретных поставщиков (например, последний заголовок типичен для AWS).

Заголовок X-Cache добавляет Fastly (и другие CDN), вместе с другими специфичными хедерами, такими как X-Cache-Hits и X-Served-By. Когда отладка включена, то добавляется ещё больше, например, Fastly-Debug-Path и Fastly-Debug-TTL.

Эти заголовки не распознаются ни одним браузером, а их удаление совершенно не отразится на отображении страниц. Но поскольку они могут предоставить вам, разработчику, полезную информацию, то можете их сохранить.

Недоразумения (Pragma)

Pragma: no-cache

Тем не менее его настолько широко используют в качестве заголовка ответа, что некоторые браузеры даже распознают его и в этом контексте. Но сегодня практически нулевая вероятность, что кто-то понимает Pragma в контексте ответа, но не понимает Cache-Control. Если хотите запретить кэширование, всё что вам нужно — это Cache-Control: no-store, private.

Не-браузеры (X-Robots-Tag)

Баги

Удаление заголовков на edge-сервере CDN

unset resp.http.Server;
unset resp.http.X-Powered-By;
unset resp.http.X-Generator;

if (!req.http.Cookie:debug && !req.http.Debug) {
unset resp.http.X-Amzn-RequestID;
unset resp.http.X-Cache;
}

В следующей статье я расскажу о лучших практиках для действительно нужных заголовков и как активировать их на edge-сервере CDN.

Заголовки в HTML: назначение HTML заголовков и их использование в документах

Привет, посетитель сайта ZametkiNaPolyah.ru! Этой записью мы продолжаем рубрику: Верстка сайтов, в которой есть раздел HTML. Эта запись поможет вам разобраться с делением страниц сайта на разделы при помощи HTML заголовков. Если вы заботитесь о том, чтобы информация на вашем сайте была доступна для посетителей и была представлена удобно, то вам просто необходимо делить большие документы на разделы при помощи специальных HTML тэгов, которые создают заголовки. Кроме того, использование заголовков помогает продвигать сайта, так как поисковые системы считают текст внутри заголовка более важным, чем текст абзаца.

Заголовки в HTML: назначение HTML заголовков и их использование в документах

В этой записи мы поговорим о применение и назначение HTML заголовков. Рассмотрим виды HTML заголовков и их отличия, разберемся с техническими особенностями заголовков и в завершении публикации попробуем самостоятельно разбить HTML документ на разделы при помощи заголовков.

Для чего нужны HTML заголовки

Содержание статьи:

HTML документ в общем случае представляет собой каким-либо образом отформатированный и структурированный текст. Любой документ, каким бы он ни был имеет заголовки (не путать с названием документа). Заголовки в HTML, как и в любом другом документе, делят текст на разделы, а разделы в свою очередь состоят из абзацев (ранее мы уже говорили про параграфы и абзацы в HTML).

Чтобы было проще понять для чего нужны заголовки в HTML, давайте сравним HTML страницу с книгой. Книга может состоять из частей, название той или иной части – это заголовок. Части в свою очередь делятся на главы, название главы – это тоже заголовок, но уже не такой значимый. Главное назначение частей и глав в книги – разделить ее на крупные разделы, в которых есть какая-то логическая связь.

Так и в HTML документе: заголовки используются, чтобы разделить его на большие фрагменты, в которых рассказывается о той или иной части темы, описываемой в данном документе. SEO оптимизаторы используют заголовки для продвижения сайтов, комбинируя тем или иным образом ключевые слова, по которым идет продвижение, в тексте HTML заголовка, так как поисковые системы считают текст внутри заголовка более важным, чем текст внутри абзацев, даже если слова выделены специальными HTML тэгами или HTML тэгами непосредственного форматирования текста.

Итак, подведем итог всему вышесказанному. HTML заголовки используются для того, чтобы разбить HTML документ на части, а также HTML заголовки используются SEO оптимизаторами для того, чтобы акцентировать внимание поисковой системы на тех или иных словах, по которым продвигается сайт.

Виды HTML заголовков

Аналогия HTML заголовков с главами и частями в книге довольно неплохо демонстрирует деление HTML заголовков на виды или уровни. Всего насчитывается шесть уровней HTML заголовков: <h2>, <h3>, <h4>, <h5>, <h5>, <h6>. Заголовок первого уровня считается самым важным в HTML, поэтому браузер отображает его самым крупным и жирным шрифтом, соответственно, заголовок <h6> будет отображен, как самый маленький.

Правда, стили отображение HTML заголовков можно изменить при помощи CSS или HTML атрибутов и сделать так, что заголовок <h2> будет отображаться шрифтом, размер которого меньше, чем размер шрифта <h6>.

SEO оптимизаторы рекомендуют использовать один единственный заголовок <h2> в документе, и не более четырех HTML заголовков второго уровня, а дальше уже вам придется исходить из объема текста и необходимости его деления на разделы (ни разу не видел ни одного сайта, где бы использовались HTML заголовки пятого и шестого уровней).

В принципе, утверждение сверху логично: заголовок первого уровня на странице должен быть один (вы же никогда не встречали книгу, на первой странице которой написано название, а потом, где-нибудь посреди повествование автор берет и переименовывает книгу, ведь нет?). Часто HTML заголовок первого уровня совпадает с названием HTML документа, которое указывается в тэге <title>. Заголовков второго уровня может быть несколько, так как ими мы делим документ на части, а заголовков третьего уровня может быть еще больше, так как ими мы делим HTML документ на главы.

Когда вы используете HTML заголовки, не исходи из чужих рекомендаций. Просто оцените текст HTML документа, подумайте, как вы его можете разбить на части и сколько частей будет в документе, каждая часть – это заголовок второго уровня. А затем оцените каждую часть в отдельности, разбив ее на логические разделы, каждому разделу дайте имя при помощи HTML заголовка третьего уровня.

Такой подход обеспечить вам две вещи: вы будете задумываться о логической структуре текста и, соответственно, будете писать его последовательно, а посетителям вашего сайта будет проще ориентироваться и понимать, о чем ваш текст, благодаря продуманной структуре, которая выделяется при помощи HTML заголовков.

Технические особенности заголовков в HTML

Давайте теперь перечислим особенности HTML заголовков. Первое, что стоит отметить – заголовки относятся к блочными HTML элементам. Второе – все заголовки представляют собой парные HTML тэги. Для HTML заголовков доступны универсальные HTML атрибуты и атрибуты событий.

Так же у HTML заголовков есть уникальный атрибут align. Браузер всегда добавляет пустое пространство над и под HTML заголовками, если, конечно, данное правило не отменить при помощи CSS стилей. Пожалуй, это всё, что нужно знать про HTML заголовки и о том, как их отображают браузеры.

Пример использования HTML заголовков

Мы довольно подробно описали как работают HTML заголовки, их назначение и особенности. Теперь давайте посмотрим примеры HTML заголовков и того, как их обработает браузер. Пример будет сразу с использование выравнивания текста внутри HTML заголовков (более подробно про выравнивание может прочитать в статье HTML абзацы, ссылку на которую я давал ранее). Откройте любой редактор, можно даже Блокнот (но есть множество бесплатных альтернатив: HTML редактор Notepad++, CSS редактор Brackets, PHP редактор IDE NetBeans, позволю порекомендовать один платный JavaScript редактор Sublime Text 3, все они имеют гораздо более широкий функционал и намного удобнее, чем Блокнот), и сохраните код ниже, назвав файл index.html:

<!DOCTYPE html> <html lang=»ru-RU»> <head> <meta charset=»UTF-8″> <title>HTML заголовки и примеры их использования</title> <link rel=»stylesheet» type=»text/css» href=»style.css» /> </head> <body> <h2>HTML заголовок первого уровня</h2> <p>Для сравнения добавим текст внутри HTML параграфа, чтобы было заметно, как браузер выделяет HTML заголовки разного уровня. А также для того, чтобы были видны вертикальные отступы, которые создает браузер, встречая HTML заголовок</p> <h3>HTML заголовок второго уровня</h3> <h4>HTML заголовок третьего уровня</h4> <h5 align=»center»>HTML заголовок четвертого уровня</h5> <p>Для сравнения добавим текст внутри HTML параграфа, чтобы было заметно, как браузер выделяет HTML заголовки разного уровня. А также для того, чтобы были видны вертикальные отступы, которые создает браузер, встречая HTML заголовок</p> <h5 align=»right»>HTML заголовок пятого уровня</h5> <h6 align=»left»>HTML заголовок шестго уровня</h6> <p>Для сравнения добавим текст внутри HTML параграфа, чтобы было заметно, как браузер выделяет HTML заголовки разного уровня. А также для того, чтобы были видны вертикальные отступы, которые создает браузер, встречая HTML заголовок</p> </body> </html>

Не забывайте использовать пробельные символы для форматирования HTML кода. Откройте получившийся файл в браузере, если вы сделали всё, как в примере, то увидите примерно следующую HTML страницу, созданную браузером:

Пример отображения HTML заголовков на странице в браузере

Здесь мы специально подсветили элемент HTML заголовка h5: светло-жёлтая область – это как раз те самые отступы, которые создает браузер, когда встречает HTML заголовки. На рисунке также видно, как изменяется способ отображения HTML заголовков в зависимости от уровня. И вы можете увидеть, как браузер выравнивает текст внутри HTML заголовка в зависимости от значения атрибута align.

Подведем итого всему, что было сказано про HTML заголовки:

1. HTML заголовки используются для деления документа на разделы.
2. В HTML шесть уровней заголовков, которые отображаются в соответствии их значимости.
3. HTML заголовки – это блочные элементы.
4. Тэги HTML заголовков парные.
5. Для HTML заголовков доступны все универсальные атрибуты и атрибуты событий.
6. Браузер создает вертикальные отступы от HTML заголовков.
7. HTML заголовки очень любят использовать SEO оптимизаторы для продвижения сайтов.