Teknoloji

WordPress’i Localhost’tan Canlı Hostinge Taşımak

İçindekiler

WordPress’i Localhost’tan Canlı Hostinge Neden Doğru Şekilde Taşımak Şart?

WordPress projelerinin büyük kısmı laptopta, bir localhost ortamında başlar. Geliştirirken her şey sorunsuz çalışır; ancak sıra siteyi gerçek alan adınızla canlıya almaya geldiğinde işler karışır: URL’ler bozulur, görseller çıkmaz, SSL nedeniyle tarayıcı “güvenli değil” uyarısı verir, Google arama sonuçlarınız dalgalanır. Bu tablo aslında teknik olarak kaçınılmaz değil; sadece plansız taşımaların doğal sonucu.

Bu rehberde, WordPress’i localhost’tan DCHost üzerindeki canlı hostinge URL değişimi, SSL/HTTPS geçişi ve SEO kaybını en aza indirecek şekilde nasıl taşıyabileceğinizi adım adım anlatacağız. Veritabanını ve dosyaları doğru taşıma, localhost adreslerini alan adıyla değiştirme, 301 yönlendirmeleri, kararlı SSL kurulumları ve Google tarafındaki ayarları tek bir yol haritasında toplayacağız. Amacımız, hem geliştiricilerin hem ajansların hem de kendi sitesini yöneten işletme sahiplerinin, “taşıma” kelimesini duyar duymaz stres yaşamamasını sağlamak.

Eğer hosting, domain ve DNS kavramları kafanızı karıştırıyorsa, önce domain, DNS, sunucu ve SSL’in birlikte nasıl çalıştığını anlattığımız rehbere göz atmanız da faydalı olabilir. Böylece bu yazıdaki teknik adımlar daha anlamlı hale gelecektir.

Taşıma Öncesi Hazırlık: Yapmadan Başlarsanız Mutlaka Pişman Olacağınız 7 Kontrol

Başarılı bir WordPress taşımasının yarısı, aslında taşıma öncesi hazırlıktır. Localhost’tan canlıya geçerken aşağıdaki noktaları netleştirmeniz, sizi çoğu sorundan korur.

1. Alan adınız ve hosting planınız hazır mı?

Önce nereye gideceğinizi bilmeniz gerekiyor. Canlı ortamda kullanacağınız:

DCHost üzerinde hangi planı seçerseniz seçin, PHP sürümü, veritabanı (MySQL/MariaDB), disk alanı ve trafik limitlerinin WordPress için yeterli olduğundan emin olun. Çok küçük bir projeden e-ticaret seviyesine kadar ölçeklenebilir bir yapı düşünüyorsanız, ileride yükseltme yapabileceğiniz bir plan seçmeniz mantıklıdır.

2. Localhost URL’nizi biliyor musunuz?

