Web z WordPressu do Astro za jeden den: jak to dělám s Claude Code

Dnes ráno v osm hodin jsem začal migrovat tento web. Teď odpoledne, po cestě na rodinný výlet a zpátky, píšu tenhle článek. Web je v podstatě hotový.

Tohle je osobní příběh a zároveň praktický návod. Hlavní sdělení je jednoduché: v roce 2026 zvládne migraci z WordPressu kdokoliv za jeden den — pokud má k ruce AI nástroj a ví, co dělá.

Než začnu, jeden tip: nechte tento článek přečíst svůj oblíbený CLI nástroj. Claude Code, Codex, ChatGPT nebo jiný. Dostanete snadno ovladatelný web, na hostingu zdarma, bezpečnější a rychlejší. Stále ho máte pod kontrolou vy — ale i vaše LLM dokáže dělat jakékoliv změny během minut.

Proč jsem se vůbec pustil do migrace

Poslední půl rok trávím velkou část pracovního času v Claude Code. Stavím si systémy, agenty, znalostní báze — a píšu o tom sem na web.

WordPress mi začal vadit. Napojení přes FTP a MCP do WordPressu bylo těžkopádné. Chtěl jsem mít web jako soubory, které spravuje AI přímo. Bez pluginů, bez databáze, bez zbytečných vrstev.

O migraci jsem se bavil s Petrem Jiránkem, který migruje desítky svých klientů téměř jako na běžícím páse. Jeho rada byla jednoduchá a přesná: udělej si seznam všech URL, ať máš co porovnávat na konci. Nascreenuj všechny důležité části webu — tohle je největší kámen úrazu, protože AI funkčně naprogramuje a vytáhne cokoliv, ale jakmile dojde na grafiku 1:1, je v háji. Udělej kompletní StyleGuide. Do složky nataháš logo a vizuální assety. A hlavně: fakt mu nakaž, ať na to kouká a ověř, že na to fakt kouká.

Měl pravdu ve všem. Pustil jsem se do toho.

Deset let ve WordPressu

Když jsem v roce 2015 odcházel na volnou nohu po přibližně dvanácti letech v agenturách — RNc / Robert Němec, Dobrý web, H1.cz, Ataxo — věděl jsem, že web bude moje vizitka. Investoval jsem do něj skoro 200 tisíc korun. V té době to pro osobní web nebylo úplně běžné.

Web stavěl Zbyšek Naděník, dnes zkušený UX designér. Programoval Honza Bien, matador a zkušený programátor. Grafický design navrhl Jiří Tvrdek, špičkový visual designer. Brand jsem konzultoval s Pavlem Podzimkem, předním českým brandovým expertem, a Honzou Strafeldou, renesančním marketérem.

Výsledek byl dobrý. Natolik dobrý, že jsem ho dalších deset let skoro nezměnil. Pár aktualizací — nová videa, drobné úpravy — ale v jádru zůstal stejný. V roce 2026 bylo na čase.

Zadání: strategická rozhodnutí před první řádkou kódu

Tady se rozhoduje o úspěchu nebo neúspěchu migrace. Technické provedení je snadné. Strategická rozhodnutí jsou drahá — a pokud je neuděláte na začátku, budete je přepisovat uprostřed projektu.

Architektura obsahu. Původní WordPress měl kategorie (blog, texty, videa, twitter) a tagy. Kategorie jsem zachoval, ale přepsal zobrazované názvy — slug texty se zobrazuje jako “Teorie”, slug twitter vede na /tweety/2023/. Tweety jsou speciální případ: namísto jednotlivých stránek pro každý tweet jsem je konsolidoval do ročních přehledových stránek.

URL strategie. Všechny původní URL musí fungovat. Mám 304 původních URL — všechny jsem ověřil, nula chybějících. K tomu 152 redirect pravidel: 66 legacy WP cest (jako /wp-content/...), přibližně 60 URL jednotlivých tweetů na roční přehledy, 4 sloučené tagy a 16 smazaných tagů.

Tag strategie. Toto je místo, kde jsem strávil nejvíce času přemýšlením. Původně jsem měl desítky tagů. Prošel jsem GSC data — kliknutí přes všechny tagové stránky byly nula. Tagy nefungovaly jako vstupní bod pro návštěvníky.

Výsledek: 5 tagů zůstalo indexovaných (skutečná témata s obsahem), 11 tagů je noindex (interní organizace), 16 tagů jsem smazal. Speciální případ byl tag “TOP” — označoval doporučené články, ale jako tag byl SEO anti-pattern. Nahradil jsem ho frontmatter polem featured: true.

Klíčové zjištění bylo, že argumentem pro smazání tagu není jen “málo trafficu”, ale špatný traffic. Tag PPC měl 50 článků a slušnou organickou návštěvnost — ale návštěvník hledající “PPC tipy” nikdy nekoupí workshop za 89 tisíc. Průnik tagů s tím, koho chci oslovit, ukázal, že PPC, SEO a e-shopy mi škodí tím, koho přitahují. GSC pak ukázala 0 kliknutí přes všechny tag stránky dohromady za celý rok 2025 — nula. Toto číslo výrazně zjednodušilo rozhodování.

Obrázky. Přesunul jsem je na Cloudflare R2. URL format je https://pub-[id].r2.dev/YYYY/MM/filename.jpg. Astro image pipeline jsem nepoužil — obrázky servíruji přímo přes <img src={url}>. Jednodušší, rychlejší.

Formuláře a JavaScript. Kontaktní formulář běží přes Cloudflare Pages Function a Resend API — email přijde na michal@krutis.com. Vlastní JavaScript je nulový. Pro vyhledávání jsem použil Pagefind — post-build krok, který indexuje statické HTML.

Vizuální ladění. Udělal jsem 8 screenshotů původního webu. Celá disciplína migrace vizuálu stojí na jednoduchém principu: před každou stránkou se podívám na screenshot, po každé stránce porovnám výsledek. Tak se to dělá.

Extrakce obsahu: SQL dump, ne XML

WordPress nabízí export do XML. Nepoužil jsem ho. SQL dump ze zálohy (338 MB z BackWPup) obsahuje vše — a Claude Code s ním pracuje přímo.

Z databáze jsem extrahoval 247 článků. Z nich 58 mělo featured image (_thumbnail_id v tabulce wp_postmeta → URL na R2). 189 článků žádný featured image ve WordPressu nemělo. Excerpty jsem vygeneroval automaticky z prvního odstavce těla — 241 z 247 článků je má, 6 zůstalo prázdných. Yoast SEO meta popisky jsem migroval z tabulky wp_mk_yoast_indexable. Přibližně 20 testimonialů skončilo jako samostatné .md soubory v content collections.

Astro content collections validují frontmatter při buildu — pokud něco chybí nebo nesedí typ, dozví se o tom okamžitě.

Redirecty: bolí nejvíc

Ověřit, že 304 původních URL přistane správně, je technicky banální. Ale otravné.

Napsal jsem ověřovací skript, který projde všechny URL ze souboru all-urls-original.txt a ověří, že každá vrátí správný status. 152 redirect pravidel v souboru _redirects:

• 66 legacy WP cest (/wp-admin, /wp-login.php, /wp-content/...)
• přibližně 60 URL jednotlivých tweetů přesměrovaných na roční přehledy
• 4 sloučené tagy
• 16 smazaných tagů
• RSS feed: /feed/ → /rss.xml — na tohle se snadno zapomene. Stávající čtenáři mají adresu /feed/ uloženou v RSS čtečkách. Rozbití feed URL je tichá ztráta — nikdo si nepřijde stěžovat, prostě přestanou číst.

Výsledek: nula chybějících. Každá původní URL funguje.

Co sloučit, co smazat

Toto byl intelektuálně nejdražší krok.

Z přibližně 247 článků je zhruba 60 takzvaných pojmových článků z let 2007–2008. Krátká vysvětlení základních marketingových pojmů — co je “reach”, co je “conversion rate”. V GA4 datech za rok 2025 mají nula pageviews. Doslova nula.

