SEO-метатеги для WordPress: title, description, Open Graph и slug — что действительно важно

Метатег — это служебная строка в <head> страницы, которую читают поисковый робот и мессенджер, а не ваш посетитель глазами. За формулировкой «поправить SEO» на практике почти всегда стоит работа с четырьмя вещами: <title>, <meta name="description">, Open Graph/Twitter Card для шаринга и slug с canonical. Разберём каждую по делу — какие длины реально работают, чем отличается выдача Google от Яндекса, почему WordPress транслитерирует slug так, что ссылка «не та», — и где эту рутину имеет смысл не держать в голове, а доверить генератору.

Часть I. Карта метатегов: что зачем и что давно не работает

Все метатеги объявляются в <head> HTML-документа. Их мало, и у каждого — своя аудитория (поисковый робот или мессенджер), поэтому и «чинить» их надо по-разному.

<!-- html — типичный набор <head> для страницы блога -->
<head>
  <title>SEO-метатеги для WordPress — Codestack</title>          <!-- 1 -->
  <meta name="description" content="Title, description, Open Graph и slug: что реально влияет на выдачу и шаринг."> <!-- 2 -->
  <meta name="robots" content="index, follow">                    <!-- 3 -->
  <link rel="canonical" href="https://example.test/seo-metadannyh/"> <!-- 4 -->

  <meta property="og:title" content="SEO-метатеги для WordPress">   <!-- 5 -->
  <meta property="og:description" content="Гайд по title, description, OG и slug.">
  <meta property="og:image" content="https://example.test/img/seo-og.jpg">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:title" content="SEO-метатеги для WordPress">
  <meta name="twitter:description" content="Гайд по title, description, OG и slug.">
</head>

<!-- html — типичный набор <head> для страницы блога -->
<head>
  <title>SEO-метатеги для WordPress — Codestack</title>          <!-- 1 -->
  <meta name="description" content="Title, description, Open Graph и slug: что реально влияет на выдачу и шаринг."> <!-- 2 -->
  <meta name="robots" content="index, follow">                    <!-- 3 -->
  <link rel="canonical" href="https://example.test/seo-metadannyh/"> <!-- 4 -->

  <meta property="og:title" content="SEO-метатеги для WordPress">   <!-- 5 -->
  <meta property="og:description" content="Гайд по title, description, OG и slug.">
  <meta property="og:image" content="https://example.test/img/seo-og.jpg">
  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:title" content="SEO-метатеги для WordPress">
  <meta name="twitter:description" content="Гайд по title, description, OG и slug.">
</head>

Что здесь что:

1. <title> — заголовок вкладки браузера и заголовок результата поиска. Единственный тег, который поисковики явно учитывают при ранжировании. Разбираем в Части II.
2. meta description — текст сниппета под заголовком в поиске. На позицию почти не влияет, но влияет на кликабельность. Часть III.
3. meta robots — инструкция роботу: индексировать (index) или нет (noindex), идти ли по ссылкам (follow/nofollow). Живой и важный.
4. link rel="canonical" — «правильный» адрес этой страницы, чтобы дубли не разводили вес. Часть V.
5. og:* и twitter:* — то, как ссылка выглядит при расшаривании в Telegram/ВК/X. Часть IV.

Почему метатег keywords игнорируют

Исторически <meta name="keywords"> перечислял ключевые слова страницы. Поисковики перестали его учитывать, потому что это была лёгкая ручка для спама (впихнуть в метатег всё что угодно). Google официально не использует его для ранжирования с 2009-х постов, Яндекс — тоже. Вывод: не тратьте на него время; ключевые фразы работают тогда, когда они в тексте, заголовке и title, а не в невидимом метатеге.

robots — отдельная директива, и robots.txt — не она

Не путайте два механизма:

• <meta name="robots" content="noindex"> работает на уровне страницы (робот зашёл и увидел запрет).
• файл robots.txt на корне сайта запрещает роботу заходить по URL.

Коварный случай: если страница помечена noindex, но при этом закрыта в robots.txt от обхода, робот не увидит noindex и оставит страницу в индексе по другим ссылкам. Правильно: noindex — а в robots.txt её не блокировать, чтобы робот зашёл и запрет считаетал.

Часть II. Title: коротко, с ключом в начале, под два поисковика

<title> — то, что вы видите синей строкой в поиске. Именно он даёт основную часть кликов и именно его поисковик переписывает/обрезает, если ему не нравится.

