---
name: landing-acceptance
description: "Приёмка коммерческого лендинга перед публикацией: проверка оффера, доказательств, конверсии, SEO, микроразметки, скорости и мобильного сценария. Использовать, когда нужно проверить лендинг, найти критичные потери или убедиться, что новую версию можно выпускать."
---

# Приёмка лендинга

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

## 1. Зафиксируй задачу страницы

Определи из страницы и контекста:

- кто целевой посетитель;
- какое действие считается конверсией;
- что человек получает после действия;
- какое главное сомнение должно быть снято до формы.

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

## 2. Проверь путь к заявке

Пройди страницу сверху вниз как новый посетитель:

1. Первый экран: конкретный результат, аудитория, причина доверять, понятная кнопка.
2. Аргументация: выгоды связаны с задачей аудитории, а не перечисляют свойства.
3. Доказательства: цифры имеют источник, кейсы содержат исходную точку, действие и результат.
4. Возражения: цена, сроки, риск, внедрение и следующий шаг раскрыты до формы.
5. Форма: полей не больше необходимого, согласие на обработку данных видно, успех и ошибка действительно работают.

Отдельно проверь все кнопки и ссылки. Для каждого призыва укажи, куда он ведёт и соответствует ли обещанию.

## 3. Проверь поиск и разметку

Для итогового URL проверь:

- один осмысленный H1;
- уникальные title и description;
- canonical на основной HTTPS-адрес;
- robots без случайного noindex;
- наличие URL в sitemap;
- последовательные H2/H3;
- alt у содержательных изображений;
- JSON-LD только для реально видимых сущностей;
- отсутствие взаимоисключающих дублей schema.org.

Не считай микроразметку доказательством качества текста. Она лишь описывает фактически видимое содержимое.

## 4. Проверь живую страницу

Открой опубликованный URL на ширине около 1440 px и 390 px. На обоих размерах:

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

Если доступен Lighthouse или аналог, зафиксируй LCP, CLS, INP/TBT и общий вес страницы. Не выдавай локальный замер за полевые данные пользователей.

## 5. Сдай отчёт

Начни с вердикта: `можно выпускать`, `можно выпускать с оговорками` или `нельзя выпускать`.

Дальше дай таблицу:

| Приоритет | Где | Наблюдение | Почему теряем | Что исправить | Как проверить |
|---|---|---|---|---|---|

Приоритеты:

- P0 — форма, оплата или основной сценарий не работает;
- P1 — сильный риск потери трафика или заявок;
- P2 — заметное улучшение ясности, доверия или скорости;
- P3 — полировка без существенного влияния на результат.

В конце перечисли пройденные проверки, непроверенные места и факты, которые нужно запросить у владельца. Не маскируй предположение под измерение.

## 6. Проверь собственный вывод

Перед сдачей отчёта повторно открой страницу и убедись, что каждый пункт P0 и P1
воспроизводится. Для каждого сильного утверждения приложи наблюдаемый факт: адрес,
скриншот, ответ сервера, ошибку консоли или конкретный фрагмент страницы. Удали из
вердикта всё, что основано только на догадке. Если часть проверки недоступна, назови её
прямо и не заменяй отсутствующий замер общими словами.