Сохранение адресов при рефакторинге в SEO

При рефакторинге хочется «привести URL в порядок»: новые slug, другая структура каталога, переезд на другую CMS. Технически это удобно, но для SEO каждый старый адрес - это история, закладки, индекс и внешние ссылки.

Если поменять URL «просто так», чужие сайты продолжат ссылаться на старые адреса. Часть трафика и веса потеряется.

Когда URL трогать опасно

Особенно осторожно нужно быть, если меняется:

• slug популярной статьи или товара
• структура каталога /phones/iphone/ → /smartphones/apple/
• формат адресов при смене CMS
• расширение в URL /about.html → /about/

На такие страницы могут ссылаться форумы, СМИ, партнеры и клиенты. Поисковик тоже помнит старые URL.

Менять адрес имеет смысл, если есть веская причина: объединение дублей, исправление ошибки, переезд раздела. Ради «красоты» без редиректов - плохая идея.

Договоренность с SEO до деплоя

Перед рефакторингом URL разработчик и SEO-специалист составляют карту редиректов: старый адрес → новый адрес.

Минимальный чеклист:

• список всех URL, которые изменятся
• для каждого - целевой новый адрес
• тип редиректа: для постоянного переезда только 301
• проверка после деплоя через curl -I или краулер
• обновление sitemap.xml и внутренних ссылок на сайте

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

Типичные ошибки при рефакторинге

Массовая смена slug без карты. Разработчик переименовал поля в CMS, а редиректы не настроил. Сотни внешних и внутренних ссылок стали битыми.

Редирект только на главную. Все старые URL ведут на /. Пользователь и робот не попадают на нужный контент, вес размывается.

Временный 302 вместо 301. Старые адреса остаются в индексе, внешние ссылки не передают вес на новые страницы полностью.

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

Безопасный порядок работ

Сначала согласовать карту URL с SEO. Потом настроить 301 на staging и проверить выборочно. Затем выкатить на прод и снова проверить важные адреса. В конце обновить внутренние ссылки и sitemap, чтобы новые URL быстрее подхватил робот.

Если меняется только верстка или код, а адреса те же - редиректы не нужны. Проблема начинается именно при смене URL.

Практические задачи