PRD для programmatic SEO портала в 2026 который строит агент

PRD для programmatic SEO портала это один документ, где прописаны модель данных, шаблоны страниц, логика генерации URL, sitemap и правила индексации. Написали его грамотно. Отдали агенту вроде Claude Code или Cursor. Получили работающий сайт на тысячи страниц без ручной верстки каждой. Ниже разберем по шагам, что положить в такой PRD, как описать данные, чтобы модель не путалась, и почему без блока про индексацию половина страниц никогда не попадет в Google.

Коротко. PRD для programmatic SEO это ТЗ, которое понимает не только команда, но и AI-агент. В нем шесть обязательных блоков: модель данных, шаблон страницы, схема URL, sitemap, правила индексации и раздел «не трогать». Один точный документ заменяет недели брифов. Портал VibeCoderz на 6 200 материалов собрали за неделю тремя скриптами голосом в Claude Code. Дальше: готовый шаблон промпта, таблицы и разбор типичных ошибок.

Зачем programmatic SEO порталу отдельный PRD?

PRD задает агенту жесткие рамки: какие данные, какие шаблоны, какие URL. Без него модель фантазирует структуру на ходу, и на 500-й странице ломается вся логика.

Агент в 2026 году пишет, тестирует и чинит код почти сам. Но он не умеет читать мысли. Дайте расплывчатый промпт «сделай SEO-сайт про кофейни» и получите красивый лендинг на пять страниц. Дайте PRD с моделью данных и шаблоном, и тот же агент развернет каталог на 30 000 URL по одному описанию. Разница в одном документе.

По данным Scriptonia за апрель 2026, 68% доработок от инженеров упираются в размытые или пропущенные критерии приемки. Для programmatic SEO это правило работает вдвойне: страниц много, ошибка в шаблоне копируется тысячи раз. PRD ловит эти дыры до сборки, а не после.

Есть и вторая причина. PRD в формате Markdown это живой источник правды. Поменяли поле в модели данных внутри документа. Агент подхватил и пересобрал. Такой цикл называют PRD-driven development, и он уже не теория.

Из каких блоков собирается рабочий PRD для SEO-портала?

Минимум шесть блоков: цель и не-цели, модель данных, шаблон страницы, схема URL, sitemap с индексацией, раздел «не трогать». Остальное по вкусу, но эти шесть без вариантов.

Классический PRD в 2026 разросся до 13 разделов под AI-агентов: проблема, цели, не-цели, пользовательские истории, функциональные требования, критерии приемки, зависимости, риски. Для programmatic SEO портала часть из них лишняя, а часть критична именно из-за масштаба. Держите практичный набор, а не академический шаблон.

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

Блок не-целей важнее, чем кажется. Агенты в начале 2026 плохо чувствуют границы: где «код можно улучшить», а где «код трогать нельзя». Явный раздел «не трогать» с перечнем схемы БД, сигнатур API и флоу авторизации спасает от тихих поломок.

Как описать модель данных, чтобы агент не путался?

Модель данных это список сущностей и их полей с типами. Опишите каждое поле явно: имя, тип, обязательность, пример значения. Агент строит из этого и БД, и шаблон, и sitemap.

Модель данных сердце всего документа. Из нее агент выводит схему базы, поля для рендера и параметры для генерации URL. Опишете небрежно, получите кашу на всех уровнях сразу.

Разберем на примере каталога AI-инструментов, как у нас на каталоге AI-инструментов. Одна сущность Tool, и от нее растут сотни карточек. Каждое поле прописано с типом и назначением.

Ключевой момент: пропишите, какое поле идет в какой SEO-элемент. name в H1, description в первые 100 слов и meta, updatedAt в дату обновления и в sitemap. Тогда агент не гадает, а собирает страницу под поисковый запрос механически. Это и есть логика programmatic SEO: данные вставляются в шаблон, шаблон превращается в тысячи страниц.

Для контентных сущностей вроде статей добавьте поля под нейровыдачу: TL;DR, FAQ-массив, дату обновления. Их потом легко разложить в JSON-LD схемы.

Как задать шаблоны страниц и логику генерации URL?

Шаблон это один файл страницы с плейсхолдерами под поля модели. URL строится через динамический маршрут в Next.js. Меняете шаблон один раз, обновляются все 30 000 страниц.

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

В Next.js App Router это связка generateStaticParams и файла страницы. Первая функция отдает список всех slug-ов, вторая рендерит страницу под каждый. Пример для каталога инструментов:

// app/item/[slug]/page.tsx
export async function generateStaticParams() {
  const tools = await getAllTools()
  return tools.map((tool) => ({ slug: tool.slug }))
}

