Settingan Wajib Cloudflare untuk SEO & GEO agar Ramah Bot AI

Dilema Keamanan Cloudflare: antara memblokir bot jahat dan membuka akses AI Search

Jika ChatGPT, Perplexity, atau crawler lain menerima 403 Forbidden atau halaman Just a moment..., masalahnya sering ada di gerbang sebelum konten dibaca. Itu tidak membuktikan konten buruk dan juga tidak berarti semua proteksi harus dimatikan. Langkah aman adalah membaca Security Events, mencatat rule atau produk yang memicu aksi, lalu mempersempit kebijakan berdasarkan identitas bot yang benar-benar diverifikasi.

Cloudflare membedakan beberapa lapisan: Web Application Firewall (WAF), aturan kustom, Bot Fight Mode, Super Bot Fight Mode, rate limiting, dan produk pengendalian crawler AI. Masing-masing punya urutan evaluasi serta batas interaksi sendiri. Karena itu, satu rule Skip tidak otomatis dapat melewati semua produk. Bot Fight Mode khususnya tidak bisa dilewati oleh custom WAF rule; jangan membuat allowlist yang terlihat benar tetapi tidak pernah mencapai crawler.

1. Jebakan Bot Fight Mode dan saklar Block AI Bots satu klik

Bot Fight Mode cocok sebagai proteksi dasar saat situs diserang otomasi sederhana, tetapi ia tidak dirancang sebagai kontrol izin crawler yang presisi. Bila event menunjukkan Bot Fight Mode menantang crawler yang kamu ingin izinkan, custom rule tidak dapat membypass produk tersebut. Pilihannya adalah menonaktifkan mode itu setelah evaluasi risiko, memakai kontrol bot yang lebih terperinci bila tersedia pada paket Anda, atau membatasi proteksi pada jalur yang benar-benar sensitif.

Demikian pula, kebijakan Block AI Bots atau AI Crawl Control dapat memblokir crawler AI berdasarkan kategori. Ini berguna bila Anda ingin membatasi penggunaan konten untuk model tertentu, tetapi tidak bisa diperlakukan sebagai tombol SEO. Jika blokirnya mencakup crawler yang Anda harapkan untuk discovery, halaman publik, robots.txt, sitemap.xml, dan llms.txt tetap tidak dapat diambil dari jaringan. Artikel Bagian 1 menjelaskan dokumen-dokumen itu; Bagian 2 memastikan mereka tidak berhenti di firewall.

Checklist sebelum mengubah saklar

• Uji URL publik yang sama dengan respons 200, bukan hanya homepage.
• Buka Security Events dan cari action Block, Managed Challenge, atau JS Challenge pada jam uji.
• Catat rule ID, produk pemicu, URI, dan status bot yang terlihat; jangan membuka seluruh situs berdasarkan satu nama user-agent.
• Biarkan /admin/, API privat, login, checkout, dan upload tetap dilindungi walau artikel publik dapat dirayapi.

2. Tutorial membuat Custom WAF Rule untuk bot pencari yang benar-benar terverifikasi

Masuk ke Security > WAF > Custom rules, tetapi jangan langsung membuat allowlist global. Mulai dari log atau simulasi jika tersedia, kemudian lihat event yang dihasilkan. Untuk rule yang tujuannya menjaga crawler terverifikasi dari rule WAF lain, gunakan sinyal bot Cloudflare dan pilih tindakan Skip hanya untuk komponen yang memang ingin dilewati. Jangan memilih Allow sebagai jalan pintas untuk semua request; tindakan itu terlalu luas dan dapat mematikan pertahanan berikutnya.

# Pakai pada zona yang menyediakan sinyal known/verified bot.

# Contoh path publik /robots.txt saja; verifikasi kebutuhan lewat Security Events.

# Action: Skip → pilih custom rules atau managed rules yang relevan saja.

(cf.client.bot and http.request.uri.path eq "/robots.txt")

Sinyal ini mencakup bot terverifikasi, bukan hanya crawler pencarian. Jangan terapkan Skip global: batasi ke path publik yang memang membutuhkan pengecualian, dan jangan membuka login, dashboard, atau API privat. Di Enterprise, ekspresi dapat diperketat dengan field Bot Management. Tetap uji field itu pada expression builder karena ketersediaannya bergantung paket. Sebuah rule yang gagal divalidasi tidak boleh dipaksa hanya karena terlihat seperti contoh di internet.

# Enterprise-only: gunakan bila expression builder menerima field ini.

(cf.bot_management.verified_bot and http.request.uri.path eq "/robots.txt")

