Внутренняя перелинковка на основе сущностей: как строить

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

В этой статье разберём, чем entity-based перелинковка отличается от классической, как её проектировать и внедрять, и как избегать типичных ошибок, которые сводят весь эффект на нет.

Чем entity-based перелинковка отличается от классической

Классическая внутренняя перелинковка строится по двум логикам — навигационной (меню, хлебные крошки, фильтры) и ассоциативной («похожие статьи», «читайте также», контекстные ссылки в тексте). В обоих случаях основа — релевантность по словам или категориям: статья про CRM ссылается на другую статью про CRM, потому что они в одной рубрике или содержат общие ключи.

Entity-based перелинковка строится по логике связей между сущностями. Когда в статье упомянута сущность «Schema.org», и на сайте есть pillar-страница, посвящённая этой сущности, — между ними должна быть ссылка с анкором «Schema.org». Когда статья про «On-page SEO» упоминает «Core Web Vitals», и есть отдельная статья про Core Web Vitals — связь обязательна. Это не просто «похожие материалы», а явное указание поисковику: вот эти две страницы говорят про связанные сущности, и связь между ними реальна.

Различие на первый взгляд тонкое, но эффект принципиальный. При классическом подходе внутренние ссылки случайны и часто избыточны: блок «похожие» автоматически выдает пять статей, которые могут быть слабо связаны. При entity-based подходе каждая ссылка — это утверждение о связи двух сущностей, и таких утверждений на странице немного, но они точные. Поисковик из набора таких утверждений собирает граф темы, и сайт начинает восприниматься как авторитетный источник по этим сущностям.

Логика: как поисковики читают внутренние ссылки

Чтобы понимать, что делать, важно представить, как поисковик обрабатывает ссылку.

При обходе страницы Google и Яндекс фиксируют каждую исходящую ссылку: куда она ведёт, какой у неё анкор (видимый текст), какой контекст вокруг нее (предложение, абзац, ближайшие сущности на странице). Анкор — самый прямой сигнал того, о чём страница на той стороне ссылки. Контекст вокруг анкора уточняет тематическую близость.

Дальше работает простая, но мощная логика: страница, на которую ведут много внутренних ссылок с осмысленным анкором «Entity SEO», скорее всего и есть главная страница про Entity SEO на сайте. Чем больше согласованных сигналов — тем увереннее поисковик ранжирует именно эту страницу по соответствующему запросу. И наоборот: если 50 ссылок ведут на одну и ту же страницу с анкорами «тут», «подробнее», «читайте также» — поисковик не получает никакой информации о ее теме и не повышает её ранжирование.

Поведение пользователей тоже играет роль. Внутренние ссылки оцениваются Google не только по факту существования, но и по тому, кликают ли по ним. Ссылка с анкором-сущностью, по которой реально переходят, передаёт сигнал сильнее, чем ссылка, которую пользователи игнорируют. Это объясняет, почему расположение ссылки в тексте, её естественность и информативность анкора важны не только для поисковика, но и для пользователя — оба аспекта работают вместе и усиливают друг друга.

Из этого следует первое правило entity-based перелинковки: анкоры должны быть сущностями или их естественными вариациями, а не общими словами. «Schema.org», «Entity SEO», «Core Web Vitals», «контекстная реклама» — это анкоры. «Тут», «здесь», «по этой ссылке» — это потеря сигнала.

Архитектура: как организовать сайт под entity-перелинковку

Перед тем как расставлять ссылки, нужно решить структурную задачу — построить архитектуру сайта вокруг сущностей. Самая рабочая модель — topic clusters (тематические кластеры), известная также как hub-and-spoke (модель «хаб и спицы», где центральная страница — хаб — соединена со множеством сателлитов).

В этой модели для каждой главной темы (главной сущности) создается pillar-страница — большой материал, раскрывающий тему широко. Вокруг нее располагаются сателлитные страницы — узкие материалы по конкретным аспектам, каждый из которых раскрывает свою связанную сущность. Pillar и сателлиты соединены двусторонней перелинковкой: pillar ссылается на каждый сателлит по анкору-сущности, каждый сателлит ссылается обратно на pillar.

