Statik Site Cloudflare Arkasında Nasıl Yayınlanır? Cache, SSL ve Yönlendirme Ayarları

Statik bir site Cloudflare arkasında yayınlanırken dört ayar belirleyicidir: SSL modunu Full (strict) yapmak, HTML ile hash'li varlık dosyaları için ayrı cache kuralları tanımlamak, SPA yönlendirmesini origin sunucuda çözmek ve www ile www'suz adreslerden birini 301 ile tekilleştirmek. Her yayından sonra cache temizlemek ise eski sayfaların sunulmasını engeller.

Statik site derken, sunucuda her istekte yeniden üretilmeyen, derleme anında hazırlanmış HTML, CSS, JavaScript ve görsel dosyalarından oluşan siteleri kastediyoruz. React veya Vue ile yazılıp derleme sırasında HTML'e dönüştürülen (prerender) siteler de bu gruba girer. Örneğin 404 Ajans'ın kendi sitesi React 18 ve Vite ile yazılıyor, derleme sırasında her sayfa statik HTML olarak üretiliyor ve Cloudflare arkasındaki bir OpenLiteSpeed sunucudan yayınlanıyor. Bu yazıdaki ayarlar, böyle bir kurulumda karşılaşılan gerçek sorunlara dayanıyor.

Cloudflare'de hangi SSL modu seçilmeli: Flexible mı, Full (strict) mı?

Cloudflare arkasındaki statik bir site için doğru SSL modu Full (strict) modudur. Full (strict) modunda Cloudflare, origin sunucuya HTTPS ile bağlanır ve sunucudaki sertifikanın geçerli olduğunu doğrular. Flexible modu ise Cloudflare ile origin arasındaki trafiği şifresiz HTTP olarak taşır ve sık görülen yönlendirme döngülerinin ana sebebidir.

Yönlendirme döngüsü şöyle oluşur: Flexible modda Cloudflare origin'e HTTP ile gider. Origin sunucuda ise genellikle HTTP isteklerini HTTPS'e çeviren bir kural (.htaccess veya panel ayarı) vardır. Sunucu 'HTTPS'e git' der, tarayıcı tekrar Cloudflare'e HTTPS ile gelir, Cloudflare yine origin'e HTTP ile sorar ve döngü tarayıcı ERR_TOO_MANY_REDIRECTS hatası verene kadar sürer.

