Автоматизация SEO нейросетями: шесть задач с примерами промптов и внедрения

Представьте: вы открываете утром чат, а там сообщение клиента: «Клики просели. Что случилось?» Вы заходите в Яндекс Вебмастер, выгружаете данные, открываете Метрику, сводите таблицы. Затем проверяете страницу за страницей. Клиент ждет объяснения, но вы все еще собираете цифры. Может быть даже вспоминаете, что для прошлого отчета вы уже проделали тот же путь, а теперь приходится делать все заново.

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

В основе материала — 20 публикаций за период с января 2025 по сентябрь 2026 года: кейсы специалистов, исследования и доклады.

Первый шаг - подготовить данные о сайте и бизнесе

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

Для строгого отбора информации нужно подготовить профиль бизнеса:

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

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

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

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

Как объединять метрики без дублирования результатов

Если вы объединяете данные Вебмастера и Метрики, сначала проверьте, что означает одна строка в каждой выгрузке. Допустим, в Вебмастере у одного URL за день есть десять строк с разными запросами, а в Метрике — одна строка с пятью целевыми визитами. Если соединить таблицы только по URL и дате, пять целевых визитов повторятся в десяти строках. При последующем суммировании получится 50 вместо пяти.

Чтобы избежать ошибки, сначала суммируйте клики и показы Вебмастера до уровня «один URL за один день», затем добавьте показатели Метрики на том же уровне. Согласуйте периоды, регионы, устройства и правила записи URL в обеих выгрузках.

После объединения сверьте суммы каждого показателя с исходным отчетом. Клики Вебмастера и визиты Метрики проверяйте отдельно: они измеряют разные действия и не обязаны совпадать.

Что можно подключить для быстрого сбора данных

MCP PR-CY поможет вам собрать данные в одном проекте: результаты аудита, позиции и показатели подключенных систем аналитики. Из этих данных можно будет составить отчет об изменениях страниц и динамике поиска. Какие данные будут доступны вам, зависит от настроек проекта и интеграций. Подключение подробно описано на странице о MCP PR-CY.

Теперь перейдем от подключения к конкретным задачам. В каждом сценарии подробно разберем, какие данные получает модель, что показывает чужой опыт и как составить задание на примере MCP PR-CY.

Шесть задач, которые можно включить в автоматизацию SEO

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

Эдуард Трубченинов, основатель агентства поискового продвижения PrivateSEO

1. Группировка запросов и проектирование страниц

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

Сходство слов еще не означает одинаковый интент. Запросы «ремонт ноутбука» и «как отремонтировать ноутбук самому» могут потребовать разные страницы (услуги и инструкции). Поэтому группировку лучше сверять с поисковой выдачей - смотреть, какие типы страниц и URL присутствуют по обоим запросам.

В кейсе Гаэля Бретона агент проектировал структуру сайта местного сантехника. После отбора услуг ему предстояло распределить запросы по страницам. По словам автора, агент через Ahrefs MCP изучил 47 конкурентов и подготовил карту из более чем 900 страниц примерно за 30 минут. Автор оценил расходы на API примерно в 3 доллара.

После такой сборки нужно обязательно проверить, не предлагают ли разные группы одну и ту же страницу. Бывает и так, что нужно проверить интент еще до генерации контента - так, например, сделал Хаммад Аббаси, потому что у него возникла проблема каннибализации. Можно запросить у модели решение по каждой группе: обновить существующий URL, создать страницу или исключить запросы с объяснением:

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

Практика: собрать семантику с проверкой существующих URL

Чтобы повторить этот этап на своем сайте, вам понадобятся не только новые запросы, но и уже назначенные страницам ключи. В проекте PR-CY у вас уже могут быть ключевые слова с целевыми URL. ИИ-помощник сверяет с ними новые запросы, чтобы предложить доработку существующей страницы или создание новой.

Для example.com подготовь семантику по теме «ремонт ноутбуков». Условия примера: сервис обслуживает частных клиентов в Москве, выезд не предоставляет. Используй MCP PR-CY: Wordstat для фраз «ремонт ноутбуков, замена экрана ноутбука, чистка ноутбука», типы general и quoted; выдачу Яндекса, Москва, desktop, топ-10. Сверь группы с ключами и целевыми URL проекта. Верни запросы с исходной частотностью, интент, предлагаемую страницу и спорные пересечения. Запросы вне услуг вынеси в другой список. Результат — список для согласования без изменения ключей проекта.

