Scrapy‑разработка окупается не на каждом проекте, и за годы коммерческого парсинга я не раз убеждался: половину задач быстрее закрыть на BeautifulSoup, а вторую половину без Scrapy не вытянуть в нормальные сроки. Ниже - как я выбираю между ними на боевых заказах: сбор цен для магазина на WooCommerce, трекинг посылок СДЭК, выгрузка каталога в Telegram‑бота на aiogram. Без религиозных войн, по фактам - где какой инструмент экономит дни, а где добавляет лишней возни.
Библиотека для веб‑скрапинга против фреймворка: в чём разница по сути
BeautifulSoup - библиотека для разбора HTML и XML. Ей на вход даёшь готовую строку разметки, она строит дерево, и ты достаёшь нужные узлы через CSS‑селекторы или поиск по тегам. Сама она ничего не качает - рядом стоит requests или httpx, которые делают запросы. Всё синхронно, линейно, предсказуемо.
Scrapy - фреймворк для веб‑скрапинга целиком. Внутри уже есть асинхронный движок на Twisted, планировщик запросов, очередь, повторные попытки на таймаутах, пайплайны для сохранения данных, middleware для прокси и заголовков, соблюдение robots.txt и троттлинг. Ты не собираешь скрипт из кусков - пишешь паука по готовой структуре, а инфраструктуру фреймворк берёт на себя.
Разница видна на объёме. Собрать 40 карточек товара с одной страницы на Tilda - работа для BeautifulSoup на 20 строк. Обойти каталог из 60 000 SKU с пагинацией, фильтрами и ретраями - территория Scrapy. Вот минимальный сбор цены на requests и BeautifulSoup:
import requests
from bs4 import BeautifulSoup
html = requests.get("https://shop.example/product/123", timeout=10).text
soup = BeautifulSoup(html, "lxml")
name = soup.select_one("h1").get_text(strip=True)
price = soup.select_one(".price").get_text(strip=True)
print(name, price)Этого достаточно, чтобы раз в сутки снимать цену с пары сотен товаров. Дальше начинаются нюансы, ради которых люди и уходят на Scrapy.
Таблица: Scrapy или BeautifulSoup под конкретную задачу
| Критерий | BeautifulSoup + requests | Scrapy |
|---|---|---|
| Порог входа | Низкий, читается за вечер | Средний, нужно понять пауков и пайплайны |
| Асинхронность | Нет из коробки (руками через httpx/asyncio) | Да, движок асинхронный по умолчанию |
| Объём страниц | До нескольких тысяч комфортно | Десятки и сотни тысяч без переписывания |
| Ретраи, троттлинг, прокси | Пишешь сам | Встроено, включается настройками |
| Экспорт данных | CSV/JSON руками | Пайплайны в JSON, CSV, БД |
| Когда избыточен | Почти никогда | На разовой выгрузке одной страницы |
Я держу это правило в голове так: если задача помещается в один файл и запускается пару раз - BeautifulSoup. Если это регулярный обход большого сайта с рисками блокировок - Scrapy.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Когда я беру BeautifulSoup и не усложняю
Большая часть входящих заказов на парсинг - небольшие. Клиенту с магазином на WooCommerce нужно было раз в сутки сверять свои цены с тремя конкурентами, примерно по 300 позиций у каждого. Я собрал скрипт на requests и BeautifulSoup, записал результат в CSV и Google Sheets, а расписание и уведомление в Telegram повесил на n8n. Вся работа заняла день, Scrapy тут не дал бы ничего, кроме лишней обвязки.
Второй типовой случай - точечный запрос к одному эндпоинту. Трекинг СДЭК по номеру заказа: один POST, разбор ответа, отдача статуса в aiogram‑бота. Отдельный краулер под такое городить незачем - httpx плюс разбор, и готово.
Коротко, BeautifulSoup я выбираю, когда совпадает несколько условий:
- объём - до нескольких тысяч страниц или разовая выгрузка;
- сайт отдаёт готовый HTML, без жёсткого антибота;
- данные уходят в простой формат - CSV, таблица, запись в бота;
- логика линейная, без хитрой навигации по каталогу.
На Tilda‑скриптах это особенно заметно: там чаще нужно вытащить заявки из встроенной формы или подтянуть внешний прайс на страницу - маленькие задачи, где тяжёлый фреймворк только мешает.
Когда нужна разработка паука на Scrapy
Как только появляется слово «регулярно» и «весь каталог», я перехожу на Scrapy. Классический пример - обход маркетплейса или крупного интернет‑магазина: 50-70 тысяч карточек, пагинация, категории, у части товаров подгрузка характеристик отдельным запросом. На requests это превращается в самодельный планировщик с очередью и ретраями - по сути, переписывание Scrapy своими руками и хуже.
Паук на Scrapy для такой задачи выглядит компактно, а всё тяжёлое делает фреймворк:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
start_urls = ["https://shop.example/catalog"]
def parse(self, response):
for card in response.css(".product-card"):
yield {
"name": card.css("h3::text").get(),
"price": card.css(".price::text").get(),
"url": card.css("a::attr(href)").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield response.follow(next_page, self.parse)Сверху навешиваются пайплайны: чистка данных, дедупликация по артикулу, запись в PostgreSQL. На проекте, где клиент строил свою витрину поверх чужого каталога, такой краулер собирал около 60 000 позиций за 25-30 минут и складывал их сразу в базу, откуда витрину и наполняли.
Ещё разработка паука на Scrapy оправдана, когда обход нужно делить на потоки, ставить на расписание и мониторить падения. Планировщик, повторные попытки и статистика по запросам уже встроены - не нужно изобретать инфраструктуру под каждый новый источник.
Скорость, антибот и прокси: где выбор ломается
Самый частый триггер перехода на Scrapy - не объём, а защита сайта. Когда источник режет по частоте запросов или отдаёт капчу, начинается работа с прокси, заголовками и задержками.
В Scrapy это настройки, а не отдельный велосипед. AutoThrottle сам подстраивает задержку под ответы сервера, ротацию прокси вешаешь через middleware, конкурентность крутишь параметрами CONCURRENT_REQUESTS и DOWNLOAD_DELAY. Для сайтов, где контент рисует JavaScript, подключаю scrapy‑playwright - паук получает уже отрендеренную страницу и разбирает её теми же селекторами.
На BeautifulSoup тот же результат достижим, но всё это ты пишешь вручную: пул прокси, обработку 429, паузы, при необходимости - связку с Selenium или Playwright для рендеринга. Для небольшого объёма терпимо. Для десятков тысяч страниц под антиботом ручная обвязка съедает всю экономию на «простой библиотеке».
Отдельно про скорость: синхронный requests качает страницы по одной. Даже при 200 мс на запрос 30 000 страниц - это часы. Асинхронный движок Scrapy при десятке параллельных запросов укладывает то же в минуты, и это не считая того, что не приходится сторожить процесс.
Сколько стоит и сколько занимает написание парсера
По срокам разброс большой и зависит именно от того, что описано выше. Простой сбор на BeautifulSoup с выгрузкой в таблицу я закрываю за 1-2 дня. Полноценный краулер на Scrapy с прокси, пайплайнами в базу и постановкой на расписание - обычно от недели, если сайт сопротивляется - дольше.
Парсинг и автоматизацию на Python я делаю от 20 000 ₽ - сюда попадает большинство задач на BeautifulSoup и несложные пауки. Крупный проект с антиботом, прокси и интеграцией в CRM ближе к комплексной работе, и цена стартует выше базовой. Если нужно ещё расписание и уведомления, добавляется автоматизация в n8n от 25 000 ₽. Для сравнения: на рынке у студий и на фрилансе за такие краулеры просят где угодно в диапазоне 30 000-150 000 ₽ - это рыночный ориентир, а не мои расценки.
Часть типовых сценариев не требует разработки с нуля - цены конкурентов, трекинг доставки, выгрузка каталога уже собраны, и их быстрее адаптировать под источник, чем писать заново. Если задача стандартная, я предлагаю стартовать с готовыми скриптами парсинга из моей библиотеки и допилить их под конкретный сайт - так дешевле и быстрее.
Мой практический ориентир по выбору держится на трёх вопросах: сколько страниц, как часто и насколько зол антибот. Один‑два ответа «мало / разово / никак» - BeautifulSoup. Хотя бы два «много / регулярно / жёстко» - Scrapy, и обычно это окупается уже на второй неделе эксплуатации.
Данные и процессы на автопилоте
Парсинг / Автоматизация
от 20 000 ₽
Подробнее →Частые вопросы
Можно ли собрать динамический сайт на BeautifulSoup?
Напрямую нет - BeautifulSoup разбирает только тот HTML, что ей дали, а на JS‑сайтах данных в исходной разметке ещё нет. Нужен рендеринг через Selenium или Playwright, который отдаст готовую страницу, а её уже парсит BeautifulSoup. В Scrapy для этого есть scrapy‑playwright, и в связке с фреймворком это удобнее на объёме.
Scrapy сложнее в поддержке, чем скрипт на BeautifulSoup?
На старте - да, структура пауков и пайплайнов требует времени на освоение. Зато на дистанции поддерживать большой краулер на Scrapy проще: ретраи, логи и статистика уже стандартизированы, и не приходится вспоминать, как ты руками собирал очередь запросов полгода назад.
Что выбрать, если сайт маленький, но парсить надо каждый час?
Смотрю на защиту источника. Если антибота нет, хватит скрипта на BeautifulSoup, поставленного на расписание через cron или n8n. Если сайт режет частые запросы, даже на маленьком объёме удобнее Scrapy с троттлингом и прокси - меньше блокировок и падений.
Законно ли парсить чужой сайт?
Сбор общедоступных данных сам по себе не запрещён, но границы задают условия использования сайта, robots.txt и характер данных - персональные и защищённые авторским правом трогать нельзя. Я всегда обсуждаю с клиентом источник и цель до старта и настраиваю разумные задержки, чтобы не создавать нагрузку на чужой сервер.