Alejandro Rioja.
GEO SEO

Многоязычный GEO: как попасть в ИИ-поиск на любом языке

Alejandro Rioja
Alejandro Rioja
9 мин чтения
TL;DR

Почти каждое руководство по GEO предполагает сайт только на английском. Мой не такой — он работает на 13 языках, — и три вещи оказались сломаны или работали хуже, как только я посмотрел за пределы английского: корректность hreflang/x-default, охват llms.txt и согласованность схемы между языками. Вот что меняется на самом деле, плюс промпт для аудита, которым я проверяю многоязычный сайт за один проход.

Бесплатная рассылка

Каждую среду. 28 400+ читателей. Никакой воды.

Опубликовано в сентябре 2026 года.

TL;DR: Почти каждое руководство по GEO предполагает сайт только на английском. Мой не такой — он работает на 13 языках, — и три вещи оказались сломаны или работали хуже, как только я посмотрел за пределы английского: корректность hreflang/x-default, охват llms.txt и согласованность схемы между языками. Вот что меняется на самом деле, плюс промпт для аудита, которым я проверяю многоязычный сайт за один проход.

[Взгляд оператора] Каждый чек-лист по GEO, который я читал, включая два своих, был написан для одного языка. Я узнал, насколько этот совет предполагает английский, только когда пошёл выяснять, почему мои страницы на испанском и японском не получают такого же обращения, как английские оригиналы — тот же контент, тот же шаблон схемы, совершенно разные результаты.

Содержание

Открыть Содержание

Почему многоязычный GEO — это не просто SEO ещё на 12 языков

У классического международного SEO есть устоявшийся план: теги hreflang, переведённый контент, готово. GEO добавляет слой, который этот план не покрывает, потому что ИИ-движок не просто индексирует вашу страницу — он решает, по каждому запросу и каждому языку отдельно, какой единственный источник процитировать пользователю. Это решение принимается отдельно на каждом языке, который обслуживает движок, против другого набора конкурентов, другого пула цитируемых источников, а иногда и совсем другого движка.

Ответ ChatGPT на английском строится на другом пуле кандидатов, чем тот же вопрос на японском. Игнорируйте это — и вы проделаете всю работу по GEO один раз, на английском, предполагая, что она распространится сама. Не распространится.

Что ломается первым: hreflang и x-default

Это то, что стоит вам видимости, никогда не проявляясь как ошибка. Два сбоя, оба тихие:

  1. Отсутствующий или неверный x-default. Каждому кластеру hreflang нужна запись x-default, сообщающая движкам и краулерам, какую версию показывать тому, чей язык не совпадает ни с одним из ваших переводов. Пропустите её — и вы говорите каждому нецелевому краулеру: «угадывай сам».
  2. hreflang, указывающий на страницы, которые не являются реальными переводами. Это коварнее и встречается чаще, чем кажется. Если ваш переключатель языка ведёт на главную страницу каждого языка как резервный вариант, когда перевода ещё нет, и вы помечаете эти резервные ссылки атрибутом hreflang, вы утверждаете, что англоязычная статья — это её собственный перевод на испанский. Это не так. Краулер Google в итоге перестаёт доверять всему кластеру; ИИ-движок, строящий граф цитирования по вашим тегам <link>, наследует тот же дефектный сигнал.

У меня был именно этот баг. Переключатель языка в шапке сайта выдавал hreflang на каждой языковой ссылке, включая те, что откатывались на главную страницу языка из-за отсутствия перевода. Каждая англоязычная статья тихо утверждала, что у неё есть двенадцать переводов, которых не было. Исправление оказалось механическим, как только проблема была найдена: помечать hreflang только при наличии реального перевода и всегда выдавать x-default — откатываясь на первую доступную альтернативу, если в кластере нет английского элемента, — чтобы у каждого реального кластера он был.

Вот как это исправление выглядит в реальности, отрендеренное в <head> страницы:

html
<link rel="alternate" hreflang="es" href="https://example.com/es/post-slug/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/post-slug/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/post-slug/" />

Три правила, которые стоит проверить на вашем сайте, в таком порядке: у каждого кластера hreflang ровно один x-default; ни одна ссылка hreflang не указывает на страницу, не являющуюся реальным переводом; ни одна пара тегов <link> в одном кластере не использует одинаковый код (иначе Google отбрасывает весь кластер, а не только дубликат).

Дыра, которую никто не проверяет: llms.txt охватывает только английский

llms.txt — это новая конвенция, дающая ИИ-краулерам курируемый индекс вашего лучшего контента вместо того, чтобы заставлять их обходить сайт и угадывать. Я собрал такой для этого сайта несколько месяцев назад. Заметил я это только когда искал данные для этой статьи: фильтр, который выбирает, какие статьи попадают в индекс, проверяет lang === 'en' и на этом останавливается.

