İçindekiler
- 1 WordPress Staging Ortamı Nedir ve Neden Kurmalısınız?
- 2 Staging Ortamı Kurmadan Önce Planlama: Alan Adı, Hosting ve Kaynaklar
- 3 cPanel’de Staging İçin Alt Alan Adı (Subdomain) Oluşturma
- 4 WordPress Dosya ve Veritabanını Staging Ortamına Klonlamak
- 4.1 1. Staging kurulumu öncesi eksiksiz yedek alın
- 4.2 2. WordPress dosyalarını staging dizinine kopyalayın
- 4.3 3. Yeni bir veritabanı ve kullanıcı oluşturun
- 4.4 4. Canlı veritabanını dışa aktarın
- 4.5 5. Veritabanını staging veritabanına içe aktarın
- 4.6 6. wp-config.php dosyasını staging veritabanına göre güncelleyin
- 4.7 7. Site URL ve WordPress URL bilgisini güncelleyin
- 5 Staging Ortamını Güvenli Hale Getirmek: Şifreleme, Erişim ve SEO
- 6 Staging Ortamında Çalışma: Test, Optimizasyon ve Onay Süreci
- 7 Staging’den Canlı Siteye Güvenli Yayına Alma Stratejileri
- 8 DCHost Üzerinde WordPress Staging Ortamı Kurarken Dikkat Edilecek Noktalar
- 9 Sonuç ve Önerilen Yol Haritası
WordPress Staging Ortamı Nedir ve Neden Kurmalısınız?
WordPress sitenizde tema değişikliği, büyük bir eklenti güncellemesi ya da özel bir geliştirme yapmanız gerektiğinde, bunu doğrudan canlı sitede denemek ciddi risk taşır. Tek bir hatalı eklenti veya kod parçası; ödeme sayfanızın çalışmaması, formların bozulması veya sitenizin tamamen erişilemez hale gelmesiyle sonuçlanabilir. Bu riskleri ortadan kaldırmanın en sağlıklı yolu, canlı sitenizin bire bir kopyası olan bir WordPress staging ortamı kurmaktır.
Staging ortamı; gerçek kullanıcıların görmediği, arama motorlarının taramadığı, sadece sizin ve ekibinizin erişebildiği bir test kopyasıdır. Tüm güncellemeleri, tasarım değişikliklerini, performans optimizasyonlarını önce burada dener, her şeyin sorunsuz çalıştığından emin olduktan sonra canlı siteye aktarırsınız. Özellikle e‑ticaret, üyelik tabanlı sistemler, eğitim platformları veya çok yazarlı bloglarda staging, neredeyse zorunlu bir mimari parçası haline gelir. DCHost olarak bu yazıda, cPanel üzerinde alt alan adı kullanarak staging ortamını nasıl adım adım kuracağınızı, WordPress dosya ve veritabanını nasıl klonlayacağınızı ve en önemlisi, yaptığınız değişiklikleri güvenli şekilde canlı siteye nasıl alacağınızı detaylı bir şekilde anlatacağız.
Staging Ortamı Kurmadan Önce Planlama: Alan Adı, Hosting ve Kaynaklar
Teknik adımlara geçmeden önce, staging ortamınızı nereye ve nasıl kuracağınıza karar vermeniz gerekir. Bu planlama aşaması, ileride karşılaşabileceğiniz pek çok sorunu baştan çözer.
Alt alan adı mı, alt dizin mi?
Staging için en sık kullanılan yöntem, alt alan adı (subdomain) kullanmaktır. Örneğin:
- Canlı site:
example.com - Staging:
staging.example.comveyatest.example.com
Alternatif olarak example.com/staging gibi bir alt dizin de kullanabilirsiniz; ancak izolelik, SSL ve yönlendirme ayarları açısından alt alan adı genellikle daha temiz ve yönetilebilir bir yapıdır. Zaten alt alan adları ile alt dizinleri karşılaştırdığımız subdomain mi alt dizin mi rehberimizde de, staging gibi test ortamlarında alt alan adının çoğu senaryoda daha mantıklı olduğunu vurguluyoruz.
Hangi hosting türü daha uygun?
Staging ortamını çoğunlukla aynı hosting hesabı içinde kurmanız yeterlidir. Özellikle DCHost üzerinde paylaşımlı hosting veya WordPress hosting kullanıyorsanız, cPanel hesabınızda ek bir alt alan adı açarak staging’i burada barındırmanız son derece pratiktir. Daha yüksek trafikli projeler, özel geliştirme ihtiyaçları veya çok sayıda staging ortamı söz konusuysa, DCHost VPS veya dedicated sunucu çözümleri ile staging ortamlarını tamamen ayrı bir altyapıya da alabilirsiniz.
Kaynak planlaması ve limitler
Staging ortamı genellikle canlı site kadar trafik almaz; ancak dosya boyutu ve veritabanı büyüklüğü neredeyse aynıdır. Bu nedenle:
- Disk alanınızın staging kopyayı da taşıyacak kadar yeterli olduğundan emin olun.
- cPanel’deki CPU, RAM ve IO limitlerini gözden geçirin; yoğun testler sırasında anlık limit aşımlarını önlemek için cPanel kaynak limitleri rehberimize göz atabilirsiniz.
- Veri kaybını önlemek için, staging kurulumu öncesinde mutlaka sağlam bir yedekleme stratejisi tasarlayın. Bu konuda detaylar için WordPress yedekleme stratejileri rehberimizi incelemenizi öneririz.
cPanel’de Staging İçin Alt Alan Adı (Subdomain) Oluşturma
Planlamayı netleştirdikten sonra, ilk somut adım staging ortamı için bir alt alan adı oluşturmaktır. Aşağıdaki adımlar DCHost üzerinde cPanel kullanan müşterilerimiz için geçerlidir.
1. cPanel’e giriş yapın
DCHost müşteri panelinizden cPanel’e tek tıkla erişebilir veya doğrudan cPanel giriş bilgilerinizle panele bağlanabilirsiniz.
2. Alt alan adı oluşturun
- cPanel ana sayfasında “Alan Adları” → “Alt Alan Adları” (Subdomains) menüsüne tıklayın.
- Alt alan adı kısmına
staging,testveya ekip içinde anlamlı bir isim yazın. - Açılır listeden staging kurmak istediğiniz ana alan adını seçin.
- Belge kökü (Document Root) otomatik olarak örneğin
public_html/stagingşeklinde gelecektir; dilerseniz değiştirebilirsiniz, ancak varsayılan genellikle uygundur. - Oluştur butonuna tıklayın.
Bu adımın sonunda, staging.example.com gibi bir alt alan adınız ve bu alan adına bağlı boş bir dizin yapınız oluşmuş olur.
3. SSL sertifikasını kontrol edin
Staging ortamında da HTTPS kullanmak önemlidir. Böylece hem canlı ortama daha yakın bir yapı kurar hem de karışıklıkları önlersiniz.
- cPanel’de “SSL/TLS Status” veya otomatik SSL arayüzünü açın.
- Yeni oluşturduğunuz alt alan adının yanında sertifika durumunu kontrol edin.
- Otomatik SSL etkin değilse, ücretsiz bir SSL sertifikası kurulumunu başlatın.
SSL ve HTTPS tarafını daha derinlemesine anlamak isterseniz, SSL sertifikası nedir ve nasıl güvence sağlar başlıklı yazımız da işinize yarayacaktır.
WordPress Dosya ve Veritabanını Staging Ortamına Klonlamak
Alt alan adınız hazır olduğuna göre, şimdi canlı WordPress kurulumunuzu bu yeni alt alan adı altına kopyalamamız gerekiyor. Bu işlem üç ana aşamadan oluşur: dosyaları kopyalamak, veritabanını kopyalamak ve yeni ortamı yapılandırmak.
1. Staging kurulumu öncesi eksiksiz yedek alın
Canlı sitenizde yapacağınız her ciddi işlemde olduğu gibi, staging kurulumu öncesinde de mutlaka tam yedek alın:
- WordPress dosyaları (tema, eklentiler, yüklemeler, çekirdek dosyalar)
- Veritabanı (tüm tablolar)
cPanel üzerinden tam hesap yedeği alabilir, sadece dosyalar için Dosya Yöneticisi veya FTP kullanabilir, veritabanı için de phpMyAdmin ile SQL dışa aktarımı yapabilirsiniz. Otomatik ve düzenli yedekleme kurmak için de yukarıda link verdiğimiz WordPress yedekleme rehberindeki yöntemleri staging sürecinize entegre etmeniz iyi bir alışkanlıktır.
2. WordPress dosyalarını staging dizinine kopyalayın
Varsayalım canlı siteniz public_html altında kurulu ve staging için public_html/staging dizinini kullanacaksınız.
- cPanel’de Dosya Yöneticisini açın.
public_htmldizinine girin vewp-admin,wp-content,wp-includesdahil olmak üzere tüm WordPress dosya ve klasörlerini seçin.- “Sıkıştır” seçeneğiyle bunları bir
.ziparşivine dönüştürün (örneğinsite.zip). - Oluşturduğunuz
site.zipdosyasınıpublic_html/stagingdizinine taşıyın. public_html/stagingiçine giripsite.zipdosyasını “Çıkar” (Extract) diyerek açın.- İşlem bitince arşiv dosyasını silebilirsiniz.
Dilerseniz bu işlemi FTP/SFTP ile de yapabilirsiniz; ancak cPanel içinden sıkıştırma/açma genellikle çok daha hızlıdır.
3. Yeni bir veritabanı ve kullanıcı oluşturun
Staging ortamınızın canlı siteyle aynı veritabanını kullanmasını istemeyiz; çünkü staging’de yaptığınız değişiklikler canlı veriyi etkileyebilir. Bu yüzden staging için ayrı bir veritabanı ve kullanıcı oluşturuyoruz.
- cPanel’de “MySQL® Veritabanları” menüsüne tıklayın.
- “Yeni Veritabanı Oluştur” bölümünde örneğin
staging_dbgibi bir isim girip veritabanını oluşturun. - “MySQL Kullanıcıları” bölümünde, staging için yeni bir kullanıcı oluşturun (örneğin
staging_user) ve güçlü bir parola belirleyin. - “Kullanıcıyı Veritabanına Ekle” bölümünde oluşturduğunuz kullanıcıyı yeni veritabanına atayın ve TÜM AYRICALIKLARı verin.
4. Canlı veritabanını dışa aktarın
- cPanel’den phpMyAdmini açın.
- Sol menüden canlı sitenizin kullandığı veritabanını seçin.
- Üst menüden “Dışa aktar” (Export) sekmesine tıklayın.
- “Hızlı” ve “SQL” seçenekleri genellikle yeterlidir; “Git” diyerek SQL dosyanızı indirin.
5. Veritabanını staging veritabanına içe aktarın
- phpMyAdmin’de bu kez yeni oluşturduğunuz staging veritabanını seçin.
- Üst menüden “İçe aktar” (Import) sekmesine tıklayın.
- Az önce indirdiğiniz canlı veritabanı SQL dosyasını seçin.
- Varsayılan ayarlar genellikle yeterli; “Git” diyerek aktarımı başlatın.
İşlem tamamlandığında, staging veritabanınız canlı veritabanının bire bir kopyası olacaktır.
6. wp-config.php dosyasını staging veritabanına göre güncelleyin
Şimdi staging dizinindeki WordPress kurulumunu yeni veritabanına bağlamamız gerekiyor.
- cPanel Dosya Yöneticisi ile
public_html/stagingdizinine girin. wp-config.phpdosyasını bulun ve “Düzenle” butonuna tıklayın.- Aşağıdaki satırları staging veritabanına göre güncelleyin:
define( 'DB_NAME', 'cpanelkullanici_staging_db' );
define( 'DB_USER', 'cpanelkullanici_staging_user' );
define( 'DB_PASSWORD', 'BURAYA_GUCLU_SIFRE' );
DB_HOST genellikle localhost olarak kalabilir. Değişiklikleri kaydedin.
7. Site URL ve WordPress URL bilgisini güncelleyin
Veritabanınız hâlâ canlı alan adını işaret ediyor olacaktır. Bu nedenle staging veritabanındaki URL’leri staging alt alan adınıza çevirmemiz gerekir.
Seçenek 1: wp-config.php ile geçici çözüm
Hızlıca erişmek için önce şu satırları wp-config.php içine ekleyebilirsiniz:
define( 'WP_HOME', 'https://staging.example.com' );
define( 'WP_SITEURL', 'https://staging.example.com' );
Bu, WordPress’in temel URL’lerini staging alan adınızla çalıştırır. Ancak veritabanındaki eski URL’ler (özellikle iç linkler ve medya URL’leri) hâlâ canlı alan adına işaret ediyor olabilir.
Seçenek 2: Veritabanında arama-değiştirme
Daha temiz ve kalıcı çözüm, veritabanında arama-değiştirme yapmaktır. Bunu:
- Güvenilir bir “search-replace” eklentisiyle,
- veya WP-CLI kullanabiliyorsanız komut satırından
gerçekleştirebilirsiniz. Mantık basit: https://example.com adresini https://staging.example.com ile değiştirirsiniz. Bu işlemi yaparken veritabanı yedeğinizin elinizde olduğundan emin olun; yanlış bir arama-değiştirme ciddi sorunlara yol açabilir.
Staging Ortamını Güvenli Hale Getirmek: Şifreleme, Erişim ve SEO
Staging ortamının canlı siteyle aynı içeriği barındırdığını unutmayın. Arama motorları bu ortama erişirse, kopya içerik (duplicate content) sorunu, yanlış URL’lerin indekslenmesi ve SEO karmaşası yaşanabilir. Ayrıca herkese açık bir staging ortamı, saldırganlara da fazladan bir hedef sunar.
1. Staging ortamını parola ile koruyun (HTTP Basic Auth)
En pratik yöntemlerden biri, staging alt alan adınızı basit bir HTTP kimlik doğrulaması ile korumaktır. cPanel’deki “Dizin Gizliliği” (Directory Privacy) aracı bu iş için idealdir.
- cPanel’de “Dizin Gizliliği” menüsünü açın.
public_html/stagingdizinini bulun, düzenle deyin.- “Bu dizin için şifre korumasını etkinleştir” kutusunu işaretleyin.
- Ekip arkadaşlarınızla paylaşabileceğiniz bir kullanıcı adı ve güçlü bir şifre belirleyin.
Artık staging adresine girmek isteyen herkes önce bu parolayı girmek zorunda kalacak. Bu, hem güvenlik hem de SEO açısından oldukça etkili bir katmandır.
2. Arama motorlarına staging’i indekslememelerini söyleyin
WordPress kontrol panelinizden:
- Ayarlar → Okuma menüsüne gidin.
- “Arama motorlarının bu siteyi indekslemesini engelle” seçeneğini işaretleyin.
- Değişiklikleri kaydedin.
Bu ayar, robots.txt ve meta etiketler üzerinden arama motoru botlarına “lütfen bu siteyi indeksleme” mesajını verir. Yine de garantiye almak için robots.txt dosyanıza staging alt alan adında Disallow: / kuralı eklemeniz de iyi bir fikirdir.
3. SSL, güvenlik ve güncelleme politikaları
Staging ortamınız da sonuçta gerçek bir WordPress kurulumu. Bu nedenle:
- SSL sertifikasının düzgün çalıştığından emin olun.
- Temel güvenlik sertleştirme adımlarını staging’de de uygulayın. Bunun için WordPress güvenlik sertleştirme kontrol listemizden yararlanabilirsiniz.
- cPanel tarafında da gereksiz servisleri kapatmak, güçlü şifreler ve 2FA kullanmak için cPanel güvenlik sertleştirme rehberimizi dikkate alın.
Staging Ortamında Çalışma: Test, Optimizasyon ve Onay Süreci
Artık staging ortamınız kuruldu ve güvenli hale getirildi. Şimdi asıl amaç olan “rahat rahat deneme yapma” kısmına geçebiliriz.
1. Güncelleme ve değişiklikleri staging’de uygulayın
Canlı sitede uygulamak istediğiniz tüm değişiklikleri önce staging’de deneyin:
- WordPress çekirdek güncellemeleri
- Tema ve eklenti güncellemeleri
- Yeni eklenti kurulumu
- Tema değişikliği veya tasarım revizyonu
- Özelleştirilmiş kod (functions.php, özel eklenti vb.)
Her değişiklikten sonra özellikle form gönderimleri, ödeme akışları, üyelik süreçleri gibi kritik işlevleri detaylı test etmeyi unutmayın.
2. Performans ve cache ayarlarını staging’de inceleyin
Sunucu tarafı optimizasyonlarını, cache yapılandırmalarını ve veritabanı ayarlarını da staging üzerinde deneyebilirsiniz. Örneğin:
- PHP versiyonunuzu yükseltmek
- OPcache, Redis, Memcached gibi bileşenleri devreye almak
- MySQL/MariaDB ayarlarını iyileştirmek
Bu tip ayarların WordPress’e etkisini merak ediyorsanız, WordPress için sunucu tarafı optimizasyon rehberimizde birçok pratik örnek bulabilirsiniz.
3. Geliştirme ekibiyle ortak bir staging süreci kurgulayın
Özellikle ajanslar, freelance geliştiriciler veya şirket içi yazılım ekipleriyle çalışıyorsanız, staging ortamı iş akışınızın merkezinde olmalıdır. DCHost blogda detaylı anlattığımız WordPress’te geliştirme–staging–canlı yolculuğu rehberinde de vurguladığımız gibi, her değişiklik staging’de test edilip onaylandıktan sonra canlıya alınmalıdır. Böylece hem geliştirici ekip hem de iş birimi tarafı, canlıya çıkmadan önce aynı ortam üzerinde test ve onay verebilir.
Staging’den Canlı Siteye Güvenli Yayına Alma Stratejileri
Staging’de her şey yolunda görünüyor; peki sırada ne var? Şimdi bu değişiklikleri güvenli ve mümkünse kesintisiz şekilde canlı ortama taşımanız gerekiyor. Burada izleyeceğiniz yol, sitenizin türüne ve değişikliklerin kapsamına göre değişebilir.
1. Sadece dosya değişikliği yapıldıysa (tema/eklenti güncellemesi vb.)
Eğer staging ortamında sadece dosya düzeyinde değişiklikler yaptıysanız (örneğin bir tema güncellemesi, CSS düzenlemesi, yeni bir eklenti kurulumu) ve canlı veri (yazılar, siparişler, kullanıcılar) staging’de değişmediyse, genellikle şu strateji yeterli olur:
- Staging ortamındaki
wp-contentklasöründe değişen tema/eklenti dosyalarını canlı siteye kopyalayın. - Gerekirse küçük yapılandırma dosyalarını (örneğin belirli config dosyaları) senkronize edin.
- Canlı sitede veritabanına dokunmadan, sadece dosya değişikliklerini canlıya geçirirsiniz.
Bu senaryoda, canlı sitede veritabanı değişmediği için siparişler, üyelikler ve içerikler stabil kalır; sadece görünüm ve işlevsel katman güncellenmiş olur.
2. Veritabanı değişiklikleri yapıldıysa (yeni sayfalar, ayarlar, form yapıları vb.)
Eğer staging ortamında yeni sayfalar oluşturdunuz, sayfa yapıları değiştirdiniz veya kompleks eklentilerin ayarlarıyla oynadıysanız, iş biraz daha dikkatli olmayı gerektirir. Çünkü staging’deki veritabanı, staging kurulduğu andaki canlı veritabanının kopyasıdır; aradan geçen sürede canlı sitede yeni yorumlar, siparişler, üyelikler eklenmiş olabilir.
Basit bloglar veya az trafikli sitelerde bazen şu strateji uygulanır:
- Canlı siteyi kısa süreliğine bakım moduna alın.
- Canlı veritabanını tekrar staging’e çekip, gerekli değişiklikleri hızlıca staging’de yeniden uygulayın.
- Son oluşan staging veritabanını tekrar canlıya geri yükleyin.
Ancak yoğun sipariş alan e‑ticaret siteleri veya yüksek etkileşimli projelerde bu yöntem veri kaybına neden olabilir. Bu tip senaryolarda daha gelişmiş dağıtım stratejileri (örneğin selectif veritabanı migrasyonu, ilgili tabloların ayrı taşınması, canary dağıtımı vb.) tercih edilir. DCHost blogda, bu konuyu daha derinlemesine ele aldığımız sıfır kesinti dağıtım ve staging yazılarına da göz atabilirsiniz.
3. Dosya + veritabanı birlikte taşınacaksa
Kimi zaman staging’de hem tema/eklenti dosyalarını hem de veritabanını değiştirmeniz gerekir. Örneğin:
- Yeni bir sayfalar bütünü tasarladınız (Ödeme akışı, kampanya sayfaları vb.)
- Form eklentinizi tamamen yenilediniz ve formları baştan kurdunuz.
- Çok dilli yapı (multilingual) veya WooCommerce yapılandırmasına dair ciddi değişiklikler yaptınız.
Bu durumlarda canlıya geçiş için güvenli bir yol haritası oluşturun:
- Canlı site ve staging ortamı için anlık tam yedek alın.
- Canlı siteyi kısa süreliğine bakım moduna alın (“bakım sayfası” veya özel bir uyarı ekranı ile).
- Staging veritabanını canlıya import edin (önce mevcut veritabanının yedeğini aldığınızdan emin olun).
- Staging’deki dosyalarla canlı sitedeki dosyaları senkronize edin.
- Bakım modunu kaldırmadan önce siteyi kapsamlı test edin.
Gerektiğinde, aldığınız yedeklerden hızlıca geri dönüş yapabilmek için 3-2-1 yedekleme prensibini öneriyoruz; bunun için 3-2-1 yedekleme stratejisi rehberimiz güzel bir referans olacaktır.
DCHost Üzerinde WordPress Staging Ortamı Kurarken Dikkat Edilecek Noktalar
DCHost altyapısında WordPress çalıştırırken staging ortamlarını verimli kullanmanız için birkaç pratik öneriyi toparlayalım.
Aynı hesapta birden fazla staging ortamı
Özellikle ajanslar ve geliştiriciler, tek bir DCHost hesabı üzerinde onlarca staging ortamı kurabiliyor. Bu durumda:
- Her proje için anlamlı alt alan adları kullanın (
proje1-staging.domain.com,clientx-test.domain.comgibi). - Disk kullanımını düzenli takip edin; eski staging ortamlarını arşivleyin veya silin.
- PHP versiyonlarını proje bazında ayarlayarak (MultiPHP Manager vb.) farklı versiyonları test edin.
Kaynak yoğun testler için VPS veya dedicated çözümler
Load test, yüksek trafiği simüle etme, ağır sorguların ve büyük veritabanı migrasyonlarının denemesi gibi senaryolarda paylaşımlı hosting limitlerine takılmamak için staging ortamınızı DCHost VPS veya fiziksel sunucu altyapısına taşımanız daha uygun olabilir. Böylece hem canlı siteyi hem de staging ortamını izole etmiş, testler sırasında canlı kullanıcı deneyimini etkilememiş olursunuz.
Güvenlik politikanızı staging’e de aynen uygulayın
Staging ortamında “nasıl olsa test” diyerek güvenlik önlemlerini gevşetmek, saldırganlara gereksiz bir kapı aralamak demektir. Canlı sitede uyguladığınız:
- Güçlü parola politikaları
- İki faktörlü kimlik doğrulama (2FA)
- Güncel WordPress çekirdeği, tema ve eklentiler
- Güvenlik eklentisi veya WAF kuralları
gibi önlemleri staging ortamında da uygulamayı ihmal etmeyin.
Sonuç ve Önerilen Yol Haritası
WordPress staging ortamı, özellikle siteniz iş kritik bir rol oynuyorsa artık bir “lüks” değil, neredeyse zorunlu bir gereklilik. cPanel üzerinde alt alan adı açarak, canlı sitenizin dosya ve veritabanını bu alt alan adına klonladığınızda; güncelleme, tasarım değişikliği, performans optimizasyonu ve güvenlik iyileştirmelerini rahatça deneyebileceğiniz güvenli bir oyun alanı elde etmiş olursunuz.
Özetlemek gerekirse yol haritanız kabaca şöyle olabilir:
- DCHost hesabınızda staging için bir alt alan adı oluşturun ve SSL kurun.
- Canlı sitenizin eksiksiz yedeklerini alın.
- WordPress dosya ve veritabanını staging dizinine kopyalayın, wp-config.php ve URL ayarlarını güncelleyin.
- Staging ortamını mutlaka parola ile koruyun ve arama motorlarından gizleyin.
- Tüm değişiklikleri staging’de test ettikten sonra, uygun stratejiyle canlıya güvenli geçiş yapın.
Eğer hangi hosting türünün staging senaryonuza daha uygun olduğuna karar veremiyorsanız veya karmaşık bir e‑ticaret sitesinde sıfır kesinti dağıtım akışı tasarlamak istiyorsanız, DCHost ekibi olarak mimari tasarımdan kapasite planlamasına kadar yanınızdayız. Mevcut sitenizi DCHost altyapısına taşıyıp, staging ortamı kurulumunu da birlikte planlamak isterseniz, destek ekibimizle iletişime geçmeniz yeterli.
Doğru kurgulanmış bir staging süreci, “güncelleme korkusunu” ortadan kaldırır ve WordPress sitenizi daha özgüvenli, kontrollü ve sürdürülebilir şekilde yönetmenizi sağlar. Bundan sonra büyük bir değişiklik yapmadan önce, önce staging’de denemeden canlıya dokunmamanızı şiddetle tavsiye ediyoruz.
