Что изменилось в поиске в H1 2026

Bing начал показывать владельцам сайтов, на какие их страницы ссылаются в ответах ИИ. Google изменил Discover, перестал показывать расширенные результаты FAQ и выпустил отдельные отчёты о показах в ИИ-функциях. Помимо этих заметных изменений, ограничения краулера, навигация в браузере и переезды доменов дали техническим командам много проверок. В этом обзоре изменения с января по июнь связаны с отчётами, страницами и решениями о релизах, на которые они влияют.

Данные

Последовательность, которая повлияла на решения

Порядок важен, потому что события отвечают на разные вопросы. В январе убрали документацию по разметке practice problem в структурированных данных и выпустили рекомендации по Preferred Sources. В феврале вышло региональное обновление Discover Core Update для US-английского и первое публичное превью AI Performance в Bing. В марте окна спам-апдейта и core-апдейта разнесли по времени, а Google объяснил, как Googlebot обрабатывает ответы. В апреле завершилась раскатка core-апдейта, а в спам-политику добавили перехват кнопки «Назад». В мае отказались от вывода FAQ-результатов и опубликовали рекомендации по генеративному ИИ. В июне добавили отчёты по ИИ в Search Console, уточнили миграцию, расширили представления Bing AI и ввели почасовые данные в мониторинге запросов Яндекса.

Такой порядок также защищает от ошибок категоризации. Издатель может сразу исправить ошибку ответа краулеру, даже если она случилась во время core-апдейта. Отказ от функции требует решения по шаблону и контенту, а запуск отчёта — определения метрики. Ставьте событие рядом с доказательствами по затронутой странице, а не в общую колонку «алгоритмическое обновление».

Изменение продукта

Discover и Preferred Sources

Февральский Discover Core Update от Google начался с охвата US-английского и рекомендаций о локальной релевантности, своевременной оригинальной экспертизе и менее сенсационном контенте. Поэтому первый вопрос к проверке — географический и редакционный: попала ли затронутая аудитория, язык и формат в задокументированную поверхность? Движение Discover вне этого контекста не доказывает, что общий шаблон страницы нужно менять. Прежде чем считать показы универсальным сигналом ранжирования, проверьте географические признаки контента, тематическую экспертизу, время публикации и фактический отчёт Discover.

Preferred Sources шёл по другому пути. Google задокументировал функцию в январе, в апреле расширил её на все языки Поиска, а в мае добавил в описанный охват AI Overviews и AI Mode — это зафиксировано в документации обновлений. Издатели могут разместить кнопку или ссылку, которая помогает читателям выбрать их как предпочтительный источник. Выбор делает читатель: разметка schema.org сделать его за читателя не может. Дайте вернувшимся читателям понятную идентичность издания и удобный способ выбрать его.

Практическая проверка Discover начинается с самого контента: подтвердите видимую дату, тему, локальную релевантность и оригинальную подачу или анализ. Затем сравните страну и язык затронутой аудитории с опубликованным охватом функции. Если сайт работает на нескольких рынках, не объясняйте обновление с US-английским охватом изменениями на каждой локали. Редакционные улучшения привязывайте к той аудитории, которая реально может увидеть эту поверхность.

Изменение продукта

Отчёты по ИИ: держите поверхности раздельно

В феврале Bing AI Performance представил отчётность о цитировании. В июньском расширении добавили Intents, Topics, Citation Share и Compare — см. следующий релиз Bing. Эти отчёты помогают владельцу разобраться, как ИИ-интерфейсы Bing цитируют страницы. Они не заменяют сессии, позиции в Google или измерение AI Overviews. Их вопрос — видимость в цитировании в рамках поверхности отчёта, которую задаёт Bing.

Июньский анонс отчётов Search Console по ИИ от Google добавил отдельные представления показов в генеративных ИИ-функциях Поиска и Discover. Эти показы по-прежнему учитываются и в общей отчётности по эффективности; отдельные представления сначала открылись только части сайтов. Яндекс добавил почасовые данные «Мониторинга запросов» — это другой тип отчёта для популярных поисковых запросов. Держите эти продукты раздельно по платформе, единице измерения и окну отчётности. Если складывать клики, цитирования и предварительные почасовые значения, станет неясно, что на самом деле измеряет каждый отчёт.

