Как мигрировать с Tilda на Next.js без потери позиций в Яндексе и Google

Что нужно знать до начала

Это технический материал по миграции, а не SEO-консультация под конкретный проект. Конкретные настройки сверяйте с актуальной документацией Яндекс.Вебмастера и Google Search Console — экосистема меняется чаще, чем переиздаются гайды.

Важная вводная по устаревшим советам, которые до сих пор гуляют по сети: директива Host в robots.txt отменена Яндексом ещё в марте 2018 — главное зеркало выбирается через 301-редиректы. Инструмент «Переезд сайта» в Яндекс.Вебмастере нужен только при смене домена или протокола (например, http→https), а не при миграции на том же домене. Раздел про поведенческие факторы — про сохранение реального пользовательского опыта; накрутка ПФ — это риск, а не стратегия.

Tilda отлично подходит, чтобы быстро запуститься, но в какой-то момент она упирается в потолок: ограниченная гибкость, зависимость от платформы, проблемы со скоростью и контролем над технической оптимизацией. Переход на Next.js даёт контроль, производительность и масштабируемость — но миграция пугает одним: страхом потерять позиции, на которые ушли месяцы. Хорошая новость в том, что потеря трафика при миграции — это следствие ошибок, а не самой миграции. Если сохранить то, что ценят поисковики (URL, контент, смысл, скорость и реальное поведение пользователей), переход проходит почти незаметно для выдачи. Ниже — пошаговый план, заточенный под то, что миграция должна выжить в двух системах сразу: и в Яндексе, и в Google.

01 · Аудит текущего Tilda-сайта

Миграция начинается с инвентаризации того, что у вас уже ранжируется — потому что нельзя сохранить то, что вы не зафиксировали.

Соберите полный список URL: выгрузите из Tilda, дополните данными из Яндекс.Вебмастера и Google Search Console — какие страницы реально в индексе и приносят трафик. Для каждой важной страницы зафиксируйте:

• URL;
• title;
• description;
• H1;
• ключевые запросы, по которым она ранжируется;
• трафик (Яндекс.Метрика, GA4 или эквивалент).

Отдельно снимите базовые поведенческие метрики в Яндекс.Метрике — время на сайте, глубину просмотра, показатель отказов, карту кликов. Это критично: после миграции вы будете сравнивать поведение с этой базой, а поведенческие факторы для Яндекса — сильный сигнал ранжирования. Аудит — это «снимок до», без которого вы не сможете доказать (себе и поисковику), что ничего не сломалось.

02 · Архитектурное решение: полная миграция или гибрид

Прежде чем переносить, решите что именно переносите.

Полная миграция (весь сайт на Next.js) даёт максимальный контроль и единую кодовую базу.

Гибрид (часть страниц остаётся на Tilda, новое — на Next.js под тем же доменом) снижает риск и нагрузку на старте, но усложняет инфраструктуру и маршрутизацию.

Ключевое техническое требование к Next.js-части: рендеринг должен быть серверным (SSR) или статическим (SSG), а не клиентским (CSR/SPA). Причина прямая — поисковые роботы исполняют JavaScript неидеально и с задержкой, а краулеры вне Google зачастую не исполняют его вовсе; если контент появляется только после выполнения JS в браузере, поисковик рискует увидеть пустую страницу. Tilda отдаёт готовый HTML, и ваша новая платформа должна делать то же самое — иначе вы променяете контроль на провал в индексации.

Выбирайте архитектуру осознанно, а не по умолчанию фреймворка.

03 · Перенос контента через CMS

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

Если статического контента в коде немного — он переезжает с разработкой. Если контента много и его будут редактировать не-разработчики, подключите headless-CMS (Strapi, Directus, Sanity, Contentful или собственная админка), чтобы тексты, мета-теги и медиа жили отдельно от кода и редактировались без релиза.

При переносе сохраняйте не только тексты, но и семантическую структуру:

• один H1 на страницу;
• корректная иерархия заголовков (H2, H3 без перепрыгивания уровней);
• alt у изображений;
• мета-теги title и description;
• внутренняя перелинковка между страницами.

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

04 · Сохранение URL-структуры

Это самый дешёвый способ не потерять позиции: по возможности оставьте URL точно такими же. Если адрес страницы не меняется, поисковику нечего переиндексировать и нечего «склеивать» — страница просто продолжает жить по тому же адресу на новой платформе.

Сохраните:

• регистр (uppercase / lowercase);
• завершающие слеши (/about vs /about/);
• кириллические или транслитерированные адреса ровно в том виде, в каком они в индексе.

