Как настроить и проверить название сайта в поиске Google

Над заголовком результата Google может показывать короткую подпись источника: бренд, название проекта либо домен. Это site name — название сайта, а не Title конкретной страницы. Владелец не вводит его в отдельном поле Search Console и не может вручную закрепить итоговый вариант. Он передает предпочтение через разметку WebSite на главной, согласует остальные сигналы и обеспечивает доступ Google к правильной версии главной страницы.

Типичная проблема выглядит просто: компания провела ребрендинг, но в выдаче осталось старое имя; вместо бренда показывается домен; у новостного поддомена появляется название основного сайта; команда пытается задать отдельную подпись каталогу в папке. Причины различаются, поэтому добавление еще одного JSON-LD-блока вслепую часто только создает противоречие.

Google формирует название автоматически, учитывая WebSite, og:site_name, Title, заголовки и другой текст главной, а также внешние упоминания. Официальная документация называет структурированные данные наиболее важным способом указать предпочтение, но не гарантирует их буквальный выбор. Если уверенности недостаточно, система может показать альтернативу, домен или поддомен.

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

Чем название сайта отличается от Title и favicon

Название сайта описывает источник результата целиком. Title link относится к конкретному URL и помогает понять содержание страницы. Поэтому для статьи результат может показать site name «Пример», а ниже заголовок «Как выбрать велосипед». Изменение <title> статьи не является способом поменять подпись всего сайта.

Favicon — соседний визуальный элемент, но у него отдельные требования и жизненный цикл. Правильная иконка не исправляет неверное название, а WebSite/name не заменяет файл favicon. Проверяйте элементы раздельно; требования к значку разобраны в материале о favicon.

Хлебные крошки и отображаемый адрес также не равны site name. Они описывают положение страницы и URL. Если в выдаче неверная навигационная цепочка, нужно проверять структуру и BreadcrumbList; если переписан Title — источники title link. Диагноз начинается с точного названия элемента на скриншоте.

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

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

Внутренний термин команды тоже важен. Если сотрудник говорит «неправильный заголовок сайта», в задаче приложите размеченный скриншот и подпишите site name, title link, URL и favicon. Такая карточка предотвращает ситуацию, когда разработчик правит Title десяти страниц, хотя проблемный сигнал находится только на главной.

Для каких доменов и поддоменов оно поддерживается

Google определяет сайт для этой функции на уровне домена или поддомена. Поддерживается главная https://example.com/ и главная самостоятельного поддомена вроде https://news.example.com/. Папка https://example.com/news/ не получает отдельное site name, даже если воспринимается редакцией как самостоятельный раздел.

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

Разметка WebSite должна находиться на корневой главной соответствующего домена или поддомена. Ее не нужно копировать на каждую статью. Размещение только на /about/, /ru/ или странице раздела не превращает этот адрес в допустимую главную для site name.

Главная должна быть доступна Google: без блокировки robots.txt, noindex и обязательной авторизации. Если корневой URL перенаправляет, робот должен получить доступ к конечной странице. Ошибки закрытия страниц разбираются в материале про noindex и nofollow.

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

Как выбрать основное и альтернативное название

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

Регистр и написание берите из бренд-стандарта. Не чередуйте «МойСайт», «Мой сайт» и «МОЙСАЙТ» между логотипом, H1 и разметкой. Если бренд использует латиницу, не добавляйте транслитерацию как основное имя только ради ключевой фразы. Согласованность важнее насыщения запросами.

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

Если предпочтительное имя не выбирается, официальная инструкция советует сначала дать осмысленное alternateName. В качестве резервного варианта можно указать домен или поддомен в нижнем регистре. Установка домена как основного name рассматривается как последний обходной вариант, а не стандарт для каждого проекта.

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

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

Как разметить WebSite, name и alternateName

На главной создайте один узел Schema.org типа WebSite. Обязательные для site name свойства — name и url. URL указывает на каноническую главную домена или поддомена. Рекомендуемое alternateName принимает строку или массив реальных альтернатив.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Северный свет",
  "alternateName": ["СС", "severny-svet.ru"],
  "url": "https://severny-svet.ru/"
}
</script>

Если узел WebSite уже существует, добавьте свойства в него, а не создавайте второй независимый блок. Два узла с разными name и url оставляют системе неясный выбор. Использование @id помогает связать один и тот же объект с Organization и другими узлами, но для этой задачи важно прежде всего отсутствие конкурирующих WebSite.

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

Site name не поддерживается в Rich Results Test. Google рекомендует проверить синтаксис, например, Schema Markup Validator, а затем использовать URL Inspection, чтобы увидеть доступность и отрендеренную главную. Отсутствие ошибки в валидаторе означает корректный синтаксис, но не гарантирует выбранную подпись.

Не добавляйте WebSite на каждую внутреннюю страницу «для усиления». Официальное требование размещает его на главной сайта. Остальные страницы получают собственные типы и ссылаются на общий сайт при необходимости; основы реализации собраны в руководстве по Schema.org.

