Восстановление ссылок после изменения URL: как работать с бэклинками на старые страницы

8 сентября 2026 methodology

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

Если старый URL корректно перенаправляет пользователя на релевантную новую страницу, такая ссылка не обязательно потеряна. Google прямо рекомендует использовать постоянные перенаправления при переносе URL и указывает, что постоянные перенаправления не приводят к потере PageRank. Но это не означает, что старые внешние ссылки можно больше не проверять.

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

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

Сначала отделим эту задачу от обычной потери бэклинка

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

Это общий жизненный цикл бэклинка. На webzhukova.ru он уже разобран в материале о потерянных бэклинках и причинах их исчезновения.

В этой статье ситуация уже:

раньше:
страница-источник → старый URL нашего сайта

после изменения структуры:
страница-источник → старый URL
старый URL → новый URL

Или хуже:

страница-источник → старый URL
старый URL → 404

Поэтому основной объект проверки здесь — не только сама внешняя ссылка, а вся цепочка страница-источник → старый URL → новая целевая страница.

Не начинайте с рассылки писем владельцам сайтов

Первая ошибка после миграции — выгрузить бэклинки на старые адреса и сразу писать всем: «Мы поменяли URL, обновите ссылку».

До обращения к внешним сайтам нужно убедиться, что собственная сторона настроена правильно.

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

Практическая последовательность:

карта старых URL
→ карта новых URL
→ проверка соответствия
→ постоянные перенаправления
→ проверка внутренних ссылок и канонических адресов
→ поиск внешних ссылок
→ приоритизация
→ обновление важных бэклинков

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

Основа работы — таблица «старый URL → новый URL»

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

Минимальная карта:

Старый URL	Новый URL	Что произошло	Статус старого URL	Есть внешние ссылки
/blog/guide-a/	/research/guide-a/	Страница переехала без смены смысла	301	Да
/blog/report-2024/	/research/report/	Старый отчёт объединён с обновляемой страницей	301	Да
/blog/old-event/	—	Материал удалён без замены	404/410	Нет
/tools/calculator-v1/	/tools/calculator/	Инструмент получил новый адрес	301	Да

Google при переносе сайта с изменением URL отдельно рекомендует создавать такое сопоставление и включать в список важные старые страницы, найденные в карте сайта, аналитике, журналах сервера и отчёте о внешних и внутренних ссылках Search Console.

Не каждый старый URL должен вести на главную

Если старую страницу удалили, иногда проще настроить:

все старые URL → главная

Но это слабая схема.

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

Правильнее сначала определить отношение между документами.

Что произошло со старой страницей	Что делать
Та же страница получила новый URL	Постоянно перенаправить на новый адрес
Несколько старых страниц реально объединены в одну	Перенаправить их на релевантную объединённую страницу
Появилась новая страница, которая решает ту же задачу	Проверить смысловое соответствие и перенаправить при достаточной близости
Материал удалён и подходящей замены нет	Вернуть 404 или 410, а не отправлять пользователя на случайную страницу

Выбор новой цели внешней ссылки — не техническая формальность. В существующей архитектуре webzhukova.ru этот вопрос подробно разобран в статье о выборе целевой страницы для внешней ссылки: новый URL должен продолжать смысл страницы-источника, а не просто принадлежать тому же домену.

Проверьте фактический маршрут старого URL

В таблице может быть написано «301 на новую страницу», но реальное поведение сервера иногда другое.

Для каждого важного старого URL полезно проверить:

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

Google рекомендует по возможности вести старый URL непосредственно к окончательной новой цели и избегать длинных цепочек перенаправлений. В этой статье не будем разбирать серверную механику 301 и 308 подробно: для восстановления бэклинков важно знать другое — старый адрес должен иметь понятный и рабочий конечный маршрут.

Когда перенаправления достаточно

Представим:

внешняя статья
→ https://site.ru/old-guide/
→ 301
→ https://site.ru/research/guide/

