Редизайн сайта: карта URL и проверка переноса

01

Сначала определите, меняются ли адреса

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

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

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

• Сохраняются URL — проверяйте страницу на том же адресе
• Меняются URL — готовьте соответствие старого и нового адреса
• Объединяются материалы — выбирайте одну действительно равнозначную цель
• Нет замены — не отправляйте все удалённые страницы на главную

02

Как устроить рабочую карту URL

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

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

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

03

Проверка новой версии до переключения

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

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

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

Search Console и Яндекс Вебмастер должны быть подтверждены для нужных вариантов сайта до запуска. Проверьте доступность Sitemap и robots.txt штатными инструментами, а в Search Console — несколько типовых новых URL через проверку адреса. Установленная аналитика должна продолжать фиксировать те же бизнес-события после смены шаблонов.

• Снять временные запреты индексации с производственных страниц
• Поставить self-canonical на каждый новый основной URL
• Заменить старые внутренние ссылки новыми адресами
• Включить в Sitemap новые канонические страницы
• Проверить редиректы, 404, циклы и цепочки
• Сохранить цели аналитики и доступ к поисковым кабинетам

04

Что контролировать после запуска

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

В первые дни следите за недоступными страницами, неожиданными запретами, ростом 404 и редиректами на неверные цели. В поисковых кабинетах проверяйте обработку Sitemap и состояние новых URL. В аналитике сравнивайте не только общий трафик, но и входы на группы страниц, отправки форм, звонки и другие настроенные действия. Это помогает отличить проблему переноса от изменения спроса или поведения посетителей.

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

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

05

Таблица приёмки переноса

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

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

Коротко

Вопросы и ответы