Короткий ответ
Директивы индексации собираются тем же кодом, что и страницы, а значит ломаются как код. Забытый Disallow или noindex в общем лэйауте уезжает в прод без единой ошибки и всплывает графиком трафика через полтора месяца.
Три файла решают, существует ли страница
До вопроса о позициях страница обязана пройти трое ворот, которые не имеют отношения к качеству текста. robots.txt решает, разрешено ли роботу вообще запросить URL. Мета-тег robots или заголовок X-Robots-Tag решает, можно ли хранить полученный ответ в индексе. Sitemap сообщает, какие адреса сам сайт считает каноническими и достойными быстрого обхода. Отличная страница может провалиться на всех трёх воротах разом. Ни один редактор об этом не узнает: в браузере она открывается ровно так же, как открывалась вчера.
Пропускают обычно другое: где эти три вещи физически лежат. Это не переключатели в маркетинговой панели. На любом современном стеке они собираются на этапе сборки тем же кодом, который рендерит страницу. Роут экспортирует объект метаданных, sitemap выходит из функции с запросом в базу, robots.txt отдаётся по-разному в зависимости от окружения, канонические адреса склеиваются из константы базового URL. Всё это правит разработчик, который слова «краулинговый бюджет» никогда не слышал.
Отсюда следует главное: правила индексации живут по законам кода. У них есть версии, ветки и конфликты слияния. Они ведут себя по-разному в зависимости от того, какая переменная окружения оказалась выставлена. Их меняет обновление зависимости, поменявшее дефолт, или вынос хелпера в общий лэйаут. И, как любой код без тестов, они дрейфуют в то состояние, в котором их оставил последний торопливый коммит.
В каталоге эта работа названа отдельной услугой, а не советом. «Sitemap, robots.txt и защита индексации в CI» — категория «Индексация», сложность «Новичок», ⏱ 2–5 часов, 5 000 – 20 000 ₽ или $80 – $300. Отметка сложности честная и слегка неприятная: здесь нет ничего трудного. Просто это никогда не является ничьей персональной задачей, пока трафик ещё на месте. Эту работу откладывают не из-за сложности, а из-за отсутствия хозяина у трёх скучных файлов.
Как раздел исчезает, хотя SEO никто не трогал
Механика первая: утечка защиты стенда. Команда закрывает staging сплошным Disallow, чтобы он не конкурировал с продом по тем же запросам. robots.txt при этом генерится из шаблона, окружение читается из переменной, и однажды деплой уезжает с неправильной переменной или вовсе без неё, откатываясь на «безопасный» дефолт. Прод начинает отдавать запрет на весь сайт. Ошибки нет, сборка зелёная, файл абсолютно валидный. Замечают такое обычно не по коду, а по падению показов через несколько недель после релиза.
Механика вторая: noindex, сбежавший из клетки. Разработчик ставит noindex на один тип страниц во время разработки — новые фильтры, постраничный архив, недоделанный шаг оформления заказа. Через месяцы условие переезжает в общий компонент лэйаута, потому что трём роутам понадобилась одна обёртка. Директива распространяется на все дочерние маршруты. Раздел живой, залинкован, красивый — и тихо исключён из индекса. Ни один тест при этом не падает, потому что тестов на директивы индексации в проекте нет.
Механика третья: схлопнувшийся sitemap. Генерация ходит в источник данных на сборке и отфильтровывает черновики. Кто-то переименовывает поле статуса или добавляет колонку со значением по умолчанию null, и фильтр, который должен был выкинуть неопубликованное, выкидывает почти всё. Сборка успешна, XML валиден по схеме. В файле одиннадцать адресов там, где было четыре тысячи, и ни один шаг пайплайна не считает это событием.
Механика четвёртая: canonical, указывающий не на тот хост. Базовый URL для канонических ссылок падает на стендовый домен, когда переменной окружения нет. Теперь каждый canonical ведёт туда, куда робот либо не доберётся, либо, что хуже, доберётся. Ни один из четырёх случаев не выдуман ради красного словца. Все четыре — обычные рефакторинги, которые уезжают во вторник днём и проходят ревью. Ревьюер смотрит на логику компонента и на стиль кода, а не на побочный эффект для робота.
Поломка, которая доезжает через шесть недель
Упавший юнит-тест падает сейчас, перед тем, кто его сломал, и с номером строки. Сломанное правило индексации падает не по вашему расписанию, а по расписанию робота. Ему нужно вернуться, перечитать robots.txt, перезапросить страницы, решить, что директива стабильна, а не случайна, и только потом выкинуть адреса. Позиции не исчезают, а осыпаются, и трафик падает кривой, которую легко принять за сезонность. Или за действия конкурента, который как раз в этот месяц запустил кампанию и забрал часть спроса.
К моменту, когда потеря видна в отчёте, причинная нить уже перерезана. С тех пор приехали десятки коммитов. Правку шаблона robots никто не помнит, потому что со стороны разработчика это была одна строка в большом пулл-реквесте. Расследование стартует из аналитики, переходит к съёму позиций и добирается до виноватого файла только если кто-то догадается сравнить его с версией прошлого квартала. А сравнивать не с чем, если никто никогда не хранил, как этот файл выглядел до релиза.
Эта асимметрия и есть весь аргумент в пользу проверки в пайплайне. Тест, который выполняется на каждом пулл-реквесте, превращает шестинедельное расследование в красную сборку с именем файла. Автор изменения ещё держит его в руках, ещё помнит контекст, и стоимость починки в этот момент — примерно минута. Тот же дефект, найденный по отчёту трафика, стоит квартал. Разница не в сложности починки, а в том, сколько времени прошло между причиной и её обнаружением.
Это сознательно не разговор про мониторинг. Мониторинг сообщает, что сайт уже вылетел из индекса, и предлагает реагировать. Проверка в CI сообщает, что деплой выкинул бы сайт из индекса, до того как это кто-то снаружи команды увидит. Та же информация, но по другую сторону релиза — по единственную сторону, где она стоит дёшево. Мониторинг индексации всё равно нужен — но как второй рубеж, а не как единственный способ узнать о проблеме.
Что именно утверждает проверка индексации перед деплоем
Работающие проверки скучны и предельно конкретны. robots.txt из продовой сборки не должен содержать сплошного запрета. Он должен ссылаться на sitemap. И самое полезное: он должен совпадать со снимком файла, закоммиченным в репозиторий, чтобы любое изменение становилось отревьюенным диффом, а не побочным эффектом чего-то другого. Осознанная правка обновляет снимок и проходит, случайная — не проходит. Разница между этими двумя случаями и есть всё, что проверка обязана уметь различать.
Sitemap не просто валидируют, его считают и выборочно дёргают. Проверяйте минимальное число адресов относительно прошлой успешной сборки, чтобы падение с четырёх тысяч до одиннадцати стало ошибкой, а не релизом. Проверяйте, что случайная выборка адресов реально отдаёт 200. Проверяйте, что все адреса абсолютные и на каноническом хосте. Проверяйте, что файл парсится и укладывается в лимиты по размеру и числу записей. Каждое из этих утверждений пишется одной строкой в тесте и работает потом годами без обслуживания.
Шаблоны сканируют на директивы, которых там быть не должно. Утверждайте: ни один тип страниц не рендерит noindex, если он не внесён в белый список, лежащий в репозитории, — корзина, личный кабинет, внутренний поиск, что там команда решила. Белый список и есть настоящий результат: он превращает невидимую договорённость в письменное, проверяемое намерение, и на вопрос «почему тут noindex» всегда есть записанный ответ.
Объём в каталоге назван прямо: ⏱ 2–5 часов, 5 000 – 20 000 ₽ или $80 – $300, сложность «Новичок», категория «Индексация». Описание обещает результат в том же регистре — поисковики видят ровно те страницы, которые нужно, быстро находят новые и не тратят краулинговый бюджет на мусор, а случайно закрытый релизом сайт больше не уходит из индекса незамеченным. Ни одного обещания про позиции в этом описании нет, и это ровно та честность, которой стоит требовать.
Что микроразметка сообщает машине на самом деле
HTML описывает, где что лежит на странице. Он не описывает, что это такое. Цена, телефон и артикул для дерева документа — одинаковые текстовые узлы внутри блоков, и любой смысл машина достаёт догадкой по вёрстке, придуманной для человеческих глаз. Микроразметка Schema.org, обычно в виде JSON-LD в теге script, убирает шаг догадки: она называет типы напрямую. Это блок Product, это его цена, это код валюты, это автор, это дата публикации статьи.
У этой явности два разных потребителя, и пользуются они ей по-разному. Поисковики читают её, решая, имеет ли результат право на расширенное отображение — рейтинг, цена с наличием, хлебные крошки, дата события, аккордеон вопросов под ссылкой. Языковые модели, которые видят страницу как текст, получают недвусмысленное заявление о сущности и её связях вместо реконструкции по визуальной иерархии, которой они не видят. При этом оба потребителя читают один и тот же файл в одном и том же формате.
Описание в каталоге говорит ровно это и ничего сверх: поисковики и ИИ-модели начинают однозначно понимать, что у вас за товар, компания, автор и событие, растут расширенные сниппеты в выдаче и шанс попасть в цитаты ИИ-ответов. Ключевое слово — растут. Не гарантируются, не открываются, не ранжируются. Разница между правом на показ и результатом — содержание следующего раздела. Осторожность этой формулировки стоит перенести и в собственные обещания клиенту.
Объём: «Микроразметка Schema.org с проверкой в CI», категория «Структурированные данные», сложность «Нужен опыт», ⏱ 4–8 часов на 5–7 шаблонов, 8 000 – 35 000 ₽ или $120 – $500. Единица измерения — шаблоны, а не страницы. Товарный шаблон размечается один раз, и разметку наследуют все товары; по той же причине одна ошибка в шаблоне разъезжается по всему каталогу за один деплой.
Чего разметка не сделает, сколько её ни пиши
Она не поднимет страницу в выдаче. Разметка — это формат описания, а не сигнал качества, и её удвоение не удваивает ничего остального. Страница с безупречными Organization, Product и BreadcrumbList, под которыми нечего читать, останется там же, где была. Команды, воспринимающие разметку как рычаг, искренне удивляются неподвижному графику, и это провал ожиданий на этапе продажи, а не провал работы. Продавать разметку как способ вырасти в выдаче — значит гарантированно получить претензию через один квартал.
Она не чинит индексацию, и порядок здесь принципиален. Если robots.txt закрывает URL, JSON-LD не прочитает никто: ответ просто не запрашивается. Если общий лэйаут несёт noindex, разметка выбрасывается вместе со страницей. Именно поэтому дешёвая работа по индексации идёт первой: разметка на неиндексируемой странице — это корректный файл, который никто никогда не откроет. Порядок работ здесь не вопрос вкуса и не вопрос бюджета: он задан тем, что от чего зависит технически.
Она не создаст права на расширенный сниппет, если контент его не заслужил. У расширенных результатов есть требования к содержимому: отзыву нужен настоящий отзыв, рецепту — ингредиенты и шаги, блоку вопросов — вопросы, реально отвеченные на видимой странице. Разметка того, чего посетитель не находит глазами, — не оптимизация, а расхождение. И расхождение — единственное в этой области, что несёт риск ручных санкций.
И она не перебивает страницу. Там, где разметка и видимый контент противоречат друг другу, истиной считается видимый контент, а игнорируется разметка — или, если противоречие системное, к ней перестают относиться серьёзно на всём домене. Рабочая аналогия — подпись под фотографией. Хорошая подпись объясняет, что вы видите. Подпись от другой фотографии хуже, чем её отсутствие. Поэтому разметку проверяют не только на валидность схемы, но и на совпадение с тем, что реально выводится на экран.
Разметка протухает, потому что это копия меняющихся данных
JSON-LD — это проекция ваших данных, а не описание вашей страницы. Товарный шаблон вычитывает цену, валюту, наличие, артикул и число оценок из тех же объектов, что и HTML, и переиздаёт их во втором формате, лежащем в теге, куда никто не смотрит. Два представления одних фактов, собранные разными ветками кода, и только одно из них человек видит каждый день. Догадаться, какое перестаёт совпадать, несложно.
Сценарии поломок унылые и постоянные. Валюта после локализации начинает приезжать символом вместо ISO-кода. Наличие перестаёт быть InStock и становится переведённой строкой. Дата теряет часовой пояс при рефакторинге сериализации. Автор после миграции CMS превращается из объекта в обычную строку с именем. Каждый случай даёт разметку, которая всё ещё безупречно парсится как JSON и уже не проходит как Schema.org, — худшая из возможных комбинаций.
Поэтому в названии услуги стоит «с проверкой в CI», а не «с проверкой по договорённости». Шаг пайплайна рендерит каждый размеченный шаблон на реальных данных, вытаскивает JSON-LD из готового ответа и валидирует его против обязательных и рекомендованных свойств заявленного типа. Отсутствие обязательного свойства роняет сборку. Проверка живёт на каждом пулл-реквесте столько, сколько живёт репозиторий, а не одну неделю сдачи. Разница принципиальна: разметку ломает не день сдачи проекта, а сотый деплой после него.
Пять-семь шаблонов — реалистичный счёт для большинства сайтов: главная, товар или услуга, категория, статья, страница организации или контактов. При ⏱ 4–8 часов на 5–7 шаблонов арифметика, которую читатель повторит сам — как пример деления вилки, а не как измерение, — даёт примерно от получаса до полутора часов на шаблон. Столько и уходит на один корректно описанный тип плюс одно утверждение в тесте.
ИИ-краулеры читают не тот сайт, который видите вы
Аудиторий теперь две, и они задают два разных вопроса о доступе. С классическими поисковыми роботами договариваются не первое десятилетие, их поведение описано подробно. ИИ-краулеры новее и разнообразнее: одни забирают страницы пачками в обучающие корпуса, другие достают несколько документов в момент ответа, третьи тянут одну страницу, потому что пользователь спросил именно про эту компанию. Они приходят под своими user-agent, robots.txt соблюдают по-разному и в большинстве не исполняют JavaScript.
Последняя оговорка — самая дорогая, и её обычно обнаруживают поздно. Сайт, который рендерится целиком на клиенте, отдаёт всему, что не запускает браузерный движок, оболочку с пустым корневым блоком. Человек видит полную страницу. Робот видит заголовок, скелетон загрузки и больше ничего. Никакая дисциплина разметки и гигиена sitemap это не компенсируют: контента не было в том ответе, который реально отдали. Проверяется это за минуту: запросите свою же страницу без исполнения скриптов и посмотрите, что осталось в ответе.
Само решение о доступе — бизнесовое, и одинакового правильного ответа для всех нет. Кто-то хочет максимального охвата в ИИ-ответах и открывает всё сознательно. Кто-то хочет читаемую документацию и закрытые от массовых корпусов страницы с ценами. Кто-то отказывает обучающим краулерам, но пускает поисковый агент, который тянет страницу именно потому, что клиент про них спросил. robots.txt умеет выразить все три позиции пер-агентно; большинство сайтов не выражает ни одной.
llms.txt — складывающаяся конвенция с другой стороны той же задачи: текстовая карта в корне, которая говорит, что это за сайт и какая страница является канонической по каждой теме, чтобы модельный читатель не гадал по меню. Объём в каталоге: «Подготовка сайта под ИИ-краулеры: robots.txt, llms.txt, рендеринг», категория «AI-инфраструктура», сложность «Новичок», ⏱ 4–8 часов, 10 000 – 35 000 ₽ или $150 – $450. В описании есть пункт, на который владельцы реагируют сильнее всего: они впервые видят, кто и что у них забирает.
Порядок, в котором сначала останавливают кровотечение
Сортируйте по зависимостям, а не по амбициям и не по цене. Защита индексации идёт первой, потому что всё дальнейшее обусловлено ею. Разметка, доступ для ИИ, вложения в контент и перелинковка обращаются в ноль на адресе, который закрыт в robots.txt или несёт noindex. К тому же это самая дешёвая из трёх позиций — 5 000 – 20 000 ₽ или $80 – $300 — и самая короткая, ⏱ 2–5 часов.
Подготовка под краулеров идёт второй, потому что это вторая половина того же вопроса о доступе и она правит те же файлы. robots.txt вы уже открыли; правила по агентам, проверка, что значимые шаблоны отдаются с сервера, и публикация llms.txt относятся к тому же заходу. В каталоге это ⏱ 4–8 часов, 10 000 – 35 000 ₽ или $150 – $450. Разносить эти работы — значит дважды открыть один файл с двумя разными моделями в голове.
Разметка идёт третьей и она единственная из трёх с отметкой «Нужен опыт», а не «Новичок». ⏱ 4–8 часов на 5–7 шаблонов, 8 000 – 35 000 ₽ или $120 – $500. Третья она потому, что это работа со смыслом, а не с доступом: она предполагает, что страницы достижимы, что контент действительно есть и что кто-то в комнате может сказать, экземпляром чего является каждый тип страниц. Последнее предположение обычно и не выполняется.
В сумме — арифметика, которую читатель повторит по цифрам выше, приведённая как пример, а не как объявленная цена пакета, — три вилки дают 23 000 – 90 000 ₽ или $350 – $1 250 при ⏱ 10–21 часах работы. Это весь машиночитаемый слой сайта, выраженный одним числом, которое покупатель сверяет со своим бюджетом до начала разговора, а не тремя коммерческими предложениями, приезжающими три недели.
Как проверки доживают до второго года
Проверка, которая выдаёт предупреждение, к четвёртой неделе перестаёт кем-либо читаться. Утверждение обязано ронять сборку и блокировать слияние, и это в гораздо большей степени социальное решение, чем техническое. Договариваться о нём надо явно при сдаче, вместе с владельцем пайплайна: в первый же раз, когда сборка покраснеет из-за диффа robots.txt, кто-то попросит понизить проверку до предупреждения, и ответ должен существовать заранее. Ответ «нет, это блокирующая проверка» стоит записать в тот же документ, где живут остальные договорённости о релизах.
Схема с закоммиченным снимком делает блокирующую проверку выносимой. Вместо правила «robots.txt не должен меняться» репозиторий хранит файл с описанием того, каким robots.txt должен быть. Осознанное изменение обновляет этот файл в том же пулл-реквесте и проходит ревью как любой другой дифф. Случайное приезжает без обновления и падает. Проверка запрещает не изменение, а незамеченное изменение — единственный вид, который вредит. Именно поэтому такую проверку не саботируют: она не мешает работать, она мешает работать вслепую.
Вторая половина выживаемости — владение. Эти файлы лежат в зазоре между маркетингом и разработкой и по умолчанию не принадлежат ни одному отделу, отчего и протухают. Назначить одного ревьюера на изменения robots.txt, генерации sitemap, логики canonical и белого списка noindex не стоит ничего и убирает ту самую двусмысленность, из-за которой директива уезжает непроверенной: каждая сторона считала, что смотрит другая. Один человек, четыре файла, ни строчки нового кода — самая дешёвая часть всей этой истории.
Возвращаться к разметке нужно при изменении модели данных, а не по календарю. Новый атрибут товара, миграция CMS, новый тип страниц, смена способа хранения авторов — каждое из этих событий является настоящим поводом перепроверить валидность и каждое невидимо из квартального регламента. Если валидация уже стоит в CI, все они перезапускают её сами. В этом и разница между сданным проектом и свойством, которое у сайта теперь есть постоянно.
Вопросы и ответы
Сколько стоит внедрить микроразметку Schema.org на сайт?
В каталоге VIT MARKET услуга «Микроразметка Schema.org с проверкой в CI» стоит 8 000 – 35 000 ₽ или $120 – $500, срок указан как ⏱ 4–8 часов на 5–7 шаблонов. Сложность помечена как «Нужен опыт», категория — «Структурированные данные». Единица измерения здесь шаблон, а не страница: один товарный шаблон закрывает весь каталог товаров.
Может ли релиз случайно выкинуть страницы из поиска?
Да, и обычно это происходит без единой ошибки. Стендовый сплошной запрет, уехавший в прод, noindex, оставшийся в общем лэйауте, или запрос sitemap, который молча вернул одиннадцать адресов вместо четырёх тысяч, — всё это проходит сборку. Ровно для этого в каталоге есть «Sitemap, robots.txt и защита индексации в CI»: ⏱ 2–5 часов, 5 000 – 20 000 ₽ или $80 – $300, сложность «Новичок».
Влияет ли микроразметка на позиции в выдаче?
Нет. Разметка даёт странице право на расширенное отображение и однозначно называет сущности для ИИ-моделей, но она не является фактором ранжирования и не спасёт адрес, закрытый в robots.txt. В каталоге выгода сформулирована как рост расширенных сниппетов и шанса попасть в цитаты ИИ-ответов — именно шанса, за ⏱ 4–8 часов на 5–7 шаблонов.
Что такое llms.txt и нужен ли он моему сайту?
llms.txt — текстовый файл в корне сайта, который сообщает модельному читателю, что это за сайт и какая страница канонична по каждой теме. Он входит в услугу «Подготовка сайта под ИИ-краулеры: robots.txt, llms.txt, рендеринг»: категория «AI-инфраструктура», сложность «Новичок», ⏱ 4–8 часов, 10 000 – 35 000 ₽ или $150 – $450. Меньше всего он поможет сайту на клиентском рендеринге, который отдаёт роботу без JavaScript пустую оболочку.