Парсинг сайтов - это когда вместо ручного копирования цен, характеристик товаров или контактов вы получаете скрипт, который сам заходит на нужные страницы, забирает данные и складывает их в таблицу или базу. У меня в практике были парсеры для мониторинга цен конкурентов у интернет-магазинов на WooCommerce, сбор остатков у поставщиков для каталога на Tilda и выгрузка тарифов курьерских служб для расчёта доставки. Ниже разберу, как устроен процесс технически и из чего складывается цена, потому что разброс на рынке большой, а задачи снаружи выглядят одинаково.
Что такое парсинг сайтов и зачем он нужен бизнесу
Чаще всего ко мне приходят с одной из трёх задач: отслеживать цены конкурентов, собрать каталог товаров с сайта поставщика для переноса в свой магазин или вытащить открытые контакты и объявления для базы лидов. Все три задачи технически похожи, разница в том, что именно скрипт ищет на странице и куда потом складывает результат.
Отдельно скажу про данные о людях. Если среди собранного попадаются контакты или другая информация, которая относится к конкретному человеку, я храню такие базы на серверах в России, а не в иностранных таблицах или облачных сервисах - это требование 152-ФЗ о локализации персональных данных, и его проще соблюдать сразу, чем потом переносить базу.
Практические примеры, где парсинг окупается:
- ежедневный мониторинг цен у 5-10 конкурентов для интернет-магазина на WooCommerce, чтобы автоматически корректировать свои цены
- перенос каталога на несколько тысяч товаров с сайта поставщика в карточки на Tilda без ручного набора
- сбор тарифов на доставку у нескольких курьерских служб вроде СДЭК для сравнения перед выбором интеграции
- агрегация вакансий, объявлений или отзывов с открытых площадок для анализа рынка
Как устроен процесс сбора данных с сайта: от запроса до таблицы
Внутри почти любой парсер решает одну и ту же последовательность задач, вне зависимости от сайта-источника.
Сначала скрипт отправляет HTTP-запрос к странице и получает в ответ HTML. Дальше этот HTML разбирается на дерево элементов, и по CSS-селекторам или XPath-выражениям вытаскиваются нужные куски: название товара, цена, артикул, наличие. После этого данные нормализуются - убираются лишние пробелы, цена приводится к числу без валютного знака, даты переводятся в единый формат. И только потом результат сохраняется: в CSV или Excel для разовой выгрузки, либо в базу MySQL, если нужно накапливать историю изменений и потом строить графики или сравнивать периоды.
Вот как выглядит минимальный рабочий пример на Python для статичной страницы, где данные уже есть в HTML без JavaScript:
import requests
from bs4 import BeautifulSoup
url = "https://example.com/catalog/item-123"
response = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}, timeout=10)
response.raise_for_status()
soup = BeautifulSoup(response.text, "html.parser")
title = soup.select_one(".product-title").get_text(strip=True)
price_text = soup.select_one(".product-price").get_text(strip=True)
price = float(price_text.replace("\u00a0", "").replace("₽", "").replace(",", "."))
print(title, price)
Если товаров тысячи, а не один, этот же принцип оборачивается в цикл по списку страниц или в очередь запросов, добавляются паузы между обращениями и обработка ошибок, чтобы разовый сбой на одной странице не останавливал весь сбор.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Инструменты для автоматизированного сбора информации
Библиотеки на Python для статичных страниц
Для большинства задач мне хватает связки requests и BeautifulSoup - она быстрая и простая в поддержке. Когда объём вырастает до десятков тысяч страниц и нужна параллельная обработка с очередью запросов, retry при ошибках и встроенным экспортом, беру Scrapy - он изначально спроектирован под промышленный парсинг, а не под разовый скрипт.
Headless-браузеры для сайтов на JavaScript
Если контент подгружается скриптами после загрузки страницы, как это часто бывает на SPA-сайтах на React или Vue, простой запрос вернёт пустой HTML без данных. Тогда использую Playwright - он запускает настоящий браузер без интерфейса, дожидается выполнения JavaScript и только потом забирает готовую разметку. Работает медленнее и требует больше ресурсов, чем обычные запросы, поэтому для регулярного мониторинга такой парсер обычно запускают на отдельном сервере по расписанию (cron), а не на хостинге сайта - это отдельная услуга виртуального сервера, которую нужно оплачивать и обслуживать ежемесячно, в отличие от разовой разработки скрипта.
Дальше собранные данные обычно нужно куда-то передать - в Telegram, в CRM или в таблицу для отдела продаж. Здесь я обычно подключаю автоматизацию в n8n, чтобы парсер сам запускался по расписанию и раскладывал результат по нужным адресам без ручного участия.
Что усложняет парсинг веб-страниц на практике
Динамический контент и авторизация
Пагинация через JavaScript, бесконечная прокрутка, данные, которые появляются только после клика или после входа в личный кабинет - каждый такой случай увеличивает время разработки, потому что скрипту нужно повторить не просто запрос, а целую последовательность действий пользователя.
Устойчивость к блокировкам и лимитам
Часть сайтов работает под защитой систем вроде Cloudflare, которые анализируют поведение запросов и могут временно ограничивать доступ при подозрительной активности. Для таких источников парсер приходится делать аккуратнее: соблюдать паузы между запросами, укладываться в разумную частоту обращений, использовать ротацию IP-адресов через прокси и снижать вероятность детекции автоматизации при работе через headless-браузер. Это не разовая настройка, а часть архитектуры скрипта, и именно она чаще всего отличает дешёвый парсер от того, который будет стабильно работать месяцами.
Из чего складывается цена на разработку парсера
Цена очень редко зависит от типа сайта-источника самого по себе - гораздо сильнее на неё влияют конкретные технические факторы:
| Фактор | Как влияет на стоимость |
|---|---|
| Статичный HTML или рендеринг на JavaScript | Requests и BeautifulSoup обходятся дешевле, headless-браузер вроде Playwright требует больше времени на настройку и ресурсов при запуске |
| Объём и структура данных | Одна таблица с товарами дешевле, чем вложенный каталог с вариациями по цвету и размеру, где под каждую комбинацию своя логика |
| Частота запуска | Разовая выгрузка дешевле регулярного мониторинга с расписанием, хранением истории и уведомлениями об изменениях |
| Устойчивость к блокировкам | Нужна ротация IP, задержки между запросами и аккуратная работа с лимитами - это добавляет время на тестирование |
| Формат выдачи и интеграция | Экспорт в CSV или Excel проще прямой записи в CRM, 1С или карточки товаров на Tilda через API |
Отдельно, вне таблицы, идут расходы, которые не зависят от сложности самого скрипта: если парсер должен работать регулярно, нужен недорогой сервер под cron-задачи, а если требуется ротация IP через сторонний сервис - подписка на прокси. Оба пункта оплачиваются отдельно каждый месяц и не входят в разработку.
Как я оцениваю проект и что входит в стоимость
Парсинг и автоматизация на Python у меня начинаются от 20 000 ₽. В эту сумму входит анализ структуры сайта-источника, написание скрипта под конкретные поля, тестовый прогон на реальных страницах и настройка экспорта в понятный формат - Excel, CSV или сразу в базу. Если нужна регулярная работа по расписанию с интеграцией в CRM, 1С или Tilda, оцениваю проект отдельно, исходя из объёма интеграции.
Если по итогу парсинга нужно ещё и мгновенное уведомление, например при изменении цены конкурента, подключаю Telegram-бота на aiogram - это уже отдельный сервис, который должен работать круглосуточно, а не разовый скрипт, поэтому такие проекты оцениваю от 30 000 ₽.
Частые вопросы
Легально ли парсить сайты конкурентов?
Сбор общедоступных данных, которые видно на странице без авторизации, сам по себе обычно не нарушает закон. Но многие сайты в пользовательском соглашении отдельно запрещают автоматический сбор данных, и это стоит учитывать при выборе источников. Я стараюсь соблюдать robots.txt и не превышать разумную частоту запросов, чтобы не создавать лишнюю нагрузку на чужой сервер.
Сколько времени занимает разработка парсера?
Простой парсер для одной статичной страницы с понятной структурой я делаю за 3-5 дней. Проект с JavaScript-рендерингом, регулярным запуском по расписанию и интеграцией в CRM или Tilda обычно занимает 2-3 недели, в зависимости от объёма данных и количества источников.
Что делать, если сайт-источник меняет вёрстку?
Рано или поздно верстка меняется, и селекторы, по которым скрипт находит нужные блоки, перестают работать. Тогда парсер нужно поправить под новую структуру страницы. Если хотите, чтобы этим занимался не сам, беру такие проекты на техподдержку от 15 000 ₽ в месяц.
Можно ли парсить сайты, которые защищены от автоматических запросов?
Часть сайтов работает под системами защиты вроде Cloudflare, которые анализируют поведение запросов. Для таких источников парсер приходится делать медленнее и аккуратнее: соблюдать паузы, использовать ротацию IP и снижать вероятность детекции автоматизации при работе через headless-браузер. Это не гарантия стопроцентной стабильности, а способ снизить число ложных блокировок, и такие проекты стоят дороже из-за дополнительного времени на настройку и тестирование.