WordPress ile çalışan herkes için canlı site üzerinde test yapmak riskli bir alışkanlıktır. Yanlış bir eklenti güncellemesi, tema dosyasındaki küçük bir değişiklik ya da PHP sürüm yükseltmesi, bir anda ziyaretçi kaybına veya arama motoru sıralaması düşüşüne yol açabilir. Bu riski ortadan kaldırmanın en sağlam yolu WordPress staging site kullanmaktır.
Staging site, canlı sitenizin birebir kopyasıdır; aynı veritabanı yapısı, aynı tema, aynı eklentiler, aynı içerik. Tek fark, kimsenin erişemeyeceği, arama motorlarının indexlemeyeceği, sizin deney yapabileceğiniz kapalı bir ortam olmasıdır. Bu ortamda yaptığınız her değişikliği test eder, onayladıktan sonra canlıya alırsınız.
Bu rehberde WordPress staging site nedir, ne zaman kullanılır, nasıl kurulur, hangi araçlar gerekir, hangi hatalardan kaçınılır ve yayın öncesi son kontrol listesinde neler olmalıdır sorularını adım adım cevaplıyoruz.
WordPress Staging Site Nedir ve Neden Önemlidir?

Staging site kavramı yazılım mühendisliğinde “pre-production environment” olarak da bilinir. WordPress özelinde düşündüğümüzde, canlı siteden ayrı bir subdomain veya alt klasörde çalışan, tüm içerik ve yapıyı birebir yansıtan bir kopyadır. Temel amaç, kullanıcıya ulaşmadan önce tüm değişikliklerin denenebileceği güvenli bir alan yaratmaktır.
Staging kullanmanın en kritik faydası geri alma imkânıdır. Canlı sitede bir hata oluştuğunda, eski yedeğe dönmek saatler sürebilir ve aradaki sürede site kapalı kalır. Staging’te ise sadece test ettiğiniz değişikliği geri alırsınız; canlı site etkilenmez. Bu durum özellikle e-ticaret siteleri, haber portalları veya her gün yeni içerik yayınlayan kurumsal siteler için vazgeçilmezdir.
WordPress Staging Site Hangi Durumlarda Kullanılır?
Staging site her değişiklik için gerekli değildir; küçük metin düzeltmeleri veya görsel değişiklikleri için staging açmaya gerek yoktur. Ancak aşağıdaki durumlarda staging şarttır:
- WordPress çekirdek sürüm yükseltmeleri (5.x → 6.x gibi büyük geçişler)
- PHP sürüm değişiklikleri (7.4 → 8.1 gibi)
- Yeni eklenti kurulumu veya mevcut eklentinin büyük sürüm geçişi
- Tema değişikliği veya tema dosyalarında kapsamlı düzenleme
- WooCommerce, ödeme sistemi, üyelik sistemi gibi hassas bileşenlerde değişiklik
- SEO ayarlarında köklü değişiklik (robots.txt, kalıcı bağlantı yapısı, sitemap)
- Veritabanı şemasını etkileyen eklentiler (WooCommerce, ACF, Polylang)
WordPress Staging Site İçin Temel Kavramlar
Staging site kurmadan önce bazı kavramları netleştirmek gerekir. Subdomain yöntemi en yaygın olanıdır: staging.ornek.com adresinde ayrı bir kurulum çalıştırılır. Alt klasör yöntemi ise ornek.com/staging şeklinde aynı domain altında farklı bir dizin kullanır. Üçüncü yöntem ise ayrı domain kullanmaktır; bu genellikle geliştiricilerin birden fazla müşteri projesini aynı hosting hesabında yönetmesi için kullanılır.
Veritabanı tarafında ise iki yaklaşım vardır: ayrı veritabanı ve aynı veritabanı, farklı ön ek. Ayrı veritabanı daha güvenlidir çünkü staging verileri canlı veriyle karışmaz. Aynı veritabanı + farklı ön ek ise daha hızlı kurulum sağlar ancak bakımı zordur. Tavsiye edilen yöntem her zaman ayrı veritabanıdır.
WordPress Staging Site Nasıl Yapılır?

