SEO checklist pro web vytvořený pomocí AI: jak se dostat do Googlu

Web vytvořený pomocí AI dostanete do Googlu tak, že projdete SEO checklist pro web v pevném pořadí: indexace, vykreslování, metadata, výkon a nakonec obsah. Postup: změřte stav v Search Console a crawleru, zadejte AI asistentovi jeden konkrétní problém, zkontrolujte git diff a výsledek ověřte testem.

Proč se weby z AI nezobrazují v Google?

Weby z AI v Googlu obvykle chybí kvůli technickým základům a indexaci, ne proto, že je napsala AI. Googlebot stránku buď nenajde, nebo z ní nevyčte obsah.

Vibe coding, tedy stavění aplikace zadáváním promptů AI asistentovi, rychle vytvoří funkční prototyp. Takový prototyp ale často vynechá všechno, co uživatel v prohlížeči nevidí. U vibe coding SEO proto narážíme na stále stejné mezery:

• chybí server-side rendering, obsah se vykreslí až JavaScriptem v prohlížeči a Googlebot ho může zpracovat pozdě nebo vůbec,
• v kódu zůstal noindex z vývojové fáze a stránku vyřazuje z indexu,
• robots.txt blokuje celý web nebo složky se styly a skripty,
• chybí sitemap.xml, canonical URL a unikátní metadata,
• obrázky nemají rozměry, takže se rozložení stránky při načítání posouvá.

Celou situaci dobře shrnuje recesistický prompt, který koluje mezi vývojáři. Začíná větou „My vibe-coded site doesn't show up on Google. Fix it.“, vyjmenuje dvacet úkolů od SSR po zpětné odkazy a končí požadavkem „Page one by Monday. Make no mistakes.“ Autor příspěvku k němu dodává, že vtip spočívá v tom, že jde opravdu o kompletní SEO checklist. Radí vložit ho do Claude Code a poslední dva body (skutečného autora a zpětné odkazy) udělat samostatně.

Ten prompt je užitečný seznam, ale nic nezměří. Nezjistí, které stránky Google skutečně zaindexoval, jak web zažívají reální návštěvníci ani jestli má obsah hodnotu. To dál zjistíte jen v Search Console, crawlerem a odborným posouzením.

SEO checklist pro web: technické SEO krok za krokem

Technické SEO řešte od indexace přes vykreslování po interní odkazy a před každou opravou změřte výchozí stav. Bez měření nepoznáte, co AI asistent skutečně opravil.

Indexace a vykreslování

Prvním krokem je server-side rendering, kdy server pošle hotové HTML s obsahem, místo prázdné stránky čekající na JavaScript. My v nobig.deals stavíme weby v Next.js, který vykreslování na serveru nabízí přímo. U jiných frameworků najdete ekvivalent v jejich dokumentaci.

Pak zkontrolujte robots.txt: musí pustit Googlebot ke stránkám i ke zdrojům, které stránka potřebuje k vykreslení. Vygenerujte sitemap.xml se všemi indexovatelnými URL a odešlete ji v Google Search Console. Nakonec projděte šablony a odstraňte zapomenuté noindex tagy.

Crawl a interní odkazy

Crawler typu Screaming Frog SEO Spider projde web jako vyhledávač a ukáže status kódy, řetězce přesměrování, rozbité odkazy a stránky, na které nevede žádný interní odkaz. Řetězce přesměrování zkraťte na jeden skok, rozbité odkazy opravte a osamocené stránky (orphan pages) propojte z navigace nebo z příbuzných článků. Obrázkům doplňte alt texty, které popisují jejich obsah.

Rozdíl mezi laboratorními a terénními daty popisuje Google v dokumentaci k PageSpeed Insights.

Jak nastavit canonical, titulky, meta popisy a schema?

Každá stránka potřebuje jednu canonical URL, unikátní titulek a meta popis, jednu H1 a strukturovaná data odpovídající viditelnému obsahu. AI to zvládne, pokud metadata čerpá z obsahu stránky, ne ze šablony.

Riziko při plošném generování je právě duplicita. Když asistent dostane pokyn „doplň všem stránkám meta popis“, často vytvoří jeden obecný text s obměnou slova. Lepší je, aby se metadata skládala z dat, která stránka opravdu zobrazuje. V Next.js to vypadá takto:

// app/blog/[slug]/page.tsx – metadata i JSON-LD z dat stránky, ne ze šablony
import type { Metadata } from "next";
import { getPost } from "@/lib/posts"; // vlastní funkce projektu

export async function generateMetadata({ params }: { params: { slug: string } }): Promise<Metadata> {
  const post = await getPost(params.slug);
  return {
    title: post.title,          // unikátní titulek pro každou stránku
    description: post.excerpt,  // popis z perexu článku
    alternates: { canonical: `/blog/${post.slug}` }, // jedna kanonická varianta (vyžaduje metadataBase)
  };
}

export default async function Page({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: post.title,
    author: { "@type": "Person", name: post.author.name }, // skutečný autor, ne vymyšlený
    datePublished: post.publishedAt,
  };
  return (
    <article>
      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }} />
      <h1>{post.title}</h1>