Новая страница действительно является продолжением старой, переход прямой и работает.

В таком случае внешняя ссылка не требует срочного ручного вмешательства. Google рекомендует постоянные перенаправления для таких переносов и отдельно указывает, что они не приводят к потере PageRank.

Но у прямого обновления внешнего href всё равно есть преимущества:

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

Поэтому вопрос не «обязательно ли переписать каждую внешнюю ссылку», а «какие ссылки разумно обновить напрямую в первую очередь».

Когда обновление внешней ссылки становится важным

Приоритет выше, если:

старый URL возвращает 404 или 410, хотя существует релевантная новая страница;
перенаправление ведёт не на ту страницу;
существует длинная или нестабильная цепочка;
страница-источник даёт заметные переходы пользователей;
ссылка находится в важном отраслевом материале;
внешняя страница регулярно обновляется;
ссылка ведёт на исследование, инструмент или документ, где точность адреса особенно полезна;
старый URL планируется окончательно выводить из эксплуатации.

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

Не оценивайте приоритет только по метрике домена

Можно выгрузить список и отсортировать его по DR, Authority Score или другой сторонней метрике. Это допустимый вспомогательный разрез, но не готовое решение.

Важная для обновления ссылка может идти:

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

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

Поэтому приоритизация лучше работает как сочетание:

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

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

Откуда собрать старые URL с бэклинками

Один источник почти никогда не даёт полной картины.

Search Console

В отчёте «Ссылки» можно посмотреть страницы сайта, на которые ведут внешние ссылки, и перейти от целевой страницы к ссылающимся сайтам.

Важно учитывать ограничение: Google прямо пишет, что отчёт не является полным списком всех ссылок. Часть данных может быть не показана, а таблицы в интерфейсе ограничены.

Поэтому отсутствие старого URL в Search Console не доказывает, что внешних ссылок на него нет.

Сервисы анализа бэклинков

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

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

Аналитика и журналы сервера

Старый URL может получать реальные переходы даже тогда, когда он плохо виден в ссылочном инструменте.

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

Старая карта сайта и архив миграции

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

Search Console полезен, но его данные нужно правильно читать

В отчёте «Ссылки» страницы группируются по каноническому URL. Кроме того, Google отмечает, что отображаемые данные — выборка, а не исчерпывающий реестр всех бэклинков.

Это важно после миграции: старый фактический href на внешней странице и целевой канонический URL в отчёте могут выглядеть не одинаково.

Поэтому для конкретной важной ссылки лучше проверять три уровня:

что показывает Search Console
→ какой href стоит на внешней странице
→ куда фактически приходит пользователь

Так мы не принимаем группировку отчёта за физическое состояние ссылки.

Сохраните источник каждой найденной связи

Рабочая таблица после миграции может выглядеть так:

Страница-источник	Старый URL	Новый URL	Текущий маршрут	Источник данных	Действие
Внешняя статья A	/old/report/	/research/report/	301 → новый	Search Console	Можно попросить прямое обновление
Каталог ресурсов B	/old/tool/	/tools/tool/	404	Ahrefs	Сначала исправить маршрут, затем обратиться
Статья C	/old/post/	—	404	Semrush	Проверить, есть ли релевантная замена

Поле «Источник данных» помогает позже понять, почему одна ссылка исчезла из повторной выгрузки: это может быть изменение индекса сервиса, а не самой страницы.

Не отправляйте просьбу обновить ссылку, пока не проверили страницу-источник

Внешний отчёт может быть устаревшим.

Перед обращением откройте страницу и проверьте:

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

Только после этого строка становится реальной задачей на обновление ссылки.

Анкор не нужно переписывать только потому, что изменился URL

Если внешний текст выглядит так:

«Подробная методика опубликована в исследовании компании X».

и ссылка в словах «исследовании компании X» ведёт на старый URL, после миграции чаще всего достаточно заменить адрес:

старый href
→ новый href

Не нужно одновременно просить автора превратить анкор в коммерческий или ключевой запрос.

