Смысл и границы
Общие анкоры встречаются и в интерфейсах, и в тексте. Сами по себе они не вредны, но их смысл зависит от соседнего контекста. Читателю с программой чтения с экрана, тому, кто просматривает страницу, или тому, кто смотрит список ссылок, «нажмите здесь» даёт меньше информации о месте назначения, чем формулировка, которая это место называет.
Порядок работы на практике
Сначала напишите предложение, а потом выбирайте адрес ссылки, которая действительно помогает читателю двигаться дальше. Если позволяет место, пусть текст ссылки описывает страницу назначения: «руководство по канонизации» понятнее, чем «читать далее». Короткий общий элемент управления может работать, если его карточка, заголовок и доступное имя уже однозначно показывают, куда он ведёт.
Что проверять
Проверьте образец шаблона в контексте и в виде списка ссылок. Убедитесь, что ссылки — настоящие элементы <a href>, доступные для сканирования, и ведут на релевантный итоговый URL. Повторяющиеся общие элементы управления в карточках, пагинации и навигации проверяйте отдельно: то, что визуально понятно, вне своего макета может оказаться расплывчатым.
Ограничения и частые ошибки
Не набивайте анкоры ключевыми словами, чтобы заменить каждую общую фразу. Google рекомендует описательный текст ссылок для людей и поисковых роботов, а правила против спама запрещают манипулятивные практики со ссылками. Понятность и редакционная релевантность важнее формульного набора анкоров.
Доступные формулировки ссылок на практике
Сетка карточек часто выявляет слабость общих подписей. Пять карточек могут заканчиваться одинаковым «Читать далее», но в списке ссылок для программы чтения с экрана окажется пять одинаковых пунктов, за которыми скрыты разные страницы. Исправьте компонент так, чтобы доступное имя указывало на страницу назначения: например, видимый заголовок карточки со ссылкой на её страницу или краткий элемент управления с aria-label, в котором есть заголовок. Не используйте ARIA, чтобы замаскировать запутанный визуальный путь: видимая связь между элементами тоже должна быть понятной.
<article>\n <h3><a href="/guides/canonical">Canonical URL guide</a></h3>\n <a href="/guides/canonical" aria-label="Read the Canonical URL guide">Read more</a>\n</article>Проверяйте текст ссылки на трёх уровнях: отдельное предложение, окружающий компонент и извлечённый список ссылок. Убедитесь, что по адресу назначения открывается итоговый публичный URL, что анкор — настоящий элемент <a href>, и что у ссылок, состоящих только из изображения, есть подходящий альтернативный текст. Затем проверьте порядок фокуса с клавиатуры и вид на узком экране, где подписи могут обрезаться или отрываться от заголовков.
Рабочее редакционное правило простое: пишите ссылку для человека, который не читал абзац перед ней. Общая фраза допустима, если адрес назначения и так очевиден, например одиночная кнопка «Продолжить» в коротком последовательном сценарии. Слабо это выглядит, когда несколько одинаковых элементов ведут на разные страницы. Это различие в удобстве использования, а не указание вставлять ключевое слово в каждую ссылку.
Требования Google к ссылкам, доступным для сканирования, предполагают обычные элементы anchor и советуют релевантный текст или атрибуты alt у изображений. Это поддерживает описательные ссылки, но не оправдывает искусственные анкоры во внешних размещениях. Записывайте повторяющиеся неоднозначные элементы по названию компонента, исправьте шаблон один раз, а затем повторно просканируйте образец шаблона, чтобы убедиться, что не появились битые или дублирующие адреса назначения.
Для регулярной проверки найдите в сайте после рендеринга повторяющиеся общие подписи, сгруппируйте их по компонентам и выборочно проверьте адреса назначения. Ведите список «было и стало» с подписями и целевыми URL. Так изменение легче проверить, а также ловится частая регрессия: меняется только видимый текст, а недоступная ссылка-изображение или дублирующий адрес остаются без изменений.