Помощник получает регион через get_region(engine="yandex", region="Москва"). Затем одним get_wordstat запрашивает все исходные фразы строкой через запятую, передавая полученный ID в regions и типы соответствия в types.

По основным и спорным запросам get_serp возвращает выдачу с одинаковыми engine, region и device. Через get_keywords помощник читает ключи проекта и целевые URL, учитывая limit и offset. Он сопоставляет выдачу с существующими страницами, предлагает группы и отмечает, какие страницы можно обновить.

2. Аудит страниц: классификация контента и технические проверки

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

В кейсе Workshop Digital агентство описывает обработку более 30 тысяч страниц десяти сайтов перед переносом контента. Screaming Frog сохранял HTML, GPT-5-mini относил страницы к внутреннему, внешнему или смешанному контенту и объяснял свой выбор. Команда агентства уточняла правила на пакетах по 10-20 страниц. Кейс показывает, зачем нужно проверять категории до обработки всего сайта: даже лишние общие слова из меню влияли на ответ модели.

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

Практика: найти технические ошибки по аудиту

Следующий пример посвящен именно техническим ошибкам. По данным аудита помощник готовит черновик задач с примерами URL и критериями приемки.

Для проекта example.com прочитай последний завершенный аудит через MCP PR-CY. Разбери URL по группам с HTTP 404, запретом индексации и дублирующимся title. Для каждой проблемы покажи масштаб из сводки, до пяти URL-примеров, возможное влияние и задачу разработчику с критерием приемки. Раздели факты и предположения. Если аудит выполняется, явно отметь неполноту. Верни черновик задач для проверки SEO-специалистом.

Сначала get_crawler_analysis_summary(domain="example.com", history="none") показывает состояние и число страниц с проблемами. Если is_updating=true, сводка получается неполная: помощник сообщает об этом, а окончательное число затронутых страниц он записывает после завершения обхода.

Помощник получает страницы через get_crawler_pages отдельными выборками: например, status_code=404, no_index=true и duplicated_title=true. Эти фильтры объединяются через И: если передать все три в одном запросе, ответ покажет только их пересечение. Небольшое значение limit помогает получить примеры, для полного списка помощник использует пагинацию.

Практика: найти изменения на сайте после релиза

Проверь example.com после релиза 24 сентября 2026 года. Через MCP PR-CY найди за 24-27 сентября страницы, получившие HTTP 404, новые запреты noIndexMeta и изменения canonicalFromHtml. Выполни отдельные выборки и укажи даты найденных изменений. Сопоставь их с событиями и заметками проекта за те же календарные дни, учитывая часовой пояс и правила включения дат в период у каждого инструмента. Верни URL, предыдущие и новые значения, связь с релизом как гипотезу и способ проверки.

Для релизной проверки get_changed_crawler_pages ищет одно измененное поле за вызов. Например, field="statusCode", value=404 находит страницы, получившие этот код; field="noIndexMeta", value=true — закрытые метатегом; field="canonicalFromHtml" — изменения canonical без параметра value. Для каждого запроса помощник задает начало и конец периода. История полей в ответе содержит записи за весь доступный срок, помощник выделяет нужные по дате.

У get_changed_crawler_pages обе даты включены в период, а часовой пояс соответствует настройкам аккаунта. А у get_project_events конечная дата не включена; начало и конец периода задаются по всемирному координированному времени (UTC). Для событий за 27 сентября по UTC нужен date_to="2026-09-28". get_project_notes принимает project_id и включает обе даты.

3. Исследование темы, бриф и черновик статьи

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

Профиль компании не дает ИИ всех нужных фактов для создания статьи. Источники для написания нужно собрать до генерации — это показывает кейс Лукаса Вальтера. Каталог ИИ-инструментов передавал процессу собственные данные о категории и продуктах. Человек запускал Deep Research и отправлял ИИ исследовательский отчет; после этого LLM писала отдельные секции и отправляла материал в CMS. Автор сообщает о более чем 30 итерациях промпта.

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

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

