Перейти до змісту
Нотатки

Коротко · SEO

Що Googlebot розповів мені про минуле мого домену

Через два місяці після запуску я вивантажив статистику сканування своєї енциклопедії рослин. У домену було минуле, Google постійно запитував файл іконки, якого не існувало, а майже третина запитів припала на копії сторінок.

Макс Кірієнко
Tech Lead SEO та маркетингу · 6 хв читання

Read in English

plants.place, моя енциклопедія кімнатних рослин, запрацювала 1 серпня. Наприкінці липня в моєму списку можливих назв домен був позначений як вільний для реєстрації, тож я вирішив, що він новий. Через два місяці я вивантажив статистику сканування із Search Console і з’ясував, що це не так.

Статистику сканування легко не помітити. Вона розміщена в налаштуваннях, а не в головному меню, і Google не дає доступу до неї через API. Але це єдине місце в Search Console, де видно самі запити Googlebot за кожен день — зокрема до адрес, яких ви ніколи не створювали.

Що я вивантажив

Два файли з розподілу звіту за відповідями: запити з відповіддю 200 і запити з відповіддю 404 «Не знайдено». Щоб їх завантажити, відкрийте Налаштування → Статистика сканування → Відкрити звіт, натисніть на тип відповіді, а потім — Експортувати. У кожному вивантаженні є графік за днями від 1 серпня до 2 жовтня й таблиця з прикладами запитів. Усі наведені нижче цифри щодо сканування я перерахував за цими файлами. Перенаправлень та інших відповідей у них немає.

Перші три дні: 483 запити, далі — близько 8 на день

За 63 дні Googlebot 1 120 разів отримав нормальну відповідь 200. З них 483 припали на перші три дні: 108, 225 і 150. Після цього медіана становила 8 на день, а 17 серпня запитів не було взагалі. Середній час відповіді сервера становив близько 0,7 секунди.

Запити Googlebot до plants.place за добу з відповіддю 200 OK

1 120 запитів за 63 дні. 483 з них — за перші три дні (108, 225, 150), далі медіана 8 на добу.

Лише запити зі звичайною відповіддю 200. Відповіді 404, переадресації та інше сюди не входять. Джерело: статистика сканування Search Console для plants.place, 1 серпня – 2 жовтня 2026

Було ще два менші сплески: 65 запитів 11 серпня і 77 — 31 серпня. 9 серпня я опублікував 30 нових видів, і каталог виріс зі 103 до 133. Це може пояснювати перший сплеск. Але я не можу точно пов’язати жоден із них із конкретною подією.

Google пам’ятав сайт на WordPress, якого в мене ніколи не було

47 запитів отримали відповідь 404, і Search Console показала 39 із них як приклади. 14 вели на адреси WordPress: сторінку входу wp-login.php, стрічку категорії та стрічку автора. plants.place ніколи не працював на WordPress. Googlebot повертався до цих адрес у вісім різних днів — від 3 серпня до 19 вересня — і завжди через звичайний http.

На що Googlebot отримував 404

Із 39 відповідей 404 у вибірці: файл значка /favicon.ico — 16, адреси WordPress — 14, усе інше — 9.

39 прикладів, які показав Search Console, із 47 запитів з відповіддю 404 за два місяці. Джерело: статистика сканування Search Console для plants.place, 1 серпня – 2 жовтня 2026

Вільний для реєстрації не означає новий. До мене хтось, мабуть, мав на цьому домені сайт на WordPress, а Google досі зберігав його адреси. Я не шукав, хто це був, бо це не змінює подальших дій. Але змінює те, що варто перевірити перед запуском. Про це — наприкінці.

Інші дев’ять — це шість запитів до файла посилань для застосунків Apple, якого на сайті ніколи не було, одне оголошення, яке вже не існувало, і дві службові адреси.

Значок, який Google постійно запитував

Найбільша група відповідей 404 стосувалася значка. У вибірці Googlebot 16 разів запитував /favicon.ico і щоразу отримував 404. Значок на сайті був: невеликий SVG, записаний прямо в HTML кожної сторінки як data URI. Браузери нормально його показують. У посібнику Google щодо значків описано інший варіант — файл, який Googlebot-Image повинен мати змогу просканувати. Про значки, вбудовані в сторінку, там нічого не написано, і я не хотів ризикувати.

Найприкріше: я дізнався про це ще тижнем раніше. 26 вересня статистика сканування іншого мого невеликого сайту підказала те саме виправлення — його значок теж був лише всередині HTML. Я виправив це на всіх сайтах того проєкту й не згадав про plants.place. Урок з одного проєкту сам собою не переходить до наступного.

Майже третина сканування припала на копії

У таблиці з 874 прикладами запитів, які отримали відповідь 200, 269 (31%) вели на адреси з параметрами:

  • 216 — на вкладки «схожі рослини» на сторінках видів: ?rel=care, ?rel=family, ?rel=all. Кожна вкладка була посиланням, тому для Google це була нова адреса.
  • 42 — на форму додавання оголошення з уже вибраним видом: /market/new?p=aspidistra.
  • 11 — на інші параметри: добірки каталогу та посилання для входу.

