Как я собрала на n8n SEO-агента для трех сайтов: данные, правила и немного нейросети

Привет! Я Анастасия Никулина, руковожу отделом контента в IT-компании. Кроме продуктовой редакции, на мне SEO-блоги трёх сайтов. В 2025 году мы столкнулись с резким падением поискового трафика: привычные гипотезы перестали давать результат, подрядчики не всегда могли объяснить, что происходит, а я всё глубже зарывалась в аналитику.

В итоге я собрала свой инструмент контроля — SEO-агента на n8n. Он забирает данные из Screaming Frog, Яндекс Метрики, Вебмастера и других источников, хранит историю, фильтрует страницы и приносит мне короткий список того, что требует внимания редакции. В отдельных случаях подключается языковая модель и помогает сформулировать гипотезы.

В статье покажу, как я его собирала, где получилось обойтись обычным кодом и правилами и за счёт чего сократить работу дорогой модели.

Как падение трафика заставило меня самой разбираться в SEO

До середины 2025 года с SEO-работами всё было супер. Мы активно работали с подрядчиками, блоги росли, поисковый трафик тоже. По флагманскому продукту из органики приходило до 30 заявок в месяц. Для нашего довольно узкого B2B-сегмента это был отличный канал привлечения.

Летом трафик резко пошёл вниз, и за несколько месяцев мы почти откатились к показателям 2024 года. Мне нужно было понять, что произошло, и заодно лучше оценивать гипотезы подрядчиков. В какой-то момент пришлось довольно плотно погрузиться в SEO: разбираться в поисковом интенте, поведении пользователя и его пути до сайта.

Причин падения оказалось несколько. Самая простая и понятная — кризис в отрасли, с которой мы работаем, и снижение спроса на программное обеспечение. На него наложилась сезонность, но вместе они всё равно не объясняли просадку трафика почти на 40%.

Параллельно менялось поисковое поведение, росли нейроответы, часть информационного спроса уходила туда. Для нас это было особенно неприятно: спрос на наши продукты всегда приходилось во многом формировать через информационный контент. Блог был частью воронки — через него мы объясняли проблему и показывали, что у неё вообще-то есть решение.

Тем временем подрядчики продолжали предлагать расширять семантическое ядро, менять метатеги и наращивать ссылочную массу. Расширение семантики могло привести на сайт новый трафик и частично компенсировать падение в цифрах, но моей бизнес-задачи это не решало. Бесконечно переписывать метатеги и закупать ссылки в той ситуации тоже казалось мне довольно бесперспективным занятием.

Поэтому я начала сама проверять гипотезы и искать другие подходы к работе с блогом. Для этого мне и понадобился помощник, который регулярно собирает данные по страницам, показывает изменения, помогает разбирать поисковый интент и выдачу и поднимает наверх только те случаи, где действительно есть о чём подумать.

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

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

Сначала я решила, что именно агент должен делать

По моему плану агент должен регулярно собирать данные по сайту, находить то, что требует внимания, и приносить мне гипотезы. Дальше я уже сама их просматриваю, отбрасываю лишнее и решаю, что действительно стоит делать.

Поэтому сначала пришлось разложить процесс на части. Какие данные мне нужны и откуда их брать? Какие страницы вообще должны попадать в анализ? Как отличить SEO-статью от новости, HR-материала или продуктовой публикации? Какие решения можно принять обычными правилами, а где уже понадобится анализ текста?

К тому моменту я довольно плотно работала с нейросетями в контенте и хорошо знала их слабые места. Нейросеть очень старательна. Если дать ей 500 страниц и сказать «проанализируй», она будет честно анализировать все 500. И если среди них 200 новостей, 50 HR-материалов и несколько страниц, закрытых от индексации, она всё равно понесёт их дальше, пока ей не объяснить правила.

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

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

Поэтому сначала я выписала, что именно хочу получать от системы раз в неделю.

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

Второй — общая температура сайта. Самые посещаемые страницы, поисковый трафик, поведенческие показатели, позиции и заметная динамика относительно прошлого периода.

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

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

Из этих требований постепенно сложилась архитектура:

• ИСТОЧНИКИ

  Screaming Frog

  Яндекс Вебмастер

  Яндекс Метрика

  содержимое страниц

          ↓

• ОЧИСТКА И СОПОСТАВЛЕНИЕ

  привести данные к одному виду

  сопоставить URL между источниками

  убрать технический шум

          ↓

