Битая ссылка

Происхождение и история термина

Единой работы, которая «ввела» термин broken link, нет: выражение сложилось в практике веб-разработки вместе с самим вебом. Ранний программный текст о проблеме — заметка Тима Бернерса-Ли «Cool URIs don't change», опубликованная на сайте W3C в 1998 году ^[10]. В ней он пишет о «висячих» ссылках (dangling links) и формулирует принцип стабильных адресов: «A cool URI is one which does not change» («Хороший URI — тот, который не меняется») ^[10]. Там же объяснено, почему это важно владельцу сайта: «When someone follows a link and it breaks, they generally lose confidence in the owner of the server» («Когда человек переходит по ссылке, а она не работает, он обычно теряет доверие к владельцу сервера») ^[10].

Слово linkrot («гниение ссылок») было в ходу уже тогда. В колонке Якоба Нильсена «Fighting Linkrot» (13 июня 1998 года) оно используется без пояснений, а сама проблема названа помехой для пользователей: «Linkrot definitely reduces the usability of the Web» («Гниение ссылок определённо ухудшает удобство веба») ^[17].

Научные измерения начались на рубеже 1990-х и 2000-х. С. Лоуренс и соавторы в мае 2000 года проанализировали 270 977 публикаций по информатике из базы ResearchIndex (CiteSeer) и выяснили, что доля недействительных веб-ссылок в статьях составляла от 23 % для публикаций 1999 года до 53 % для публикаций 1994 года (исторические данные) ^[16]. Обзор Кляйна и соавторов называет и другие ранние работы, например четырёхлетнее наблюдение У. Кёлера за случайной выборкой адресов ^[11].

В 2010-х терминология уточнилась: к link rot добавились content drift и объединяющий термин reference rot ^[11]:

• Link rot — ресурс, на который указывает адрес, перестаёт существовать, и ссылка больше не даёт доступа к содержимому ^[11].
• Content drift («дрейф содержимого») — ресурс по адресу продолжает существовать, но со временем меняется ^[11].
• Reference rot — термин, которым М. Кляйн и соавторы (проект Hiberlink, PLOS ONE, 2014) обозначили сочетание этих двух проблем ^[11].

Трактовки различаются. У Кляйна и соавторов reference rot объединяет link rot и content drift ^[11]. У Дж. Зиттрейна, К. Альберт и Л. Лессига (Harvard Law Review Forum, 2014) link rot — адрес, который вообще перестал отдавать содержимое, а reference rot — случай, когда ссылка работает, но цитируемой информации по ней уже нет или она изменилась ^[12].

Русскоязычное «битая ссылка» — разговорное название, принятое среди веб-разработчиков и SEO-специалистов (наблюдение). В справке Яндекс Вебмастера используется нейтральный вариант — «неработающая ссылка», слово «битые» в ней не встречается ^[1]. Справочник MDN фиксирует английские варианты: ссылки на страницу 404 «are often called broken or dead links» («часто называют битыми или мёртвыми ссылками») ^[14].

Суть и механизм

На странице A в HTML-коде стоит элемент <a href="https://mediatrone.ru/seo/bitaya-ssylka/URL" target="_blank" rel="noopener">. Когда пользователь нажимает на ссылку или робот переходит по ней, клиент запрашивает URL и вместо успешного ответа 200 с нужным содержимым получает ошибку: код 4xx или 5xx, ошибку разрешения домена (DNS), обрыв по таймауту или бесконечную цепочку перенаправлений.

Что видит пользователь. Страницу ошибки. Справка Яндекса определяет неработающую ссылку как ссылку, которая не ведёт на нужную страницу или ресурс либо ведёт к ошибке ^[1]. MDN отмечает, что ошибки 404 ухудшают пользовательский опыт, поэтому число битых ссылок, внутренних и внешних, стоит сводить к минимуму; частые причины 404 — опечатки в адресах и страницы, перенесённые или удалённые без перенаправления ^[14].

Что «видит» поисковый робот.

• Google не использует содержимое адресов, отдающих 4xx; все 4xx, кроме 429, обрабатываются одинаково ^[5]. Такие адреса не индексируются, а уже проиндексированные удаляются из индекса; новые адреса с 404 не обрабатываются, частота их сканирования постепенно снижается; на скорость сканирования сайта коды 4xx (кроме 429) не влияют ^[5].
• При ответах 5xx и 429 роботы Google временно замедляют сканирование; проиндексированные адреса сохраняются в индексе, но в итоге удаляются, если ошибка не проходит ^[5].
• Яндекс в справочнике HTTP-кодов описывает 404 как «Документ не существует», а 410 — как ресурс, который «был окончательно удален с сайта» ^[3].
• Стандарт HTTP (RFC 9110) различает эти коды так: 404 не говорит, временное отсутствие ресурса или постоянное, а 410 означает, что недоступность, скорее всего, постоянна ^[9]. Код 410 в первую очередь нужен для обслуживания веба: он сообщает, что владельцы сервера хотят, чтобы внешние ссылки на ресурс были удалены ^[9].

