CMS seçimi çoğu zaman editöryal kolaylık, geliştirici alışkanlığı veya bütçe kısıtına göre yapılır. Seçilen sistem ise yalnızca içerik yönetim arayüzü olmaktan çıkıp sitenin URL yapısını, taksonomi düzenini ve sayfa hiyerarşisini şekillendirir. İki yıl sonra değiştirmek isteyeceğiniz URL desenleri, büyük olasılıkla sistemin kurulum sihirbazında seçilmiş varsayılan ayarlarda gizlidir.

WordPress, Drupal, Contentful ve benzer sistemlerin her biri farklı yapısal varsayımlarla gelir. Bu varsayımlar kategori derinliğini, içerik türleri arasındaki ilişkileri ve navigasyon mimarisini belirler. Hangisini seçtiğinize bağlı olarak bazı mimari tercihler kolaylaşır, bazıları neredeyse imkansızlaşır, bazıları ise mümkün görünse de sürdürülmesi güçleşir.

Bir CMS'i değerlendirirken önce içerik ekibinin rahat edeceği arayüz sorulur, ardından geliştirici ekosistemi tartışılır. Mimari kısıtlar en sona kalır ya da hiç sorulmaz. Doğru sıra tersine işler: önce ihtiyaç duyduğunuz URL yapısını ve içerik modelini tanımlayın, sonra hangi sistemin bunu karşılayıp karşılamadığına bakın.

URL Yapısı: Sistemin Verdiği ve Vermediği Özgürlük

WordPress'te varsayılan permalink yapısı /?p=123 biçimindedir; kullanışlı değildir ve çoğu proje bunu hemen değiştirir. Ancak özelleştirme seçenekleri de belirli kalıplarla sınırlıdır: /yil/ay/yazi-adi/, /kategori/yazi-adi/ veya düz /yazi-adi/. Ürün sayfaları için /urun/kategori/alt-kategori/urun-adi/ gibi dört seviyeli bir hiyerarşi istiyorsanız, varsayılan yapı yetmez ve özel rewrite kuralları gerekir. Bu kurallar bir WordPress güncellemesinde bozulabilir ya da yeni bir eklentiyle çakışabilir.

Drupal bu konuda daha esnektir. Pathauto modülüyle içerik türü bazında farklı URL desenleri tanımlayabilirsiniz; makaleler /blog/[node:title], ürünler /katalog/[term:name]/[node:title] biçiminde ayrı şemalara bağlanabilir. Esneklik arttıkça yapılandırma karmaşıklığı da artar; yanlış yapılandırma, aynı içerik için birden fazla geçerli URL üretmesine ve kanonikleşme sorununa yol açar.

Headless yapılar veya API tabanlı sistemler URL yapısını CMS'ten tamamen ayırır. URL'ler frontend katmanında tanımlanır. Özgürlük gerçektir; ancak URL ile içerik modeli arasındaki tutarlılığı artık sistem değil geliştirici ekibi korumak zorundadır. Sistemin kısıtı ortadan kalkar; sistemin disiplini de.

Taksonomi Yapısı ve İçerik Modeli Kısıtları

Taksonomi, içeriği gruplamak için kullandığınız etiket ve kategori sisteminin bütünüdür. Çoğu CMS'te taksonomiler bir veya iki hiyerarşi seviyesinde iyi çalışır. Dördüncü seviyenin ötesinde sorunlar başlar: arama botları derin sayfaları bulmakta zorlanır, URL'ler uzar, navigasyon karmaşıklaşır.

WordPress'te kategori taksonomisi hiyerarşiktir; etiketler değildir. Bir içerik birden fazla kategoriye girebilir, ancak URL her zaman tek bir kategori yolunu yansıtır. Çift kategorili bir yazı için kanonik URL seçimi elle yapılmadıkça tutarsızlaşır; bazı eklentiler bunu otomatikleştirir, ama varsayılan davranış güvenilir değildir. Ürün ya da hizmet sayfaları için karmaşık ilişki kurmanın yolu özel post type ve taxonomy kombinasyonlarından geçer; bu da her yeni içerik türü için tekrar tekrar yapılandırma demektir.

