Как найти страницы-сироты на сайте и вернуть их во внутреннюю перелинковку

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

Что считать страницей-сиротой

Для практического SEO-аудита страницей-сиротой удобно считать индексируемый или потенциально полезный URL, который существует на сайте, но не получает обычных внутренних HTML-ссылок с других доступных страниц.

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

Главная проверка: URL присутствует в sitemap, аналитике, серверных логах, CMS или данных поисковой системы, но отсутствует среди страниц назначения внутренних ссылок при полном обходе сайта. Такой URL нужно проверять вручную, а не автоматически считать ошибкой.

Шаг 1. Получить список URL, доступных через внутренние ссылки

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

Перед обходом задайте единые правила, иначе сравнение будет загрязнено дублями:

выберите основной протокол: обычно HTTPS;
учитывайте только нужный hostname;
нормализуйте завершающий слеш в соответствии с архитектурой сайта;
не смешивайте URL с параметрами и их канонические версии без необходимости;
не превращайте фрагменты вида #section в отдельные страницы.

После обхода экспортируйте минимум два поля:

URL страницы;
количество входящих внутренних ссылок или список источников этих ссылок.

Этот экспорт назовём Crawl. Он показывает страницы, которые краулер реально смог обнаружить из структуры сайта.

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

Шаг 2. Выгрузить XML Sitemap

Следующий источник — XML Sitemap. Получите все URL из sitemap и всех вложенных sitemap-файлов, если используется sitemap index.

Список назовём Sitemap.

Само присутствие URL в sitemap не доказывает, что страница должна индексироваться или что она является сиротой. Sitemap — только источник известных URL. В нём могут оставаться удалённые, перенаправленные, неканонические или технические страницы.

Для каждого URL из Sitemap позже потребуется проверить как минимум HTTP-ответ, возможность индексации и canonical.

Шаг 3. Добавить URL из аналитики

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

Такой список назовём Analytics.

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

Перед сравнением удалите служебные параметры, если система аналитики записывает один документ как множество URL, например варианты с рекламными метками. Делать это нужно только для параметров, назначение которых известно. Нельзя автоматически удалять все query-параметры: на некоторых сайтах они определяют отдельный контент.

Шаг 4. Использовать серверные логи

Логи веб-сервера позволяют обнаружить URL, которых нет ни в sitemap, ни в текущей перелинковке. Выберите запросы к HTML-страницам вашего сайта и исключите очевидные статические ресурсы: изображения, CSS, JavaScript, шрифты и другие файлы, которые не являются документами.

Список можно назвать Logs.

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

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

запросы к давно удалённым адресам;
ошибочные URL;
сканирование ботами случайных путей;
редиректы;
404 и другие ответы.

Поэтому HTTP-статус необходимо проверять отдельно.

Шаг 5. Добавить URL из CMS и базы контента

Для крупного сайта полезно получить список опубликованных сущностей непосредственно из CMS: статей, товаров, категорий, справочных страниц и других типов контента.

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

Не выгружайте без фильтрации черновики, preview-URL, служебные записи и административные страницы.

Шаг 6. Сравнить списки

После нормализации URL создайте объединённую таблицу. Для каждого адреса достаточно следующих колонок:

URL	Crawl	Sitemap	Analytics	Logs	CMS
/guide/example/	нет	да	да	да	да
/category/example/	да	да	да	да	да

Основные кандидаты в сироты определяются условием:

Crawl = нет
И
(Sitemap = да ИЛИ Analytics = да ИЛИ Logs = да ИЛИ CMS = да)

Если ваш краулер отдельно экспортирует число входящих ссылок, полезна и вторая проверка:

Internal inlinks = 0

Не объединяйте два критерия вслепую. Некоторые инструменты могут добавить URL в crawl из sitemap, API или другого дополнительного источника. Тогда страница окажется в общем экспорте, хотя внутренних HTML-ссылок на неё действительно нет. Для окончательной классификации ориентируйтесь именно на входящие внутренние ссылки.

Шаг 7. Проверить каждый найденный URL