Задача восстановления после смены URL — вернуть корректный путь к тому же содержанию. Если начать использовать миграцию как повод переписать чужой текст под SEO, обращение становится сложнее и менее естественным.

Если содержание страницы изменилось, старый анкор нужно перечитать

Бывает, что новый URL ведёт уже не на точную копию старого материала, а на расширенную или объединённую страницу.

Тогда нужно проверить, остаётся ли исходная фраза верной.

Например:

раньше:
«калькулятор стоимости доставки»

после объединения:
«справочник логистических инструментов»

Если старого калькулятора на новой странице больше нет, простой перенос href создаст плохой пользовательский переход.

В таком случае варианты:

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

Объединение нескольких страниц требует отдельной проверки каждого бэклинка

Представим, что три статьи:

/guide-a/
/guide-b/
/guide-c/

объединили в:

/complete-guide/

Технически все три старых адреса могут вести на новый материал. Но внешние ссылки могли указывать на разные фрагменты:

определение;
таблицу;
методику;
конкретный пример.

Поэтому для самых важных ссылок нужно проверить, сохранился ли объект цитирования после объединения. Если нет, прямой запрос на замену адреса не решает проблему.

Страница удалена без замены: не придумывайте цель только ради бэклинка

Старый материал мог окончательно потерять смысл.

Например:

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

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

Корректный 404 или 410 лучше нерелевантного маршрута. Это соответствует рекомендациям Google для удалённого содержимого, которое не переносится на новый сайт или новую структуру.

Письмо владельцу сайта должно быть максимально конкретным

Для обновления ссылки после миграции не нужен длинный рассказ о SEO.

Рабочая структура:

В вашем материале [название / URL страницы] есть ссылка на наш материал по адресу [старый URL]. Мы перенесли эту страницу на новый адрес [новый URL]. Старый адрес пока перенаправляет корректно, но прямой переход будет актуальнее для читателей. Если будете обновлять материал, можно заменить только адрес ссылки — текст менять не требуется.

Если старый URL уже не работает, это тоже лучше сказать прямо:

Старая ссылка сейчас ведёт на недоступный адрес. Тот же материал находится здесь: [новый URL].

Чем меньше редактору нужно самостоятельно искать старую ссылку и новую страницу, тем проще проверить запрос.

Не обещайте владельцу сайта «улучшение SEO»

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

Нормальные причины:

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

То есть запрос строится вокруг корректности и удобства существующего материала.

Не нужно обращаться ко всем сайтам одновременно

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

Удобнее разбить его на очереди.

Приоритет	Ситуация
Высокий	Ссылка ведёт на 404, есть точная замена, страница-источник актуальна и заметна
Высокий	Ссылка приносит заметные переходы пользователей
Средний	Работает прямое 301 на правильный URL, но источник важен и поддерживается
Средний	Ссылка стоит в справочном или отраслевом материале, который периодически обновляют
Низкий	Корректный постоянный переход уже решает задачу, а источник почти не обновляется
Не обращаться	Новая релевантная цель отсутствует или ссылка уже обновлена

Это не универсальная система баллов. Она просто помогает не тратить одинаковое время на разные ситуации.

После ответа нужно проверить реальный href

Ответ «обновили» ещё не означает, что задача завершена.

Откройте страницу-источник и проверьте:

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

После этого в рабочей таблице можно менять статус с «обновление обещано» на «проверено».

Сохраняйте редиректы даже после обновления важных внешних ссылок

Невозможно найти и обновить весь интернет.

Часть ссылок находится:

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

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

Поэтому ручное обновление бэклинков и серверное перенаправление не заменяют друг друга:

перенаправление
→ страхует старый адрес в целом

обновление внешней ссылки
→ исправляет конкретный известный источник

После миграции нужно контролировать старые URL во времени

В день запуска всё может работать правильно, а через несколько месяцев часть правил исчезнет после смены CMS или конфигурации сервера.

