CMS koleksiyonları: siteyi içerikten ayırmak

Perşembe 14:40. Yirmi iki şubeli bir servis zincirinin pazarlama sorumlusu, yeni açılan şubeyi siteye eklemek için sayfa editörünü açıyor. Şube listesi sayfanın içine elle kurulmuş yirmi iki karttan oluşuyor; yirmi üçüncüsü için kartlardan biri kopyalanacak, metni değiştirilecek, sıralama bozulmadan araya yerleştirilecek. Aynı hafta bir başka şubenin telefonu değişmiş: numara ana sayfada, iletişim sayfasında ve bölge açılış sayfasında ayrı ayrı yazılı olduğu için üç yerde düzeltilmesi gerekiyor. İşin tamamı yirmi dakikalık bir güncelleme gibi görünüyordu; üç saat sürüyor ve bir yerde eski numara kalıyor. Rakamlar örnek, tablo tanıdık.

Bu yazı o üç saati yirmi dakikaya indiren ayrımla ilgili: içeriği sayfanın içinden çıkarıp ayrı bir yerde, kendi alan şemasıyla tutmak. Sırayla şunlara bakacağız: bir içerik güncellemesi neden tasarım işine dönüşür, hangi içerik koleksiyona girer hangisi sayfada kalır, alan şeması nasıl kurulur, veri nereden beslenir, liste ve detay sayfaları tek düzenden nasıl üretilir, çok dilli yayında eksik çeviri nasıl engellenir, değişiklik yayına nasıl çıkar ve nasıl geri alınır, koleksiyon kaydıyla CRM kaydı nerede ayrışır, arama motoru bu sayfaları nasıl görür, ayrımın işe yaradığı hangi ölçümle anlaşılır ve ilk koleksiyon hangi sırayla kurulur.

Bir içerik güncellemesi neden tasarım işine dönüşür?

Çünkü içerik sayfanın içinde saklanır. Bir hizmet kartının başlığı, açıklaması ve fiyat aralığı bir bölümün kutucuklarına yazıldığında o metin artık bir veri değil, bir yerleşim parçasıdır. Metni değiştirmek için yerleşimi açmanız, doğru kutucuğu bulmanız ve yanlışlıkla başka bir şeyi kaydırmadan çıkmanız gerekir. On kartla bu katlanılabilir; kırk kartla, üç dille ve iki farklı sayfada tekrarlanan aynı listeyle katlanılmaz hale gelir.

İkinci maliyet görünmez olanıdır: aynı bilginin kaç kopyası olduğunu kimse bilmez. Şubenin telefonu üç sayfada yazılıysa, o üç sayfayı hatırlayan kişi ekipten ayrıldığında bilgi de gider. Bir süre sonra site, kimsenin tam envanterini çıkaramadığı bir metin yığınına döner ve “güncelledik mi?” sorusunun cevabı ancak tek tek bakarak bulunur.

Çözümün adı basit: içeriği yapılandırılmış kayıtlar olarak bir kez tanımlayıp sayfaya yalnızca “şu kayıtları şu düzende göster” talimatını bırakmak. Bunu ayrı bir başlıksız içerik sistemi kurarak da yapabilirsiniz, sitenizin kurulduğu yerde de. Karar, entegrasyonun maliyetiyle bağımsızlığın değerini tartmaktır; yerel bir çözümle üçüncü parti bir araç arasındaki seçimin nasıl yapıldığına dair ölçütler burada da geçerlidir. Küçük ve orta ölçekte tartıyı çoğunlukla “aynı yerde” tarafı kazanır: bir sistem daha az, bir kimlik doğrulama daha az, bir yayın akışı daha az.

Hangi içerik koleksiyona girer, hangisi sayfada kalır?

Ayrımın tek bir işareti var: aynı biçimde birden fazla kez tekrar ediyor mu? Hizmetler, şubeler, ekip üyeleri, ürünler, referanslar, açık pozisyonlar, blog yazıları, etkinlikler — hepsi aynı alanları farklı değerlerle taşır. Bunlar koleksiyondur. Buna karşılık ana sayfanın kapak metni, hakkımızda anlatısı ya da bir kampanyaya özel açılış sayfası tek nüshadır ve bir şemaya sığdırmaya çalışmak yalnızca ekstra iş çıkarır.

