AI deníček: 5.9 – 11.9.2026, Rozcestníky na recepty z dat o hledanosti, měsíční rutina na nefunkční zpětné odkazy, favicony podle nové dokumentace Googlu

Minulý týden jsem s AI postavil rozcestníky na recepty podle hledanosti dotazů, udělal z kontroly nefunkčních zpětných odkazů měsíční rutinu a navrhl nový reporting pro jeden SaaS. Kromě toho jsem ladil pravidla robots.txt proti testovacím adresám, posílal data z exportů Search Console rovnou do tabulek a upravil audit favicon, protože Google změnil dokumentaci. Jak jsem u každé z těch věcí postupoval a co jsem musel rozhodnout, najdete níž.

Receptové rozcestníky: z exportu hledanosti jsme vybírali nové vstupní stránky

Jeden e-shop má na webu recepty a v administraci je vede jako strukturované záznamy. Už dřív k nim měl několik rozcestníků, tedy vstupních stránek, které vypisují recepty k jednomu tématu, a nad nimi jeden hlavní rozcestník.

Osmého září jsem Claudovi poslal export hledanosti dotazů se slovy „recept“ a „recepty“ z Ahrefs. Měl z něj vytáhnout dotazy, ke kterým má e-shop podle jeho odhadu aspoň tři recepty, a posoudit, jestli jimi vyplnit stávající rozcestníky, nebo pro ně vytvořit nové ve stejném stylu. Zároveň měl promyslet, jak je zařadit do hierarchie, jestli to platforma e-shopu vůbec dovolí a jak kolem nich postavit drobečkovou navigaci a rozcestník pro další vstupní stránky. Předpokládal jsem, že jich bude hodně, takže půjde i o úlohu pro použitelnost webu.

Recepty si Claude nejdřív stáhl do vlastní aktuální databáze na disku. Při každém dotazu tak nemusel procházet administraci a hledal rovnou v souborech. Pro celý e-shop jsme zapsali pravidlo, že názvy kategorií budou v množném čísle, i když lidé častěji hledají jednotné. Kategorie vždycky obsahuje víc položek a tuhle hledanost pokryjeme i tak.

Dřív jsme u jedné značkové stránky nasadili CSS, díky kterému jde obsah upravovat v administraci jako text, aniž by se rozbily styly. Tuhle úpravu jsem chtěl přenést na celou sadu stránek, které jsme spolu vytvořili, a k tomu i šipky mezi odstavci, které zdobí značkovou stránku. Ještě jsem se ptal, proč se rozcestník načítá dlouho. Nejdřív naběhne šablona se záhlavím a menu, obsah rozcestníku se objeví až po dlouhé chvíli.

U boxu „Všechny recepty v této kategorii“ jsem chtěl místo obecného textu konkrétní název, tedy „Všechny recepty na [kategorii]“. Vedle boxu „Související témata“ s odkazy na ostatní rozcestníky jsme přidali box „Co nakoupit“ ve shodném vzhledu. Nabízí kategorie zboží, které se hodí k receptům v daném výpisu. Obojí jsme doplnili i na nové stránky.

Meta titulky měly vzor, ve kterém se stejné slovo opakuje dvakrát, a to mi vadilo. Nový vzor začíná vždycky frází „recept na [něco]“, protože to je hlavní cíl a v titulku chybět nesmí. Další přívlastek lidé hledají méně, a proto patří až za tuhle frázi, třeba do závorky. Varianty jsem si nechal nejdřív navrhnout.

Na stránky s výpisem receptů jsem navrhl strukturovaná data ItemList, tedy seznam, ve kterém každou položku tvoří recept s náhledovým obrázkem a názvem. Než jsme první rozcestník publikovali, ověřil jsem nasazení sám na náhledové verzi. Ostatní šly ven hned po něm.

Založili jsme evidenci toho, co už je pokryté, co zbývá a o jakou hledanost jde. K ní jsme připravili CSV pro nástroj na sledování pozic Collabim: v prvním sloupci klíčové slovo, ve druhém adresa rozcestníku, který ho má pokrýt.