Менять URL стоит только там, где это даёт реальную пользу (например, чистка мусорных Tilda-параметров), и каждое такое изменение должно быть осознанным, а не побочным эффектом новой системы маршрутизации.

Идеальная миграция с точки зрения URL — та, после которой карта редиректов почти пустая.

05 · Карта 301-редиректов

Для всех URL, которые всё же меняются, нужна полная карта постоянных редиректов 301 — именно 301, «постоянный», он передаёт сигналы ранжирования; не 302.

Правила, которые экономят трафик:

• каждый старый URL ведёт на наиболее релевантный новый (а не скопом на главную — это убивает позиции);
• без цепочек редиректов (старый → новый напрямую, не через промежуточные);
• без «битых» переходов на 404.

Составьте таблицу старый URL → новый URL → код ответа и проверьте её до публикации — простыми инструментами (Screaming Frog, curl-скриптом, любым crawl-инструментом).

В Яндексе именно постраничные 301-редиректы сегодня и выбирают главное зеркало при смене адреса. Директива Host в robots.txt, которую до сих пор советуют старые инструкции, отменена Яндексом ещё в марте 2018 года — использовать её не нужно, и её наличие ни на что не повлияет.

Карта редиректов — это мост между старым и новым индексом; дыры в мосте = потерянный трафик.

06 · Schema-разметка для Яндекса и Google

Миграция — хороший момент, чтобы не просто сохранить, а усилить. Структурированная разметка (Schema.org в формате JSON-LD) помогает обеим системам точнее понимать содержимое и формировать расширенные сниппеты.

Разметьте то, что релевантно вашему сайту:

• Organization — данные компании;
• BreadcrumbList — хлебные крошки;
• Product / Service — продукты или услуги;
• Article — материалы блога;
• FAQPage — частые вопросы;
• LocalBusiness — для офлайн-присутствия.

JSON-LD понимают и Google, и Яндекс (последний дополнительно использует свою микроразметку для некоторых сервисов, но JSON-LD — безопасная универсальная база). Проверьте разметку валидаторами обеих систем после публикации.

Корректная schema не поднимет вас «вместо» контента, но делает сниппет заметнее и помогает не потерять то оформление выдачи, что было.

07 · Работа в Яндекс.Вебмастере и Search Console

Сообщите поисковикам об изменениях через их же инструменты.

Подтверждение прав. Убедитесь, что сайт добавлен и подтверждён в Яндекс.Вебмастере и Google Search Console. Для нового стека проверьте, что подтверждение прав не слетело при смене платформы (HTML-файл подтверждения, мета-тег или DNS-запись).

Sitemap и переобход. Отправьте обновлённый sitemap, запросите переобход ключевых страниц, и следите за разделами индексации и ошибок.

Инструмент «Переезд сайта». Важный нюанс: инструмент «Переезд сайта» в Яндекс.Вебмастере нужен только если меняется домен или протокол (например, http→https или новый домен). При миграции Tilda→Next.js на том же домене и протоколе «переезда» в смысле Яндекса нет — достаточно 301-редиректов на изменившихся URL, sitemap и переобхода. Не запускайте «Переезд» без необходимости.

Вебмастер и Search Console — это ваши приборы: через них вы увидите проблемы раньше, чем их увидит трафик.

08 · Обновление sitemap и robots.txt

Технические файлы должны соответствовать новой реальности.

Sitemap.xml. Сгенерируйте актуальный sitemap (Next.js это умеет автоматически через app/sitemap.ts или next-sitemap), включающий только живые, индексируемые URL новой структуры. Укажите его в Вебмастере, Search Console и в robots.txt.

Robots.txt. Проверьте файл дважды:

• он не должен случайно закрывать важные разделы (классическая катастрофа миграции — Disallow: /, забытый со staging-окружения);
• должен ссылаться на актуальный sitemap;
• директиву Host добавлять не нужно — она больше не используется Яндексом.

IndexNow. Чтобы ускорить переиндексацию, подключите IndexNow — протокол, который поддерживают Яндекс и Bing: он позволяет мгновенно уведомлять поисковик об изменившихся URL, а не ждать планового обхода. Для Next.js существуют простые интеграции.

Перепроверьте эти файлы дважды: одна строка в robots.txt способна обнулить весь остальной труд по миграции.

09 · Защита поведенческих факторов

Это шаг, который недооценивают, а для Яндекса он один из решающих.

Поведенческие факторы — как реальные пользователи ведут себя на странице (время, глубина, возвраты в выдачу, отказы) — Яндекс измеряет (в том числе через Метрику и Вебвизор) и использует как сильный сигнал качества. Опасность миграции в том, что новый сайт может незаметно ухудшить реальное поведение: стал медленнее, поехала вёрстка, пользователь не находит привычную кнопку, сломалась форма — люди уходят быстрее, и поведенческие проседают вслед за ними, утягивая позиции.

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

