Сайт упал под Core Update — что делаем дальше?

После Core Update декабря 2025: как мы перестраиваем автомобильную референс-платформу под GEO/LLM-эпоху

В декабре 2025 года Google выкатил очередной Core Update. У одного из проектов, с которым я работаю — независимой автомобильной референс-платформы для немецкоязычного рынка с англоязычной редакцией под аудиторию экспатов — органический трафик просел сразу по нескольким векторам одновременно. Шаблонные страницы потеряли около 87% трафика. Контент без указания авторства просел на 52%. Архивные материалы старше трёх лет, не обновлённые редакторски, ушли вниз на 58%. В сумме платформа потеряла больше половины органики за две недели, и это была не сезонная флуктуация — это было системное переоценивание сайта поисковой системой.

Самое неприятное даже не в цифрах падения. Самое неприятное в том, что упало именно то, на чём проект зарабатывал. Платформа работает по гибридной B2B+B2C модели — B2C-трафик и редакционный авторитет создают основу для B2B-доходов через API данных по автомобилям, white-label виджеты для дилеров и OEM-партнёрства. Когда уходит B2C-видимость, B2B-воронка пересыхает следом: дилеры и медиа-партнёры приходят на API через органический трафик и публикации с упоминанием платформы. Нет первого — нет второго.

Я думаю каждый, кто работает с информационно-сервисными проектами в 2026 году, уже понял или вот-вот поймёт одну неудобную вещь. Google перестал быть единственной точкой входа. ChatGPT с веб-поиском, Perplexity, AI Overviews, Gemini, Claude — все они в совокупности забирают значительную долю информационных запросов на верхних этажах воронки. До классического сайта доходит уже квалифицированный пользователь, и если он не доходит — у вас не падение трафика, у вас падение качества всего канала.

И вот про этот переход — с классического SEO на GEO/LLM-стек — и пойдёт речь дальше. На конкретном кейсе, в котором мы за последние недели прошли диагностику, выработали стратегию и начали перестраивать архитектуру платформы под новую реальность поиска.

Что мы увидели на диагностике: пять категорий просадки

Первое, что я сделал после фиксации факта падения — разобрал, в какие именно категории пострадавших страниц мы попали. Google в Search Quality Rater Guidelines декабрьского обновления (раздел 4.5.3 о ratings для контента без подтверждённого авторства) дал довольно ясные сигналы того, что именно переоценивается. Я прошёлся по нашему проекту с этим документом в руке.

Шаблонные страницы менее 300 слов с идентичной структурой текста — найдено около 1200 единиц. Это были автогенерированные карточки конкретных вариантов модификаций автомобилей с однотипным набором полей и без редакционного контекста. Они работали в эпоху до Core Update — давали хвост низкочастотного трафика по запросам типа «BMW 3 Series 320d 2018 specifications». После апдейта эти страницы стали восприниматься как массовая шаблонная генерация, потеряли ранжирование и потянули за собой средний показатель качества всего поддомена.

Массовый AI-сгенерированный контент с распознаваемой шаблонной структурой — это была серая зона. Часть архивных описаний моделей формально была написана редактором, но через инструменты, которые оставляли характерные следы (одинаковая длина абзацев, повторяющиеся переходные конструкции, отсутствие конкретики). Google научился такие тексты ловить и снижать им вес. Потеря по этому пулу — около 71% трафика.

Контент без идентифицируемого авторства. У нас не было системы публичной идентификации авторов на новостных и аналитических страницах. Просто имя в подписи без профиля, без credentials, без подтверждений экспертизы вовне сайта. Для алгоритма это эквивалентно анонимности. Потеря по этому пулу — около 52%.

Архивные страницы старше трёх лет без обновления или редакционного комментария. У платформы есть огромный исторический архив оцифрованных оригинальных брошюр производителей, и часть страниц жила в режиме «загрузили в 2018-м и забыли». Без редакционного комментария, без обновлённых метаданных, без явного указания даты последней проверки информации. Потеря — около 58%.

E-E-A-T-дефицит на уровне сайта в целом. Не было страницы методологии, не было прозрачного описания подхода к работе с данными, не было явной декларации редакционной политики и принципов проверки фактов. Для платформы, претендующей на статус авторитетного источника технических данных по автомобилям, это критический пробел. Влияние оценить трудно, но косвенно — это умножающий коэффициент к остальным потерям.

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

