Редизайн и миграция сайта: смена CMS, сохранение SEO
Клиент пришёл через 6 недель после самостоятельного редизайна: «Мы переехали с WordPress на Tilda, трафик упал на 70%». Открываю Google Search Console — 847 страниц отдают 404, URL-структура полностью изменилась, не было ни одного 301-редиректа. Яндекс ещё не переиндексировал новый сайт, позиции рухнули. Восстановление заняло 4 месяца.
Почему миграции ломают SEO
Поисковики проиндексировали конкретные URL. Если /catalog/shoes/nike-air-max-270 превратился в /products/nike-air-max-270 без 301-редиректа — весь ссылочный вес страницы, весь трафик, все позиции уходят в никуда. Google говорит, что 301 передаёт ~99% PageRank, но на практике позиции восстанавливаются за 2–8 недель, а не мгновенно.
Чаще всего SEO ломают не из злого умысла, а потому что разработчик не думает о URL-структуре как о публичном API.
Типичные поломки при миграции:
Дублированный контент. Новый сайт открывается и на старом домене, и на новом во время разработки. Googlebot индексирует оба — дубликаты.
Потеря метаданных. Title и description были в кастомных полях WordPress, в новой CMS их забыли перенести для 500+ страниц. Google подставляет что попало.
Изменение canonical. Страницы пагинации, фильтры каталога — canonical ссылки сбросились на новый формат.
Скорость просела. Tilda с тяжёлыми секциями, без оптимизации изображений: LCP 6.8s вместо 2.1s на старом сайте. Core Web Vitals в красной зоне влияют на ранжирование.
Предмиграционный аудит: что нельзя пропустить
До начала разработки нового сайта нужно:
- Сделать полный краул текущего сайта через Screaming Frog или Sitebulb. Получить список всех индексируемых URL с трафиком из Google Search Console.
- Выгрузить все страницы с органическим трафиком > 0 за последние 6 месяцев — это приоритет для редиректов.
- Зафиксировать все внешние ссылки (backlinks) на конкретные страницы — Ahrefs, Semrush.
- Сфотографировать текущие позиции по ключевым запросам — база для сравнения после миграции.
- Сохранить Core Web Vitals из Search Console за предыдущие 90 дней.
Маппинг URL и редиректы
Для проекта с 200+ страницами создаём таблицу маппинга: старый URL → новый URL → статус (301, объединён с другой страницей, удалён). Каждая строка проходит проверку: реально ли контент переехал именно сюда.
В Laravel редиректы через конфигурационный файл и middleware, не через .htaccess — это быстрее и управляемо. Для WordPress → Next.js: редиректы настраиваются в next.config.js (статические) и на уровне Nginx/CDN для динамических.
Старый .htaccess на shared хостинге с 500+ строками редиректов — особый ад. Каждый редирект проверяется последовательно, производительность падает. Переносим в Nginx map директиву или Redis-кэш для динамического поиска.
Миграция контента из разных CMS
WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API или WP All Export для экспорта постов, метаполей, медиафайлов. Скрипт миграции на Node.js: парсим экспорт, трансформируем структуру, загружаем через API CMS. Медиафайлы перегружаем в новое хранилище, обновляем ссылки в контенте. Типичная проблема — shortcodes в контенте WordPress ([gallery id="123"]): нужен парсер и трансформация в новый формат.
1С-Битрикс → современный стек:
Битрикс хранит контент в нестандартных таблицах с IBLOCK_ELEMENT_PROPERTY. Прямой SQL-экспорт через phpMyAdmin или Bitrix API. Трансформация — самая долгая часть из-за специфики структуры данных Битрикса.
Тяжёлые WYSIWYG → структурированный контент: Годы редактирования в FCKEditor/TinyMCE оставляют inline-стили, нестандартные теги, сломанные атрибуты. HTML sanitize + трансформация в Markdown или Portable Text (Sanity) с ручной проверкой проблемных страниц.
SEO-сохранение технических элементов
Структурированные данные (Schema.org) — если на старом сайте были Product, Article, BreadcrumbList разметки, они должны быть и на новом. Google Search Console → Enhancement reports покажут потерю rich snippets.
Sitemap XML: генерируется автоматически, отправляется в GSC через день после запуска. Старый sitemap остаётся до полной переиндексации.
hreflang для мультиязычных сайтов: если теги потерялись при миграции, через несколько недель начнутся конфликты между языковыми версиями в выдаче.
Open Graph и Twitter Card мета-теги — часто забывают при смене шаблона, страницы перестают корректно отображаться при шаринге в соцсетях.
Запуск и мониторинг первых недель
DNS propagation: переключение DNS занимает до 48 часов, планируйте запуск с запасом. Cloudflare как DNS-провайдер — propagation занимает минуты, не часы.
После запуска ежедневно мониторим: Search Console → Coverage (ошибки индексации), Analytics → органический трафик, сравнение с аналогичным периодом прошлого года, краулинг сайта на 404-ошибки.
Первые 2 недели — критический период. Если трафик падает на 30%+ — немедленный аудит редиректов и сравнение с предмиграционным краулом.
Процесс работы
Предмиграционный аудит → маппинг URL → разработка нового сайта параллельно со старым → финальный аудит перед запуском → запуск с мониторингом → постмиграционный мониторинг 4–8 недель.
Сроки
Редизайн с миграцией небольшого сайта (до 100 страниц): 4–8 недель. Миграция e-commerce с 500+ страниц товаров: 8–16 недель. Только техническая часть миграции (редиректы, метаданные) без редизайна: 1–3 недели.