Внутренняя перелинковка 2026+: архитектура, которая поднимает сайт в поиске

Артем Довгопол

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

Ключевые идеи👌

Введение

В 2026 году внутренняя перелинковка стала одним из ключевых факторов ранжирования. Причины очевидны.
Google все сильнее опирается на структурные сигналы: хабы, кластеры, тематические деревья.
Алгоритмы оценивают не отдельные документы, а взаимосвязанные блоки контента.
Даже у средних сайтов ограничен Crawl Budget — робот обходит только то, что хорошо связано.
Внутренний PageRank формирует костяк стабильного топа: от архитектуры зависит, что индексируется, а что исчезает со временем. Именно поэтому работа со структурой сайта, как в услуге
SEO-оптимизация сайта стала задачей номер один для бизнеса.

А внутренняя перелинковка остается самым безопасным способом усиливать важные страницы.

Правильная структура ссылок создает ощутимые эффекты:

— увеличивает глубину обхода;
— ускоряет индексацию новых и обновленных страниц;
— повышает CTR дочерних материалов;
— формирует сильное тематическое ядро;
— снижает влияние мусорных разделов;
— улучшает навигацию и увеличивает конверсии;
— делает сайт устойчивым в конкурентных нишах.

ЧАСТЬ 1. Базовые модели и стратегия

1. Типы сайтов и принципы перелинковки

Перелинковка не одинаковая для разных типов сайтов — стратегия зависит от архитектуры, задач бизнеса и типа проекта. Именно поэтому в комплексных проектах по веб-разработке структура всегда проектируется заранее.

Мы разберем четыре модели:

1) Маленькие сайты (до 100 страниц)

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

2) Корпоративные сайты (100–2000 страниц)

Корпоративные сайты — самый сложный тип архитектуры.

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

3) Большие контентные сайты (до ~15 000 страниц)

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

4) Агрегаторы и маркетплейсы (15 000–5 000 000+ страниц)

Это самый тяжелый тип проектов с точки зрения crawl budget и контроля качества.
Огромные каталоги, миллионы карточек, фасетная навигация, фильтры — любая ошибка в структуре размножается по всей системе.
Поэтому для таких проектов особенно важно проектировать структуру категорий и сквозную перелинковку, как в сложных e-commerce-системах уровня интернет-магазинов.

2. PageRank, Crawl Budget и Link Graph: техническая база

Любая перелинковка опирается на три фундаментальных механики, которые определяют, как Google распределяет вес внутри сайта и какие страницы получают приоритет при обходе. Эти механики лежат в основе любой внутренней оптимизации — включая работу с контентными блоками, структурой и внутренней SEO-оптимизацией.

2.1. Внутренний PageRank (IPR)

Классическая упрощенная формула выглядит так:
PR(A) = (1 - d) + d * Σ(PR(Bᵢ) / L(Bᵢ))
Где:
A — целевая страница;
Bᵢ — страницы, ссылающиеся на A;
L(Bᵢ) — количество исходящих ссылок на странице;
d — коэффициент затухания (обычно 0.85–0.95 для внутренних графов).

Практические выводы:

— на корпоративных сайтах оптимальный коэффициент d = 0.85–0.90;
— на больших агрегаторах d = 0.92–0.95, иначе граф теряет вес;
— страницы с более чем 200 исходящими ссылками резко падают в значимости.

Правильно распределенный PageRank формирует «силовой каркас» сайта — основу, которая определяет, какие страницы удерживаются в поиске при обновлениях алгоритмов.

2.2. Crawl Budget

Google выделяет на сайт ограниченный ресурс обхода — Crawl Budget:
— на маленьких сайтах лимит примерно равен количеству страниц;
— на средних зависит от качества перелинковки и структуры;
— на больших — почти полностью определяется архитектурой.

Неправильные технические зоны, слабые структуры, дубли и мусорные разделы «съедают» бюджет, замедляют индексацию и выводят часть сайта из обращения. Это особенно заметно на сайтах, где требуется защищенность и строгая гигиена структуры — тема, пересекающаяся с практиками, описанными в статье «Безопасность сайта: защита от 95% угроз за 7 шагов».

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

2.3. Semantic Link Graph

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

Google оценивает:
— отношение родитель → дочерняя;
— связь «хаб → группа»;
— принадлежность к контентным кластерам;
— связь товара и категории;
— связь категории и бренда;
— и самую важную цепь: статья → услуга.

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

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

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

3. Стратегия перелинковки по типам сайтов

Перелинковка работает по-разному для разных типов сайтов. Архитектура, количество уровней вложенности, объем контента и цели бизнеса определяют, как именно должен распределяться внутренний PageRank. Ниже — четыре универсальные модели.

ТИП 1. Маленькие сайты (до 100 страниц)

Это визитки, сайты малого бизнеса, персональные проекты.

Задачи перелинковки здесь максимально прикладные:
— усилить ключевые коммерческие страницы;
— направить вес с блога → на услуги;
— сформировать замкнутый цикл навигации;
— связать информационный контент с коммерческим.

Фундаментальная модель

«Колесо → Спицы»:
Главная → Услуги → Подуслуги → Статьи → Услуги

Правила:

1) Каждая услуга должна иметь 10–20 входящих ссылок из статей, других услуг, главной, хабов. Это важно не только для SEO, но и для планирования бюджета — подробнее об этом можно прочитать здесь: сколько стоит разработка сайта в 2026.

2) Каждый пост блога обязан ссылаться на услугу
Анкоры: прямой, частичный, смысловой.

