Рано или поздно с этим сталкивается любой, кто настраивает автоматический сбор контента из внешних источников: вчера лента исправно приносила статьи, а сегодня источник вдруг молчит. Первая мысль обычно паническая — "источник сломался, всё, автопилот встал". На практике в девяти случаях из десяти это не поломка, а защита сайта: он просто увидел не браузер человека, а автоматический запрос, и решил не отдавать контент.
Разница между "источник действительно недоступен" и "источник временно защищается от ботов" — принципиальная. Во втором случае система не должна сдаваться после первой неудачи, потому что за одной и той же блокировкой может стоять что угодно: от простого таймаута до продвинутой антибот-системы, которая проверяет поведение браузера. Мы в Telematic строили сбор контента с расчётом именно на такие ситуации, а не на идеальный мир, где каждый сайт всегда отдаёт чистый HTML по первому запросу.
Ниже — как это устроено внутри и что это значит для человека, который просто хочет, чтобы в проект каждый день приходил свежий материал, а не бесконечные ошибки в журнале запусков.
//Почему источники вообще блокируют сбор
Большинство сайтов, особенно новостных и отраслевых, давно живут под давлением ботов: одни воруют контент, другие накручивают трафик, третьи просто перегружают сервер частыми запросами. Ответ индустрии — многоуровневая защита: от простых лимитов запросов с одного IP до сложных проверок, которые анализируют, ведёт ли себя "посетитель" как настоящий браузер — исполняет ли JavaScript, двигает ли курсор, грузит ли шрифты и картинки в правильном порядке.
Для системы автосбора это означает, что нельзя полагаться на один способ получения страницы. То, что сработало вчера, завтра может быть заблокировано — не потому что источник закрылся, а потому что защита стала строже, или система заметила паттерн запросов и временно занесла его в подозрительные.
//Три уровня получения страницы
Именно поэтому сбор контента в Telematic не останавливается после первой неудачи, а последовательно проходит через несколько уровней получения страницы, прежде чем признать источник по-настоящему недоступным:
- Простой запрос. Самый быстрый и дешёвый способ — прямое обращение к странице без эмуляции браузера. Подходит для большинства открытых сайтов и RSS-лент, где никакой защиты нет вовсе.
- Эмуляция браузера. Если простой запрос отбит или возвращает пустую/обрезанную страницу, в игру вступает полноценный браузерный движок, который исполняет JavaScript, подгружает динамический контент и ведёт себя как настоящий пользовательский визит.
- Продвинутый обход маскировки. Для источников с наиболее агрессивной антибот-защитой применяется более глубокий уровень, имитирующий сетевой и поведенческий отпечаток обычного клиента — вплоть до того, как выглядит сетевое рукопожатие запроса.
Только если материал не удаётся получить ни на одном из этих уровней, источник помечается как временно недоступный, а не как "сломанный навсегда". Это принципиально: разовый сбой сети или временная блокировка не должны обнулять источник, который до этого месяцами исправно работал.
//Что происходит с материалом, который всё-таки собрался
Получить страницу — только половина дела. Дальше в игру вступает тематический фильтр контента: если в проекте настроена тематика, система на уровне проекта отсеивает материалы, которые формально пришли из источника, но не подходят по смыслу — например, отраслевая лента вдруг публикует рекламный пресс-релиз или материал не по теме канала. Это происходит ещё до того, как контент попадает в дорогостоящую переработку ИИ, что экономит и токены, и внимание человека, который иначе разгребал бы черновики "не в тему".
То, что прошло фильтр, дальше проверяется по порогам авто-анализа: система сама решает, какие материалы достаточно уверенно соответствуют критериям проекта, чтобы автоматически пойти дальше по конвейеру, а какие — остаются черновиком для ручной проверки. Это не бинарный переключатель "доверять источнику или нет", а настраиваемая граница уверенности, которая позволяет автоматизировать очевидные случаи и оставлять человеку решение в спорных.
//Наш опыт: когда источник "упал" не по нашей вине
У нас был показательный случай во время тестирования: один из отраслевых сайтов, который стабильно давал материал по несколько недель, вдруг за один день перестал отдавать что-либо, кроме заглушки с капчей. Первая реакция — списать источник в мёртвые и удалить его из проекта. Но при проверке оказалось, что сайт просто включил более жёсткую защиту после волны массового скрапинга со стороны каких-то третьих сервисов — досталось всем, кто ходил на сайт автоматически, включая нас.
Именно многоуровневый подход спас ситуацию: простой запрос действительно перестал работать, но эмуляция браузера продолжала получать страницу нормально, потому что защита в первую очередь резала самые примитивные запросы без признаков реального браузера. Если бы система сдавалась после первого же уровня, источник ушёл бы в разряд "недоступных" совершенно незаслуженно — а материал продолжал спокойно собираться.
Бывает и обратная ситуация: источник в какой-то момент включает защиту настолько серьёзную, что не проходит ни один уровень. В таких случаях система честно фиксирует источник как недоступный, вместо того чтобы бесконечно "стучаться" в закрытую дверь и тратить на это ресурсы. Это тоже осознанный выбор: лучше явно показать в журнале запусков, что источник требует внимания, чем маскировать проблему бесконечными молчаливыми повторами.
//Что это значит для владельца проекта
Практический вывод простой: если в журнале запусков источника вы видите единичный сбой сегодня, это ещё не повод паниковать и переносить всю ленту в другой сервис или вручную перепроверять настройки. Система уже прошла путь от простого запроса до продвинутого обхода, прежде чем сообщить о проблеме — то есть к моменту, когда вы видите ошибку, действительно стоит присмотреться к источнику внимательнее.
Стоит настроить тематический фильтр как можно точнее с самого начала — это экономит не только время на ручную модерацию, но и токены, которые иначе тратились бы на переработку материалов не по теме. А пороги авто-анализа лучше сначала выставить консервативно и постепенно ослаблять по мере того, как вы видите, что автоматически принятый контент действительно соответствует ожиданиям — так автопилот набирает доверие постепенно, а не одним резким переключением.
В конечном счёте задача этого механизма — снять с человека рутинную нагрузку "проверить, живой ли ещё источник", оставив ему только содержательные решения: стоит ли материал публикации, подходит ли тон, нужна ли ручная правка. Всё, что касается технической доступности сайта, система старается решить сама, прежде чем побеспокоить владельца проекта.