WordPress Staging Yenileme ve Veri Maskeleme

WordPress staging ortamı zamanla canlı siteden uzaklaşır: yeni siparişler, içerikler, eklenti ayarları ve medya dosyaları test kopyasında bulunmayabilir. Staging yenileme, güncel üretim verisini kontrollü biçimde test ortamına çekmektir. Kopyalama sırasında staging’e özel çalışmaları kaybetmemek, kişisel verileri azaltmak ve canlı servis bağlantılarını yeniden ayırmak gerekir.

Bu rehber, tek site WordPress için mevcut staging ortamının yenilenmesine odaklanır. İlk alt alan adı, veritabanı ve erişim koruması kurulumu ile canlıya yayınlama adımları için cPanel WordPress staging kurulum rehberini kullanın. Buradaki akış canlıdan staging’e ilerler; iki veritabanını otomatik birleştirme yöntemi değildir. Multisite ve özel uygulama depoları ayrıca planlanmalıdır.

Yenilemeden Önce Verinin Sahibini Belirleyin

Geliştirme, staging ve canlı ortam farklı amaçlara hizmet eder. Staging; tema, eklenti, WordPress/PHP sürümü, özel kod, tasarım ve sorgu değişikliklerini test etmek için hazırlanır. Farklı hostname veya klasör, aynı hosting hesabında bağımsız sistem kullanıcısı ya da kaynak izolasyonu sağlamaz. Daha geniş yerleşim seçenekleri geliştirme, test ve canlı hosting mimarisi rehberinde açıklanır.

İlk iş, hangi verinin hangi ortamda korunacağını yazmaktır. Aşağıdaki tablo bir planlama örneğidir; eklentilerin gerçek veri şemasının veya güvenli tablo listesinin yerine geçmez.

Staging’e özgü yeni sayfalar, menüler, özel alanlar veya tema seçenekleri yalnızca dosyalarda bulunmayabilir. Yenilemeden önce uygulamaya uygun dışa aktarım, sürümlü migrasyon veya doğrulanmış geri yükleme kopyası hazırlayın. Eski staging DB’sini sonradan yeni kopyanın üstüne dökmek, yenilemenin getirdiği güncel veriyi tekrar kaybettirir.

1. Yenileme Zamanını ve Kaynak Bütçesini Planlayın

Takvimi sitenin değişim hızına ve test amacına göre belirleyin. Büyük bir güncelleme öncesinde güncel veri gerekebilir; devam eden tasarım çalışmasının ortasında habersiz yenileme uygun değildir. Kopyanın zamanı, WordPress/eklenti/tema sürümleri, PHP ve DB sürümleri ile beklenen test senaryolarını kaydedin. Sessiz saatler kaynak baskısını azaltabilir; verinin tutarlı olduğunu veya yazımların durduğunu kanıtlamaz.

• Disk ve inode: Mevcut staging, yeni kopya, SQL dışa aktarımı, arşivler ve geçici dosyalar için gereken alanı birlikte hesaplayın. Her site için “iki kat alan yeterlidir” kuralı yoktur. Inode temizliği rehberi yardımcı olabilir; yalnızca aidiyetini ve yedeğini doğruladığınız dosyaları silin.
• CPU, RAM, IO ve EP: Kopyalama, sıkıştırma, içe aktarma ve testler canlıyla aynı bütçeyi tüketebilir. Resource Limit Reached rehberindeki ölçümlerle etkiyi izleyin.
• Araç sınırları: SSH, WP-CLI, panel yedekleme ve otomatik staging özelliklerinin gerçekten açık olduğunu doğrulayın. Dosya veya DB boyutuna göre süre ve içe aktarma sınırları değişir.

Bir CDN, kaynak sunucudaki medya dosyalarını kendiliğinden silmez. Harici medya deposu kullanılıyorsa staging’in canlı dosyaları değiştiremeyeceği ayrı erişim ve ad alanı gerekir. Kapasite ya da erişim ayrımı yetersizse paylaşımlı hosting planını veya ayrı bir VPS ortamını gerçek gereksinimlerle değerlendirin; ürün adı tek başına yeterlilik sağlamaz.