• —Off: HTTPS yok. Yeni bir sitede kullanılmamalı.
• —Flexible: Ziyaretçi ile Cloudflare arası şifreli, Cloudflare ile sunucu arası şifresiz. Güvenlik açığı ve yönlendirme döngüsü riski taşır.
• —Full: Sunucuya HTTPS ile gidilir ama sertifika doğrulanmaz; süresi dolmuş veya kendinden imzalı sertifika da kabul edilir.
• —Full (strict): Sunucuya HTTPS ile gidilir ve geçerli bir sertifika (genel bir sertifika otoritesinden ya da Cloudflare Origin CA'dan) şart koşulur. Önerilen moddur.

Origin sertifikası için iki pratik seçenek vardır: sunucu panelinden (CyberPanel, cPanel vb.) alınan Let's Encrypt sertifikası ya da Cloudflare panelinden üretilen Origin CA sertifikası. Origin CA sertifikası yalnızca Cloudflare üzerinden gelen trafik için geçerlidir, uzun süreli verilebilir ve yenileme derdini azaltır. Ardından 'Always Use HTTPS' açılabilir. HSTS'yi ise tüm alt alan adlarınızın HTTPS desteklediğinden emin olduktan sonra etkinleştirin; tarayıcılar bu kararı aylarca hatırlar.

HTML ve hash'li dosyalar için cache nasıl ayarlanır?

Statik sitede cache stratejisi iki katmanlıdır: dosya adında içerik hash'i taşıyan JavaScript, CSS ve font dosyaları bir yıl boyunca değişmez kabul edilip agresif şekilde cache'lenir; HTML dosyaları ise kısa süreli cache'lenir veya her yayında temizlenir. Bu ayrım, yeni sürümün hemen görünmesini ve varlıkların hızlı yüklenmesini aynı anda sağlar.

Vite gibi derleme araçları çıktı dosyalarını assets/index-a1b2c3.js gibi adlarla üretir. İçerik değiştiğinde hash, dolayısıyla dosya adı da değişir; eski dosyanın cache'te kalması hiçbir soruna yol açmaz. Bu dosyalar için 'Cache-Control: public, max-age=31536000, immutable' başlığı uygundur. HTML ise her zaman aynı adla (index.html) sunulduğu için uzun süre cache'lenirse yeni içerik görünmez. Cloudflare varsayılan olarak HTML'i cache'lemez; yalnızca belirli uzantılardaki statik dosyaları saklar. HTML'i de edge'de tutmak istiyorsanız bunu bir Cache Rule ile bilinçli şekilde açmanız gerekir.

• —Kural 1 — /assets/ ile başlayan yollar: önbelleğe uygun (Eligible for cache), Edge TTL 1 yıl, Browser TTL origin başlığına uysun.
• —Kural 2 — HTML sayfaları: ya cache'i atla (Bypass) ya da kısa bir Edge TTL (örneğin birkaç saat) verip her yayında purge yapın. Browser TTL kısa tutulmalı.
• —Kural 3 — sitemap.xml, robots.txt, llms.txt: kısa TTL; arama motoru ve yapay zeka tarayıcıları güncel sürümü görmeli.
• —Kural 4 — form gönderimi veya API yolları: her zaman Bypass cache.

Sık yapılan bir hata şudur: HTML uzun süre cache'lenir, yeni yayında eski hash'li dosyalar sunucudan silinir. Cache'teki eski HTML artık var olmayan JavaScript dosyalarını ister ve site boş beyaz ekranla açılır. Çözüm, HTML'i her yayında temizlemek ya da önceki derlemenin assets klasörünü birkaç gün sunucuda bırakmaktır.

SPA yönlendirmesi (fallback) origin sunucuda nasıl kurulur?

SPA fallback, sunucuda gerçek bir dosya ya da klasör karşılığı olmayan her isteği uygulamanın index.html dosyasına yönlendiren kuraldır. Cloudflare bu kuralı kendiliğinden uygulamaz; kural origin sunucuda tanımlanmalıdır: Apache ve OpenLiteSpeed üzerinde .htaccess içindeki RewriteRule ile, Nginx üzerinde ise try_files yönergesiyle.

Apache uyumlu sunucularda mantık üç satırdır: istenen yol gerçek bir dosya değilse (RewriteCond %{REQUEST_FILENAME} !-f), gerçek bir klasör de değilse (!-d), isteği index.html'e aktar. Prerender kullanan sitelerde her sayfanın kendi klasöründe hazır bir index.html'i olduğu için fallback yalnızca bilinmeyen adreslerde devreye girer; bu da hem hızı hem de arama motorlarının gördüğü içeriği korur.

Dikkat edilmesi gereken nokta 'soft 404' riskidir. Fallback, var olmayan her adrese 200 durum koduyla ana sayfa kabuğunu döndürürse Google bu adresleri boş ya da yinelenen sayfa olarak algılayabilir. Daha sağlıklı yaklaşım, bilinmeyen yollar için noindex etiketli ayrı bir 404 kabuğu sunmak ya da mümkünse gerçek 404 durum kodu döndürmektir. 404 Ajans'ın derleme sürecinde bu amaçla ayrı bir 404.html dosyası üretiliyor.

www ve www'suz alan adı tek adrese nasıl 301 ile yönlendirilir?

www ve www'suz sürümlerin ikisi de ayrı ayrı yanıt veriyorsa arama motorları aynı içeriği iki farklı adreste görür ve sinyaller bölünür. Çözüm, birini kanonik adres seçip diğerini kalıcı 301 yönlendirmesiyle ona taşımaktır. Cloudflare'de bu yönlendirme en temiz şekilde Redirect Rules ile, istek origin sunucuya hiç ulaşmadan edge'de yapılır.

• —DNS'te www için proxied (turuncu bulut) bir kayıt olduğundan emin olun; kayıt yoksa ya da yalnızca DNS modundaysa kural hiç çalışmaz.
• —Rules bölümünde yeni bir Redirect Rule oluşturun: host adı www.alanadiniz.com olan istekleri https://alanadiniz.com adresine, yol korunarak yönlendirin.
• —Durum kodunu 301 seçin ve sorgu parametrelerinin korunmasını açın.
• —Canonical etiketleri, hreflang bağlantıları ve sitemap.xml içindeki tüm adreslerin seçtiğiniz kanonik host'u kullandığını kontrol edin.
• —curl -I ile http, https, www ve www'suz dört kombinasyonu test edin; her biri en fazla bir veya iki adımda hedefe ulaşmalı.

Yönlendirme zincirlerinden kaçının. Örneğin http://www adresi önce https://www'ye, oradan da www'suz adrese gidiyorsa iki adım oluşur. Bu durum siteyi bozmaz ama gereksiz gecikme ekler; kuralı mümkün olduğunca tek adımda nihai adrese gidecek şekilde kurmak en iyisidir.

Her yayından sonra cache neden ve nasıl temizlenir?

Cache temizleme (purge), Cloudflare edge sunucularında saklanan eski dosya kopyalarını silerek ziyaretçilerin yeni yayını görmesini sağlar. HTML dosyaları edge'de cache'leniyorsa ve her yayından sonra purge yapılmazsa, bazı ziyaretçiler cache süresi dolana kadar eski sayfaları, eski başlıkları ve eski iç bağlantıları görmeye devam eder.

• —Purge Everything: Küçük ve orta ölçekli statik siteler için en basit ve güvenli yöntem.
• —Custom Purge: Yalnızca değişen sayfaların ve sitemap.xml'in URL'lerini temizler; büyük sitelerde cache isabet oranını korur.
• —API ile otomatik purge: Yalnızca 'Cache Purge' yetkisi verilmiş bir API token'ı ile yayın betiğinin son adımı olarak çalıştırılabilir.
• —Development Mode: Test sırasında cache'i geçici olarak (yaklaşık üç saat) devre dışı bırakır; kalıcı çözüm değildir.

Sıralama önemlidir: önce dosyalar sunucuya yüklenir, sonra purge yapılır. Tersi yapılırsa, yükleme sürerken gelen bir istek Cloudflare'in eski ya da yarım kalmış sürümü yeniden cache'lemesine neden olabilir.

Adım adım yayın kontrol listesi

Statik bir siteyi Cloudflare arkasında sorunsuz yayınlamak için ayarların sırası önemlidir: önce origin sertifikası ve HTTPS, sonra SSL modu, ardından yönlendirmeler ve cache kuralları, en son da dosya yükleme ile purge. Bu sıralama, yayın sırasında yönlendirme döngüsü, karışık içerik uyarısı ve eski sayfa sunumu risklerini en aza indirir.

• —1. Alan adının DNS kayıtlarını Cloudflare'e taşıyın; kök alan adı ve www kaydını proxied yapın.
• —2. Origin sunucuya geçerli bir sertifika kurun (Let's Encrypt veya Cloudflare Origin CA).
• —3. SSL/TLS modunu Full (strict) yapın, ardından Always Use HTTPS'i açın.
• —4. www ile www'suz sürüm arasında tek yönlü 301 Redirect Rule tanımlayın.
• —5. Origin'de SPA fallback kuralını ve 404 kabuğunu kurun.
• —6. Cache Rules ile hash'li varlıkları uzun, HTML'i kısa süreli veya bypass olarak ayarlayın.
• —7. Tam derlemeyi (prerender dahil) sunucuya yükleyin.
• —8. Cache'i temizleyin ve curl -I ile cf-cache-status başlığını (HIT, MISS, DYNAMIC, BYPASS) kontrol edin.
• —9. Google Search Console'da birkaç URL'yi denetleyip sitemap'i yeniden gönderin.

Bu adımlar bir kez doğru kurulduğunda her yeni yayın yalnızca 7. ve 8. adımlardan ibaret kalır. Kurulum aşamasında emin olmadığınız noktalar varsa, özellikle SSL ve yönlendirme ayarlarını canlı sitede deneme yanılma ile yapmak yerine bir uzmana danışmak, birkaç saatlik erişim kaybını önler.