Обзор ZenRows 2026: реальная цена скрапинга и результаты тестов

ZenRows является облачной платформой для веб-скрапинга, которая получает страницы через API, рендерит JavaScript и управляет прокси и антибот-обработкой. Сервис используют для мониторинга цен, маркетинговых исследований, сбора каталогов и подготовки веб-данных для AI-систем.

Командам, сравнивающим провайдеров инфраструктуры, полезно сопоставить ZenRows с подходом из обзора прокси для сбора данных и AI-проектов. Здесь расходы зависят не только от IP или объема трафика, но также от типа запроса, способа рендеринга и уровня защиты целевой страницы.

Лучше всего это видно на практических сценариях. Обычный HTML-каталог может стоить один базовый кредит, тогда как парсинг Instagram или другой JavaScript-зависимой платформы часто требует браузерной среды, стабильной сессии и проверки полезного содержимого в ответе.

Отдельно учитывайте сетевой слой. В задачах, где важны географическое положение, тип IP и продолжительность сессии, модель ZenRows следует сравнивать с процессом, в котором мобильные прокси объединены с отдельными профилями. Именно на стыке браузера, IP и cookies появляются расходы, которых не видно в цене тарифа.

Этот обзор опирается на актуальные официальные тарифы ZenRows по состоянию на октябрь 2026 года.

Что такое ZenRows и кому подходит платформа

ZenRows подходит командам, которым нужен управляемый доступ к статическим, динамическим или защищенным веб-страницам без развертывания собственного Chromium-кластера. Пользователь передает URL и параметры, а платформа возвращает HTML, Markdown, JSON, текст или снимок страницы в зависимости от выбранного инструмента.

В 2026 году линейка включает Fetch, Extract, Batch, Browser Sessions, CLI, SDK и MCP Server. В официальном описании также фигурирует Crawl. Продукты работают с одной учетной записью и общим балансом кредитов, но единица списания различается. В Fetch списание зависит от сложности получения страницы, в Browser Sessions учитываются минуты и гигабайты, а для Batch действует стоимость соответствующих Fetch-запросов.

Чаще всего ZenRows используют для таких задач:

• собирают цены и остатки товаров из каталогов
• готовят датасеты для AI Training или RAG
• отслеживают изменения на страницах конкурентов
• запускают большие списки URL для асинхронной обработки
• автоматизируют страницы с кликами, формами и авторизацией
• получают данные с сайтов, где обычный HTTP-клиент видит CAPTCHA или страницу блокировки

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

Как построена методика тестирования ZenRows

Корректное тестирование ZenRows проверяет статус ответа, полезное содержимое, задержку и фактическое списание кредитов. В тестировании, на которое опирается обзор, использовали пять типов целей: статическую HTML-страницу, SPA на JavaScript, e-commerce страницу, сайт с DataDome и страницу с авторизацией.

Такой набор удачен, поскольку разделяет разные причины неудачи. Статический сайт показывает базовую задержку сервиса. SPA проверяет JS rendering. Страница интернет-магазина добавляет сложную разметку и антибот. Страница с авторизацией позволяет проверить сохранение cookies, IP и User-Agent в течение сессии.

Для каждого ответа автор опубликованного тестирования применил два критерия:

• HTTP-ответ завершился без транспортной ошибки
• тело содержало маркер, присутствующий только на полезной целевой странице

Второй критерий важнее: проверка только кода статуса не отсеивает антибот-заглушки и страницы входа вместо нужных данных.

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

Практический цикл выглядит так:

1. определите маркер полезного содержимого для каждой цели
2. запустите базовый Fetch без дорогих опций
3. включите JavaScript только для страниц без нужного маркера
4. добавьте premium proxy для целей, которые остались заблокированными
5. повторите каждую конфигурацию серией из 20 или более запросов
6. запишите задержку ответа, кредиты, размер ответа и долю валидных результатов
7. рассчитайте стоимость 1000 полезных страниц, а не 1000 HTTP-ответов