2. Kopyalama Başlamadan Hedefi Kapatın ve Ayırın

Yenileme, daha önce doğru yapılmış korumaları da değiştirebilir. Canlıdan alınan wp-config.php, .htaccess, eklenti seçenekleri ve zamanlanmış işler eski bağlantıları geri getirebilir. Yeni kopya çalışmadan önce web üzerinden PHP çalışmasını, staging CLI/cron görevlerini ve bağımsız kuyruk işçilerini durdurun; mail, ödeme, webhook ve diğer dış etkileri altyapı veya kontrollü test hedefleriyle sınırlandırın. Koruma doğrulanamıyorsa içe aktarılan uygulamayı başlatmayın.

Alt alan adı olarak staging.ornekalanadi.com, test.ornekalanadi.com veya qa.ornekalanadi.com kullanılabilir. Mevcut hostname ve gerçek document root eşleşmesini kontrol edin. Yeni hedef gerekiyorsa güncel cPanel’de Domains → Create a New Domain akışını kullanın; sunuluyorsa Registered Domain seçeneğini seçin, tam adı yazın ve document root paylaşımını kaldırın. Güncel belge yeni kökü public_html altında sınırlar; arayüz ve yetkiler kurulu sürüme göre değişebilir.

public_html/staging gibi bir kök hem staging hostname’i hem ornekalanadi.com/staging yoluyla açılabilir. İkisini de, varsa proxy/CDN ve alternatif yönlendirmeleri de sınayın. DNS kaydını alan adının gerçek yetkili DNS sağlayıcısında doğrulayın; cPanel’de hostname oluşturmak harici DNS’i otomatik güncellemez. Sertifikanın staging adını kapsadığını ve HTTPS doğrulamasının başarılı olduğunu kontrol edin.

1. cPanel Directory Privacy içinde gerçek staging dizini için parola korumasını etkinleştirip kaydedin; ayrı yetkili kullanıcı oluşturun.
2. Kimlik bilgisi olmadan ana sayfa, PHP dosyası ve statik dosyaya erişimin reddedildiğini doğrulayın. HTTP koruması CLI, SFTP veya aynı hesap kullanıcısının dosya erişimini durdurmaz.
3. Canlıdan kopyalanan arşivi staging’e çıkardıktan sonra koruma kurallarını yeniden sınayın; kopyalanan dosyalar staging kurallarını ezmiş olabilir.

WordPress’te Ayarlar → Okuma → Arama motorlarının bu siteyi indekslemelerini engelle tercihini ayrıca etkinleştirip noindex çıktısını kontrol edin. robots.txt içindeki Disallow: / bir tarama talimatıdır; erişim koruması veya indeks dışı kalma garantisi değildir ve botun noindex’i görmesini engelleyebilir. Hassas staging verisini botların görebilmesi için açmayın. robots.txt ve sitemap.xml rehberindeki canlı görünürlük ayarlarını staging ayarlarıyla karıştırmayın.

3. Dosyaları ve Veritabanını Tutarlı Bir Kopyadan Yenileyin

Önce mevcut staging’in benzersiz çalışmaları dahil geri yükleme noktasını koruyun. Üretimden alınacak kopya dosya, DB ve medya ilişkilerini tutarlı temsil etmelidir. Yedekleme yönteminin hareketli veri ve kullanılan depolama motorları için tutarlılık koşullarını doğrulayın; gerekirse ilgili yazım kaynaklarını planlı biçimde durdurun veya desteklenen tutarlı yedekleme yöntemini kullanın. Rastgele zamanlarda tabloları parça parça dışa aktarmak ilişkileri bozabilir.

Panelin tam hesap yedeği ile tek site dosya/DB yedeğinin kapsamı ve geri yükleme yetkileri farklıdır. Bir cPanel tam hesabını geri yüklemek ek yönetici yetkisi gerektirebilir. Yedek dosyasının bulunması geri yükleme başarısının kanıtı değildir; cPanel yedekleme ve geri yükleme rehberindeki kapsamı kendi kurulumunuza uyarlayın.

Dosyaları Kontrollü Hedefe Aktarın