Например, для SEO-агентства может быть несколько кластеров.

Кластер «Entity SEO». Pillar: «Entity SEO: что это и как работает». Сателлиты: «Schema.org Organization и sameAs», «Wikidata и Knowledge Panel», «Entity-based keyword research», «Internal linking на основе сущностей», «E-E-A-T и Topical Authority», «Topic clusters и pillar-страницы».

Кластер «Технический SEO». Pillar: «Технический SEO: полный гайд». Сателлиты: «Core Web Vitals», «robots.txt и управление индексацией», «sitemap.xml», «Canonical-теги», «Hreflang для многоязычных сайтов», «JavaScript SEO», «HTTPS и безопасность».

Кластер «Локальный SEO». Pillar: «Локальный SEO для малого бизнеса». Сателлиты: «Google Business Profile», «Яндекс Бизнес», «NAP-консистентность», «Локальные каталоги», «Отзывы и рейтинги», «Schema.org LocalBusiness».

Внутри одного кластера ссылки плотные. Между кластерами — разреженные, но осмысленные: если в материале про Core Web Vitals уместно упомянуть Schema.org как сущность, влияющую на отображение в SERP, это упоминание становится ссылкой между кластерами. Так на сайте вырастает не дерево с изолированными ветками, а граф, повторяющий граф знаний поисковика по нише:

Глубина перелинковки

Помимо логики кластеров, важно следить за глубиной кликов (click depth) — сколько кликов от главной нужно сделать, чтобы дойти до страницы. Pillar, до которого нужно сделать 5 кликов от главной, получает значительно меньше веса, чем pillar в одном-двух кликах. Это связано с тем, как поисковики передают авторитет сверху вниз по структуре, и с тем, как распределяется crawl budget (краулинговый бюджет) — лимит страниц, который поисковик готов обходить за визит.

Рабочее правило: pillar-страницы должны быть в 1–2 кликах от главной (через меню, главный экран, hub-разделы), сателлиты — в 2–3 кликах, отдельные углубленные материалы — не глубже 3–4 кликов. На больших сайтах (10 000+ страниц) этот фактор становится критичным: страницы на глубине 5+ кликов могут вообще не индексироваться или индексироваться с большой задержкой.

Типы внутренних ссылок и их роль

Не все ссылки на сайте играют одинаковую роль с точки зрения entity-перелинковки. Полезно разделить их по функциям.

Контекстные ссылки в теле текста — самый ценный тип. Ссылка стоит внутри предложения, анкор — это сущность, контекст вокруг подтверждает связь. Именно эти ссылки формируют граф сущностей на сайте и передают наибольший вес. Каждая такая ссылка — осознанное решение автора, и их немного — обычно 3–5 на сателлитной статье средней длины (3–5 тыс. знаков). На pillar-странице по широкой теме их закономерно больше — 15-20, потому что pillar по своей природе является хабом, и ссылки на сателлиты являются его структурной функцией.

Ссылки в навигации (меню, футер) — структурные. Они показывают поисковику основные разделы сайта и помогают распределять вес на верхнеуровневые страницы. С точки зрения entity-перелинковки они работают слабее контекстных, потому что анкоры в меню обычно общие («Услуги», «Блог», «О нас»), а не сущностные. Но если в меню есть пункт «Entity SEO» с прямой ссылкой на pillar — это уже сильный сигнал.

Хлебные крошки (breadcrumbs) — подтверждают иерархию. Каждая крошка — ссылка с анкором-сущностью соответствующего уровня (категория, подкатегория). Обязательно сопровождаются разметкой BreadcrumbList в Schema.org.

Блоки «похожие материалы» / «читайте также» — ассоциативные. Они полезны для UX и могут передавать вес, но если они автоматически генерируются по тегам или категориям, ценность для entity-перелинковки невысокая. Гораздо лучше работают вручную подобранные блоки или блоки, генерируемые на основе общности сущностей между страницами.

Ссылки в карточках товаров и услуг — продуктовые. Связывают категории, родственные товары, аксессуары. С точки зрения сущностей особенно важна связка «Product → Manufacturer» (через @id в Schema.org) и связи между категориями.

