Внутренняя перелинковка: как связать услуги, статьи и кейсы

Перелинковка начинается с роли страницы

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

Сначала нужен реестр URL с назначением каждой страницы. В управленческом смысле это карта ответственности: команда понимает, какой вопрос принадлежит URL, куда вести человека дальше и кто пересмотрит связь при изменении структуры. Минимальный набор полей:

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

Свяжите роли в понятный маршрут

Хаб помогает выбрать направление, а не просто перечисляет URL. Для большого журнала ему нужны стабильная пагинация или другой проверяемый путь ко всем материалам. Фильтр, поиск и кнопка, которая подгружает карточки только после действия, не должны быть единственным способом добраться до старых статей.

Страница услуги сохраняет коммерческий интент и не превращается в энциклопедию. Если частный вопрос глубоко раскрыт в статье, достаточно краткого ответа и контекстной ссылки. Например, страница SEO-продвижения объясняет состав услуги, а отдельное руководство может разобрать один этап работы.

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

Кейс B2B-бухгалтерии с длинной воронкой можно использовать как пример страницы-доказательства в длинном коммерческом маршруте. Он не доказывает отдельный эффект внутренней перелинковки.

Задайте для каждой ссылки рабочий контракт

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

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

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

Разберите одну связь от источника до проверки

Выбирайте цель до анкора

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

У цели должны совпасть четыре признака:

1. Она отвечает на следующий вопрос читателя.
2. Ее основной интент не дублирует источник.
3. Она доступна по финальному каноническому адресу.
4. Она дает новое действие или новую глубину, а не повторяет тот же абзац.

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

Так статья про выбор CMS может вести на материал об ограничениях CMS для SEO, но не обязана ссылаться на каждую страницу, где упомянуты WordPress, Tilda или Bitrix.

Пишите анкор как обещание перехода

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

Слабый вариант:

Подробнее <a href="/services/seo">здесь</a>.

По слову «здесь» нельзя понять, что откроется после клика. Лучше назвать действие или объект:

Если нужен аудит и внедрение, изучите<a href="/services/seo">состав SEO-продвижения</a>.

Анкор не обязан дословно повторять основной запрос целевой страницы. Естественные варианты полезнее механического точного повтора ключевой фразы в каждом материале:

• состав SEO-продвижения;
• как проходит SEO-аудит и внедрение;
• работа со структурой и внутренними ссылками.

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

Не собирайте ссылки в плотные списки

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

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

Ссылка должна существовать в доступном HTML

Для Google наиболее надежный вариант - элемент <a> с href, который содержит разрешимый URL. Это описано в технических требованиях к ссылкам. Яндекс также рекомендует обычные HTML-ссылки в структуре сайта.

Рабочий пример:

<a href="/expertise/internal-linking-guide">  Внутренняя перелинковка сайта</a>

Рискованный вариант:

<span onclick="openArticle('internal-linking-guide')">  Внутренняя перелинковка сайта</span>

Второй элемент может работать для пользователя с JavaScript, но не является обычной ссылкой. Если карточки или блоки рекомендаций вставляются скриптом, нужно проверить HTML после отрисовки. Яндекс предлагает для этого инструмент рендеринга страниц JavaScript. Для Google фактический HTML также проверяют доступным инструментом инспекции URL.

Ведите сразу на финальный URL

Внутренние ссылки не должны регулярно проходить через 301 или 302, старый домен, HTTP-версию, вариант с лишним слешем или параметр, который затем канонизируется на другой адрес. Google отдельно рекомендует ссылаться на канонический URL, а не на дубль. Редирект нужен для сохранения старого входа извне, но собственный сайт может ссылаться сразу на конечную страницу.

Для каждой цели проверяют:

• ответ 200;
• canonical указывает на этот же финальный URL;
• разрешенную индексируемость, если цель должна участвовать в поиске;
• отсутствие цепочки редиректов;
• один нормализованный формат URL;
• доступность ссылки в исходном или отрисованном HTML;
• непустой текст ссылки или корректный alt у изображения-ссылки.