Стратегическая пересборка: позиционирование как корень всех решений

В начале февраля 2026 я сел с командой и сформулировал главный вопрос, на котором стоит вся последующая работа. Вопрос звучал так: что именно представляет собой эта платформа в графе сущностей Google и в обучающих данных LLM? Не «как мы себя описываем на главной», а «как нас будут описывать алгоритмы поиска и языковые модели, когда им нужно объяснить пользователю, что это за источник».

Анализ конкурентного поля показал любопытную картину. На немецкоязычном автомобильном рынке доминируют крупные маркетплейсы (которые в наших публикациях не упоминаются по имени из соображений брендинга, замещаются формулировками уровня «major German used-car portals»). В англоязычном поле работают мощные редакционные проекты — Carwow с моделью marketplace плюс контент, AutoTrader как чистые classifieds, WhatCar и AutoExpress как независимые редакционные платформы, TopGear как entertainment-направление, RAC как сервис плюс контент. Все они UK-фокусированные. Ни один из них системно не покрывает специфику немецкого рынка. И ни один из англоязычных «экспат-гидов» по Германии не имеет глубины именно в автомобильной теме.

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

Финальная формулировка позиционирования, которую мы зашили во все слои сайта — от H1 на главной до Schema.org Organization, от Open Graph-описаний до llms.txt — звучит как «Die unabhängige technische Fahrzeug-Referenz». Независимая техническая референс-база. Не «автомобильный портал», не «информационный сайт», а именно «референс-база» — это в немецкоязычном поле уровень академической точности, к которому привыкли инженеры, журналисты и B2B-клиенты.

Из позиционирования вытекает гибридная модель монетизации. B2C-трафик — это не самоцель, это фундамент, на котором стоят B2B-доходы: подписки на API автомобильных данных, лицензирование white-label виджетов для дилеров, OEM-партнёрства по официальному размещению брошюр и контентные коллаборации, медиа-синдикация технических даталистов в отраслевые издания. Аналог, на который мы ориентируемся по структуре — Carwow с его моделью «контент создаёт трафик, трафик создаёт лид-формы, лид-формы создают B2B-выручку», но с фокусом на данные вместо транзакций по продаже автомобилей.

Эта гибридность важна для архитектуры. На главной странице есть переключатель «Enthusiasten / Profis & API», который меняет контекстные ссылки и подсказки поиска. По умолчанию пользователь видит B2C-режим. В режиме «Profis» появляются ссылки на API-документацию, виджеты, лицензии на данные. B2C — дефолт для максимального трафика, B2B — отдельная видимая ветка, не размывающая основной интент.

Архитектурное разделение: каталог, архив, сравнения, магазин

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

Каталог автомобилей под адресом /en/catalog/{brand}/{model} — это вложенная иерархия современных моделей с техническими даталистами, спецификациями, сравнениями поколений внутри модели и лайнапом поколений в виде наглядного picker’а. Цветовая метка в интерфейсе — оранжевая, подпись «Fahrzeugkatalog», метаданные говорят «все поколения». Это страницы исследования и сравнения актуальных моделей. Интент пользователя — информационный плюс коммерческий.

Технический архив — это совершенно другой тип контента. Здесь живут оцифрованные оригинальные брошюры производителей с редакционным комментарием и OCR-распознанным текстом. Цветовая метка — золотая, подпись «Technisches Archiv», метаданные говорят «от 1960-х до сегодня». Интент пользователя — информационный плюс исследовательский. Это страницы для энтузиастов, историков, журналистов, B2B-клиентов, которые ищут конкретные исторические данные.

Сравнения автомобилей по адресу /en/comparison/{slug} — плоская URL-структура без вложенности по бренду или модели. Это отдельный тип контента, отвечающий на запросы вида «X vs Y», «X generation comparison», «X trim comparison». Здесь живут side-by-side сравнения с категориями-победителями, фильтрами по профилю использования, экспертной оценкой и редакционным вердиктом.

Magazine — это блог с экспертными статьями на английском языке, построенный по модели топикального авторитета с четырьмя топикальными кластерами. Live URL — /en/magazine/{category}/{slug}. Это раздел вечнозелёного экспертного контента, отдельный от оперативных новостей.

