GTmetrix Bot: как распознать тест скорости и отличить его от обычного пользователя

GTmetrix — сервис тестирования производительности веб-страниц. Его автоматические запросы принципиально отличаются от поведения поискового робота, SEO-crawler или массового scraper.

GTmetrix получает конкретный URL, запускает реальный браузер, открывает страницу и загружает ресурсы практически так же, как это сделал бы пользователь. После этого результаты анализируются с помощью Lighthouse и преобразуются в отчёт о производительности.

Поэтому термин «бот» здесь удобен для классификации автоматического трафика, но технически GTmetrix правильнее считать browser-based performance testing service.

Параметр	Значение
Название	GTmetrix
Оператор	WP Media SAS
Тип	Автоматизированное браузерное тестирование производительности
Основной UA-маркер	GTmetrix
Браузер	Chrome / Chromium-based test environment
Движок анализа	Google Lighthouse
Загрузка ресурсов страницы	Да
Поисковая индексация	Нет
Автоматический обход всего сайта	Не является стандартной моделью работы
Тесты по расписанию	Да, в рамках monitoring
Официальные test server IP	Да
Категория TrafficVeil	Прочие краулеры и сервисы / Performance Monitoring
Статус	Легитимный

Кому принадлежит GTmetrix

Оператор GTmetrix не является неизвестным.

На текущий момент юридическим оператором сервиса выступает WP Media SAS — французская компания, также известная по продуктам в области оптимизации производительности сайтов.

В 2025 году GTmetrix начал перенос своей глобальной тестовой инфраструктуры в организацию WP Media и одновременно перевёл test servers на облачную инфраструктуру.

Для TrafficVeil это означает, что GTmetrix можно хранить как известного оператора с документированной инфраструктурой, а не как неопределённого клиента, установленного только по строке User-Agent.

GTmetrix — не обычный crawler

В исходных описаниях автоматических агентов часто используется универсальная формулировка: «обходит страницы, пагинацию и ссылочный граф».

Для GTmetrix она неправильна.

Стандартный тест начинается с конкретного URL:

https://example.com/product

После этого браузер GTmetrix загружает документ и ресурсы, необходимые самой странице.

Например:

GET /product
GET /assets/app.css
GET /assets/app.js
GET /images/product.webp
GET /fonts/inter.woff2
GET /analytics.js

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

Что именно загружает GTmetrix

Поскольку тест выполняется реальным браузером, GTmetrix может запрашивать почти тот же набор ресурсов, который получает обычный посетитель:

• HTML;
• CSS;
• JavaScript;
• изображения;
• WebP/AVIF;
• шрифты;
• XHR/fetch-запросы;
• API endpoints, вызываемые фронтендом;
• сторонние аналитические скрипты;
• рекламные ресурсы;
• CDN-ресурсы;
• внешние виджеты.

Поэтому формулировка «GTmetrix иногда трогает API и статику» слишком осторожна: для современной динамической страницы это совершенно нормальная часть теста.

Почему один тест может создать десятки или сотни запросов

Допустим, страница состоит из:

• 1 HTML-документа;
• 8 CSS-файлов;
• 17 JavaScript-файлов;
• 45 изображений;
• 6 шрифтов;
• 14 API и аналитических запросов.

Одна загрузка уже даст:

1 + 8 + 17 + 45 + 6 + 14 = 91 HTTP-запрос

Это не означает, что GTmetrix обошёл 91 страницу сайта.

Большинство запросов относятся к зависимостям одной страницы.

Чем GTmetrix отличается от Googlebot

Признак	GTmetrix	Поисковый crawler
Цель	Измерить производительность страницы	Проиндексировать контент
Исходная задача	Получает URL для теста	Самостоятельно обнаруживает URL
Запускает браузер	Да	Зависит от crawler
Загружает ресурсы страницы	Да, это необходимо для измерений	Не обязательно в том же объёме
Переходит по всем ссылкам	Нет в рамках обычного page test	Может
Создаёт поисковый индекс	Нет	Да

Когда GTmetrix приходит на сайт

Есть два наиболее очевидных сценария.

Ручной тест

Пользователь вводит URL в GTmetrix и запускает анализ.

Через короткое время test server открывает страницу и выполняет измерения.