İkinci işaret güncelleme sıklığı ve sahibidir. Yılda bir değişen ve pazarlama ekibinin elinden çıkan bir metin sayfada durabilir. Haftada birkaç kez değişen ve operasyondan gelen bir liste durmamalıdır, çünkü her değişiklikte sayfa editörünü açacak kişi darboğaz olur. Aynı içeriği başka kanallarda da kullanacaksanız ayrım daha da değerlidir: yapılandırılmış kayıtlar, tek içerikten birden çok parça üretme alışkanlığının altyapısıdır; kaynak metin sayfada gömülü olduğunda yeniden kullanmak kopyalamaktan ibaret kalır.

İçerik	Tekrar	Kim günceller	Nerede durmalı
Şube bilgileri	Her şube için aynı alanlar	Operasyon	Koleksiyon
Hizmet kartları	Her hizmet için aynı alanlar	Pazarlama	Koleksiyon
Ürün kataloğu	Yüzlerce kayıt, dış kaynak	ERP / ticaret ekibi	Koleksiyon, dışarıdan beslenir
Kampanya açılış sayfası	Tek nüsha, kısa ömürlü	Pazarlama	Sayfa
Hakkımızda anlatısı	Tek nüsha, nadiren değişir	Yönetim	Sayfa

Alan şemasını nasıl tasarlarsınız ki altı ay sonra bozulmasın?

Şema tasarımının ilk kuralı, bir alanın tek bir soruya cevap vermesidir. “Adres” diye tek bir serbest metin alanı açtığınızda, altı ay sonra şehre göre filtrelemek istediğinizde elinizde ayrıştırılacak bir metin yığını olur. Şehir, ilçe, açık adres ve posta kodu ayrı alanlar olduğunda hem liste filtresi hem harita bağlantısı hem de yapılandırılmış veri kendiliğinden mümkün olur.

İkinci kural, görünüşü şemaya karıştırmamaktır. “Kart rengi” ya da “kalın yazılsın mı” gibi alanlar içeriğe değil düzene aittir; şemaya girdiklerinde tasarım değiştiğinde yüzlerce kaydı elden geçirmek zorunda kalırsınız. Şemada yalnızca bilgi durur: ad, özet, uzun metin, görsel, kategori, sıra numarası, yayın durumu.

Üçüncü kural, zorunlu alanları cömertçe işaretlememektir. Her alanı zorunlu yapan şema, kaydı eksik veriyle taslakta tutmayı imkansızlaştırır ve insanlar boş alanları noktayla doldurmaya başlar. Ad, özet ve görsel gibi listede görünen alanlar zorunlu olsun; geri kalanı isteğe bağlı kalsın. Rocketly tarafında bu yapı CMS Koleksiyonları ile kurulur: hizmetler, şubeler, ekip üyeleri ya da ürünler gibi tekrar eden içerikleri bir kez alan şemasıyla tanımlar, sonra sayfaya yalnızca koleksiyon bloğunu koyarsınız — liste otomatik dolduğu için içerik güncellemesi artık sayfayı yeniden tasarlamayı gerektirmez.

İçerik nereden beslenir: elle giriş, ERP, tablo dosyası?

Küçük koleksiyonlar için elle giriş en ucuz yoldur. Yirmi şube, on iki hizmet ya da otuz ekip üyesi tek seferde girilir ve ayda birkaç kez elle güncellenir; bunun için otomasyon kurmak, kurulum maliyetini asla geri kazanmayan bir yatırımdır.

Ürün kataloğu gibi büyük ve otoritesi başka bir sistemde olan koleksiyonlarda durum tersine döner. Stok kodu, fiyat kademesi ve teknik özellik zaten ERP tarafında tutuluyorsa, siteye elle kopyalanan her kayıt bir gün mutlaka sapar. Böyle bir koleksiyonda kural nettir: kaynak sistem yazar, koleksiyon okur, sitedeki alanlar elle düzenlenmez.

Arada kalan durumlar için tablo dosyası pratik bir köprüdür. Pazarlama ekibi kayıtları alışık olduğu yerde hazırlar, senkron işi de dosyayı düzenli olarak koleksiyona taşır; tablo ile sistem arasındaki senkronizasyonun kurulum kuralları burada da aynıdır: tek yönlü akış, sabit kolon başlıkları, satır başına değişmeyen bir kimlik. Kimlik yoksa her içe aktarma kayıt kopyalar.

