SEO-агент на n8n своими руками: автоматический аналитик

Что реально умеет SEO-агент на n8n: сценарии вместо рутины

В 2025 году поисковый трафик у многих сайтов просел внезапно и сильно. Выдача перестраивается быстрее, чем SEO-специалист успевает открыть Search Console, выгрузить отчёт и свести его в таблицу. Ручной мониторинг просто перестал успевать за реальностью — и это тот самый момент, когда автоматизация перестаёт быть «игрушкой».

Собрала похожий агент на n8n и пощупала, что он закрывает на практике. Анастасия Никулина описала свой опыт на Habr, и выводы сходятся с моими: ценность не в «магии ИИ», а в том, что рутина уходит в фон.

Вот пять сценариев, которые агент тянет без выходных и больничных:

1. Снимок позиций и трафика по расписанию. Нода Schedule Trigger + Google Search Console (или HTTP Request к API) раз в сутки собирает клики, показы, позиции по ядру и складывает в Google Sheets.

2. Каннибализация запросов. Нода Code сравнивает URL, которые ранжируются по одному и тому же запросу, и подсвечивает страницы, «съедающие» друг у друга трафик.

3. Кластеризация семантики. OpenAI (блок embeddings) превращает запросы в векторы, а Code считает косинусную близость и режет ядро на группы.

4. Контент-план. AI Agent на основе кластеров и текущих позиций предлагает темы, форматы и частоту публикаций, а нода Google Sheets пишет всё в готовую таблицу.

5. Алерт при просадке CTR. IF-нода ловит падение CTR или позиций ниже порога и Telegram-нодой кидает уведомление в чат — до того, как просадка превратится в минус по выручке.

Дальше разберём, как это собирается в визуальном редакторе n8n — нода за нодой, без единой строки кода.

Архитектура воркфлоу: триггеры, ноды и хранилище данных

Любой воркфлоу в n8n — это конвейер, который кто-то должен запустить. На входе всегда стоит триггер: Schedule Trigger для регулярного прогона (обычно раз в неделю по понедельникам, чтобы не ловить неполные данные), Webhook — если хочется дернуть анализ руками из браузера, и RSS Trigger для тех, кто следит за новостным фоном ниши.

Дальше сценарий ровно на три слоя, и путать их не стоит.

Слой источника. Тут живут ноды, которые просто тянут сырье: Google Search Console (запросы, показы, CTR, позиции), Google Analytics (поведение и конверсии), RSS Read для новостей отрасли и HTTP Request для парсинга выдачи конкурентов. Никакой логики здесь быть не должно — только выгрузка.

Слой обработки. Это сердце схемы. Нода Set переименовывает и оставляет только нужные поля, Merge склеивает данные из GSC и Analytics по URL, а Code-нода приводит их к общему виду.

Вот тут и всплывает вопрос к тем, кто обещал «без единой строки кода».

Слой вывода. Куда сливать результат: Telegram или Slack — для оперативного «что упало за неделю», Google Sheets или Notion — для отчета, который прочтут люди.

А вот историю лучше держать отдельно — в той же Sheets или в Postgres через ноду Postgres. Минимальная схема такая:

Поле	Тип	Зачем
snapshot_date	date (ISO)	Точка отсчета для сравнения периодов
url_normalized	text	Ключ склейки между неделями
query	text	Поисковый запрос из GSC
clicks / impressions	int	Базовые метрики видимости
ctr / position	float	Качество сниппета и позиция
sessions / conversions	int	Данные из Analytics

Хороший ориентир по сборке такой схемы — кейс SEO-агента на n8n от Анастасии Никулиной на Хабре: там видно, как слои раскладываются в реальном проекте. И заранее прикиньте, что именно автоматизация должна окупить — методика расчета ROI внедрения ИИ тут неплохо отрезвляет.

Сравнение платформ: n8n, Make, Zapier и Python-скрипт

Прежде чем тащить в проект понравившийся логотип, давайте честно разложим по полочкам. Я гонял все пять вариантов на реальной задаче — SEO-агент, который раз в сутки собирает данные, ходит в LLM и складывает отчёт. Спойлер: универсального победителя нет, есть разные бюджеты и разные уровни боли.

