AI sistem za pisanje sadržaja i SEO: šta obuhvata

Kad firma traži "AI za pisanje sadržaja", obično misli da kupuje generator teksta. Tekst je međutim najjeftiniji deo celog lanca. Ja sam Lazar Milićević i gradim sisteme koji istražuju pitanja, pišu, objavljuju, mere i popravljaju sami sebe, na više sajtova istovremeno. Ovo nije lista agencija i ne rangiram nikoga, pa ni sebe. Pokušavam da objasnim šta zapravo kupujete i na šta da pazite kad birate izvođača.

Šta takav sistem zaista obuhvata

U mom pristupu sistem za automatski sadržaj i SEO obuhvata šest faza: istraživanje pitanja, generisanje, objavu, indeksaciju, merenje i popravku. Pisanje je jedna od šest, i to najlakša, jer modeli danas pišu uredno. Vrednost je u ostalim fazama, a tu se razlikuje sistem od skripte koja zove API.

1. Istraživanje pitanja. Šta ljudi zaista pitaju, šta sajt već pokriva, gde su praznine. Bez ovoga dobijate hiljadu tekstova o temama koje niko ne traži.
2. Generisanje. Tekst iz proverenih izvora, sa jasnim pravilom šta sme da tvrdi, a šta ne. Tekst koji izmišlja brojeve je gori od praznog sajta.
3. Objava. Direktno u CMS ili na sajt, sa metapodacima, internim linkovima, slikama, strukturiranim podacima.
4. Indeksacija. Da li je Google uopšte primio ono što ste objavili.
5. Merenje. Klikovi, impresije, pozicije, ali i ponašanje posetilaca i vidljivost u AI odgovorima.
6. Popravka. Šta merenje pokaže, vraća se u sistem: koje teme pojačati, koje stranice prepraviti, šta prestati da pišem.

Takav sistem držim u produkciji kao autonomni multi-agent pipeline koji radi bez nadzora. Ovo navodim samo kao dokaz da sistem postoji i radi, a ne zato što je stack ono što kupujete.

Jedna napomena o riziku. Googleov vodič o generativnoj AI u sadržaju kaže da AI može da pomogne u istraživanju teme i strukturiranju originalnog sadržaja, ali da generisanje velikog broja stranica bez dodate vrednosti za korisnika može da prekrši spam politiku o "scaled content abuse" (Google Search's Guidance on Generative AI Content). Isto važi za pravljenje zasebnih stranica za svaku varijaciju upita, primarno radi manipulacije rangiranjem (Google's Guide to Optimizing for Generative AI Features). Zato kontrola kvaliteta nije luksuz, nego deo sistema.

Kako izgleda saradnja korak po korak

Saradnja ide od razgovora ka pilotu na jednom sajtu, pa tek onda ka širenju. Redosled je važan jer se greške otkrivaju jeftino na jednom sajtu, a skupo na deset.

1. Razgovor o ciljevima i sajtu. Šta firma prodaje, ko je publika, kakav sadržaj već postoji, da li postoji CMS i ko njime upravlja.
2. Izbor tema i izvora istine. Odakle sistem sme da vuče činjenice: vaši proizvodi, cenovnici, dokumentacija, stručnjaci u firmi. Sve što nije u izvoru istine, sistem ne sme da tvrdi. Ovo je najčešće najduži razgovor, i vredi ga voditi pažljivo.
3. Pilot na jednom sajtu. Ograničen obim, pun lanac od istraživanja do merenja. Cilj nije količina nego da vidite da svaka faza radi.
4. Merenje. Sa pilota se čitaju stvarni podaci: šta je objavljeno, šta je indeksirano, šta ima impresije.
5. Širenje. Tek kad pilot pokaže da lanac radi, dodaju se sajtovi, jezici ili vrste sadržaja.

Od čega zavise rok i cena

Ne navodim cene ni rokove jer zavise od faktora koje tek treba izmeriti na vašem slučaju. Evo tih faktora:

Zadnji red je najpodcenjeniji. Sistem je samo toliko dobar koliko su dobri podaci iz kojih piše.

Merenje: zašto ukupni brojevi lažu

Merenje mora da bude po segmentima i da alarmira kad ima pokušaja, a nema ishoda. Ovo ne važi samo za sadržaj, nego za svaki sistem koji se meri ukupnim brojkama.

Evo primera iz mog iskustva, izvan sadržaja. Tipičan scenario: registracija mejlom potpuno otkazuje zato što je na edge funkciji uključen verify_jwt, dok GoTrue hook nosi Standard Webhooks potpis, pa gateway vraća 401 pre nego što se kod funkcije uopšte pokrene. Supabase dokumentacija opisuje opšti mehanizam: verify_jwt je podrazumevano uključen, platforma očekuje validan korisnički JWT u Authorization headeru i vraća 401 pre izvršavanja (Supabase: Authorization headers). Auth Hook zahtevi su pak potpisani HMAC potpisom u zasebnim headerima, a ne JWT-om (opisuje to Hookdeck, kao treća strana).