Где ещё бывают битые ссылки. Не только в <a href>. W3C Link Checker извлекает ссылки и якоря не только из HTML- и XHTML-документов, но и из таблиц стилей CSS ^[15]. Адреса стоят и в служебных указаниях для поисковых систем: в элементе <link rel="canonical"> в <head> страницы ^[24], в элементах <link> с атрибутом hreflang ^[25] и в файле sitemap — списке адресов сайта ^[26]. Для hreflang и sitemap Google требует полные абсолютные адреса ^[25], ^[26]. Перечень мест для проверки (src изображений, скриптов и фреймов, <link href> стилей, canonical, hreflang, sitemap) — обобщение.

Битый якорь. Ссылка вида page.html#section ведёт на фрагмент страницы. По RFC 3986 фрагмент обрабатывается только клиентом: «dereferenced solely by the user agent» («разыменовывается исключительно агентом пользователя») ^[19]. MDN уточняет, что фрагмент не отправляется на сервер, а браузер прокручивает полученную страницу к элементу с таким id ^[22]. Значит, сервер получает тот же запрос, что и без фрагмента, и может ответить 200, даже если нужного элемента нет. По HTML Living Standard браузер ищет элемент с id, равным фрагменту (или a с таким name); если его нет, прокрутки к элементу не происходит ^[23]. Поэтому W3C Link Checker отдельно проверяет ссылки «including the fragments» («включая фрагменты») ^[15].

Виды и классификации

Таблица 1. По расположению ссылки (классификация Яндекса)

Справка Яндекс Вебмастера делит неработающие ссылки на внутренние и внешние ^[1]; переходы по ним описаны в отдельном отчёте ^[2].

Таблица 2. По причине и ответу сервера

Составлена по RFC 9110 ^[9], документации Google ^[5]–^[7] и справочнику кодов Яндекса ^[3].

Разграничение со смежными терминами

• Ошибка 404 — ответ сервера на запрос адреса. Битая ссылка — элемент исходной страницы, ведущий на ошибку, не обязательно 404.
• Цепочка редиректов — серия перенаправлений; слишком длинная цепочка или петля делает ссылку неработающей.
• Страницы-сироты — обратная ситуация: страница существует, но ссылок на неё нет.
• 301-редирект — один из способов исправления, когда страница переехала.

Как применяется на практике

Почему это важно

1. Доверие и удобство. Ошибка вместо нужной страницы снижает доверие к сайту ^[10] и ухудшает пользовательский опыт ^[14].
2. Индексация. Адрес с 4xx выпадает из индекса Google ^[5]. Если на удалённую страницу вели внешние ссылки, а замены нет, они ведут в никуда (вывод).
3. Сканирование. По Google, 4xx (кроме 429) не влияют на скорость сканирования сайта ^[5]; называть массовые 404 «тратой краулингового бюджета» без первоисточника не стоит.
4. Справочные и новостные издания. Для СМИ, энциклопедий и научных текстов битая ссылка означает потерю источника. В исследовании Pew Research Center по выборке страниц из снимка Common Crawl за март–апрель 2023 года 23 % новостных и 21 % государственных веб-страниц содержали хотя бы одну битую ссылку, а 54 % страниц Википедии имели в разделе References хотя бы одну неработающую ссылку ^[13]. Оценка намеренно консервативная: страница считалась недоступной, только если возвращала один из девяти кодов ошибок ^[13]. Данные собраны в 2023 году, опубликованы в мае 2024 года и на дату проверки фактов являются историческими.

Что делать: ситуация → действие

Профилактика

• Стабильные адреса. Главный принцип Бернерса-Ли — проектировать URI так, чтобы их не приходилось менять ^[10].
• План редиректов при редизайне и переезде. Google рекомендует составить соответствие старых и новых адресов и заменить внутренние ссылки ^[8].
• Регулярная проверка. Яндекс советует периодически проверять и исправлять неработающие ссылки ^[1]; полезны проверка перед публикацией и мониторинг 404 в логах — так обычно делают на практике.

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

