Python парсер обычно заказывают не ради самого скрипта, а ради данных, которые он собирает: цены конкурентов, объявления с досок, курсы валют, остатки на складе. По моей практике собирал такие скрипты и для мониторинга цен на WooCommerce-магазины, и для выгрузки объявлений в Telegram-бота на aiogram, и для разовой выгрузки данных под отчёт для бухгалтерии. Стоимость подобных проектов отличается в разы, и разница не в капризе исполнителя, а в составе задач: сколько источников, нужен ли браузер для рендеринга JavaScript, как часто скрипт должен запускаться и куда складывать результат.
Из чего состоит парсер на Python
Любой парсер, простой или сложный, собирается из одних и тех же блоков, просто в упрощённом варианте часть из них можно пропустить.
- Загрузчик страниц. Отправляет запросы к сайту-источнику и получает HTML, JSON из внутреннего API или готовый DOM после рендеринга JavaScript.
- Парсер разметки. Достаёт из полученного HTML нужные поля: цену, название, характеристики, ссылку на карточку товара.
- Логика перехода по страницам. Пагинация, ссылки из каталога, кнопки «показать ещё», иногда скрытый API, который сайт дёргает при подгрузке.
- Хранилище. Файл CSV или JSON для разового сбора, база данных для регулярного.
- Обработка ошибок и повторные попытки. Сайт может отдать таймаут или временно лечь, и скрипт должен пережить это без остановки всего процесса.
- Планировщик. Нужен, если данные должны обновляться регулярно, а не собираться один раз.
Для разовой выгрузки под отчёт хватает первых трёх пунктов и файла на выходе. Для мониторинга цен конкурентов, который крутится месяцами, нужны все шесть, плюс уведомление, если скрипт вдруг перестал получать данные.
Библиотеки для скрапинга и разбора HTML на Python
Для статических сайтов, где данные приходят в готовом HTML без JavaScript, беру связку requests или httpx для запросов и BeautifulSoup или lxml для разбора разметки. Для больших объёмов selectolax работает быстрее BeautifulSoup за счёт парсера на C, и я перехожу на него, когда речь про десятки тысяч страниц за один проход.
import requests
from bs4 import BeautifulSoup
response = requests.get("https://example.com/catalog")
soup = BeautifulSoup(response.text, "html.parser")
for item in soup.select(".product-card"):
title = item.select_one(".product-title").get_text(strip=True)
price = item.select_one(".product-price").get_text(strip=True)
print(title, price)Если данные подгружаются через JavaScript уже после загрузки страницы, ни requests, ни BeautifulSoup не помогут: они видят только исходный HTML без того, что добавили скрипты. Тут нужен headless-браузер, Playwright или Selenium, который открывает страницу как настоящий браузер, дожидается загрузки и только потом отдаёт готовый DOM. Это заметно медленнее и требовательнее к ресурсам сервера, поэтому JS-рендеринг подключаю только когда без него данные физически не достать, а не по умолчанию для любой задачи.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Где хранить и как обрабатывать собранные данные
Для разового сбора хватает CSV или JSON, файл открывается в Excel или таблицах и этого достаточно для отчёта. Для регулярного мониторинга беру SQLite, если скрипт крутится на одном сервере и объём данных умеренный, либо PostgreSQL, если данных много и с ними параллельно работает несколько процессов. База нужна ещё и для дедупликации: чтобы при повторном запуске скрипт не добавлял одни и те же позиции по второму разу, а обновлял их и хранил историю изменений цены или наличия.
Если среди собранных данных попадаются персональные данные, например контакты из объявлений на досках, хранить их лучше на сервере в России, а не в зарубежном облачном сервисе: закон обязывает обрабатывать персональные данные российских граждан на серверах внутри страны.
Перед сохранением прогоняю данные через pandas: убираю дубли, привожу цены к единому формату, если на сайте они записаны вперемешку с валютой и пробелами, и только потом кладу результат в базу или отдаю заказчику готовым файлом.
Что усложняет разработку скрипта и увеличивает сроки
На бумаге любой парсер выглядит одинаково просто: зайти на страницу, забрать данные, сохранить. На практике сроки растягивают несколько вещей.
- Несколько источников с разной вёрсткой. Каждый сайт требует своих селекторов, и парсер для пяти конкурентов это не один скрипт, а пять модулей с общей логикой хранения.
- Авторизация и сессии. Если данные доступны только после входа в личный кабинет, добавляется логика логина, хранения cookies и их обновления.
- Пагинация и подгрузка по скроллу. Бесконечная лента требует эмуляции скролла или поиска скрытого API, который сайт дёргает при подгрузке новых карточек.
- Защита от автоматических запросов. Сайты под Cloudflare или похожими системами ограничивают частоту запросов и блокируют подозрительный трафик. Здесь помогает соблюдение rate-limit и robots.txt, ротация IP через прокси и рандомизация заголовков запроса, чтобы не создавать нагрузку, которая выглядит как атака.
- Изменение вёрстки источника. Сайт обновил дизайн, и селекторы, которые работали месяц, перестают находить нужные блоки. Для регулярных парсеров закладываю в архитектуру алерт в Telegram, если скрипт вернул пустой результат, чтобы заметить поломку сразу, а не через неделю по жалобе клиента.
Сколько стоит и сколько занимает разработка парсера
Ниже примерная вилка по срокам и моя цена в зависимости от сложности задачи, по опыту похожих проектов.
| Сложность | Что входит | Срок | Цена |
|---|---|---|---|
| Разовый сбор с одной страницы | Статический HTML, экспорт в CSV или JSON | 2-3 дня | от 20 000 ₽ |
| Парсер с пагинацией и несколькими источниками | Постраничный сбор каталога, дедупликация, база SQLite | 4-6 дней | от 30 000 ₽ |
| Парсер с JS-рендерингом | Playwright, авторизация, работа с SPA-сайтами | 7-10 дней | от 45 000 ₽ |
| Парсер с расписанием и мониторингом | Планировщик на сервере, ротация прокси, алерты в Telegram | 10-15 дней | от 60 000 ₽ |
Если для регулярного запуска парсеру нужен отдельный сервер, это отдельная строка расходов: обычный хостинг сайта на Tilda или WordPress для запуска Python-скриптов по расписанию не подходит, там нет доступа к cron для произвольных процессов. Сервер требует настройки, обновлений и ежемесячной оплаты, и я закладываю это в оценку отдельно от разработки самого скрипта. Аренда прокси для ротации IP тоже оплачивается отдельно, напрямую у провайдера прокси, и не входит в стоимость разработки.
Как парсер встраивается в автоматизацию бизнес-процессов
Собранные данные редко нужны сами по себе, обычно это часть более крупного процесса. Для интернет-магазинов на WooCommerce беру выгрузку цен конкурентов и завожу правило переоценки: если цена у конкурента упала больше, чем на процент, заданный клиентом, менеджер получает уведомление и решает, снижать ли свою цену. Для агентств недвижимости собираю объявления с нескольких досок в одну таблицу, чтобы не мониторить руками каждый сайт по отдельности.
Готовый результат чаще всего нужно куда-то доставить, а не просто сохранить в базе. Отправку беру на Telegram-бота на aiogram, если заказчику удобнее смотреть сводку в мессенджере, или на связку с автоматизацией в n8n, если данные нужно разложить по нескольким системам сразу: закинуть новые позиции в CRM, отправить уведомление в чат и запустить повторный сбор по расписанию без ручного вмешательства.
Python регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.
Частые вопросы
Сколько парсер проработает без обслуживания, пока сайт-источник не поменяет вёрстку?
Зависит от сайта-источника. Крупные каталоги меняют вёрстку раз в несколько месяцев, небольшие интернет-магазины иногда годами не трогают структуру страниц. На регулярных проектах закладываю проверку раз в квартал, а между проверками полагаюсь на алерт, если скрипт вернул пустой результат.
Можно ли парсить маркетплейсы вроде Wildberries или Ozon?
Технически да, но у крупных маркетплейсов свои условия использования и строгие ограничения на частоту запросов, а часть данных доступна через официальные API для продавцов и партнёров. Перед тем как собирать данные с конкретной площадки, я смотрю, что она сама открывает по API: это надёжнее и не ломается при каждом обновлении дизайна сайта.
Нужен ли отдельный сервер для парсера на Python?
Если парсер запускается один раз и отдаёт файл, сервер не нужен, скрипт можно прогнать локально. Если данные должны обновляться по расписанию, скрипту нужно где-то жить и просыпаться по таймеру, а обычный хостинг сайта на Tilda или WordPress для этого не годится, там не запустить Python-процесс по расписанию. Для таких задач арендуется отдельный сервер, и его обслуживание, обновления и оплата идут отдельно от разработки скрипта.
Что лучше для сбора данных: готовый сервис или парсер под задачу?
Готовые сервисы парсинга удобны для стандартных задач вроде мониторинга цен на популярных площадках и стоят предсказуемо по подписке. Как только нужна нестандартная логика, свои поля, объединение нескольких источников в одну таблицу, доставка результата в конкретную CRM или бота, готовый сервис либо не умеет так, либо упирается в лимиты тарифа, и тогда разработка под задачу окупается быстрее, чем подгонка чужого инструмента.