Миграция с Tilda, Wix или Webflow без потери SEO: пошаговый план
Перенос сайта с Tilda, Wix, Webflow или другой платформы часто воспринимают как простую техническую задачу: скопировать дизайн, перенести тексты, переключить домен — готово.
Но если сайт уже получает органический трафик, имеет проиндексированные страницы, внешние ссылки, рекламные кампании и историю в Google, миграция становится значительно серьезнее.
Необходимо перенести не только то, что видит пользователь.
Важно сохранить или правильно передать:
- URL страниц;
- контент;
- title и description;
- canonical;
- внутренние ссылки;
- языковые связи;
- структурированные данные;
- аналитику;
- формы и интеграции;
- поисковые сигналы старых URL.
Когда полезна эта статья
В журнале TimeKairos уже есть отдельный материал о том, когда бизнес действительно перерастает конструктор. Здесь вопрос другой. Предположим, решение о миграции уже принято. Теперь необходимо понять:- как подготовить старый сайт;
- что переносить без изменений;
- когда нужны 301-редиректы;
- можно ли менять URL;
- что делать с SEO;
- как проверить новый сайт перед запуском;
- что контролировать после переключения.
Можно ли мигрировать сайт без потери SEO
Обещать абсолютно нулевые колебания при крупной миграции было бы неправильно. Google предупреждает, что после существенного изменения сайта позиции могут временно колебаться, пока поисковая система повторно обходит и обрабатывает старые и новые URL. Но это не означает, что миграция обязательно уничтожает органический трафик. Риски можно существенно снизить, если:- не удалять ценные страницы без причины;
- сохранять URL там, где это возможно;
- правильно настроить редиректы там, где адрес меняется;
- не оставить новый сайт закрытым от индексации;
- сохранить значимый контент и метаданные;
- обновить внутренние ссылки;
- контролировать Search Console после запуска.
Сначала определите тип миграции
1. Платформа меняется, URL остаются
Например: example.com/services остается example.com/services, но сайт больше не работает на Tilda. С точки зрения SEO это один из наиболее простых сценариев, поскольку пользовательские адреса страниц сохраняются.2. Меняются платформа и URL
Например: example.com/t123456-page → example.com/services. Здесь необходима карта соответствий и постоянные редиректы.3. Меняется домен
oldbrand.com → newbrand.com. Это отдельный тип миграции, требующий дополнительной работы с Search Console и внешними ссылками.4. Меняется все одновременно
Новый домен, CMS, структура URL, дизайн и контент. Это наиболее сложный сценарий. Где это практически возможно, крупные изменения лучше разделять, чтобы после запуска было проще определить причину проблем.Шаг 1. Соберите все старые URL
Не стоит строить новый сайт, пока неизвестно, какие страницы уже существуют. URL можно собрать из:- sitemap;
- Google Search Console;
- аналитики;
- результатов краулинга;
- CMS или конструктора;
- данных о внешних ссылках.
Шаг 2. Определите судьбу каждой страницы
Старые страницы можно разделить на несколько категорий:- оставить;
- объединить;
- перенести на новый URL;
- удалить как полностью устаревшие.
- поисковый трафик;
- показы;
- внешние ссылки;
- рекламные кампании;
- внутренние ссылки;
- бизнес-ценность.
Шаг 3. Сохраняйте URL, если нет причины менять их
Если содержание страницы остается прежним, техническая платформа сама по себе не является причиной менять адрес. Стабильный URL упрощает миграцию для пользователей, поисковых систем, аналитики и внешних ссылок.Шаг 4. Подготовьте redirect map
Если URL меняются, каждому старому адресу нужно назначить наиболее релевантный новый. Например: /old-web-design → /services/web-design а не автоматически на главную страницу. Перенаправление десятков разных материалов на одну нерелевантную страницу не является качественной миграцией.Шаг 5. Используйте постоянные редиректы
Если контент окончательно переехал, обычно используются постоянные серверные редиректы, например 301 или 308. Они сообщают пользователю и поисковой системе, что у страницы появился постоянный новый адрес. По возможности лучше сразу вести на финальную страницу и не создавать длинные цепочки перенаправлений.Теряется ли PageRank из-за 301
Google прямо указывает, что 301 и другие постоянные редиректы сами по себе не вызывают потери PageRank. Однако правильный код ответа не исправляет плохую карту миграции. Риски появляются, если:- страница перенаправлена на нерелевантный контент;
- важный материал удален;
- новый сайт закрыт от сканирования;
- содержание полностью изменено;
- присутствуют другие технические ошибки.
Шаг 6. Осторожно переносите работающий контент
Миграция — не всегда лучший момент для полного переписывания всех текстов. Если страница уже получает релевантный трафик, разумнее сначала сохранить ее ключевой смысл и структуру, а крупные контентные изменения проводить отдельным этапом. Особенно внимательно переносите:- H1 и заголовки;
- основной текст;
- FAQ;
- цены;
- изображения;
- alt;
- внутренние ссылки;
- основные CTA.
Шаг 7. Не потеряйте SEO-метаданные
Во время редизайна легко забыть элементы, которых нет в макете. Перед запуском сравните:- SEO Title;
- Meta Description;
- robots meta;
- canonical;
- языковые атрибуты.
Шаг 8. Проверьте canonical
После запуска canonical не должен случайно вести на staging, старый домен или неправильный URL. Для каждой индексируемой страницы должна быть понятна ее каноническая версия.Шаг 9. Удалите временный noindex
Тестовый сайт часто специально закрывают от индексации. Перед production-запуском необходимо проверить:- robots.txt;
- meta robots;
- HTTP-заголовки;
- настройки CMS;
- firewall;
- антибот-защиту.
Шаг 10. Обновите внутренние ссылки
Внутренние ссылки нового сайта должны вести прямо на актуальные URL. Не стоит оставлять: новая страница → старый URL → 301 → новый URL. Проверьте:- меню;
- footer;
- тексты;
- CTA;
- breadcrumb;
- related posts;
- карточки.
Шаг 11. Сохраните мультиязычность
Для UA / RU / EN версии необходимо сохранить логическую связь между соответствующими страницами. Проверяются:- lang;
- hreflang;
- canonical;
- language switcher;
- редиректы;
- метаданные.
Шаг 12. Проверьте Schema.org
При смене платформы структурированные данные часто исчезают или, наоборот, начинают дублироваться. Проверьте используемые типы, например:- Organization;
- Article;
- BreadcrumbList;
- Product;
- LocalBusiness.
Шаг 13. Перенесите аналитику
Проверьте не только наличие скриптов, но и реальные события:- Google Analytics;
- Google Tag Manager;
- Meta Pixel;
- рекламные конверсии;
- CRM;
- call tracking;
- покупки и формы.
Шаг 14. Протестируйте интеграции
Необходимо вручную пройти ключевые бизнес-сценарии. Проверьте:- отправку формы;
- доставку email;
- создание сделки в CRM;
- Telegram-уведомления;
- оплату;
- бронирование;
- загрузку файлов;
- другие интеграции.
Шаг 15. Обновите sitemap
Sitemap нового сайта должен содержать актуальные канонические URL. После запуска его можно отправить в Google Search Console. Карта сайта не гарантирует индексацию, но помогает поисковой системе обнаружить актуальную структуру.Шаг 16. Следите за Search Console
После запуска контролируйте:- индексацию;
- 404;
- ошибки редиректов;
- canonical;
- sitemap;
- Core Web Vitals;
- показы;
- клики.
Когда нужен Change of Address
Change of Address используется при переезде на другой домен или субдомен. Если сайт просто переехал с Wix или Tilda на другую технологию, сохранив тот же домен, этот инструмент не нужен.Как долго сохранять редиректы
Google рекомендует оставлять редиректы при изменении URL как можно дольше и в целом не менее года. Для важных старых адресов часто разумно сохранять их и после этого срока. При этом собственные ссылки сайта нужно постепенно обновить на новые URL.Нужно ли менять домен
Нет. Переезд с конструктора сам по себе не требует смены доменного имени. Если бренд остается прежним, обычно проще сохранить существующий домен и поменять только инфраструктуру.Нужен ли редизайн одновременно с миграцией
Не обязательно. Возможны три подхода:Перенос существующего дизайна
Если проблема исключительно техническая.Контролируемое обновление
Исправляются mobile UX, отдельные компоненты и структура.Полный rebuild
Если устарели и дизайн, и структура, и техническая основа. Последний вариант уже правильнее называть не просто миграцией, а новым проектом.Когда миграция становится новой разработкой
Сложные системы могут включать:- большой каталог;
- checkout;
- личный кабинет;
- авторизацию;
- базы данных;
- booking;
- ERP;
- marketplace;
- сложные API.
Всегда ли custom дешевле конструктора
Нет. У собственной разработки тоже существуют расходы:- хостинг;
- домен;
- обслуживание;
- разработка;
- изменения;
- мониторинг.
Всегда ли конструктор медленнее
Нет. Хорошо собранная страница на конструкторе способна работать быстрее плохо реализованного custom-сайта. Индивидуальная разработка дает больше контроля, но качество результата зависит от реализации.Чек-лист перед запуском
- Все старые URL учтены.
- Redirect map готов.
- 301/308 ведут на релевантные страницы.
- Production не содержит случайный noindex.
- Robots.txt настроен правильно.
- Canonical корректны.
- Метаданные проверены.
- Hreflang работает.
- Формы отправляются.
- Аналитика фиксирует конверсии.
- Mobile протестирован.
- 404 проверены.
- Sitemap обновлен.
- Есть план отката при критической ошибке.
Что контролировать после запуска
Следите за:- органическими кликами;
- показами;
- индексацией;
- 404;
- редиректами;
- серверными ошибками;
- заявками;
- рекламными конверсиями;
- скоростью;
- Core Web Vitals.
