Cloudflare za WordPress: napredni vodič za Rules, cache i Workers

Od CDN-a do pravila koja se izvršavaju prije WordPressa

U prvom dijelu Cloudflare vodiča prošli smo osnovnu konfiguraciju za WordPress: DNS, SSL/TLS, zaštitu, cache i postavke performansi. To je dovoljno da Cloudflare počne raditi ono zbog čega ga većina vlasnika web stranica koristi: filtrirati promet, posluživati statički sadržaj i smanjivati opterećenje web servera.

No, Cloudflare može puno više od toga.

Pomoću Cloudflare Rulesa možemo odlučiti što će se dogoditi s pojedinim zahtjevom prije nego što uopće stigne do WordPressa. Možemo preusmjeriti stari URL, zaobići cache za administratorsko sučelje, promijeniti HTTP zaglavlje ili primijeniti drugačije ponašanje samo na određeni dio web stranice.

A kada Rules više nisu dovoljni, tu su Cloudflare Workers – mali programi koji se izvršavaju na Cloudflareovoj mreži i omogućuju znatno složeniju logiku bez pokretanja PHP-a na našem hostingu.

U ovom vodiču nećemo pokušavati uključiti svaku opciju koju Cloudflare nudi. Fokusirat ćemo se na nekoliko funkcija koje imaju smisla na tipičnom WordPress sajtu i pokazati ih na konkretnim primjerima.

Page Rules su stari način rada

Ako ste ranije čitali Cloudflare tutorijale, gotovo sigurno ste naišli na Page Rules.

Godinama su bili glavni način za postavljanje posebnih pravila za određene URL-ove. Jednim Page Ruleom moglo se, primjerice, napraviti preusmjeravanje, promijeniti cache ili isključiti određene Cloudflare funkcije.

Page Rules još uvijek postoje, ali za nove konfiguracije Cloudflare preporučuje moderni Rules sustav.

Umjesto jednog univerzalnog alata danas postoje specijalizirana pravila:

• Redirect Rules za preusmjeravanja
• Cache Rules za kontrolu cachea
• Transform Rules za izmjene URL-ova i HTTP zaglavlja
• Configuration Rules za promjenu određenih Cloudflare postavki
• te još nekoliko specijaliziranih vrsta pravila.

To nije samo promjena naziva. Moderni Rules mogu koristiti znatno više podataka o HTTP zahtjevu, pravila se mogu kombinirati, a Cloudflare ima i alat Trace kojim možemo provjeriti koja su se pravila stvarno izvršila.

Zbog toga ćemo u ovom vodiču koristiti moderni Rules sustav. Page Rules vrijedi poznavati zbog starijih konfiguracija i tutorijala, ali novi WordPress setup nema razloga graditi oko njih.

Redirect Rules: preusmjeravanje prije nego zahtjev stigne do WordPressa

Jedan od najjednostavnijih primjera onoga što Cloudflare Rules mogu napraviti jest preusmjeravanje URL-a.

Pretpostavimo da smo na WordPress sajtu promijenili adresu nekog članka. Posjetitelj ili Google i dalje pokušavaju otvoriti stari URL, pa ih želimo poslati na novi.

To možemo riješiti WordPress pluginom ili pravilom na web serveru, ali u tom slučaju zahtjev prvo mora doći do našeg hostinga. Cloudflare Redirect Rule može odgovoriti već na svojoj mreži, prije nego što se WordPress uopće pokrene.

Put zahtjeva tada izgleda otprilike ovako:

Posjetitelj → Cloudflare → preusmjeravanje

umjesto:

Posjetitelj → Cloudflare → hosting → WordPress → plugin → preusmjeravanje

Za pojedinačna ili dinamička preusmjeravanja Cloudflare preporučuje Single Redirects. Dostupni su na svim planovima, a Free plan trenutačno omogućuje do deset takvih pravila. Wildcard obrasci dostupni su i besplatnim korisnicima, dok je podrška za regularne izraze rezervirana za više planove.