Практика: составить бриф по актуальной выдаче

В следующем примере объединим задачи: исследовать выдачу, составить бриф и перечислить факты, которых пока нет.

Через MCP PR-CY подготовь бриф для статьи example.com/blog/kak-vybrat-noutbuk по теме «как выбрать ноутбук для учебы». Аудитория — родители школьников; задача — выбрать характеристики под учебные программы без лишних расходов. Получи топ-10 Яндекса по России на desktop, выбери 3-4 информационные страницы и прочитай их. Верни структуру с тезисами и ссылками на источники, вопросы читателя, пробелы конкурентов и список фактов, которые нужно уточнить у эксперта. Предложи title и description. Условия и характеристики товаров используй только из предоставленных материалов компании.

Помощник сохраняет в брифе структуру выбранных материалов, ссылки на источники и вопросы к эксперту. Для исследования достаточно API-ключа и вводных о читателе; проект нужен, если требуется сверка с уже закрепленными ключами. Помощник получает get_serp по основному запросу и отбирает 3-4 информационные страницы. Для обзора большого списка подойдет get_page_content(format="structure"); выбранные источники помощник читает через format="md".

4. Анализ выбранной страницы перед обновлением и подготовка метатегов

После выбора страницы для обновления соберите ее текущий текст, поисковые запросы и показатели Яндекс Вебмастера: показы, клики, среднюю позицию и CTR. Эти данные вместе с выдачей по основным запросам помогут модели предложить изменения в содержании, title и description.

Отбор страниц и проверка текста — два разных этапа. Разницу показывает следующий пример с Реддита. В сценарии автоматизации код искал страницы с позициями 5-15, большим числом показов и низким CTR. Выбранная страница вместе с запросами попадала в Gemini, после чего код проверял предложенные правки. При первом запуске модель выдала метаописание в 160 символов при заданном максимуме 155. Сбой в этом кейсе произошел уже после выбора страницы: модель нарушила требование к длине текста. Чтобы обнаружить такую ошибку, скрипт после генерации считает символы.

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

Эдуард Трубченинов, основатель агентства поискового продвижения PrivateSEO

Практика: обновить конкретную статью

Для example.com/blog/kak-vybrat-noutbuk через MCP PR-CY сравни запросы Вебмастера за 21-27 и 14-20 сентября 2026 года. Получи текущий текст и проверь выдачу Яндекса по трем релевантным запросам, Москва, desktop. Раздели статистику Вебмастера и разовую проверку выдачи Яндекса. Верни изменения кликов и показов, вопросы, которые статья не закрывает, план доработки и варианты title/description. Максимальная длина вариантов в этом примере: 60 и 155 символов; покажи фактическую длину. Если данных Вебмастера нет, сообщи об этом и подготовь только контентный разбор.

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

Нужен проект с подключенным Яндекс Вебмастером и точный URL. get_keywords_pages_summary получает запросы страницы: source="webmaster", фильтр url с compare_type="equals", текущий и предыдущий периоды через date_from/date_to и prev_date_from/prev_date_to. Помощник читает все нужные строки с учетом пагинации.

Далее get_page_content(format="md") возвращает текущую статью, а get_serp — выдачу по выбранным запросам в согласованном регионе и на одном устройстве. Модель составляет план изменений, опираясь на текст и запросы страницы.

5. Предложения для внутренней перелинковки

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

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

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

Практика: создать анкоры на основе реальных фрагментов

Для example.com/blog/kak-vybrat-noutbuk предложи до трех внутренних ссылок через MCP PR-CY. Кандидаты: example.com/blog/operativnaya-pamyat и example.com/blog/ssd. Если страницы недоступны, не придумывай им содержимое. Прочитай доступные статьи и проверь, нет ли уже таких ссылок в исходной странице. Для каждого предложения верни точную исходную цитату, анкор, полный целевой URL и фрагмент после вставки. В другом списке укажи, какие страницы не удалось проверить.