Birden fazla kaynak varsa — ERP'den ürün, pazaryerinden stok, bir dosyadan açıklama — akışı ayrı ayrı kurmak yerine tek bir orkestrasyon katmanına toplamak daha yönetilebilirdir; entegrasyon platformlarının ne zaman gerektiği tam olarak bu eşikte tartışılır.

Hangi yolu seçerseniz seçin, besleme işini kaynak sistemin sınırlarına saygılı kurun: gece toplu bir çekim, gün içinde yalnızca değişenleri gönderen küçük paketler ve tekrar denemede artan bekleme süresi. Hız limitleri ve kota yönetimi ihmal edildiğinde ilk büyük içe aktarma, bütün gün boyunca reddedilen isteklerle geçer.

Liste ve detay sayfaları tek düzenden nasıl üretilir?

Koleksiyonun asıl kazancı burada görünür. Liste sayfası bir düzendir: kaç sütun, hangi alanlar görünür, sıralama neye göre, filtre var mı. Detay sayfası da bir düzendir: başlık, görsel, uzun metin, iletişim bloğu, ilgili kayıtlar. İki düzeni bir kez kurarsınız; kayıt sayısı yüze de çıksa sayfa sayısı sizin için ikidir.

Pratikte üç ayrıntı işi kurtarır. Birincisi boş durum: kategoriye ait hiç kayıt yoksa liste ne gösterecek? İkincisi sıralama kuralı: elle sıra numarası mı, tarihe göre mi, alfabetik mi? Üçüncüsü uzunluk toleransı: kart başlığı iki satıra taştığında düzen kırılıyor mu? Bu üçü test edilmeden yayına çıkan liste, ilk gerçek veri girişinde bozulur.

Aynı mantık müşteriye dönük sayfaların ötesine de geçer. Bayilere açılan bir katalogda ürün listesi koleksiyondan gelirken sipariş akışı ayrı bir uygulamadır; bayi sipariş portalı kurarken içerik tarafını koleksiyona, işlem tarafını uygulamaya bırakmak ikisini birbirinden bağımsız güncellenebilir kılar. Rocketly'de sayfa iskeleti Site Studio Bölüm Editörü ile kurulur: kapak, özellik listesi, SSS, form gibi bölümler sıralanır, her bölümün yerleşim varyantı seçilir ve kritik bölümler kilitlenerek yetkisiz düzenlemeye kapatılır.

Çok dilli koleksiyonda eksik çeviri yayına nasıl sızmaz?

Çok dilli içerikte en sık görülen hata, çeviriyi kaydın kopyası olarak tutmaktır. İki ayrı kayıt oluşturduğunuzda bir gün biri güncellenir diğeri unutulur ve iki dil birbirinden farklı bir gerçeklik anlatmaya başlar. Doğru kurgu tek kayıt, dile göre değişen alanlardır: kimlik, kategori ve görsel ortak; başlık, özet ve metin dile bağlı.

İkinci mesele eksik çevirinin ne yapacağıdır. Üç seçenek vardır: kaydı o dilde listeden gizlemek, ana dildeki metni göstermek ya da yayını engellemek. Kurumsal sitelerde en güvenli varsayılan gizlemektir; yarım çevrilmiş bir kart, olmayan bir karttan daha kötü bir izlenim bırakır.

Bu kararın elle takip edilmesi zordur, çünkü eksik alan yayın gününde kimsenin baktığı yerde değildir. Rocketly'de Yayın Öncesi Denetim bu işi devralır: eksik sayfa başlığı, eksik açıklama ya da bir dilde tamamlanmamış metin bulgu olarak listelenir ve engelleyici bulgular giderilmeden sürüm hazırlanamaz. Yani yarım kalmış bir çeviri yayın düğmesine kadar gelemez.

Koleksiyon değişikliği yayına nasıl çıkar ve nasıl geri alınır?

Burada bir gerilim vardır. İçeriği sayfadan ayırmanın amacı hızlı güncellemedir; ama her kayıt düzenlemesi anında yayına çıkarsa yanlış yazılmış bir fiyat aralığı ya da yarım bırakılmış bir açıklama da anında yayına çıkar. Çözüm, düzenleme ile yayının aynı an olmamasıdır.