• ПАМЯТЬ

  Google Таблицы

  текущее состояние

  история

  ручные решения

          ↓

• ПРАВИЛА

  пороги

  сигналы

  система баллов

          ↓

• ЯЗЫКОВАЯ МОДЕЛЬ

  классификация новых страниц

  глубокий анализ нескольких кандидатов

          ↓

• ЧЕЛОВЕК

  три коротких отчёта в Telegram

  решение, что делать дальше

Почему я выбрала n8n

Я не разработчик. Весь мой технический опыт на тот момент — простой вайбкодинг для лендингов и несложные автоматизации.

Здесь же задача была заметно объёмнее. Предстояло собирать данные из нескольких источников, очищать их, нормализовывать сотни URL, хранить историю и связывать всё это в один регулярный процесс. Писать для этого целый сервис с нуля, поднимать сервер и потом самостоятельно всё обслуживать мне совершенно точно не хотелось.

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

В итоге выбрала n8n. Весь сценарий было видно, можно подключить API, Google Таблицы и Telegram, поставить условия, циклы и глазами проследить, куда дальше уходят данные.

А ещё можно было в любой момент можно добавить ноду с JavaScript и, например, очистить данные или проверить нужное условие обычным кодом. Сам код при этом мне могла помочь написать та же нейросеть.

Сам код я писала с ChatGPT. Обычно это выглядело так: я объясняла, какие данные приходят на вход, что хочу получить на выходе и какая логика должна быть внутри. ChatGPT писал код для узла, я запускала его на своих данных, смотрела результат и возвращалась с замечаниями: здесь потеряли строки, здесь неправильно сопоставились URL, здесь ты зачем-то тащишь дальше данные, которые нам вообще не нужны.

Потом мы разбирались, что произошло, и переписывали узел. Поэтому дальше в статье будет код, но приписывать себе внезапно открывшийся талант к JavaScript я не буду. Архитектуру и правила системы собирала я, — техническую реализацию многих частей помогал писать ChatGPT.

Screaming Frog дал мне технический срез сайта

Я знала, что наши SEO-специалисты используют Screaming Frog, поэтому решила не изобретать колесо.

Сейчас из России с оплатой сервиса могут быть сложности. Альтернативы есть — например, SiteAnalyzer или Netpeak Spider. Я с ними этот проект не собирала, поэтому качество сравнивать не буду. Просто отмечу, что варианты есть.

Screaming Frog регулярно сканирует сайт. Из него я выгружаю данные по внутренним HTML-страницам в CSV и складываю файлы в отдельную папку на Google Диске. Название всегда строится одинаково:

sf_internal_html_YYYY_MM_DD.csv

Дата в названии нужна n8n, чтобы при очередном запуске найти самый свежий отчёт.

На одном из первых запусков мы нашли 197 HTML-страниц. Система увидела семь страниц без Description, один редирект и 11 страниц, которые нельзя индексировать. Из этих одиннадцати десять оказались совершенно нормальными служебными страницами.

Но даже здесь уже видно, зачем с самого начала нужны правила. Формально система нашла 11 потенциальных проблем с индексацией. Фактически проверять нужно было одну.

Сырые данные сначала пришлось привести в порядок

После сканирования Screaming Frog отдаёт таблицу со всеми найденными страницами и их параметрами: URL, статусом ответа, Title, Description, H1, доступностью для индексации и другими данными. Эту таблицу я сохраняю в формате CSV — по сути, это файл с теми же строками и столбцами, который удобно передать дальше в n8n.

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

На этом месте и возникла первая техническая проблема.

В первой версии ChatGPT предложил довольно простой разбор файла по разделителям. На чистых данных он работал. Потом в реальной выгрузке встретились запятые, кавычки, переносы строк и двойные кавычки внутри самих значений. Строки начали разъезжаться, значения попадали не в те поля, и дальше вся аналитика строилась уже на испорченных данных.

Я пришла обратно к ChatGPT с конкретными примерами битых строк, и мы переписали разбор CSV.

const item = $input.first();

const binary = item.binary?.data;

if (!binary) {

  throw new Error('Не найден binary.data с CSV-файлом');

}

const buffer =

  await this.helpers.getBinaryDataBuffer(0, 'data');

let csvText =

  buffer.toString('utf8');

csvText =

  csvText.replace(/^\uFEFF/, '');

