Сайт обновили, а Google всё ещё показывает старые страницы как не потерять поисковый трафик при смене CMS

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

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

Но у Google может оставаться совсем другая картина проекта.

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

Это не всегда техническая ошибка. Однако игнорировать такие адреса тоже нельзя.

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

Что я обнаружил в данных собственного сайта

В октябре 2026 года я проверил выгрузку Google Search Console для SEOGIDTALK — проекта, у которого изменилась структура сайта: прежние форумные разделы и публикации были перенесены в новый блог и коммерческую систему страниц.

В коротком отчёте за последние 24 часа было зафиксировано 50 показов и 2 клика.

Оба клика пришлись на адрес прежнего формата:

/viewforum.php?f=100

Среди 30 строк отчёта по страницам я обнаружил 13 URL с характерными для старой форумной системы путями viewforum.php и viewtopic.php.

Одновременно Google показывал новые адреса статей внутри /blog/. В выгрузке также присутствовали варианты с www, без www, HTTP и HTTPS.

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

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

Почему старые адреса сохраняются после обновления сайта

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

У каждого адреса есть своя история обнаружения, обхода и обработки.

Например, старая статья могла располагаться по адресу:

/viewtopic.php?t=49

А после перехода на новую систему управления её адрес изменился:

/blog/seo-49/

Если перенаправление настроено правильно, посетитель старой страницы сможет попасть на соответствующий новый материал.

Но поисковому роботу ещё нужно обработать изменения.

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

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

Гораздо важнее установить, куда попадает пользователь.

Три сценария, которые маркетолог должен различать

После смены CMS старый адрес может вести себя по-разному.

Первый сценарий: корректное перенаправление.

Старая статья возвращает постоянный редирект на новый адрес с соответствующим содержимым.

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

Второй сценарий: адрес существует, но показывает неподходящее содержимое.

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

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

Третий сценарий: старый адрес возвращает ошибку.

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

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

Именно поэтому нельзя массово перенаправлять все старые страницы на главную.

Почему редирект на главную не решает проблему

Представим коммерческий сайт, на котором раньше было 300 публикаций.

После редизайна осталось 50.

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

Владелец видит, что ошибок 404 стало меньше, и считает проблему решённой.

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

Он искал конкретную инструкцию, сравнение товаров или условия определённой услуги.

Вместо этого открылась главная с общим коммерческим предложением.

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

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

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

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

Как найти исторические URL через Google Search Console

Для первой проверки не требуется дорогостоящий SEO-сервис.

Начать можно с данных собственного сайта.

Шаг 1. Откройте отчёт «Эффективность».

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

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

Шаг 2. Перейдите к таблице страниц.

Выгрузите URL вместе с показами, кликами и другими доступными показателями.

Шаг 3. Найдите адреса прежней CMS.

Обращайте внимание на характерные конструкции:

viewtopic.php

viewforum.php

index.php?id=

?page=

.html

А также на старые каталоги и прежние форматы адресов вашего проекта.

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

Шаг 4. Сопоставьте адреса с новым сайтом.

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

1. Есть ли соответствующая новая страница?
2. Какой HTTP-ответ возвращает старый адрес?
3. Куда ведёт перенаправление?
4. Соответствует ли результат прежнему пользовательскому запросу?
5. Открывается ли целевая страница на мобильном устройстве?

Шаг 5. Проверьте реальное поведение.

Можно использовать инструменты разработчика браузера и проверку URL в Search Console.

Важно смотреть не только на факт перенаправления, но и на конечную страницу.

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

Если она ведёт на общий прайс, задача посетителя может остаться нерешённой.

Не путайте сохранённый поисковый спрос с коммерческими заявками

Есть ещё одна проблема, которую легко не заметить.

Старый раздел сайта способен привлекать посетителей по запросам, которые больше не соответствуют текущей бизнес-модели.

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

Он получал переходы по запросам об обсуждениях, программах и инструкциях.

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

Технически такая миграция может быть выполнена правильно.