Это значит, что двенадцать тринадцатых контента этого сайта невидимы для любого краулера, который относится к llms.txt как к индексу, а не просто как к подсказке. Каждая неанглийская статья по-прежнему обходится через карту сайта и внутренние ссылки, но курируемый, заслуживающий доверия индекс — созданный специально, чтобы дать ИИ-движку ваши лучшие страницы, — был только английским по недосмотру, а не по решению.

Если вы ведёте многоязычный llms.txt, проверьте это прямо сейчас: действительно ли файл (или файлы) перечисляет ваши переведённые статьи, или индекс тихо схлопывается до вашего исходного языка, как это было у меня? Единый общий llms.txt, перечисляющий только английские URL, не то чтобы неправильный — он просто ничего не делает для остальных языков, на которых существует ваш сайт.

Схема и согласованность сущности между языками

Схема FAQPage, Article и Person, которую вы уже используете (см. мой разбор schema markup, если ещё не настроили это), должна говорить о вас одно и то же на каждом языке, потому что ИИ-движки строят единый граф сущности по всем этим языкам сразу.

Два момента, которые важно сделать правильно:

  • Оставляйте идентификаторы непереведёнными, переводите строки, обращённые к человеку. @id, url, массив sameAs и значение jobTitle в вашей схеме Person или Organization должны быть идентичны на каждом языке — именно это говорит движку «это та же сущность» на разных языках. Меняется только окружающий текст и читаемые человеком подписи.
  • Не давайте устаревшему переводу отставать от схемы. Если вы обновляете dateModified в схеме Article или добавляете новый вопрос в FAQ на английском, то же изменение должно попасть в JSON-LD каждого языка, а не только в текст. Движок, который видит английский контент, обновлённый на прошлой неделе, и французскую версию той же страницы со схемой полугодовой давности, читает это как две разные страницы, а не как одну страницу на двух языках.

Разные языки — разные ИИ-движки

Разговор о GEO по умолчанию подразумевает ChatGPT, Perplexity и Google AI Overviews, потому что именно там идёт англоязычный разговор. Это не полная картина, как только вы начинаете публиковаться на русском, китайском или корейском.

Яндекс использует собственный слой генеративных ответов для запросов на русском языке и имеет заметно большую долю русскоязычного поиска, чем Google. Ответы Baidu на основе ERNIE важны для китайского. ИИ-сводки Naver важны для корейского. Если ваш чек-лист по GEO учитывает только трио движков, ориентированных на США, вы оптимизируетесь, возможно, лишь под 60% движков-ответчиков, которыми реально пользуются ваши международные читатели, — и вы этого не заметите, потому что ни один из этих движков не отображается в Google Search Console.

У меня нет чистого способа проверить показатели цитирования в Яндексе или Baidu отсюда, и я говорю об этом прямо, а не делаю вид, что это не так. Что я могу сказать: не думайте, что тот же список из трёх движков, под который вы оптимизируетесь для английского, — это полный список везде.

Реальное доказательство с моего собственного сайта

Вот что я могу измерить. Это та же статья со сравнением GEO и SEO, тот же шаблон контента, та же схема, переведённая на каждый язык — данные Search Console за период с 15 июня по 11 сентября 2026 года:

ЯзыкПоказыСредняя позиция
Испанский207731,9
Нидерландский337046,6
Французский139325,1
Японский10614,8
Корейский5724,9
Немецкий8660,6
Итальянский3267,8
Английский56958,2

Одна и та же статья, одна и та же структура, один и тот же шаблон схемы, а разброс позиций — от 14,8 до 67,8. Хочу быть честным насчёт того, что это доказывает, а что нет: это классические позиции Google из Search Console, а не данные о цитировании ИИ — у меня нет чистой атрибуции по языкам для цитирований ChatGPT или Perplexity, и я не знаю никого, у кого она есть. А доказывает это то, что «переведите — и та же работа по оптимизации сработает одинаково везде» — неверно даже на моём собственном сайте. Японский перевод при доле показов от общего числа обгоняет по позиции все остальные языки, включая английский оригинал. Что-то в этой странице — конкуренция, качество перевода, то, как сущность распознаётся на японском, — работает так, как не работает на немецком или итальянском, при абсолютно идентичном шаблоне схемы во всех случаях.

Поручите это Claude или ChatGPT: промпт для многоязычного GEO-аудита

Не нужно читать спецификации hreflang, чтобы это проверить. Вставьте это в Claude или ChatGPT вместе с URL вашего сайта:

У меня сайт с контентом на нескольких языках. Для [URL] проверь: (1) выдаёт ли страница тег hreflang x-default, и указывает ли каждый тег hreflang на странице на реальный перевод, а не на резервную главную страницу; (2) использует ли JSON-LD-схема страницы (Person, Organization или Article) одинаковые значения @id, url и sameAs во всех языках, или они различаются по языкам; (3) если на сайте есть файл llms.txt, перечисляет ли он страницы на языках, отличных от английского. Скажи мне точно, какой из этих пунктов не выполняется, и процитируй конкретный тег или поле, которое ошибочно, а не давай общее резюме.

Проверьте ответ по реальному исходному коду страницы, прежде чем доверять ему — модель уверенно опишет тег x-default, которого не существует, если вы не покажете ей, как всё выглядит на самом деле.

Чего избегать

Не создавайте тринадцать отдельных файлов llms.txt без реальных доказательств — логов сервера, показывающих обращения ИИ-краулеров по поддоменам, а не догадки, — что движки относятся к вашим языкам как к отдельным ресурсам. Один хорошо очерченный файл, который действительно перечисляет ваши переведённые URL, закрывает пробел выше без нагрузки на обслуживание тринадцати файлов.

Не переводите страницу машинным способом только ради того, чтобы заполнить языковую ячейку. Плоский, дословный перевод для GEO хуже, чем отсутствие перевода вообще — он даёт ИИ-движку низкокачественный источник для сравнения с нативным контентом конкурента, и это самый быстрый способ оказаться процитированным на форуме поддержки как «сайт со странными переводами».

Итог

Если ваш чек-лист по GEO был написан для одного языка, проверьте его на своём худшем по эффективности языке, прежде чем доверять ему как системе. У меня был реальный, тихий баг с hreflang и индекс цитирования только на английском, который простоял месяцами, пока я не проверил. Оба были простыми исправлениями. Ни одно из них не всплыло бы, если бы я не пошёл искать, держа в уме второй язык.

Многоязычный GEO — Часто задаваемые вопросы

Влияет ли hreflang на цитирования ИИ-движков на самом деле, или только на классический ранжинг Google?

И то, и другое, хотя механизм разный. Для классического Google hreflang говорит краулеру, какой URL показывать для какого языка в результатах поиска. Для ИИ-движков hreflang вместе со схемой — часть того, как движок решает, «это одна и та же сущность/контент на разных языках» — ошибётесь здесь, и движок рискует обращаться с вашими английской и испанской страницами как с несвязанными источниками, а не как с одной темой, освещённой дважды.

Нужно ли переводить каждую статью на все языки, которые поддерживает мой сайт?

Нет. Переводите статьи там, где тема и поисковый спрос это оправдывают на конкретном рынке — специфичное для США руководство по ценам, возможно, не нуждается в переводе на арабский, а глобальная статья о GEO, скорее всего, нуждается. Непереведённые почти-дубликаты между языками хуже, чем меньшее количество статей, но полностью переведённых.

Как понять, правильно ли очерчен мой llms.txt?

Откройте файл и проверьте, включают ли перечисленные URL пути на языке, отличном от исходного. Если все URL на одном языке, а ваш сайт публикуется на нескольких, индекс ограничен этим одним языком — независимо от того, было это задумано или нет.

Нужна ли отдельная схема для каждого языка или один блок схемы, переиспользуемый везде?

Одна сущность, переведённое представление. Идентифицирующие поля (@id, url, sameAs) остаются идентичными на всех языках; читаемый человеком текст (headline, description, ответы FAQ) переводится по языкам. Относитесь к этому как к одной сущности, описанной на нескольких языках, а не как к нескольким сущностям.

Похожие материалы: Schema Markup для GEO · Как перевести статью блога на 13 языков одним агентом · GEO для соло-операторов

Нужен взгляд со стороны на вашу собственную многоязычную настройку? Свяжитесь со мной — я провожу GEO-аудиты для сайтов, публикующихся более чем на одном языке, или попробуйте промпт выше сами с Claude, если хотите проверить это сегодня.

Читать дальше

Похожие статьи

GEO

Как добавить GEO к действующему SEO-сопровождению

Как SEO-агентство добавляет реальную GEO-работу к действующему сопровождению: сначала аудит, отдельная цена, без простого переименования той же работы.

SEO

Сколько брать с клиентов за GEO-аудит

Как я оцениваю GEO-аудит: фиксированная цена, что входит в отчёт с результатами и когда переводить его в сопровождение.

GEO

Как Получить Цитирование в AI-Поиске Через Reddit

AI Overviews и ChatGPT опираются на треды Reddit чаще, чем на блоги компаний. Как попасть в них без накрутки, покупки апвоутов и банов.

Читать дальше

Получайте ИИ-руководство на почту

Каждую среду. 28 400+ читателей. Никакой воды.

↵ ↵ — все результаты esc esc — закрыть