Логи сервера для SEO: что робот действительно смог получить

Владелец сайта видит в отчёте тысячи ответов 403 и решает, что поисковик разлюбил магазин, хотя отказ выдал защитный экран. Разберём, как читать журнал, чтобы отличать реальный доступ робота от подделки и неполных данных.

Логи сервера для SEO — это проверка того, кто фактически пришёл, каким методом и что получил в ответ. User-agent лишь заявление: источник сверяют по официальной процедуре поисковика. Код ответа читают вместе с методом, слоем (origin, кеш, WAF) и цепочкой редиректов. Вывод о доступности делают только по подтверждённым событиям за полный период.

Представьте: сайт на небольшом маркетплейсе мебели, условно, в понедельник открывает в панели поисковой аналитики отчёт и видит, что за неделю «робот» запросил 48 000 страниц, из них 31 000 — с ответом 403. Владелец решает, что поисковик разлюбил магазин, и просит «починить SEO». А через два дня выясняется, что 403 отдавал не сервер, а защитный экран, который срабатывал на частые обращения с одного адреса. Робот при этом честно приходил, но получал от ворот поворот. Вся история — не про контент и не про ссылки, а про то, что в журнале записано, кто пришёл и что ему ответили.

Эта статья — про узкую задачу: научиться читать серверные логи так, чтобы отличать реальный доступ поискового робота от имитации, видеть, что именно ушло в ответ, и не строить выводы на обрезанном или перепутанном наборе строк. Речь не о том, как настроить robots.txt или выбрать CMS. Речь о методике проверки: какие поля смотреть, как сверять заявленного гостя с его поведением, где журнал врёт по своей природе и как сделать из этого рабочий объект, который сотрудник сможет использовать без вашего участия.

Запись, в которой смешаны гость, ответ и посредник

Первый источник путаницы — сама структура строки журнала. В типичной записи веб-сервера рядом стоят адрес клиента, метод, путь, код ответа, размер тела и user-agent. Выглядит как связный рассказ, но это не рассказ, а набор независимых фактов, которые совпали в одну секунду. Адрес клиента может принадлежать прокси или CDN, а не роботу. Код ответа мог сформировать WAF, балансировщик или кеш. Размер тела может быть нулевым, потому что ответ ушёл из кеша, а не потому что страница пустая.

Поэтому первое правило чтения — не склеивать поля в причинно-следственную связь раньше времени. Сначала разделяем три слоя: кто стучался (идентификация), что запрашивал (метод и путь), что получил (код, размер, заголовки, если они есть). Пока эти три слоя лежат в одной куче, любая аналитика превращается в гадание. Методика начинается с того, что мы физически раскладываем журнал на эти слои и смотрим на каждый отдельно.

Второе правило — помнить, что журнал фиксирует только то, что дошло до точки логирования. Если запрос остановил внешний фильтр до вашего сервера, в логах приложения его может не быть вовсе, а в логах фильтра он будет. Если ответ отдал кеш, в журнале origin может стоять один код, а пользователь и робот увидели другой. Это не ошибка настройки, это нормальная многослойность современного веба, и её надо учитывать в методике, а не игнорировать.

Если ваша задача — разобрать доступ поисковых роботов, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Почему user-agent — это заявление, а не удостоверение

Строка user-agent в запросе — это то, что клиент сам про себя написал. Никакой проверки в этом поле нет: любой скрипт может отправить Googlebot/2.1 и формально «стать» роботом в глазах наивного парсера. Google прямо предупреждает об этом в документации о верификации Googlebot и предлагает проверять принадлежность адреса, а не строку. Это принципиальный момент: идентификация робота — это сверка заявленного имени с фактическим источником, а не чтение одного поля.

На практике это означает, что в методике появляется шаг «сверка источника». Для Google есть официальный способ: обратное DNS-разрешение адреса и проверка, что полученное имя принадлежит домену Google, а затем прямое разрешение этого имени обратно в тот же адрес. Если цепочка не сходится — перед вами не Googlebot, чем бы он себя ни называл. Для других роботов действует тот же принцип: смотрим на официальную документацию поисковика и сверяем адрес, а не строку. Ссылка на первичный источник здесь не украшение, а рабочий инструмент: как Google рекомендует проверять Googlebot.

