İçerik Yönetim Sistemi: Çok Siteli Bir CMS'i Kendimiz Yazarken Öğrendiklerimiz

İçerik yönetim sistemi, bir web sitesinin metnini ve görselini değiştirmek için yazılımcıya ihtiyaç duyulmasını ortadan kaldıran katmandır. Çözdüğü asıl problem 'sayfa yapmak' değil, sahipliktir: sitenin sahibi bir fiyatı, bir başlığı ya da bir duyuruyu kendisi değiştiremiyorsa o site zamanla eskir. Küçük düzeltmelerin bir başkasının takvimine bağlı olması, güncellemenin hiç yapılmamasının en yaygın sebebidir.

İkinci çözdüğü şey tutarlılıktır. Aynı bilgi bir sitede beş yerde geçer: ana sayfadaki kısa tanıtım, hizmet sayfasındaki uzun anlatım, altbilgideki iletişim satırı, paylaşım kartındaki açıklama, arama motoruna verilen özet. Bunlar ayrı ayrı elle yazıldığında biri güncellenir, dördü unutulur. İyi bir sistem aynı içeriği tek yerde tutar ve gerektiği yerlerde gösterir.

Bu yazıyı bir gözlemci olarak değil, bu problemin içinden geçen bir ekip olarak yazıyoruz. Vosetu CMS'i — tek kurulumdan birden fazla siteyi yayınlayan çok kiracılı içerik platformunu — kendi ihtiyacımızdan geliştirdik; okuduğunuz yaklaşımın hepsi kendi sitelerimizde çalışıyor. Aşağıda bir CMS'in bileşenlerini bir çerçeveye oturtacak, sonra her parçayı nasıl kurduğumuzu, nerede yanıldığımızı ve neyi bilinçli olarak sonraya bıraktığımızı anlatacağız.

Kendi platformumuzu yazmamızın sebebi tek bir siteye çözüm aramamız değil, aynı anda birçok siteyi yaşatmak zorunda olmamızdı. Bir kişisel site, bir ürün sitesi, birkaç sektör şablonu, müşteriler için açılacak siteler... Her biri için ayrı kurulum, ayrı güncelleme, ayrı yedek ve ayrı güvenlik takibi demek, sitelerin sayısı arttıkça geometrik büyüyen bir bakım yükü demekti. İhtiyacımız 'bir siteyi mükemmel yöneten' değil, 'onuncu siteyi birincisi kadar ucuz yaşatan' bir sistemdi.

İkinci sebep, içeriğin şeklini kendimizin belirlemek istemesiydi. Bir emlak sitesinin ilanı, bir danışmanlık sitesinin hizmeti ve bir kişisel sitenin projesi birbirine benzemez; her birini aynı 'yazı' kalıbına sokmak, sonradan hep zorlama alanlar ve sözde-çözümler üretir. Kendi modelimizi yazınca içerik tipini biz tanımladık ve alanları ihtiyacın kendisine göre şekillendirdik.

Üçüncü sebep en dürüst olanı: satacağımız ürünü kendimiz kullanmak istiyoruz. Bu platformun üzerinde yaşayan sitelerden biri, ürünün kendi tanıtım sitesi. Bir eksiği fark etmek için müşteri şikâyetini beklemiyoruz; kendi içeriğimizi girerken canımızı sıkan şey o hafta düzeliyor. Bu yazıdaki 'şurada zorlandık' cümlelerinin hepsi bu yüzden birinci elden.

Çok kiracılı bir sistemde her istek, önce 'bu hangi siteye ait' sorusuyla karşılanır. Bizim cevabımız alan adı oldu: ziyaretçinin tarayıcısının gönderdiği adres, kayıtlı sitelerin alan adlarıyla eşleştirilir ve o sitenin teması, dilleri ve içeriği yüklenir. Adres alt yol da olabilirdi, alt alan adı da; biz tam alan adı eşleşmesini seçtik çünkü müşteri sitesinin kendi adında yaşaması pazarlanabilir tek seçenekti.

Bu kararın en güzel sonucu, yeni site açmanın altyapı işi olmaktan çıkmasıdır. Yeni bir müşteri geldiğinde ne yeni bir sunucu kurulur ne yeni bir dağıtım yapılır: bir kayıt satırı, bir tema seçimi, bir alan adı yönlendirmesi. Tema da çalışma anında seçildiği için aynı süreç tek bir yazılım sürümüyle yürür — on sitede on ayrı sürümü güncel tutmak zorunda kalmazsınız.