Pro on-page minimum platí:

• canonical u každé stránky, včetně variant s parametry a lomítkem na konci,
• titulek a meta popis unikátní pro každou URL,
• jedna H1 na stránku, další nadpisy hierarchicky,
• strukturovaná data Article a FAQ jen tam, kde stránka článek nebo otázky skutečně obsahuje,
• drobečková navigace (breadcrumbs) viditelně na stránce i ve schema,
• kontrola v Rich Results Testu a Schema Markup Validatoru.

Strukturovaná data, která neodpovídají obsahu, nejsou jen zbytečná. Google je ve spamových zásadách řadí mezi zavádějící techniky.

Jaká má být hodnota CLS a rychlost načtení?

Google považuje CLS do 0,1 za dobrý výsledek, mezi 0,1 a 0,25 za potřebný zlepšení a nad 0,25 za špatný. Rychlost posuzuje metrikou LCP, ne celkovou dobou načtení.

Core Web Vitals tvoří podle Google Search Central tři metriky: LCP (Largest Contentful Paint) měří načtení hlavního obsahu, INP (Interaction to Next Paint) odezvu na interakci a CLS (Cumulative Layout Shift) nečekané posuny rozložení.

Požadavek „Load every page in under 2 seconds“ ze zdrojového promptu je rozumný cíl, ale není to oficiální metrika Googlu. Google hodnotí LCP, INP a CLS, nikoli jedno číslo pro celé načtení. Pro optimalizaci rychlosti a uživatelského zážitku proto udržujte všechny tři metriky v dobrém pásmu, ne jen jednu z nich.

Laboratoř vs. reální uživatelé

Lighthouse spouští test v simulovaném prostředí. PageSpeed Insights podle Googlu kombinuje tento laboratorní test s daty skutečných uživatelů z Chrome UX Reportu, pokud jich má stránka dost. Search Console ukazuje Core Web Vitals z reálného provozu.

Pro posouzení webu Googlem rozhodují terénní data. Laboratorní běh slouží k ladění a k zachycení regresí, ale zlepšení skóre v Lighthouse samo nedokazuje, že se zlepšila zkušenost návštěvníků. INP navíc vyžaduje skutečnou interakci, takže ho běžný laboratorní běh přímo nezměří.

Na CLS nejčastěji působí obrázky bez rozměrů, pozdě vložené bannery a cookie lišty a výměna webfontů. Opravou je komprese obrázků do WebP s explicitní šířkou a výškou nebo s aspect-ratio, rezervace místa pro bannery a embedy a fonty s podobnými metrikami náhradního písma.

Příklad testu v CI

Test v CI sestaví aplikaci, spustí ji, změří hlavní stránku v Lighthouse a selže, když výsledek překročí limit:

# CI krok: sestavit, spustit, změřit, vyhodnotit
npm run build
npm run start &
npx wait-on http://localhost:3000
npx lighthouse http://localhost:3000/ \
  --output=json \
  --output-path=./artifacts/lighthouse.json \
  --chrome-flags="--headless"
node scripts/assert-vitals.mjs ./artifacts/lighthouse.json

Vyhodnocovací skript čte JSON report a nenulovým návratovým kódem zastaví pipeline:

// scripts/assert-vitals.mjs – limity podle prahů Core Web Vitals
import { readFileSync } from "node:fs";

const report = JSON.parse(readFileSync(process.argv[2], "utf8"));
const cls = report.audits["cumulative-layout-shift"].numericValue;
const lcp = report.audits["largest-contentful-paint"].numericValue; // v ms

const errors = [];
if (cls > 0.1) errors.push(`CLS ${cls.toFixed(3)} je nad 0.1`);
if (lcp > 2500) errors.push(`LCP ${Math.round(lcp)} ms je nad 2500 ms`);

if (errors.length) {
  console.error(errors.join("\n"));
  process.exit(1); // selhání buildu místo tichého zhoršení
}
console.log("Laboratorní limity splněny.");

Co z checklistu zvládne AI a co zůstává na lidech

AI asistent jako Claude Code zvládne většinu technických bodů: metadata, schema, převod obrázků do WebP, rezervaci místa pro prvky nebo opravu robots.txt. Jeho přínos není v tom, že by SEO měřil lépe než crawler, ale v tom, že nález rovnou promění ve změnu kódu. Proto musí být každá změna kontrolovatelná.

Nejčastější chybou je oprava symptomu místo příčiny. Asistent může snížit CLS tím, že posouvající se prvek skryje, nebo zrychlit LCP vypnutím obsahu. Skóre se zlepší, stránka je horší. Proto do promptu patří výslovný zákaz: neopravuj CLS skrytím prvku, najdi ho a rezervuj mu místo.

Druhou chybou je záměna doporučení za ranking faktor. AI ráda tvrdí, že konkrétní délka titulku nebo skóre Lighthouse přímo ovlivní pořadí, což z dokumentace Googlu nevyplývá. Třetí je hnaní skóre na úkor UX: odstranění funkcí, které uživatelé potřebují, jen aby test ukázal vyšší číslo.

