Writescope в логах сайта: что это за бот и нужно ли его блокировать

Writescope — наблюдаемый идентификатор автоматизированного HTTP-клиента, который может встречаться в access.log в виде токена writescope.

В интернете Writescope регулярно включают в списки AI-ботов, предназначенные для блокировки через robots.txt, Nginx, Apache и другие механизмы. Однако само присутствие имени в таком списке ещё не подтверждает ни оператора, ни конкретное назначение агента.

На момент проверки не удалось найти официальную страницу crawler, техническую документацию, опубликованные IP-диапазоны или иной первичный источник, который позволял бы уверенно сказать:

• кто управляет Writescope crawler;
• используется ли он для AI training;
• работает ли он для inference или retrieval;
• как он относится к robots.txt;
• какая инфраструктура считается официальной.

Поэтому для TrafficVeil правильная начальная классификация — AI-related automated client / Unverified, а не подтверждённый LLM crawler.

Почему Writescope относят к AI-ботам

Токен Writescope присутствует в многочисленных сторонних списках автоматизированных AI-клиентов.

Например, веб-мастера добавляют в единый блок:

User-agent: Writecream
User-agent: WriterZen
User-agent: Writescope
User-agent: Writesonic
Disallow: /

Такие списки полезны для первичного обнаружения новых или малоизвестных User-Agent.

Но они не являются официальной bot directory.

Иными словами:

Writescope присутствует в AI blocklists

не равно:

Writescope официально подтверждён как LLM training crawler

Почему нельзя утверждать, что Writescope забирает контент для обучения LLM

В исходном описании была формулировка:

Writescope забирает публичный текст и структуру страниц для AI-пайплайна оператора.

Это возможно, но без документации оператора является предположением.

Автоматический AI-related клиент может выполнять множество разных задач:

• user-initiated URL fetch;
• анализ статьи;
• SEO-анализ;
• создание summary;
• retrieval;
• импорт контента;
• проверку страницы;
• model training;
• другую внутреннюю функцию.

Пока нет первичного источника, TrafficVeil не должен выбирать один из этих вариантов и выдавать его пользователю как установленный факт.

Почему название Writescope само по себе мало помогает

Поисковые результаты по Writescope не дают устойчивой технической идентичности.

В разных сторонних публикациях этим названием обозначают AI-writing инструменты с разными функциями — от SEO-оптимизации до помощи с художественными текстами.

Это ещё одна причина не связывать User-Agent автоматически с конкретным продуктом.

Что точно означает появление writescope в access.log

Если сервер записал:

User-Agent: Writescope

мы можем уверенно сказать только одно:

HTTP-клиент сообщил серверу, что его User-Agent содержит Writescope.

Это ещё не означает:

• что запрос принадлежит конкретной компании;
• что он является AI training crawler;
• что его нужно разрешать;
• что его нужно блокировать;
• что IP является официальной инфраструктурой Writescope.

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

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

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

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

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

Топ URL:

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

Топ IP:

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

HTTP-коды:

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

Проверьте HTTP-методы

grep -i "writescope" /var/log/nginx/access.log \
| awk -F'"' '{print $2}' \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn

Это поможет увидеть, ограничивается ли агент обычными GET/HEAD или использует неожиданные POST, PUT, DELETE и другие методы.

Проверьте глубину обхода

Количество уникальных URL:

grep -i "writescope" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort -u \
| wc -l

Так можно быстро понять, перед вами несколько on-demand fetch или полноценный обход большого числа страниц.

Какие URL интересуют Writescope

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

Именно поэтому лучше строить профиль на собственных данных TrafficVeil.

Например, если основная активность:

/blog/article-1
/blog/article-2
/news/example

можно предполагать content fetch.

Если:

/
 /pricing/
 /about/
 /docs/

это может быть другой сервисный сценарий.

А если:

/.env
/.git/config
/wp-config.php
/backup.zip
/phpmyadmin/

источник следует оценивать уже как security scanner или spoofed automation.

Почему одного User-Agent недостаточно

User-Agent устанавливает сам клиент.

Простейший скрипт может отправить:

User-Agent: Writescope

Поэтому правило:

writescope → trusted → allow

создаёт простой bypass антибот-защиты.

Как верифицировать Writescope в TrafficVeil

Поскольку официальной схемы проверки не найдено, нужно использовать совокупность сигналов.

• User-Agent;
• IP;
• ASN;
• ASN organization;
• network type;
• reverse DNS;
• TLS fingerprint;
• HTTP fingerprint;
• частоту;
• набор URL;
• HTTP methods;
• историю активности.

Какие сетевые данные стоит хранить

asn
asn_org
network_type
is_datacenter
is_proxy
is_vpn
is_tor

Для недостаточно документированных агентов эти поля особенно ценны.

Например:

Writescope
1 ASN
1 datacenter network
стабильный fingerprint
похожие URL
стабильная частота

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

Writescope
300 ASN
residential proxy
постоянно меняющийся fingerprint
случайные технические URL

Observed IP и Verified IP — не одно и то же

Если TrafficVeil видит UA Writescope с IP:

203.0.113.10

нужно записать:

Observed IP