Генерируйте JSON сериализатором, а не соединением строк. Кавычка, перенос или амперсанд в названии не должны ломать документ. Автоматический тест разбирает каждый JSON-LD-блок как JSON, находит узлы типа WebSite и проверяет число, типы свойств и абсолютный HTTPS-адрес главной.

Какие сигналы главной страницы согласовать

Проверьте видимый логотип или текстовый бренд в header, основной заголовок, Title главной, og:site_name и узел WebSite. Они не обязаны повторяться посимвольно: Title может содержать описание, а H1 — ценностное предложение. Но название источника должно иметь одну форму и не конкурировать с прежним брендом или названием холдинга.

Open Graph используется для превью в социальных сетях, но og:site_name также входит в сигналы, которые Google может учитывать. Не меняйте его отдельно от WebSite. Как формируется социальная карточка, описано в статье про Open Graph.

Текст главной должен ясно показывать, чей это сайт. Если логотип является изображением без alt, H1 описывает только услугу, Title начинается с общего запроса, а бренд спрятан в footer, структурированные данные оказываются единственным явным сигналом. Добавьте понятное видимое название не ради робота, а ради посетителя.

Организация и сайт — разные сущности. У компании может быть корпоративный домен, медиа и сервис с собственными названиями. Для site name узел WebSite описывает конкретный сайт. Не подставляйте полное юридическое имя Organization автоматически, если пользователь знает продукт под другим брендом.

Проверьте шаблон после A/B-теста, геоперсонализации и языкового переключения. Робот и новый посетитель должны видеть согласованное имя без cookie. Если сервер иногда отдает один бренд, а JavaScript затем заменяет его другим, отрендеренные сигналы нестабильны.

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

Как проверить www, HTTPS, canonical и редиректы

Перечислите все известные варианты главной: HTTP и HTTPS, www и без www, адрес с /index.html, параметры, завершающий слеш. Каждый технический дубль либо перенаправляется на выбранную главную, либо при доступности содержит те же согласованные данные. Google отдельно рекомендует одинаковую разметку на дублях главной, а не только на canonical.

Проверьте цепочку редиректов снаружи. HTTP должен вести к правильному HTTPS-хосту, старый домен — к новой главной, а не на ошибку или промежуточную заглушку. Конечная страница отвечает 200 и доступна Googlebot. Длинные цепочки задерживают обработку и усложняют диагностику.

Canonical главной совпадает со свойством WebSite.url. Если разметка указывает без www, а canonical и внутренние ссылки — на www, система получает конфликт. Способы выбора главной версии описаны в материале про canonical.

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

Внутренние ссылки на логотипе, canonical, sitemap и hreflang должны вести к выбранной главной. Несогласованный одинокий URL редко объясняет все, но массовый старый шаблон способен поддерживать прежнюю версию. Аудитируйте источники системно, а не заменяйте одну строку JSON.

Проверяйте ответы для обычного Googlebot без специальных обходов защиты. Если CDN отдает роботу challenge, заглушку региона или устаревший кеш, разметка в браузере владельца ничего не доказывает. Сопоставьте исходный HTML с разных точек и время обновления кеша, прежде чем ждать переобработку.

Как работать с поддоменами, папками и языками

Самостоятельный поддомен может иметь свое site name, если у него есть корневая главная и собственная разметка WebSite. Например, news.example.com может передать имя редакционного проекта. Если разметки на главной поддомена нет, Google может использовать название доменного сайта как запасной вариант.

Не задавайте отдельное имя каждому техническому поддомену: CDN, checkout, static или авторизация не становятся брендами только из-за адреса. Сначала решите, появляется ли их контент как самостоятельный источник в поиске и предназначен ли он для индексации. Часто правильное действие — каноникализация или закрытие служебной области, а не новый WebSite.

Папка языка /ru/ или раздел /blog/ не поддерживает отдельное site name. Она может иметь локализованный Title и видимое название раздела, но подпись источника остается на уровне домена. Архитектуру языковых страниц согласуйте с hreflang, не пытаясь решить ее через alternateName.

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

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

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

Как диагностировать неверную подпись в Google

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

Получите исходный HTML главной и отрендеренную версию через URL Inspection. Найдите все узлы WebSite, их name, alternateName и url. Затем проверьте Title, H1, логотип, og:site_name, canonical, robots и ответ сервера. Не ограничивайтесь просмотром DOM в своем авторизованном браузере.

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

Если остается старое имя, найдите его на главной и технических дублях. Оно может жить в старом JSON-LD, OG, Title, изображении с alt, мобильном шаблоне или редирект-цели. Внешние упоминания не меняются мгновенно, поэтому после очистки собственных сигналов системе потребуется повторный обход и обработка.

Если проблема только у внутренних страниц, а главная уже показывает правильную подпись, дайте Google время переобойти их. Не копируйте WebSite на весь сайт. Для понимания состояния используйте Google Search Console, но помните: отдельного отчета с кнопкой выбора site name нет.