Staging site kurmanın üç ana yolu vardır: hosting sağlayıcısının sunduğu tek tıkla staging özelliği, manuel kurulum ve eklenti tabanlı kurulum. Her yöntemin avantaj ve dezavantajları farklıdır.
WordPress Staging Site Adım Adım Uygulama Rehberi
Manuel kurulum en şeffaf yöntemdir; her adımı kontrol edebilir, istediğiniz gibi özelleştirebilirsiniz. Aşağıdaki adımlar cPanel tabanlı bir hosting için geçerlidir; Plesk veya DirectAdmin için arayüz farklı olsa da mantık aynıdır.
- Alt domain oluşturun: cPanel → Domains → Subdomains.
staging.ornek.comadresini, public_html üzerinde farklı bir klasöre (ör.public_html/staging) yönlendirin. - Veritabanı oluşturun: cPanel → Databases → MySQL Databases. Yeni bir veritabanı ve kullanıcı oluşturun, kullanıcıyı veritabanına atayın, tüm ayrıcalıkları verin.
- Canlı sitenin yedeğini alın: Dosyalar için FTP/SFTP veya dosya yöneticisi kullanarak
public_htmliçeriğinipublic_html/stagingklasörüne kopyalayın. Veritabanı için phpMyAdmin’den dışa aktarın. - wp-config.php dosyasını düzenleyin: Staging klasöründeki
wp-config.php‘de veritabanı adı, kullanıcı adı ve şifreyi yeni staging veritabanı bilgileriyle değiştirin. - Site URL’lerini güncelleyin: phpMyAdmin’den
wp_optionstablosundasiteurlvehomesatırlarını staging URL’si ile değiştirin. Alternatif olarakwp search-replacekomutunu kullanın. - Arama motoru engellemesi ekleyin: Staging kök dizinine
robots.txtileDisallow: /ekleyin. Ek olarak staging klasörüne parola koruması koyun; bu, SEO açısından kritik bir adımdır. - SSL sertifikası kurun: Let’s Encrypt veya hosting sağlayıcınızın ücretsiz SSL’i ile staging için ayrı bir sertifika oluşturun. SSL’siz staging, içerideki bağlantıların “güvensiz” uyarısı vermesine neden olur.
- İlk giriş ve test:
staging.ornek.com/wp-adminadresinden giriş yapın, tüm sayfaların açıldığını, medya dosyalarının göründüğünü doğrulayın.
WordPress Staging Site İçin Gerekli Araçlar ve Ön Hazırlık
Manuel kurulum yerine hosting sağlayıcısının sunduğu araçları kullanmak hem zaman kazandırır hem de hata riskini azaltır. Aşağıdaki tablo, popüler hosting sağlayıcılarının staging özelliklerini özetliyor:
| Hosting Sağlayıcı | Staging Özelliği | Kullanım | Ücretsiz mi? |
|---|---|---|---|
| SiteGround | Site Tools → Staging | Tek tıkla staging + push to live | Evet (GrowBig+) |
| WP Engine | Admin bar → Staging | Otomatik staging ortamı | Evet (tüm planlar) |
| Kinsta | MyKinsta → Staging | Tek tıklama + Git entegrasyonu | Evet (tüm planlar) |
| Cloudways | Application → Staging | Klasik staging + clone | Evet |
| cPanel genel | Manuel veya Softaculous | Softaculous eklentisi ile tek tık | Hostinge göre değişir |
| Plesk | WordPress Toolkit | Staging + clone + sync | Evet (eklenti ile) |
Eklenti tabanlı çözüm ise WP Staging, All-in-One WP Migration, Duplicator gibi araçlarla gelir. WP Staging eklentisi özellikle basit arayüzü ile öne çıkar; tek tıkla staging kopyası oluşturur, veritabanı ve medya dosyalarını ayrı klasöre taşır. Dezavantajı, çok büyük sitelerde (5GB+ medya) zaman aşımına uğrayabilmesidir.
WordPress Staging Site Ayarları ve Dikkat Edilmesi Gerekenler

