CMS Block Editor ve Page Builder Yapıları: Esneklik ve Kontrol Dengesi

Block editor; içerik alanını “tek bir dev metin kutusu” yerine, anlamlı yapı taşlarına böler: hero, paragraf, görsel, grid, banner, SSS, kartlar gibi. Bu yapı, içerik ekibinin düzenli ve tekrar kullanılabilir bileşenlerle üretim yapmasını sağlar. Page builder ise genellikle daha “layout” odaklıdır; sürükle-bırak ile sayfa düzenini kurdurur. İkisi benzer görünse de, kurumsal web için kritik fark şudur: block editor daha yapılandırılmış ve yönetilebilir, page builder ise yanlış kurgulanırsa “sonsuz özgürlük” nedeniyle standardı kırabilir.

CMS block editor nedir, page builder’dan farkı nedir? (AEO – Soru formatı)

Kısa cevap: Block editor içerik ve bileşenleri yapılandırılmış bloklarla yönetir; page builder sayfa düzenini daha serbest kurdurur. Kurumsal projelerde block editor genelde daha iyi “kontrol” ve “tutarlılık” sağlar.

Kurumsal web’te en kritik karar: sayfa düzeni mi (layout) içerik mi (content) yönetilecek? Structured content yaklaşımı; içerikleri anlamlı alanlara böler (başlık, özet, galeri, USP listesi) ve front-end bu veriyi tasarım sistemine göre render eder. Page builder yaklaşımı ise editöre “layout” yaptırır. Otel ve B2B gibi marka tutarlılığı önemli yapılarda, çoğu zaman “tam serbest layout” yerine structured + blok hibriti daha iyi çalışır.

Tamamen serbest page builder mı, kısıtlı şablon mu kullanmalıyım? (AEO – Soru formatı)

Kısa cevap: Kurumsal sitelerde genellikle kısıtlı şablon + kontrollü blok alanları daha doğru bir dengedir. Tam serbestlik hız kazandırır gibi görünür ama tasarım/SEO/performans borcu üretir.

Kritik değerlendirme kriterleri

• •Marka standardı: her sayfa aynı dilde mi konuşmalı?
• •Ekip yetkinliği: editörler layout kararını taşıyabilir mi?
• •Performans hedefi: CWV/TTFB/LCP kritik mi?
• •SEO kontrolü: başlık hiyerarşisi ve schema tetikleri yönetilecek mi?
• •Ölçek: 50 sayfa mı 1000 sayfa mı?

Blok tabanlı bir model; doğru kurgulanırsa hız ve çeşitlilik getirir. Ancak blok sayısı, görsel yönetimi ve script yükleri kontrol edilmezse sayfa şişer. Bu yüzden “performans bütçesi” yaklaşımı işe yarar: her sayfa türü için maksimum blok sayısı, maksimum medya, maksimum ağır bileşen sınırı.

Sheet veri noktası (yumuşatılmış): Block tabanlı modelin iyi kurgulandığı projelerde, sayfa çeşitliliği artarken marka dili ve tasarım tutarlılığı korunabiliyor.

Blok yapısı performans ve tasarım tutarlılığını nasıl etkiler? (AEO – Soru formatı)

Kısa cevap: Bloklar “kontrollü” ise hem tutarlılık hem performans korunur; kontrol yoksa her blok yeni CSS/JS yükü ve farklı layout üretip sayfayı ağırlaştırır ve görsel dili bozar.

Pratik performans bütçesi örneği (Varsayım)

• •Landing: max 8–12 blok
• •Blog: max 6–10 blok
• •Otel oda sayfası: max 10–14 blok (galeri + USP + oda kartları)
• •Ağır blok (video/slider): sayfa başına max 1

Blok yaklaşımı en iyi; tekrar eden sayfa türlerinde değer üretir. Otelde kampanya landing’leri, destinasyon sayfaları, oda sayfaları; B2B’de hizmet sayfaları, case sayfaları, webinar/whitepaper landing’leri. Burada kritik olan; blok setinin “her şey” olmaması; birkaç güçlü blokla yönetilebilir kalmasıdır.

Otel için örnek blok seti

• •Hero (kilitli): başlık, alt metin, 1 görsel, 1 CTA
• •USP Grid: 3–6 madde (ikon+metin)
• •Oda Kartları: oda tipi, öne çıkan özellikler, CTA
• •Kampanya Banner: tarih/koşul + CTA
• •SSS: belirli kategoriyle
• •Gallery (kontrollü): max 8–12 görsel

Mini örnek: Antalya/Belek’te sezon kampanyasında; “Hero mesaj + teklif bloğu + oda kartları + SSS” aynı şablonla hızlı üretilir, tasarım dağılmaz.

B2B için örnek blok seti

• •Hero (kilitli): value prop + demo/teklif CTA
• •Problem/Solution: yapılandırılmış alanlar
• •Proof/Logo wall: referanslar
• •Case highlights: 2–3 kart
• •FAQ: satış itirazlarını çözen blok
• •Resource CTA: whitepaper/webinar

Hibrit modelin çalışması için rol dağılımı net olmalı. Tasarım ekibi “sistem”i kurar: component kuralları, spacing, tipografi, token’lar, blok kütüphanesi. Editör ekibi “içeriği” üretir: blokları doğru sırada kullanır, metni ve görseli standarda uygun doldurur. Ajans yapılarında bu iki rol farklı ekiplerde olabilir; o yüzden governance şarttır.

Editörlere esneklik vermek istiyorum ama site dağılmasın, ne yapmalıyım? (AEO – Soru formatı)

Kısa cevap: Hibrit model kur: kilitli şablon iskeleti + izinli blok seti + publish gate + tasarım onayı gerektiren istisna akışı.

Kilitli şablon alanları + serbest blok alanları tablosu (1 tablo)

Block/page builder yaklaşımında SEO’nun bozulma sebebi çoğu zaman “kötü niyet” değil; editörün farkında olmadan H2/H3 düzenini kırması, aynı sayfada birden çok H1 üretmesi, görsel alt metinlerini boş bırakmasıdır. Bu yüzden block modelinde HTML hiyerarşisi ve schema tetikleri “tasarımın değil, sistemin” işi olmalıdır.

Teknik not (sheet ile uyum): Blok tabanlı içerik yapısı /tr/creative/ui-ux-tasarim ve /tr/yazilim/web-sitesi-gelistirme ile tutarlı olmalı; blokların HTML hiyerarşisi ve schema açısından kontrol edilmesi gerekir.

Block editor ve page builder yapıları, doğru kurgulandığında içerik üretimini hızlandırır; yanlış kurgulandığında ise tasarım kaosu, ağır sayfalar ve SEO kontrol kaybı üretir. Bu yüzden en sağlıklı yaklaşım çoğu otel ve B2B projesinde hibrit modeldir: kilitli şablon iskeleti, izinli blok seti, net rol dağılımı ve publish gate.

Kilitli alanlar marka ve SEO tutarlılığını korurken; serbest blok alanları kampanya, içerik ve iletişim çeşitliliği sağlar. Performans bütçesi, HTML hiyerarşisi ve schema tetikleri sistem seviyesinde kontrol edildiğinde, editörler daha hızlı üretir ve site bütünlüğü bozulmaz.