--- title: "Парсер сайтов на n8n: HTTP Request, извлечение — Nodbot" source_url: "https://nodbot.ru/recipes/web-scraper/" canonical_url: "https://nodbot.ru/recipes/web-scraper/" language: "ru" content_type: "HowToGuide" section: "recipes" generated_at: "2026-05-30" word_count_source: 1094 --- # Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация ## AI summary Как собрать парсер сайта на n8n: Schedule Trigger, HTTP Request, HTML/Code обработка, задержки, дедупликация, хранение результата и ограничения. ## Best used for Страница объясняет «Парсер сайтов на n8n: HTTP Request, извлечение — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Схема workflow - HTTP Request - Извлечение данных - Дедупликация - Ограничения и этика - Архитектура production workflow - Минимальная схема данных - Проверка на реальных крайних случаях ## Source outline # Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация Обновлено: 2026-05-29 Парсер на n8n подходит для мониторинга страниц, цен, вакансий, новостей и простых каталогов. Для сложного JavaScript-rendering лучше использовать специализированный браузерный сервис, а n8n оставить для оркестрации: расписание, запрос, обработка, хранение и уведомление. ## Схема workflow - Schedule Trigger запускает проверку раз в час или день. - HTTP Request скачивает страницу или API-ответ. - Code node извлекает нужные поля. - Merge / PostgreSQL сравнивает с уже сохранёнными записями. - Telegram / Email отправляет новые результаты. ## HTTP Request Настройте метод GET, timeout, user-agent и при необходимости headers. Не делайте частые запросы без задержки: это может перегрузить сайт и привести к блокировке. ``` Headers: User-Agent: NodbotMonitor/1.0 Accept: text/html,application/xhtml+xml Options: Timeout: 10000 ms Retry on Fail: true ``` ## Извлечение данных Если страница простая, можно обработать HTML в Code node регулярными выражениями или HTML-парсером, доступным в окружении. Если сайт отдаёт JSON API, лучше парсить JSON напрямую — это стабильнее, чем разбирать HTML. ## Дедупликация - Ключ | Когда использовать | Пример - URL | Новости, вакансии | Одна запись на страницу - SKU / id | Товары | Один товар в каталоге - Хэш заголовка + даты | Если id нет | Мониторинг публикаций ## Ограничения и этика - Проверяйте robots.txt и правила сайта. - Ставьте задержки и batching, не создавайте лишнюю нагрузку. - Не парсите закрытые данные и контент, доступ к которому запрещён. - Для коммерческого мониторинга лучше использовать официальный API, если он есть. ## Архитектура production workflow Для сценария Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация полезно строить workflow не как одну длинную цепочку, а как понятный конвейер: вход, нормализация, проверка, основное действие, запись результата и обработка ошибок. Тогда статью можно использовать как инструкцию внедрения, а не как набор разрозненных советов. - Слой | Задача | Что логировать - Trigger | получить событие от http request | event_id, source, время получения - Normalize | привести поля к единой схеме | id события или записи, source, created_at, status, payload_hash - Validate | отсечь пустые, повторные и рискованные входы | причину отказа и исходный payload_hash - Action | выполнить главное действие рецепта | id созданной/обновлённой записи - Notify | сообщить человеку или системе результат | канал, статус, ссылка на execution ## Минимальная схема данных Не начинайте рецепт с настройки красивых уведомлений. Сначала определите контракт данных: какие поля приходят, какие обязательны, где создаётся уникальный ключ и что считается успешным результатом. Для этой статьи базовый контракт можно начать с таких полей: - id события или записи - source - created_at - status - payload_hash - method - url - response_code - retry_count Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку. ## Проверка на реальных крайних случаях - пустой payload или форма без обязательного поля - повторная доставка одного и того же события - частичный успех: внешняя запись создана, но уведомление не отправилось - медленный API или временный 429/5xx - ручной повтор старого execution через неделю после первого запуска ## MVP и production-версия рецепта Рецепт Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат. - Уровень | Что включить | Что пока не делать - MVP | Webhook/Trigger, нормализация, основное действие, короткий ответ | сложные retry, multi-tenant логику, лишние ветки - Production | idempotency, error workflow, лог статусов, ручная очередь, alert | хранить токены в тексте нод или логировать полный payload - Scale | очередь, лимиты, batch processing, SLA-метрики | раздувать один workflow до нечитабельной схемы ### Как понять, что рецепт готов - Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта. - Повторный запуск с тем же payload не создаёт дубль. - Ошибочный payload не теряется, а попадает в manual review или alert. - Все внешние API вызываются через credentials, а не через токен в plain text. - К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен. ## Production-сценарий и проверка рецепта Рецепт «Парсер сайтов на n8n» стоит собирать в два прохода: сначала минимальный happy path, затем production-слой. В production-слое появляются dedupe, retry, error branch, audit trail и уведомление владельцу процесса, а не только красивые ноды на canvas. Источник события для проверки: payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом. Сразу подготовьте три теста: обычный вход, повтор того же события и ошибку внешнего API. - Слой | Что зафиксировать | Зачем - Вход | payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Парсер сайтов на n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "event_id": "evt_...", "event_type": "object.updated", "received_at": "2026-05-29T10:00:00Z", "signature_valid": true, "dedupe_key": "provider:event_id", "payload_version": "v1" } ``` ### Критерий готовности - рецепт проходит на тестовых данных и не создаёт дубли при повторном запуске - ошибка внешнего сервиса уходит в отдельную ветку с понятным уведомлением - результат можно найти по execution_id или external_id - у workflow есть владелец, описание и ссылка на runbook ## Что читать дальше Ноды: HTTP Request , Schedule Trigger , Merge , PostgreSQL . ## Production-контекст и проверка внедрения Материал «Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация» стоит использовать не только как пример настройки, но и как мини-runbook для внедрения в реальный n8n. Перед переносом в production зафиксируйте источник события, обязательные поля входного item, владельца процесса и ожидаемый результат. Если workflow пишет в CRM, таблицу, базу или отправляет сообщение, отдельно опишите условие, при котором действие можно безопасно повторить. Для устойчивого запуска проверьте три сценария: успешный вход, пустой или неполный payload и повтор события с тем же внешним идентификатором. Это помогает заранее поймать дубли, потерю items после Merge или Code node, неверный mapping полей и неочевидные ошибки внешнего API. Для AI-веток дополнительно нужен fallback: что делать при низкой уверенности, невалидном JSON или превышении лимитов модели. ### Чеклист перед публикацией workflow - Добавьте тестовый payload без секретов и персональных данных. - Проверьте retry, error branch, idempotency и ручной override. - Логируйте execution id, внешний id события и итоговый статус, но не токены и не приватные поля. - Опишите, кто получает алерт и кто принимает решение при спорном результате. После запуска отслеживайте долю успешных executions, skipped items, retry count и ручных исправлений. Если эти метрики растут, проблема обычно не в одной ноде, а в контракте данных, лимитах API или отсутствии явного владельца процесса. ### Связанные материалы для углубления - Все рецепты — открыть связанный материал для проверки контекста. - Workflow JSON — открыть связанный материал для проверки контекста. - Диагностика — открыть связанный материал для проверки контекста. - Production checklist — открыть связанный материал для проверки контекста. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.