Миграция сайта на WordPress без потери позиций в поиске

Почему трафик проседает после переноса сайта на WordPress

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

Позиции проседают не из-за самой смены CMS, а из-за побочных эффектов: меняются адреса страниц, теряются редиректы, дублируется контент на старом и новом домене одновременно, исчезают ключевые meta-теги, ломается перелинковка. Для владельца бизнеса это выражается в конкретных цифрах — падении органического трафика на 30-60% в первые недели после запуска, если миграция сделана без SEO-плана. Восстановление после такого провала занимает месяцы, а иногда позиции не возвращаются вовсе, потому что конкуренты успевают занять освободившиеся места в выдаче.

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

Аудит текущего сайта: что нужно зафиксировать до переноса

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

• Полный список индексируемых URL. Выгрузите все страницы из Google Search Console (раздел «Страницы» → «Проиндексировано») и из Яндекс.Вебмастера. Это те адреса, которые поисковики уже знают и ранжируют — их нужно либо сохранить, либо корректно перенаправить.
• Данные по органическому трафику постранично. В Google Analytics или Яндекс.Метрике выгрузите отчёт по посещаемости за последние 6-12 месяцев в разрезе URL. Страницы с наибольшим трафиком — приоритет №1 при переносе: если что-то пойдёт не так, именно они принесут наибольшие потери.
• Профиль внешних ссылок. Через Google Search Console («Ссылки» → «Внешние ссылки») или сторонние инструменты выгрузите список страниц, на которые ссылаются другие сайты. Обратные ссылки — один из самых дорогих SEO-активов, и их легко обесценить, если целевая страница исчезнет без редиректа.
• Метаданные и структурированные данные. Title, description, канонические ссылки, разметка Schema.org (отзывы, FAQ, товары, статьи) — всё это должно быть задокументировано, чтобы новая версия сайта не потеряла то, что уже даёт richsnippets в выдаче.
• Текущую скорость загрузки и мобильную версию. Зафиксируйте показатели Core Web Vitals через PageSpeed Insights до миграции — это будет базой для сравнения после запуска, чтобы доказать (себе и команде), что новая версия быстрее, а не медленнее.

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

Карта редиректов 301 — основа безопасного переноса

Если новая структура URL на WordPress отличается от старой хотя бы частично, без карты редиректов 301 позиции гарантированно просядут. Редирект 301 — это сигнал поисковику «страница переехала навсегда, передай новому адресу авторитет старого». Без него поисковая система видит две ситуации: старый URL отдаёт 404 (ошибка), а новый URL — это совершенно незнакомая страница без истории.

Правило, которое стоит соблюдать без исключений: у каждого старого проиндексированного URL должен быть ровно один целевой редирект на смысловой аналог на новом сайте. Не на главную страницу «на всякий случай» — это распространённая ошибка, которая почти обнуляет пользу редиректа в глазах Google. Если у старой страницы нет прямого аналога, ищите максимально близкую по теме страницу в новой структуре, а не сваливайте всё на главную.

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

• через правила в файле .htaccess (для Apache) или в конфигурации Nginx — быстрее по производительности, но требует доступа к серверу;
• через плагин редиректов (например, Redirection) — удобнее для контента-менеджера, позволяет вести таблицу соответствий и логировать 404-ошибки после запуска;
• комбинированно: массовые редиректы по шаблону (например, изменение структуры категорий) — на уровне сервера, точечные редиректы для конкретных страниц — через плагин.

Для сайтов с несколькими тысячами страниц карту редиректов стоит строить не вручную, а через сопоставление URL по шаблонам (regex), проверяя итоговый список выборочными запросами перед запуском.

Технические SEO-параметры, которые легко потерять при переносе на WordPress

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

Файл robots.txt. На старой платформе он мог закрывать от индексации служебные разделы (админку, корзину, страницы фильтров). На WordPress по умолчанию генерируется другой robots.txt, и если его не настроить заново, можно либо случайно закрыть от индексации нужные страницы, либо, наоборот, открыть то, что должно быть скрыто.

XML-карта сайта. WordPress-плагины (Yoast SEO, Rank Math) генерируют sitemap автоматически, но её нужно вручную отправить в Google Search Console и Яндекс.Вебмастер после запуска — старая карта сайта, если она была прописана в настройках, будет вести на несуществующий URL.

