Дубли страниц и rel=canonical: как найти и устранить дубликаты на сайте

Дубли страниц — одна из самых недооценённых технических проблем в SEO: сайт вроде бы работает, страницы открываются, а позиции стоят на месте или медленно проседают. Причина часто в том, что поисковик видит десятки почти одинаковых URL и не понимает, какой из них главный. В этой статье разберём, что такое дубли страниц, откуда они берутся, чем опасны и как их находить. Отдельно — про rel=canonical: как правильно прописывать канонические URL, когда canonical лучше 301-редиректа, а когда нужен noindex. Материал рассчитан на владельцев сайтов, маркетологов и начинающих SEO-специалистов, которые хотят навести порядок в индексации без риска потерять трафик. В конце — пошаговый план, как убрать дубли на сайте, чек-лист типичных ошибок и особенности для Яндекса и Google.

Что такое дубли страниц простыми словами

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

Разберём на простом примере. Карточка товара доступна по адресу с параметром сортировки ?sort=price, с UTM-меткой ?utm_source=vk, со слэшем на конце и без него. Итого четыре адреса — и один и тот же текст, одни и те же фото, одна цена. Для пользователя разницы нет. Для поисковика это четыре конкурирующих между собой документа.

Важно различать два понятия. Дубли — это непреднамеренное размножение одного контента по разным URL внутри вашего сайта. Плагиат или воровство контента — это когда ваш текст скопировали на чужой ресурс. Механика разная, и способы борьбы тоже: с внутренними дублями работают технически (canonical, редиректы, настройка CMS), с внешними — жалобами и защитой авторства.

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

Ключевая мысль, с которой стоит начать наведение порядка: у каждого смыслового блока контента должен быть один канонический адрес. Не «примерно один», а строго один — тот, который вы осознанно выбрали для индексации и на который ведёте внутренние ссылки. Всё остальное — технические варианты того же документа, и их задача не конкурировать с оригиналом, а честно указывать на него. Именно из этого принципа вырастают все дальнейшие инструменты: rel=canonical, 301-редиректы, настройка параметров и правильная перелинковка.

Виды дублей: полные, частичные и технические

Дубли делятся на полные (контент совпадает целиком) и частичные (совпадает существенная часть), а по природе — на технические, генерируемые самой системой, и контентные, возникающие из-за структуры сайта. Понимание типа сразу подсказывает способ лечения: одни адреса достаточно склеить canonical, другие — закрыть от индексации, третьи — переписать.

Полные дубли — самый очевидный случай: две страницы отдают идентичный HTML. Классика — версия со слэшем и без, http и https, www и без него, главная страница по адресу с /index.php и по корню. Пользователь видит одно и то же, робот — разные документы.

Частичные дубли опаснее, потому что их сложнее заметить. Это страницы фильтров и сортировок в каталоге, пагинация, версии для печати, карточки, отличающиеся одним параметром, или разные категории с почти одинаковым описанием. Контент пересекается на 70–90%, и поисковик воспринимает такие страницы как малополезные и вторичные.

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

Откуда берутся дубли: главные причины

В подавляющем большинстве случаев дубли порождает не человек, а сама CMS и настройки сервера: движок генерирует технические URL с параметрами, сервер отдаёт страницу по нескольким вариантам адреса, а маркетинг добавляет метки. Знать источники важно, потому что бороться нужно с причиной, а не с бесконечным потоком следствий.

Основные источники дублей на сайте:

• GET-параметры. Сортировки, фильтры, пагинация, идентификаторы сессий и партнёрские метки создают новые URL при том же контенте. Один товар легко превращается в десятки адресов.
• UTM-метки и рекламные параметры. Каждая рекламная кампания добавляет к адресу хвост вроде ?utm_source=&utm_medium=. Если такие URL попадают в индекс, они конкурируют с чистой версией.
• Зеркала сайта. Доступность по www и без, по http и https без склейки даёт до четырёх копий каждой страницы.
• Слэш и регистр. Сервер отдаёт документ и со слэшем, и без, и с разным регистром букв в пути.
• Пагинация и фильтры каталога. Комбинации фильтров множат почти одинаковые листинги.
• Технические разделы. Версии для печати, тестовые поддомены, копии на CDN, устаревшие мобильные версии.

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

Чем дубли вредят продвижению: краулинговый бюджет и каннибализация

Дубли вредят тремя способами: они распыляют краулинговый бюджет, размывают релевантность между конкурирующими URL и мешают накапливать поведенческие и ссылочные сигналы на одной сильной странице. По отдельности каждый эффект неочевиден, но вместе они заметно тормозят рост.