Rozcestníky jsem chtěl v analytice poznat jako samostatnou skupinu podle regulárního výrazu. Ověřovali jsme proto, jestli všechny adresy končí na „-recepty“. Zvažoval jsem i unikátní koncovku typu „-recepty-rozcestnik“, jenže kvůli ní bych musel přesměrovat všechny existující adresy. Rozhodl jsem se pro regulární výraz na stávající tvar a pro další stránky jsem zavedl pravidlo, že nová adresa bude vždy končit stejně jako ty stávající.

„Tam, kde máme čtyři recepty, chci taky rozcestník,“ rozšířil jsem zadání. Přibyla i rutina, která hlídá přidávání nových receptů na rozcestníky, a chtěl jsem, aby běžela každý týden.

Na mobilu ukazuje hlavní rozcestník recepty jako dvě dlaždice vedle sebe s náhledem 44 px a delší názvy neořezává. Tahle velikost se mi líbila. Upozornil jsem ale, že dlaždice má text i obrázek u spodní hrany a nahoře zbývá víc místa. Stejný mobilní vzhled jsem potom přenesl na jednotlivé rozcestníky, „abychom na mobilních zařízeních dokázali zobrazit uživatelům více obsahu na stejné ploše“.

CSS jsem na web vkládal ručně a Claude po každé změně ověřil výsledek na živé verzi. Na závěr jsme celou rozcestníkovou sekci popsali v klientské wiki.

Nefunkční zpětné odkazy: nástroj z Linki jsem převedl na měsíční rutinu

V Linki mám nástroj, který ověřuje nefunkční zpětné odkazy z Ahrefs. U téhož e-shopu ale nefungoval, protože jeho platforma vyžaduje vlastní HTTP hlavičku s omezenou platností.

Claude měl 8. září vzít mechaniku nástroje a udělat z ní skill s pevnou HTTP hlavičkou. Ta má omezenou platnost a budeme ji obnovovat, proto si skill musí hlídat datum a včas mě upozornit.

Nejdřív jsem si ověřil, že postup nesahá do celého odkazového profilu. Chtěli jsme šetřit spotřebované jednotky, a proto bere jen report Broken Backlinks a z něj dofollow odkazy, každý na jednom řádku, v režimu subdomény.

Postup smí přesměrovat jen zboží ve stavu „Archived“, a to umíme ověřit. Když chybí zboží stejné značky, je v pořádku vést přesměrování na podobné zboží jiné značky. Archivovanou položku, která nemá kam vést, postup přesměruje na kolekci, do které ji e-shop primárně zařadil. Navrhl jsem ještě kontrolu, jestli pro danou adresu přesměrování už neexistuje.

Při běhu vrátil server odpověď 429. Zeptal jsem se, odkud přišla, protože blog funguje jinak a hlavička pro něj neplatí.

Den nato mi přišlo, že „je těch redirectů hrozně moc“. Ptal jsem se, jestli jsme si jistí zdrojem dat v Ahrefs a tím, že přesměrováváme opravdu jen archivované zboží. Zároveň jsem chtěl vědět, kolik přesměrování už je v administraci celkem.

Postup teď ignoruje nefunkční odkazy z jedné spřízněné domény, protože „to je věc, kterou si vyřešíme sami“. Z celého postupu jsme nakonec udělali rutinu. Spustí se každý sedmý den v měsíci, a když přinese výsledek, založí mi úkol v Todoistu, „abych se dozvěděl, že to proběhlo“.

Pravidla pro roboty: testovací data jsem srovnal s tím, co web vrací

Jiný e-shop vede pravidla pro vyhledávací roboty (robots.txt) v tabulce. K nim mám postup, který je kontroluje proti listu testovacích adres a porovnává je s ostrou verzí webu.

Devátého září přišel na řadu řádek, ve kterém jsme pravidla rušili. Claude ho měl opravit, nakonec jsem ho ale ručně smazal a dal mu o tom vědět, aby ho to nepřekvapilo. Měl upravit adresy, které v listu testovacích dat neodpovídají, a pustit zkušební běh (dry-run) s výpisem nekonzistencí.

Testovací data jsem mezitím aktualizoval sám: všechny adresy prošly Screaming Frogem, který zjistil, jestli vracejí stavový kód 200, nebo jiný, a přitom ignoroval pravidla robots.txt. Každá testovací adresa teď má vracet 200, s výjimkou jedné skupiny kategorií. Ve dvou jazykových verzích web přesměrovává štítky jednoho filtru. Tuhle známou chybu řeším. Claude na ni má upozornit a nic víc s ní nedělá.

