# SEO и приемка публичного сайта
Версия источника: d33454c0dad753475ecc92aaecf8d783f02fd01b
Синхронизировано: 2026-11-13T05:38:20.984Z
Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/d33454c0dad753475ecc92aaecf8d783f02fd01b
## Оглавление
- [Заголовок страницы title](#seo-page-titles)
- [Структура заголовков H1–H6](#seo-heading-structure)
- [Описание страницы meta description](#seo-meta-description)
- [Favicon и идентификация сайта](#seo-favicon)
- [Индексирование и исключение страниц](#seo-indexability)
- [Канонические URL](#seo-canonical-urls)
- [HTTP-статусы и перенаправления страниц](#seo-status-redirects)
- [Sitemap и даты изменения](#seo-sitemaps)
- [Навигационные ссылки и достижимость страниц](#seo-crawlable-links)
- [Доступность содержания при рендеринге](#seo-rendered-content)
- [Изображения в публичном содержании](#seo-images)
- [Структурированные данные](#seo-structured-data)
- [Пагинация и индексирование фильтров](#seo-pagination-facets)
- [Языковые версии и hreflang](#seo-multilingual)
- [Производительность публичного сайта](#seo-performance)
- [Мобильное содержание и метаданные](#seo-mobile-content)
- [Приемка публичного сайта перед релизом](#seo-release-audit)
# Заголовок страницы title
## Коротко
У публичной HTML-страницы есть содержательный title, соответствующий ее назначению и языку.
## Плохо
```html
Главная — Главная — Купить дешево купить
```
## Хорошо
```html
Аккумуляторная дрель D18 — Каталог Пример
```
## Почему
Title помогает идентифицировать страницу. Поисковая система может сформировать другой заголовок результата; тег не гарантирует точный вид выдачи.
## Когда применять
Для публичных индексируемых HTML-страниц. Внутренние приложения также должны иметь понятные названия страниц, но SEO-индексация им не обязательна.
### Требования
- Профиль требует один title в head; шаблон заполняется из актуального содержимого без заглушек и неэкранированного пользовательского HTML.
- Разные по смыслу страницы имеют различимые названия. Для серии пагинации одинаковые title допустимы; добавление номера является решением проекта.
- Используйте краткое описание предмета страницы и при необходимости название сайта. Лимит 60 символов не является универсальным требованием Google; проверяйте читаемость и отображение.
## Как проверить
- Проверьте исходный и итоговый HTML главной, категории, карточки, статьи, пагинации и 404.
- Найдите пустые title, дубли разных сущностей, неверный язык и устаревшие значения после клиентской навигации.
## Человек
Утверждает понятные названия и редакционный шаблон для типов страниц.
## Агент
Проверяет один title в head, фактические значения, язык, экранирование и клиентскую навигацию.
## Источники
- [Google Search Central: Title links](https://developers.google.com/search/docs/appearance/title-link)
- [Google Search Central: Pagination](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/page-titles.md)
---
# Структура заголовков H1–H6
## Коротко
Для обычной содержательной страницы профиль устанавливает один основной H1 и последовательную структуру подзаголовков.
## Плохо
```html
Логотип
Меню
Доставка
```
## Хорошо
```html
Доставка
Сроки доставки
Условия по регионам.
Стоимость доставки
Тарифы и исключения.
```
## Почему
Один H1 является проверяемым соглашением шаблона, а не утверждением о запрете нескольких H1 в Google. Уровни описывают структуру содержания; размер шрифта задается стилем.
## Когда применять
Для стандартных страниц сайта. Для сложных составных документов допустимо документированное исключение с проверкой семантики и доступности.
### Требования
- Основной H1 называет содержание, а не повторяет логотип или элементы меню. Он может отличаться от title при сохранении темы.
- Подразделы используют смысловую иерархию; не выбирайте h3 только ради размера шрифта. Оформление и семантика разделены.
- Содержание и основные заголовки доступны в мобильной версии и скринридеру; скрытые декоративные дубли не создают ложную структуру.
## Как проверить
- Проверьте число основных H1 и дерево заголовков на каждом типе страницы.
- Пройдите навигацию по заголовкам скринридером; проверьте длинные заголовки и мобильный шаблон.
## Человек
Определяет тему страницы и смысловую иерархию разделов; согласует исключения из профиля одного основного H1.
## Агент
Проверяет дерево заголовков, доступное содержание и мобильные дубли; отделяет семантику от CSS-размера.
## Источники
- [W3C: Headings](https://www.w3.org/WAI/tutorials/page-structure/headings/)
- [Google Search Central: Title links](https://developers.google.com/search/docs/appearance/title-link)
Уровень: Рекомендуется. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/heading-structure.md)
---
# Описание страницы meta description
## Коротко
Описание кратко и достоверно передает содержание индексируемой страницы.
## Плохо
```html
```
## Хорошо
```html
```
## Почему
Google может использовать описание для сниппета, но выбирает текст и из содержимого страницы. Отдельного универсального лимита 160 символов нет.
## Когда применять
Для страниц, которым полезно управляемое описание. При большом каталоге допустимы проверяемые шаблоны из фактических свойств.
### Требования
- Описание соответствует видимому содержанию и языку; не содержит фиктивных скидок, недоступных услуг или набора ключевых слов.
- Различайте существенные страницы; массовые одинаковые описания и пустые шаблонные переменные являются дефектом профиля.
- Экранируйте значение атрибута; не превращайте ручное описание в возможность HTML-инъекции. Контроль длины является редакционным бюджетом, а не гарантией вида сниппета.
## Как проверить
- Проверьте description в итоговом HTML и после смены маршрута.
- Сверьте выборку описаний с фактическими ценами, условиями и содержанием страницы.
## Человек
Проверяет достоверность описания и соответствие предложению на странице.
## Агент
Проверяет наличие, язык, экранирование, дубли и обновление description после навигации.
## Источники
- [Google Search Central: Snippets](https://developers.google.com/search/docs/appearance/snippet)
Уровень: Рекомендуется. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/meta-description.md)
---
# Favicon и идентификация сайта
## Коротко
Сайт предоставляет доступный favicon; главная страница объявляет его через link rel="icon".
## Плохо
```html
```
## Хорошо
```html
```
## Почему
Favicon помогает идентифицировать сайт в браузере и может использоваться в поиске. Его показ Google не гарантируется.
## Когда применять
Для публичного сайта. Иконки приложения, Apple touch icon и manifest проверяются отдельно при наличии соответствующих платформ.
### Требования
- Профиль выбирает квадратный PNG/ICO не меньше 48×48 как базовый вариант. Это проектный минимум; проверенная документация Google допускает минимум 8×8 и рекомендует от 48×48.
- URL стабилен, возвращает изображение правильного типа и доступен для нужных роботов. Не блокируйте главную и favicon, если ожидается показ в поиске.
- Используйте узнаваемую иконку, читаемую в малом размере; не объявляйте отсутствующие размеры или формат.
## Как проверить
- Запросите URL без пользовательской сессии, проверьте HTTP-статус, MIME, декодирование и квадратные размеры.
- Проверьте вкладку браузера и доступность link на главной; наличие тега не считается доказательством появления в поиске.
## Человек
Утверждает узнаваемую иконку и нужные платформенные варианты.
## Агент
Проверяет rel=icon, MIME, реальные размеры, публичную загрузку и отображение во вкладке; не обещает показ в поиске.
## Источники
- [Google Search Central: Favicon](https://developers.google.com/search/docs/appearance/favicon-in-search?hl=ru)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/favicon.md)
---
# Индексирование и исключение страниц
## Коротко
Для каждого типа URL определите ожидаемое индексирование и согласуйте HTTP-статус, robots и доступ.
## Плохо
```text
Страница закрыта robots.txt и содержит noindex; команда считает ее удаленной из поиска. Приватный документ защищен только noindex.
```
## Хорошо
```text
Публичная карточка: 200, доступна роботу, noindex отсутствует.
Служебная публичная страница: доступна роботу для чтения noindex.
Приватный документ: аутентификация и авторизация независимо от robots.
```
## Почему
Запрет обхода и запрет индексирования имеют разную семантику. Робот должен получить страницу, чтобы прочитать noindex.
## Когда применять
Для публичного сайта, staging, служебных страниц и пользовательских данных. Правило не требует открывать приватные ресурсы ради удаления из поиска.
### Требования
- Составьте матрицу типов URL: indexable, noindex, private, redirect, deleted. Для каждого задайте ожидаемые ответы.
- Noindex передается meta либо X-Robots-Tag для поддерживающего его робота. Не используйте запись noindex в robots.txt как рабочий механизм Google.
- Robots.txt управляет обходом и не является контролем доступа. Staging защищается доступом; перед production отдельно проверяйте отсутствие случайного noindex/Disallow.
## Как проверить
- Проверьте матрицу по реальным HTTP-ответам и итоговому HTML, включая robots.txt и заголовки CDN.
- Для публичной страницы с noindex подтвердите доступ робота; для приватной проверьте невозможность чтения без прав.
## Человек
Утверждает, какие страницы публичны, индексируемы, служебны или приватны.
## Агент
Проверяет матрицу URL, robots, noindex и авторизацию; не открывает приватные данные ради обхода поисковиком.
## Источники
- [Google Search Central: noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/indexability.md)
---
# Канонические URL
## Коротко
Дубли согласованно указывают предпочтительный URL, а уникальные страницы не канонизируются на несоответствующее содержание.
## Плохо
```html
```
## Хорошо
```html
```
## Почему
Canonical является сигналом выбора представителя дублирующегося содержания. Он не заменяет redirect, авторизацию или удаление страницы.
## Когда применять
Для URL с дублями из параметров, нескольких доменов или вариантов маршрута. Self-canonical принят как соглашение профиля для основной страницы.
### Требования
- Укажите один согласованный абсолютный canonical в head или применимый HTTP Link. Он ведет на доступную релевантную индексируемую страницу без цепи redirects.
- Согласуйте canonical, sitemap, внутренние ссылки, HTTPS/домен и локаль. Не отправляйте все варианты пагинации на первую страницу, если содержание различается.
- Не задавайте conflicting canonical в исходном HTML и после рендеринга. Noindex не используется как способ выбора canonical среди дублей.
## Как проверить
- Проверьте чистый URL, tracking-параметры, другой домен/протокол, локаль и вторую страницу каталога.
- Убедитесь в отсутствии циклов, нескольких конфликтующих canonical и целей с 404/noindex.
## Человек
Выбирает канонические страницы и политику дублей, включая параметры, языки и пагинацию.
## Агент
Проверяет canonical в HTML и HTTP, конечный статус цели, отсутствие циклов и согласованность sitemap/ссылок.
## Источники
- [Google Search Central: Canonical URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=ru)
- [Google Search Central: Pagination](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/canonical-urls.md)
---
# HTTP-статусы и перенаправления страниц
## Коротко
Статус соответствует состоянию ресурса, а перенаправление ведет к релевантной конечной странице.
## Плохо
```text
Любой неизвестный URL возвращает 200 с текстом «Не найдено». Все удаленные товары перенаправляются на главную.
```
## Хорошо
```text
Существующая страница: 200.
Отсутствующая: 404; окончательно удаленная по политике: 410.
Постоянно перенесенная: 301/308 на релевантный URL.
Временная недоступность: 503, при известном сроке Retry-After.
```
## Почему
Успешный HTTP-ответ с сообщением об отсутствии может восприниматься как soft 404. Ошибка сервера и удаление имеют разные последствия.
## Когда применять
Для HTML, ресурсов и маршрутизации публичного сайта. Выбор 301/308 либо 302/307 учитывает постоянство переноса и семантику метода.
### Требования
- Верните фактический статус на сервере/CDN, включая прямой запрос вложенного маршрута. Страница ошибки может содержать навигацию, сохраняя статус.
- Уберите redirect-циклы и лишние цепи; старый URL ведет сразу к окончательному релевантному адресу.
- Не маскируйте временный сбой под 404 или успешную пустую страницу. Не используйте 401/403 как средство ограничения частоты обхода.
## Как проверить
- Запросите известный, случайный, удаленный и перенесенный URL, включая trailing slash и HTTPS.
- Проверьте всю цепь Location и ответ при временном отказе backend.
## Человек
Согласует удаление, перенос и релевантные страницы назначения.
## Агент
Проверяет HTTP-статусы, Location, цепи и циклы, случайные URL и временный отказ backend.
## Источники
- [Google: HTTP status codes](https://developers.google.com/crawling/docs/troubleshooting/http-status-codes)
- [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/status-redirects.md)
---
# Sitemap и даты изменения
## Коротко
Sitemap перечисляет выбранные канонические URL и отражает фактическое существенное изменение содержания.
## Плохо
```xml
В sitemap включены 404, приватные URL и noindex; lastmod заменяется текущей датой при каждой сборке.
```
## Хорошо
```xml
https://example.com/delivery/2026-11-10
```
## Почему
Sitemap помогает обнаружению URL, но не гарантирует индексирование. Неверные даты ухудшают достоверность метаданных.
## Когда применять
Для публичного сайта, особенно большого, нового или со сложной структурой. Для небольшого связного сайта отсутствие sitemap не означает невозможность индексирования.
### Требования
- Включайте абсолютные канонические URL, предназначенные для индексирования. Исключите закрытые, удаленные, redirect и noindex страницы из базового профиля.
- При превышении 50 000 URL или 50 MB в несжатом виде разделяйте sitemap и используйте индекс. XML должен корректно экранировать значения и использовать UTF-8.
- Lastmod, если он указан, отражает значимое изменение страницы; при отсутствии достоверной даты опустите его. Google не использует priority и changefreq как обещание обхода.
## Как проверить
- Распарсите XML, проверьте лимиты, дубли, доступность и статусы выборки URL.
- Сравните lastmod с историей реальных изменений, включая сборку без изменений содержания.
## Человек
Определяет индексируемый набор страниц и смысл значимого изменения материала.
## Агент
Проверяет XML, лимиты, URL, статусы и достоверность lastmod; исключает подмену даты временем сборки.
## Источники
- [Google Search Central: Sitemaps](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap)
Уровень: Рекомендуется. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/sitemaps.md)
---
# Навигационные ссылки и достижимость страниц
## Коротко
Значимые публичные страницы доступны через обычные ссылки с href и понятным названием.
## Плохо
```html
Каталог
```
## Хорошо
```html
Каталог инструментов
```
## Почему
Ссылка обеспечивает адресуемость, стандартную навигацию и обнаружение URL роботом. Наличие страницы только в sitemap не решает пользовательскую навигацию.
## Когда применять
Для меню, категорий, хлебных крошек, связанных материалов и пагинации. Кнопка используется для действия, не являющегося переходом к ресурсу.
### Требования
- Используйте a с разрешимым href. Клиентский роутер сохраняет рабочий URL при прямом открытии и стандартные действия ссылки.
- Текст или доступное имя описывает цель. Пустая иконка-ссылка имеет доступное имя; generic «сюда» не является основным шаблоном навигации.
- Значимые страницы достижимы из навигации или контекстных ссылок. Родительский каталог остается ссылкой при наличии подменю.
## Как проверить
- Обойдите сайт от главной и сравните достижимые URL с индексируемым набором.
- Проверьте Enter, новую вкладку, прямой запрос и отсутствие href="#" для содержательных страниц.
## Человек
Определяет важные разделы и понятные названия переходов.
## Агент
Строит доступные ссылки с href, проверяет обход от главной, прямые URL, Enter и новую вкладку.
## Источники
- [Google Search Central: Crawlable links](https://developers.google.com/search/docs/crawling-indexing/links-crawlable)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/crawlable-links.md)
---
# Доступность содержания при рендеринге
## Коротко
Публичный URL отдает доступное основное содержание и согласованные метаданные после выбранного способа рендеринга.
## Плохо
```text
Карточка доступна только после клика и авторизованного API; прямой URL возвращает пустую оболочку или 404.
```
## Хорошо
```text
Прямой URL карточки возвращает корректный статус.
Основной текст, title, canonical и ссылки доступны в проверенном HTML.
SSR/SSG либо подтвержденный CSR-путь не требуют пользовательского действия для загрузки основного содержания.
```
## Почему
Google выполняет JavaScript, но обход, рендеринг и индексирование являются отдельными этапами. Другие потребители могут не выполнять JS.
## Когда применять
Для сайтов с SSR, SSG, CSR и гибридным рендерингом. Документационный репозиторий не требует JavaScript-runtime; это правило относится к сайту-потребителю.
### Требования
- Проверьте прямую загрузку и клиентский переход, status, canonical, title, ссылки и видимый текст. Не допускайте расхождения существенного содержания.
- Не блокируйте необходимые публичные CSS/JS/API для выбранного робота. Основное содержание не должно требовать scroll/click/type для загрузки.
- Выбирайте SSR/SSG при необходимости предсказуемого получения HTML разными роботами. Если выбран CSR, приемка включает фактический рендеринг и обработку ошибок загрузки.
## Как проверить
- Сравните исходный ответ, DOM после рендеринга и проверку URL целевой поисковой системы.
- Отключите один ресурс, откройте вложенный маршрут напрямую и проверьте отсутствие ложного успешного пустого ответа.
## Человек
Выбирает целевые поисковые системы и обязательное публичное содержание.
## Агент
Сравнивает прямую загрузку и клиентский переход, HTML/DOM, статусы и доступность ресурсов для выбранного робота.
## Источники
- [Google Search Central: JavaScript SEO](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [Google Search Central: Mobile-first indexing](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/rendered-content.md)
---
# Изображения в публичном содержании
## Коротко
Содержательные изображения имеют доступный URL, подходящий ресурс и описание по контексту.
## Плохо
```html
```
## Хорошо
```html
```
## Почему
Изображение как CSS-фон не заменяет содержательный img для поиска изображений. Alt объясняет смысл, а не служит списком ключевых слов.
## Когда применять
Для изображений товаров, статей и других значимых материалов. Декоративные изображения могут оставаться фоном или иметь пустой alt.
### Требования
- Для содержательных изображений используйте img с src; picture/srcset имеют подходящий fallback. Ресурс доступен без сессии, если предназначен для индексирования.
- Alt и подпись соответствуют роли и языку страницы; не дублируйте длинный соседний текст без необходимости.
- Задайте размеры/соотношение для устойчивой компоновки, подходящие варианты разрешения и бюджет байтов. Основное изображение не откладывается до пользовательского действия.
## Как проверить
- Проверьте URL, MIME, загрузку на мобильном устройстве, alt и отсутствие лишнего скачивания оригиналов.
- Сравните визуальный контекст и описание; проверьте поведение при недоступном изображении.
## Человек
Проверяет смысл alt и подписи, права на изображение и качество выбранных вариантов.
## Агент
Проверяет src/srcset, размеры, загрузку, MIME и alt по контексту; измеряет объем ресурсов и сдвиги компоновки.
## Источники
- [Google Search Central: Images](https://developers.google.com/search/docs/appearance/google-images)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/images.md)
---
# Структурированные данные
## Коротко
Структурированные данные описывают фактическое видимое содержание и соответствуют выбранному типу разметки.
## Плохо
```json
JSON-LD содержит рейтинг 5.0 и 1000 отзывов, которых нет на странице и в системе.
```
## Хорошо
```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Главная","item":"https://example.com/"},{"@type":"ListItem","position":2,"name":"Каталог","item":"https://example.com/catalog/"}]}
```
## Почему
Синтаксическая валидность не подтверждает достоверность. Корректная разметка дает возможность расширенного результата, но не гарантирует его показ.
## Когда применять
При наличии поддерживаемого и полезного типа: BreadcrumbList, Product, Article и другие. Не добавляйте неподходящий тип только ради расширенного результата.
### Требования
- Выберите тип и сверяйте его обязательные/рекомендуемые поля с актуальной документацией конкретной функции. JSON-LD является допустимым форматом, а не отдельным runtime приложения.
- Сведения о цене, наличии, организации, авторе и отзывах берутся из фактического содержания; даты и ссылки актуальны.
- Разметка согласована с видимой страницей и доступна роботу. Общие правила не заменяют требования конкретного типа.
## Как проверить
- Проверьте JSON и применимый Rich Results Test, затем вручную сопоставьте поля с содержанием.
- Измените цену/наличие и проверьте синхронное обновление разметки; отсутствие расширенного результата не объявляйте автоматически дефектом кода.
## Человек
Подтверждает фактические цены, отзывы, авторство и применимость выбранного типа разметки.
## Агент
Сверяет JSON-LD с видимым содержанием и документацией функции, выполняет доступные валидаторы и фиксирует ограничения результата.
## Источники
- [Google Search Central: Structured data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [Google Search Central: Breadcrumb](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb)
Уровень: Зависит от задачи. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/structured-data.md)
---
# Пагинация и индексирование фильтров
## Коротко
Страницы каталога имеют устойчивые URL, а индексирование фильтров управляется явной матрицей.
## Плохо
```text
Все страницы имеют URL /catalog/#page-2 и canonical на первую. Фильтры создают бесконечные комбинации URL.
```
## Хорошо
```text
/catalog/?page=2 — самостоятельный URL и self-canonical.
Ссылки «Следующая» ведут через href.
Индексируемые посадочные фильтры перечислены; остальные получают согласованную политику обхода/индексирования.
```
## Почему
Бесконечная прокрутка не гарантирует обнаружение последующих объектов. Фасеты могут создавать большое число малополезных дублей.
## Когда применять
Для каталогов с пагинацией, сортировкой и фильтрами. Решение об индексируемых фильтрах зависит от содержания и поисковых задач.
### Требования
- Каждая логическая страница имеет URL без fragment как единственного номера и доступные ссылки продолжения. Не канонизируйте разные страницы серии на первую.
- Задайте allowlist полезных индексируемых комбинаций и политику остальных. Noindex требует доступности для чтения; robots.txt не заменяет удаление из индекса.
- Не создавайте бесконечные URL из повторных/несовместимых параметров. В профиле обхода Google фасетный URL без результатов, с повторными/бессмысленными фильтрами или несуществующей страницей пагинации возвращает 404 на том же URL; не перенаправляйте все такие случаи на общую страницу ошибки. Это не универсальное требование к пустому внутреннему поиску или намеренно существующей редакционной странице категории.
## Как проверить
- Обойдите каталог без scroll/click-обработчиков и подтвердите достижимость всех нужных объектов.
- Проверьте page=2, несуществующую страницу, повторные/бессмысленные фильтры и фасет без результатов: ошибочные фасетные URL возвращают 404 на исходном адресе. Отдельно проверьте политику обычного внутреннего поиска.
## Человек
Определяет полезные посадочные страницы фильтров и политику остальных комбинаций.
## Агент
Проверяет href пагинации, canonical, конечность обхода, ошибочные комбинации и соответствующие HTTP-статусы.
## Источники
- [Google Search Central: Pagination](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
- [Google Search Central: noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing)
- [Google Crawling: Faceted navigation](https://developers.google.com/crawling/docs/faceted-navigation)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/pagination-facets.md)
---
# Языковые версии и hreflang
## Коротко
Языковые версии имеют стабильные URL, корректные связи и содержание соответствующего языка.
## Плохо
```html
Все hreflang ведут на одну русскую страницу; английская версия канонизируется на русский оригинал без причины.
```
## Хорошо
```html
```
## Почему
Hreflang описывает соответствующие языковые/региональные варианты. Он не переводит страницу и не заменяет выбор языка пользователем.
## Когда применять
При наличии нескольких языковых или региональных версий. Для одноязычного сайта hreflang не требуется.
### Требования
- Укажите поддерживаемые коды языка и при необходимости региона; регион без языка не используется.
- Связи взаимны и включают саму страницу. Canonical согласован с языком и политикой дублей; отсутствующий перевод не подменяется нерелевантной страницей.
- Пользователь может перейти между вариантами. Не делайте IP/языковой redirect единственным способом доступа к версии; HTML lang проверяется для доступности.
## Как проверить
- Проверьте пары страниц, обратные ссылки, статусы и фактический язык содержания.
- Откройте каждую версию напрямую с разными языковыми настройками и без cookies.
## Человек
Выбирает поддерживаемые языки/регионы и проверяет качество переводов.
## Агент
Проверяет взаимный hreflang, коды, canonical, статусы, HTML lang и прямой доступ без принудительной смены версии.
## Источники
- [Google Search Central: Localized versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
- [Google Search Central: Canonical URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=ru)
Уровень: Зависит от задачи. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/multilingual.md)
---
# Производительность публичного сайта
## Коротко
Оценивайте загрузку, отзывчивость и стабильность по измеримым метрикам и репрезентативным страницам.
## Плохо
```text
Один Lighthouse score=100 на пустой странице объявлен доказательством быстрых форм и каталога у всех пользователей.
```
## Хорошо
```text
Полевые p75 отдельно для mobile/desktop: LCP, INP, CLS.
Целевые good-пороги: LCP<=2.5 s, INP<=200 ms, CLS<=0.1.
До накопления полевых данных: лабораторный профиль и отдельная проверка реальных взаимодействий.
```
## Почему
Лабораторное измерение воспроизводимо, а полевое показывает реальный опыт. Оценка Lighthouse не является гарантией ранжирования.
## Когда применять
Для публичных страниц и критических сценариев. При недостатке полевых данных это указывается явно, без выдуманного соответствия.
### Требования
- Зафиксируйте типы страниц, устройство, сеть, кеш и размер данных. Бюджеты ресурсов и операций задаются дополнительно к Core Web Vitals.
- Оценивайте LCP/INP/CLS на 75-м перцентиле подходящей выборки; не смешивайте хорошие desktop и плохие mobile в один маскирующий показатель.
- Обычная лабораторная загрузка без взаимодействия не измеряет INP; TBT служит вспомогательной метрикой. Проверьте реальные поиск, меню, форму и фильтры.
- Мониторинг не должен нарушать выбранные правила обработки данных и блокировки необязательных трекеров.
## Как проверить
- Сохраните конфигурацию и результаты измерений главной, категории, карточки и формы.
- Проверьте изображения, шрифты, изменение layout и задержки взаимодействия; повторите после оптимизации на том же профиле.
## Человек
Согласует устройства, сценарии и бюджеты, оценивает реальный пользовательский эффект.
## Агент
Измеряет согласованный профиль, отделяет полевые данные от лабораторных, проверяет взаимодействия и повторяет сравнимые замеры.
## Источники
- [web.dev: Web Vitals](https://web.dev/articles/vitals)
Уровень: Рекомендуется. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/performance.md)
---
# Мобильное содержание и метаданные
## Коротко
Мобильная версия сохраняет основное содержание, метаданные и доступ к критическим действиям.
## Плохо
```text
На телефоне отсутствуют описание товара, H1 и ссылки на подкатегории; содержание появляется только после свайпа.
```
## Хорошо
```text
Одинаковые существенные данные и title/canonical доступны на desktop и mobile.
Компоновка адаптивна; секции могут сворачиваться, но содержание присутствует и доступно.
```
## Почему
Google использует мобильное содержание для индексирования. Разница в компоновке допустима; исчезновение существенного содержания требует отдельного решения.
## Когда применять
Для responsive, dynamic serving и отдельных мобильных URL. Специфика Vary, redirects и альтернативных URL проверяется для выбранной архитектуры.
### Требования
- Сравните основной текст, заголовки, изображения, robots, структурированные данные и ссылки между вариантами.
- Основное содержание не должно требовать пользовательского действия для загрузки. Сворачивание уже доступного содержания отличается от загрузки только по клику.
- Проверьте меню, поиск, формы и согласия на узком экране; popup и фиксированные элементы не перекрывают действия.
## Как проверить
- Проверьте реальный мобильный браузер и HTML, получаемый мобильным роботом.
- Сравните индексируемые данные и пройдите критические сценарии при узком экране и увеличенном тексте.
## Человек
Принимает читаемость и критические сценарии на реальном мобильном устройстве.
## Агент
Сравнивает существенное содержание, метаданные и ссылки вариантов; проверяет отсутствие перекрытых действий.
## Источники
- [Google Search Central: Mobile-first indexing](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/mobile-content.md)
---
# Приемка публичного сайта перед релизом
## Коротко
Релиз принимается по матрице типов страниц и сценариев с сохраненными свидетельствами.
## Плохо
```text
Проверена только главная. После релиза каталог закрыт noindex, форма теряет заявку, sitemap содержит staging-домен.
```
## Хорошо
```text
Матрица: главная, категория, карточка, статья, поиск, форма, 404, legal.
Для каждой: URL, ожидаемый статус/indexability, правила, результат, свидетельство, ответственный.
Проверен production после публикации и определен откат.
```
## Почему
Список требований становится приемкой только при привязке к конкретному результату. SEO-проверка не заменяет функциональную, доступностную и правовую приемку.
## Когда применять
Для запуска сайта и изменений маршрутов, шаблонов, CMS, домена, форм, аналитики или контента. Неприменимые проверки имеют явное основание.
### Требования
- До релиза выберите применимые правила и репрезентативные URL, включая длинные/пустые данные, ошибки и приватные маршруты.
- Проверьте статусы, индексирование, canonical, title/H1, favicon, sitemap, ссылки, mobile, производительность и формы. Подключите профиль требований РФ при его применимости.
- Фиксируйте commit/release, окружение, дату, фактический результат и ссылку на свидетельство. Статусы pass/fail/not-run/not-applicable/blocked не подменяются общим «готово».
- После публикации повторите критический smoke на production: прямые URL, robots, реальные формы в безопасном тестовом режиме и внешний результат. Определите владельца отката.
## Как проверить
- Покажите заполненную матрицу с конкретными URL, а не пустой шаблон.
- Измените шаблон или домен и подтвердите повторную проверку затронутых типов страниц и конечной production-версии.
## Человек
Принимает применимость проверок, открытые риски и решение о выпуске; назначает владельца отката.
## Агент
Заполняет матрицу фактическими результатами и свидетельствами, проверяет опубликованные URL и конечный результат форм.
## Источники
- [Google Search Central: SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/release-audit.md)
```
## Почему
Изображение как CSS-фон не заменяет содержательный img для поиска изображений. Alt объясняет смысл, а не служит списком ключевых слов.
## Когда применять
Для изображений товаров, статей и других значимых материалов. Декоративные изображения могут оставаться фоном или иметь пустой alt.
### Требования
- Для содержательных изображений используйте img с src; picture/srcset имеют подходящий fallback. Ресурс доступен без сессии, если предназначен для индексирования.
- Alt и подпись соответствуют роли и языку страницы; не дублируйте длинный соседний текст без необходимости.
- Задайте размеры/соотношение для устойчивой компоновки, подходящие варианты разрешения и бюджет байтов. Основное изображение не откладывается до пользовательского действия.
## Как проверить
- Проверьте URL, MIME, загрузку на мобильном устройстве, alt и отсутствие лишнего скачивания оригиналов.
- Сравните визуальный контекст и описание; проверьте поведение при недоступном изображении.
## Человек
Проверяет смысл alt и подписи, права на изображение и качество выбранных вариантов.
## Агент
Проверяет src/srcset, размеры, загрузку, MIME и alt по контексту; измеряет объем ресурсов и сдвиги компоновки.
## Источники
- [Google Search Central: Images](https://developers.google.com/search/docs/appearance/google-images)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/images.md)
---
# Структурированные данные
## Коротко
Структурированные данные описывают фактическое видимое содержание и соответствуют выбранному типу разметки.
## Плохо
```json
JSON-LD содержит рейтинг 5.0 и 1000 отзывов, которых нет на странице и в системе.
```
## Хорошо
```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Главная","item":"https://example.com/"},{"@type":"ListItem","position":2,"name":"Каталог","item":"https://example.com/catalog/"}]}
```
## Почему
Синтаксическая валидность не подтверждает достоверность. Корректная разметка дает возможность расширенного результата, но не гарантирует его показ.
## Когда применять
При наличии поддерживаемого и полезного типа: BreadcrumbList, Product, Article и другие. Не добавляйте неподходящий тип только ради расширенного результата.
### Требования
- Выберите тип и сверяйте его обязательные/рекомендуемые поля с актуальной документацией конкретной функции. JSON-LD является допустимым форматом, а не отдельным runtime приложения.
- Сведения о цене, наличии, организации, авторе и отзывах берутся из фактического содержания; даты и ссылки актуальны.
- Разметка согласована с видимой страницей и доступна роботу. Общие правила не заменяют требования конкретного типа.
## Как проверить
- Проверьте JSON и применимый Rich Results Test, затем вручную сопоставьте поля с содержанием.
- Измените цену/наличие и проверьте синхронное обновление разметки; отсутствие расширенного результата не объявляйте автоматически дефектом кода.
## Человек
Подтверждает фактические цены, отзывы, авторство и применимость выбранного типа разметки.
## Агент
Сверяет JSON-LD с видимым содержанием и документацией функции, выполняет доступные валидаторы и фиксирует ограничения результата.
## Источники
- [Google Search Central: Structured data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [Google Search Central: Breadcrumb](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb)
Уровень: Зависит от задачи. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/structured-data.md)
---
# Пагинация и индексирование фильтров
## Коротко
Страницы каталога имеют устойчивые URL, а индексирование фильтров управляется явной матрицей.
## Плохо
```text
Все страницы имеют URL /catalog/#page-2 и canonical на первую. Фильтры создают бесконечные комбинации URL.
```
## Хорошо
```text
/catalog/?page=2 — самостоятельный URL и self-canonical.
Ссылки «Следующая» ведут через href.
Индексируемые посадочные фильтры перечислены; остальные получают согласованную политику обхода/индексирования.
```
## Почему
Бесконечная прокрутка не гарантирует обнаружение последующих объектов. Фасеты могут создавать большое число малополезных дублей.
## Когда применять
Для каталогов с пагинацией, сортировкой и фильтрами. Решение об индексируемых фильтрах зависит от содержания и поисковых задач.
### Требования
- Каждая логическая страница имеет URL без fragment как единственного номера и доступные ссылки продолжения. Не канонизируйте разные страницы серии на первую.
- Задайте allowlist полезных индексируемых комбинаций и политику остальных. Noindex требует доступности для чтения; robots.txt не заменяет удаление из индекса.
- Не создавайте бесконечные URL из повторных/несовместимых параметров. В профиле обхода Google фасетный URL без результатов, с повторными/бессмысленными фильтрами или несуществующей страницей пагинации возвращает 404 на том же URL; не перенаправляйте все такие случаи на общую страницу ошибки. Это не универсальное требование к пустому внутреннему поиску или намеренно существующей редакционной странице категории.
## Как проверить
- Обойдите каталог без scroll/click-обработчиков и подтвердите достижимость всех нужных объектов.
- Проверьте page=2, несуществующую страницу, повторные/бессмысленные фильтры и фасет без результатов: ошибочные фасетные URL возвращают 404 на исходном адресе. Отдельно проверьте политику обычного внутреннего поиска.
## Человек
Определяет полезные посадочные страницы фильтров и политику остальных комбинаций.
## Агент
Проверяет href пагинации, canonical, конечность обхода, ошибочные комбинации и соответствующие HTTP-статусы.
## Источники
- [Google Search Central: Pagination](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading)
- [Google Search Central: noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing)
- [Google Crawling: Faceted navigation](https://developers.google.com/crawling/docs/faceted-navigation)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/pagination-facets.md)
---
# Языковые версии и hreflang
## Коротко
Языковые версии имеют стабильные URL, корректные связи и содержание соответствующего языка.
## Плохо
```html
Все hreflang ведут на одну русскую страницу; английская версия канонизируется на русский оригинал без причины.
```
## Хорошо
```html
```
## Почему
Hreflang описывает соответствующие языковые/региональные варианты. Он не переводит страницу и не заменяет выбор языка пользователем.
## Когда применять
При наличии нескольких языковых или региональных версий. Для одноязычного сайта hreflang не требуется.
### Требования
- Укажите поддерживаемые коды языка и при необходимости региона; регион без языка не используется.
- Связи взаимны и включают саму страницу. Canonical согласован с языком и политикой дублей; отсутствующий перевод не подменяется нерелевантной страницей.
- Пользователь может перейти между вариантами. Не делайте IP/языковой redirect единственным способом доступа к версии; HTML lang проверяется для доступности.
## Как проверить
- Проверьте пары страниц, обратные ссылки, статусы и фактический язык содержания.
- Откройте каждую версию напрямую с разными языковыми настройками и без cookies.
## Человек
Выбирает поддерживаемые языки/регионы и проверяет качество переводов.
## Агент
Проверяет взаимный hreflang, коды, canonical, статусы, HTML lang и прямой доступ без принудительной смены версии.
## Источники
- [Google Search Central: Localized versions](https://developers.google.com/search/docs/specialty/international/localized-versions)
- [Google Search Central: Canonical URLs](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=ru)
Уровень: Зависит от задачи. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/multilingual.md)
---
# Производительность публичного сайта
## Коротко
Оценивайте загрузку, отзывчивость и стабильность по измеримым метрикам и репрезентативным страницам.
## Плохо
```text
Один Lighthouse score=100 на пустой странице объявлен доказательством быстрых форм и каталога у всех пользователей.
```
## Хорошо
```text
Полевые p75 отдельно для mobile/desktop: LCP, INP, CLS.
Целевые good-пороги: LCP<=2.5 s, INP<=200 ms, CLS<=0.1.
До накопления полевых данных: лабораторный профиль и отдельная проверка реальных взаимодействий.
```
## Почему
Лабораторное измерение воспроизводимо, а полевое показывает реальный опыт. Оценка Lighthouse не является гарантией ранжирования.
## Когда применять
Для публичных страниц и критических сценариев. При недостатке полевых данных это указывается явно, без выдуманного соответствия.
### Требования
- Зафиксируйте типы страниц, устройство, сеть, кеш и размер данных. Бюджеты ресурсов и операций задаются дополнительно к Core Web Vitals.
- Оценивайте LCP/INP/CLS на 75-м перцентиле подходящей выборки; не смешивайте хорошие desktop и плохие mobile в один маскирующий показатель.
- Обычная лабораторная загрузка без взаимодействия не измеряет INP; TBT служит вспомогательной метрикой. Проверьте реальные поиск, меню, форму и фильтры.
- Мониторинг не должен нарушать выбранные правила обработки данных и блокировки необязательных трекеров.
## Как проверить
- Сохраните конфигурацию и результаты измерений главной, категории, карточки и формы.
- Проверьте изображения, шрифты, изменение layout и задержки взаимодействия; повторите после оптимизации на том же профиле.
## Человек
Согласует устройства, сценарии и бюджеты, оценивает реальный пользовательский эффект.
## Агент
Измеряет согласованный профиль, отделяет полевые данные от лабораторных, проверяет взаимодействия и повторяет сравнимые замеры.
## Источники
- [web.dev: Web Vitals](https://web.dev/articles/vitals)
Уровень: Рекомендуется. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/performance.md)
---
# Мобильное содержание и метаданные
## Коротко
Мобильная версия сохраняет основное содержание, метаданные и доступ к критическим действиям.
## Плохо
```text
На телефоне отсутствуют описание товара, H1 и ссылки на подкатегории; содержание появляется только после свайпа.
```
## Хорошо
```text
Одинаковые существенные данные и title/canonical доступны на desktop и mobile.
Компоновка адаптивна; секции могут сворачиваться, но содержание присутствует и доступно.
```
## Почему
Google использует мобильное содержание для индексирования. Разница в компоновке допустима; исчезновение существенного содержания требует отдельного решения.
## Когда применять
Для responsive, dynamic serving и отдельных мобильных URL. Специфика Vary, redirects и альтернативных URL проверяется для выбранной архитектуры.
### Требования
- Сравните основной текст, заголовки, изображения, robots, структурированные данные и ссылки между вариантами.
- Основное содержание не должно требовать пользовательского действия для загрузки. Сворачивание уже доступного содержания отличается от загрузки только по клику.
- Проверьте меню, поиск, формы и согласия на узком экране; popup и фиксированные элементы не перекрывают действия.
## Как проверить
- Проверьте реальный мобильный браузер и HTML, получаемый мобильным роботом.
- Сравните индексируемые данные и пройдите критические сценарии при узком экране и увеличенном тексте.
## Человек
Принимает читаемость и критические сценарии на реальном мобильном устройстве.
## Агент
Сравнивает существенное содержание, метаданные и ссылки вариантов; проверяет отсутствие перекрытых действий.
## Источники
- [Google Search Central: Mobile-first indexing](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/mobile-content.md)
---
# Приемка публичного сайта перед релизом
## Коротко
Релиз принимается по матрице типов страниц и сценариев с сохраненными свидетельствами.
## Плохо
```text
Проверена только главная. После релиза каталог закрыт noindex, форма теряет заявку, sitemap содержит staging-домен.
```
## Хорошо
```text
Матрица: главная, категория, карточка, статья, поиск, форма, 404, legal.
Для каждой: URL, ожидаемый статус/indexability, правила, результат, свидетельство, ответственный.
Проверен production после публикации и определен откат.
```
## Почему
Список требований становится приемкой только при привязке к конкретному результату. SEO-проверка не заменяет функциональную, доступностную и правовую приемку.
## Когда применять
Для запуска сайта и изменений маршрутов, шаблонов, CMS, домена, форм, аналитики или контента. Неприменимые проверки имеют явное основание.
### Требования
- До релиза выберите применимые правила и репрезентативные URL, включая длинные/пустые данные, ошибки и приватные маршруты.
- Проверьте статусы, индексирование, canonical, title/H1, favicon, sitemap, ссылки, mobile, производительность и формы. Подключите профиль требований РФ при его применимости.
- Фиксируйте commit/release, окружение, дату, фактический результат и ссылку на свидетельство. Статусы pass/fail/not-run/not-applicable/blocked не подменяются общим «готово».
- После публикации повторите критический smoke на production: прямые URL, robots, реальные формы в безопасном тестовом режиме и внешний результат. Определите владельца отката.
## Как проверить
- Покажите заполненную матрицу с конкретными URL, а не пустой шаблон.
- Измените шаблон или домен и подтвердите повторную проверку затронутых типов страниц и конечной production-версии.
## Человек
Принимает применимость проверок, открытые риски и решение о выпуске; назначает владельца отката.
## Агент
Заполняет матрицу фактическими результатами и свидетельствами, проверяет опубликованные URL и конечный результат форм.
## Источники
- [Google Search Central: SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)
Уровень: Обязательно. Опубликовано: 2026-11-13. Проверено: 2026-11-13. Изменено: 2026-11-13.
[Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/d33454c0dad753475ecc92aaecf8d783f02fd01b/registry/standards/seo/site-audit/rules/release-audit.md)