1. Canlı kökteki wp-admin, wp-includes, wp-content ve gerekli kök dosyalarını belirleyin. Özel yükleme yolları, mu-plugin’ler, cache drop-in’leri, sembolik bağlantılar ve dış medya depolarını envantere ekleyin.
2. File Manager kullanıyorsanız gizli dosyaları gösterin. Kopyalanan içerikten staging’in kendisini, eski yedekleri ve gereksiz geçici dosyaları dışlayın; iç içe kök nedeniyle staging’i kendi içine kopyalamayın.
3. Dosyaları panel veya yetkili SFTP ile alın. Sıkıştırma gerekiyorsa site-live.zip gibi bir arşivi webden erişilemeyen özel yerde tutun. Çıkarma yollarını ve dosya değiştirme/silme kapsamını inceleyin; uygulama çalışması kapalı kalsın.
4. Üretim yapılandırmasını körlemesine etkinleştirmeyin. Staging korumasını ve ortama ait yapılandırmayı yeniden uygulayın, tamamlanan geçici arşivleri onaylı saklama planına göre kaldırın.

Sıkıştırma aktarımı kolaylaştırabilir, ancak her zaman daha hızlı olduğu veya IO tüketimini azalttığı söylenemez. Süre, disk ve işlemci etkisini ölçün; yarıda kalan kopyayı tamamlanmış saymayın.

Staging’e Ayrı DB ve Kullanıcı Atayın

cPanel’de Manage My Databases arayüzünü kullanın; eski sürümlerde ad MySQL Databases olabilir. Yeni DB ve yalnızca bu staging DB’sine yetkili ayrı kullanıcı oluşturun veya mevcut staging’e ait ayrımı doğrulayın. Canlı DB kullanıcısını tekrar kullanmayın. Gerekli WordPress yetkilerini sadece seçilen staging DB’sine verin; cPanel’in eklediği önek dahil gerçek tam adları ve DB sunucusunu kaydedin.

1. Üretim DB’sinin doğru seçildiğini doğrulayarak desteklenen tutarlı dışa aktarımı alın. phpMyAdmin’de Export/SQL seçimi bir araçtır; “Quick” seçeneği tek başına tutarlılık sağlamaz.
2. SQL içindeki DB seçme, oluşturma veya silme ifadelerini ve tablo kapsamını inceleyin. Yalnızca staging hedefinde işlem yapabilecek yetki kullanın. Eski staging DB’si yeniden kullanılacaksa dökümün mevcut tabloları nasıl ele aldığını ve döküm dışında kalan tabloları belirleyin; Import işlemini tam hedef temizliği saymayın. Tercihen yeni, boş bir staging DB’sine aktarın. Mevcut hedefte temizlik gerekiyorsa benzersiz çalışmaları ve geri yükleme noktasını koruduktan sonra yalnızca staging’e ait olduğu doğrulanan nesneler için açık bir plan uygulayın.
3. phpMyAdmin’de ayrı staging DB’sini seçip Import işlemini tamamlayın. Hata/limit kayıtlarını inceleyin; yarım kalmış içe aktarımı kullanıma açmayın. DB ve kullanıcıyı phpMyAdmin yerine cPanel’den yönetmek panel kayıtlarının tutarlı kalmasını sağlar.

Aşağıdaki yapılandırmayı kendi staging ortamınıza uyarlayın. Bunlar örnek değerlerdir: yeni_sifre yerine üretilmiş güçlü staging parolası, tam cPanel DB/kullanıcı adı ve sağlayıcının gerçek DB host değerini yazın. localhost her kurulumda doğru değildir. Yalnızca staging dosyasını düzenleyin.

define( 'DB_NAME', 'dchost_staging' );
define( 'DB_USER', 'dchost_staging_user' );
define( 'DB_PASSWORD', 'yeni_sifre' );
define( 'DB_HOST', 'localhost' );

Staging’e farklı WordPress anahtar/tuzları, test yönetici parolaları ve gerekli test API bilgilerini atayın. WP_ENVIRONMENT_TYPE için staging değeri ortamı etiketler; mail, ödeme veya cron işlemlerini tek başına durdurmaz. Ziyaretçi tetiklemeli WP-Cron ayrı kontrol edilir; host cron, doğrudan cron URL’leri, CLI ve kuyruk işçileri ayrıca denetlenmelidir.