Hreflang-связи между языковыми версиями — отдельный пласт перелинковки на многоязычных проектах. Технически это не ссылки в HTML-смысле, а атрибуты в <link rel="alternate" hreflang="..."> или отдельная разметка, но они работают как явное указание поисковику, что русская и английская версии страницы — это одна сущность на двух языках. На многоязычных сайтах рассинхрон или отсутствие hreflang приводит к каннибализации между языковыми версиями и снижает эффект entity-перелинковки внутри каждого языка.

Главный фокус для entity-перелинковки — контекстные ссылки и хлебные крошки. Остальное обслуживает UX и базовую структуру.

Анкоры: что писать в видимом тексте ссылки

Качество анкоров определяет, считывается ли entity-сигнал или теряется. Несколько практических принципов.

Анкор — это сущность или ее прямая вариация. «Schema.org», «разметка Schema.org», «Schema.org разметка» — все варианты валидны. «Тут», «по ссылке», «читать» — нет.

Точное вхождение допустимо и желательно. В отличие от внешних ссылок, где Google настороженно относится к избытку точных вхождений (опасаясь манипуляции PageRank — внутренним сигналом авторитетности страниц, который Google официально вывел из публичной коммуникации, но продолжает использовать в алгоритмах под разными названиями: link equity, link juice), внутренние ссылки с точными анкорами воспринимаются нормально и являются ожидаемым сигналом. Не нужно искусственно «разбавлять» внутренние анкоры синонимами ради безопасности.

Анкор должен соответствовать главной сущности целевой страницы. Если ссылка ведёт на pillar «Entity SEO», анкор — «Entity SEO» или «сущности в SEO», а не «наша статья про SEO в общем смысле».

Вариативность естественна и полезна. На pillar «Entity SEO» с разных страниц могут вести анкоры: «Entity SEO», «сущности в SEO», «entity-based SEO», «работа с сущностями в SEO». Это не разбавление ради разбавления, а естественные синонимы одной сущности. Поисковик объединяет их в один сигнал.

Анкоры в навигации могут быть короче. В меню «Entity SEO» — нормально. В контексте статьи можно расширить до «подробнее про Entity SEO как стратегию».

Избегайте каннибализации анкоров. Если на сайте есть и pillar «Entity SEO», и сателлит «Что такое Knowledge Graph», не используйте анкор «Entity SEO» для ссылок на сателлит — это сбивает поисковика. Каждой сущности — свой целевой URL.

Следите за временной динамикой. Когда сущность переименовывается (Twitter → X) или у компании меняется название, в перелинковке остаются старые анкоры. В какой-то момент поисковик перестаёт ассоциировать старый анкор с актуальной сущностью. При ребрендинге, переименовании продуктов или смене терминологии в нише имеет смысл провести точечный аудит анкоров и привести их к актуальной форме.

Распределение ссылочного веса: где должны быть pillar-страницы

Внутренняя перелинковка — главный способ управлять распределением веса (link equity) внутри сайта. Pillar-страницы должны получать больше внутренних ссылок, чем сателлиты, потому что они являются ключевыми коммерческими и ранжирующими активами.

Несколько практических способов «поднять» pillar:

Прямые ссылки с главной страницы. Главная — обычно самая авторитетная страница сайта. Ссылка с главной на pillar — мощный сигнал. Идеально, если это контекстная ссылка с анкором-сущностью, а не просто пункт меню.

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

Ссылки из соседних pillar-страниц. Pillar по теме A ссылается на pillar по теме B, если темы связаны. Это «горизонтальные» связи между кластерами.

Упоминание в навигации. Если pillar по важной теме включен в основное меню или в боковую навигацию — это дает стабильный поток веса.

Ссылки из статей блога, не входящих в кластер. Когда в статье на смежную тему уместно упомянуть pillar — упоминайте.

В сумме на зрелый pillar через 6–12 месяцев работы кластера обычно ведёт 15–40+ внутренних ссылок с разных страниц. Сателлит обычно получает 5–15. На свежем pillar в первый месяц после публикации таких ссылок будет мало, и это нормально — это целевое состояние, а не требование с момента запуска. Пропорция важна, потому что она показывает поисковику, какие страницы вы сами считаете опорными.