Sloučil jsem je do 6 tematických celků — PPC metriky, SEO pojmy, formy online reklamy, internetový marketing, affiliate marketing, online PR. Ze všech starých URL vedou 301 redirecty na příslušný celek. Obsah nezmizel, ale zbývající stránky mají větší šanci, že je někdo najde.

Duplicitní obsah je druhý kandidát na sloučení. Na krutis.com jsem měl například dvakrát článek o plošné reklamě z různých let — to je potřeba sloučit do jednoho kanonického článku a přidat redirect ze staršího.

Než smažete soubory, zkopírujte je do lokálního adresáře v .gitignore. Do repozitáře se nedostanou, ale zůstanou vám lokálně pro případ, že budete chtít starý obsah zpětně dohledat.

GA4 data jsem použil i jinde. Rozhodování o obsahu na základě dat je jiné rozhodování než rozhodování na základě pocitu. Doporučuji tohle udělat před migrací, ne po.

Technické SEO: krátce

Sitemap filtruje noindex stránky. Robots.txt je jednoduchý. Canonical URL jsou nastaveny na každé stránce. Schema.org jsem implementoval pro typy Article, BreadcrumbList a Person. OG tagy pro sdílení na sociálních sítích. RSS feed na /rss.xml.

Dvě konkrétní věci, na které je dobré myslet předem:

Pagefind potřebuje běžet jako post-build krok — indexuje statické HTML soubory, nestačí ho nainstalovat jako závislost.

Adobe Fonts (Typekit): přidejte *.pages.dev do povolených domén, jinak font nebude fungovat na preview URL při nasazení.

V Cloudflare dashboardu je rozdíl mezi “Workers” a “Pages” — kontaktní formulář jako Pages Function patří do Pages, ne Workers. Drobnost, která mě na chvíli zastavila.

Tech stack

Co	Jak	Proč
Framework	Astro 5.x	Nulový JS, statický output, content collections
Hosting	Cloudflare Pages	Gratis, globální CDN, Pages Functions pro formulář
Obrázky	Cloudflare R2	CDN, jednou nahrát, odkazovat přímou URL
Kontaktní formulář	Cloudflare Pages Function + Resend API	Bez třetí strany, spolehlivé, v free tieru
Vyhledávání	Pagefind	Statické, generuje se při buildu, bez serverového JS
CSS	Hand-written ze starého WP theme	Pixel-přesná shoda s originálem
Vlastní JS	Nulový	GTM + Typekit jsou třetí strany, vlastní = nula
Deploy	GitHub → auto-build	Push na main = deploy za ~30 sekund

Co bych příště udělal jinak

Technická část migrace je zvládnutelná za den — fakt.

Co den nestihnu? Rozhodování o obsahu. Co sloučit, co smazat, jaké URL zachovat, jak přepsat tag strategii — to jsou otázky, které vyžadují přemýšlení, ne jen provedení. Čím déle váhám, tím dražší jsou.

Příště bych zadání připravil kompletní ještě před spuštěním migrace. Strategická rozhodnutí na papíře (nebo v dokumentu), pak teprve Claude Code.

Druhá věc: screenshoty na začátku, ne dodatečně. Screenshoty je nejlepší mít k dispozici od prvního momentu.

---

V roce 2015 jsem do tohoto webu investoval 200 tisíc korun a potřeboval tým čtyř lidí. V roce 2026 jsem ho přestavěl za jeden den, sám, konverzací s AI. Hosting stojí nula korun měsíčně. Build trvá 30 sekund. Jakoukoliv změnu udělám během minut.

Jsem marketér, ne vývojář. Celou migraci jsem dělal konverzací s AI — ne psaním kódu.

Ráno jsem začal. Odpoledne píšu tenhle článek. V roce 2026 to takhle funguje.

Pokud takhle migruji vlastní web za den, představte si, co zvládnu za měsíc pro váš marketing. Chcete projít vlastní migrací nebo podobným AI-driven rozhodnutím? Objednejte si hodinu přes Booknuto. Více o tom, jak s AI pracuji, v článcích AI a tvorba obsahu a Stínový kabinet.