Внутренние ссылки и orphan pages: как робот находит страницы сайта

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

Такую страницу обычно называют orphan page, или страницей-сиротой. Но статус «сироты» лучше понимать не как ярлык из SEO-инструмента, а как свойство графа: URL существует, однако нормальный маршрут от других доступных страниц сайта к нему отсутствует.

Поисковый робот начинает не со списка всех URL сайта

У Google нет центрального реестра всех страниц каждого сайта. В документации Search Central этап обнаружения URL описан отдельно: часть адресов уже известна, часть находится через ссылки на ранее обработанных страницах, ещё часть может быть сообщена через sitemap.

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

Главная
  ├── Раздел A
  │     ├── Статья 1
  │     └── Статья 2
  └── Раздел B
        └── Статья 3

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

Что считать orphan page на практике

У термина нет отдельного официального статуса в Google Search Console. Для технического аудита удобно использовать рабочее определение:

Orphan page — это URL, который относится к сайту, но не имеет входящего пути из нормального crawlable-графа внутренних страниц.

Здесь важны слова «из нормального графа». Если две изолированные страницы ссылаются только друг на друга, формально входящие ссылки у них есть, но от остального сайта этот маленький кластер всё равно отрезан.

Главная → Категория → Статья A

Статья X ↔ Статья Y
   ↑
нет пути от основного сайта

Такой случай полезнее считать изолированным кластером, а не объявлять проблему решённой из-за одной технически существующей ссылки.

Orphan page и dead-end page — разные проблемы

Страница-сирота не имеет нормального входящего маршрута. Dead-end page, наоборот, может быть легко доступна с других страниц, но сама никуда не ведёт.

Состояние	Входящие внутренние пути	Исходящие ссылки
Обычная связанная страница	Есть	Обычно есть
Orphan page	Нет пути из основного графа	Могут быть
Dead-end page	Есть	Нет или почти нет

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

Не любая визуальная кнопка является crawlable link

Google прямо рекомендует использовать обычный HTML-элемент <a> с атрибутом href. Например:

<a href="/publications/http-kody-veb-stranicy/">
  HTTP-коды веб-страницы
</a>

А конструкции, где переход живёт только в JavaScript-событии, менее надёжны как способ дать crawler адрес:

<div onclick="goTo('/publications/http-kody-veb-stranicy/')">
  HTTP-коды
</div>

JavaScript может динамически вставить ссылку, и Google способен её обработать, если в rendered HTML появляется нормальный <a href>. Поэтому для клиентского интерфейса проверяют не только визуальный результат, но и фактическую разметку ссылки после рендеринга.

Анкор нужен не для механического повторения ключа

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

Сравним:

Плохо:
<a href="/canonical/">читать здесь</a>

Лучше:
<a href="/canonical/">как работает canonical URL</a>

Но это не повод превращать каждый внутренний анкор в одинаковую точную ключевую фразу. Если ссылка естественно продолжает мысль, её текст можно подстроить под предложение. Задача — объяснить переход, а не создать повторяющийся шаблон.

Количество внутренних ссылок само по себе мало что говорит

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

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

Поэтому в этой серии статей мы не ставим ссылки «по норме». Связь появляется там, где у читателя возникает следующий реальный вопрос.

Sitemap может сообщить URL, но не делает страницу частью навигации

Это один из главных источников путаницы. Google может обнаружить адрес из XML Sitemap. Значит, orphan page не обязательно неизвестна поисковой системе.

Но sitemap и внутренний граф выполняют разные функции. Google пишет, что при хорошо связанной структуре большинство важных страниц обычно можно обнаружить через навигацию; sitemap помогает сообщать URL, особенно на больших, новых или сложных сайтах, но не гарантирует crawling или indexing.

Иными словами:

Sitemap:
Google знает, что URL существует.

Internal links:
у URL есть место и путь внутри сайта.

Поэтому добавление страницы в sitemap не превращает её автоматически в связанную страницу. Механику XML-файла и его реальные ограничения разберём отдельно в статье про XML Sitemap.

Как реально находить orphan pages: сравнивать два множества URL

Один обычный crawler не может сам по себе показать все страницы-сироты. В этом и состоит парадокс: если инструмент начинает только с главной и следует по внутренним ссылкам, настоящий orphan URL он как раз не увидит.