Cloudflare podržava statična preusmjeravanja prema jednom zadanom URL-u, ali i wildcard pravila kojima jedno pravilo može pokriti veći broj adresa. Moguće je odabrati i hoće li se zadržati postojeći query string.

Za trajno preseljenje stranice najčešće ćemo koristiti 301 Permanent Redirect. Ako je promjena privremena, prikladniji je 302 Temporary Redirect. Cloudflare podržava i statuse 307 i 308, koji za razliku od 301 i 302 jamče očuvanje izvorne HTTP metode, ali za tipična WordPress preusmjeravanja najčešće nam neće biti potrebni.

Za ovaj vodič napravili smo jednostavan test na webmajestori.net. Nepostojeću adresu /cloudflare-test/ privremeno smo preusmjerili na naslovnicu. Budući da je riječ samo o testu, koristili smo status 302, provjerili da pravilo radi i nakon snimanja primjera možemo ga bez posljedica ukloniti.

Ako selimo stotine ili tisuće URL-ova, Single Redirects više nisu najbolji izbor. Za takve migracije Cloudflare nudi Bulk Redirects, a Free račun trenutačno podržava do 10.000 URL preusmjeravanja kroz Bulk Redirect liste.

Cache Rules: najvažnija napredna Cloudflare funkcija za WordPress

Cloudflare već u osnovnoj konfiguraciji cacheira tipične statične datoteke poput slika, CSS-a i JavaScripta. HTML stranice, poput WordPress članaka i naslovnice, prema zadanim postavkama nisu automatski spremljene u Cloudflareov edge cache.

To možemo promijeniti pomoću Cache Rulesa.

Ideja je jednostavna. Ako Cloudflare već ima spremljenu kopiju stranice, posjetitelju je može vratiti iz svojeg podatkovnog centra bez čekanja da hosting pokrene PHP, WordPress, temu, plugine i upite prema bazi podataka. Na prometnijem sajtu to može znatno smanjiti opterećenje origin servera.

Upravo zato je full-page cache jedna od Cloudflare opcija s kojom treba biti oprezan.

„Eligible for cache” nije bezazlena opcija

Kod izrade Cache Rulea Cloudflare nam nudi dvije osnovne mogućnosti:

• Bypass cache – zahtjev se neće cacheirati
• Eligible for cache – sadržaj smije biti spremljen u Cloudflare cache

Važan detalj lako se previdi: kod modernih Cache Rulesa odabirom Eligible for cache za odgovarajući zahtjev omogućujemo i cacheiranje sadržaja koji se inače ne bi cacheirao, uključujući HTML. To je ponašanje koje se u starim Page Rules tutorijalima često nazivalo Cache Everything.

Pravilo poput „cache cijeli webmajstori.net” nije nešto što treba uključiti i zaboraviti.

WordPress nije potpuno statičan sajt. Administratorsko sučelje, prijava korisnika, obrasci, personalizirani sadržaj i stranice koje ovise o sesiji moraju ostati dinamični.

WordPress admin i login moraju zaobići full-page cache

Najjednostavniji primjer sigurnog Cache Rulea jest izuzimanje:

/wp-admin/ i /wp-login.php iz cachea.

Za zahtjeve prema tim adresama postavljamo Cache eligibility → Bypass cache. Cloudflare tada zahtjev šalje prema origin serveru umjesto da pokušava poslužiti spremljenu HTML kopiju.

To je važno jer agresivno cache-ana login stranica može uzrokovati probleme sa session cookiejima, prijavom korisnika ili stanjem obrazaca. Cloudflare u svojoj dokumentaciji posebno upozorava da login, account i checkout stranice ne treba cache-ati kao obični HTML.

Što je s već prijavljenim WordPress korisnikom?

Samo izuzimanje /wp-admin/ nije dovoljno.
Prijavljeni administrator može otvoriti i običan članak na frontendu, ali taj prikaz može sadržavati administratorsku traku ili drugi personalizirani sadržaj. WordPress tada koristi login cookie, pa naprednija konfiguracija može napraviti bypass cache-a kada request sadrži odgovarajući WordPress cookie.

