WordPress Adresi ve Site Adresi: Teknik Farklılıklar, Yapılandırma ve Yaygın Tuzaklar

WordPress Address (URL) ve Site Address (URL), sırasıyla WordPress çekirdek dosyalarının sunucuda nerede bulunduğunu ve kullanıcıların sitenizin ön yüzüne ulaşmak için hangi URL’yi kullandığını kontrol eden iki ayrı yapılandırma parametresidir. Çoğu standart kurulumda her iki değer de aynıdır; ancak WordPress dosyalarını bir alt dizinde barındırırken siteyi kök etki alanından sunduğunuzda bu değerler farklılaşabilir — hatta bazen farklılaşmak zorunda kalır.

Bu iki değeri yanlış girmek, tek bir karakter hatası bile olsa, yönetici panosuna erişiminizi engelleyebilir, karma içerik uyarılarını tetikleyebilir, REST API uç noktalarını bozabilir ve yönlendirme zincirlerini çökertebilir. Aşağıdaki bölümler her bir ayarın arkasındaki mimari mantığı, bunları değiştirmenin meşru her senaryosunu ve bunu güvenli biçimde yapmanın tam yöntemlerini açıklamaktadır.

İki URL Parametresinin Arkasındaki Mimari Mantık

WordPress, URL yapılandırmasını eş zamanlı olarak iki yerde saklar: wp_options veritabanı tablosunda (siteurl ve home satırları) ve isteğe bağlı olarak PHP sabitleri aracılığıyla wp-config.php dosyasında. Herhangi bir şeye dokunmadan önce hangi kaynağın öncelikli olduğunu anlamak son derece önemlidir.

Öncelik sırası (en yüksekten en düşüğe):

1. wp-config.php içinde tanımlanan sabitler (WP_SITEURL, WP_HOME)
2. wp_options tablosunda saklanan değerler
3. Paneldeki Settings > General bölümüne girilen değerler

wp-config.php içinde bir sabit tanımlandığında, Settings > General bölümündeki ilgili alan salt okunur hale gelir ve gri görünür. Bu kasıtlıdır — programatik kontrole izin verirken kullanıcı arayüzü üzerinden yapılacak yanlışlıkla üzerine yazmaları önler.

WordPress Address (URL) — WP_SITEURL

WordPress Address, wp_options içindeki siteurl seçeneğine ve wp-config.php içindeki WP_SITEURL sabitine karşılık gelir. WordPress’e çekirdek PHP dosyalarının, wp-admin dizininin ve wp-includes dizininin fiziksel olarak nerede bulunduğunu söyler. WordPress bu değeri; yönetici giriş URL’si, AJAX uç noktaları (/wp-admin/admin-ajax.php) ve REST API tabanı (/wp-json/) dahil olmak üzere tüm dahili dosya yolu referanslarını oluşturmak için kullanır.

Örnek: WordPress kurulumunuz https://example.com/wordpress konumundaysa, WP_SITEURL değeri https://example.com/wordpress olmalıdır. https://example.com/wordpress/wp-admin adresine gidildiğinde panoya ulaşılır.

Site Address (URL) — WP_HOME

Site Address, wp_options içindeki home seçeneğine ve wp-config.php içindeki WP_HOME sabitine karşılık gelir. Kullanıcıların tarayıcılarına yazdığı adres ve WordPress’in tüm ön yüz kalıcı bağlantı yapılarını oluşturduğu taban olan kurallı genel URL’yi tanımlar.

Örnek: çekirdek dosyalar https://example.com/wordpress konumunda olsa bile, ana sayfanın, gönderilerin ve sayfaların kök etki alanından sunulması için WP_HOME değerini https://example.com olarak ayarlayabilirsiniz. Bu, kök dizinde ek bir index.php dosyası ve .htaccess kuralı gerektirir (aşağıda ele alınmaktadır).

Karşılaştırma: WordPress Address ile Site Address

Bu İki Değerin Farklı Olması Gereken Durumlar

WP_SITEURL ve WP_HOME değerlerini ayırmanın en yaygın meşru nedeni alt dizin kurulum düzenidir: WordPress dosyalarını temiz bir alt dizinde (örn. /wordpress veya /cms) izole etmek isterken genel sitenin kök etki alanında çözümlenmesini sağlamak. Bu kasıtlı bir mimari tercihtir, geçici bir çözüm değildir.

Bir veya her iki değerin güncellenmesini gerektiren diğer senaryolar:

• Alan adı geçişi — http://old-domain.com adresinden https://new-domain.com adresine taşınmak her iki değerin eş zamanlı olarak güncellenmesini gerektirir.
• HTTP’den HTTPS’ye yükseltme — SSL sertifikası eklemek, her iki ayardaki protokol önekinin http:// yerine https:// olarak değiştirilmesi anlamına gelir. Yalnızca birinin güncellenmesi karma içerik hatalarına yol açar.
• Hazırlık ortamından üretime geçiş — hazırlık ortamı genellikle bir alt etki alanında veya farklı bir etki alanında çalışır; dağıtım sırasında her iki değer de yeniden yazılmalıdır.
• Ters proxy veya CDN boşaltma — bir yük dengeleyici veya CDN SSL’yi sonlandırıp trafiği arka uç sunucusuna ilettiğinde, WordPress URL ayarları iç sunucu adresini değil genel etki alanını yansıtmalıdır.
• Multisite ağ yeniden yapılandırması — WordPress Multisite’ta WP_SITEURL ve WP_HOME, DOMAIN_CURRENT_SITE ve PATH_CURRENT_SITE sabitleriyle etkileşime girer; bu da doğru yapılandırmayı daha da kritik hale getirir.

Yöntem 1: WordPress Panosu Üzerinden Güncelleme

Bu yöntem, yönetici erişiminiz hâlâ mevcut olduğunda ve değişiklik basit olduğunda (örn. aynı etki alanında HTTP’den HTTPS’ye geçiş) uygundur.

1. https://yourdomain.com/wp-admin adresine giriş yapın.
2. Settings > General bölümüne gidin.
3. WordPress Address (URL) ve Site Address (URL) alanlarını bulun.
4. Her iki değeri de gerektiği şekilde güncelleyin.
5. Save Changes düğmesine tıklayın.

WordPress sizi hemen güncellenmiş yönetici URL’sine yönlendirecektir. Etki alanını değiştirdiyseniz tarayıcınız yeni adrese yönlendirmeyi takip edecektir. Yeni etki alanı henüz sunucuya çözümlenmiyorsa panoya erişiminizi kaybedersiniz — DNS yayılımını buna göre planlayın.

Yöntem 2: wp-config.php İçinde Sabitleri Tanımlama

Bu yöntem, üretim sunucularında tercih edilir; çünkü yanlışlıkla yapılacak kullanıcı arayüzü değişikliklerini önler, veritabanı geçici olarak kullanılamaz olsa bile çalışır ve sürüm kontrolüne kolayca alınabilir. Kök SSH erişimine sahip bir VPS Hosting ortamında bu en güvenilir yaklaşımdır.

wp-config.php dosyasını tercih ettiğiniz düzenleyicide açın:

nano /var/www/html/wp-config.php

Aşağıdaki iki satırı /* That's all, stop editing! */ yorumunun üstüne ekleyin:

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

Çekirdek dosyaların /wordpress içinde bulunduğu ancak sitenin kök dizinden sunulduğu alt dizin kurulum düzeni için:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );

Dosyayı kaydedin ve kapatın. Pano alanları artık salt okunur olacaktır; bu beklenen davranıştır.

Alt Dizin Kurulumu: Gerekli .htaccess ve index.php Adımları

WP_HOME ve WP_SITEURL farklı olduğunda, WordPress tek başına kök etki alanı isteklerini alt dizindeki çekirdek dosyalara yönlendiremez. Belge kökünde değiştirilmiş bir index.php ve bir .htaccess dosyası yerleştirmeniz gerekir.