Отдельно стоит сказать про подделку. В условном примере выше 31 000 запросов с ответом 403 могли быть как настоящим роботом, так и чужим скриптом, который просто скопировал user-agent. Пока вы не сверили адреса, вы не знаете, чинить надо доступ для поисковика или блокировать чужой трафик. Это две разные задачи с разными действиями, и путать их дорого.

Что на самом деле значит код ответа в строке

Код ответа — второй по частоте источник неверных выводов. Кажется, что 200 — хорошо, 403 — плохо, 404 — страница удалена. В реальности код описывает результат обработки конкретного запроса в конкретном слое, и его надо читать вместе с методом и контекстом. Сводка статусов HTTP в документации MDN полезна именно тем, что напоминает: коды делятся на классы, и внутри класса поведение разное. Справочник кодов ответа MDN стоит держать под рукой, когда вы разбираете незнакомый код в журнале.

Возьмём HEAD. Робот может проверять доступность страницы методом HEAD, ожидая только заголовки. Если сервер настроен так, что HEAD отдаёт 405 или 403, а GET — 200, вы увидите в логах «робот получал отказы», хотя обычный посетитель видел страницу нормально. Это не значит, что контент недоступен, это значит, что обработчик метода ведёт себя иначе. В методике появляется обязательная колонка «метод», без неё вывод о доступности страницы неполон.

Редиректы добавляют ещё один слой. Цепочка 301 → 302 → 200 в логах выглядит как три запроса, и если считать «успешными» только строки с 200, вы занизите число обращений и не увидите, где цепочка рвётся. А рвётся она регулярно: устаревший редирект на несуществующий адрес, петля из двух правил, редирект на страницу, которую закрыл WAF. Каждый такой случай в журнале — это последовательность строк, которую надо читать как одно событие, а не как три независимых.

429 и защитный экран: когда сервер сам закрывает дверь

Код 429 «слишком много запросов» — частая причина «пропажи» робота, и он же самый неудобный для диагностики, потому что формально сервер работает, просто отказывает. В условной сцене с мебельным магазином сработал похожий механизм: защита посчитала частоту обращений с одного адреса подозрительной и начала отвечать 403. Аналогично проявляется и 429: сервер формально работает, но отказывает в обслуживании. Робот при этом не менял поведения — он приходил по расписанию, как обычно.

Разбирать такие случаи надо по времени, а не по итоговой сумме. Смотрим, в какие минуты росла частота, совпадает ли она с настройками лимитов, какие адреса попадали под ограничение. Если под ограничение попал диапазон, принадлежащий поисковику, — это вопрос к настройке защиты, а не к контенту. Если под ограничение попали чужие адреса с тем же user-agent — это, скорее всего, не робот, и трогать защиту ради них не нужно. Здесь важно не отключать фильтр целиком «ради проверки»: это открывает сайт для всего остального трафика. Правильнее — точечно проверить, какие правила срабатывают, и согласовать изменение с тем, кто отвечает за защиту.

Кеш, который ответил вместо сервера

Ещё один слой, который ломает наивное чтение, — кеширование. Если страницу отдал кеш, в журнале origin может не быть строки вообще, а в журнале кеша будет код 200 с пометкой HIT. При этом робот получил контент, но не тот, что вы только что обновили. Или наоборот: кеш хранит устаревшую версию с 404, хотя на сервере страница уже есть. В обоих случаях вывод «робот не видит страницу» может быть верным по факту и неверным по причине.

Методика требует явно фиксировать, из какого слоя взята строка. Если у вас есть доступ к журналам кеша и балансировщика — сводите их по времени и адресу запроса. Если доступа нет — хотя бы помечайте в рабочем объекте, что часть ответов могла прийти из кеша, и не делайте выводов о доступности контента только по origin-логам. Это честнее, чем строить красивую диаграмму на неполных данных.

Журнал обращений роботов: одна строка — одно проверенное событие

Теперь о том, как превратить всё это в объект, с которым можно работать. Идея простая: не пытаться анализировать сырой журнал целиком, а собрать нормализованную таблицу, где каждая строка — одно событие обращения, прошедшее проверку. Сырой лог остаётся источником, а рабочий объект — это то, что читает человек и на что опирается решение.