3) Запрещены страницы-сироты
Страница без входящих ссылок теряет до 45% шансов быть в индексе.

Правильная схема для маленьких сайтов

И еще немного о внутренних ссылках…

Хочешь понять, как создать структуру сайта, которая выдерживает нагрузку и усиливает ключевые страницы? Загляни в разбор Структура сайта для SEO и юзабилити: планируем правильно — мы объясняем, как спроектировать дерево страниц, чтобы оно работало на SEO, UX и конверсии.

Тип 2. Корпоративные сайты (100–2000 страниц)

Типичные примеры: digital-агентства (включая Toimi), производственные компании, застройщики, образовательные проекты, франшизы.

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

Корпоративные сайты — это уже не визитки. Это полноценные экосистемы, где важна архитектура, логика переходов и распределение веса между сервисами. Именно поэтому здесь особенно важна корректная структура услуги, например:
Разработка корпоративных сайтов → /web-development/corporate/

Задачи перелинковки в корпоративных структурах

— распределить PageRank между сервисами и их поднаправлениями;
— усилить коммерческие услуги;
— выстроить информационные пирамиды вокруг ключевых направлений;
— устранить «мусорные циклы» и тупиковые страницы;
— обеспечить глубокий обход и постоянную переиндексацию.

Модель перелинковки: «Service → Cluster → Authority → Hub → Service»
Это актуальная реализация паттернов «Topical Authority», описанных в патентах Google.

Типовая схема:
Услуга → Хаб → Подхабы → Статьи → Рекомендации → Услуга

Ключевые правила перелинковки корпоративных сайтов

Правило №1. Каждая услуга — это самостоятельный «узел» со своими кластерами

Пример на Toimi: услуга «Разработка сайта» включает:
— «UX/UI» (хаб),
— «SEO» (хаб),
— «Верстка» (технический хаб),
— статья «История разработки»,
— лонгрид «Как выбрать агентство».

Все эти материалы должны ссылаться обратно на услугу.

Правило №2. Лонгриды — самые сильные доноры веса

Они обеспечивают:
— глубину переходов,
— высокий dwell time,
— низкий Bounce Rate,
— сильный тематический сигнал.

Лонгрид должен отдавать 3–7 ссылок на услуги, кластеры и хабы.

Правило №3. Главная → хабы → услуги (а не наоборот)

Частая ошибка:
Главная → услуги → хабы → статьи

Правильная логика:
Главная → хабы → услуги → статьи → услуги

Правило №4: каждая статья должна содержать минимум 3 внутренних ссылки

— на услугу,
— на хаб,
— на соседнюю статью внутри кластера.

Схема корпоративного сайта

ТИП 3. Контентные сайты (до 15 000 страниц)

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

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

Стратегия: «Topic → Subtopic → Articles → Article Web»

Главный принцип:
Каждая тема — это дерево, а не линейная цепочка.

Компоненты кластера:
— Хаб (главная страница темы)
— Подхабы (группы внутри темы)
— Статьи ядра
— Статьи-сателлиты
— Соседние связи («sibling links»), связывающие материалы «по горизонтали»

Именно на этом этапе важно помнить, что любое дерево создается не вручную, а на основе семантики. Поэтому логично упомянуть:
Сбор семантического ядра и кластеризация → основа для построения тематических кластеров

Компоненты:
— Хаб (главная страница темы)
— Подхабы (подгруппы)
— Статьи ядра
— Статьи-сателлиты
— Связи «сibling links» между статьями

Оптимальная модель (для Google Discover + SEO):

Требования к каждой статье внутри кластера

— 2 ссылки вверх (подхаб → хаб)
— 1 ссылка на основную статью кластера
— 3 горизонтальные ссылки на родственные материалы
— 1 ссылка вниз — на детальную статью или FAQ

Такой подход формирует Article Web, а не линейную цепочку. Это критическое отличие — и ключ к Topic Authority.

Типовая ошибка (90% контентных сайтов)
Хаб → Статья 1 → Статья 2 → Статья 3

Она убивает:
— PageRank
— глубину обхода
— тематический вес
— Discover-сигналы

Правильная графовая структура

Внутри каждого под-кластера статьи связаны друг с другом.
Это формирует Topic Authority, удерживает статический вес внутри дерева и увеличивает количество точек входа в органике.

ТИП 4. Агрегаторы и маркетплейсы (50 000 – 5 000 000 страниц)

Это высшая лига. Здесь 80% SEO = перелинковка, потому что масштаб меняет все:
— глубина обхода
— качество индексации
— перераспределение веса
— траектории робота
— ограниченность crawl budget

Главные задачи перелинковки в агрегаторах

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

Модель: «Hierarchy → Facets → Listings → Backlinks → Loops»

Разберем детально.

Компонент 1: Иерархия категорий

Основной донор веса — КАТЕГОРИИ.

Правильная схема:

Категории:
— усиливают подкатегории,
— отдают вес листингам,
— получают ссылки от фильтров и статей.

Компонент 2: Faceted Navigation (фасетная навигация)

Это самый опасный элемент. Он создает миллионы дублей, если сделано неправильно.

Верифицированные правила:
1) индексация только белого списка фасетов,
2) nofollow/noindex на второстепенных фильтрах,
3) каноникал на основную версию листинга,
4) блокировка параметров в robots,
5) внутренняя перелинковка только на разрешенные фасеты.

Компонент 3: Листинги

Это страницы товаров/объявлений.
Задачи:
— отдавать вес вверх → категории,
— получать вес вниз → от других товаров.

