Języki

SEO w Nuxt

Nuxt domyślnie renderuje po stronie serwera, ale to ustawienie per-route, a nie gwarancja — pełny HTML dla botów tylko na trasach, które to zachowują. Tryby renderowania, useSeoMeta(), zestaw narzędzi @nuxtjs/seo, uwagi o hydracji i Nitro, Core Web Vitals oraz błędy, które po cichu kosztują.

Opublikowano po raz pierwszy: 26 cze 2026 · Ostatnia aktualizacja: 3 sie 2026 · Zaawansowane
AIAutor:AI v2
1 sygnał dowodowy na tej stronie

Nuxt domyślnie renderuje strony po stronie serwera, więc trasa, która zachowuje ten domyślny tryb, daje botom kompletny dokument HTML zamiast pustej skorupy, jaką wysyła zwykła aplikacja Vue SPA — ale to ustawienie per-route: routeRules lub globalne ssr:false może przełączyć dowolną trasę na CSR, więc zweryfikuj faktyczną trasę, a nie zakładaj na podstawie nazwy frameworka. Podstawową decyzją jest tryb renderowania dla każdej trasy — SSR (domyślnie), SSG przez nuxt generate lub hybrydowe reguły tras — ponieważ meta tagi, schema i sitemapy pojawiają się po tym. Użyj useSeoMeta() dla meta, traktuj pakiet @nuxtjs/seo Harlana Wiltona jako opcjonalny zestaw narzędzi firm trzecich (nie rdzeń Nuxt) dla robots/sitemap/OG/schema/canonical, nigdy nie sięgaj po dynamiczne renderowanie (Google je wycofał), zweryfikuj hydrację/payload i zachowanie presetów wdrożeniowych/pamięci podręcznej Nitro niezależnie od HTML serwera i pamiętaj, że kontrakty renderowania botów AI różnią się w zależności od dostawcy — SSR/SSG umieszcza treść w surowym HTML i maksymalizuje zasięg.

TL;DR — Domyślnym ustawieniem Nuxt jest renderowanie po stronie serwera, więc trasa, która zachowuje to ustawienie domyślne, otrzymuje kompletny DOM zamiast pustej skorupy, którą wysyła zwykła aplikacja Vue SPA — ale to jest wynik per trasa: ssr: false lub nadpisanie routeRules może zamienić dowolną trasę na CSR lub hybrydową, więc przetestuj faktyczną trasę, a nie nazwę projektu. Strategia renderowania jest fundamentalną decyzją — SSR (domyślnie), SSG (nuxt generate) lub hybrydowe routeRules — ponieważ meta, schema i sitemapy pojawiają się po niej. Użyj useSeoMeta() dla tagów meta (useHead() dla reszty head, warianty tylko serwerowe, gdy nie potrzebujesz reaktywności) i traktuj pakiet @nuxtjs/seo Harlana Wiltona jako opcjonalny zestaw narzędzi firm trzecich dla robots/sitemap/OG/schema/canonical — nie część rdzenia Nuxt i nie dowód, że jego wynik jest poprawny, dopóki tego nie sprawdzisz. Nigdy nie używaj dynamicznego renderowania (Google je wycofał). Renderowanie przez AI-crawler różni się w zależności od dostawcy — SSR/SSG maksymalizuje pokrycie surowego HTML. Poza początkowym HTML, zweryfikuj hydratację/payload, presety wdrożeniowe Nitro i cache, oraz bezpośrednio status HTTP niezależnie — sam HTML serwera nie dowodzi żadnego z tych. Zwykłe zasady JS-SEO nadal obowiązują: prawdziwe linki <a href>, nie blokuj JS/CSS, obserwuj wyrenderowany vs. surowy HTML.

Nuxt jest odpowiedzią Vue na problem SPA

Vue, samo w sobie, wysyła aplikację jednostronicową: skorupę HTML plus JavaScript, który buduje DOM w przeglądarce. Nuxt to meta-framework na bazie Vue (działający na silniku serwera Nitro w Nuxt 3, z Nuxt 4 w 2025 roku), a jego cały powód istnienia — z punktu widzenia SEO — polega na tym, że domyślnie renderuje po stronie serwera. Każda strona dociera jako w pełni uformowany dokument HTML, co jest dokładnie tym, co Googlebot chce przeczytać bez konieczności wykonywania JavaScriptu najpierw. Czyste SEO Vue to osobny temat z własnymi trybami awarii; tutaj zakładam, że wybrałeś Nuxt właśnie po to, aby nie musieć walczyć z problemem SPA.

