ИИ-агенты для SEO: какие процессы стоит автоматизировать, а какие — пока рано

Представьте планёрку. Руководитель SEO-отдела говорит: «В следующем квартале внедряем ИИ-агентов — автоматизируем SEO». Все кивают, кто-то уже прикидывает, сколько строк в бюджете уйдёт на подписки, а через месяц выясняется неприятная вещь: «автоматизировать SEO» — это примерно как «автоматизировать бизнес». Звучит как план, а на деле это не задача, а направление, под которым может скрываться что угодно: от скрипта, который раз в неделю выгружает отчёт по позициям, до системы, которая сама что-то публикует на сайте без согласования.

Если коротко, ИИ-агент — это не чат-бот, который отвечает на один вопрос, а система, которая сама планирует шаги, вызывает нужные инструменты и доводит задачу до результата без присмотра человека на каждом шаге. У этого определения есть неудобное следствие: агенту нужна задача с понятными границами — вход, выход и критерий «готово». «SEO» целиком под такое определение не подходит. Это десятки разных процессов, и у значительной части из них вообще нет единого критерия правильности.

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

Разница похожа на найм сотрудника без должностной инструкции. Можно посадить нового человека в команду и сказать «занимайся SEO» — и он будет метаться между десятком задач, не понимая, что от него ждут и по какому критерию оценят результат. А можно дать конкретное поручение с понятным результатом — и тогда даже стажёр справится за неделю. С агентом то же самое: разница не в том, насколько он «умный», а в том, насколько чётко сформулирована задача.

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

• Повторяемость. Задача выполняется регулярно и примерно одинаковым образом — а не раз в год по особому случаю.
• Понятное «готово». Есть чёткий критерий, что результат правильный, а не ощущение «на глаз вроде похоже».
• Минимум неоднозначных суждений. Решение не зависит от истории отношений с конкретным клиентом, от невыписанной стратегии компании или от личного вкуса того, кто обычно это делает.

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

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

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

Если собрать процессы, которые в SEO- и контент-командах чаще всего проходят проверку из предыдущего раздела, получится список примерно из четырёх категорий: техническое SEO, контент-операции, мониторинг видимости (в том числе в AI-системах) и репортинг.

Обратите внимание на закономерность в правом столбце: там почти никогда не написано «ничего, агент справится сам». Даже у самых механических процессов остаётся точка, где решение принимает человек — просто эта точка сужена до одного конкретного вопроса вместо целого процесса целиком. В этом и есть практическая выгода декомпозиции: вместо «отдать или не отдать SEO агенту» вопрос превращается в «агент готовит 90% работы, человек отвечает за один узкий шаг».

Процесс №7 из таблицы — по сути тот же паттерн, что лежит в основе AI Control: агентоподобная система по расписанию прогоняет один и тот же набор промптов через ChatGPT, Perplexity, Copilot, Gemini и Google AI и фиксирует, упоминается ли бренд в ответе, с историей по времени. Это не реклама, а скорее честный пример того, что шаблон «мониторинг по расписанию» не нужно придумывать с нуля для каждой новой задачи: чёткий вход (набор промптов), чёткий выход (упомянут или нет, в каком контексте), минимум суждений на этапе сбора данных — суждения начинаются уже потом, на этапе интерпретации. Подробнее о механике такого мониторинга — в материале про мониторинг промптов для AI-поиска.

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

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

Раз в неделю краулер отдаёт агенту сырой отчёт — условно 900–1500 строк: битые ссылки, 5xx-ответы, редиректы длиннее двух хопов. Агент группирует их по шаблону страницы (карточка товара, категория, статья блога) и по примерному объёму трафика на эти URL за последние 28 дней, затем сортирует группы по оценочному ущербу — не по алфавиту и не по дате обнаружения. На выходе получается не 1200 разрозненных строк, а условно 15–20 сгруппированных карточек с кратким описанием проблемы и числом затронутых URL в каждой.

SEO-специалист открывает не сырой отчёт, а эти 15–20 карточек и тратит на просмотр не часы, а минут двадцать — решает, какие группы чинить в текущем спринте, а какие могут подождать до следующего релиза. Это и есть разделение труда из раздела выше: агент берёт на себя механическую часть (сбор, группировку, сортировку по правилу), человек — решение о приоритете, которое зависит от контекста конкретного сайта и текущего спринта.

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

Если свести всё выше к одному простому делению, получится примерно такая карта.

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

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

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

Опиши процесс [название], который я рассматриваю для автоматизации через ИИ-агента. Ответь на вопросы по порядку и будь предельно конкретным.

1. ВХОД. Что именно агент получает на входе — структурированные данные (таблица, API-ответ) или свободный текст, который сначала нужно интерпретировать?
2. ВЫХОД. Как выглядит правильный результат? Можно ли описать его без слова «примерно»?
3. КРИТЕРИЙ ГОТОВНОСТИ. Как я или клиент поймём, что задача выполнена верно, без ручной перепроверки каждого отдельного случая?
4. ТОЧКИ ПРИНЯТИЯ РЕШЕНИЙ. Сколько раз за выполнение процесса нужно выбирать между вариантами, которые зависят от контекста, а не от фиксированного правила?
5. ЦЕНА ОШИБКИ. Что произойдёт, если результат окажется неверным и это не заметят до публикации или отправки клиенту? Это час переделки или удар по доверию?
6. ЧАСТОТА. Как часто процесс повторяется — ежедневно, раз в квартал? Окупится ли время на настройку агента при такой частоте?
7. ОТКАТ. Если агент ошибся, легко ли это заметить и откатить до того, как результат кто-то увидит?

На основе ответов дай вердикт: «хороший кандидат на автоматизацию», «кандидат с человеком в контуре» — агент готовит черновик, человек утверждает, — или «рано». Объясни, какой именно пункт стал решающим.

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

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

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

Это не повод отказываться от агентов для клиентских и публичных процессов — скорее повод чётко разграничивать, где агент действует автономно, а где каждый результат проходит через утверждение человека перед тем, как его увидит кто-то снаружи команды. Граница обычно проходит не по типу задачи («репортинг» или «контент»), а по аудитории результата: внутренний рабочий документ — один уровень риска, текст, который увидит клиент или попадёт в публичный интернет, — совсем другой.

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

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

1. Выпишите 10–15 регулярных задач команды за последний месяц — без предварительной фильтрации «это точно не для автоматизации».
2. Для каждой отметьте: есть ли чёткий вход и выход и можно ли описать «готово» без «на глаз виднее».
3. Вычеркните всё, где результат зависит от отношений с конкретным клиентом или от незадокументированной стратегии.
4. Прогоните оставшееся через промпт-интервью из раздела выше и честно зафиксируйте цену ошибки для каждого пункта.
5. Начните с процесса, где агент готовит черновик, а человек утверждает финальный результат, — не с полностью автономного публичного действия.
6. Измеряйте не только сэкономленное время, но и то, сколько раз черновик агента пришлось переделывать с нуля.
7. Расширяйте список процессов только после того, как первый отработал на реальных данных месяц-два без инцидентов.