Разбираю самую недооценённую категорию факторов Google - LOCAL. Недооценённую, потому что многие до сих пор считают локальность чем-то про карты и пин на адресе. На деле это про условие полезности результата: для локального и visit-in-person запроса страница из чужого региона часто проигрывает в принципе, даже если по контенту она объективно сильнее. Авторитет домена тут не спасает.
Логику всей категории удобно держать в голове как пару: гео-аннотация документа на одной стороне и гео-контекст запроса/пользователя на другой. Система их сводит.Дисклеймер. Ниже - реконструкция по утечке Content Warehouse / API leak (май 2024), материалам процесса DOJ против Google, патентам и Quality Rater Guidelines. Это не официальная формула ранжирования. Имена полей реальны (взяты из утёкшей документации), но их точный вес и способ применения - предмет интерпретации. Часть выводов спорна, и я это помечаю.
Код: Выделить всё
СТОРОНА ДОКУМЕНТА СТОРОНА ПОЛЬЗОВАТЕЛЯ
--------------------------------- ---------------------------
geotopics (гео-темы) локация (IP, история)
brainloc (ML-локализация) <--> тип интента запроса
countryInfo (страна) "рядом" = радиус под запрос
metroNavboost (кликовый профиль) персонализация по классу юзеров
localinfo / NAP (физ. бизнес)
Тут не один сигнал, а несколько независимых подсистем, которые перепроверяют друг друга. Это важно: одной разметкой их все не закроешь.
GeoTopicality (F-LOCAL-001, документирован)
Аннотатор вешает на документ набор гео-тематических меток (geotopics), отсортированных по normalized_score, у каждой свой rawScore. По сути - насколько страница про конкретную географию. Поля из утечки: RepositoryAnnotationsGeoTopicality.geotopics, RepositoryAnnotationsGeoTopicalityScore.rawScore.
Brainloc (F-LOCAL-004, документирован)
Отдельная ML-подсистема (PerDocData.brainloc), которая считает привязку к локации независимо от geotopics и webref. То есть у вас три разных механизма локализации работают параллельно. Совпадают - сигнал чёткий. Противоречат - размытый.
Geo-entity метаданные (F-LOCAL-002, документирован)
Webref связывает упомянутые на странице географические сущности с записями Geostore: координата центра, bounding box (bbox), площадь полигона в км2. Отсюда точность: Москва это ~2500 км2 расплывчатого контекста, а Арбат - точка. Поля: RepositoryWebrefGeoMetadataProto.location/.bound/.areaKm2.
2. Страна и таргетингПрактический вывод по разметке. Не пишите abstract gео ("наш ресторан в Москве"). Пишите узко и согласованно: район, улица, ориентир ("кофейня на Покровке у Чистых прудов"). Узкий bbox привязывает контент к локальному интенту точнее, чем название города. И добивайте это NAP-данными: полный адрес в тексте + schema.org/LocalBusiness с координатами, телефоном, часами. Несколько согласованных сигналов = надёжная локализация.
Код: Выделить всё
PerDocData.countryInfo -> CountryCountryAttachment (страна документа)
источники вычисления: ccTLD, hreflang, язык, гео-сущности, КЛИКИ
на выдаче: страна документа <-> страна пользователя
hreflang и localizedCluster (F-LOCAL-007, документирован). Google парсит исходящие hreflang, складывает альтернативные URL в localizedAlternateName и группирует переводы в PerDocData.localizedCluster. На serving URL автоматически подменяется под регион/язык. Ключевое требование - взаимность: /en/ ссылается на /ru/ и наоборот, x-default на универсальную версию. Односторонний hreflang просто игнорируется, а несогласованный кластер повышает риск показать не ту языковую версию.
queriesForWhichOfficial (F-LOCAL-020, документирован). Документ помечается официальным для тройки {запрос, страна, язык}. Канонический пример из утечки: britneyspears.com официальна для ("britney spears","us",0). Так Google отделяет первоисточник бренда от агрегаторов и сателлитов в нужной локали. Для мультиязычных брендов - проверяйте, что официальный домен совпадает с целевой аудиторией.
3. Поведенческая локализация - сигнал, который не подделать разметкой
Вот здесь самое интересное и это та часть, которую утечка 2024 и показания на процессе DOJ подтвердили независимо друг от друга. Локальность Google строит в том числе из реального кликового поведения, разбитого по гео.
Metro-level NavBoost (F-LOCAL-015, документирован). CountryCountryAttachment.metroNavboost - список пар (NavBoost feature, float-множитель). Каждая пара кодирует комбинацию страна+язык+metro и множитель к базовому рангу для запросов из этого metro. Проще: страница, которая стабильно собирает хорошие клики у пользователей конкретного города, получает усиление именно для запросов оттуда.
Это перекликается с тем, что разобрало SEO-сообщество после утечки. NavBoost оперирует goodClicks, badClicks, lastLongestClicks, и - что критично - badClicks накапливаются не только на уровне URL, но и на уровне metro-locale (FeatureCrapsData / locationId). То есть одна и та же страница может быть хороша для одного города и слаба для другого. Европейские и американские SEO независимо отмечали, что эффекты NavBoost регион-специфичны. На процессе DOJ это подкрепил Pandu Nayak: NavBoost - система памяти на агрегированных кликах примерно за 13 месяцев.
GeoLocation clickRadius50Percent (F-LOCAL-016, документирован). Радиус в милях вокруг присвоенной локации документа, внутри которого собрано 50% кликов. Малый радиус (5-20 миль) = узкая локальная аудитория, большой = региональный/национальный охват. Для кофейни вы хотите компактный профиль, размытый трафик со всей страны ухудшает локальную ясность.
Click distribution по странам (F-LOCAL-013, документирован). CountryCountryAttachment.clickDistribution - распределение кликов по странам, дополняет TLD/hreflang. Концентрация кликов на одной стране = выше уверенность в локальности. .com, который льёт случайный трафик отовсюду, размывает страновой профиль.
4. Гейты и демоушены: когда нелокальность наказываютГраница вывода. metroNavboost - не рычаг прямого управления. Его нельзя включить разметкой или закупкой ссылок, он строится из органического поведения аудитории. Поэтому любые обещания "накрутим клики из нужного metro и поднимем локалку" - это про CTR-манипуляции, которые Google научился фильтровать через badClicks/last-longest-click. Единственный честный путь - публиковать гиперлокальный контент (события, гиды, местная аналитика), который реально притягивает нужную аудиторию.
Код: Выделить всё
isNonLocationSpecific | флаг для high-traffic страниц с плоским гео-профилем
(F-LOCAL-017) | примеры из утечки: facebook.com, walmart.com, wikipedia.org
| НЕ наследуется подстраницами
-----------------------+--------------------------------------------------------
global / superGlobal | взаимоисключающие флаги, демоушн в локальных SERP
(F-LOCAL-014) | superGlobal штрафуется МЯГЧЕ ("нейтральный авторитет")
-----------------------+--------------------------------------------------------
geo-specific gate | чужой регион = низкий Needs Met, авторитет не спасает
(F-LOCAL-012, QRG) | пример QRG: minimum wage California для юзера из Канзаса
global / superGlobal (F-LOCAL-014). Глобальные страницы понижаются в локальной выдаче, но Google разделяет нейтральные авторитеты (superGlobal, демоушн мягче) и просто не-локальные. Без чётких страновых сигналов сеть рискует получить global-контекст и проиграть локально-специфичному конкуренту.
Geo-specific results gate (F-LOCAL-012, источник QRG p.165). Для гео-привязанных тем (минимальная зарплата, местные сервисы, законодательство) результат для чужого региона получает низкий Needs Met. QRG прямо приводит пример: страница про minimum wage Калифорнии для пользователя из Канзаса - unhelpful result. Гео-соответствие здесь - необходимое условие полезности, а не довесок.
5. Контекст пользователя, интент и персонализация
Локация юзера меняет выдачу (F-LOCAL-010, подтверждён двумя источниками: COURT p.92-93 + QRG p.164). Для локальных запросов выдача обязана меняться по физическому местоположению - "where they might be, where they typically are, where they work, where they live". Для visit-in-person самые полезные результаты - около пользователя. Это один из немногих факторов с уровнем "подтверждён", а не "документирован".
Радиус "рядом" зависит от типа запроса (F-LOCAL-011, QRG p.164). Для кофейни полезны только очень близкие результаты, за редкой специализированной клиникой человек готов ехать сильно дальше. QRG задаёт асессорам: обыденные частые нужды - гиперлокальность, специализированные услуги - шире радиус. Под это и строится стратегия GBP и контента.
Персонализация по пользователю / классу (F-LOCAL-008, подтверждён: PATENT2 claim 3-4 + LEAK + COURT p.93). Веса ссылок и ранги таргетируются на конкретного пользователя или класс пользователей (патент), personalizationContextOutputs хранит доп. скоры с персонализационным контекстом (утечка), IP логируется для кастомизации (суд). Вывод жёсткий: единой объективной позиции не существует.
6. LocalWWWInfo - мост между сайтом и физическим местомМетодологическая граница для аудита. Раз объективной позиции нет, проверка позиций со своего IP без гео-контекста нерепрезентативна. Снимайте позиции с эмуляцией локации и языка целевой аудитории, используйте GSC с фильтром по стране и отдельные проекты в трекерах под регионы. Средняя позиция без гео-разбивки регулярно вводит в заблуждение.
LocalWWWInfo (F-LOCAL-019, документирован). CompositeDoc.localinfo несёт структуру с адресом и координатами (latE7/lngE7), телефоном, часами и brickAndMortarStrength - силой физического присутствия. А LocalWWWInfoCluster.confidence = authority_page_probability, вероятность того, что страница - авторитетная страница бизнеса. Именно этот кластер связывает веб-страницу с физическим местом для локального пака Maps.
Код: Выделить всё
ЧЕКЛИСТ под LocalWWWInfo / локальный пак
[ ] schema.org/LocalBusiness: address, geo, telephone, openingHours
[ ] NAP в тексте страницы == NAP в GBP-профиле (точное совпадение)
[ ] NAP согласован на внешних агрегаторах/каталогах
[ ] отдельная страница на филиал/город, не одна на всех
[ ] взаимные hreflang + x-default (для мультиязычных)
Что это значит на практике в 2025-2026
Свежие данные локального SEO-сообщества хорошо ложатся на каркас утечки. По разборам Local Search Ranking Factors близость (proximity) фигурирует как тяжелейший единичный фактор локального пака (оценки около 50-55% решений), а сам блок GBP-сигналов - порядка трети веса, где топ-3 внутри это: основная категория GBP, близость адреса к ищущему и ключевики в названии профиля. Это ровно та же ось "близость + согласованная гео-идентичность", что и в полях countryInfo/metroNavboost/localinfo.
Для мультилокейшн-брендов консенсус прямой: хаб-страница store-locator плюс отдельные лендинги под филиал (свои NAP, часы, фото, отзывы, FAQ), каждый GBP линкуется на свою страницу. Бренды с согласованными данными по каталогам показывают заметно выше вовлечённость, чем с рассинхроном - это эмпирическое подтверждение важности confidence в LocalWWWInfoCluster.
Сухой остаток.
1) Локальность Google - это аннотация документа + кликовый профиль + контекст юзера, а не только разметка.
2) Для visit-in-person и гео-специфичных тем гео-соответствие - условие полезности; авторитет домена его не компенсирует (F-LOCAL-012).
3) Самый недооборудуемый сигнал - metro NavBoost: строится поведением, не накручивается без риска.
4) Главные ошибки: одна страница на много городов, односторонний hreflang, проверка позиций со своего IP.
Что НЕ доказано: точные веса всех полей, формула связи metroNavboost с финальным рангом, и то, как именно персонализация по классу пользователей пересекается с локальным паком. Это реконструкция, не официальная формула.