Краулинговый бюджет. Поисковый робот обходит ограниченное число URL за визит. Если половина этого лимита уходит на технические копии, важные страницы обходятся реже, новые товары и статьи попадают в индекс с задержкой, а обновления подхватываются медленнее. На небольшом сайте это почти незаметно, но на крупном каталоге с десятками тысяч страниц разница в скорости индексации становится критичной. Точную величину потерь заранее назвать нельзя — она зависит от размера сайта, частоты обновлений и авторитетности домена, — но направление всегда одно: чем больше мусора, тем медленнее работает индексация полезного.

Каннибализация. Когда несколько URL претендуют на один и тот же запрос, поисковик вынужден выбирать между ними и может выбрать не ту версию — например, страницу с параметром вместо чистой, или слабый фильтр вместо основной категории. В результате позиции «прыгают», в выдачу попадает то один адрес, то другой, а суммарный сигнал релевантности размывается вместо того, чтобы концентрироваться на одном документе.

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

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

Как найти дубли страниц на сайте: инструменты и методы

Найти дубли страниц можно тремя взаимодополняющими способами: через панели вебмастеров (Яндекс.Вебмастер и Google Search Console), через десктопные краулеры-парсеры и вручную через поисковые операторы. Ни один метод не даёт полной картины в одиночку, поэтому опытные специалисты комбинируют минимум два.

Панели вебмастеров. В Google Search Console смотрите отчёт об индексировании: статусы вроде «Страница является копией, канонический вариант не выбран пользователем» или «Проиндексировано без отправки в sitemap» прямо указывают на дубли. В Яндекс.Вебмастере полезны разделы страниц в поиске, исключённых страниц и отчёт по дублям, где сервис сам группирует адреса с одинаковым контентом. Это самый достоверный источник, потому что показывает, как видит сайт именно поисковик.

Краулеры-парсеры. Программы вроде Screaming Frog, Netpeak Spider или аналогов обходят сайт как робот и находят страницы с одинаковыми Title, Description, H1 и хешем контента. Совпадающие метатеги — почти безошибочный маркер дублей. Такой обход выявляет проблемы ещё до того, как мусор попадёт в индекс, что особенно ценно перед запуском или после доработок.

Ручная проверка операторами. Запрос вида site:вашдомен.ru в поиске показывает примерное число проиндексированных страниц — если оно в разы больше реального количества, это тревожный сигнал. Оператор с уточнением по фрагменту текста помогает найти, по скольким адресам продублирован конкретный абзац.

Практический порядок работы при поиске дублей:

1. Сверьте число проиндексированных страниц с реальным количеством товаров и статей.
2. Выгрузите из панелей вебмастеров исключённые и «слабые» страницы.
3. Прогоните сайт парсером и отсортируйте по повторяющимся Title и H1.
4. Сгруппируйте найденное по типам: параметры, зеркала, слэши, пагинация.
5. Для каждой группы выберите одно системное решение, а не правьте адреса поштучно.

Комплексный технический аудит, в котором дубли ищут одновременно всеми методами и сразу увязывают с картой редиректов, — типовая услуга в арсенале агентства Seotika; в нишевых проектах такой аудит обычно вскрывает основную массу проблем ещё на старте.

Что такое rel=canonical и как он работает

Rel=canonical — это указание для поисковой системы, какой из нескольких похожих URL считать основным (каноническим), чтобы именно он индексировался и участвовал в выдаче, а его копии передавали ему свои сигналы. Технически это атрибут, который сообщает роботу: «этот документ — вариант вон того главного, объедини их и показывай главный».

Работает механизм так. На странице-дубле в секции <head> размещается тег со ссылкой на канонический адрес. Робот, обходя дубль, видит указание и в большинстве случаев склеивает страницы: в индекс попадает канонический URL, а накопленные копией сигналы (ссылки, релевантность) переходят к нему. Важно понимать, что canonical — это рекомендация, а не жёсткая директива. Поисковик учитывает её вместе с другими факторами и в спорных случаях может выбрать другую каноническую версию.

Канонический URL

Основной адрес страницы, который вы выбрали для индексации; на него указывают все дубли.

Self-canonical

Страница указывает canonical сама на себя — стандартная и рекомендуемая практика для всех основных страниц.

Cross-canonical

Дубль указывает canonical на другую страницу — так объединяют технические копии с оригиналом.

Канонизация

Процесс выбора поисковиком одного основного URL из группы похожих.

Ключевое отличие canonical от редиректа в том, что обе страницы остаются доступными для пользователя. Посетитель по-прежнему может открыть версию с фильтром или сортировкой и увидеть нужный ему результат — а поисковик при этом индексирует одну чистую версию. Именно поэтому canonical незаменим там, где страница-дубль нужна людям, но не нужна в индексе: сортировки в каталоге, UTM-версии, пагинация с параметрами.

