Редизайн сайта на WordPress без потери SEO-позиций

Почему после редизайна органика проседает, и почему это предсказуемо

Компания живёт с сайтом, который приносит заявки, потом решает «освежить внешний вид». Через три недели после запуска отдел продаж спрашивает, куда делись обращения с поиска. Ситуация настолько типовая, что в агентской практике редизайн давно перестал быть задачей дизайнера: это прежде всего техническая миграция и уже потом смена картинки.

Механика здесь простая. Поисковая система не оценивает «красоту» нового макета и не наказывает за обновление дизайна как таковое. Позиции теряются из-за конкретных вещей, которые ломаются при переезде на новый шаблон:

изменилась структура адресов, а старые URL начали отдавать 404;
из нового шаблона выпали служебные элементы — заголовки, микроразметка, canonical, хлебные крошки;
вместе с редизайном «почистили» тексты, и со страниц исчез именно тот контент, который и приводил трафик;
тестовая копия сайта успела попасть в индекс и создала дубли;
новый шаблон оказался тяжелее старого, и метрики скорости ушли в красную зону.

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

Замер «до»: что зафиксировать, пока дизайнер ещё не открыл макет

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

Что нужно выгрузить и положить в отдельную папку проекта:

Полный список URL. Выгрузите карту сайта, список из Search Console (отчёт «Страницы»), список из Яндекс.Вебмастера и, для надёжности, обход сайта краулером. Три источника дают разный результат: sitemap показывает то, что вы хотели отдать в индекс, а отчёты вебмастеров показывают то, что реально проиндексировано, включая забытые страницы, о которых никто в компании уже не помнит.
Топ страниц по трафику и конверсиям. За последние 12 месяцев, не за месяц — иначе выпадет сезонка. Это ваш список неприкасаемого: страницы, которые в редизайне трогают в последнюю очередь и только с обоснованием.
Позиции по семантике. Снимок позиций в Google и Яндексе на дату старта работ. Без него после запуска вы не отличите реальное падение от обычных колебаний выдачи.
Метаданные. Title, description, H1 и canonical для всех значимых страниц — в виде таблицы. Эта таблица потом станет чек-листом приёмки.
Внешние ссылки. Какие именно страницы получают ссылки со сторонних сайтов. Если такая страница исчезнет без редиректа, вы потеряете не только её саму, но и накопленный ссылочный вес.
Показатели скорости. Замерьте текущие значения основных веб-показателей: LCP, INP и CLS. По методике Google хорошими считаются LCP до 2,5 секунды, INP до 200 миллисекунд и CLS не выше 0,1. Метрика INP, к слову, в 2024 году окончательно заменила устаревшую FID. Если вы ориентируетесь на старые отчёты, они уже неактуальны.

На этот замер уходит один-два дня. Это самая дешёвая страховка во всём проекте.

Карта URL — главный документ редизайна

Если из всей статьи вы запомните один пункт, пусть это будет он. Карта URL — таблица, где для каждого адреса старого сайта указан адрес нового и тип перехода. Три возможных сценария:

Адрес не меняется. Идеальный случай. Страница просто получает новый внешний вид, все накопленные сигналы остаются при ней, никакой дополнительной работы не требуется.
Адрес меняется. Нужен постоянный редирект со старого на новый. Google прямо рекомендует использовать серверные постоянные редиректы — коды 301 или 308 — и предупреждает: не выстраивайте длинные цепочки, больше трёх-пяти переходов подряд лучше не допускать, они добавляют задержку пользователю.
Страница удаляется. Ставьте редирект на ближайший по смыслу раздел, а не на главную. Массовый редирект всего подряд на главную страницу поисковые системы обычно трактуют как мягкую 404 — ценность такого перехода близка к нулю.

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

Техническая реализация в WordPress. Самый производительный вариант — правила на уровне веб-сервера, в .htaccess для Apache или в конфиге Nginx: редирект отрабатывает до того, как запустится PHP. Если правил сотни и они генерируются из таблицы, это по-прежнему рабочий путь. Плагинный вариант тоже допустим: в Yoast SEO Premium есть менеджер редиректов, который отслеживает смену адреса записи и предлагает создать редирект автоматически, поддерживает типы 301, 302, 307, 410 и 451 и умеет импортировать готовый список из CSV или из .htaccess. По умолчанию он работает средствами PHP — это чуть медленнее серверных правил, но зато не требует доступа к конфигурации хостинга. В каталоге wordpress.org есть и бесплатные плагины со схожей задачей.

Важная деталь именно для WordPress: если в ходе редизайна вы меняете структуру постоянных ссылок в «Настройки → Постоянные ссылки», адреса меняются у всех записей сразу, а не у одной. Это самый частый способ обрушить сайт одним кликом — решение принимайте до старта работ и сразу закладывайте массовые редиректы в карту URL.