а не:

Official Writescope IP.

Как выглядит возможный spoofing Writescope

User-Agent: Writescope

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

Такой клиент нужно классифицировать по поведению.

Название AI-сервиса не должно автоматически уменьшать risk score.

Какой behavioural fingerprint использовать

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

Надёжной официальной crawler-policy найти не удалось.

При этом Writescope действительно встречается в многочисленных сторонних robots.txt blocklist:

User-agent: Writescope
Disallow: /

Но это говорит только о том, что веб-мастера пытаются блокировать такой токен.

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

Поэтому:

robots.txt compliance: Unverified

robots.txt для Writescope

Если владелец сайта хочет объявить запрет:

User-agent: Writescope
Disallow: /

Частичная политика:

User-agent: Writescope
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /internal/
Disallow: /api/private/
Allow: /

После изменения обязательно проверьте access.log.

robots.txt не защищает контент технически

Даже если автоматический клиент соблюдает robots.txt, директива не заменяет:

• authentication;
• authorization;
• WAF;
• ACL;
• закрытые API;
• сетевые ограничения.

Если страница действительно приватна, она не должна быть публично доступна независимо от crawler.

Блокировка Writescope через Nginx

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

Это блокировка по заявленному User-Agent.

Она не определяет настоящего оператора.

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

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

Нужен ли Rate Limit

Для плохо документированного агента Rate Limit часто является разумным промежуточным вариантом.

Например:

Identity: Unverified
Behavior: non-malicious
Origin Impact: noticeable

В таком случае:

Rate Limit

может быть логичнее немедленного полного Block.

Но сначала оцените реальную нагрузку

Количество hits само по себе не показывает стоимость crawler.

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

• Requests;
• Unique URLs;
• Unique IP;
• Unique ASN;
• RPS/RPM;
• Bandwidth;
• Average Response Size;
• Cache HIT/MISS;
• Origin Requests;
• Origin TTFB.

Пример

10 000 запросов
98% cache HIT
200 origin requests

могут создавать меньшую нагрузку, чем:

500 запросов
0% cache HIT
500 тяжёлых динамических render

Поэтому TrafficVeil стоит показывать:

Bot Requests + Origin Impact.

Стоит ли автоматически считать Writescope нежелательным

Нет.

Нам не хватает данных, чтобы уверенно заявлять:

Writescope = массовый training crawler

Но также недостаточно данных для:

Writescope = trusted legitimate service

Поэтому наиболее корректный default:

Monitor

Стоит ли относить Writescope к AI-категории

Как предварительную категорию — да.

Токен регулярно встречается именно среди AI-related agents в сторонних blocklist.

Но в интерфейсе я бы написал:

AI-related / Unverified

а не:

Verified AI Training Crawler

Что будет при блокировке Writescope

Точечный Block остановит HTTP-клиентов, которые используют соответствующий UA.

Однако без понимания продукта нельзя уверенно обещать конкретное последствие вроде:

«вы потеряете AI-цитирования»

или:

«контент больше не будет использоваться для обучения модели».

Такие утверждения требуют документации оператора.

Повлияет ли блокировка Writescope на Google

Нет оснований считать Writescope частью Google Search.

Точечная блокировка:

User-agent: Writescope
Disallow: /

не является запретом для:

Googlebot
Googlebot-Image
AdsBot-Google
YandexBot
Bingbot

Как учитывать Writescope в аналитике

Если TrafficVeil подтвердил, что запрос является автоматизацией, он не должен увеличивать human metrics.

Рекомендуемая структура:

Automated Traffic
→ AI-related
→ Unverified Agents
→ Writescope

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

• исключать из Human Traffic;
• не считать конверсией;
• не считать автоматически malicious;
• учитывать в Bot Analytics;
• показывать Identity Confidence;
• показывать Origin Impact.

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

Само сходство названий не означает связь между агентами.

Не стоит использовать одно правило вроде:

write*

потому что оно создаст множество ложных совпадений.

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

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

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

Вместо:

«Writescope — легитимный AI crawler, который собирает ваш контент.»

лучше написать:

Writescope — наблюдаемый автоматизированный User-Agent, который часто включают в списки AI-ботов. Его оператор и точное назначение пока не подтверждены официальной документацией. TrafficVeil рекомендует сначала проверить IP, ASN, URL и нагрузку, а затем выбрать Allow, Rate Limit или Block.

Итог

Writescope существует как наблюдаемый User-Agent и регулярно встречается в сторонних AI-bot blocklists, но этого недостаточно, чтобы считать его подтверждённым LLM-training crawler.

Надёжной официальной документации, IP feed, DNS verification или подтверждённой robots.txt-policy на момент проверки найти не удалось.

Поэтому TrafficVeil лучше использовать статус:

Observed
AI-related
Unverified
Low confidence
Default: Monitor

Дальше решение должно зависеть от фактического поведения. Стабильный безопасный клиент можно оставить под наблюдением или разрешить при наличии пользы. Источник, создающий нагрузку, ограничить. А UA Writescope, используемый для vulnerability scanning или перебора чувствительных файлов, блокировать по реальному поведению независимо от заявленного имени.