Технічне SEO для Next.js: метадані, sitemap, hreflang і структуровані дані

Next.js з коробки дає серверний рендеринг, статичну генерацію і Metadata API, що прибирає класичні SEO-проблеми односторінкових застосунків. Але SEO за вас він не налаштовує. Дублікати URL, відсутній hreflang, sitemap з вигаданими датами і структуровані дані, що суперечать сторінці, досі трапляються на більшості сайтів на Next.js, які ми аудитуємо. У гайді — налаштування, яке ми використовуємо на багатомовних проєктах на App Router, узгоджене з тим, що, за документацією Google, вона справді використовує, а що ігнорує.

Почніть з того, що Google вважає важливим

Технічне SEO робить якісний контент знаходжуваним, але не замінює його. Рекомендації Google зосереджені на корисному, надійному контенті, створеному для людей (Google: корисний контент). Її політики щодо спаму прямо спрямовані проти масового створення контенту (scaled content abuse) — генерації великої кількості сторінок, з AI чи без, передусім для маніпуляції ранжуванням, а не для допомоги користувачам (Google: політики щодо спаму). Використовувати AI як помічника в написанні — нормально; публікувати некорисний контент у масштабі — ні (Google: про контент, створений AI).

Усе, що нижче, виходить з того, що сторінки варті індексації.

1. Рендеріть контент на сервері

Google вміє рендерити JavaScript, але рендеринг відкладений і обмежений ресурсами (Google: основи JavaScript SEO). В App Router тримайте контент для індексації — заголовки, текст, посилання — у Server Components, щоб він був у початковому HTML. Для навігації використовуйте справжні посилання <a href> (їх рендерить next/link); посилання, що існують лише як обробники кліків, краулер не бачить (Google: посилання, доступні для сканування).

2. Title, description і canonical

Використовуйте Metadata API: статичний експорт metadata для фіксованих сторінок, generateMetadata — для динамічних (Next.js: generateMetadata).

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }: PageProps<"/blog/[slug]">): Promise<Metadata> {
  const { slug } = await params
  const post = getPost(slug)
  if (!post) return {}
  const url = `https://example.com/blog/${slug}`
  return {
    title: post.title,                       // унікальний, описовий, ~50–60 символів
    description: post.description,           // справжній підсумок, ~140–160 символів
    alternates: {
      canonical: url,
      languages: {
        "en-US": url,
        "uk-UA": `https://example.com/ua/blog/${slug}`,
        "x-default": url,
      },
    },
    openGraph: {
      type: "article", url, title: post.title, description: post.description,
      publishedTime: post.date, modifiedTime: post.updated ?? post.date,
    },
  }
}

Рекомендації з документації Google:

• Title мають бути унікальними й описовими; Google може переписати розмиті, перенасичені ключовими словами чи однакові на різних сторінках заголовки (Google: title links).
• Meta description не є фактором ранжування, але часто стає сніпетом; пишіть конкретний підсумок для кожної сторінки (Google: сніпети).
• Canonical підказує Google, який із кількох дублікатів URL індексувати, — слеш у кінці, query-параметри, коди відстеження (Google: консолідація дублікатів URL).

3. hreflang для багатомовних сайтів

Якщо ви публікуєте ту саму статтю кількома мовами, повідомте Google, які версії пов'язані. Кожна мовна версія має перелічувати всі версії, включно із собою, анотації мають бути взаємними, а x-default — вказувати на резервну версію (Google: локалізовані версії). Next.js рендерить alternates.languages як теги <link rel="alternate" hreflang="...">.

Дві типові помилки:

• Посилання на переклад, якого не існує. Генеруйте alternates з наявного контенту, а не зі списку підтримуваних мов.
• Canonical на іншу мову. Кожна мовна версія canonical сама на себе; зв'язок між ними забезпечує hreflang.

4. Sitemap з чесними датами

Генеруйте sitemap з контенту через app/sitemap.ts (Next.js: sitemap). Що використовує Google:

• Google ігнорує priority і changefreq.
• Google використовує lastmod, якщо він стабільно й перевірювано точний, тобто це дата останньої суттєвої зміни основного контенту, структурованих даних чи посилань (Google: створення sitemap).

Тож не ставте всім сторінкам lastModified на час білду. Зберігайте для кожної статті дату updated і використовуйте її:

// app/sitemap.ts
export default function sitemap(): MetadataRoute.Sitemap {
  return getAllPosts().map((post) => ({
    url: `https://example.com/blog/${post.slug}`,
    lastModified: new Date(post.updated || post.date),   // лише реальні зміни контенту
    alternates: { languages: hreflangFor(post.slug) },
  }))
}

