Google Search Console — як підключити і що там дивитись

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

Богдан Кононенко — CEO і засновник, ApricodeБогдан Кононенко15 хв читання
Самописець із металевим барабаном виводить паперову стрічку, помаранчеве перо веде на ній безперервну лінію

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
Not indexed — шість груп, а не пʼятнадцять бід

Другий за важливістю і перший за кількістю неприємних відкриттів. Він ділить усі відомі 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 місяців. І пам'ятайте, що один ресурс можуть тримати підтвердженим кілька людей одночасно, ваш вихід не закриває доступ іншим власникам.

Чи була стаття корисною?

Схожі статті