CMS İçerik Modeli: Kurumsal Web Siteleri İçin Content Type ve Field Tasarımı

CMS içerik modeli; içerikleri (sayfa, blog, oda, paket, kampanya, case study vb.) content type’lara ayırıp her tipin alanlarını (fields) ve ilişkilerini (relations) tanımlama disiplinidir. Bu disiplin iyi kurulmadığında; editoryal ekip her içerikte farklı ekranlar görür, geliştirici ekip her sayfa tipinde yeni koşullar yazar, SEO tarafında meta ve schema tutarsızlaşır. İyi kurulduğunda ise aynı içerik “panelde net”, “kodda öngörülebilir” ve “SERP/SGE’de daha tutarlı” görünür.

Bu noktada kritik fikir şu: CMS’i “panel” değil, ürünün veri sözleşmesi (content contract) olarak düşünmek. Çünkü Next.js gibi modern framework’lerde sayfa üretimi; verinin şekline, zorunluluklarına, lokalizasyonuna ve cache mantığına bağlıdır. Yanlış model, performansı ve sürdürülebilirliği doğrudan etkiler.

CMS içerik modeli neden “yeniden mimari” ihtiyacını azaltır?

İçerik modeli proje başında doğru tasarlanan sitelerde, yeni sayfa/özellik eklerken “CMS yetmiyor, tablo değiştirelim” ihtiyacı belirgin şekilde azalır. Bunun nedeni; içerik tipleri ve field setlerinin, yalnız bugünü değil 6/12 aylık roadmap’i taşıyacak şekilde kurgulanmasıdır. “Genelde/çoğu projede” en pahalı revizyonlar; URL/slug değişiklikleri, ilişki alanlarının sonradan eklenmesi ve çok dilli yapıların geç düşünülmesinden çıkar.

CMS içerik modeli nedir, nasıl tasarlanır?

• •Envanter: Hangi içerikler var ve hangileri büyüyecek?
• •Sözleşme: Hangi tip hangi alanları zorunlu kılar?
• •Governance: Kim hangi alanı doldurur, kim onaylar?
• •Versioning: Model değişirse migration nasıl yapılır?

Content type tasarımı, “panelde kaç menü var?” sorusu değil; hangi içerikler farklı yaşam döngüsüne ve farklı şablona sahip? sorusudur. Bir content type; hem editoryal ekranı hem de front-end şablonunu temsil eder. İçerik türleri karışırsa, editoryal ekip doğru alanı bulamaz; geliştirici ekip de “her ihtimal” için kod yazar.

Hangi içerikler için ayrı content type açmalıyım?

• •Farklı şablon: Oda sayfası ile blog aynı olamaz.
• •Farklı SEO alanları: “Hizmet sayfası” ile “SSS” meta yapısı değişir.
• •Farklı ilişki: Oda→paket→kampanya gibi ilişkiler blogdan farklıdır.
• •Farklı workflow: Case study onay süreci blogdan farklı olabilir.

Otel sitesi için örnek content type seti

• •Room (Oda): kapasite, metrekare, özellikler, galeri, fiyat/CTA, sezon etiketi
• •Package (Paket): tarih aralığı, dahil olanlar, fiyat bandı, şartlar
• •Destination (Destinasyon): bölge, ulaşım, harita, deneyimler
• •Campaign (Kampanya): teaser/launch/reminder alanları, bitiş tarihi
• •FAQ: soru/cevap tekrar eden yapı
• •Blog: kategori/etiket, yazar, okuma süresi, içerik blokları

B2B kurumsal site için örnek content type seti

• •Service (Hizmet): problem–çözüm, süreç, deliverables, CTA blokları
• •Case Study: problem/müdahale/sonuç + KPI kartı
• •Reference/Partner: logo, sektör, proje türü
• •Resource (Rehber/İndirilebilir): asset yönetimi
• •FAQ: satış engellerini çözen soru seti
• •Blog: thought leadership + how-to

Field tasarımı; “hangi alanlar var?” değil, hangi alanlar zorunlu, hangileri opsiyonel, hangileri standardize? sorusudur. İyi bir field seti; editoryal ekibi korur (yanlış veri girişi azalır) ve front-end tarafını hızlandırır (her sayfa için özel koşul yazma ihtiyacı düşer).

Field seviyesinde zorunlu/opsiyonel alanlar nasıl belirlenir?

Zorunluluk, genelde üç şeye göre belirlenir: SEO, sayfa şablonu, iş akışı. Örneğin blogda “kapak görseli” zorunlu olabilir; ama “Video” opsiyonel kalabilir. Service sayfasında “Primary CTA” zorunludur; “Secondary CTA” roadmap’e göre opsiyonel kalabilir.

Önerilen field kategorileri (genel)

• •Identity: title, slug, locale, status (draft/published)
• •Content: summary, body (rich text / block editor), sections
• •Media: cover image, gallery, video, attachments
• •SEO: meta title, meta description, canonical, robots, OG image
• •Relations: category, tags, related posts, related services
• •Governance: author, reviewer, publish date, version