Zpětné odkazy ani autentický obsah AI nezíská. Odkazy vznikají tím, že má firma co říct a někdo to chce citovat, a to se promptem nenahradí. Pokud chcete takové kontroly zavést systematicky, popisujeme, jak zapojit AI ve vývojovém procesu i s hlídáním kvality. Opakované kroky, jako noční crawl a otevření pull requestu s opravou, lze předat automatizaci pomocí AI agentů, pokud o sloučení dál rozhoduje člověk.

Pro úplnost: my v nobig.deals používáme Next.js a nasazujeme na Railway. SEO checklist ale platí bez ohledu na stack, jiný framework mění jen to, kde se metadata a vykreslování nastavují.

Jak Google zachází s obsahem vytvořeným pomocí AI?

Google nepenalizuje obsah jen proto, že vznikl pomocí AI. Postihuje obsah bez přidané hodnoty vyráběný ve velkém, manipulaci s pořadím a falešnou identitu autorů.

Google v pokynech ke generativní AI uvádí, že generování mnoha stránek pomocí AI bez přidané hodnoty může porušovat zásady proti zneužívání škálovaného obsahu (scaled content abuse). Spamové zásady popisují systém SpamBrain, který spam vyhledává, a uvádějí, že weby porušující zásady mohou být ve výsledcích níž nebo se nezobrazí vůbec. V květnu 2026 Google doplnil, že se zásady vztahují i na generativní odpovědi ve vyhledávání.

Rizikové jsou hlavně tyto vzorce:

• stovky stránek podle jedné šablony s obměnou klíčového slova,
• samostatné stránky pro každou variantu dotazu bez vlastní hodnoty,
• přepisování dostupných textů bez nové informace,
• smyšlení autoři, fotografie a kvalifikace,
• strukturovaná data, která slibují něco, co stránka neobsahuje.

Průvodce tvorbou užitečného obsahu se ptá, zda je jasné, kdo za obsahem stojí, a zda stránka vznikla pro lidi, nebo pro návštěvnost z vyhledávání. V průvodci optimalizací pro generativní funkce zveřejněném v říjnu 2026 Google zdůrazňuje nekomoditní obsah a varuje před stránkami pro každou variantu dotazu.

Prakticky to znamená přepsat AI texty, které nic nového neříkají, doplnit vlastní zkušenost nebo data a uvést skutečného autora s biografií. Pro firmy je to dobrá zpráva: obor, zákazníky a vlastní postupy znají jen ony a právě to model nevygeneruje.

Časté otázky

Jak zjistím, jestli je můj web v Googlu indexovaný?

Nejspolehlivěji v Google Search Console. Po ověření webu ukáže přehled indexování, které stránky Google zaindexoval a proč jiné vynechal, například kvůli noindex, přesměrování nebo duplicitě. Nástroj pro kontrolu URL navíc zobrazí, jak Googlebot konkrétní stránku vidí včetně vykresleného HTML. Dotaz s operátorem site: ve vyhledávání dává jen orientační představu, ne úplný seznam.

Jak dlouho trvá, než se nový web objeví ve výsledcích Googlu?

Pevná lhůta neexistuje a Google žádnou nezaručuje. Záleží na tom, jak snadno Googlebot web najde, zda je odeslaná sitemap, jestli na web vedou odkazy odjinud a jak rychle server odpovídá. U nového webu jde spíš o dny až týdny než o hodiny. Odeslání sitemap a žádost o indexování v Search Console proces urychlí, ale pořadí ve výsledcích neovlivní.

Je Lighthouse skóre ranking faktor Googlu?

Ne, skóre Lighthouse samo o sobě ranking faktor není. Google pracuje s metrikami Core Web Vitals z dat reálných uživatelů, tedy s LCP, INP a CLS, které vidíte v Search Console. Lighthouse je laboratorní nástroj pro ladění a hlídání regresí. Vysoké skóre je užitečný signál, že je stránka technicky v pořádku, ale nezaručuje lepší pozici ani lepší zkušenost návštěvníků.

Musí být web na SSR, aby ho Google zaindexoval?

Nemusí, Google umí vykreslovat JavaScript. Vykreslování na klientovi ale přidává krok, který může indexaci zpozdit nebo selhat, pokud skript spadne či je blokovaný v robots.txt. Server-side rendering nebo statické generování pošle obsah rovnou v HTML, takže ho Googlebot přečte hned. U webů z AI, kde chyby ve vykreslování bývají časté, je to bezpečnější volba.

Mám na webu označit, že text vznikl pomocí AI?

Povinné to není a samotné označení o kvalitě nerozhoduje. Google doporučuje transparentnost tam, kde ji čtenář rozumně očekává, například u obsahu, jehož věrohodnost závisí na tom, jak vznikl. Důležitější než štítek je, aby text měl skutečného autora, ověřené informace a vlastní přidanou hodnotu. Falešný autor nebo smyšlená kvalifikace jsou problém bez ohledu na to, zda text psal člověk, nebo model.