Коротко · SEO
Що Googlebot розповів мені про минуле мого домену
Через два місяці після запуску я вивантажив статистику сканування своєї енциклопедії рослин. У домену було минуле, Google постійно запитував файл іконки, якого не існувало, а майже третина запитів припала на копії сторінок.
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 на добу.
Було ще два менші сплески: 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.
Вільний для реєстрації не означає новий. До мене хтось, мабуть, мав на цьому домені сайт на 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 інших адрес із параметрами.
Якщо рахувати унікальні адреси, картина ще гірша. У вибірці 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.txt | 301 |
| http відповідав 200 | Одне перенаправлення на https, а браузерам вказано використовувати лише https | 301 |
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 з першого дня, навіть якщо значок уже є на сторінці.
- Не додавайте вкладки й фільтри, які не хочете бачити в пошуку, до рядка запиту. Якщо стан потрібно зберегти в адресі, розмістіть його після #.