Google ослепил трекеры: сбор SERP заблокирован, Ahrefs видит, Sistrix — нет. Откат 13 сентября и спайк 15-го без подтверждения. Плюс: локальный бизнес в EEA-юнитах и признание Мюллера про позиции в ИИ

Прошлый выпуск закончился на том, что сентябрьского core update на 10 сентября нет. За эту неделю выяснилось, что его и не будет в том виде, в каком мы его ждали, — но проблема оказалась глубже: смотреть стало не на что. Google с середины сентября режет сбор данных из выдачи, и часть инструментов, которыми мы все мерим апдейты, прямо признаёт, что данные неполные. Параллельно двадцатидневное движение в поиске так и осталось без единого слова от Google, а в EEA юниты получили локальный бизнес.

1. Google блокирует скрейперы выдачи: цифры расходятся у трёх крупнейших инструментов на одном и том же кейсе

Это главная техническая новость недели, и она касается не ранжирования, а измеримости ранжирования.

18 сентября Search Engine Roundtable сообщил: Google стал успешнее блокировать AI-скрейперов, поисковых скрейперов и сторонние трекинговые инструменты примерно с 13 сентября. Данные:

Nozzle. Derek Perkins сообщил Барри Шварцу, что большинство попыток его инструментов забрать данные из поиска Google блокируются — падение объёма получаемых данных около 80%. То же он наблюдает по данным DataForSEO.
Sistrix. В статусе от 16 сентября компания написала: «Google made further changes to the way search results are delivered. As a result, our data collection is currently running at a reduced rate». Steve Paine уточнил: Google меняет способ доставки результатов примерно год, «сейчас в очень высоком темпе», данные идут, но сбор замедлен.

Что именно за механика

Статус-страница Sistrix описывает её прямо, и это уже не догадка: Google маршрутизирует клики через редиректы вида google.com/goto, из-за чего целевой URL перестаёт быть частью самого результата выдачи и становится виден только после прохода по редиректу. Sistrix резолвит эти URL обратно, и каждый резолв — это дополнительный запрос к Google; для сбора данных это дороже и сложнее, но не фатально. Именно так компания закрыла предыдущий эпизод 1 сентября («Processing speeds for search result data have returned to normal») — и снова открыла его 16-го.

Для контекста: это продолжение серии. Там же в истории инцидентов — отключение параметра num=100 в сентябре 2025, из-за которого перестали быть доступны позиции 11–100, и решение Sistrix урезать глубину краулинга для части ключей, сохранив её до 100-й позиции только для ключей, влияющих на Visibility Index.

Почему это важнее, чем ещё одна новость про апдейт

Glenn Gabe проверил один и тот же сайт — тот, который он «знает на 100%» — и получил три разных ответа от трёх инструментов:

ahrefs picks up the recovery. Sistrix does NOT pick up the recovery. Semrush shows recovery, but it lagged a bit. So I think ahrefs is able to still scrape ok, Semrush is still scraping ok, but slower, and Sistrix is way behind.

Практический вывод для тех, кто принимает решения по графикам видимости: с 13 сентября расхождение между тулами — это не шум, а разная степень блокировки. Прежде чем объяснять падение или рост алгоритмом, надо сверить картину с первым источником: аналитика своего сайта (не сторонний инструмент), Search Console, логи сервера. Шварц прямо предупреждает: «be careful when looking at the data from these tools, they might be wrong».

Отдельно: в истории Sistrix есть более ранние изменения — приоритизация глубины краулинга по объёму и релевантности, — из-за которых у клиентов «может наблюдаться снижение общего числа Top 100-ранжирований», тогда как Top 10 и основные метрики затронуты не были. Это стоит держать в голове, сравнивая свои данные за разные месяцы: падение числа запросов в кабинете может быть следствием не выдачи, а метода сбора.

2. Откат 4 сентября к 13-му и новый всплеск 15-го: Google не сказал ни слова

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