Помощник получает кандидатов из предоставленного списка URL или get_pages_summary подключенного проекта, например с фильтром url={"value":"/blog/","compare_type":"contains"}. Отчет поисковой консоли не включает все существующие страницы, поэтому может потребоваться дополнительный список всех URL блога.

ИИ читает исходную статью и выбранные целевые материалы через get_page_content. format="html" нужен, если требуется проверить существующие ссылки в содержимом, а format="md" — для смыслового разбора. Ответ содержит точную цитату из исходного текста и соответствующий фрагмент после вставки ссылки.

6. Регулярные отчеты и объяснение изменений

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

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

Эдуард Трубченинов, основатель агентства поискового продвижения PrivateSEO

Практика: составить недельную сводку с источниками

Собери недельный отчет example.com через MCP PR-CY за 21-27 сентября в сравнении с 14-20 сентября 2026 года. Используй Вебмастер для кликов и показов, историю позиций PR-CY для Яндекса, Москва, desktop, и события/заметки проекта. Покажи до десяти страниц с наибольшим абсолютным падением кликов; назови охват исходной выборки. Раздели наблюдения, гипотезы и следующие проверки. Укажи даты, источники и настройки поиска. Недоступные источники перечисли в другом списке.

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

Для отчета с поисковыми кликами вам нужно подключить к проекту Яндекс Вебмастер; для истории позиций по заданным запросам — добавить ключи и параметр поиска. get_pages_summary сравнивает два периода, а get_user_keywords_projects возвращает настройки системы, региона и устройства. Помощник выбирает нужный search_options_id и передает его в get_keywords_positions_history.

ИИ получает события через get_project_events по домену, а заметки — через get_project_notes по ID проекта. У событий конец периода исключен и используется UTC; у заметок обе даты включены. В списке событий ориентируются на has_more, а не на число записей в очередном ответе.

Практика: проверить результаты оптимизации по целям Метрики

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

Для example.com сравни органический трафик и конверсию по цели «Отправка формы» за 21-27 и 14-20 сентября 2026 года через MCP PR-CY. Найди цель в списке Метрики, покажи ее ID; при нескольких совпадениях запроси выбор. Получи отчет по источникам и посадочным страницам, выдели органический поиск и укажи охват данных. Сохрани названия метрик и объясни знаменатель коэффициента конверсии. Верни изменения, сведения о неполноте данных и следующие проверки без вывода о выручке.

Сначала get_metrika_goals возвращает реальные ID и названия целей. get_metrika_conversion_rate_by_source_and_landing получает показатели по выбранному goal_id, источнику и посадочной странице; для сравнения периодов помощник вызывает инструмент дважды.

Как проверить ответ помощника

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

Ольга Костенко, SEO-маркетолог, руководитель агентства okostenko.agency

Разберем на условном примере недельного отчета. По исходному отчету Метрики органический трафик изменился так:

• Визиты: с 1 000 за 14-20 сентября до 800 за 21-27 сентября 2026 года.
• Пользователи: с 800 до 640 за те же периоды.
• Визиты на страницу /blog/kak-vybrat-noutbuk: с 200 до 150.

Помощник подготовил вывод:

Органические визиты снизились на 25%. Страница о выборе ноутбука потеряла трафик из-за обновления текста.

При проверке специалист обнаружил две ошибки. Помощник разделил разницу на показатель текущей недели: 200 ÷ 800 × 100 = 25%. Для расчета снижения относительно предыдущей недели нужен исходный показатель: 200 ÷ 1 000 × 100 = 20%. Кроме того, в переданных данных нет сведений об обновлении текста, поэтому названная причина не подтверждена.

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

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

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

1) Максимально точно формулировать запрос (если не знаешь - говори не знаю).
2) Использовать простые паттерны (детерминировать сложные запросы на подзадачи).

Один из способов выявить нестабильность ответа - задать один и тот же вопрос несколько раз и сравнить результаты. Если модель при одинаковых исходных данных начинает давать разные факты или выводы - это повод дополнительно проверить результат.

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

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

Иван Сиваков, Senior SEO компании WSS. Специалист в области E-commerce, Fintech, Medicine, AIO

Как устроен запуск еженедельного отчета по расписанию