Drupal'da içerik türleri entity reference alanlarıyla birbirine bağlanır. Bir makale bir veya daha fazla taksonomi terimine, bir yazara ve ilgili ürünlere referans verebilir. İlişkiler çok boyutludur ve içerik modeli baştan iyi kurulduysa güçlü çalışır. Ancak içerik modelini baştan düzgün tanımlamak zorunludur; sonradan eklenen ilişki alanları mevcut içerik göçünde ciddi veri temizliği çıkarır.

Contentful ve benzeri headless sistemlerde içerik modeli tamamen özeldir. Taksonomi hiyerarşisi yoktur; siz inşa edersiniz. Başlangıçta cazip görünür. İlerleyen aylarda iki farklı geliştirici iki farklı ilişki modeli oluşturursa, model çakışması içerik göçünden daha ağır bir sorun hâline gelir. İçerik modelinin belgelenmesi bu nedenle araç seçimi kadar kritiktir.

Navigasyon hiyerarşisi sitenin menü yapısını belirler. İki seviyeli menü çoğu CMS'te sorunsuz çalışır. Üçüncü seviye çoğunlukla mümkündür ama arayüzde yönetmek zorlaşır. Dördüncü seviye büyük çoğunlukla özel geliştirme gerektirir.

WordPress'te menüler sayfa, kategori ve özel bağlantıdan oluşur. Sürükle-bırak arayüzüyle üç seviyeye kadar yönetilebilir; ancak bu menü yapısının URL yapısıyla otomatik ilişkisi yoktur. Menüde üç seviye görünse de URL hâlâ tek seviye düz olabilir. Arama botları menüyü değil URL hiyerarşisini tarar; iki yapı birbiriyle uyumsuzsa sitenin hiyerarşisi botlar için belirsizleşir.

Drupal'da menüler içerik yapısıyla daha sıkı bağlantılıdır. Sayfa hiyerarşisi hem URL'e hem menüye yansıyabilir. Büyük, karmaşık sitelerde bu tutarlılık değerlidir; ancak içerik editörlerinin hiyerarşiyi anlayıp doğru seviyede yayın yapması gerekir. Editörün bir sayfayı yanlış seviyeye yerleştirmesi hem URL'i hem menüyü aynı anda bozar.

Hiyerarşi derinliği arttıkça tıklama sayısı da artar. Ana sayfadan beşinci seviyedeki bir sayfaya ulaşmak için dört tıklama gerekmesi, crawl bütçesi açısından sorun yaratmaz; kullanıcı deneyimi açısından yaratır. Mimari kararlar bu iki gerekliliği ayrı ayrı değil birlikte ele almalıdır.

Kanonik URL Sorunları ve İçerik Çoğaltma

CMS'lerin büyük bölümü aynı içeriği farklı URL'ler üzerinden erişilebilir kılar. WordPress'te bir yazı /yazi-adi/, /kategori/yazi-adi/ ve /?p=123 adreslerinin üçünden de ulaşılabilir olabilir. Varsayılan ayarlarla bunların hepsi geçerli URL'dir; kanonik etiket eklenmezse içerik çoğaltma riski oluşur.

İçerik çoğaltma kendi başına bir ceza mekanizması değildir. Arama motorları hangi URL'yi öne çıkaracağını seçer; ancak bu seçimi siz değil sistem yapar. Kanonik URL'i sizin belirlemeniz, crawl bütçesinin gereksiz varyantlar yerine asıl sayfalara harcanmasını sağlar. Filtreleme, sıralama ve sayfalama parametreleri eklendiğinde aynı içerik onlarca farklı URL altında görünebilir; bu noktada parametrelerin nasıl ele alındığı CMS yapılandırmasına bağlıdır.

Drupal'da yol takma adları (path alias) yanlış yapılandırıldığında hem eski yol hem yeni takma ad aktif kalabilir. Eski yolların 301 yönlendirmesi almadan açık bırakılması, özellikle göç sonrasında yaygın bir hatadır. WordPress WooCommerce kurulumlarında ürün varyantları bazen ayrı URL'ler üretir; bunların kanonikleştirilmesi tema değil eklenti düzeyinde yönetilir ve her eklenti güncellemesinde kontrol gerekir.

