Google Search Console — как подключить и что там смотреть

Ресурс-домен или префикс URL, семь методов подтверждения прав и какие отчёты Search Console читать первыми. Порядок подключения, который мы проходим с клиентом.

Богдан Кононенко — CEO и основатель, ApricodeБогдан Кононенко15 мин чтения
Google Search Console — как подключить и что там смотреть

Search Console — единственное место, где Google сам рассказывает, что он думает о вашем сайте. Не инструмент-гадалка, не оценка «SEO на 78 баллов», а сырые данные: по каким запросам вас показали, какие страницы Google выбросил из индекса и почему именно.

Мы подключаем Search Console каждому клиенту на старте работ, до того как что-то менять на сайте. Без него невозможно доказать, что изменения хоть что-то дали. Наш аудит индексации сайта на 556 страниц держался целиком на одном отчёте: в индексе 534, остальное отпало по объяснимым причинам. Без Search Console это был бы разговор в стиле «кажется, стало лучше».

Первое решение — тип ресурса, и оно не косметическое

Сравнение двух типов ресурса: Domain property — это example.com со всеми поддоменами (m, www) и протоколами http, https, ftp, и подтверждается он только DNS-записью; URL-prefix property — ровно введённая строка вместе с протоколом, без поддоменов, зато со всеми методами подтверждения. Лимит — 1 000 ресурсов на аккаунт, поэтому практика простая: заводить оба.ОХВАТЧто попадает в ресурс, а что нетDomain propertyURL-prefix propertyЧто вы вводитеexample.com — без протоколаhttps://example.com — ровно этастрокаПоддоменыВсе: m, www, blog — в одной картинеНи одного: поддомен — отдельныйресурсПротоколыhttp, https, ftp — вместеТолько указанный: http и https —разные ресурсыПодтверждениеТолько DNS-запись у поставщикадоменаВсе методы, включая HTML file uploadи HTML tagЗачем он вамУвидеть сайт целиком, вместе сзабытыми поддоменамиСмотреть на поддомен отдельно ицеплять другие сервисы

Search Console просит выбрать между двумя типами ресурса (property), и большинство инструкций пробегают мимо этого экрана. Зря: сменить тип потом нельзя, можно только завести второй ресурс с нуля.

Ресурс-домен (Domain property) — это example.com целиком. В справке Search Console сказано прямо: он охватывает все поддомены (m, www и прочие) и несколько протоколов — http, https, ftp. То есть мобильная версия на поддомене, старая http-версия и блог на blog.example.com сольются в одну картину.

Ресурс с префиксом URL (URL-prefix property) — это ровно то, что вы вписали, вместе с протоколом. https://example.com и http://example.com для Search Console — разные ресурсы. Поддомены не входят.

Практическое правило, которым пользуемся мы: заводите оба. Домен покажет сайт целиком, вместе с трафиком, который приходит куда-то, куда вы не смотрите. Префикс URL нужен по двум причинам: часть инструментов и связка с другими сервисами цепляются именно к нему, и только так можно смотреть на поддомен отдельно. Лимит щедрый: до 1 000 ресурсов на один аккаунт Search Console, экономить не на чем.

Данные для ресурса начинают собираться сразу, как только его кто-то добавил, ещё до подтверждения прав. Заводите ресурс сегодня, подтверждаете через неделю — неделя истории у вас уже есть. Мгновенной картины всё равно не будет: в справке Search Console пишут, что данные появляются через несколько дней.

Семь методов подтверждения — и почему для домена работает только один

Справка Search Console перечисляет семь способов доказать, что сайт ваш:

  1. HTML file upload — кладёте файл, который выдал Google, в корень сайта.
  2. HTML tag — вставляете мета-тег в <head> главной страницы.
  3. Google Analytics tracking code — если на сайте уже стоит Analytics и у вас там права редактирования.
  4. Google Tag Manager — тот же принцип, только через контейнер GTM.
  5. Google Sites — для сайтов на этой платформе.
  6. Blogger — для блогов на Blogger.
  7. Domain name provider — DNS-запись у поставщика домена.

И теперь главное. Первые шесть работают только для ресурса с префиксом URL. Для ресурса-домена Google принимает исключительно DNS: в справке это сформулировано как требование именно для Domain property, а не для URL-prefix. Логика понятна. Файл лежит на конкретном хосте, а домен — это всё пространство имён, и владение им доказывают только на уровне зоны.

