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

> Перенос сайта без потери позиций: инвентаризация URL, карта 301-редиректов 1:1, сохранение метаданных и schema, стейджинг и мониторинг Search Console после.

Source: https://shipmint.kz/blog/perenos-sayta-na-nextjs-bez-poteri-seo-poziciy
Published: 2026-06-15
Category: Веб-разработка

---


## 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 и влияние скорости на продажи](/blog/core-web-vitals-skorost-sayta-prodazhi-2026).

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

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

Если вы только взвешиваете решение и хотите сравнить платформы по пунктам, у нас есть отдельный детальный разбор: [WordPress против Next.js для бизнеса](/compare/wordpress-vs-nextjs-dlya-biznesa). Здесь же мы исходим из того, что решение принято, и фокусируемся на том, как переехать без потерь.

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

Поисковые позиции — это не свойство домена, а сумма сигналов, привязанных к конкретным 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`, что делает их версионируемыми и проверяемыми:

```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](/services/digital-foundation) мы проводим миграции на Next.js именно по этой методике — с полной картой 301-редиректов, сохранением метаданных и schema, проверкой на закрытом стейджинге и сопровождением в Search Console и Вебмастере после запуска. Лендинг от 350 000 ₸, корпоративный сайт от 720 000 ₸, интернет-магазин или тендерный портал от 1 200 000 ₸. Если вы планируете переезд и не хотите рисковать позициями — [напишите нам](/contact), разберём вашу структуру URL и составим план миграции под ваш проект.


---

## Related

- [Blog](https://shipmint.kz/blog)
- [Contact](https://shipmint.kz/contact)