Bedeli ise şudur: sistem artık 'hangi site' bilgisini her yerde taşımak zorundadır. Her içerik kaydı site kimliği tutar, her sorgu o kimlikle süzülür, her önbellek anahtarı siteyi içerir. Bir yerde bunu unutursanız hata sessizdir ve en kötü biçimde ortaya çıkar: bir kiracının içeriği başka bir kiracının sitesinde görünür. Bu yüzden site kimliği filtresini isteğe bağlı bir parametre değil, sorgunun doğal parçası hâline getirdik.

Bu, bir CMS yazarken verilecek en belirleyici karardır ve biz onu iki kez verdik. İlk sürümde her içerik tipinin kendi tablosu vardı: hizmetler bir tabloda, projeler başka bir tabloda, blog yazıları üçüncü bir tabloda. Temiz görünüyordu; ta ki bir siteye 'referanslar' eklemek gerekene kadar. Yeni tip demek yeni tablo, yeni model sınıfı, yeni uç, yeni ekran demekti — yani her içerik fikri bir yazılım sürümüne bağlıydı.

İkinci sürümde bütün içeriği tek bir yapıya taşıdık: her kayıt bir site, bir tip, bir anahtar ve serbest şemalı bir gövde taşır. Hizmet de, blog yazısı da, menü kalemi de, sayfanın blok kurgusu da aynı yapının farklı tipleridir. Bunun kazancı büyük oldu: yeni bir içerik tipi artık yazılım sürümü değil, bir tanım işidir. Eski tablolar veri taşındıktan sonra tamamen kaldırıldı — iki modeli aynı anda yaşatmak, en pahalı seçenek olurdu.

Dürüst olalım: esnek modelin bedeli de var. Veritabanı artık sizin için 'bu alan zorunlu' demiyor; doğrulama uygulama katmanının sorumluluğu oluyor ve şema ile gerçek veri zamanla birbirinden kayabiliyor. Biz bunu, alan tanımlarını ayrı bir şema katmanında tutup panel formunu o tanımlardan üreterek dengeliyoruz; yine de 'tek doğruluk kaynağı' konusunda uyanık olmak gerekiyor. Esneklik bedava değildir, sadece bedelini başka yerde ödersiniz.

İçeriği adreslemenin en iyi yolu, sitedeki yerini adres olarak kullanmaktır. Biz üç kademeli bir anahtar kullanıyoruz: sayfa, o sayfadaki bölüm ve bölümün alt alanı. 'İletişim sayfasının üst bandındaki başlık' bir arama sonucu değil, bir adrestir. Bu basit kural, panelde içeriği bulmak için gereken süreyi düşüren en büyük etken oldu — çünkü kullanıcı zaten sitenin yerleşimini biliyor, sistemin sözlüğünü öğrenmesi gerekmiyor.

Adreslemenin ikinci faydası, panelin kendisini üretebilmesidir. Anahtarlar noktalarla bölündüğünde ortaya doğal bir ağaç çıkar: sayfalar, altlarında bölümler, onların altında alanlar. Panel bu ağacı içerikten okur; ekranı elle çizmeyiz. Yeni bir bölüm eklendiğinde panelde de kendiliğinden belirir. Görünen adları ve sıralamayı ise ayrı bir yönetim katmanında tutuyoruz ki teknik anahtar ile insanın gördüğü etiket birbirine karışmasın.

Bu disiplinin bir maliyeti var ve onu saklamayacağız: kural, uygulandığı ölçüde işe yarıyor. Pilot sitemizde adresleme baştan sona titizlikle kuruldu ve panel orada gerçekten kendi kendini açıklıyor. Henüz yayında olmayan bazı şablon temalarda aynı titizlik yok; oralarda ağaç daha kaba görünüyor. Bunu bir eksiklik olarak biliyor ve tema tema kapatıyoruz — 'her yerde otomatik oluyor' demek kolay olurdu ama doğru olmazdı.

Bir platformun temaları birbirinin renk varyantı olduğunda, ürettiği bütün siteler akraba görünür ve bu, müşterinin fark ettiği ilk şeydir. Biz ters yönü seçtik: her tema kendi iskeleti, kendi bileşenleri ve kendi tipografisiyle sıfırdan tasarlanıyor. Bir emlak sitesiyle bir doğal taş üreticisinin sitesi arasında paylaşılan tek şey motor; görsel dil düzeyinde ortak nokta bilinçli olarak sıfır.

