Silktide в логах почти всегда означает не постороннего бота, а собственный инструмент контроля качества сайта — либо вашей команды, либо клиента, который заказал у вас разработку и сам подключил мониторинг. Silktide (Silktide Ltd) — известная платформа веб-governance, которую используют компании из списка Fortune 500, госорганы, здравоохранение и вузы для автоматической проверки доступности, качества контента, SEO, UX и приватности данных.
1. Что такое Silktide на самом деле
Silktide — это не разовый скрипт, а полноценная enterprise-платформа веб-governance. Её бот регулярно сканирует сайт и проверяет его по WCAG 2.0/2.1/2.2 (стандарт цифровой доступности, закреплённый законодательно в Великобритании, ЕС и ряде других стран), а также по критериям качества контента, SEO и UX. По собственным данным Silktide, автоматические проверки покрывают 40.8% критериев WCAG 2.2 AA, а вместе с полуавтоматическими (assisted) проверками — 75.5%; оставшееся требует ручного тестирования.
Ключевой практический факт: обход сайта Silktide-ботом не бывает случайным. Согласно официальному описанию, бот посещает сайт, потому что кто-то — чаще всего сама организация-владелец сайта или её подрядчик — сознательно настроил Silktide на мониторинг именно этого домена. Это тот же принцип, что и у MainWP: трафик почти всегда означает вашу же инфраструктуру контроля качества, а не постороннего игрока.
| Параметр | Значение |
| Название | Silktide (SilktideBot) |
| Оператор | Silktide Ltd — официально подтверждённый оператор, silktide.com |
| Роль | Автоматический аудит сайта: доступность (WCAG), качество контента, SEO, UX, приватность данных |
| User-Agent / паттерн | Обычный Chrome-подобный UA с добавленным токеном Silktide в конце, например: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36 Silktide |
| Кто обычно настраивает | Сама организация-владелец сайта или её подрядчик/агентство — не случайный третий игрок |
| Паттерн трафика | Периодические проверки с интервалами, близкими к cron-расписанию, либо разовые интенсивные сканирования; обычно ограничен конкретным набором страниц или всем сайтом целиком по настройке заказчика |
| robots.txt | Официально не считается соблюдающим — запись стоит дублировать серверной блокировкой |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем Silktide приходит на сайт
- плановый аудит доступности по WCAG — например, перед юридической проверкой или как часть регулярного governance-процесса организации;
- мониторинг качества контента и SEO — часть комплексного governance-пакета, который используют крупные организации для контроля множества страниц;
- проверка приватности данных — Silktide заявляет это как отдельное направление сканирования, отличающее его от узкоспециализированных accessibility-чекеров;
- разовый ручной запуск через браузерное расширение Silktide, если кто-то из команды тестирует конкретную страницу вручную — в этом случае визит будет единичным, а не частью регулярного расписания.
Типичный кейс: в логах фиксируются регулярные заходы Silktide на один и тот же набор страниц с интервалом, близким к расписанию — это ожидаемое поведение enterprise-инструмента governance, а не аномалия. Прежде чем реагировать как на нежелательный фон, стоит спросить у команды или клиента, не их ли это собственный аудит.
3. Нагрузка и риски
Поскольку Silktide — легитимный, официально задокументированный инструмент с известным оператором, прямого риска для контента (republishing, скрытый сбор данных) практически нет. Основной риск — операционный: если аудит настроен без ведома технической команды сайта (например, клиент подключил Silktide самостоятельно, не предупредив хостинг/разработчика), регулярные сканирования могут восприниматься как непонятный фоновый шум и создавать путаницу в аналитике.
Как и у MainWP, здесь первый диагностический шаг отличается от типичного для «прочих краулеров»: вместо анализа ASN эффективнее сразу спросить у клиента или команды, не подключён ли Silktide намеренно, прежде чем переходить к техническим мерам.
4. Как найти Silktide в логах
# Базовый поиск
grep -i "silktide" /var/log/nginx/access.log
# Топ URL, которые проверяет Silktide
grep -i "silktide" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA
grep -i "silktide" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Регулярность — плановый аудит обычно идёт близко к cron-расписанию
grep -i "silktide" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c
Верификация. У Silktide нет опубликованного криптографического способа подтвердить подлинность запроса — совпадение UA считается лишь косвенным признаком, как и у большинства сервисных ботов. Более надёжный первый шаг здесь — не техническая проверка, а прямой вопрос клиенту или команде, заказан ли такой аудит:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"
5. robots.txt для Silktide
# Жёсткий запрет
User-agent: Silktide
Disallow: /
# Разрешить всё — если аудит нужен и заказан
User-agent: Silktide
Allow: /
# Компромисс: закрыть личный кабинет и служебные разделы, оставить публичные страницы под аудитом
User-agent: Silktide
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /account/
Disallow: /api/
Allow: /
Поскольку Silktide официально не считается соблюдающим robots.txt, для гарантированного результата запись стоит дублировать блокировкой на уровне сервера.
6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "silktide") {
return 403;
}
Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} silktide [NC]
RewriteRule ^ - [F,L]
TrafficVeil:
- прежде чем блокировать — уточните у клиента или команды, не настроен ли Silktide намеренно как часть governance-процесса;
- если аудит нужен и заказан — allow, дополнительно ограничивать не требуется;
- если это действительно посторонний трафик (например, конкурент или третье лицо проверяет ваш сайт через собственную подписку Silktide без вашего ведома) — Disallow и блокировка в TrafficVeil обоснованы;
- после изменения сверьте логи и, если применимо, уточните у клиента, не пропали ли его собственные отчёты по доступности.
7. Что делать: короткий алгоритм
- Первый шаг всегда один: спросить у клиента/команды, не заказан ли аудит Silktide сознательно — это быстрее и надёжнее, чем техническая диагностика;
- Аудит заказан — allow, не трогать;
- Аудит не заказан, источник действительно посторонний — Disallow + запрет в TrafficVeil;
- Нагрузка от регулярных проверок заметна, но аудит нужен — обсудите с клиентом частоту сканирования на его стороне, а не блокируйте технически;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать Silktide
| Бот / сосед | Кластер | Комментарий |
| AccessStatus | Прочие краулеры и сервисы | Мониторинг HTTP-статусов (аптайм) — уже с сайтов, а не полноценный governance-аудит по WCAG/SEO/приватности |
| AlertSite (SmartBear) | Прочие краулеры и сервисы | Синтетический мониторинг доступности и производительности — похожая логика «настроено кем-то из вашей организации» |
| Acquia Optimize (Monsido) | Прочие краулеры и сервисы | Прямой конкурент Silktide — тоже платформа веб-governance с той же моделью «свой, а не чужой» трафик |
| 2ip Bot | Прочие краулеры и сервисы | легитимный, но принципиально другая модель — сторонний сервис без привязки к конкретному владельцу сайта |
9. Стратегия allow/deny для Silktide
| Ситуация | Действие |
| Аудит заказан клиентом или командой сознательно | Allow — это часть их governance-процесса |
| Непонятно, кто и зачем подключил Silktide | Сначала уточнить у клиента/команды, прежде чем блокировать технически |
| Точно посторонний источник, аудит не заказан | Disallow + запрет в TrafficVeil |
| Аудит нужен, но частота сканирования мешает | Обсудить настройку расписания на стороне клиента, а не резать технически |
| Подозрение на подделку UA | Криптографической верификации нет — полагайтесь на прямое уточнение у клиента, а не только на IP/ASN |