Новости под адресом /en/news/{slug} — оперативный контент: отзывы производителей, регуляторные новости, премьеры моделей. NewsArticle-разметка, eligibility для Google Top Stories.

Технический справочник, EV-инструменты, Car Stories — это вспомогательные секции, поддерживающие основные четыре.

Разделение это не косметическое. Каждая секция имеет свой Schema-тип, свой шаблон хлебных крошек, свой цветовой код в интерфейсе, свои метаданные. Google и LLM получают однозначный сигнал того, что они видят на конкретной странице, без необходимости угадывать тип контента.

URL-архитектура: почему сравнения плоские, а каталог вложенный

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

Каталог использует вложенные URL — /en/catalog/audi/a4. Это логично, потому что у каталожной страницы есть однозначная иерархия: модель принадлежит бренду, бренд принадлежит каталогу. Хлебные крошки симметричны URL: Home › Catalog › Audi › A4. Schema.org BreadcrumbList отражает эту же иерархию. Всё прозрачно.

А вот сравнения используют принципиально плоский URL — /en/comparison/audi-a4-b9-vs-b10 или /en/comparison/audi-a4-vs-bmw-3er-vs-mercedes-c-klasse. Никакой вложенности по бренду или модели. Это сделано осознанно по трём причинам.

Первая причина — устранение конкуренции за entity-ключевики. Если поставить comparison-страницу во вложенный URL вида /comparison/audi/a4/b9-vs-b10, она попадает в общий keyword-сегмент с /catalog/audi/a4. Google начинает выбирать одну страницу из двух как канонический ответ на запрос «audi a4» — обычно ту, у которой больше backlinks. Сравнения почти всегда проигрывают каталогу. Плоский URL устраняет проблему: comparison-страница занимает собственный keyword-сегмент уровня «audi a4 b9 vs b10 comparison», не пересекаясь с базовой моделью.

Вторая причина — экономия краулингового бюджета. В планах раздела 127 сравнений с расчётным расширением до нескольких сотен. Если каждое сидит в собственном дереве /catalog/{brand}/{model}/comparison/…, краулинговый бюджет фрагментируется по тысячам комбинаторных URL-патернов. Плоская структура держит весь раздел в одном предсказуемом дереве с понятной для Googlebot логикой.

Третья причина — корректная обработка многомерных сравнений. У cross-brand сравнения вида A4 vs BMW 3 Series vs Mercedes C-Class нет одного «родительского» бренда. В вложенной схеме приходится изобретать искусственные категории типа /comparison/category/premium-sedans/…, которые ломают паттерн и создают новые URL-уровни. Плоская схема даёт /comparison/audi-a4-vs-bmw-3er-vs-mercedes-c-klasse — slug самодостаточен и self-describing.

Но вот тонкость, которая отличает наш подход от большинства плоских URL-схем в индустрии. Хлебные крошки на comparison-странице всё равно содержат путь через каталог. Home › Comparisons › Audi › A4 › B9 vs B10 generations. Несмотря на то, что физический URL — плоский. И это совершенно правильно с точки зрения Google.

Google официально подтверждает в документации Search Central (раздел Structured Data → Breadcrumb), что BreadcrumbList не обязан отражать URL-вложенность — он отражает логическую иерархию контента. То есть URL — это адрес ресурса, оптимизированный под краулинг и keyword-routing. А хлебные крошки — это семантическая карта пути, оптимизированная под пользовательскую модель «где я нахожусь по отношению к сущности» и под Schema.org. Это две независимые системы, которые могут совпадать, но не обязаны.

Получается интересная двунаправленность. С comparison-страницы пользователь по крошке может уйти на /catalog/audi или /catalog/audi/a4, получив контекст сущности. С catalog/audi обратный путь в comparison не через крошки (там их просто нет — крошки бренда это Home › Catalog › Audi, без упоминания comparisons) — а через выделенную секцию «Comparisons featuring Audi» с шестью карточками сравнений, в которых упоминается Audi. То есть UP-путь через крошки, DOWN-путь через секции. Это разные механизмы возврата, и они не конкурируют.

