WordPress Staging: Hosting’de Demo Site Nasıl Kurulur?

WordPress’te yeni eklenti, tema güncellemesi, PHP sürümü değişikliği ya da CDN/cache ayarı yapmadan önce test etmek istersiniz. Ancak test ortamı yoksa denemeler doğrudan prod (canlı) siteye taşınır ve en küçük hatada kullanıcı trafiği etkilenir. Bu rehberde staging (test/demosu) mantığını netleştirip, hosting kontrol paneli üzerinden demo site oluşturma akışını adım adım anlatacağız. Ayrıca staging ile prod arasında senkron, veri tutarlılığı, yedek (backup) ve hızlı geri alma (rollback) planını somut şekilde kuracağız.

Staging ile “demo site” aynı şey mi?

Staging, canlı sitenin kontrollü bir kopyasıdır. Amaç “eğlence amaçlı deneme” değil; prod’u bozmadan değişiklikleri doğrulamak ve riski minimize etmektir.

Staging’in prod’tan farkı

• Staging’de trafik akışı kısıtlıdır: arama motoru indekslemesi kapalı, erişim çoğunlukla şifre/izin ile yapılır.
• Staging’de deneme yapılır: eklenti çakışması, performans cache davranışı, form entegrasyonları gibi konular test edilir.
• Staging, gerektiğinde geri alınabilir: doğru kurulumda rollback süresi dakikalar seviyesine indirilebilir.

Demo site seçeneği ne zaman yeterli olur?

• İçerik şablonu denemeleri (tasarım/tema) için staging yerine “temiz WordPress + aynı tema” yaklaşımı bazı senaryolarda yeterlidir.
• Ancak üyelik, WooCommerce, özel yazı tipleri, mevcut eklenti verileri gibi durumlar varsa mutlaka staging kopyası gerekir.

Hosting kontrol panelinde staging oluşturma: 2 yaygın yöntem

Türkiye’de birçok hosting sağlayıcısı şu iki yaklaşımdan birini sunar:

1) Tek tıkla staging özelliği (staging clone) 2) Manuel kopyalama (veritabanı + dosyalar) ve ayrı bir alan/alt dizin

Aşağıdaki tablo, iki yöntemi “hangi koşulda daha hızlı/kolay” açısından netleştirir.

Tek tıkla staging adımları (kontrol paneliyle)

Hizmet sağlayıcınızın panelinde genellikle şu seçenekler bulunur: - WordPress yönetimi - “Staging”, “Demo”, “Kopyala”, “Clone” gibi butonlar

Genel akış (panel isimleri değişebilir): 1. Panelde WordPress yöneticisini açın. 2. Prod sitenizi seçin. 3. “Staging oluştur” seçeneğini çalıştırın. 4. Staging konumunu belirleyin (alt alan adı, alt dizin veya ayrı domain). 5. Veri kopyalamayı tamamlayın (dosyalar + veritabanı). 6. Staging erişimini kısıtlayın. 7. Arama motoru erişimini kapatın.

Not: Panel staging işlemi sırasında veritabanı şifreleri, wp-config ayarları ve dosya izinleri gibi detayları da otomatik güncelleyebilir. Bu nedenle panel destekliyse en hızlı yoldur.

Manuel staging kurulumu (kopyalama + doğrulama)

Panelde staging yoksa şu çerçeve ile ilerleyin.

1) Staging için hedefi seçin

• Alt dizin: https://site.com/staging/
• Alt alan: https://staging.site.com/

En pratik yaklaşım genelde alt dizindir; çünkü domain yönetim yükü azalır. Ancak bazı sağlayıcılar alt alanı daha iyi yönettiği için gecikmesiz çalışır.

2) Dosyaları kopyalayın

• Prod klasörünüzü (public_html veya benzeri) staging lokasyonuna kopyalayın.
• Kopyalama sonrası dosya izinlerini kontrol edin (özellikle wp-content).

Örnek dizin mantığı: - Prod: /public_html - Staging: /public_html_staging (sağlayıcınıza göre)

3) Veritabanını kopyalayın