export async function generateMetadata({ params }) {
  const { slug } = await params
  const tool = await getTool(slug)
  return {
    title: `${tool.name} обзор, цены и альтернативы 2026`,
    description: tool.description,
    alternates: { canonical: `https://vibecoderz.ru/item/${slug}` },
  }
}

По официальной документации Next.js, generateStaticParams пре-рендерит все маршруты на этапе сборки. Страницы отдаются как статический HTML и грузятся моментально. Для краулера это идеал: Googlebot предпочитает быстрый HTML, а рендерить JavaScript ему дорого и медленно.

Почему динамические маршруты, а не параметры запроса

URL вида /item/cursor индексируется, а /search?q=cursor нет. Google-краулер игнорирует параметрические адреса и любит выделенные структурные страницы.

Схема URL это отдельная строка в PRD, и она решает судьбу трафика. Адрес /miami/sushi попадет в индекс. Адрес /search?q=sushi&location=miami почти наверняка нет. Пропишите в PRD явно: каждая комбинация данных получает уникальный человекочитаемый URL из полей модели. Один slug, один смысл, один поисковый запрос.

Есть нюанс. Не плодите страницы ради страниц. Google индексирует не все подряд из sitemap, а то, что несет пользу. Мусорные комбинации данных лучше отсечь на уровне generateStaticParams.

Как прописать sitemap и индексацию прямо в PRD?

Sitemap генерируется динамически из той же модели данных. В Next.js это файл app/sitemap.ts. Без sitemap и без стратегии индексации новые страницы Google находит месяцами.

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

Next.js App Router поддерживает это из коробки через app/sitemap.ts:

import { MetadataRoute } from 'next'

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const tools = await getAllTools()
  return tools.map((tool) => ({
    url: `https://vibecoderz.ru/item/${tool.slug}`,
    lastModified: tool.updatedAt,
    changeFrequency: 'weekly',
    priority: 0.8,
  }))
}

Дальше пропишите стратегию обновления. Для большого каталога подходит Incremental Static Regeneration: страницы собираются на сборке, а потом фоново обновляются через заданный интервал revalidate. По чеклисту SEOGraphy за апрель 2026, ISR это рекомендованная стратегия рендеринга для больших programmatic-наборов страниц.

И последнее, что часто забывают в PRD. Индексация не заканчивается на sitemap. Отправьте карту в Google Search Console, используйте Request Indexing для приоритетных страниц, помня про дневные лимиты, и следите за покрытием через оператор site:. Год в title вроде «2026» тоже сигнал свежести, краулер это любит.

Как выглядит готовый PRD-промпт для агента?

Готовый PRD это Markdown-файл, который вы отдаете агенту одним куском. Ниже скелет промпта: роль, стек, модель данных, шаблон, URL, sitemap, не-цели. Копируйте и адаптируйте под свой портал.

Собираем все блоки в один промпт. Сохраните в файл prd.md и передайте агенту с командой «прочитай PRD и построй проект по нему». Формат Markdown выбран не случайно: он универсален и понятен любой модели.

# PRD: SEO-портал каталога [ниша]

## Роль
Ты продакт-менеджер и технический архитектор.
Собери production-ready проект по этому документу.

## Стек
Next.js 15 App Router, TypeScript, Tailwind, [CMS].
Рендеринг: SSG + ISR. Деплой: [платформа].

## Модель данных
Сущность Tool:
- slug: string, обязательно, латиница+дефисы -> кусок URL
- name: string, обязательно -> H1 и title
- description: text, обязательно -> первые 100 слов + meta
- category: reference -> фильтры
- updatedAt: datetime -> lastModified в sitemap

## Шаблон страницы /item/[slug]
H1 = name. Первый абзац = description.
generateMetadata: title, description, canonical.
Блоки: обзор, плюсы, минусы, альтернативы, FAQ.

## Схема URL
/item/[slug] для карточек.
Только ЧПУ. Никаких ?q= параметров в индексе.

## Sitemap и индексация
app/sitemap.ts из всех Tool.
JSON-LD: BlogPosting, FAQPage.
canonical на каждой странице.

## НЕ ТРОГАТЬ
- Схему БД без явного запроса
- Сигнатуры API
- Флоу авторизации

Лайфхак от нас: попросите агента сначала сгенерировать Mermaid-диаграмму потоков данных по этому PRD. Увидите архитектуру глазами до того, как напишется первая строка кода. Если предлагает не тот стек, укажите свой явно и попросите альтернативы.

Максим: «VibeCoderz собрали за неделю тремя скриптами голосом в Claude Code. 6 200 материалов. Первый месяц: 4 303 посетителя, 6 700 просмотров, Google дал 36 000 показов. Ребят, это работает. Один точный документ вместо месяца созвонов с разработчиком.»

