Jak pomocí Claude Code zanalyzovat crawl ze Screaming Frogu

Screaming Frog je skvělý crawler. Umí projít web, uložit stavové kódy, titulky, popisy, kanonické URL, interní odkazy, hloubku zanoření, obrázky, strukturovaná data, hreflang, bezpečnostní signály a desítky dalších věcí. Tím ale práce nekončí.

Crawl není audit. Crawl je sběr dat.

Audit začíná až ve chvíli, kdy z těch dat někdo udělá rozhodnutí: co je skutečný problém, čeho se týká, jak velký má dopad, co je jen šum a co má vývojář opravit jako první. A právě tahle část bývá nejtěžší. Ne proto, že by v datech nebyla odpověď. Spíš proto, že je schovaná v desítkách exportů a tisících řádků.

V re:LLMO jsme proto postavili plugin rellmo-sf-analysis pro Claude Code. Pracuje s hotovým crawlem ze Screaming Frogu, převede ho do lokální databáze, postaví nad ním sadu analytických pohledů a nechá specializované agenty napsat audit podle jednotné metodiky.

Co k tomu potřebuješ

Potřebuješ tři věci:

• hotový crawl ze Screaming Frogu ve formátu .seospider nebo .dbseospider,
• Claude Code s nainstalovaným pluginem rellmo-sf-analysis,
• vlastní licenci Screaming Frogu.

Plugin umí při prvním spuštění pomoct s instalací Screaming Frogu na macOS, Linuxu i Windows. Licenci ale neobstará. Bez platné licence Screaming Frog crawluje jen omezený počet URL, takže audit většího webu bude neúplný.

Důležité je i nastavení samotného crawlu. Pokud chceš, aby audit řešil výkon, přístupnost, JavaScript rendering, bezpečnostní hlavičky, cookies nebo validaci strukturovaných dat, musí být příslušné funkce zapnuté už při crawlu. Screaming Frog neumí většinu těchto dat dopočítat zpětně jen z uloženého souboru.

Jak plugin nainstaluješ

Plugin se distribuuje přes náš marketplace. Po nákupu ti dorazí licenční klíč a instalační příkaz. Ten už má klíč doplněný, takže ho jen zkopíruješ do terminálu.

Na macOS a Linuxu vypadá instalační příkaz takhle:

curl -fsSL "https://dist.rellmo.com/install/<tvuj-klic>?lang=cs" | sh

Na Windows se používá PowerShell varianta:

irm "https://dist.rellmo.com/install/<tvuj-klic>/ps1?lang=cs" | iex

Instalátor ověří licenci, přidá marketplace re:LLMO do Claude Code a nainstaluje plugin rellmo-sf-analysis.

Potřebuju GitHub účet nebo nějaké další klíče?

GitHub účet k tomu nepotřebuješ; přístup k repozitáři řeší distribuční worker podle licenčního klíče v instalační URL a v marketplace přístupu. Soubor ~/.rellmo/credentials se používá jen u pluginů, které přes rellmo-install.json vyžadují další API nebo MCP klíče. Crawl audit aktuálně žádné takové doplňkové credentials neukládá.

Po instalaci je potřeba Claude Code restartovat nebo reloadnout, aby se nově nainstalovaný plugin načetl.

Jak vypadá celý postup

V praxi to může začít obyčejným promptem:

Mám crawl example.dbseospider. Udělej baseline audit pro example.cz, crawl je z 2026-06-24.

Claude Code pak převezme orchestraci. Plugin postupuje zhruba takhle:

1. Ověří prostředí: uv, Python, DuckDB, Screaming Frog a licenci.
2. Vytvoří pracovní složku s lokální databází analysis.duckdb.
3. Přes Screaming Frog CLI vyexportuje CSV soubory z .seospider nebo .dbseospider.
4. Načte CSV do DuckDB, normalizuje názvy sloupců a vytvoří per-crawl schéma.
5. Postaví nad daty sadu v_* pohledů pro SEO analýzu.
6. Vygeneruje coverage.json, tedy mapu toho, co crawl opravdu obsahuje.
7. Spustí paralelní analytické agenty.
8. Report writer složí z nálezů audit, vyrenderuje HTML a připraví XLSX přílohy.
9. QA agent zkontroluje jazyk, konkrétnost, pokrytí a faktickou konzistenci.
10. Výsledkem je klientský balíček: report.html, audit.xlsx a vybraná CSV.