Внутренние ссылки и Schema.org

Перелинковка усиливается, когда подкреплена структурированной разметкой. Здесь важно понимать, что HTML-ссылки и разметка работают на разных уровнях: HTML-ссылки видны пользователю и передают вес через анкор и контекст, а связи внутри JSON-LD (через @id) машиночитаемы и существуют параллельно — это не альтернатива HTML-ссылкам, а второй слой сигналов поверх них. Несколько связок, которые работают особенно хорошо.

BreadcrumbList на всех страницах сайта. Это разметка хлебных крошек, явно описывающая иерархию: главная → категория → подкатегория → текущая страница. Дублирует визуальные крошки в машиночитаемом виде. Помогает поисковику быстрее понять структуру и может выводиться в SERP в виде структурированной цепочки навигации вместо длинного URL — Google в последние годы ужесточил требования к выводу breadcrumbs, и не на всех типах страниц они появляются автоматически, но при корректной разметке шансы заметно выше.

@id-связи между Schema.org сущностями. На главной странице Organization с @id: "https://site.com/#organization". На странице автора Person с @id: "https://site.com/about/author#person" и worksFor: { "@id": "https://site.com/#organization" }. На статье Article с author: { "@id": "https://site.com/about/author#person" } и publisher: { "@id": "https://site.com/#organization" }. Эти ссылки внутри JSON-LD создают граф сущностей сайта, который читается поисковиком отдельно от HTML-ссылок и усиливает их.

Свойства about и mentions для статей. В разметке Article можно явно указать главную сущность через about (это и есть entity salience на уровне разметки) и связанные сущности через mentions, привязав их к Wikidata Q-идентификаторам. Это самый прямой способ сообщить поисковику граф сущностей страницы:

Сайты, которые используют HTML-ссылки и разметку согласовано, получают наиболее устойчивые позиции в Entity-чувствительных нишах.

Процесс: как внедрить entity-перелинковку на существующем сайте

На реальном сайте внедрение обычно идёт в несколько этапов.

Этап 1. Аудит текущего состояния. Сканируем сайт через Screaming Frog или Ahrefs Site Audit, выгружаем все внутренние ссылки с анкорами. Смотрим: какие страницы получают больше всего ссылок (это фактические «хабы» сайта), какие анкоры доминируют, есть ли страницы-сироты (без входящих ссылок), есть ли каннибализация анкоров (один анкор ведёт на разные страницы).

Этап 2. Карта сущностей и кластеров. Перечисляем главные темы сайта и для каждой определяем pillar-страницу (существующую или планируемую). Для каждой темы выписываем связанные сущности, которые либо уже представлены сателлитами, либо требуют создания. Получается таблица «сущность → URL», которая становится словарём анкоров для перелинковки.

Этап 3. Миграция существующих ссылок. На сайтах с многолетней историей часто накоплены сотни внутренних ссылок в старых статьях с анкорами «тут», «здесь» и общими словами. Делать миграцию массово нерентабельно — приоритезируйте по ценности страниц: сначала pillar и топ-20% страниц по трафику, потом средний слой, потом архивные материалы. Точечный апдейт анкоров на ключевых страницах дает основной эффект, остальное доделывается фоном при следующих редакциях. Полная зачистка слабых анкоров на сайте в 1000+ страниц может занять 2–3 месяца, и это нормальный темп.

Этап 4. Расстановка контекстных ссылок. Проходим по существующим статьям. На каждой ищем упоминания сущностей из карты, которым соответствуют целевые URL на сайте. Делаем эти упоминания ссылками с анкором-сущностью. Базовое правило: первое упоминание сущности на странице становится ссылкой, последующие обычно нет — избыточная перелинковка ухудшает читаемость и не дает дополнительного веса. Исключение — длинные лонгриды (10+ тыс. знаков), где сущность упоминается в нескольких далеко разнесенных разделах: там допустимо повторное связывание во второй или третьей зоне страницы, потому что для пользователя это улучшает навигацию, а для поисковика не выглядит избыточным.