U dalšího filtru vývojáři změnili adresy zakódované v base64 na čitelné slugy a ze starého tvaru teď vede trvalé přesměrování 308. Ještě 9. září jsem to hlásil jako podezření na chybu a ověřoval ho s vývojáři. Desátého září jsme vyměnili adresy v testovacích datech a změnu zapsali do wiki, včetně vysvětlení, proč tahle úprava robots.txt nerozbila.

Pro novou doménu jsem upravil pravidla v tabulce a nechal je ověřit proti ostré verzi. Nasadil jsem je, přestože menu odkazuje na štítky, které zatím nefungují: „Já budu preventivně připravenej, až se to rozběhne.“ Pak jsem doplnil testovací adresy i pro ni.

Nakonec měl Claude připravit anglické shrnutí všech změn toho dne pro kolegy na Slacku, „stručně co a proč“.

Search Console: exporty indexace a procházení zapisuje postup do tabulek

Pro tentýž e-shop vedu Google tabulky s daty o indexaci a o procházení Googlebotem. Podkladem jsou exporty z Google Search Console, které stahuji jako ZIP.

Sedmého září jsem do postupu pro indexaci přidal novou doménu a jednu starou vyřadil, protože se přesměrovala jinam. Postup má navíc sám poznat, jestli ZIP obsahuje report indexace (coverage), nebo statistiky procházení (crawl stats).

Rozšířili jsme ho i o data o procházení. Ukládá je do druhé tabulky, kde má každá oblast samostatné listy pro desktop a pro mobil. Exporty budu posílat vždycky ve stejně zabalených ZIP souborech.

Při kontrole jsem narazil na datum v jiném formátu, než mají ostatní listy. „Bojím se, že to bude dělat problémy při čtení souborů v jiných platformách,“ napsal jsem. Formát jsme sjednotili.

Obecná verze téhož postupu běžela 7. září i pro ještě jiný e-shop, nad třemi ZIP exporty: dvěma se statistikami procházení a jedním s indexací.

Pro tenhle deníček jsem 8. září výsledek shrnul takto: „V téhle úloze jsme automatizovali stahování balíčků dat … o procházení a indexaci, tak aby se automaticky ukládaly do Google tabulek.“

Reporting pro SaaS: tabulka jako zdroj pravdy a report ve třech záložkách

Po hovoru o analytice a přínosu SEO jsem od jednoho SaaS dostal stávající PDF report. Nechal jsem Clauda popsat jeho strukturu a slabiny. Jedna mi byla jasná: v reportu je brand i non-brand dohromady. V poznámkách z hovoru už jsem měl sekci „Jak to udělat nově“ se svými nápady.

Jedenáctého září dostal Claude za úkol stáhnout všechna data, která mají smysl vzhledem k mým nápadům. Měl přístup do Ahrefs i do klientovy Search Console. Z dat měl vytvořit vzorovou tabulku se všemi možnými listy a podle ní potom navrhnout HTML report, který se bude blížit tomu, co dnes chtějí dostávat v PDF.

Chci z tabulky udělat zdroj pravdy s automatickým stahováním dat. Z ní pak buď v budoucnu vygeneruje HTML report Python skript, nebo tabulku propojíme s Looker Studiem, aby výstup mohl být dynamický.

Report jsem potom nechal doplnit o tři věci. Výkyvy pozic klíčových slov zobrazuje bodový graf. Rozložení do skupin 1–3, 4–10, 11–20 a zbytek jsme do tabulky spočítali pro celou datovou sadu dohromady, podobně jako rozložení pozic ukazuje Ahrefs. Celý report má tři záložky, celek, brand a non-brand, a nahoře přepínač.

„Horní část je skvělá, rychlý report pro CEO,“ napsal jsem k návrhu. Chyběly mi v ní ale non-brand metriky: „to je výkon SEO a ten chceme interně prodat.“

K výsledku jsem napsal „Líbí moc“ a zeptal se, jestli jde něco podobného postavit i v Looker Studiu. Potom měl Claude opravit dva řetězce, naklikat dashboard, doplnit AI a přebarvit report podle klientovy značky.

Favicony: v nové dokumentaci Googlu chybí SVG

