Sirak Ghroyan - AI, SEO, GEO

Илья, спасибо за важное дополнение. Согласен: перед редизайном стоит собрать фильтр-URL с показами и переходами из поисковых панелей, дополнить их данными аналитики, внутренними и внешними ссылками. При этом отсутствие показов в выбранном периоде ещё не доказывает бесполезность страницы особенно при сезонном спросе.
Для ценных срезов я бы сохранял адреса, а при неизбежной смене URL составлял карту соответствий и ставил постоянный редирект на эквивалентную посадочную. Массовый редирект на главную такую задачу не решает. И robots.txt здесь важно не использовать как универсальное средство удаления: запрет обхода сам по себе не означает исключения URL из индекса и может помешать роботу увидеть изменения. Поэтому сначала - инвентаризация и решение по каждому классу страниц, затем - правила закрытия.

Олег, спасибо, это важная развилка. Я бы разделял произвольный пустой результат фильтрации и постоянную сезонную посадочную. Для комбинации фильтров без результатов Google прямо рекомендует 404: https://developers.google.com/crawling/docs/faceted-navigation. Один только белый список не отменяет этой рекомендации.
Если страницу нужно сохранять круглый год, я бы проектировал её как самостоятельную полезную посадочную: с описанием сезонного предложения, честным сообщением о наличии, релевантными альтернативами и возможностью узнать о поступлении, если такая функция действительно есть. Для такого решения 200 можно рассматривать, но это уже редакционно-продуктовое решение, а не обещанный поисковиком способ удержать пустой срез в индексе. Одна заглушка «товаров нет» может быть воспринята как soft 404.
И важная поправка к формулировке: удаление URL из sitemap не запрещает его индексирование. Если сохраняем полезную посадочную с 200 и хотим видеть её в поиске, исключать её из sitemap только из-за нулевого остатка я бы не стал. Если остаётся именно пустая выдача фильтра ь следовал бы рекомендации 404. Срок возврата в индекс после восстановления не гарантирован, поэтому сезонную архитектуру лучше определить до обнуления ассортимента.

Спасибо!

Олег, спасибо, что поделились наблюдением. Я бы выбирал очередь с автоматическими повторами, а ручное окно оставлял для диагностики. Фиксированную паузу 15–20 минут не стал бы считать универсальной: допустимая частота зависит от ограничений сервиса.

При 429 официальный FAQ IndexNow рекомендует приостановить отправку и выдержать Retry-After: https://www.indexnow.org/faq. Если заголовка нет, мой вариант реализации — нарастающая задержка с небольшим случайным разбросом, ограничением числа попыток и уведомлением при устойчивых ошибках. Это инженерная рекомендация, а не обязательный алгоритм протокола.

В очереди полезно объединять повторные события для одного URL, отправлять только реальные изменения и сохранять код ответа, время, попытку и причину повтора. Успешно принятую пачку не нужно бесконечно дублировать. И отдельно уточню: 202 означает, что URL получен и проверка ключа ещё ожидается; это не подтверждение обхода или индексирования.

Олег, спасибо! Я бы собирал такую карту из двух источников, а не выбирал между ними. Краулер вроде Screaming Frog показывает текущие сигналы сайта: HTTP-статус, редиректы, canonical в HTML, robots/noindex, внутренние ссылки и включение в sitemap. А выбранный Google канонический URL нужно брать из Search Console — сам краулер решение Google не определяет.

Для массива адресов удобно объединить выгрузку обхода с URL Inspection API по исходному URL: userCanonical, googleCanonical, lastCrawlTime и статус индексирования. Важно: API показывает данные версии в индексе, а не результат проверки живой страницы, поэтому дату обхода надо сохранять: https://developers.google.com/webmaster-tools/v1/urlInspection.index/inspect.

В итоговой таблице я бы держал ещё ожидаемый canonical и причину расхождения. «Проверка ответа сервера» Яндекса полезна для диагностики ответа роботу, но сама по себе не подтверждает, какой адрес Яндекс в итоге оставил в поиске. Для приёмки редизайна стоит отдельно фиксировать корректность сигналов на релизе и результат повторной обработки поисковиком — сроки последнего подрядчик гарантировать не может.

Олег, спасибо за дополнение! Для публичных страниц, которые должны находиться и цитироваться, я бы действительно не делал клиентский JS единственным способом получить основной контент. Но критерий - содержательный исходный HTML, а не обязательный выбор только между SSR и SSG. Подойдут и обычные серверные шаблоны, и пререндеринг, и гибрид: основной текст и ссылки приходят с сервера, интерактивность добавляется после гидратации. CSR можно оставить для личного кабинета, корзины и других частей, которым не нужна поисковая видимость.

При этом «все ИИ-боты вообще не выполняют JS» я бы не превращал в универсальное правило. Исследование Vercel/MERJ, опубликованное 17 декабря 2024 года, подтверждало отсутствие рендеринга у изученных краулеров, но это наблюдение конкретного периода, а не неизменная спецификация всех способов доступа к вебу: https://vercel.com/blog/the-rise-of-the-ai-crawler. Поисковый краулер, загрузка по запросу пользователя и браузерный агент - разные сценарии.

Поэтому для AEO мой практический ориентир такой: проверить, что без JS в HTML уже есть ответ на запрос, характеристики и обычные ссылки. SSR/SSG помогают обеспечить доступность контента, но сами по себе не гарантируют цитирование.

Я делюсь полезной информацией. К чему здесь подобные выражения?

Спасибо! Приятно, что вы отметили фокус на first-party data, без этого в эпоху AI-поиска строить долгосрочную стратегию очень сложно)

Всё, что касается технички и автоматизации: автотесты для SEO (проверка тегов, статус-кодов, микроразметки в CI/CD), кастомные скрипты для анализа логов, парсеры данных и генераторы Schema.org

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