Nuxt для маркетингового сайту: SEO, швидкість, мультимовність.

Nuxt розробка для маркетингового сайту виправдана, коли вам потрібні швидкі сторінки з повним HTML для пошуковиків, чіткий контроль над SEO і можливість додати інтерактив (калькулятор, форму, кабінет) без переписування сайту. Для сайту з п'яти статичних сторінок і редактором, що «просто хоче щось поправити», простіше інструменти не вигадаєш. Нижче розбираємо, що саме дає Nuxt, як це налаштувати, і де він зайвий.

Ми самі робимо власний сайт Tochno на Nuxt із генерацією статичних сторінок, тому розповідаємо про налаштування, з якими стикаємося щодня. Конкретні версії й імена модулів змінюються, тому перед впровадженням звіряйте з документацією.

Чому маркетинговому сайту важливий SSG або SSR

Класичний SPA на Vue чи React віддає порожній <div id="app">, а контент малює JavaScript у браузері. Google вміє виконувати JS, але робить це у другій хвилі індексації, із затримкою і не завжди бездоганно. Інші пошукові системи і сервіси попереднього перегляду посилань (месенджери, соцмережі) JS не виконують зовсім.

Для маркетингового сайту це неприйнятно: його головна мета, щоб його знаходили й коректно показували в пошуку та в соцмережах. Тому потрібен HTML із повним текстом уже у відповіді сервера. Nuxt дає це з коробки в кількох режимах:

Гібрид у Nuxt налаштовується декларативно:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/**': { prerender: true },       // marketing pages: static HTML
    '/api/**': { prerender: false },  // API stays dynamic
    '/kabinet/**': { ssr: false },    // private area: SPA, no SEO needed
  },
})

Для сайту, що змінюється раз на тиждень, SSG майже завжди найкращий вибір: сторінки віддаються з CDN чи звичайного nginx без обчислень, а відповідь миттєва.

SEO в Nuxt: що налаштувати, а що вже є

Мета-теги і канонічні адреси

Nuxt має вбудований useSeoMeta і useHead. Усе, що ми описуємо в компоненті сторінки, потрапляє в готовий HTML:

useSeoMeta({
  title: 'Розробка сайтів на Nuxt під ключ',
  description: 'Лендінги й корпоративні сайти: дизайн, розробка, SEO.',
  ogTitle: 'Розробка сайтів на Nuxt під ключ',
  ogImage: '/og/rozrobka-saitiv.png',
})

Правила, які ми дотримуємо: унікальний title до 60 символів і description до 155 для кожної сторінки, один h1, канонічна адреса в єдиному форматі (без кінцевого слеша, або навпаки, але завжди однаково). Дублі й розбіжності в канонічних адресах це одна з найчастіших причин «дивних» проблем в Search Console.

Sitemap, robots, структуровані дані

Для sitemap і robots є готові модулі (@nuxtjs/sitemap, @nuxtjs/robots), для schema.org окремі модулі чи власний composable, що додає JSON-LD. Для маркетингового сайту ми зазвичай додаємо:

• Organization і WebSite на всі сторінки;
• BreadcrumbList на внутрішні сторінки;
• Service або Product на сторінки послуг;
• FAQPage там, де на сторінці справді є блок питань;
• BlogPosting із автором для статей.

Важливо, щоб розмітка відповідала видимому контенту. Розмітка питань, яких на сторінці немає, порушує правила пошукових систем і шкодить більше, ніж допомагає.

Внутрішні посилання та хлібні крихти

Nuxt-компонент NuxtLink рендерить звичайний <a href>, тому пошукові системи бачать посилання. Простіше помилитися з кнопками, що навігують через router.push без реальної адреси: такі переходи для краулера невидимі. Усі індексовані переходи мають бути реальними посиланнями.

Перевірка перед релізом

Після білда корисно мати автоматичну перевірку: чи є в кожного HTML унікальний title і description, один h1, канонічна адреса, чи немає битих внутрішніх посилань. Ми робимо це скриптом, який запускається в CI, і блокуємо реліз при порушеннях. Це дешевше, ніж шукати дублі в Search Console за місяць після запуску.

Швидкість: на чому виграє Nuxt, і де можна програти

Nuxt не робить сайт швидким автоматично. Він дає інструменти, а результат залежить від того, як ними користуватися.

Зображення

Модуль @nuxt/image перетворює картинки у сучасні формати (WebP, AVIF), підбирає розміри під екран і додає loading="lazy". Два правила, що дають найбільше:

1. Зображення першого екрана (LCP-елемент) не лінивити, а навпаки, пріоритезувати (fetchpriority="high").
2. Завжди вказувати width і height, щоб не було стрибків верстки (CLS). Про метрики докладно в статті Core Web Vitals для власника магазину.

Шрифти

Шрифти найчастіше псують і LCP, і CLS. У Nuxt модуль @nuxt/fonts завантажує шрифти зі сторонніх сервісів під час білда і віддає їх зі свого домену, підставляє запасні метрики для зменшення стрибків і додає preload. Вигода очевидна: менше запитів на сторонні домени й жодного блокуючого CSS від Google Fonts. Порада: обирайте не більше двох-трьох накреслень і підмножини (subsets) лише для потрібних мов.

Розмір JavaScript

Тут Nuxt програє «чистому» HTML. Навіть статична сторінка підвантажує Vue, роутер і ядро Nuxt, щоб гідратувати сторінку. Орієнтир: ядро з'їдає десятки кілобайт стисненого JS ще до вашого коду. Що ми робимо, щоб тримати бюджет:

• ліниво гідратуємо важкі інтерактивні блоки (калькулятор, форма, cookie-банер) через hydrate-on-visible та hydrate-on-idle;
• підключаємо важкі бібліотеки (наприклад, валідацію форм) лише в момент потреби, динамічним імпортом;
• не тягнемо UI-кіт цілком, а беремо лише компоненти, що використовуємо;
• відстежуємо розмір бандлу в CI, щоб регресії були видно одразу.

Чесно: якщо вашому сайту треба один екран тексту й форма, ванільний HTML або Astro дадуть менший JS. Nuxt виграє, коли на сайті багато компонентів, інтерактиву й спільної логіки.

Кешування і CDN

Для SSG достатньо віддавати статичні файли з довгим Cache-Control для хешованих ресурсів (/_nuxt/*) і коротким для HTML. Це можна зробити на nginx, Vercel чи Cloudflare. Окремо перевірте, щоб стиснення (gzip або brotli) було ввімкнене: різниця в розмірі передачі помітна.

Потрібен сайт, який швидко відкривається і приводить заявки? Робимо лендінги й корпоративні сайти на Nuxt: дизайн, розробка, SEO-основа та перевірка швидкості перед запуском. Розробка сайтів на Nuxt під ключ, від 25 000 грн.

Мультимовність без дублів і плутанини

Для двомовного сайту (українська й англійська) важливо три речі: структура адрес, hreflang і переклади.

Структура адрес

Найпрактичніша схема для українського ринку: основна мова без префікса, інші з префіксом. Тобто /posluhy для української й /en/services для англійської. У модулях Nuxt-i18n це режим prefix_except_default. Слаги української версії транслітеруємо латиницею за офіційною транслітерацією, англійської робимо англійською. Так адреси читабельні й корисні для пошуку.

hreflang і canonical

Кожна мовна версія посилається на всі інші та на себе (hreflang), а канонічна адреса вказує на саму сторінку. Додається x-default на основну мову. Важливий нюанс: якщо англійська версія ще не готова, не публікуйте порожніх сторінок і не віддавайте hreflang на неіснуючі адреси. Краще мова, вимкнена прапорцем, поки контент не готовий.

Переклади й контент

Нестатичні тексти (кнопки, навігація, мітки форм) зручно тримати в JSON-файлах локалей. Контент сторінок і статей краще віддати в окремі Markdown- або YAML-файли за мовами, щоб редактор міг змінювати текст без правки компонентів. Тоді додавання нової мови зводиться до додавання файлів, а не до змін у шаблонах.

Типові помилки в мультимовності:

• автоматичний редирект за мовою браузера, який заважає краулеру бачити всі версії (краще пропонувати перемикач, а не примусово перенаправляти);
• переклад лише тексту, без перекладу мета-тегів і alt-атрибутів;
• перемикач мови, що веде на головну, а не на ту саму сторінку іншою мовою;
• різні формати дат і валют без урахування локалі.

Контент: де його зберігати

Для маркетингового сайту є три підходи:

1. Файли в репозиторії (Markdown/YAML через Nuxt Content). Плюси: версіонування, швидкість, жодних зовнішніх залежностей, повний контроль. Мінус: правки йдуть через розробника або Git.
2. Headless CMS (Strapi, Directus, Sanity та інші). Плюси: зручний редактор для нетехнічної людини. Мінуси: ще одна система для підтримки й додаткові витрати.
3. Адмінка на Laravel. Виправдана, коли контент тісно пов'язаний з бізнес-логікою (каталог, замовлення). Тоді Nuxt бере дані з API Laravel.

Для сайту, де контент змінюється кілька разів на місяць, перший варіант найекономніший: кожна зміна це коміт і автоматична пересборка. Якщо ж сайт редагують щодня кілька людей, без CMS не обійтися.

Зв'язку Nuxt і Laravel присвячена наша розробка на Nuxt і Laravel, коли потрібно більше, ніж статичний сайт: кабінет, замовлення, інтеграції.

Коли Nuxt не потрібен

Краще сказати прямо, коли ми не радимо Nuxt:

• Сайт на 3–5 сторінок без інтерактиву й без планів зростання. Достатньо статичного HTML або простого генератора.
• Редактор самостійно щодня змінює контент і дизайн. Тут буде кращим WordPress або конструктор, бо вигода від повного контролю над кодом не виправдає витрат на підтримку.
• Дуже малий бюджет і потреба «вчора». Конструктор запустить сайт швидше, а перейти на власний код можна пізніше, коли виникнуть обмеження.
• Команда без жодного досвіду з Vue. Вартість підтримки зросте. Якщо ви плануєте самі розвивати сайт, врахуйте цей фактор.

У решті випадків, коли потрібні швидкість, власний дизайн, SEO-контроль і запас на розвиток, Nuxt виправдовує себе. Порівняння з іншими підходами для магазинів ми розбирали в статті про Laravel, OpenCart і WordPress.

Підводні камені, з якими ми стикалися

• Гідратаційні помилки. Якщо HTML із сервера не збігається з тим, що рендерить клієнт (випадкові значення, Date.now(), залежності від window), Vue видає попередження й може перемалювати сторінку. Дані, що залежать від браузера, виносимо в onMounted або <ClientOnly>, але лише для неіндексованого контенту.
• Контент лише на клієнті. Усе, що має індексуватися, повинно бути в HTML. Перевірка проста: відкрийте «Переглянути код сторінки» (не інспектор) і знайдіть свій текст.
• Кінцеві слеші та дублі адрес. /posluhy і /posluhy/ для пошуковика різні адреси. Оберіть один формат, налаштуйте редирект на рівні сервера й канонічну адресу.
• Сторонні скрипти. Аналітика, чати й віджети можуть з'їсти весь виграш у швидкості. Підключайте їх після згоди користувача і відкладено.
• Прев'ю-середовища в індексі. Закривайте тестові та preview-деплої від індексації (noindex), інакше пошуковик знайде дублі вашого сайту.

Чек-лист перед запуском Nuxt-сайту

1. Відкритий код сторінки містить повний текст і один h1.
2. Унікальні title і description на кожній сторінці.
3. Канонічні адреси в єдиному форматі, редирект зі слешів налаштований.
4. sitemap.xml і robots.txt працюють на проді та закривають тестові середовища.
5. Структуровані дані проходять Rich Results Test.
6. Зображення в сучасних форматах, першого екрана не лінивимо, розміри задані.
7. Шрифти віддаються з вашого домену, із запасними метриками.
8. Lighthouse на мобільному, а не на десктопі; реальні дані CWV додаємо після запуску з Search Console.
9. Форми й кнопки працюють без JS або мають запасний шлях (посилання на месенджер, mailto).
10. Мовні версії посилаються одна на одну, порожніх мов немає.

Якщо ви вже маєте сайт на Nuxt і сумніваєтесь у ньому, першим кроком буде технічний аудит коду або експрес-перевірка швидкості й індексації.

Плануєте сайт або перепис на Nuxt? Опишіть задачу в брифі: ми скажемо, чи Nuxt справді вам потрібен, і дамо оцінку за 1 робочий день. Заповнити бриф.