Автоматическое сравнение даёт кандидатов, а не окончательный список ошибок. Для каждого кандидата последовательно проверьте:

HTTP-ответ. Полезная страница обычно должна отдавать конечный успешный ответ. Редиректы, 404 и другие состояния требуют отдельной обработки.
Тип страницы. Убедитесь, что это реальный HTML-документ, а не файл, API или технический маршрут.
Индексируемость. Проверьте robots meta и другие применяемые сайтом механизмы управления индексированием.
Canonical. Если страница указывает canonical на другой URL, сначала выясните, является ли текущий адрес самостоятельным документом или дублем.
Наличие ссылки. Найдите страницу в исходном HTML других документов. Ссылки, формируемые только нестандартными сценариями, могут обрабатываться SEO-инструментами иначе.
Ценность страницы. Решите, должна ли она вообще оставаться доступной и индексируемой.

Шаг 8. Разделить сироты по причине появления

Исправление зависит от причины. На практике полезно разделить найденные URL как минимум на четыре группы.

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

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

Не ограничивайтесь ссылкой из sitemap: XML Sitemap не заменяет внутреннюю навигацию.

Страница нужна только для узкой кампании

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

Страница устарела

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

URL является дублем

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

Как правильно вернуть страницу во внутреннюю перелинковку

Для полезной страницы выберите ссылки не случайно, а по смыслу. Наиболее полезные места:

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

Анкор должен описывать назначение перехода. Не требуется вставлять одинаковую ключевую фразу во все ссылки.

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

Шаг 9. Повторно проверить сайт

После изменений выполните новый crawl с теми же настройками, что использовались при первоначальной проверке.

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

краулер обнаруживает URL, начиная обход с обычной точки входа сайта;
у URL есть хотя бы одна ожидаемая внутренняя HTML-ссылка;
ссылка ведёт непосредственно на нужный адрес, если промежуточный редирект не предусмотрен архитектурой;
страница возвращает ожидаемый HTTP-ответ;
canonical и правила индексирования соответствуют принятому решению;
sitemap не содержит URL, которые сайт больше не считает актуальными каноническими страницами.

После этого снова сравните Crawl со всеми внешними относительно графа ссылок источниками. Разница должна содержать только намеренно изолированные, технические или уже обработанные URL.

Что часто даёт ложные результаты

Первый источник ошибок — разные форматы одного URL. Например, варианты HTTP/HTTPS, с www и без него, с завершающим слешем и без него могут попасть в таблицу как разные записи.

Второй источник — JavaScript-навигация. Возможности конкретных SEO-краулеров по рендерингу JavaScript различаются и зависят от продукта и его версии. Без проверки документации используемого инструмента нельзя утверждать, что он увидит те же ссылки, что браузер после выполнения сценариев.

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

Также нельзя считать страницу нормальной только потому, что она присутствует в XML Sitemap. Sitemap используется как механизм перечисления URL, но не создаёт HTML-связей между документами.

Ограничение по Search Console и другим облачным сервисам

Данные поисковых систем могут быть дополнительным источником URL: они помогают найти страницы, известные поисковой системе, но отсутствующие в текущем crawl. Однако названия отчётов, доступные поля, способы экспорта и интерфейс таких сервисов меняются. В рамках этого материала актуальная официальная документация сервисов не была проверена, поэтому конкретные названия пунктов интерфейса и версионно-зависимые инструкции не приводятся.

Итоговый чек-лист

Выполнить полный crawl сайта от основной точки входа.
Экспортировать URL из XML Sitemap.
Получить адреса страниц из аналитики.
При наличии доступа добавить URL из серверных логов.
Для крупных сайтов выгрузить опубликованные страницы из CMS.
Нормализовать формат URL во всех наборах данных.
Найти адреса, отсутствующие среди получателей внутренних ссылок.
Проверить HTTP-ответ, индексируемость, canonical и назначение каждого кандидата.
Вернуть полезные страницы в тематические разделы и контекстную перелинковку.
Не создавать ссылки на дубли и страницы, которые должны быть удалены.
Повторить crawl и убедиться, что исправленные URL обнаруживаются через внутренние HTML-ссылки.