Но старый информационный трафик необязательно превратится в клиентов новых услуг.

Поэтому при анализе важно разделять два вопроса:

Первый: сохранилась ли доступность исторических страниц?

Второй: насколько посетители этих страниц соответствуют текущим коммерческим задачам?

Для ответа на второй вопрос понадобится уже не только Search Console, но и веб-аналитика с корректно настроенными целями.

Количество показов не равно количеству заинтересованных покупателей.

А рост числа индексируемых страниц не гарантирует роста обращений.

Что проверить перед запуском нового сайта

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

Его основу составляет таблица старых и новых URL.

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

Нужно также проверить:

1. Основную версию домена и HTTPS.
2. Наличие случайного noindex.
3. Доступность важных страниц поисковым роботам.
4. Канонические адреса.
5. XML-карту сайта.
6. Внутренние ссылки.
7. Сохранение коммерческих страниц и их содержимого.
8. Работу форм заявок.
9. Мобильную версию.
10. Аналитику и события конверсий.

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

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

Но решение об удалении, объединении или перенаправлении должно быть осознанным.

Почему запуск нельзя считать завершённым в день публикации

Технический релиз и завершение поисковой миграции — разные этапы.

Разработчик может закончить работу в пятницу.

Но это не означает, что к понедельнику поисковые системы полностью обновят сведения обо всех URL.

После запуска стоит отслеживать:

1. Изменение показов и кликов старых и новых страниц.
2. Ошибки обхода.
3. Динамику индексируемых URL.
4. Корректность перенаправлений.
5. Доступность новых посадочных.
6. Изменения органического трафика.
7. Поступление коммерческих обращений.

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

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

Почему старые страницы продолжают появляться в Google

После смены CMS старые адреса могут сохраняться в поисковых отчётах. Это особенно характерно для проектов, которые долго работали на форумах, самописных движках или системах управления с динамическими URL.

Например, форум phpBB может использовать адреса следующего вида:

/viewtopic.php?t=123

/viewforum.php?f=15

После миграции соответствующие материалы могут получить новые адреса:

/blog/nazvanie-stati/

/blog/tema-razdela/

Но Google не всегда сразу перестаёт показывать исторические URL в отчётах.

Причин несколько.

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

Вторая — поисковый робот ещё не обработал все перенаправления. Время повторного обхода различается в зависимости от конкретных страниц.

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

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

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

Главная ошибка при переносе: все старые страницы перенаправляют на главную

Один из самых рискованных сценариев — массовая настройка перенаправлений без сопоставления содержимого.

Предположим, на старом сайте опубликованы сотни обсуждений, инструкций и тематических материалов.

После обновления платформы разработчик настраивает единое правило:

«Любой старый URL → главная страница».

Технически пользователь получает ответ сервера и попадает на работающий сайт. Но его первоначальная задача остаётся нерешённой.

Человек искал инструкцию по настройке robots.txt, а оказался на главной странице с общим перечнем услуг.

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

Правильная стратегия — составить карту соответствия старых и новых адресов.

Старый документ Правильное решение Статья перенесена без изменения темы

301 на новую версию статьи

Несколько материалов объединены в одно руководство

301 на содержательную объединённую страницу, если она действительно заменяет прежние

Раздел форума преобразован в тематическую рубрику

Перенаправление на релевантный раздел, если он сохраняет назначение

Документ окончательно удалён и замены нет

404 или 410 по ситуации

URL остался действующим

HTTP 200 и корректный canonical

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

Как проверить миграцию без дорогостоящего программного обеспечения

Для первоначальной диагностики достаточно Google Search Console, браузера и инструмента проверки HTTP-ответов.

1. Выгрузите страницы из Search Console

Откройте отчёт «Эффективность» и посмотрите вкладку «Страницы».

Отдельно выделите:

1. Старые адреса предыдущей CMS.
2. Новые страницы сайта.
3. URL с параметрами.
4. Адреса с www и без него.
5. HTTP- и HTTPS-версии, если они присутствуют в доступной статистике.