Такой запрос может появиться совершенно неожиданно для владельца сайта, потому что тест способен запустить не только администратор, но и разработчик, SEO-специалист, клиент, конкурент или любой другой пользователь сервиса, если страница публична.

Monitoring

GTmetrix позволяет сохранять страницы и запускать повторяющиеся проверки.

В таком случае в логах можно увидеть периодические загрузки одного и того же URL.

Регулярность сама по себе здесь не означает вредоносную автоматизацию: это может быть настроенный performance monitoring.

Как выглядит User-Agent GTmetrix в 2026 году

С 17 ноября 2025 года стандартный GTmetrix User-Agent содержит хорошо заметный маркер GTmetrix в конце строки.

В официальной документации приводится формат:

Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/142.0.0.0 Safari/537.36 GTmetrix

Номер Chrome со временем изменяется, поэтому использовать всю строку как статическую сигнатуру нельзя.

Практический паттерн:

GTmetrix

с поиском без учёта регистра.

Почему короткий User-Agent «gtmetrix» устарел как модель

В некоторых базах ботов агент хранится просто как:

gtmetrix

Для токен-матчинга это допустимо.

Но реальный стандартный запрос выглядит как обычный браузер Chrome с дополнительным маркером GTmetrix.

Если TrafficVeil выводит пользователю «полный User-Agent: gtmetrix», это создаёт неверное представление о реальном трафике.

Пользователь GTmetrix может изменить User-Agent

Это одна из самых важных особенностей для антибот-системы.

GTmetrix позволяет использовать User Agent Override. Пользователь может указать собственную строку или сформировать её из шаблонов устройства и тестовой локации.

Например, GTmetrix способен выполнить тест, представившись обычным мобильным Chrome:

Mozilla/5.0 (...) Chrome/... Mobile Safari/537.36

или практически любым другим значением, заданным пользователем.

GTmetrix можно запустить вообще без маркера GTmetrix

В сервисе существует сценарий anonymized User-Agent, позволяющий убрать стандартный хвост:

GTmetrix

из строки браузера.

Следовательно:

нет "GTmetrix" в UA ≠ запрос точно не GTmetrix

Это очень важный вывод для TrafficVeil.

UA прекрасно подходит для определения стандартного теста, но не способен обнаружить все возможные тесты GTmetrix.

У GTmetrix есть официальный список IP

Да. Причём инфраструктура документирована значительно лучше, чем у многих crawler.

GTmetrix публикует IP test servers для каждой доступной географической локации.

На момент актуализации сервис сообщает о:

• 113 test servers;
• 25 глобальных test locations.

Среди регионов представлены Северная и Южная Америка, Европа, Ближний Восток, Африка и Азиатско-Тихоокеанский регион.

Примеры тестовых регионов

Регион	Примеры локаций
Северная Америка	Seattle, San Francisco, San Antonio, Chicago, Quebec City
Латинская Америка	São Paulo, Santiago, Mexico City
Европа	London, Paris, Amsterdam, Frankfurt, Stockholm, Madrid
Ближний Восток	Dubai
Азия	Tokyo, Singapore, Hong Kong, Busan, Pune, Chennai
Африка	Johannesburg
Океания	Sydney

Почему не стоит хранить IP GTmetrix прямо в статье

Адреса инфраструктуры меняются.

Хороший пример произошёл в 2025 году, когда GTmetrix перевёл test servers в инфраструктуру WP Media и заменил значительную часть IP.

Позднее Vancouver был заменён Seattle, а Mumbai — Pune.

Поэтому длинный статичный перечень IP в статье быстро превращается в источник ошибок.

Правильнее использовать официальный актуальный список GTmetrix.

Как TrafficVeil лучше идентифицировать GTmetrix

Можно использовать два уровня уверенности.

Высокая уверенность

официальный GTmetrix IP
+
UA содержит GTmetrix

Это наиболее очевидный стандартный тест.

Вероятный GTmetrix

официальный GTmetrix IP
+
браузерный UA без GTmetrix
+
поведение полноценной page load

Так может выглядеть тест с User Agent Override или анонимизацией UA.

Это гораздо сильнее простой проверки:

if UA contains GTmetrix

Почему нельзя доверять только слову GTmetrix

Обратная ситуация тоже возможна.

Любой клиент способен отправить:

User-Agent: Mozilla/5.0 Chrome/... Safari/537.36 GTmetrix

Поэтому совпадение UA не должно автоматически выключать:

• WAF;
• SQL injection detection;
• XSS detection;
• path traversal protection;
• credential protection;
• прочие security rules.

Если источник одновременно пытается открыть /.env, /.git/config и /wp-login.php, известный UA не делает такое поведение безопасным.

Как найти GTmetrix в Nginx access.log

Стандартные тесты:

grep -i "gtmetrix" /var/log/nginx/access.log

Количество:

grep -ic "gtmetrix" /var/log/nginx/access.log

Топ URL:

grep -i "gtmetrix" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -nr \
| head -30

Топ IP:

grep -i "gtmetrix" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -nr \
| head -20

Коды ответов:

grep -i "gtmetrix" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -nr

Почему grep по UA показывает не весь GTmetrix-трафик

Из-за User Agent Override предыдущие команды находят только запросы, в которых действительно сохранился текст GTmetrix.

Если задача — точно установить обращения тестовой инфраструктуры, анализируйте также IP.

Это особенно важно для антибота, где пользователь может намеренно тестировать:

• мобильный браузер;
• Googlebot-like UA;
• собственный приложение-клиент;
• обычный Chrome без маркера GTmetrix.

Как проверить IP и ASN

IP="1.2.3.4"

whois "$IP"
dig +short -x "$IP"

ASN:

whois -h whois.cymru.com " -v $IP"

Но для GTmetrix официальный список test servers является более сильным признаком, чем просто ASN.

Сейчас значительная часть инфраструктуры размещается в облаке, поэтому принадлежность IP крупному cloud provider сама по себе не подтверждает GTmetrix.

Как выглядит нормальный GTmetrix-тест в логах

Типичная последовательность:

1. запрос HTML;
2. получение redirect, если он есть;
3. финальный HTML с 200 OK;
4. загрузка CSS;
5. загрузка JavaScript;
6. получение изображений;
7. загрузка шрифтов;
8. XHR/fetch запросы страницы;
9. выполнение сторонних скриптов.

То есть профиль напоминает реальный браузер намного больше, чем SEO crawler.

Какие HTTP-коды помогают найти проблему

Статус	Что может означать
200	Страница или ресурс успешно загружены
301/302	Обычный redirect
401	Требуется авторизация
403	GTmetrix блокируется защитой
404	Ресурс страницы отсутствует
429	Сработал rate limit
5xx	Ошибка origin или приложения

Почему 403 ломает тест GTmetrix

GTmetrix ожидает успешную загрузку анализируемой страницы.

Если root request после цепочки перенаправлений заканчивается ответом 403 Forbidden, сервис не может выполнить нормальный Lighthouse-анализ.

GTmetrix отдельно указывает firewall, security plugins и reverse proxies как распространённые причины подобных ошибок.

Поэтому ситуация:

сайт работает у меня,
но GTmetrix пишет ошибку

часто означает не проблему GTmetrix, а различие в политике доступа.

Как WAF может исказить результат даже без 403

Есть более сложный сценарий.

Вместо блокировки WAF показывает challenge:

Checking your browser...

или CAPTCHA.

Если GTmetrix тратит часть теста на эту страницу, отчёт уже не отражает обычный пользовательский сценарий.

Можно получить завышенные:

• TTFB;
• LCP;
• Fully Loaded Time;
• объём JavaScript;
• число запросов.

Или тест вообще не завершится корректно.

Почему GeoIP-фильтрация тоже влияет на GTmetrix

GTmetrix запускает проверки из разных стран.

Если сайт доступен только пользователям из определённых регионов, test server из другой страны закономерно может получить блокировку.

Например, владелец запускает тест из London, а политика сайта разрешает только Казахстан.

Ответ 403 в такой ситуации не является ошибкой антибота — это реальное действие настроенной GeoIP-политики.

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

Почему robots.txt здесь почти не имеет смысла

GTmetrix получает конкретный URL для браузерного performance-test, а не исследует сайт с целью поисковой индексации.

Поэтому конструкция:

User-agent: GTmetrix
Disallow: /

не является корректным способом управления тестами.

robots.txt вообще не является firewall и не гарантирует запрет HTTP-доступа.