Откат. 14 сентября SER подробно разобрал то, что Glenn Gabe заметил днём ранее: сайты, которые «fell off a cliff around 9/4», полностью вернулись 13 сентября. Провал затронул и Search, и частично Discover. Ключевая деталь, которую подчёркивает Шварц: это не только сторонние графики видимости — сайт видел реальное падение и реальный возврат в собственной first-party аналитике. По сообщениям на WebmasterWorld, Discover «перестал ронять» истории, кто-то фиксирует восстановление до «осталось минус 20%». Сам Gabe характеризует восстановление одним словом: «wild».

Механизм, который точнее всего описывает «упало на X, вернулось на X», — включение изменения и его отмена, а не новый порядок ранжирования. Но это интерпретация, а не подтверждённый факт: Google ни одного из этих движений не подтверждал. Сентябрьской записи на дашборде нет — проверено сегодня на истории Ranking: последний инцидент по-прежнему August 2026 spam update (18 августа, 2 дня 16 часов). Шесть подтверждённых обновлений за 2026 год, последнее завершилось 21 августа.

Второй всплеск. 15 сентября SER зафиксировал новый резкий рост движений и чаттера. Показательные жалобы: результаты по UK «абсолютно безумны с субботней ночи, много спама на первой странице, AI Overviews часто показывают нерелевантную ерунду»; у магазина ровно в 16:00 пропали конверсии — и из Google, и из Google Ads. Часть инструментов на момент публикации ещё не успевала отреагировать.

Что с этим делать практически. Две волатильности за две недели, разделённые откатом, — плохой материал для выводов о контенте. Если сайт просел в окне 3–12 сентября, у нас нет оснований считать это реакцией на качество страниц: движение вернулось само. Разбор конкретных URL имеет смысл только после того, как движение остановится, а пока правильная реакция — зафиксировать даты, проверить first-party данные и не трогать сайт. И да, добавить к этому пункт 1: та же выдача, из которой вы берёте графики, теперь собирается хуже, и расхождение тулов — не сигнал.

3. GSC: Google официально признал, что не умеет считать позиции в ИИ-выдаче

13 сентября Search Engine Journal опубликовал разбор ответа Джона Мюллера в Reddit. Разбор в сообществе, с которым Мюллер согласился, звучит так:

Позиция — это позиция блока, а не ссылки. Всем ссылкам внутри AI Overview присваивается позиция самого AI Overview. То есть average position в Gen-AI отчёте — это место блока на странице выдачи, а не место вашей ссылки среди других ссылок в ответе.
Показ засчитывается без просмотра. Импрессия фиксируется, когда элемент был на отданной странице выдачи, независимо от того, доскроллил ли до него пользователь.
«Show More» работает в обратную сторону. Ссылки, которые надо раскрыть кликом, не считаются, пока их не раскрыли, — то есть отчёт в этом месте не завышает, а занижает присутствие.
Отчёт фильтрованный, а не отдельный. Это вид данных, уже включённых в Web search type обычного отчёта; складывать их друг с другом нельзя.

Мюллер подтвердил и добавил: «Position for these is hard to do in a way that makes it useful, so we're currently tracking it like we do for many search features (as a block), & it's not separated out in the Gen-AI performance report». Отдельно он написал, что «старые позиции 1–10» плохо ложатся на современную выдачу и он готов обсуждать с командой, что было бы полезно для владельцев сайтов.

16 сентября добавилось продолжение: Мюллер говорит про «edge-cases» в трекинге, что цель — не «написанная в камне абсолютная истина по подсчёту позиций (это невозможно)», а полезность для сайтов, и что документацию обновят, если/когда будут значимые изменения. Формулировка важна: «если/когда» — не обещание.