To ten sam punkt, który podnoszę ogólnie o JavaScript: każda poprawna konfiguracja SSR, renderowania statycznego lub prerenderowania może być odpowiednia dla wyszukiwarek; dotyczy to między innymi Gatsby, Next i Nuxt. Domyślne ustawienia Nuxt są skierowane we właściwą stronę. Większość problemów SEO w Nuxt to ludzie wyłączający te ustawienia domyślne lub nakładający błędy na nie.

Strategia renderowania jest fundamentem — decydowana per trasa, nie per projekt

Przed tagami meta, przed schema, przed sitemapami, pytanie, które decyduje o wszystkim, to jak HTML jest produkowany dla tej konkretnej trasy? Nuxt dokumentuje uniwersalne (serwerowe) renderowanie jako domyślne dla całej aplikacji, ale to domyślne nie jest gwarancją na poziomie trasy: globalne ssr: false przełącza całą aplikację na renderowanie klienckie, a routeRules może przypisać inny tryb do dowolnego wzorca URL. “To jest aplikacja Nuxt” nie mówi ci nic o tym, jak jedna konkretna strona się renderuje — musisz sprawdzić trasę. Nuxt daje ci pięć strategii:

TrybJak to ustawiaszWpływ na SEONajlepsze dla
Uniwersalny / SSRDomyślnie (ssr: true)Doskonały — pełny HTML przy każdym żądaniuDynamiczne, spersonalizowane treści
Statyczny / SSGnuxt generateDoskonały — HTML zbudowany w czasie wdrożeniaBlogi, dokumentacja, marketing
HybrydowyrouteRules per trasaDoskonały — mieszanka per trasaDuże strony z mieszaną treścią
SPA / CSRssr: falseSłaby dla indeksowanych treściPanele, panele administracyjne
Po stronie edgeCel wdrożeniaDoskonały — niski TTFBGlobalna wydajność

Oficjalna dokumentacja Nuxt wyjaśnia bezpośrednio, dlaczego renderowanie po stronie klienta jest złym wyborem dla treści: indeksowanie i aktualizowanie takich materiałów zajmuje więcej czasu, podczas gdy przy renderowaniu uniwersalnym roboty mogą bezpośrednio indeksować zawartość strony. Dowód potwierdzający to twierdzenie Nuxt documents that universal rendering delivers HTML content immediately and allows crawlers to index it directly. Zakres: Nuxt rendering; no indexing guarantee. Poziom ufności: wysoki · Zweryfikowano: Nuxt: Rendering modes (Dokumentacja renderowania Nuxt.) CSR (ssr: false) jest przeznaczone do systemów back-office, pulpitów nawigacyjnych i gier — a nie do czegokolwiek, co chcesz indeksować.

Renderowanie hybrydowe to najlepsze rozwiązanie dla dużych witryn. Reguły tras w nuxt.config.ts pozwalają ustawić tryb renderowania i buforowania dla każdego wzorca URL:

routeRules: {
  '/blog/**':     { prerender: true },        // SSG for the blog
  '/product/**':  { swr: 3600 },              // ISR-style: regenerate hourly
  '/admin/**':    { ssr: false },             // SPA for the admin area
  '/checkout/**': { ssr: true },              // always-fresh SSR
}

swr (stale-while-revalidate) i isr (incremental static regeneration) generują stronę statycznie, a następnie odświeżają ją w tle — idealne rozwiązanie dla e-commerce z dużą liczbą stron lub serwisów informacyjnych, gdzie pełna przebudowa przy każdej zmianie nie jest praktyczna. Nuxt Islands (<NuxtIsland>) renderują komponenty bez wysyłania JavaScriptu po stronie klienta, zmniejszając koszt hydratacji i pomagając wskaźnikowi INP — najczęściej problematycznej metryce Core Web Vitals w aplikacjach Nuxt.

Jak zweryfikować to, co faktycznie wdrożyłeś: View Source pokazuje surowy HTML, który wysłał serwer; jeśli Twoja treść tam jest, renderujesz po stronie serwera. Panel Elements w DevTools pokazuje wyrenderowany DOM. A narzędzie URL Inspection w GSC pokazuje, co Google faktycznie pobrał i wyrenderował — źródło prawdy. Nie ufaj stwierdzeniu “w mojej przeglądarce wygląda dobrze”.