4. URL Dönüşümünü Veri Maskelemeden Ayırın

İçe aktarılan kopyada üretim URL’leri bulunur. WP_HOME ve WP_SITEURL değerleri ilgili WordPress adreslerini geçersiz kılabilir, ancak DB içeriğini yeniden yazmaz. Aşağıdaki örnek, WordPress çekirdeğinin site kökünde olduğu kurulum içindir; çekirdek alt dizindeyse iki adresin farklı olması gerekebilir:

define( 'WP_HOME', 'https://staging.ornekalanadi.com' );
define( 'WP_SITEURL', 'https://staging.ornekalanadi.com' );

Kalıcı içerik dönüşümünde serialize edilmiş PHP verisini anlayan desteklenen bir araç kullanın. Önce staging geri yükleme kopyasını ve değişecek tablo/alan listesini hazırlayın. WP-CLI wp search-replace kullanılıyorsa doğru --path, DB bağlantısı ve tablo kapsamını doğrulayın; --dry-run değişiklikleri kaydetmeden raporlar. Bu önizleme, WordPress yüklenirken çalışan kodun dış etkilerini engellemez. --skip-plugins mu-plugin’leri atlamaz.

Komutun varsayılan kapsamı WordPress’in kayıtlı tablolarıdır; özel eklenti tabloları ayrıca incelenmelidir. --all-tables diğer tabloları da kapsar; bu rehber için güvenli varsayılan değildir. URL taşımada GUID alanlarını değiştirmeyin; tam URL biçimlerini ve eklentiye özgü depolamayı değerlendirin. Arama-değiştirme müşteri verisi maskeleme ya da DB birleştirme aracı değildir.

SSH yoksa korumalı, bakımı yapılan bir taşıma aracının önizlemesini kullanın. İnternete açık geçici bir PHP arama-değiştirme betiği yüklemeyin. İşlemden sonra araç dosyalarını ve raporlardaki sırları koruyun; staging üzerinde Ayarlar → Genel, oturum açma, yönlendirme, medya ve tarayıcıdaki mixed-content hatalarını kontrol edin.

5. Kişisel Veriyi ve Üretim Kimlik Bilgilerini Azaltın

Gerçek müşteri adı, e-posta, telefon, adres, sipariş notu veya form eki her test için gerekli değildir. Önce yapay test kayıtlarını veya asgari bir veri kümesini tercih edin. Gerçek kopya gerekiyorsa dış erişim ve uygulama yürütmesi kapalıyken, yalnızca yetkili operatörün eriştiği alanda maskeleyin. Maskeleme işleminin kendisi WordPress yükleyecekse üretim sırları ve dış etkiler daha önce ayrılmış olmalıdır.

1. Kapsamı çıkarın: Kullanıcılar, yorumlar, sipariş/adres tabloları, özel eklenti tabloları, serialized seçenekler, loglar, kuyruk payload’ları, ek dosyalar ve harici depolamayı inceleyin. Yalnızca görünen kullanıcı e-postasını değiştirmek yeterli değildir.
2. İlişkileri koruyun: Örneğin bir test müşterisinin birden fazla siparişte aynı takma kimlikle görünmesi gerekiyorsa dönüşümü tutarlı uygulayın. ID, foreign-key benzeri ilişkiler, benzersizlik ve uygulama doğrulama kurallarını bozmayın. Bu bir tasarım örneğidir; tüm eklentiler için tek SQL şablonu yoktur.
3. Sırları yenileyin: Canlı API anahtarları, SMTP bilgileri, ödeme token’ları, webhook imzalama sırları ve oturumları test kapsamından çıkarın. Maskeleme, aynı parolayla giriş yapılmasını veya canlıya API çağrısı gönderilmesini kendiliğinden engellemez.
4. Sonucu doğrulayın: Gerekli müşteri–sipariş ilişkileri ve test senaryoları çalışırken gerçek alıcı, adres veya kimlik bilgisi kalmadığını kapsama uygun kontrollerle sınayın. Hata logları, yedekler ve dışa aktarımlar da aynı erişim/saklama kurallarına tabi olsun.