Staging site kurulduktan sonra, canlı siteye etki etmemesi için birkaç kritik ayar yapılmalıdır. Bu ayarlar yapılmazsa, staging üzerinden gönderilen e-postalar müşterilere ulaşabilir, arama motorları staging’i indexleyebilir veya staging yapısı ile canlıya yanlışlıkla veri gönderebilirsiniz.
WordPress Staging Site Yaparken Sık Yapılan Hatalar
Yeni başlayanların en sık düştüğü hataları aşağıda sıraladık. Bu hataların her biri, staging avantajını ortadan kaldırır ve ciddi sorunlara yol açabilir:
- robots.txt unutmak: Arama motorları staging’i indexlerse, “duplicate content” cezası alabilirsiniz.
Disallow: /ile tüm botları engelleyin. - Parola koruması koymamak: Public staging, rakiplerin sitenizi incelemesine olanak tanır.
.htpasswdveya hosting aracılığıyla parola koruması ekleyin. - Ödeme sistemi aktif bırakmak: WooCommerce staging’de ödeme modülü aktifse, test siparişleri gerçek ödeme alabilir. Stripe/PayPal test moduna alın.
- E-posta bildirimlerini kapatmamak: Sipariş onayı, üyelik aktivasyonu gibi e-postalar müşterilere ulaşır. WP Mail SMTP eklentisinin test modunu kullanın veya staging’de e-posta gönderimini tamamen kapatın.
- Cache eklentisini kapatmamak: Bazı cache eklentileri (özellikle sayfa cache), staging sayfalarını canlıda gösterebilir. Staging’de cache’i devre dışı bırakın.
- URL değişikliğini atlamak:
siteurlvehomedeğişmezse, staging canlı siteye yönlendirir ve sonsuz döngü oluşur.
WordPress Staging Site Performans, Güvenlik ve SEO Etkileri
Staging site doğru yapılandırıldığında, canlı sitenin performansına hiçbir etkisi olmaz. Ancak yanlış yapılandırılmış bir staging, üç kritik risk oluşturur: duplicate content (Google cezası), gerçek ödeme (müşteri mağduriyeti) ve veri sızıntısı (KVKK ihlali).
SEO tarafında, robots.txt + parola koruması kombinasyonu yeterlidir. Ek olarak staging’i noindex,nofollow meta tagı ile işaretleyebilirsiniz; bu, Google’ın yanlışlıkla staging’i keşfetmesi durumunda bile indexlenmemesini garanti eder.
Performans açısından, staging hosting kaynaklarını paylaşır. Çok yoğun bir eklenti testi sırasında canlı site yavaşlayabilir. Bu durumda staging’i ayrı bir sunucuda barındırmak (ör. ücretsiz bir fly.io hesabı) en sağlıklı çözümdür.
WordPress Staging Site Kontrol Listesi ve Sık Sorulan Sorular
Yayın öncesi son kontrol listesini uygulamadan staging’den canlıya push etmeyin. Aşağıdaki liste, 5+ yıllık WordPress deneyiminden derlenmiş en kritik kontrolleri içerir.
WordPress Staging Site Yayın Öncesi Son Kontrol Listesi
- Tüm sayfalar ve yazılar staging’de açılıyor mu?
- Form gönderimleri çalışıyor mu? (İletişim, yorum, abonelik)
- Ödeme akışı test modunda mı? (Stripe test kartı ile doğrulayın)
- robots.txt ve parola koruması aktif mi?
- SSL sertifikası geçerli mi? Tarayıcıda asma kilit ikonu var mı?
- Cache eklentisi staging’de devre dışı mı?
- E-posta bildirimleri kapatıldı mı? (wp-config.php’de
WP_DEBUG_LOGile loglanıyor mu?) - 404 hataları için staging taranmış mı? (Broken Link Checker eklentisi)
- PHP sürümü staging ve canlıda aynı mı?
- Veritabanı ön ek farklı mı? (ör.
wp_stg_)
Tüm maddeler tamam ise, hosting sağlayıcınızın “Push to Live” özelliğini veya manuel wp search-replace + dosya senkronizasyonu ile değişiklikleri canlıya alabilirsiniz. Push sonrası, canlı sitede hızlı bir smoke test (ana sayfa, kategori sayfası, tekil yazı, iletişim) yaparak her şeyin yolunda olduğunu doğrulayın.
WordPress Staging Site Hakkında Sık Sorulan Sorular
Staging site kaç günde bir güncellenmeli?
İçerik güncellemesi yapmadan 24 saat önce staging’i canlıdan taze yedek ile güncellemek idealdir. Bu, staging veritabanının canlıdan çok uzaklaşmasını engeller ve merge çakışmalarını azaltır.
Staging’de cache eklentisi kullanmalı mıyım?
Hayır, staging’de cache (özellikle sayfa cache) kapalı olmalıdır. Aksi halde, değişikliklerinizi anlık göremezsiniz ve bazen eski versiyon cache’i canlıda görünebilir. Sadece object cache (Redis/Memcached) staging’de açık kalabilir.
Staging ile production aynı sunucuda olursa ne olur?
Kaynak paylaşımı nedeniyle performans dalgalanması olur. Ayrıca, staging’de yapılan yüksek CPU tüketen bir test, canlı sitenin yavaşlamasına neden olabilir. Mümkünse staging’i ayrı bir sunucuda barındırın; en azından farklı bir hosting hesabı kullanın.
Staging subdomain’ini Google indexlerse ne yapmalıyım?
Öncelikle Google Search Console’dan staging’i URL kaldırma aracı ile geçici olarak kaldırın. Sonra robots.txt ve parola korumasını doğrulayın. Google bir sonraki taramada staging’i bırakacaktır. Eğer zaten indexlenmişse, noindex meta tagı ekleyin ve bir sitemap gönderin.
Staging’de eklenti test ederken lisans sorunu çıkar mı?
Bazı premium eklentiler domain bazlı lisanslama kullanır (ör. Yoast, WP Rocket). Staging subdomain’i için ayrı lisans gerekebilir. Eklentilerin çoğu test modunda lisans istemez; ancak üretimde kullanılan lisansı staging’de aktive etmeniz gerekebilir. Bu durum genellikle lisans sağlayıcının destek sayfasında açıklanır.
Staging’i kim görebilir?
Parola koruması ile sadece siz ve ekibiniz görebilir. Müşteri sunumu yapmak istiyorsanız, müşteriye özel bir kullanıcı adı + şifre verebilirsiniz. Paylaşımlı hosting’de .htpasswd dosyası ile kullanıcı bazlı erişim tanımlanabilir.
Staging’den canlıya geçiş (push) ne kadar sürer?
Site büyüklüğüne bağlıdır. 1GB’a kadar veritabanı + medya için 5-15 dakika yeterlidir. 10GB+ siteler için saatler sürebilir. Bu nedenle büyük sitelerde push’u gece yarısı gibi trafiğin az olduğu saatlerde planlamak gerekir.
Multisite yapısında staging nasıl kurulur?
Multisite staging, subdomain’lere de yayıldığı için daha karmaşıktır. Wildcard subdomain DNS kaydı, her alt site için ayrı staging subdomain’i ve özel bir wp-config.php gerektirir. Tavsiye: Multisite projelerinde staging için WP Engine veya Kinsta gibi multisite desteği iyi olan hosting sağlayıcılarını tercih edin.
Sonuç ve Öneriler
WordPress staging site, profesyonel bir yayın yönetiminin olmazsa olmaz parçasıdır. Doğru kurulduğunda, canlı sitede sıfır kesinti ile güncelleme yapmanızı sağlar. Yanlış kurulduğunda ise duplicate content cezasından veri sızıntısına kadar birçok risk oluşturur.
Bu rehberde öğrendiğiniz temel prensipleri özetlersek: ayrı veritabanı kullanın, robots.txt + parola koruması mutlaka ekleyin, cache ve e-posta bildirimlerini staging’de kapatın, push öncesi son kontrol listesini eksiksiz uygulayın.
Daha fazla içerik için aşağıdaki rehberlerimize göz atabilirsiniz:
- WordPress Child Theme Nasıl Oluşturulur? — Tema güncellemelerinde staging ile birlikte kullanmanız gereken kritik yapı.
- WordPress Beyaz Sayfa Hatası Çözümü — Staging’de yakaladığınız kritik hataların canlıda çözüm stratejileri.
- wp-config.php Güvenliği İçin Yapılması Gerekenler — Staging ve canlı arası dosya senkronizasyonunda güvenlik kontrolleri.
Staging site kurulumu veya yönetiminde spesifik bir sorununuz varsa, yorum bölümünden bize ulaşabilirsiniz.
Bir Cevap Yaz
E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir.