Jak vypadá SEO zadání pro vývoj: nález, důkaz, akceptační kritéria

Zadání pro vývoj je popis jedné změny, kterou lze nasadit a potom ověřit. Má nález, důkaz, rozhodnutí, kroky, akceptační kritéria a způsob kontroly.

V auditech, se kterými pracuji, se SEO doporučení k vývoji často dostávají v jiné podobě. Jako řádek v tabulce nebo odstavec v prezentaci. Vývojář z toho nepozná, co má udělat, ani kdy je hotovo.

Rozdíl mezi auditem, který se nasadí, a auditem, který zapadne, vytváří v mé praxi často právě kvalita zadání. S hloubkou analýzy to obvykle nesouvisí.

Tato struktura vznikla z auditů, u kterých jsem sledoval, které úkoly se nasadily a které zůstaly ležet.

Proč vývoj SEO doporučení často odloží

Protože v podobě, ve které k němu dorazí, nejde odhadnout rozsah ani riziko.

Začíná to formátem. Vývojový tým pracuje s frontou úkolů, které mají odhad a definici hotového stavu. Položka „opravit přesměrování“ nemá ani jedno, takže se v plánování nedá s ničím porovnat. Odsune se za úkol, který popsaný je.

Zadání také běžně zamění cíl za změnu. „Zlepšit indexaci sekce“ je výsledek. Kdo takový úkol dostane do sprintu, musí nejdříve sám zopakovat analýzu, kterou už jednou někdo udělal.

Chybí i důkaz. Bez uložené odpovědi serveru, záznamu z Google Search Console (GSC) nebo reprodukčního kroku se úkol zastaví u první námitky, že to tak přece funguje.

Nikde není napsáno, jak se pozná, že je hotovo. Testování nemá co ověřit, úkol se zavře, výsledek nikdo nezkontroluje a stejný nález se objeví v dalším auditu.

Pod tím vším leží jednodušší věc. Vývojář zná kód a nezná historii webu ani data z vyhledávání. Bez věty o tom, co se stane, pokud se úkol neudělá, nemá jak ho obhájit proti funkci, kterou chce obchod.

Anatomie zadání, které vývoj nasadí

Používám šest polí. Každé z nich odpovídá na otázku, která by jinak přišla v komentářích k úkolu.

U zadání kontroluji zejména důkaz a akceptační kritéria.

Důkaz posouvá diskusi z názorů na fakta. Datum u něj je stejně důležité jako obsah, protože stav webu se mění a půl roku starý snímek už nedokládá aktuální stav.

Akceptační kritérium musí jít splnit nebo nesplnit bez debaty. Určuje konkrétní příkaz, očekávaný stavový kód a cílovou adresu. Formulace „Přesměrování funguje správně“ takovou kontrolu neumožňuje.

U pole kroky platí opatrnost. Píšu, co se má stát a kde. Jak to napsat, je práce vývoje. Když znám soubor nebo nastavení, pojmenuji ho, protože to šetří hledání. Vývojáři mi z toho pak často vrátí lepší řešení, než jaké jsem měl v hlavě.

Hrubou náročnost odhaduji sám ve třech stupních, přesný odhad patří vývoji. Bez alespoň hrubého odhadu se ale priorita nedá obhájit.

Tři modelová zadání z vlastního webu

Dvě vznikla při auditu mipaco.cz 5. 9. 2026, třetí je vzor akceptačních kritérií pro migraci. Ukazuji je proto, že na klientských datech nemohu zveřejnit ani nálezy, ani čísla.

Přesměrování apex domény a staré adresy auditu

Nález: Požadavek na starou adresu /sluzby/seo-audit/ projde dvěma přesměrováními 308, než skončí na /seo-audit. Apex doména, tedy mipaco.cz bez www, vrací dočasný 307 na www.

Důkaz: curl -I, uložené odpovědi protokolu HTTP v souboru crawl.json, 5. 9. 2026.

Rozhodnutí: Nízká priorita, nízká náročnost. Opravit v jedné iteraci spolu s formulářem, nečekat na větší vydání.

Kroky:

1. Vercel Domains: přepnout přesměrování mipaco.cz → www.mipaco.cz na 308 Permanent.
2. next.config.ts: ověřit skipTrailingSlashRedirect. Test ukázal 404 na /sluzby/seo-audit/, změna se proto vrátila zpět a dvoukrokový řetězec zůstal přijatý a zdokumentovaný.

Akceptační kritéria:

• curl -I https://mipaco.cz/ vrací 308 a Location https://www.mipaco.cz/.
• curl -IL https://www.mipaco.cz/sluzby/seo-audit/ končí stavem 200 na /seo-audit nejvýše přes dva kroky 308.
• Žádná jiná URL ze sitemap.xml nezměnila stavový kód, ověřeno porovnáním s crawl.json.

Kontrola: Po nasazení opakuji curl na obě adresy a porovnám stavy všech 75 URL ze sitemapy proti auditnímu inventáři.

Druhý krok neprošel. Nejkratší varianta opravy v testu rozbila starou adresu, takže kritérium připouští dva kroky 308 a zkrácení řetězce jsem nechal na pozdější úpravu směrování.

Kritérium zachování ostatních stavových kódů chrání zbytek webu. Bez něj lze úkol splnit a přitom rozbít odpovědi na jiných adresách. Dobré kritérium popisuje i to, co se změnit nesmí.

Stránka, kterou Google nemá v indexu

Nález: Stránka /seo-ai je v sitemapě, meta robots má hodnotu index, kanonická adresa vede na ni samotnou, a přesto k 5. 9. 2026 v indexu Googlu není.

Důkaz: GSC, kontrola URL: Googlebot pro mobilní zařízení stránku stáhl úspěšně, procházení i indexace jsou povolené, výsledek „URL is not on Google“.

Rozhodnutí: Střední priorita. Zjevnou blokaci přes robots, noindex nebo nedostupnost stránky kontrola neukázala, ostatní technické příčiny jako duplicita, jiná kanonická adresa nebo soft 404 zatím vyloučené nejsou. Příčinu hledám nejdříve v interních odkazech a hodnotě stránky.

Kroky:

1. Přidat kontextový odkaz na /seo-ai z /blog/ai-v-seo a /blog/llm-a-vyhledavani, v první třetině textu.
2. Do rozcestníku na domovské stránce přidat položku Viditelnost v AI vyhledávání s odkazem na /seo-ai.
3. Přesunout sekci s výstupem a cenou nad odborný výklad, jako samostatnou změnu textu.

Akceptační kritéria:

• /seo-ai má nejméně tři interní odkazy z jiných stránek webu, jejich existenci ověřím novým procházením webu. Indexaci zdrojových stránek kontroluji samostatně v GSC.
• /seo-ai vrací stav 200, meta robots má hodnoty index a follow, kanonická adresa vede na ni samotnou a adresa je v sitemap.xml.

Kontrola: Po nasazení požádám o indexaci ručně v GSC. Po 14 a 28 dnech zaznamenám stav indexace v GSC jako výsledkovou metriku experimentu a výsledek zapíšu do záznamu experimentů. Indexaci Google negarantuje ani u stránky, která technické požadavky splňuje.

Tady je rozhodnutí důležitější než kroky. Kdyby zadání znělo jen „opravit indexaci /seo-ai“, vývoj by mohl hledat blokaci v kódu, přestože dosavadní kontrola žádnou zjevnou blokaci neukázala. Věta o výsledku kontroly proto patří přímo do zadání.

Ukázkou hranice je způsob kontroly. Indexaci nemám ve svých rukou já ani vývoj, takže do akceptačních kritérií nepatří. Vedu ji jako výsledkovou metriku experimentu. Kritéria zůstávají u věcí, které tým skutečně ovládá. Pozice ve výsledcích vyhledávání do zadání nepatří vůbec.

Akceptační kritéria pro migraci do Next.js

Toto zadání popisuje riziko, které ještě nenastalo. Vlastní web jsem stěhoval z WordPressu na statický web a v lednu 2026 na Next.js, takže vím, kde se to láme.

