Qwantbot: что это за поисковый робот Qwant и нужно ли его блокировать

Qwantbot — официальный веб-краулер поисковой системы Qwant. Он автоматически получает публичные веб-страницы и помогает Qwant развивать и актуализировать собственный поисковый индекс.

Qwant имеет отдельную официальную страницу для веб-мастеров, где документированы User-Agent, правила robots.txt и сразу два способа проверки настоящего crawler: через DNS и официальный список IP.

Для TrafficVeil это важное отличие от малоизвестных ботов: Qwantbot можно достаточно надёжно верифицировать, поэтому совпадение User-Agent не должно быть единственным сигналом.

Зачем Qwantbot приходит на сайт

Qwant официально сообщает, что использует web crawlers для улучшения своего индекса и предоставления поискового сервиса.

Типичная схема:

Qwantbot
↓
получает публичную страницу
↓
анализирует документ
↓
обнаруживает и обновляет URL
↓
информация используется поисковой инфраструктурой Qwant

Поэтому Qwantbot относится к той же функциональной категории, что и другие поисковые роботы:

Search Crawlers
→ Qwant
→ Qwantbot

Его не следует смешивать с AI training crawler, link-preview ботами, RSS-reader или security scanner.

Как выглядит User-Agent Qwantbot

Qwant официально публикует общий шаблон:

Mozilla/5.0 (compatible; Qwantbot{-news}/X.Y_{worker_id}; +https://help.qwant.com/bot/)

Часть:

{-news}

является необязательной. То же относится к конкретной версии и идентификатору worker.

Примеры официальных User-Agent

Qwant приводит, например:

Mozilla/5.0 (compatible; Qwantbot/1.0_12345; +https://help.qwant.com/bot/)

и:

Mozilla/5.0 (compatible; Qwantbot-news/2.0; +https://help.qwant.com/bot/)

При этом сама документация отдельно подчёркивает: строка Qwantbot всегда присутствует в UA официальных web crawlers Qwant.

Почему в TrafficVeil не нужно матчить полную строку UA

Версия crawler и worker ID могут меняться.

Если правило ожидает:

Qwantbot/1.0_12345

оно пропустит:

Qwantbot/1.0_2600345
Qwantbot/2.0_98765
Qwantbot-news/2.0

Поэтому основной matcher:

contains case-insensitive "Qwantbot"

значительно устойчивее.

Что такое Qwantbot-news

Qwantbot-news — официальный вариант Qwantbot, а не сторонний бот с похожим названием.

Он входит в документированный Qwant шаблон:

Qwantbot{-news}

и пример Qwantbot-news/2.0 опубликован самим Qwant.

В TrafficVeil имеет смысл сохранять семейство:

Qwant
├── Qwantbot
└── Qwantbot-news

но при необходимости показывать статистику этих вариантов отдельно.

Как найти Qwantbot в access.log

Базовый поиск:

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

Он одновременно найдёт:

Qwantbot
Qwantbot-news

Количество запросов

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

Топ URL

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

Топ IP

grep -i "Qwantbot" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

HTTP-коды

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

Разделить Qwantbot и Qwantbot-news

# Обычный Qwantbot
grep -i "Qwantbot/" /var/log/nginx/access.log

# News-вариант
grep -i "Qwantbot-news" /var/log/nginx/access.log

Одного User-Agent недостаточно

Строку:

User-Agent: Mozilla/5.0 (compatible; Qwantbot/1.0_12345; +https://help.qwant.com/bot/)

может отправить любой HTTP-клиент.

Поэтому TrafficVeil не должен использовать:

UA contains Qwantbot
→ unconditional trusted Allow

В отличие от множества малоизвестных crawler, Qwant предоставляет официальный механизм проверки.

Как правильно проверить настоящий Qwantbot

Qwant называет reverse + forward DNS предпочтительным методом проверки crawler.

Алгоритм:

1. получить исходный IP запроса;
2. выполнить reverse DNS lookup;
3. убедиться, что hostname заканчивается на qwant.com;
4. выполнить forward DNS для найденного hostname;
5. проверить, что среди результатов присутствует исходный IP.

Пример проверки

Qwant приводит IP:

91.242.162.1

Reverse DNS:

host 91.242.162.1

возвращает hostname вида:

qwantbot-1-162-242-91.qwant.com

После этого выполняется:

host qwantbot-1-162-242-91.qwant.com

и hostname должен разрешиться обратно в исходный IP. Именно такой пример опубликован Qwant.

Почему нужен именно forward-confirmed reverse DNS

Недостаточно увидеть:

something.qwant.com

только в PTR.

Надёжнее убедиться:

IP
↓
PTR → hostname.qwant.com
↓
hostname
↓
A/AAAA → исходный IP

Так значительно сложнее выдать сторонний сервер за настоящий crawler Qwant.

Как проверить автоматически в TrafficVeil

Логика может выглядеть так:

UA contains Qwantbot
AND
PTR suffix == qwant.com
AND
forward_dns(PTR) contains source_ip
=
Verified Qwantbot

Это соответствует рекомендуемой Qwant схеме.

Официальный qwantbot.json

Есть и второй механизм.

Qwant публикует официальный файл:

qwantbot.json

с IP-диапазонами crawler.

TrafficVeil может автоматически загружать его и проверять:

source_ip ∈ official Qwant ranges

Но DNS является предпочтительным способом

Qwant прямо пишет, что reverse/forward DNS — первый и предпочтительный метод.

IP ranges — альтернативный способ проверки.

Поэтому архитектура TrafficVeil может выглядеть так:

Primary:
FCrDNS

Secondary:
official qwantbot.json

Additional:
ASN + behavior + fingerprint

Почему qwantbot.json нужно регулярно обновлять

Это очень важная деталь официальной документации.

Qwant рекомендует:

Refresh this list on a daily basis

потому что IP-диапазоны могут измениться в любой момент.

То есть статически зашить диапазоны в код на годы — плохая идея.

Как хранить официальный IP feed в TrafficVeil

Практически полезные поля:

source = qwant_official
feed = qwantbot.json
last_sync
last_successful_sync
range_count
feed_hash
verification_status

Обновление — минимум ежедневно, как рекомендует сам оператор.

Что делать при временной ошибке обновления JSON

Не следует немедленно удалить все старые диапазоны.

Разумнее:

download failed
↓
retain last known good set
↓
mark feed stale
↓
continue FCrDNS verification

Так временный сетевой сбой не сломает проверку поискового crawler.

Рекомендуемые уровни identity

Как выглядит spoofed Qwantbot

Например:

User-Agent: Qwantbot/1.0_12345
IP: residential proxy
PTR: отсутствует

GET /.env
GET /.git/config
GET /wp-config.php.bak
GET /backup.sql
GET /vendor/phpunit/

Такой клиент не должен получать trusted status.

TrafficVeil должен показать:

Claimed identity: Qwantbot
Verification: Failed
Behavior: Security scanning
Action: Block

Как выглядит нормальный Qwantbot

Соблюдает ли Qwantbot robots.txt

Да.

Официальная документация Qwant прямо указывает, что crawler соблюдает стандарт robots.txt.

Это позволяет управлять Qwantbot обычным способом, не прибегая сразу к firewall или WAF.

Полная блокировка через robots.txt

User-agent: Qwantbot
Disallow: /

Поскольку все варианты crawler содержат Qwantbot, это базовый вариант отдельной политики.

Частичное ограничение

User-agent: Qwantbot
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /internal/
Allow: /

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

Нужно ли делать отдельное правило Qwantbot-news

Если политика должна быть одинаковой для всего семейства, обычно достаточно корректно настроить правила для Qwantbot.

Если же TrafficVeil позволяет управлять вариантами отдельно, можно дополнительно хранить:

Qwantbot
Qwantbot-news

как разные sub-identities одного оператора.

robots.txt лучше 403 для обычного SEO-контроля

Если настоящий Qwantbot просто не должен обходить часть сайта, robots.txt является более естественным механизмом.

Схема:

Verified Qwantbot
↓
robots.txt
↓
crawler учитывает policy

лучше, чем постоянно возвращать crawler 403.

Когда нужен Nginx Block

Server-side блокировка полезна, если:

• нужен немедленный технический запрет;
• UA подделывается;
• источник не прошёл verification;
• наблюдается security scanning;
• robots.txt недостаточно для вашей политики доступа.

Nginx

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

Но это правило проверяет только User-Agent и поэтому не различает настоящий Qwantbot и spoofing.

Apache

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

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

Qwant — европейская поисковая система, но географический firewall:

France → Block

или:

Europe → Block

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

TrafficVeil должен разделять:

Geo
ASN
Bot Identity
Bot Operator
Bot Policy

Нужно ли разрешать Qwantbot

Если владелец хочет, чтобы его публичные страницы были доступны поисковой инфраструктуре Qwant, базовая рекомендация:

Allow

Qwant официально подтверждает, что его crawlers используются для развития поискового индекса.

Когда Monitor лучше безусловного Allow

Если TrafficVeil увидел только строку:

Qwantbot

но DNS/IP verification ещё не выполнялась, разумнее:

Claimed Qwantbot
→ Verify
→ Allow if verified

а не автоматически whitelist любого запроса с таким UA.

Когда имеет смысл Block

Block возможен, если:

• Qwant не представляет поисковой ценности для проекта;
• владелец сознательно не хочет indexing/crawling этим поисковиком;
• есть внутренние ограничения на automated access;
• источник лишь притворяется Qwantbot.

А если Qwantbot создаёт нагрузку

Сначала нужно убедиться, что это настоящий crawler.

Затем посмотреть:

• Requests;
• Unique URLs;
• Requests per URL;
• RPS/RPM;
• Cache HIT Ratio;
• Origin Requests;
• Bandwidth;
• TTFB.

Не стоит блокировать полезного search crawler только из-за большого абсолютного числа запросов.

Hits и Origin Impact — разные показатели

Например:

10 000 Qwantbot requests
97% cache HIT
300 origin requests

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

А:

1000 Qwantbot requests
0% cache HIT
1000 expensive dynamic pages

могут заметно нагружать backend.

Внутренняя статистика TrafficVeil

По вашей сводке TrafficVeil паттерн qwantbot дал порядка 10 тыс. запросов за март–июнь 2026 года, при этом июнь учитывался только по 14 июня.

В статье такую цифру лучше показывать явно как внутреннее наблюдение:

TrafficVeil telemetry
March – June 14, 2026
Qwantbot: ≈10,000 requests

Не стоит превращать эту цифру в глобальную характеристику нагрузки Qwantbot: это статистика конкретной выборки TrafficVeil.

Что добавить к статистике

Полезнее показывать:

Requests
Verified Requests
Failed Verification
Qwantbot-news share
Unique IP
Unique URLs
Cache HIT
Origin Requests
Bandwidth

Так становится понятно не только сколько раз crawler пришёл, но и насколько он реально воздействовал на инфраструктуру.

Что делать с Qwantbot-news в статистике

Я бы сделал:

Qwant
Total requests: 10,000

├── Qwantbot: 8,700
└── Qwantbot-news: 1,300

если ваша телеметрия позволяет разделить их.

Это даст владельцу сайта более полезное представление о характере поискового обхода.

Qwantbot не нужно считать реальным посетителем

Search crawler request — машинный запрос.

Правильная аналитика:

Qwantbot GET /article
→ Automated / Search Crawler

пользователь Qwant Search нажал результат
→ Human Traffic / Search referral

Это две разные сущности.

Как учитывать Qwantbot в TrafficVeil

Рекомендуемая иерархия:

Automated Traffic
→ Search Crawlers
→ European / Regional Search Engines
→ Qwant
→ Qwantbot

Трафик следует:

• исключать из Human Traffic;
• не считать конверсией;
• учитывать отдельно как Search Bot Traffic;
• разделять Verified и Spoofed;
• отдельно учитывать Qwantbot-news;
• показывать Origin Impact.

С кем не путать Qwantbot

Qwantbot и Googlebot — независимые crawler

Правило:

User-agent: Qwantbot
Disallow: /

не применяется к:

Googlebot
Bingbot
YandexBot

Поэтому точечное ограничение Qwant не является автоматическим запретом других поисковиков.

Контакт при проблемах с crawler

Qwant публикует отдельный адрес:

qwantbot@qwant.com

для сообщений о проблемах, вызванных crawling.

Это полезно добавить в карточку TrafficVeil рядом с официальной документацией и verification data.

Рекомендуемая карточка TrafficVeil

Стратегия Allow / Monitor / Block

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

Вместо короткого:

«Qwantbot — поисковый робот Qwant. Нужен Qwant — разрешите.»

лучше:

Qwantbot — официальный поисковый crawler Qwant. Настоящего робота можно проверить через reverse DNS: hostname должен заканчиваться на qwant.com, после чего forward DNS должен вернуть исходный IP. Qwant также публикует официальный qwantbot.json со своими IP и рекомендует обновлять его ежедневно. Если вам нужна видимость в Qwant, рекомендуем разрешать только верифицированный Qwantbot.

Итог

Qwantbot — хорошо документированный поисковый crawler, для которого нет необходимости доверять одному User-Agent.

Qwant официально публикует шаблон:

Qwantbot{-news}/X.Y_{worker_id}

и прямо указывает, что токен Qwantbot присутствует во всех UA его web crawlers. В документации подтверждены как обычный Qwantbot, так и вариант Qwantbot-news.

Для проверки Qwant рекомендует reverse DNS с hostname, заканчивающимся на qwant.com, и последующий forward lookup. Альтернативно доступен официальный qwantbot.json, который следует обновлять ежедневно.

Также Qwant официально подтверждает соблюдение robots.txt и публикует контакт qwantbot@qwant.com для проблем с crawler.

Поэтому для TrafficVeil оптимальная модель:

Search Crawlers
→ European / Regional Search Engines
→ Qwant
→ Qwantbot

Verification:
1. Reverse + Forward DNS
2. qwantbot.json

Identity: Verified
Default: Allow / Monitor

И главное: не whitelist'ить любой запрос только потому, что его UA содержит Qwantbot. У Qwant есть полноценная официальная verification scheme, поэтому TrafficVeil может отличать настоящий поисковый crawler от spoofing значительно надёжнее.