Ещё один важный нюанс — согласованность сигналов. Canonical не должен противоречить остальным указаниям: если страница отдаёт canonical на один адрес, но при этом закрыта в robots.txt, помечена noindex или ведёт через редирект на третий URL, робот получает конфликтующие команды и может проигнорировать всё сразу. Канонический адрес должен быть доступен, отдавать код 200 и сам на себя указывать self-canonical. Тогда вся группа копий надёжно сходится к одной точке, и поисковик получает однозначный сигнал, какую версию продвигать.

Как правильно прописать канонические URL

Прописать канонический URL можно двумя способами: тегом <link rel="canonical"> в HTML-коде страницы или HTTP-заголовком Link для файлов, где нет HTML (например, PDF). В обоих случаях указывается один абсолютный адрес — тот, который вы выбрали основным.

Базовый вариант выглядит так — в секции <head> каждой страницы:

<link rel="canonical" href="https://site.ru/catalog/tovar">

Правила, которые нельзя нарушать:

• Только абсолютный URL. Указывайте полный адрес с протоколом и доменом, а не относительный путь. Относительные ссылки в canonical — частый источник ошибок.
• Один canonical на страницу. Два тега canonical на одной странице аннулируют друг друга — робот проигнорирует оба.
• Канонический адрес доступен и отдаёт 200. Нельзя каноникализировать на страницу с редиректом, ошибкой 404 или закрытую в noindex.
• Согласованность с зеркалом. Если основное зеркало — https без www, все canonical должны вести именно на такие адреса, без разнобоя в протоколе, регистре и слэшах.
• Self-canonical на основных страницах. Каждая важная страница должна указывать canonical сама на себя — это защищает от случайной генерации параметров.

Для нестандартных случаев используют HTTP-заголовок. Например, для документа без HTML сервер отдаёт заголовок вида Link: <https://site.ru/doc.pdf>; rel="canonical". Это полезно, когда файлы индексируются и их нужно привязать к основной странице.

Отдельная тема — canonical и пагинация. Раньше применяли связку rel="next" и rel="prev", но сейчас поисковики их фактически не учитывают. Практичный подход: каждая страница пагинации указывает canonical сама на себя (не на первую страницу), а уникальность обеспечивается корректными Title с номером страницы. Каноникализировать все страницы листинга на первую — распространённая ошибка: так вторая, третья и последующие страницы выпадают из индекса вместе со всеми товарами, которые есть только на них.

Canonical или 301-редирект: что выбрать

Выбор между canonical и 301-редиректом определяется одним вопросом: нужна ли страница-дубль пользователю. Если вариант URL реально используется людьми — ставьте canonical и оставляйте страницу доступной; если это лишний технический адрес, который человеку не нужен, — делайте 301-редирект и убирайте дубль физически.

301-редирект — это жёсткая переадресация: пользователь и робот, попав на старый адрес, автоматически перебрасываются на новый, а старый URL перестаёт существовать в выдаче и передаёт почти весь свой вес целевому. Это самое сильное и однозначное решение, но и самое бескомпромиссное — вернуться на исходную страницу уже нельзя.

Главное правило: не редиректьте то, что нужно людям, и не каноникализируйте то, что должно быть удалено. Если 301-редиректом закрыть страницу фильтра, пользователь, перешедший по сохранённой ссылке, не увидит нужный ему отфильтрованный результат. И наоборот — оставлять доступными десятки технических зеркал через canonical бессмысленно, когда их можно просто склеить редиректом раз и навсегда.

Есть и промежуточные случаи. Например, при объединении двух похожих категорий, обе из которых собирают трафик, иногда разумнее не резать одну редиректом сразу, а сначала поставить canonical, отследить перераспределение позиций и лишь потом принять окончательное решение. В отличие от 301, canonical обратим: снял тег — страница снова самостоятельна. Эта обратимость делает его удобным инструментом для аккуратных экспериментов с индексацией, тогда как редирект стоит применять там, где решение окончательное.

Canonical, noindex и robots.txt: в чём разница

Canonical, noindex и robots.txt решают разные задачи и не заменяют друг друга: canonical объединяет похожие страницы и передаёт вес основной, noindex запрещает индексировать страницу, а robots.txt запрещает роботу её обходить. Путаница между ними — источник половины проблем с индексацией, поэтому важно чётко понимать зону ответственности каждого.