Этап 5. Усиление pillar-страниц. Проверяем, сколько ссылок ведёт на каждый pillar. Если меньше 10 — целенаправленно добавляем ссылки из релевантных статей и страниц.

Этап 6. Внедрение Schema.org разметки. Добавляем BreadcrumbList на все страницы, Article с about и mentions на статьи, связки через @id между Organization, Person, Article.

Этап 7. Регулярный аудит. Раз в 1–2 месяца сканируем сайт заново. Проверяем новые страницы — встроены ли они в граф сущностей, имеют ли входящие ссылки, ссылаются ли на pillar. При ребрендингах и переименованиях — точечный аудит анкоров.

На сайте в 200–500 страниц первичное внедрение занимает 2–4 недели единовременной работы и потом превращается в фоновый процесс при публикации новых материалов.

Инструменты

Несколько инструментов, которые делают entity-перелинковку выполнимой Screaming Frog SEO Spider — сканер сайта, выгружает все внутренние ссылки с анкорами. Бесплатен до 500 URL, дальше платный. Незаменим для аудита.

Ahrefs Site Audit  или Semrush Site Audit — облачные сканеры с детальным анализом внутренней перелинковки, выявлением страниц-сирот и нерационального распределения веса.

InLinks — специализирован именно на entity-based перелинковке. Извлекает сущности из контента, автоматически предлагает или расставляет внутренние ссылки на основе графа сущностей сайта. Работает в полу-автоматическом режиме: дает рекомендации, ссылки расставляет по подтверждению.

LinkWhisper — плагин для WordPress, предлагает релевантные внутренние ссылки при написании статей на основе текстового сходства. Не настолько entity-нативен, как InLinks, но удобен для редакторов.

Surfer SEO Audit — для отдельных страниц подсказывает, на какие внутренние URL стоит сослаться по семантической релевантности.

Google Search Console — раздел «Ссылки → Внутренние ссылки» показывает, какие страницы получают больше всего внутренних ссылок. Бесплатный, обязательный к регулярной проверке инструмент. Важная оговорка: Search Console показывает количество входящих внутренних ссылок и URL источников, но не показывает анкоры, под которыми эти ссылки стоят. Для анализа анкоров нужен Screaming Frog или его аналог.

Для русскоязычных проектов обычно достаточно связки Screaming Frog + Search Console + ручной работы по карте сущностей. InLinks и LinkWhisper подключаются на крупных контентных проектах.

Типичные ошибки

Слишком много ссылок на странице. Если в одной статье 30 внутренних ссылок, поисковик распределяет вес по всем, и каждая получает мало. Плюс читаемость падает. Норма — 3–5 контекстных ссылок на сателлите средней длины (3–5 тыс. знаков), плюс навигация и крошки. На pillar-страницах — больше, но это структурно оправдано.

Все ссылки ведут на одну страницу. Часто встречается в попытках «усилить» одну коммерческую страницу: с каждой статьи блога стоит ссылка на /services/. Поисковик видит неестественный паттерн и снижает вес ссылок. Лучше распределять: с каждой статьи 1–2 ссылки на разные релевантные страницы.

Анкоры «тут» и «здесь». Уже упоминалось, повторим: каждый такой анкор — потерянный сигнал. Замените на сущности.

Каннибализация анкоров. Один анкор «Entity SEO» с разных страниц ведёт на три разные страницы. Поисковик не понимает, какая из них основная. Решение: одной сущности — один целевой URL, единая политика анкоров.

Игнорирование страниц-сирот. Страница без входящих внутренних ссылок не индексируется уверенно и почти не получает веса. Регулярный аудит на страниц без входящих внутренних ссылок — обязательный процесс.

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

Ссылки только в footer и боковой панели. Без контекстных ссылок в теле текста основной entity-сигнал не передается, как бы много ни было сквозных ссылок в шаблоне.

Несогласованность Schema.org и HTML-ссылок. В разметке Article в mentions указана сущность «Schema.org», но на странице нет ссылки на pillar по Schema.org. Расхождение снижает доверие к разметке. Правило: всё, что в разметке, должно быть на странице.