Для украинских доменов это означает поход в панель регистратора — Ukraine.com.ua, Hostiq, Mirohost, Cloudflare, если вы делегировали зону туда. Запись TXT, значение с экрана Search Console, ждёте обновления зоны. С .ua и .com.ua никакой специфики нет: TXT есть TXT.

Самая частая ошибка после подтверждения — убрать запись. Верификация действует ровно до тех пор, пока Search Console видит токен. В справке об этом предупреждают отдельно: не удаляйте DNS-запись даже после того, как подтверждение прошло. То же касается мета-тега — переезд на новую тему сайта, и права слетели. Мы добавляем проверку верификации в чек-лист релиза как раз потому, что теряли её на редизайне.

Один ресурс могут подтвердить несколько человек, теми же самыми или разными способами. Разработчик через файл, маркетолог через Analytics: никто никого не вытесняет.

Кто получает доступ и в какой роли

Тут агентства ломают дрова чаще, чем где-либо. Search Console различает пять уровней:

  • Verified owner — тот, кто подтвердил права токеном. Таких может быть сколько угодно, лимита нет.
  • Delegated owner — владелец, которого назначил подтверждённый владелец, без собственного токена. Вместе с подтверждёнными владельцами их не больше 500.
  • Full User — видит все данные и может выполнять часть действий.
  • Restricted User — в основном просмотр.
  • Associate — аккаунты и сервисы, которые выполняют определённые действия от имени сайта.

Не-владельцев на ресурс — максимум 100.

Правило, от которого мы не отступаем: владельцем остаётся клиент. Подрядчик получает Full User. Причина прозаичная: подрядчик сменился — доступ забрали одним кликом, а история за 16 месяцев никуда не делась. Когда ресурс подтверждён на аккаунт агентства, бизнес теряет собственные данные вместе с контрактом.

Performance — отчёт, который отвечает на вопрос «по чему нас вообще находят»

Это главный отчёт, и читать его нужно первым.

Четыре метрики, по определению справки: Clicks — сколько раз пользователь кликнул на ваш сайт из результатов поиска; Impressions — сколько раз сайт появился в выдаче; CTR — клики, делённые на показы; Average position — средняя позиция самого высокого вашего результата.

Что нужно знать, чтобы не делать ложных выводов:

Вид по умолчанию — три месяца. Не год, не «всё время». Расширяйте диапазон руками: история доступна за 16 месяцев. Search Console хранит данные именно за такой период, поэтому и отчёты в Analytics ограничены шестнадцатью месяцами.

Свежие данные предварительные. Самые новые цифры ещё собираются и могут измениться в ближайшие часы: на графике их отмечает пунктир. Не делайте вывод о вчерашнем дне сегодня утром. Данные Search Console вообще становятся доступными через 48 часов после сбора.

Даты — по тихоокеанскому времени. Исключение одно: 24-часовой вид. Он показывает локальное время браузера и единственный даёт почасовую детализацию, точки графика в нём — это часы. Для разбора свежего падения или эффекта от публикации это самый полезный режим.

Часть запросов скрыта. Некоторые запросы выбрасывают из отчёта ради приватности, это анонимизированные запросы. В итоги графика они входят, в таблицу нет. Отсюда вечное «сумма по строкам не сходится с общей цифрой». Но и помимо анонимизированных в таблице показаны не все запросы: Search Console хранит и показывает только самые важные строки, а самый полный перечень даёт массовый экспорт данных.

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

И мелочь, которая портит отчётность: в скачанном файле прочерки и тильды из отчёта превращаются в нули. Увидели ноль в выгрузке — это может быть «нет данных», а не «ноль кликов».

Отдельно: в Search Console появился отчёт эффективности для генеративного ИИ, он показывает показы из AI Overviews и AI Mode. Доступен не всем, разворачивается на часть владельцев сайтов, данных из экспериментов Search Labs в нём нет. Если в вашем интерфейсе его ещё нет, это нормально.

Page indexing — отчёт, который объясняет, почему страницы нет в Google