Jak Googlebot obsługuje aplikację Nuxt

Google przetwarza każdą aplikację JavaScript w trzech fazach — crawl, render, index — a problemem jest czas: renderowanie odbywa się w kolejce, a nie natychmiast. Jak ująłem to w moim przewodniku po JavaScript SEO, renderer jest cierpliwy — “there is no fixed timeout for the renderer… It’s really patient, and you should not be concerned.” (tłumaczenie) „Nie ma ustalonego limitu czasu dla renderera… Jest naprawdę cierpliwy i nie powinieneś się martwić.” Ale cierpliwość to nie to samo co szybkość w przypadku świeżych treści. Jeśli dostarczasz stronę renderowaną po stronie klienta, Twoja treść nie istnieje dla Google, dopóki nie nastąpi ta fala renderowania; SSR i SSG eliminują tę lukę, ponieważ HTML jest kompletny przy pierwszym pobraniu.

Dwie kolejne rzeczy mają znaczenie na dużą skalę. Renderowanie JavaScriptu jest kosztowne — z mojej prelekcji JavaScript SEO (Ungagged) z 2019 roku, koszty indeksowania wzrastają o około 20×, gdy Google musi renderować (szacunkowo, ale rząd wielkości pozostaje aktualny). Google stosuje najbardziej restrykcyjną dyrektywę spośród surowego i wyrenderowanego HTML — więc noindex wstrzyknięty przez JavaScript wygra z index w surowym HTML i odwrotnie. Kanoniczny adres URL wstrzyknięty za pomocą JavaScriptu jest respektowany tylko wtedy, gdy w surowym HTML nie ma już kanonicznego adresu URL. Trzymaj sygnały robots i canonical w HTML renderowanym po stronie serwera, co Nuxt robi za Ciebie, gdy włączone jest SSR.

Rzeczywistość botów AI

To nowość roku 2026. Boty AI — GPTBot, ClaudeBot, PerplexityBot i inne — zazwyczaj w ogóle nie wykonują JavaScriptu. Indeksują surowy HTML i nic więcej. Więc strona Nuxt renderowana po stronie klienta jest praktycznie niewidoczna dla silników odpowiedzi AI. SSR lub SSG to tutaj nie tylko lepsze rozwiązanie dla Google; to warunek wstępny dla optymalizacji pod kątem silników odpowiedzi również. Jeśli chcesz, aby Twoje treści były cytowane przez ChatGPT, Perplexity lub Claude, muszą być w HTML przy pierwszym pobraniu.

Poza początkowym HTML: payload, hydratacja i kody statusu

Uzyskanie HTML serwera z Twoją treścią jest konieczne, ale niewystarczające — kilka rzeczy może nadal pójść źle po tej pierwszej odpowiedzi, a “sprawdziłem View Source” ich nie obejmuje:

  • Ładunek i hydratacja. Renderowanie uniwersalne wysyła HTML oraz serializowany ładunek danych, który klient wykorzystuje do hydratacji — dołączenia nasłuchiwaczy zdarzeń i przejęcia tam, gdzie serwer zakończył — bez ponownego pobierania. To, że HTML serwera wygląda dobrze, nie dowodzi, że hydratacja się powiodła, że nawigacja po stronie klienta odtwarza tę samą treść ani że ładunek nie jest nieaktualny. Jeśli strona działa dobrze przy pierwszym ładowaniu, ale psuje się po zmianie trasy po stronie klienta, to problem z hydratacją/ładunkiem, a nie z trybem renderowania.
  • <ClientOnly> i treść tylko dla przeglądarki. Opakowanie czegoś w <ClientOnly> — często stosowane w przypadku widżetów zależnych od API przeglądarki — oznacza, że element jest nieobecny w odpowiedzi serwera nawet na trasie w innym przypadku uniwersalnej. Jeśli Twoja główna treść, kluczowy link lub tagi meta znajdą się wewnątrz granicy tylko dla klienta, roboty indeksujące i boty AI, które czytają tylko surowy HTML, je pominą, niezależnie od ustawienia trybu renderowania. Sprawdź faktyczną odpowiedź, a nie tylko konfigurację trybu renderowania.
  • Kody statusu i przekierowania nie są samopotwierdzające. Strona błędu Nuxt renderowana w przeglądarce lub przekierowanie sterowane przez navigateTo()/composable nie dowodzi samo w sobie, jaki kod statusu HTTP wysłała bezpośrednia odpowiedź serwera. Wytyczne Google są jednoznaczne, że znaczące kody statusu mają znaczenie dla indeksowania i crawlowania — potwierdź faktyczny nagłówek za pomocą curl -I, a nie to, co wyświetla strona błędu renderowana po stronie klienta.

Nic z tego nie jest argumentem przeciwko renderowaniu uniwersalnemu — to przypomnienie, że „HTML jest renderowany po stronie serwera” to pierwsza kontrola, a nie ostatnia.

Nitro, presety wdrożeniowe i granice pamięci podręcznej

Wyjście serwera Nuxt jest budowane przez Nitro, a Nitro kompiluje się inaczej w zależności od presetów wdrożeniowych, które wybierzesz (serwer Node, Cloudflare, Vercel, Netlify, statyczny i inne). Ma to znaczenie dla SEO, ponieważ presety i adaptery mogą różnić się dostępnymi API środowiska uruchomieniowego, zachowaniem pamięci podręcznej, obsługą strumieniowania, wdrożeniem regionalnym i dostępem do systemu plików — reguła trasy lub handler serwera, który działa pod jednym presetem, nie ma gwarancji, że będzie działać identycznie pod innym. Dwie konsekwencje, które warto przetestować jawnie, a nie zakładać:

  • Klucze pamięci podręcznej i unieważnianie są specyficzne dla trasy, a nie automatyczne. Reguły tras swr i isr buforują i regenerują wyjście, ale błędny klucz pamięci podręcznej, brak unieważnienia lub nagłówek buforowania ustawiony przez platformę wdrożeniową mogą serwować nieaktualny, spersonalizowany lub niespójny HTML robotom indeksującym. Sprawdź faktyczny wiek odpowiedzi i wszelkie nagłówki Cache-Control/Age na żywym adresie URL, a nie tylko konfigurację routeRules.
  • Parytet produkcyjny nie jest gwarantowany przez zachowanie środowiska przejściowego. Trasa renderująca się poprawnie w lokalnym środowisku deweloperskim lub we wdrożeniu podglądowym nie potwierdza, że preset produkcyjny daje to samo wyjście — trasy serwera, przekierowania i obsługa błędów żyją w warstwie serwera Nitro, a ta warstwa najprawdopodobniej różni się w zależności od celu. Przetestuj produkcyjny adres URL bezpośrednio po każdej zmianie wdrożeniowej, tak samo jak weryfikowałbyś tryb renderowania.

Tagi meta: useSeoMeta() i useHead()

Zarządzanie nagłówkami w Nuxt działa na Unhead i daje dwa composable do różnych zadań.

useSeoMeta() to narzędzie, po które warto sięgnąć do tagów meta SEO i społecznościowych. To płaskie, bezpieczne typowo API z typowanymi parametrami. Dowód potwierdzający to twierdzenie useSeoMeta is a typed Nuxt API for SEO and social meta tags. Zakres: Current Nuxt composable. Poziom ufności: wysoki · Zweryfikowano: Nuxt: useSeoMeta Pomaga uniknąć klasycznego błędu Open Graph polegającego na użyciu name, gdy potrzebne było property:

useSeoMeta({
  title: 'My Page Title',
  ogTitle: 'My Page Title',
  description: 'Concise page-specific description with the key information first',
  ogDescription: 'Concise social description tailored to this page',
  ogImage: 'https://mysite.com/og-image.png', // must be an absolute URL
  twitterCard: 'summary_large_image',
})

useHead() to ogólne narzędzie do nagłówków dla wszystkiego innego — skryptów, tagów link, atrybutów body i szablonów tytułów:

useHead({
  titleTemplate: '%s · My Site Name',
  htmlAttrs: { lang: 'en' },
})

Niezawodny wzorzec warstwowy to: statyczne wartości domyślne (charset, viewport, favicon) w nuxt.config.ts → szablon tytułu dla całej witryny i globalne domyślne ustawienia OG w app.vue → nadpisania specyficzne dla strony przez useSeoMeta() w komponencie strony. Częstym błędem jest umieszczenie useSeoMeta() w layoucie zamiast na stronie, co nadpisuje specyficzne tagi strony tagami ogólnymi. A ponieważ wyszukiwarki czytają początkowy stan, meta SEO zazwyczaj nie musi być reaktywne — useServerHead() pomija ponowne wykonanie po stronie klienta.

