Next.js удобен для разработки, но его гибкость часто оборачивается техническими SEO-проблемами: робот видит не то, что видит пользователь, или получает сигналы, которые сбивают его с толку. По наблюдениям за несколькими сайтами на Next.js, чаще всего повторяются четыре ошибки: полная копия сайта на www, ответ 200 вместо 404 на несуществующих адресах, теги title и canonical не в том месте, где их ждёт робот, и лишние параметры в URL. Ниже — как каждую из них обнаружить и исправить без переписывания проекта с нуля.

Дубли на www и зеркала домена

Если сайт открывается и по адресу с www, и без него, а содержимое идентично, поисковик получает два одинаковых сайта. Робот тратит краулинговый бюджет на обход копий, а вес страниц распределяется между зеркалами. В Next.js это обычно следствие того, что редирект настроен на уровне хостинга или CDN не полностью: например, обрабатывается только главная, а внутренние страницы отдают 200 на обоих вариантах.

  • Проверьте оба варианта домена через curl или инструменты проверки редиректов: код ответа должен быть 301 на один канонический хост.
  • Настройте редирект на уровне платформы (Vercel, сервер, CDN), а не в клиентском коде — робот не выполняет JavaScript-редиректы так же надёжно.
  • Убедитесь, что sitemap и внутренние ссылки ведут только на канонический хост.

Типичная ошибка — оставить редирект только в middleware для определённых путей и забыть про статические файлы и API-роуты, которые тоже попадают в индекс.

Мягкие 404: код 200 вместо 404

Next.js по умолчанию отдаёт страницу 404 с кодом ответа 404, но при использовании fallback, catch-all роутов или клиентского роутинга легко получить «мягкую» 404: пользователь видит заглушку, а робот — код 200 и пустую или шаблонную страницу. Такие адреса накапливаются в индексе как малоценные.

  • Проверьте ответы на несуществующие адреса через curl -I: код должен быть 404, а не 200.
  • Для динамических страниц используйте notFound() в серверных компонентах, чтобы код ответа формировался на сервере.
  • Не полагайтесь на клиентские редиректы на страницу ошибки — робот может не дождаться их выполнения.

Отдельно проверьте пагинацию и фильтры: пустые результаты фильтра не должны отдавать 200 с текстом «ничего не найдено», если эти адреса не нужны в индексе.

Title и canonical не там, где их ждёт робот

В Next.js метаданные можно задавать через metadata API, head-компоненты или вручную в шаблоне. Проблема возникает, когда title и canonical формируются на клиенте или подставляются после гидратации: робот видит один заголовок, а пользователь — другой. Особенно часто это касается динамических страниц, где canonical должен указывать на самодостаточный URL без параметров.

  • Проверьте исходный HTML (View Source), а не DOM в DevTools: title и canonical должны присутствовать в первичном ответе сервера.
  • Используйте серверные метаданные для динамических роутов, чтобы canonical строился из параметров пути, а не из query-строки.
  • Следите, чтобы canonical не вёл на страницу, которая сама закрыта в robots.txt или отдаёт редирект.

Частая ошибка — ставить canonical на всех страницах пагинации на первую страницу. Это склеивает разные наборы контента и мешает индексации глубоких страниц.

Лишние параметры в адресах

UTM-метки, параметры сортировки и фильтров создают множество URL с одинаковым содержимым. Если такие адреса отдают 200 и попадают в sitemap или внутренние ссылки, робот обходит дубли и тратит бюджет. В Next.js это усугубляется тем, что клиентские переходы могут добавлять параметры без перезагрузки страницы.

  • Закройте служебные параметры в robots.txt или настройте canonical на «чистый» URL.
  • Не включайте адреса с параметрами в sitemap.
  • Проверьте, что фильтры и сортировки не создают ссылки, которые робот обходит бесконечно.

Пример: страница каталога с параметрами ?sort=price&page=2 и ?page=2&sort=price — для робота это два разных адреса с одинаковым содержимым. Приводите параметры к единому порядку или используйте canonical.

Что делать в первую очередь

Начните с проверки ответов сервера: коды 301 для зеркал, 404 для несуществующих страниц, наличие title и canonical в первичном HTML. Затем проверьте sitemap и внутренние ссылки на наличие параметров и дублей. Эти шаги не требуют переписывания проекта и закрывают большинство причин, по которым страницы не попадают в индекс. Дальше — мониторинг отчётов в Яндекс.Вебмастере и Google Search Console: они покажут, какие адреса исключены и почему.