Каталог переехал на новые адреса, но посетители продолжают открывать старые ссылки из поиска, закладок и внешних публикаций. Без маршрута к подходящей новой странице они получают ошибку или попадают на главную, где заново ищут товар. Чтобы исправить переход, сначала установите соответствие старых и новых страниц, затем настройте и проверьте перенаправления.
Разберём собственный учебный магазин на Next.js 15 с App Router. Его красная кружка раньше находилась по /products/red-cup, теперь — по /catalog/red-mug. Это вымышленные адреса для примера, а не опубликованный кейс переезда. Для другого каталога придётся составить свою карту и проверить, что новые страницы действительно заменяют старые.
До кода составьте карту старых адресов
Возьмите URL старой sitemap, экспорт товаров и известные входные страницы из аналитики. Добавьте адреса, на которые ещё ссылаются меню, статьи и партнёры. Для каждой строки укажите новую цель и причину соответствия. Если возможно, сопоставляйте записи по стабильному ID товара, а не только по похожему названию.
В нашем примере получаются разные решения:
| Старый адрес | Решение | Почему |
|---|---|---|
/products/red-cup | /catalog/red-mug | Та же карточка, изменился slug |
/products/blue-cup | /catalog/blue-cup | Та же карточка, изменился раздел |
/products/discontinued-kit | Проверка удаления | Прямой замены пока нет |
Последняя строка не должна автоматически вести на главную. Если товар исчез и равноценной замены нет, нужна согласованная обработка отсутствующей страницы. Если карточка остаётся полезной как информация о снятом товаре, можно сохранить её содержимое. Решение зависит от продукта; редирект не создаёт полезную замену сам по себе.
Отдельно проверьте старые категории. Категория «Кружки» и одна карточка красной кружки решают разные задачи, поэтому объединение таких страниц требует объяснения. До автоматизации убедитесь, что выбранная цель соответствует прежнему содержанию и ожиданию посетителя.
Настройте постоянное перенаправление на сервере
Для окончательного переноса подходит постоянный серверный редирект. Google описывает 301 и 308 как сигналы постоянного перемещения. Это не обещание сохранить каждую позицию: поиску всё равно нужно обработать новые страницы и другие сигналы сайта.
В Next.js 15 правила можно задать в next.config.ts. Собственный учебный пример использует точные соответствия, без общего правила для неизвестных товаров:
import type { NextConfig } from 'next'
const nextConfig: NextConfig = {
async redirects() {
return [
{
source: '/products/red-cup',
destination: '/catalog/red-mug',
permanent: true,
},
{
source: '/products/blue-cup',
destination: '/catalog/blue-cup',
permanent: true,
},
]
},
}
export default nextConfigЕсли файл уже существует, добавьте функцию к существующей конфигурации, сохранив другие настройки. Затем пересоберите приложение и запустите production-версию. Правило в локальном файле ещё не означает, что сервер с предыдущим релизом начал его применять.
По документации redirects для Next.js 15 permanent: true использует статус 308, а false — 307. Эти статусы сохраняют метод запроса. Проверяйте обычную загрузку страницы методом GET; случайный POST на этот адрес не становится GET только из-за перенаправления.
Правила Next проверяются до разрешения файловых маршрутов, но перед приложением может стоять собственный proxy или CDN. Если публичный ответ отличается от локального, выясните, какой слой обработал старый URL первым.
Решите, какие параметры нужно сохранить
Старый адрес может выглядеть как /products/red-cup?utm_source=partner. Параметры важны для аналитики, а иногда определяют сам товар: например, /product?id=42. Это разные случаи, и одним правилом замены папки их нельзя надёжно обработать.
При обычном перенаправлении Next.js передаёт параметры исходного запроса дальше, как описано в документации. Наш пример не удаляет маркетинговые метки и не преобразует id в slug. Проверяйте полный Location, включая query string, прежде чем считать поведение правильным.
Если идентификатор хранится в query, нужна отдельная карта ID и точное правило её обработки. Не берите next, returnUrl или произвольный параметр посетителя как адрес назначения. Цели переноса должны поступать из проверенной конфигурации, иначе вместо миграции можно получить открытое перенаправление на чужие сайты.
Для нашего магазина ожидаемый переход с меткой сохраняет выбранный товар. При этом canonical новой карточки может указывать на чистый основной адрес. Настройка canonical и редирект — разные действия; первая не перемещает посетителя. Типичная ошибка с доменом рассмотрена в статье о metadataBase и canonical.
Зафиксируйте требование к параметрам в карте миграции: какие сохраняются, какие определяют содержимое и какие не должны влиять на выбор цели. Не объявляйте все URL с параметрами дублями без проверки смысла этих параметров.
Шаблон используйте только при устойчивом соответствии
Когда меняется лишь префикс, а все slug сохраняются, можно рассмотреть правило с параметром пути. Но учебный red-cup изменился в red-mug, поэтому механическая подстановка отправит его на неверный адрес. Для таких исключений нужна точная карта.
Сначала проверьте десяток разных строк: короткий slug, старую категорию, адрес с вложенными сегментами, URL с кодированными символами и известное исключение. Если новая цель вычисляется неоднозначно, оставьте явные соответствия. Для большого каталога карту можно подготовить из экспорта данных, но проверку назначения нужно выполнить до сборки конфигурации.
Расположите исключения так, чтобы более широкое правило их не перехватывало. Проверьте также действующие редиректы нормализации домена, HTTPS и завершающего слеша: вместе они способны создать лишнюю цепочку или цикл. Оценивать нужно весь публичный маршрут запроса, а не только одну функцию Next.
Не разрешайте шаблону объявлять любое случайное значение существующей карточкой. Для неизвестного старого адреса без записи в карте должно оставаться заранее согласованное поведение ошибки. Это отдельный отрицательный сценарий приёмки.
Проверяйте весь переход, а не только первый статус
В production-сборке выполните GET старого URL без автоматического следования, чтобы увидеть первый ответ. Затем повторите запрос со следованием и сохраните все заголовки. Например, для согласованного тестового окружения:
curl -sS -D old-headers.txt -o old-body.html \
'https://staging.example.ru/products/red-cup?utm_source=test'
curl -sS -L --max-redirs 5 -D chain-headers.txt -o final-page.html \
'https://staging.example.ru/products/red-cup?utm_source=test'В первом файле проверьте 308 и точный Location. Во втором — отсутствие циклов, окончательный адрес и результат загрузки карточки. Лимит пяти переходов служит предохранителем теста, а не рекомендацией строить цепочку такой длины. По возможности старый адрес должен сразу вести на конечную релевантную страницу.
Полученный 200 ещё не доказывает успех: откройте итоговую страницу и сравните товар, заголовок и canonical. Главная страница с 200 вместо карточки не проходит проверку. Сохраните результаты для метки, обычного URL, исключения и неизвестного товара.
После публичного выпуска повторите те же запросы через рабочий домен. Учитывайте кэш браузера и CDN: постоянные перенаправления могут сохраняться. Затем проверьте новые страницы через технический аудит, отдельно отмечая, какие адреса вошли в проверку.
Обновите ссылки и сформулируйте приёмку
Перенаправление помогает старым входящим ссылкам, но внутренние ссылки уже должны вести на новые URL. Обновите каталог, меню, рекомендации товаров и статьи. В sitemap оставьте согласованные основные страницы; проверьте, что canonical новых страниц указывает на согласованные адреса, а не на старый раздел или домен.
Задача разработчику включает утверждённую карту, правила для параметров, список исключений и контрольные запросы. Приёмка: старые известные адреса ведут на соответствующие конечные карточки, методы и параметры обрабатываются по контракту, циклов нет, неизвестные адреса не отправляются на случайный товар, публичный релиз повторяет проверенную конфигурацию.
Сохраните карту и результаты проверки рядом с задачей миграции. После обхода смотрите ошибки и выбор страниц в панелях вебмастеров. Если трафик изменился, сопоставьте периоды, ассортимент и новые страницы, прежде чем объяснять всё одним редиректом.
Примеры рассчитаны на настройки Next.js 15. При отдельном сервере, CDN-правилах или другом роутере сначала выясните место исполнения перенаправлений: дублирующие правила в нескольких слоях особенно трудно проверять после следующих обновлений.