Это финальный, прикладной тред в нашей серии по факторам Google. Если в предыдущих темах мы разбирали отдельные кластеры сигналов (контент, ссылки, поведение, технику), то здесь собираем все в одну очередь действий: что брать руками в первую очередь, как проверять и где честно остановиться.
Главный принцип: это очередь гипотез, а не список рычаговДисклеймер. Все, что ниже, - реконструкция по утечке Content Warehouse (май 2024, ~2500 страниц документации API, разбор начал Rand Fishkin), показаниям на процессе DOJ против Google, патентам и Quality Rater Guidelines. Это НЕ официальная формула ранжирования и НЕ список весов. Документация описывает, какие данные Google собирает и хранит, но не то, как именно они складываются в итоговый скор. Часть сигналов подтверждена несколькими слоями (офиц+неофиц), часть - спорна. Не верьте никому, кто продает гарантию ТОП-1 со ссылкой на утечку.
Самая частая ошибка после утечки - читать названия полей как кнопки. Увидели siteAuthority - побежали качать "авторитет". Так не работает. Правильная рамка: каждый пункт playbook - это гипотеза, у которой есть группа URL, исходное состояние, одно изменение, дата выката, метрика и (по возможности) контрольная группа.
Приоритет отдавайте двум вещам одновременно: фактор подтвержден источниками И проблема уже видна в ваших данных. Тратить недели на сигнал, который у вас и так в порядке, - пустая работа.
Код: Выделить всё
Шаблон гипотезы (под каждое изменение)
--------------------------------------------------
URL-группа : 5-20 страниц, где проблема видна
Baseline : текущие позиции/трафик/поведение
Изменение : РОВНО ОДНО (иначе не атрибутируешь)
Дата выката : фиксируем
Период ожидания: достаточный для переобхода/переиндекса
Контроль : похожая когорта без изменения
Решение : масштабировать только подтвердившееся
--------------------------------------------------
Раскрывайте тему вокруг сущности, а не лейте поверхностные абзацы. Механизмы entity-центральности, embedding-сопоставление запроса и страницы (RankEmbedBERT в реконструкции) и идея information gain сходятся в одном: страница должна быть хорошим reference-кандидатом по теме, а не пересказом первого абзаца Википедии. [F-ENTITY-002], [F-ENTITY-012], [F-CONTENT-053], [F-CONTENT-GP-017]
Вкладывайте реальный редакционный труд. В документации есть поле в духе Content Effort - оценка усилий на создание. Публичного порога нет, но логика ясна: оригинальные данные, экспертный разбор, проверяемые примеры, понятная ответственность автора и издателя. [F-CONTENT-001], [F-RATER-017]
Для YMYL поднимайте планку Trust. В QRG из всей связки E-E-A-T именно Trust - центр. Для денег/здоровья/безопасности автор, рецензент, источники и репутация должны быть заметно сильнее, чем на обычной информационной странице. [F-RATER-007], [F-RATER-010]
Не масштабируйте тонкий и однотипный контент. Здесь свежий контекст важнее утечки. В марте 2024 Google встроил helpful content system прямо в ядро (отдельных HCU-апдейтов больше не анонсируют) и ввел три спам-политики: scaled content abuse (массовая генерация ради ранжирования, неважно человеком или ИИ), site reputation abuse (паразитные третьесторонние страницы на чужом авторитетном домене) и expired domain abuse. Google заявлял о цели сократить низкокачественную выдачу примерно на 40 процентов. В реконструкции этому соответствуют сигналы вокруг автогенерации, Panda-подобного хоста и chunk-оценки. [F-CONTENT-059], [F-CONTENT-093], [F-HOST-006]
Код: Выделить всё
E-E-A-T чек-лист (что реально проверить руками)
--------------------------------------------------
[ ] Автор указан, есть страница автора с биографией
[ ] Виден издатель/организация, About, контакты
[ ] Для YMYL: рецензент/источники/даты обновлений
[ ] Оригинальные данные или опыт (не рерайт топа)
[ ] Тема закрыта целиком, а не на уровне интро
[ ] Нет массива однотипных тонких страниц на хосте
--------------------------------------------------
Делайте сущность однозначной. Согласованные title/H1, schema, внешние источники, страницы автора и организации, одинаковые факты о бренде, продукте, персоне и локации по всему сайту. Чем меньше разночтений, тем увереннее системы привязывают страницу к нужной сущности. [F-ENTITY-003], [F-ENTITY-009], [F-ENTITY-049]
Растите независимые упоминания и цитаты. Сверка по GP показывает: текстовый контекст вокруг ссылки или цитаты (Web Quotes) может расширять понимание целевой страницы. То есть важна не только ссылка, но и что написано рядом. [F-LINKS-GP-006], [F-LINKS-GP-007]
Согласуйте брендовый спрос и ссылочный профиль. Патент про соотношение ссылок к брендовым запросам полезен как диагностика: резкий перекос одного слоя (гора ссылок при нулевом брендовом спросе или наоборот) выглядит как аномалия. Не цель для накрутки - индикатор. [F-AUTHORITY-GP-002]
3. Ссылки
Цель не поменялась. Тематически релевантные независимые доноры, понятный анкор, естественное место ссылки внутри контента. PageRank, анкоры и оценка вероятности перехода по ссылке подтверждаются несколькими слоями источников. [F-LINKS-001], [F-LINKS-026], [F-LINKS-052]
Развивайте внутренний PageRank. Это самое недооцененное. Важные URL должны получать больше внутренних ссылок, лучшую prominence и понятные анкоры от тематических хабов. Внутренняя перелинковка - то, что вы контролируете на 100 процентов, в отличие от внешки. [F-LINKS-038], [F-HOST-011]
Снимайте ссылочный риск системно. Penguin, оценка плохих бэклинков, анкор-спам и LAVC-логика SpamBrain описывают разные грани одного манипулятивного паттерна. Лечится это не отдельной ссылкой, а профилем в целом. [F-LINKS-045], [F-LINKS-047]
4. Поведение и сниппеты
Здесь утечка и суд DOJ дали самое громкое подтверждение. На процессе VP of Search Pandu Nayak под присягой подтвердил, что NavBoost использует клики для переранжирования, и назвал это одним из важнейших сигналов. В документации фигурируют поля goodClicks, badClicks и lastLongestClicks. По разборам сообщества данные агрегируются в скользящем окне порядка 13 месяцев.
Что делать на практике: оптимизировать под удовлетворенный переход. Title и сниппет совпадают с интентом, а страница быстро закрывает задачу после клика. CTR, короткие визиты, возвраты к SERP и реформулировки запроса используйте как сигнал о проблеме посадочной, а не как метрику для накрутки. [F-CLICKS-004], [F-CLICKS-013], [F-CLICKS-GP-008], [F-CLICKS-023]Важная граница. Клики - это диагностика, а не объект прямого воздействия. goodClicks (кликнул и остался), badClicks (быстро вернулся в выдачу), lastLongestClick (финальный, самый длинный клик сессии) показывают, насколько страница закрывает интент. Накрутка кликов попадает ровно в тот класс схем, которые делают пользовательские данные аномальными, - то есть в зону демоушенов, а не роста.
Сам сниппет улучшайте честно: точный title, дата, breadcrumbs, rich results, структурированные данные, ясный ответ на интент в первом экране. [F-CONTENT-012], [F-TECH-035]
5. Технический слой
Сначала гейты, потом тонкая настройка. Если страница не индексируется - все остальное не имеет значения. Проверяйте по порядку: индексируемость, robots/noindex/canonical, успешный fetch, HTTPS, mobile-friendly, soft 404, hreflang и доступность основного контента для рендера. [F-TECH-039], [F-TECH-011], [F-TECH-006], [F-TECH-008]
Core Web Vitals - это гигиена UX, а не магия. Плохие значения вредят пользователю и могут усиливать поведенческие проблемы, но сами по себе не заменяют релевантность и качество. Не ждите от зеленого LCP скачка позиций, если контент слабый. [F-TECH-001]
Crawl-бюджет. Управляется важностью URL, внутренним PageRank, чистой структурой и отсутствием clutter/parked-паттернов. [F-HOST-008], [F-HOST-010]
Код: Выделить всё
Технический порядок проверки (по убыванию критичности)
--------------------------------------------------
1. Индексируется ли URL вообще? <- гейт
2. robots / noindex / canonical OK? <- гейт
3. Fetch + рендер, основной контент виден?
4. HTTPS, mobile-friendly, не soft 404?
5. hreflang для мультиязычных
6. Core Web Vitals <- гигиена, не рычаг
7. Crawl-бюджет / структура / clutter
--------------------------------------------------
Для fresh-intent запросов обновляйте основной контент, а не дату в подвале. Сигналы возраста документа против возраста контента и метки ненадежных дат читаются как требование честной редакционной свежести. Подмена даты без изменения сути - это фейк-свежесть, см. раздел демоушенов. [F-FRESHNESS-001], [F-FRESHNESS-023]
Для локальных запросов: NAP, гео-интент, hreflang, региональная релевантность, локальные сущности и поведение пользователей из региона. [F-LOCAL-019], [F-LOCAL-010]
7. Демоушены, которых избегать
Код: Выделить всё
КРАСНЫЙ список (то, что тянет вниз)
--------------------------------------------------
- тонкий, массовый, однотипный контент
- keyword stuffing, exact-match переоптимизация
- купленные нерелевантные ссылки, анкор-спам
- фейк-свежесть и подмена дат
- обманная монетизация, навигационный мусор
- скрытие основного контента
- накрутка кликов и любые схемы, делающие
пользовательские данные аномальными
--------------------------------------------------
Главная мысль: после утечки и DOJ мы знаем гораздо больше о том, ЧТО Google собирает (NavBoost-клики, siteAuthority, hostAge, Content Effort). Но веса по-прежнему скрыты, а helpful content теперь живет внутри ядра. Поэтому стратегия не сменилась радикально - она просто стала доказательной: меньше мифов, больше проверяемых гипотез.Как проверять. Возьмите 5-20 URL, где проблема видна и фактор подтвержден источниками. Зафиксируйте baseline, внесите ОДНО изменение, дождитесь переобхода и переиндексации, сравните с контрольной когортой. Масштабируйте только то, что подтвердилось на ВАШИХ данных. Утечка дает карту полей, а не пульт управления - решает всегда эксперимент на вашем проекте.