Что нельзя потерять при переносе шаблона

Новая тема WordPress — это новый набор файлов шаблона. Всё, что было «прибито» к старой теме, при переключении исчезает молча, без предупреждений в админке. Проверяйте по списку:

Заголовки и метаописания. Если они хранятся в SEO-плагине, при смене темы они уцелеют. Если предыдущий подрядчик прописывал их прямо в header.php старой темы — они пропадут вместе с ней.
Структурированные данные. Микроразметка организации, товаров, статей, хлебных крошек, FAQ. В новом шаблоне её нужно воспроизвести и проверить валидатором.
Иерархия заголовков. Частая ошибка нового макета: дизайнер сделал крупный текст в шапке, разработчик обернул его в H1, и на каждой странице стало по два H1. Или наоборот — H1 исчез вообще, потому что визуально заголовок «не вписался».
Атрибуты alt у изображений. При переносе контента через копирование блоков alt часто теряется.
Внутренняя перелинковка. Новый минималистичный дизайн любит убирать блоки «читайте также» и боковые меню. Вместе с ними уходит перелинковка, которая распределяла вес по сайту.
Тексты. Отдельный больной пункт. Часто всё начинается с фразы «слишком много текста, давайте сократим», после которой сайт теряет позиции по низкочастотным запросам. Если текст мешает дизайну, задача дизайна — найти для него форму: аккордеон, вкладки, блок ниже первого экрана. Скрытый в аккордеоне контент индексируется, если он присутствует в HTML-коде страницы.
Файлы robots.txt и sitemap.xml. Убедитесь, что новая сборка отдаёт их корректно и карта сайта содержит актуальные адреса.

Скорость: почему новый дизайн часто медленнее старого

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

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

Что закладывать в проект заранее:

изображения в современных форматах и с явно заданными размерами — незаданные размеры дают скачки вёрстки и портят CLS;
отложенную загрузку для всего, что ниже первого экрана, и приоритетную — для главного изображения первого экрана, оно чаще всего и является объектом измерения LCP;
ограниченный набор шрифтов: два семейства и три начертания вместо пяти;
ревизию плагинов — редизайн хороший повод выкинуть то, что установили три года назад и забыли;
кеширование на уровне сервера, а не только плагином.

Замерять скорость нужно на копии нового сайта до запуска, а не после. Если новая версия проигрывает старой по LCP и INP, это повод оптимизировать её до переключения, а не в авральном режиме на живом трафике.

Тестовая площадка: как не проиндексировать черновик

Дубли сайта — вторая по частоте причина проблем после редизайна. Схема одинаковая: разработчик поднимает копию на поддомене вроде new.вашсайт.kz, копию находит поисковый робот, и в индексе появляется второй экземпляр всех страниц.

В WordPress есть встроенная защита: «Настройки → Чтение → Видимость для поисковых систем», флажок «Попросить поисковые системы не индексировать сайт». Начиная с версии 5.3 он добавляет в секцию <head> тег <meta name="robots" content="noindex,nofollow" />. Но обратите внимание на формулировку в самой документации WordPress: это просьба, а не запрет, и поисковые системы вольны её проигнорировать. Доступ к сайту флажок не закрывает вообще.

Поэтому надёжный вариант для тестовой площадки — базовая HTTP-авторизация на уровне сервера: посторонний просто не получит страницу без логина и пароля. Флажок в настройках при этом всё равно ставьте, как второй рубеж.

И главное — снимите его при переносе на боевой домен. Забытый «noindex» после запуска — классика жанра: сайт работает, выглядит отлично, а из индекса уходит целиком за пару недель. Проверка занимает десять секунд: откройте исходный код главной страницы и поищите в нём слово «noindex».

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

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

За сутки: полный бэкап работающего сайта — файлы и база. Проверьте, что бэкап разворачивается, а не просто лежит в папке.
Перед переключением: финальная проверка карты URL. Прогоните список старых адресов и убедитесь, что для каждого есть правило.
Переключение: лучше в будни утром, а не вечером пятницы. Нужен запас рабочего времени команды на реакцию.
Сразу после: проверьте выборочно 20-30 старых URL из разных разделов — они должны отдавать код 301 и вести на релевантные страницы. Отдельно проверьте те, у которых больше всего внешних ссылок.
Проверьте счётчики. Коды аналитики при смене шаблона теряются регулярно. Убедитесь, что Google Analytics и Яндекс.Метрика получают данные, а цели и события работают.
Проверьте формы. Отправьте тестовую заявку через каждую форму на сайте и убедитесь, что она дошла до почты и до CRM. Если сайт связан с CRM-системой, проверьте, что лид создаётся с правильным источником.
Отправьте обновлённую карту сайта в Search Console и Яндекс.Вебмастер. Google отдельно предупреждает: предупреждения о редиректах в старой карте сайта в период переезда — нормальное явление, на них можно не реагировать.
Инструмент «Изменение адреса» в Search Console нужен только при смене домена. При редизайне в пределах того же домена он не применяется; не нужен он и при переходе с HTTP на HTTPS.

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