Перелинковка листингов:
— блок «Похожие товары»,
— блок «С этим смотрят»,
— блок «Категория»,
— блок «Фильтр»,
— блок «Бренды».

Компонент 4: Backlinks redistribution

Входящие внешние ссылки часто идут на:
— главную,
— категории,
— популярные товары.

Наша задача — внутренней перелинковкой перенаправить их силу вниз по дереву.

Компонент 5: Anti-loop architecture

Нужно полностью исключить циклы вида:
Товар → Похожее → Похожее → Похожее → ...

Google тратит Crawl Budget, а эффект нулевой.

Модель агрегатора

4. Четырнадцать правил внутренней перелинковки

1) No orphan pages — каждая страница должна иметь входящие ссылки.
2) Parent → child → sibling — главный принцип.
3) PageRank concentration — важные страницы получают больше ссылок.
4) Лонгриды — главные доноры веса.
5) Горизонтальные связи усиливают тему.
6) Вертикальные связи создают силу структуры.
7) Услуги получают вес от контента, а не наоборот.
8) Фильтры индексируются выборочно.
9) Не больше 200 исходящих ссылок на страницу.
10) Главная отдает вес хабам, а не всем подряд.
11) Ссылки в меню индексируются, но PageRank распределяют слабо.
12) Footer-линки работают только в больших сайтах.
13) 404, архивы, пагинация — всегда регулируются PR-бюджетом.
14) Добавление новых страниц должно усиливать структуру, а не ломать.

ЧАСТЬ 2. Алгоритмы Google, формулы, моделирование графа и внутренняя архитектура перелинковки

5. Как Google реально оценивает внутренние ссылки в 2026

SEO-рынок до сих пор живет мифами «Google не учитывает внутренние ссылки» или «внутренние ссылки — это не важно». Это неправда.

С 2022–2025 Google активно использует:
— PageRank (обновленный)
— Inverse Document Frequency Graph
— Topic-Sensitive PageRank
— Contextual Link Relevance
— Semantic Attention Maps
— Link Distance Scoring
— Crawl Efficiency Algorithms
— Site-Level Authority Redistribution

Разбираем по порядку.

5.1. Обновленный PageRank внутри сайтов

Google официально не отключал PageRank — он интегрирован в RankBrain, Neural Matching, Hummingbird, BERT и MUM.

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

Упрощенная формула (модель, максимально близкая к реальной):
IPR(A) = (1 - d) + d * Σ[(PR(B_i) / Out(B_i)) * W(B_i→A)]
Где W — вес контекстной релевантности:
W = α * семантика + β * позиция ссылки + γ * тип блока + δ * уникальность анкора
Где:
α (0.4–0.6) — тематическая близость,
β (0.1–0.2) — визуальная позиция (выше = больше вес),
γ (0.2–0.3) — тип блока (контент > навигация > футер),
δ (0.05–0.1) — анкор (естественный > прямой > мусорный).

5.2. Topic-Sensitive PageRank

Это важнейший алгоритм для крупных сайтов. Google выбирает «тему страницы» и распределяет вес по степени тематической принадлежности.

Практический вывод:

— Ссылка внутри одного кластера весит ×3–6.
— Ссылка между далекими кластерами весит ×0.2–0.4.
— Хабы усиливают «родных детей», но почти не усиливают «чужих».

5.3. Contextual Link Relevance (CLR)

Google анализирует:
— окружение ссылки,
— часть текста,
— наличие LSI-терминов,
— semantic embeddings.

Практически:

— ссылка в «слабом» абзаце → снижение веса до −40%,
— ссылка внутри списка «см. также» → снижение −20–50%,
— ссылка в середине смыслового параграфа → максимум веса.

5.4. Link Distance Scoring

Алгоритм измеряет, насколько далеко страницы друг от друга.
Distance = шагов по ссылкам

Влияние:

1–2 клика → сильный семантический сигнал
3–4 клика → слабый
5+ кликов → связь почти потеряна

Вывод:

Глубина вложенности должна быть ≤3 кликов от главной. Подробно это разобрано в нашем Пошаговом руководстве по разработке сайтов

5.5. Site-Level Authority Redistribution

Google пересчитывает авторитет домена и распределяет его внутри по:
— силе хабов,
— числу статей в кластере,
— доверию страницы,
— типам внутренних ссылок.

Сайты без хабов → теряют до 40–70% возможного веса.

6. Моделирование Link Graph: как правильно строить структуру внутренних ссылок

Моделирование графа — это основной навык архитектора сайтов. Большинство SEO-специалистов этого не делают → отсюда слабые результаты.

6.1. Основные типы внутренних графов

1) Древовидный граф (Tree Structure)

Используется на:
— маленьких сайтах,
— корпоративных сайтах.

Плюс: простота.
Минус: мало горизонтальных связей.

2) Граф хабов (Hub Graph)

Используется на:
— корпоративных,
— контентных.

Плюс: сильное распределение по теме.
Минус: требует архитектуры.

3) Граф кластеров (Cluster Graph)

Для:
— медиа,
— учебных платформ,
— информационных сайтов.

Плюс: максимальная тематическая сила.
Минус: сложная поддержка.

4) Граф фасетной навигации (Facet Graph)

Для:
— агрегаторов,
— маркетплейсов.

Плюс: масштабируемость.
Минус: риск взрыва дублей.

6.2. Правильная структура распределения веса

В идеале структура должна быть 3-уровневой:

Уровень 1 — Главная / Корневые хабы
Уровень 2 — Категории / Услуги / Темы
Уровень 3 — Статьи / Листинги / Карточки

И между уровнями:

V2 → V1 (усиление вверх),
V3 → V2 (распределение вниз),
V3 ↔ V3 (горизонтальная связь),
V2 ↔ V2 (связность тем).

6.3. Пример идеальной нетривиальной модели

Каждая статья имеет:
— 1 ссылку вверх (родитель),
— 1 ссылку на хаб,
— 2–5 ссылок на соседей.

7. Link Sculpting 2026+: современная методология управления распределением веса

Link Sculpting = управление внутренним PageRank.

Методика позволяет:
— усиливать коммерческие страницы,
— уменьшать влияние мусорных,
— контролировать глубину обхода,
— формировать тематические сигналы.

7.1. Где Link Sculpting работает идеально

1) Корпоративные сайты
2) Контент-медиа
3) Маркетплейсы (с ограничениями)

7.2. Методы Link Sculpting

Разберем методы с практической пользой.

Метод 1: Концентрация веса (PR Concentration)

Мы передаем больше ссылочного веса в:
— услуги,
— категории,
— хабы,
— важные лендинги (подробнее в руководстве по созданию эффективных лендингов)

Для этого:
1) Лонгриды → дают 3–7 ссылок на услуги
2) Кейсы → дают 2–3 ссылки
3) Блог → 1–2 ссылки
4) Хабы → 5–15 ссылок

Метод 2: Отсечение мусорных страниц

Используем:
— noindex,
— robots.txt,
— canonical,
— запрет сквозных ссылок.

Страницы, которые нужно «отключать»:
— архивы тегов,
— страницы сортировки,
— бесконечная пагинация,
— фильтры,
— технические страницы.

Метод 3: Эффект «силового треугольника»

Модель:
Хаб → Услуга → Хаб → Статья → Услуга

Такая траектория формирует:
— тематическое усиление,
— рост релевантности,
— улучшение PR-потока.

Метод 4: Weight Pumping (перекачивание веса)

Используется, если:
— услуга должна попадать в топ,
— много информационного контента.

Техника:
1) выбираем 20–50 статей,
2) меняем структуру внутренних ссылок,
3) усиливаем коммерческую страницу 2–4 ссылками каждая.

Метод 5: PR-изоляция плохих разделов

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

7.3. Что категорически нельзя делать

❌ Random linking — хаотичные ссылки, без логики
❌ Over-anchoring — 100% прямых анкорных ссылок
❌ Infinite loops — бесконечные цепочки
❌ Сквозные ссылки без оценки веса
❌ Скрытые ссылки
❌ Ctrl+C/Ctrl+V из конкурентов

8. Анкорная стратегия (внутренняя)

Внутренняя анкорная стратегия — отдельная дисциплина.
Google:
— понимает смысл анкора,
— оценивает разнообразие,
— анализирует контекст,
— понимает overspam.

8.1. Типы внутренних анкоров

8.2. Оптимальное распределение

Для корпоративных сайтов:
— Прямой: 20–30%
— Частичный: 40–50%
— Смысловой: 20–30%
— Брендовый: 5–10%
— URL: 0–5%

Для крупных контентных:
— Смысловой: 60–80%
— Частичный: 20–30%
— Прямой: ≤10%

Для маркетплейсов:
— Смысловой: 60–70%
— Фасетный: 20–30%
— Прямой: ≤5%

9. Архитектура хабов и кластеров: как строить правильно

Хаб — это страница, которая:
— объединяет тему,
— усиливает дочерние страницы,
— собирает PageRank.

9.1. Идеальный хаб

Хаб должен содержать:
— описание темы,
— ссылки на подхабы,
— ссылки на ключевые статьи,
— список рекомендованных материалов,
— связки между кластерами.

9.2. Пример хаба

ЧАСТЬ 3. Практические схемы перелинковки

10. Перелинковка корпоративных сайтов (архитектура Toimi как эталон)

Корпоративный сайт — это смесь:
— коммерческих страниц,
— хабов,
— инфо-контента,
— кейсов,
— презентаций,
— блога.

Это фундаментально отличается от:

— контентных сайтов (где 90% — статьи),
— маркетплейсов (где 90% — листинги).

10.1. Главная ошибка корпоративных сайтов — отсутствие вертикального и горизонтального графа

Типовой граф выглядит так:

Главная → Услуги → Статьи → Услуги
Это линейная модель, она слабая.

Google не видит:
— тематические кластеры,
— хабы,
— связи между услугами,
— связи между кейсами,
— связи между услугами и статьями.

10.2. Правильный корпоративный граф (универсальная схема)

10.3. Как перелинковывать хабы

Хаб (например, «Web Development») должен иметь:
— ссылку на каждую услугу в кластере,
— ссылки на 3–5 кейсов,
— ссылки на 2–3 лонгрида,
— ссылки на 5–7 ключевых статей блога,
— 1–2 ссылки на смежные хабы.

Пример анкор-блока в хабе:

→ Разработка корпоративных сайтов
→ UX/UI дизайн
→ SEO-архитектура
→ Frontend/Backend
→ Кейсы: Taskee, Kirillitsa
→ Лонгрид: Архитектура сайта под SEO
→ Статьи: структура, прототипирование, SEO-компоненты

10.4. Как перелинковывать услуги

Каждая услуга должна иметь:

1. Входящие ссылки из:

— минимум 1 ссылка с хаба
— минимум 1 ссылка с подхаба
— минимум 5–20 ссылок из блога
— минимум 2–5 ссылок из кейсов
— минимум 1–2 из лонгридов
— минимум 1 из презентации

2. Исходящие ссылки на:

— хаб
— 2–4 статьи
— 1–2 кейса
— FAQ
— лонгрид/гайд
— 2 смежные услуги (консистентность графа)

10.5. Перелинковка кейсов

Главное правило: каждый кейс = усиление услуги.
Минимальный комплект ссылок:

Услуга → Кейс → Услуга
Хаб → Кейс
Статья → Кейс

Кейсы должны перелинковываться на связанные кейсы.

10.6. Перелинковка инфо-контента (блог)

Каждая статья должна иметь:
— 1–2 ссылки на услугу
— 1 ссылку на хаб
— 1 ссылку на лонгрид
— 2–5 ссылок на смежные статьи

10.7. Лонгриды — главные доноры веса

Лонгриды (как эти) должны:
— усиливать услуги,
— усиливать хабы,
— создавать горизонтальные связи,
— собирать в себя трафик.

Лонгрид → 7–12 исходящих ссылок:

— 3–5 на услуги
— 1–3 на хабы
— 3–4 на статьи
— 1–2 на кейсы

11. Перелинковка блогов от 2 000 до 10 000 статей

Здесь вступает в игру кластеризация. Если нет кластеров — перелинковка превращается в хаос.

11.1. Кластерная архитектура

Все статьи распределяются по:
— 3 уровням тем
— дереву подгрупп
— хабам
— центральным статьям

Пример:

11.2. Внутрикластерные связи

Каждая статья связывается с:
1) родительским хабом
2) сестринскими статьями
3) центральным материалом кластера

Графическая модель:

11.3. Межкластерные связи

Запрещены прямые связи между далекими темами:
❌ SEO → SMM
❌ Брендинг → Семантика

Разрешены:
✔ SEO → UX (смежные темы)
✔ Разработка → SEO
✔ Контент → Разработка

11.4. Формула распределения ссылок в статье (универсальная)

— 1 ссылка вверх (хаб)
— 1 ссылка на центральный материал
— 2–3 ссылки на стабильные статьи
— 1–2 ссылки на смежные статьи

11.5. Ошибка большинства сайтов — «динамические блоки»

То есть автоподбор:
— «Похожие статьи»
— «Популярные»
— «Свежие»
Это сливает PageRank на случайные страницы.

Решение:
— статические вручную заданные блоки,
— тематические подборки,
— curated lists.

12. Перелинковка городских страниц (geo-сайты и городские логики)

Используется на:
— сайтах услуг,
— региональных проектах,
— франшизах,
— каталогах.

12.1. Структура городского кластера

/city/  
    /service/  
        /local-case/  
        /local-landing/  

12.2. Как делать ссылки правильно

1) Главная → страны → города
2) Города → услуги
3) Услуги → города
4) Локальные кейсы → услуги
5) Локальные статьи → услуги

12.3. Таблица перелинковки городских страниц

13. Перелинковка кейсов: инженерная модель

Кейсы — тип страниц, который:
— формирует E-E-A-T,
— влияет на продажи,
— дает вес услугам.

13.1. Схема перелинковки кейсов

Услуга → Кейс
Хаб → Кейс
Кейс → Услуга
Кейс → Кейсы
Кейс → Лонгрид
Статья → Кейс

13.2. Минимальный набор внутренних ссылок в кейсе

— 1–2 ссылки вверх (услуги)
— 1 ссылка на страницу процесса
— 1 ссылка на связанный кейс
— 1 ссылка на статью
— 1 ссылка на хаб

14. Международные локали: перелинковка

Большинство сайтов допускают ошибку:
❌ сквозная перелинковка между языками.

Google интерпретирует это как:
— смешение индекса,
— ухудшение релевантности,
— потерю веса.

14.1. Правильная логика:

1) rel= «alternate» + hreflang
2) Внутренние ссылки внутри языка (строго)
3) Разрыв PR-потока между локалями
4) Хабы уникальны для каждой локали

14.2. Модель Toimi для международных локалей

/en/  
   /services/  
   /cases/  
   /blog/  
/es/  
   /servicios/  
   /casos/  
   /blog/  
/pt/  
   /servicos/  
   /cases/  
/ru/  
   /услуги/  
   /кейсы/

Никаких перекрестных ссылок между языками.

15. Перелинковка PDF, презентаций, HTML-лендингов, видео

Google индексирует:
— PDF
— HTML-презентации
— Google Docs
— YouTube-видео
— И эти материалы могут усиливать страницы.

15.1. Правильный подход к PDF

PDF должен:
— содержать ссылки на услуги,
— быть загружен на сайте,
— иметь хорошо читаемый URL,
— быть частью хаба.

15.2. Перелинковка HTML-презентаций

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

15.3. YouTube → сайт

Сильная связка:
Видео → Лонгрид → Хаб → Услуга

В видео:
— ссылки в описании,
— аннотации,
— закрепленный комментарий.

ЧАСТЬ 4. Технический регламент перелинковки: Toimi, Taskee, большие сайты, сервисные сайты.

16. Готовый регламент перелинковки для Toimi.pro (универсальный и масштабируемый)

Этот блок — реальный технический документ, который может использовать и SEO, и контент-редактор, и верстальщик, и PM.

16.1. Общая структура Toimi:

Ключевые разделы:
— Главная
— Услуги
— Хабы
— Кейсы
— Блог
— Лонгриды
— PDF-презентации
— Города (опционально)
— Международные локали

16.2. Главная страница: правила перелинковки

Главная → хабы (обязательно)
Это основной вектор распределения веса.

Запрещено:
❌ Ссылки напрямую на все услуги — это размазывает PageRank.

16.3. Хабы Toimi: правила перелинковки

Каждый хаб должен содержать:
1) ссылки на услуги кластера (4–10 ссылок),
2) ссылки на 3–5 кейсов,
3) ссылки на 2–3 лонгрида,
4) ссылки на 5–7 ключевых статей блога,
5) 1–2 ссылки на смежные хабы.

Пример для хаба «Разработка»:

→ Корпоративные сайты
→ Разработка SaaS
→ UX/UI дизайн
→ Backend/Frontend
→ Кейсы: Taskee, Kirillitsa
→ Лонгрид: Архитектура сайта под SEO
→ Статьи: структура, прототипирование, SEO-компоненты

16.4. Услуги: архитектура ссылок

Услуги Toimi — важнейшие коммерческие страницы.
Их нужно усиливать.

1. Входящие ссылки (должны быть):

— минимум 1 ссылка с хаба
— минимум 1 ссылка с подхаба
— минимум 5–20 ссылок из блога
— минимум 2–5 ссылок из кейсов
— минимум 1–2 из лонгридов
— минимум 1 из презентации

2. Исходящие ссылки (должны быть):

— хаб
— 2–4 статьи
— 1–2 кейса
— FAQ
— лонгрид/гайд
— 2 смежные услуги (консистентность графа)

16.5. Кейсы: правила перелинковки Toimi

Кейсы → Услуги:

— минимум 2 ссылки
— разные анкоры

Кейсы → Кейсы:

— минимум 1 ссылка (похожие работы)

Кейсы → Блог:

— минимум 1 статья

Кейсы → Хаб:

— 1 ссылка обязательно

16.6. Блог Toimi: строгая структура линковки

Каждая статья должна иметь такой набор:
— 1 ссылка вверх — на хаб
— 1 ссылка на услугу
— 1 ссылка на лонгрид
— 2–5 ссылок на статьи
— 1 ссылка на кейс
Никакой случайной перелинковки.

16.7. Лонгриды Toimi — главные доноры веса

Лонгриды дают:
— большой объем контента,
— много мест для ссылок,
— сильные тематические сигналы.

Лонгрид → 7–12 ссылок:

— 3–5 на услуги
— 2–3 на хабы
— 2–3 на статьи
— 1–3 на кейсы

Лонгриды переплетены между собой.

17. Регламент перелинковки для Taskee.pro

SaaS сильно отличается от корпоративных сайтов.

17.1. Основная структура Taskee

— Главная
— Функции
— Интеграции
— Блог
— Pricing
— Onboarding pages
— Use-cases
— Support/FAQ

17.2. Главная → функции (главный PR-поток)

17.3. Функции → блог → функции

Каждая функция должна иметь:

1. Входящие ссылки из блога

Минимум 10 ссылок с анкоров:
— time tracking
— учет времени
— task manager
— kanban
— productivity tools
— time management

2. Исходящие ссылки:

— 3 соседних функции
— pricing
— onboarding
— 3–5 статей блога
— 1–2 use-case
— FAQ

17.4. Use-cases → функции → pricing

Каждый use-case должен:
— ссылаться на 2–3 функции,
— ссылаться на pricing,
— иметь минимум 1 ссылку из блога,
— иметь минимум 1 ссылку из главной.

17.5. Блог Taskee: строгая линковка

Каждая статья должна иметь:
— 1 ссылка на функцию
— 1 ссылка на pricing
— 2–4 ссылки на статьи
— 1 ссылка на use-case

18. Алгоритм добавления новых страниц (универсальная модель)

Каждая новая страница должна пройти процедуру линковки:

Шаг 1. Определение «кластера принадлежности»

Каждая страница принадлежит к:
— услуге,
— теме,
— подкластеру,
— хабу.

Шаг 2. Добавление 2 вертикальных ссылок вверх

Пример:
Статья → Подхаб
Статья → Хаб

Шаг 3. Добавление 3–5 горизонтальных ссылок

Связи с сестринскими страницами:
A1 ↔ A2 ↔ A3 ↔ A4 ↔ A5

Шаг 4. Добавление 1–2 ссылок вниз (если релевантно)

Примеры:
Хаб → Статья
Услуга → FAQ
Лонгрид → Часть лонгрида

Шаг 5. Добавление на страницу 1 ссылки на ключевую услугу

Это основной monetization anchor.

Шаг 6. Добавление на страницу ссылки на кейс

Только если есть тематическая связь.

Шаг 7. Проверка правил анкоринга

Прямой: ≤ 20–30%
Частичный: 40–50%
Смысловой: 20–30%

19. Автоматизация перелинковки (engineering level)

Перелинковку можно автоматизировать через:

19.1. Авто-блоки

Типы:
1) «Похожие материалы» (СТАТИЧЕСКИЕ, а не динамические)
2) «Часто читают»
3) «Материалы по теме»
4) «Части руководства»
5) «Связанные услуги»

19.2. API-генерация ссылок

На сайтах с 5 000+ страниц:
— создаем внутренний API: /related/?id=123
— API выдает список «ручных» ссылок, заданных SEO
— редактор не может сломать структуру

19.3. Авто-генерация хабов

На больших сайтах можно генерировать:
— хабы по тегам,
— хабы по категориям,
— хабы по частоте слов.

