“wordpress”ı Site URL’nizden Nasıl Kaldırırsınız (Eksiksiz Teknik Kılavuz)

WordPress /wordpress adlı bir alt dizine kurulduğunda, her genel URL bu yol segmentini taşır — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — bu durum marka güvenilirliğini zayıflatır ve SEO değerini düşürür. Çözüm, veritabanı URL güncellemeleriyle birleştirilmiş kontrollü bir dosya taşıma işlemidir: tüm WordPress çekirdek dosyalarını alt dizinden sunucunun belge köküne (public_html) taşır, WordPress Adresi ve Site Adresi ayarlarını güncellersiniz, yeniden yazma kurallarını yeniden oluşturursunuz ve dizine eklenmiş eski URL’ler için 301 yönlendirmeleri yapılandırırsınız. Yeniden kurulum gerekmez.

Bu kılavuz, bu sürecin her teknik katmanını kapsar — dosya sistemi işlemleri, veritabanı dize değiştirme, .htaccess yeniden yazma mantığı, yönlendirme stratejisi ve taşıma sonrası doğrulama — çoğu eğiticide sessiz hatalara yol açan uç durumlar dahil.

WordPress Neden Alt Dizine Kurulur

Temel nedeni anlamak, aynı sorunun tekrarlanmasını önler. En yaygın senaryolar şunlardır:

• Yükleyici varsayılanları: Birçok tek tıklamalı yükleyici (Softaculous, Installatron), kullanıcı kurulum yolunu açıkça / olarak ayarlamadığında varsayılan olarak bir alt dizin yolu kullanır.
• Hazırlık ortamından üretime geçiş: Bir geliştirici, WordPress’i test için /wordpress konumuna kurar ve site, yol düzeltmesi yapılmadan yayına girer.
• Hiçbir zaman hayata geçirilmeyen çoklu site planlaması: Biri tek bir alan adı altında birden fazla CMS çalıştırmayı öngörerek WordPress’i kendi klasörüne yerleştirdi.
• cPanel otomatik yükleyici tuhaflıkları: cPanel ile VPS ortamlarında, yükleyici bazen geçersiz kılınmadığı sürece uygulama adını alt dizin olarak ekler.

Kaynağından bağımsız olarak, taşıma prosedürü aynıdır.

Taşıma Öncesi Kontrol Listesi

Tek bir dosyaya dokunmadan önce bu listedeki her öğeyi tamamlayın. Herhangi birini atlamak, bu işlem sırasında kesintinin başlıca nedenidir.

• Tam site yedeklemesi: Hem dosya sistemini hem de MySQL veritabanını arşivleyin. UpdraftPlus veya Duplicator gibi eklentiler iyi çalışır; VPS Hosting sağlayıcınız destekliyorsa sunucu düzeyinde anlık görüntü de kullanılabilir.
• Veritabanı kimlik bilgileri hazırda: Manuel wp-config.php düzenlemesi gerekirse bunlara ihtiyaç duyacaksınız.
• Bakım modu etkin: Taşıma penceresi sırasında yazmaları önlemek için bir eklenti kullanın veya geçici olarak define('WP_MAINTENANCE_MODE', true); ekleyin.
• PHP hata günlüğü etkin: Taşıma sonrası hataların ekranda görünmek yerine /wp-content/debug.log dosyasına yazılması için wp-config.php içinde WP_DEBUG_LOG değerini true olarak ayarlayın.
• DNS TTL not edildi: DNS değişikliği de söz konusuysa, başlamadan en az bir saat önce TTL’yi 300 saniyeye düşürün.

Adım 1: WordPress Dosyalarını Belge Köküne Taşıyın

Amaç, /public_html/wordpress/ içindeki her şeyi doğrudan /public_html/ dizinine kopyalamaktır — klasörün kendisini değil, içeriğini.

FTP İstemcisi Kullanarak (FileZilla)

1. Kimlik bilgilerinin ele geçirilmesini önlemek için düz FTP yerine SFTP (port 22) üzerinden sunucunuza bağlanın.

public_html/wordpress/ dizinine gidin.
Gizli dosyalar dahil tüm dosya ve klasörleri seçin. FileZilla’da .htaccess ve herhangi bir .env dosyasını görmek için Görünüm > Gizli Dosyaları Göster seçeneğini etkinleştirin.
Seçimi bir dizin üstündeki public_html/ dizinine sürükleyin.
index.php dosyasının üzerine yazma istendiğinde (kökte bir yer tutucu mevcutsa) üzerine yazmayı onaylayın.

