Заказчики обычно приходят с одной и той же формулировкой: нужно каждый день видеть цены конкурентов, собирать объявления с доски или выгружать остатки из чужого каталога в свою CRM. Парсинг данных решает эту задачу, но между «хочу сбор данных» и рабочим скриптом, который сам выгружает файл в нужное время без моего участия, обычно проходит несколько шагов: точная постановка задачи, выбор инструмента, проверка источника на предмет ограничений и настройка регулярного запуска. Расскажу, как я строю такие проекты на практике.
С какой задачи начинается парсинг данных
Прежде чем открывать редактор кода, я всегда фиксирую три вещи: какие именно поля нужны на выходе, с какой периодичностью их собирать и в каком формате отдавать результат. Разница между «раз в сутки выгрузить цены конкурентов в таблицу» и «каждый час проверять остатки и слать уведомление в Telegram, если товар закончился» это разные архитектуры, а не один и тот же скрипт с другим расписанием.
На практике задачи делятся на несколько типов: мониторинг цен конкурентов для интернет-магазина, сбор объявлений с доски для последующей фильтрации, выгрузка каталога поставщика для синхронизации с собственной базой, сбор контактов компаний из открытых справочников для последующей ручной проверки. Для каждого типа важно заранее понять объём: пятьдесят страниц раз в неделю и пятьдесят тысяч страниц каждую ночь требуют разных инструментов и разного бюджета.
Инструменты для сбора и извлечения данных
Под парсинг я беру Python: у языка богатый набор библиотек именно под задачи скрапинга, и большинство готовых решений для работы с HTML, очередями запросов и headless-браузером написаны под него.
requests и BeautifulSoup для простых сайтов
Если данные уже лежат в HTML-разметке и страница не подгружает контент через JavaScript, беру связку requests для запросов и BeautifulSoup для разбора разметки. Это самый быстрый путь для небольших сайтов: каталог из пары сотен товаров или список объявлений с постраничной навигацией парсится за несколько часов работы.
Scrapy для больших объёмов
Когда страниц тысячи и нужно обходить сайт по ссылкам, соблюдать паузы между запросами и переживать временные сбои без потери прогресса, беру Scrapy. У фреймворка есть встроенная очередь запросов, повторные попытки при ошибках и экспорт сразу в CSV или JSON, что экономит время на инфраструктуре вокруг самого сбора.
Playwright для сайтов с JavaScript-рендерингом
Если данные подгружаются скриптами уже в браузере, обычная библиотека для HTTP-запросов ничего не увидит: в ответе сервера просто нет нужных данных, они появляются после выполнения JavaScript. Здесь беру Playwright: он запускает настоящий браузер, дожидается загрузки контента и только потом забирает нужные значения со страницы.
| Инструмент | Когда беру | Работает с JS-рендерингом | Порог входа |
|---|---|---|---|
| requests + BeautifulSoup | Статичный HTML, до пары сотен страниц | Нет | Низкий |
| Scrapy | Тысячи страниц, нужна очередь запросов и повторные попытки | Нет без дополнительного рендерера | Средний |
| Playwright | Контент подгружается скриптами, есть бесконечная прокрутка | Да | Средний |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как собирать данные без лишних блокировок
Перед тем как писать скрипт, смотрю robots.txt сайта-источника и условия использования: если раздел явно закрыт от индексации или требует авторизации, это сигнал не трогать его вообще, а искать данные через открытое API или публичный каталог. Дальше работаю с открытыми страницами без авторизации и без попыток получить то, что скрыто за логином.
Чтобы сайт не помечал скрипт как подозрительную активность и не резал доступ, соблюдаю паузы между запросами в рамках разумного rate-limit, не долблю сервер параллельными потоками без необходимости и добавляю ротацию IP-адресов через прокси, если источник ограничивает количество запросов с одного адреса. Библиотеки вроде playwright-stealth снижают вероятность детекции автоматизации за счёт более естественного набора заголовков и параметров браузера, и это тоже часть настройки, а не отдельный хак. Если сайт стоит под защитой Cloudflare или похожего сервиса, это обычно означает более аккуратный темп запросов и работу через настоящий браузер вместо голых HTTP-запросов, а не попытки эту защиту обойти.
Если среди собранных данных попадаются контакты людей - телефоны, email, имена из открытых анкет, - храню их на сервере в России, а не в зарубежных облачных таблицах: это требование 152-ФЗ о локализации персональных данных, и оно не зависит от того, откуда взяты контакты.
Как построить регулярную выгрузку данных
Однократно собрать данные редко решает задачу целиком, обычно нужен процесс, который выгружает свежие цифры сам, без напоминаний. Здесь есть несколько рабочих вариантов.
Если скрипт написан на Python и должен запускаться по расписанию, стандартный путь это cron на отдельном сервере. Важно понимать: это отдельный VPS, который нужно арендовать, настраивать, обновлять и оплачивать ежемесячно, обычный хостинг сайта на Tilda или WordPress под такой скрипт не годится, там нет Python и нет доступа к cron для произвольных программ.
Для регулярного запуска по расписанию и передачи результата дальше по цепочке я обычно предлагаю автоматизацию в n8n: сценарий забирает файл, который отдал парсер, кладёт данные в таблицу или базу и присылает уведомление в Telegram, если появились новые позиции или изменилась цена. Если использовать облачную версию n8n, отдельный сервер не нужен, но при self-hosted варианте action такое же обслуживание, как у любого VPS.
Для небольших локальных задач подойдёт планировщик заданий Windows, но у него есть очевидное ограничение: скрипт не запустится, если компьютер выключен или ушёл в сон, поэтому для критичных по времени выгрузок этот вариант не рассматриваю.
| Вариант запуска | Где выполняется | Что требует обслуживания |
|---|---|---|
| cron на VPS | Отдельный арендованный сервер | Настройка, обновления, оплата ежемесячно |
| n8n | Облачный сервис или self-hosted сценарий | Облачная версия обслуживания не требует, self-hosted обслуживается как любой VPS |
| Планировщик заданий Windows | Локальный компьютер | Скрипт не работает, если компьютер выключен |
Где хранить результат и что с ним делать дальше
Для разовой выгрузки хватает CSV или Excel: собрал, отдал файл, закрыл задачу. Для регулярного мониторинга такой подход быстро превращается в кучу файлов без истории, поэтому обычно завожу таблицу в MySQL прямо на сервере, где крутится скрипт: одна таблица под текущие значения, вторая под историю изменений с датой и временем среза.
Отдельно настраиваю сравнение с предыдущим срезом, чтобы в уведомление или в отчёт попадали только новые или изменившиеся позиции, а не весь список заново. Это экономит время на просмотр отчёта и сразу видно, что реально поменялось: появился новый товар, ушла цена, пропало объявление.
Сколько стоит парсинг данных и от чего зависит цена
Цена проекта складывается из нескольких факторов: количества источников, есть ли на сайте JavaScript-рендеринг, нужна ли ротация прокси и защита от блокировок, и главное - нужна ли разовая выгрузка или регулярный процесс с мониторингом ошибок.
Разовый скрипт под понятную задачу, вроде сбора каталога с одного сайта без сложной защиты, я оцениваю от 20 000 ₽. Если нужен не просто сбор, а весь конвейер с регулярным запуском, хранением истории и уведомлениями, добавляется настройка автоматизации в n8n от 25 000 ₽. Если процесс уже работает, но нужно следить за ним, чинить при изменении вёрстки источника и реагировать на сбои, такое веду на техподдержке от 15 000 ₽ в месяц.
У других разработчиков и в студиях цены на подобные задачи расходятся очень сильно, это рыночный ориентир, а не мои расценки, и зависит от количества источников, объёма данных и того, нужна ли регулярная поддержка скрипта после сдачи.
Частые вопросы
Законно ли парсить данные с чужого сайта?
Сбор общедоступной информации без авторизации, которую видно любому посетителю сайта, сам по себе не нарушение. Проблемы начинаются, если обходить платный доступ, копировать данные, защищённые авторским правом, для перепродажи целиком, или собирать персональные данные без основания для их обработки. Перед стартом смотрю условия использования конкретного сайта и robots.txt, чтобы понимать границы.
Как часто можно запускать парсинг, чтобы не получить блокировку по IP?
Жёсткого числа тут нет, частота запросов подбирается под конкретный сайт: сколько запросов в секунду он выдерживает без ошибок и капчи. На практике начинаю с одного запроса в несколько секунд с одного адреса, добавляю паузы и смотрю на код ответов сервера, дальше подстраиваю темп под реакцию сайта.
Можно ли обойтись без разработчика и собрать данные вручную?
Если источник один и данных немного, например пятьдесят позиций раз в месяц, вручную это реально быстрее, чем заказывать скрипт. Как только источников несколько, данные меняются часто или их тысячи, ручной сбор перестаёт окупаться по времени, и автоматизация начинает экономить часы каждую неделю.
Что делать, если сайт-источник меняет вёрстку и парсер перестаёт работать?
Это нормальная часть жизни любого скрапера: селекторы, завязанные на конкретные классы и структуру страницы, ломаются при редизайне сайта-источника. Поэтому для регулярных процессов закладываю мониторинг ошибок, который сообщает, если скрипт вернул пустой результат вместо данных, а не молча перестал работать.