Двадцать запросов не дают статистической гарантии для всего домена, но помогают заметить нестабильность. Перед покупкой крупного тарифа лучше провести тест в разное время, на реальных URL и в том же регионе, который будет использовать рабочий процесс.

Как устроена линейка продуктов ZenRows

Продукты ZenRows отвечают за разные этапы обработки данных. Fetch получает отдельную страницу, Extract структурирует данные, Batch организует обработку больших списков, а Browser Sessions выполняет интерактивный сценарий в удаленном Chromium.

Таблица показывает разные единицы учета: страница, задача, минута сессии и гигабайт трафика не взаимозаменяемы. Разложите будущий процесс на эти единицы, чтобы определить основные статьи расходов и необходимые ограничения в коде.

Fetch для отдельных страниц

Fetch является базовым инструментом. По официальной модели стандартная страница стоит 1 кредит, JavaScript rendering повышает списание до 5, premium proxy до 10, а сочетание обеих опций до 25 кредитов. Поэтому один и тот же баланс может дать в 25 раз разное количество страниц.

Fetch уместен, когда запрос можно описать как URL плюс параметры, а результат не требует длинной цепочки кликов. Для каждого домена используйте самую простую конфигурацию, которая стабильно возвращает нужные данные. Автоматическое включение всех дорогих опций упрощает код, но делает расчет невыгодным.

Extract для структурированных полей

Extract возвращает JSON и устраняет необходимость поддерживать селекторы для предварительно настроенных доменов. Официальная страница цен на дату проверки прямо указывает, что Extract не добавляет стоимости сверх Fetch-запроса. В changelog ZenRows также указано, что подготовка нового домена имеет отдельный месячный лимит и не расходует кредиты.

Структурированный JSON следует проверять на полноту. В исходном тесте e-commerce страницы поле с количеством отзывов было пустым, а URL изображений вели не на нужные фотографии. Структурированный ответ еще не гарантирует правильности данных.

Простой мониторинг может ограничиться Fetch. Extract добавляется после проверки полей, Batch после стабилизации конфигурации, а браузерная сессия остается для URL, где действительно требуется взаимодействие.

Batch для массовых задач

Batch принимает до 100 000 URL в одном задании (job), обрабатывает их асинхронно и возвращает результаты через API, webhook или экспорт. Каждый URL обрабатывается как отдельная задача (task) со статусом и фактическим кодом HTTP-ответа. По официальному описанию Batch не добавляет собственной наценки: списание соответствует параметрам Fetch.

Асинхронная модель полезна для ночного сбора данных из каталогов и регулярного мониторинга. Она также позволяет управлять повторными запросами: можно повторно запустить только неудачные задачи, не оплачивая весь список снова. Для обнаружения скрапинга на стороне целевого сайта быстрый параллельный запуск может быть заметнее, поэтому уровень параллельности нужно подбирать для каждого домена, а не только по лимиту тарифа.

Browser Sessions для интерактивных сценариев

Browser Sessions запускает удаленный браузер, совместимый с Playwright, Puppeteer и другими CDP-клиентами. Он нужен, когда страница требует входа, кликов, прокрутки или многоэтапной формы. Официальная страница продукта указывает лимит одной сессии в 15 минут.

Следует различать сохранение состояния между вызовами и временной лимит сессии. Если сценарий должен жить часами или восстанавливаться на следующий день, проверьте, как повторно загружаются cookies и остаются ли стабильными параметры браузера и его цифровой отпечаток.

Какие результаты показал тест ZenRows

Опубликованное тестирование показало высокую эффективность Fetch на защищенных страницах, но нестабильность длительных сессий и разное качество результатов между продуктами. Эти цифры относятся к конкретным целям и конфигурациям, проверенным 2 октября 2026 года, поэтому для других доменов результаты нужно проверять отдельно.

В таблице показано количество попыток, которые автор тестирования засчитал как успешные, относительно общего количества попыток для каждого продукта и типа цели.

Для Fetch, Extract и Batch результат следует оценивать по наличию нужного содержимого.

Критерии успешности зависят от продукта:

• Fetch, Extract и Batch: наличие нужного содержимого
• Browser Sessions: выполнение тестового браузерного сценария с получением нужного результата
• Residential Proxies: успешность запросов через прокси, а не работы Fetch или Browser Sessions

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

Fetch прошел 19 из 20 попыток на цели с DataDome и все пять e-commerce попыток с JavaScript и premium proxy. Для этой выборки результат высокий. При этом та же конфигурация стоила 25 кредитов за запрос, то есть в 25 раз больше базовой страницы.

В тесте Batch обеспечил меньшее расчетное время на страницу благодаря параллельному выполнению задач. Для 30 URL интернет-магазинов среднее время составило примерно 3,1 секунды на страницу, если общую продолжительность задания разделить на количество страниц. Последовательный Fetch в той же категории имел медиану около 16,2 секунды. Это результат параллельного выполнения, а не ускорения каждого отдельного запроса.

Browser Sessions прошел только 4 из 10 попыток на сайте со сложной антибот-защитой. Сессионный сценарий также зависел от размера страницы, поскольку трафик составлял основную часть списания. Для страницы с небольшим объемом данных это может быть приемлемо. Ресурсоемкая страница с медиа, трекерами и большими скриптами способна существенно увеличить расходы.

В одном из описанных тестов Fetch в сценарии с авторизацией не передал целевому сайту ожидаемый User-Agent. Cookie передавался, но несоответствие User-Agent нарушало привязку сессии. Это наблюдение относится к конкретной конфигурации и не доказывает, что Fetch всегда меняет User-Agent. Этот случай показывает, почему резидентные прокси для AI-поиска и SEO не решают всю задачу самостоятельно: IP, заголовки, cookies и цифровой отпечаток браузера должны работать как согласованный контекст.

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

Сколько стоит ZenRows в 2026 году

Цена ZenRows зависит от плана, типа страницы и доли полезных ответов. При месячной оплате базовые уровни стоят $19 за 45 000 кредитов, $69 за 250 000, $199 за 1,2 млн и $549 за 5 млн. Годовая оплата на официальной странице показывает эквивалент $16, $58, $166 и $458 в месяц.

Цифры в последней колонке являются теоретическим пределом, если каждая страница списывает ровно 25 кредитов и не добавляются Browser Sessions или bandwidth. Они не учитывают повторы на уровне вашего приложения, невалидное содержимое в технически успешном ответе и пополнение баланса.

Реальная цена 1000 страниц

Если распределить полную месячную цену Build на все 45 000 кредитов, расчетная стоимость одного кредита составит около $0,000422. По этой модели себестоимость 1000 базовых страниц равна примерно $0,42, страниц с JavaScript около $2,11, с premium proxy около $4,22, а с обеими опциями около $10,56. Это расчетная доля стоимости тарифа, а не отдельная плата за каждую тысячу запросов. Если часть кредитов не использована, фактическая себестоимость обработанной страницы будет выше.

Для оценки расходов используйте показатель cost per useful page. Если из 1000 оплаченных ответов только 800 содержат нужный маркер, расчетные расходы следует делить на 800, а не на 1000. При полном использовании кредитов Build и неизменной доле валидных ответов себестоимость 1000 полезных страниц с JS и premium proxy составит около $13,20. Это модельная оценка, а не дополнительный счет от ZenRows.

Расчет можно воспроизвести в четыре шага:

1. разделите цену плана на количество кредитов
2. умножьте результат на кредитный множитель конфигурации
3. добавьте стоимость bandwidth и минут Browser Sessions
4. разделите общую сумму на долю ответов с валидным маркером нужного содержимого

Скрытые расходы в кредитной модели

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

На бюджет влияют такие составляющие:

• множитель 5 за JavaScript rendering
• множитель 10 за premium proxy
• множитель 25 при одновременном включении обеих опций
• 25 000 кредитов за каждый ГБ резидентного трафика
• 5 кредитов за минуту Browser Sessions
• оплата ответов 404 и 410 как корректных результатов
• повторы вашего приложения после неудачной проверки маркера нужного содержимого
• время инженера на контроль схемы Extract и восстановление сессий