20. Матрица ошибок (ТОП-30 самых опасных)

ЧАСТЬ 5. Полная пропатченная архитектура перелинковки Toimi.pro

Это готовый технический документ, который можно читать разработчикам, SEO, редактору, PM и руководителю.

1. Общая карта Toimi (высокоуровневая)

2. Архитектура хабов (технический стандарт Toimi)

Каждый хаб:
— собирает тематический PR
— распределяет его вниз (услуги)
— связывает через горизонтальные связи (смежные хабы)
— подключает блог
— подключает кейсы
— подключает длинные лонгриды

Обязательные компоненты хаба:

1) Title (SEO-фокус)
2) 4–10 ссылок на услуги
3) 3–5 ссылок на ключевые статьи
4) 2–3 ссылки на кейсы
5) 2 ссылки на лонгриды
6) 1–2 ссылки на смежные хабы

3. Архитектура услуг Toimi (техрегламент)

Каждая услуга — коммерческий центр PR-системы.
Каждая услуга должна иметь минимум 25–40 входящих ссылок.

Входящие:

— Хаб → Услуга (1)
— Подхаб → Услуга (1)
— Статьи → Услуга (10–20)
— Контент из кейсов → Услуга (2–5)
— Лонгриды → Услуга (3–5)
— PDF → Услуга (1)
— Презентации → Услуга (1)

Исходящие:

— Услуга → 2–4 статьи
— Услуга → хаб
— Услуга → 1–3 кейса
— Услуга → лонгрид
— Услуга → FAQ
— Услуга → 2 смежные услуги

4. Архитектура кейсов (Toimi)

Кейсы — точки распределения E-E-A-T.

Каждый кейс должен выстраивать PR-петлю:
— Услуга → Кейс → Услуга
— Хаб → Кейс → Хаб
— Статьи → Кейс
— Лонгрид → Кейс

Минимальный набор ссылок внутри кейса:

— 1–2 ссылки на услуги
— 1 ссылка на хаб
— 1 ссылка на статью
— 1 ссылка на похожий кейс

5. Архитектура блога (2k+ статей будущего Toimi)

Каждая статья должна иметь:

↑ 1 ссылка на хаб
↑ 1 ссылка на услугу
↔ 2–5 ссылок на смежные статьи
→ 1 ссылка на кейс
→ 1 ссылка на лонгрид

Нельзя:

❌ динамические блоки «похожие»
❌ случайная перелинковка
❌ блочные автолисты

6. Архитектура лонгридов

Лонгриды — главные доноры.
Каждый лонгрид:
— 3–5 ссылок на услуги
— 2–4 на хабы
— 3–6 на статьи
— 1–3 на кейсы

7. Архитектура PDF/HTML-презентаций

PDF должны:
— ссылаться на услуги
— иметь нормальные URL
— быть загружены локально
— попадать в хабы

HTML-презентации должны иметь:

→ Услуги
→ Хабы
→ Кейсы
→ Лонгриды

8. Полная внутренняя модель Toimi

8.1. Главная модель

8.2. Граф для хаба «web»

9. Ready-to-implement правила разработчикам

Разработчик должен обеспечить:

— В шаблоне статьи — 5 обязательных блоков перелинковки
— В шаблоне услуги — 3 блока
— В шаблоне хаба — 4 блока
— В шаблоне кейса — 4 блока
— Возможность ручного управления перелинковкой
— Возможность API-генерации списков «связанных материалов»

На уровне HTML:

— ссылки — без JS-инъекций
— ссылки — стандартные «a href»
— избегать «div onclick»
— не использовать редиректы JS для внутренних ссылок

10. Алгоритм при создании нового контента

Каждый контент обязан пройти 7-ступенчатый цикл:
1) Определить кластер → хаб → услугу
2) Назначить 2 ссылки вверх
3) Назначить 3–5 горизонтальных ссылок
4) Назначить 1 ссылку вниз (если есть)
5) Назначить ссылку на услугу
6)Добавить ссылку на кейс
7) Проверить анкорную матрицу

ЧАСТЬ 6. Инженерная инструкция по внутренней перелинковке для агрегаторов и маркетплейсов (50 000 – 5 000 000+ страниц)

Эта глава — профессиональный документ уровня senior+ SEO-инженера.
Можно использовать как blueprint при построении или масштабировании агрегатора любого типа:
— маркетплейс товаров (Ozon, WB, Kaspi),
— агрегаторы услуг (Avito, Profi),
— каталоги недвижимости (DomClick, Cian),
— агрегаторы вакансий (Jooble, HH),
— агрегаторы автомобилей, туров, заведений.

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

1. Базовая структура любого агрегатора

2. Главные технические задачи перелинковки в агрегаторе

Агрегатор ≠ обычный сайт.
Здесь перелинковка должна решать то, что невозможно решить ссылками, контентом и руками:

1) Управление Crawl Budget
Google быстро «захлебывается» на больших сайтах.

2) Управление PageRank-потоками
У агрегаторов много «мусорных» страниц.

3) Поддержание тематического веса
Чтобы категории/подкатегории ранжировались на топ-запросах.

4) Управление фасетами (фильтры)
Они создают миллионы дублей.

5) Борьба с гигантскими графами ссылок
Граф у агрегаторов огромен — миллионы вершин → ошибки стоят в сотни миллионов потерянных страниц.

3. Главная формула для перелинковки агрегаторов