Cloudflare Cache Rules mogu donositi odluke i prema cookie-ima u zahtjevu. To omogućuje vrlo korisnu logiku:

anonimni posjetitelj → cache

prijavljeni korisnik → origin

Cloudflare upravo takav pristup preporučuje i u svojoj dokumentaciji za ubrzavanje WordPressa.

Ipak, cookie pravilo ne treba slijepo kopirati s drugog sajta. Prije uključivanja treba provjeriti koje cookieje konkretna WordPress instalacija i njezini plugini koriste.

WooCommerce zahtijeva još više opreza

Ako WordPress site koristi WooCommerce, popis iznimki postaje znatno važniji.

Košarica, checkout, korisnički račun i WooCommerce session cookieji ovise o pojedinom posjetitelju. Posluživanje cache-ane verzije takve stranice može značiti prikaz pogrešne košarice, zastarjelog stanja ili probleme s prijavom.

Zbog toga full-page Cloudflare cache na WooCommerce sajtu ne treba uključivati dok nisu precizno definirane stranice i cookieji koji moraju zaobići cache.

Edge TTL i Browser TTL nisu ista stvar

Kod Cache Rulesa susrest ćemo još dva slična pojma.

Edge Cache TTL određuje koliko dugo Cloudflare svoju kopiju resursa smatra svježom u vlastitoj mreži.

Browser Cache TTL određuje koliko dugo kopiju smije zadržati browser posjetitelja.

Možemo, primjerice, željeti da Cloudflare dulje zadržava kopiju članka na svojim edge serverima, ali da browser posjetitelja češće provjerava postoji li novija verzija.

Na Free planu minimalni ručno zadani Edge Cache TTL trenutačno je dva sata. Cloudflare također upozorava da purge njihovog cachea ne može ukloniti datoteku koja je već spremljena u browseru posjetitelja. Zbog toga s visokim Browser TTL vrijednostima treba biti oprezniji nego s edge cacheom.

Praktično pravilo je jednostavno: edge cache možemo kontrolirati centralno, ali jednom kada sadržaj pošaljemo u browser s dugim TTL-om, više nemamo jednaku kontrolu nad tom kopijom.

Cache Response Rules: kontrola odgovora origin servera

Klasični Cache Rule donosi odluku na temelju zahtjeva koji dolazi prema Cloudflareu. Cache Response Rule radi kasnije, nakon što Cloudflare primi odgovor našeg web servera, ali prije nego odluči kako će taj odgovor spremiti u cache.

To znači da pravilo može reagirati i na informacije koje prije kontakta s WordPressom još nisu postojale.
Cache Response Rules mogu, primjerice:

• promijeniti Cache-Control direktive poput max-age, s-maxage ili stale-while-revalidate
• dodavati cache tagove za preciznije čišćenje cachea
• ukloniti ETag, Last-Modified ili Set-Cookie iz odgovora prije cacheiranja.

Na Free planu dostupno je do 10 Cache Response Rules.

Ovo je vrlo moćan alat, zato s njim treba biti oprezan. Primjerice, uklanjanje Set-Cookie zaglavlja može pomoći u vrlo specifičnim cache scenarijima, ali na WordPress stranici koja koristi sesije, prijavu korisnika ili personalizirani sadržaj može izazvati ozbiljne probleme.

Za većinu WordPress sajtova Cache Rules ostaju prvi alat koji treba koristiti. Cache Response Rules imaju smisla kada točno znamo što origin server šalje i želimo promijeniti ponašanje tog odgovora bez izmjene WordPressa ili konfiguracije web servera.

Cloudflare pritom navodi i važnu razliku: Cache Rules određuju je li sadržaj uopće podoban za cacheiranje, dok Cache Response Rules upravljaju odgovorom nakon što stigne s origina.

Transform Rules: promjene bez diranja WordPressa