function parseCSV(text) {

  const rows = [];

  let currentRow = [];

  let currentValue = '';

  let insideQuotes = false;

  for (let i = 0; i < text.length; i++) {

    const char = text[i];

    const nextChar = text[i + 1];

    if (

      char === '"' &&

      insideQuotes &&

      nextChar === '"'

    ) {

      currentValue += '"';

      i++;

      continue;

    }

    if (char === '"') {

      insideQuotes = !insideQuotes;

      continue;

    }

    if (

      char === ',' &&

      !insideQuotes

    ) {

      currentRow.push(currentValue);

      currentValue = '';

      continue;

    }

    if (

      (char === '\n' || char === '\r') &&

      !insideQuotes

    ) {

      if (

        char === '\r' &&

        nextChar === '\n'

      ) {

        i++;

      }

      currentRow.push(currentValue);

      if (

        currentRow.some(

          value => String(value).trim() !== ''

        )

      ) {

        rows.push(currentRow);

      }

      currentRow = [];

      currentValue = '';

      continue;

    }

    currentValue += char;

  }

  if (currentValue || currentRow.length) {

    currentRow.push(currentValue);

    rows.push(currentRow);

  }

  return rows;

}

const rows = parseCSV(csvText);

if (rows.length < 2) {

  throw new Error(

    'CSV пустой или содержит только заголовки'

  );

}

const headers = rows[0].map(

  header => String(header || '').trim()

);

const dataRows = rows.slice(1);

const output = dataRows.map(row => {

  const json = {};

  headers.forEach((header, index) => {

    json[header] = row[index] ?? '';

  });

  return { json };

});

return output;

После разбора файла система группирует найденные проблемы по типу задачи. Мне не нужен Telegram со списком из двадцати URL, после которого я должна сама ещё раз проводить аудит.

В техническом отчёте я хотела видеть примерно такое:

Редакция

Добавить Description

7 URL

SEO

Проверить индексацию

1 URL

Служебные страницы

Ожидаемый noindex

11 URL

Последняя группа остаётся в полной таблице, но срочной задачи из неё не возникает.

Метрика добавила поведение пользователей — пришлось учесть размер выборки

Из Яндекс Метрики я получаю данные по страницам входа из органического поиска за последние 30 дней: визиты, пользователей, отказы, глубину просмотра, среднее время и саму страницу входа.

Здесь системе снова пришлось объяснять вещь, которую человек обычно понимает без инструкции. Если у статьи один визит и 100% отказов, принимать на основании этого решение практически бессмысленно. Один пользователь в такой выборке и есть вся статистика.

Поэтому в расчётах появились пороги:

Десять посещений тоже не превращают показатель в истину, поэтому здесь у меня именно «осторожно».

И нейросети на этом этапе вообще нечего делать. Проверить, больше десяти визитов или меньше, обычный код всё-таки способен без помощи искусственного интеллекта.

Вебмастер помог понять, что происходит до перехода на сайт

По одной Метрике я видела только то, что уже произошло после перехода на сайт. Для SEO этого мало.

У страницы может быть ноль переходов из поиска по совершенно разным причинам. Она только опубликована, тема очень узкая, спрос сезонный, поисковик почти её не показывает или показывает достаточно высоко, но пользователь почему-то не кликает. В Метрике результат во всех этих случаях один — переходов нет.

Поэтому я добавила Яндекс Вебмастер. Оттуда агент получает показы, клики, CTR, среднюю позицию и данные по связанным поисковым запросам.

Например:

Последние семь дней

34 показа

0 кликов

CTR — 0%

средняя позиция — 8,2

Предыдущие семь дней

46 показов

2 клика

средняя позиция — 9,8

Теперь уже есть причина посмотреть страницу. Она показывается достаточно высоко, видимость есть, а кликов нет.

На одном из тестовых запусков Вебмастер вернул данные по 89 URL. Там же обнаружился ещё один технический нюанс: данные приходят с задержкой. Допустим, агент запускается 15 сентября, а последняя доступная дата в API — 13 сентября. Если взять последние семь календарных дней, 14 и 15 сентября внезапно превращаются в два дня с нулевыми показателями.

После одного такого теста мы поменяли логику. Сначала агент находит последнюю дату, за которую Вебмастер действительно отдал данные. От неё считает семь дней назад, а потом берёт предыдущий такой же период.

Мелочь, но именно из таких мелочей потом складывается отчёт, которому можно хотя бы начать доверять.

Из 113 публикаций мне были нужны далеко не все