Внутренний граф агрегатора должен быть:
Иерархический → Контролируемый → Ограниченный → Целевой → Тематически плотный

Запрещено:
❌ бесконечные цепочки похожих товаров
❌ циклические алгоритмы рекомендаций
❌ автогенерация ссылок без верхних лимитов
❌ хаотичные «related» блоки
❌ навигация, которая создает 10 000+ версий страниц

4. Фундамент: правильная иерархия для перераспределения веса

4.1. Правильная структура (Level 1–4)

Уровень 1 — Главная
Уровень 2 — Категории
Уровень 3 — Подкатегории / Бренды
Уровень 4 — Листинги (товары)

Логика PR-распределения:

Главная → дает 40–55% суммарного веса
Категории → получают 10–20%
Подкатегории → получают 5–10%
Листинги → получают 0.01–0.5%

Важно: листинги не должны конкурировать с категориями в SERP.

5. Правила перелинковки для каждого уровня

5.1. Главная → Категории

Главная должна ссылаться только на:
— топ-категории,
— несколько брендовых хабов,
— 0 ссылок на листинги.

Количество ссылок: 20–60

Минимум → PR-сопротивление↓
Максимум → размывание PR↑

5.2. Категории → Подкатегории

Каждая категория:
— должна ссылаться на 100% подкатегорий (если их ≤100),
— должна иметь статический, не динамический список,
— может иметь до 3 статей-гайдов.

Запрещено:
❌ выводить все подтеги или фильтры (создает тысячи дублей).

5.3. Подкатегории → Листинги

Правильная логика:
Подкатегория должна ссылаться только на первых N листингов, где выбран лимит N.

Рекомендуемый лимит:

E-commerce: N = 40–80
Недвижимость: N = 50–120
Авто: N = 20–60
Услуги: N = 10–40

Зачем лимит?

Если на странице 500–10 000 листингов:
— PR размазывается
— Crawl Budget уходит на бесконечные листинги
— Google не индексирует глубину
— падение ранжирования категорий

5.4. Листинги: куда должны ссылаться

Листинг должен давать вес вверх:
Листинг → Подкатегория
Листинг → Категория

Дополнительно:
Листинг → Похожие товары (строгий лимит)

Лимиты похожих товаров:

— E-commerce — 4–8
— Недвижимость — 6–12
— Авто — 6–10
— Услуги — 4–8

Нельзя:
❌ related=20+
❌ related=бесконечные карусели
❌ related=авто-сгенерированные без лимита

6. Фасетная навигация (фильтры) — самая опасная часть любого агрегатора

6.1. Почему фасеты разрушают граф

Каждый фильтр = новая URL:
/krossovki?color=white  
/krossovki?color=white&brand=nike  
/krossovki?color=white&brand=nike&size=43  
/krossovki?color=white&brand=nike&size=43&season=summer

Это приводит к:
— миллионам дублей
— 99.99% мусорных страниц
— истощению Crawl Budget
— снижению PR категорий
— утечке веса в пустые запросы
— каннибализации

6.2. Белый список фасетов

Единственно правильный подход:
индексировать только те фильтры, которые имеют спрос в поиске.

Например:
/krossovki/muzhskie/
/krossovki/zimnie/
/krossovki/nike/

Что индексировать нельзя:

❌ size
❌ color
❌ material
❌ price
❌ availability
❌ sale=true
❌ sort=asc/desc

6.3. Ограниченная перелинковка фасетов

Перелинковывать можно только фасеты из белого списка.

Правильная модель:
Категория → Подкатегория → Фасет (индексируемый)
Подкатегория → Фасет (индексируемый)
Фасет → Подкатегория

Нельзя:
❌ листинг → фасет
❌ фасет → фасет
❌ фасет → сортировки

7. Оптимизация Crawl Budget (главная часть руководства)

Google краулит не весь сайт, а:
— страницы с входящими ссылками
— страницы с низкой глубиной
— страницы с высоким PR
— часто обновляемые разделы
— индексируемые фасеты
— хабы
— категории

7.1. Формула оптимального обхода

Для агрегатора важно, чтобы:
80% бюджета → ключевые категории + подкатегории
10% → листинги
5% → фасеты
5% → служебные разделы

Если листинги получают больше 30–50% краулинга →
категории начинают выпадать из топа.

8. Архитектура перелинковки для агрегаторов

8.1. Высокоуровневый граф

8.2. Граф фасетов (с учетом белого списка)

Листинги → только вверх

8.3. Граф похожих листингов

Строго 4–8 ссылок.

9. Линковка инфо-контента в агрегаторах

Нужно усилить категории с помощью статей.

Каждая статья должна ссылаться на:
— Категорию
— Подкатегорию
— Сводный материал
— Топ-листинг

10. Линковка страниц продавцов / компаний

Если агрегатор содержит страницы продавцов:
Продавец → Категория → Подкатегория → Листинги продавца

11. Линковка брендов

Бренды — мощные страницы.

Правильно:
— Категория → Бренд
— Бренд → Листинги бренда
— Бренд → Подкатегория (иногда)
— Листинг → Бренд

12. Контроль циклов и петлей (infinite loops)

Правило:
никаких бесконечных цепочек рекомендаций.

Типовая ошибка:
A → B → C → D → A → ...
Google теряет бюджет.

Решение:

— строгие лимиты связей,
— циклы не длиннее 3–5 узлов,
— контроль depth-first/breadth-first.

13. Стандарты перелинковки для агрегаторов — финальная таблица

13. Стандарты перелинковки для агрегаторов — финальная таблица