Заголовки, описания и представление страницы в поиске

Мы выбрали для C основную задачу: объяснить устройство статического сайта из Markdown. Теперь нужно ясно представить этот материал до перехода и после него. Если название обещает онлайн-конвертер, а страница содержит последовательный урок о сборке библиотеки, человек может получить другой ответ, чем ожидал. Простое добавление популярных слов не устраняет такое расхождение.

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

Документ и его представление

Сниппет — блок сведений о результате поиска. В нём могут отображаться заголовок, описание, адрес и дополнительные элементы. Мы управляем исходной страницей: элементом title, метатегом description, видимым текстом и структурированными данными. Это источники для формирования результата, а не готовое изображение, которое поисковик обязан воспроизвести.

Google создаёт ссылку-заголовок автоматически, используя title, основной заголовок и другие сведения страницы и ссылок. Он рекомендует информативные названия без лишних повторов и согласование с содержимым. Ссылки-заголовки Google. Яндекс тоже описывает формирование заголовка из title и контента, с возможными различиями по запросам. Как написать title для Яндекса.

Продолжим вымышленный сценарий на https://example.com. B сохраняет старый URL, C находится по /articles/markdown-guide.html, D — по /catalog/. Примеры ниже — предлагаемые фрагменты учебной страницы. Они не показывают текущий HTML или настоящий сниппет ProfessorWeb.

Рассмотрим неудобный вариант названия C:

<title>Markdown HTML сайт создание сайта уроки Markdown</title>

Здесь есть нужные слова, но нет ясного результата. Непонятно, речь об инструменте, справочнике или учебном проекте. Повтор «Markdown» не помогает выбору. Исправление начнём с фразы, которая естественно описывает содержание:

<title>Статический сайт из Markdown: сборка и шаблоны</title>

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

Title, H1 и описание

Элемент title находится внутри head и используется браузером как название документа. H1 — видимый основной заголовок в теле страницы. Они могут различаться по подробности, сохраняя один смысл. Например, название документа уточняет этапы, а видимый заголовок остаётся привычным: «Статический сайт из Markdown».

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

Ниже два фрагмента одной C. Первый заменяет соответствующие метаданные в head, второй показывает заголовок и вступление внутри main. Остальные элементы существующей оболочки сохраняются.

<title>Статический сайт из Markdown: сборка и шаблоны</title>
<meta name="description"
      content="Как связать Markdown-исходники, общие шаблоны и постоянные адреса статического сайта: устройство проекта и разбор сборки HTML.">
<link rel="canonical"
      href="https://example.com/articles/markdown-guide.html">

<main>
  <h1>Статический сайт из Markdown</h1>
  <p>
    Рассмотрим, как Markdown-исходники превращаются в HTML-страницы,
    как общие шаблоны задают оформление и почему адрес статьи
    следует хранить отдельно от имени файла.
  </p>
</main>

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

Google может использовать метаописание, когда оно лучше представляет страницу, либо выбрать фрагмент видимого текста. Описание результата зависит от запроса. Фиксированного максимума символов для метаописания нет; отображение может сокращаться под доступное пространство. Формирование описаний Google. Поэтому правило «ровно заданное число символов» не заменяет редакционную ясность.

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

Общий шаблон и самостоятельные названия

Для библиотеки важно проверить, откуда берутся метаданные. Если все страницы получают название «Уроки программирования», изменение только C не решает общую проблему. Генератор должен использовать параметры конкретного материала и при необходимости добавлять короткое название сайта.

В Markdown-проекте можно хранить название и описание в метаданных статьи. Формирование title и H1 относится к шаблону. Не добавляйте второй видимый H1 вручную в текст, если оболочка уже выводит его. Не вставляйте теги title внутрь тела Markdown в надежде, что они заменят содержимое head.

Для B оставим предметную тему «Запросы LINQ to XML» и прежний путь /my/LINQ/linq_xml/level7/7_1.php. Если нужно уточнить описание B, оно должно рассказывать о её запросах, исходном XML и результате. Шаблонный абзац об устройстве всей библиотеки не объясняет отличие B от C.

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

При чтении готового HTML сравните страницы попарно. Есть ли у B и C собственные названия? Не потеряно ли описание при использовании другой оболочки старого урока? Не выводится ли вместо имени материала пустая строка и название сайта? Такие ошибки заметны в документе ещё до появления новых поисковых данных.

Разметка хлебных крошек

В девятом уроке мы показали видимый путь A → D → C. Для него подходит структурированная разметка BreadcrumbList: список звеньев навигации с названиями, порядком и адресами. Она описывает положение статьи и не превращает её в товар, отзыв или ответ с выдуманным рейтингом. Разметка навигации Google.

Начнём с видимого фрагмента. Он находится в теле страницы перед основным материалом:

<nav aria-label="Хлебные крошки">
  <ol>
    <li><a href="/">Главная</a></li>
    <li><a href="/catalog/">Каталог материалов</a></li>
    <li aria-current="page">Статический сайт из Markdown</li>
  </ol>
</nav>

Теперь добавим в HTML соответствующее описание в JSON-LD. Ниже полный блок для этих трёх звеньев; в собственном проекте используйте свой домен и действительные адреса:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Главная",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Каталог материалов",
      "item": "https://example.com/catalog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Статический сайт из Markdown",
      "item": "https://example.com/articles/markdown-guide.html"
    }
  ]
}
</script>

itemListElement содержит элементы в нужной последовательности. position явно задаёт номер, name — подпись, item — адрес соответствующей страницы. Последнее звено указывает на C, хотя её URL не начинается с /catalog/. Навигация описывает структуру библиотеки, а не обязана повторять все папки пути.

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

Что подтверждает разметка

Техническая корректность JSON-LD, соответствие странице и показ дополнительного элемента в поиске — отдельные наблюдения. Google требует, чтобы структурированные данные соответствовали содержанию и не вводили в заблуждение; даже успешная проверка не гарантирует расширенный результат. Общие правила структурированных данных.

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

После изменения сначала подтвердите опубликованный документ: нужный title, описание, один основной заголовок, прежний canonical и согласованные крошки. Затем отдельно исследуйте обработку страницы и разметки в инструментах. Инструмент проверки расширенных результатов Google помогает проверить поддерживаемые виды данных, но не является отчётом о фактическом показе пользователю.

Наконец, сравнивайте представление и показатели поиска по условиям из прошлого урока. Изменение CTR может быть связано с названием, позицией, спросом и составом результатов. Сохраните гипотезу и даты, вместо вывода «разметка повысила рейтинг». У нас получилось ясное, согласованное представление C без изменения её адреса. Такой же принцип можно использовать при росте библиотеки, если каждая новая страница имеет собственную задачу и содержательное отличие.