Миграция сайта на 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 была слабым местом уже давно.

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

Сколько времени занимает миграция сайта на 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 и раздел «Переобход страниц» в Яндекс.Вебмастере для ключевых страниц — это не обязательно, но помогает быстрее обновить данные в поиске.