Перелинковка без учёта Search Intent. Информационная статья ссылается на коммерческую посадочную, но контекст ссылки информационный — анкор и контекст должны соответствовать тому, что пользователь увидит на той стороне. Иначе высокий показатель отказов разрушает поведенческие сигналы.

Как измерить результат

Entity-based перелинковка — это инвестиция времени, и без понимания, как измерить отдачу, легко потерять мотивацию через 2–3 месяца. Что смотреть.

Рост позиций по entity-related запросам у pillar. После усиления pillar по теме «Entity SEO» должны расти позиции не только по главному запросу, но и по связанным: «что такое entity seo», «entity seo стратегия», «работа с сущностями в seo». Это сигнал, что граф ссылок укрепил pillar как авторитет по теме.

Сокращение числа страниц-сирот. Прямая операционная метрика. Через 1–2 месяца после внедрения число страниц без входящих внутренних ссылок должно стремиться к нулю (исключение — служебные страницы, которые сознательно изолированы).

Изменение распределения внутренних ссылок в Search Console. В разделе «Ссылки → Внутренние ссылки» pillar-страницы должны подниматься в топ списка. Если pillar не попадает в первую двадцатку самых линкуемых страниц сайта — это сигнал, что распределение веса нерациональное.

Глубина просмотра и страницы за сессию. Контекстные ссылки с анкорами-сущностями работают и для пользователя — он переходит по ним, изучает связанные темы, остаётся на сайте дольше. Рост среднего числа страниц за сессию (видно в GA4 или Метрике) — побочный, но показательный эффект.

Кликабельность внутренних ссылок. Через GA4 или Метрику можно настроить отслеживание кликов по внутренним ссылкам. Если ссылки с анкорами-сущностями получают значимо больше кликов, чем ссылки со слепыми анкорами — это и пользовательский, и поисковый сигнал в пользу подхода.

Рост числа уникальных запросов в Search Console для pillar. До работы с перелинковкой pillar обычно ранжируется по узкому пулу запросов вокруг головной сущности. После — пул расширяется за счет сотен длиннохвостых запросов, связанных через сущности. Это тот же эффект, что в entity-based research, но усиленный графом ссылок.

Горизонт измерения — 3–6 месяцев. Раньше делать выводы преждевременно: Google нужно время, чтобы переоценить страницы в новой конфигурации входящих ссылок и анкоров.

Чек-лист внедрения

• Составить карту сущностей сайта: для каждой главной темы — pillar и список сателлитов с целевыми URL.
• Закрепить словарь анкоров: одна сущность → один URL → набор естественных вариаций анкора.
• Провести аудит текущего состояния через Screaming Frog: какие страницы получают мало входящих ссылок, какие анкоры доминируют, есть ли каннибализация.
• Приоритизировать миграцию старых ссылок: сначала pillar и топ-20% страниц по трафику, потом средний слой, потом архив.
• Проставить контекстные ссылки в существующих статьях по карте сущностей — первое упоминание сущности на странице становится ссылкой.
• Усилить pillar-страницы: добиться минимум 10–15 входящих внутренних ссылок на каждый, целевое состояние через 6–12 месяцев — 15–40+.
• Проверить глубину кликов: pillar в 1–2 кликах от главной, сателлиты в 2–3.
• Внедрить BreadcrumbList на всех страницах с разметкой Schema.org.
• Добавить about и mentions в Article-разметку с привязкой к Wikidata.
• Связать Organization, Person, Article через @id.
• Поставить процесс перелинковки в редакционный workflow: при публикации новой статьи редактор обязательно проверяет карту сущностей и расставляет ссылки на релевантные pillar и сателлиты.
• Раз в 1–2 месяца проводить технический аудит: новые сироты, новые каннибализации, изменения в распределении веса.
• Через 3–6 месяцев замерить результат по entity-related запросам, числу сирот, распределению внутренних ссылок и поведенческим метрикам.
• При ребрендингах и переименованиях — точечный аудит анкоров.

Заключение

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

Entity-based перелинковка не требует переделки сайта или внедрения дорогих инструментов. Она требует одного — подхода: вместо случайных «читайте также» появляется карта сущностей, словарь анкоров, осмысленные контекстные ссылки, согласованная Schema.org разметка.

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