Bunun mümkün olması için motor ile temanın sınırını net çizmek gerekti. Motor tarafında olanlar: site çözümü, içerik okuma, dil yönetimi, sayfa meta bilgileri, site haritası, yapısal veri, ölçüm ve yerinde düzenleme köprüsü. Tema tarafında olanlar: tasarım, bileşenler ve hangi bloğun neye benzeyeceği. Bu sınır sayesinde yeni bir tema yazmak, CMS'i yeniden yazmak anlamına gelmiyor; tema yalnız görünümle ilgileniyor.

Karşılığında şunu kabul ediyoruz: yeni tema hâlâ kod işidir. Panelde renk seçip font değiştirilen görsel bir tema editörü yok ve yakın planda da yok — çünkü o araç, tasarımı şablonlaştırmadan çalışmıyor; şablonlaşan tasarım da ilk paragraftaki 'hepsi akraba görünüyor' sonucuna geri götürüyor. Seçim burada bilinçli: özgün tasarım uğruna bir kolaylıktan vazgeçtik.

Sayfa yapıcı, kullanıcıya ne kadar özgürlük verdiğine göre iyi ya da kötüdür. Boş bir tuvale her şeyi sürükleyebildiğiniz araçlar, birkaç ay sonra tasarımı bozuk sayfalar üretme eğilimindedir — çünkü hizalama, boşluk ve ritim gibi kararları tasarımcıdan alıp içerik girene devrederler. Biz sınırlı özgürlüğü seçtik: sayfanın blokları sıralanabilir, gizlenebilir, eklenebilir ve ayarlanabilir; ama bloğun kendi tasarımı temaya aittir.

Ayar tarafında en çok işe yarayan şey, blokların listelerle ilişkisini kurabilmek oldu: 'bu bölüm blog yazılarından son üçünü göstersin', 'şu bölüm yalnız öne çıkarılmış hizmetleri alsın'. Böylece içerik girildikçe sayfa kendini günceller; kimse ana sayfaya elle bağlantı eklemez. Yanına bir de bölünmüş ekranda canlı önizleme koyduk — değişiklik kaydedilmeden sonucun ne olacağı görünüyor.

Bunun da dürüst bir sınırı var: bir temanın sayfa yapıcıya açılması için bloklarının tanımlanması gerekiyor ve bu tanım tema başına yapılıyor. Bugün pilot temamızda blok listesi eksiksiz; bazı temalarda ise henüz boş ve orada sayfa kurgusu koddaki varsayılana düşüyor. Sistem bu durumda kırılmıyor, sadece o temada blok ayarı görünmüyor — ama 'her temada hazır' demek yanlış olurdu.

Yerinde düzenleme işe yarıyor, çünkü içerik girenin kafasındaki soru hep aynıdır: 'şu yazıyı nasıl değiştiririm'. Klasik panel bu soruyu bir arama problemine çevirir — hangi bölüm, hangi alan, hangi anahtar? Sitenin önizlemesinde metnin üstüne tıklayıp oracıkta düzeltmek ise soruyu tamamen ortadan kaldırır. Ekranda gördüğünüz şey ile düzenlediğiniz şey aynıdır.

Teknik olarak bunun kalbi bir köprüdür: önizleme, düzenleme kipinde açılır ve her düzenlenebilir metin kendi adresini taşır. Tıklanan öğe adresini panele bildirir, panel de ya doğrudan o alanı açar ya da metni yerinde düzenletir. Bu, adresleme disiplininin karşılığını aldığımız yerdir — içeriğin adresi olmasaydı tıklanan şeyin hangi kayda denk geldiğini bilemezdik.

Yanına cihaz önizlemesini de koyduk: aynı sayfayı masaüstü, tablet ve telefon genişliğinde görebiliyorsunuz. Bunun sebebi estetik değil, pratik: metin uzunluğu kararlarının çoğu telefonda verilmelidir. Masaüstünde zarif duran bir başlık, dar ekranda dört satıra bölündüğünde bambaşka bir şeye dönüşür ve bunu yayına aldıktan sonra fark etmek pahalıdır.

Çok dillilik zordur, çünkü çevrilmesi gereken şey yalnız içerik değildir. Bir sitede üç ayrı metin katmanı vardır: içeriğin kendisi (başlıklar, açıklamalar, yazılar), arayüzün sabit metinleri (buton yazıları, form etiketleri, 'sonuç bulunamadı' gibi durum cümleleri) ve makineye giden metinler (sayfa başlığı, açıklaması, paylaşım kartı). Çoğu proje ilkini çevirir, ikincisini koda gömer, üçüncüsünü unutur.