Канонические ссылки. При переносе легко получить ситуацию, когда одна и та же страница доступна по нескольким URL (с завершающим слешем и без, с www и без, по HTTP и HTTPS). Без корректных canonical-тегов поисковик может посчитать это дублированным контентом и размыть ранжирующий сигнал между копиями.

Структурированные данные (Schema.org). Если на старом сайте были настроены микроразметка отзывов, товаров, статей или организации — это нужно воссоздать на WordPress через плагин SEO или кастомные поля, иначе сайт потеряет расширенные сниппеты в выдаче (рейтинги со звёздами, FAQ-блоки), которые повышают CTR.

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

SSL-сертификат и протокол. Если сайт переезжает одновременно на HTTPS (а не только на новую CMS), это отдельное изменение адреса для поисковика — потребуется дополнительный уровень редиректов с http:// на https:// версии.

Тестовая среда: что проверить до того, как сайт увидят пользователи

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

Чек-лист перед переключением на боевой домен:

• Тестовая версия закрыта от индексации через noindex в meta-тегах или через пароль на уровне сервера — иначе Google может проиндексировать тестовый URL как отдельный сайт-дубликат.
• Все запланированные редиректы 301 протестированы на тестовом окружении и отдают корректный код ответа (не 302, который поисковик воспринимает как временный, а именно 301).
• Проверена корректность отображения на мобильных устройствах — большинство трафика в коммерческом сегменте сейчас мобильное, и адаптивность напрямую влияет на ранжирование.
• Сверены title, description и заголовки H1 на топ-20 страниц по трафику — они должны совпадать с тем, что зафиксировано на этапе аудита, либо быть осознанно улучшены, а не потеряны при переносе контента.
• Настроена система аналитики (Google Analytics, Яндекс.Метрика) на новой версии сайта с сохранением идентификаторов целей и событий, чтобы не потерять историю конверсий.
• Проверена скорость загрузки через PageSpeed Insights — новая версия должна быть быстрее старой, а не медленнее, иначе миграция создаёт дополнительный риск для позиций.

День запуска: последовательность действий

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

Оптимальное время запуска — период минимального трафика (обычно ночь с пятницы на субботу или выходные для B2B-сегмента), чтобы у команды было время оперативно отреагировать на неожиданности до начала рабочей недели.

Порядок действий:

1. Финальная выгрузка контента со старой платформы и сверка с тестовой версией на WordPress — на случай, если за время подготовки на старом сайте появились новые публикации.
2. Включение файла редиректов на боевом сервере — редиректы должны заработать в тот же момент, что и переключение DNS, а не позже.
3. Переключение DNS или домена на новый хостинг с WordPress.
4. Снятие блокировки индексации (если она стояла на тестовом окружении) и проверка, что новый robots.txt действительно открыт для поисковых роботов.
5. Отправка новой XML-карты сайта в Google Search Console и Яндекс.Вебмастер, использование инструмента «Проверка URL» для явного запроса переобхода главных страниц.
6. Ручная проверка 15-20 самых трафикообразующих URL по списку из аудита — открыть их напрямую и убедиться, что редирект или контент работают корректно, без ошибок сервера.

Не стоит вносить в этот же день никакие другие изменения на сайте — ни новый дизайн, ни правки контента, ни смену структуры меню. Задача первого дня — точный перенос, а не одновременное улучшение всего сразу. Дополнительные изменения только усложняют диагностику, если что-то пойдёт не так.

Мониторинг после переноса: первые 30, 60 и 90 дней

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

Что стоит отслеживать в этот период:

• Отчёт «Покрытие» / «Страницы» в Google Search Console — рост числа ошибок 404 или страниц, исключённых из индекса, сигнализирует о проблемах с редиректами, которые нужно закрыть в первую очередь.
• Позиции по ключевым коммерческим запросам — сравнивайте не абсолютные цифры, а динамику: краткосрочная просадка на 1-2 недели с последующим восстановлением — нормальное поведение, длительное падение без признаков восстановления — повод для аудита редиректов.
• Органический трафик по посадочным страницам — если конкретная страница, которая раньше приносила заявки, перестала получать трафик, в первую очередь проверьте, корректно ли она проиндексирована и не потерян ли на неё редирект.
• Логи сервера на предмет 404-ошибок — краулеры поисковых систем какое-то время будут по инерции заходить на старые адреса; если лог показывает регулярные обращения на URL без редиректа, его нужно добавить в карту.

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

Типичные ошибки при самостоятельном переносе сайта