• Prod veritabanını dump (SQL export) ile dışa aktarın.
• Staging için yeni bir veritabanı oluşturun.
• Dump dosyasını staging veritabanına import edin.

4) wp-config.php ayarlarını staging’e uyarlayın

Staging’de DB_NAME, DB_USER, DB_PASSWORD, DB_HOST değerlerini staging veritabanıyla eşleştirin.

Ek olarak şu kontrolleri yapın: - WP_HOME ve WP_SITEURL (kullanıyorsanız) staging URL’sine ayarlı mı? - Önbellek pluginleri staging’de doğru davranıyor mu?

5) URL araması/değişimi (siteurl/home eşleşmesi)

Prod URL’si staging’de farklıysa şu sorunlar çıkar: - Menü bağlantıları yanlış görünür - Görsel URL’leri prod’u çağırabilir - Eklenti ayarları prod URL’ini tutabilir

Bu durumda staging kurulumunda URL değişimi gerekir. Sağlayıcılar bazen “search/replace” aracını sunar. Yoksa WP-CLI veya veritabanında kontrollü update gerekir.

En temiz yöntem: WP-CLI ile staging veritabanında kontrollü search/replace yapmak. (Müdahale öncesi dump alın.)

Staging’i canlıdan izole edin: Erişim, indeksleme ve eklenti güvenliği

Staging doğru kurulmazsa iki risk büyür: - Arama motoru staging sayfalarını indeksler. - Staging prod oturum/iş akışlarını etkileyebilir.

Arama motoru indekslemesini kapatma

En azından şu üç adımı birlikte uygulayın: - Panelde “site visibility” ayarı varsa kapatın. - robots.txt dosyası staging’i engelleyecek şekilde güncellenmelidir. - WordPress tarafında eklenti/ayar üzerinden “arama motorlarında görünme” kuralını etkinleştirin.

Bu üçlü birlikte çalışır; tek bir adımın atlanması durumunda riski azaltır.

Staging erişimini kısıtlayın

Staging’i şunlardan biriyle sınırlayın: - HTTP Basic Auth / parola koruma - Sadece belirli IP’lere izin

Hedef: staging’i herkesin erişebildiği açık bir URL olmaktan çıkarmak.

Eklenti ve eylem tetikleyicilerini devre dışı bırakın

Prod ile bağlantılı olabilecek süreçler: - Form kayıtları (ör. e-posta/CRM’e bildirim) - WooCommerce sipariş bildirimleri - Webhook gönderimleri - Otomatik e-posta akışları

Staging’de test yaparken bu bildirimleri durdurmak için eklenti ayarlarında hedef URL/hesapları staging’e çevirmek veya “yalnızca admin bildirimi” modunu açmak gerekir.

Veritabanı tutarlılığı: staging ile prod senkronu nasıl yapılır?

Staging’in en büyük değeri, prod üzerinde yapılacak değişiklikleri onaylamadan önce risk azaltmasıdır. Bunun için iki senaryo vardır:

1) Değişiklikleri staging’de yapar, sonra prod’a taşır/senkronlarsın. 2) Prod’da değişiklik olduğunda staging’i güncellersin.

Trafik ve zamanlama kuralı

• Prod’da güncelleme yaptığınız anda staging otomatik güncellenmiyorsa, prod’u tekrar clone etmek gerekir.
• Staging’de büyük değişiklik yaptınız ve prod’a taşıyacaksanız, taşıma öncesi staging’in prod ile “aynı veri durumunda” olduğundan emin olun.

Pratik senkron stratejileri

• Günlük/haftalık clone: Kritik dönemlerde en güvenlisi.
• Dosya taşıma + DB migration: Gelişmiş yaklaşım; yanlış yapılırsa tutarsızlık yaratır.
• Versiyonlu deploy: Git tabanlı ekiplerde daha doğru.

Tek tıkla staging kullanan sağlayıcılarda clone işlemi daha hızlı olur; yine de her clone öncesi staging snapshot/backup mantığını doğrulamak gerekir.

Cache ve performans testini doğru yapmak: staging’de hangi ayarlar değişmeli?