WordPress’in kişisel veri silme aracı belirli e-posta için çekirdek ve kayıtlı eklenti silme işlevlerini çalıştırır; kullanıcı hesabını otomatik silmez ve tüm özel depoların kapsandığını garanti etmez. Bildirim e-postası da gönderebilir. Bu nedenle bütün staging verisini tek işlemle anonimleştirdiği varsayılmamalıdır. Geri eşleme imkânı kalan takma adlandırılmış veriyi tamamen anonim kabul etmeyin.

6. Aracın Kopyalama ve Tablo Davranışını Doğrulayın

Manuel kopya, paneldeki otomatik yükleyici ve WordPress taşıma eklentisi aynı kapsama sahip değildir. Araç sürümü, lisans, site boyutu, multisite desteği, özel tablolar, medya ve dış servisleri kapsama biçimini kontrol edin. Hiçbir yöntemin adını veri koruma garantisi olarak kullanmayın.

Softaculous örneği: Resmî Create Staging belgesi mevcut kurulumu seçip Stage simgesinden domain, dizin ve DB ayrıntılarını girmeyi anlatır. Elle kurulmuş site önce araç kayıtlarına alınmalıdır; belgede WordPress Multisite staging desteklenmez. Ayrıca yönetici/kullanıcı giriş bilgilerinin kaynakla aynı kalacağı açıkça belirtilir. Dolayısıyla klon oluşturmak test kimliklerini otomatik ayırmaz. Mevcut staging’i nasıl yenilediğini kurulu sürümde doğrulayın; önceki kopyayı kurtarma planı olmadan silmeyin.

Softaculous Push to Live, ters yöndeki yayınlama işlemidir. Belgede Default/Customize ve dosya üzerine yazma seçenekleri ile tam DB seçeneğinin veritabanını sildiği uyarısı yer alır; bu açıklama satır düzeyinde birleştirme garantisi sunmaz. Belgedeki aktarım kaynağı ifadesi de muğlaktır: gerçek ekranda kaynak/hedefi ve seçilen kapsamı doğrulamadan işlem yapmayın. Başka eklentilerdeki “seçili tablo” özelliği için de bağımlılık ve kayıt koruma davranışı ayrıca doğrulanmalıdır.

wp_options yalnızca tema ayarlarından, wp_posts/wp_postmeta yalnızca sayfalardan oluşmaz. wp_terms ve wp_term_relationships gibi yapılar diğer kayıtlarla ilişkilidir. Bu adlar taşınması güvenli tablolar listesi değildir. WooCommerce HPOS’ta yetkili sipariş deposu ile yedek tabloların rolleri ve senkronizasyon durumu önemlidir; sipariş ID’leri eşleşmelidir. Sadece posts tablolarını almak veya dışlamak siparişleri koruduğunuzu kanıtlamaz.

Üretim yeni sipariş, ödeme, stok ve üyelik verisinin yetkili kaynağı olarak kalmalıdır. Gelişmiş aktarım gereksiniminde uygulamaya uygun migrasyon ve doğrulanmış birleştirme yöntemi seçin. VPS yönetim modeli araç erişimini değiştirebilir; veritabanı ilişkilerini kendiliğinden çözmez.

7. Staging’i Açmadan Kabul Kontrolü Yapın