По описанным правилам ZenRows кредиты не списываются за запросы, которые сервис классифицирует как неудачные. При этом HTTP 404 и 410 могут считаться полученными ответами и оплачиваться. HTTP 200 со страницей блокировки также не следует автоматически считать бесплатной ошибкой: для биллинга важна классификация результата сервисом, а для пользователя наличие нужных данных.

Точный список оплачиваемых статусов и исключений нужно сверять с действующими правилами ZenRows. Именно поэтому собственный валидатор должен находиться после API-ответа и до записи в основную базу.

Чем ZenRows отличается от собственного скрапера и браузерных профилей

ZenRows отличается от собственного скрапера тем, что продает управляемое выполнение, прокси и антибот-обработку как сервис. От браузерных профилей платформа отличается фокусом на получении данных, а не на постоянной изолированной конфигурации браузера для каждой сессии.

ZenRows имеет преимущества в сценариях с большим количеством коротких независимых запросов к URL. Собственный кластер целесообразен, если команда уже поддерживает Playwright, работает с узким набором доменов и хочет полностью контролировать кеш, браузер и сеть. Изолированные профили полезны, когда один браузерный контекст нужно сохранять в течение дней или недель.

Эти подходы можно комбинировать. Например, профиль выполняет вход и сохраняет изолированный контекст, а API-конвейер обрабатывает публичные страницы без авторизации. Считайте их отдельно: запрос Fetch, минута удаленного браузера и час работы собственного обработчика задач являются разными единицами.

Какие риски и ограничения учитывать перед оплатой

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

Перед оплатой крупного плана проверьте:

• свои реальные домены, а не демонстрационные страницы
• долю ответов с валидным маркером нужного содержимого
• кредитный множитель для каждого класса URL
• фактический размер страниц в Browser Sessions
• поведение cookies, IP и User-Agent после повторного подключения
• ограничения concurrency и время выполнения очереди
• правила хранения и экспорта результатов Batch
• процесс миграции при изменении API или цены

Настройте ограничения расходов на уровне приложения. Оно должно останавливать job, когда среднее количество кредитов на страницу с нужными данными превышает порог. Для Batch сохраняйте идентификатор external_id. Это поможет повторно обрабатывать только URL, предыдущие запросы которых завершились ошибкой. Для Browser Sessions блокируйте загрузку ненужных медиа, если это не нарушает работу целевой страницы, поскольку трафик напрямую влияет на списание.

Производственный мониторинг должен отдельно показывать технические сбои API и неудачные проверки содержимого. Это помогает определить, находится ли проблема в ZenRows, разметке сайта или другом компоненте.

Отдельно учитывайте юридические и этические ограничения. Получение технического доступа к странице не означает разрешение собирать и хранить любые данные. Проверяйте условия использования сайта и применимые требования к персональным данным. Храните только необходимые поля, устанавливайте умеренный rate limit и согласовывайте чувствительные сценарии с юристом.

Когда ZenRows оправдывает расходы и как объединить его с Afina

ZenRows оправдывает цену, когда управляемая инфраструктура стоит дешевле собственного браузерного кластера, прокси, очередей и времени инженеров. Лучше всего ZenRows подходит проектам с большим количеством независимых URL, короткими запросами и измеримым маркером нужного содержимого. Длительные авторизованные процессы следует отдельно тестировать через Browser Sessions.

Если для работы нужно сохранять браузерные контексты, использовать отдельные cookies, прокси и цифровые отпечатки браузера для разных задач, Afina можно использовать как слой изолированных профилей, а ZenRows оставить для независимого сбора публичных страниц. Такое разделение не делает скрапинг невидимым и не отменяет правила целевых платформ, но разграничивает два сценария: долгосрочную сессию и массовое получение данных через API. Материал предоставлен исключительно в ознакомительных и образовательных целях.

Начните с Free на 5 000 кредитов и протестируйте 50-100 реальных URL каждого класса по описанной выше методике. Переходите на платный план, когда сможете оценить стабильность получения данных и расходы для своей нагрузки. Такой подход дает более точную оценку затрат, чем ориентация только на указанную в тарифе цену.

Скачать