Доповніть це файлом app/robots.ts, що посилається на sitemap і не блокує CSS чи JavaScript (Next.js: robots).

5. Структуровані дані, що відповідають сторінці

JSON-LD допомагає Google зрозуміти сторінку; у Next.js його рендерять у тезі <script type="application/ld+json"> з компонента сторінки (Next.js: JSON-LD). Для статей Google рекомендує headline, image, datePublished, dateModified і author з іменем і бажано URL (Google: структуровані дані Article).

const jsonLd = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  description: post.description,
  inLanguage: "uk-UA",
  datePublished: post.date,
  dateModified: post.updated ?? post.date,
  author: { "@type": "Person", name: post.author },
  image: [`https://example.com/og/${post.slug}.png`],
  mainEntityOfPage: `https://example.com/ua/blog/${post.slug}`,
}

Що варто знати у 2026 році:

• Розширені результати FAQ показуються лише для відомих авторитетних урядових і медичних сайтів, а розширені результати HowTo скасували у 2023 році (Google: зміни для HowTo і FAQ). Розділи FAQ досі корисні як контент для читачів, просто не очікуйте, що розмітка FAQ змінить вигляд сторінки у видачі.
• Дати мають бути видимими й узгодженими. Показуйте на самій сторінці дату публікації і, коли доречно, дату оновлення, а структуровані дані мають їм відповідати (Google: дати публікації).
• Хлібні крихти через BreadcrumbList допомагають Google зрозуміти ієрархію сайту.

6. Внутрішня перелінковка

Внутрішні посилання — це спосіб, яким краулери знаходять сторінки, а Google розуміє, які сторінки пов'язані й важливі. Для блогу:

• Посилайтеся з кожної статті на дві-п'ять справді пов'язаних статей у контексті, з описовим текстом посилання, а не «натисніть тут».
• Показуйте блок схожих статей, підібраних за темою, а не просто останні публікації.
• Давайте заголовкам стабільні атрибути id, щоб інші сторінки могли посилатися на конкретні розділи.
• Тримайте важливі сторінки в кількох кліках від головної й уникайте сторінок-сиріт, на які ніщо не посилається.

7. Продуктивність і доступність

Досвід на сторінці теж важливий. Core Web Vitals використовуються системами ранжування Google; про виправлення INP, LCP і CLS — у статті Core Web Vitals у 2026 році. Доступна розмітка — семантичні заголовки, alt-тексти, підписані форми — допомагає і людям, і машинам читати сторінки, а в ЄС дедалі частіше є юридичною вимогою, див. Вебдоступність у 2026 році.

Чек-лист технічного SEO для Next.js

• Контент для індексації рендериться на сервері; навігація через справжні посилання
• Унікальні title і description для кожної сторінки
• Canonical на саму себе на кожній сторінці
• hreflang генерується лише для наявних перекладів, взаємний, з x-default
• Sitemap з контенту з точним lastModified, без вигаданих дат білду
• robots.txt посилається на sitemap і не блокує ресурси
• JSON-LD для статей і хлібних крихт, узгоджений з видимим контентом
• Видимі дати публікації та оновлення
• Схожі статті за темою і контекстні внутрішні посилання
• Core Web Vitals моніторяться за польовими даними
• Search Console підтверджено, sitemap надіслано, покриття переглядається щомісяця

Перехід на Next.js 16 змінює кілька API, важливих тут, як-от async params у функціях метаданих; див. Next.js 16 у продакшені.

FAQ

Чи потрібна окрема SEO-бібліотека з App Router? Ні. Вбудованих Metadata API, sitemap.ts і robots.ts вистачає більшості сайтів.

Чи потрібна кожній статті розмітка FAQ? Для більшості сайтів вона не дасть розширених результатів FAQ. Залишайте FAQ-контент, якщо він корисний читачам; розмітка опційна.

Як часто має оновлюватися sitemap? Щоразу, коли контент суттєво змінюється. Генерація з контенту під час білду чи запиту автоматично тримає його точним.

Чи шкодить SEO контент, написаний з AI? Google оцінює корисність, а не авторство. Точний, оригінальний і корисний контент — це нормально; масово створені сторінки без цінності порушують політики щодо спаму.

Джерела

1. Google Search Central. Creating helpful, reliable, people-first content і Spam policies.
2. Google Search Central. Build and submit a sitemap.
3. Google Search Central. Tell Google about localized versions of your page.
4. Google Search Central. Article structured data і Changes to HowTo and FAQ rich results.
5. Google Search Central. JavaScript SEO basics, Consolidate duplicate URLs.
6. Next.js. generateMetadata, sitemap, robots, JSON-LD.