На сайте есть большое количество URL со словом /publikatsii/. Внутри могут находиться SEO-статьи, продуктовые материалы, новости, PR, видео, подкасты, HR-блог и ещё много всего.

В одном из тестов таких страниц было 113.

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

Сначала я пыталась разделить контент обычными правилами: по URL, словам в заголовках и другим признакам. Правил довольно быстро стало слишком много, а предусмотреть все варианты всё равно не получалось.

Здесь мне впервые действительно понадобилась языковая модель.

Она смотрит на заголовок, описание и содержание страницы и относит материал к одной из нескольких групп:

• SEO- или продуктовый материал

• медиа

• новость / PR / брендовый материал

• не удалось определить

Идеальная редакционная классификация мне здесь вообще ни к чему. Нужно понять только одно: стоит ли включать страницу в регулярный SEO-анализ.

Первый запуск всех 113 публикаций я отдала дешёвой модели. Страницы уходили пачками по десять, полный проход занимал примерно пять-шесть минут.

После первого же полного прогона я посмотрела на эти 113 страниц и поняла, что через неделю снова платить модели за тот же самый ответ мне совершенно не хочется.

Память убрала повторную классификацию и лишние расходы на токены

У языковой модели нет причин помнить, что неделю назад мы уже определили статью как SEO-релевантную. Если каждую неделю спрашивать её заново, снова потратим деньги и время, а сама классификация ещё и будет немного плавать.

В одном тесте модель распределила страницы так:

57 — SEO / продукт

17 — медиа

39 — новости / PR

В другом запуске на тех же страницах:

52 — SEO / продукт

20 — медиа

41 — новости / PR

Поэтому на Google Диске у меня появилась большая таблица. Здесь она работает как внешняя память агента: перед новым запуском сценарий сначала проверяет, что уже знает о странице и какие решения по ней были приняты раньше.

В одной вкладке лежат все публикации: для каждой страницы сохраняются URL, Title, H1, Description, тип материала, признак участия в SEO-анализе, источник классификации, трафик, поисковые показатели, сигналы и дата обновления. Отдельная вкладка хранит еженедельные показатели, ещё одна — страницы, выбранные для глубокого анализа, ещё одна — результаты работы модели. Плюс настройки и ручные поля.

Последние для меня принципиальны. Если я сама посмотрела страницу и решила, что она относится к SEO-контенту, агент не имеет права через неделю передумать за меня и переписать это значение.

В итоге Google Таблицы стали историей всех страниц сайта. Telegram показывает только выжимку. Если её недостаточно, я открываю таблицу и могу посмотреть, что происходило с конкретной статьёй несколько недель назад: как она была классифицирована, почему получила приоритет и что советовала модель.

113 знакомых страниц — ноль новых обращений к модели

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

Сама проверка в n8n довольно простая:{{ $json.ai_classification_pages.length > 0 }}

Пустой список означает, что ветка с моделью вообще не запускается.

На контрольном прогоне получилось:

Всего публикаций: 113

Есть в базе: 113

Взяты из сохранённых данных: 113

Нужна новая классификация: 0

Новых страниц: 0

Изменённых страниц: 0

Все 113 страниц уже были знакомы системе. На их повторную классификацию мы не потратили ни одного нового обращения к модели.

Система баллов сокращает около 50 страниц до 5–7 кандидатов

После фильтрации у меня всё равно остаётся около полусотни SEO- и продуктовых страниц. Поэтому перед глубоким анализом агент считает приоритет по системе баллов:

Если итог меньше 20 баллов, страница в глубокий анализ не идёт. Эти значения нельзя использовать как готовую SEO-формулу: я выставляла их под свой сайт, объём данных и свои приоритеты.

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

И ещё одно правило: нулевой трафик сам по себе не даёт баллов. Иначе молодые или низкочастотные статьи постоянно побеждали бы в конкурсе «срочно что-нибудь со мной сделайте».

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

До сильной модели в итоге доходят пять-семь страниц

К этому моменту агент уже знает тип страницы, технические проблемы, трафик за 30 дней, показы, клики, CTR, позицию, динамику относительно прошлой недели, связанный поисковый запрос, баллы приоритетности и причину попадания в очередь.

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

Здесь ChatGPT тоже пришлось немного поправлять. В первой версии он предложил взять первые 2500 символов страницы. Но на реальном сайте модель иногда получала только меню, телефон, ссылки на разделы и другие элементы шапки. До самой статьи первые 2500 символов просто не доходили.

