Automatizace, která neřeší rozhodnutí

Gus Pelogia z Moz ukazuje, jak malé interní AI nástroje šetří hodiny rutiny v SEO: od párování URL přes hreflang až po sledování entit. Nejde o zázrak, ale o chytřejší práci s daty.

---

Ruční párování URL, kontrola entit nebo hledání souvisejících stránek vám vezme hodiny, aniž by šlo o skutečné rozhodování. V ukázkách, které Gus Pelogia popisuje na Whiteboard Friday pro Moz, nejde o další AI SaaS. Jde o malé interní nástroje, které vrátí hrubý návrh k vaší kontrole a zkrátí rutinu, jež vás dnes zdržuje.

Realistický přínos malých pracovních nástrojů

V praxi nejde o to, abychom si vyráběli další velký produkt a snili o převratu na trhu. Podle Whiteboard Friday, autora Gus Pelogia a webu Moz má tahle cesta mnohem střízlivější cíl: udělat malé pomocníky pro rutinu, které ušetří čas, vezmou na sebe nudnou část práce a nechají člověku prostor na posouzení výsledku.

To je podstatný rozdíl oproti běžnému marketingovému vyprávění, které rád prodává automatizaci jako hotové řešení. V reálné práci ale většinou vítězí nástroj, který vrátí hrubý návrh, se kterým si umíme dál poradit sami. Nečekáme zázrak, čekáme úsporu desítek drobných kroků, které se denně opakují a berou energii.

Právě v tom je síla malých nástrojů. Neřeší všechno, nechtějí nahradit úsudek a nedělají z operativy strategii. Dělají přesně to, co v týmu často chybí nejvíc: zkrátí práci, kterou by jinak člověk odklikal nebo přepsal ručně, a vrátí nám výsledek k rychlé kontrole. Pro SEO i širší marketing je to praktický posun, ne technologické divadlo.

Whiteboard Friday, Gus Pelogia a Moz tím vlastně připomínají jednoduchou věc: hodnota není v tom, že nástroj působí chytře, ale že se používá každý den. Když z běžné rutiny vezme pár opakovaných úkonů, začne dávat smysl i bez velkých ambicí. A právě tehdy se z experimentu stane opravdu užitečná pracovní pomůcka.

Provozní minimum pro spuštění vlastních nástrojů

Když se bavíme o vlastních SEO nástrojích, většinou stačí méně, než čekáme. Nepotřebujeme hned složitou infrastrukturu ani vývojářský stack, který zabere víc času než samotná úspora práce. V praxi se opíráme o LLM, případně o API a o prostředí, kde vůbec dokážeme kód spustit.

Autor začíná v ChatGPT, ale smysl má i jiný model. Důležité je, aby zvládl navrhnout použitelný základ a aby z něj šel dostat výstup, který dál upravíme. Právě tady se láme běžná představa o AI nástroji: nejde o hotové řešení bez zásahu člověka, ale o hrubý pracovní návrh.

Jakmile má nástroj sáhnout ven za samotný model, přichází na řadu API. To propojí model s místem, kde poběží kód a odkud si bude tahat vstupy nebo vracet výsledky. Bez toho často zůstane člověk u hezkého nápadu v chatu, který se v provozu nikam nepřenese.

Pro spuštění kódu autor zmiňuje Google Colab. Jde o Python prostředí v prohlížeči, takže odpadá instalace a první technická bariéra. Pro lidi, kteří chtějí rychle otestovat postup bez zbytečného nastavování, je to nejpřímější cesta.

Alternativou je Google Sheets, pokud dává větší smysl pracovat v prostředí, které tým už zná. V praxi to bývá často pohodlnější než honit se za „správným“ technickým řešením. Nástroj pak může běžet v tabulce a přitom dělat práci, kterou bychom jinak skládali ručně.

Nejlépe funguje kombinace obojího. Colab dává prostor pro Python a rychlé testování, Sheets zase pro práci s daty a kontrolu výsledků. Pro spuštění vlastních nástrojů to obvykle stačí. Zbytek bývá už jen snaha vypadat sofistikovaněji, než situace skutečně vyžaduje.

Pravidla pro psaní promptů k použitelnému výstupu