Rocketly'de yayınlanan şey taslağınız değil, o anın dondurulmuş kopyasıdır: Sürüm ve Dondurulmuş Anlık Görüntü yaklaşımında sürüm numarası alınır ve içeriği bir daha değişmez; siz taslakta çalışmaya devam ederken ziyaretçi yayın düğmesine basılana kadar eski sürümü görür. Riskli bir değişiklikte Tek Tıkla Geri Alma önceki sürüme döner ve bekleyen zamanlanmış yayını da temizler, böylece iki karar birbirini ezmez. Kimin yayınlayabileceğini kısıtlamak isterseniz İnceleme ve Onay Politikası ile yayın için hangi rollerin onayının gerektiğini belirlersiniz.

Beslenen koleksiyonlarda bir soru daha çıkar: kaynak sistem ile sitedeki kayıt aynı anda değiştiyse hangisi kazanır? Bu, klasik bir çakışma sorusudur ve baştan yazılı bir kurala bağlanmadığında sessiz veri kaybına dönüşür; iki yönlü senkronizasyonda kimin kazanacağı kuralını koleksiyon başına değil alan başına tanımlamak en sağlam yoldur. Fiyat her zaman ERP'den, pazarlama metni her zaman siteden gelsin gibi.

Koleksiyon kaydı CRM kaydının yerine geçer mi?

Geçmez, ve bu ayrım gözden kaçtığında en pahalı hatalar yapılır. Koleksiyon, halka açık ve okunmak için var olan içeriktir: bir hizmetin tanımı, bir şubenin adresi, bir ürünün özellikleri. CRM kaydı ise kişiye ait, gizli ve süreç taşıyan veridir: lead, fırsat, teklif, randevu. Birincisi herkese gösterilir, ikincisi yetkiye göre gösterilir.

Pratik sonuç şudur: sitedeki form doğrudan CRM'e yazmamalıdır. Rocketly'de Formlar CRM'e Bağlanır akışında gönderim önce siteye özel bir gönderim kutusuna düşer, oradan alan eşlemesiyle bir iş akışına bağlanır ve kayıt öyle açılır; yayına almadan önce kuru bir deneme çalıştırıp eşlemenin doğru olduğunu görürsünüz. Uygulamaların hangi kayıt tiplerine dokunabileceği CRM Veri Kapsamı ile tek tek seçilir ve kapsam değişikliği denetim kaydına yazılır. Dışarıdan besleme yapan bir servis varsa erişimi aynı titizlikle sınırlayın; API anahtarlarının kapsamı ve saklanması koleksiyon beslemesi için de geçerlidir, çünkü içerik anahtarı ile veri anahtarı aynı olduğunda bir sızıntı iki alanı birden açar.

Müşteri davranışını tek yerde birleştirme ihtiyacı büyüdüğünde soru ayrı bir sisteme kayar; müşteri veri platformunun CRM'den farkı tam da bu sınırda netleşir. Ama site içeriği için bu tartışmaya girmeye gerek yoktur: koleksiyon içerik içindir, kişi verisi için değil.

Arama motoru koleksiyondan üretilen sayfaları nasıl görür?

Koleksiyondan üretilen detay sayfaları, arama açısından en değerli sayfalar olabilir: her biri belirli bir hizmete, şubeye ya da ürüne karşılık gelir ve niyeti dar bir sorguyu yanıtlar. Bunun karşılığını alabilmek için üç şey gerekir. Birincisi sayfanın sunucuda render edilmesi, yani başlık ve açıklamanın tarayıcı JavaScript çalıştırmadan HTML'in içinde bulunması. İkincisi her kaydın kendi kalıcı adresi olması. Üçüncüsü başlık ve açıklamanın kayıt alanlarından türetilmesi.

Üçüncü madde küçük görünür ama koleksiyonun tüm avantajını taşır: “{ad} — {şehir} şubesi” gibi bir kalıp kurduğunuzda yüz kaydın yüz farklı başlığı otomatik oluşur. Rocketly'de Arama Motoru Görünürlüğü tarafında halka açık sayfalar sunucuda render edilir; başlık, açıklama, canonical, hreflang ve yapılandırılmış veri HTML'in içinde gelir, yayınlanan her sitenin kendi sitemap.xml ve robots.txt dosyası olur ve dizine ekleme tercihi sayfa bazında verilir.

Bir uyarı: koleksiyon kolay sayfa ürettiği için ince içerik üretmesi de kolaydır. Yalnızca ad ve iki cümleden oluşan iki yüz kayıt, iki yüz zayıf sayfa demektir. Ölçüt basit: bir kaydın kendi sayfası, o kayda özgü en az bir gerçek bilgi taşımıyorsa liste içinde kalsın, ayrı sayfa açmasın.