Отчёт Page indexing делит страницы на Indexed и Not indexed, а пятнадцать причин второй группы раскладываются на шесть: технические сбои (Server error 5xx, Redirect error), ваши собственные запреты (robots.txt, noindex), недоступность для робота (404, 401, 403, прочие 4xx), отказ Google брать страницу (Soft 404, Crawled и Discovered - currently not indexed), каноникалы (Duplicate, Google chose different canonical than user) и копии с редиректами. Две последние группы разбирают в конце, и именно каноникалы чаще всего кусают двуязычные сайты.ПОРЯДОК РАЗБОРАNot indexed — шесть групп, а не пятнадцатьбед01Технические сбои — чинить первымиServer error (5xx); Redirect error02Вы запретили самиURL blocked by robots.txt; URL marked 'noindex'03Страница недоступна роботуNot found (404); Blocked due to unauthorized request (401); Blocked due toaccess forbidden (403); URL blocked due to other 4xx issue04Google посмотрел и не взялSoft 404; Crawled - currently not indexed; Discovered - currently not indexed05Каноникалы — боль двуязычных сайтовDuplicate, Google chose different canonical than user; Duplicate withoutuser-selected canonical06Копии и редиректы — и это нормальноAlternate page with proper canonical tag; Page with redirect

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

  • Server error (5xx), Redirect error — технические сбои, чинить первыми.
  • URL blocked by robots.txt, URL marked 'noindex' — вы сами запретили. Вопрос один: осознанно или нет.
  • Not found (404), Blocked due to unauthorized request (401), Blocked due to access forbidden (403), URL blocked due to other 4xx issue — страница недоступна роботу.
  • Soft 404 — страница отдаёт 200, а выглядит как пустая. Классика фильтров каталога без товаров.
  • Crawled - currently not indexed — Google зашёл и решил не брать. Чаще всего это про ценность контента, а не про технику.
  • Discovered - currently not indexed — нашёл адрес, но даже не сканировал. Обычно вопрос бюджета сканирования на больших сайтах.
  • Alternate page with proper canonical tag, Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user, Page with redirect — история про каноникалы и дубли.

Последние четыре — отдельный разговор. Duplicate, Google chose different canonical than user означает, что вы указали одну каноническую страницу, а Google выбрал другую. В проектах с двумя языками это случается постоянно.

Есть ещё два предупреждающих состояния среди проиндексированных: Indexed, though blocked by robots.txt и Page indexed without content. Оба означают, что страница в индексе, но Google не видит её содержимого.

У отчёта два ограничения. Примеров URL он показывает до 1 000 на проблему: для большого сайта это выборка, а не полный список. А проверка исправления (validation), которую вы запускаете кнопкой после фикса, длится примерно до двух недель. Не два дня. Планируйте соответственно.

Именно через этот отчёт мы проходим при каждом аудите: он показывает не «что плохо вообще», а конкретные адреса и конкретную причину. Дальше начинается работа: переписать каноникалы, убрать noindex, доделать тонкие страницы. Это и есть SEO-продвижение сайта в ежедневном виде, без магии.

URL Inspection — проверка одного адреса

Инструмент отвечает на два разных вопроса, и их путают.

Что в индексе сейчас. Статусы: URL is on Google, URL is on Google, but has issues, URL is not on Google, URL is an alternate version. Это снимок прошлого сканирования.

Что видит робот прямо сейчас — кнопка Test live URL. Статусы у неё другие: URL is available to Google, URL is available to Google, but has issues, URL is not available to Google. Разница принципиальная: первое — история, второе — текущее состояние страницы.

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

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

Sitemaps — три статуса, которые решают всё

Подали карту сайта — смотрите статус. Их три, и каждый означает конкретное:

  • Success — карта получена и прочитана без ошибок.
  • Has errors — карта получена, но в ней ошибки разбора. Важно: URL без ошибок всё равно встанут в очередь на сканирование, то есть это не полный отказ.
  • Couldn't fetch — Google не смог получить файл. Тут проблема на вашей стороне: адрес, доступ, отдача сервера.

Саму карту Google получает сразу, а вот сканирование перечисленных в ней адресов занимает время — подача sitemap не ускоряет индексацию, она лишь сообщает о существовании страниц.

Лимиты, с которых начинаются проблемы у больших магазинов: 50 000 URL на одну карту, 50 МБ в распакованном виде, 50 000 карт в одном индексном файле. Сам отчёт показывает максимум 1 000 поданных запросов.

Core Web Vitals и Manual actions — два отчёта, в которые смотрят реже, чем нужно

Core Web Vitals — это не лабораторный тест. Отчёт собран из полевых данных: анонимные метрики скорости от реальных пользователей, которые заходили на ваши URL. Цифры здесь не совпадают с локальным прогоном Lighthouse, и правы они, а не он.

Пороги, по которым Google делит URL:

МетрикаGoodNeeds improvementPoor
LCP≤ 2,5 с≤ 4 с> 4 с
INP≤ 200 мс≤ 500 мс> 500 мс
CLS≤ 0,1≤ 0,25> 0,25