Jakmile chceme po modelu víc než jen obecný nápad, rozhoduje pořadí informací v zadání. V praxi se nám osvědčuje začít úplně od země: pro jaké prostředí má kód vzniknout. Gus Pelogia v rámci Whiteboard Friday pro Moz ukazuje, že prompt má rovnou říct, zda jde o Google Colab nebo Google Sheets. Tím AI hned ví, v jakém prostředí se má pohybovat a jak má výstup vypadat.

Stejně důležité je hned přidat, jaké API má volat. V autorově případě jde o OpenAI API. Tohle není drobný detail, ale základ pro to, aby model nepsal univerzální pseudokód, který pak stejně nepoužijeme. Když požadavek API nepojmenujeme, dostaneme často hezky vypadající, ale provozně nepoužitelný výsledek.

Další krok je stejně praktický: říct si o CSV vstup i CSV výstup. Autor pracuje s CSV daty, takže prompt má počítat s tím, že stejné CSV se nahraje a stejné CSV se vrátí upravené. V běžné praxi se tady často ztrácí čas na ruční převody formátů. Přitom právě formát bývá to, co rozhodne, jestli se nástroj dá použít hned, nebo skončí v šuplíku.

Pak má přijít popis datových sloupců. Ne obecně, ale konkrétně: co je ve sloupci A, co ve sloupci B a co ve sloupci C. Tohle je přesně ten moment, kdy se prompt mění z vágního zadání na použitelný pracovní pokyn. AI pak nemusí hádat, kde leží vstup, kde má hledat souvislosti a kam má zapisovat výstupy.

Smysl celého postupu je jednoduchý: model musí přesně poznat vstupy i výstupy. Když mu určíme prostředí, API, formát a strukturu tabulky, dostaneme výsledek, který už jen doladíme. Bez toho často vzniká kód, který působí správně na první pohled, ale v realitě naráží na nesoulad mezi daty a tím, co má dělat.

Základní technické pojmy a práce s API

V praxi se nejvíc zasekáváme ne na samotném nápadu, ale na slovní zásobě kolem něj. Když chceme z mini nástroje dostat něco použitelného, musíme vědět, co od modelu, API a dat vlastně chceme.

Embeddingy fungují jako převod textu na čísla. Neřeší jednotlivá slova izolovaně, ale zachycují význam stránky jako celek. Právě proto se hodí tam, kde nechceme ručně porovnávat desítky nebo stovky položek podle dojmu.

Kosinová podobnost pak porovnává, jak blízko si jsou dva nebo více takto převedených korpusů. V praxi tak srovná stránky A, B a C, případně i jiné hodnoty ve sloupcích, a ukáže, které záznamy k sobě významově sedí.

To je rozdíl proti běžné marketingové rutině, kde se často páruje ručně podle názvu, intuice nebo rychlého otevření pár URL. Embeddingy a kosinová podobnost dělají z podobnosti datový problém, ne pocitový odhad.

Zdroj zmiňuje i další API, například Google Knowledge Graph API. Pointa je prostá: musíme znát přesný název služby a mít vlastní API klíč. Bez něj se k datům nedostaneme.

U některých služeb navíc platí, že se cena odvíjí od používání, což se týká třeba OpenAI. Jiné mají aspoň bezplatné limity, jako Gemini nebo Google Knowledge Graph. I to je součást technického plánování, ne jen detail do poznámky pod čarou.

V citovaném Moz materiálu se pracuje právě s tímto minimem. A to nám v praxi stačí: vědět, co embedding porovnává, co dělá kosinová podobnost a jak se připojit přes API klíč ke službě, kterou nástroj volá.

Shoda tagů

V praxi se často začíná ručním dohledáváním, kam který tag nebo výzva k akci patří. U většího webu je to rychlá cesta k únavě a nekonzistentním rozhodnutím. V popsaném postupu šlo o jednodušší a poctivější variantu: nahrát data, nechat model navrhnout shody a až potom výsledek projít ručně.

Autor měl před sebou velké množství stránek a neměl jasný bod, od kterého se odrazit. Místo ručního rozřazování proto připravil vstupní tabulku tak, že do jednoho sloupce vložil tagy a do dalších dvou sloupců URL a embeddings. Tím si vytvořil základ pro srovnání, které už nepracuje s dojmem, ale s podobností dat.