Куди пішли 874 запити Googlebot із вибірки

605 чистих адрес, 216 копій карток видів із ?rel=, 42 копії форми оголошення з ?p=, 11 інших адрес із параметрами.

Приклади запитів із відповіддю 200 OK у Search Console за ті самі два місяці. Копії «схожих рослин» мали canonical на чисту сторінку, і Google однаково їх забирав. Джерело: статистика сканування Search Console для plants.place

Якщо рахувати унікальні адреси, картина ще гірша. У вибірці Google завантажив 163 різні копії сторінок «схожі рослини» і 121 різну сторінку виду.

Кожна копія «схожі рослини» мала канонічний тег, що вказував на чисту сторінку виду, а форму було закрито від індексації. Імовірно, це не дало копіям потрапити до індексу. Але не завадило Google їх завантажувати. За перші три дні у вибірці 183 із 400 запитів (46%) припали на копії «схожі рослини». Пізніше Google майже перестав їх чіпати — ще 33 за два місяці. Але у вересні побільшало копій форми: 27 із 230 запитів у вибірці — більше, ніж того місяця отримали копії «схожі рослини».

Чи справді це проблема для сайту такого розміру? Згідно з посібником Google щодо бюджету сканування, мабуть, ні: він насамперед стосується сайтів щонайменше з 10 000 сторінок, які змінюються щодня, або з мільйоном сторінок, які змінюються щотижня. Там також згадано сайти, де значна частка сторінок має статус «Знайдено — наразі не проіндексовано», а я не вимірював цю частку для plants.place. Я не можу довести, що копії затримали хоча б одну справжню сторінку. Але все одно це виправив. Виправлення було простим, а сайт саме подвоївся: 3 жовтня, у день виправлення, я опублікував англійські версії всіх 133 видів.

Сайт існував у двох версіях

13 із 874 запитів у вибірці отримали повну сторінку через звичайний http без перенаправлення — головна сторінка 9 разів. Ні Cloudflare, ні мій код не перенаправляли з http на https. Канонічна адреса вела на https, тож, імовірно, знову захистила індекс, але не сканування.

Що я змінив 3 жовтня

Що знайшов GooglebotЩо змінилосяВідповідь зараз
/favicon.ico → 404Файли значків: favicon.ico розміром 16, 32 і 48 пікселів, SVG, PNG розміром 96 пікселів, Apple Touch Icon і вебманіфест; посилання на них є на кожній сторінці200
Адреси WordPress → 404Одразу 410 «Видалено», і через http теж410
Вкладки «схожі рослини» в ?rel=Тепер вкладка розміщена в адресі після #, а цю частину Google ігнорує. Старі адреси з ?rel= перенаправляються на чисту сторінку301
Копії форми в ?p=Так само переніс у #p=. Форму з будь-яким параметром закрито в robots.txt301
http відповідав 200Одне перенаправлення на https, а браузерам вказано використовувати лише https301

4 жовтня я перевірив кожну відповідь на робочому сайті. Два параметри з вибірки залишилися. Добірки каталогу, наприклад «Підійде, якщо забуваєте поливати», отримали 7 із 874 запитів, а їхня канонічна адреса веде на каталог. Посилання для входу отримали 4 запити, а сторінку входу закрито від індексації.

Щодо 410: Google зазначає, що однаково обробляє всі відповіді 4xx, крім 429, тому я не очікую від неї більшого ефекту, ніж від 404. Це просто чесна відповідь — видалено назавжди — і вона нічого не коштувала.

Що далі

Це стан «до». Для стану «після» потрібне друге вивантаження, а статистику сканування не можна отримати через API, тому це доведеться зробити вручну. Я зроблю це приблизно 19 жовтня й додам сюди результати. Перевірю чотири речі: чи отримує /favicon.ico відповідь 200, чи стає менше запитів до адрес WordPress, яка частка сканування досі припадає на параметри та чи показує plants.place свій значок у видачі Google.

Заздалегідь одне застереження. Того самого дня я також переніс увесь сайт на нові адреси: англійську версію — у корінь, українську — в /ua/. Кожна стара адреса тепер відповідає перенаправленням, тому в наступному вивантаженні буде багато відповідей 301, не пов’язаних із цими виправленнями. Я розділю їх, перш ніж робити висновки.

Перевірте минуле домену перед запуском

У дослідженні plants.place я написав, що тепер зробив би це інакше. Ось що я тепер перевіряю:

  • Відкрийте статистику сканування в перший тиждень, а не на третій місяць, і перегляньте відповіді 404. Адреси, яких ви ніколи не створювали, — це історія домену.
  • Перегляньте розділ «Файли Sitemap» у Search Console. На іншому моєму сайті на домені з простроченою реєстрацією досі був файл Sitemap, який хтось надіслав за рік до того, як я зареєстрував домен.
  • Додайте файл значка за адресою /favicon.ico з першого дня, навіть якщо значок уже є на сторінці.
  • Не додавайте вкладки й фільтри, які не хочете бачити в пошуку, до рядка запиту. Якщо стан потрібно зберегти в адресі, розмістіть його після #.