Поэтому диагностика строится на сравнении.

Множество A: URL, которые должны существовать	Множество B: URL, найденные crawl от входных страниц
XML Sitemap	Ссылки из главной и навигации
URL из CMS или базы данных	Контекстные внутренние ссылки
Страницы из Search Console	Ссылки из категорий, архивов, хлебных крошек
URL из аналитики или серверных журналов	Другие crawlable `<a href>`

Кандидаты в orphan pages = A − B.

Это диагностическая модель, а не формула Google. Её ценность в другом: она заставляет искать известные URL вне crawl-графа, вместо того чтобы ожидать от crawler список страниц, до которых он физически не смог дойти.

Search Console Links не является полным инвентарём ссылок

В Links report можно посмотреть внутренние link targets, но Google описывает этот отчёт как выборку ссылок. Поэтому отсутствие URL в отчёте не доказывает, что внутренней ссылки нет вообще, а наличие данных не заменяет собственный crawl сайта.

Для одной проблемной страницы полезнее сочетать несколько наблюдений: найти фактические href на сайте, проверить доступность source pages, посмотреть URL Inspection и сравнить это с собственным графом.

Иначе диагностический инструмент легко принять за саму архитектуру.

Найденную страницу-сироту не всегда нужно «спасать ссылкой»

Это важнее самого поиска orphan URLs. После обнаружения нужно спросить: должна ли эта страница вообще оставаться самостоятельным индексируемым документом?

Что обнаружили	Следующий вопрос	Возможное действие
Полезная актуальная статья	Где читатель естественно должен её находить?	Встроить в раздел или поставить релевантную контекстную ссылку
Старый URL после переноса	Есть ли новая точная замена?	Проверить permanent redirect
Дубль основной страницы	Нужны ли обе версии?	Проверить canonicalization или архитектуру URL
Техническая/служебная страница	Должна ли она появляться в поиске?	Решать indexing/crawling задачу отдельно
Слабый или устаревший материал	Есть ли у него самостоятельный user job?	Обновить, объединить или удалить — не добавлять ссылку автоматически

Иначе аудит превращается в странную процедуру: сначала найти мусорный URL, а потом специально усилить его внутренней ссылкой только потому, что инструмент назвал его orphan.

Что проверить у внутренней ссылки кроме самого href

Source page доступна? Если страница-источник сама изолирована или недоступна crawler, её ссылка не создаёт нормальный путь из основного графа.
Target отвечает ожидаемо? Внутренняя ссылка на redirect, ошибку или неканонический дубль усложняет маршрут.
Ссылка присутствует в HTML или rendered HTML? Особенно если навигацию формирует JavaScript.
Анкор объясняет переход? «Подробнее» без контекста слабее, чем текст, описывающий следующий материал.
Связь нужна пользователю? Тематическая похожесть сама по себе ещё не причина ставить ссылку.

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

Минимальная проверка нового URL после публикации

Для новой важной страницы достаточно пройти короткий маршрут:

URL отвечает ожидаемым HTTP-кодом.
Нет случайного запрета в robots/noindex.
Canonical указывает на ожидаемую версию.
Есть хотя бы один осмысленный путь из связанной доступной страницы.
Ссылка реализована как crawlable <a href>.
Если ссылка добавляется JavaScript-ом, она присутствует в rendered HTML.
В sitemap находится канонический URL, если сайт использует sitemap для этого типа страниц.

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

Внутренняя связность — часть технической готовности страницы

У URL может быть 200 OK, корректный canonical и доступный HTML, но это ещё не означает, что сайт нормально ведёт к нему crawler и пользователя. Поэтому внутренние ссылки проверяются не как декоративный SEO-слой, а как часть маршрута обнаружения и навигации.

Для целевой страницы этот слой логично смотреть вместе с HTTP, robots/noindex, canonical и rendering — в общей проверке технической готовности страницы.

Главный вывод короткий: страница существует не только потому, что у неё есть URL. Для сайта она становится частью структуры тогда, когда к ней есть осмысленный, технически доступный путь.

Источники

Источники проверены 19 августа 2026 года. Поведение Google сверено с актуальной официальной документацией Search Central и Search Console Help. Термин orphan page используется в статье как рабочее понятие технического аудита, а не как отдельный официальный статус Google.