Pak zadal ChatGPT, aby položky spojil. Podstatné je, že nejde o volné „navrhněte něco“, ale o práci nad připravenými sloupci. Právě proto se celý krok dá zrychlit bez toho, aby člověk začínal od nuly a ručně přemýšlel nad každou stránkou zvlášť.

Samotné zpracování proběhlo přes vektorové embeddings a kosinovou podobnost. V běžné praxi se tagy často párují podle intuice nebo podle několika náhodně otevřených URL. Tady funguje lépe hromadné porovnání, které umí vyhodnotit shodu napříč větším objemem dat a vrátí použitelné kandidáty k finální kontrole.

Kód autor spustil v Google Colab, takže si celý postup zjednodušil na prostředí, které dovolí rychle zpracovat data bez lokální instalace. Pro tento typ úlohy je to typický praktický kompromis: my nechceme stavět robustní systém, ale dostat z velkého seznamu stránky, které dávají smysl pro přiřazení tagu nebo CTA.

Hodnota podobného kroku není v tom, že by rozhodl za nás. Hodnota je v tom, že přesune práci od ručního párování k rychlému návrhu shod. Zůstane nám poslední kontrola, ale zmizí největší kus repetitivní práce, který u podobných SEO úloh běžně zdržuje nejvíc.

Sledovač důvěryhodnosti entit

V běžné praxi se pořád vrací stejný problém: chceme vědět, jestli Google chápe značku nebo jméno jako samostatnou entitu, a nechceme to kontrolovat ručně každý den. Právě tady dává smysl jednoduchý sledovač, který z odpovědi vytáhne, jak silná je důvěra v entitu, a výsledek pošle rovnou do tabulky.

V popsaném případě autor sledoval vlastní značku i vlastní jméno. Nešlo mu o jednorázovou kontrolu, ale o průběžný přehled, jestli se u položky objevuje znalostní panel a jak se v čase mění míra důvěry. Z praktického hlediska je na tom cenné hlavně to, že si člověk nemusí pokaždé znovu otevírat vyhledávání a dělat stejnou rutinu od začátku.

Řešení postavil v Google Sheets a nastavil ho tak, aby kontrolu provedlo automaticky každý den. Výsledek se ukládá přímo do tabulky, takže vzniká jednoduchá časová řada bez ručního přepisování. Podle autora běží řešení už rok, což je pro podobný pracovní nástroj důležitější než jakákoli efektní ukázka.

Z redakčního pohledu je na tom vidět rozdíl mezi běžnou marketingovou praxí a tím, co skutečně pomáhá. Ruční kontrola vypadá levněji, ale v pravidelném provozu spolkne víc času a stejně nepřinese systematický přehled. Automatický ping do Sheets naopak dává opakovatelný výstup, který se dá dál porovnávat bez improvizace.

Právě v tom je síla podobných mini nástrojů. Neřeší strategii za nás, ale odstraňují nudnou část práce a vracejí nám data v podobě, se kterou se dá dál pracovat.

Shoda hreflang

U hreflang se v praxi často začíná zbytečně ručně. My pak sedíme nad jazykovými verzemi a skládáme je po jedné, místo abychom si nechali připravit rozumný návrh.

Právě v tomhle bodě dává smysl nástroj založený na embeddingách. Do něj se nahrají embeddingy původní stránky i embeddingy stránek, které mají dostat přiřazení. Výsledek není finální verdikt, spíš kandidát na propojení.

To je rozdíl proti běžné praxi, kde se hreflang mapuje od nuly a člověk snadno ztratí čas už na prvním kole párování. Zde dostane hotový návrh, který zkrátí úvodní fázi a posune práci rovnou k ověření smysluplnosti.

Podle Guse Pelogie v Whiteboard Friday od Moz funguje tahle cesta i u webů ve více jazycích, ne jen u angličtiny nebo úzkého jazykového setu. To je podstatné hlavně tam, kde ruční orientace v jazykových mutacích rychle narazí na kapacitu týmu.

