Перенос сайта с Tilda без потери SEO: что сохранить, проверить и перенаправить

Чтобы перенести сайт с Tilda без неоправданной потери SEO, нужно до запуска зафиксировать все ценные URL и их роль, решить, какие адреса сохраняются, подготовить однозначную карту старый URL → новый URL, настроить серверные постоянные перенаправления там, где адрес меняется, перенести содержимое и метаданные, проверить canonical, robots, sitemap, формы, аналитику и внутренние ссылки, а после переключения — контролировать ответы сервера, индексирование и обращения.

Главный принцип: не менять то, что уже работает, без бизнес-причины. Если URL можно сохранить, его лучше сохранить. Если он меняется, у него должен быть ближайший смысловой преемник, а не массовое перенаправление на главную.

Фраза «перенос с Tilda» может обозначать разные операции. От типа зависит риск и состав работ.

Смена хостинга без изменения домена и URL

Страницы сохраняют те же адреса, но обслуживаются другим сервером или статической сборкой. Это наиболее управляемый сценарий, если:

• контент остаётся доступным в основном HTML;
• старые URL действительно совпадают;
• коды ответа корректны;
• canonical не указывает на staging;
• SSL работает;
• аналитика и формы перенесены;
• новые правила .htaccess или сервера не создают циклы.

Здесь чаще ломается инфраструктура, а не структура спроса.

Смена CMS или дизайна с изменением URL

Команда переносит сайт на другую систему и одновременно пересобирает архитектуру. Риск выше: один старый URL может разделиться на несколько новых, несколько страниц — объединиться, а часть старого контента исчезнуть.

Нужны решения по каждому адресу: сохранить, перенести, объединить, удалить с 410/404 либо перенаправить на действительно эквивалентный материал.

Смена домена

Меняются не только пути, но и весь доменный контур. Требуется полный mapping, серверные 301, обновление canonical, sitemap, внутренних ссылок, внешних профилей и инструментов вебмастеров. Такой перенос нельзя сводить к одному правилу «всё на новый домен» без проверки конкретных URL.

Перестройка внутри самой Tilda

Даже без ухода с платформы можно потерять адреса при переименовании страниц, изменении структуры или удалении старых материалов. Встроенные 301 Tilda работают для несуществующих страниц внутри одного домена, но не решают все сценарии междоменной миграции.

До редизайна нужно сохранить фактическое состояние сайта. Минимальный реестр должен содержать:

• полный URL;
• код ответа;
• canonical;
• indexability;
• Title и Description;
• H1;
• тип и роль страницы;
• основной интент;
• показы, клики и переходы;
• внешние ссылки, если известны;
• внутренние входящие ссылки;
• конверсии или участие в маршруте;
• решение по миграции;
• целевой URL;
• ответственного.

Не все страницы имеют одинаковую ценность. Приоритетными считаются URL, которые:

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

Инвентаризация не означает, что нужно сохранить весь старый сайт. Она нужна, чтобы удаление стало решением, а не побочным эффектом.

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

• URL хранит адрес и накопленные связи;
• контент отвечает на спрос и объясняет предложение;
• дизайн управляет представлением и взаимодействием.

Можно изменить шаблон, сохранив URL и основную роль страницы. Можно переработать текст, не меняя адрес. Менять всё одновременно следует только при явной архитектурной необходимости и готовом migration map.

Для каждого старого адреса выберите один статус.

Keep

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

Move 1:1

Адрес меняется, но существует ближайший эквивалентный новый URL. Настраивается постоянный серверный редирект.

Merge

Несколько старых страниц объединяются в одну более сильную. Каждая старая страница перенаправляется на новый материал только тогда, когда он действительно покрывает её смысл.

Split

Одна старая универсальная страница разделяется на несколько. Автоматического идеального правила здесь нет: нужно выбрать основной преемник и перестроить внутренние ссылки на новые специализированные страницы.

Remove

Материал больше не нужен и не имеет эквивалента. Не следует перенаправлять любой удалённый URL на главную только ради отсутствия 404. Иногда корректный 404 или 410 честнее и понятнее.

Для SEO-миграции важен настоящий HTTP-редирект на серверном уровне. JavaScript-переход или визуальный блок перенаправления может отправить пользователя на другую страницу, но не является полноценной заменой серверного 301.

Официальная справка Tilda отдельно указывает:

• встроенные 301 настраиваются в SEO-разделе и работают для старых несуществующих путей внутри домена;
• для перенаправления между разными доменами полноценный 301 требует внешнего сервера или инфраструктуры, способной вернуть нужный HTTP-ответ;
• блок T223 не является универсальным междоменным 301.

После настройки проверяйте не интерфейс панели, а фактический ответ URL внешним инструментом или командой curl -I.

Слабая схема выглядит так:

старый URL → промежуточный URL → новый URL.

Рабочая схема:

старый URL → конечный новый URL.

Цепочки увеличивают сложность диагностики и могут сохраняться годами. Также нежелательно направлять десятки тематических адресов на главную: пользователь ожидал конкретный ответ и получает общий экран.

Для каждого редиректа задайте вопрос: новый URL действительно является ближайшим смысловым продолжением старого? Если нет — нужен другой маршрут или честное удаление.

При ручной или автоматической миграции часто забываются:

• Title;
• Description;
• H1 и иерархия заголовков;
• canonical;
• Open Graph;
• structured data;
• alt и подписи изображений;
• хлебные крошки;
• FAQ;
• ссылки на связанные страницы;
• дата изменения;
• авторство;
• юридические страницы;
• verification-файлы;
• robots и sitemap.

Экспорт Tilda позволяет получить HTML, CSS, JavaScript и другие файлы, но дальнейшая работа на внешнем сервере становится ответственностью владельца. Нельзя предполагать, что все платформенные функции, формы и настройки продолжат работать без проверки.

До переключения production нужно убедиться:

• production-страницы не содержат noindex;
• canonical указывает на фактический production URL;
• staging закрыт от индексации;
• robots.txt не блокирует важные разделы;
• sitemap содержит только конечные индексируемые URL;
• старые адреса не остаются одновременно доступными с тем же содержанием;
• HTTP и HTTPS, www и non-www сведены к одной версии.

Критическая ошибка — перенести staging-policy в production: сайт физически работает, но запрещает индексацию.

Редиректы являются страховкой, а не постоянной архитектурой. После запуска внутренние ссылки должны вести сразу на конечные новые URL.

Проверьте:

• меню;
• футер;
• хлебные крошки;
• статьи;
• карточки услуг;
• CTA;
• related materials;
• ссылки внутри FAQ;
• sitemap HTML, если используется;
• ссылки из писем, презентаций и рекламных кабинетов.

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

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

• работу всех форм;
• доставку уведомлений;
• страницу или сообщение подтверждения;
• номера телефонов и мессенджеры;
• цели Метрики/GA, если используются;
• UTM;
• call tracking;
• CRM-интеграции;
• согласия и privacy;
• работу на мобильном;
• скорость ответа команды.

Тестовая отправка должна быть частью release gate, а не задачей после жалобы клиента.

Безопасная последовательность:

1. Зафиксировать старый сайт и аналитику.
2. Утвердить URL mapping.
3. Собрать новый сайт на staging.
4. Провести content, link, schema и responsive QA.
5. Подготовить redirect rules.
6. Сделать резервную копию production.
7. Переключить сайт.
8. Проверить главные URL и формы в первые часы.
9. Загрузить новый sitemap в инструменты вебмастеров.
10. Контролировать 404, редиректы, индексирование, трафик и обращения.
11. Исправлять расхождения по журналу, а не хаотично.

В первые дни:

• доступность главной и приоритетных страниц;
• HTTP-коды старых и новых URL;
• canonical;
• robots и sitemap;
• формы и цели;
• мобильную версию;
• логи ошибок;
• наличие новых URL в инструментах вебмастеров.

В следующие недели:

• изменение показов и кликов по группам страниц;
• индексацию новых URL;
• исключённые и дублирующиеся страницы;
• 404 и цепочки редиректов;
• качество обращений;
• необходимость обновить внешние ссылки и профили.

Колебания после миграции возможны. Их нельзя автоматически считать катастрофой или успехом без сравнения по группам URL и понимания внесённых изменений.

Новый сайт лежит во вложенной папке

В document root остаётся старый index.html, а новая сборка распаковывается в каталог с названием архива. В результате часть файлов присутствует, но домен продолжает обслуживать старую версию.

.htaccess переносится без проверки хостинга

Запрещённые директивы, неверный RewriteBase или циклические правила могут дать 500. Диагностика начинается с error log и временного отключения файла, а не с добавления случайных правил.

Все старые URL ведут на главную

Теряется смысловая преемственность и ухудшается путь пользователя.

Новый сайт содержит staging noindex

Это один из самых опасных дефектов: внешне всё работает, но страницы не должны попадать в поиск.

Команда меняет URL после запуска

Migration map теряет актуальность, редиректы не совпадают, а ссылки снова ведут через промежуточные адреса.

Независимая проверка особенно оправдана, если:

• сайт получает органические переходы и заявки;
• адресов больше, чем команда может проверить вручную;
• меняется домен или структура;
• одновременно обновляются тексты и позиционирование;
• нет полной аналитики;
• несколько подрядчиков отвечают за дизайн, разработку и SEO;
• уже есть старые редиректы;
• бизнес не может позволить себе выяснять ошибки после запуска.

Аудит миграции должен завершиться не общим советом «поставьте 301», а URL mapping, redirect specification, QA checklist и планом мониторинга.

Передайте:

1. текущий домен;
2. staging или прототип нового сайта;
3. список старых и новых URL, если он уже есть;
4. доступ к Search Console/Яндекс.Вебмастеру и аналитике;
5. дату предполагаемого переключения;
6. информацию о домене, CMS и хостинге;
7. список приоритетных услуг и страниц;
8. известные редиректы;
9. ответственных за внедрение;
10. ограничения по срокам и доступам.

    На этой основе можно быстро определить, нужен ли полный аудит, проверка карты или Sprint внедрения.

Google рекомендует при изменении URL использовать постоянные серверные редиректы, обновлять внутренние ссылки и sitemap, а затем контролировать перенос. Tilda подтверждает ограничения встроенных сценариев: внутри домена доступны правила 301 для несуществующих страниц, а для полноценного междоменного перенаправления требуется внешняя серверная инфраструктура.

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