Сайт без SEO-карты — это дом без фундамента. И как QA нашёл 32 дыры за 4 минуты

QA-скрипт запускается перед каждым деплоем. Его задача: проверить, что в HTML-файлах нет запрещённых слов из §10 SUPER_PROMPT (гарантии, клиентские бренды, AI-штампы), а все internal_links из YAML-метаданных отдают 200 OK.

В 12:33 скрипт выдал: 34 YELLOW, 0 RED. RED блокирует деплой (грубые нарушения), YELLOW выдаёт предупреждения, которые не блокируют, но требуют разбора. За 4 минуты (12:33 → 12:37) я разобрал все 34 случая, выпустил отчёт qa-post: 0 RED, 0 YELLOW.

32 из 34 предупреждений оказались одного типа: ссылки в 06_seo_map.yaml ведут на slug-и, которых нет в папке site/. Конкретные примеры: /cases/dispatcher-bot/, /blog/marketing/, /legal/privacy/, /blog/safe-launch-30-days/, /blog/n8n-bot/, /blog/multi-kanal/ и ещё 26 адресов.

Обычно страницу добавляют в sitemap.xml уже после того, как она создана. Я сделал иначе: при проектировании архитектуры в апреле прописал в YAML-карте все страницы, которые планирую создать. Это форвард-декларация: «вот как будет выглядеть сайт через 3 месяца».

QA воспринимает эти ссылки буквально: нет файла, выдаёт YELLOW. Поэтому 32 «дыры» показывают просто список страниц, которые ещё предстоит написать.

• Плюс подхода: никогда не забудешь, что запланировал. YAML честно хранит долг архитектуры.
• Минус без QA: если нет автоматической проверки, ссылки на несуществующие страницы уходят в прод и режут crawl-budget Яндекса.
• Решение: QA считает YELLOW и блокирует только RED, поэтому деплой разрешён, долг виден. Это намеренное проектное решение.

Параллельно с QA разобрал второй застарелый баг: раздел проектов и раздел кейсов на сайте показывали одинаковые 5 проектов с похожими заголовками и мета-тегами. Яндекс видел дубли.

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

Решение: разнести по поисковому intent. /projects/ стал информационным каталогом: все 7 проектов, разбивка «Свои» / «Клиентские», описание что и зачем. /cases/ теперь коммерческая витрина: 3 флагманских проекта с измеримыми результатами + CTA на /contact/. Разный intent, ключи и призывы к действию у каждой страницы свои.

Дополнительно: 8 skel-статей блога с priority 0.7-0.8 в sitemap без реального контента автоматически понижены до 0.3. Builder.py теперь сам определяет приоритет: если есть content-фрагмент, ставит priority 0.7, если нет, то 0.3. Ещё убрана orphan-папка /projects/content-factory/ от старого slug, которая индексировалась Яндексом и уводила краулер в никуда.

Если у вас статический сайт, портфолио или лендинг, проверьте четыре вещи. Для CMS (WordPress, Тильда) часть из них делается автоматически, но не всё.

• 1. Есть ли у вас разделы с похожим содержимым? «Портфолио» и «Кейсы», «Услуги» и «Проекты»: если они показывают одно и то же, Яндекс видит дубли. Разнесите по intent: один информационный, другой коммерческий.
• 2. Есть ли в sitemap.xml страницы без контента? Пустые категории, заглушки-«скоро», архивные slug-и едят crawl-budget и не дают ничего взамен. Ставьте priority 0.1-0.2 для таких страниц или исключите из sitemap совсем.
• 3. Есть ли у вас orphan-папки? Страницы, которые не ссылаются на сайт и не упоминаются ни в одном меню, Яндекс индексирует, но не знает, что с ними делать. Удалите или закройте noindex.
• 4. Настроена ли автоматическая проверка перед деплоем? Даже простой Python-скрипт с grep по HTML-файлам + httpx для HTTP-проверок уже защищает от случайных ошибок. На написание уходит 2-3 часа, а разгребать последствия приходится дольше.

Хотите такой же QA-конвейер для своего сайта?

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