Большинство проблем с позициями после миграции возникает не из-за нехватки инструментов — WordPress и его SEO-плагины закрывают почти все технические потребности. Проблема в порядке действий и в том, какие шаги пропускают, торопясь запустить новую версию сайта.

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

Редирект всех страниц раздела на одну общую страницу. Это самая распространённая техническая ошибка. Например, если старый раздел «Услуги» состоял из 20 отдельных страниц с описанием каждой услуги, а на новом сайте временно есть только одна общая страница «Услуги», соблазн — перенаправить все 20 старых адресов на неё. Для пользователя это работает, но для поисковика это выглядит как резкая потеря 19 уникальных страниц с их собственным контентом и историей ранжирования. Правильное решение — либо воссоздать отдельные страницы под каждую услугу на новом сайте, либо, если объединение оправдано бизнес-логикой, смириться с тем, что позиции по узким запросам временно просядут, и заложить это в план миграции заранее.

Игнорирование мобильной версии на этапе тестирования. Часто тестируют новую версию сайта только в браузере на компьютере, а мобильную адаптивность проверяют уже после запуска. Учитывая, что для большинства коммерческих ниш в Казахстане мобильный трафик составляет более половины визитов, а Google использует mobile-first индексацию, ошибки в мобильной вёрстке напрямую и быстро влияют на ранжирование всего сайта, а не только мобильной выдачи.

Смена домена одновременно со сменой платформы. Если вместе с переходом на WordPress меняется ещё и домен (например, при ребрендинге), риски миграции удваиваются: поисковику приходится одновременно обрабатывать смену CMS, структуры URL и домена целиком. По возможности эти два изменения стоит разносить по времени на несколько месяцев — сначала стабилизировать сайт на новом движке, затем отдельным проектом переносить на новый домен.

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

Пример из практики: перенос корпоративного сайта без потери позиций

Один из показательных случаев — перенос сайта производственной компании со старой самописной CMS на WordPress. У сайта было около 400 индексируемых страниц, включая карточки продукции и статьи блога, накопившие за несколько лет обратные ссылки с отраслевых площадок.

Основная сложность заключалась в том, что структура URL менялась почти полностью: старые адреса вида /catalog.php?id=123 нужно было привести к человекочитаемым ЧПУ-адресам WordPress. Решение — построение таблицы соответствий по внутреннему ID товара, который сохранялся в обеих системах, что позволило автоматически сопоставить каждый старый URL с новым без ручной сверки по 400 строкам.

Редиректы были протестированы на staging-окружении за неделю до запуска, миграция проведена в ночь на субботу, а в первый рабочий день после запуска команда вручную проверила топ-30 страниц по трафику. В первые две недели органический трафик просел примерно на 12% — ожидаемая техническая просадка, связанная с переиндексацией, — а к 60-му дню превысил показатели старого сайта на 18%, в основном за счёт возросшей скорости загрузки страниц каталога, которая на старой CMS была слабым местом уже давно. Сопровождение переезда без потери позиций входит в наше SEO-продвижение.

Частые вопросы

Сколько времени занимает миграция сайта на WordPress без потери SEO?
Для небольшого сайта (до 100 страниц) подготовка и перенос обычно занимают 1-2 недели, включая аудит, настройку редиректов и тестирование. Для крупных сайтов с несколькими тысячами страниц процесс может растянуться на 1-2 месяца, в основном из-за объёма работы по карте редиректов и проверке контента.

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

Что делать, если после переноса резко упал трафик?
Сначала проверьте отчёт «Покрытие» в Google Search Console на предмет ошибок 404 или проблем с индексацией — в большинстве случаев причина именно там: пропущенный редирект, случайно закрытый в robots.txt раздел или дублирующийся контент между старым и новым доменом.

Можно ли перенести сайт на WordPress самостоятельно, без агентства?
Технически да, особенно для небольших сайтов — WordPress и его плагины (Redirection, Yoast SEO) дают все необходимые инструменты. Риск в том, что без опыта легко пропустить один из технических пунктов чек-листа, а его последствия проявятся не сразу, а через несколько недель, когда исправить будет уже сложнее.

Нужно ли уведомлять Google и Яндекс о переносе сайта отдельно?
Прямого «уведомления о миграции» не существует, но стоит ускорить переобход через инструмент проверки URL в Google Search Console и раздел «Переобход страниц» в Яндекс.Вебмастере для ключевых страниц — это не обязательно, но помогает быстрее обновить данные в поиске.