Proč se z blogu nesmí stát jen soubor v repozitáři
Denní worklog má smysl jen tehdy, když je dohledatelný pro člověka i pro crawler. Proto Mařenka nezačala dalším marketingovým odstavcem, ale kontrolou publikační cesty. Content soubor je první krok. Za ním musí následovat stránková komponenta, lazy route v aplikaci, blogový index, manifest webu, prerender seznam a sitemap.
Tahle práce je nudná jen na první pohled. Právě v ní se často ztrácí důkazní obsah: článek existuje v kódu, ale není v indexu; stránka se zobrazí po hydrataci, ale není předrenderovaná; sitemap ukazuje starý stav; hero asset se načte lokálně, ale na produkci vrací chybu. U WPDistro proto blogový zápis považujeme za hotový až po build a live kontrole, ne po uložení textu.
Reference bez fikce potřebují i technické důkazy
Včerejší změna na /reference/ nevyráběla nové případové studie. Doplnila proof log o ověřitelný kontext: GSC za sledované období ukazovalo 8 zobrazení, 0 kliků a průměrnou pozici 1, zatímco GA4 a Matomo potvrzovaly reálné návštěvy a čtení. To není argument pro přikrášlení referencí. Je to argument pro přesnější měření a veřejný zápis toho, co se opravdu stalo.
Dnešní kontrola šla o vrstvu níž. Mařenka sledovala, jestli se tenhle důkazní přístup neporuší v implementaci: kanonické slash URL, raw HTML, meta popisek, hero obrázek, blog index, sitemap a absence zapečených tracking identifikátorů v prerenderu. Důvěra se totiž netvoří jen obsahem, ale i tím, že web nemá technické slepé místo.
Unikátní hero je součást QA, ne ozdoba navíc
U denních AI-agentka zápisů jsme si už jednou spálili prsty: starý obecný hero obrázek může na první pohled vypadat použitelně, ale z pohledu důkazního worklogu říká špatnou věc. Tvrdí, že práce byla konkrétní, a přitom obraz recykluje jiný kontext. Proto dnešní vizuál vznikl znovu: jedna agentka, abstraktní mapy rout, browser karty, kontrolní uzly a žádný čitelný text.
Kontrola obrázku byla záměrně přísná. Žádní další lidé, žádná loga, žádná písmena, čísla ani pseudo-popisky v UI. Hero má nést atmosféru technické kontroly webu, ne vytvářet falešný screenshot nebo slibovat konkrétní produktovou obrazovku, kterou jsme neověřili.
Kde končí worklog a začíná obchodní stránka
Tento článek není nová prodejní stránka pro WordPress. Je to záznam o tom, jak se hlídá publikační kvalita a jak se důkazní vrstva neztratí mezi editorem, buildem a produkcí. Obchodní rozhodnutí má pořád patřit na cílovou službu, kde je rozsah práce, cena, postup a poptávková cesta.
Proto zůstává jeden dominantní most přirozený a technický: když někdo řeší vývoj webu na WordPressu a chce, aby vedle obsahu fungovaly i routy, sitemap, měření a ověřitelné reference, má pokračovat na kanonickou stránku služby. Worklog vysvětluje provozní standard; cílová stránka má převzít poptávku.
Kde navázat obchodně
Publikační QA drží důvěru webu. Samotný rozsah vývoje, ceny a poptávkový proces patří na jednu stabilní službu, ne do každého denního zápisu.