Это важный паттерн для любого проекта, в котором есть несколько типов контента, обслуживающих разные интенты по одним и тем же сущностям. URL-плоскость для типов контента, которые НЕ должны конкурировать с базовой иерархией. Крошки и cross-link секции для двунаправленной связности. Schema.org для машинного понимания структуры.

Schema.org @graph: что мы отдаём машинам

Если плоские URL и крошки решают вопрос человеческой и поисковой навигации, то Schema.org @graph решает вопрос машинного понимания каждой страницы. Раньше типовая практика SEO — поставить на страницу один Schema-тип, Article или BreadcrumbList, и считать что разметка сделана. В реальности 2026 года этого катастрофически мало.

На каждой странице платформы мы используем JSON-LD блок с @graph, в котором собраны несколько связанных Schema-нод с явными @id, перекрёстными ссылками через mainEntity и сущностной идентификацией через sameAs на Wikidata и Wikipedia.

На странице каталога бренда (например /en/catalog/audi) @graph содержит около десяти связанных нод. WebSite и Organization — общие для сайта. WebPage — обёртка для страницы. BreadcrumbList с тремя позициями. Brand с логотипом, sameAs на Wikidata Q23317 и на немецкую Wikipedia, foundingDate, headquartersLocation. Organization подтипа Manufacturer для самой автокомпании, с parentOrganization-связью на VW Group. ItemList «Audi current model lineup» с двенадцатью Product-объектами для лайнапа. Второй ItemList «Comparisons featuring Audi» с шестью Article-объектами для секции сравнений. FAQPage с пятью вопросами о бренде. Всё это связано через @id-ссылки в единый сущностной граф.

На странице detail-сравнения (например /en/comparison/audi-a4-b9-vs-b10) @graph включает WebSite, Organization, WebPage, BreadcrumbList с пятью позициями (Home, Comparisons, Audi, A4, B9 vs B10 generations), Article с datePublished и dateModified, два Car entity — по одному на каждое сравниваемое поколение с brand, model, vehicleModelDate, productionDate, sameAs на Wikidata, и FAQPage. На странице cross-brand сравнения добавляется ItemList с тремя ListItem, связанными с Car-объектами.

Несколько критических правил, к которым мы пришли после нескольких итераций.

CollectionPage — НЕ Google-supported rich result. Используется только WebPage. Это финальное архитектурное решение, не подлежит обсуждению — Schema.org декларирует CollectionPage, но Google не использует его как сигнал, и попытки внедрения создают только confusion в поисковых сниппетах.

ItemList должен соединяться с WebPage через mainEntity только для главного ItemList на странице. Если на странице несколько ItemList — как у нас на бренд-странице, где один для лайнапа моделей и второй для сравнений — mainEntity-связь даётся только основному, второй существует как независимый node. Это даёт Google ясный сигнал о том, что является семантическим сердцем страницы, и одновременно сохраняет богатую entity-картину для AI-краулеров.

Все sameAs — обязательно Wikidata плюс Wikipedia. Опционально — Google Knowledge Graph MID, если он известен для сущности. Без sameAs на авторитетные графы знаний entity-разметка теряет половину силы, потому что машинам не на что опереться для дисамбигуации.

NewsArticle vs Article — это не косметическое различие. NewsArticle используется только для оперативного новостного контента в /news/ с временной актуальностью, что даёт eligibility для Google Top Stories. Article — для evergreen контента в Magazine, для сравнений, для каталожных страниц. Перепутать эти типы означает либо потерять Top Stories, либо запутать Google в типе контента.

hreflang alternates на всех страницах — обязательны минимум en, de, x-default. Платформа мультиязычна (DE/EN с планами на ES/FR/IT плюс ещё шесть языков), и без hreflang Google не сможет правильно маршрутизировать пользователей разных гео.

E-E-A-T-фреймворк: авторы, методология, источники

Если Schema-разметка — это машинная инфраструктура авторитета, то E-E-A-T — это человеческая. И именно здесь мы вложили больше всего ручного труда, потому что обнулить никаким алгоритмом или плагином невозможно — нужны реальные эксперты с реальной публичной историей.