Biz üçünü de içerik katmanına aldık. İçerik alanları tek kayıtta çok dilli tutuluyor ve bir dil boş bırakıldığında sayfa kırılmıyor, ana dile düşüyor — yarım çevrilmiş bir site, hata veren bir siteden iyidir. Arayüz metinleri ise ayrı bir katman: 445 anahtarın tamamı site bazında değiştirilebiliyor, yani aynı butona bir sitede 'Teklif alın', başka bir sitede 'Randevu oluştur' dedirtebiliyorsunuz. Bu, çok kiracılı bir sistemde beklenenden çok daha sık gereken bir şey.

Çeviri işinin kendisine gelince: tek tıkla makine çevirisi koyduk ama onu bitmiş iş saymıyoruz. Makine çevirisi ilk taslağı üretir, insan düzeltir. Pratikte en çok işe yarayan da bu oldu — boş bir kutuya bakmakla, düzeltilecek bir metne bakmak arasındaki fark, içeriğin hiç çevrilmemesiyle iki günde çevrilmesi arasındaki farktır.

Çok siteli kurulumda SEO'nun ilk kuralı şudur: her site kendi dünyasını görmeli. Site haritası ve tarayıcı yönergesi statik dosya olarak durursa tek bir içerik üretirsiniz ve kiracılar birbirinin haritasını görür. Biz ikisini de isteğin geldiği adrese göre üretiyoruz — istek hangi siteye aitse, harita o sitenin yayınlanmış sayfalarını listeler. Kulağa küçük gelen bu ayrıntı, ilk kiracı ikinciyi aldığınız gün büyük bir soruna dönüşür.

İkinci kural, meta bilgisinin temaya bırakılmamasıdır. Sayfa başlığı, açıklaması, paylaşım kartı etiketleri, çok dilli karşılık bağlantıları ve yapısal veri motorun ortak katmanından gelir; tema yalnız görünümle ilgilenir. Sebebi basit: on temanın onunda da bu işi doğru yapmak, tek bir yerde doğru yapmaktan on kat daha zordur ve biri mutlaka eksik kalır.

Üçüncüsü, SEO'nun içerik girenin işi hâline gelmesidir. Panelde her sayfa için bir puan ve eksik alan uyarısı gösteriyoruz: başlık yok, açıklama kısa, adres anahtarı anlamsız. Yanına da meta metnini üreten bir yardımcı koyduk; yazıyı okur, 150–160 karakterlik bir açıklama önerir, kullanıcı düzeltir. Amaç kimseyi SEO uzmanı yapmak değil, en sık yapılan üç hatayı sayfa yayına girmeden yakalamak.

Bir CMS'te hızın kaynağı, sayfayı her ziyaretçi için yeniden üretmemektir. Sayfa bir kez üretilir, bir süre saklanır ve o süre boyunca herkese hazır hâlde sunulur. Bunun bedeli tazelik: içerik değiştiğinde sitenin güncellenmesi o sürenin dolmasını bekler. Doğru cevap 'her zaman anında' değildir — kurumsal bir sitede bir dakikalık gecikme kimsenin umurunda değilken, her isteği yeniden üretmenin faturası ciddidir.

Biz burada bir kere yanıldık ve dersini aldık. 'İçerik kaydedilince ilgili sayfa anında tazelensin' diye bir mekanizma kurduk; tek kopya çalışırken kusursuz işledi. Ancak site birden fazla kopya hâlinde çalıştığında tazeleme çağrısı yalnız birine ulaşıyor, diğerleri eski içeriği sunmaya devam ediyordu — yani bazı ziyaretçiler yeni, bazıları eski sayfayı görüyordu. Bu, gecikmeden daha kötü bir durumdur: tutarsızlık.

Şimdilik öngörülebilir olanı seçtik: kısa ömürlü önbellek, herkes için aynı davranış. Anında tazeleme yeniden gelecek ama bu sefer kopyalar arasında paylaşılan bir mekanizmayla. Buradan çıkardığımız genel ders şu: dağıtık bir sistemde 'anında' sözü vermeden önce, o sözü kaç kopyanın birden tutması gerektiğini sayın.