Если необходимо реально блокировать GTmetrix, используйте TrafficVeil, WAF, IP rules или конфигурацию веб-сервера.

Нужно ли блокировать GTmetrix

В большинстве случаев причин для глобальной блокировки немного.

GTmetrix:

• не создаёт поисковый индекс;
• не является AI training crawler;
• не предназначен для массового scraping;
• не должен самостоятельно обходить весь сайт;
• обычно работает только по инициативе пользователя или monitoring job.

Если тестирование полезно владельцу, разработчикам или подрядчикам, GTmetrix разумнее разрешить.

Когда блокировка всё же оправданна

• публичное тестирование сайта принципиально нежелательно;
• кто-то намеренно запускает чрезмерное количество тестов;
• performance-тесты затрагивают дорогой динамический endpoint;
• UA GTmetrix подделан и источник ведёт себя вредоносно;
• сервис не нужен и политика организации запрещает external synthetic testing.

Почему обычный rate limit может испортить тест

Один браузер GTmetrix способен одновременно загружать множество ресурсов.

Если установить:

rate=10r/m

для всех запросов test server, страница практически гарантированно начнёт получать 429 Too Many Requests.

Это будет измерение вашего rate limiter, а не реальной производительности сайта.

Для browser-based testing слишком низкий request-rate особенно неудачен.

Корректный rate limit в Nginx

В исходных конфигурациях часто встречается ещё одна техническая проблема: limit_req пытаются помещать внутрь if.

Более аккуратный вариант — сначала сформировать ключ через map:

map $http_user_agent $gtmetrix_limit_key {
    default "";
    ~*GTmetrix $binary_remote_addr;
}

limit_req_zone $gtmetrix_limit_key zone=gtmetrix:10m rate=5r/s;

server {
    location / {
        limit_req zone=gtmetrix burst=30;
    }
}

Но даже такое ограничение следует применять только после анализа реальной задачи: слишком низкие значения ухудшат достоверность performance-теста.

Полная блокировка по User-Agent в Nginx

if ($http_user_agent ~* "GTmetrix") {
    return 403;
}

Это остановит стандартный UA, но не обнаружит GTmetrix с User Agent Override.

Блокировка через Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} GTmetrix [NC]
RewriteRule ^ - [F,L]

Ограничение то же: правило работает с заявленным UA, а не с происхождением запроса.

Почему IP rule для GTmetrix практичнее UA rule

Если задача — разрешить именно test servers GTmetrix, официальный IP-list имеет сразу два преимущества.

Во-первых, пользователь не сможет случайно потерять доступ из-за собственного User Agent Override.

Во-вторых, неизвестный клиент не получит allow только потому, что дописал себе слово GTmetrix.

Проверка	Надёжность
Только UA содержит GTmetrix	Средняя
Только cloud ASN	Низкая
Официальный GTmetrix IP	Высокая для инфраструктуры сервиса
GTmetrix IP + стандартный UA	Очень высокая для стандартного теста
GTmetrix IP + browser behavior	Полезно для overridden/anonymized UA

GTmetrix в TrafficVeil

Для TrafficVeil GTmetrix лучше классифицировать как Performance Testing / Synthetic Browser внутри группы сервисных агентов.

Проверка может выглядеть так:

1. найти маркер GTmetrix в UA;
2. проверить исходный IP;
3. сопоставить его с актуальными test servers;
4. определить географическую test location;
5. посмотреть browser-like request pattern;
6. учесть User Agent Override;
7. не давать security bypass только по строке UA;
8. применить allow, deny или специальную политику.

Что полезно показывать пользователю TrafficVeil

Поле	Рекомендуемое значение
Название	GTmetrix
Оператор	WP Media SAS
Тип	Browser-based performance test
Категория	Прочие краулеры и сервисы
Статус	Легитимный
Назначение	Тест производительности страницы
Основной UA token	GTmetrix
Custom UA	Поддерживается
Официальные IP	Есть
Рекомендуемая проверка	IP + UA + browser behavior

Как отличить обычный тест от подозрительного клиента

Поведение	Оценка
HTML + CSS + JS + изображения одной страницы	Типичный GTmetrix
Периодическая загрузка одного URL	Возможный monitoring
Официальный test IP, но необычный UA	Возможен User Agent Override
UA GTmetrix с постороннего IP	Требует дополнительной проверки
Перебор .env/.git/wp-login	Не соответствует обычному performance-test
Последовательный обход тысяч несвязанных страниц	Нетипично для стандартного GTmetrix page test