Длина: десктоп против мобильной выдачи

Google показывает примерно 50–60 символов на десктопе и меньше на мобильном — но режет не по символам, а по ширине в пикселях (~580 px), поэтому точный «запас» зависит от букв (заглавные и W/М шире, чем i/l). Ориентиры, по которым не ошибёшься:

• десктоп: держитесь в ~60 символах;
• мобильный: реально ~45–50 — иначе посреди ключа будет многоточие;
• ключевую фразу ставьте в начало — отсечка всегда с конца, и если ключ спереди, он переживёт обрезку.

Сравните (в обоих случаях ключ «php-fpm» в начале):

Хорошо:  PHP-FPM под WordPress: пул процессов и лимиты | Codestack
Плохо:   Подробное руководство по настройке PHP-FPM, который является движком для WordPress на VPS сервере

Второй вариант Google обрежет примерно до «Подробное руководство по настройке…», и ключ php-fpm окажется за отсечкой. Первый переживёт и обрезку, и просмотр на телефоне.

Google ≠ Яндекс по подаче

Два поиска режут по-разному и по-разному любят разделитель. Разница практичная:

• Google часто подставляет название сайта сам (из структуры), даже если вы его не писали в title. Поэтому дублировать бренд в каждом title вручную — иногда лишнее: проверьте, не дублируется ли он уже.
• Яндекс более охотно переписывает заголовок под запрос («Адрес страницы: …» в превью, подстановка разделителей) и сильнее опирается на то, что есть в тексте.

Отсюда — не вычитайте title «под один» поисковик; проверяйте, как он смотрится в обоих. Именно поэтому у SEO-инструментов есть переключатель поисковика (см. Инструменты).

Что не стоит делать с title

• Спам ключами. PHP-FPM WordPress PHP-FPM пул PHP настройка — зачитывается как спам, Google перепишет заголовок сам, по своему усмотрению.
• Уникальность ради уникальности в обратную сторону. Одинаковый title на пяти страницах — это «дубли», и поисковик выберет из них один канонический, а остальные сожмёт.
• Слишком короткий title. PHP-FPM — мало контекста; PHP-FPM под WordPress: лимиты и пул уже отвечает на «зачем мне это».

Часть III. Meta description: это реклама сниппета, а не SEO-рычаг

meta description напрямую позицию не поднимает. Он делает другое: определяет текст под заголовком в выдаче, а значит — сколько людей кликнут. Это рекламный текст вашего сниппета, а не техническая настройка.

Длина и структура

Норма — до ~155–160 символов для десктопа (на мобильном режется раньше). Рабочая формула, которая стабильно даёт CTR:

выгода (что я получу) + ключ (узнаю, что это про мой запрос) + CTA (что сделать).

title:       PHP-FPM под WordPress: пул процессов и лимиты
description: Как рассчитать pm.max_children под память VPS, включить Opcache и читать slow-log PHP-FPM.
             Пошаговый разбор для WordPress-админа.  (≈155 символов)

Здесь: «как рассчитать / включить / читать» = выгоды, «WordPress-админа» = релевантность и аудитория, последний оборот = мягкий CTA. Ключ (php-fpm, wordpress) присутствует естественно.

Когда Google перепишет вашу description

Даже заполненный description поисковик иногда заменяет куском из текста страницы — это нормально и не ошибка: он подстраивает сниппет под конкретный запрос пользователя. Ваша задача — написать так, чтобы в любом варианте сниппет читался. Отсюда правило: не начинайте description с воды («В этой статье расскажу про…»), потому что этот хвост первым режется и не даёт пользы.

Чего не делать

• Дублировать один description на весь сайт — признака релевантности нет, сниппеты скучные.
• Ставить description длиннее ~160 — обрезанный хвост выглядит битым.
• Спамить ключами — тошнота в description так же отталкивает, как в тексте. Про плотность ключа по тексту — это уже тема аудита контента, где норма 3–7%.

Часть IV. Open Graph и Twitter Card: как ссылка выглядит при расшаривании

Когда пост кидают в Telegram, ВК или X, мессенджер читает не title/description, а набор Open Graph (og:*) и Twitter Card тегов. Здесь другая логика длин и своя критичность — og:image.

Почему og:title ≠ <title>

Боевой <title> ужат под обрезку поисковика и содержит SEO-шум (ключ, бренд, разделители). og:title читает человек в ленте мессенджера — ему можно быть короче и «человечнее»:

<!-- html — разные заголовки для поиска и для шаринга -->
<title>PHP-FPM под WordPress: пул процессов и лимиты | Codestack</title>
<meta property="og:title" content="PHP-FPM: как настроить движок под WordPress">

<!-- html — разные заголовки для поиска и для шаринга -->
<title>PHP-FPM под WordPress: пул процессов и лимиты | Codestack</title>
<meta property="og:title" content="PHP-FPM: как настроить движок под WordPress">

Это осознанное расхождение, а не дубль «для галочки».

og:image решает кликабельность

Превью-картинка — то, что первым цепляет в ленте. Практические правила:

• размер около 1200×630 px (у X крупная карточка — summary_large_image);
• текст на картинке не должен терять смысл при сжатии превью;
• у картинки должен быть alt/осмысленность так же, как у обычных изображений — это тот же сигнал релевантности, просто в метатеге.

Отдельный вопрос про description шаринга

og:description/twitter:description не обязаны быть длиной как сниппет Google. В мессенджере их часто режут по своему лимиту, но он мягче и «терпит» хвост. Это частая путаница: один и тот же человек, правя description на сайте, не понимает, почему «для превью ссылок» можно оставить длиннее, а для поиска — нет. Коротко: для сниппета Google держите ~160, а для OG-описания это не блокер — их можно синхронизировать по смыслу, но не по длине.

Часть V. Slug и canonical: как не потерять адрес по дороге

Slug — это «хвост» адреса (example.test/php-fpm-...) и часть SEO-релевантности: ключ в URL — прямой сигнал, и WordPress его формирует сам.

WordPress сам делает slug — и умеет транслитерировать

Когда вы публикуете пост с русским заголовком «Бэкапы и восстановление без даунтайма», WordPress по умолчанию делает slug транслитерацией (кириллица латиницей):

Заголовок:  Бэкапы и восстановление без даунтайма: как не потерять WordPress
Slug WP:    bjekapy-i-vosstanovlenie-bez-dauntajma-kak-ne-poterjat-wordpress-i-umet-otkatitsja

Обратите внимание на «ловушку», которую легко пропустить: боевой URL получается совсем не таким, как вы бы написали вручную. Если у вас в карте сайта, robots или внешних ссылках прописан ожидаемый slug вида rezervnoe-kopirovanie-..., а WP отдал bjekapy-... — ссылка битая, и это неочевидно, потому что в самом WP всё «работает» (он отдаёт свой вариант). Правило: переснимайте боевые slug из фактического sitemap.xml, а не предполагайте их из заголовка. Транслитерация у разных версий/плагинов отличается, так что угадать нельзя — только считать.

Если нужен «человеческий» английский slug — задайте его вручную в поле Slug до первого сохранения (или фильтром); после публикации менять slug — это переадресация, иначе все прежние ссылки битые.

Canonical: защита от склейки дублей

Один и тот же пост WordPress умеет отдавать по нескольким адресам:

• страница и пагинация (/post/page/2/);
• с UTM-параметрами (/post/?utm_source=tg);
• (в зависимости от настроек) через архив категории.

Без canonical поисковик видит «несколько разных страниц с одинаковым содержимом» (duplicate content) и сам решает, какой адрес весовой, размывая ссылки между дублями. link rel="canonical" говорит прямо: «вот этот URL — главный, остальное — копии».

<!-- html — canonical на сам себя для основной страницы поста -->
<link rel="canonical" href="https://example.test/php-fpm-dvizhok-pod-wordpress/">

<!-- html — canonical на сам себя для основной страницы поста -->
<link rel="canonical" href="https://example.test/php-fpm-dvizhok-pod-wordpress/">

На пагинированном архиве (2-я, 3-я страница списка) canonical обычно ведёт на себя (или на первую страницу, если вы не хотите индексировать хвост) — настройка плагина решает детали; главное — не оставляйте пустой canonical, иначе дубли слипаются сами.

Slug и редиректы при переезде

Меняли адрес или переезжали на новый хост — старые URL надо переадресовать, иначе всё, на что ссылались, станет битым. Это часть отдельного процесса миграции (замена URL внутри базы), см. Миграция WordPress между серверами без простоя — там же про wp search-replace и почему нельзя менять URL «sed-ом».

Часть VI. Где это настраивается в WordPress (и почему не руками в шаблоне)

В чистом, но типичном стеке автора — WordPress + тема Kadence + плагин The SEO Framework — всё из частей II–V настраивается в полях плагина, а не правкой header.php:

• Заголовок и description — поле «Title» / «Description» в метабоксе плагина на экране редактирования поста; плагин по умолчанию собирает title из шаблона (обычно Название поста | Название сайта), и его можно переписать вручную для конкретной страницы.
• Slug — то самое поле под заголовком редактора поста, до публикации.
• Open Graph / Twitter Card — у The SEO Framework есть свои поля превью и отдельная картинка; og:image часто автоматически берётся из «миниатюры записи» (featured image) — отсюда и требование к featured image осмысленной, с alt.
• noindex / robots — чекбокс плагина на странице (например, закрыть от индекса служебные страницы или архивы меток).
• canonical — плагин генерирует сам; проверять надо, что он указывает на актуальный адрес (часть V про транслитерацию и переезд).

Почему не хардкодить

Вписать title/description в header.php или functions.php темы — потеря при обновлении темы (файл перезапишется) и невозможно вести по-странично: у Kadence общий шаблон на все посты. Метатеги по-странично живут в данных поста (метабоксы плагина) или в коде плагина/дочерней темы, а не в теле родительской темы. Если метаданные надо выдать программно (например, свой тип контента) — это фильтры плагина или шорткод-функция, а не ручная правка родительской темы; общий приём «как вынести вывод в свою функцию» разобран в Шорткоды WordPress своими руками.

Инструменты под задачу

Собирать title под мобильный отсчёт, держать description в 160 символах, не забыть og:*/twitter:* и корректный slug — это механическая, легко сбиваемая рутина: посимвольный пересчёт и сверку «что обрезалось бы в выдаче» держать в голове невозможно, а один пропущенный og:image обесценивает карточку в мессенджере. Чтобы снять эту рутину, в codestack.space есть AI SEO-генератор метаданных. Вы вставляете текст статьи и выбираете поисковик (Яндекс + Google / только Яндекс / только Google) и язык, опционально бренд и ключевые слова, — а он отдаёт связку целиком:

• SEO-оценку (что не так с текущим оформлением),
• Title и Meta Description под выбранный поисковик (с учётом разной длины),
• URL-slug,
• готовый HTML-блок Open Graph + Twitter Card,
• список рекомендаций по тексту.

Попробуйте инструмент прямо здесь, на своих данных:

Он не заменяет понимание из частей I–V: что мёртв keywords, зачем ключ в начале title и почему canonical важен на пагинации. Зато переставает быть нужной руками считать символы и подгонять описание под мобильную отсечку — это ровно то, что генератор считает за вас.

Чек-лист граблей

• Ключевая фраза не в начале `<title>` → отсекается на мобильном, теряется релевантность.
• Title длиннее ~60 символов (или description длиннее ~160) → резаный сниппет выглядит битым.
• Одинаковый description на нескольких страницах → дубли, скучные сниппеты.
• Тратите время на `keywords` → его игнорируют; ключи должны быть в тексте/title.
• Страница с `noindex` закрыта и в robots.txt → робот не увидит запрет и оставит её в индексе.
• Нет `og:image` / картинка без alt-смысла → ссылка в мессенджере серая, CTR падает.
• Думаете, что `og:description` обязан быть длиной как сниппет Google → превью допускает длиннее; синхронизируйте по смыслу, не по символам.
• Предполагаете боевой slug по-русски вместо транслитерированного → битые ссылки в карте/robots; переснимайте slug из фактического `sitemap.xml`.
• Поменяли slug после публикации без редиректа → все прежние ссылки битые.
• Пустой/кривой `canonical` на пагинации или с UTM → дубли слипаются, вес размывается.
• Вписали title/description в `header.php` родительской темы → потеря при обновлении + нет по-страничности; используйте плагин (Kadence + The SEO Framework).

Что дальше

Метатеги оформляют то, что уже есть в тексте и структуре страницы — дальше логично проверить сам контент на плотность ключа, структуру H2/H3 и читабельность (тема SEO-аудита текста, где норма плотности 3–7%), а если меняете адрес страницы или переезжаете — это отдельный процесс замены URL внутри базы, разобраный в Миграции WordPress между серверами без простоя. Если метаданные нужно отдавать программно для своего типа контента — приём в Шорткодах WordPress своими руками. А когда метатеги вы уже раздали и хотите, чтобы их увидели — карта сайта sitemap.xml и роботы разбираются в соседних статьях по эксплуатации VPS и Мониторингу.