Сайту 5 лет. Хотел бы перевести сайт на ЧПУ. Стоит ли это делать сейчас, или есть риски потерять трафик?

Переводить пятилетний сайт на ЧПУ только ради более «красивых» адресов обычно не стоит. Если текущие URL стабильно индексируются, получают трафик и не создают технических дублей или бесконечных комбинаций параметров, потенциальная SEO-выгода мала, а смена адресов запускает полноценную URL-миграцию.

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

Возраст сайта не определяет решение

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

Оценивать нужно не возраст, а состояние текущей URL-системы:

• получают ли старые адреса органические клики и показы;

• есть ли на них внешние ссылки и реферальный трафик;

• создают ли параметры дубли, бесконечные пространства или нестабильные адреса;

• мешает ли текущая схема развитию структуры, смене CMS или нормальной аналитике;

• можно ли однозначно сопоставить каждый старый URL с новым.

Если проблема сводится только к тому, что адрес вида /page.php?id=125 выглядит хуже, чем /catalog/product-name/, этого недостаточно для массовой миграции. Google умеет обрабатывать URL с параметрами; сама по себе транслитерация ключевых слов в адресе не создаёт достаточного основания для смены уже работающих URL.

Когда переход на ЧПУ оправдан

Изменение URL имеет смысл, если оно решает конкретную техническую или продуктовую проблему:

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

2. Адреса нестабильны и меняются при обновлении контента или CMS.

3. Планируется обязательная смена CMS или архитектуры, при которой сохранить прежние URL невозможно.

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

5. Можно подготовить полную карту соответствия «старый URL → эквивалентный новый URL» и протестировать миграцию до запуска.

Google относит изменение путей, например переход с /page.php?id=1 на /widget, к миграциям с изменением URL. Яндекс также рассматривает внедрение ЧПУ как смену структуры сайта и требует корректного перенаправления старых страниц.

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

Почему трафик может просесть

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

Корректный постоянный редирект сам по себе не означает автоматическую потерю PageRank в Google. Риск возникает из-за реализации миграции:

• старый URL отдаёт 404, 200 OK или временный редирект вместо постоянного;

• несколько старых страниц перенаправляются на нерелевантную главную;

• появляются цепочки, петли или переходы на несуществующие страницы;

• новый URL закрыт в robots.txt или содержит noindex;

• canonical на новой странице указывает на старый адрес либо другой документ;

• внутренние ссылки, hreflang, Sitemap и структурированные данные продолжают использовать старые URL;

• одновременно меняются URL, контент, дизайн, CMS и перелинковка, поэтому невозможно определить причину падения.

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

Яндекс предупреждает, что изменение структуры или URL способно повлиять на позиции. Для корректной смены адресов он рекомендует серверный 301, доступность нового URL с кодом 200 OK, обновление Sitemap и внутренних ссылок.

Как провести миграцию безопаснее

1. Зафиксировать исходное состояние

До изменения URL выгрузите:

• все доступные старые URL из краулера и базы CMS;

• страницы с кликами и показами из Google Search Console и Яндекс Вебмастера;

• посадочные страницы из аналитики;

• адреса из Sitemap;

• URL с внешними ссылками;

• ошибки и обращения поисковых роботов из серверных логов.

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

2. Составить карту редиректов

Для каждой старой страницы назначьте наиболее близкий новый эквивалент. Не направляйте весь массив адресов на главную страницу. Если существует действительно релевантный объединённый материал, несколько старых URL можно перенаправить на него. Когда подходящей замены нет, корректнее вернуть 404 или 410, чем создавать нерелевантный soft 404.

Минимальная серверная логика:

HTTP/1.1 301 Moved Permanently
Location: https://example.ru/catalog/product-name/

Google поддерживает постоянные серверные редиректы 301 и 308. По стандарту HTTP оба статуса обозначают постоянное перемещение, но 308 однозначно сохраняет метод исходного запроса. Для обычных GET-страниц чаще применяется 301.

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

3. Проверить тестовую версию

Сравните старые и новые страницы по следующим параметрам:

• основной контент;

• title и H1;

• meta robots и X-Robots-Tag;

• canonical;

• hreflang;

• структурированные данные;

• внутренние ссылки;

• HTTP-статусы;

• доступность ресурсов и изображений.

Новая страница должна отдавать 200 OK, быть доступной для сканирования и указывать canonical на собственный новый URL.

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

4. Обновить внутренние сигналы

После запуска:

• замените внутренние ссылки на новые адреса;

• обновите canonical и hreflang;

• включите в основной Sitemap новые канонические URL;

• обновите рекламные объявления, профили и другие контролируемые ссылки;

• проверьте, что старые URL стабильно отдают постоянный редирект;

• удалите временные noindex и блокировки тестовой версии.

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

Инструмент Google Change of Address не применяется к простой смене путей внутри того же домена: он работает на уровне сайта и предназначен прежде всего для переезда между доменами. Для отдельных новых URL достаточно редиректов, внутренних ссылок, Sitemap и URL Inspection.

5. Мониторить не только общий трафик

Контроль должен проводиться на уровне URL и групп страниц:

• доля старых URL, отдающих правильный 301;

• доля новых URL с 200 OK;

• ошибки 404, 5xx, циклы и цепочки;

• индексирование новых адресов;

• клики и показы по перенесённым группам страниц;

• обращения роботов к старым и новым URL;

• расхождения между canonical, Sitemap и внутренними ссылками;

• страницы, потерявшие внутренние или внешние ссылки.

Google рекомендует отслеживать миграцию через Search Console, аналитику и серверные логи. В Яндекс Вебмастере можно контролировать обход, состояние страниц и динамику важных URL.

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

Когда остановить внедрение

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

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

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

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