Главная ловушка сравнения — в разных единицах тарификации. Zapier считает задачи (task = одно действие), Make — операции (одно действие модуля), а n8n — выполнения целиком. Один и тот же сценарий на 10 000 шагов у них будет стоить совершенно по-разному.

Критерий	n8n self-hosted	n8n Cloud	Make	Zapier	Python-скрипт
Стоимость ~10 000 выполнений/мес	$5–20 за VPS + токены	~€50/мес (Pro)	от $9–16/мес (Core/Pro, 10k операций)	~$150–200/мес (Professional, 10k задач)	$5–20 за VPS + токены + ваше время
Self-hosted	Да, полностью	Нет	Нет	Нет	Да, это его суть
LLM-агенты из коробки	Да (AI Agent node, Memory, Tools)	Да	Частично, через HTTP-модули	Через сторонние интеграции	Нет, только SDK вручную
Гибкость кастомного кода	Code node, npm, свои библиотеки	Code node, без npm	Ограниченные сниппеты	Очень ограниченно	Абсолютная
Порог входа для неразработчика	Средний: нужен VPS и Docker	Низкий	Низкий, drag-n-drop	Самый низкий	Высокий
Данные на своих серверах	Да	Нет	Нет	Нет	Да

Смотрите, что вырисовывается. Если у вас есть хоть минимальный навык работы с консолью — self-hosted n8n выигрывает вчистую по экономике. Вы платите только за VPS и токены модели, а вся логика, все логи и вся база остаются у вас. Никаких лимитов на executions, никаких «упс, закончились задачи на 28-е число».

Перед тем как фиксировать бюджет, прогоните сценарий через нормальную методику расчёта ROI внедрения ИИ — она отрезвляет лучше любого бенчмарка. А если решите экономить на модели, посмотрите разбор экономики DeepSeek API: на объёмах вроде нашего разница в цене токенов перекрывает годовую подписку на облако.

Живой кейс похожего агента на n8n с реальными цифрами падения трафика и логикой сборки разобран в материале Анастасии Никулиной на Хабре — рекомендую к прочтению перед выбором стека.

Пошаговая сборка первого сценария: от пустого канваса до отчёта

Открываем пустой воркфлоу и даём ему внятное имя — «SEO Digest · GSC → Sheets → TG». Имя тут не для красоты: через месяц у вас будет десяток сценариев, и «My workflow 7» превратится в археологические раскопки.

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

1. Schedule Trigger. Ставим режим «Every Day» и время 08:00 (или сразу cron 0 8 * * *). Сразу проверьте таймзону воркфлоу, иначе дайджест приедет в пять утра.
2. Доступ к Search Console. Берём ноду HTTP Request → Authentication: Predefined Credential Type → Google Search Console API. Жмём Connect и логинимся аккаунтом, у которого есть подтверждённый сайт в GSC. Токен n8n потом обновляет сам, руками ничего не трогаем.
3. Сам запрос. POST на searchAnalytics/query. В теле JSON: dimensions: ["query","page"] и диапазон дат. Даты не хардкодим, а считаем выражениями — {{ $now.minus({days:7}).toFormat('yyyy-MM-dd') }}. Так сценарий не отвалится через неделю.
4. Split Out. API возвращает один объект с массивом rows. Нода Split Out разбивает его на отдельные items — по одному на связку «запрос + страница».
5. Google Sheets. Append Row, поля маппим drag-and-drop: clicks, impressions, ctr, position. Побочный бонус — копится история, а через пару месяцев это уже собственная база под тренды.
6. Сборка текста. Aggregate + Set собирают топ-10 в одно сообщение: где просел CTR, где позиция выросла, а кликов нет.
7. Telegram. Send Message, chatId в credentials. Готово.

На выходе получаете то, что раньше занимало час ручной работы: таблицу с сырыми данными и короткий дайджест в Telegram. Если хочется сверить подход с чужой практикой — на Хабре есть разбор SEO-агента на n8n от контент-команды: там про ту же боль с падением поискового трафика и похожую архитектуру.