Transform Rules omogućuju da Cloudflare promijeni određene dijelove HTTP zahtjeva ili odgovora dok promet prolazi kroz njegovu mrežu. Možemo mijenjati URL, query string ili HTTP zaglavlja bez izmjena u WordPressu, .htaccess datoteci ili konfiguraciji web servera.

Cloudflare ih dijeli na nekoliko vrsta:

• URL Rewrite Rules mijenjaju path ili query string zahtjeva
• Request Header Transform Rules mijenjaju zaglavlja prije nego zahtjev stigne do našeg servera
• Response Header Transform Rules mijenjaju zaglavlja prije nego odgovor stigne do posjetitelja
• Managed Transforms nude nekoliko unaprijed pripremljenih izmjena

Free plan trenutačno omogućuje do deset aktivnih Transform Rulesa. Regularni izrazi nisu dostupni na Free planu, ali za većinu tipičnih WordPress primjera nisu ni potrebni.

Rewrite nije isto što i redirect

Redirect i URL Rewrite na prvi pogled mogu izgledati kao ista stvar, ali postoji važna razlika.

Kod redirecta browser dobije novu adresu:

/stara-stranica/ → /nova-stranica/

i korisnik u adresnoj traci vidi novi URL.

Kod rewritea Cloudflare može interno promijeniti URL zahtjeva, dok posjetitelju u browseru ostaje originalna adresa. Rewrite zato nije zamjena za 301 preusmjeravanje kod SEO migracije, nego alat za situacije u kojima želimo promijeniti način na koji se zahtjev obrađuje iza kulisa.

Sigurnosni HTTP headeri preko Cloudflarea

Za WordPress nam je posebno zanimljiv Response Header Transform Rule. Njime možemo dodavati, mijenjati ili uklanjati HTTP zaglavlja koja Cloudflare šalje posjetitelju.

Primjer jednostavnog sigurnosnog zaglavlja je:

X-Content-Type-Options: nosniff

Njime browseru govorimo da ne pokušava samostalno „pogađati” drugačiji MIME tip sadržaja od onoga koji je server deklarirao.

Cloudflare nudi i gotov Managed Transform pod nazivom Add security headers, ali ovdje vrijedi biti oprezan. U listopadu 2026. taj preset između ostalog dodaje X-XSS-Protection i Expect-CT.

Problem je što su oba zaglavlja danas zastarjela. MDN Expect-CT označava kao zastario (deprecated) jer moderni Chromium ionako provodi Certificate Transparency, X-XSS-Protection je također zastario i u nekim okolnostima čak može izazvati sigurnosne probleme.

Zato nije preporučljivo automatski uključivati cijeli Cloudflareov paket samo zato što nosi naziv „security headers”. Bolje je dodati samo zaglavlja koja razumijemo i koja stvarno želimo koristiti.

Isto posebno vrijedi za Content-Security-Policy (CSP). Dobro konfiguriran CSP može biti vrlo učinkovita sigurnosna mjera, ali WordPress site s analyticsom, oglasima, vanjskim fontovima, embedovima i različitim pluginovima lako se može pokvariti pogrešnim copy-paste pravilom. CSP zato nećemo uključivati samo radi ovog vodiča.

Rule simulator (Cloudflare Trace): provjerite izvršava li se pravilo stvarno

Nakon nekoliko kreiranih pravila lako je doći u situaciju gdje konfiguracija izgleda ispravno, ali rezultat nije onakav kakav očekujemo. Umjesto pogađanja možemo koristiti Rule simulator, alat koji Cloudflare u dokumentaciji i dalje naziva Cloudflare Trace.
Rule simulator simulira HTTP zahtjev kroz Cloudflareovu mrežu i pokazuje koje su konfiguracije i pravila evaluirani, koja su se podudarila sa zahtjevom i kojim su se redoslijedom izvršila.

Možemo zadati URL i HTTP metodu, ali i simulirati dodatne uvjete poput cookieja, request headera, user-agenta, države posjetitelja ili čak bot scorea. To Trace čini posebno korisnim kod složenijih Cache, Redirect i Transform Rulesa.