Adım 1: index.php dosyasını WordPress alt dizininden kök dizine kopyalayın:

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Adım 2: Kopyalanan /var/www/html/index.php dosyasını alt dizine işaret edecek şekilde düzenleyin:

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Adım 3: Kök .htaccess dosyanızın standart WordPress yeniden yazma bloğunu içerdiğinden emin olun:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

.htaccess dosyasını alt dizinden kopyalamayın — kök etki alanı yönlendirmesini bozacak olan RewriteBase /wordpress/ içerecektir.

Yöntem 3: WP-CLI Aracılığıyla Doğrudan Veritabanı Güncellemesi

Panoya erişilemiyor ve wp-config.php dosyasına kalıcı olarak dokunmak istemiyorsanız, WP-CLI temiz ve betiklenebilir bir çözüm sunar. Bu, otomatik dağıtım hatları çalıştıran Dedicated Servers üzerinde özellikle kullanışlıdır.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Değişikliğin uygulandığını doğrulamak için:

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI, wp-config.php sabitlerini dikkate alır — WP_SITEURL veya WP_HOME orada zaten tanımlıysa, wp option update komutu bunları geçersiz kılmaz. Sabitleri doğrudan dosyada güncellemeniz gerekir.

Yöntem 4: Doğrudan MySQL Güncellemesi (Son Çare)

Bunu yalnızca SSH erişimi mevcut ancak WP-CLI kurulu değilse ve pano kilitliyse kullanın. Önce tablo önekini belirleyin (wp-config.php içindeki $table_prefix değerini kontrol edin, genellikle wp_).

mysql -u db_user -p db_name

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

Güncellemeyi onaylayın:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

MySQL’den çıkın ve siteyi test etmeden önce nesne önbelleğini (Redis, Memcached veya OPcache) temizleyin.

SSL Yapılandırması ve URL Güncellemeleri

HTTP’den HTTPS’ye yükseltme, her iki URL parametresinin eş zamanlı olarak güncellenmesinin en yaygın tek nedenidir. Certbot aracılığıyla Let’s Encrypt ya da SSL Certificates üzerinden sağlanan ticari bir sertifika gibi bir SSL sertifikası yükledikten sonra, hem WP_HOME hem de WP_SITEURL değerlerini https:// önekini kullanacak şekilde güncellemeniz gerekir.

Her ikisini birden güncellememek veya yalnızca birini güncellemek karma içerik uyarılarına yol açar: tarayıcı, HTTP varlıklarına (betikler, stil sayfaları, görseller) başvuran bir HTTPS sayfası alır. Modern tarayıcılar karma etkin içeriği tamamen engeller; bu da JavaScript işlevselliğini ve yönetici panosunu bozar.

URL sabitlerini güncelledikten sonra, gönderi içeriğinde, postmeta’da ve seçeneklerde saklanan tüm serileştirilmiş URL’leri güncellemek için veritabanında arama-değiştirme işlemi çalıştırın:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

--all-tables bayrağı, özel tablolardaki (WooCommerce, sayfa oluşturucular) serileştirilmiş verilerin de güncellenmesini sağlar. Bu komutu çalıştırmadan önce her zaman veritabanı yedeği alın.

cPanel ile WordPress URL’lerini Yapılandırma

WordPress’i VPS with cPanel üzerinde yönetiyorsanız, SSH erişimi gerektirmeden wp-config.php dosyasını düzenlemek için cPanel File Manager’ı kullanabilirsiniz:

1. cPanel’e giriş yapın ve File Manager‘ı açın.
2. WordPress belge köküne gidin (genellikle public_html veya bir alt dizin).
3. wp-config.php dosyasına sağ tıklayın ve Edit seçeneğini seçin.
4. Yöntem 2’de gösterildiği gibi WP_HOME ve WP_SITEURL sabitlerini ekleyin.
5. Dosyayı kaydedin.

Alternatif olarak, Yöntem 4’teki SQL UPDATE ifadelerini doğrudan WordPress veritabanınıza karşı çalıştırmak için cPanel’deki phpMyAdmin aracını kullanın.

Kritik Tuzaklar ve Uç Durumlar

