Najveća promena na Odmori365 nije novi dizajn, nova mapa ili još jedan AI alat. Najveća promena je što smo prestali da razmišljamo o sajtu kao skupu stranica i počeli da ga gradimo kao sistem.
Na početku je sve izgledalo mnogo jednostavnije. Imamo turistički portal, nekoliko vodiča, nekoliko objekata i ideju da vlasnicima smeštaja ponudimo profesionalniji profil. Delovalo je kao klasičan WordPress posao: napravi stranicu, ubaci slike, napiši tekst, dodaj kontakt i objavi.
Problem je što takav način rada lepo funkcioniše sa dva ili tri partnera. Sa deset počinje da zamara. Sa trideset postaje ozbiljan operativni problem. A ako jednog dana imate sto ili više objekata, ručno menjanje kartica, mapa, kategorija, profila i različitih prikaza više nije posao — to je recept za greške.
Zato je cilj postao drugačiji: partner treba da se unese jednom, a sistem zatim treba da zna gde sve taj partner pripada. Profil, kartica, slider, mapa, relevantna kategorija, destinacija i drugi prikazi ne bi smeli da zahtevaju novo ručno unošenje istih podataka.
U ovom AEO AI Media Lab zapisu objašnjavamo kako smo došli do tog modela, šta smo prvo uradili pogrešno, gde smo usporili sajt, zašto nam je četvrti partner nestajao sa mape, kako smo razlikovali stvarni problem od PageSpeed greške i šta smo na kraju naučili o WordPress automatizaciji malog digitalnog proizvoda.
Početna ideja: napraviti lep turistički portal
Prva verzija Odmori365 bila je klasičan sadržajni projekat. Fokus je bio na stranicama kao što su vikend za dvoje, privatni spa, romantični smeštaj, brvnare, đakuzi i destinacije. To je imalo smisla jer korisnik retko počinje pretragu imenom objekta. Češće počinje potrebom: želi privatnost, bazen, saunu, dobar pogled ili mesto do kog može da stigne za vikend.
Takva struktura je dobra za korisnika i dobra je osnova za SEO. Ali kada su počeli da stižu prvi partneri, pojavilo se drugo pitanje: kako da partner ne bude samo još jedan članak na sajtu?
Ako vlasnik objekta dobije samo jednu stranicu koju niko ne vidi, partnerski model nema veliku vrednost. Profil mora da bude povezan sa drugim delovima sistema. Ako je objekat na Zlatiboru, treba da postoji u relevantnim prikazima Zlatibora. Ako ima bazen, privatni spa ili đakuzi, treba da može da se pojavi tamo gde korisnik traži upravo takav sadržaj. Ako postoji mapa, objekat mora da bude na mapi. Ako početna ima izdvojena mesta, sistem treba da može da povuče partnera bez ručnog pravljenja nove kartice svaki put.
Tu smo prvi put shvatili da ne gradimo samo portal. Gradimo malu bazu podataka sa više interfejsa.
Prva velika greška: isti podatak na više mesta
Najbrži način da napravite ranu verziju proizvoda jeste da podatke upišete tamo gde vam trenutno trebaju. I upravo je to zamka.
Ime objekta može da završi u tekstu profila, zatim ponovo u kartici, pa ponovo u mapi, pa u nekom JavaScript nizu, pa u drugoj verziji kartice. Cena se promeni na jednom mestu, a na drugom ostane stara. Doda se novi partner, ali mapa ga ne zna. Promeni se URL, a jedan deo sajta i dalje vodi na stari.
To je klasičan problem dupliranja podataka. U početku deluje bezazleno, jer je ručno najbrže. Kasnije postaje jedan od glavnih izvora tehničkog duga.
Naš cilj je zato postao ono što se u razvoju proizvoda često zove single source of truth: jedan glavni zapis partnera iz kog drugi delovi sajta povlače podatke.
U WordPress-u je prirodno mesto za to poseban tip sadržaja za objekte, sa metapodacima kao što su naziv, lokacija, cena, sadržaji, kontakt, status partnera i koordinate. Kada sistem ima takvu osnovu, više nije potrebno da svaki prikaz živi sopstvenim životom.
Kako danas razmišljamo o partneru
Partner više nije „stranica“. Partner je zapis koji ima više izlaza.
Kada je objekat pravilno unet u WordPress, njegova vrednost nije samo u pojedinačnom PRO profilu. Isti podaci mogu da hrane karticu na početnoj, slider sa izdvojenim partnerima, prikaz u relevantnom vodiču, mapu i kasnije druge funkcije kao što su preporuke, filtriranje i Match.
To menja ekonomiju celog projekta. Svaki novi partner ne zahteva pet novih ručnih zadataka. On povećava vrednost postojeće infrastrukture.
Najjednostavnije rečeno:
- partner se unosi jednom;
- profil koristi isti skup podataka;
- kartice koriste isti skup podataka;
- slider prikazuje aktuelne partnere;
- mapa dobija koordinate i status iz centralnog izvora;
- novi prikazi kasnije mogu da koriste iste podatke bez ponovnog unosa.
To još nije „potpuni autopilot“ u kome čovek više ništa ne proverava. Fotografije, tačnost podataka, tekst i kvalitet prezentacije i dalje zahtevaju uredničku kontrolu. Ali ručni posao se pomera sa kopiranja podataka na proveru kvaliteta. To je mnogo zdraviji model.
Kartice su izgledale kao dizajn problem, a zapravo su bile problem skaliranja
Jedna od poslednjih većih izmena bila je redizajn partnerskih kartica i uvođenje slidera za više partnera. Na prvi pogled to je vizuelna izmena. U praksi je to bila promena načina na koji početna strana koristi bazu partnera.
Sa jednim ili dva objekta možete ručno napraviti lepu sekciju. Kada broj raste, kartice moraju da budu generisane iz podataka. Slider mora da zna koliko partnera postoji. Navigacija ne sme da zavisi od toga da li je urednik ručno dodao novu karticu u HTML.
Tu smo dobili važnu lekciju: dobar frontend nije samo lep interfejs. Dobar frontend mora da bude spreman za podatke koji još ne postoje.
Ako danas imate četiri partnera, komponenta mora da radi i kada ih bude četrdeset. Ne mora odmah da prikazuje svih četrdeset, ali struktura ne sme da se raspadne zato što je napravljena oko fiksnog broja elemenata.
Mapa: od ručnog spiska do živog prikaza partnera
Mapa je bila možda najbolji primer razlike između demo funkcije i stvarnog sistema.
Prvu mapu je lako napraviti sa ručno upisanim podacima. U JavaScript fajlu navedete nekoliko objekata, njihove koordinate i nazive i sve radi. Za demonstraciju je to sasvim dovoljno.
Ali čim je stigao novi partner, pojavila se rupa u modelu. Na sajtu je postojao četvrti partner — Luna Vineyard Glamping u Sremskim Karlovcima — ali na velikoj mapi su se u jednom trenutku prikazivala samo tri objekta.
To je bio trenutak kada je postalo jasno da nije dovoljno da mapa „radi“. Mora da bude povezana sa istim podacima kao i WordPress.
Proverom smo videli da WordPress partnerski API već vraća sva četiri aktuelna partnera, uključujući status i koordinate. To je značilo da problem nije u samom unosu objekta, već u sloju između baze i statičke aplikacije mape: stari podaci, cache ili verzija aplikacije koja nije koristila najsvežiji izvor.
Kada se četvrti partner pojavio na mapi bez ponovnog ručnog crtanja kartice, dobili smo ono što smo zapravo želeli od početka: mapa mora da bude pogled na bazu, a ne odvojena baza.
To je princip koji planiramo da zadržimo i za buduće partnere. Novi objekat koji ispunjava potrebne uslove treba da se pojavi kroz sistem, a ne kroz ručno menjanje posebnog JavaScript spiska svaki put.
Onda smo napravili novu grešku: automatizovali smo pre nego što smo izmerili cenu
Kada dodate automatizaciju, prirodna reakcija je da dodate još automatizacije. Partner profil je već imao podatke, pa je delovalo logično da ispod njega dodamo još jedan koristan modul: mapu i sadržaj „šta je blizu“, kako bi gost mogao da vidi okolinu.
Ideja je dobra. Implementacija je, međutim, otvorila novi problem.
Posle poslednjih izmena pojedinačni partner profil počeo je povremeno da se otvara veoma sporo. U realnom testu čekanje je išlo i do približno 20 sekundi. To više nije estetski problem. Ako korisnik čeka 20 sekundi da vidi smeštaj, izgubili smo smisao svih ostalih optimizacija.
Prvi instinkt je bio da sumnjamo na pluginove. Na sajtu je bilo više dodataka, uključujući share dugmad i nekoliko administratorskih alata. Isključili smo ono što očigledno nije bilo neophodno, ali problem se time nije objasnio.
Važniji trag bio je vremenski: usporenje se pojavilo posle promena na partner prikazima i dodavanja mape ispod profila. To je mnogo bolji način za dijagnostiku od nasumičnog gašenja svega redom. Kada nešto pukne, prvo gledamo šta se promenilo neposredno pre kvara.
Zašto je Leaflet postao važan detalj
Za mapu koristimo Leaflet, laganu JavaScript biblioteku za interaktivne mape. Sama biblioteka nije problematična po definiciji. Problem nastaje kada se takav kod učitava u trenutku kada korisniku još nije potreban.
Na početnoj strani mapa se nalazi niže od prvog ekrana. Ipak, Leaflet i MarkerCluster su se učitavali odmah pri otvaranju stranice. To znači da mobilni uređaj troši vreme na JavaScript za element koji korisnik možda neće ni videti.
Promenili smo pristup: biblioteke za mapu ne moraju da budu deo početnog opterećenja. Mogu da se učitaju tek kada se korisnik približi mapi tokom skrolovanja. Vizuelno se ništa ne menja. Funkcija ostaje ista. Ali se početni rad browsera smanjuje.
Ovo je važna lekcija za svaki WordPress projekat koji preraste običan blog: optimizacija nije samo kompresovanje slike. Često je važnije odlučiti kada se određena funkcija uopšte učitava.
PageSpeed nas je skoro odveo u pogrešnom smeru
Posle optimizacije pojavila se nova frustracija. Google PageSpeed Insights za mobilni prikaz nije davao normalan Performance rezultat. Umesto broja dobijali smo crveni uzvičnik, dok je Largest Contentful Paint vraćao „Error“ i oznaku NO_LCP.
Na prvi pogled izgleda katastrofalno. Još gore, druge stavke kao što su Total Blocking Time i pojedini dijagnostički testovi takođe su počele da prikazuju greške.
Da smo gledali samo crveni simbol, mogli smo da počnemo da razmontiravamo sajt koji se korisniku zapravo normalno otvara.
Zato smo proverili više izvora. Desktop Lighthouse test je u jednom merenju dao rezultat 98/100, sa LCP oko 1,1 sekundu i TBT od samo 20 ms. WordPress/PHP odgovor je bio brz. Filmstrip mobilnog testa je pokazivao da se stranica zaista renderuje. Istovremeno je mobilni Lighthouse odbijao da registruje LCP.
Tokom ponovljenih automatizovanih provera hosting je jednom vratio i HTTP 429 — Too Many Requests. To nije dokaz da je hosting bio jedini uzrok, ali je dodatni signal da automatizovani test nije isto što i iskustvo realnog korisnika.
Najvažnija odluka bila je da prestanemo da „popravljamo skor“ i vratimo se pitanju: da li je stranica stvarno spora?
To je razlika između optimizacije proizvoda i optimizacije za alat za merenje.
Šta zapravo znači „automatska mašina“
Kada kažemo da smo napravili automatsku mašinu, ne mislimo da sistem radi bez čoveka. To bi bila loša definicija.
Za nas automatizacija znači da čovek donosi odluku jednom, a softver je dosledno prenosi kroz sistem.
Ako partner promeni cenu, cilj je da se cena promeni iz centralnog podatka, a ne na pet ručno održavanih mesta. Ako se novi partner aktivira, relevantni prikazi treba da ga prepoznaju. Ako objekat više nije aktivan, ne treba ručno juriti svaki modul u kom se nekada pojavljivao.
Čovek i dalje odlučuje da li je partner kvalitetan, koje fotografije predstavljaju objekat, da li je opis tačan, koji sadržaji se ističu i da li profil zaslužuje PRO status. Automatizacija preuzima ponavljanje, ne odgovornost.
AI nije napisao sistem umesto nas — ali je promenio brzinu rada
Ovaj projekat je dobar primer zašto veštačku inteligenciju ne treba svoditi na pisanje članaka.
AI nam je pomagao da pregledamo WordPress strukturu, pronađemo gde se učitavaju određeni skriptovi, analiziramo šta se promenilo između dve verzije, proverimo REST podatke, formulišemo sigurnije izmene i mnogo brže ponovimo ciklus testiranja.
To ne znači da model „zna“ šta je pravi proizvod. Kada smo previše brzo dodali funkciju koja je pogoršala performanse, alat nas nije automatski sprečio. Kada je mapa imala tri umesto četiri partnera, bilo je potrebno razumeti tok podataka. Kada je PageSpeed pokazao crveni uzvičnik, bilo je potrebno razlikovati signal od šuma.
AI ubrzava rad, ali i ubrzava grešku. Zato je važnije imati dobar proces nego imati najnoviji model.
O ovome smo već pisali u našem prvom Odmori365 case study-ju o izgradnji turističkog portala uz AI i WordPress. Ovaj tekst je sledeća faza: šta se dešava kada prototip prestane da bude prototip i počne da dobija prave partnere, podatke i operativni teret.
Od portala do proizvoda: gde smo otišli dalje nego što smo planirali
Početna ideja bila je sadržaj + partneri. Danas je sistem mnogo širi.
Imamo sadržajne stranice koje hvataju nameru korisnika. Imamo partnerske profile koji nose strukturirane podatke. Imamo kartice i slider koji predstavljaju objekte na mestu gde korisnik već bira. Imamo veliku mapu kao poseban interfejs. Imamo Match kao pokušaj da korisniku suzimo izbor. Imamo višejezični sloj za deo partnerske prezentacije. Imamo centralizovaniji model podataka koji može da hrani nove funkcije.
To je važna promena: sadržaj više nije krajnji proizvod. Sadržaj postaje jedan ulaz u sistem.
Korisnik može da dođe preko Google vodiča, društvene objave, direktnog linka partnera, početne strane, mape ili Match-a. Svi ti putevi treba da vode ka istim pouzdanim podacima o objektu.
Šta bismo danas uradili drugačije
Da ponovo gradimo isti sistem od nule, nekoliko stvari bismo postavili ranije.
Centralni model podataka pre posebnih interfejsa
Prvo bismo definisali koja polja svaki partner mora da ima: naziv, status, plan, lokaciju, koordinate, cenu, kapacitet, sadržaje, kontakt, URL, fotografije i verifikaciju. Tek onda bismo gradili kartice, mapu i Match.
To smanjuje broj kasnijih migracija i ručnih zakrpa.
Performance budžet pre dodavanja funkcije
Svaka nova interaktivna funkcija treba da odgovori na dva pitanja: koliko vrednosti daje korisniku i koliko košta u učitavanju. Ako se nalazi ispod prevoja, verovatno ne mora da se učita u prvoj sekundi.
Automatski test reprezentativnog partner profila
Posle svake veće izmene kartica, mape ili partnerskog template-a treba otvoriti jedan pravi profil i proveriti realno vreme učitavanja. Tako se problem otkrije pre nego što ga primeti korisnik.
Manje paralelnih izmena
Kada istog dana promenite kartice, mapu, template partnera, cache i nekoliko pluginova, mnogo je teže znati šta je izazvalo problem. Manje serije izmena daju bolju dijagnostiku.
Zašto je ovo važno i van turizma
Odmori365 je turistički projekat, ali obrazac je primenljiv mnogo šire.
Isti model može da postoji na portalu za restorane, ordinacije, stručnjake, nekretnine, događaje, lokalne usluge ili bilo koji direktorijum u kome jedan entitet treba da se pojavljuje na više mesta.
Ključna ideja je ista: ne pravite pet kopija istog podatka. Napravite jedan dobar podatak i pet pametnih prikaza.
LLMO i AEO lekcija: sistem je jači kada su podaci jasni
Postoji još jedan razlog zbog kog nam je ova arhitektura važna: AI pretraga i answer engine sistemi bolje rade sa sadržajem koji ima jasne entitete, veze i konzistentne podatke.
Ako je naziv objekta na jednoj stranici drugačiji nego na mapi, ako cena nema jasan izvor, ako lokacija nije dosledna i ako sadržaji postoje samo u slobodnom tekstu, sistem je teže razumljiv i ljudima i mašinama.
Ne postoji magični AEO trik koji garantuje citiranje u AI odgovoru. Ali postoji zdrava tehnička osnova: jasan entitet, stabilan URL, konzistentni podaci, razumljiva struktura, korisni odgovori i dobro interno povezivanje.
Zato LLMO za nas nije pravljenje teksta „za robote“. To je pravljenje sistema koji ne tera ni korisnika ni mašinu da nagađaju šta nešto znači.
Gde smo sada
U trenutku pisanja ovog teksta, četiri aktuelna partnera mogu da se prikažu na velikoj mapi, a partnerski sistem više nije zamišljen kao skup izolovanih ručnih kartica. Novi frontend elementi koriste centralizovanije podatke, mapa je odvojena od ručno održavanog statičkog spiska, a teže map biblioteke na početnoj ne moraju da budu deo prvog učitavanja.
To ne znači da je sistem završen. Naprotiv. Sledeći test dolazi tek kada baza poraste. Četiri partnera dokazuju da koncept radi. Trideset će pokazati da li arhitektura zaista štedi vreme. Sto će pokazati gde su nova uska grla.
Naš cilj nije da sada dodajemo funkcije samo zato što možemo. Cilj je da svaki sledeći partner bude lakši za unos i bolji za korisnika nego prethodni.
Najvažnija lekcija: automatizacija počinje odbijanjem duplog rada
Najvredniji trenutak u celom procesu nije bio kada smo napravili mapu niti kada se četvrti partner konačno pojavio na njoj. Najvredniji trenutak bio je kada smo prestali da prihvatamo rečenicu: „Za svakog novog partnera samo ćemo ovo ručno da dodamo i ovde.“
Ta rečenica zvuči bezazleno. Ali svaki put kada je ponovite, gradite budući posao koji neko mora da radi zauvek.
Automatizacija počinje pitanjem: zašto isti podatak unosimo drugi put?
Ako nema dobrog razloga, verovatno postoji način da sistem uradi taj deo umesto nas.
Upravo tu vidimo najveću vrednost kombinacije WordPress-a, AI asistencije i sopstvene logike proizvoda. Ne u tome da AI napravi još jedan tekst ili još jednu stranicu, već u tome da mali tim može da napravi sistem koji bi ranije zahtevao mnogo više ručnog rada i tehničkog vremena.
To je ono što danas nazivamo našom malom automatskom mašinom. Nije savršena. Nije završena. Ali više nije samo sajt.
Odmori365 je počeo kao portal. Polako postaje infrastruktura.
Najčešća pitanja
Da li je Odmori365 potpuno automatizovan?
Ne. Podaci partnera i više prikaza su sve više povezani, ali urednička kontrola ostaje obavezna. Fotografije, opis, status, kontakt i kvalitet profila proverava čovek. Automatizujemo ponavljanje, ne odgovornost.
Kako se novi partner pojavljuje na mapi?
Cilj sistema je da mapa koristi aktuelne partnerske podatke iz WordPress-a, uključujući status i koordinate, umesto posebnog ručno održavanog spiska. Tako se izbegava da svaki novi partner zahteva zasebnu izmenu aplikacije mape.
Zašto je sajt bio spor posle dodavanja novih funkcija?
Najveća sumnja bila je na nove frontend funkcije oko partner profila i mapa. U optimizaciji smo posebno gledali kada se Leaflet i drugi JavaScript resursi učitavaju, jer funkcija koja je niže na stranici ne mora da optereti prvo otvaranje.
Da li PageSpeed rezultat treba da bude jedini kriterijum?
Ne. PageSpeed je važan dijagnostički alat, ali rezultat mora da se uporedi sa realnim učitavanjem, server response vremenom i drugim testovima. U našem slučaju mobilni Lighthouse je povremeno vraćao NO_LCP i nije uspevao da izračuna Performance, dok su drugi testovi pokazivali normalno renderovanje i veoma dobar desktop rezultat.
Može li WordPress da bude osnova za ovakav proizvod?
Za ranu i srednju fazu — da. WordPress omogućava brzo upravljanje sadržajem, custom post type-ove, metapodatke i REST API. Važno je da se struktura podataka projektuje kao sistem, a ne kao niz ručno povezanih stranica.
Gde se ovde koristi AI?
AI koristimo kao asistenta za istraživanje, pisanje, analizu strukture, debugging, WordPress operacije i brže iteracije. Poslovna pravila, provera podataka, prioriteti i finalne odluke ostaju ljudski posao.
Više tekstova iz ove serije nalazi se u kategoriji AEO AI Media Lab, gde javno dokumentujemo kako gradimo i popravljamo sopstvene digitalne proizvode.