zoom_in

Для дашборда сначала определите строку, и только потом выгружайте данные. Одна строка может означать клики в Google Search Console по группе URL, другая — цитирования в Bing по теме, третья — почасовые наблюдения запросов в Яндексе. У каждой строки должны быть свой ресурс или рынок, диапазон дат и часовой пояс. Так не возникает соблазна строить гладкий график из показателей, которые никогда не предназначались для сложения.

Действие

Обработка краулером и граница в 2 МБ

Мартовское объяснение Google о краулере сделало старое, но легко пропускаемое ограничение рабочим: Googlebot обрабатывает ограниченный объём содержимого ответа, а для HTML-ответа есть практическая граница в два мегабайта. Вывод не в том, чтобы считать размер бандла и остановиться. Проверьте фактический статус, конечный URL, тело ответа, тег canonical и критичное содержимое в HTML после рендеринга. Если важные инструкции или текст приходят слишком поздно, просмотр страницы в браузере на быстром соединении может скрыть проблему.

Для крупного JavaScript-маршрута возьмите один основной URL и сохраните необработанные заголовки ответа и байты. Затем сравните, что приходит в исходном HTML, и что появляется после рендеринга: основной контент, тег canonical, директивы для роботов, структурированные данные и ссылки на следующие значимые страницы. Некритичную нагрузку выносите из критического пути, если это подтверждают данные, но не удаляйте контент просто ради числа в байтах. Условие приёмки — чтобы смысл обязательной страницы оставался доступным и отрисовываемым в практических ограничениях краулера.

zoom_in

Граница в два мегабайта особенно важна, когда шаблон отдаёт большие сериализованные данные, навигационные данные или дублирующуюся разметку раньше основного содержимого. Ищите стоимость в байтах в возвращаемом документе, а не только в результатах сборки JavaScript. Если canonical или текст страницы подставляются на клиенте после длинной цепочки операций, сделайте эту зависимость явной и проверьте её с теми же параметрами маршрута, которые может запросить краулер.

Действие

Раскатка спам-апдейта и перехват кнопки «Назад»

Мартовский спам-апдейт шёл с 24 по 25 марта. Мартовский core-апдейт стартовал 27 марта и завершился в апреле. В расследовании эти окна нужно держать раздельно. Страница, которая потеряла клики в любом из этих периодов, может иметь техническую поломку, изменение спроса на запросы, проблему с canonical, перестановку у конкурентов или более общую проблему качества. Календарь сам по себе не выбирает между ними.

13 апреля Google добавил перехват кнопки «Назад» как явное нарушение спам-политики; применение объявлено с 15 июня. Этот срок стоит внести в календарь релизов. Это конкретное поведение браузера, которое нужно проверить: после перехода из выдачи нажатие «Назад» должно возвращать посетителя на предыдущую страницу, а не удерживать его в неожиданной цепочке навигации. Проверьте это в чистой сессии браузера и на мобильном, а не только на десктопе, затем изучите редиректы, манипуляции с историей и внедрённые скрипты. Убирайте сам механизм, а не маскируйте его поверхностным изменением посадочной страницы.

Разница между изменением политики и окнами апдейтов важна при разборе. Перехват кнопки «Назад» — воспроизводимый дефект взаимодействия, и его тест даёт понятный результат «пройдено» или «провалено». Пересечение с core-апдейтом — это контекст расследования, поэтому его нужно разбирать по сегментам. Ведите эти направления раздельно: явную подмену навигации исправляйте сразу, а решение о более широком пересмотре контента принимайте после данных по запросам и страницам.

Действие

План миграции должен учитывать все варианты хоста

В июньских рекомендациях по переезду сайта Google явно указал, что инструкции Change of Address относятся ко всем вариантам домена. Это меняет инвентаризацию миграции: корневой хост, www и любой значимый поддомен должны иметь заявленный конечный адрес, а не подразумеваемое соглашение. Карта редиректов, которая покрывает только один предпочтительный хост, может оставить дубли, битые или непроверенные варианты доступными пользователям и краулерам.