Главная ловушка — закрывать дубли в robots.txt в надежде убрать их из индекса. Это не работает так, как ожидают. Если страница запрещена к обходу, робот не может зайти на неё и прочитать ни canonical, ни noindex. В результате указания игнорируются, а сам URL при этом может остаться в выдаче как «страница без описания» — потому что о её существовании поисковик знает по ссылкам, а содержимое прочитать ему запрещено.

Практическая логика выбора такая. Нужно склеить дубль и передать вес основной странице — canonical. Нужно, чтобы страница существовала для людей, но не индексировалась и не мешала — noindex (при открытом обходе). Нужно вообще не пускать робота в раздел (например, личный кабинет, корзину, служебные скрипты) — robots.txt. Нужно навсегда убрать адрес — 301. Часто на реальном сайте применяются все четыре инструмента, но каждый — строго по своему назначению, и именно грамотное распределение ролей между ними отличает аккуратную техническую оптимизацию от хаотичного затыкания дыр.

Типичные ошибки при работе с canonical

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

Разберём главные ошибки подробно:

• Canonical на редирект или 404. Канонический адрес обязан отдавать код 200. Если он ведёт на страницу с переадресацией или ошибкой, робот не может считать её основной и отбрасывает указание целиком.
• Относительный URL вместо абсолютного. Робот может неверно достроить путь, особенно на сайтах со сложной структурой. Всегда указывайте полный адрес с протоколом и доменом.
• Несколько canonical на странице. Два тега — и оба аннулируются. Часто это результат того, что canonical добавляют и в шаблоне, и через плагин одновременно.
• Конфликт с noindex или robots.txt. Противоречивые сигналы заставляют поисковик игнорировать всё сразу.
• Разнобой в зеркалах. Часть canonical ведёт на https, часть на http, где-то со слэшем, где-то без. Единого основного адреса не получается.
• Каноникализация разных страниц на одну. Если непохожие товары или категории массово указывают canonical на одну «главную», поисковик видит подмену и просто перестаёт доверять указаниям на сайте.

Ещё одна коварная ошибка — canonical на страницы пагинации с первой страницы. Каноникализировав вторую, третью и последующие страницы листинга на первую, вы фактически вычёркиваете из индекса товары и статьи, которые встречаются только на этих страницах. Правильно — self-canonical на каждой странице пагинации.

Отдельно стоит проверять динамически подставляемый canonical. На сайтах, где адрес формируется скриптом, canonical иногда «уезжает» вместе с параметрами: например, страница с UTM-меткой указывает canonical сама на себя вместе с меткой вместо чистого URL. В итоге в индекс попадает грязная версия. Проверять canonical нужно не в шаблоне, а на живых страницах — открыв исходный код реальных URL с параметрами и убедившись, что тег ведёт именно на канонический адрес. Регулярная сверка после каждой доработки CMS избавляет от 90% таких сюрпризов; в проектах, где эту сверку ставят на поток, дубли перестают возвращаться после релизов.

Как убрать дубли на сайте: пошаговый план

Чтобы убрать дубли на сайте, нужно пройти пять этапов: собрать все версии URL, выбрать каноническую, применить к каждой группе правильный инструмент (canonical, 301 или noindex), настроить CMS на уровне шаблонов и проверить результат в панелях вебмастеров. Работа системная, но при последовательном подходе укладывается в понятный алгоритм.

Пошаговый план:

1. Аудит и сбор. Прогоните сайт парсером, выгрузите исключённые страницы из Search Console и Яндекс.Вебмастера, сверьте число проиндексированных URL с реальным. Соберите полный список дублей.
2. Группировка. Разложите найденное по типам: зеркала, слэши и регистр, GET-параметры, UTM, пагинация, фильтры, технические копии. Для каждой группы будет своё системное решение.
3. Выбор канонического адреса. Определите одно основное зеркало (обычно https без www) и для каждого блока контента — один канонический URL. Зафиксируйте правила: протокол, слэш, регистр.
4. Применение инструментов. Зеркала, слэши и старые URL — 301-редиректом. Сортировки, метки и параметры — canonical. Служебные и тонкие страницы — noindex. Разделы, куда роботу вообще не нужно, — robots.txt.
5. Настройка на уровне CMS. Пропишите self-canonical в шаблонах, настройте ЧПУ, обработку параметров, автоматическую генерацию корректных Title. Цель — чтобы дубли не появлялись заново.
6. Проверка и мониторинг. Через несколько недель сверьте, как изменился индекс, ушли ли дубли из выдачи, не пропало ли лишнее. Настройте регулярную проверку после каждой доработки.