Не считайте GTmetrix человеческим посетителем

GTmetrix использует настоящий браузер, но это всё равно автоматизированный synthetic traffic.

Он не должен попадать в показатели:

• реальной аудитории;
• конверсии;
• человеческих сессий;
• реального DAU/MAU;
• поведения клиентов.

При этом его браузерное поведение может выглядеть гораздо реалистичнее классического crawler.

Именно поэтому классификация на уровне reverse proxy особенно полезна.

Не путайте лабораторные показатели GTmetrix с реальными пользователями

GTmetrix выполняет synthetic/lab test из выбранной локации, на определённом устройстве и с заданной скоростью соединения.

Полученные показатели позволяют сравнивать состояние страницы и находить проблемы производительности, но они не являются прямым измерением опыта всей реальной аудитории.

Например, пользователь в Алматы на мобильном интернете и GTmetrix server в London с заданным connection profile находятся в разных условиях.

Поэтому лабораторные данные лучше использовать вместе с Real User Monitoring и полевыми Web Vitals, если они доступны.

Практический алгоритм при появлении GTmetrix в логах

1. Посмотрите User-Agent. Есть ли стандартный маркер GTmetrix.
2. Проверьте IP. Сопоставьте его с актуальным списком test servers.
3. Посмотрите URL. Стандартный тест связан с конкретной страницей.
4. Изучите соседние запросы. CSS, JS и изображения подтверждают browser-like page load.
5. Проверьте HTTP-коды. 403/429 могут ломать тест.
6. Не забудьте про Custom UA. Настоящий GTmetrix способен не содержать маркер в строке.
7. Не применяйте слишком низкий rate limit. Браузер загружает ресурсы параллельно.
8. Определите бизнес-пользу. Используется ли performance testing командой сайта.
9. После этого выберите политику. Allow, deny или отдельные ограничения.

Когда GTmetrix лучше разрешить

• разработчики используют сервис для диагностики;
• настроен performance monitoring;
• проводятся регулярные тесты после релизов;
• нужно сравнивать показатели из разных локаций;
• GTmetrix входит в рабочий процесс SEO/performance-команды.

Когда запрет допустим

• внешние synthetic tests запрещены политикой сайта;
• GTmetrix не используется и не представляет ценности;
• запрос заявляет UA GTmetrix, но ведёт себя как вредоносный scanner;
• наблюдается злоупотребление тестами;
• владельцу принципиально не нужен публичный performance analysis.

Сводная стратегия TrafficVeil

Ситуация	Рекомендуемое действие
Официальный IP + стандартный UA	Allow для нужного performance testing
Официальный IP + custom UA	Учитывать как возможный GTmetrix test
GTmetrix получает 403	Проверить WAF и IP policy
GTmetrix получает 429	Проверить слишком строгий rate limit
UA GTmetrix, но IP не подтверждается	Не предоставлять bypass автоматически
GTmetrix не нужен организации	Deny допустим
Поведение похоже на vulnerability scan	Применять обычные security rules независимо от UA

Итог

GTmetrix — легитимный сервис автоматизированного тестирования производительности, а не обычный веб-краулер. Он запускает реальный браузер, загружает конкретную страницу вместе с её ресурсами и анализирует результат с помощью Lighthouse.

Это объясняет характерный профиль в логах: один тест способен породить десятки или сотни HTTP-запросов к HTML, CSS, JavaScript, изображениям, шрифтам и API, но это не следует путать с массовым обходом сайта.

У GTmetrix есть публичная инфраструктура test servers и актуальные IP по глобальным локациям. В то же время User-Agent стал менее надёжным идентификатором: стандартная строка содержит GTmetrix, но пользователь сервиса может заменить или анонимизировать её.

Для TrafficVeil оптимальная идентификация должна учитывать официальный IP, полный UA и характер browser-like загрузки. Если GTmetrix нужен команде сайта, подтверждённые тесты лучше разрешить; если сервис не используется, доступ можно ограничить. При этом ни знакомый User-Agent, ни принадлежность к cloud ASN не должны автоматически отключать остальные механизмы безопасности.