CMS Kısıtları Crawl Bütçesini Nasıl Etkiler

Crawl bütçesi, arama botlarının belirli bir süre içinde sitenizde tarayacağı sayfa sayısının pratikte sınırlı olmasıdır. Küçük siteler için bu sınır nadiren sorun yaratır; binlerce sayfalık kataloglarda veya sık güncellenen içerik sitelerinde belirleyici hâle gelir.

CMS'in ürettiği yardımcı sayfalar crawl bütçesini tüketir. Yazar arşiv sayfaları, etiket listeleri, tarih bazlı arşivler, boş arama sonuç sayfaları - bunların tümü bot tarafından ziyaret edilebilir URL'lerdir. WordPress'te yazar arşiv sayfaları varsayılan olarak açıktır; tek yazarlı bir sitede bu sayfalar içerik kopyaladığından robots.txt ile kapatılması ya da noindex etiketiyle işaretlenmesi önerilir.

Sayfalama da crawl bütçesi açısından dikkat gerektiren bir alandır. Kategori sayfaları çok sayıda ürün veya yazı içeriyorsa sayfalama URL'leri birikir. /kategori/page/47/ gibi derin sayfalama URL'lerini botların taramasının gerçek değeri düşüktür; ancak bu URL'lerin engellenip engellenmeyeceği ve nasıl işaretleneceği yine CMS yapılandırmasına bağlıdır.

Headless sistemlerde crawl bütçesi yönetimi tam anlamıyla geliştirici sorumluluğuna girer. Sitemap oluşturma, robots.txt yönetimi ve kanonik etiketler için ayrı araçlar veya özel kod gerekebilir. CMS'in sağladığı yerleşik araçlara artık güvenemezsiniz; her bileşeni ayrıca doğrulamanız gerekir.

CMS Seçimi Mimari Gereksinimden Başlamalı

Proje başlamadan önce şu soruları yanıtlamak seçimi netleştirir: Kaç farklı içerik türünüz var? İçerik türleri arasında ilişki kurmak gerekiyor mu? URL yapısında kaç hiyerarşi seviyesi gerekli? Filtreleme ve arama parametreleri URL'de görünecek mi? İçerik ekibi teknik olmayan kişilerden mi oluşuyor?

Basit blog veya içerik odaklı bir site için WordPress, olgun ekosistemi ve geniş eklenti tabanıyla makul bir seçimdir. URL yapısı kısıtları çoğu içerik senaryosunu karşılar; eklentilerle boşluklar kapatılabilir. Karmaşık ilişkisel içerik modeli, çok sayıda içerik türü veya kurumsal iş akışları gerektiren projeler için Drupal daha doğru zemin sağlar; ancak başlangıç maliyeti yüksektir ve teknik ekip gerektirir.

Headless sistemler esnekliği maksimize eder; ancak bu esneklik takım olgunluğu gerektirir. İçerik modeli, URL yapısı ve sitemap yönetimi merkezi olarak belgelenmez ve sürdürülmezse esneklik zamanla düzensizliğe dönüşür. Headless bir mimari için karar vermeden önce ekibin bu altyapıyı inşa edip sürdüreceğini somut olarak değerlendirin - soyut esneklik vaadi yeterli gerekçe değildir.

CMS göçü, yani bir sistemden diğerine geçiş, URL değişikliği anlamına gelir. URL değişikliği ise doğru yönlendirmeler yapılmadığında arama görünürlüğünde geçici - zaman zaman uzun süreli - düşüş anlamına gelir. Mevcut sitenizin URL yapısıyla uyumlu çalışan bir sisteme geçmek her zaman daha az risklidir; uyumsuz bir yapıya geçmek migrasyonu sadece teknik değil mimari bir proje hâline getirir.

Seçtiğiniz CMS uzun süre sitenizin kemik yapısını belirler. Arayüz ve şablon değiştirilebilir; içerik modeli ve URL şeması çok daha sert kısıtlar koyar. Bu kısıtları önceden görünür kılmak, sonradan pahalı düzeltme çalışmalarından kaçınmanın en pratik yoludur.