Primjerice, ranije smo napravili Cache Rule koji zaobilazi cache za WordPress /wp-admin/ i /wp-login.php. Ako Rule simulator pokrenemo za:

https://webmajstori.net/wp-admin

u rezultatima možemo provjeriti je li naš WordPress admin – bypass cache rule pronađen i izvršen.

Pravilo koje izgleda ispravno nije isto što i pravilo za koje smo provjerili da radi. Treba samo imati na umu da Rule simulator prikazuje simulirani zahtjev, a ne povijest stvarnih posjetitelja. Za analizu stvarnog produkcijskog prometa Cloudflare danas ima zasebne observability alate.

Cloudflare Workers: kada Rules više nisu dovoljni

Redirect, Cache i Transform Rules mogu riješiti velik broj tipičnih webmaster problema bez pisanja koda. Ali imaju granicu: pravilo provjerava određene uvjete i zatim izvršava unaprijed definiranu akciju.

Kada nam treba složenija logika, Cloudflare nudi Workers.

Worker je mali program koji se izvršava na Cloudflareovoj mreži. Može pregledati dolazni zahtjev, donijeti odluku, izmijeniti ga, kontaktirati drugi servis ili čak generirati cijeli HTTP odgovor bez pokretanja WordPressa.

Kod postojećeg sajta arhitektura može izgledati ovako:

Posjetitelj → Cloudflare Worker → WordPress server

Cloudflare za takve postojeće aplikacije preporučuje Worker Routes. Route povezuje određeni URL obrazac s Workerom, pa se kod izvršava samo kada zahtjev odgovara tom obrascu. Origin server pritom i dalje može ostati postojeći WordPress hosting.

Jednostavan primjer: odgovor bez WordPressa

Na primjer, želimo da adresa:

/edge-test/

vrati jednostavan odgovor direktno iz Cloudflarea. Worker može vratiti tekst poput:

Ovaj odgovor poslužio je Cloudflare Worker.

bez pokretanja PHP-a, WordPressa, teme, plugina ili baze podataka.

Dali smo trivijalan primjer, ali vrlo dobro pokazuje koncept. Ista tehnologija može se koristiti za API endpointove, autentikaciju, geografska pravila, izmjene odgovora, povezivanje s vanjskim servisima ili znatno kompleksniju edge logiku.

Rule ili Worker?

Dobro pravilo za održavanje konfiguracije je:

Zadatak	Prvi izbor
Preusmjeriti URL	Redirect Rule
Kontrolirati cache	Cache Rule
Promijeniti HTTP header	Transform Rule
Provjeriti ponašanje pravila	Rule simulator
Izvršiti vlastitu programsku logiku	Worker

Nema smisla pisati Worker ako problem možemo riješiti jednim preglednim Ruleom.

Free Workers plan trenutačno dopušta 100.000 zahtjeva dnevno, uz 10 ms CPU vremena po zahtjevu i 128 MB memorije, što je dovoljno za mnoge male edge funkcije.

Što postaviti na tipični WordPress site

Nakon svih ovih mogućnosti lako je steći dojam da dobar Cloudflare setup mora imati desetke pravila. U praksi je bolje krenuti s nekoliko jasnih pravila koja rješavaju konkretan problem.

Za većinu klasičnih WordPress sajtova razumna napredna konfiguracija izgleda ovako:

• koristiti Redirect Rules za važna trajna i privremena preusmjeravanja
• osigurati da /wp-admin/ i /wp-login.php zaobilaze full-page cache
• cacheirati HTML tek nakon što su definirane sve potrebne iznimke
• koristiti Transform Rules samo za HTTP zaglavlja koja stvarno želimo kontrolirati
• nakon svake važnije izmjene provjeriti ponašanje pomoću Rule simulatora
• koristiti Worker tek kada problem više nije moguće jednostavno riješiti običnim Ruleom.