Команда редакции платформы — это несколько профильных специалистов с подтверждаемой профессиональной биографией: специалист по автомобильной аналитике, технический редактор с фокусом на электромобили и силовые установки, ревьюер по Schema и техническому SEO, отдельная Technical Reference Team для сложных технических материалов. Каждый получил персональную страницу под адресом /en/authors/{slug} с биографией, фотографией, описанием профессионального опыта, ссылками на профили в LinkedIn и XING, перечнем тем экспертизы (поле knowsAbout в Schema), списком опубликованных на платформе материалов.

Каждая статья начинает помечаться конкретным автором с миниатюрой и блоком «Об авторе» перед текстом и после него. На страницах сравнений в author-box стоят сразу два значимых сигнала — должность с кратким credential («Driven both gens», «Two-source verified») и явная подпись о методе верификации фактов. Эти «two-source verified» бейджи — машинно-читаемый сигнал, который попадает в model context при цитировании LLM-системами.

Параллельно с внутренней работой запущено внешнее наращивание видимости экспертов в немецкоязычном профессиональном поле. Это не классический линкбилдинг — это нарабатывание digital footprint авторов через публикации в профильных отраслевых блогах, интервью на нишевых YouTube-каналах автомобильной тематики, участие в отраслевых конференциях с публикуемыми спикерскими профилями, ответы на запросы журналистов через немецкие HARO-аналоги. Каждое такое внешнее упоминание усиливает entity-сигнал автора и косвенно — entity-сигнал самой платформы как места его работы.

Страница методологии (/en/methodology) — отдельная критическая часть E-E-A-T-фундамента. На ней детально описано, откуда платформа берёт данные, как их верифицирует, какова политика исправлений ошибок, как работает Vier-Augen-Prinzip (принцип проверки в четыре глаза, классическая немецкая методология контроля качества). Эта страница ссылается с каждой content-страницы через секции «Methodology» и «Sources», и из неё ссылки расходятся обратно на типы контента и на авторов. Получается замкнутый граф доверия.

Иерархия источников данных, на которые ссылается платформа, формализована в три уровня. Уровень первый — первичные источники: KBA (Kraftfahrt-Bundesamt, немецкое федеральное автомобильное управление), пресс-релизы производителей, Euro NCAP, ADAC, Umweltbundesamt. Уровень второй — авторитетные индустриальные источники: S&P Global Mobility, Dataforce, JATO Dynamics. Уровень третий — журналистские источники: Automobilwoche, Automotive News Europe, Reuters. В каждой статье обязательны инлайн-цитирование плюс отдельная секция «Sources» внизу с указанием источника и датой проверки. Таблицы с данными — также с указанием источника и timestamp. Это решает сразу две задачи: даёт читателю возможность верифицировать факты и одновременно даёт LLM-системам цитируемые источники второго уровня, к которым они могут вернуться при формировании ответа пользователю.

Сигналы Experience (первая E в E-E-A-T) — это отдельная работа. На каждой странице сравнения, каталожной странице и аналитическом материале добавляются признаки реального опыта взаимодействия с темой: оригинальный анализ данных KBA с собственными графиками, скриншоты реальных немецких автомобильных процессов (Zulassungsstelle для регистрации, TÜV для технического осмотра), личные расчёты стоимости владения, повествование от первого лица в guide-материалах, фотодокументация. Это убирает у Google и LLM-систем подозрение в том, что контент написан удалённым автором, никогда не имевшим дела с темой непосредственно.

Топикальный авторитет через магазин: четыре кластера за десять недель

Помимо архитектуры каталога, архива и сравнений, отдельная критическая часть проекта — это магазин (редакционный блог) /en/magazine/. Его задача — построить топикальный авторитет в немецкоязычном автомобильном поле для англоязычной аудитории через систему четырёх топикальных кластеров.

Как оказалось после внедрения топикальной архитектуры на сайте — Быстро в топ вышли только топикальные кластеры.

Каждый кластер построен по модели Hub-and-Spoke: одна пилларная статья объёмом 4000–5000 слов, дающая обзор всей подтемы, и набор спок-статей по 2000–3500 слов, раскрывающих конкретные аспекты. Перекрёстные ссылки между кластерами создают плотную семантическую сеть.

Кластер первый — Buying Guides под URL /en/magazine/buying-guides/. Приоритет номер один. Пилларная статья — «The Complete Guide to Buying a Car in Germany as an Expat» на 4200 слов. Споки покрывают темы немецкой автомобильной страховки (Haftpflicht, Teilkasko, Vollkasko), процедуры TÜV/HU, регистрации автомобиля через Zulassungsstelle, оценки рыночной стоимости по Schwacke-листу, сравнения платформ покупки на немецком рынке, финансирования через Kredit/Leasing/Ballonfinanzierung, типов специальных немецких авто (Jahreswagen, Vorführwagen, Tageszulassung), полной стоимости владения с актуальными данными 2026 года, и расчёта Kfz-Steuer. Десять статей в первой фазе.

Кластер второй — Market Analytics. Пилларная статья «German Car Market Report: KBA Data Analysis» обновляется ежемесячно с новыми регистрационными данными. Споки — аналитические разборы: реальная динамика adoption электромобилей в Германии, выход китайских брендов (BYD, MG), темпы амортизации по брендам, разбор популярных моделей по KBA, квартальные обзоры рынка. Восемь статей.

Кластер третий — Technical Reference. Пилларная статья «How We Compare Cars: Testing & Verification Methodology» (по сути расширенная версия страницы методологии для глубокой публикации). Споки — разборы силовых установок (ICE, HEV, PHEV, BEV, FCEV), Euro NCAP, рейтингов надёжности ADAC, технологий батарей, автомобильных платформ. Помимо классической SEO-функции, эти материалы цементируют экспертный статус платформы — на них активно ссылаются журналисты и блогеры.

Кластер четвёртый — History. Истории брендов (VW, BMW, Mercedes, Porsche), знаковые модели, история мотоспорта, эволюция дизайна. Этот кластер имеет низкую коммерческую ценность, но высокий потенциал заработка качественных бэклинков и социальных шеров. Три статьи истории вплетены в первые три фазы как перекрёстные ссылки, расширяющие смысловое поле платформы.

Тридцать статей за десять недель. Темп 2-3 материала в неделю, что для редакции из двух-трёх человек плюс внешний копирайтер — реальная нагрузка без потери качества.

Цель — Topic Coverage Ratio минимум 70% в кластере Buying Guides к десятой неделе. Это базовая метрика топикального авторитета, заменяющая классическое отслеживание позиций. Ranking Distribution (количество страниц в топ-10/20/50 по кластерным запросам), Impressions Growth (рост показов по группам запросов кластера как опережающий индикатор), Average CTR на топикальные запросы — три дополнительные метрики, которые трекаем еженедельно через GSC.

Реалистичный таймлайн результатов, основанный на опыте предыдущих проектов с топикальным авторитетом: первый рост показов в GSC по ключам кластера ожидается на неделях 3-4, первые позиции в топ-20 по низкоконкурентным запросам (типа «Schwacke list expat», «TÜV inspection Germany English») — недели 5-6, значимый рост органического трафика и выход материалов в топ-10 — недели 7-8, полный топикальный авторитет по основному кластеру — после недели 10.

AI-инфраструктура: что мы делаем для машин

Отдельный слой работы, который большинство SEO-специалистов в СНГ ещё не освоили — это техническая инфраструктура для AI-краулеров и LLM-индексаторов. Это не альтернатива классическому SEO, это надстройка поверх него.

Что конкретно мы внедрили на уровне инфраструктуры.

llms.txt — машиночитаемое описание платформы и API-эндпоинтов в формате текстового файла в корне сайта. По сути это файл инструкций для AI-краулеров, аналог robots.txt, но с описанием контента и его структуры. Ссылка на llms.txt стоит в <head> каждой страницы и в footer. В файле описана структура платформы (разделы, API), указаны лицензионные условия использования данных, перечислены типы контента и для каждого — рекомендуемый способ цитирования.

Полная разметка Schema.org в JSON-LD @graph формате — об этом подробно выше. Главное здесь то, что разметка стоит на каждой странице, использует @id для перекрёстных связей и sameAs для дисамбигуации сущностей через Wikidata и Wikipedia.

Семантический HTML5 без div-каши. Article, section, nav, header, footer, aside — используются по назначению, чтобы парсеры без headless browser могли строить корректную модель страницы. Все ключевые цифры и факты — в чистом HTML, доступны без выполнения JavaScript, потому что AI-краулеры в подавляющем большинстве не запускают JS и видят только серверный рендеринг.

