Проверьте, готов ли сайт к Search Console
Прежде чем разбираться, как подключить Google Search Console к сайту и читать данные, проверьте несколько базовых вещей. Вам нужен доступ к самому сайту, к его DNS или хостингу, а также Google-аккаунт, который останется у проекта. Если что-то из этого находится в чужой почте, сначала исправьте именно это.
Сайт должен уже быть доступен в открытом домене. Search Console — не игрушка для staging-среды, и она мало поможет, если сайт всё ещё спрятан за паролем или доступен только по тестовому URL. Если это клиентский сайт, выясните, кто владеет доменом, кто может редактировать DNS и кто утверждает изменения. Звучит бюрократично. Но экономит часы.
Есть одно практическое правило: человек, который настраивает всё это, должен иметь возможность внести небольшое изменение без трёхдневного ожидания. Если вы не можете добавить TXT-запись, загрузить файл или вставить тег на сайт, вы упрётесь в проверку прав. На этом многие настройки тихо и заканчиваются.
Если на сайте уже есть средства безопасности сайта, отметьте их до начала работы. Строгий фаервол, плагин кэширования или перенаправление на HTTPS могут помешать проверке, если вы не знаете, как именно ведёт себя сайт. Это не повод останавливаться. Это повод быть внимательнее.
Добавьте правильный тип свойства
В Search Console есть два основных варианта: свойство домена и свойство с префиксом URL. Это не косметический выбор. Он влияет на то, что Google объединяет в отчётах и что вы сможете увидеть дальше.
Свойство домена охватывает все версии домена: http, https, www, без www и поддомены, если они относятся к тому же имени домена. Если у сайта гуляет несколько версий, это обычно более удобный вариант. Одно свойство. Один взгляд. Меньше путаницы.
Свойство с префиксом URL отслеживает только одну конкретную версию, например https://www.example.com/. Это может быть полезно, если вы управляете только одним разделом большого сайта или если технический доступ ограничен. Небольшая агентская команда может выбрать его ради быстрого запуска, но компромисс очевиден: данных меньше, и для полного обзора может понадобиться несколько свойств.
Смотрите на реальную структуру сайта, а не на макет дизайна. Корпоративный сайт часто включает основной домен, блог в подпапке и, возможно, staging-поддомен, который никто не должен путать с рабочей версией. Свойство домена упрощает этот хаос. Свойство с префиксом URL тоже может подойти, но только если вы точно знаете, какую версию хотите отслеживать.
Выбирайте ту версию, по которой пользователи реально попадают на сайт. Если посетители открывают и https://example.com, и https://www.example.com, а обе версии редиректят на один канонический адрес, выбирайте свойство, которое соответствует финальной версии. Две одинаковые по содержанию версии могут потом сильно запутать анализ.
Подтвердите права, не сломав сайт
Подтверждение прав показывает Google, что вы контролируете сайт. Обычно используют DNS-запись, загрузку HTML-файла, метатег, Google Analytics и Google Tag Manager. Для свойства домена DNS обычно самый надёжный вариант, потому что он находится вне кода сайта. Это важно, когда разработчики не любят трогать шаблоны.
Если вы можете редактировать DNS, выберите этот способ первым. Он простой и не зависит от того, останется ли плагин активным. Если вы не уверены, как подтвердить права, заранее посмотрите, как подтвердить права в Google Search Console, чтобы выбрать метод, который подходит именно вашему доступу. Добавьте TXT-запись ровно так, как показывает Google, подождите распространения и затем проверьте подтверждение. DNS может обновляться не сразу. Иногда быстро, иногда нет.
Загрузка HTML-файла подходит для некоторых сайтов, особенно если вы можете положить файл в корень сайта через хостинг или FTP. Проблема в поддержке. Если кто-то изменит процесс деплоя или почистит старые файлы, файл подтверждения может исчезнуть. Тогда Search Console потеряет доверие к свойству.
Проверка через метатег удобна для команд, которые могут редактировать шапку сайта. Это часто самый простой путь на сайте с системой управления контентом, но только если вы знаете, где именно находится этот header. Не вставляйте код в случайный блок конструктора и не надейтесь на лучшее. Надежда — не способ подтверждения.
Google Analytics или Google Tag Manager тоже могут подойти, если эти инструменты уже установлены и у вас есть нужные права. Выбирайте их только тогда, когда вы доверяете текущей настройке и понимаете, кто владеет контейнером или свойством аналитики. Если тегом управляет сторонний подрядчик, вы можете создать зависимость, которую не планировали.
Безопасность важнее скорости. Если доступно несколько способов, выбирайте тот, который меньше всего рискует сломаться при редизайне или обновлении контента. Для многих команд самым спокойным вариантом остаётся DNS. Для небольшого сайта без доступа к DNS метатег может быть единственным реальным путём.
Отправьте sitemap и убедитесь, что Google видит страницы
После подтверждения свойства найдите поле для sitemap в Search Console и отправьте URL XML-карты сайта. Если вам нужно понять, как отправить sitemap в Google Search Console, проще всего ориентироваться на основной адрес карты сайта: у большинства сайтов sitemap находится по адресу /sitemap.xml, но точное расположение зависит от CMS, плагина или кастомной сборки. Проверьте сам сайт или файл robots.txt, если адрес вам уже не известен.
Не угадывайте. Неверный URL sitemap не даст полезного сигнала — только бесполезную отправку. Если у сайта несколько sitemap, начните с основного индексного файла, а он уже покажет остальные.
После отправки Search Console должна показать, может ли Google получить файл и обнаружил ли он в нём URL. Это первая проверка. Если sitemap так и не читается, это часто означает техническую блокировку, неправильный путь или проблему на сервере, которую стоит исправить до того, как вы начнёте думать о позициях.
Проверяйте сайт на индексацию косвенно — по признакам сканирования. Если в sitemap указано 200 страниц, а Search Console сообщает только о небольшой части из них как о известных, что-то не так. Причина может быть безобидной или серьёзной; понять это можно только после более глубокого анализа.
Для сайта с активной публикацией это становится частью поддержки сайта после запуска. Новые страницы должны появляться в sitemap, а старые неработающие URL — удаляться или перенаправляться. Если sitemap устарел, Search Console честно покажет эту устаревшую структуру.
Найдите первые отчёты, которые важны после настройки
Сначала откройте три отчёта: Performance, Pages и Indexing. Такой порядок удобен, потому что он отвечает на три разные вопроса. Какой поисковый трафик приходит? Какие страницы в индексе? Какие страницы исключены и почему?
Отчёт Performance показывает запросы, страницы, клики, показы, CTR и среднюю позицию. Используйте его, чтобы понимать видимость и спрос, а не только трафик. Страница может получать мало кликов, но при этом набирать много показов — и именно с этого часто начинается самая полезная работа.
Отчёт Pages показывает, какие URL проиндексированы, исключены или затронуты конкретными проблемами. Это самый быстрый способ заметить структурные ошибки. Страница со статусом “Crawled - currently not indexed” означает, что Google её увидел, но пока не включил в индекс. Это стоит проверить.
Отчёт Indexing, в зависимости от интерфейса и типа сайта, помогает понять более общую картину того, как Google видит сайт. Он отвечает на простой вопрос: что Google вообще может сохранять и показывать? Если ответ — “меньше, чем вы ожидали”, у вас уже есть место для расследования.
Не прыгайте по всем отчётам в первый день. Начните с этих трёх, сделайте заметки и сравните их ещё раз через неделю. Search Console становится полезной, когда вы видите движение, а не когда одновременно рассматриваете все пункты меню.
Читайте клики, показы, CTR и среднюю позицию без ошибок в трактовке
Клики — это переходы из Google Search. Показы — это появление в результатах поиска. CTR — доля показов, которая превратилась в клики. Средняя позиция — это среднее значение, а значит, оно может скрывать много деталей, если воспринимать его как фиксированное место в выдаче.
Страница с 1000 показов и 10 кликами не обязательно “плохая”. Возможно, она ранжируется по широким и смешанным запросам или у неё заголовок недостаточно точно совпадает с поисковым намерением. Метрика лишь подсказывает вопрос. Сама по себе она на него не отвечает.
Среднюю позицию нужно интерпретировать осторожно. Если по одному запросу страница находится на 3-м месте, а по другому — на 18-м, среднее значение может выглядеть прилично, хотя нужной аудитории страница всё равно не достаётся. Поэтому важно открывать список запросов, а не смотреть только на общий показатель. Числа без контекста вежливо врут.
Изменения CTR могут означать многое. Лучше заголовок — CTR растёт. Новый расширенный результат — CTR может как снизиться, так и вырасти. Брендовый запрос может исказить картину. Резкий рост показов тоже способен опустить процент без реальной потери качества. Не паникуйте, если изменился только один показатель.
Сайт с хорошо выстроенной платформой аналитики и мониторинга сайта может сочетать Search Console с другими данными, но у Search Console всё равно своя задача. Она показывает спрос в поиске и то, как сайт представлен в выдаче. Это не то же самое, что поведение пользователя после клика.
Используйте эти цифры вместе. Пять кликов по одному запросу с CTR 40% могут быть ценнее, чем 200 показов без кликов — всё зависит от намерения пользователя. Search Console поощряет терпение. И наказывает за ленивое чтение.
Используйте данные, чтобы находить проблемы с индексацией и видимостью
Ищите страницы, которые исключены или не проиндексированы. Затем смотрите причину. “Discovered - currently not indexed” часто означает, что Google знает о странице, но ещё не обошёл её, а “Duplicate, Google chose different canonical” означает, что Google нашёл другую версию, которую предпочитает. Это не одна и та же проблема.
Дальше найдите запросы с большим числом показов и малым числом кликов. Такой рисунок часто указывает на слабый заголовок, слишком расплывчатый сниппет или страницу, которая отвечает не на то намерение. Если карточка товара постоянно показывается по исследовательскому запросу, контент, возможно, нужно переписать или перенести на более подходящую посадочную страницу.
Страницы, теряющие видимость, стоит сравнивать с предыдущими периодами. Search Console может показывать падения по запросам или страницам, и такие падения часто указывают на одно из трёх: технические проблемы с индексацией, контент, который больше не соответствует спросу, или конкурента, перехватившего намерение. Без дополнительной проверки отчёт не скажет, что именно произошло.
Обращайте внимание на страницы, которые важны, но почти не появляются. Страница с ценами, ключевая страница услуги или недавно опубликованная статья не должны долго оставаться невидимыми. Если это происходит, проверьте внутренние ссылки, canonical-теги и включение в sitemap, прежде чем решать, что проблема в самом контенте.
Именно здесь сайт с большим объёмом публикаций, например контентный портал об инвестициях, требует регулярной проверки. На больших сайтах мелкие ошибки накапливаются очень быстро. Один сломанный шаблон может затронуть десятки URL.
Также проверьте, может ли страница вообще индексироваться технически. Теги noindex, блокировка ресурсов, ошибки canonical и цепочки редиректов способны не пустить хороший контент в поиск. Одного неправильного тега достаточно. Search Console обычно показывает подсказку, если внимательно читать причину.
Сделайте простой еженедельный ритуал проверки Search Console
Выделите одно еженедельное окно на 20–30 минут. Выберите один и тот же день каждую неделю. Проверяйте Performance, Pages и новые предупреждения по покрытию. Режим важнее случайных проверок, потому что он делает изменения заметными на стабильной базе.
Оставьте один фиксированный интервал сравнения, например последние 7 дней против предыдущих 7 дней или последние 28 дней против предыдущих 28 дней. Не меняйте окно каждый раз, когда открываете отчёт. Так тренды становится труднее интерпретировать. Search Console работает лучше, когда ваш подход скучно постоянен.
Записывайте три вещи: страницу, которая получила больше кликов, страницу, которая потеряла показы, и одну проблему, требующую действия. Этого достаточно для еженедельного журнала. Журнал из 3 пунктов полезнее, чем хаос из 30 скриншотов.
Если изменение связано с намерением контента, передайте его SEO или редакции. Если это ошибка обхода, проблема canonical или заблокированная страница — отправьте разработчикам. Если вопрос касается редиректов, sitemap или шаблонов — передайте тому, кто может поменять сайт без догадок. Короткая и понятная передача экономит время.
Некоторые команды ведут эту работу через инфраструктуру частной сети или внутреннюю административную систему, но процесс тот же: проверьте данные, зафиксируйте причину, назначьте исправление. Search Console становится привычкой только тогда, когда за следующим шагом кто-то закреплён.
Ещё одна полезная дисциплина для загруженных сайтов — сохранять примеры. Оставляйте точный запрос, страницу и диапазон дат, когда что-то меняется. Через две недели эта заметка может быть единственной причиной, по которой вы отличите реальное падение от обычного колебания.