Семантику элемента <a> и роль href можно сверить со справочником MDN. Но технически валидная ссылка еще не становится полезной: ее смысл проверяется отдельно.

Найдите страницы-сироты и ложные входы

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

Страница-сирота не получает внутренних ссылок из доступной части сайта. Она может присутствовать в CMS, Sitemap, аналитике или старом отчете, но обычный обход от главной и хабов до нее не доходит.

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

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

• ссылка появляется только после внутреннего поиска;
• карточка доступна лишь при выбранном фильтре;
• блок рекомендаций случайно меняется при каждой загрузке;
• URL существует только в Sitemap;
• ссылка ведет через сломанный редирект;
• цель закрыта от индексирования, хотя указана как приоритетная;
• переход реализован кнопкой без href;
• хаб показывает только первую страницу и не дает пути к архиву.

Sitemap помогает сообщить поисковой системе об URL, но не объясняет пользователю отношения между материалами. Поэтому карта сайта дополняет внутренние ссылки, а не заменяет их.

Проведите аудит как сравнение нескольких реестров

Я бы не принимал аудит, построенный только на отчете одного краулера. Он показывает лишь ту часть сайта, до которой уже смог добраться по ссылкам. Чтобы обнаружить сироты и ложные входы, результат обхода сравнивают с реестром CMS, Sitemap, аналитикой и поисковыми данными.

1. Соберите полный список кандидатов

В реестр входят:

• опубликованные URL из CMS;
• индексируемые страницы из Sitemap;
• страницы с показами и кликами из поисковых панелей;
• посадочные страницы из аналитики;
• URL из серверных логов, если они доступны;
• известные старые адреса и карта редиректов;
• результаты обычного обхода от главной.

Каждый источник отражает только свою часть сайта. Их объединение помогает найти URL, которые существуют вне текущего ссылочного графа.

2. Обойдите сайт от разрешенных точек входа

Краулер должен использовать зафиксированные параметры обхода, учитывать директивы robots и правила выбора канонического URL. Для JavaScript-сайта полезно сравнить обход исходного HTML и отрисованной версии. Так видно, исчезают ли карточки, пагинация или анкоры без выполнения скриптов.

3. Сопоставьте входящие и исходящие связи

Для каждого индексируемого URL нужны минимум:

• число уникальных внутренних источников;
• список фактических страниц-источников;
• тип каждой ссылки;
• анкоры;
• исходящие цели;
• глубина от родительского хаба;
• статус и canonical цели;
• признак сироты или связи только через Sitemap.

Количество не оценивается само по себе. Одна ссылка из точного тематического контекста может быть полезнее десятков одинаковых ссылок из общего подвала.

4. Используйте панели как контроль, а не единственный реестр

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

В Яндекс Вебмастере статистика обхода помогает увидеть посещенные роботом URL, время обхода и полученный ответ. Эти данные полезны для контроля, но причину повторного обращения к адресу нужно подтверждать отдельно.

5. Расставьте приоритеты

Сначала исправляют проблемы, которые разрывают путь:

Встройте связи в выпуск нового материала

Перелинковка быстро устаревает, если проводится отдельным проектом раз в год. У каждого нового URL должен быть короткий выпускной протокол.

До публикации

1. Подтвердить главный вопрос страницы и финальный адрес.
2. Выбрать родительский хаб.
3. Назначить полезные исходящие ссылки в тексте.
4. Найти две-три существующие страницы, где новый ответ действительно продолжает мысль.
5. Подготовить анкоры и контекст для входящих ссылок.
6. Проверить, что новый маршрут локально отвечает 200.

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

После локального появления URL

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

После разрешенного деплоя

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

Автоматизируйте повторение, но не выбор смысла

