Как перенести сайт на Next.js без потери SEO-позиций

TL;DR

Перенос сайта без потери позиций — это не про новый дизайн, а про сохранение каждого URL и сигнала, который Google и Яндекс уже связали с вашим доменом. Сначала вы собираете полную инвентаризацию всех адресов (из Search Console, Яндекс.Вебмастера, sitemap и логов сервера), затем строите карту 301-редиректов 1:1 со старых URL на новые, переносите без изменений метаданные, структурированные данные и тексты, проверяете всё на закрытом стейджинге, и только потом переключаете домен. После запуска вы отправляете свежий sitemap и две-три недели следите за индексацией в Search Console и Вебмастере. Главные причины уйти на Next.js — скорость и Core Web Vitals, серверный рендеринг, который понимают и поисковики, и AI-системы, и предсказуемая структура URL. Большинство провалов миграции — это не «магия Google», а забытые редиректы, потерянные canonical и выкатка без проверки.

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

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

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

Почему вообще стоит переходить на Next.js

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

Скорость и Core Web Vitals. Next.js рендерит страницы на сервере и отдаёт браузеру готовый HTML, а не тяжёлый JavaScript, который нужно сначала загрузить и выполнить. На практике это означает быстрый первый экран и хорошие показатели LCP и INP — тех самых метрик, по которым Google оценивает реальный опыт посетителя. Для казахстанской аудитории, которая заходит преимущественно с мобильных на сотовом интернете, это решающий фактор; подробный разбор механики мы давали в материале про Core Web Vitals и влияние скорости на продажи.

Готовность к AI-поиску. ChatGPT, Perplexity, Gemini и Яндекс с Алисой всё чаще отвечают пользователю напрямую, цитируя сайты. Чтобы попасть в эти ответы, контент должен быть доступен ботам в виде чистого серверного HTML, со структурированными данными и предсказуемой разметкой. Сайты на тяжёлых клиентских фреймворках, которые «дорисовывают» контент в браузере, для многих AI-краулеров остаются полупустыми. Серверный рендеринг Next.js снимает эту проблему по умолчанию.

Контроль над структурой и метаданными. На типовой CMS структура URL, теги и редиректы часто живут «как получилось» — в плагинах, шаблонах и базе данных. В Next.js маршрутизация, метаданные и редиректы описываются явно в коде, их можно версионировать в git, ревьюить и тестировать. Для SEO это означает, что ничего не «отвалится само» при следующем обновлении плагина.

Если вы только взвешиваете решение и хотите сравнить платформы по пунктам, у нас есть отдельный детальный разбор: WordPress против Next.js для бизнеса. Здесь же мы исходим из того, что решение принято, и фокусируемся на том, как переехать без потерь.

Что именно вы рискуете потерять при переносе

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

• Сами URL. Если адрес страницы меняется (/uslugi/sayt превращается в /services/website), а старый адрес начинает отдавать 404, поисковик теряет страницу, которую ранжировал, и весь её накопленный вес.
• Ссылочный вес. Внешние ссылки, упоминания в 2ГИС, каталогах и на других сайтах ведут на старые URL. Без редиректа этот вес обнуляется.
• Метаданные. Title и description, под которые страница ранжировалась, легко «потерять» при копировании контента в новые шаблоны.
• Структурированные данные. Разметка Organization, Article, FAQ, BreadcrumbList, по которой формируются расширенные сниппеты, часто просто не переносится.
• Изображения. Картинки получают новые пути, а старые URL изображений, которые приводили трафик из поиска по картинкам, отдают 404.
• Поведенческие сигналы. Резкий рост ошибок и падение скорости после неаккуратного запуска ухудшают поведенческие факторы, которые особенно важны для Яндекса.

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

Шаг 1. Полная инвентаризация URL до начала работ

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

Источники, которые нужно свести в одну таблицу:

| Источник | Что даёт | Как получить | |---|---|---| | Google Search Console | Реальные индексируемые страницы и те, что приносят клики | Отчёты «Эффективность» и «Индексирование страниц», экспорт | | Яндекс.Вебмастер | Страницы в индексе Яндекса, важно для рынка РК | Раздел «Индексирование» → «Страницы в поиске» | | Текущий sitemap.xml | Все страницы, которые сайт сам объявляет | Открыть /sitemap.xml, выгрузить список | | Лог-файлы сервера | Реальные URL, по которым ходят боты и люди | Запросить у хостинга access-логи за 1–3 месяца | | Краулер (Screaming Frog и аналоги) | Полный обход сайта по внутренним ссылкам | Просканировать домен целиком |

Сведённый список нужно дедуплицировать и разметить по приоритету: какие страницы приносят трафик и заявки (их сохраняем в первую очередь), какие технические, какие — мусорные и от них можно избавиться осознанно. Здесь же фиксируем для каждой важной страницы её текущие title, description, h1 и наличие структурированных данных — это понадобится на следующих шагах.

Отдельно выгрузите список URL изображений, которые приносят трафик из поиска по картинкам, — их тоже придётся редиректить или сохранить пути.

Шаг 2. Карта 301-редиректов один к одному

Это самый ответственный артефакт всей миграции. Карта редиректов — таблица, где для каждого старого URL указан новый, на который он должен вести.

Базовое правило: 301 (постоянный редирект), один к одному, на максимально близкую по смыслу страницу. 301 сообщает поисковику, что страница переехала навсегда, и передаёт новому адресу накопленный вес. Временный 302 для миграции не подходит — он говорит «это ненадолго», и вес не передаётся.

Чего избегать:

• Цепочек редиректов. A → B → C замедляет обход и размывает сигнал. Всегда ведите старый URL сразу на финальный новый.
• Массового редиректа на главную. Если десятки страниц ведут на /, поисковик трактует это как «мягкую 404» и не переносит вес. Каждый URL должен вести на релевантную страницу, а не на главную «лишь бы не 404».
• Потери языковых версий. Если на сайте были ru и kk версии, редиректы должны сохранять язык: русская страница ведёт на русскую, казахская — на казахскую.

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

В Next.js редиректы описываются явно в next.config.js, что делает их версионируемыми и проверяемыми:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/uslugi/razrabotka-saytov',
        destination: '/services/digital-foundation',
        permanent: true, // permanent: true = 301
      },
      {
        source: '/old-blog/:slug',
        destination: '/blog/:slug',
        permanent: true,
      },
    ]
  },
}

При большом числе URL редиректы удобнее хранить в отдельной таблице (CSV или JSON) и генерировать массив программно, а не вписывать руками каждый из сотен адресов.

Шаг 3. Перенос метаданных, контента и структурированных данных

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

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

Контент. Тексты переносятся целиком, без сокращений «под новый дизайн». Если на старом сайте страница услуги была на 1500 слов и ранжировалась по этому объёму, новая версия не должна внезапно ужаться до трёх абзацев — это прямой сигнал поисковику, что страница стала менее полезной. Сохраняем заголовки H1–H3, списки, таблицы и внутреннюю перелинковку.

Структурированные данные. Разметку schema.org переносим и валидируем. Минимум для бизнес-сайта в РК:

• Organization — название, логотип, контакты, профили в соцсетях;
• BreadcrumbList — хлебные крошки на всех вложенных страницах;
• Article — для статей блога;
• Service — для страниц услуг;
• FAQPage — для блоков вопросов и ответов.

Важная деталь, которую часто путают: расширенные FAQ-сниппеты Google свернул для большинства сайтов ещё в 2023 году, поэтому FAQ-разметку сегодня стоит держать прежде всего ради корректного машинного понимания контента и попадания в AI-ответы, а не ради звёздочек в выдаче. И не добавляйте в schema фейковый aggregateRating — это нарушение, за которое можно получить ручную санкцию.

Изображения. Сохраняем alt-тексты, по возможности — пути к файлам. Если пути меняются, для трафиковых изображений тоже нужны 301-редиректы.

