Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация¶

Обновлено: 2026-05-29

Парсер на n8n подходит для мониторинга страниц, цен, вакансий, новостей и простых каталогов. Для сложного JavaScript-rendering лучше использовать специализированный браузерный сервис, а n8n оставить для оркестрации: расписание, запрос, обработка, хранение и уведомление.

Схема workflow¶

1. Schedule Trigger запускает проверку раз в час или день.
2. HTTP Request скачивает страницу или API-ответ.
3. Code node извлекает нужные поля.
4. Merge / PostgreSQL сравнивает с уже сохранёнными записями.
5. 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.

Дедупликация¶

Ограничения и этика¶

• Проверяйте robots.txt и правила сайта.
• Ставьте задержки и batching, не создавайте лишнюю нагрузку.
• Не парсите закрытые данные и контент, доступ к которому запрещён.
• Для коммерческого мониторинга лучше использовать официальный API, если он есть.

Архитектура production workflow ¶

Для сценария Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация полезно строить workflow не как одну длинную цепочку, а как понятный конвейер: вход, нормализация, проверка, основное действие, запись результата и обработка ошибок. Тогда статью можно использовать как инструкцию внедрения, а не как набор разрозненных советов.

Минимальная схема данных ¶

Не начинайте рецепт с настройки красивых уведомлений. Сначала определите контракт данных: какие поля приходят, какие обязательны, где создаётся уникальный ключ и что считается успешным результатом. Для этой статьи базовый контракт можно начать с таких полей:

• id события или записи
• source
• created_at
• status
• payload_hash
• method
• url
• response_code
• retry_count

Если поля отличаются у разных источников, добавьте отдельную нормализационную ноду сразу после trigger. Это снижает количество выражений в последующих нодах и упрощает поддержку.

Проверка на реальных крайних случаях ¶

• пустой payload или форма без обязательного поля
• повторная доставка одного и того же события
• частичный успех: внешняя запись создана, но уведомление не отправилось
• медленный API или временный 429/5xx
• ручной повтор старого execution через неделю после первого запуска

MVP и production-версия рецепта

Рецепт Парсер сайтов на n8n: HTTP Request, извлечение данных и дедупликация не должен конкурировать со справочником нод. Здесь важен готовый сценарий: какие ноды соединить, какие данные передать и как проверить бизнес-результат.

Как понять, что рецепт готов

1. Есть один владелец процесса и понятный критерий успеха: лид создан, письмо отправлено, документ сохранён, задача закрыта.
2. Повторный запуск с тем же payload не создаёт дубль.
3. Ошибочный payload не теряется, а попадает в manual review или alert.
4. Все внешние API вызываются через credentials, а не через токен в plain text.
5. К рецепту привязан готовый шаблон в разделе workflow или указано, почему шаблон не нужен.

Что читать дальше¶

Ноды: HTTP Request, Schedule Trigger, Merge, PostgreSQL.