Инструменты поисковых систем

Яндекс Вебмастер. Отчёт о неработающих ссылках показывает внутренние и внешние ссылки; данные формируются со страниц, которые известны роботу Яндекса ^[1]. Справка называет шесть причин, по которым ссылка может не попасть в отчёт, например страница со ссылкой неизвестна роботу или ссылка появилась недавно ^[1]. Отчёт «Переходы по неработающим ссылкам» строится по обезличенным данным Яндекс Браузера; в записи могут быть адрес страницы со ссылкой, целевой адрес, HTTP-статус (4xx или 5xx), текст ссылки и дата последней проверки роботом; данные выгружаются в XLS или CSV ^[2].

API Яндекс Вебмастера. Метод получения примеров неработающих внутренних ссылок возвращает адрес страницы со ссылкой (source_url), адрес, куда ведёт ссылка (destination_url), дату обнаружения ссылки (discovery_date) и поле source_last_access_date, которое документация описывает как дату последнего посещения роботом страницы назначения ссылки; выборку можно фильтровать по индикатору причины, например DISALLOWED_BY_USER («Страница не существует или ее индексирование запрещено») или UNSUPPORTED_BY_ROBOT ^[4].

Google Search Console. В отчёте «Индексирование страниц» среди причин неиндексирования есть «Not found (404)», «Soft 404», «Blocked due to other 4xx issue», «Server error (5xx)» и «Redirect error» ^[7]. Про 404 справка уточняет, что Google мог обнаружить адрес по ссылке с другой страницы, и что отчёт показывает только адреса, отдававшие 404 в течение последнего месяца ^[7]. Откуда пришла ссылка, помогает понять инструмент проверки URL: поле «Referring page» — «A page that Google possibly used to discover this URL» («страница, через которую Google, возможно, обнаружил этот URL») ^[18]. Оговорки справки: это может быть не страница с прямой ссылкой, а «grandparent or great-grandparent» — страница на один-два шага выше по цепочке; если поля нет, это не значит, что ссылающихся страниц нет ^[18]. Отчёта со всеми битыми ссылками сайта в виде «страница — ссылка — код» в этой справке нет (вывод).

Краулеры, логи, аналитика

• W3C Link Checker читает HTML- или XHTML-документ либо таблицу стилей CSS, извлекает ссылки и якоря, проверяет, что ни один якорь не определён дважды и что все ссылки, включая фрагменты, доступны; предупреждает о редиректах и умеет рекурсивно проверять часть сайта ^[15]. Между запросами к одному серверу он делает паузу не менее секунды и соблюдает правила robots.txt ^[15].
• Настольные и облачные краулеры обходят сайт и выгружают таблицу «страница — ссылка — код ответа» (сервисы не оцениваются).
• Логи сервера: обращения с ответом 404 и заголовком Referer показывают, с какой страницы пришёл запрос (практика редакции; см. Лог-файлы сервера).
• Веб-аналитика: просмотры страницы ошибки и источник перехода на неё.

Метрики (редакционные)

• Доля битых ссылок = число уникальных ссылок с ошибкой ÷ число проверенных уникальных ссылок × 100 %.
• Число страниц, содержащих хотя бы одну битую ссылку, — так Pew Research Center считал долю «поражённых» новостных и государственных страниц ^[13].

Порогов «нормы» для этих метрик в использованной документации Google и Яндекса нет.

Мини-инструмент «Проверка ссылок на странице»

Инструмент готовится к запуску; ниже описано, как он будет работать. До запуска можно пользоваться отчётами Яндекс Вебмастера ^[1], ^[2], Google Search Console ^[7], ^[18] и W3C Link Checker ^[15].

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

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

Выход:

1. Таблица ссылок из a[href], img[src], link[href], script[src], iframe[src]: адрес, тип элемента, внутренняя или внешняя, анкор.
2. Предупреждения:
   • пустой href, href="#" data-section="", javascript: — адрес ссылки должен разрешаться в реальный веб-адрес ^[6];
   • пробелы и недопустимые символы, пропущенная схема. Адрес www.example.com без https:// и без начальных // по RFC 3986 — относительная ссылка (relative-path reference), которая разрешается относительно базового адреса ^[19]: на странице https://example.com/blog/ она превратится в https://example.com/blog/www.example.com;
   • ссылки http:// на странице, открытой по HTTPS;
   • якоря #id, для которых во вставленном HTML нет элемента с таким id;
   • повторяющиеся ссылки, адреса localhost и тестовых доменов.