Автоматизация хорошо находит битые ссылки, редиректы и страницы без входов. Решить, какой URL важнее для человека и бизнеса, она не может: этот приоритет должен оставаться за владельцем структуры.

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

Для каждого материала полезно хранить:

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

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

Почему одного тега недостаточно

Тег SEO может объединить десятки материалов: от robots.txt до цены услуги. Случайная выборка по тегу не знает, какой вопрос продолжает текущий абзац. Она способна показать разные карточки при каждой загрузке и оставить часть архива без стабильного входа.

Надежнее использовать типизированные отношения:

• explains - подробно объясняет упомянутый вопрос;
• proves - показывает реальный кейс или доказательство;
• compares - помогает выбрать между вариантами;
• next_step - ведет к услуге или действию;
• parent - возвращает в раздел;
• related - продолжает тему без дублирования интента.

Названия полей могут быть другими. Важно, чтобы CMS хранила смысл связи, а не только совпавший тег.

Какие проверки стоит автоматизировать

• индексируемый URL без внутренних входов;
• ссылка на 4xx, 5xx или цепочку редиректов;
• ссылка не на канонический вариант;
• пустой анкор или изображение-ссылка без полезного alt;
• одинаковый точный анкор у разных целей как сигнал для ручной проверки;
• карточка, которая не выводится ни в одном доступном хабе;
• новый материал без родительского раздела, связанной услуги или исходящих связей;
• удаленный URL, который остается в хабе, статье или блоке рекомендаций;
• различие между серверным и отрисованным графом ссылок.

Автоматическая проверка находит нарушение контракта. Она не решает, должны ли две страницы конкурировать, какой кейс честно подтверждает метод и нужен ли конкретный переход человеку.

Оценивайте результат на трех уровнях

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

Технический уровень

• важные страницы входят в ссылочный граф;
• сироты перечислены и получили решение;
• ссылки доступны как <a href>;
• цели отвечают 200 и совпадают с canonical;
• нет массовых редиректов и битых переходов;
• хабы и пагинация открывают весь индексируемый каталог;
• исходный и отрисованный HTML не теряют важные ссылки.

Поисковый уровень

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

Нельзя приписывать рост позиции только внутренней ссылке, если одновременно менялись текст, метаданные, canonical или содержание хаба.

Пользовательский уровень

Если аналитика переходов уже настроена, можно проверить:

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

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

Чек-лист приемки перелинковки

Перед завершением работ проверьте:

• у каждой индексируемой страницы есть владелец интента;
• хаб дает доступ ко всему индексируемому каталогу;
• важные URL получают минимум одну внутреннюю HTML-ссылку;
• страницы-сироты найдены сравнением обхода, CMS, Sitemap и поисковых данных;
• входящие и исходящие ссылки отвечают роли страницы;
• слова «здесь» и «подробнее» не являются единственным анкором;
• одинаковые анкоры у разных целей проверены в контексте и не вводят читателя в заблуждение;
• ссылки ведут на финальные canonical URL с ответом 200;
• важные переходы видны в отрисованном HTML;
• пагинация и фильтры не являются единственным путем к архиву;
• блоки рекомендаций стабильны или дополняют стабильные связи;
• кейсы используются только в подтвержденном контексте;
• новый материал получил родителя, исходящие и входящие связи;
• перенос и удаление URL сопровождаются обновлением внутренних ссылок;
• данные поисковых панелей не приняты за единственный реестр;
• результат не сведен к числу ссылок и не объявлен гарантией роста.

Внутренняя перелинковка становится системой, когда связь можно объяснить, воспроизвести и проверить. Услуга показывает коммерческий маршрут, статья закрывает частный вопрос, кейс подтверждает реальную работу, а хаб помогает выбрать направление. Если сайту нужен аудит такой структуры и план внедрения без массовой расстановки случайных анкоров, следующим шагом может быть SEO-продвижение Медиакода.