Ayrımın işe yaradığını hangi ölçümle anlarsınız?

İlk ölçüt zaman: bir içerik değişikliğinin talepten yayına geçme süresi. Ayrım kurulmadan önce bu süreyi bir hafta boyunca kabaca not edin, kurduktan sonra aynı ölçümü tekrarlayın. İkinci ölçüt kişi bağımlılığı: değişikliği kaç kişi yapabiliyor? Bir kişiden üç kişiye çıkması, tasarım bilgisi gerektirmeyen bir düzenleme yüzeyinin kurulduğunun kanıtıdır.

Üçüncü ölçüt sonucun kendisidir. Rocketly'de Günlük Site Metrikleri sayfa görüntülenmesi, form başlangıcı, form gönderimi, yarıda bırakma ve sayfa derinliğini günlük olarak biriktirir; cihaz ve trafik kaynağı kırılımıyla birlikte hangi detay sayfasının dönüşüm ürettiğini okursunuz. Koleksiyon kurduktan sonra bakılacak soru şudur: liste sayfasından detay sayfasına geçiş oranı nedir, ve detay sayfalarının hangileri hiç görülmüyor? Hiç görülmeyen kayıtlar ya listede yanlış sıradadır ya da hiç var olmamalıydı.

Nereden başlanır: ilk koleksiyon için iki haftalık sıra

Birinci hafta envanterle geçer. Sitedeki tekrar eden içerikleri listeleyin, her biri için kaç kopya olduğunu ve kimin güncellediğini yazın. Sonra en çok acıtan tek koleksiyonu seçin — genellikle şubeler ya da hizmetlerdir. Alan şemasını kağıt üstünde kurun, beş örnek kaydı elle doldurun ve şemanın beşinci kayıtta çatlayıp çatlamadığına bakın; çatlıyorsa alan eksiktir.

İkinci hafta düzenle geçer. Liste ve detay düzenini kurun, boş durumu ve uzun başlığı test edin, çok dilli davranışı seçin, sonra kayıtları taşıyın. Taşıma bittiğinde eski elle kurulmuş bölümü silmeyi unutmayın; iki kaynak bir arada durduğunda hangisinin doğru olduğu tartışması altı ay sürer. Şablon ve tema kararlarını sıfırdan vermek istemiyorsanız Şablondan Başlama hazır düzenlerle işe başlamanızı sağlar, Marka Kitleri ise renk ve yazı tipi kararlarını tek yerde tutup bir değişiklikten hangi sitelerin etkileneceğini önceden gösterir.

Üçüncü haftanın işi yoktur; ölçüm vardır. İlk ayın sonunda güncelleme süresini ve düzenleyebilen kişi sayısını yeniden bakın. Kendi sitenizde denemek isterseniz Rocketly hesabınızı ücretsiz açıp ilk koleksiyonu tek bir hizmet listesiyle kurabilirsiniz.

Sıkça sorulan sorular

Koleksiyon kurmak için kod bilmem gerekir mi?

Hayır. Alan şemasını tanımlamak, kayıt girmek ve sayfaya koleksiyon bloğu koymak yapılandırma işidir. Kod yalnızca çok özel bir görünüm ya da dış sistemle özel bir besleme gerektiğinde devreye girer.

Var olan bir siteyi koleksiyonlara taşımak baştan kurmak demek mi?

Hayır, ve tek seferde taşımak da gerekmez. Tek bir listeyle başlayın, o liste koleksiyondan gelirken sitenin geri kalanı olduğu gibi kalsın. Kazanç ilk taşımadan sonra zaten görünür olur.

Aynı koleksiyonu birden fazla sayfada kullanabilir miyim?

Evet, ve asıl amaç budur. Aynı şube koleksiyonunu iletişim sayfasında harita listesi, bölge sayfasında filtreli kart listesi olarak gösterebilirsiniz; kayıt tek olduğu için bir güncelleme her iki yerde birden geçerli olur.

Kayıt sayısı büyüdükçe liste sayfası yavaşlar mı?

Yavaşlamaması sayfalama ve filtre kurgusuna bağlıdır. Yüzlerce kaydı tek sayfada göstermek yerine kategoriye göre bölün, sayfa başına sabit sayıda kayıt gösterin ve listede yalnızca listede görünen alanları çekin.