Databáze a exporty zůstávají jako lokální soubory v projektu. Claude Code do kontextu posílá jen výsledky dotazů, se kterými při analýze pracuje. Plugin používá DuckDB soubor analysis.duckdb; pro pozdější dotazování nepotřebuješ MotherDuck účet ani token.

Proč se crawl převádí do DuckDB

Screaming Frog exportuje hodně CSV souborů. To je pro člověka čitelné, ale pro systematickou analýzu nepohodlné. Jakmile chceš spojit status kódy s inlinky, kanonické URL se sitemapou, noindex s interním prolinkováním nebo výkon s indexovatelností, práce v tabulkách začne být křehká.

DuckDB z crawlu udělá dotazovatelnou databázi.

Plugin vytváří jedno analysis.duckdb na projekt. Každý crawl dostane vlastní schéma a nad ním vznikne sada expertních pohledů. Aktivní crawl je dostupný přes schéma active, takže se můžeš po auditu dál ptát přirozeně:

Ukaž mi indexovatelné stránky s nízkým link score.

nebo:

Které URL v sitemapě vrací 404 nebo redirect?

Claude nemusí držet celý crawl v kontextu. Dotazuje se databáze a vrací jen relevantní výsledek.

MCP server: dotazuj se na data přirozeným jazykem

Plugin zároveň nastaví MCP server pro Claude Code. Ten připojí lokální analysis.duckdb jako zdroj dat, se kterým může Claude pracovat přímo z chatu.

Samotný audit kvůli tomu nemusí čekat na restart. Během auditní fáze se agenti ptají přes query.py, aby se neztratila rozpracovaná konverzace. MCP je hlavně pro následné interaktivní dotazování po dokončení reportu.

Výchozí režim MCP je read-only. Běžným dotazem tedy nepřepíšeš databázi ani si nerozbiješ žádná data.

Deterministická vrstva: fakta bez interpretace

První část pipeline je záměrně neagentní. Skripty udělají mechanickou práci:

• načtou CSV,
• zkontrolují povinné tabulky,
• přeskočí prázdné nebo nepoužitelné exporty,
• postaví analytické pohledy,
• zapíšou manifest a coverage.json,
• vytvoří deterministický crawl-summary.json a crawl-summary.md.

Tohle není místo pro kreativní úsudek. Tady má být výsledek opakovatelný.

coverage.json je obzvlášť důležitý. Říká, které pohledy mají data, které chybí kvůli nastavení crawlu a které se nepovedlo postavit. Díky tomu report nerozmazává rozdíl mezi:

• prověřeno - data existují a problém se nenašel,
• nekonfigurováno - crawl danou oblast nesbíral,
• neúplné - data existují, ale jen částečně.

Tohle je drobnost, která zásadně zlepšuje kvalitu auditu. Jednojazyčný web bez hreflangu není problém. Vícejazyčný web bez hreflangu problém být může. A crawl bez zapnutého JavaScript renderingu neříká, že je renderování v pořádku; říká jen, že ho tenhle crawl neprověřil.

Agentní vrstva: úsudek nad daty

Teprve po databázové vrstvě nastupují agenti. Aktuální verze pluginu rozděluje audit mezi pět paralelních analytiků:

• indexability+canonicals+sitemap,
• links+link-equity+orphans+anchor,
• content+on-page-meta+structured-data,
• performance+accessibility,
• hreflang+security.

Každý agent dostane jen svůj okruh. Nečte všechno, nepíše celý report a neposílá orchestrátorovi obří výpisy z databáze. Nejdřív si přečte coverage.json, pak se ptá DuckDB přes query.py, seskupuje nálezy podle URL prefixů, šablon nebo konkrétních polí a vrací kompaktní JSON s nálezy.

Tohle rozdělení práce je podstatné. Velký technický audit snadno přeroste jeden kontext. Když jeden model najednou prochází odkazy, sitemapu, canonicaly, metadata, výkon, obrázky i bezpečnost, začne zkracovat, zapomínat a míchat symptomy s příčinami. Paralelní agenti drží každý svůj problém v samostatném kontextu.