Nález: Při migraci mohou vzniknout chyby v mapování URL, kanonických adresách nebo strukturovaných datech. Dopad na výsledky vyhledávání se může projevit až při dalším procházení a indexaci.

Důkaz: Migrace mipaco.cz z WordPressu na statický web a v lednu 2026 na Next.js. Klientská čísla tu neuvádím.

Rozhodnutí: Akceptační kritéria patří do zadání dříve, než vývoj začne.

Kroky:

1. Schválená mapa starých a nových URL: každá stará adresa má odpovídající novou adresu a přímé trvalé přesměrování 301 nebo 308. Adresy bez relevantní náhrady vracejí 404 nebo 410.
2. Kanonické adresy a sitemapa používají odpovídající nové URL, hreflang odkazuje na správné jazykové verze, meta robots odpovídá zamýšlené indexaci a adresy v JSON-LD jsou aktualizované.
3. Stránky vykreslují hlavní obsah v HTML odpovědi i bez JavaScriptu.

Akceptační kritéria:

• Procházení staré sitemapy odpovídá schválené mapě u 100 % adres: náhrady vracejí přesměrování 301 nebo 308 jedním krokem s cílem ve stavu 200, odstraněné adresy vracejí 404 nebo 410.
• U vzorku 20 stránek odpovídají titulek, nadpis H1 a hlavní text původní stránce a kanonická adresa odpovídá nové URL podle schválené mapy.

Kontrola: Před spuštěním procházím testovací prostředí, po spuštění produkci, obojí porovnám. V GSC po 14 a 28 dnech porovnám důvody neindexace s výchozím stavem a prošetřím nové problémy související s migrací.

Co do zadání nepatří

Zadání se kazí přidáváním. Vyhazuji z něj:

• Vysvětlování, proč je SEO důležité: Ten spor se vede jinde a v úkolu jen prodlužuje čtení.
• Dvě změny v jednom úkolu: Jedna projde, druhá ne, a není co uzavřít.
• Doporučení bez cílového stavu: „Optimalizovat titulky“ nebo „zlepšit rychlost“ vývoj nemůže nasadit.
• Odhad v hodinách: Hrubý stupeň náročnosti stačí, přesný odhad dělá ten, kdo to bude psát.
• Sliby o pozicích: Zadání slibuje splněné kritérium a nic víc.
• Odkaz na celý audit: Do úkolu patří ta konkrétní pasáž, které se týká.

Pokud zadání přesahuje jednu obrazovku, kontroluji, zda nespojuje více samostatných rozhodnutí.

Jak zadání zkontrolovat po nasazení

Kontrola má dvě úrovně a obě patří do zadání předem.

Technická kontrola v den nasazení: Při ní spouštím přesně ty příkazy, které jsou v akceptačních kritériích. Výsledky porovnám s očekávaným stavem. Při neshodě ověřím implementaci i formulaci kritéria.

Datová kontrola: U indexace ji provádím po 14 a po 28 dnech. Google uvádí, že nové procházení může trvat od několika dní po několik týdnů, takže časná kontrola ještě nemusí zachytit jeho výsledek. Oba pevné body jsou můj vlastní harmonogram.

Každé nasazené zadání dostane řádek v záznamu změn: datum, co se změnilo, co jsem čekal, co se stalo. Ten záznam později usnadní posouzení, se kterou úpravou mohl výsledek souviset.

Když kritérium neprojde, úkol se vrací s odkazem na tu konkrétní odrážku, kterou nesplnil. Věta o tom, že to nefunguje, vývoji nepomůže.

Kudy začít

Kvalita zadání výrazně ovlivňuje, zda se SEO práce dostane do vývoje a půjde ověřit. Analýzu lze udělat znovu. Sprint, ve kterém se nic nenasadilo, se vrátit nedá.

Struktura z tohoto článku je výstupem, který dostáváte z mého SEO auditu webu. U problémů s procházením, vykreslováním a indexací na ni navazuje technické SEO, u aplikací vykreslovaných v prohlížeči potom JavaScript SEO.

Pokud vám audit leží půl roku bez nasazení, problém nemusí být v jeho obsahu. Vezměte jeden nález a přepište ho do těch šesti polí.