Поля рабочего объекта стоит выбрать так, чтобы каждое отвечало на конкретный вопрос. Ниже — примерная форма; конкретный набор зависит от вашего стека, но логика полей переносится.

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

Два эпизода, в которых методика решает исход

Первый эпизод — условный интернет-магазин садовой техники. Владелец замечает, что раздел с газонокосилками перестал появляться в поиске. Первый порыв — переписать тексты. Но в журнале видно: за две недели робот приходил на эти страницы 1 200 раз, из них 900 раз получил 301 на новый адрес, а новый адрес отвечал 404. То есть страницы существовали, но цепочка редиректов вела в никуда. Методика с полем «цепочка» сразу показывает это: 900 строк — не 900 успешных обращений, а 900 обрывов. Действие — починить редирект, а не тексты. Заодно выясняется, что часть 404 пришла из кеша, который хранил старую версию правила, — это отдельная задача для тех, кто отвечает за кеш.

Второй эпизод — условный сервис записи на приём. Здесь проблема в другом: робот получает 200, но размер тела нулевой. Смотрим метод — HEAD. Для HEAD отсутствие тела в ответе нормально: сервер должен вернуть те же заголовки, что и на GET, но без тела. Поэтому нулевой размер тела в строке HEAD сам по себе не означает, что контент недоступен; проверять надо коды и заголовки ответа на HEAD и GET. Методика с колонкой «метод» и «размер тела» показывает: 200-е строки есть, но они не несут информации. Действие — проверить, как обработчик метода формирует заголовки и тело, и согласовать изменение с разработкой. Ни в одном из эпизодов нельзя было сделать правильный вывод, глядя только на итоговый код ответа или только на user-agent.

Журнал обращений роботов: исключения и проверка условий

Любая методика проверяется на случаях, которые в неё не помещаются. Их стоит перечислить заранее, чтобы сотрудник не растерялся и не начал подгонять данные под ожидание.

Первое исключение — общий адрес. Несколько роботов или сервисов могут выходить с одного адреса, и тогда проверка источника даёт «подтверждено» для одного имени, а в журнале смешаны обращения разных гостей. В рабочем объекте появляется пометка «адрес общий, разделение по поведению», и выводы делаются осторожнее.

Второе — неполный период. Журналы ротируются, старые строки удаляются, часовой пояс мог поменяться при переезде. Если период обрезан, сумма обращений за «неделю» может быть меньше реальной, и сравнивать её с прошлой неделей нельзя. В объекте фиксируется фактический диапазон, а не желаемый.

Третье — легитимные всплески. Маркетинговая рассылка, публикация в СМИ, сезонный спрос — всё это меняет частоту обращений, и защита может отреагировать на всплеск, не связанный с роботом. Отличить одно от другого помогает сверка с календарём активностей, а не только с логами.

Четвёртое — роботы, которых вы не ждали. Новые поисковики, агрегаторы, AI-краулеры приходят со своими правилами и своими адресами. Методика не должна предполагать конечный список гостей; она должна предполагать процедуру проверки для любого заявленного имени. Пятое — расхождение между журналом приложения и журналом инфраструктуры по времени: часы на разных узлах могут отличаться, и тогда «одно событие» распадается на две строки в разных минутах. Сверка по времени — отдельный шаг, а не деталь.

Журнал обращений роботов на экране сотрудника

Рабочий объект бесполезен, если читать его умеет только автор методики. Поэтому интерфейс — это не про красоту, а про то, какие решения сотрудник может принять сам. Минимальный набор экранов выглядит так: список событий с фильтрами по источнику, методу и коду; карточка события с цепочкой связанных строк; сводка по подтверждённым и неподтверждённым гостям; отметка «требует ручной проверки» с причиной.

Ключевое решение в интерфейсе — не показывать итоговые цифры без контекста. Если на экране написано «403: 31 000», сотрудник сделает вывод «робот заблокирован». Если рядом стоит «источник: WAF, подтверждено: нет, период: 5 дней из 7», вывод меняется на «надо проверить, кого блокирует фильтр». Это разница между интерфейсом, который подталкивает к действию, и интерфейсом, который подталкивает к пониманию.