Które API i co faktycznie dowodzi:

APIZakresReaktywne?Co dowodzi o wyniku
useSeoMeta()Płaskie, typowane meta SEO/social tylkoTak (domyślnie)Ustawia typowane właściwości poprawnie — nie to, że trasa jest unikalna, kanoniczna lub indeksowalna; nadal odpowiadasz za tę logikę
useHead()Wszystko w <head> — skrypty, linki, atrybuty, szablon tytułuTak (domyślnie)Ogólna kontrola nad head; to samo zastrzeżenie — użycie API nie jest dowodem poprawnej odpowiedzi serwera
useServerHead() / wywołania tylko serweroweJak wyżejNie — tylko serwer, pomija ponowne wykonanie po stronie klientaPotwierdza, że tag jest wysyłany raz w HTML serwera; nie potwierdza, że nawigacja po stronie klienta ustawia go ponownie, jeśli na nim polegasz

Wywołanie jednego z tych composables mówi ci, że API zostało uruchomione — samo w sobie nie mówi, co faktycznie emituje bezpośrednia odpowiedź serwera lub zmiana trasy po stronie klienta. Potwierdź to przez View Source lub curl, a nie tylko „wywołałem useSeoMeta()”.

Ekosystem modułów @nuxtjs/seo (Harlan Wilton) — opcjonalny, nie podstawowy

Rdzeń Nuxt nie dostarcza sitemap, robots.txt, generowania obrazów OG ani Schema.org po wyjęciu z pudełka — to poza prymitywami Nuxt (useHead, useSeoMeta, reguły tras, tryby renderowania). Społeczność wypełnia tę lukę @nuxtjs/seo Harlana Wiltona — osobno instalowany, zewnętrzny pakiet parasolowy (nuxtseo.com, obecnie w wersji v5.x, aktywnie utrzymywany, kierowany do Nuxt 3,16+ i Nuxt 4), który łączy sześć modułów. Jego instalacja daje sitemap, robots, obrazy OG i generowanie schematu — samo w sobie nie gwarantuje, że wynik jest poprawny dla twoich tras; zweryfikuj to, co generuje, tak samo, jak zweryfikowałbyś cokolwiek innego:

ModułCo robi
@nuxtjs/robotsrobots.txt + meta robots + nagłówki X-Robots-Tag
@nuxtjs/sitemapAutomatyczne sitemapy XML ze stron + dynamicznych tras
nuxt-og-imageDynamiczne obrazy OG (szablon Vue → obraz)
nuxt-schema-orgDane strukturalne Schema.org JSON-LD
nuxt-seo-utilsKanoniczne URL, breadcrumbs, wartości domyślne
nuxt-link-checkerWykrywanie zepsutych linków w czasie budowania

Zainstaluj cały pakiet przez npx nuxt module add seo lub pobierz pojedyncze moduły (npx nuxt module add sitemap robots). Kilka zachowań, które warto znać:

  • @nuxtjs/sitemap automatycznie generuje z katalogu pages/ plus dynamiczne trasy, dzieli na indeks sitemap automatycznie powyżej 50 000 URL, obsługuje i18n wielojęzyczne sitemapy i ma wbudowane wsparcie IndexNow. Jedna rzecz do zrobienia dobrze: Google ignoruje changefreq i priority; liczy się tylko dokładny lastmod, i to tylko wtedy, gdy treść faktycznie się zmienia.
  • @nuxtjs/robots generuje robots.txt, meta tag robots i nagłówek X-Robots-Tag — a domyślnie blokuje wszystkich crawlerów w środowiskach nieprodukcyjnych, co jest dokładnie pułapką indeksacji stagingowej, która dotyka headless buildów. Daje też reguły per-bot, więc możesz zablokować GPTBot konkretnie, zostawiając wszystkich innych w spokoju (bądź świadomy — zablokuj crawlera AI, a nie będzie cytować ciebie).
  • nuxt-seo-utils obsługuje kanoniczne URL i, co przydatne, automatycznie usuwa parametry śledzenia (utm_*, fbclid, gclid) z kanonicznych.

nuxt/image i Core Web Vitals

@nuxt/image to moduł obrazów: automatyczny responsywny srcset, nowoczesne formaty (WebP/AVIF), wbudowana optymalizacja przez dostawców CDN i leniwe ładowanie. Dwie zasady niosą większość wartości SEO:

  • Nigdy nie leniwie ładuj obrazu LCP. Twój obraz hero powinien ładować się eagerly; leniwe ładowanie opóźnia Largest Contentful Paint.
  • Zawsze ustaw width i height, aby przeglądarka zarezerwowała miejsce i nie poniosła straty z powodu Cumulative Layout Shift.