Пустой отчёт не означает, что всё хорошо: группа URL без пороговых данных одновременно по LCP и CLS в отчёт просто не попадает. Для сайта с малым трафиком это обычная ситуация. Подробнее про сами метрики — в разборе Core Web Vitals простыми словами.

Manual actions — отчёт, в который заходят раз в квартал и надеются увидеть пустоту. Ручную санкцию Google накладывает тогда, когда живой проверяющий решил, что страницы сайта не соответствуют спам-политикам. Типы в отчёте: неестественные ссылки на сайт и с сайта, тонкий контент с малой добавленной ценностью, скрытый текст и перенасыщение ключевыми словами, клоакинг и хитрые редиректы, спам от пользователей, проблемы со структурированными данными, злоупотребление репутацией сайта.

Если санкция есть, вы исправляете причину и подаёте запрос на пересмотр. Рассмотрение занимает от нескольких дней до нескольких недель, а в делах о ссылках бывает дольше. Это не тот отчёт, который можно отложить на потом.

Читать отчёты руками — не единственный вариант

Всё, что есть в интерфейсе, доступно через Search Console API, и на определённом масштабе это становится обязательным. Мы снимаем данные собственным тулингом через сервисный аккаунт: месячные отчёты по клиентам собираются сами, а не руками из экспорта.

От этих ограничений зависит архитектура выгрузки. Один запрос к Search Analytics API отдаёт от 1 до 25 000 строк, по умолчанию 1 000. Параметр dataState определяет, какие данные вы берёте: final (финализированные, это default), all (свежие, включая предварительные) или hourly_all для почасовой разбивки. Квоты для Search Analytics: 1 200 запросов в минуту на сайт и столько же на пользователя. Для URL Inspection API отдельно: 2 000 запросов в сутки и 600 в минуту на сайт.

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

Что делать в первую неделю

Порядок, по которому мы идём на старте с новым клиентом:

  1. Завести ресурс-домен, подтвердить через DNS, запись не трогать никогда.
  2. Завести ресурс с префиксом URL для основной версии сайта.
  3. Раздать доступы: владелец — клиент, подрядчик — Full User.
  4. Подать sitemap и дождаться статуса Success.
  5. Через несколько дней открыть Page indexing и выписать все причины из группы Not indexed.
  6. Открыть Performance, поставить диапазон на максимум и посмотреть, по каким запросам вас уже показывают. Часто это совсем не те слова, под которые писался сайт.

Тогда же логично сделать ещё два подключения. Google Consent Mode для корректной аналитики под GDPR. А если у бизнеса есть активные соцсети — platform properties в Search Console, отдельный тип ресурса для аккаунтов в Instagram, TikTok, X и YouTube. Он подключается отдельно от сайта и показывает, что Google тянет в выдачу из ваших профилей.

Search Console ничего не чинит. Он показывает, где болит, и даёт доказательства, что после исправления стало лучше. Остальное — работа над сайтом, и именно с неё мы обычно начинаем.

Частые вопросы

Сколько времени нужно, чтобы Search Console начал показывать данные?

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

Нужен ли Search Console, если уже есть Google Analytics?

Да, они про разное. Analytics видит человека после того, как он зашёл на сайт. Search Console видит то, что происходило в выдаче до захода: показы, позиции, запросы. Плюс индексацию и санкции, чего в Analytics нет в принципе.

Почему Search Console показывает меньше кликов, чем Analytics?

Потому что это разные счётчики с разными правилами. Search Console считает клики из органической выдачи Google. Analytics считает сессии из всех источников и по-своему обрабатывает возвраты, редиректы и блокировщики. Расхождение нормально, тревожит только его резкое изменение.

Что делать, если отчёт показывает ноль показов и кликов?

Сначала проверить, сколько времени прошло с подключения — за несколько дней данных может ещё не быть. Дальше — Page indexing: если страниц в индексе нет, показов тоже не будет. И проверить robots.txt и noindex: статусы URL blocked by robots.txt и URL marked 'noindex' в отчёте объяснят ситуацию за минуту.

Можно ли подключить чужой сайт?

Подтвердить права без доступа к DNS, файловой системе, GTM или Analytics не выйдет — в этом и смысл верификации. Если вы делаете SEO для клиента, правильный путь один: клиент подтверждает ресурс сам и выдаёт вам доступ Full User.

Влияет ли подключение Search Console на позиции?

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

Что делать со статусом Crawled - currently not indexed?

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

Можно ли удалить ресурс из Search Console?

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

Была ли статья полезной?

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