Кратко
- Собери старые URL из краулинга, панелей для вебмастеров, аналитики и sitemap.
- Для каждого адреса запиши подходящую цель и конечный ответ сервера.
- Убирай лишние переходы, направляя старый URL прямо на актуальную страницу.
Как собрать старые URL для проверки после переезда сайта
Составь единый реестр до проверки редиректов. Один список редко охватывает все адреса: часть старых страниц может быть в sitemap или аналитике, а часть — обнаружиться только при сканировании сайта. Если начать с одного источника, нужный URL легко пропустить.
Объедини адреса из доступных источников:
- результата краулинга сайта;
- Google Search Console и Яндекс Вебмастера;
- аналитики — в том числе посадочные страницы;
- старого XML Sitemap;
- списка URL с внешними ссылками;
- базы товаров, категорий или другого каталога, если он есть;
- списка важных файлов и изображений, получавших органические переходы.
Не оставляй дубликаты из разных списков: сначала приведи адреса к единому формату и объедини совпадающие записи. Однако похожие URL не считай одинаковыми автоматически. Например, варианты с разным протоколом, поддоменом или завершающим слешем могут пройти по разным маршрутам. Их имеет смысл сохранить как отдельные входные адреса, если они были доступны до переезда.
Для каждого старого URL заведи строку с такими полями:
| Поле | Что записать |
|---|---|
| Старый URL | Адрес до переезда без сокращений |
| Источник | Откуда адрес попал в реестр |
| Целевая страница | Подходящий новый URL или отметка «замены нет» |
| Проверка маршрута | Каждый код HTTP и адрес из Location |
| Конечный результат | Последний URL и его код ответа |
| Решение | Оставить, исправить или разобраться отдельно |
Сохраняй исходный адрес, даже если он уже перенаправляется. Иначе при повторной проверке легко потерять точку входа и увидеть только конечную страницу. А что делать с URL, который не встречается в одном из источников, но есть в другом? Оставить в общем реестре и указать происхождение: так проще понять, почему он вошёл в проверку.
Как сопоставить старые URL с конечными страницами
Для каждого старого адреса выбери конечную страницу с тем же смыслом. Цель редиректа — не просто привести посетителя на работающий сайт, а привести его к содержанию, соответствующему старому URL. Не нашлось подходящей замены? Зафиксируй это отдельно, вместо того чтобы назначать адрес наугад.
Начни с назначения страниц. Сопоставь старые URL с новыми по теме, типу страницы и содержанию. Для товара ищи его актуальную страницу, для категории — соответствующий раздел, для статьи — обновлённую или заменившую её публикацию. Совпадение только по части адреса недостаточно: похожие слова в URL ещё не означают, что страницы взаимозаменяемы.
Проверь каждое соответствие по двум вопросам:
- Сохраняет ли конечная страница основное содержание или назначение старой?
- Ожидает ли посетитель, перешедший по старому адресу, именно такой результат?
Если да — запиши новый адрес как цель. Если ответ неясен, отметь запись для ручного решения. Так ты отделишь уверенные соответствия от предположений и не смешаешь их при массовой настройке.
Старой странице может не найтись подходящей замены. Это не повод направлять её на главную или на случайный раздел: такой переход не объясняет, куда попал посетитель. Отметь URL как «замены нет» и реши, должен ли он оставаться доступным, вести на содержательно близкую страницу или отдавать другой ответ. Выбор зависит от того, существует ли реальная замена и нужно ли сохранять старое содержание.
В таблице полезно записать не только целевой адрес, но и причину решения: «тот же товар», «обновлённая статья», «подходящей страницы нет». Тогда другой участник переезда сможет проверить логику, а ты не будешь заново разгадывать её во время настройки. Это особенно пригодится для похожих карточек и страниц, где содержание изменилось.
Как проверить цепочку редиректов от старого URL до конечного ответа
Проверь маршрут от исходного старого URL до последнего ответа, а не только факт перехода на новый адрес. Для каждого шага зафиксируй код HTTP и заголовок Location; затем сравни фактический конечный URL с тем, который внесён в реестр.
В заголовках Location указан адрес следующего перехода. Код HTTP показывает, какой ответ сервер отправил на конкретный запрос. Например, в последовательности 301 → 301 → 200 сначала идут два перенаправления, а затем конечный ответ. Само наличие ответа не доказывает, что маршрут настроен правильно: конечная страница может не соответствовать старой по смыслу. Поэтому сравни и цепочку, и результат с выбранной целью.
Для быстрой проверки можно использовать curl, передав старый URL и проследив переходы. Например:
curl -sILk http://example.com | grep -iE "^HTTP|^location"
В выводе читай строки HTTP и Location по порядку. Каждая новая строка с кодом ответа показывает следующий шаг, а Location — куда он ведёт. Подставь свой старый адрес, а не условный example.com; результат запиши в реестр. После настройки повтори запрос и проверь, заканчивается ли маршрут на ожидаемом URL.
Если нужно увидеть, как ведёт себя страница в браузере, открой DevTools, вкладку Network и включи Preserve log до загрузки страницы. Затем посмотри запросы с ответами перенаправления и их Location: без сохранения записей переход между адресами может скрыть предыдущие строки в журнале. Такой способ полезен, когда маршрут зависит от условий просмотра, например от браузерного запроса.
Для внешней проверки подойдёт онлайн-проверка цепочки редиректов. Введи старый URL, просмотри последовательность кодов и адресов, а затем сравни конечный результат со своим реестром. Сканер сайта, например Screaming Frog, может показать редиректы и цепочки при обходе страниц. Какой способ выбрать? Для одного адреса достаточно curl или онлайн-проверки; для браузерного поведения — DevTools; для списка страниц — краулинг с последующей сверкой записей.
Как найти лишние звенья и исправить цепочки после переезда
Если старый URL проходит через несколько промежуточных адресов, выясни, нужны ли они. При переезде практичнее направить старый адрес сразу на конечную релевантную страницу, а не сохранять промежуточный маршрут без причины. Но считать любое число переходов универсальным порогом ошибки нельзя: подтверждённого общего лимита нет.
Допустим, старый адрес ведёт сначала на новый URL, а тот перенаправляет на окончательный. Если в реестре уже выбрана конечная страница, проверь настройку первого перехода: ведёт ли он сразу к ней или по-прежнему отправляет посетителя на промежуточный адрес? Когда промежуточный URL не нужен, измени правило так, чтобы старый адрес указывал прямо на конечный. После правки повтори проверку от старого URL и запиши новый маршрут.
Не делай вывод только по числу переходов. Задай себе более предметные вопросы:
- Каждый ли шаг ведёт к адресу, который нужен посетителю?
- Совпадает ли последний URL с выбранной целью в реестре?
- Нет ли цикла, возврата на исходный адрес или перехода на нерелевантную страницу?
- Есть ли понятная причина оставлять промежуточный адрес?
Если ответов нет, сначала выясни, какое правило создало переход. Проверь настройки, отвечающие за редиректы, и сопоставь их с картой переезда. Не меняй цепочку вслепую: один и тот же адрес может участвовать в нескольких правилах, а поспешная правка способна заменить нужное перенаправление неверным.
Избавление от лишних звеньев — разумная цель, но обещать конкретное изменение позиций или ссылочного веса только на основании длины цепочки нельзя. Доступные источники не подтверждают универсальное влияние каждого перехода. Практическая проверка здесь проще: маршрут должен вести к правильной странице, быть понятным и совпадать с планом переезда. После изменения зафиксируй новый код каждого шага и конечный ответ, а не только факт, что адрес открылся.
Как проверить старые URL на условном примере
Представим учебную ситуацию, а не реальный переезд или проведённый тест. Старый адрес товара — http://shop.example/old-item; в реестре для него указана новая карточка https://shop.example/catalog/item. Это условные входные данные: они нужны лишь для разбора порядка действий.
Сначала проверь соответствие: действительно ли конечная карточка относится к тому же товару и подходит посетителю старого URL? Если да, оставь её целью в реестре. Если нет — не назначай её автоматически; отметь строку для выбора другой страницы или решения без подходящей замены.
Затем проверь маршрут от старого адреса, например командой curl из предыдущего раздела. Допустим, в условном выводе окажутся ответы 301 и Location: https://shop.example/temporary, затем ещё один 301 с адресом https://shop.example/catalog/item, после которого будет 200. Это только пример возможного вывода, а не наблюдение за работающим сайтом.
Сравни результат с картой: конечный адрес совпадает с выбранной карточкой, но есть промежуточный шаг. Если правило временного адреса больше не нужно и старый URL должен вести прямо на карточку, измени перенаправление так, чтобы его целевым значением стал конечный адрес. Если промежуточный переход нужен для другой причины, сначала уточни её, а потом решай, можно ли его убрать.
После правки повтори запрос именно к исходному старому URL. Запиши коды и Location заново, проверь совпадение последнего адреса с реестром и убедись, что конечный ответ относится к ожидаемой странице. Если маршрут не совпал, не отмечай строку как исправленную: выясни, какое перенаправление сработало иначе, и проверь ещё раз. Так итоговая запись отражает проверенный маршрут, а не только предполагаемую настройку.
Как сверить canonical, sitemap и внутренние ссылки после проверки редиректов
Работающий редирект не завершает проверку переезда. Отдельно убедись, что новая страница указывает на нужный canonical, sitemap содержит актуальные адреса, а внутренние ссылки ведут прямо на конечные страницы. Это связанные проверки, но каждая отвечает на свой вопрос.
На каждой новой странице посмотри значение canonical в HTML-коде. Сверь указанный адрес с конечным URL из реестра: он должен соответствовать выбранной странице, а не старому адресу или тестовой версии. Если значение указывает не туда, передай это в список исправлений для шаблона или конкретной страницы. Затем открой актуальный XML Sitemap и сопоставь его адреса с целевыми URL: после переезда там должны быть новые адреса, а не только старые перенаправляемые URL.
Не смешивай проверку sitemap с проверкой редиректов. Адрес может перенаправляться правильно, но оставаться в карте сайта; это отдельная несогласованность, которую нужно исправить в самом списке. После изменения заново просмотри sitemap и сверь несколько затронутых записей с реестром. Если в карте есть URL без соответствующей конечной страницы, не добавляй замену наугад — вернись к решению по этой записи.
Теперь проверь внутренние ссылки: ссылки в навигации, категориях, текстах и других элементах сайта. Найди те, что всё ещё указывают на старые адреса, и замени их прямыми ссылками на соответствующие новые страницы. Сам редирект при этом может продолжать работать, но ссылка в контенте уже должна вести на конечный URL. Повторно просканируй сайт или просмотри изменённые страницы и проверь, что переход больше не начинается со старого адреса.
Закончи сверку реестра: для каждого важного URL должны быть записаны исходный адрес, назначение, фактический маршрут, конечный ответ и состояние связанных сигналов. Начни с адресов, для которых уже выбрана точная замена, исправь ссылки и записи sitemap, затем перепроверь результат.