Строка w3c_validator в access-логе почти никогда не означает атаку — обычно это официальный инструмент проверки вёрстки от W3C, который кто-то (сам владелец сайта, разработчик или сторонний QA-сервис) запустил вручную или по расписанию. Но за одним и тем же именем в разных источниках скрывается сразу несколько разных сервисов W3C с разным поведением, и путать их — источник большинства ошибок при настройке блокировок. Ниже — как отличить их друг от друга, проверить активность в логах, оценить реальную нагрузку и настроить доступ через robots.txt, веб-сервер или TrafficVeil.
Что такое W3C_Validator и почему это не один бот, а семейство
Под общим названием «валидатор W3C» на практике работает несколько отдельных сервисов, у каждого — собственная строка User-Agent:
| Сервис | User-Agent | Задача |
| Markup Validator (проверка HTML) | W3C_Validator/1.3 (http://validator.w3.org/services) | Проверка HTML/XHTML на соответствие спецификациям |
| Link Checker | W3C-checklink | Обход и проверка ссылок на странице |
| CSS Validator | Jigsaw/2.3.0 W3C_CSS_Validator_JFouffa/2.0 | Проверка корректности CSS |
| Internationalization Checker | W3C_I18n-Checker/1.0 | Проверка настроек интернационализации страницы |
| Feed Validator | FeedValidator/1.3 | Проверка RSS/Atom-лент |
Практический вывод: правило вида User-agent: w3c_validator, Disallow: / остановит только основной HTML-валидатор. Если цель — ограничить весь набор инструментов W3C, каждый сервис нужно прописывать отдельной строкой, иначе часть трафика продолжит приходить под другим именем.
Как и когда бот вообще попадает на сайт
Важное отличие от классических краулеров: Markup Validator не сканирует сайт самостоятельно и не ходит по внутренним ссылкам в фоне. Запрос к конкретному URL появляется только тогда, когда кто-то явно передаёт этот адрес валидатору — вручную через форму «Validate by URI» на validator.w3.org или программно, через прямой запрос к его API. Отсюда и типичный сценарий нагрузки: не постепенный прогрев, а короткая серия обращений, если сторонний SEO-аудитор, CI-пайплайн или расширение браузера прогоняет через валидатор сразу несколько десятков URL сайта подряд.
Соблюдение robots.txt: не универсальное правило для всей линейки
Здесь черновые данные стоит уточнить. По документации W3C, явно как «соблюдающий robots.txt» описан именно Link Checker (W3C-checklink) — это отдельно прописано в его технической документации, а сам механизм построен на модуле LWP::RobotUA и поддерживает только базовую версию стандарта 1994 года (без учёта meta-тега robots). Для основного Markup Validator подобного явного заявления в официальных источниках нет, и независимые обзоры бота указывают, что при разовой проверке конкретного URL по прямой ссылке HTML-валидатор запрашивает страницу напрямую, не сверяясь предварительно с robots.txt проверяемого сайта. Практический вывод: рассчитывать на robots.txt как на единственный барьер для этого User-Agent не стоит — директива сигнальная, а не обязательная к исполнению, и для гарантированного результата нужны серверные правила или блокировка на уровне TrafficVeil.
Нагрузка на сервер: на что реально смотреть
Поскольку сам по себе запрос — разовая проверка одной страницы, единичное обращение W3C_Validator погоды не делает. Риск возникает, когда сторонний инструмент массово прогоняет через валидатор весь список URL сайта (например, из sitemap.xml) за короткий промежуток времени: тогда в логах видна волна запросов с одинаковым User-Agent и без единой пользовательской сессии между ними. Стоит обращать внимание на: рост RPS без роста конверсий, повторяющиеся обращения к одним и тем же тяжёлым страницам за минуты, и совпадение всплеска по времени с публикацией новой партии URL (частый триггер — QA-чеклист перед деплоем или сторонний SEO-аудит, заказанный без ведома команды разработки).
Как найти бота в логах
Базовые команды для поиска активности по этому User-Agent:
# Все запросы
grep -i "w3c_validator" /var/log/nginx/access.log
# Количество запросов за сегодня
grep -i "w3c_validator" /var/log/nginx/access.log | grep "$(date '+%d/%b/%Y')" | wc -l
# Уникальные IP
grep -i "w3c_validator" /var/log/nginx/access.log | awk '{print $1}' | sort -u
# Частота по часам
grep -i "w3c_validator" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -cОтдельно стоит искать и полную строку W3C_Validator/1.3 (http://validator.w3.org/services) — часть логов пишет User-Agent целиком, и короткий паттерн можно пропустить, если сравнение регистрозависимое.
Верификация: User-Agent легко подделать
Официального публичного списка IP-адресов W3C не публикует — сервис прямо предлагает блокировать по IP или по строке User-Agent на своё усмотрение, но готового реестра адресов для сверки нет. Поэтому для важных решений стоит дополнительно проверить IP через ASN и обратный DNS:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"Если обратный DNS не указывает на инфраструктуру, связанную с w3.org, а частота запросов нетипично высокая — вероятно, это подделанный User-Agent, а не настоящий валидатор.
Блокировка через robots.txt
# Полная блокировка
User-agent: w3c_validator
Disallow: /
# Точечное ограничение
User-agent: w3c_validator
Disallow: /admin/
Disallow: /cart/
Disallow: /account/
Allow: /
# Разрешить полностью
User-agent: w3c_validator
Allow: /Как показано выше, эта директива относится только к основному Markup Validator. Если нужно закрыть и Link Checker, добавьте отдельный блок с User-agent: W3C-checklink — для него, в отличие от основного валидатора, соблюдение robots.txt задокументировано официально, так что директива сработает надёжнее.
Управление на уровне сервера
Nginx — жёсткая блокировка или мягкое ограничение частоты:
if ($http_user_agent ~* "w3c_validator") {
return 403;
}
# Мягкий вариант — rate limit
limit_req_zone $binary_remote_addr zone=w3c-validator:10m rate=15r/m;
location / {
if ($http_user_agent ~* "w3c_validator") {
limit_req zone=w3c-validator burst=30 nodelay;
}
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} w3c_validator [NC]
RewriteRule ^ - [F,L]Rate-limit обычно предпочтительнее полного 403 для разовых всплесков: он гасит пиковую нагрузку от массовой проверки URL, но не мешает разработчику вручную проверить одну страницу, когда это действительно нужно.
Управление через TrafficVeil
- Откройте список известных ботов в панели домена или в разделе
/system/bots. - Найдите
w3c_validator/W3C_Validator. - Поставьте категорию «запретить» или оставьте разрешённым согласно политике сайта.
- При необходимости используйте массовые операции allow/deny без правки origin-сервера.
- Проверьте логи: запросы должны уходить в блок или лимит согласно выбранной политике.
Поскольку сервисы W3C формально относятся к разным User-Agent, для полного контроля над всей линейкой валидаторов имеет смысл проверить в панели и соседние записи — по CSS-, ссылочному и i18n-валидатору, — а не только по основному имени.
Похожие боты и сервисы для сравнения
| Бот | Кластер | User-Agent | Метка |
| 2ip Bot | Прочие краулеры и сервисы | 2ip bot | легитимный |
| AccessStatus | Прочие краулеры и сервисы | accessstatus | легитимный |
| AddThis.com | Прочие краулеры и сервисы | addthis.com | легитимный |
| Agent | Прочие краулеры и сервисы | agent | легитимный |
| AgentReadinessScanner | Прочие краулеры и сервисы | agentreadinessscanner | легитимный |
Итоговая стратегия
| Цель сайта | Рекомендация |
| QA-проверка своей же вёрстки нужна регулярно | Разрешить в TrafficVeil, не трогать robots.txt |
| Бот не нужен и создаёт лишнюю нагрузку | Disallow + запрет в TrafficVeil или 403 на nginx/Apache |
| Доступ нужен, но беспокоит частота при массовых проверках | Rate-limit вместо полной блокировки |
| Нежелательная сторонняя проверка по базе TrafficVeil | Запретить в /system/bots и отслеживать по логам |