Autor zároveň zdůrazňuje, že výstup má zůstat jen jako návrh. My ho potom ručně projdeme a kontrolujeme, zda vazba mezi stránkami skutečně dává smysl. Tím se z automatizace nestává slepá zkratka, ale praktický filtr, který odstraní část práce na začátku.

Sledovač úpadku obsahu

V praxi často začínáme až ve chvíli, kdy návštěvnost klesne a ruční kontrola jednotlivých URL přestane dávat smysl. Whiteboard Friday / Gus Pelogia / Moz tu míří na přesně ten problém: neřešit po jedné stránce, ale dostat hromadný přehled o tom, co se v čase zhoršilo a co naopak drží.

Pointa není v tom, že nástroj za nás opraví obsah. Udělá datovou práci, kterou bychom jinak lámali po kusech ručně. Místo porovnávání návštěvnosti před dvěma lety a dnes na každé URL zvlášť dostaneme souhrn, kde je vidět, které stránky spadly, které si polepšily a o jaký rozdíl jde za sledované období.

To je v marketingové praxi důležitý posun. Mnoho týmů pořád tráví čas dohledáváním, kde přesně ztráty vznikly. Jenže samotné hledání příčiny výkon nenapraví. Hodnota sledovače úpadku obsahu je v tom, že zkrátí diagnostiku. Teprve potom má smysl řešit, jak vrátit obsah nebo stránku na správnou cestu.

Whiteboard Friday / Gus Pelogia / Moz tím vlastně dává realistický obraz práce s obsahem: nejdřív rychle zjistit rozsah problému, pak teprve přepnout na nápravu. A právě v tomhle pořadí dává podobný nástroj smysl.

Hledání souvisejících stránek

V praxi nejde o další hezkou hračku na vyplnění času. Jde o způsob, jak rychle vytáhnout stránky, které si spolu reálně sedí, a dát je do hry pro interní práci.

Běžný postup bývá ruční: někdo prochází URL jednu po druhé, hledá podobnosti podle názvu, tématu nebo intuice a doufá, že nic důležitého nepřehlédne. Tahle práce se ale snadno rozpadne na ad hoc dohledávání. Kombinace embeddingů a kosinové podobnosti funguje praktičtěji, protože porovnává nahraný seznam stránek systematicky a vrací množství shod, které by člověk ručně sbíral dlouho.

Podstatné je i to, co se do nástroje vlastně posílá. Nezačíná se od nuly, ale nahraje se seznam stránek a jejich embeddings. Z toho pak nástroj hledá související dvojice nebo skupiny, takže výstup slouží jako pracovní podklad, ne jako konečný verdikt.

Právě v tom je jeho síla. Nemá nahrazovat redakční nebo SEO úsudek, ale zkrátit první průchod daty a vytáhnout kandidáty, které bychom jinak hledali zbytečně ručně. Většinou jde o víc shod, než člověk čeká, a právě to dává smysl pro další ruční kontrolu.

Možný návod k principu popisuje i Moz v článku na blogu o interních příležitostech s vektorovými embeddingy: Internal Linking Opportunities with Vector Embeddings.

Největší úspora není v modelu, ale v tom, co už nemusíme dělat ručně

Když si tyhle malé nástroje shrneme z praxe, vychází z toho poměrně střízlivý závěr: jejich hodnota není v tom, že by nám nahradily SEO úsudek. Hodnota je v tom, že odnesou nudnou datovou práci, která zabírá čas, ale nepřináší rozhodnutí. A právě na rozhodování, kontrole a úpravách, které mají dopad, pak konečně zůstane prostor.

To je také dobrý moment k nepříjemnější otázce, kterou si v týmu občas klademe málo: kolik z naší současné SEO práce je skutečně expertní a kolik je jen mechanické přebírání, párování a přepisování dat. Pokud je většina času v tabulkách a ruční kontrole, není to známka preciznosti. Je to signál, že jsme si rutinu nechali přerůst přes hlavu.

Mini nástroje dávají smysl právě tam, kde se opakují stejné kroky pořád dokola. Neudělají z nás lepší marketéry samy o sobě, ale dokážou odstranit část práce, která expertní vůbec není. A to je často rozdíl mezi týmem, který jen zpracovává data, a týmem, který z nich opravdu dělá rozhodnutí.

Zdroj: moz.com

---