Соберите тестовый набор до переключения трафика. Для каждого живого старого URL зафиксируйте запланированный конечный URL, один прямой постоянный редирект, финальный статус, canonical, наличие в sitemap и критичный контент после рендеринга. Затем повторите проверку через каждый публичный вариант хоста. Обновите внутренние ссылки, теги canonical и sitemap на финальный хост; не полагайтесь на цепочки, которые исправляют старые соглашения. Если у URL нет подходящего преемника, верните соответствующий ответ «не найдено», а не отправляйте на главную.

Проверка вариантов хоста должна учитывать протокол, а не только имя хоста: корневой HTTP, корневой HTTPS, HTTP www и HTTPS www, если эти варианты открываются публично. Миграции чаще всего ломаются по краям: изображение или цель hreflang может сохранить старый хост, а старый поддомен может обойти редирект. Короткая машиночитаемая карта соответствий плюс проверки в браузере дают и краулерам, и людям один финальный адрес.

Изменение продукта

Отказ от FAQ и более узкое изменение данных о товарах

В мае появились два очень разных решения по поддержке структурированных данных. Google перестал показывать расширенные результаты FAQ с 7 мая — это зафиксировано в документации обновлений. Видимый FAQ по-прежнему отвечает на вопросы клиента, но валидная разметка больше не означает, что этот вид результата в Поиске вернётся. Оставляйте вопросы для читателя там, где они полезны. Реализацию, нужную только для функции, удаляйте после проверки шаблонов, аналитики и зависимостей доступности.

В тех же майских обновлениях в документацию по товарам и Merchant добавили hasAdultConsideration. Это узко заданное поле для записей, где факт точен и отражён правдиво. Это не общее улучшение товарного фида, и его не стоит добавлять ради попытки получить функцию. Общее правило: сохраняйте семантические данные, которые соответствуют видимой странице, валидируйте граф и отдельно — целевого потребителя, а обещания о виде результата, который продукт больше не выдаёт, убирайте.

Для FAQ проверьте видимые вопросы на десктопе и мобильном, затем спросите себя, снимает ли каждый ответ реальный вопрос перед покупкой или в поддержке. Если да, контент может остаться без стимула в виде расширенного результата. Для поля hasAdultConsideration требуйте фактического источника в карточке каталога и видимого отображения там, где это уместно. Так комплаенс-поле не превратится в спекулятивный SEO-флаг.

Действие

Конкретные проверки к следующему обзору

В следующем обзоре создавайте по одной таблице доказательств на каждую поверхность, а не одну общую оценку. Для Discover фиксируйте страну, язык, формат и соответствующий отчёт. Для видимости в ИИ сохраняйте платформу, название отчёта, даты, единицу измерения и атрибуцию. Для работы со сканированием сохраняйте заголовки ответа, размер тела, критичный контент после рендеринга, canonical и состояние robots. Для миграций сохраняйте все входные хосты и карту маршрутов. Для схемы сохраняйте видимый факт, проверку графа и текущую политику функции. Такие записи позволяют объяснить будущее изменение без выдуманной причинно-следственной истории.

• Для Discover сравнивайте затронутую страну и формат контента с опубликованным охватом продукта, прежде чем менять редакционные шаблоны.
• Для отчётов Google, Bing и Яндекса ведите отдельные таблицы: никогда не складывайте цитирования, клики Search Console и почасовые наблюдения запросов.
• Для тяжёлого маршрута фиксируйте размер ответа и критичный контент после рендеринга до и после любого изменения производительности.
• Для миграции проверяйте корневой хост, www и каждый публичный поддомен по карте редиректов, тегам canonical, sitemap и отрисованной странице.
• Для структурированных данных отделяйте видимую информацию, которая остаётся полезной, от формата расширенного результата, который Google отключил.
• Для любого окна раскатки сначала изучите данные по запросам, посадочным страницам и техническое состояние, и только потом называйте причину апдейта.