Každý, kto spravuje WordPress web s pravidelne publikovaným obsahom, riešil tento problém aspoň raz. Databáza je jediný zdroj pravdy. Záloha hostingu zachráni server, nie konkrétny článok v stave, v akom bol pred týždňom. A ručné kopírovanie obsahu do Google Docs pri každom publikovaní nie je riešenie – je to strata času, ktorá rastie s každým ďalším článkom. Postavil som preto n8n workflow, ktorý túto vrstvu zálohovania rieši automaticky. Spúšťa sa každých 6 hodín, rozozná nové aj upravené príspevky a pre každý z nich vytvorí dva Google Docs priamo v Drive. Bez manuálneho zásahu. Workflow je open source a môžete si ho stiahnuť bezplatne na GitHube a nasadiť na vlastné prostredie.
Prečo klasické zálohy nestačia a kde vzniká skutočné riziko pre obsah vášho webu
Binárny snapshot databázy je užitočný vtedy, keď treba obnoviť celý web. Pre obsah je však nepraktický. Ak potrebujem zistiť, ako vyzeral konkrétny článok pred tromi mesiacmi – pred úpravou SEO štruktúry alebo pred prepisom textu – z binárnej zálohy to zisťujem len ťažko. Musel by som obnoviť celú databázu do testovacieho prostredia, extrahovať konkrétny záznam a porovnať ho s aktuálnym stavom. To je pol hodiny práce pri každom takomto dopyte.
Druhý problém je tím. Ak na webe pracuje viac ľudí – redaktori, SEO špecialistu, klient – nikto nemá jednoduchý prístup k histórii obsahu bez prístupu do WordPress adminu. Google Drive túto medzeru vypĺňa prirodzene. Každý článok ako samostatný dokument, dostupný komukoľvek v tímovom Drive, bez nutnosti prihlasovať sa do CMS.
Tretia motivácia bolo AI spracovanie. Čisté HTML bez skriptov, shortcodes a inline štýlov, uložené v Drive, je ideálny vstup pre ďalšie automatizácie – content audit, analýzu štruktúry, AI prepis alebo preklad. Workflow teda nerieši iba zálohu, ale aj prípravu korpusu obsahu webu pre následné využitie. Ak v budúcnosti nasadíte nad Drivom ďalší automatizačný layer – napríklad AI audit zastaraných článkov alebo detekciu duplicitného obsahu – budete vďační, že dáta sú čisté, štruktúrované a indexované od prvého dňa.
Prakticky vzaté: väčšina WordPress projektov nemá žiadnu vrstvu medzi databázou a produkčným serverom, ktorá by obsah sprístupňovala v čitateľnej, prenositeľnej forme. Hostingové zálohy chránia pred havarovaním servera. Nechránia pred tým, že redaktor prepíše fungujúci článok na horšiu verziu, klient omylom zmaže sekciu, alebo migrácia na nový CMS o rok spôsobí stratu časti obsahu. Toto riešenie pokrýva práve tieto scenáre, na ktoré bežná záloha nestačí.
Stack, ktorý za tým stojí: čo presne potrebujete a koľko to mesačne stojí
Celý systém stojí na šiestich nástrojoch. Prevádzkové náklady sú mimo n8n nulové – všetky Google služby bežia v bezplatných tieroch, WordPress REST API je súčasť každého WordPressu od verzie 5.6 a Slack Bot Token je zadarmo.
Jediné rozhodnutie s finančným dopadom je n8n. Máte dve možnosti. Prvou je self-hosted n8n na vlastnom VPS – od približne 5 eur mesačne, s plnou kontrolou a bez limitu na počet workflow behov. Druhou možnosťou je n8n cloud, teda platený plán bez nutnosti správy servera, no s limitom podľa zvoleného plánu. Workflow funguje identicky v oboch prípadoch. Pre interné projekty používam self-hosted verziu na Hetzner VPS, kde bežia aj ďalšie automatizácie – náklady sú teda rozdelené medzi viacero projektov a reálna mesačná cena za tento workflow konkrétne je zanedbateľná.
Zvyšok stacku tvorí šesť nástrojov, z ktorých každý plní presne vymedzenú úlohu. WordPress REST API je zabudovaný v každom WordPresse vo verzii 5.6 a vyššej, nevyžaduje žiadnu inštaláciu na strane servera a autentifikácia prebieha cez Application Password – bezpečný mechanizmus, ktorý nevyžaduje zdieľanie hlavného hesla administrátora. XML Sitemap generuje Yoast SEO alebo Rank Math – väčšina projektov ho má nasadený – a slúži ako zdroj zoznamu URL aj ako detektor zmien cez atribút „lastmod“, ktorý pluginy automaticky aktualizujú pri každej úprave príspevku. Google Sheets – konkrétne záložka nazvaná „memory“ – funguje ako stavový register celého systému; každý príspevok má tu presný záznam o tom, kedy bol extrahovaný, kde sú uložené jeho dokumenty a v akom stave sa nachádza. Google Drive a Google Docs sú výstupné úložisko; pre každý článok vzniknú v jednom priečinku dva dokumenty s odlišným účelom. Slack zaisťuje, že tím vie o výsledku každého behu bez toho, aby musel otvárať n8n editor.
Čo workflow konkrétne vytvorí: dva súbory na každý článok a prečo to tak funguje
Pre každý WordPress príspevok vzniknú v Drive dva Google Docs. Nie jeden, ale dva – a je to zámerné rozhodnutie, nie nadbytočnosť.
Prvý dokument je čitateľná verzia. Obsahuje metadáta – identifikátor príspevku vo WordPress (wp_id), slug, dátum publikovania, dátum poslednej úpravy, URL a typ príspevku – a pod nimi čistý text článku bez obrázkov, skriptov, shortcodes a inline štýlov. Tento dokument je určený pre review, content audit alebo ako vstup pre AI spracovanie. Dá sa prečítať bez WordPress prostredia, v ľubovoľnom nástroji, ktorý otvorí Google Docs. Je to formát pre ľudí aj pre stroje zároveň.
Druhý dokument obsahuje čisté HTML s komentármi na začiatku – identifikátor príspevku, slug, titulok, URL, dátumy. Samotný obsah je sémantický HTML bez závislostí na WordPress prostredí. Tento súbor je pripravený na spätný import do CMS, copy-paste do iného systému alebo ako referencia pri migrácii webu na inú platformu.
Oba súbory sú pomenované podľa vzorca „[wp_id] Titulok článku“ a „[wp_id] Titulok článku – HTML“. V Drive priečinku sa teda ľahko orientujete aj pri stovkách dokumentov, pretože číselný prefix zo WordPress ID zaručuje konzistentné radenie a jednoznačnú identifikáciu bez potreby otvárať obsah súboru.
Architektúra, ktorá umožňuje spracovať 100 článkov za 5 minút bez zaťaženia servera
Workflow nebeží lineárne. Rozdeľuje sa do dvoch vetiev, ktoré pracujú súčasne a nezávisle. Vetva 1 spracúva nové príspevky. Vetva 2 detekuje zmenené príspevky a okamžite ich znovu extrahuje. Obe vetvy sa spúšťajú pri každom behu, žiadna nečaká na druhú.
V jednom behu môže workflow zároveň zálohovať pätnásť nových článkov a prepísať tri, ktoré boli upravené od posledného cyklu. Spustenie riadi Schedule Trigger – štandardne každých 6 hodín – alebo Manual Trigger pre okamžité spustenie. Oba vedú do nodu Set Config, kde sú uložené všetky konfiguračné hodnoty pre daný web. Celá konfigurácia je sústredená v jedinom mieste: URL webu, identifikátor Sheets tabuľky, názov záložky a identifikátor Drive priečinka. Zmena webu alebo presunutie priečinka nevyžaduje zásah do logiky jednotlivých nodov.
Hlavný flow: ako workflow rozhoduje, čo je nové a čo je zmenené
Po spustení workflow paralelne načíta dve dátové sady. Z WordPress stiahne súbor „sitemap_index.xml“, rozparsuje relevantné sub-sitemaps a získa zoznam URL so slugmi a dátumami poslednej úpravy. Zároveň načíta všetky záznamy zo Sheets – záložka „memory“ obsahuje stav každého príspevku, ktorý bol kedy detekovaný.
Node Merge Sources spojí tieto dve sady. Z porovnania vzniknú dve skupiny: nové príspevky, teda také, ktoré sú v sitemape, ale ešte nie sú v Sheets, a upravené príspevky, pri ktorých dátum poslednej zmeny zo sitemapy je novší ako zaznamenaný dátum v Sheets. Táto detekcia zmien nevyžaduje webhooky ani žiadne zásahy na strane WordPress – stačí štandardný výstup Yoast alebo Rank Math.
Vetva 1: postupnosť nodov od nového príspevku po hotové Google Docs v Drive
Nové príspevky sa okamžite zapíšu do Sheets so stavom „pending“. Následne workflow pre každý záznam v tomto stave zavolá WordPress REST API a stiahne plný obsah príspevku. Node Prepare Content HTML parsuje raw odpoveď – odstráni obrázky, skripty, shortcodes, iframe elementy a inline štýly. Výsledkom je čisté sémantické HTML, prenositeľné mimo WordPress prostredia, bez závislostí na konkrétnej inštalácii alebo aktívnych pluginoch.
Pred vytvorením dokumentov workflow overí, či v Drive priečinku Google Doc pre daný slug už neexistuje. Ak áno, označí príspevok ako „already_extracted“ a aktualizuje Sheets bez duplicitného vytvárania. Ak nie, spustí sekvenciu Docs Create Readable, Docs Create HTML a Docs Insert HTML. Po úspešnom dokončení aktualizuje Sheets – zapíše identifikátory a URL oboch dokumentov, časový odtlačok extrakcie a zmení stav na „extracted“. Na konci behu workflow agreguje všetky úspešne extrahované príspevky a pošle do Slacku súhrn s priamymi odkazmi.
Vetva 2: prečo sa zmenený článok prepíše v tom istom behu a nie až pri ďalšom spustení
Toto je časť, ktorú považujem za architektonicky najdôležitejšiu. Keď workflow zistí, že dátum poslednej úpravy v sitemape je novší ako zaznamenaný dátum zmeny v Sheets, neplánuje re-extrakciu na ďalší beh. Spraví to okamžite, v rovnakom behu.
Postup prebieha v štyroch krokoch za sebou. Najprv sa pripravia identifikátory oboch existujúcich Google Docs – čitateľná verzia aj HTML verzia. Node Delete Drive Doc ich zmaže z Drive s nastavením „continueOnFail: true“, takže chýbajúci dokument nezastaví zvyšok procesu. Node Deduplicate Slugs zlúči dve položky – jeden slug, dva doc-items – na jeden záznam, aby nedošlo k duplicitným riadkom v Sheets. Node Sheets Reset to Pending vymaže identifikátory a URL starých dokumentov a zmení stav záznamu späť na „pending“.
Nasleduje rozvetvenie: jedna vetva pošle Slack notifikáciu o detekovaných zmenách so zoznamom slugov a novými dátumami zmeny, druhá okamžite spustí získanie plného obsahu príspevku a prebehne cez rovnakú sekvenciu ako Vetva 1. Výsledkom je, že upravený článok je znovu zazálohovaný ešte v tom istom behu – tím dostane kompletný prehľad v jednej Slack správe.
Stavový register: štyri stavy, jedna tabuľka, nula nekonzistentných záznamov
Každý príspevok má v každom okamihu jeden zo štyroch stavov. Stav „pending“ znamená, že príspevok čaká na extrakciu – buď je nový, alebo bol práve resetovaný po detekcii zmeny. Stav „extracted“ potvrdzuje, že oba Google Docs boli úspešne vytvorené a Sheets obsahuje ich identifikátory aj URL. Stav „already_extracted“ nastane vtedy, keď Google Doc pre daný slug v Drive už existoval – Sheets sa aktualizuje bez vytvárania nových dokumentov. Stav „skip_error“ zaznamenáva príspevky, pri ktorých WordPress REST API vrátilo chybu 404 alebo 5xx – príspevok sa preskočí bez blokovania zvyšku fronty a pri nasledujúcom behu sa skúsi znova.
Workflow nikdy neopustí Sheets v nekonzistentnom stave. Ak zlyhá akýkoľvek krok, stav záznamu zostane na „pending“ a bude znovu spracovaný pri ďalšom behu. Táto vlastnosť je kľúčová pre dlhodobú prevádzku bez manuálneho dohľadu.
Výkon v praxi: 100 článkov za 5 minút, 200 súborov v Drive, minimálny počet API volaní
Generovanie zálohy pre 100 WordPress príspevkov trvá približne 5 minút. Výsledkom je 200 Google Docs – dve verzie na každý článok. Parsovanie XML sitemáp je odladené na minimálny počet HTTP volaní.
Podstatnejšie ako absolútne číslo je však to, že workflow nezaťažuje WordPress server pri opakovaných behoch. WordPress REST API sa volá iba pre príspevky so stavom „pending“. Pri 600 článkoch na webe, z ktorých sa od posledného behu zmenili štyri, workflow vykoná 4 API volania, nie 600. Register v Sheets je presne ten mechanizmus, ktorý to umožňuje – každý príspevok sa spracuje iba toľkokrát, koľkokrát je to skutočne potrebné. Pre WordPress stránky bežiace na menšom hostingu je toto zásadná vlastnosť, ktorá znamená rozdiel medzi nenápadnou automatizáciou a zaťažením servera, ktoré zákazník pocíti.
Chybové stavy neblokujú zvyšok fronty. Ak jeden príspevok vracia chybu 404 – napríklad bol zmazaný z WordPress, ale ešte je v sitemape – označí sa ako „skip_error“ a workflow pokračuje ďalej bez manuálneho zásahu. Tento princíp izolácie chýb som považoval pri návrhu za nenegociateľný požiadavok: žiadny jeden pokazený príspevok nesmie zastaviť zálohovanie celého webu.
Slack notifikácie: úplný prehľad po každom behu bez otvárania n8n editora
Workflow posiela do Slacku tri typy správ podľa toho, čo sa v danom behu stalo. Prvou je súhrn úspešnej extrakcie – zoznam zazálohovaných článkov s titulkami a priamymi odkazmi na nové Google Docs. Člen tímu môže kliknutím rovno otvoriť dokument bez prechodu cez Drive alebo WordPress admin. Druhou je správa o zmenených príspevkoch – zoznam slugov s novými dátumami zmeny; prichádza vždy v rovnakom behu ako súhrn, pretože re-extrakcia prebehne okamžite. Treťou je informačná správa „nič nové“ – krátke potvrdenie, že beh prebehol a nebolo čo spracovať. Táto správa je rovnako dôležitá ako ostatné dve: potvrdí, že automatizácia funguje, aj keď sa obsah webu nezmenil.
Slack integrácia závideniahodne znižuje kognitívnu záťaž pri správe viacerých webov naraz. Namiesto kontroly n8n dashboardu a Drive priečinka raz denne stačí jeden pohľad do Slacku. Ak správa prišla a výsledky vyzerajú normálne, nie je čo riešiť. Ak správa neprišla, viem okamžite, že niečo treba skontrolovať.
Nastavenie v správnom poradí: od Google Cloud po prvý úspešný beh bez strateného času
Poradie krokov nie je náhodné. Najčastejšie chyby pri nasadení vznikajú vtedy, keď niekto začne s importom workflow ešte pred tým, ako má pripravené credentials.
Krok 1 – Google Cloud. Vytvorte nový projekt na Google Cloud Console, zapnite tri API naraz: Google Sheets API, Google Drive API a Google Docs API. Nastavte OAuth consent screen s rozsahmi „spreadsheets“, „drive“ a „documents“. Vygenerujte OAuth 2.0 Client ID pre Web application – Redirect URI bude adresa vášho n8n hosta s cestou „/rest/oauth2-credential/callback“. Client ID a Client Secret si okamžite skopírujte, pretože k nim budete pristupovať viackrát.
Krok 2 – Tri samostatné Google credentials v n8n. Napriek tomu, že všetky tri zdieľajú rovnaký Client ID, n8n potrebuje tri oddelené záznamy: Google Sheets OAuth2 API, Google Drive OAuth2 API a Google Docs OAuth2 API. Dôležitá technická poznámka: nody Docs Create a Docs Create HTML používajú Drive API cez multipart upload, nie Docs API. Docs API využívajú iba nody Docs Insert HTML a Docs Insert Content. Ak tento rozdiel prehliadnete a priradíte zlý credential, nody budú hlásiť chybu oprávnení napriek tomu, že autorizácia prebehla správne.
Krok 3 – WordPress Application Password. V administrácii WordPress prejdite na sekciu Users, otvorte profil administrátorského účtu a nájdite časť Application Passwords. Zadajte názov napríklad „n8n-extractor“ a kliknite na pridanie nového hesla. Heslo sa zobrazí len raz – okamžite ho skopírujte do schránky a uložte do správcu hesiel. V n8n vytvorte credential typu WordPress API s URL vášho webu a prihlasovacím menom, ku ktorému heslo patrí.
Krok 4 – Google Sheets tabuľka. Vytvorte novú tabuľku na Google Sheets, premenujte záložku na „memory“ a vložte do prvého riadku hlavičku so 15 stĺpcami v tomto poradí: „wp_id“, „post_type“, „slug“, „title“, „status“, „date_published“, „date_modified“, „link“, „extraction_status“, „gdoc_id“, „gdoc_url“, „gdoc_html_id“, „gdoc_html_url“, „extracted_at“ a „site_url“. Stĺpec „slug“ je primárny kľúč pre párovanie záznamov a musí byť v každom riadku jedinečný.
Krok 5 – Google Drive priečinok. Vytvorte priečinok v Google Drive, otvorte ho v prehliadači a z URL skopírujte identifikátor priečinka – je to časť adresy za segmentom „/folders/“. Priečinok musí byť vlastnený alebo zdieľaný na rovnaký Google účet, ktorý je použitý v Drive OAuth2 credentiali. Samotná existencia priečinka v Drive nestačí, ak má iného vlastníka.
Krok 6 – Slack Bot. Na stránke pre správu Slack aplikácií vytvorte novú aplikáciu, pridajte Bot Token Scopes „chat:write“ a „channels:read“, nainštalujte ju do workspace a skopírujte Bot User OAuth Token, ktorý začína reťazcom „xoxb-„. Bota pozvite do cieľového kanála príkazom „/invite @nazov-vasho-bota“. V Slack nodoch workflow používajte vždy Channel ID – identifikátor, ktorý začína písmenom „C“ – nie názov kanála. ID nájdete v URL kanála pri otvorení Slacku v prehliadači.
Krok 7 – Import workflow a vyplnenie Set Config. Stiahnite workflow JSON z GitHubu a importujte ho v n8n cez Workflows – Import from file. V node Set Config vyplňte päť hodnôt: URL webu bez lomky na konci, označenie webu pre Slack správy, identifikátor Sheets tabuľky, názov záložky a identifikátor Drive priečinka. Následne priraďte credentials k nodom podľa tabuľky v dokumentácii – každý typ nodu potrebuje presne určený credential, zámena Sheets a Drive credentialov je najčastejšou chybou pri prvom nasadení.
Dve cesty nasadenia: manuálna konfigurácia alebo import hotového JSON cez Claude
Po stiahnutí workflow z GitHubu máte dve možnosti, ako pokračovať.
- Cesta A je manuálna. Otvoríte workflow v n8n editore, vyplníte Set Config a priradíte credentials ku každému nodu podľa tabuľky v priloženej dokumentácii. Pre toho, kto chce rozumieť každému nodu pred spustením, táto cesta trvá približne 15 minút pri už pripravených credentials. Je vhodná pre tých, ktorí plánujú workflow ďalej upravovať alebo prispôsobovať vlastným potrebám.
- Cesta B využíva Claude. V repozitári je pripravený prompt – zadáte do neho svoje hodnoty pre URL webu, identifikátor Sheets tabuľky, identifikátor Drive priečinka a Channel ID v Slacku, a Claude vráti nakonfigurovaný workflow JSON. Importujete, priradíte credentials a spustíte. Táto cesta je vhodná pre tých, čo chcú dostať systém do funkčného stavu čo najrýchlejšie bez hlbšieho štúdia architektúry.
Obe cesty vedú k identicky fungujúcemu workflow. Voľba závisí od toho, či chcete rozumieť architektúre alebo len nasadiť a používať. Odporúčam Cestu B (pretože je veľmi rýchla) pre každého, kto plánuje spravovať viacero webov alebo chce vedieť, čo presne sa deje pri každom behu.
Stiahnite workflow zadarmo: čo nájdete v repozitári na GitHube
Workflow je dostupný na GitHube pod MIT licenciou, bez podmienok použitia. Repozitár obsahuje štyri súčasti. Prvou je workflow JSON pripravený na priamy import do n8n bez ďalších úprav. Druhou je kompletná dokumentácia s architektonickými diagramami a popisom každého nodu vrátane toho, aký credential má priradený a prečo. Treťou je podrobný postup pre získanie všetkých potrebných API kľúčov – Google Cloud, WordPress Application Password, Slack Bot Token. Štvrtou je README so quickstart návodom, ktorý vás prevedie celým nastavením od začiatku do prvého úspešného behu krok za krokom.
Problémy, na ktoré narazíte najčastejšie, a ako ich vyriešiť bez strateného času
- Sitemap sa nenačíta: skontrolujte URL webu v Set Config – nesmie obsahovať lomku na konci. Otvorte adresu webu s príponou „/sitemap_index.xml“ priamo v prehliadači a overte dostupnosť. Názvy sub-sitemaps v node Parse & Filter Sitemaps musia zodpovedať skutočným názvom – napríklad „post-sitemap.xml“ nie je to isté ako „posts-sitemap.xml“. Ak používate vlastné typy príspevkov, skontrolujte, aký názov sitemapového súboru pre ne Yoast alebo Rank Math generuje.
- Drive Search Doc vracia prázdne výsledky: skontrolujte identifikátor Drive priečinka a overte, že autorizovaný Google účet má k priečinku prístup. Priečinok musí byť vlastnený alebo zdieľaný na použitý účet – samotná existencia súboru v Drive nestačí, ak bol priečinok vytvorený iným účtom a nebol explicitne zdieľaný.
- Chyba 403 pri Docs Create: Google Drive API nie je zapnuté v Google Cloud Console, alebo OAuth2 scope neobsahuje oprávnenie „drive“ alebo „drive.file“. Skontrolujte obe nastavenia v Cloud Console pod sekciou APIs & Services. Docs Create a Docs Create HTML používajú Drive API, nie Docs API – táto neintuitívna závislosť je zdrojom väčšiny 403 chýb pri prvom nasadení.
- WordPress API vracia chybu 401: vygenerujte nové Application Password v administrácii WordPress v sekcii profilu používateľa. Skontrolujte, či bezpečnostný plugin, napríklad Wordfence alebo iThemes Security, neblokuje REST API endpoint na adrese „/wp-json/wp/v2/“. Niektoré pluginy blokujú REST API pre neprihlásených používateľov, čo spôsobuje autentifikačné chyby aj pri správne nastavenom Application Password.
- Príspevok sa stále znovu extrahuje: skontrolujte hodnotu dátumu poslednej zmeny v Sheets. Ak je staršia ako zodpovedajúca hodnota zo sitemapy, workflow ho pri každom behu resetuje na „pending“. Častou príčinou je WordPress plugin, ktorý aktualizuje dátum zmeny pri každom uložení nastavení, aj keď sa obsah samotného príspevku nezmenil. V takom prípade problém nespočíva vo workflow, ale v správaní konkrétneho pluginu.
Záverečné zhodnotenie projektu a osobný pohľad
Čo fungovalo a čo by som zopakoval na každom ďalšom podobnom projekte
Stavový register v Google Sheets sa ukázal ako správne rozhodnutie. Mohol som použiť internú n8n databázu alebo Redis, ale Sheets prináša jednu zásadnú výhodu – transparentnosť. Ktokoľvek v tíme vidí stav každého príspevku bez prístupu do n8n editora. Keď niečo nefunguje, otvorí tabuľku a okamžite vidí, kde sa to stalo. Toto oceňujem pri ladení oveľa viac, ako som čakal. Okrem toho Sheets umožňuje manuálny zásah – ak potrebujem jeden konkrétny príspevok znovu extrahovať, stačí zmeniť jeho stav priamo v tabuľke a pri ďalšom behu ho workflow zahrnie. Žiadne zásahy do n8n editora, žiadne spúšťanie workflow s upravenými parametrami.
Paralelné vetvy bez vzájomného blokovania fungujú spoľahlivo od prvého behu. Rozhodnutie spustiť re-extrakciu zmeneného príspevku okamžite v tom istom behu bolo správne, nie čakať na ďalší cyklus. Tím dostane kompletný prehľad v jednej Slack správe. Zároveň izolácia chýb na úrovni jednotlivých príspevkov sa osvedčila pri každom webe, kde som workflow nasadil: jeden pokazený príspevok nezastaví zálohovanie zvyšku.
Nastavenie „continueOnFail: true“ na node Delete Drive Doc sa tiež osvedčilo. Keď Google Doc už neexistuje v Drive – napríklad bol zmazaný ručne – workflow to nevníma ako kritickú chybu a pokračuje v re-extrakcii. Bez tohto nastavenia by každý ručne zmazaný dokument blokoval celú vetvu pre upravené príspevky.
Čo by som zlepšil a čo plánujem nasadiť v ďalšej verzii tohto workflow
Polling každých 6 hodín je kompromis medzi frekvenciou a záťažou. Pre projekty s vysokou frekvenciou publikovania by bol ideálny webhook trigger, ktorý by spustil workflow okamžite po publikovaní alebo aktualizácii článku vo WordPress. WordPress REST API webhooky to umožňuje – je to nasledujúci krok vo vývoji a chcem ho mať implementovaný do ďalšej verzie workflow ešte tento kvartál.
Konfigurácia typov príspevkov, teda custom post types, teraz vyžaduje ručnú úpravu nodu Parse & Filter Sitemaps. Plánujem to presunúť priamo do Set Config ako pole hodnôt – jeden bod konfigurácie pre celý workflow bez akéhokoľvek zásahovania do logiky nodov. Toto zjednoduší nasadenie na weby s neštandardnými post types, kde si dnes používateľ musí otvoriť node a pochopiť jeho štruktúru, aby mohol pridať jeden vzorec.
Zálohované dokumenty v Drive sú zatiaľ nevyužitý potenciál. Čisté HTML a čitateľná verzia každého článku sú ideálny vstup pre AI content audit, detekciu zastaraných informácií alebo automatické návrhy aktualizácií. Toto je smer, ktorý chcem rozvíjať ako nadstavbu tohto workflow v ďalšej fáze – druhý layer automatizácie, ktorý bude nad týmto korpusom obsahu pracovať a generovať akčné odporúčania pre obsahových špecialistov aj bez ich aktívneho dohľadu.