Staging’de yaptığınız hız testleri prod’u doğru yansıtmalıdır; ancak aynı zamanda test sürecini bozan faktörleri elemeniz gerekir.

Cache prewarming ve test düzeni

• Cache davranışı test sonucu üzerinde ciddi etki yaratır.
• Cache prewarming (ön ısıtma) yapıyorsanız aynı adımları staging’de de uygulayın.

Bu sayede “ilk istek yavaş, sonraki hızlı” farkını prod ile aynı mantıkta görürsünüz.

CDN/WAF ayarları staging’e otomatik taşınmalı mı?

• Cloudflare gibi CDN kullanıyorsanız staging’de DNS ve cache katmanlarının nasıl davrandığını netleştirin.
• WAF kural setleri staging’de de çalışırsa, testler daha gerçekçi olur.

Ama kritik nokta: Staging’de hata ayıklarken (debug) bazı kurallar geçici olarak kapatılabilir. Bunun için bir “test modu” planı çıkarın.

Rollback planı: staging yanlışsa dakikada toparlayın

Sık yapılan hata: “Staging’de de bozuldu, şimdi ne olacak?” sorusunu ancak sorun çıkınca düşünmek.

Net rollback yaklaşımı

• Staging’i güncellemeden önce staging’de bir yedek (backup) veya snapshot alın.
• Yanlış değişiklik olduğunda staging’i sıfırlayın veya clone ile geri alın.
• Prod’a taşımadan önce kontrol listesi uygulayın.

“Snapshot” kavramının her sağlayıcıda aynı davranmadığını unutmayın. Kritik iş akışlarında, staging rollback’inin gerçekten restore edilebilir olduğundan emin olmak gerekir.

Staging kurulumu için kontrol listesi (hata azaltan pratik liste)

Aşağıdaki maddeler “kurulum bitince” değil, kurulum sırasında aynı sırayla kontrol edilmelidir.

Kurulum öncesi

• [ ] Prod yedeğini (backup) doğrulayın
• [ ] Staging hedefini belirleyin (alt dizin/alt alan)
• [ ] Staging için erişim kısıtı planlayın

Kurulum sonrası

• [ ] Arama motoru indekslemesini kapatın
• [ ] wp-config’de DB bilgileri doğru mu kontrol edin
• [ ] URL değişimi (home/siteurl) doğru mu kontrol edin
• [ ] Eklenti tetikleyicileri (webhook/e-posta/ödeme akışları) staging’de güvenli mi?

Test sırasında

• [ ] Cache prewarming varsa staging’de de uygulayın
• [ ] Admin hariç erişimde davranışı test edin
• [ ] En az: ana sayfa, 1 içerik sayfası, 1 form/checkout akışı test edin

Hosting seçerken staging desteği hangi kriterlerde ölçülür?

Staging’i kolaylaştıran özellikler “var/yok” değil; operasyonel olarak hız ve güven getirmelidir.

Staging için şu kriterleri özellikle değerlendirin: - Kontrol panelinde staging/clone özelliği var mı? - Clone işlemi dosya + DB’yi birlikte doğru taşıyor mu? - Staging erişim kısıtı seçenekleri var mı? - Restore/rollback süresi makul mü (ör. dakikalar)? - Yedekleme sıklığı ve geri dönüş garantisi net mi?

Aşağıdaki tablo, sağlayıcı karşılaştırmasında hızlı karar aldırır:

Sonuç: Bugün staging kurun, test riskini somut şekilde düşürün

WordPress staging, canlıyı bozmadan güncelleme yapmanızı sağlayan operasyonel bir güvenlik katmanıdır. Eğer sağlayıcınız panelden tek tıkla clone/staging sunuyorsa, en kısa yol bu özelliktir; yoksa manuel kopyalamada DB + wp-config uyumu ve URL değişimini hatasız yapmanız gerekir. İlk aksiyon olarak prod yedeğini doğrulayın, staging’i erişim kısıtlı biçimde kurun, ardından küçük bir eklenti güncellemesini staging’de test ederek rollback planınızı da pratikte çalıştırın. Böylece bir sonraki değişiklikte belirsizlik yerine ölçülebilir kontrol elde edersiniz.