Как исправить ссылки без href в B2B-базе знаний, чтобы Google мог находить статьи

Почему работающая карточка может быть проблемой

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

Если переход реализован только обработчиком события на карточке, кнопке или элементе a без href, Google не может надёжно извлечь из него URL. Рекомендуемый вариант — элемент a с атрибутом href, содержащим реальный адрес статьи, и понятным текстом ссылки. Эти требования описаны в документации Google о доступных для обхода ссылках.

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

1. Выберите статьи и страницы, которые должны на них ссылаться

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

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

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

Для каждой пары сохраните:

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

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

2. Сравните исходный и отрендеренный HTML

Проверьте исходный код страницы

Откройте каталог или тематический раздел и выберите в браузере просмотр исходного кода страницы. Найдите адрес целевой статьи либо характерную часть её пути.

Если адрес найден, посмотрите, где именно он находится. URL в JSON, атрибуте данных или коде обработчика — не то же самое, что адрес в href элемента a.

Для найденной ссылки проверьте:

• используется ли элемент a;
• есть ли у него href;
• ведёт ли значение href на нужную статью;
• есть ли понятный текст ссылки.

Проверьте разметку после выполнения JavaScript

Откройте инструменты разработчика и найдите карточку во вкладке Elements. Посмотрите, какой элемент получился после загрузки страницы и выполнения скриптов.

Отсутствие ссылки в исходном коде само по себе не доказывает дефект: JavaScript может создавать ссылки. Важно, чтобы результат содержал обычный элемент a с корректным href. Google прямо допускает динамически созданные ссылки, соответствующие этим требованиям, в документации о ссылках.

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

Какие конструкции считать дефектными

Ниже — условные примеры с демонстрационными путями статей:

<!-- Переход работает через событие, но обычной ссылки нет -->
<div class="article-card"
     onclick="window.location.href='/knowledge-base/api-setup'">
  Настройка API
</div>

<!-- Элемент a есть, но адрес отсутствует в href -->
<a onclick="window.location.href='/knowledge-base/api-setup'">
  Настройка API
</a>

Такие конструкции не дают Google надёжного способа извлечь URL как ссылку. При этом сам onclick не является дефектом: Google различает обработчик без href и обработчик на ссылке с корректным href. Основание — примеры допустимых и ненадёжных ссылок Google.

3. Зафиксируйте дефекты в таблице

Таблица должна описывать конкретную пару страниц и наблюдаемую разметку, а не общий вывод «JavaScript мешает SEO».

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

К каждой строке приложите фрагмент найденного HTML и дату проверки. Если в исходном коде ссылки нет, но после рендеринга появляется корректный a с href, зафиксируйте это как наблюдение, а не как подтверждённый дефект.

4. Передайте разработчику конкретное задание

Формулировка задачи может быть такой:

В перечисленных карточках каталога и тематических разделов реализовать переход на статью через элемент a. В href указать реальный URL соответствующей статьи. Текст ссылки должен объяснять, какую инструкцию откроет пользователь. После выполнения JavaScript ссылка должна сохраняться в итоговом HTML. Если обработчик события нужен приложению, он не должен заменять или удалять href.

Пример исправленной карточки:

<a class="article-card" href="/knowledge-base/api-setup">
  Настройка API: подключение и проверка доступа
</a>

Относительный путь допустим, если он разрешается в правильный адрес статьи. В href не следует оставлять пустое значение, # или JavaScript-вызов вместо адреса целевой страницы. Требования к адресам и описательному тексту приведены в документации Google.

Не обязательно отказываться от клиентской маршрутизации или переписывать весь интерфейс. Здесь критерий исправления узкий: в итоговой разметке переход на другую статью представлен настоящей ссылкой с адресом и понятным текстом.

5. Примите исправление через Search Console

После публикации изменений проверьте не только браузер, но и HTML, полученный при проверке Google.

1. Выберите в Search Console ресурс, которому принадлежит страница-источник.
2. Введите URL каталога или тематического раздела — страницы, на которой исправили ссылку.
3. Запустите Test live URL.
4. После завершения откройте View tested page и вкладку HTML.
5. Найдите адрес целевой статьи и убедитесь, что он находится в href элемента a, а у ссылки есть понятный текст.

Порядок проверки текущей страницы и просмотра её HTML описан в справке об инструменте проверки URL. Требования к ссылке в полученной разметке — в документации Google о ссылках.

Не ограничивайтесь скриншотом: он показывает внешний вид карточки, но не подтверждает наличие href. Также недостаточно найти адрес статьи где угодно в HTML — он должен быть частью нужной ссылки.

Чек-лист приёмки

• Для каждой выбранной важной статьи предусмотрена ссылка хотя бы с одной другой страницы сайта.
• Все строки таблицы дефектов проверены после публикации изменений.
• В итоговой разметке каждой исправленной карточки есть элемент a.
• Его href содержит адрес нужной статьи, а не заглушку или скриптовый вызов.
• Текст ссылки позволяет понять, какую статью она открывает.
• Переход работает для посетителя публичной базы знаний.
• В HTML из View tested page подтверждены адрес, элемент a, атрибут href и текст ссылки.

Что подтверждает проверка — и чего она не подтверждает

Не смешивайте четыре разных этапа:

Успешная проверка страницы-источника не подтверждает индексацию статьи, на которую она ссылается. Для этого отдельно введите URL самой статьи в Search Console и изучите данные индекса. Live test проверяет текущее состояние страницы и не гарантирует её индексацию или появление в поиске — это ограничение указано в справке Search Console.

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

Как это связано с Google AI Overviews и AI Mode

Google включает внутренние ссылки в рекомендации по обнаружению контента для AI Overviews и AI Mode. Чтобы страница могла использоваться как supporting link — ссылка на источник в AI-ответе, — она должна быть проиндексирована и допускать показ в Google Search со сниппетом. Выполнение требований не гарантирует включения в AI-ответы: см. документацию Google об AI-функциях поиска.

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

Источники

• Google: доступные для обхода ссылки и текст ссылок.
• Search Console: инструмент проверки URL.
• Google: AI Overviews, AI Mode и требования к страницам.