Отдельно про сроки. Внести технические правки можно за считанные дни, но переиндексация занимает время: поисковикам нужно повторно обойти страницы, учесть указания и пересобрать индекс. В зависимости от размера и авторитетности сайта заметный результат обычно проявляется в диапазоне от пары недель до пары месяцев. Наберитесь терпения и не откатывайте изменения раньше времени. Комплексную чистку индекса с последующим мониторингом удобно вести в связке с общей технической оптимизацией — именно так эту задачу обычно решает агентство Seotika, увязывая устранение дублей с картой редиректов, sitemap и перелинковкой в единый план.

Дубли в Яндексе и Google: различия и работа с параметрами

Яндекс и Google по-разному обрабатывают дубли и параметры URL, поэтому одной универсальной настройки недостаточно — нужно учитывать особенности каждой системы. Основное различие в том, что у Яндекса есть отдельный механизм для обработки незначащих GET-параметров через директиву Clean-param в robots.txt, тогда как Google опирается прежде всего на canonical и собственные алгоритмы канонизации.

Яндекс и Clean-param. Директива Clean-param в robots.txt сообщает роботу Яндекса, что указанные параметры не влияют на содержимое страницы и их можно игнорировать при обходе. Например, для UTM-меток и идентификаторов сессий это позволяет роботу не плодить лишние URL и обходить только чистую версию. Это экономит краулинговый бюджет эффективнее, чем один только canonical, потому что робот вообще не тратит ресурсы на грязные адреса. Важно: Clean-param — специфичная для Яндекса директива, Google её не понимает.

Google. Раньше в Search Console был инструмент обработки параметров URL, но он давно закрыт. Сейчас Google рекомендует полагаться на rel=canonical, логичную структуру ссылок и, при необходимости, на управление сканированием через robots.txt. Google в целом более самостоятельно определяет каноническую версию и иногда выбирает не тот URL, что указан в canonical, если сочтёт его более подходящим — например, по внутренним ссылкам или sitemap.

Практический вывод: используйте оба подхода вместе. Для Яндекса добавьте Clean-param для рекламных и сессионных параметров, для обеих систем настройте корректные self-canonical и единое зеркало через 301. Такая двойная страховка охватывает и специфику Яндекса, и логику Google. При этом не забывайте, что обе системы всё активнее опираются на общее качество и структуру сайта, а чистая, непротиворечивая техническая база одинаково полезна и для классической выдачи, и для карт, и для новых форматов на основе нейросетей.

Дубли, GEO/AEO и перелинковка: почему чистая структура важна для нейровыдачи

Чистая структура без дублей напрямую влияет на видимость сайта в нейросетевых ответах (GEO/AEO), потому что языковые модели и ассистенты, как и классические поисковики, должны понять, какая страница — авторитетный первоисточник по теме. Когда контент размазан по десяткам похожих URL, ни один из них не выглядит однозначным ответом, и шанс попасть в цитируемый ответ падает.

GEO (Generative Engine Optimization) и AEO (Answer Engine Optimization) — это оптимизация под ответы, которые формируют нейросети и голосовые ассистенты вместо привычного списка ссылок. Такие системы ценят структурированный, однозначный контент с чёткой каноничностью. Если у вас пять версий одной статьи, модель либо выберет случайную, либо не выберет ни одной, предпочтя более аккуратный источник конкурента. Устранение дублей и концентрация сигналов на одном каноническом URL повышают вероятность, что именно ваша страница станет тем самым первоисточником для ответа.

Связь с внутренней перелинковкой здесь прямая. Когда canonical и редиректы наведены, все внутренние ссылки ведут на канонические адреса, а не на их технические копии. Это усиливает смысловые связи между разделами: услуги, кейсы, статьи и смежные материалы сшиваются в понятную для машины структуру. Аккуратная перелинковка на чистые URL помогает и классическому SEO, и GEO/AEO одновременно — робот и модель одинаково легче выстраивают карту тематической экспертности сайта.

Стоит смотреть на дубли шире, чем на техническую мелочь. Порядок в индексации — часть общей репутационной гигиены наравне с работой над SERM, присутствием в картах и качеством контента. Разрозненный, противоречивый сайт хуже воспринимается и людьми, и алгоритмами; собранный и структурированный — вызывает доверие и охотнее цитируется. Наведение технической чистоты, грамотная перелинковка и подготовка контента под нейровыдачу — задачи одного порядка, и в проектах агентства Seotika они решаются в связке: устранение дублей становится фундаментом, на который затем ложатся семантика, контент и работа над видимостью в новых форматах выдачи. Итог такой работы — сайт, где каждая тема представлена одной сильной страницей, которую одинаково уверенно показывают и поисковик, и нейросеть.