Canonical. Каждая страница нового сайта должна указывать абсолютный canonical на саму себя (https://вашдомен.kz/...). Это защищает от дублей, которые легко плодятся при миграции — например, версии с www и без, со слешем на конце и без.

Шаг 4. Сборка и проверка на закрытом стейджинге

Новый сайт собирается и тестируется на отдельном адресе (стейджинге), полностью закрытом от индексации, пока вы не убедитесь, что всё на месте. Это критично: если черновую версию случайно проиндексируют, вы получите дубли контента и кашу в выдаче.

Закрываем стейджинг от роботов на уровне всего сайта:

# robots.txt на стейджинге
User-agent: *
Disallow: /

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

Чек-лист проверки до переключения домена:

• [ ] Все URL из инвентаризации либо сохранены, либо имеют рабочий 301-редирект (проверяем выборочно и автоматически по списку).
• [ ] Нет цепочек редиректов и нет редиректов на 404.
• [ ] Title, description и H1 на месте и совпадают с задуманными.
• [ ] Структурированные данные валидны (проверка через Schema Markup Validator и Rich Results Test).
• [ ] Sitemap.xml генерируется и содержит только финальные, индексируемые URL.
• [ ] Canonical на каждой странице абсолютный и указывает на себя.
• [ ] Core Web Vitals на ключевых шаблонах в зелёной зоне.
• [ ] Формы, заявки, интеграции (Kaspi, 1С, CRM, n8n-вебхуки) работают.
• [ ] Версии ru и kk отдаются корректно, языковые редиректы сохранены.
• [ ] На боевом стейджинге Disallow: / будет заменён на боевой robots.txt — проверьте, что в продакшене сайт открыт для индексации.

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

Шаг 5. Переключение и действия в первые часы

Переключение домена на новый сайт лучше планировать на период наименьшего трафика — для большинства бизнесов в РК это ночь или раннее утро буднего дня. Сразу после переключения:

1. Проверьте боевой robots.txt — он должен разрешать индексацию и содержать ссылку на актуальный sitemap.
2. Прогоните карту редиректов на боевом домене — выборочно откройте десяток ключевых старых URL и убедитесь, что они отдают 301 на правильные новые адреса, а не 404 и не 302.
3. Проверьте HTTPS и единственный канонический хост — весь трафик должен сходиться на одну версию (например, без www, с https), а остальные варианты 301-редиректить на неё.
4. Убедитесь, что аналитика и счётчики на месте — Google Analytics, Яндекс.Метрика, пиксели; иначе вы ослепнете именно в тот момент, когда нужнее всего видеть данные.

Для казахстанского сайта особенно важны два момента. Первый — Яндекс по-прежнему даёт ощутимую долю трафика, поэтому Яндекс.Вебмастер и Метрику нельзя оставлять «на потом». Второй — если на сайте есть формы сбора данных, перенос не должен сломать соответствие Закону РК о персональных данных: согласие на обработку, политика конфиденциальности и корректная передача данных должны остаться на месте после переезда.

Шаг 6. Отправка sitemap и мониторинг после запуска

Миграция не заканчивается в момент переключения — самый информативный период наступает в следующие две-три недели, когда поисковики переобходят сайт.

Сразу после запуска:

• Отправьте новый sitemap.xml в Google Search Console и Яндекс.Вебмастер.
• Запросите переобход ключевых страниц через инструмент проверки URL в Search Console.
• Используйте IndexNow для Яндекса — отправьте изменённые и новые URL, чтобы ускорить переиндексацию (отправлять стоит именно изменённые адреса, а не весь сайт целиком на каждый деплой).
• Оставьте старый sitemap доступным какое-то время, чтобы поисковик быстрее увидел старые URL и их 301-редиректы.

Что отслеживать в первые недели:

| Сигнал | Где смотреть | Норма | |---|---|---| | Ошибки 404 | Search Console → Индексирование | Близко к нулю, всплеск — забытые редиректы | | Покрытие индекса | Search Console, Вебмастер | Постепенный переход старых URL на новые | | Позиции по ключам | Search Console → Эффективность | Возможна короткая просадка с восстановлением | | Клики и показы | Search Console, Метрика | Без обвала; колебания в пределах 1–2 недель нормальны | | Core Web Vitals | Search Console → Основные веб-показатели | Улучшение относительно старого сайта |

Небольшая турбулентность позиций в первые дни после миграции — нормальное явление: поисковик пересматривает сайт. Тревожный признак — это не колебания, а устойчивое падение на фоне роста ошибок 404 и пропажи страниц из индекса. В этом случае первое, что нужно проверить, — карту редиректов и robots.txt.

Типичные ошибки, которые обрушивают трафик

Почти все провалы миграций — это не «невезение с алгоритмом», а конкретные операционные просчёты. Самые частые:

• Забытые редиректы. Перенесли главное, а блог, старые посадочные и страницы услуг с прошлой структурой оставили на 404. Это прямая потеря трафика.
• Запуск с Disallow: /. Стейджинговый robots.txt уехал в продакшен. Сайт исчезает из выдачи целиком.
• Редирект всего на главную. Поисковик трактует это как soft-404 и не передаёт вес.
• Цепочки и циклы редиректов. Замедляют обход, размывают сигнал, иногда зацикливаются.
• Потеря метаданных и контента. Под предлогом редизайна страницы «похудели», title переписали — и причины просадки уже не отделить от самой миграции.
• Дубли из-за canonical. Версии с www/без, со слешем/без, http/https плодят дубли, между которыми размывается вес.
• Выкатка без стейджинга. «Переключим и по ходу поправим» — самый дорогой подход: ошибки чинятся уже на боевом трафике, на глазах у поисковика.
• Игнор Яндекса. Для рынка РК это половина задачи — настройка только под Google оставляет часть аудитории без присмотра.

Хорошая новость: каждая из этих ошибок предотвратима на этапе подготовки. Именно поэтому инвентаризация, карта редиректов и стейджинг — не бюрократия, а страховка, которая на порядок дешевле восстановления потерянного трафика.

Часто задаваемые вопросы

Сколько времени занимает восстановление позиций после переноса сайта?

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

Обязательно ли менять URL при переходе на Next.js?

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

Нужны ли отдельные действия для Яндекса, а не только для Google?

Да, для казахстанского рынка это обязательно. Яндекс даёт существенную долю трафика, поэтому Яндекс.Вебмастер и Яндекс.Метрику нужно настраивать наравне с инструментами Google: добавить новый sitemap, проверить индексацию, отправить изменённые URL через IndexNow. Яндекс чувствителен к поведенческим факторам, так что прирост скорости после переезда на Next.js работает в вашу пользу именно здесь.

Можно ли одновременно с переездом обновить дизайн и тексты?

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

Что делать со старыми ссылками из 2ГИС, соцсетей и каталогов?

Эти ссылки ведут на старые URL и приносят и трафик, и ссылочный вес, поэтому 301-редиректы должны покрывать в том числе их. Дополнительно стоит обновить адрес сайта в карточках 2ГИС, Google Бизнес-профиле и основных каталогах на актуальный — это убирает лишний редирект и поддерживает консистентность данных о компании, что важно и для локального SEO, и для распознавания вашей организации AI-системами.

Как понять, что миграция прошла без потерь?

Через две-три недели после запуска сверьте в Search Console и Яндекс.Вебмастере: ошибки 404 близки к нулю, старые URL заменились новыми в индексе, клики и показы держатся на прежнем уровне без устойчивого обвала, а Core Web Vitals улучшились. Если все эти сигналы в норме — миграция прошла чисто. Всплеск 404 или пропажа страниц из индекса означает забытые редиректы, которые нужно срочно достроить.

Перенос сайта на современный стек — это шанс одновременно ускорить сайт, подготовить его к AI-поиску и не потерять ничего из накопленного. Но безопасной такую операцию делает не платформа сама по себе, а дисциплина: инвентаризация, карта редиректов, стейджинг и мониторинг. В Shipmint мы проводим миграции на Next.js именно по этой методике — с полной картой 301-редиректов, сохранением метаданных и schema, проверкой на закрытом стейджинге и сопровождением в Search Console и Вебмастере после запуска. Лендинг от 350 000 ₸, корпоративный сайт от 720 000 ₸, интернет-магазин или тендерный портал от 1 200 000 ₸. Если вы планируете переезд и не хотите рисковать позициями — напишите нам, разберём вашу структуру URL и составим план миграции под ваш проект.

Следующий шаг

Ваш сайт теряет лиды прямо сейчас