Zašto ovakav kvar može dugo da prođe neprimećen? Zato što druga putanja prijave i dalje radi, pa ukupan broj korisnika raste i metrika izgleda zdravo, a neuspešna registracija nigde nije vidljiva u praćenim događajima.

Lekcija je prosta: ukupne brojke lažu, meri se po segmentu (mejl registracija odvojeno od prijave preko Google-a), a alarm treba da se javi kad ima pokušaja a nema ishoda.

Isti princip na sadržaju: objavljeno nije indeksirano

Za sadržaj je analogno pitanje "objavljeno ili indeksirano". Indeksacija se kod različitih sajtova često ne poklapa: neki imaju gotovo sve stranice u indeksu, a drugi tek njihov deo. To je upravo razlog zašto se indeksacija meri. Da merite samo "objavljeno", izgledalo bi da je sve u redu. Google razlikuje stanja poput "Discovered, currently not indexed" (zna za URL, ali ga još nije indeksirao) i "Crawled, currently not indexed" (pregledao je stranicu, ali je odlučio da je ne indeksira). Prvi izvor kao uzrok navodi serverske probleme ili kvalitet stranice (Search Engine Land), a drugi to ne tumači kao kaznu, nego kao znak da Google trenutno ne vidi dovoljno vrednosti (SEO Testing).

Za merenje se može koristiti URL Inspection API, koji vraća iste indeksne podatke kao alat u Search Console-u (Google Search Central). Kvota se računa po property-ju i predstavlja plafon koji se mora uračunati u dizajn sistema; tačne limite proveri u zvaničnoj dokumentaciji. Napomena: Indexing API nije za blog postove, zvanično je podržan samo za JobPosting i BroadcastEvent strukturirane podatke, pa za blog služi sitemap.

Što se tiče trendova klikova i impresija, čitaju se iz Search Console-a, poređenjem uporedivih perioda. To je činjenica o tom periodu na tom sajtu, ne obećanje da će isto važiti i za vas.

AI vidljivost, bez uljepšavanja

I vidljivost u AI odgovorima se meri, i rezultati nisu uvek lepi. Ali merljivo se može popraviti, a nemerljivo ne. Kad pratite pominjanja u AI asistentima, zapišite metodologiju i datum merenja, jer se rezultati menjaju od upita do upita.

Pitanja koja treba da postavite izvođaču

Ova pitanja razdvajaju sistem od skripte:

1. Da li meri indeksaciju i kako? Dobar odgovor pominje URL Inspection API ili GSC izvoz, i razliku između objavljenog i indeksiranog.
2. Šta se dešava kad LLM pukne ili vrati grešku? Treba da postoji retry, failover na drugog provajdera i pravilo šta se radi sa napola završenim tekstom. Važno je razlikovati uzroke: Anthropic 429 može značiti prekoračen rate limit ili mesečni spend cap, a spend-cap 429 nema retry-after header i ne prolazi dok se pristup ne vrati, pa automatski retry tu ne pomaže. 529 znači privremenu preopterećenost (Claude API errors, Rate limits). Drugi provajderi imaju svoje kodove grešaka, na primer Z.ai za svoj GLM API (Z.ai dokumentacija). Failover koji ne razlikuje ove slučajeve loše radi.
3. Ko vidi kad nešto tiho prestane da radi? Ako je odgovor "pogledamo ručno", to nije sistem.
4. Da li može da pokaže sopstveni sistem u produkciji? Ne demo, nego pravi sajt sa pravim brojevima, uključujući one neprijatne.

Česte greške

• Objavljivanje bez provere indeksacije. Stotinu objavljenih stranica od kojih je samo deo indeksiran nije stotinu stranica sadržaja, nego znatno manje.
• Merenje samo ukupnih brojeva. Rast na jednom kanalu sakriva potpuni pad na drugom, kao u slučaju registracije.
• Nema alarmiranja. Sistem koji radi bez nadzora mora da javi kad prestane da radi. Tišina nije dobra vest.
• Količina umesto vrednosti. Masovno generisanje bez dodate vrednosti nije samo gubitak truda, nego i rizik po spam politiku.

Šta bih ja uradio

Na vašem mestu počeo bih od jednog sajta i jednog izvora istine, i odmah postavio merenje po segmentima, pre nego što se objavi prvi tekst. Alarm "objavljeno, a nije indeksirano posle X dana" i alarm "pokušaji bez ishoda" su jeftini za izgradnju, a spašavaju od nedelja tihog kvara. Tek kad pilot pokaže da lanac radi do kraja, širio bih se na sledeći sajt ili jezik. I tražio bih da vidim brojeve, uključujući slabe.

Kako izgleda prvi razgovor

Prvi razgovor je mapiranje: koji sajtovi i koji ciljevi, pregled postojećeg sadržaja i trenutne indeksacije, dogovor o pilotu na jednom sajtu i šta se meri od prvog dana. Ako vam to zvuči kao razgovor koji želite da vodite, javite se preko lazar-milicevic.com/#contact, a više o sistemu možete videti na bizflowai.io.