İki ayar arasında protokol uyumsuzluğu. WP_SITEURL değerini https://example.com olarak, WP_HOME değerini ise http://example.com olarak ayarlamak (ya da tam tersi) bir yönlendirme döngüsü oluşturur. Tarayıcı sunucudan gelen HTTPS yönlendirmesini takip eder, ancak WordPress HTTP ön yüz bağlantıları üretir; sunucu bunları tekrar HTTPS’ye yönlendirir. Bu döngü panoda görünmez ama tarayıcılar ve kullanıcılar için yıkıcıdır.

Sondaki eğik çizgi tutarsızlığı. WordPress bu sabitlerdeki sondaki eğik çizgilere karşı hassastır. https://example.com ve https://example.com/ farklı değerler olarak işlenir. WordPress’in dahili beklentileriyle eşleşmesi için her iki sabitte de sondaki eğik çizgiyi her zaman atlayın.

URL değişikliğinin ardından nesne önbelleği zehirlenmesi. Sunucunuz kalıcı bir nesne önbelleği (Redis veya Memcached) çalıştırıyorsa, veritabanı güncellendikten sonra bile eski URL değerleri bellekte önbelleğe alınmış olabilir. Herhangi bir URL değişikliğinin hemen ardından nesne önbelleğini temizleyin:

wp cache flush --path=/var/www/html

Veritabanındaki serileştirilmiş veriler. WordPress, pek çok seçenek değerini ve gönderi meta verisini PHP serileştirilmiş dizeler olarak saklar. Basit bir dize değiştirme işlemi (örn. bir veritabanı dökümünde sed kullanmak), bayt sayısı öneklerini geçersiz kılarak serileştirilmiş verileri bozar. Her zaman serileştirmeyi doğru biçimde işleyen WP-CLI’nin search-replace komutunu kullanın.

Multisite ağ değerlendirmeleri. WordPress Multisite kurulumunda WP_SITEURL, tek tek alt sitelere değil ağ yöneticisine uygulanır. Her alt sitenin kendi siteurl tablosunda kendi home ve wp_X_options girişleri bulunur. Ağ genelinde bir URL değişikliği, her alt sitenin seçenekler tablosunun güncellenmesini gerektirir; WP-CLI bunu --network bayrağıyla gerçekleştirir:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Ters proxy başlık güveni. Yük dengeleyici veya Nginx ters proxy arkasındaki sunucularda, proxy X-Forwarded-Proto başlığını iletmiyorsa WordPress yanlış protokolü algılayabilir. Doğru URL sabitleri olsa bile dahili bağlantılar HTTP’ye dönebilir. HTTPS algılamayı zorlamak için wp-config.php dosyasına şunu ekleyin:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Değişikliklerden Sonra Yapılandırmayı Doğrulama

URL parametrelerinden herhangi birini güncelledikten sonra, değişikliği tamamlanmış saymadan önce aşağıdaki doğrulama adımlarını gerçekleştirin:

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Son komuttaki --dry-run bayrağı, verileri gerçekten değiştirmeden kaç değişiklik yapılacağını raporlar. Sayı sıfırsa, geçiş temizdir.

Shared Web Hosting veya VPS ortamlarında birden fazla WordPress örneğini yöneten ekipler için bu doğrulama adımını dağıtım sonrası bir betikte otomatikleştirmek, eski URL referanslarıyla bir sitenin yayına alınması riskini ortadan kaldırır.

Karar Matrisi: Hangi Yöntemi Kullanmalı

Teknik Temel Çıkarımlar Kontrol Listesi