Для сборки такого портала мы берем Claude Code на архитектуру и Cursor на правки по мелочи. Кому нужен минимальный порог входа, подойдут Lovable или Bolt.

Какие ошибки в PRD ломают весь портал?

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

Разберем честно, без прикрас. PRD легко написать так, что агент соберет красивый, но мертвый для SEO сайт.

Первая ошибка. Модель данных без типов и назначения полей. Агент сам решит, что куда положить, и решит неверно. Итог: name уедет в description, canonical потеряется, дубли расплодятся.

Вторая. Нет раздела не-целей и «не трогать». Агент из лучших побуждений перепишет схему БД при добавлении фичи. На большом проекте это часы отката. Практики 2026 года прямо рекомендуют защищать стабильные части явным списком.

Третья, самая дорогая для трафика. PRD молчит про sitemap и индексацию. Страницы собрались, но Google про них не знает. Мы такое видели: 6 200 материалов на портале, а в первый месяц без нормальной карты сайта бот заходил на служебные роуты вместо статей.

Какую модель брать под саму сборку, тоже стоит зафиксировать. Ориентир по состоянию на июль 2026.

Итог с чего начать свой PRD

Начните с модели данных, а не с дизайна. Опишите одну сущность и ее поля с типами. Прицепите к каждому полю SEO-назначение. Добавьте шаблон, схему URL, sitemap и раздел «не трогать». Это и есть костяк, по которому агент развернет портал на тысячи страниц.

Не пытайтесь описать все идеально с первого раза. PRD это живой документ. Собрали MVP на десяти страницах, проверили индексацию, дописали блок. На третьей итерации структура встанет на место.

Если хотите разобрать свой проект под programmatic SEO предметно, запишитесь на консультацию к Максиму. А готовые стеки под каждую задачу лежат в каталоге AI-инструментов.

FAQ

Что такое PRD простыми словами? PRD (Product Requirements Document) это документ, где описано, что вы строите, для кого и как оно должно работать. В 2026 году его читают не только люди из команды, но и AI-агенты вроде Cursor и Claude Code. Чем точнее PRD, тем меньше правок потом.

Можно ли отдать один PRD агенту и получить готовый портал? Да, если PRD содержит модель данных, шаблон страницы, схему URL и правила индексации. Агент разворачивает шаблон на все данные через динамические маршруты. Но первый прогон обычно дает MVP, а не финал. Дальше идут итерации.

В каком формате писать PRD для агента? В Markdown. Он универсален, читается любой моделью и легко правится. Сохраните файл как prd.md и передайте агенту командой «построй проект по этому документу». Text-файлы тоже работают, но Markdown удобнее для структуры.

Почему динамические URL лучше параметров запроса для SEO? Google индексирует структурные адреса вроде /item/cursor и почти игнорирует параметрические /search?q=cursor. Краулер видит в ЧПУ отдельную страницу под конкретный запрос, а в параметрах просто фильтр. Для programmatic SEO это разница между трафиком и его отсутствием.

Сколько страниц реально попадет в индекс? Не все из sitemap. Google индексирует страницы, которые несут пользу, а не пустые комбинации данных. Отсекайте мусорные варианты на этапе генерации, добавляйте уникальный контент на каждую страницу и отправляйте карту сайта в Search Console.

Нужен ли программист, чтобы собрать такой портал? Нет, если владеете вайбкодингом и умеете писать PRD. Портал VibeCoderz на 6 200 материалов собран без классической разработки, тремя скриптами голосом в Claude Code. Языки программирования учить не обязательно, важнее понимать архитектуру: фронт, бэк, база данных.

Глоссарий

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

PRD — Product Requirements Document, документ с требованиями к продукту: что строим, для кого, как работает. В AI-эпоху служит промптом для агента.

Модель данных — описание сущностей и их полей с типами, из которого строятся база, страницы и sitemap.

Динамический маршрут — шаблон URL с плейсхолдером вроде /item/[slug], который Next.js разворачивает в отдельную страницу под каждое значение.

generateStaticParams — функция Next.js, которая отдает список всех slug-ов для пре-рендера страниц на этапе сборки.

ISR — Incremental Static Regeneration, стратегия, при которой статические страницы фоново обновляются через заданный интервал без полной пересборки.

Sitemap — карта сайта в XML, список всех URL для поисковика. В Next.js генерируется через app/sitemap.ts.

ЧПУ — человекопонятный URL, читаемый адрес из слов вместо параметров запроса.

Обновлено: июль 2026. Данные по моделям и ценам актуальны на момент публикации.