Анализ логов Googlebot показывает, какие запросы подтверждённого робота попали в выбранный журнал, какие адреса он запрашивал и какие ответы зафиксировала система. По этим записям нельзя установить, что страница была отрисована, включена в индекс или показана пользователю.
Для полезного отчёта заранее определите период, уровень сбора и ожидаемые группы страниц. Затем проверьте происхождение запросов, сохраните исходные URL и отдельно подсчитайте повторные обращения, коды и время ответа. Отсутствие записи означает только отсутствие её в доступной выборке.
Что запросить у разработчика
Сначала сформулируйте рабочий вопрос. Например: обращался ли Googlebot к новым карточкам после импорта или какие параметры каталога встречаются в его запросах? Для ответа попросите журнал за согласованный период и перечень опубликованных страниц на дату проверки. В реестре отметьте языки, типы шаблонов, дату появления и ожидаемую роль адресов.
Уточните, на каком уровне записываются события: CDN, балансировщик или основной сервер. Если CDN отвечает из кеша и запрос не доходит до основного сервера, в origin-логе его не будет. При наличии нескольких источников опишите охват каждого, возможную выборочность и пропущенные промежутки. Не складывайте две записи одного запроса как два независимых визита, если удалось связать их идентификатором; при отсутствии такой связи не придумывайте объединение.
Запросите описание полей и способ экспорта. Для проверки нужны время, хост и полный путь с параметрами, метод, код ответа, User-Agent, IP источника из доверенного уровня и, если есть, идентификатор запроса. Для анализа скорости понадобятся значение, единицы и определение измеряемого интервала. Получайте только необходимые данные и храните исходные журналы в согласованном защищённом месте: параметры URL и заголовки могут содержать сведения о посетителях.
Приведите время и поля к одной схеме
Сохраните оригинальный файл и составьте рабочую копию с описанием преобразований. Уточните часовой пояс каждого источника, переходы времени и то, относится ли отметка к началу запроса или записи ответа. Для сопоставления переведите время в одну шкалу и зафиксируйте границы периода. Без этого всплеск ошибок после релиза может оказаться ошибкой сравнения часов.
Не теряйте протокол, хост, регистр пути, завершающий слеш и параметры до проверки их роли. /chairs/ и /chairs/?sort=price могут относиться к одной товарной группе, но это разные запрошенные адреса. Сохраните обе формы: исходный URL для проверки и отдельную метку группы для отчёта. Canonical не подставляйте вместо запрошенного адреса без отдельного правила и источника.
Убедитесь, что в выборку попадают нужные методы и типы ресурсов. Запрос страницы, изображения и файла sitemap отвечают на разные вопросы; HEAD не следует без объяснения смешивать с GET. При повторном экспорте удаляйте только доказанные дубликаты одного события, а не два реальных обращения к одному адресу в разное время.
Проверьте, кто сделал запрос
Строку User-Agent можно подделать. Сначала выделите кандидатов по нужному обозначению робота, затем проверьте IP по подходящей процедуре Google. Для отдельных адресов используют обратный DNS-запрос, проверку полученного доменного имени и прямой DNS-запрос: полученный IP должен совпасть с исходным. Для основного Googlebot сверяйте имя с актуальной маской Google, например crawl-*.googlebot.com или geo-crawl-*.geo.googlebot.com. Одного слова Google внутри произвольного домена недостаточно. Для массовой проверки можно использовать опубликованные Google диапазоны соответствующей категории роботов.
Не называйте любое обращение из инфраструктуры Google поисковым Googlebot: у разных роботов и запускаемых пользователем загрузчиков разные назначения. Сохраните метод, дату проверки и версию списка диапазонов. Для старого журнала учитывайте, что текущий список или DNS не всегда восстанавливает прежнее состояние. Неподтверждённые строки оставьте отдельно, а не включайте в итог как установленный обход.
При работе через прокси проверьте, действительно ли поле содержит адрес исходного клиента. Произвольный заголовок перенаправления и IP самого CDN не доказывают происхождение запроса. Техническую проверку выполняют на исходных данных с ограниченным доступом; в отчёте обычно достаточно агрегированных результатов и метода без публикации IP.
Разберите условные записи и повторные обращения
Ниже – восемь вымышленных запросов GET к магазину example.com за один короткий промежуток. Для примера считаем, что происхождение каждого уже подтверждено и все записи получены на одном уровне сбора. Время приведено в UTC, длительность – условный интервал ответа в секундах по одному определению. Это не данные клиента и не представительная выборка обхода.
| Время UTC | Запрошенный путь | HTTP | Длительность, с |
|---|---|---|---|
| 09:00 | /ru/chairs/ | 200 | 0,20 |
| 09:05 | /ru/chairs/ | 304 | 0,08 |
| 09:07 | /ru/chairs/?sort=price | 200 | 0,30 |
| 09:08 | /ru/chairs/?sort=price | 200 | 0,34 |
| 09:10 | /ru/chairs/?color=black | 200 | 0,28 |
| 09:12 | /ru/chair-a/ | 200 | 0,25 |
| 09:14 | /ru/chair-b/ | 503 | 1,20 |
| 09:16 | /ru/old-chair/ | 301 | 0,09 |
Два обращения к сортировке оставлены как два события, хотя URL совпадает. Ответ 304 не равен серверной ошибке: он сообщает, что для условного запроса версия не изменилась. Код 301 у старого адреса требует проверки конечной цели; один ответ 503 у карточки B – повод изучить доступность и журналы вокруг этого времени, а не доказательство постоянного отказа.
Сгруппируйте результаты и сохраните знаменатель
Для примера объединим события по назначению адреса, не удаляя исходные строки. В таблице указана средняя длительность только по показанным запросам; она не является скоростью загрузки страницы у посетителя или показателем TTFB. Округление до сотых выполнено после расчёта.
| Группа URL | Подтверждённые запросы | Коды | Время ответа | Период | Действие |
|---|---|---|---|---|---|
| Основная категория | 2 обращения к одному URL | 200 и 304 | Среднее 0,14 с | 09:00–09:16 UTC | Сохранить оба события; проверить реестр нужных категорий |
| Параметры категории | 3 обращения к двум URL | Три ответа 200 | Среднее 0,31 с | 09:00–09:16 UTC | Уточнить назначение сортировки и цветового отбора; оценить более длинный период |
| Карточки A и B | 2 обращения к двум URL | 200 и 503 | Среднее 0,73 с | 09:00–09:16 UTC | Исследовать ответ 503 и состояние карточки B |
| Старый адрес карточки | 1 обращение | 301 | 0,09 с | 09:00–09:16 UTC | Проверить конечный адрес и назначение перенаправления |
Проверка суммы: 2 + 3 + 2 + 1 = 8 событий. Для параметров среднее составляет (0,30 + 0,34 + 0,28) / 3, то есть около 0,31 секунды. Для карточек (0,25 + 1,20) / 2 = 0,725 секунды, или 0,73 после округления. Четыре группы и их доли описывают только этот условный фрагмент.
Для оценки охвата сопоставьте список ожидаемых опубликованных URL с уникальными запрошенными адресами за одинаковый период. Страницы без найденного обращения сохраняйте отдельными строками, а не убирайте из знаменателя. При неполном origin-логе пишите «не найдено в данном журнале», а не «робот никогда не посещал страницу».
Превратите наблюдения в проверяемые действия
В отчёте укажите цель, источник, уровень сбора, период и часовой пояс, охват хостов, метод подтверждения робота, правила группировки и известные пропуски. Приложите обезличенные примеры запросов с ошибками и укажите, кто проверит сервер, шаблон или источник ссылок. При большом числе параметров сначала разберите их назначение; отдельный материал объясняет, как ограничить технические URL фильтров.
Сравните выводы с доступным отчётом о статистике сканирования Search Console, учитывая различие источников и периодов. Для важных страниц отдельно запросите сведения об индексации: проверка большого каталога требует собственного плана и не заменяется логами. Если после исправления меняется число запросов, учтите одновременно другие изменения и не обещайте автоматического роста индексации или трафика.
Нужна помощь с вашим проектом?
Оставьте имя и телефон. Свяжусь с вами, чтобы обсудить задачу, объём работ и следующий шаг.