Режим Б: проверка ответов сервера (одна страница, ограниченное число ссылок, паузы между запросами, соблюдение robots.txt) требует серверной части. Страница в браузере может отправить запрос на чужой адрес, но по политике одного источника (same-origin policy) сценарий, как правило, не может прочитать ответ чужого сервера, если тот не разрешил это заголовками CORS ^[20], ^[21]. Ответы 401, 403, 429, 5xx и таймауты этот режим будет помечать как «перепроверьте вручную», а не как битые ссылки.

Как пользоваться. Вставьте код и адрес страницы, запустите разбор, отмеченные адреса проверьте вручную и примените действие из таблицы «ситуация → действие».

Пример условный. Для страницы https://example.com/blog/ и фрагмента <a href="/about/">О нас</a> <a href="#contacts">Контакты</a> <a href="https://mediatrone.ru/seo/bitaya-ssylka/javascript:void(0)" target="_blank" rel="noopener">Ещё</a> <img src="http://example.com/logo.png"> инструмент выведет четыре ссылки: https://example.com/about (без замечаний), #contacts (предупреждение, если во фрагменте нет элемента с id="contacts"), javascript:void(0) (не веб-адрес) и http://example.com/logo.png (HTTP на HTTPS-странице).

Ошибки, ограничения и спорные вопросы

«Битые ссылки понижают сайт в поиске». Прямого утверждения об этом в использованной документации Google и Яндекса нет. Подтверждено другое: адреса с 4xx удаляются из индекса Google ^[5]; Search Console советует исправлять 404, на которые вы ссылаетесь сами или которые есть в sitemap, а 404 удалённой без замены страницы называет не обязательно проблемой ^[7]; Яндекс советует периодически проверять и исправлять неработающие ссылки ^[1].

Ложные срабатывания проверок. Многие сайты отвечают автоматическим проверщикам иначе, чем браузеру: защита от ботов отдаёт 403 или 429, временный сбой — 5xx. Часть ссылок появляется только после выполнения JavaScript, а некоторые серверы по-разному отвечают на запросы HEAD и GET. Поэтому 403, 429 и 5xx стоит перепроверять вручную (наблюдение).

Массовый 301 на главную — не исправление. Google предупреждает, что перенаправление многих старых адресов на одну нерелевантную страницу может быть воспринято как soft 404 ^[8]. Подробнее — в статье 301-редирект.

Soft 404 маскирует битые ссылки. Если сайт на несуществующий адрес отвечает кодом 200 и текстом «страница не найдена», проверка по коду ответа ссылку битой не посчитает. Google распознаёт такие случаи и показывает их в Search Console как soft 404 ^[5], ^[7].

404 или 410. Google обрабатывает все 4xx, кроме 429, одинаково ^[5]. Яндекс для ресурса, удалённого навсегда, советует обеспечить отдачу 410 ^[3]. RFC 9110 предпочитает 410, если сервер знает, что отсутствие постоянное, но не требует помечать так все удалённые ресурсы ^[9]. Выбор кода не заменяет исправления собственных ссылок.

robots.txt. Справочник Яндекса допускает, что после удаления раздела можно запретить роботу обращаться к нему в robots.txt ^[3]. Это управляет обходом, но не исправляет ссылки на раздел с ваших страниц (вывод).

Живая ссылка — не всегда правильная. При content drift страница открывается с кодом 200, но содержимое уже другое ^[11]. Кляйн и соавторы, изучив более миллиона ссылок на веб-ресурсы из более чем 3,5 млн научных статей 1997–2012 годов, пришли к выводу, что reference rot затрагивает примерно одну из пяти статей в области науки, техники и медицины, а среди статей со ссылками на веб-ресурсы — семь из десяти ^[11] (исторические данные, публикация 2014 года). Зиттрейн, Альберт и Лессиг по базе решений Верховного суда США, полученной 26 июня 2013 года (555 ссылок, самая ранняя — в решении 1996 года), установили, что около половины ссылок (49,9 % по тексту авторов) уже не вели к цитируемому материалу ^[12] (исторические данные: база на 2013 год, публикация 2014 года). Эта доля включает не только неработающие адреса: многие ссылки технически работали, но цитируемой информации там не было или она существенно изменилась ^[12].

Частые вопросы

Связанные термины

• Ошибка 404
• Коды ответа сервера
• 301-редирект
• Цепочка редиректов
• Внутренняя перелинковка
• Обратная ссылка (бэклинк)
• Анкор
• Страницы-сироты
• Сканирование (краулинг)
• SEO-аудит
• Индексация
• Лог-файлы сервера