Nama bot tetap berguna untuk observasi, bukan sebagai identitas keamanan. Contoh berikut cocok untuk rule Log sementara saat menelusuri keluhan “ChatGPT tidak bisa mengakses website Cloudflare”. Jangan menjadikannya allowlist produksi tanpa verifikasi IP/identitas dari penyedia bot; penyerang dapat mengirim header yang sama.

(http.user_agent contains "OAI-SearchBot" or

 http.user_agent contains "PerplexityBot" or

 http.user_agent contains "Claude-SearchBot" or

 http.user_agent contains "Googlebot" or

 http.user_agent contains "bingbot")

ChatGPT-User juga tidak boleh dijadikan tiket otomatis untuk melewati autentikasi atau rate limit. Request yang dipicu tindakan pengguna dapat berbeda dari crawler indeks. Lindungi data privat di aplikasi, bukan dengan berharap robots atau user-agent akan menjadi lapisan akses. Setelah perubahan, ulangi cek Security Events dan lihat apakah response berubah dari challenge/403 ke respons halaman publik yang normal.

3. Membedah Cloudflare AI Audit dan AI Crawl Control

Nama menu Cloudflare dapat berubah menurut paket dan pembaruan produk. Cari permukaan AI Audit atau AI Crawl Control untuk kebijakan crawler AI, lalu gunakan Security Analytics dan Security Events untuk bukti request yang sebenarnya. Fokusnya bukan mengejar angka crawl semata, melainkan memahami siapa yang meminta halaman, apakah request diizinkan atau diblokir, serta URL mana yang paling sering menjadi target.

Gunakan data itu untuk mengambil keputusan konten dan keamanan secara terpisah. Jika crawler training ingin dibatasi tetapi crawler pencarian ingin dipertimbangkan, buat kebijakan eksplisit per kategori/identitas dan dokumentasikan alasannya. Jika traffic berasal dari scraper tanpa verifikasi, pertahankan rate limiting, WAF, dan cache strategy. AI Audit tidak menjamin halaman dikutip sistem AI; ia hanya membantu mengamati dan mengendalikan request yang melewati Cloudflare.

4. Optimasi DNS, speed, dan batas infrastruktur Cloudflare di AICLUB.AI.ID

Untuk subdomain AICLUB yang diarahkan melalui CNAME ke GitHub Pages, Vercel, Netlify, atau Cloudflare Pages, konfigurasi layanan AICLUB memakai DNS-Only (grey cloud). Tujuannya agar provider hosting tujuan dapat menyelesaikan custom domain dan TLS-nya sendiri tanpa double proxy. DNS-Only bukan mode “lebih cepat” atau “lebih lambat” secara otomatis: request HTTP tidak melewati fitur proxy Cloudflare pada zona AICLUB, sehingga HTTP/3, cache, Brotli/Zstd compression, WAF, dan Early Hints ditentukan oleh hosting atau CDN tujuan.

Jika Anda mengelola zona Cloudflare sendiri dan memakai status Proxied, aktifkan fitur speed hanya setelah mengukur dampaknya. HTTP/3 (QUIC) dapat membantu koneksi klien yang mendukungnya, tetapi bukan pengganti HTML ringan, gambar terkompresi, cache origin, dan TTFB yang sehat. Early Hints (103) dapat membantu browser mulai mengambil resource tertentu lebih awal, namun harus diuji karena resource yang tidak benar justru membuang bandwidth. 0-RTT juga memiliki pertimbangan replay; jangan menyalakannya untuk endpoint yang tidak idempoten tanpa memahami risiko aplikasi.

Masalah too many redirects saat pointing CNAME biasanya bukan alasan untuk mengubah DNS ke proxy secara sembarangan. Periksa canonical host di hosting tujuan, redirect HTTP-to-HTTPS, konfigurasi custom domain, dan apakah ada dua CDN yang mencoba mengelola SSL. Untuk SEO dan GEO, hasil yang dicari sederhana: URL kanonis merespons stabil, resource penting tidak diblokir, dan halaman publik cepat bagi manusia maupun crawler yang sah.

Butuh alamat proyek yang rapi untuk hosting statis? Cek pilihan subdomain di katalog domain AICLUB. Setelah situs aktif, pasang badge melalui Badge Builder AICLUB untuk tambahan slot bila memenuhi syarat, lalu diskusikan konfigurasi yang Anda temukan di komunitas Telegram AICLUB.

FAQ seputar pengaturan Cloudflare untuk SEO dan GEO

Rujukan teknis

• Cloudflare: Bot Fight Mode
• Cloudflare: stop malicious bots
• Cloudflare: manage AI crawlers
• Cloudflare: Bot Management variables
• Cloudflare: HTTP/3
• Cloudflare: Early Hints

Lanjutkan ke Bagian 3: struktur konten yang dapat diperiksa pembaca dan sistem jawaban.