Мы переделали очистку HTML. Система сначала ищет <article>, затем <main>, в крайнем случае берёт <body>. Потом убирает шапку, навигацию, подвал, боковые блоки, формы, скрипты и стили.

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

Для модели я формулирую конкретную задачу вместо «сделай SEO-аудит»

Мне не нужен универсальный SEO-аудит страницы. Если попросить нейросеть «провести SEO-аудит», она предложит проверить H2, FAQ, перелинковку, Title, ключевые слова и ещё десяток базовых вещей.

Такой отчёт можно получить практически для любой страницы в интернете.

Мне нужна гипотеза, которая объясняет конкретные данные конкретной страницы. Поэтому смысл запроса выглядит примерно так:

Ты SEO-аналитик B2B SaaS в строительной отрасли.
Проанализируй конкретную страницу сайта.
Опирайся только на данные, которые переданы ниже.
Для каждого вывода укажи конкретный сигнал, на котором он основан.
При небольшой выборке отметь, что данных недостаточно
для уверенного вывода.
Твоя задача:

1. Кратко описать поисковую ситуацию страницы.

2. Выбрать наиболее вероятную гипотезу.

3. Предложить максимум три действия, которыми эту гипотезу можно проверить.

4. Для каждого действия указать ожидаемый результат.

СТРАНИЦА

URL:

${page.url}

Title:

${page.title || ''}

H1:

${page.h1 || ''}

Связанный запрос из Яндекс Вебмастера:

${page.top_query || 'нет данных'}

H2:

${h2Headings.join(' | ') || 'нет данных'}

Содержимое страницы:

${contentExcerpt || 'текст страницы получить не удалось'}

МЕТРИКА — 30 ДНЕЙ

Визиты из поиска:

${page.visits || 0}

Пользователи:

${page.users || 0}

Отказы:

${page.bounce_rate || 0}%

Глубина:

${page.page_depth || 0}

Среднее время:

${page.avg_visit_duration_text || '0 сек.'}

Дальше в запрос передаются показатели Вебмастера за две недели и сигналы, из-за которых страница вообще попала в очередь.

Ответ мне нужен не сплошным текстом, а в форме, которую сможет прочитать следующий узел сценария. Поэтому модель возвращает его в JSON — условно, раскладывает ответ по заранее заданным полям: гипотеза, рекомендации, причины, ожидаемый эффект, приоритет и уверенность.

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

Не запрещай — обучай

Первый глубокий анализ я запустила на дешёвой модели. Технически всё было ок: семь страниц пришли на вход, семь корректных JSON пришли на выход.

А вот с содержанием начали происходить чудеса.

Модель рассуждала о Description, которого вообще не было во входных данных. По восьми визитам и 50% отказов могла сделать довольно уверенный вывод о проблеме с намерением пользователей. Периодически появлялись рассуждения о конверсии, хотя информацию о конверсии я ей вообще не давала.

Особенно сильно она цеплялась за один связанный поисковый запрос из Вебмастера. Для одной страницы Вебмастер показал запрос со словом «отзывы». Модель сразу решила добавить отзывы на страницу, вынести слово в Title и добавить соответствующую разметку.

Из одного запроса внезапно выросла целая SEO-стратегия.

ChatGPT в процессе разработки предложил лечить эти галлюцинации дополнительными запретами в промпте:

• не выдумывай Description

• не делай выводы о конверсии

• не считай один запрос главным

• ...

Эту ветку я сразу пресекла. Строить промпты из десятков запретов — плохая стратегия. Чем длиннее список «не делай вот этого», тем больше внимания модель начинает уделять именно этим сущностям.

Это примерно как «только не думай о пирожках». Поздравляю: теперь мы оба думаем о пирожках.

Я оставила исходную задачу и позитивно сформулировала правила: используй только переданные данные, показывай основание каждого вывода, указывай недостаточность выборки, предлагай максимум три проверяемые гипотезы.

После этого на тех же семи страницах я просто поменяла модель на более сильную.

Разница оказалась очень ощутимой. При 29 или 34 показах модель сама отмечала, что данных мало и делать уверенный вывод по CTR рано. В другом материале она заметила смысловую разницу между запросами «управление затратами» и «затраты на управление».

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

Для массовой классификации мне такой уровень рассуждений не требуется. А вот для пяти-семи страниц, которые уже прошли все фильтры и действительно требуют решения, более дорогая модель вполне оправдана.