Çoğu geliştirici taşıma sırasında en çok burada takılıyor. Localhost ortamınızda WordPress genelde şu adreslerden biriyle çalışıyordur:

  • http://localhost/
  • http://localhost/projeadi/
  • http://127.0.0.1/proje/
  • Yerel bir sanal host (ör. http://ornek.local/)

Bu bilgi önemli; çünkü veritabanında bu eski adresin tamamını yeni alan adınızla değiştireceğiz. Birden fazla local URL kullandıysanız (ör. önce /test/ klasörü, sonra /proje/), hepsini not edin.

3. Canlıda hangi URL yapısını kullanacaksınız?

Localhost’ta bazen şöyle adresler görürsünüz: http://localhost/proje/?p=123. Canlıda ise https://www.orneksite.com/blog/wordpress-tasima gibi SEO dostu kalıcı bağlantılar (permalink) isteyeceksiniz. Aşağıdakileri önceden kararlaştırın:

  • www kullanacak mısınız? (www.orneksite.com mu, yoksa sadece orneksite.com mu?)
  • Alt dizin mi kullanacaksınız? (orneksite.com/blog/ gibi)
  • Kalıcı bağlantı yapınız ne olacak? (ör. /%postname%/ veya /blog/%postname%/)

Bu kararlar, hem URL aramalarında hem de 301 yönlendirme kurallarında kullanılacak.

4. SSL/HTTPS zorunlu mu, ne zaman aktif edilecek?

Yeni projelerde HTTP kullanmak için hiçbir sebep yok. En baştan HTTPS ile yayına çıkmak hem güvenlik hem SEO için avantaj sağlar. DCHost üzerindeki birçok planda otomatik SSL (örneğin Let’s Encrypt benzeri çözümler) dakikalar içinde devreye alınabilir. Ayrıntılı bir adım istiyorsanız, alan adı, DNS ve SSL’i adım adım anlattığımız rehberde canlı örnekleriyle gösteriyoruz.

5. Localhost’ta yedek aldınız mı?

Taşımaya başlamadan önce mutlaka:

  • WordPress dosyalarının tamamını (wp-content dahil) yedekleyin.
  • phpMyAdmin veya benzeri bir araçla tüm veritabanını dışa aktarın.

Profesyonel projelerde ayrıca versiyon kontrolü (Git), staging ortamı ve otomatik yedek politikasını da devreye almak güvenli bir yaklaşımdır. DCHost blogunda, WordPress için otomatik yedekleme ve geri yükleme stratejilerini ayrıca anlattık; taşıma sonrası mutlaka göz atmanızı öneririz.

6. DNS ve nameserver geçiş zamanlamasını planladınız mı?

DNS değişiklikleri anında devreye girmez; genellikle 5 dakika ile 24 saat arasında yayılır. Eğer sıfıra yakın kesinti istiyorsanız, zero-downtime taşıma için TTL stratejileri rehberimizde anlattığımız şu iki adıma dikkat edin:

  • Taşıma öncesi TTL değerlerini düşürün (ör. 300 sn).
  • Taşıma tamamlanınca yeni IP’ye yönlendirin.

Bu sayede çoğu ziyaretçi için kesinti süresini dakikalar seviyesinde tutabilirsiniz.

7. Farklı bir alan adına mı geçiyorsunuz?

Eğer localhost → canlı yerine, mevcut bir siteden tamamen farklı bir alan adına geçiyorsanız (ör. deneme.com → markaisim.com), işin SEO kısmı daha kritik hale gelir. Böyle durumlarda yalnızca WordPress taşıma teknikleri yetmez; alan adı değiştirirken SEO kaybını önleme rehberimizi de mutlaka sürece dahil edin.

Adım Adım: WordPress’i Localhost’tan DCHost Üzerindeki Canlı Hostinge Taşıma

Burada en sık kullanılan ve en kontrollü yöntem olan manuel taşıma akışını anlatacağız. Farklı “migration” eklentileri de mevcut; ancak işin mantığını bir kez kavradığınızda, hangi aracı kullanırsanız kullanın ne yaptığınızı bilerek ilerlemiş olursunuz.

1. Localhost ortamınızı analiz edin

Önce aşağıdaki bilgileri netleştirin ve bir yere not edin:

  • Localhost veritabanı adı, kullanıcı adı ve şifresi
  • WordPress kurulu dizin (ör. C:xampphtdocsproje)
  • Şu anki Site Adresi (URL) ve WordPress Adresi (URL) (wp-admin > Ayarlar > Genel ekranından görebilirsiniz)

Ayrıca PHP sürümü ile canlı sunucudaki PHP sürümünün uyumluluğunu da kontrol edin. Eski bir PHP sürümünden daha yeni bir sürüme geçerken bazı eklentiler sorun çıkarabilir; bunu önden yakalamak en sağlıklısıdır.

2. Veritabanını dışa aktarın

Localhost ortamınızda genellikle phpMyAdmin veya benzeri bir arayüz kullanırsınız. Adımlar kısaca şöyle:

  1. phpMyAdmin’e girin.
  2. WordPress sitenizin veritabanını seçin.
  3. Üst menüden Dışa Aktar (Export) sekmesini tıklayın.
  4. Yöntem olarak “Hızlı” ve biçim olarak “SQL” seçili olsun.
  5. “Git” diyerek SQL dosyasını bilgisayarınıza indirin.

İleri seviye kullanıcılar, komut satırından mysqldump ile de yedek alabilir. Önemli olan, veritabanının eksiksiz ve hatasız dışa aktarılmış olması.

3. WordPress dosyalarını hazırlayın

Localhost’taki WordPress dizininizi açın ve şu klasör ve dosyaları kopyalayın:

  • wp-admin
  • wp-includes
  • wp-content
  • Kök dizindeki tüm .php dosyaları (index.php, wp-config.php hariç olmak üzere diğer çekirdek dosyalar)

wp-config.php dosyasını ayrı bir kopya olarak saklayın; çünkü içinde yalnızca veritabanı bilgileri değil, bazı özel ayarlar, güvenlik anahtarları ve debug parametreleri de olabilir. Canlı ortamda yeni bir wp-config oluşturup, localhost’taki kritik satırları kontrollü şekilde taşımanız daha güvenlidir.

4. Dosyaları DCHost sunucusuna yükleyin

DCHost kontrol panelinizden:

  • Alan adınızın kök dizinini (genellikle public_html veya httpdocs) bulun.
  • İsterseniz aynı yapıyı alt dizinde kurabilirsiniz (ör. public_html/blog).

Dosya yüklemek için tavsiyemiz SFTP kullanmanız; klasik FTP güvenlik ve bütünlük açısından zayıftır. Bu konuyu ayrıntılı ele aldığımız “FTP yerine SFTP kullanmanın zamanı geldi” rehberimize göz atarak, bağlantılarınızı daha güvenli hale getirebilirsiniz.

Localhost’tan kopyaladığınız WordPress dosyalarını SFTP ile bu dizine yükleyin.

5. Canlı veritabanını oluşturun

DCHost kontrol panelinizden yeni bir MySQL/MariaDB veritabanı ve kullanıcı oluşturun:

  • Veritabanı adı
  • Kullanıcı adı
  • Güçlü bir şifre

Ardından phpMyAdmin veya paneldeki veritabanı yöneticisinden:

  1. Yeni oluşturduğunuz veritabanını seçin.
  2. “İçe Aktar (Import)” sekmesine tıklayın.
  3. Localhost’tan aldığınız .sql dosyasını seçin.
  4. İçe aktarma işlemini başlatın.

İşlem tamamlandığında veritabanı tablolarının listelendiğini görmelisiniz. Hata alıyorsanız, dosya boyutu limitleri veya karakter seti ayarlarına bakmanız gerekebilir.

6. Yeni wp-config.php dosyasını hazırlayın

Sunucudaki WordPress dizininizdeki wp-config-sample.php dosyasını wp-config.php olarak kopyalayın ve düzenleyin. İçindeki şu bölümü canlı veritabanı bilgilerinizle doldurun:

define('DB_NAME', 'canli_veritabani_adi');
define('DB_USER', 'canli_kullanici_adi');
define('DB_PASSWORD', 'guclu_sifre');
define('DB_HOST', 'localhost'); // Çoğu shared hosting'de localhost kalır

Localhost’taki eski wp-config içinden, özellikle şu satırları da gerekiyorsa dikkatle taşıyın:

  • Özel tablo prefix’i ($table_prefix)
  • AUTH_KEY, SECURE_AUTH_KEY vb. güvenlik anahtarları (taşımak oturumların geçerliliğini korur)
  • WP_DEBUG ve benzeri ayarlar (canlıda genelde kapatılmalıdır)

7. Localhost URL’lerini geçici olarak güncelleyin (isteğe bağlı ama faydalı)

İki yol izleyebilirsiniz:

  • Yol A: Önce veritabanında URL’leri yeni alan adınızla değiştirir, sonra siteyi canlıya alırsınız.
  • Yol B: Önce siteyi canlıya alır, sonra WP-CLI veya eklenti ile URL değişimini yaparsınız.

Genellikle Yol A daha öngörülebilir sonuç verir. Bir sonraki başlıkta, URL değiştirme adımını detaylı anlatacağız.

URL Değişimi: Localhost Adreslerinden Gerçek Alan Adına Geçiş

WordPress, URL’leri yalnızca bir iki yerde değil; yazı iç linklerinde, menülerde, widget’larda, seri hale getirilmiş (serialized) verilerde saklar. Bu nedenle saf SQL “Bul-Değiştir” bazen sorun çıkarabilir. Yine de doğru yapıldığında en pratik çözümlerden biridir.

1. siteurl ve home değerlerini güncelleyin

Önce veritabanındaki temel URL alanlarını değiştirin. phpMyAdmin’de SQL sekmesine girip, aşağıdaki sorguları yeni alan adınıza göre düzenleyerek çalıştırabilirsiniz:

UPDATE wp_options 
SET option_value = 'https://www.orneksite.com' 
WHERE option_name IN ('siteurl', 'home');

Tablo önekiniz (prefix) wp_ değilse, sorgudaki tablo adını kendi önekine göre değiştirin (ör. wp123_options gibi).

2. Tüm içerikte URL arama-değiştirme

Sırada içerik, menü, widget ve kısa yolların (shortcode) içinde geçen localhost URL’lerini değiştirmek var. Burada üç yaklaşım var:

  • WP-CLI ile search-replace
  • Serialized veriyi düzgün yöneten bir PHP script veya araç kullanmak
  • Güvenilir bir migration/search-replace eklentisi kullanmak

WP-CLI erişiminiz varsa, kök dizinde şu komutu çalıştırabilirsiniz:

wp search-replace 'http://localhost/proje' 'https://www.orneksite.com' --skip-columns=guid

guid sütununu genelde değiştirmeyiz; RSS okuyucular için benzersiz tanımlayıcıdır. Eğer komut satırına erişiminiz yoksa, serialized verileri bozmayan bir search-replace aracı kullanmanız gerekir; basit “Find & Replace” yapan script’ler, özellikle widget ve tema ayarlarında sorun yaratabilir.

3. Medya dosyalarının yollarını kontrol edin

Taşıma sonrası en sık görülen hata: sayfalar açılır ama görsellerin bir kısmı 404 verir. Bunun tipik sebepleri:

  • wp-content/uploads klasörü eksik veya yanlış yüklenmiş
  • Uploads klasör yapısı farklı (ör. yıl/ay klasörleri)
  • Veritabanında kalan eski localhost yol referansları

Medya kütüphanesinden rastgele birkaç görsele tıklayıp, dosya URL’lerinin yeni alan adınızla göründüğünü kontrol edin. Gerekirse search-replace adımını yalnızca wp_posts ve wp_postmeta tablolarında tekrar çalıştırabilirsiniz.

4. Kalıcı bağlantıları (permalink) yenileyin

WordPress yönetim paneline (https://www.orneksite.com/wp-admin) giriş yapabildiğinizde:

  1. Ayarlar > Kalıcı Bağlantılar menüsüne girin.
  2. İstediğiniz URL yapısını seçin (çoğu sitede /%postname%/ idealdir).
  3. “Değişiklikleri Kaydet” butonuna tıklayın.

Bu işlem, .htaccess içindeki rewrite kurallarını güncelleyerek 404 sorunlarının büyük kısmını çözer.

SSL ve HTTPS Geçişi: Tarayıcı Uyarılarını ve SEO Kaybını Önlemek

Artık siteniz yeni alan adında açılıyor; sırada HTTPS’e geçiş var. DCHost üzerinde ya otomatik Let’s Encrypt benzeri ücretsiz SSL kullanabilir, ya da kurumsal sertifikalarla daha gelişmiş çözümler üretebilirsiniz. Temel akış şu şekilde:

1. SSL sertifikanızı kurun

DCHost kontrol panelinizdeki SSL/TLS bölümünden alan adınız için sertifika talebi oluşturup, kurulumu tamamlayın. Adım adım ekran görüntüleri ve otomatik yenileme süreçlerini, Let’s Encrypt ile ücretsiz SSL sertifikası kurulum rehberimizde ayrıntılı şekilde anlattık.

2. WordPress adreslerinizi https:// olarak güncelleyin

wp-admin > Ayarlar > Genel ekranına gidip:

  • WordPress Adresi (URL)
  • Site Adresi (URL)

alanlarını https:// ile başlayan kesin adresinizle güncelleyin. Örnek:

https://www.orneksite.com

Ardından tekrar oturum açmanız istenebilir; bu normal.

3. Tüm http:// adreslerini https:// ile değiştirin

Site içinde “mixed content” (karışık içerik) uyarısı almamak için, veritabanındaki http://www.orneksite.com veya http://orneksite.com adreslerini https://... ile değiştirin. Yine WP-CLI veya serialized destekli search-replace araçları kullanabilirsiniz:

wp search-replace 'http://www.orneksite.com' 'https://www.orneksite.com' --skip-columns=guid

Bu değişim özellikle tema ayarları, sayfa builder verileri ve kısa kodlar içindeki medya linkleri için kritiktir.

4. 301 yönlendirmeleri ile HTTP’den HTTPS’e geçiş

Artık kimsenin sitenize HTTP üzerinden erişmesini istemiyoruz. .htaccess dosyanıza, WordPress kuralları başlamadan önce şu gibi bir yönlendirme ekleyebilirsiniz:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Bu sayede eski http:// istekleri kalıcı (301) olarak https:// sürüme yönlendirilir. SEO açısından da bu zorunludur; Google’a tek bir kanonik versiyon sunmuş olursunuz. Bu konuyu çok daha ayrıntılı merak ediyorsanız, HTTP’den HTTPS’e geçiş rehberimizde HSTS ve güvenlik başlıklarıyla birlikte ele aldık.

5. Mixed content hatalarını temizleyin

Tarayıcı konsolunda (F12 > Console) “mixed content” uyarıları görüyorsanız, bazı CSS, JS veya görseller hâlâ http:// ile çağrılıyordur. Bunları tespit etmek için:

  • Kaynağı görüntüleyip (View Source) arama yapın.
  • Tarayıcı konsolundaki uyarıların satır numaralarını takip edin.
  • Gerekirse tema/eklenti ayarlarında manuel düzenleme yapın.

Bu aşama bittiğinde, tarayıcı adres çubuğunda kilit simgesi ve “Güvenli” ibaresini görmeniz gerekir.

SEO Kayıpsız Geçiş İçin Yol Haritası

Localhost’tan ilk kez canlıya geçiyorsanız SEO kaybı değil, aslında bir “SEO kazanımı” sürecindesiniz. Ancak mevcut bir canlı siteden yeni alan adına veya büyük URL değişikliklerine gidiyorsanız, işleri daha dikkatli yürütmek gerekiyor.

1. Aynı alan adı, sadece HTTP → HTTPS ve localhost → canlı geçiş

Eğer:

  • İlk kez yayına çıkıyorsanız veya
  • Önceden index almamış bir test alanından esas alanınıza geçiyorsanız

SEO tarafında büyük bir risk yok. Yine de:

  • Tüm HTTP isteklerini 301 ile HTTPS’e yönlendirin.
  • Google Search Console’da hem http hem https için mülk açtıysanız, HTTPS sürümü esas alın.
  • XML site haritasını (sitemap) güncelleyip Search Console’a tekrar gönderin.

Site hızınız, TTFB, Core Web Vitals metrikleri de SEO için önemli; bu konuları DCHost tarafında “yeni web sitesi yayına alırken hosting tarafında SEO ve performans kontrol listesi” rehberimizde ayrıntılı inceledik.

2. Farklı bir alan adına geçiş yapıyorsanız

Burada asıl kritik olan iki şey var:

  • Eski alan adınızdan yeni alan adınıza kusursuz 301 yönlendirme
  • Google’a bu değişimi net şekilde anlatmak

Özet başlıklar halinde:

  • Eski sitedeki her bir URL’yi, yeni sitedeki birebir karşılığına 301 yönlendirin.
  • Eski domain için Google Search Console’da Adres Değişikliği aracını kullanın.
  • Hem eski hem yeni domain için XML sitemap’leri güncel tutun.
  • Eski domaini tamamen kapatmayın; en az birkaç ay 301 yönlendirmeleriyle ayakta kalsın.

Bunların tamamını, örneklerle birlikte “Alan adı değiştirirken SEO kaybetmemek” rehberinde ayrıntılandırdık. Localhost’tan canlıya geçişe ek olarak alan adı da değişiyorsa, iki rehberi birlikte okumanızı öneririz.

3. Kanonik adres (canonical) ve www seçimi

Google açısından https://orneksite.com ile https://www.orneksite.com farklı sitelerdir. Birini “asıl sürüm” olarak seçip diğerini 301 ile ona yönlendirin. Ardından:

  • Yoast, Rank Math vb. SEO eklentilerinde kanonik ayarını kontrol edin.
  • Şablonlarınızda <link rel=”canonical”> etiketinin doğru URL’yi gösterdiğinden emin olun.

Bu, kopya içerik sorunlarını ve otoritenin dağılmasını önler.

4. Robots.txt, sitemap ve Search Console

  • robots.txt: Geliştirme sürecinde engellediğiniz (disallow) yollar varsa, canlıda kaldırın.
  • XML sitemap: SEO eklentinizin oluşturduğu sitemap’in artık yeni alan adınızı ve HTTPS adreslerinizi içerdiğini kontrol edin.
  • Search Console: Yeni alan adınızı ve HTTPS sürümünü ayrı bir mülk olarak ekleyin, sitemap’i tanımlayın.

Bunlar, Google’ın yeni yapınızı daha hızlı ve kontrollü şekilde tarayıp dizine eklemesini sağlar.

DNS, Nameserver ve Yayına Alma Zamanlaması

WordPress dosyalarınız ve veritabanınız hazır, URL değişimlerini yaptınız, HTTPS’i kurdunuz. Sırada alan adınızı bu yeni ortama bağlamak var. Burada da iki temel adım var: nameserver ayarı ve DNS kayıtları.

1. Alan adınızı DCHost’a yönlendirmek

Alan adınızı aldığınız kayıt operatörünün panelinde, nameserver alanına DCHost tarafından verilen NS adreslerini girmeniz gerekir. Bu işlem sonrası DNS’ler yavaş yavaş DCHost’a taşınır. Detaylı ekran görüntüleri ile adım adım anlatımı, “yeni aldığınız alan adını hosting hesabına bağlama” rehberimizde bulabilirsiniz.

2. A ve AAAA (IPv6) kayıtlarını doğru IP’ye yönlendirmek

Nameserver’lar DCHost’a geçtikten sonra sıra, alan adınızın hangi IP adresine gideceğini söyleyen A (ve varsa AAAA) kayıtlarını tanımlamaya gelir. Temel mantığı kısaca:

  • A kaydı → IPv4 adresiniz (ör. 192.0.2.10)
  • AAAA kaydı → IPv6 adresiniz

Detaylı bir DNS kayıtları özeti için, A, AAAA, CNAME, MX, TXT ve SRV kayıtlarını anlattığımız DNS rehberimize göz atabilirsiniz. Özellikle e-posta altyapısı da aynı alan adında çalışıyorsa, MX ve SPF kayıtlarını da doğru taşımanız gerekir.

3. TTL stratejisi ile kesintiyi azaltmak

Taşıma öncesinde DNS TTL değerlerinizi yüksekten (ör. 14400 sn) daha düşük bir değere (ör. 300 sn) çektiyseniz, şimdi meyvesini yiyeceksiniz. A kaydını yeni IP’ye çektiğinizde, ziyaretçilerin büyük çoğunluğu birkaç dakika içinde yeni sunucuya düşecektir. Bu konuyu pratik örneklerle, zero-downtime TTL stratejileri rehberimizde ayrıntılı anlattık.

Canlıya Geçiş Sonrası Kontroller ve Sık Görülen Sorunlar

DNS’ler oturdu, site yeni alan adında ve HTTPS ile açılıyor. Şimdi hem teknik hem SEO açısından son kontrolleri yapmanın zamanı.

1. Temel fonksiyon testi

  • Ana sayfa ve birkaç alt sayfanın açılıp açılmadığını kontrol edin.
  • Menü linklerinin kırık (404) üretmediğinden emin olun.
  • Görsellerin, PDF dosyalarının, CSS ve JS dosyalarının düzgün yüklendiğini test edin.
  • İletişim formu, üyelik, yorum ve ödeme adımları (varsa) çalışıyor mu, test edin.

2. Hata loglarını takip edin

Taşıma sonrası ilk 24–48 saatte, sunucu loglarını takip etmek çok işe yarar. Özellikle:

  • PHP hata logları
  • Web sunucusu erişim ve hata logları (Apache/Nginx)

DCHost blogunda Apache ve Nginx loglarıyla 4xx–5xx hatalarını teşhis etmeyi anlattığımız rehberimiz, burada çok işinize yarayacaktır.

3. Performans ve önbellek ayarları

Localhost’ta site size hep hızlı görünür; çünkü genellikle tek kullanıcı sizsiniz ve ağ gecikmesi yoktur. Canlıya geçince:

  • Bir önbellek eklentisi veya sunucu taraflı önbellek mekanizması kullanmayı düşünün.
  • GZIP/Brotli sıkıştırmasını ve HTTP/2 veya HTTP/3 desteğini etkinleştirin.
  • PHP-FPM, OPcache, veritabanı ayarlarını trafiğe göre optimize edin.

DCHost tarafında WordPress performansını artırmaya yönelik birçok rehberimiz var; özellikle WordPress için sunucu tarafı optimizasyon rehberi ile başlayabilirsiniz.

4. Güvenlik kontrolleri

Canlıya alınan her WordPress sitesi için minimum güvenlik adımları:

  • Güçlü yönetici şifreleri, mümkünse 2FA (iki faktörlü doğrulama)
  • Güncel çekirdek, tema ve eklentiler
  • Gereksiz eklentilerin kaldırılması
  • Temel WAF ve brute-force korumaları

Özellikle paylaşımlı hosting üzerinde çalışıyorsanız, paylaşımlı hosting’de WordPress güvenliği rehberimiz bu konuda iyi bir kontrol listesi sunuyor.

DCHost Üzerinde Hangi Hosting Türü Bu Senaryoya Daha Uygun?

Localhost’tan canlıya geçen projelerde kaynak ihtiyacı her zaman aynı değildir. DCHost tarafında tipik senaryolar şöyle:

  • Kişisel blog, kurumsal tanıtım sitesi: Paylaşımlı hosting veya WordPress için optimize edilmiş bir paket genellikle yeterlidir. SSD/NVMe disk ve güncel PHP sürümü büyük fark yaratır.
  • Küçük–orta ölçekli WooCommerce mağazası: CPU ve RAM ihtiyacı arttığı için, yüksek kaynaklı paylaşımlı paketler veya yönetilen VPS çözümleri daha sağlıklıdır.
  • Yüksek trafikli içerik siteleri, ajans projeleri: VPS veya dedicated sunucu ile kaynakları ayırmak, özel önbellek ve veritabanı ayarları yapmak mantıklıdır.
  • Kritik kurumsal projeler, fintech, LMS vb.: Yüksek erişilebilirlik (HA), yedekli disk ve gelişmiş güvenlik gerektiren durumlarda dedicated ve colocation çözümleri ile daha esnek senaryolar kurulabilir.

Özetle, localhost’ta prototipini yaptığınız her WordPress sitesi, DCHost tarafında uygun bir yere oturabilir; önemli olan trafiği, büyüme planınızı ve iş kritik seviyesini doğru analiz etmek.

Özet ve Yol Haritası: Localhost’tan Canlıya Stres Değil, Rutine Dönsün

WordPress’i localhost’tan canlı hostinge taşımak gözünüzde büyüyorsa, sebebi çoğu zaman sürecin dağınık görünmesidir. Aslında yaptığımız şey oldukça net: dosyaları ve veritabanını güvenle aktarmak, localhost URL’lerini yeni alan adınızla değiştirmek, SSL/HTTPS’i doğru kurmak ve Google’a bu yeni yapıyı düzgün anlatmak. Bunu bir kez sistematik biçimde yaptığınızda, sonraki projelerinizde taşıma işi birkaç saatlik, öngörülebilir bir rutine dönüşür.

Bu rehberde; taşıma öncesi hazırlık, manuel dosya ve veritabanı aktarımı, URL değişimi, SSL ve HTTPS’e geçiş, SEO kaybını önleme ve DNS/TTL stratejilerini aynı akışta topladık. Artık elinizde, hem küçük bir blogu hem de ciddi bir kurumsal siteyi localhost’tan DCHost üzerindeki canlı ortama taşıyabilecek net bir kontrol listesi var. Bir sonraki adımda, projenizin ölçeğine uygun bir DCHost planı seçip bu adımları kendi sitenize uygulayabilirsiniz.

Tüm adımları uygularken takıldığınız noktalar olursa, DCHost ekibi olarak destek taleplerinizde teknik detayları birlikte gözden geçirmeye her zaman hazırız. WordPress sitenizi güvenli, hızlı ve SEO dostu şekilde canlıya almak için doğru altyapı ve doğru planlama bir araya geldiğinde, taşıma kelimesi artık korkutucu değil, keyifli bir son adım haline gelir.

Sıkça Sorulan Sorular

En güvenli yaklaşım, WordPress’i manuel olarak taşıyıp her adımı kontrol etmektir. Önce localhost ortamında tam dosya ve veritabanı yedeği alırsınız. Ardından DCHost üzerinde boş bir veritabanı oluşturup, localhost’tan dışa aktardığınız SQL dosyasını içe aktarırsınız. WordPress çekirdek dosyalarını ve wp-content klasörünü SFTP ile sunucuya yükler, yeni wp-config.php dosyasında canlı veritabanı bilgilerini tanımlarsınız. Sonrasında veritabanında localhost URL’lerini yeni alan adınızla değiştirip kalıcı bağlantıları yenilersiniz. En son SSL/HTTPS’i kurar, 301 yönlendirmeleri ve temel SEO ayarlarını yaparsınız. Böylece neyin nerede değiştiğini bilerek ilerlediğiniz için, yaşanabilecek sorunları hızlıca teşhis edebilirsiniz.

WordPress veritabanında bazı alanlar serialized (seri hale getirilmiş) veri içerir; bu alanlarda basit bir “Bul-Değiştir” işlemi, veri uzunluğunu bozarak hatalara yol açabilir. Bu yüzden iki güvenli seçeneğiniz var: Birincisi, WP-CLI kullanarak search-replace komutu ile URL değişimi yapmak; bu araç serialized alanları da doğru şekilde günceller. İkincisi, serialized veriyi destekleyen güvenilir bir PHP script veya WordPress eklentisiyle arama-değiştirme yapmaktır. Hangi yolu seçerseniz seçin, işlem öncesi mutlaka tam veritabanı yedeği alın ve önce test/staging ortamında deneyip, canlıya öyle uygulayın. Böylece menü, widget ve tema ayarlarının bozulmasını önlersiniz.

Yeni bir site yayına alıyorsanız, HTTPS’i mümkün olduğunca en baştan, hatta ilk canlı testler sırasında devreye almak en sağlıklı yaklaşımdır. Önce DCHost üzerindeki kontrol panelden alan adınız için SSL sertifikanızı kurun (örneğin Let’s Encrypt tabanlı bir çözüm). Ardından WordPress Ayarları bölümünde site adresinizi https:// ile güncelleyin ve veritabanındaki http:// referanslarını https:// ile değiştirin. Son adımda .htaccess veya sunucu yapılandırması üzerinden tüm HTTP isteklerini 301 ile HTTPS’e yönlendirin. Bu sıralama; mixed content uyarılarını, tarayıcıdaki “güvenli değil” ibarelerini ve SEO tarafındaki karışıklıkları önemli ölçüde azaltır.

Eğer localhost’taki siteniz Google tarafından indexlenmemişse, aslında bir SEO kaybı değil, yeni bir kazanım dönemine giriyorsunuz demektir. Ancak daha önce farklı bir alan adında yayında olan bir siteyi yeni bir alan adına taşıyorsanız, doğru yapılmayan 301 yönlendirmeleri ve hatalı URL değişimleri sıralamalarınızda dalgalanma yaratabilir. Bunu önlemek için; eski domaininizden yeni domaininizdeki birebir URL’lere kalıcı (301) yönlendirme yapmalı, HTTPS’e tam geçişi sağlamalı, sitemap’i güncelleyip Google Search Console’da yeni alan adınızı tanıtmalısınız. Düzgün planlanmış bir geçişte, kısa vadeli küçük oynamalar olsa da orta vadede otoritenizin büyük bölümünü korursunuz.

Taşıma eklentileri, özellikle teknik bilgisi sınırlı kullanıcılar için pratik bir çözüm sunabilir; ancak büyük veritabanları, özel dizin yapıları veya kısıtlı PHP kaynakları olan sunucularda zaman zaman takılabilirler. Manuel yöntem ise biraz daha emek ister, fakat tam kontrol sağlar ve neyin nerede değiştiğini bildiğiniz için sorunları teşhis etmek kolaylaşır. Profesyonel ajans ve geliştirici ekipler genellikle çekirdek mantığı manuel taşımayla öğrenip, uygun buldukları yerlerde eklentileri hız kazandırmak için kullanıyor. Kritik projelerde, önce staging ortamında manuel veya eklentiyle deneme taşıması yapmak, ardından canlıya geçmek en risksiz yaklaşımdır.