SEO/Meta alanları (schema ve SERP uyumu)

Kurumsal projelerde en sık hata: SEO alanlarını içerik alanına karıştırmak. SEO alanları her içerikte standart olmalı ve şunları kapsamalı: Meta Title/Meta Description, Canonical URL (özellikle benzer içerikler), OG Image ve sosyal paylaşım alanları, Index/noindex, follow/nofollow, Structured data tetikleyicileri (ör. FAQ var mı?). Teknik SEO Notu ile uyum: URL/slug standardı, schema kurgusu ve çok dilde hreflang yaklaşımı içerik modelinin parçası olmalı.

Media ve relation alanları: Ne zaman şart?

Media alanlarını “görsel yükledik bitti” diye düşünmeyin. Hero, OG, kart görselleri ve galeri farklı ihtiyaçlardır. Relation alanları ise içerikleri birbirine bağlayarak hem kullanıcı deneyimini hem internal linking’i güçlendirir: Blog → Service ilişkilendirme (iç link hedefleri), Room → Package, Destination ilişkisi (otel bağlamı), Case Study → Service, Sector ilişkisi (B2B bağlamı).

Bu bölüm, rakiplerin çoğunun atladığı “ileri tasarım” katmanını kapatır: yalnız içerik tipi saymak yerine, modeli büyüten ilişkileri ve SEO sözleşmesini netleştirir. Otel projelerinde oda/paket/destinasyon ilişkileri; B2B projelerinde service/case/reference ilişkileri kritik fark yaratır.

Otel modeli örneği (Room–Package–Destination–Campaign)

Aşağıdaki model, Türkiye’de özellikle Antalya, Belek, Side, Kemer, Bodrum gibi destinasyon odaklı aramalarda “yerel sayfa + deneyim + teklif” mimarisini taşır:

• •Room → (relation) Package (çoklu)
• •Package → (relation) Campaign (opsiyonel)
• •Destination → (relation) Room / Package (çoklu)
• •Blog → (relation) Destination / Service (çoklu)
• •FAQ → hem Service hem Room altında yeniden kullanılabilir

B2B modeli örneği (Service–Case Study–Reference–FAQ)

B2B tarafında amaç; “hizmet + kanıt + süreç + SSS” ile satış engellerini kırmaktır:

• •Service → (relation) Case Study (çoklu)
• •Case Study → (relation) Reference/Partner (çoklu)
• •FAQ → Service’lere bağlanır
• •Blog → Service’lere bağlanır (otorite → dönüşüm yolu)

Örnek içerik modeli tablosu (1 tablo – Media Pack ile uyumlu)

CMS modeli iyi olsa bile, veri akışı ve yayınlama mimarisi doğru değilse ekipler yine zorlanır. Next.js tarafında amaç; CMS’den gelen veriyi öngörülebilir, cache’lenebilir, çok dilli ve SEO uyumlu bir şekilde sayfaya dönüştürmektir. Bu yüzden “schema-aware modelling” yaklaşımıyla, model ve front-end sözleşmesi birlikte düşünülmelidir.

Veri akışı planı (önerilen)

• •Draft/Preview: içerik ekibi ön izleme görür (staging/preview)
• •Publish: publish tetikleyince cache invalidation (revalidate) çalışır
• •SEO üretimi: meta + canonical + OG + schema aynı sözleşmeden gelir
• •i18n: locale bazlı slug, hreflang ve içerik fallback kuralları belirlenir

URL/Slug, hreflang, schema uyumu (Technical SEO)

İçerik modeli; slug’ı yalnız “metin alanı” olarak değil, URL sözleşmesi olarak ele almalıdır. Çok dilli projelerde slug yönetimi kritikleşir: örneğin TR/EN içerikler birebir aynı olmaz; hreflang mantığı ve canonical kuralları baştan tanımlanmalıdır. Ayrıca schema türleri (FAQ/HowTo/Article/Service) CMS’de “tetikleyici alanlar” ile yönetilirse, front-end tarafında manuel iş azalır.

İç link uyumu: Bu yaklaşımın altyapı mantığı /tr/yazilim/web-sitesi-gelistirme ve içerik stratejisi /tr/seo/icerik-seo ile birlikte ele alınmalıdır.

Rakip içeriklerin çoğu CMS’i sadece “panel” olarak anlatıyor; oysa sürdürülebilirlik versioning + migration + governance ile gelir. “Yeni bir content type eklemek” kaçınılmazdır; önemli olan bunu kontrollü yapmak. Yılda en az 1 kez (Refresh Cycle: 365) model gözden geçirilmeli; yeni içerik tipleri ve SEO ihtiyaçları geldikçe field setleri versioned şekilde güncellenmelidir.

CMS içerik modelini doğru kurduğunuzda, içerik ekibi daha hızlı ve hatasız üretim yapar; Next.js tarafında sayfa üretimi daha öngörülebilir hale gelir; SEO/meta ve schema çıktıları tutarlı olur. En büyük kazanım ise şudur: 6/12 aylık roadmap büyüdüğünde bile “yeniden mimari” ihtiyacı azalır.