Kod WooCommercea, membership sajtova i drugih aplikacija sa sesijama treba biti još konzervativniji. Cache pravilo koje je odlično za klasični blog može biti potpuno pogrešno za trgovinu ili korisnički portal.

Najbolja Cloudflare konfiguracija nije ona s najviše uključenih opcija, nego ona u kojoj možemo objasniti zašto svako pojedino pravilo postoji.

Najčešće pogreške kod Cloudflare Rulesa

Cacheiranje svega bez iznimki

Najčešća greška je pokušaj da se cijeli WordPress site pretvori u statični cache. Admin, login, session cookieji, obrasci i personalizirane stranice nisu običan statični HTML.

Cacheiranje WooCommerce košarice i checkouta

Košarica, checkout i korisnički račun ovise o konkretnom posjetitelju. Njihovo cacheiranje može proizvesti vrlo neugodne rezultate.

Worker za problem koji rješava jedno pravilo

Ako Redirect Rule može riješiti problem u nekoliko klikova, pisanje Workera samo povećava kompleksnost i održavanje.

Copy-paste sigurnosnih headera

HTTP sigurnosna zaglavlja nisu lista kvačica. Posebno CSP treba prilagoditi stvarnom sajtu, a ne kopirati s tuđeg tutoriala.

Promjena više pravila odjednom

Ako istovremeno promijenimo cache, redirect i headere, a nešto prestane raditi, sami smo si otežali dijagnostiku.

Bolji pristup je jednostavan: jedna promjena, jedan test, pa tek onda sljedeća promjena.

Česta pitanja

Treba li mi Cloudflare Pro za korištenje Rulesa?

Ne. Free plan već uključuje Redirect, Cache, Transform i nekoliko drugih vrsta pravila, uz određene limite. Za većinu manjih WordPress sajtova to je sasvim dovoljno za početak.

Može li Cloudflare zamijeniti WordPress cache plugin?

Ne nužno. Cloudflare cache i WordPress cache plugin rade na različitim razinama. Plugin može optimizirati generiranje stranice na samom serveru, dok Cloudflare može poslužiti već spremljenu kopiju prije nego zahtjev uopće stigne do WordPressa.

U nekim konfiguracijama rade vrlo dobro zajedno.

Trebam li još redirect plugin u WordPressu?

Ako imate nekoliko jednostavnih preusmjeravanja, Cloudflare Redirect Rules mogu biti dovoljni. Ako WordPress urednici često mijenjaju URL-ove ili trebaju upravljati velikim brojem redirecta direktno iz administracije, plugin i dalje može biti praktičniji.

Jesu li Workers besplatni?

Cloudflare ima Free Workers plan koji je dovoljan za mnoge male edge funkcije i eksperimente. Za zahtjevnije aplikacije postoje plaćeni limiti i dodatne mogućnosti.

Mogu li pogrešnim Ruleom srušiti web stranicu?

Da. Loš redirect može napraviti petlju, agresivan cache može prikazivati pogrešan sadržaj, a pogrešan sigurnosni header može blokirati legitimne resurse.

Zbog toga pravila treba uvoditi postupno i nakon svake promjene testirati rezultat.

Zaključak

Cloudflare postaje puno zanimljiviji kada ga prestanemo promatrati samo kao CDN.

Redirect Rules mogu zaustaviti nepotreban zahtjev prije WordPressa, Cache Rules smanjiti opterećenje hostinga, Transform Rules promijeniti HTTP odgovor bez diranja servera, a Workers omogućiti vlastitu programsku logiku direktno na Cloudflareovoj mreži.

Ali cilj nije uključiti sve što Cloudflare nudi.

Cilj je što više jednostavnih problema riješiti jednostavnim pravilom, a kompleksnost dodavati tek kada je stvarno potrebna.

Ako ste tek krenuli s Cloudflareom, prvo postavite osnovnu konfiguraciju iz prvog dijela vodiča. Tek nakon toga ima smisla graditi naprednija pravila poput ovih iz ovog članka.