Po nich může nastoupit sf-verify. Ten se nepouští na všechno. Ověřuje jen věci, které závisí na aktuálním stavu webu: robots.txt, sitemapu, kritické redirect smyčky, bot-detekci nebo kontrolu nejzávažnějšího nálezu.

Pak přijde report writer. Skládá nálezy napříč tématy, řeší překryvy a píše čitelný audit. Nakonec QA agent kontroluje, jestli report neobsahuje vymyšlená čísla, nepřesné formulace nebo neověřené živé tvrzení.

Metodika naší automatizace

Metodika pluginu používá diagnostickou pyramidu:

Crawl → Render → Index → Canonical → Link Equity → Content → Presentation

Nejdřív řešíme, jestli se crawler na URL dostane a jestli stránku dokáže vyhodnotit. Pak zda je indexovatelná a posílá správné signály. Teprve potom dává smysl hodnotit interní prolinkování, obsah, metadata, strukturovaná data, obrázky, přístupnost a bezpečnost.

Aktuální metodika pokrývá 15 hlavních témat:

• crawl efficiency,
• JavaScript rendering,
• výkon,
• indexovatelnost,
• kanonické URL,
• sitemapu vůči crawlu,
• interní prolinkování,
• link equity,
• duplicity a thin content,
• on-page metadata,
• strukturovaná data,
• hreflang,
• obrázky,
• přístupnost,
• bezpečnost.

V porovnávacím módu se přidává ještě migration delta, tedy porovnání dvou crawlů před a po migraci.

Jak se určují priority

Každý nález dostane slovní závažnost: critical, high, medium, low.

Agent ji neurčuje vzorcem. Rozhoduje podle tří věcí:

• dopad - blokuje to důležité stránky, plýtvá crawl budgetem, nebo jde jen o formální chybu bez většího dopadu,
• jistota - potvrzuje nález více pohledů, nebo jde o jednu heuristiku,
• náročnost opravy - je to jedna změna v šabloně, nebo bude oprava náročná?

Quick win je nález s vysokým dopadem a nízkou náročností. Typicky jedna šablona, která opraví stovky URL, nebo jedno pravidlo v robots.txt, které odblokuje důležitou sekci webu.

Každý nález musí stát na konkrétním místě: URL prefix, šablona, pole, počet zasažených URL a ukázková adresa. „Mnoho stránek má problém“ není nález. „147 z 320 indexovatelných URL pod /blog/ nemá canonical“ už nález je.

Stejně důležité je odfiltrovat falešné poplachy. Noindex na přihlášení, košíku, interním vyhledávání nebo filtrovacích URL může být záměr. Audit má upozornit na noindex na money pages, ne na každou neindexovatelnou URL.

Co dostaneš na výstupu

Výstup není jen odpověď v chatu.

Standardní běh připraví HTML report v re:LLMO šabloně, JSON payload, ze kterého se report renderuje, a klientský bundle s audit.xlsx a vybranými CSV. XLSX obsahuje URL seznamy k hlavním nálezům, takže vývojář nemusí dolovat konkrétní řádky z původních exportů.

Report má pevnou strukturu:

• závěr v několika odstavcích,
• tematické nálezy s doporučením,
• prioritizovaný seznam akcí,
• přehled toho, co bylo prověřeno,
• datové přílohy.

Příklad: proč propojení dat mění závěr

Samotný Screaming Frog ti řekne, že nějaké URL mají noindex. To ještě není auditní nález.

Zajímavé to začne být až ve chvíli, kdy se noindex spojí s dalšími daty:

• stránka je v hlavní navigaci,
• dostává stovky nebo tisíce interních odkazů,
• je v sitemapě,
• patří do kategorie nebo produktu,
• canonical míří sama na sebe.

Pak už nejde o běžnou neindexovatelnou stránku. Jde o místo, kam web posílá interní autoritu, ale Google ji nemůže využít. Takový nález má jinou prioritu než noindex na /kosik/.