Храните сырой результат каждой проверки: HTML, выбранный canonical, конечный URL редиректа, извлеченный узел WebSite и фактическую подпись в наблюдаемой выдаче. Сводная таблица без доказательств быстро устаревает. При следующем инциденте можно сравнить версии и понять, изменился сайт или только отображение.

Как выпускать изменение и ждать переобработки

Подготовьте изменение на одной канонической модели данных. Из нее формируются WebSite, OG и видимый бренд. До релиза проверьте все варианты главной, JSON-синтаксис, редиректы, canonical и доступ без cookie. Если ребрендинг затрагивает домен, используйте отдельный план миграции.

После публикации запросите главную через внешний клиент и URL Inspection. Убедитесь, что Google видит новый текст и разметку. Затем можно запросить переобход главной. Это запрос на обработку, а не обязательство изменить подпись в определенный срок.

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

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

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

План отката нужен даже для небольшой разметки. Сохраните прежний корректный узел, версию шаблона и список измененных вариантов главной. Если релиз породил два WebSite или неверный URL, команда быстро возвращает согласованную модель, не меняя одновременно редиректы и видимый бренд.

Числовой кейс ребрендинга

Компания сменила название «Старый Дом» на «Теплый Дом», сохранив домен. Для контроля подготовили фиксированную выборку из 200 результатов: 80 URL услуг, 60 статей, 40 категорий и 20 справочных страниц. Проверка суммы: 80 + 60 + 40 + 20 = 200.

До исправления 124 результата показывали новое имя, 46 — домен, 20 — старый бренд, 10 — общее название холдинга. Категории взаимоисключающие и дают 124 + 46 + 20 + 10 = 200. Доля предпочтительного имени составляла 124 / 200 × 100 = 62%.

Аудит нашел 12 доступных вариантов главной и шаблонов: семь содержали новое имя согласованно, три отдавали старый og:site_name, два не имели name в существующем WebSite. Семь + три + два = 12. Кроме того, в двух JSON-LD-блоках одновременно существовали разные узлы WebSite.

Команда оставила один WebSite с name «Теплый Дом», alternateName из общепринятого сокращения и домена в нижнем регистре, согласовала OG и видимый header. Все технические дубли получили ту же разметку до редиректа, а цепочки свели к одной HTTPS-главной. Старое имя осталось только на отдельной странице истории бренда, где контекст не представлял его текущим названием сайта.

После переобхода повторили те же 200 наблюдений: 172 результата показывали предпочтительное имя, 20 — домен, восемь — старый бренд, общее имя холдинга не встретилось. Сумма 172 + 20 + 8 + 0 = 200. Доля нового имени стала 172 / 200 = 86%, наблюдаемое изменение — 86 − 62 = 24 процентных пункта.

Это сравнение не доказало, что каждый сдвиг вызван только разметкой: между датами Google переобрабатывал страницы и внешние сигналы, а состав результатов мог меняться. Оно подтвердило согласованность собственной реализации и дало измеримую картину. Оставшиеся 28 случаев продолжили наблюдать, не меняя name ежедневно.

Как контролировать название после запуска

В техническую регрессию главной добавьте проверки: ровно один WebSite, непустой name, допустимый alternateName, url равен canonical, значение совпадает с настройкой бренда, страница отвечает 200 после редиректов. Отдельно проверяйте HTTP, www и прежний домен.

После каждого изменения header, CMS, SEO-плагина или локализации просматривайте исходный и отрендеренный HTML. Плагины часто добавляют собственный WebSite поверх серверного. Автоматический тест должен находить количество узлов и конфликтующие name до публикации.

Раз в месяц сохраняйте небольшую ручную выборку результатов по главной, важным внутренним URL и самостоятельным поддоменам. Записывайте дату и вид подписи. Не используйте site name как KPI ранжирования: цель контроля — правильное представление источника, а не гарантированный рост кликов.

Выборка должна оставаться сопоставимой: одинаковые типы страниц, язык, страна и устройство. Если URL перестал появляться по прежнему запросу, отметьте отсутствие отдельно и не заменяйте его удобным результатом. Иначе рост доли правильного имени может объясняться изменением состава наблюдений, а не обновлением подписи.

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

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

Храните владельца бренд-настройки и журнал изменений. Ребрендинг, новый домен, выделение поддомена и смена CMS должны обновлять один источник данных, а не пять независимых полей. Тогда диагностика сводится к проверке доставки, а не к поиску случайно забытого старого имени.

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

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

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

Главный вывод

Название сайта в Google — автоматически выбранная подпись источника, отдельная от Title, favicon и хлебных крошек. Владелец задает предпочтение одним узлом WebSite на доступной корневой главной, передает name, canonical url и настоящие alternateName, затем согласует видимый бренд, OG, Title, дубли и редиректы. Папка не получает отдельное site name, а самостоятельный поддомен может получить его через собственную главную. Валидная разметка и переобход не гарантируют конкретный вариант или срок, поэтому результат оценивают по фиксированной выборке и не меняют сигналы каждый день.