Еженедельная сверка нужна, чтобы отличать изменение от тренда

Кроме основной таблицы с текущим состоянием страниц, раз в неделю агент сохраняет сверку поисковых показателей. Для каждой SEO-релевантной страницы записываются период, показы, клики, CTR, позиция и изменения относительно прошлой недели.

На одном из тестовых запусков история сохранилась по 52 страницам. Чтобы повторный запуск сценария в ту же неделю не создавал дубль, строка получает уникальную метку из даты и URL: week_end|url

Например:

2026-09-13|https://site.ru/publikatsii/example

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

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

В итоге в Telegram приходят те самые три отчёта

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

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

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

Третье — обзорное: самые посещаемые страницы, их трафик, глубина и заметные изменения в поиске.

Полный SEO-отчёт в Telegram мне оказался не нужен. Если короткого сообщения не хватает, только тогда я открываю Google Таблицы и смотрю всю историю.

Что я планирую доработать

Самый заметный технический план сейчас связан с определением изменений страницы. Для повторной классификации я пока проверяю в первую очередь Title и H1. Если редактор полностью переписал тело статьи, но сохранил заголовки, система может решить, что ничего не изменилось.

Следующий шаг — считать хеш содержимого страницы. По сути, это короткий цифровой отпечаток текста: если содержание страницы изменилось, изменится и хеш. Так агент сможет замечать правки даже при прежних Title и H1.

Есть ещё один нюанс с HTML. Сейчас сценарий успевает скачать содержимое публикаций до того, как окончательно проверяет, нужна ли им новая классификация:

скачать HTML 113 страниц

↓

проверить сохранённую классификацию

↓

понять, что все 113 уже известны

↓

0 обращений к модели

Оптимальнее сначала проверить URL, Title и H1 по таблице и скачивать содержимое только у новой или изменённой страницы. До этой оптимизации я пока не дошла — для первой рабочей версии она не была критичной.

Вебмастер сейчас тоже даёт ограниченный контекст по поисковым запросам. Одного популярного связанного запроса мало для серьёзного анализа семантики. В следующих версиях хочу передавать модели более полный набор запросов с показами, CTR, позициями и динамикой.

Сам агент пока не принимает за меня SEO-решения. Его задача — собрать данные, убрать шум, показать изменения и помочь сформулировать гипотезу. Все реальные решения принимаю я.

Сколько всё это стоит и получится ли экономить на SEO

Сейчас расходы на инфраструктуру выглядят примерно так:

Keys.so в базовой схеме не обязателен. Я подключаю и отключаю его под отдельные задачи, когда этого требует конкретная гипотеза.

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

Поэтому пока основной эффект я считаю именно во времени. Раньше для SEO-статьи нужно было отдельно смотреть семантику, изучать конкурентов, собирать ТЗ, проверять материал, а потом ещё не забыть вернуться к нему после публикации. Контент-отдел при этом занимается множеством других задач, поэтому на SEO у нас оставался ресурс примерно на два-четыре материала в месяц — и это в лучшем случае.

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

То же самое с результатами для самого SEO. Я пока не могу сказать, что агент увеличил трафик на 40%, CTR на 20% и принёс сто лидов. Нужно накопить историю, внедрить достаточное количество рекомендаций и посмотреть на результат через несколько месяцев.

Пример: какое ТЗ в итоге получает копирайтер

Ниже — фрагмент реального ТЗ, которое агент подготовил после глубокого анализа страницы. 

Цель переработки

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

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

Целевая аудитория

• руководитель отдела снабжения или закупок;

• руководитель проекта;

• финансовый директор;

• специалист планово-экономического отдела;

• руководитель компании, отвечающий за рентабельность проектов. 

Что сохранить

• Базовое объяснение пользы мониторинга для закупок, бюджета проекта, себестоимости и планирования.

• Перечень факторов, влияющих на цены: сезонность, валютные курсы, энергоресурсы, спрос и предложение, регулирование.

• Разделение методов на ручные и автоматизированные.

• Упоминание торговых площадок, сервисов мониторинга и аналитических систем как возможных источников данных.

• Связь мониторинга цен с закупочным процессом и выбором предложений поставщиков.

• Нейтральный информационный тон без превращения материала в рекламную страницу продукта. 

Что переработать

• Убрать или сократить общие декларации, если за ними не следует конкретный механизм или пример.

