1. Visual Editing Nedir?
Visual editing; editörün içeriği yalnız form alanlarında değil, sayfanın görsel bağlamında (layout içinde) görerek düzenlemesidir. “WYSIWYG” (what you see is what you get) benzeri bir algı yaratır; ama headless dünyada hedef, her şeyi sürükle-bırak yapmak değil, doğru alanları doğru yerde görmektir. Visual editing’i değerli yapan şey; editörün kararını hızlandırmasıdır: başlık çok mu uzun, görsel kırpma doğru mu, CTA doğru blokta mı?
Bu nedenle web ve yazılım hizmetlerinde Headless CMS preview yaklaşımı, preview deneyimini sadece konfor değil; editör deneyimi, yayın güvenliği ve kalite kontrol katmanı olarak konumlandırır.
Visual editing ve in-context preview nedir?
Kısa cevap: In-context preview, CMS’teki draft içeriği Next.js sayfasında canlıya çok yakın görüntülemektir; visual editing ise bu preview üzerinde düzenleme kısayolları (click-to-edit) ile çalışmaktır.
Ne yapmalıyım?
- • “Düzenlenebilir alanlar”ı listele (headline, lead, hero görsel, CTA).
- • Layout’u kilitle; editöre içerik alanı ver.
- • Click-to-edit bağlantılarını sadece izinli alanlarda göster.
- • Preview’yı standartlaştır (tek URL kuralı).
- • Eğitim: editöre “preview’da kontrol” alışkanlığı kazandır.
2. In-Context Preview ve “Sayfada Düzenle” Deneyimi
In-context preview; editörü panelde alanlar arasında dolaştırmak yerine, sayfanın üzerinde doğru bağlama taşır. Tipik bir akış:
Bu akışın güvenli işlemesi için preview review publish süreci net tanımlanmalı; preview yalnızca ara adım değil, review ve publish kalitesini etkileyen resmi kontrol katmanı olarak ele alınmalıdır.
- •CMS’te içerik kaydı (draft)
- •“Preview” butonu → Next.js preview sayfası
- •Sayfada “Edit this section” / “Sayfada düzenle” → CMS’te ilgili alana geri dönüş
- •Düzenle → preview otomatik güncellenir
- •Review → Publish
Headless CMS + Next.js projelerinde sayfa üstünden düzenleme nasıl çalışır?
Kısa cevap: CMS, draft içeriği preview token/kimliğiyle Next.js’e gönderir; Next.js sayfayı preview modunda render eder ve sayfadaki bloklar CMS’deki alanlara “edit link” verir.
Pratik tasarım notları
Sayfa üstündeki alanların editöre güvenli biçimde açılması için sayfada düzenleme deneyimi mantığıyla çalışan blok şablonları gerekir; böylece editör içerik alanlarını görür, fakat layout ve grid kararları korunur.
Aynı zamanda in-context preview ile UI/UX kontrolü sayesinde CTA yerleşimi, form akışı ve mobil görünüm gibi tasarım kararları yayına çıkmadan bağlam içinde değerlendirilebilir.
- •Preview URL’leri içerik tipine göre üretilebilir: blog/oda/case
- •Sayfadaki edit link’ler “hangi alan”a gideceğini bilir (field path)
- •Preview ortamı prod’dan ayrı olmalı (staging/preview domain)
Ne yapmalıyım?
- • Preview URL standartlarını yaz (content_type + slug).
- • “Edit section” linklerini component bazında ekle.
- • Preview domain’i prod’dan ayır ve noindex yap.
- • Preview cache/revalidation kuralını netleştir.
- • Otomatik “preview healthcheck” ekle (Varsayım: ops).
3. Next.js + Headless CMS’te Nasıl Çalışır?
Next.js tarafında preview, genelde iki temel ihtiyacı çözer:
- •Draft içerik render edebilmek
- •Cache/revalidation ile prod’u bozmadan hızlı güncelleme sağlayabilmek
Headless CMS tarafında ise preview; draft içeriği güvenli şekilde paylaşmak için token/secret mekanizması gerektirir.
Bu aşamada AI destekli CMS QA ve otomatik kontrol yaklaşımı; eksik alan, hatalı başlık yapısı, zayıf CTA veya unutulan içerik bloklarını preview üzerinde yayına almadan önce işaretleyebilir.
Preview ile cache/revalidation nasıl birlikte çalışmalı?
- •Preview: mümkün olduğunca “anlık” (cache minimum)
- •Prod: ISR/SSG/SSR stratejisine göre cache + revalidation
- •Publish olayı: prod revalidation tetikler (webhook)
Teknik not (genel): Preview’da “anlık” görürken prod’da “stabil performans” hedeflenir; ikisi aynı cache kuralıyla yönetilmez.
Ne yapmalıyım?
- • Preview cache’i minimuma indir (güvenli ve hızlı).
- • Prod’da ISR/SSG/SSR kararını içerik tipine bağla.
- • Publish → revalidate/purge akışını kur.
- • Preview ve prod için ayrı env secret’ları kullan.
- • Preview hatalarını logla; prod’u etkilemesin.
4. Otel ve B2B İçin İçerik Ekibi Avantajları
Visual editing’in etkisi, özellikle yoğun kampanya ritminde görünür.
Kampanya ve kreatif ekipleri için sosyal medya içerik üretiminde görsel önizleme mantığı da değerlidir; CMS’te hazırlanan mesaj ve görsel kombinasyonlarının sayfa bağlamında nasıl durduğu erken görülebilir.
Otel senaryoları (oda/landing)
- •Oda sayfasında: başlık, USP listesi, galeri sırası, CTA metni
- •Kampanya landing’inde: hero mesaj, koşullar bloğu, SSS ve CTA
- •Mini örnek: Belek’te sezon kampanyası için landing metni güncellenirken editör preview’da görüp aynı gün yayına hazır hale getirir; “yayında sürpriz” azalır.
B2B senaryoları (blog/case)
- •Blog: başlık, özet, görsel ve CTA blokları
- •Case: problem/sonuç metni, proof blokları, download CTA
- •Mini örnek: Case sayfasında “sonuç” metni uzadığında editör preview’da görür ve kart dengesi bozulmadan düzeltir.
Veri noktası (yumuşatılmış): In-context editing olan projelerde “yayına çıkınca sürpriz görünüm” ve basit revizyonlar için geliştirici bekleme ihtiyacı belirgin şekilde azalabiliyor (ekip ve kurguya bağlıdır).
Ne yapmalıyım?
- • Otel için landing/oda sayfalarında visual editing’i önceliklendir.
- • B2B’de case/blog için click-to-edit’i standartlaştır.
- • En kritik 5 template’te “editable field” sınırlarını yaz.
- • Eğitim: 30 dakikalık “preview ile yayın” kılavuzu hazırla.
- • KPI: time-to-publish ve rollback oranını izlemeye başla.
5. Sınırlar ve Riskler
Visual editing yanlış kurgulanırsa “kaos” üretir: editör layout’u kırar, SEO başlık hiyerarşisi bozulur, preview indexlenir, güvenlik zayıflar. Bu yüzden sınırlar net olmalı.
Visual editing kurgusunda hangi sınırlar ve riskler vardır?
Kısa cevap: Düzenlenebilir alanlar sınırlı olmalı (template-safe), preview indexlenmemeli, yetkiler RBAC ile korunmalı ve publish/revalidation akışı ayrı yönetilmelidir.
Risk seti
- •Tasarım bozulması: serbest layout yetkisi
- •SEO bozulması: H1/H2 kontrolsüz bloklar
- •Güvenlik: preview token sızıntısı, yetkisiz preview erişimi
- •Cache tutarsızlığı: preview/prod aynı cache kuralına bağlanması
- •Operasyon: edit link’lerin yanlış alanı açması (hata)
Düzenlenebilir alan matrisi (1 tablo – Media Pack ile uyumlu)
| Alan | Editör düzenler mi? | Neden | Kontrol |
|---|---|---|---|
| H1/Title | ✅ | içerik | max uzunluk + help text |
| Layout/grid | ❌ | marka & UX | kilitli template |
| Hero görsel | ✅ | kampanya | oran/format validasyon |
| CTA metni | ✅ | performans | onay/preview |
| SEO meta | ✅ (kısıtlı) | snippet | zorunlu alan + karakter limiti |
| Schema tetikleri | ❌/kısıtlı | teknik | template-controlled (Varsayım) |
Ne yapmalıyım?
- • Layout’u kilitle; sadece içerik alanlarını aç.
- • Preview alanını noindex + auth ile koru.
- • RBAC ile “kim preview/publish yapar?” sınırla.
- • Edit link’leri component bazında test et.
- • Rollback planını yaz (content version history).
6. Teknik Not: Cache/Revalidation ve SEO Uyumu
In-context editing kurgusunda preview ortamı noindex olmalı; canonical/robots meta doğru yönetilmeli ve preview cache stratejisi prod’dan ayrı tutulmalıdır. Ayrıca publish sonrası revalidation zinciri /tr/seo/teknik-seo ile uyumlu tasarlanmalıdır (özellikle eski içerik gösterimi ve indeks tutarlılığı açısından).
Özellikle heading yapısı, metadata, canonical ve indexlenebilirlik tarafında preview sonrası teknik SEO kontrolü sürecinin publish öncesi checklist’e dahil edilmesi gerekir.
İç link uyumu (Internal Link Targets)
- •https://dgtlface.com/tr/yazilim/cms-entegrasyonu
- •https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
- •https://dgtlface.com/tr/creative/ui-ux-tasarim
AIO paragrafı (in-context editing modeli)
Visual editing, preview URL, blok alanları ve şablon kısıtları; tek bir “in-context editing modeli” içinde çalışır. CMS editöre düzenlenebilir alanları sunar; Next.js preview modunda sayfayı render eder; click-to-edit bağlantıları editörü doğru field’a götürür; publish olunca revalidation tetiklenir. Bu model, editor-friendly authoring sağlarken template-safe editing ile marka ve SEO tutarlılığını korur.
Bu yapıyı kurmak isteyen ekipler için visual editing destekli CMS entegrasyonu preview mimarisi, edit sınırları ve yayın güvenliğini birlikte planlamayı kolaylaştırır; uygulama detayları için CMS entegrasyonu hakkında sık sorulan sorular sayfasına da göz atabilirsiniz.
7. Next.js + Headless CMS Visual Editing & Preview Planlama Şablonunu İndir
Next.js + Headless CMS Visual Editing & Preview Planlama Şablonunu İndir — Yazılım / Visual Editing (v1.0)
Bu şablon; Next.js + headless CMS projelerinde preview URL sözleşmesini, click-to-edit akışını ve düzenlenebilir alan sınırlarını planlamanızı sağlar. Noindex preview, cache/revalidation ayrımı, RBAC ve loglama gibi güvenlik/SEO kontrollerini tek dokümanda toplar; “yayına çıkınca sürpriz” riskini azaltır.
Kim Kullanır?
Teknik lider, CMS owner, UX lead, ajans teknik PM.
Nasıl Kullanılır?
- İçerik tiplerini ve preview URL formatını tanımlayın.
- Edit edilebilir alanları ve şablon kilitlerini belirleyin.
- Noindex, cache/revalidation, RBAC ve loglama kurallarını ekleyip test senaryolarını yazın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Preview URL formatları içerik tiplerine göre tanımlandı
- ▢ ✅ Preview token ve content_id parametreleri belirlendi
- ▢ ✅ H1/Title, lead, hero, CTA ve FAQ edit sınırları yazıldı
- ▢ ✅ Layout ve grid şablon seviyesinde kilitlendi
- ▢ ✅ Click-to-edit field path eşleşmeleri doğrulandı
- ▢ ✅ Preview ortamına RBAC kontrolü uygulandı
- ▢ ✅ Preview ve prod cache kuralları ayrıldı
- ▢ ✅ Publish→revalidate webhook akışı kuruldu
- ▢ ✅ Preview domain noindex/nofollow olarak yapılandırıldı
- ▢ ✅ Audit log ve preview→publish test senaryoları tamamlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables
- •Preview runbook
- •Editable fields matrisi
- •Test checklist (preview→publish)
- •SEO/noindex doğrulama listesi
Bir Sonraki Adım
Editörlere sayfa üstünde düzenleme deneyimi sunarken şablon ve SEO güvenliğini koruyacak preview mimarisini tasarlayın.