Open Graph плюс Twitter Card теги полные, с og:image для каждой страницы. Это даёт корректные превью при шеринге, но что важнее — попадает в обучающие выборки и в RAG-индексы AI-систем.

Метатег ai-content-declaration с тремя значениями: editorial-reviewed, human-authored, data-verified. Это сигнал AI-систем о том, что контент прошёл редакционную проверку, написан человеком, и данные верифицированы. На фоне массового AI-сгенерированного шума 2024-2025 годов такой сигнал начинает играть роль фактора доверия.

robots.txt не блокирует основные AI-краулеры. Если вы хотите быть цитируемыми в ChatGPT, Claude, Perplexity и Google AI Overviews — соответствующие user-agent’ы (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) должны иметь доступ. Многие сайты по инерции блокируют их через robots.txt из опасений по копирайту, но платой за такую блокировку становится исчезновение из AI-цитируемости. Мы это не блокируем сознательно — наоборот, хотим быть в этих обучающих и retrieval-выборках.

Sitemap.xml с правильными priority и lastmod. Comparison-detail имеет priority 0.8, brand 0.7, model 0.7, hub 0.6. lastmod обновляется при каждом edit. Это даёт краулерам сигнал о свежести и относительной важности секций.

Пять признаков «цитируемого» LLM-контента, к которым мы пришли через анализ публикаций Anthropic, OpenAI и Perplexity по retrieval-стратегиям, выглядят так. Первое — named author с credentials, потому что LLM активно используют авторство как сигнал доверия. Второе — two-source verified facts, что мы зашили прямо в author-box в виде явного бейджа. Третье — структурированные comparison tables с чёткими метриками и единицами измерения, потому что LLM хорошо парсят таблицы. Четвёртое — явные даты publication и last-modified, потому что LLM учитывают свежесть. Пятое — methodology link на каждой странице с фактами, что даёт LLM возможность верифицировать подход.

Что мы НЕ делаем сознательно. Не используем «AI-friendly content plugins» категории «ChatGPT-optimized» — это маркетинговый шум, который добавляет в контент бойлерплейт без реальной пользы. Не дублируем контент в специальные «AI-version» страницы — это путь к каннибализации и сниженному качеству. Не пишем «как будто для AI» — пишем для человека, но с правильной структурой, разметкой и сигналами, которые AI читает.

Что мы уже видим: первые сдвиги

Платформа сейчас находится в середине цикла перестройки — основная архитектурная работа завершена, контент-производство в Magazine идёт по плану, первые сравнения по новой архитектуре опубликованы. Полных результатов восстановления после Core Update ещё нет — нужно как минимум два-три месяца, чтобы Google переоценил сайт по новой структуре, и параллельно ещё столько же, чтобы AI-индексаторы наработали достаточное количество references на нас в своих обучающих и retrieval-данных.

Но первые сигналы уже видны. По логам и через прямой мониторинг AI Overviews по 80 ключевым запросам ниши мы видим, что упоминания платформы в нейроответах начали появляться. Не системно — пока единичные кейсы, но они есть. Чаще всего цитируется контент с самой плотной разметкой и явными источниками — страница методологии, аналитические материалы с данными KBA, страницы сравнений с two-source verified badge. Это подтверждает, что выбранный стек сигналов работает в нужную сторону.

В Search Console показы начали расти по запросам, на которые мы целенаправленно строили контент в Buying Guides — особенно по англоязычным запросам экспат-аудитории про Schwacke, TÜV, Zulassung. Эти запросы низкочастотные в абсолютном выражении, но они высококонверсионные с точки зрения вовлечения — пользователь, ищущий «Schwacke list expat Germany», находится в активной фазе принятия решения, не в режиме «почитать на досуге».

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

Ошибки, на которых сэкономлю время другим

Несколько вещей, которые я бы сделал по-другому, если бы начинал проект сначала.

Первое — не пытаться сохранять старый тонкий контент. На старте я тратил несколько недель на попытку расширить и улучшить 1200 старых тонких автогенерированных страниц вместо того, чтобы сразу применить noindex или полностью убрать их. Расширение шаблонных страниц редко даёт результат — они остаются распознаваемо шаблонными даже после переписывания. Лучше радикально сократить количество страниц и оставить только те, которые имеют редакционную ценность, чем растягивать ресурс на спасение пула, который Google уже отметил как низкокачественный.

