// руководство
Как на практике делать GEO на своём сайте?
Обновлено: 2026-08-03
// краткий ответ
Технический GEO — это гигиена, а не магия. На get-geo.ai за полдня работы каждый сигнал стал указывать на один хост, AI-фетчеры получают контент с первого запроса, Search Console переведён на доменную property, а полный корпус гайдов лежит в per-locale файлах llms-full, которые обновляются из того же реестра, что и страницы. Контент решает, процитируют ли вас; техника решает, дочитают ли до контента.
Исходная точка: сайт, который выглядит правильно
Мы продаём GEO — значит, наш собственный сайт обязан быть образцом. Этот гайд — не теория, а протокол одного реального рабочего дня: что мы нашли, как чинили и что проверяли. Все примеры — с этого самого сайта.
get-geo.ai с первого дня строился «по учебнику»: серверный рендеринг, 8 языков с hreflang, Schema.org JSON-LD, answer-first структура, llms.txt. Казалось бы, что тут чинить? Аудит нашёл проблему, которую не видно глазами.
Находка №1: конфликт apex и www
Сайт физически жил на www.get-geo.ai, а все сигналы — canonical, sitemap, hreflang, JSON-LD, llms.txt — указывали на get-geo.ai (apex, домен без поддомена). При этом apex отвечал 308-редиректом обратно на www.
Получался цикл: «каноническая версия — apex» → apex редиректит на www → www говорит «каноническая версия — apex». Классический краулер Google такое переживает, хоть и тратит crawl-бюджет. А вот AI-фетчеры — нет: у многих из них бюджет 1–2 запроса на страницу, и часть просто не доходит до контента через редирект. Для GEO это критично: невидимый для фетчера файл — несуществующий файл.
Фикс: apex сделан primary-доменом на хостинге (Vercel), www переведён в 308 на apex. Один переключатель — и все сигналы стали консистентными: фактический адрес, canonical, внутренние ссылки, sitemap и llms.txt теперь указывают в одну точку.
Урок: выбор между apex и www не важен. Важно, чтобы сайт жил ровно на одном из них, а второй жёстко редиректил. Любое расхождение между «где сайт живёт» и «куда указывают сигналы» — это налог на каждый визит краулера.
Находка №2: устаревший совет от AI-агента
Диагностику проводил AI-агент, и в его чек-листе был пункт: «проверьте, что A-запись apex указывает на 76.76.21.21». Проверка реального DNS показала другое: домен резолвится в 216.198.79.1 — новую инфраструктуру Vercel, на которую хостинг мигрировал позже среза обучающих данных модели.
Совет был не вредный, но устаревший. Модель уверенно цитировала прошлое.
Урок: AI-агент без инструментов проверки — это память, а не знание. Любую техническую рекомендацию модели сверяйте с живым состоянием системы: один DNS-запрос стоит секунду и снимает вопрос. Это, кстати, главный принцип и самого GEO: модели отвечают из того, что смогли прочитать, — поэтому мы и делаем контент читаемым.
Шаг 3: Google Search Console — доменная property
После смены primary-хоста старая property в GSC (URL-prefix на https://www.get-geo.ai/) стала бесполезной: она покрывает только www, а страницы переезжают на apex.
Правильная конфигурация — доменная property (get-geo.ai без протокола и поддомена): она покрывает apex, www, http, https и все поддомены разом. Верифицируется только через DNS TXT-запись — и здесь приятная деталь: токен google-site-verification привязан к аккаунту, а не к способу проверки, поэтому запись, добавленная в DNS ранее, сработала мгновенно. Затем — отправка sitemap с apex-адреса: https://get-geo.ai/sitemap.xml.
Урок: свежеотправленный sitemap в GSC часто висит с красным статусом «Не удалось получить» и нулём страниц. Это не ошибка, а плейсхолдер до первой обработки — она асинхронная и занимает до пары суток. Прежде чем паниковать, проверьте три вещи: файл открывается по прямому URL, все <loc> внутри указывают на правильный хост, robots.txt содержит строку Sitemap:. Если всё так — просто ждите.
Шаг 4: sitemap как GEO-инструмент, а не формальность
Наш sitemap включает не только страницы. В нём перечислены llms.txt, llms-full.txt и все языковые версии llms-full/{locale} — с lastmod и приоритетами.
Зачем: AI-краулеры (GPTBot, ClaudeBot, PerplexityBot) замечены за чтением sitemap, и явное включение LLM-файлов даёт им прямой маршрут к машиночитаемой версии сайта — не полагаясь на то, что фетчер знает конвенцию /llms.txt.
Урок: относитесь к sitemap как к меню для машин, а не как к чекбоксу. Всё, что вы хотите показать AI-системам, должно быть в нём перечислено с честными датами lastmod.
Шаг 5: llms-full — полный контент, а не оглавление
Конвенция различает два файла: llms.txt — оглавление со ссылками, llms-full.txt — полный контент для систем, которые не ходят по ссылкам. У нас в full-версии изначально был только лендинг: гайды — самый цитируемый актив — оставались доступны только постранично.
Что мы изменили:
- Per-locale файлы. Полные тексты гайдов ушли в llms-full/{locale}, каждый файл целиком на своём языке. Сваливать 8 языков в один файл — значит в 8 раз разбавить полезную плотность для любого конкретного запроса.
- URL под каждым заголовком. Внутри файла каждый гайд начинается с заголовка и канонического URL сразу под ним — чтобы модель, взяв текст, могла сослаться на страницу, а не на сам txt.
- Автогенерация из единого реестра. Файлы собираются из того же источника, что и страницы гайдов. Новый гайд попадает на сайт, в sitemap и в llms-full одним действием. Ручная синхронизация умирает через месяц — мы её даже не начинали.
- Лимит с честной деградацией. У файла есть предел размера; при переполнении вместо молчаливого обрезания — список не вошедших гайдов со ссылками.
- Урок из неожиданного места: первый лимит в 100 КБ чуть не сломала письменность. Devanagari (хинди) в UTF-8 занимает 3 байта на символ против 1 у латиницы — hindi-файл достиг 85 КБ, когда английский был вдвое легче. Подняли лимит до 200 КБ. Если у вас мультиязычный сайт, считайте бюджеты с поправкой на алфавит: CJK и индийские письменности «весят» в разы больше.
Итог дня
Полдня работы, ни одной новой страницы контента — и при этом:
- каждый сигнал сайта указывает на один хост, без циклов и лишних редиректов;
- AI-фетчер с бюджетом в один запрос получает контент с первой попытки;
- GSC собирает данные по всему домену, а не по одному поддомену;
- полный корпус гайдов на 8 языках доступен машинам одним файлом на локаль;
- публикация нового гайда автоматически обновляет сайт, sitemap и llms-full.
Гигиена, а не магия
Это и есть техническая часть GEO: не магия, а гигиена. Контент решает, процитируют ли вас. Техника решает, дочитают ли до контента.
Смежные вопросы
Важен ли выбор apex или www для GEO?
Сам выбор не важен. Важно, чтобы сайт жил ровно на одном хосте и все сигналы — canonical, sitemap, hreflang, JSON-LD, llms.txt — указывали туда, а второй hostname жёстко редиректил. Цикл между apex и www сжигает crawl-бюджет и часто останавливает AI-фетчеры, которые делают лишь один-два запроса.
Нужна ли доменная property в Google Search Console?
Да, если вам важны и apex, и www (или http и https). Доменная property покрывает всё разом и верифицируется через DNS TXT. URL-prefix property только на www слепнет в момент, когда primary-хост переезжает на apex.
Зачем перечислять llms.txt в sitemap?
AI-краулеры замечены за чтением sitemap. Перечисление llms.txt и per-locale файлов llms-full даёт им прямой маршрут к машиночитаемому корпусу — не полагаясь на то, что каждый фетчер знает конвенцию /llms.txt.
Почему per-locale файлы llms-full, а не один мультиязычный дамп?
Один файл с восемью языками в восемь раз разбавляет полезную плотность для любого конкретного запроса. Один файл на локаль держит корпус плотным, ставит канонический URL под каждым заголовком гайда и может собираться из того же реестра, что и HTML-страницы.