Mám univerzální postup favicon-audit, který změří, co web nabízí Googlu jako ikonu. Kontroluje deklaraci v hlavičce, typ souboru proti výčtu podporovaných formátů, skutečné rozměry a dostupnost pro Googlebota. Vznikl na konci srpna 2026, kdy měl Google chybu v zobrazování favicon ve výsledcích vyhledávání.

V dokumentaci Googlu jsem si 10. září všiml změny: přesněji vyjmenovává podporované typy souborů a chybí mezi nimi třeba SVG. Postup jsme podle nové verze upravili a do jeho paměti jsem přidal odkaz na článek o srpnové chybě, aby bylo zřejmé, v jakém období vznikl.

Upravený audit jsem pak pustil na weby všech klientů zapsaných ve wiki.

U jednoho webu audit hlásil neúspěch kvůli ikoně ve formátu SVG. Ten web ale v hlavičce deklaruje dvě ikony, jednu SVG a druhou ICO, a toho jsem si všiml. Audit jsme proto rozšířili: když najde nepodporovaný formát, zkontroluje, jestli vedle něj není deklarovaná doplňková ikona, která podmínky splňuje.

Co přibylo do nástrojů

Vzniklo pět nových postupů a devět starších jsem upravil. Web jiného SaaS dostal vlastní publikační postup. Vznikl jako kopie toho, přes který publikuji na GeekLife, jen s jiným dokumentem stylu, bez affiliate odkazů a bez sdílení na sociální sítě. Kontrola kalků a stylu v něm zůstala. Náhledový obrázek umí vyrobit sám, v ilustračním stylu webu a z barev značky. Zkoušel jsem ho na článku o evropské peněžence digitální identity (EUDIW). Na vygenerovaném náhledu mi vpravo dole vadila hvězdička, a tak jsem si řekl, ať ji vynechá a poznamená si to. Další nový postup připraví tiskovou zprávu z mzdových dat jednoho webu. Čísla stáhne z BigQuery, text napíše přes Claude API a prožene ho faktickou i stylovou bránou ve smyčce oprav. Celý běh zvládne bez odklikávání. K zadání jsem napsal: „budeme to používat opakovaně a chceme, aby nad tím byla minimální lidská kontrola.“

Postup pro Mailchimp pracuje přes API s kontakty, importem CSV, štítky, segmenty, šablonami i kampaněmi. Každý zápis provede nejdřív jen nanečisto. Než odešle kampaň, musím potvrdit přesný počet příjemců. Postup na odkazové příležitosti hledá weby, které linkují na konkurenci, zatímco na klienta dosud žádný odkaz nevede. Než sáhne do Ahrefs API, spočítá odhad spotřeby jednotek a počká na potvrzení. Postavit jsem ho nechal podle veřejně popsaného postupu z webu rellmo.com. Převzatý designový nástroj impeccable dostal novou verzi.

Upravil jsem publikační postupy pro Domovistu, Domovy.sk a GeekLife. U Domovisty jsem nechal porovnat své ruční úpravy textu s původní verzí a roztřídit je do typů, aby se z nich stala pravidla. Změny dostal i audit favicon, zápis dat ze Search Console do tabulek i revize robots.txt popsané v předchozích sekcích. Úpravy dostaly také obecné nástroje na Search Console a Google Sheets. Totéž platí pro postup, ze kterého vzniká tenhle deníček. Na samostatné stránce najdete přehled toho, co pro mě AI dělá, popsaný podle situace, kdy se hodí.

Pointa týdne

U každé práce důsledně hledám, co může AI udělat místo mě, a uvažuji, jak to opakovaně využít. Kontrola nefunkčních odkazů se tenhle týden stala rutinou: sama se spustí vždy sedmého v měsíci a o výsledku mi dá vědět úkolem v Todoistu. Jednou týdně hlídá další rutina, jestli nové recepty přibývají i na rozcestníky. U dat o indexaci a procházení mi zbývá ručně jen stáhnout balíčky, zbytek se odehraje automaticky.

---

Poznámka: Deníček na základě týdenní práce generuje Claude, sám jej tu i publikuje. Tonalitu sdílí s mým tech blogem, kde se řídím týmž dokumentem. Klienti jsou popsaní obecně záměrně.