GEO для бизнеса с филиалами в разных городах: как не плодить дубли и попасть в ответ нейросети
Чем GEO отличается от привычного SEO для регионов
Локальное SEO годами работало так: под каждый город - своя страница с уникальным title, H1 и текстом под ключ "услуга + город". Это логично для поисковика, который отдает выдачу под геолокацию пользователя.
GEO (Generative Engine Optimization - продвижение в ответах нейросетей: ChatGPT, Яндекс.Алиса, Google AI Overviews, Perplexity, GigaChat) устроено иначе. Нейросеть не привязывает ответ к 200 разным страницам одной компании - она ищет один достоверный, подробный источник и цитирует или пересказывает его. Если у вас 50 почти одинаковых страниц с минимальными заменами города в тексте, нейросеть видит в этом не 50 источников доверия, а один слабый, размноженный контент - и скорее возьмет ответ у конкурента с одной сильной статьей.
Это ключевое отличие определяет всю дальнейшую архитектуру.
Почему размножать статьи по городам - плохая идея
Три причины, почему это не работает ни для SEO, ни для GEO
Как нейросети технически видят мультирегиональный сайт
Для сайта с десятками или сотнями городских поддоменов здесь есть проблема на уровень сложнее, чем у обычного одностраничного сайта - и она напрямую решает, дойдет ли до нейросети сигнал о том, что статья вообще одна, а не размножена.
Стандартная схема - на 190+ городских поддоменах стоит rel canonical на основную статью - работает для Google и Яндекса. Но у краулеров нейросетей (GPTBot, ClaudeBot, Google-Extended, YandexGPT-бот) хуже с исполнением JavaScript, чем у поискового краулера Google. Если тег canonical подставляется через JS, краулер нейросети может его не увидеть вообще - и тогда каждый из 190 поддоменов выглядит для него как независимая страница, а не как копия с указанием на первоисточник. Итог обратный задуманному: вместо одного сильного источника нейросеть видит десятки слабых. .
У AI-краулеров ограниченный crawl budget, приоритет обхода строится по ссылочному весу и частоте обновления. Если 190 поддоменов ссылаются друг на друга по шаблону и не имеют собственного уникального веса, часть из них краулер нейросети может не обходить месяцами - а значит, даже корректно выставленный canonical на такой странице ничего не даст, потому что до самой страницы бот не дошел. Проверяется по логам сервера - реально ли заходят GPTBot/ClaudeBot/Google-Extended на поддомены, или только на основной домен.
Практический вывод: прежде чем писать десятки статей под GEO, нужно проверить на нескольких городских поддоменах - отдается ли тег canonical в исходном HTML-ответе сервера без выполнения JavaScript, и заходят ли туда вообще AI-краулеры по логам. Если canonical виден только после рендера в браузере - вся многогородовая архитектура для нейросетей невидима, и переделывать нужно это, а не контент.
Архитектура: один экспертный источник + локальные точки входа
Рабочая модель для мультирегионального бизнеса - развести две задачи по разным типам страниц, а не пытаться закрыть обе одной статьей на 50 поддоменах:
| Тип страницы | Задача | Где живет | Привязка к городу |
|---|---|---|---|
| Экспертная статья (блог) | Отвечать на вопрос, дать нейросети цитируемый источник | Один канонический URL на основном домене | Нет - статья не про город, а про тему |
| Страница услуги | Закрывать транзакционный запрос "услуга + город" | Локальный поддомен | Да - уникальный текст, цены, портфолио под город |
Связка между ними - не дублирование, а перелинковка: статья в блоге отвечает на широкий вопрос ("как настроить GEO для сети филиалов"), и в теле статьи, в естественном месте, стоит блок с ссылкой на страницу услуги нужного города. Так нейросеть цитирует один сильный источник, а трафик из этого источника доходит до локальной страницы, которая уже закрывает конверсию под конкретный город.
Чек-лист для проверки своего сайта
Услуга
Настраиваем видимость сайта в ответах ChatGPT, Яндекс.Алисы, Google AI и Perplexity: от технического аудита рендеринга под краулеры нейросетей до контентной стратегии и структурированных данных. Отдельно прорабатываем архитектуру для бизнеса с филиалами в нескольких городах, чтобы контент не размножался, а работал на один сильный источник.
Нет. Статья в блоге отвечает на широкий вопрос и живет на одном каноническом URL. Под город адаптируются отдельные страницы услуг, а не статьи блога.