В примерах выше вы сами отправляете задание помощнику. Если вы уже протестировали эти примеры и все работает, как надо (помощник выбирает нужные периоды и фильтры, расчеты сходятся с исходным отчетом, выводы можно проверить по полученным данным), можно автоматизировать запуск задач по расписанию. Расписание и доставку результата в этом сценарии задает платформа автоматизации рабочих процессов (например, n8n).

Допустим, вы хотите получать черновик недельного отчета на почту каждый четверг. Ниже — примерная схема для такой настройки. Для ее реализации вам потребуется настроить доступ к источникам, вызов ИИ-помощника с инструментами MCP PR-CY, хранение результатов и отправку писем.

1. Вы задаете расписание запуска. Например, четверг, 10:00, часовой пояс Europe/Moscow. Перед включением расписания нужно проверить цепочку вручную.
2. Цепочка определяет периоды и сохраняет параметры запуска. Для сравнения она выбирает две завершенные недели с понедельника по воскресенье. В запись запуска попадают идентификатор проекта, даты и фильтр поискового трафика. При повторной попытке цепочка использует эти же параметры.
3. Помощник получает данные через MCP PR-CY. Он запрашивает показатели Метрики и данные по посадочным страницам.
4. Скрипт рассчитывает изменения, а модель готовит пояснения к ним. Цепочка сохраняет ответы источника, проверяет наличие нужных полей и рассчитывает разницу показателей. Затем модель составляет черновик: что изменилось, какие страницы требуют внимания и какие гипотезы нужно проверить. Если данных не хватает, цепочка останавливает подготовку отчета и отправляет уведомление: какой источник недоступен, за какой период не получены данные и что нужно проверить перед повторным запуском.
5. Платформа сохраняет черновик отчета и отправляет вам письмо со ссылкой на него. Перед доставкой цепочка проверяет запись об отправке, чтобы не прислать тот же отчет второй раз.

Как можно сократить вызовы к модели

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

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

В том же докладе автор разбирает и повторяющееся оформление: для карточек и графических отчетов Лазарина предлагает один HTML/CSS-шаблон с подстановкой данных вместо новой генерации изображения для каждого результата.

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

Чек-лист: как запустить первый тест

Поставим ИИ задачу - подготовку недельного отчета через MCP PR-CY. Помощник должен сравнить органический трафик за две полные недели, назвать страницы с наибольшими изменениями и предложить, что проверить дальше.

1. Подготовьте доступ к данным. Проверьте, что нужный проект и данные Яндекс Метрики доступны в PR-CY. Подключите MCP PR-CY к ИИ-клиенту по инструкции. Сохраните исходный отчет Метрики за выбранные недели для сверки.
2. Поставьте задачу. Для недельного отчета укажите сайт, две полные недели и показатели: визиты и пользователи из поисковых систем. Ответ ИИ должен содержать исходные числа, изменения по страницам и предложения для дальнейшей проверки.
3. Проверьте весь отчет вручную по Метрике. Сверьте периоды, фильтр поискового трафика, числа и расчеты.
4. Посчитайте расходы и доработки. Запишите, сколько результатов вы приняли сразу, сколько исправили и сколько отклонили, а также сколько времени занял весь запуск.
5. Повторите процесс на новом наборе данных. Если правила работают и на нем, можно расширять объем и подключать автоматизацию.

Промпт для подготовки недельного отчета:

Для этой задачи используй MCP PR-CY. Найди проект [домен]. По данным Яндекс Метрики сравни органический трафик за [первая полная неделя] и [вторая полная неделя]. Укажи визиты и пользователей за каждый период и изменения этих показателей. Выдели пять страниц с наибольшим снижением числа визитов из поисковых систем. Назови источник, периоды и фильтры. Раздели наблюдения, гипотезы и следующие проверки. Не делай вывод о причине падения только по изменению трафика. Если данные недоступны или неполны, сообщи об этом.

Вопросы о LLM и SEO-автоматизации

Помощник предлагает обновить страницу, которая приносит заявки. Как решить, нужна ли правка?

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

Несколько страниц отвечают на одни и те же запросы. Можно поручить модели выбрать одну, а остальные удалить?

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

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

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

После подготовки брифа изменились цены и условия продукта. Нужно повторять весь процесс?

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

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