• Во вводном блоке сразу объяснить, что понимается под мониторингом цен, какие решения он поддерживает и чем отличается от простого сбора прайс-листов.

• Не смешивать мониторинг рыночных цен с полным управлением затратами.

• Раздел «Методы мониторинга» перестроить вокруг критериев сравнения: актуальность данных, сопоставимость условий, трудозатраты, охват поставщиков и возможность использовать результат при закупке.

• В разделе «Инструменты» объяснить место каждого решения в процессе: источник данных, сравнение, согласование закупки, фиксация обязательства и контроль отклонения.

• Любые цифры и характеристики продукта оставлять только при наличии актуального подтверждения.

• Финальный перечень советов заменить рабочим алгоритмом и чек-листом.

Фрагмент рекомендуемой структуры

H2 — Как организовать мониторинг цен: рабочий процесс

Зачем этот блок: закрыть главный практический интент статьи — объяснить последовательность действий.

Что написать: в начале дать короткую схему процесса: определить номенклатуру и базу сравнения, выбрать источники, собрать предложения, привести условия к сопоставимому виду, проверить отклонения, использовать результат при закупке и обновить прогноз проекта. Затем раскрыть шаги отдельно.

Какие данные и доказательства нужны: процесс должен быть проверен профильным специалистом. Нельзя описывать этапы продукта как существующие функции без подтверждения. 

Например, дальше модель отдельно расписывает:

1. Определить номенклатуру и базу сравнения.

2. Выбрать источники и собрать актуальные предложения.

3. Нормализовать и сравнить условия.

4. Связать цену с лимитом, обязательствами, фактом и прогнозом.

5. Разобрать отклонение и принять решение. 

Требования для нейроответов

Отдельно модель сформулировала требования к тому, как материал должен читаться в поисковых и нейроответах:

• определение мониторинга цен должно быть сформулировано самостоятельным абзацем и включать сбор, нормализацию, сравнение и применение данных;

• отдельный фрагмент должен объяснять разницу между мониторингом рыночных цен и управлением всеми затратами проекта;

• определения лимита, обязательства, факта и прогноза должны быть краткими и понятными без знания продукта;

• процесс мониторинга должен извлекаться как законченная последовательность шагов;

• сравнение методов должно строиться по явным критериям без неподтверждённых рейтингов;

• алгоритм реакции на отклонение должен работать как самостоятельный ответ;

• продуктовый блок должен описывать проверяемый сценарий работы;

• пример должен отделять подтверждённые факты от условной иллюстрации;

• каждая цифра или характеристика рынка должна сопровождаться источником и контекстом. 

Что запросить у эксперта

Дальше ТЗ само собирает список фактуры, которой не хватает для качественной переработки:

• какие параметры, кроме цены за единицу, нужно учитывать при сравнении предложений;

• как определяется сопоставимая номенклатурная позиция;

• какие источники цен используются в реальном процессе;

• как разграничиваются лимит, согласованное изменение, обязательство, факт и прогноз;

• кто видит отклонение и что происходит после его обнаружения;

• есть ли обезличенный сквозной пример от потребности до принятого решения. 

Что нельзя придумывать

• динамику цен и проценты изменения;

• количество поставщиков и предложений;

• экономию и другие результаты использования продукта;

• сроки внедрения и получения эффекта;

• функции продукта без подтверждения команды;

• универсальные пороги и периодичность мониторинга;

• нормативные и бухгалтерские выводы без проверки специалистом. 

С чего начать, чтобы повторить проект

Я бы взяла обычный лист бумаги или таблицу и описала свой ручной процесс: какие данные я смотрю, какие решения принимаю и почему. Потом разделила бы этот процесс на операции.

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

И заранее подумала бы, что произойдёт на втором, десятом и пятидесятом запуске.

У меня итоговая цепочка сейчас выглядит так:

получить данные

↓

очистить

↓

привести к общей структуре

↓

сопоставить страницы между источниками

↓

посмотреть сохранённую историю

↓

посчитать понятные сигналы

↓

выбрать несколько страниц

↓

подключить языковую модель

↓

сохранить гипотезу

↓

показать человеку

↓

через неделю проверить результат

А если хочется повторить кейс и не разбираться во всём с нуля, самый простой способ — показать статью ChatGPT или Claude и сказать, что хотите собрать похожую систему под свои задачи. Попросите провести вас по схеме по шагам и объяснять каждый шаг как новичку.