Podobné je to s kanonickými URL. Jedna tabulka ukáže canonical mismatch. Jiná ukáže, jestli cílová URL vrací 200, zda není noindex, kolik má stránka interních odkazů a jestli se problém opakuje na jedné šabloně. Audit pak nehlásí deset podobných symptomů. Popíše jednu příčinu.

Po auditu se můžeš ptát dál

Protože data zůstávají v DuckDB, report není konec práce. Je to výchozí vrstva.

Po vygenerování auditu se můžeš v Claude Code doptávat:

Které indexovatelné stránky mají crawl depth větší než 4 a zároveň nízký link score?

Ukaž mi URL v sitemapě, které nejsou indexovatelné, seskupené podle důvodu.

Najdi stránky s thin contentem, které mají zároveň hodně interních odkazů.

Když potřebuješ přesnější obchodní prioritu, dá se přidat GA4 nebo Google Search Console overlay přes CSV. Pak už neřešíš jen „co je technicky špatně“, ale „co je špatně na URL, které nosí návštěvnost nebo konverze“.

Migrace: porovnání dvou crawlů

Stejný princip funguje i pro migrace. Do jednoho workspace můžeš nahrát více crawlů a přepínat aktivní schéma. Porovnávací dotazy pak hledají rozdíly mezi původním a novým stavem:

• staré URL, které po migraci nekončí na 200,
• ztracenou indexovatelnost,
• změny status kódů,
• canonical drift,
• ztrátu obsahu v title, H1 nebo word count,
• propad interních odkazů,
• změny click depth,
• výpadky strukturovaných dat.

To je typ kontroly, která se v ručním režimu dělá špatně. Dvě tabulky vedle sebe nestačí. Potřebuješ dotazy, které projdou URL po URL a ukážou změnu, která má dopad.

Limity, které stojí za to znát

Plugin pracuje s tím, co je v crawlu. Když crawl nebyl dobře nastavený, dobrý audit na to upozorní, ale data si nevymyslí.

Bez PageSpeed integrace ve Screaming Frogu plugin neuvidí laboratorní metriky LCP, CLS a INP. Bez GSC CWV exportu nebude mít data z reálných návštěv. Bez JavaScript renderingu nepůjde férově posoudit rozdíl mezi statickým a renderovaným HTML. Bez Crawl Analysis budou slabší témata kolem orphan pages, link score a near-duplicates. Bez exportu bezpečnostních hlaviček nelze tvrdit, že je bezpečnostní vrstva čistá.

Druhé omezení je živý stav webu. Crawl je snímek v čase. Pokud se mezitím změnilo přesměrování, robots.txt nebo sitemap, report to musí buď živě ověřit, nebo jasně říct, že vychází z dat crawlu. Proto existuje sf-verify, ale pouští se selektivně jen tam, kde to dává smysl.

Kde je v tom hodnota Claude Code

Claude Code tu není jen textový editor, který „nějak napíše SEO audit“. Je to orchestrátor práce nad lokálním projektem:

• spouští skripty,
• čte soubory,
• dotazuje databázi,
• předává práci subagentům,
• skládá výsledky,
• renderuje report,
• hlídá, co je ověřené a co ne.

Nejdůležitější je oddělení vrstev. Skripty dělají opakovatelnou práci nad daty. Agenti dělají interpretaci. Writer skládá výstup pro člověka. QA brání tomu, aby se do reportu dostala neurčitá čeština, vymyšlené číslo nebo nález bez URL.

To je rozdíl mezi „zeptal jsem se modelu na CSV“ a použitelným auditním workflow.

Shrnutí

Crawl ze Screaming Frogu je dobrý začátek, ale sám o sobě ti neřekne, co máš opravit jako první. Na to potřebuješ interpretaci, prioritizaci a schopnost spojovat data napříč tabulkami.

Claude Code s pluginem rellmo-sf-analysis k tomu používá lokální DuckDB databázi, expertní pohledy, coverage manifest a několik specializovaných agentů. Výsledkem je audit, který drží konkrétní URL, počty, důvod závažnosti a doporučenou opravu.

Nejde o nahrazení Screaming Frogu. Screaming Frog pořád dělá crawl. Claude Code z něj pomáhá udělat audit, který se dá přečíst, obhájit a poslat vývojáři.