Классификация сайта отвечает на вопрос «какой тип ресурса мы наблюдаем», а не «можно ли ему доверять». Для каталога партнёров это может быть интернет-магазин, СМИ, SaaS, государственный портал или личный блог. Для команды безопасности нужны другие метки: форма входа, платежи, загрузка файлов, техническая документация или редирект. Для маркетинга важны отрасль, язык и коммерческое намерение. Одна универсальная категория редко работает одинаково хорошо для всех задач, поэтому сначала определите, какое решение будет зависеть от результата. Затем выберите таксономию, допустимый уровень неизвестности и способ ручной проверки спорных сайтов.
Категория не равна репутации
Сайт может быть классифицирован как финансовый, но при этом иметь неизвестную репутацию. Страница новостей может быть легитимной, даже если её сервер временно возвращает ошибку. Парковочная страница может не содержать вредоносного контента, однако не подходить для партнёрской программы. Если система смешивает категорию, доступность, риск и принадлежность, одно неточное поле начинает управлять важными действиями. В схеме результата держите эти измерения раздельно. Полезны значения category, confidence, evidence, checked_at и classification_status. При timeout, блокировке или пустом ответе возвращайте unknown, а не самую популярную категорию. Это позволяет бизнесу решить, нужна ли повторная проверка или ручная оценка.
Создайте таксономию под рабочую задачу
Слишком общие классы вроде «сайт» и «не сайт» мало помогают. Слишком подробное дерево превращает каждую новую страницу в спор о термине. Начните с десяти или двадцати классов, которые меняют действие команды. Например, для продаж полезны ecommerce, B2B service, media, education и public sector. Для безопасности добавьте login, payment, download, redirect, parked и unknown как отдельные наблюдаемые признаки. Разрешите несколько меток, если сайт совмещает магазин, блог и документацию, но задайте одну основную категорию для фильтров. В описании класса приведите положительные и отрицательные примеры. Так аналитик будет понимать, почему документация относится к software, а не к media, даже если на ней есть статьи.
- Опишите, какое действие зависит от категории.
- Разделите основную категорию и дополнительные признаки.
- Добавьте unknown и not_requested.
- Запишите примеры, границы и исключения.
- Определите, когда нужен человек.
- Назначьте владельца таксономии и дату пересмотра.
Какие сигналы помогают классификации
Классификатор может использовать URL, заголовок, видимый текст, метаданные, редирект, язык, DNS и технический профиль. Каждый сигнал имеет ограничения. Заголовок можно подделать, robots.txt может скрыть разделы, а общий шаблон может встречаться у тысяч компаний. DNS помогает найти mail и API-хосты, но не описывает содержимое главной страницы. Технология CMS говорит о реализации, а не об отрасли. Поэтому полезно соединять независимые наблюдения и хранить evidence для решения. Не добавляйте скрытый внешний источник без проверки стоимости, условий и свежести. Если источник не объясняет свою уверенность, не выдавайте внутреннее число за объективную вероятность.
Для русскоязычного рынка добавьте язык и регион как отдельные поля, а не встраивайте их в название категории. Сайт на русском может обслуживать несколько стран, а домен .ru не доказывает местонахождение компании. Кириллический домен требует нормализации формы и осторожного сопоставления с латинскими вариантами. Автоматически переводить название отрасли в другой язык не стоит без словаря, утверждённого владельцем продукта. Лучше хранить стабильный код класса и отображать локализованную подпись на уровне интерфейса. Это облегчает аналитику и не ломает отчёты при изменении редакционного термина.
Проверьте качество на реальных примерах
Тестовый набор должен включать известные сайты каждой категории, смешанные проекты, домены с редиректом, пустые страницы, парковку, ошибку DNS и защищённые разделы. Не измеряйте качество только на популярных доменах. Малый сайт партнёра и новый продукт клиента могут выглядеть иначе, чем лидеры рынка. Зафиксируйте эталонную метку и источник человеческой оценки, затем сравните предсказание. Ошибки первого рода и второго рода имеют разную цену: неверная блокировка партнёра может стоить сделки, а пропуск неизвестного сайта требует дополнительного просмотра. Периодически пересматривайте спорные примеры, потому что содержимое и назначение домена меняются. История решений помогает улучшить таксономию без обвинения конкретного источника.
Используйте результат в CRM и безопасности
В CRM категория может выбрать шаблон карточки, маршрут менеджера или отраслевой фильтр. В закупках она помогает отделить потенциальных поставщиков от медиа и технических доменов. В безопасности метки login, payment и download могут направить ресурс на дополнительную проверку, но не должны автоматически объявлять его вредоносным. Для мониторинга полезно реагировать на смену категории: корпоративный домен внезапно стал редиректом или парковкой. Такой сигнал требует повторной проверки и понимания, а не немедленного блокирования. Сохраняйте предыдущую категорию, новую категорию, дату и доказательство изменения. Это делает автоматизацию объяснимой для поддержки и аудита.
- Принять список канонических URL.
- Проверить формат и доступность.
- Собрать наблюдаемые сигналы.
- Вернуть основную и дополнительные метки.
- Сохранить уверенность, источник и дату.
- Отправить unknown или спорные случаи на повторную проверку.
Пакетная категоризация через API
Когда список содержит сотни или тысячи URL, важны устойчивый контракт и частичные результаты. Очередь должна ограничивать параллелизм, повторять только временные ошибки и не считать обычный 403 доказательством отсутствия сайта. Для каждого элемента храните исходный URL и нормализованный домен, иначе результаты нельзя будет связать с CRM. Разделяйте результат target_response, failed, unknown и cached. Если категория изменена после обновления страницы, показывайте время свежести. Перед запуском в продакшене протестируйте кириллические домены, редиректы, URL с путём, несуществующий хост и сайт с формой входа. В DomScan интерактивный инструмент подходит для проверки отдельных адресов, а Website Categorization API для программного конвейера. Прочитайте документацию и проверьте лимиты до расчёта бюджета.
{
"url": "https://example.ru",
"primary_category": "b2b_service",
"signals": ["contact_form", "product_pages"],
"confidence": "medium",
"status": "classified",
"checked_at": "2026-09-14T09:00:00Z"
}Классификация приносит пользу, когда она помогает принять следующее решение и остаётся честной при неполных данных. Регулярно просматривайте unknown, измеряйте ошибки на свежем эталонном наборе и удаляйте категории, которые ничего не меняют в работе. Не используйте один результат как окончательное доказательство компании, репутации или безопасности. Сочетайте категорию с профилем домена, DNS, регистрационными данными и ручным контекстом. Тогда даже простая метка становится надёжным элементом операционного процесса, а не загадочным числом в таблице.
Владелец таксономии должен управлять изменениями как частью продукта. Перед добавлением нового класса опишите, какое решение он улучшит и чем будет отличаться от соседних классов. Сначала поместите несколько спорных примеров в тестовый набор, затем проведите ручное сравнение с текущим правилом. Если переименование нужно для локализованного интерфейса, не меняйте внутренний стабильный код без миграции отчётов. Отмечайте дату версии таксономии в каждом API-ответе, иначе невозможно понять, почему вчерашний сайт получил другую метку. Для клиентов полезно публиковать краткое описание категорий и ограничений, чтобы они не интерпретировали поле шире, чем оно задумано.
Русскоязычная таксономия должна учитывать локальные формы бизнеса, но не приписывать страну по зоне домена. Интернет-магазин на .ru может продавать в нескольких странах, а сайт на .com может быть российским проектом. Для B2B-исследования добавьте отдельные поля языка интерфейса, региона контактов и юридической регистрации, если они подтверждены. Не называйте сайт государственным только из-за слова в домене или герба на странице. Для СМИ и образовательных проектов полезно различать редакционный сайт, каталог, курс и личный блог, потому что эти категории требуют разных действий. Примеры из российского рынка добавляйте только после ручной проверки, чтобы изменившийся сайт не стал вечным эталоном.
При пакетной обработке используйте очередь с понятным повтором. Входной URL должен пройти проверку схемы и канонизацию, затем получить наблюдаемые признаки с ограниченным временем ответа. Обычный HTTP 403, капча или временный timeout не означают, что сайт относится к неизвестной опасной категории. Сервисная ошибка одного элемента не должна стирать результаты остальных. Возвращайте partial и сохраняйте статус каждого источника. Для важных клиентов добавьте ручную маркировку, которая не перезаписывается следующей автоматической проверкой без аудита. Так команда сможет сравнить автоматический сигнал с экспертным решением и понять, где таксономия требует улучшения.
Проверяйте категории после значительного изменения сайта. Редизайн, смена домена, новый каталог или закрытие раздела могут изменить основной класс, но не должны автоматически создавать инцидент. Сначала покажите diff и причины, затем примените заранее описанное правило. История особенно полезна для партнёрских баз: если домен из B2B service стал parked или redirect, закупщик может остановить дальнейшую проверку. Для SEO и маркетинга храните дату и язык, чтобы не сравнивать прошлогоднюю страницу с сегодняшним шаблоном. Классификация приносит максимальную пользу, когда её результат можно объяснить человеку за минуту.
Особенно осторожно работайте с категориями, которые влияют на доступ или деньги. Метка gambling, finance, health или government может направить сайт в усиленную проверку, но ошибка не должна автоматически блокировать компанию без апелляции. Для таких классов задайте порог уверенности и ручное подтверждение. Учитывайте, что один сайт может обслуживать дочерний проект, витрину и блог одновременно. Разрешите поле secondary_categories и сохраняйте evidence, которое привело к каждой метке. Если содержимое страницы временно недоступно, используйте предыдущий результат только с пометкой stale, а не представляйте его свежим. Это защищает бизнес-процесс от скрытой подмены контекста.
- Версия таксономии
- Код и локализованное название класса
- Основная и дополнительные метки
- Сигналы, приведшие к классификации
- Уровень уверенности и свежесть
- Правило ручной апелляции
Перед выпуском локального отчёта проверьте названия категорий на реальных русскоязычных примерах и исключите двусмысленные слова. Одна и та же страница может быть магазином и медиа, поэтому основная метка должна сопровождаться дополнительной. Показывайте оператору причину и дату, а не только перевод кода. При изменении сайта обновляйте категорию после повторной проверки и сохраняйте предыдущую версию. Так классификация остаётся полезной для бизнеса, даже когда содержимое и язык домена меняются.
Храните решение человека рядом с автоматической меткой, чтобы со временем видеть, какие классы чаще всего требуют пересмотра.
При неизвестном результате не назначайте категорию по умолчанию: создайте повторную проверку или передайте адрес специалисту.
Короткое объяснение рядом с меткой помогает оператору принять решение без повторного чтения всего отчёта.