Второе — не откладывать страницу методологии. Это та страница, без которой E-E-A-T-сигналы не складываются в систему. Я подспудно откладывал её на «когда будет время», потому что она не приносит трафика сама по себе. Это ошибка. Страница методологии не приносит трафика напрямую, но она резко повышает машинное доверие ко всем остальным страницам сайта через перекрёстные ссылки на неё из секций «Sources» и «Methodology» в каждом материале.

Третье — не недооценивать важность Schema.org @graph по сравнению с одиночной разметкой. На старте я использовал классический подход «один Schema-тип на страницу» и думал, что этого достаточно. После перехода на полный @graph с перекрёстными ссылками между нодами и явными sameAs на Wikidata, видимость в AI-ответах начала меняться. Современные LLM-краулеры читают именно граф связей сущностей, а не отдельные изолированные ноды. Время, потраченное на построение полноценного @graph, окупается тем, что становится возможным машинное чтение страницы как структурированной базы знаний.

Четвёртое — не путать Article и NewsArticle. Один из ранних аудитов показал, что половина evergreen-материалов на сайте была размечена как NewsArticle. Google от этого терял, во-первых, eligibility для Top Stories (потому что Top Stories требует свежести и оперативной актуальности), а во-вторых, корректное понимание типа контента. После приведения разметки в порядок — NewsArticle только в /news/, Article везде остально — поведение поиска по этим страницам нормализовалось.

Пятое и самое стратегическое — раньше определять позиционирование. Если бы я с первой же недели проекта зафиксировал «Die unabhängige technische Fahrzeug-Referenz» как ядро всей коммуникации, многие архитектурные решения сложились бы быстрее. Позиционирование — это не маркетинговый слайд, это основа, на которой стоит и SEO-стратегия, и Schema-разметка, и контент-план, и набор партнёрств. Не стоит начинать с тактики, пока не зафиксирована стратегическая формулировка.

Что забирать с собой

Если у вас информационно-сервисный проект, попавший под Core Update декабря 2025 или ожидающий следующий — несколько ключевых тезисов.

Старые правила SEO больше не дают полной картины. Технический аудит, скорость, базовая Schema, ссылки — это всё ещё необходимо, но уже не достаточно. Нужен слой GEO/LLM поверх классического SEO, иначе при растущем zero-click и AI-mediated discovery трафик деградирует не количественно, а качественно.

Архитектура важнее тактики. Разделение типов контента по URL-структуре, по Schema, по визуальным признакам, по хлебным крошкам — это фундамент, который определяет, насколько Google и LLM смогут понимать вашу платформу. Если архитектура спутанная, никакая работа над контентом не вытянет позиции.

Schema.org @graph с перекрёстными ссылками между нодами и sameAs на Wikidata — это базовый стек 2026 года. Одиночная разметка одного типа на страницу больше не работает. Граф сущностей — работает.

E-E-A-T должен быть зашит на уровне инфраструктуры, не косметически. Реальные авторы с публичной digital footprint, страница методологии с детальным описанием подхода, явная иерархия источников и инлайн-цитирование, признаки experience через первое лицо, фотодокументацию и оригинальный анализ данных. Без этого AI-системы не начнут цитировать вас как авторитетный источник.

AI-краулеры — это новые SEO-агенты. GPTBot, ClaudeBot, PerplexityBot, Google-Extended должны иметь доступ к сайту. llms.txt должен существовать. Метатег ai-content-declaration должен быть на каждой странице. Это работа, которая в 2024 была экзотикой, в 2025 — рекомендуемой практикой, в 2026 — базовой гигиеной.

И главное — позиционирование первично. Если вы не можете в одной фразе сказать, что такое ваш проект и чем он отличается от соседей по нише, ни SEO, ни GEO, ни LLM-оптимизация не помогут. Они только усилят сигнал того позиционирования, которое уже есть. А если его нет — усилят пустоту.

Пишите в комментариях, какие из подходов вы пробовали применять у себя, и где встречались с подводными камнями. Кейс live, проект продолжает работу, через 2-3 месяца планирую отдельную публикацию с конкретными цифрами восстановления после полного цикла перестройки.