Поднимаю отдельный тред про самый недооценённый слой Google - технику и индексацию. Тут нет магических бустеров позиций. Тут гейты: попадёт ли страница в индекс, в какой serving-tier она ляжет, как часто её будут переобходить и не словит ли она тихий демоушен. Контент и ссылки можно вылизать до блеска, но если документ сидит в нижнем тире или его краулер по факту не видит - вся остальная работа уходит в пустоту.
Откуда вообще цифрыДисклеймер. Всё ниже - реконструкция по утечке Content Warehouse (май 2024), по материалам суда DOJ против Google и по патентам краулинга. Это не официальная формула ранжирования. Имена полей реальны (они из слитой API-документации), но интерпретации storage-уровней и часть выводов - это консенсус SEO-сообщества, а не подтверждение Google. Где спорно - помечаю.
Коротко по источникам, чтобы был контекст уровня доверия.
Код: Выделить всё
Источник Что это Уровень
--------- ---------------------------------- ------------------
LEAK Content Warehouse API docs, имена полей точны,
случайно опубликованы ботом смысл - реконструкция
yoshi-code-bot ~13.03.2024,
публичны до 07.05.2024;
~2500 страниц, 14014 атрибутов,
2596 модулей
COURT Показания и документы DOJ v. высокий, под присягой
Google, remedies-фаза апр-май 2025
PATENT Патенты Google по краулингу механика описана,
применение в проде - ?
QRG Quality Rater Guidelines официально, но это
не сама формула
Тиры индекса: Base, Zeppelins, Landfills
Это центральная находка утечки по нашей теме. Раньше Google публично никогда не говорил, что индекс многоуровневый. А он многоуровневый.
Что нашли в полях
Код: Выделить всё
Поле Где Смысл
--------------------------------- ------------ ---------------------------
CompositeDocIndexingInfo CompositeDoc тир, в который попал
.selectionTierRank документ
PerDocData PerDoc нормализованный по языку
.scaledSelectionTierRank ранг 0..1 внутри иерархии
качества индекса
Код: Выделить всё
Тир Качество Интерпретация storage (King/iPullRank, НЕ Google)
---------- --------- -------------------------------------------------
Base высокое быстрая память/flash; топ-контент, частый
переобход, максимальный приоритет показа
Zeppelins среднее SSD; средняя важность и свежесть
Landfills низкое HDD; редко обновляемое и второсортное
Раскладывает документы по тирам система, которую в материалах называют SegIndexer (segment indexer). Решение принимается по сигналам качества. Практический смысл жёсткий: страница в Landfills практически не показывается по сколько-нибудь важным запросам - даже если контент объективно отличный. Тир - это потолок видимости, который накрывает всё остальное.Жирная граница вывода. Маппинг тиров на типы носителей (flash / SSD / HDD) - это интерпретация Майка Кинга (iPullRank), а не подтверждение Google. Сам факт трёх тиров и поля scaledSelectionTierRank - из утечки, это твёрдо. А вот storage-механика - гипотеза. Не продавайте клиенту "переедем со шпинделя на флеш" как услугу.
Ещё один момент, который любят SEO-аналитики: ссылки с документов из верхних тиров (Base) предположительно весят больше, чем ссылки из Landfills. Логично с инженерной точки зрения, но это вывод сообщества, не строка из суда. Держим как гипотезу.
Как этим пользоваться
Прямого рычага "поставь мне tier=Base" нет и быть не может. Но Base-тир - отличная диагностическая цель. Признаки, что страница, вероятно, провалилась в нижний тир
Код: Выделить всё
- "Crawled - currently not indexed" в GSC (висит, но не в индексе)
- стабильно почти нулевые показы по нормальным запросам
- тонкий контент, дубли, near-duplicate шаблоны
- слабый внутренний линк (страница-сирота) и ноль внешних ссылок
- общий низкий авторитет хоста
Краул-частота: качество, популярность, spam score
Тут утечка красиво стыкуется с судом. На процессе DOJ всплыли два фундаментальных топ-сигнала ранжирования: Q (quality) и P (popularity). И эти же сигналы, по показаниям, влияют на то, как часто Google переобходит страницу ради свежести индекса.
Код: Выделить всё
Сигнал Эффект на краул-частоту Источник
--------------- --------------------------- --------------
Quality (Q*) выше качество -> чаще обход COURT
Popularity (P*) популярнее -> чаще обход COURT
Spam score выше спам -> ниже приоритет COURT
переобхода
URL-pattern crawl period (changerate prior)
Отдельная тонкость из поля CrawlerChangerateUrlChangerate.patternBasedChangePeriod (и patternBasedPriorPeriod). Частота обхода берётся не только из истории конкретного URL, а ещё из байесовского prior по URL-паттерну. URL, похожие на новости, краулятся чаще; статичные - реже.
Гейты индексируемости: что выбивает страницу из индексаПрактика: держите предсказуемую URL-структуру. /news/2026/06/slug читается как регулярно обновляемый паттерн, а /p?id=84713 - нет. И не мешайте в одном паттерне часто меняющиеся и статичные страницы - вы размываете prior.
Это раздел "тихих убийц". Тут одна строчка в шаблоне может стереть страницу из индекса без явной ошибки в Coverage.
Код: Выделить всё
Поле / директива Эффект ID
--------------------------------- ----------------------------- ---------
WWWDocInfo.seenNoindex полное исключение из индекса F-TECH-010
+ HopPageNoIndexInfo noindex учитывается на КАЖДОМ
хопе редиректа
WWWDocInfo.isRoboted robots.txt disallow -> статус F-TECH-011
(crawlStatus=ROBOTED) ROBOTED, краул стоп; URL всё
равно может попасть в индекс
без сниппета
TrawlerFetchStatus.State URL_CRAWLED / URL_ROBOTED / F-TECH-015
URL_ERROR; только URL_CRAWLED
ведёт к нормальной индексации
CompositeDocIndexingInfo.errorType soft 404: страница с кодом 200 F-TECH-017
помечается как error page по
контенту, а не по HTTP-коду
IndexingConverterRobotsInfo unavailable_after: после даты F-TECH-037
.contentExpiry показ в SERP прекращается
И про редиректы: noindex проверяется на каждом хопе цепочки. Один лишний noindex на промежуточном 301 - и важная страница тихо выпадает.
Краул-здоровье и экспоненциальный backoff
Это патентная механика (PATENT5), и она объясняет, почему "у нас полежал сервер пару дней" аукается неделями.
Код: Выделить всё
Статус ресурса Что значит Источник
----------------- --------------------------------- --------------
Healthy нормальный обход PATENT5
Temporarily Dead серверные сбои (DNS, таймауты, PATENT5
5xx) - обход приостановлен
Dead ресурс полностью исключён из PATENT5
обхода, индекс не обновляется
Рендеринг, JS и усечение
Код: Выделить всё
Поле Смысл
------------------------------------------- ----------------------------
IndexingEmbeddedContentSelectionResult % контента, доступного ТОЛЬКО
.newTokensPercentageAfterRendering после JS-рендера; высокий % -
риск (зависимость от рендера)
.withMissingResources = true при рендере не подгрузились
JS/CSS/шрифты -> в индекс идёт
ДЕГРАДИРОВАННАЯ версия
TrawlerFetchReplyDataProtocolResponse документ усечён по размеру;
.CutoffSize контент за порогом НЕ
индексируется
AI-слой: FastSearch и Google-Extended
Свежак из суда (remedies-фаза, апрель-май 2025). Для grounding своих моделей Gemini Google использует проприетарную технологию FastSearch на сигналах RankEmbed. Это отдельный, более быстрый, но менее точный retrieval: меньше документов, ниже качество, чем у полного Search. По показаниям он тянет из отдельного content store, не из основного индекса.
Отдельно Google-Extended (поля googleExtendedRobotsStatus / googleExtendedObeyWildcardRobotsStatus) - это управление доступом AI-краулера для обучения моделей, отдельно от основного Googlebot. User-agent: Google-Extended / Disallow: / закрывает контент от AI-продуктов и НЕ роняет основную индексацию. Это editorial/licensing-решение, а не рычаг позиций.Что из этого НЕ следует. Что есть отдельное "AI SEO" в обход обычного ранжирования. RankEmbed - это семантика связи "запрос-контент", и да, многие grounding-URL не совпадают с органикой и наоборот. Но рычаги те же: авторитет, качество, точность, индексируемость, структура. Оптимизация под обычный поиск остаётся базой и для AI Overviews. Гнаться за "AI-формулой" в обход этого - пустая трата.
Чек-лист и чего избегать
Код: Выделить всё
Аудитируй системно
[ ] noindex / robots / redirect-цепочки - проверять КАЖДЫЙ хоп
[ ] 5xx и таймауты - алерты на всплески (экспоненциальный backoff)
[ ] JS/CSS не закрыты от бота (robots, CSP, rate-limit по IP)
[ ] soft 404: 404 для несуществующих, 301 для переездов, 410 для удалённых
[ ] HTTPS/HSTS валидны на ВСЕЙ цепочке редиректов (CDN/прокси тоже)
[ ] interstitials/реклама на мобайле - на уровне шаблона, не лендинга
(нарушение size-level "размазывается" на URL-кластер хоста)
[ ] тонкие URL - резать или noindex, чтобы не топить тир хоста
Кидайте свои кейсы: у кого реально вытаскивали страницы из "crawled - currently not indexed" и за счёт чего сдвигалось - качество, внутренний линк или внешка. Интересно собрать паттерны.