Полезно периодически проверять:

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

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

Новые ссылки на старый URL помогают найти источник устаревшего адреса

Представим, что после миграции новые бэклинки продолжают появляться на:

/blog/old-research/

Хотя актуальная страница:

/research/current/

Нужно искать, откуда авторы берут старый адрес.

Возможные причины:

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

Исправление первичного источника иногда эффективнее десятков отдельных писем.

Не путайте успешную миграцию с полным обновлением внешнего графа

Google может корректно обработать перенос, новый URL индексируется, а постоянное перенаправление работает. При этом множество внешних страниц ещё годами будет содержать старые href.

Это нормально.

Поэтому у процесса есть два разных результата:

Задача	Когда считается решённой
Перенос URL	Старый адрес корректно ведёт на релевантную новую страницу, внутренние сигналы обновлены
Обновление внешних ссылок	Приоритетные страницы-источники по возможности заменили старый href на новый

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

Как измерять работу по восстановлению после смены URL

Необязательно сводить процесс к одному проценту.

Полезно отдельно считать:

число старых URL с внешними ссылками;
сколько из них корректно перенаправляются;
сколько ведут на ошибочную или нерелевантную цель;
сколько возвращают 404/410 при наличии подходящей замены;
число приоритетных страниц-источников;
сколько владельцев сайтов получили запрос;
сколько ссылок обновлено и перепроверено;
сколько новых бэклинков продолжает появляться на старые адреса.

Эти показатели отвечают на разные вопросы. Смешивать их в один «процент восстановления» не обязательно.

Практический рабочий процесс

Собрать карту старых URL. Из прежней карты сайта, CMS, аналитики, серверных журналов и архивов миграции.
Сопоставить каждый старый адрес с новой целью. Не отправлять всё на главную.
Проверить постоянные перенаправления. Старый URL должен вести к правильной конечной странице.
Найти старые URL с внешними ссылками. Search Console плюс доступные сервисы анализа бэклинков.
Открыть приоритетные страницы-источники вручную. Убедиться, что ссылка действительно существует и всё ещё ведёт на старый адрес.
Разделить случаи. 404, неверная цель, рабочее перенаправление, отсутствующая замена.
Приоритизировать обращения. По пользовательской и редакционной ценности источника, а не только по сторонней метрике домена.
Предложить точный новый URL. Без требования переписать анкор ради SEO.
Проверить результат после изменения. Фактический href и конечную страницу.
Продолжить контроль старых адресов. Редиректы нужны и после ручного обновления известных бэклинков.

Типичные ошибки

Ошибка	Почему мешает	Что делать
Сразу писать владельцам внешних сайтов	На своей стороне может не быть корректной новой цели	Сначала завершить карту URL и перенаправления
Все старые страницы вести на главную	Нарушается смысл старых ссылок	Подбирать релевантную цель или возвращать 404/410
Считать любой 301 проблемой	Корректное постоянное перенаправление уже сохраняет маршрут	Приоритизировать действительно слабые случаи
Ориентироваться только на DR	Теряются полезные для пользователей и отрасли источники	Смотреть контекст, переходы и роль ссылки
Просить одновременно новый URL и SEO-анкор	Простая техническая правка превращается в сложный редакционный запрос	Сохранять естественный текст ссылки
Не проверять страницу-источник	В отчёте может быть устаревшее состояние	Открывать реальную страницу перед обращением
Удалить редирект после нескольких обновлённых ссылок	Неизвестные старые ссылки и закладки снова ломаются	Сохранять перенаправления длительно
Не следить за новыми ссылками на старые URL	Источник устаревшего адреса продолжает размножаться	Найти, откуда авторы копируют прежний URL

Итог

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

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

Рабочая логика выглядит так:

старый URL
→ новая релевантная цель
→ корректное постоянное перенаправление
→ список внешних ссылок
→ ручная проверка источников
→ приоритетное обновление href
→ повторная проверка
→ долгосрочный контроль старых адресов

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