Komut Satırı Kullanarak (VPS için Önerilen)
SSH erişiminiz varsa — ki düzgün yapılandırılmış herhangi bir VPS Hosting veya Dedicated Server ortamında olmalıdır — komut satırı yaklaşımı daha hızlıdır ve büyük kurulumlarda FTP zaman aşımı sorunlarını önler:
# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30
/wordpress dizinini henüz silmeyin. Taşıma tamamen doğrulanana kadar olduğu gibi bırakın. Son temizlik adımında kaldırabilirsiniz.
Kritik Uç Durum: Eklentilerdeki Sembolik Bağlantılar ve Mutlak Yollar
Bazı eklentiler (özellikle yedekleme ve güvenlik eklentileri) veritabanında mutlak dosya yollarını depolar — örneğin /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Bunlar taşıma işleminden sonra sessizce bozulur. Adım 5’teki veritabanı arama-değiştirme işlemi bunu ele alır, ancak wp_options tablosunu ve özel eklenti tablolarını değiştirme kapsamına dahil etmeniz gerekir.
Adım 2: WordPress Adresini ve Site Adresini Güncelleyin
WordPress, wp_options tablosunda iki kritik URL değeri depolar: siteurl (WordPress çekirdek dosyalarının bulunduğu yeri gösteren WordPress Adresi) ve home (ziyaretçilerin siteye ulaşmak için kullandığı URL olan Site Adresi). Her ikisi de güncellenmelidir.
Yöntem A: WordPress Yönetim Paneli

yourdomain.com/wordpress/wp-admin adresine giriş yapın — dosyalar bu noktada her iki konumda da bulunduğundan bu hâlâ çalışır.
Ayarlar > Genel bölümüne gidin.
Her iki alanı da güncelleyin:


WordPress Adresi (URL): https://yourdomain.com

2. Site Adresi (URL): https://yourdomain.com
1. Değişiklikleri Kaydet seçeneğine tıklayın.

Yöntem B: Doğrudan Veritabanı Düzenlemesi (Yönetim Paneline Erişilemediğinde)

Yönetim paneline zaten erişilemiyorsa WP-CLI veya phpMyAdmin kullanın:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

Ya da phpMyAdmin’de şunu çalıştırın:

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

wp_ kısmını, kurulum sırasında değiştirildiyse gerçek tablo ön ekiyle değiştirin.

Yöntem C: Geçici wp-config.php Geçersiz Kılma

Hem yönetim paneline hem de veritabanına geçici olarak erişilemiyorsa, önyükleme geçersiz kılması olarak wp-config.php dosyasına şu iki satırı ekleyin:

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

Bu, veritabanında depolanan her şeyi geçersiz kılar. Yönetim panelinin erişilebilir olduğunu ve veritabanı değerlerinin kalıcı olarak güncellendiğini onayladıktan sonra bu satırları kaldırın.

Adım 3: .htaccess Dosyasını Doğrulayın ve Güncelleyin

Belge kökündeki .htaccess dosyası, Apache’nin WordPress için URL yeniden yazma işlemini kontrol eder. Dosyalar taşındıktan sonra bu dosya zaten public_html/ konumunda olmalıdır — ancak RewriteBase yönergesi yeni kök düzeyindeki kurulumu yansıtmalıdır.

public_html/.htaccess dosyasını açın ve tam olarak aşağıdaki 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

Alt dizin kurulumundan temel fark, RewriteBase /wordpress/ yerine RewriteBase / kullanılmasıdır. Bu satır yanlışsa, ana sayfa doğru yüklenirken tüm güzel kalıcı bağlantılar 404 hatası döndürür — bu, yanlış yapılandırılmış RewriteBase dosyasının klasik tanısal belirtisidir.

Nginx kullanıcıları: WordPress .htaccess kullanmaz. Bunun yerine sunucu bloğunuzun try_files yönergesini güncelleyin:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Adım 4: Kalıcı Bağlantı Yapısını Yenileyin

WordPress, yeniden yazma kurallarını veritabanında önbelleğe alır. Site URL’si değiştirildikten sonra, önbelleğe alınan bu kurallar eski yol yapısına başvurur ve yeniden oluşturulması gerekir.

1. WordPress yönetim panelinde Ayarlar > Kalıcı Bağlantılar bölümüne gidin.
2. Seçili kalıcı bağlantı yapısını değiştirmeden Değişiklikleri Kaydet seçeneğine tıklayın.

Bu, WordPress’i yeniden yazma kurallarını yeni kök düzeyindeki yola göre yeniden oluşturmaya ve önbelleğe almaya zorlar. Alternatif olarak WP-CLI kullanın:

wp rewrite flush --hard

--hard bayrağı, veritabanı önbelleğini temizlemenin yanı sıra .htaccess dosyasını da yeniden oluşturur — .htaccess dosyasının doğru olup olmadığından emin değilseniz kullanışlıdır.

Adım 5: Veritabanı Genelinde URL Değiştirme

Dosyaları taşımak ve siteurl/home değerlerini güncellemek yeterli değildir. WordPress, veritabanı genelinde — gönderi içeriğinde, postmeta’da, widget ayarlarında, tema seçeneklerinde ve eklenti yapılandırma tablolarında — serileştirilmiş URL dizeleri depolar. Kalan /wordpress yol referansları bozuk görsellere, yanlış kanonik etiketlere ve arızalı eklenti özelliklerine yol açar.

Better Search Replace Eklentisini Kullanarak

1. Better Search Replace eklentisini yükleyin ve etkinleştirin.
2. Araçlar > Better Search Replace bölümüne gidin.
3. Değiştirme işlemini yapılandırın:

• Aranan: https://yourdomain.com/wordpress
• Değiştirilen: https://yourdomain.com

1. Tüm veritabanı tablolarını seçin.
2. Deneme çalışmasının beklenen sayıda değiştirme gösterdiğini onayladıktan sonra Deneme çalışması olarak çalıştır? seçeneğinin işaretini kaldırın.
3. Arama/Değiştirme Çalıştır seçeneğine tıklayın.

Mutlak sunucu yolu için de ikinci bir geçiş yapın:

• Aranan: /public_html/wordpress
• Değiştirilen: /public_html

WP-CLI Kullanarak (Üretim için Tercih Edilen)

WP-CLI’nin search-replace komutu, serileştirilmiş verileri doğru şekilde işler; basit SQL REPLACE() işlevi bunu yapamaz:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Mutlak dosya sistemi yolları için ikinci bir geçiş yapın:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

--precise bayrağı, regex yerine PHP’nin serileştirme uyumlu değiştirmesini kullanır; bu, veritabanında depolanan serileştirilmiş dizilerin bozulmasını önler.

Adım 6: SEO Sürekliliği için 301 Yönlendirmeleri Uygulayın

Site /wordpress URL’lerinde kamuya açık olarak erişilebilir durumdaysa — ve özellikle bu URL’ler Google tarafından dizine eklenmişse veya dış kaynaklardan bağlantı verilmişse — kalıcı yönlendirmeler zorunludur, isteğe bağlı değil. Bunlar olmadan, dizine eklenmiş her URL 404 hatası verir ve birikmiş tüm bağlantı değeri kaybolur.

Aşağıdaki yönlendirme kuralını public_html/.htaccess dosyasına, WordPress yeniden yazma bloğunun üstüne ekleyin:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Bu kural, wordpress/ ile başlayan herhangi bir isteği yakalar ve eşdeğer kök düzeyindeki yola yönlendirir. Örneğin:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Önemli yerleştirme notu: Bu yönlendirme bloğu # BEGIN WordPress yorumundan önce görünmelidir. Yönlendirme bunların arkasına yerleştirilirse WordPress’in kendi yeniden yazma kuralları isteği önce yakalar.

Nginx için bunu sunucu bloğuna ekleyin:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Adım 7: Taşıma Sonrası Doğrulama

Sistematik testler, sessiz hataların üretimde fark edilmeden geçmesini önler.

İşlevsel Kontroller

Komut Satırı Doğrulaması

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Doğrulamanın hemen ardından Google Search Console’da güncellenmiş site haritasını gönderin. Ana sayfanın yeniden dizine eklenmesini talep etmek için URL Denetimi aracını kullanın. Kaçırılan URL değiştirmelerini gösterebilecek 404 hatalarındaki herhangi bir artış için sonraki 48–72 saat boyunca Kapsam raporunu izleyin.

Adım 8: Temizlik ve Son Sağlamlaştırma

Site kök URL’sinde 24–48 saat kararlı biçimde çalıştıktan sonra:

1. Sunucudan /wordpress alt dizinini silin. Yerinde bırakmak yinelenen içerik riski oluşturur ve WordPress kurulumuna ikincil bir giriş noktası açar.

rm -rf /var/www/html/public_html/wordpress

1. Eklediyseniz WP_MAINTENANCE_MODE sabitini wp-config.php dosyasından kaldırın.
2. Adım 2’de Yöntem C’yi kullandıysanız geçici WP_HOME/WP_SITEURL tanımlarını wp-config.php dosyasından kaldırın.
3. SSL kapsamını doğrulayın: SSL Sertifikanız yourdomain.com/wordpress için yol tabanlı kapsam olarak verilmişse (bazı yapılandırmalarda nadir de olsa mümkündür), sertifikanın apex alan adını doğru şekilde kapsadığını onaylayın.
4. Eski yol yapısını önbelleğe almış olabilecek harici DNS veya CDN yapılandırmalarını güncelleyin.
5. Tüm önbellek katmanlarını temizleyin: Sunucu tarafı sayfa önbelleğini, nesne önbelleğini (Redis/Memcached) ve CDN önbelleğini temizleyin. /wordpress URL’leri için eski önbellek girişleri, taşıma tamamlandıktan sonra bile yanlış içerik sunmaya devam eder.

Karşılaştırma: Bir Bakışta Taşıma Yöntemleri

SSH erişimi olan herhangi bir ortamda — Dedicated Sunucular ve yönetilmeyen VPS örnekleri dahil — WP-CLI yaklaşımı en güvenilir ve en az hata riski taşıyan seçenektir.

Teknik Karar Matrisi

Belirli senaryonuz için hangi adımların zorunlu, hangilerinin duruma bağlı olduğunu belirlemek için bu matrisi kullanın:

Temel Çıkarımlar

• Temel işlem şudur: dosyaları belge köküne kopyalayın, veritabanında siteurl ve home değerlerini güncelleyin, .htaccess RewriteBase dosyasını düzeltin, serileştirme uyumlu arama-değiştirme yapın, 301 yönlendirmeleri ekleyin.
• Serileştirme işlemi olmadan WordPress tablolarında hiçbir zaman düz SQL REPLACE() kullanmayın — seçenek değerlerini bozar ve eklentileri sessizce kırar.
• .htaccess RewriteBase / yönergesi, bu taşımada en sık yanlış yapılandırılan tek öğedir; yanlış bir değer, ana sayfa doğru yüklenmeye devam ederken kalıcı bağlantı tabanlı tüm URL’lerde 404 hatası üretir.
• 301 yönlendirmeleri kozmetik değildir — bağlantı değerini aktarır ve dizin parçalanmasını önler. Mevcut arama görünürlüğüne sahip herhangi bir site için zorunludur.
• Orijinal /wordpress dizinini yalnızca 24 saatlik kararlı gözlem penceresinin ardından silin.
• WordPress’i cPanel ile VPS üzerinde çalıştırıyorsanız, kopyalama işlemine .htaccess dosyasının dahil edildiğinden emin olmak için Dosya Yöneticisi’nin Gizli Dosyaları Göster seçeneğini kullanın.

Sıkça Sorulan Sorular

URL’den /wordpress kaldırmak SEO sıralamalarımı etkiler mi?

Kısa vadede, Googlebot yeni URL’leri yeniden tararken küçük sıralama dalgalanmaları bekleyin. 301 yönlendirmeleri doğru şekilde uygulanırsa bağlantı değeri tamamen aktarılır ve sıralamalar genellikle iki ila dört hafta içinde istikrar kazanır. 301 yönlendirmelerini atlamak, daha önce dizine eklenmiş tüm sayfalar için kalıcı sıralama kaybına neden olur.

Dosyaları taşıdıktan sonra WordPress yönetim paneline erişemiyorsam ne yapmalıyım?

En yaygın neden, veritabanındaki siteurl değeri ile gerçek dosya konumu arasındaki uyumsuzluktur. Erişimi yeniden sağlamak için WP-CLI (wp option update siteurl) kullanın veya geçici bir geçersiz kılma olarak wp-config.php dosyasına define('WP_SITEURL', 'https://yourdomain.com'); ekleyin.

WordPress’i köke taşıdıktan sonra wp-config.php dosyasını güncellememem gerekiyor mu?

Çoğu durumda hayır. wp-config.php dosyası, veritabanı bağlantısı için göreli yollar kullanır ve kurulum yolunu sabit kodlamaz. İstisna, ABSPATH değerinin eski /wordpress dizinine işaret eden mutlak bir yol olarak manuel olarak tanımlandığı durumdur — bu durumda söz konusu satırı güncelleyin veya kaldırın.

Better Search Replace çalıştırdıktan sonra görseller neden hâlâ bozuk?

Bu genellikle eklentinin bir tablo alt kümesinde çalıştığı ve özel eklenti tablolarını ya da wp_postmeta tablosunu kaçırdığı anlamına gelir. Tüm tablolar seçili olarak değiştirmeyi yeniden çalıştırın ve URL tabanlı dizelere ek olarak mutlak dosya sistemi yollarını da (örn. /public_html/wordpress/wp-content/uploads/) kontrol edin.

WordPress Multisite kurulumunda bunu nasıl ele almalıyım?

Multisite, wp-config.php dosyasında ek sabitler (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) gerektirir ve ağın site URL’leri hem wp_site hem de wp_blogs tablolarında güncellenmelidir. Standart tek site prosedürü yetersizdir — bunu tam bir ağ taşıması olarak ele alın ve önce bir hazırlık klonunda test edin.