Çoğu site için hayır — sorulan soruların cevabı zaten sizin sunucunuzdan geçiyor. 'Bugün kaç kişi geldi, hangi sayfa okundu, nereden geldiler, hangi dilde ve hangi cihazla' sorularının hepsi, hiçbir dış servise veri göndermeden cevaplanabilir. Biz de öyle yaptık: sayfa görüntülemesi kendi veritabanımıza yazılıyor, panelde günlük grafik, en çok okunan sayfalar, kaynak ve cihaz dağılımı olarak görünüyor.

Bunun iki faydası var. Birincisi gizlilik: kişiyi tanımlayan bir veri toplamadığınızda, saklamak, açıklamak ve silmek zorunda olduğunuz bir yük de doğmaz. İkincisi doğruluk: reklam engelleyicilerin büyük kısmı dış ölçüm betiklerini durdurur, kendi sunucunuza giden istek ise durmaz. Yani daha az veri toplayıp daha doğru sayabilirsiniz.

Sınırını da söyleyelim: bu, pazarlama ekiplerinin kullandığı derin analitiğin yerine geçmez. Dönüşüm hunisi, kampanya atıfı, kullanıcı yolculuğu gibi ihtiyaçlar başlarsa dış bir araç gerekir. Bizim iddiamız şu: sitelerin büyük çoğunluğu bu ihtiyaçlara hiç gelmeden, yalnız 'hangi içerik ilgi görüyor' sorusunu sorar ve bunun için üçüncü tarafa gerek yoktur.

Formdan gelen mesaj, kaybolmayacağı bir yere düşmelidir; e-posta tek başına o yer değildir. Bir iletişim formunun içeriği doğrudan posta kutusuna gidiyorsa mesaj bir kişinin gelen kutusunda yaşar: o kişi izinliyse görülmez, silinirse geri gelmez, ikinci bir kişi bakamaz. Biz gönderimleri önce sisteme yazıyoruz — panelde forma göre gruplanmış bir gelen kutusunda, okundu bilgisiyle birlikte duruyorlar.

Form yapısını da serbest bıraktık: her formun kendi anahtarı ve kendi alanları var, gövde serbest şemalı saklanıyor. Böylece 'iletişim' formuyla 'teklif iste' formu aynı hattı kullanıyor ama farklı alanlar topluyor; yeni bir form eklemek kod işi olmaktan çıkıyor. Dışarıya açık her uç gibi burası da baştan korunuyor — kötüye kullanıma karşı sessiz tuzak alan ve hız sınırı var.

Eksiğimizi de yazalım: mesaj geldiğinde site sahibine otomatik e-posta gitmiyor; bugün panelden kontrol ediliyor. Bunu bilinçli olarak sonraya bıraktık, çünkü çok kiracılı bir kurulumda 'kimin adına, hangi sunucudan, hangi alan adıyla' e-posta gönderileceği başlı başına bir tasarım işidir ve yarım yapılmış e-posta gönderimi, spam klasörüne düşen bir bildirimden ibarettir.

Birincisi, esnek içerik gövdesini veritabanına doğru yazmaktı. Serbest şemalı bir gövde saklarken, verinin metin olarak değil yapı olarak kaydedilmesi gerekiyor; bu ayrımı kaçırdığınızda kayıt görünüşte başarılı olur, okuma tarafında ise beklediğiniz yapı yerine düz bir metin bulursunuz. Hatayı yakalamak zordu çünkü hiçbir yerde istisna fırlamıyordu — sadece içerik 'bir şekilde' yanlış görünüyordu.

İkincisi, kiracı çözümünün altyapıya bağımlı olmasıydı. Sistem hangi siteye ait olduğunu isteğin taşıdığı adresten anlıyor; araya giren bir ara sunucu bu bilgiyi kendi adıyla değiştirirse platform yanlış siteyi açar. Üstelik bu 'hata' bir hata gibi görünmez: site açılır, sadece yanlış site açılır. Bunu bir kez yaşadıktan sonra kuralı yazılı hâle getirdik — adres bilgisi zincir boyunca korunmalı.

Üçüncüsü, şema ile verinin birlikte yaşlanmasıydı. Alan tanımları bir yerde, gerçek içerik başka yerde durduğunda ikisi zamanla ayrışıyor: panelde görünmeyen ama veride duran alanlar, ya da tanımlı olduğu hâlde hiç doldurulmamış alanlar. Bunu katmanlı bir geri-düşme kuralıyla (tanım yoksa genel tanım, o da yoksa güvenli varsayılan) yönetiyoruz ama tek doğruluk kaynağını netleştirmek hâlâ açık bir iş.