• скорость загрузки на новой платформе не должна быть хуже Tilda (для большинства сайтов Next.js даёт быстрее, но это нужно мерить);
• ключевые конверсионные элементы (кнопки CTA, формы) должны остаться на привычных местах или работать заметно лучше;
• мобильная вёрстка не должна потерять то, что работало на Tilda «из коробки»;
• сохраните аналитику: Метрика, GA4, Вебвизор, цели — без перерыва, чтобы у вас была непрерывная серия данных.

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

10 · Постмиграционная верификация

Миграция не заканчивается публикацией — она заканчивается, когда вы убедились, что всё перенеслось чисто.

Сразу после запуска прогоните проверки:

• Core Web Vitals на реальных данных — ориентиры Google: LCP менее 2,5 с, INP менее 200 мс, CLS менее 0,1 на 75-м перцентиле полевых данных. Это сигнал для Google и просто хорошая скорость для удержания людей и ПФ.
• Работоспособность всех 301-редиректов — ни одной цепочки и ни одного 404 на месте старых URL. Прогоните crawl-инструментом, сверьте с картой из шага 5.
• Индексация новых страниц в Вебмастере и Search Console — старые уходят, новые появляются. Это процесс на дни и недели, но он должен идти.
• Валидность sitemap и schema — отдельными инструментами обеих поисковых систем.
• Аналитика и цели — Метрика и GA4 фиксируют события так же, как до миграции.

Затем — наблюдение в динамике: первые недели позиции и трафик могут слегка «дышать», пока поисковики переобходят сайт, это нормально. Тревожный сигнал — устойчивое падение в течение 2–4 недель, проседание поведенческих относительно вашей базы из шага 1 или рост ошибок индексации.

Сравнивайте с «снимком до» — именно ради этого вы его делали. Чистая миграция выглядит как ровный график с короткой паузой, а не как обрыв.

Коротко

Потерять позиции при переходе с Tilda на Next.js легко — но только если пропустить базовые шаги: не сохранить URL, забыть 301, отдать клиентский рендеринг вместо серверного, закрыть сайт в robots.txt или ухудшить реальный пользовательский опыт.

Сделайте обратное — зафиксируйте «снимок до», сохраните адреса и контент, постройте полную карту редиректов, отдавайте готовый HTML (SSR/SSG), корректно настройте Вебмастер, Search Console, sitemap и IndexNow, и сохраните то, что нравится живым пользователям — и миграция станет тем, чем должна быть: технической заменой движка под капотом, незаметной для выдачи. Вы получаете контроль и скорость Next.js, не платя за это трафиком.

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

Потеряю ли я позиции при миграции с Tilda на Next.js? Не обязательно. Потеря трафика — следствие ошибок (потерянные URL, отсутствие 301, клиентский рендеринг, закрытый robots.txt, ухудшенный UX), а не самой миграции. При сохранении URL, контента, серверного рендеринга и реального поведения пользователей переход проходит почти незаметно для выдачи.

Нужно ли использовать инструмент «Переезд сайта» в Яндекс.Вебмастере? Только если меняется домен или протокол (например, http→https). При миграции на том же домене это не «переезд» в смысле Яндекса — достаточно 301-редиректов на изменившихся URL, обновлённого sitemap и запроса на переобход.

Нужна ли директива Host в robots.txt для Яндекса? Нет. Яндекс отказался от директивы Host ещё в 2018 году; главное зеркало теперь определяется через 301-редиректы. Старые инструкции, советующие Host, устарели.

Почему важен серверный рендеринг (SSR/SSG) на Next.js? Потому что поисковые роботы исполняют JavaScript неидеально и с задержкой, а часть краулеров — вовсе нет. При серверном или статическом рендеринге поисковик получает готовый HTML сразу, как и было на Tilda. Клиентский рендеринг (SPA) рискует отдать роботу пустую страницу.

Что такое «защита поведенческих факторов» при миграции? Это сохранение реального пользовательского опыта — скорости, привычной навигации, рабочих форм и конверсионных путей — чтобы живые пользователи вели себя на новом сайте так же хорошо или лучше. Речь о подлинном поведении: накрутка ПФ детектируется Яндексом и ведёт к санкциям.

---

Это технический материал по миграции, а не SEO-консультация под конкретный проект; конкретные настройки сверяйте с актуальной документацией Яндекс.Вебмастера и Google Search Console.