• Alt dizin düzenine kasıtlı olarak ihtiyaç duymadığınız sürece WP_SITEURL ve WP_HOME değerlerini her zaman birlikte güncelleyin.
• Yanlışlıkla yapılacak kullanıcı arayüzü üzerine yazmalarını önlemek için üretim sunucularında wp-config.php içinde sabitleri tanımlayın.
• Herhangi bir URL değişikliğinin ardından nesne önbelleğini temizleyin ve serileştirilmiş verileri yakalamak için --all-tables ile wp search-replace komutunu çalıştırın.
• HTTP’den HTTPS’ye geçişlerde önce URL sabitlerini güncelleyin, ardından arama-değiştirme işlemini çalıştırın, sonra karma içerik için curl ile doğrulayın.
• Alt dizin kurulumlarında kök index.php dosyası alt dizin yoluna başvurmalı ve .htaccess dosyası RewriteBase / kullanmalıdır.
• WP_HOME veya WP_SITEURL sabitlerinde asla sondaki eğik çizgi kullanmayın.
• Ters proxy kurulumlarında, URL ayarlarından bağımsız olarak WordPress’in yanlış protokol referansları üretmesini önlemek için wp-config.php dosyasına HTTP_X_FORWARDED_PROTO algılaması ekleyin.
• Multisite’ta her alt sitenin wp_X_options tablosu bağımsız olarak güncellenmeli; WP-CLI ile --network bayrağını kullanın.

Sıkça Sorulan Sorular

WordPress Address ve Site Address, alt dizin kurulumu olmadan farklıysa ne olur?

WordPress, çekirdek dosyaları WP_SITEURL içinde belirtilen yoldan yüklemeye çalışır. Bu yolda herhangi bir WordPress kurulumu yoksa, tüm yönetici istekleri 404 hatası veya beyaz ekran döndürür. WP_HOME doğruysa ve yeniden yazma kuralları yerindeyse ön yüz yüklenmeye devam edebilir; ancak tüm AJAX istekleri, REST API çağrıları ve yönetici işlemleri başarısız olur.

WP_HOME ve WP_SITEURL değerlerini farklı protokollerle (biri HTTP, diğeri HTTPS) ayarlayabilir miyim?

Hayır. İki sabit arasında protokol karıştırmak, ne tarayıcıların ne de tarayıcı botlarının çözemeyeceği bir yönlendirme döngüsü oluşturur. Her iki sabit de aynı protokolü kullanmalıdır. HTTPS’yi sunucu düzeyinde (Nginx veya Apache aracılığıyla) zorunlu kılıyorsanız, her iki sabit de https:// kullanmalıdır.

Settings > General bölümünde WordPress Address alanı neden gri görünüyor?

Alan salt okunurdur çünkü WP_SITEURL (veya WP_HOME) wp-config.php içinde PHP sabiti olarak tanımlanmıştır. Kodda tanımlanan sabitler veritabanı değerlerine göre önceliklidir ve kullanıcı arayüzü üzerinden geçersiz kılınamaz. Alanı tekrar düzenlenebilir hale getirmek için wp-config.php içindeki ilgili define() satırını kaldırın veya yorum satırına alın.

Site Address’i değiştirmek SEO’mu ve mevcut geri bağlantılarımı etkiler mi?

Evet. WP_HOME değerini değiştirmek, sitenizdeki her sayfanın kurallı taban URL’sini değiştirir. Eski URL yapısından yenisine uygun 301 yönlendirmeleri yapılmadan, arama motorları eski ve yeni URL’leri ayrı sayfalar olarak değerlendirir; bu da bağlantı değerini böler ve potansiyel olarak yinelenen içerik cezalarını tetikler. URL değişikliğinden önce veya eş zamanlı olarak sunucu düzeyinde 301 yönlendirmelerini her zaman yapılandırın.

Yanlış URL girdim ve şimdi wp-admin’e erişimim engellendiyse nasıl kurtarırım?

SSH aracılığıyla sunucunuza bağlanın ve Yöntem 2’yi kullanarak wp-config.php dosyasına doğru sabitleri tanımlayın ya da Yöntem 3 aracılığıyla WP-CLI ile siteurl ve home seçeneklerini doğrudan güncelleyin. Bunların hiçbiri mevcut değilse, Yöntem 4’teki UPDATE ifadelerini çalıştırmak için phpMyAdmin veya doğrudan bir MySQL bağlantısı kullanın. Erişim yeniden sağlandıktan sonra, değerlerin ilerleyen süreçte pano tarafından yönetilmesini tercih ediyorsanız geçici sabitleri kaldırın.