10.2Промптинг для SEO: проверяемый формат, контрольный набор и скрипт там, где есть правило

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

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

Общие руководства по промптингу есть у разработчиков моделей; для SEO-задач в них не хватает двух вещей — работы с данными и проверки. Где модель вообще стоит применять и сколько это экономит — глава о LLM в рабочих процессах. Готовые промпты — в библиотеке промптов (П3).

Анатомия рабочего промпта для SEO-задачи: роль, контекст, данные, формат, ограничения

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

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

Контекст — то, без чего модель отвечает про чужой бизнес. У электриков это три факта: компания работает только с юрлицами в пределах МКАД и не берёт квартиры; аварийный выезд — отдельная услуга с отдельной ценой; вопрос о допуске для работ в бизнес-центре в проекте относится к «выбрать у кого», потому что его задают перед заказом. Без третьего факта модель уверенно отнесёт такой запрос к «разобраться». Это продолжение критерия из главы о текстовых факторах: если промпт можно написать, не задав ни одного вопроса владельцу, ответ будет про среднюю компанию, а не про вашу.

Источники контекста в SEO-задаче — не догадки специалиста, а три документа: прайс и список услуг от владельца, выдача по спорным запросам, записи звонков и заявок. Модель не видит текущую выдачу, если её не дать, и не знает, что в Яндексе и Google по одному запросу может стоять разный тип страниц, — где это меняет решение, систему указывают явно, а разметку делают для каждой.

Ограничения в SEO-задачах свои. Запросы не нормализуются: «электрик в офис» и «электрик в офисе», опечатка, порядок слов — для поиска это разные запросы, и модель, которая их «почистит», испортит сопоставление с выгрузкой. Топонимы не обобщаются: «Москва-Сити» не превращается в «Москву». Модели прямо запрещают объединять то, что бизнес разводит: офис и квартиру, аварийный выезд и плановый монтаж. И ей разрешают «не определить»: без этого значения она разложит по категориям все четыреста запросов, включая те, где ответа нет без взгляда на выдачу. Помеченные сомнительные строки — короткая ручная проверка; спрятанные среди уверенных — ошибка в структуре сайта. Интент определяет выдача, а не мнение модели; где модель здесь систематически ошибается — глава о семантике и контенте с LLM и урок «Интент запроса и тип страницы».

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

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

Раздел о текущем состоянии моделей, проверено на 25.10.2026; пересматривается раз в квартал.

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

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

• Строка на каждый объект входа, с его номером. Число строк на выходе равно числу на входе — одна формула покажет, нет ли потерянных и добавленных.
• Закрытый список значений. Интент, тип страницы, статус — только из перечня, включая «не определить». Значение вне перечня ловится фильтром, а не чтением.
• Числа только переносятся из входа. Показы, клики, позиции, проценты модель не считает — это делает таблица или скрипт. Почему модель ошибается на числах уверенно — в главе о LLM в аналитике и диагностике.
• Основание — одной фразой, в отдельной колонке. По нему проверяют выборку: если основание не сходится с ответом, строка идёт на ручной разбор.
• Пометка сомнения. Сомнительные строки проверяются первыми; если их больше четверти, дело не в данных, а в задаче.

Кластеры — не «список групп с запросами внутри», а «запрос → группа → посадочная страница»: так видно, что куда попало и что осталось без страницы. Модель группирует по смыслу, а выдача иногда разводит близкие запросы на разные страницы; группировка по совпадению выдачи — урок «Кластеризация». Отдельная колонка «существующая страница» сразу показывает, где группа ложится на страницу, которая уже есть, а где нужна новая, — это и есть решение, ради которого кластеризуют.

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

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

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

Сколько данных давать и как их структурировать

Раздел о текущем состоянии моделей, проверено на 25.10.2026; пересматривается раз в квартал.

В модель вставляют выгрузку на тридцать тысяч строк, и она уверенно рассуждает о нескольких сотнях — из начала и конца. Контекстное окно — сколько текста модель удерживает за один раз: инструкцию, документы, переписку и свой ответ вместе. Чего нет в окне, модель не видит, а в очень длинном окне хуже замечает детали из середины. Это измерено: качество ответа заметно падает, когда нужное стоит в середине длинного контекста, даже у моделей для длинного ввода (Liu и др., TACL, 2024).

Отсюда правило: модели дают столько данных, сколько нужно для решения, и ни строкой больше. Отфильтровать и посчитать — до модели, скриптом или таблицей: убрать брендовые запросы, отсечь хвост ниже порога показов, свести дни к неделям. Модель получает то, что требует суждения, а не арифметики. Большие списки для разметки делят на порции по сто–двести строк (оценка практики); каждая порция самодостаточна, результаты собираются по номерам строк.

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

Как понять, что промпт плохой, а не модель

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

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

Контрольный набор. Пятьдесят–сто объектов, размеченных вручную, с обязательной долей трудных случаев. Каждая версия промпта и каждая новая модель прогоняются на нём, сравнивается доля совпадений с ручной разметкой. Без набора «стало лучше» означает «первые десять строк выглядят лучше». Насколько это ненадёжно: смена разделителей и пробелов в промпте при той же задаче давала у одной из открытых моделей разницу до 76 пунктов точности (Sclar и др., ICLR, 2024). Плюс пять пунктов на двадцати строках — шум; логика та же, что у контрольной группы страниц в главе о тестировании.

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

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

Когда промпт не нужен: задачи, где проще написать скрипт; как промпты стареют

Раздел о текущем состоянии моделей, проверено на 25.10.2026; пересматривается раз в квартал.

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

Неделю мы чинили промпт. Модель путала «от 1 500 ₽» с ценой за точку, сравнивала цену за метр с ценой выезда, часть страниц терялась между порциями, в отчёте появлялись расхождения, которых на странице не было. Двенадцать версий подняли согласие с ручной проверкой с 41 до 49 страниц из 60 (68 → 82 %), дальше оно не двигалось. Тем временем список на 120 страниц ушёл контент-менеджеру, и тот успел поправить тридцать — часть верных цен на неверные.

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

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

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

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

Мифы

• «Есть волшебный промпт». Промпт работает на тех данных и той модели, на которых его проверили. Без контрольного набора чужой промпт — рецепт с форума: может сработать, проверить нечем.
• «Чем длиннее промпт, тем лучше». По моему опыту, длина добавляет противоречия: в длинном списке ограничений модель выполняет одни и пропускает другие. Каждая строка должна менять результат на контрольном наборе; те, что не меняют, удаляются.
• «Роль „ты опытный SEO-специалист“ решает». Исследование 162 ролей на 2 410 вопросах в четырёх семействах моделей показало, что роль в инструкции не улучшает ответы на фактические вопросы (Zheng и др., EMNLP Findings, 2024). Разработчики моделей роль рекомендуют — для тона и фокуса, а не для точности. Знание о бизнесе и данные роль не заменяет.
• «Модель ошиблась — надо переформулировать». Без контрольного набора переформулировка — лотерея. Чаще причина в данных, в формате или в том, что задача решается правилом.
• «Промпт, который работает, работает всегда». Модель обновится, выгрузка сменит поля — и промпт сломается молча.

Что запомнить

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

Базового урока у этой главы нет. Где модель применять — глава о LLM в рабочих процессах; как эти правила работают на ядре и на данных панелей — главы о семантике и контенте с LLM и о LLM в аналитике и диагностике.