SEO u headless webu: na co nezapomenout v Astru a Next.js

Je headless web horší pro SEO?

Ne. Headless web je web, kde obsah spravuje samostatný CMS (třeba Sanity) a stránky vykresluje frontend v Astru nebo Next.js. Vyhledávačům je jedno, odkud obsah pochází. Zajímá je, jaké HTML dostanou, jaký stavový kód stránka vrátí a jestli má metadata.

Háček je jinde. Klasické systémy jako WordPress nebo Webflow řeší spoustu SEO věcí za vás: sitemapu, kanonické URL, přesměrování, pole pro meta popisky. U headless webu nic z toho nevznikne samo. Musí se to navrhnout a postavit. Když se na to zapomene, web vypadá skvěle, jen ho ve vyhledávání nikdo nenajde. Proto procházím u každého headless projektu stejný technický checklist.

Dostane vyhledávač hotové HTML?

Tohle je první a nejdůležitější otázka. Pokud se obsah stránky skládá až v prohlížeči JavaScriptem (client-side rendering), robot při prvním načtení dostane prázdnou kostru. Google JavaScript vykreslit umí, ale dělá to s odstupem. Řada dalších robotů, včetně většiny crawlerů AI vyhledávačů, ho podle dostupných měření nespouští vůbec.

Řešení je posílat hotové HTML ze serveru:

• Statické generování (SSG): stránky se vyrobí při buildu. Výchozí režim Astra, ideální pro obsahové weby.
• Renderování na serveru (SSR): stránka se složí na serveru při požadavku. V Next.js s App Routerem je to díky React Server Components výchozí chování.
• Průběžné přegenerování: statická stránka, která se po změně obsahu v CMS obnoví sama.

Rychlý test: otevřete na svém webu „Zobrazit zdrojový kód stránky“. Pokud tam nevidíte nadpis a text článku, nevidí ho ani část robotů. Přesnější pohled dá nástroj Kontrola URL v Search Console, který ukáže vykreslené HTML tak, jak ho vidí Google.

Kde se berou titulky, popisky a kanonické URL?

V headless webu z CMS. Ale jen tehdy, když na ně v obsahovém modelu myslíte. V Sanity proto ke každému typu stránky přidávám SEO objekt: titulek pro vyhledávače, meta popis, obrázek pro sdílení, kanonickou URL a přepínač noindex. Když pole zůstane prázdné, frontend použije rozumný výchozí stav, třeba nadpis a perex stránky.

V Next.js to obstará Metadata API:

export async function generateMetadata({ params }) {
  const { slug } = await params
  const page = await getPage(slug)
  return {
    title: page.seo?.title ?? page.title,
    description: page.seo?.description ?? page.perex,
    alternates: { canonical: `https://example.com/${slug}` },
    robots: page.seo?.noindex ? { index: false } : undefined,
  }
}

V Astru stejná data vypíšete do <head> ve společném layoutu. Výhoda je v tom, že marketing pak metadata upravuje sám v Sanity Studiu a nemusí kvůli nim čekat na vývojáře.

Má web sitemapu a robots.txt?

Musí. U headless webu je nejlepší generovat sitemapu automaticky z obsahu, aby nová stránka nebo článek byly v sitemapě ve chvíli, kdy je publikujete.

• Astro má oficiální integraci @astrojs/sitemap.
• Next.js vygeneruje sitemapu i robots.txt ze souborů app/sitemap.ts a app/robots.ts.

Do sitemapy patří jen kanonické, indexovatelné stránky se stavem 200. Ne koncepty, ne stránky s noindex a ne přesměrované URL.

Vrací chybějící stránka opravdu 404?

U webů postavených jako jednostránková aplikace se často stává, že neexistující URL vrátí stav 200 a jen zobrazí text „Stránka nenalezena“. Google tomu říká soft 404. Ověřte, že neexistující slug vrací skutečný stavový kód 404. V Next.js na to slouží funkce notFound(), v Astru stránka 404.astro, u serverového renderování pak nastavení Astro.response.status.

Kdo se stará o přesměrování?

Při redesignu nebo přejmenování stránky musí stará URL vést přesměrováním 301 na novou. V headless webu doporučuji spravovat přesměrování jako obsah: v Sanity je seznam „stará URL → nová URL“ a frontend nebo hosting si ho načte při buildu. Marketing tak přesměrování přidá sám, když mění strukturu webu. Víc o přesměrováních píšu v článku o přípravě na migraci webu.

Na co se zapomíná nejčastěji?

• Náhledová prostředí v indexu. Testovací a preview verze webu musí mít noindex nebo být za heslem, jinak soupeří s ostrým webem.
• Koncepty mimo web. Nepublikovaný obsah z CMS nesmí proniknout do sitemapy ani na veřejné stránky.
• Zastaralé stránky po publikaci. Když se stránky generují staticky, musí je publikace v CMS obnovit. Webhook ze Sanity spustí nový build nebo přegeneruje jen změněné stránky.
• Hreflang u vícejazyčného webu. Každá jazyková verze má odkazovat na ostatní. V Sanity se propojí překlady, frontend z nich vygeneruje alternativní odkazy.
• Alt texty. Pole pro popis obrázku v Sanity udělejte povinné. Validace je levnější než audit.
• Strukturovaná data. JSON-LD pro článek, organizaci nebo produkt se skládá ze stejných polí jako stránka, takže se s obsahem nerozjede.
• Konzistentní URL. Rozhodněte jednou, jestli adresy končí lomítkem, a držte se toho všude, v odkazech i v sitemapě.

Proč se to vyplatí postavit pořádně?

Protože když jsou tyhle základy hotové, má headless web pro SEO nadprůměrné podmínky. Statické HTML je rychlé, v kódu je jen to, co tam má být, a metadata jsou strukturovaná data místo ručně vyplňovaných polí na stovce stránek. Marketing pak v Sanity skládá nové landing pages z hotových bloků a každá z nich dostane SEO pole, místo v sitemapě i kanonickou URL automaticky.

Jak bloky v Sanity fungují, popisuju v článku Sanity CMS: co to je, jak funguje a kdy se vyplatí. Výběr frameworku rozebírám v článku Astro, Next.js, nebo Webflow a viditelnost v AI odpovědích v článku Jak optimalizovat web pro AI vyhledávače.

Co si z toho odnést

Headless web není pro SEO handicap, jen nic nedostanete zadarmo. Rozhoduje hotové HTML ze serveru, SEO pole v obsahovém modelu, automatická sitemapa, správné stavové kódy a přesměrování spravovaná v CMS. Když je to součástí návrhu od začátku, marketing pak řeší obsah, ne technické chyby.

Plánujete headless web, nebo už ho máte a nevíte, jestli je technicky v pořádku pro vyhledávače? Napište mi. Projdu ho podle tohoto checklistu a řeknu vám, co opravit jako první.