Chrome-Lighthouse в логах — это не безымянный «сервисный обход», а конкретный открытый инструмент Google для аудита страниц: производительность, доступность, SEO, PWA. Запускается он не сам по себе, а по чьей-то команде — из Chrome DevTools, из PageSpeed Insights или как шаг в CI/CD-конвейере. И у этого бота есть важная техническая особенность, которую стоит знать до того, как настраивать фильтры: с 2023 года Google в части сценариев перестал добавлять токен «Chrome-Lighthouse» в конец строки User-Agent, поэтому часть реального аудиторского трафика в логах может не находиться по этому фильтру вообще.
1. Что такое Chrome-Lighthouse на самом деле
Lighthouse — открытый инструмент Google, который загружает страницу и прогоняет по ней серию автоматических аудитов: скорость загрузки, доступность для людей с ограничениями, соответствие SEO-практикам, критерии PWA. На выходе — отчёт с оценками по каждой категории. Источники запуска три: расширение/панель Lighthouse в Chrome DevTools (локально, разработчиком), веб-сервис PageSpeed Insights (доступен публично — проверить может кто угодно, введя ваш URL), и headless-запуск в CI/CD-пайплайне для регулярных проверок производительности при деплое.
Официальная (историческая) строка User-Agent выглядит как обычный Chrome/Android UA с добавленным токеном в конце:
Mozilla/5.0 (Linux; Android 11; moto g power (2022)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Mobile Safari/537.36 Chrome-LighthouseВажная поправка. По репорту в официальном репозитории GoogleChrome/lighthouse на GitHub, начиная примерно с 2023 года API PageSpeed Insights в части запусков перестал добавлять суффикс Chrome-Lighthouse, отправляя обычную мобильную строку Chrome без опознавательного токена. Это значит, что фильтрация access.log только по токену chrome-lighthouse покажет не весь Lighthouse-трафик, а лишь ту его часть, что всё ещё помечена явно.
| Параметр | Значение |
| Название | Chrome-Lighthouse (Google Lighthouse) |
| Оператор | Google — открытый проект, официальная документация: developer.chrome.com/docs/lighthouse |
| Роль | Разовый или регулярный аудит конкретной страницы (производительность, SEO, доступность, PWA), не индексация контента |
| User-Agent / паттерн | Стандартный Chrome/Android UA + суффикс Chrome-Lighthouse — но суффикс присутствует не всегда (см. выше) |
| Кто инициирует | Чаще всего своя же команда (CI, мониторинг), но также — любой внешний человек через публичный PageSpeed Insights |
| robots.txt | Официально не считается соблюдающим robots.txt — правило нужно дублировать серверной блокировкой |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы (точнее — Developer Helper / сервисный аудит) |
2. Зачем Chrome-Lighthouse приходит на сайт
- Своя команда проверяет производительность — вручную через DevTools, разово через PageSpeed Insights или регулярно как шаг CI/CD при каждом деплое;
- Сторонний сервис мониторинга — если сайт подключён к системе синтетического мониторинга (например, работающей поверх Lighthouse), запросы идут по расписанию с почти cron-регулярностью;
- Любой внешний человек — PageSpeed Insights публично доступен, и проверить производительность вашего сайта может кто угодно: конкурент, потенциальный клиент, случайный аудитор. Это не нарушение и не сбор данных для republishing — просто разовый прогон аудита.
Типичный случай: в логах фиксируются регулярные запросы к одному и тому же набору URL с интервалом в несколько минут — это, скорее всего, синтетический мониторинг или CI-проверка, а не бесконтрольный обход. Разовый нерегулярный хит на конкретную страницу — вероятно, кто-то вручную прогнал PageSpeed Insights.
3. Нагрузка и особенности
Аудит нагружает сервер иначе, чем обычный краулер: Lighthouse не просто скачивает HTML, а полноценно рендерит страницу, включая выполнение JavaScript, — с точки зрения origin-сервера один запрос Lighthouse близок по стоимости к полноценной загрузке страницы реальным браузером, а не к лёгкому HTTP-хиту.
Прежде чем ограничивать этот трафик, стоит выяснить, не ваш ли это собственный мониторинг: по данным Known Agents, чаще всего Chrome-Lighthouse на сайте появляется именно потому, что кто-то из своей же команды настроил проверку — блокировка в этом случае молча ломает мониторинг производительности, а не отсекает постороннюю нагрузку.
Поскольку суффикс UA присутствует не всегда, чисто UA-based фильтрация может недооценивать реальный объём такого трафика — при подозрении на скрытые аудиты стоит смотреть паттерн поведения (полный рендеринг страницы, характерные интервалы), а не только строку заголовка.
4. Как найти Chrome-Lighthouse в логах
# Базовый поиск по явному токену
grep -i "chrome-lighthouse" /var/log/nginx/access.log
# Топ URL, которые аудирует инструмент
grep -i "chrome-lighthouse" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP
grep -i "chrome-lighthouse" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Регулярность — синтетический мониторинг обычно бьёт cron-паттерном
grep -i "chrome-lighthouse" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
# Признак "невидимого" Lighthouse-трафика без суффикса — ищите мобильный Chrome UA
# с полной загрузкой одних и тех же страниц без обычной пользовательской навигации по сайту
grep -i "Mobile Safari/537.36\"" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | headВерификация. Как и у большинства сервисных инструментов, у Chrome-Lighthouse нет опубликованного способа криптографически подтвердить подлинность запроса — совпадение строки UA считается лишь косвенным признаком. Смотрите на связку UA + паттерн поведения (полный рендер страницы, регулярность):
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"5. robots.txt для Chrome-Lighthouse
Правило в robots.txt воспринимайте как пожелание — по открытым данным Chrome-Lighthouse не обязан его соблюдать, и для гарантированного результата запись стоит дублировать блокировкой на сервере.
# Жёсткий запрет
User-agent: Chrome-Lighthouse
Disallow: /
# Замедлить, а не запретить (соблюдается не всеми запусками)
User-agent: Chrome-Lighthouse
Crawl-delay: 10
# Компромисс: закрыть служебные разделы, оставить публичные страницы доступными для аудита
User-agent: Chrome-Lighthouse
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "chrome-lighthouse") {
return 403;
}
limit_req_zone $binary_remote_addr zone=chromelighthouse:10m rate=10r/m;
location / {
if ($http_user_agent ~* "chrome-lighthouse") {
limit_req zone=chromelighthouse burst=20 nodelay;
}
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} chrome-lighthouse [NC]
RewriteRule ^ - [F,L]TrafficVeil:
- перед блокировкой уточните у команды разработки, не завязан ли на этот трафик собственный мониторинг производительности или CI-пайплайн;
- если нагрузка от полного рендеринга страниц заметна на слабом origin — рассмотрите rate-limit вместо полного deny, чтобы не терять данные аудита совсем;
- для внешних разовых прогонов через публичный PageSpeed Insights блокировка обычно не нужна — риска для данных нет, это стандартный публичный инструмент;
- после изменения сверьте логи: явно помеченные хиты Chrome-Lighthouse должны уйти в блок/лимит, а обычные пользователи и поисковые боты — остаться без изменений.
7. Что делать: короткий алгоритм
- Трафик — это ваш собственный CI/мониторинг — не блокируйте, при необходимости снижайте частоту через Crawl-delay;
- Источник неясен, единичные хиты — скорее всего, кто-то вручную прогнал PageSpeed Insights, риска нет;
- Регулярный cron-паттерн заметно грузит origin — сначала rate-limit, полный запрет — только если это точно не ваш мониторинг;
- Подозреваете, что часть Lighthouse-трафика идёт без суффикса UA — не полагайтесь только на фильтр по токену, смотрите поведенческий паттерн;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot и YandexBot заодно.
8. С кем не путать Chrome-Lighthouse
| Бот / сосед | Категория | Комментарий |
| Googlebot | Поисковый краулер | Индексирует контент для поиска — влияет на ранжирование, в отличие от Chrome-Lighthouse, который контент не индексирует |
| Google-InspectionTool | Developer Helper | Тоже от Google, но питает Search Console (URL Inspection, Rich Results Test), а не аудит производительности |
| AccessStatus | Developer Helper | Мониторинг HTTP-статусов (аптайм), не полноценный рендеринг страницы — легче нагружает сервер |
| 2ip Bot | Прочие краулеры и сервисы | легитимный |
| AgentReadinessScanner | Developer Helper (Cloudflare) | Проверяет готовность сайта к работе с AI-агентами (llms.txt, MCP), задача принципиально другая |
9. Стратегия allow/deny для Chrome-Lighthouse
| Ситуация | Действие |
| Собственный CI/CD или мониторинг производительности | Allow, при нагрузке — Crawl-delay вместо блокировки |
| Разовые внешние прогоны через публичный PageSpeed Insights | Не трогать — стандартный публичный инструмент, риска для данных нет |
| Регулярная заметная нагрузка от полного рендеринга страниц | Rate-limit на nginx/TrafficVeil |
| Точно посторонний и мешает, не ваш мониторинг | Disallow + запрет в TrafficVeil |
| Подозрение на скрытый Lighthouse-трафик без суффикса UA | Смотреть поведенческий паттерн (полный рендер, регулярность), не только строку UA |