И прежде чем тиражировать сценарий на три сайта сразу, посчитайте ROI внедрения ИИ — иначе легко автоматизировать то, что никто не читает.

Подключение LLM и Search Console: где агент начинает думать

Данные из Search Console уже льются в воркфлоу. Клики, показы, CTR, средняя позиция — всё это лежит в нодах красивыми массивами. Но массив чисел не думает. Он просто есть. Мозг агента появляется ровно в тот момент, когда в схему встаёт нода AI Agent.

Внутри неё три обязательных «слота»: Chat Model (кто думает), Memory (что помнит) и Tools (чем может пользоваться). Собирается всё драг-н-дропом — ноды подключаются друг к другу как конструктор.

Самый недооценённый элемент — системный промпт. Это не «опиши, что тут происходит». Это техзадание для аналитика, и писать его надо с той же строгостью, что ТЗ для джуна.

Ты — SEO-аналитик с 8-летним опытом. Тебе дают готовые метрики
по страницам за два периода: текущий и предыдущий.

ПРАВИЛА:
1. Считай просадкой падение кликов >20% при неизменном спросе.
2. Используй ТОЛЬКО переданные цифры. Запрещено достраивать проценты,
   доли и динамику самостоятельно.
3. Если данных не хватает — пиши «данных нет», а не догадку.

ФОРМАТ ОТВЕТА (строго):
— Топ-5 страниц-просадок: URL, клики было → стало, % падения
— Гипотеза причины (1-2 предложения каждой)
— Приоритет фикса: high / medium / low

Обратите внимание на п.2. Без него модель через два прогона придумает вам динамику CTR за прошлый квартал и будет уверена в этом.

Поэтому между HTTP-нодой и AI Agent всегда стоит Code-нода или нода Edit Fields, которая считает дельты и обрезает лишнее. Логика — код, интерпретация — модель. Не наоборот.

Memory — тоже не роскошь. Обычный Window Buffer Memory на 10 сообщений позволяет агенту помнить, что вы уже обсудили просадку по блогу, и во втором запросе не начинать с чистого листа. Без памяти каждый вызов — разговор с незнакомцем.

Tools — это то, что превращает болтуна в агента. Минимальный набор для SEO: HTTP Request к GSC API за свежими данными, Code-нода с расчётами, запись вердикта в Google Sheets.

А на чём это всё гонять? Вариантов сегодня два — облако и своё железо. Разница не только в цене.

Вариант	Плюсы	Минусы
Облачные API (DeepSeek, Kimi, Qwen, GigaChat, YandexGPT)	Умные модели, ноль затрат на железо, старт за 10 минут	Данные уходят на чужой сервер, оплата за токены
Локально (Ollama, LM Studio, llama.cpp)	Данные не покидают контур, лимитов нет, фиксированные расходы	Нужна GPU, модели 7-8B слабее в аналитике

Своё железо почти всегда выигрывает, когда на входе данные клиентов под NDA, внутренние CRM или выгрузки с персональными данными. Плюс когда запросов десятки тысяч в сутки — API-счёт начинает кусаться, и это уже задача из методики расчёта ROI внедрения ИИ.

Живой пример такой сборки на n8n с реальными цифрами падения трафика разбирали в кейсе на Habr — рекомендую сверить свой воркфлоу с чужим опытом перед тем, как гнать его в прод.

Грабли, лимиты и стоимость автономного аналитика

Первые две недели всё летает. На третью ночь агент молча падает, а утром выясняется, что таблица истории распухла до 60 тысяч строк, из которых половина — дубли.

Начинается это всегда с квот. Search Console API отдаёт порядка 1 200 запросов в минуту и 40 000 в сутки на сайт, URL Inspection API — ещё жёстче: около 2 000 проверок в день на ресурс. Прогон по 5 000 ключей в лоб просто выбьет 429-ю ошибку на середине списка.

Лечится это батчингом и паузой между итерациями: не больше 50 запросов за проход, потом Wait-нода на 30 секунд. Скучно, зато без банов.