Второе решение — явные состояния вместо процентов. «Подтверждён», «не подтверждён», «не проверялся» — три разных состояния, и их нельзя схлопывать в одно «робот». Третье — журнал изменений: кто и когда пометил событие, какое действие предложил. Это помогает не терять историю, когда разбор затягивается на недели.

Как проверить саму методику, а не только данные

Методику тоже надо тестировать, иначе она тихо разойдётся с реальностью. Простейший тест — контрольный пример: возьмите известное событие, где вы точно знаете ответ (например, страницу, которую вы сами запросили браузером), и проверьте, что объект воспроизводит его правильно. Если браузерный запрос попал в объект как «робот» — проверка источника работает неверно.

Второй тест — подделка. Сымитируйте запрос с чужим user-agent с адреса, который вам принадлежит, и убедитесь, что объект помечает его как неподтверждённого гостя. Это проверяет не только логику, но и то, что сотрудник увидит разницу. Третий тест — обрезанный период: возьмите журнал за заведомо неполный интервал и проверьте, что объект не выдаёт его за полный.

Четвёртый тест — редирект. Создайте цепочку из двух переходов и убедитесь, что объект связывает строки в одно событие, а не считает их тремя. Пятый — метод: проверьте, что HEAD и GET не смешиваются в одну категорию. Шестой — кеш: если у вас есть доступ к журналу кеша, проверьте, что событие с пометкой HIT не выдаётся за ответ origin. Эти тесты не требуют больших усилий и ловят большинство ошибок до того, как на объект начнут опираться решения.

Практикум: разбор условной недели в три шага

Возьмём другой условный пример, чтобы не повторять арифметику из начала. Небольшой сервис по ремонту техники, журнал за семь дней, три гостя с разными заявленными именами. Задача — за один проход понять, кому из них можно доверять и что чинить.

Шаг первый: разделяем по источнику строки. Из 10 000 строк 6 000 пришли из origin, 3 500 из кеша, 500 из WAF. Это сразу говорит, что итоговые суммы по коду ответа нельзя читать без разбивки: 500 строк из WAF — это отдельная история про фильтр, а не про контент.

Шаг второй: проверяем источники. Из трёх заявленных имён одно подтверждается официальной процедурой, второе не подтверждается (адрес не сходится), третье проверить не удалось — адрес общий с другими сервисами. В объекте появляются три разных состояния, и дальше работа идёт только с подтверждённым гостем, а по двум другим — отдельные пометки.

Шаг третий: смотрим на подтверждённого гостя по методу и цепочке. Из его 2 000 строк 1 400 — GET с кодом 200 и ненулевым телом, 300 — HEAD с кодом 200 и нулевым телом, 200 — цепочки редиректов, 100 — 404 на устаревшие адреса. Вывод: контент в основном доступен, но есть 300 HEAD-ответов без тела и 100 битых адресов. Действия — проверить обработчик HEAD и почистить старые ссылки. Никаких выводов про «робот разлюбил» здесь не требуется.

Такой проход занимает меньше времени, чем кажется, и главное — он воспроизводим. Другой сотрудник, взяв тот же журнал и ту же форму объекта, придёт к тем же выводам, потому что шаги зафиксированы, а не зависят от настроения.

Где заканчивается методика и начинается чужая зона

Важно честно очертить границы. Методика отвечает на вопрос «что робот действительно смог получить и от кого пришёл запрос». Она не отвечает на вопрос «почему страница плохо ранжируется» — это уже про контент, ссылки и качество, и там свои инструменты. Она не заменяет настройку robots.txt и не решает, какие страницы закрывать. Она не даёт гарантий роста трафика и не обещает, что после починки редиректов всё наладится.

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

Наконец, про инструменты. Если в вашем стеке уже есть продукт для работы с контентом или аналитикой, он может закрывать часть шагов, но проверять его возможности стоит по опубликованной документации и в обсуждении задачи, а не по ожиданиям. Ссылки на первичные источники по кодам ответа и верификации робота — это то, на что можно опереться в разговоре с разработкой и защитой, и их стоит держать рядом с рабочим объектом, а не пересказывать по памяти.

Проверка на практике: журнал обращений роботов

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

Смежный вопрос разобран отдельно: AI-краулеры в robots.txt: кого пускать и зачем.