Сохраните данные с датами и периодом измерения.

Отчёт об эффективности показывает статистику поисковых показов и кликов, но не заменяет проверку актуального HTTP-ответа каждого адреса.

2. Проверьте старые URL

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

Посмотрите, какой HTTP-код возвращается при обращении к каждому из них.

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

Особое внимание уделите динамическим URL с параметрами. При обработке адресов вроде viewtopic.php?t=123 важно учитывать конкретное значение идентификатора, а не перенаправлять все обсуждения на одну страницу.

3. Сопоставьте содержимое

Найдите соответствующую новую публикацию.

Ответьте на вопросы:

1. Сохранена ли исходная тема?
2. Получает ли пользователь ответ на прежний запрос?
3. Не исчезла ли важная часть инструкции?
4. Сохранены ли изображения и другие необходимые материалы?
5. Нет ли нескольких новых страниц с почти одинаковым содержанием?

Если материал был существенно сокращён, полезно оценить, не потерял ли он самостоятельную поисковую ценность.

Но не нужно восстанавливать устаревший или некачественный текст исключительно ради сохранения объёма.

4. Проверьте canonical и индексирование

Для нового URL убедитесь, что поисковый робот может получить страницу, а в HTML нет случайного noindex.

Посмотрите канонический адрес.

Если статья доступна по одному основному URL, её canonical обычно должен указывать именно на него.

Проверьте, не указывают ли разные самостоятельные статьи на один канонический адрес.

Затем используйте инструмент проверки URL в Search Console, чтобы увидеть доступные сведения о выбранной Google канонической версии.

5. Проверьте внутренние ссылки и Sitemap

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

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

В Sitemap включайте актуальные канонические URL, предназначенные для индексирования.

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

Как понять, что поисковая видимость действительно ухудшилась

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

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

Для обоснованного вывода необходимо рассмотреть более продолжительные сопоставимые периоды.

Сравнивайте не только общий график, но и отдельные группы документов.

ГруппаЧто исследоватьСтарые URLПоказы, клики и текущие перенаправленияНовые статьиИндексацию, запросы и поисковые переходыКоммерческие страницыВидимость по целевым запросам и обращенияРазделы сайтаИзменение доли поискового трафикаОсновные запросыСмена посадочных страниц и колебания позиций

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

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

Если же обе версии постепенно теряют видимость, а соответствующего роста на других страницах нет, проблему стоит исследовать глубже.

При этом важно не путать корреляцию с причиной. Сам факт падения показов после изменения CMS ещё не доказывает, что причиной стала именно новая платформа.

Что делать с большим архивом старого форума

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

У такого переноса есть несколько особенностей.

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

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

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

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

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

Здесь недостаточно настроить перенаправление по одному шаблону. Нужна таблица соответствия конкретных исторических адресов и новых документов.

Когда можно оценивать результат переезда

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

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

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

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

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

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

Не рекомендуется постоянно менять адреса, заголовки и canonical только потому, что позиции колеблются в первые дни после миграции.

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

Что должен получить владелец сайта после смены CMS

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

В результате у владельца должны быть:

1. Список старых и новых URL с правилами обработки.
2. Проверенные постоянные перенаправления.
3. Корректные canonical для действующих страниц.
4. Настроенные robots.txt и XML Sitemap.
5. Сохранённые полезные материалы.
6. Исправленные внутренние ссылки.
7. Проверка основных страниц на мобильных устройствах.
8. Подключённые поисковые панели.
9. Сохранённая исходная статистика для сравнения.
10. Перечень выявленных проблем и выполненных исправлений.

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

Вывод: сохранить поисковый трафик важнее, чем просто заменить CMS

При смене платформы часто основное внимание уделяют дизайну, скорости и удобству редактирования.

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

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

Пользователь должен находить ту информацию, за которой пришёл из поиска.

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

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

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

Именно поэтому начинать переезд следует не с удаления старого движка, а с инвентаризации URL, содержимого и поисковых данных. А завершать — проверкой перенаправлений, индексации и фактических результатов.