Грабли	Что видно на практике	Лечение
Повторный запуск	Дубли строк в истории	Идемпотентность: ключ сайт + дата + фраза, апсерт вместо append
Раздувание истории	Таблица на сотни тысяч строк, медленные выборки	Окно запроса 7–14 дней вместо «всё с 2020-го»
Скачок расходов на токены	Счёт за LLM растёт нелинейно к объёму данных	Лимит max_tokens на ответ, сжатие промпта, отсечение шума
Падение внешнего сервиса	Тишина в логах, никто не знает	Error Trigger + уведомление в мессенджер

Идемпотентность — самая недооценённая штука. В n8n это делается связкой из уникального ключа записи и ноды, которая обновляет существующую строку вместо создания новой. Один раз настроили — и ручной чистки дублей больше нет.

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

И обязательный Error Trigger. Не для красоты — он превращает ночной сбой из «утром узнали от клиента» в сообщение в чат через минуту после падения. Многие упускают этот шаг, а он экономит больше нервов, чем весь остальной тюнинг. Кстати, считать экономику внедрения до и после таких доработок удобно по методике из пошагового расчёта ROI внедрения ИИ.

Подробный разбор похожего пути с цифрами и скринами — в кейсе автора на Хабре: там про те же грабли с трафиком и автоматизацией.

Масштабирование и контроль качества: как не утонуть в шуме

Первый месяц ваш воркфлоу — это 12 нод и чувство абсолютного могущества. Через полгода это уже 60 нод, три ветки на разные сайты, захардкоженный API-ключ в четырёх местах и паника при каждом изменении.

Знакомо? Тогда пора выносить логику наружу. Начинаем с банального: все креды — в Credentials n8n, никаких ключей в HTTP-нодах и заметках. Один раз поменяли провайдера — и не перелопачиваете весь граф руками.

Дальше — подворкфлоу (Execute Sub-workflow). Сбор данных, парсинг выдачи, вызов LLM и отправка в мессенджер — это четыре отдельные единицы. Каждую можно тестировать в изоляции, а не гонять весь пайплайн из-за опечатки в промпте.

Главный архитектурный сдвиг — разделение ролей. Агент-сборщик только тянет данные: позиции, трафик, новые страницы конкурентов. Агент-аналитик только думает: сравнивает с базовой линией, ищет аномалии, формулирует выводы. Смешаете в одном воркфлоу — получите кашу, которую невозможно отлаживать.

Дальше — ритм. Ежедневный дайджест отвечает на вопрос «что случилось сегодня». Еженедельная сводка поверх него — «что это значит». Разные горизонты, разные промпты, разные получатели.

Контур	Частота	Что на выходе
Агент-сборщик	Ежедневно	Сырые метрики, позиции, диффы
Агент-аналитик	Ежедневно	3–5 сигналов о просадках
Еженедельная сводка	Раз в неделю	Тренды, гипотезы, план правок

Промпты — это код, и относиться к ним надо так же. Храните версии в таблице или репозитории: дата, версия, что поменяли, на каком интервале тестировали. Откат на «позапрошлый промпт, который работал» должен занимать минуту, а не вечер археологии.

Теперь про качество. Раз в неделю берите три случайных вывода агента и сверяйте с фактическими данными вручную — в Search Console, analytics, через обычный браузер. Скучно, нудно, спасает от катастрофы.

LLM умеет уверенно галлюцинировать цифры, особенно когда входной JSON кривой. Без выборочной ручной сверки вы узнаете о проблеме не из отчёта, а от разъярённого клиента. Про экономику такого мониторинга и окупаемость автогенерации мы разбирали в материале ROI внедрения ИИ: пошаговая методика расчета от пилота до продакшена. Там же есть неплохая схема для сравнения с ручным трудом редакции.

Если нужен референс, как это выглядит у людей с реальным SEO-бэкграундом, почитайте разбор сборки SEO-агента на n8n — Habr. Многое совпадает с тем, к чему приходишь сам через пару месяцев эксплуатации.

Часто задаваемые вопросы (FAQ)