Индексация Next.js в Google: полное руководство для App Router и Pages Router
Разберитесь с SSG, SSR, ISR и клиентскими компонентами, чтобы каждый маршрут был обнаружен Google
В этой инструкции
Next.js — самый популярный React-фреймворк для продакшен-приложений, а его модель рендеринга, охватывающая SSG, SSR, ISR и клиентский рендеринг, создаёт одновременно мощные возможности и тонкие ловушки для индексации. Одни маршруты отдают идеальный HTML с первого запроса; другие — пустой каркас, требующий исполнения JavaScript.
Это руководство охватывает и App Router, и Pages Router, проходя через Metadata API, generateStaticParams, программную генерацию карт сайта через sitemap.ts, настройку robots.ts, структурированные данные и конкретные ловушки, из-за которых страницы Next.js кажутся Googlebot пустыми.
Стратегии рендеринга и их влияние на индексацию
Next.js предлагает четыре стратегии рендеринга, и у каждой свои последствия для того, как (и увидит ли вообще) Googlebot Ваш контент.
Статическая генерация (SSG) — золотой стандарт для индексации. Страницы рендерятся в полноценный HTML на этапе сборки и отдаются как статические файлы. Googlebot сразу получает готовый HTML — исполнение JavaScript не требуется. В App Router любой Server Component, не вызывающий динамические функции (например, cookies(), headers() или searchParams), по умолчанию рендерится статически. В Pages Router SSG достигается экспортом getStaticProps.
Серверный рендеринг (SSR) генерирует HTML на каждый запрос. Googlebot получает полноценный HTML так же, как и при SSG, но страница не кешируется (если Вы не добавили заголовки кеширования). SSR в App Router включается использованием динамических функций или установкой export const dynamic = «force-dynamic» на сегменте маршрута. В Pages Router Вы используете getServerSideProps. SSR надёжен для индексации, но медленнее SSG, поскольку каждый запрос на сканирование запускает полный рендер.
Инкрементальная статическая регенерация (ISR) — гибрид: страница статически генерируется при сборке, отдаётся из кеша и регенерируется в фоне после настраиваемого интервала времени. В App Router ISR достигается установкой export const revalidate = 3600 (в секундах) на странице или layout. В Pages Router Вы добавляете revalidate в возвращаемое значение getStaticProps. ISR отлично подходит для индексации — Googlebot получает быстрый статический HTML, а контент остаётся достаточно свежим.
Клиентский рендеринг (CSR) — там, где возникают проблемы с индексацией. Если компонент помечен «use client» и получает данные в useEffect, начальный HTML, отправляемый браузеру (и Googlebot), содержит только состояние загрузки. Хотя Googlebot до некоторой степени умеет исполнять JavaScript, он обрабатывает его на вторичном проходе индексации, который может произойти спустя часы или дни, — и сложная клиентская выборка данных часто молча падает в среде рендеринга Google.
Правило: любой контент, который Вы хотите проиндексировать, должен присутствовать в начальном HTML, отрендеренном на сервере, а не подгружаться через клиентский JavaScript после гидрации.
Metadata API: generateMetadata и статическая метаинформация
App Router ввёл мощный Metadata API, который заменяет старый компонент <Head> из Pages Router. Есть два способа задать метаинформацию: статический экспорт и динамическая функция generateMetadata.
Для статической метаинформации экспортируйте объект metadata из любого файла page.tsx или layout.tsx. Это хорошо работает для страниц с известной фиксированной метаинформацией.
Для динамических маршрутов, где метаинформация зависит от данных (например, slug записи блога), используйте generateMetadata. Эта асинхронная функция получает параметры маршрута и может запрашивать данные для динамического построения метаинформации.
Важный момент: generateMetadata выполняется на сервере, поэтому всегда срабатывает для запросов Googlebot. Если же Вы задаёте метаинформацию в компоненте «use client» через document.title или сторонний head-менеджер, Googlebot может не подхватить её при начальном разборе HTML. Всегда задавайте метаинформацию через серверный Metadata API.
Metadata API поддерживает весь спектр мета-тегов:
titleиdescriptionopenGraphиtwitterдля шеринга в соцсетяхrobotsдля управления индексациейalternatesдля hreflang и canonical URLverificationдля Google Search Consoleiconsдля фавиконок
Для canonical-URL используйте поле alternates.canonical. Для страниц с языковыми версиями заполните alternates.languages отображением кодов локалей на URL.
В Pages Router метаинформация обрабатывается импортом Head из «next/head» и размещением мета-тегов внутри него в Вашем компоненте. Это по-прежнему работает, но имеет ограничения: содержимое Head обрабатывается только после рендеринга React, а сложные вложенные компоненты Head могут привести к дублированию тегов. Если Вы начинаете новый проект, используйте Metadata API из App Router.
Генерация sitemap через sitemap.ts и sitemap.xml
App Router в Next.js поддерживает программную генерацию sitemap через специальный файл sitemap.ts (или sitemap.xml/route.ts), размещённый в директории app. Самый простой подход — создать app/sitemap.ts, который экспортирует функцию по умолчанию, возвращающую массив записей sitemap.
Это автоматически генерирует /sitemap.xml. Функция выполняется во время запроса в режиме разработки и при сборке в продакшене (для статических экспортов) или при каждом запросе (для динамического рендеринга).
Для крупных сайтов с более чем 50 000 URL используйте паттерн sitemap index. Создайте app/sitemap.ts, возвращающий sitemap-индекс, указывающий на несколько подкарт, затем создайте отдельные route-обработчики для каждой подкарты (например, app/sitemaps/[id]/route.ts). Спецификация Google для sitemap допускает до 50 000 URL в одном файле sitemap и до 500 файлов sitemap в индексе.
Главная ошибка, которую допускают разработчики, — забыть включить динамические маршруты в sitemap. Если у Вашего приложения есть маршрут вроде /blog/[slug], функция sitemap должна обращаться к базе данных или CMS, чтобы получить каждый валидный slug и сгенерировать URL для каждого. Просто перечислить /blog/[slug] в sitemap бессмысленно — Google нужны реальные разрешённые URL.
В Pages Router встроенной генерации sitemap нет. У Вас два варианта:
- Использовать npm-пакет
next-sitemap(генерирует sitemap при сборке, читая директорию pages и выводgetStaticPaths) - Создать кастомный API-маршрут
pages/api/sitemap.ts, который динамически генерирует XML
Пакет next-sitemap — самый распространённый выбор, поддерживающий серверные карты сайта, генерацию robotsTxt и разбиение sitemap на несколько файлов.
Динамические маршруты: generateStaticParams и поведение fallback
Динамические маршруты (app/blog/[slug]/page.tsx) — самый частый источник пробелов в индексации в приложениях Next.js. Без правильной настройки динамические маршруты могут не быть предварительно отрендерены при сборке, и тогда Googlebot при первом посещении встречает либо 404, либо состояние загрузки.
В App Router экспортируйте функцию generateStaticParams из Вашей динамической страницы, чтобы предварительно отрендерить конкретные пути при сборке. Каждый slug, возвращаемый этой функцией, становится статически сгенерированной страницей.
А что насчёт slug-ов, которых нет в generateStaticParams? Это контролируется экспортом dynamicParams:
- `dynamicParams = true` (по умолчанию) — Next.js пытается серверно отрендерить несовпавшие slug-и по запросу и закешировать результат
- `dynamicParams = false` — несовпавшие slug-и возвращают 404
Для SEO значение по умолчанию (true) обычно корректно, потому что позволяет рендерить только что опубликованный контент без полной пересборки.
В Pages Router эквивалент — getStaticPaths с параметром fallback:
- `fallback: false` — возвращает 404 для неизвестных путей
- `fallback: true` — рендерит страницу загрузки при первом запросе (Googlebot видит состояние загрузки, что ужасно для индексации)
- `fallback: «blocking»` — блокирует ответ, пока страница полностью не отрендерится, и затем кеширует её
Для SEO всегда используйте `fallback: «blocking»` в Pages Router.
Взаимодействие generateStaticParams и ISR важно. Если Вы задаёте revalidate на динамической странице, предварительно отрендеренные страницы регенерируются в фоне после периода ревалидации. Новые slug-и, отсутствующие в generateStaticParams, рендерятся при первом запросе (если dynamicParams равно true) и затем кешируются через ISR. Это сочетание даёт лучшее из двух миров: быструю статическую отдачу для известных страниц и рендеринг по запросу для нового контента.
robots.ts, правила noindex и контроль сканирования
App Router поддерживает файл robots.ts по пути app/robots.ts, программно генерирующий /robots.txt.
Ключевые специфичные для Next.js соображения по robots.txt:
- Всегда блокируйте маршруты
/api/(они возвращают JSON, а не HTML) - Блокируйте
/_next/data/(JSON-данные для клиентской навигации, которые не должны индексироваться как отдельные страницы) - Блокируйте любые маршруты дашборда с авторизацией
- НЕ блокируйте
/_next/static/— там лежат CSS и JS-файлы, которые Googlebot нужны для корректного рендеринга Ваших страниц
Для noindex на уровне страницы используйте поле robots в Metadata API. Установите robots: { index: false } в экспорте метаинформации любой страницы, которую Вы хотите исключить из результатов поиска. Это уместно для:
- Страниц аутентификации (
/login,/register) - Пользовательских дашбордов
- Документации API за авторизацией
- Любых страниц с персонализированным контентом
Middleware (middleware.ts в корне проекта) также может влиять на индексацию. Если Ваш middleware выполняет редиректы для аутентификации или определения локали, убедитесь, что Googlebot не попадает в циклы редиректов.
Распространённый безопасный паттерн — middleware, перенаправляющий неавторизованных пользователей с /dashboard на /login. Это нормально, потому что Вы и так хотите видеть /dashboard с noindex. Но middleware, перенаправляющий на основе геолокации, может ловить Googlebot (сканирующий с американских IP) в ловушку постоянной американской версии, не давая индексировать другие локали.
Протестируйте поведение middleware с помощью инструмента «Проверка URL» в Google Search Console, чтобы увидеть, что именно встречает Googlebot.
Структурированные данные и Open Graph для расширенных результатов поиска
Структурированные данные (JSON-LD) критически важны для получения расширенных результатов в Google: звёздные рейтинги, FAQ-аккордеоны, хлебные крошки, даты публикации статей и многое другое. В App Router самый чистый подход — создать серверный компонент JsonLd, который рендерит тег <script type=«application/ld+json»>.
Этот компонент должен принимать типизированные пропсы, соответствующие типам Schema.org (Article, FAQPage, Product, BreadcrumbList, Organization), и сериализовать их в тег скрипта. Поскольку это серверный компонент, JSON-LD присутствует в начальном HTML, который получает Googlebot, — клиентское исполнение не требуется.
Для Open Graph тегов используйте поле openGraph в экспорте Metadata API. Включите:
og:titleиog:descriptionog:image(с размерами)og:url,og:typeиog:locale
Для Twitter Cards используйте поле twitter. Эти теги должны присутствовать в <head> HTML, чем автоматически занимается Metadata API.
Распространённая ошибка в приложениях Next.js — генерация структурированных данных на клиенте. Если Вы используете компонент «use client» для получения отзывов о товаре и затем генерируете JSON-LD с агрегированным рейтингом, начальный разбор HTML Googlebot может не включить структурированные данные. Всегда генерируйте структурированные данные в серверных компонентах или в `generateMetadata`. Инструмент Google Rich Results Test позволяет тестировать конкретные URL, чтобы убедиться, что Ваши структурированные данные видны краулерам.
Структурированные данные «хлебных крошек» особенно ценны для приложений Next.js со вложенными маршрутами. Если структура Вашего приложения — /blog/category/post-slug, сгенерируйте схему BreadcrumbList с элементами для Главной, Блога, страницы категории и текущего поста. Это даёт Google явную информацию о навигационной иерархии и может привести к показу хлебных крошек в результатах поиска вместо «сырого» URL.
Пошаговое руководство
Проведите аудит стратегии рендеринга по каждому маршруту
Проверьте next.config.ts на глобальные настройки вывода. Просмотрите каждый page.tsx и классифицируйте: динамические функции = SSR, экспорт revalidate = ISR, generateStaticParams = предварительно отрендеренный, «use client» с получением данных в useEffect = CSR (риск для индексации). Составьте таблицу с каждым маршрутом, его стратегией и признаком наличия критического контента в начальном HTML.
Внедрите Metadata API на каждом маршруте
Для каждого page.tsx и layout.tsx в App Router добавьте либо статический экспорт metadata, либо функцию generateMetadata. Как минимум, каждой странице нужны уникальные title и description.
- Для корневого layout (
app/layout.tsx) задайте метаинформацию по умолчанию через полеtitle.template(например,title: { template: «%s | YourApp», default: «YourApp» }) - Для динамических маршрутов вроде
/blog/[slug]реализуйтеgenerateMetadata, которая получает контент и возвращает метаинформацию, специфичную для страницы - Добавьте
alternates.canonicalна каждую страницу, чтобы явно задать canonical-URL - Если Ваше приложение поддерживает несколько языков, заполните
alternates.languages
Не задавайте метаинформацию в компонентах «use client» — всегда используйте серверные экспорты metadata.
Создайте sitemap.ts и robots.ts
Создайте app/sitemap.ts, экспортирующий асинхронную функцию по умолчанию, возвращающую массив записей sitemap. Обратитесь к базе данных или CMS за всем динамическим контентом (записи блога, страницы товаров, страницы категорий) и сгенерируйте полный URL для каждого.
Задайте значения приоритета:
- 1.0 для главной страницы
- 0.8–0.9 для ключевых посадочных страниц
- 0.5–0.7 для обычного контента
Для каждой записи укажите дату lastModified.
Создайте app/robots.ts, возвращающий правила, блокирующие /api/, /_next/data/, /admin/ и любые маршруты с авторизацией, разрешая при этом всё остальное и указывая URL Вашего sitemap.
Задеплойте и убедитесь, что /sitemap.xml возвращает валидный XML, а /robots.txt — валидные директивы, открыв их в браузере.
Предварительно рендерите динамические маршруты с generateStaticParams
Экспортируйте generateStaticParams из каждого динамического маршрута, чтобы предварительно отрендерить валидные пути при сборке. Сочетайте с dynamicParams: true и revalidate, чтобы новый контент рендерился серверно при первом запросе и кешировался через ISR. В Pages Router используйте fallback: «blocking» вместо fallback: true, чтобы не отдавать Googlebot состояния загрузки.
Вынесите критический контент из клиентских компонентов
Просмотрите каждый компонент «use client», который отображает контент, который Вы хотите проиндексировать. Если компонент получает данные через useEffect, useSWR или React Query и рендерит их на клиенте, Googlebot может не увидеть этот контент.
Паттерн рефакторинга: перенесите получение данных в родительский серверный компонент и передавайте данные как пропсы в клиентский компонент. Клиентский компонент по-прежнему может обрабатывать интерактивность (обработчики кликов, состояние), но начальный контент должен присутствовать в HTML, отрендеренном на сервере.
Тест: отключите JavaScript в браузере и загрузите каждую страницу. То, что Вы видите без JavaScript, примерно соответствует тому, что Googlebot видит при начальном разборе HTML.
Добавьте структурированные данные для расширенных результатов
Создайте переиспользуемый серверный компонент для структурированных данных JSON-LD. Добавьте подходящие типы схем:
- Записи блога — схема
Articleсheadline,author,datePublished,dateModifiedиimage - Страницы товаров — схема
Productсname,description,priceиaggregateRating - Все вложенные страницы — схема
BreadcrumbListдля иерархии навигации - Главная страница — схема
Organization
Проверьте каждую реализацию структурированных данных с помощью Google Rich Results Test, введя свои действующие URL. Исправьте все ошибки и предупреждения, прежде чем двигаться дальше.
Помните: все структурированные данные должны быть в серверных компонентах, чтобы они появлялись в начальном HTML.
Отправьте критические URL через IndexBolt и отслеживайте результат
Отправьте через IndexBolt главную страницу, ключевые посадочные страницы и приоритетный контент. Для нового приложения 20–50 URL ускоряют понимание Google на несколько дней. Отслеживайте в инструменте «Проверка URL» Search Console — убедитесь, что выборка страницы показывает полный HTML, а не состояния загрузки. Расследуйте любые маршруты со статусом «Обнаружена, не проиндексирована» на предмет проблем с рендерингом.
Частые проблемы и способы их решения
Страницы показывают пустой контент или спиннеры загрузки Googlebot
Причина: Контент получается внутри компонента «use client» через useEffect или клиентскую библиотеку выборки данных. Начальный HTML, отрендеренный на сервере, содержит только состояние загрузки (спиннер, скелетон или пустой div). Начальный разбор HTML Googlebot не видит контента, а его вторичный проход рендеринга JavaScript может упасть из-за аутентификации API, проблем с CORS или таймаута рендеринга.
Решение: Перенесите получение данных в серверные компоненты или используйте generateStaticParams со статической генерацией. Передавайте данные как пропсы в клиентские компоненты, которым нужна интерактивность. Для Pages Router используйте getStaticProps или getServerSideProps вместо клиентской выборки. Проверьте, просмотрев исходный код страницы (не отрендеренный DOM в DevTools): исходник должен содержать фактический текст контента.
Динамические маршруты возвращают 404 для страниц, отсутствующих в generateStaticParams
Причина: У динамического маршрута установлено export const dynamicParams = false, что означает, что любой slug, не возвращённый из generateStaticParams, выдаёт 404. В Pages Router getStaticPaths с fallback: false ведёт себя так же. Только что опубликованный контент, отсутствовавший на момент сборки, недоступен.
Решение: Установите dynamicParams в true (по умолчанию) и добавьте период revalidate, чтобы вновь сгенерированные страницы кешировались через ISR. В Pages Router переключитесь с fallback: false на fallback: «blocking». Затем убедитесь, что Ваш sitemap.ts динамически запрашивает весь актуальный контент, чтобы новые страницы появлялись в sitemap, даже если они не были предварительно отрендерены при сборке.
Sitemap не включает динамически сгенерированные страницы
Причина: Файл sitemap.ts был написан со статическим списком URL и не запрашивает базу данных или CMS для динамического контента. Либо sitemap генерировался при сборке через next-sitemap, но сборка не была перезапущена после публикации нового контента. Новые записи блога, страницы товаров или категорий отсутствуют в sitemap.
Решение: Перепишите sitemap.ts так, чтобы он динамически запрашивал Ваш источник контента (базу данных, headless CMS API или файловую систему) при каждом запросе. Для сайтов на ISR установите revalidate на маршруте sitemap, чтобы он периодически регенерировался. Если используете next-sitemap в Pages Router, настройте серверную генерацию sitemap или настройте cron-задание, запускающее пересборку при изменении контента.
Редиректы middleware мешают Googlebot получить доступ к локализованным страницам
Причина: Middleware для определения локали читает заголовок Accept-Language или использует геолокацию по IP, чтобы перенаправлять посетителей на путь конкретной локали (например, /en-us/, /fr/). Googlebot преимущественно сканирует с американских IP с английскими заголовками, поэтому его всегда перенаправляет на американскую английскую версию. Страницы для других локалей никогда не сканируются и не индексируются.
Решение: Не перенаправляйте Googlebot на основе геолокации или Accept-Language. Вместо этого отдавайте контент локали по умолчанию и полагайтесь на hreflang-теги (заданные через alternates.languages в Metadata API), чтобы сообщать Google о вариантах локалей. В Вашем middleware Вы можете проверять User-Agent на Googlebot и пропускать редиректы локали для него, а лучше — использовать hreflang как основной сигнал локали и применять редиректы middleware только как удобство для реальных пользователей.
Файлы loading.tsx показывают плейсхолдеры, попадающие в индекс
Причина: App Router в Next.js использует loading.tsx, чтобы показывать мгновенный UI загрузки через React Suspense, пока страница рендерится. Если страница использует SSR (динамический рендеринг), начальный запрос Googlebot может получить содержимое loading.tsx вместо фактической страницы. Это особенно вероятно для страниц с медленной выборкой данных.
Решение: Для страниц с критическим SEO-контентом предпочитайте статическую генерацию или ISR динамическому рендерингу. Если динамический рендеринг необходим, обеспечьте быструю (менее 5 секунд) выборку данных, чтобы потоковый ответ доставлял фактический контент до таймаута Googlebot. Подумайте о переносе тяжёлой выборки данных в клиентские компоненты, дополняющие страницу после того, как критический серверный контент уже присутствует.
Компонент Image в Next.js генерирует URL, забивающие бюджет сканирования
Причина: Компонент Image в Next.js оптимизирует изображения через пути /_next/image?url=…&w=…&q=…. Каждая комбинация ширины и качества генерирует уникальный URL. Если эти URL не заблокированы в robots.txt, Googlebot может тратить бюджет сканирования на эндпоинты оптимизации изображений вместо фактического контента страниц.
Решение: Добавьте Disallow: /_next/image в Ваш файл robots.ts, чтобы Googlebot не сканировал URL оптимизации изображений напрямую. Фактические изображения, на которые ссылаются теги <img> Ваших страниц, по-прежнему будут обнаруживаемы и индексируемы через HTML страниц. Это значительно экономит бюджет сканирования на сайтах с обилием изображений.
Советы профи
Задеплоили новое приложение Next.js или добавили динамические маршруты? У Google могут уйти недели на обнаружение страниц, рендерящихся по запросу. Используйте IndexBolt, чтобы протолкнуть свежесобранные страницы прямо в очередь индексации Google — особенно критично для SSR- и ISR-маршрутов, не имеющих сборочного URL-следа.
100 бесплатных кредитов. Без банковской карты. Результаты менее чем за 24 часа.
Часто задаваемые вопросы
Исполняет ли Googlebot JavaScript в приложениях Next.js?+
Да, у Googlebot есть движок рендеринга JavaScript на основе свежей версии Chromium. Однако рендеринг JavaScript происходит на вторичном проходе индексации, который может случиться спустя часы или даже дни после первоначального сканирования HTML. Это означает, что контент, появляющийся только после исполнения JavaScript, индексируется с задержкой — а сложная клиентская выборка данных (особенно к API с авторизацией) может полностью падать в среде рендеринга Google. Для надёжной индексации обеспечьте, чтобы весь критический контент присутствовал в HTML, отрендеренном на сервере, через серверные компоненты, getStaticProps или getServerSideProps.
Что лучше для SEO — App Router или Pages Router?+
У App Router превосходные инструменты SEO, включая встроенный Metadata API, sitemap.ts, robots.ts и серверные компоненты, рендерящие контент на сервере по умолчанию. Pages Router нормально работает для SEO, но требует больше ручной работы: нужен компонент next/head для метаинформации, сторонние пакеты вроде next-sitemap для sitemap, а также getStaticProps/getServerSideProps для серверного рендеринга. Для новых проектов App Router — очевидный выбор. Для существующих проектов на Pages Router нет срочной необходимости мигрировать — сосредоточьтесь на том, чтобы у Вас были правильные getStaticProps/getServerSideProps и работающий sitemap.
Как ISR влияет на индексацию в Google?+
Инкрементальная статическая регенерация отлично подходит для индексации. Googlebot мгновенно получает статически закешированный HTML (быстрое время ответа повышает эффективность сканирования), а контент регенерируется в фоне, оставаясь свежим. Единственный момент — период ревалидации: если Вы установили revalidate в 3600 (один час), изменения контента могут отображаться в кешированной странице до часа. Для контента, чувствительного ко времени, используйте более короткий период ревалидации или запускайте ревалидацию по запросу через вебхуки. С точки зрения Google, страницы на ISR ведут себя идентично статическим — они быстрые, полностью отрендеренные и надёжные.
Мои страницы Next.js показаны как «Обнаружена, не проиндексирована» в Search Console. Почему?+
Этот статус означает, что Google нашёл URL (через Ваш sitemap или внутренние ссылки), но ещё не отрендерил и не проиндексировал его. Для приложений Next.js это часто происходит, когда: (1) страница использует клиентский рендеринг, и начальное сканирование HTML Googlebot не нашло контента, поэтому он понизил приоритет страницы; (2) у страницы тонкий контент, который Google считает малоценным; (3) Ваш сайт новый, и Google ещё не выделил достаточно бюджета сканирования; или (4) у страницы canonical-тег, указывающий в другое место. Используйте инструмент «Проверка URL», чтобы получить страницу как Googlebot, и изучите отрендеренный HTML. Если он пустой или показывает состояние загрузки, у Вас проблема с рендерингом, которую нужно исправить.
Как обрабатывать canonical URL в Next.js для страниц с параметрами запроса?+
В Metadata API App Router установите alternates: { canonical: «https://yourdomain.com/page» } без параметров запроса. Это сообщает Google, что базовый URL — каноническая версия, независимо от любых трекинговых параметров, пагинации или параметров фильтра, добавленных к нему. Для страниц, где параметры запроса создают значимо разный контент (например, постраничные результаты поиска), либо генерируйте уникальные canonical URL для каждой страницы (alternates: { canonical: «https://yourdomain.com/search?page=2» }), либо используйте единственный canonical, указывающий на страницу 1, и полагайтесь на внутренние ссылки, чтобы Google обнаруживал последующие страницы.
Можно ли использовать IndexBolt с Next.js, чтобы ускорить индексацию новых страниц?+
Безусловно. IndexBolt особенно ценен для приложений Next.js, потому что многие сайты на Next.js используют ISR или рендеринг по запросу — а значит, у новых страниц нет статических URL, которые Google обнаружил бы через традиционное сканирование. После публикации нового контента используйте API или дашборд IndexBolt, чтобы отправить URL прямо в конвейер индексации Google. Это особенно эффективно для страниц товаров в e-commerce, генерируемых по запросу, для новых записей блога в headless CMS или для посадочных страниц, задеплоенных в рамках запуска фичи. Обычный режим подходит для рутинного контента; используйте мгновенный режим для запусков продуктов или страниц, чувствительных ко времени.