• Erişim: Yetkisiz web istekleri reddediliyor; staging ve canlı hostname’in olası alt dizin yolu korunuyor. Test kullanıcıları ayrı. WordPress güvenliği rehberindeki WAF, güncelleme ve 2FA kontrollerini erişiminize göre uygulayın.
• Mail ve dış servisler: Üretim SMTP/API kimlikleri yok; form ve sandbox ödeme testi yalnızca onaylı test hedeflerine gidiyor. Boş SMTP ayarı gönderimi garanti olarak durdurmaz; wp_mail engeli doğrudan SMTP veya HTTP API’lerini kapsamayabilir.
• İşler: Kopyalanan cron/queue görevleri ve bekleyen payload’lar incelendi. Gerekli test işleri yalnızca staging verisiyle çalışıyor; canlı stok, fatura veya ödeme işlemiyor.
• URL ve veri: Gerekli sayfalar, medya, oturum ve müşteri–sipariş ilişkileri doğru; maskeleme kapsamı doğrulandı. Canlı servislere beklenmeyen bağımlılık kalmadı.
• Cache ve loglar: Cache erişimi ve key/ad alanı, CDN ve obje deposu staging’e ait. Yalnızca farklı önek yetkilendirme sağlamaz. Debug çıktısı ziyaretçiye gösterilmiyor; loglar özel yerde ve sınırlı süre saklanıyor.

Geliştirme sırasında tam sayfa cache’ini azaltabilirsiniz; yayın öncesi üretime benzer cache davranışını ayrıca test edin. Sepet, hesap, giriş yapmış kullanıcı ve kişiselleştirilmiş yanıtları kontrol edin. Core Web Vitals ve hosting rehberi ölçüm bağlamı sağlar; sakin staging sonuçları canlı yük altında aynı sonucu garanti etmez. Güvenlik kurallarını genel olarak gevşetmek yerine gerekli istisnaları kapsam ve süreyle sınırlandırın.

Yenileme Başarısız Olursa ve Yayına Hazırlanırken

Yarım dosya kopyası, içe aktarma hatası, yanlış DB veya gerçek mail alıcısı tespitinde staging’i kapalı tutun. Hata kayıtlarını koruyun, kapsamı belirleyin ve yalnızca staging’e ait dosya/DB/ayarları doğrulanmış önceki noktaya döndürün. İşlem üretime veya dış servise etki ettiyse staging geri yüklemesi bunu geri alamaz; ilgili kayıtları ve etkileri ayrıca uzlaştırın.

Örneğin saat 10.00’daki kopyadan sonra canlıda yeni siparişler geldiyse akşam eski staging DB’sini canlıya yüklemek o kayıtları kaybettirir. “Statik site”, düşük trafik veya bakım sayfası bütün yazımların durduğunu kanıtlamaz. Tam canlı DB değişimi ancak ilgili yönetici/API/callback/cron/queue yazımları gerçekten durduktan sonra alınan güncel tutarlı kopya, yeniden uygulanmış testli değişiklikler ve doğrulama sonuna kadar süren yazım kontrolüyle ayrı planlanabilir. Yedek almak sonradan oluşan kayıtların korunmasını garanti etmez.

Test edilen aynı kod sürümlerini ve gerekli uygulama migrasyonlarını kontrollü yayınlayın; yeni canlı yüklemeleri koruyun. Staging’de tasarlanan medya/içerik için uygulamaya uygun taşıma planı hazırlayın. Dosya senkronizasyonu DB’yi birleştirmez. İlk kurulum ve yayınlama rehberindeki kontrol listesine dönmeden bir yenileme işlemini canlıya geçiş saymayın.

Sürekli import zaman aşımı, disk/inode baskısı, birden çok test ortamı veya farklı CI/CD araçları gereksinimi varsa ayrı kapasite ve yönetim modeli değerlendirin. Paylaşımlı hosting’den VPS’e geçiş rehberi planlamaya yardımcı olur. Her yenilemenin sonunda kopya zamanını, kapsamı, maskeleme sürümünü, test sonuçlarını, kurtarma noktasını ve sorumlusunu kaydedin; kullanılmayan staging’i benzersiz çalışmaları koruduktan sonra yalnızca kendisine ait kaynaklarla birlikte kaldırın.

Resmî Kaynaklar

Panel, araç ve veri deposu açıklamaları 4 Kasım 2026’da incelenen resmî belgelere dayanır. İşlem öncesinde kurulu sürümün kapsamını yeniden kontrol edin.

• cPanel: Create a New Domain
• cPanel: Manage My Databases
• cPanel: Directory Privacy
• WP-CLI: search-replace
• WordPress: Personal Data Eraser
• WooCommerce: HPOS
• Softaculous: Create Staging
• Softaculous: Push to Live
• Google: noindex