Dördüncüsü en insani olanıydı: paneli, içeriği girecek kişinin diliyle konuşturmak. Teknik anahtarlar geliştiriciye anlamlı gelir, içerik girene hiçbir şey ifade etmez. Görünen adları ve sıralamayı ayrı bir katmana taşımak, ardından paneli sitedeki yerleşim sırasına göre dizmek, aslında kod değil sabır işiydi — ve panelde geçirilen süreyi en çok düşüren değişiklik de bu oldu.

Bugün platform, tek kurulumdan alan adı bazlı çözümle siteleri servis ediyor; kayıtlı tema sayısı on, içerik tipi on üç, yayın dili üç ve site bazında değiştirilebilen arayüz metni dört yüz kırk beş. Yönetim yüzü Vosetu Studio'da yerinde düzenleme, sayfa düzenleyici, içerik ağacı, menü düzenleyici, form gelen kutusu, arayüz metinleri, SEO asistanı ve ziyaret istatistikleri var. Bu platformun üzerinde yaşayan sitelerden biri, ürünün kendi tanıtım sitesi.

Olmayanları da aynı netlikle sayalım. Medya kütüphanesi yok: dosya yükleme akışı henüz bağlanmadı, bugün görseller tema varlıkları ya da dış bağlantı olarak kullanılıyor. İçerik sürüm geçmişi ve geri alma yok. Ayrıntılı rol-izin yönetimi yok; yetkilendirme yönetici ile site sahibi ayrımından ibaret. Ziyaretçiye yönelik site içi arama, yorum sistemi ve çerez rızası bildirimi de yok.

Bunları eksik olarak yazıyoruz çünkü bir platformun olgunluğu, sahip olduğu özelliklerin listesinden çok, sahip olmadıklarını söyleyip söylemediğiyle ölçülür. Yol haritasının başında medya kütüphanesi ve form bildirimleri var; ikisi de 'yakında' derken bir tarih vermek yerine, hazır olduğunda burada yazacağımız türden işler.

Bir: içeriğinizin şeklini siz mi belirliyorsunuz, sistemin hazır kalıplarına mı uyuyorsunuz? İki: sitenizin tasarımı, o sistemi kullanan diğer sitelerden ayırt edilebiliyor mu? Üç: bir metni değiştirmek kaç tıklama sürüyor — ve bunu içerik girecek kişiye denettiniz mi? İlk üç soru, sistemin bir yıl sonra hâlâ kullanılıp kullanılmayacağını belirler.

Dört: birden fazla siteniz olursa ne oluyor — her biri ayrı kurulum, ayrı güncelleme mi? Beş: çok dilli yayında arayüz metinleri de çevrilebiliyor mu, yoksa yalnız içerik mi? Altı: SEO'nun temel işleri (başlık, açıklama, adres anahtarı, site haritası, çok dilli karşılıklar, yapısal veri) hazır mı geliyor, yoksa her sayfa için elle mi kuruluyor?

Yedi: içeriğinizi istediğiniz gün eksiksiz dışarı alabiliyor musunuz? Bu soru sıkıcı görünür ama bütün diğerlerinin sigortasıdır: veriniz yapılandırılmış hâlde elinizdeyse, sistemden memnun kalmadığınız gün taşınmak bir proje olur; değilse bir kurtarma operasyonu.

Bir içerik yönetim sistemi, sitenin sahibine sitesini geri veren araçtır. Bunu başarması için üç şeyi aynı anda yapması gerekir: içeriği o kişinin zihnindeki yerleşime göre adreslemek, tasarımı bozulmaya karşı korumak ve makinelere gidecek bilgiyi (meta, harita, yapısal veri) kimseye sormadan doğru üretmek. Vosetu CMS'i geliştirirken zamanımızın çoğu bu üçünün arasındaki dengeye gitti; özellik eklemek hep daha kolay olanıydı.

Platform bugün bulutta abonelikle ya da kendi sunucunuzda kurulu çalışıyor; eksikleri açıkça işaretli ve yol haritası kendi kullanımımızın ritmiyle ilerliyor. Kaç siteniz olduğunu, hangi dillerde yayın yapacağınızı ve tasarımın nereye oturması gerektiğini anlatırsanız, kurgunun size uyup uymadığını birlikte konuşalım.