---
title: "SEO checklist pro web z AI v Googlu"
description: "Praktický SEO checklist pro web vytvořený pomocí AI: co změřit, co svěřit asistentovi a co musí ohlídat člověk, aby se web objevil v Googlu."
author: "Jan Černošek"
author_role: "Spoluzakladatel · Business & Consulting"
author_url: https://nobig.deals/cs/blog/autor/jan-cernosek
url: https://nobig.deals/cs/blog/seo-checklist-pro-web-ai
content_type: text/markdown
---

Autor: Jan Černošek (Spoluzakladatel · Business & Consulting)

[Blog](https://nobig.deals/cs/blog)/[SEO a viditelnost](https://nobig.deals/cs/blog/kategorie/seo-a-viditelnost)/SEO checklist pro web vytvořený pomocí A…

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

Web z AI se v Googlu neobjeví hlavně kvůli technickým základům: vykreslení na serveru, robots.txt, sitemap.xml a zapomenutým noindex tagům. Většinu oprav zvládne AI asistent, ale jen když nejdřív změříte stav a výsledek zkontrolujete.

[Jan Černošek](https://nobig.deals/cs/blog/autor/jan-cernosek)·Publikováno 31\. října 2026·11 min čtení

![Dvě serverové skříně vedle sebe: levá s neuspořádanou změtí kabelů, pravá s urovnanou kabeláží.](https://nobig.deals/_next/image?url=https%3A%2F%2Fassets.nobig.deals%2Fblog%2Fcmvwftj4m00000xutxcfujqd0%2Fseo-checklist-pro-web-ai-hero-68e86f6890.webp&w=3840&q=75)

Web z AI často potřebuje hlavně technické základy do pořádku.

Obsah článku · 7
1. [Proč se weby z AI nezobrazují v Google?](#proc-se-weby-z-ai-nezobrazuji-v-google)
2. [SEO checklist pro web: technické SEO krok za krokem](#seo-checklist-pro-web-technicke-seo-krok-za-krokem)
3. [Indexace a vykreslování](#indexace-a-vykreslovani)
4. [Crawl a interní odkazy](#crawl-a-interni-odkazy)
5. [Jak nastavit canonical, titulky, meta popisy a schema?](#jak-nastavit-canonical-titulky-meta-popisy-a-schema)
6. [Jaká má být hodnota CLS a rychlost načtení?](#jaka-ma-byt-hodnota-cls-a-rychlost-nacteni)
7. [Laboratoř vs. reální uživatelé](#laborator-vs-realni-uzivatele)
8. [Příklad testu v CI](#priklad-testu-v-ci)
9. [Co z checklistu zvládne AI a co zůstává na lidech](#co-z-checklistu-zvladne-ai-a-co-zustava-na-lidech)
10. [Jak Google zachází s obsahem vytvořeným pomocí AI?](#jak-google-zachazi-s-obsahem-vytvorenym-pomoci-ai)
11. [Časté otázky](#caste-otazky)

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.

Ve zkratce

* Weby z AI obvykle nechybí obsah, ale technické základy: SSR, indexace, canonical, sitemap a metadata.
* Google nepenalizuje obsah jen proto, že vznikl pomocí AI, ale hromadný obsah bez přidané hodnoty a falešné autory.
* CLS do 0,1 je dobrý výsledek podle Googlu, nad 0,25 je špatný; 2 sekundy jsou cíl ze zdrojového promptu, ne oficiální metrika.
* Postup, který funguje: změřit, nechat AI opravit konkrétní problém, zkontrolovat git diff a testy v CI.
* Autentický obsah, skutečný autor a zpětné odkazy zůstávají na lidech.

## 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.

| Nástroj                   | Co kontroluje                                  | Typ dat                      |
| ------------------------- | ---------------------------------------------- | ---------------------------- |
| Google Search Console     | Indexace, sitemap, Core Web Vitals             | Reální uživatelé a Google    |
| Screaming Frog SEO Spider | Status kódy, přesměrování, canonical, metadata | Vlastní crawl                |
| PageSpeed Insights        | Výkon stránky                                  | Laboratoř i reální uživatelé |
| Lighthouse                | Výkon, přístupnost, SEO                        | Laboratoř                    |
| Rich Results Test         | Strukturovaná data                             | Validace kódu                |

Rozdíl mezi laboratorními a terénními daty popisuje Google v [dokumentaci k PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about).

Pozor

Nejčastější důvod, proč nový web v indexu vůbec není, je `noindex` nebo plošná blokace v `robots.txt` převzatá z vývojového prostředí. Zkontrolujte produkční build, ne lokální verzi.

Než zadáte opravy AI asistentovi

* Ověřte web v Google Search Console a uložte si stav indexace.
* Projeďte web crawlerem a exportujte chyby.
* Zkontrolujte, že produkční HTML obsahuje text stránky bez JavaScriptu.
* Otevřete `robots.txt` na produkční doméně.
* Vyhledejte v kódu všechny výskyty `noindex`.
* Odešlete `sitemap.xml` v Search Console.

## 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:

```tsx
// 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](https://developers.google.com/search/docs/essentials/spam-policies) řadí mezi zavádějící techniky.

Příklad

SEO prompt pro AI s konkrétním omezením: „Doplň metadata do všech rout v `app/`. Titulek a popis ber z dat, která stránka zobrazuje, nikdy je nevymýšlej. Canonical nastav na čistou URL bez parametrů. FAQ schema přidej jen na stránky, které mají viditelnou sekci s otázkami. Nakonec vypiš seznam stránek, kde data pro titulek chybí, a nic za ně nedoplňuj.“

## 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](https://developers.google.com/search/docs/appearance/core-web-vitals) 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í.

Klíčová čísla

* **0,1** je horní hranice dobrého CLS podle [Googlu](https://developers.google.com/search/docs/appearance/core-web-vitals)
* **0,25** a víc znamená špatný CLS podle [Googlu](https://developers.google.com/search/docs/appearance/core-web-vitals)
* **2,5 s** je hranice dobrého LCP v [dokumentaci Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals)

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](https://developers.google.com/speed/docs/insights/v5/about) 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:

```bash
# 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:

```js
// 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.");
```

Tip

Měřte v CI mobilní i desktopový profil a vedle hlavní stránky aspoň jednu šablonu článku nebo produktu. CLS se často objeví jen na jednom typu stránky.

## 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á.

![Dvoje ruce drží uprostřed svazek stránek s oranžovým pruhem, dole leží tužka.](https://assets.nobig.deals/blog/cmvwftj4m00000xutxcfujqd0/seo-checklist-pro-web-ai-img-1-1b3b3ea90b.webp)

AI změnu navrhne, člověk ji projde a schválí.

Postup

1. **Změřte výchozí stav.** Uložte si report ze Search Console, crawleru a Lighthouse, aby bylo s čím porovnávat.
2. **Zadejte jeden problém.** Asistent dostane konkrétní nález, například posun rozložení způsobený cookie lištou, ne celý checklist najednou.
3. **Omezte rozsah změny.** Požadujte úpravu jen relevantních souborů a zachování vzhledu i chování mimo opravu.
4. **Zkontrolujte git diff.** Člověk projde každou změnu a ověří, že řeší příčinu, ne symptom.
5. **Spusťte testy v CI.** Lighthouse, přístupnost a regresní testy musí projít dřív, než změna jde do produkce.

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.

Výhody a nevýhody

Co svěřit AI asistentovi

* Metadata, canonical a strukturovaná data generovaná z obsahu stránky
* Převod obrázků do WebP a doplnění rozměrů
* Opravy přesměrování, rozbitých odkazů a `robots.txt`
* Spouštění testů a čtení reportů

Co zůstává na lidech

* Rozhodnutí, která změna řeší příčinu
* Originální obsah a odborné know-how
* Skutečný autor s ověřitelnou biografií
* Zpětné odkazy z webů, kterým lidé věří

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](https://nobig.deals/cs/sluzby/ai-transformace) 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ů](https://nobig.deals/cs/sluzby/ai-agenti), 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](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) 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](https://developers.google.com/search/docs/essentials/spam-policies) 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](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) 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](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide/) 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.

Poznámka

Google nezveřejňuje detektor AI textu ani hranici, od které postih nastává. Měřítkem je hodnota pro čtenáře, ne to, zda text napsal člověk, nebo model.

## Č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.

Zdroje a odkazy (6)

Externí stránky, na které článek odkazuje.

1. [developers.google.com](https://developers.google.com/speed/docs/insights/v5/about) /speed/docs/insights/v5/about
2. [developers.google.com](https://developers.google.com/search/docs/essentials/spam-policies) /search/docs/essentials/spam-policies
3. [developers.google.com](https://developers.google.com/search/docs/appearance/core-web-vitals) /search/docs/appearance/core-web-vitals
4. [developers.google.com](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) /search/docs/fundamentals/using-gen-ai-content
5. [developers.google.com](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) /search/docs/fundamentals/creating-helpful-content
6. [developers.google.com](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide/) /search/docs/fundamentals/ai-optimization-guide