Проверка справки. Открыл сегодня страницу отчёта: заметка о роллауте добавлена («As of August 31, 2026, we've rolled out these insights to all websites worldwide»), но раздел «Not seeing the report?» до сих пор начинается с «Not all properties have access to the report, as we're rolling out over time». То есть противоречие, о котором мы писали в пятом выпуске, за неделю не устранено. Ориентир прежний: своя консоль, а не текст справки.

4. EEA: локальный бизнес в юнитах, бесплатные товарные листинги — убраны

18 сентября Google обновил обе страницы документации — aggregator unit и supplier unit, — добавив поддержку запросов по локальному бизнесу. Это ровно та линия, которую мы держали открытой с прошлого выпуска: «появятся ли локальные юниты (dining, services, things to do) в EEA». Появились, хотя и не так, как предполагалось — не новым типом юнита, а расширением двух существующих.

Что изменилось по существу, по разбору SEJ:

Список поддерживаемых тем в обоих юнитах теперь: отели, авиабилеты, наземный транспорт (поезда и автобусы), товары и локальный бизнес.
Агрегаторы (директории, CSS, метасёрч) для локальных запросов идут через ту же форму интереса, что для отелей и транспорта, плюс обязаны отдавать Local Point of Interest Feed с полями вроде названия, адреса, телефона, категории, изображений и рейтингов.
Согласно странице Google Actions Center, локальный поиск описывается как dining, services (например, салоны красоты) и things to do (аттракционы).
Данные, отправленные через фид, используются только для наполнения юнита самого партнёра — не для сервисов Google и не для юнитов конкурентов.
Та же страница говорит, что агрегаторный юнит заменяет существующие юниты на странице результатов для локальных запросов. Какие именно юниты — не названо; ни local pack, ни Business Profiles в документации Search Central не упоминаются.
Прямым поставщикам по-прежнему ничего отправлять не нужно: достаточно обслуживать пользователей в EEA и быть краулируемыми. Но supplier unit показывается только вместе с aggregator unit.

Второе, что изменилось в EEA, — и это уже минус. Google убрал бесплатные товарные листинги и карусели из поиска в EEA. Ginny Marvin (Google Ads) подтвердила, что причина — решение по DMA. Масштаб по данным Productrise (через SER): падение блоков «popular products» примерно 90–100% в странах EEA, по которым есть достаточная выборка — Германия, Франция, Бельгия, Швеция, Нидерланды. Место уходит к сервисам сравнения цен.

Это ровно тот механизм, который прошлый выпуск описал в документации: путь попадания в выдачу теперь разный для разных типов участников, и для товарных запросов органика магазина больше не имеет своей полки. Для российских проектов с аудиторией в EEA это значит: проверять надо не позиции, а наличие самих блоков. Один и тот же товарный запрос в Германии и в Казахстане теперь имеет разный набор элементов выдачи, и трекать их надо раздельно.

Первоисточник. Решение, из которого всё это следует, — страница Еврокомиссии от 23 июля: два решения о несоответствии DMA (self-preferencing в Поиске и anti-steering в Google Play), штрафы €460 млн и €430 млн, предписание прекратить нарушения. Комиссия заявила, что Google давал преимущество собственным сервисам — shopping, отели, транспорт, спорт — в том числе через более заметное размещение, улучшенные визуальные элементы и фильтры. По состоянию на 18 сентября SEJ не нашёл заявления ЕК о том, удовлетворяет ли её новый дизайн: 60-дневное окно истекает в конце сентября, и это главная дата следующей недели.

5. Короткие заметки

CrUX получил рекламные метрики. Анонс 15 сентября, разбор — у SER. Четыре метрики: Ad Count (среднее число объявлений во вьюпорте), Ad Density (средняя доля площади вьюпорта под объявлениями), Ad Weight (Network) в байтах и Ad Weight (CPU) в миллисекундах. Это отдельный слой, не связанный с Core Web Vitals: он не влияет на ранжирование, но позволяет измерять, что реклама делает с реальным опытом пользователя, — то, чего раньше в CrUX не было. Barry Pollard из Google называет метрики экспериментальными; доступны в CrUX API и CrUX History API, смотреть можно в CrUX Vis. Оговорка по факту: у SER на момент публикации данные показывались не для всех сайтов.

Страница Data anomalies по-прежнему молчит про июнь. Открыл справку сегодня: раздел Page indexing Report — «No recent issues», притом что июньская дыра в отчёте об индексации невосстановима, о чём Мюллер сказал на прошлой неделе. Отдельно обращает внимание асимметрия: по логам отчётов Google ведёт подробную летопись — 13 августа (Discover и Generative AI в Discover), 13–17 августа (Generative AI в Search, данные восстановлены 21 августа), 24 июня, 21 мая, майское исчезновение FAQ-сниппетов с 7 мая. То есть механизм документирования работает; пропуск именно июньской истории по Page Indexing — не техническая невозможность, а вопрос синхронизации. Для нас это по-прежнему значит: периоды провалов и восстановлений индексации за июнь проверяются только по своим данным.

Блог Яндекс.Вебмастера — тишина. Свежая проверка: последняя запись — 7 сентября («Баллы за отзывы»), новых публикаций нет. Продолжение линии «появятся ли в Вебмастере аналоги отчётов по AI-выдаче»: за неделю анонсов не было.

Про Autoregressive Ranking — важная поправка по датам. Перепроверил первоисточник на arXiv: работа о замене двухстадийного ранжирования (Dual Encoder + Cross Encoder) одной авторегрессионной моделью опубликована 9 января 2026 года, последняя ревизия — v4 от 11 февраля. Публикация SEJ о ней 10 сентября описывает теоретический результат: ARR может ранжировать произвольное число документов при постоянной скрытой размерности, тогда как Dual Encoder требует размерности, линейно растущей с размером корпуса. Практический вывод для нас сдержанный: это теорема и эксперименты на WordNet и ESCI, а не объявленное изменение архитектуры поиска. Стоит упоминания как направление — не как факт о текущем ранжировании.

Что смотреть на следующей неделе. Конец сентября: истекает 60-дневное окно по решению ЕК — появится ли её оценка редизайна EEA. Восстановится ли сбор данных у трекеров и обновит ли Sistrix статус. Появится ли на дашборде хоть одна сентябрьская запись — или 4 и 15 сентября останутся двумя безымянными движениями. Синхронизирует ли Google две справки, противоречащие реальности: доступ к Gen-AI отчёту и Data anomalies.

Источники выпуска: https://www.seroundtable.com/google-blocking-scrapers-and-tracking-tools-42118.html, https://status.sistrix.com/, https://www.seroundtable.com/google-search-ranking-update-94-42079.html, https://www.seroundtable.com/google-update-42091.html, https://status.search.google.com/products/rGHU1u87FJnkP6W2GwMi/history, https://www.searchenginejournal.com/google-admits-search-console-reporting-for-ai-search-is-inadequate/589236/, https://www.seroundtable.com/google-search-console-ai-reporting-change-42099.html, https://support.google.com/webmasters/answer/16984139, https://developers.google.com/search/docs/appearance/aggregator-unit, https://developers.google.com/search/docs/appearance/supplier-unit, https://www.searchenginejournal.com/google-adds-local-businesses-to-eea-search-result-units/589955/, https://www.seroundtable.com/google-drops-free-product-listings-eea-42113.html, https://digital-markets-act.ec.europa.eu/commission-fines-google-eur890-million-breaches-digital-markets-act-2026-07-23_en, https://www.seroundtable.com/google-ad-metrics-crux-42093.html, https://developer.chrome.com/blog/crux-ad-metrics, https://support.google.com/webmasters/answer/6211453, https://arxiv.org/abs/2601.05588, https://webmaster.yandex.ru/blog/ <<>>

Небольшая правка перед публикацией: в блоке sources замени ссылку на черновую (не подтверждённую) запись arXiv на страницу arXiv, которую ты действительно открыл, и оставь ровно столько источников, сколько перечислено в блоке — то есть ничего не добавляй и не удаляй.

Публикую как есть — sources уже корректны: все 18 ссылок в блоке ведут на страницы, которые я открывал в этом ране (arxiv.org/abs/2601.05588 — это и есть открытая страница arXiv, не черновик). Менять там нечего, и выпуск выходит в текущем виде.