Технічне SEO, яке кожен розробник має шипити за замовчуванням (і яке більшість пропускає)

Більшість розробників ставляться до SEO як до проблеми маркетингу. Це не так. Технічне SEO — це проблема коду, і більша частина шкоди відбувається, коли розробники шиплять без нього.

Я проаудитував 15+ Next.js-проєктів. У кожному без винятку було мінімум 5 з цих 12 проблем. Кожен фікс займає менше 30 хвилин. Разом вони — різниця між «Google не може проіндексувати половину ваших сторінок» і «ваш сайт працює як очікується».

Чекліст

1. Canonical URL на кожній сторінці

Без канонічного тегу Google бачить https://site.com/page, https://site.com/page/ та https://site.com/page?ref=twitter як три окремі сторінки з дублюючимся контентом.

// app/[locale]/layout.tsx
export async function generateMetadata({ params }: Props) {
  const { locale } = await params
  return {
    alternates: {
      canonical: `https://dimaver6.com/${locale}`,
    },
  }
}

Кожна сторінка. Без винятків.

2. hreflang для мультимовних сайтів

Якщо у вас кілька мов, Google має знати, яка сторінка є еквівалентом кожною мовою. Без hreflang Google може показати російську сторінку англомовним користувачам.

alternates: {
  languages: {
    en: `/en/${slug}`,
    ru: `/ru/${slug}`,
    uk: `/uk/${slug}`,
  },
}

Я написав повний гайд по i18n-роутингу та SEO-патернах включаючи hreflang та x-default.

3. Сайтмап з точним lastmod

Сайтмап каже Google «ось усі мої сторінки». Але сайтмап з неправильними lastmod датами гірше, ніж відсутність сайтмапу — він привчає Google ігнорувати ваші сигнали свіжості.

// app/sitemap.ts — НЕПРАВИЛЬНО
lastModified: new Date(), // кожен білд = «все змінилось»

// app/sitemap.ts — ПРАВИЛЬНО
lastModified: post.date, // реальна дата зміни контенту

Ставте lastmod на реальну дату, коли контент був осмислено змінений. Не дату білду. Не new Date().

4. robots.txt, що не блокує сам себе

Я бачив Next.js-проєкти, де robots.txt випадково блокував сайтмап, API-роути або директорію _next/static.

// app/robots.ts
export default function robots() {
  return {
    rules: { userAgent: '*', allow: '/' },
    sitemap: 'https://dimaver6.com/sitemap.xml',
  }
}

Після деплою перевірте: curl https://yoursite.com/robots.txt. Переконайтесь, що дозволений / і вказаний правильний URL сайтмапу.

5. Meta-тайтли до 60 символів

Google обрізає тайтли довші за ~60 символів. Тайтл, що читається як «How Much Does a Custom SaaS MVP Cost in 2026? A Real Breakdow...» втрачає свою силу.

Ставте ключове слово ближче до початку. Бренд у кінці (якщо взагалі).

6. Meta-описи, що збігаються з пошуковим інтентом

Google використовує meta description як сніпет у пошуковій видачі. Якщо ваш дженерік — Google перепише його (погано). Якщо конкретний — Google покаже ваш, і ви контролюєте клік.

Включіть основне ключове слово, конкретну деталь та причину клікнути. До 155 символів.

7. Структуровані дані (JSON-LD)

Структуровані дані дають Google явну інформацію про тип вашого контенту. Для блог-постів — схема Article. Для послуг — Service. Для бізнесу — LocalBusiness або ProfessionalService.

<script
  type="application/ld+json"
  dangerouslySetInnerHTML={{
    __html: JSON.stringify({
      '@context': 'https://schema.org',
      '@type': 'Article',
      headline: post.title,
      datePublished: post.date,
      author: {
        '@type': 'Person',
        name: 'Dmitry Vereschagin',
      },
    }),
  }}
/>

Структуровані дані не впливають на ранжування безпосередньо, але вмикають розширені сніпети (рейтинги, дати, FAQ), що драматично покращують CTR.

8. Alt-текст і розміри зображень

Кожному <Image> потрібні три речі:

alt-текст, що описує зображення (не «image1.png»)
Атрибути width та height (запобігають зсуву макету)
Сучасний формат (WebP або AVIF через оптимізацію Next.js Image)

Відсутність alt-тексту означає, що Google Image Search не може індексувати ваші зображення. Відсутність розмірів означає CLS, що є фактором ранжування.

9. Внутрішня перелінковка між пов'язаним контентом

Google знаходить сторінки, переходячи за посиланнями. Якщо на сторінку немає жодного внутрішнього посилання, Google може її ніколи не знайти — навіть якщо вона в сайтмапі.

Кожен блог-пост має посилатися мінімум на 2 пов'язаних пости. Кожна сторінка послуг — на релевантні кейси. Кожен кейс — назад на сторінку послуг.

10. Швидкість сторінки (Core Web Vitals)

Google використовує Core Web Vitals як фактор ранжування. Три метрики:

LCP (Largest Contentful Paint): до 2.5с
FID/INP (Interaction to Next Paint): до 200мс
CLS (Cumulative Layout Shift): до 0.1

Я писав про досягнення Lighthouse 98 — більша частина роботи в усуненні ресурсів, що блокують рендер, і правильному розмірі зображень.

11. 404-сторінки, що повертають 404-статус

Часта помилка в Next.js: кастомні 404-сторінки, що повертають статус 200. Google індексує їх як реальні сторінки, створюючи «м'які 404» в Search Console.

Перевірте HTTP-статус: curl -I https://yoursite.com/nonexistent-page. Має повернути 404, не 200.

12. HTTPS-редирект і www-канонізація

Якщо і http://, і https:// резолвляться, або і www., і без www. резолвляться, Google бачить дублюючийся контент. Налаштуйте один канонічний домен і 301-редирект усіх варіацій на нього.

Більшість хостингів (Vercel, Cloudflare) обробляють це автоматично. Перевірте: curl -I http://yoursite.com має повернути 301 → https://yoursite.com.

30-хвилинний аудит

Запустіть ці 4 команди, щоб знайти більшість проблем:

curl -s https://yoursite.com/robots.txt — перевірте коректність
curl -s https://yoursite.com/sitemap.xml | head -50 — перевірте, що сторінки перераховані з правильними датами
Chrome DevTools → Lighthouse → SEO-аудит
Google Search Console → Перевірка URL → протестуйте найважливіші сторінки

Більшість проблем — це конфігурація, не код. Виправте їх один раз, переконайтесь, що вони переживають деплої, і рухайтесь далі.

Хочете технічний SEO-аудит вашого Next.js-сайту? Напишіть — я проганяю цей чекліст на кожному клієнтському проєкті і зазвичай знаходжу 5+ швидких перемог.