<NuxtImg
  src="/hero.jpg"
  width="1200"
  height="630"
  alt="Descriptive alt text"
  :loading="isHeroImage ? 'eager' : 'lazy'"
  format="webp"
/>

Cele na 2026 rok, do których należy dążyć (p75): LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1. W aplikacjach Nuxt INP jest tym, który zwykle cierpi, ponieważ hydratacja powoduje opóźnienie wejścia — dokładnie do tego służą Nuxt Islands i <NuxtIsland>.

Nuxt Content + SEO

Jeśli używasz @nuxt/content (modułu markdown/MDX), integracja z @nuxtjs/seo jest prosta, ale ma jedną pułapkę dotyczącą kolejności: załaduj @nuxtjs/seo przed @nuxt/content w tablicy modułów. Następnie możesz ustawić SEO w frontmatter treści (title, description, robots, ogImage, schemaOrg) i pobrać je do swojego szablonu [slug].vue za pomocą useSeoMeta() po pobraniu treści. To natywna dla Nuxt wersja wzorca headless-CMS i obowiązuje ta sama dyscyplina „przebuduj to, co zrobił wtyczka”.

Częste błędy SEO w Nuxt

  1. Używanie trybu aplikacji jednostronicowej (ssr: false) dla treści, które chcesz indeksować. Najdroższy błąd — i ten, który czyni cię niewidocznym dla robotów modeli generatywnych.
  2. Względne adresy obrazów Open Graph. ogImage musi być adresem bezwzględnym, w przeciwnym razie podglądy społecznościowe się psują.
  3. useSeoMeta() w layoutcie zamiast na stronie — ogólne tagi nadpisują te specyficzne dla strony.
  4. Nieweryfikowanie wyrenderowanego HTML — źródło strony ≠ DevTools ≠ to, co wyrenderował Google. Użyj narzędzia do sprawdzania adresów URL.
  5. Blokowanie JS/CSS w robots.txt — Google nie wyrenderuje z zablokowanych plików.
  6. Pozostawienie stagingowego noindex/disallow po starcie (lub odwrotnie, zapomnienie, że @nuxtjs/robots domyślnie blokuje nie-produkcyjne środowiska i zastanawianie się, dlaczego produkcja działa, a niestandardowe środowisko nie).
  7. Leniwie ładowanie obrazu LCP — obniża LCP.
  8. Brak width/height na obrazach — CLS.
  9. changefreq/priority w sitemapach — Google je ignoruje; liczy się tylko lastmod.
  10. Sięganie po dynamiczne renderowanie. Google zdeprecjonował je jako obejście, a nie rozwiązanie długoterminowe — i służy ono tylko silnikom, dla których je skonfigurujesz, pomijając Bing i każdego bota AI. Z Nuxt nigdy tego nie potrzebujesz: SSR i SSG już dają botom pełny HTML.

llms.txt i AEO

llms.txt to plik tekstowy — kuzyn robots.txt — który pomaga narzędziom AI nawigować po treści. Moduł nuxt-llms automatycznie generuje /llms.txt i /llms-full.txt z Nuxt Content. Od końca 2025 roku jego głównymi odbiorcami są serwery MCP i narzędzia do kodowania AI (Cursor, Claude Code), a nie bezpośrednio ChatGPT czy Perplexity, i jest najbardziej przydatny dla stron dokumentacji i blogów technicznych — mniej dla e-commerce czy wiadomości. Warto dodać, jeśli jesteś stroną docs/dev; w przeciwnym razie nie jest to priorytet.

Gdzie to pasuje

SEO w Nuxt to tak naprawdę konkretne zastosowanie JavaScript SEO poprzez własne konwencje Nuxt — i mocno pokrywa się z tematem SEO dla headless CMS, gdy twój frontend Nuxt pobiera dane z headless backendu. Zasady się nie zmieniają; Nuxt po prostu daje dobre domyślne ustawienia i silny ekosystem modułów do ich wdrożenia.

Dodaj notatkę eksperta

Przypnij cytat eksperta

Nowa osoba? Najpierw utwórz jej nieprzejęty profil na /admin/experts/ → Przypnij cytat eksperta .