WordPress Kalıcı Bağlantı Ayarları Nasıl Yapılır?

WordPress kalıcı bağlantı ayarları neden bu kadar önemli?

Bir WordPress sitesinde sayfa açılıyor, yönetim paneli çalışıyor ve ana sayfa düzgün görünüyorsa her şey yolunda sanmak kolaydır. Ta ki bir yazının bağlantısını değiştirdikten sonra eski adresin 404 vermeye başladığını görene kadar.

Kalıcı bağlantı, WordPress içindeki yazı, sayfa, kategori ve etiketlerin tarayıcıda görünen URL yapısıdır. İngilizce arayüzde bu bölüm Permalinks adıyla geçer. Doğru yapı seçildiğinde adresler daha anlaşılır olur, içerik taşımak kolaylaşır ve ziyaretçi hangi sayfada olduğunu URL üzerinden de anlayabilir.

Benim için bu ayarların bir başka anlamı daha var: Yanlış yapı genellikle site kurulurken sessizce seçilir; sorun ise aylar sonra, Google’dan gelen bir ziyaretçinin eski bir bağlantıya tıklamasıyla ortaya çıkar. O noktada yalnızca URL görüntüsünü değil, yönlendirmeleri, önbelleği ve sunucudaki rewrite kurallarını birlikte kontrol etmek gerekir.

Yönetim panelinden kalıcı bağlantı yapısını değiştirme

WordPress yönetim panelinde Ayarlar > Kalıcı Bağlantılar yolunu izleyin. Burada WordPress’in sunduğu birkaç hazır yapı ve özel yapı seçeneği görünür.

• Düz: ?p=123 biçiminde adres üretir.
• Gün ve isim: /2026/09/12/ornek-yazi/ gibi tarih bilgisi içerir.
• Ay ve isim: Yıl ve ay bilgisini URL’ye ekler.
• Sayısal: Yazı kimliğini temel alır.
• Yazı ismi: /ornek-yazi/ biçimindeki kısa yapıdır.
• Özel yapı: URL’yi belirlediğiniz etiketlerle oluşturmanızı sağlar.

Çoğu kurumsal site, blog ve WooCommerce projesinde başlangıç için Yazı ismi seçeneği yeterlidir. Ardından sayfanın altındaki Değişiklikleri kaydet düğmesine basın. Yeni bir ayar seçmemiş olsanız bile bu düğmeye basmak WordPress’in rewrite kurallarını yeniden yazmasını sağlar.

Şöyle anlatayım: Panelde değişiklik yapıp yalnızca başka bir menüye geçmek, ayarı uygulamak anlamına gelmez. WordPress’in bu bölümdeki kaydetme işlemi, bazı sunucularda .htaccess dosyasını da günceller.

En çok kullanılan yapı: Yazı ismi

/wordpress-kalici-baglanti-ayarlari/ gibi bir URL, ziyaretçiye ve arama motoruna sayfanın konusunu anlatır. Tarih içermediği için içerik güncellendiğinde adresi değiştirme ihtiyacı da azalır.

Yine de bu yapı her site için otomatik olarak doğru değildir. Haber sitelerinde yayın tarihi editoryal anlam taşıyabilir. Çok uzun süredir kullanılan bir sitede mevcut URL yapısı arama sonuçlarına, dış bağlantılara ve sosyal paylaşımlara yerleşmiş olabilir. Sırf adresler daha kısa görünsün diye çalışan bir sistemi taşımak, kazancı belirsiz bir değişiklik karşılığında gereksiz risk almaktır.

URL yapısı seçerken hangi noktaları değerlendirmelisiniz?

Kalıcı bağlantı seçimi yalnızca SEO başlığı değildir. İçeriğin ömrü, editoryal süreç, kategori kullanımı ve teknik taşıma planı birlikte düşünülmelidir.

%category% etiketini kullanmadan önce iki kez düşünün. Bir yazının kategorisi değişirse URL’si de değişebilir. Aynı içerik birden fazla kategoriye atanırsa WordPress hangi kategoriyi kullanacağı konusunda eklenti ve ayarlara bağlı davranabilir. Bu da gereksiz yönlendirme zincirleri veya tutarsız bağlantılar doğurabilir.

Ben yeni kurduğum içerik sitelerinde çoğunlukla /%postname%/ yapısını seçiyorum. Ürün kataloglarında ise ürün URL’sinin kategoriye bağlı olmamasını tercih ediyorum; çünkü kategori ağacı zaman içinde değişebiliyor. Bir ürünün “aksesuar” kategorisinden “kampanya” kategorisine taşınması, ürün adresini değiştirmek zorunda bırakmamalı.

Yazı, sayfa ve özel içerik türleri için URL ayarları

Kalıcı bağlantılar ekranının alt kısmında kategori ve etiket tabanlarını değiştirebileceğiniz alanlar bulunur. Varsayılan olarak bir kategori adresi /category/hosting/, etiket adresi ise /tag/wordpress/ şeklinde oluşur.

İsterseniz kategori tabanını konu, etiket tabanını etiket yapabilirsiniz. Böylece adresler /konu/hosting/ ve /etiket/wordpress/ biçimine dönüşür. Bu değişiklik yalnızca görünüşü etkilemez; mevcut kategori ve etiket URL’lerinin tamamı değişir.

WooCommerce kullanıyorsanız ürün, ürün kategorisi ve ürün etiketi yapılarını ayrıca kontrol edin. WooCommerce’in kendi ayarlarında ürün kalıcı bağlantıları için seçenekler olabilir. Aynı slug’ın hem bir sayfada hem ürün kategorisinde kullanılması çakışmaya yol açabilir. Örneğin /magaza/ adlı bir sayfanız varken ürün kategorisi tabanını da magaza yapmak beklenmedik sonuçlar üretebilir.

Özel içerik türleri, kullandığınız tema veya eklentinin kayıt biçimine göre davranır. Bir portföy eklentisi /portfolio/, etkinlik eklentisi /event/ gibi kendi rewrite yapısını tanımlayabilir. Paneldeki genel ayar değişikliğinden sonra bu içerik türlerinin tekil sayfalarını ayrıca test edin.

Kalıcı bağlantıyı kaydettikten sonra neden 404 görürsünüz?

Bir yazının ana sayfada görünmesi, o yazının kendi URL’sinin doğru çalıştığı anlamına gelmez. WordPress’in URL’yi fiziksel bir dosya gibi değil, rewrite kuralları aracılığıyla index.php dosyasına yönlendirmesi gerekir.

Apache kullanılan sunucularda bu görev çoğunlukla WordPress kök dizinindeki .htaccess dosyasıyla yerine getirilir. Tipik bir WordPress kurulumu için temel içerik şöyledir:

# 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

Burada mevcut dosya ve klasörler doğrudan sunulur; diğer istekler WordPress’in giriş dosyasına aktarılır. Sunucunuz alt dizinde çalışıyorsa RewriteBase ve yönlendirme yolu kurulum dizinine göre değişebilir.

.htaccess dosyasını elle düzenlemeden önce yedek alın. Dosyaya rastgele bir kural eklemek, yalnızca tek bir yazıyı değil, yönetim panelini de erişilmez hale getirebilir. İlk sitemde bir forum eklentisinin istediği rewrite kuralını yanlış yere ekleyip 500 hatası almıştım; hatayı ekran değil, Apache error log söyledi. O geceden beri 500 hatasında önce loga bakarım.

OpenLiteSpeed ve Nginx tarafında durum

OpenLiteSpeed, çoğu WordPress kurulumunda Apache uyumlu .htaccess kurallarını okuyabilir. Yine de panelde kalıcı bağlantıyı kaydettikten sonra OpenLiteSpeed önbelleğini temizlemek gerekebilir. CyberPanel gibi panellerde rewrite ve sanal host ayarları panel tarafından yönetildiği için dosyayı elle değiştirmeden önce panel yapılandırmasını kontrol edin.

Nginx ise .htaccess okumaz. WordPress için sanal host yapılandırmasında genellikle aşağıdaki yönlendirme bulunur:

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

try_files mevcut dosya veya klasörü arar; bulamazsa isteği index.php dosyasına gönderir. Nginx yapılandırmasını değiştirdikten sonra sözdizimini kontrol edip servisi yeniden yükleyin:

nginx -t
systemctl reload nginx

İlk komut yapılandırmada hata olup olmadığını test eder, ikinci komut çalışan Nginx sürecini kesmeden yeni ayarı yükler. Üretim sunucusunda doğrudan restart yerine çoğu durumda reload tercih ederim.

Kalıcı bağlantı değişikliğinden önce alınması gereken önlemler

Çalışan bir sitenin URL yapısını değiştiriyorsanız önce mevcut yapıyı kaydedin. En azından şu bilgileri not edin:

• Eski ve yeni kalıcı bağlantı formatı.
• Google’da veya başka sitelerde görünür olan önemli URL’ler.
• Site haritasında bulunan yazı, sayfa, kategori ve ürün adresleri.
• Özel rewrite kullanan eklentiler ve içerik türleri.
• Önbellek, CDN ve güvenlik eklentisinin yönlendirme ayarları.

Veritabanı yedeği de alın. Ben WordPress üzerinde panelden güncelleme yapmadan önce en azından şu komutu çalıştırıyorum:

wp db export /home/site/backups/before-permalinks-$(date +%F).sql

Bu komut veritabanını tarih bilgisi içeren bir SQL dosyasına aktarır. Yedeğin oluştuğunu yalnızca komutun hata vermemesinden anlamayın; dosya boyutunu ve mümkünse ayrı bir makinede geri yüklenebilirliğini de kontrol edin.

Kalıcı bağlantı değişikliği dosyaları doğrudan silmez, fakat URL’leri değiştirir. Eski URL’ler için 301 yönlendirmeleri tanımlanmazsa ziyaretçiler 404 sayfasına düşer ve dış bağlantıların değeri azalır. Çok sayıda URL varsa yönlendirmeleri tek tek eklenti alanına yazmak yerine bir eşleştirme tablosu hazırlayın.

301 yönlendirmeleri nasıl planlanır?

Örneğin eski yapı /%year%/%monthnum%/%postname%/, yeni yapı ise /%postname%/ olsun. Eski adres ile yeni slug aynı kaldığı sürece genel bir yönlendirme kuralı kullanılabilir; fakat kategori, özel karakter ve daha önce değiştirilmiş slug’lar için ayrı kontrol gerekir.

Yönlendirme eklentisi kullanıyorsanız önce birkaç örnek URL ile test edin. Eski adresin tek bir 301 ile yeni adrese gittiğini, yeni adresin de 200 durum kodu döndürdüğünü kontrol edebilirsiniz:

curl -I https://example.com/2025/08/ornek-yazi/

Çıktıda HTTP/2 301 ve doğru bir location: başlığı görmelisiniz. Yeni URL’yi ayrıca kontrol ettiğinizde 200 dönmesi gerekir; 301’in tekrar başka bir 301’e gitmesi yönlendirme zincirine işaret eder.

İçerik içinde eski URL’ler de kalmış olabilir. Menüleri, görsellerin bağlantılarını, XML site haritasını ve yapılandırılmış veri üreten eklentileri kontrol edin. WordPress Site Sağlığı Raporu Nasıl Okunur? başlıklı içerikte de görülebileceği gibi, WordPress’in teknik uyarıları tek başına teşhis koydurmaz; hangi URL’nin hangi katmanda kırıldığını ayrıca doğrulamak gerekir.

Değişiklik sonrası kontrol listesi

Kaydet düğmesine bastıktan sonra ana sayfaya bakmak yeterli değil. Ben aşağıdaki sırayla kontrol ediyorum:

1. Bir yazı, bir sayfa ve bir kategori adresini gizli sekmede açın.
2. Yönetim panelinde yeni bir deneme yazısı oluşturup taslak URL’sini kontrol edin.
3. Eski bir URL’nin doğru 301 yönlendirmesi verdiğini doğrulayın.
4. Menü, etiket, kategori ve arama sonuçlarındaki bağlantıları deneyin.
5. WooCommerce kullanıyorsanız ürün, sepet, ödeme ve hesap sayfalarını test edin.
6. Önbelleği ve CDN katmanını temizleyin; aynı adresi farklı bir ağdan deneyin.
7. Sunucu erişim ve hata loglarında 404 artışı olup olmadığına bakın.
8. Google Search Console’daki tarama ve sayfa indeksleme raporlarını birkaç gün izleyin.

Google Search Console Performans Raporu Nasıl Okunur? içeriğinde trafik ve sorgu verileri anlatılıyor; URL yapısını değiştirdikten sonra da yalnızca tıklamalara bakmayın. Eski sayfaların gösterim almaya devam edip etmediğini, yeni adreslerin indekslenip indekslenmediğini birlikte izleyin.

404 sayfalarının tamamı hata değildir. Yazım hatalı, hiç var olmamış veya kasıtlı olarak kaldırılmış adresler de loglara düşer. Fakat aynı eski URL’nin sürekli istenmesi, dışarıda hâlâ kullanılan bir bağlantı veya eksik bir 301 kuralı olduğunu gösterebilir.

Yanlış kalıcı bağlantı seçiminin sık görülen belirtileri

Yazılar açılıyor, sayfalar 404 veriyor

Bu durumda rewrite kuralları yalnızca kısmen çalışıyor olabilir. Kalıcı bağlantılar ekranında hiçbir değişiklik yapmadan Değişiklikleri kaydet düğmesine basın. Düzelmezse .htaccess, Nginx try_files kuralı, dosya izinleri ve sunucu hata logunu kontrol edin.

URL sonunda iki farklı biçim oluşuyor

Bir adresin hem eğik çizgili hem eğik çizgisiz biçimde ayrı ayrı açılması, canonical ve yönlendirme ayarlarının çakıştığını gösterebilir. WordPress, web sunucusu, CDN veya SEO eklentisinden hangisinin canonical yönlendirmeyi yönettiğini netleştirin; aynı işi yapan üç farklı katman bırakmayın.

Slug Türkçe karakterlerle bozuluyor

WordPress Türkçe karakterleri genellikle URL uyumlu biçime dönüştürür. Yine de slug’ı elle ve kısa biçimde belirlemek daha sağlıklıdır. Başlık değişse bile mevcut slug’ı zorunlu olmadıkça değiştirmeyin; değiştirirseniz eski adrese 301 ekleyin.

Yönetim paneli açılıyor ama ön yüz açılmıyor

Bu tablo çoğunlukla rewrite veya önbellek katmanına işaret eder. Önce eklentileri geçici olarak devre dışı bırakıp temel bir tema ile test etmek, ardından sunucu loglarına bakmak rastgele dosya değiştirmekten daha hızlıdır.

WP-CLI ile URL ve rewrite kontrolü

SSH erişiminiz varsa WP-CLI, paneldeki belirsizliği azaltır. Aşağıdaki komut mevcut kalıcı bağlantı yapısını gösterir:

wp option get permalink_structure

Çıktı /%postname%/ ise site yazı ismi yapısını kullanıyordur. Boş çıktı, düz bağlantı yapısına işaret eder.

Rewrite kurallarını yeniden oluşturmak için:

wp rewrite flush

Bu komut WordPress’in bellekteki rewrite kurallarını yeniler. Sunucudaki Nginx veya Apache kuralı eksikse tek başına mucize yaratmaz; komut çalıştı diye web sunucusu yapılandırmasının doğru olduğunu varsaymayın. Apache veya OpenLiteSpeed üzerinde .htaccess dosyasını da yeniden yazmanız gerekiyorsa, kullanacağınız WP-CLI sürümünde --hard seçeneğinin etkisini kontrol ederek wp rewrite flush --hard çalıştırabilirsiniz.

Bir taşıma sonrasında alan adı veya URL değiştiyse wp search-replace kullanmadan önce mutlaka veritabanı yedeği alın. Yanlış kapsamda çalıştırılan bir arama-değiştirme işlemi, seri hale getirilmiş WordPress verilerini bozabilir. Bu tür değişiklikleri önce staging ortamında ve --dry-run seçeneğiyle denemek daha güvenlidir.

Yeni bir site için benim tercih ettiğim başlangıç ayarları

Yeni bir kurulumda önce alan adı, SSL ve ana sayfa ayarlarını tamamlarım. Ardından /%postname%/ yapısını seçer, kategori ve etiket tabanlarını proje ihtiyacına göre belirlerim. İlk yazıyı yayınlamadan önce bir sayfa, bir kategori ve bir etiket açıp hepsini dışarıdan test ederim.

Site WooCommerce ise ürün URL’sini kategoriye bağlamamaya çalışırım. İçerik sitesi ise kısa ve sabit slug’ları tercih ederim. Tarih bilgisi editoryal olarak anlam taşımıyorsa URL’ye tarih koymam; çünkü iki yıl sonra güncellenen yazının adresinde eski tarihi taşımak zorunda kalmak gereksiz bir yük olabilir.

Bir destek biletinde, .htaccess dosyasına eklenen hatalı bir kural yüzünden ana sayfanın çalışmadığını, yazıların ise 500 hatası verdiğini görmüştüm. İlk bakışta WordPress panelindeki kalıcı bağlantı seçimi suçlu görünüyordu. Apache error logda kuralın yanlış bağlamda kullanıldığı ortaya çıktı; dosyayı yedekten geri alıp kuralları yeniden oluşturduktan sonra sorun düzeldi. O olay bana küçük bir URL değişikliğinde bile önce yedek, sonra log, en son elle düzenleme sırasını bıraktı.

Sık Sorulan Sorular

WordPress kalıcı bağlantı ayarları için en iyi seçenek hangisidir?

Çoğu blog ve kurumsal site için Yazı ismi seçeneği kısa ve sürdürülebilir bir yapı sağlar. Haber veya kronolojik arşiv sitelerinde tarih içeren yapıların editoryal bir anlamı olabilir.

Kalıcı bağlantıyı değiştirince eski yazılar silinir mi?

Hayır, yazılar silinmez; yalnızca URL’leri değişir. Eski adreslerden yenilerine 301 yönlendirmesi eklemezseniz ziyaretçiler ve arama motorları eski bağlantılarda 404 görebilir.

Kalıcı bağlantıları kaydettikten sonra sayfalar neden 404 oluyor?

En sık neden rewrite kurallarının sunucuda doğru uygulanmamasıdır. Apache veya OpenLiteSpeed için .htaccess, Nginx için try_files kuralı kontrol edilmeli; ayrıca WordPress panelinde kalıcı bağlantılar yeniden kaydedilmelidir.

Kalıcı bağlantı yapısını sonradan değiştirmek SEO’ya zarar verir mi?

Doğru 301 yönlendirmeleri, güncel site haritası ve iç bağlantı kontrolleriyle risk azaltılabilir. Yönlendirmeler unutulursa trafik kaybı ve çok sayıda 404 görülebilir; bu yüzden değişikliği önce staging ortamında prova etmek iyi bir fikirdir.