Первые тридцать дней: что смотреть и когда начинать волноваться

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

Что держать под наблюдением:

Отчёт по индексированию в Search Console. Рост числа страниц с ошибками — сигнал, что часть редиректов не отработала. Особое внимание категории «Не найдено (404)».
Журнал 404-х на сервере. Самый честный источник: показывает адреса, которые реально запрашивают, а вы их не предусмотрели.
Позиции по тому же списку запросов, что снимали до запуска. Сравнивайте с исходным замером, а не с ощущениями.
Трафик по разделам, а не в целом по сайту. Общая цифра прячет ситуацию, когда один раздел вырос, а другой обвалился.
Конверсию. Бывает и обратное: трафик просел на 10%, а заявок стало больше, потому что новый сайт лучше продаёт. Оценивать редизайн только по трафику — ошибка.

Ориентир по срокам: если через две недели картина стабилизировалась и постепенно возвращается, значит, процесс идёт штатно. Если через месяц позиции продолжают падать, а в отчётах растут 404-е и дубли, значит, что-то не доделано технически, и это нужно разбирать точечно, а не ждать «пока само устаканится».

Что прописать в техзадании подрядчику

Большинство конфликтов «мы же не просили ломать SEO» возникает потому, что в договоре про SEO не было ни строчки. Дизайн-студия честно выполнила то, за что ей платили: нарисовала макеты. Разработчик так же честно их сверстал. Ответственного за сохранение позиций в проекте просто не назначили.

Формулировки, которые стоит внести в ТЗ ещё до подписания:

Карта URL как отдельный принимаемый результат. Не «сделаем редиректы», а таблица «старый адрес — новый адрес — тип», которую вы принимаете и подписываете до запуска.
Список неприкасаемых страниц. Перечислите топ по трафику и конверсиям и зафиксируйте: тексты и заголовки на этих страницах не сокращаются без письменного согласования.
Целевые значения скорости. Пропишите пороги основных веб-показателей, которым должна соответствовать новая версия на момент сдачи, и способ замера. Иначе «сайт стал медленнее» превращается в спор о вкусе.
Требование к тестовой площадке. Закрытая паролем на уровне сервера, не только флажком в настройках WordPress.
Перенос микроразметки и метаданных — отдельным пунктом, с проверкой валидатором при приёмке.
Гарантийный период после запуска. Хотя бы 30 дней, в течение которых подрядчик закрывает всплывающие 404-е и технические ошибки без дополнительной оплаты.

Отдельно решите вопрос доступов: к моменту запуска права в Search Console, Яндекс.Вебмастере, аналитике и на хостинге должны быть у вашей стороны, а не только у подрядчика.

Как это выглядит на практике

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

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

В понедельник трафик ниже вдвое. Разбор показывает три причины. Первая: в новой теме адреса категорий получили другой префикс, редиректы никто не настроил — примерно 40 страниц отдают 404. Вторая: описания категорий, по 1500-2000 знаков каждое, в новом макете «не помещались», и их убрали; вместе с ними ушли ключевые вхождения, по которым эти страницы и ранжировались. Третья: на тестовом поддомене был выключен флажок приватности, и часть страниц копии успела попасть в индекс.

Разбор занимает неделю. Восстановление позиций занимает около двух месяцев. Все три причины закрывались на этапе подготовки: карта URL сняла бы первую, список неприкасаемых страниц — вторую, HTTP-авторизация на тесте — третью. Два-три дня работы до старта против двух месяцев потерянного трафика после.

Именно поэтому в смете на редизайн строка «SEO-сопровождение переезда» не является опциональной надстройкой. Обновление дизайна без потери позиций стоит примерно 10-15% бюджета проекта в виде дополнительной технической работы — и экономит куда больше, если считать в недополученных заявках.

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

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

Сколько держать редиректы со старых адресов?
Google рекомендует держать их как минимум год. На практике удобнее не снимать их вообще: правило в конфигурации сервера не создаёт нагрузки, а внешние ссылки на старые адреса могут всплыть и через несколько лет.

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

Нужно ли использовать инструмент «Изменение адреса» в Search Console?
Только при смене домена. Если редизайн проходит в пределах того же домена, инструмент не применяется. Он также не нужен при переезде с HTTP на HTTPS.

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