Cara setting Cloudflare optimal untuk WordPress pada 2026 bukan dengan mengaktifkan semua tombol keamanan dan optimasi secara bersamaan. Pengaturan yang efektif harus menyeimbangkan DNS, SSL/TLS, cache, keamanan bot, dan kebutuhan aplikasi. Website yang terasa lebih cepat tetapi membuat pengunjung gagal login, salah melihat keranjang belanja, atau terjebak challenge bukan hasil optimasi.
Panduan ini memperbarui pengalaman asli penulis saat menghadapi DDoS dan scraper pada blognya serta menjelaskan menu Cloudflare modern. Tampilan Firewall Rules, Page Rules, dan Scrape Shield pada 22 screenshot lama disimpan sebagai dokumentasi historis; gunakan dokumentasi vendor terkini untuk konfigurasi baru.
Pengaturan Cloudflare yang direkomendasikan untuk WordPress
| Fitur | Baseline 2026 | Perlu diwaspadai |
|---|---|---|
| DNS web | Proxied jika layanan HTTP/HTTPS mendukung | Origin tetap terbuka dari subdomain lain |
| SSL/TLS | Full (strict) dengan sertifikat origin valid | Error 525/526 atau redirect loop |
| Cache | Cache Rules untuk aset dan halaman publik | Data pengguna tercache ke publik |
| Bot/WAF | Managed Rules dan challenge berdasarkan log | False positive pada pengunjung/Googlebot |
| Monitoring | Cache status, error, CWV dan konversi | Hanya berpatokan pada satu skor |
1. Cara setting DNS Cloudflare dengan benar
Tambahkan domain dan periksa seluruh record A, AAAA, CNAME, MX dan TXT sebelum mengubah nameserver. Untuk website yang memang perlu melewati Cloudflare, nyalakan Proxied (orange cloud) pada record HTTP/HTTPS yang didukung. Record email dan layanan non-web perlu penanganan khusus; jangan mem-proxy port yang tidak didukung. Pastikan layanan layanan email SMTP tidak rusak setelah migrasi DNS.
Untuk melindungi origin, lihat perlindungan IP origin, alamat IP, dan mengecek IP server. Orange cloud mengurangi paparan IP origin melalui record web, tetapi tidak menggantikan firewall server ketika IP diketahui dari sumber lain.
2. SSL Cloudflare: prioritaskan Full (strict)
Mode Full (strict) mengenkripsi koneksi browser–Cloudflare serta Cloudflare–origin dan memvalidasi sertifikat origin. Gunakan sertifikat CA publik atau Cloudflare Origin CA yang valid untuk hostname. Mode Full biasa tidak memeriksa sertifikat origin secara ketat, sedangkan Flexible tidak menyediakan enkripsi end-to-end menuju origin. Saat menyalakan Always Use HTTPS, periksa redirect loop, mixed content, serta canonical URL.
Jika muncul error 502 Bad Gateway, bedakan error upstream dari masalah TLS. Setelah migrasi WordPress, periksa koneksi origin sebelum mengubah redirect domain. redirect 301 membantu memahami perbedaan redirect permanen dari setting SSL.
3. Cloudflare Rules modern menggantikan ketergantungan pada Page Rules lama
Cloudflare pada 2026 memiliki Cache Rules untuk kelayakan caching dan TTL, Configuration Rules untuk setting pada request tertentu, Redirect Rules untuk perubahan URL, serta WAF Custom Rules untuk proteksi. Page Rules lama masih dapat ditemui tetapi Cloudflare menyarankan produk Rules yang lebih fleksibel untuk penggunaan baru. Periksa urutan prioritas sebab beberapa rule dapat saling berinteraksi.
Cache situs WordPress tanpa mengekspos konten privat
Jangan menerapkan cache everything secara membabi buta pada semua URL. Bypass cache untuk login, admin, keranjang, pembayaran, atau halaman personal; pertimbangkan cookie dan header yang relevan. Jika ada page cache dari plugin WordPress, pahami hubungan dengan cache edge agar purge dan variasi konten benar. Cache aset statis sering lebih mudah dan aman daripada cache HTML yang personalized.
4. Konfigurasi WAF dan Bot Management
Aktifkan managed rules sesuai paket, lalu periksa Security Events. Gunakan challenge yang terukur untuk traffic mencurigakan daripada memblokir seluruh negara, ASN, atau user agent hanya berdasarkan tebakan. Pengalaman lama penulis menghadapi scraping tetap berguna, tetapi prosedur proteksi bot AGC memerlukan bukti request dan evaluasi false positive. Pastikan pengunjung, crawler terverifikasi, API dan sistem monitoring dapat berfungsi.
Untuk lonjakan traffic, baca mitigasi DDoS dan pantau error server. Proteksi yang salah konfigurasi dapat mengganggu pengindeksan Google dan hasil pertumbuhan traffic. Website sebaiknya tetap mudah diakses oleh pelanggan sah.
5. Percepat WordPress lewat kompresi dan cache aset
Uji kompresi Brotli, HTTP/3 dan caching sesuai kebutuhan aktual, bukan hanya mengaktifkan semua fitur. Rocket Loader dapat menunda JavaScript, tetapi bisa mengubah perilaku menu, analitik atau checkout. Lakukan pengujian A/B teknis di staging dan bandingkan PageSpeed Insights serta loading blog setelah deploy. Pada halaman yang ramai, batas bandwidth hosting dan performa server masih menjadi faktor penting.
6. Jaga keamanan origin dan aplikasi
Batasi trafik langsung ke port web origin bila cocok dengan arsitektur, pertimbangkan Authenticated Origin Pulls atau Cloudflare Tunnel, dan lakukan backup. Untuk WordPress self-hosted, patching PHP, core, tema dan plugin harus tetap dilakukan. CDN tidak otomatis memperbaiki kerentanan WordPress. Audit technical SEO agar file sitemap, robots dan resource untuk rendering tetap tersedia.
7. Pengujian setelah mengubah setting Cloudflare
| Yang diuji | Tujuan |
|---|---|
| Homepage, artikel, kategori | HTML dan cache benar |
| Admin, login, form dan checkout | Tidak ter-cache publik |
| API, cron dan sitemap | Tidak terblokir WAF |
| SSL dan redirects | Tidak ada loop atau mixed content |
| Mobile performance | Data lapangan dan fungsi sama-sama membaik |
Periksa sitemap XML dan catat perubahan setelan, waktu, serta langkah rollback. Konfigurasi terbaik untuk blog informasi belum tentu tepat untuk website membership atau e-commerce.
Contoh konfigurasi Cache Rules yang lebih aman untuk WordPress
Misalnya sebuah website mempunyai 90% artikel publik serta area login/member. Aset seperti CSS, JavaScript dan gambar dapat memperoleh manfaat cache edge, tetapi halaman personal harus ditangani secara berbeda. Di Cloudflare, buat kondisi rule berdasarkan hostname dan path yang tepat, bukan “cache everything” untuk seluruh domain tanpa evaluasi cookies atau autentikasi.
Apa yang terjadi saat migrasi dari Page Rules?
Cloudflare mendokumentasikan bahwa pada produk Cache Rules, memilih Eligible for cache dapat mengaktifkan perilaku setara Cache Everything secara default. Pada Page Rules lama, perilaku tersebut harus dinyalakan secara eksplisit. Perbedaan ini penting ketika admin memigrasikan konfigurasi lama. Jika sebelumnya hanya ingin cache aset statis, uji pengaturan dasar sebelum mengaktifkan cache HTML.
| Jenis URL | Perlakuan umum | Uji yang wajib |
|---|---|---|
| Artikel dan landing publik | Cache bila aman dan sesuai policy | Konten update, cookie, variasi halaman |
| /wp-admin/ dan login | Bypass cache dan perlindungan akses | Admin tetap dapat bekerja |
| Cart/checkout/member | Bypass cache personal | Tidak ada data antar pengguna yang tercampur |
| Gambar, CSS, JS versi statis | Cache dengan TTL yang tepat | Asset terbaru muncul setelah deploy |
Tahapan QA Cloudflare sebelum dan sesudah perubahan
Periksa header respons dan status cache
Gunakan browser DevTools Network atau perintah HTTP client yang Anda pahami untuk melihat status cache, status code, lokasi redirect dan header keamanan. Nilai seperti HIT, MISS, DYNAMIC atau BYPASS perlu diinterpretasikan dalam konteks rule. Jangan menilai semua MISS sebagai kegagalan; pada halaman privat atau request pertama, MISS/BYPASS bisa merupakan perilaku yang memang diinginkan.
Uji dari akun berbeda
Buka website sebagai pengunjung anonim dan pengguna login pada browser berbeda. Periksa bahwa isi member tidak pernah terlihat oleh orang lain. Pada website toko online, uji keranjang, kupon, pengiriman, checkout, pembayaran, dan halaman konfirmasi. Jika fungsi terganggu, rollback rule daripada memaksa caching hanya untuk memperbaiki PageSpeed.
Evaluasi false positive pada bot
Perhatikan perubahan challenge terhadap pengguna sah serta crawler terverifikasi. Perubahan WAF yang terlalu agresif dapat mengurangi visibilitas dan conversion rate. Dokumentasikan ekspresi rule, alasan dibuat, penanggung jawab dan tanggal review berkala. Perlindungan harus tetap dapat diaudit serta mudah dibatalkan jika ditemukan dampak yang tidak diharapkan.
Arsip 22 screenshot konfigurasi Cloudflare versi lama
Seluruh gambar historis dari tutorial terdahulu, termasuk contoh Firewall/SSL/Caching/Page Rules, tetap tersedia sebagai dokumentasi. Beberapa nama menu dan pilihan tombol kini sudah berpindah atau berubah.
Tampilkan semua 22 screenshot asli
FAQ: setting Cloudflare optimal
1. Apakah Cloudflare Free cukup untuk blog?
Cukup untuk banyak kebutuhan dasar, tetapi fitur dan kuota bergantung paket.
2. Apa pengaturan SSL yang paling disarankan?
Full (strict) jika origin memiliki sertifikat valid dan sesuai hostname.
3. Apa beda Full dan Full (strict)?
Full tidak memvalidasi sertifikat origin secara ketat, Full (strict) memvalidasinya.
4. Apakah harus menggunakan Flexible SSL?
Tidak; untuk WordPress modern gunakan koneksi terenkripsi end-to-end.
5. Apa pengganti Page Rules?
Cache Rules, Configuration Rules, Redirect Rules dan produk WAF sesuai fungsinya.
6. Apakah semua URL aman di-cache?
Tidak. Login, checkout dan data personal memerlukan bypass atau aturan khusus.
7. Apakah Rocket Loader selalu membantu?
Tidak; uji apakah JavaScript penting menjadi rusak atau tertunda.
8. Apakah WAF boleh memblokir seluruh negara?
Hanya setelah evaluasi karena bisa menghalangi pengguna sah.
9. Apakah Cloudflare otomatis meningkatkan skor PageSpeed?
Tidak; hasil bergantung origin, jenis resource, cache dan pengalaman pengguna.
10. Bagaimana memperbaiki error 526?
Periksa sertifikat origin dan mode Full (strict).
11. Apa fungsi Cloudflare Tunnel?
Membantu menghubungkan origin melalui koneksi keluar tanpa mengekspos listener publik tertentu.
12. Bagaimana tahu optimasi berhasil?
Bandingkan error, cache, CWV, trafik sah dan fungsi website sebelum-sesudah.
Referensi eksternal
- Cloudflare — SSL Full (strict)
- Cloudflare — Cache Rules
- Cloudflare — migrasi Page Rules
- Cloudflare — Configuration Rules
Wah bagus juga ya cloudflare… Mau nyoba ah…
Bang mau tanya, setelah berhasil setting untuk WordPress ternyata membuat REST API error dengan kode CONTEXT. Solusinya gimana?