SaaS changelog ve sürüm notları sitesi nasıl hazırlanır: yapı, yazım ipuçları, kategoriler, arama, abonelikler, SEO ve bakım adımları.

Bir SaaS changelog sitesi, ürün güncellemelerini tutarlı, kolay gezilen bir arşiv halinde yayınladığınız halka açık bir sayfa (veya mini-site) dir. Bunu, "ne değişti, ne zaman ve neden" sorusunun cevabını veren merkezi bir yer olarak düşünün — özellikle uygulamanıza günlük olarak güvenen müşteriler için değerli.
Kullanıcılar bir şey farklı hissettiklerinde („O düğme nereye gitti?”), bir özelliği etkinleştirip etkinleştirmeyeceklerine karar verirken veya ürünün ne kadar aktif tutulduğunu değerlendirirken changelog ararlar. Net bir güncelleme geçmişi kafa karışıklığını azaltır ve insanların kullandıkları şeye güvenmesini sağlar.
Bu terimler karışabiliyor, ama işlevleri biraz farklıdır:
Birçok SaaS ekibi her ikisini de aynı sitede yayınlar: üstte kısa bir özet, ihtiyacı olanlar için genişletilebilir detaylar şeklinde.
İyi yönetilen bir changelog sitesi aynı anda birden fazla hedefi destekler:
Neyin müşteri odaklı neyin dahili olduğunu belirleyin. Genel notlar kullanıcı etkisine odaklanmalı, hassas ayrıntılardan kaçınmalı ve yalın bir dil kullanılmalı. İç notlar daha teknik olabilir (ör. altyapı değişiklikleri) ve genel changelog’da değil, iç dokümanlarda yer almalıdır.
Bir şablon seçmeden veya yayınlamaya başlamadan önce changelog’un kim için olduğunu karar verin. Tek bir “sürüm notları sayfası” herkese hizmet etmeye çalışır ve çoğu zaman kimseye yardımcı olmaz.
Çoğu SaaS changelog en az üç hedef kitleye hizmet eder; her biri farklı bilgiye ihtiyaç duyar:
Ayrıca bir dahili kitleniz (Destek, CS, Satış) olabilir. Changelog halka açık olsa bile, iç kullanım için yazmak zaman kazandırır: destek, belirli bir girdiye bağlanabilir ve açıklamayı yeniden yazmak zorunda kalmaz.
Yazı stilini ürün karmaşıklığı ve kullanıcı beklentilerine göre eşleştirin:
Ses tutarlı olsun: UI dostunsa, changelog da dostça olabilir — ancak aşırı samimi veya belirsiz olmamalı.
Bir halka açık ürün güncellemeleri sayfası şeffaflık, güven ve paylaşılabilir bağlantılar sağlar. Bir giriş-kilitli changelog ise hassas kurumsal özellikler, müşteri-özel işler veya indekslenmemesi gereken güvenlik ayrıntıları için daha uygun olabilir.
Emin değilseniz, genel olarak yayınlayın ancak bazı girdileri kimlik doğrulamalı kullanıcılar için saklayın.
"İyi"nin ne demek olduğunu tanımlayın. Yaygın hedefler arasında daha az “ne değişti?” bileti, daha hızlı benimseme ve daha yüksek özellik kullanımı var. Bir veya iki metrik seçin (destek bilet hacmi, özellik etkinleştirme oranı, changelog sayfa görüntülemeleri) ve bunları aylık olarak gözden geçirin ki changelog sadece meşgul görünmesin, gerçekten yararlı olsun.
Bir changelog yalnızca insanlar onu sürekli bulabiliyorsa işe yarar—ve hızla ilgili güncellemeye ulaşabiliyorsa. İlk sürüm notunu yazmadan önce ana site, uygulama ve yardım merkezi üzerinden kullanıcıların hangi sayfalara ve yollara geleceğini taslaklayın.
Çoğu SaaS ürünü için karmaşık bir bilgi mimarisine gerek yok. Tahmin edilebilir kısa bir URL setiyle başlayın:
/changelog — ana “en son güncellemeler” akışı (varsayılan giriş noktası)/releases — arşiv görünümü (çoğunlukla /changelog ile aynı olabilir veya filtrelenmiş/sayfalandırılmış liste olabilir)/subscribe — abonelik seçeneklerini ve kullanıcıların neler alacağını açıklayan sayfa/rss (isteğe bağlı) — güç kullanıcıları ve iç ekipler için RSS beslemesiDaha az sayfa tercih ederseniz, /subscribe sayfasını /changelog içine yapışkan bir CTA olarak birleştirebilirsiniz.
Changelog’u kullanıcıların zaten beklediği bir yere koyun:
Hangi yöntemi seçerseniz seçin, URL kısa, kalıcı ve kolay yazılır olsun.
Changelog için net bir bağlantı ekleyin:
Varsayılan olarak en yeni ilk listesine öncelik verin ki kullanıcılar anında neyin yeni olduğunu görsün. Sonra tarama için basit filtreler ekleyin (örnek: ürün alanına göre veya "Bug fixes" vs "New"). Bu, gündelik okuyucular için hız ve belirli bir değişikliği arayanlar için kontrol sağlar.
İyi bir sürüm notu formatı öngörülebilir olmalıdır: okuyucular ilk birkaç satırı taradıklarında neyin değiştiğini, ne zaman olduğunu ve kendilerini etkileyip etkilemediğini hemen anlamalıdır. Yazmaya başlamadan önce küçük bir zorunlu alan seti belirleyin ve her gönderi için buna sadık kalın.
Bu alanlar tutarlı kaldığında, sürüm notları sayfanız yapılandırılmış bir dizin haline gelir, dağınık duyurular akışı olmaz.
Versiyonları build-temelli yazılım yayınladığınızda veya desteğin hassas bir referans noktasına ihtiyaç duyduğu durumlarda kullanın (mobil uygulamalar, masaüstü uygulamalar, API sürümleri, self-hosted dağıtımlar). Bir kullanıcı hata bildirirken “2.14.3 kullanıyorum” diyebilmeli.
Tarih-temelli sürümler ise sürekli dağıtım ve feature-flag arkası roll-out'lar için uygundur. Birçok SaaS ekibi iç build numarası ekler, fakat halka açık olarak yayınları tarih bazında gösterir çünkü bu müşteriler için daha kolaydır.
Hibrit bir yaklaşım iyi çalışır: tarih birincil çapa olsun, destek için versiyon/build küçük metinde gösterilsin.
Opsiyonel alanlar faydalıdır ama yalnızca amaçlı kaldıkları sürece:
Title
Date • Version • Category • Affected area (optional)
Summary (1–2 sentences)
Details
- Bullet 1
- Bullet 2
Rollout status (optional)
Known issues (optional)
Bu yapı her girdiyi okunabilir kılar, sonradan filtrelemeyi kolaylaştırır ve başlıklar ile aramada tutarlılık sağlar.
Bir changelog, her güncelleme iki soruyu hızlıca yanıtladığında en kolay taranır: bu ne tür bir değişiklik? ve ürünün hangi kısmını etkiliyor? Kategoriler ve etiketler bunu sağlar—okuyucuların her gönderiyi okumaya zorlanmadan aradıklarını bulmaları için.
Çoğu sürümü kapsayan ve zaman içinde tutarlı kalan küçük bir taksonomi kullanın:
Kategorileri sınırlı tutun. Bir değişiklik uymuyorsa, yeni bir kategori icat etmeden önce notun söylemini ayarlayın.
Etiketler değişikliğin nerede olduğunu tanımlamalı; UI ve dokümanlarda zaten kullandığınız kelimelerle eşleşsin. Yaygın örnekler: Billing, API, Dashboard, Mobile.
İyi bir kural: her sürüm notu 1–3 etiket alsın. Filtrelemek için yeterli, bunaltmak için fazla değil.
Etiket çoğalması filtreleri işe yaramaz hale getirir. Hafif rehberlik uygulayın:
İnsanlar üründe gördükleri kelimelerle arama yapar. UI, yardım dokümanları ve notlarda aynı özellik adını kullanın (ör. “Saved Views”, bir yerde “View Presets” veya başka yerde “Saved Filters” yazmayın). Herkesin güncellemeleri aynı sözcüklerle göndermesini sağlamak için kısa bir iç adlandırma kılavuzu düşünün.
Sürüm notları ekibinizin ne yaptığına dair bir günlük değil—kullanıcılar için ne değiştiğini, kimin etkilendiğini ve gerekiyorsa ne yapmaları gerektiğini anlatan bir rehber olmalı. Amaç: insanların değeri hızlıca anlaması ve etkilenip etkilenmediğini çabucak görmesi.
İyi bir başlık bir satırda “neden umurunda olmalıyım?” sorusunu yanıtlar.
Kötü: “Project Falcon rollout”
Daha iyi: “Daha hızlı fatura dışa aktarma (3× daha hızlıya kadar)”
Daha iyi: “Yeni: Panoları görüntüleme bağlantılarıyla paylaşma”
Gerekirse kısa, kullanıcı odaklı bir altyazı ekleyin: “Pro ve Business planlarda mevcut.”
Kullanıcıların hızlıca göz atabilmesi için 2–5 kısa maddeyle başlayın. Sonra “Detaylar” paragrafında ne/niçin/nasıl bağlamı verin.
Örnek yapı:
Detaylar: Artık bir pano için yeni bir kullanıcı oluşturmadan güvenli bir paylaşım bağlantısı oluşturabilirsiniz. Bağlantılar Ayarlar → Sharing’den istediğiniz zaman iptal edilebilir.
Değişiklik davranışı, izinleri, faturalamayı veya iş akışlarını etkiliyorsa bunları ekleyin.
Kim etkilenir? Paylaşım ayarlarını yöneten yöneticiler; paylaşılan bağlantıları alan herkes.
Ne yapmam gerekir? Varsayılan olarak hiçbir şey. Bağlantı paylaşımını sınırlamak isterseniz Ayarlar → Sharing’de “Public links”i devre dışı bırakın.
Kullanıcı terimleriyle yazın, iç proje isimleriyle değil. “v2 pipeline’a geçirildi” demek yerine “yüklemeler daha güvenilir hale geldi” deyin (ve kullanıcı deneyimini nasıl değiştirdiğini bir cümlede açıklayın). Teknik bir terim kullanmak zorundaysanız, bir cümlede tanımlayın.
Açıklık, tamlık yerine önceliğiniz olsun: kullanıcı için eylemsel veya anlamlı olmayan ayrıntılardan kaçının.
Beş gönderi varken changelog kolay taranır. Elliye ulaşınca “Biliyorum yayınladınız… ama nerede?” haline gelir. Arama ve gezinme araçları, özellikle destek ekipleri, ürünü değerlendiren müşteriler ve belirli bir hatayı arayanlar için changelog sayfanızın uzun vadede kullanılabilir kalmasını sağlar.
Changelog listesi üstünde belirgin bir arama kutusu ekleyin. Öncelikle başlıklar, etiketler ve her notun ilk paragrafı içinde arama yapın. Eşleşenleri vurgulamayı düşünün ve özellik adları, entegrasyonlar (ör. “Slack”) veya hata kodları gibi yaygın sorguları destekleyin.
Changelog’unuz birden fazla ürün veya modül içeriyorsa, gürültüyü azaltmak için seçili bir ürün alanı içinde arama yapılmasına izin verin.
Filtreler kullanıcıların kullandığı kelimeleri yansıtmalı, iç ekip isimlerini değil.
Yararlı kontroller:
Filtreleri mümkün olduğunca çoklu seçime izin verecek şekilde tutun ve “tümünü temizle” butonunu görünür yapın.
Daha uzun sürüm notları için üstte anchor linkleri ekleyin (ör. New features, Improvements, Fixes). Ayrıca başlıklara “Bağlantıyı kopyala” anchorları ekleyin ki destek ekibi kullanıcıları tam bölüme yönlendirebilsin.
Uygun bir gönderi sayısından sonra sayfalandırma veya “Daha fazla yükle” kullanın (10–20 arası makul). Toplam sayıyı gösterin. Sayfaları hızlı tutun: listeyi sunucu tarafında render edin, ağır öğeleri lazy-load yapın ve büyük arşivlerde engelleyen karmaşık istemci tarafı filtrelemeden kaçının. Hızlı yükleme, gezinmenin güvenilir hissetmesini sağlar.
Kullanıcıların kontrolü ele almadan changelog kontrol etmemeleri için abonelikler sunun. Abonelikler, sosyal medya veya destek taleplerine ihtiyaç duymadan hafif bir iletişim kanalı sağlar.
Üç seçeneği hedefleyin:
Butonların ve CTA’ların sayfa üstünde (girdi listesinin üstünde) görünür olduğundan emin olun: "Subscribe" ve "View latest updates" gibi. Eğer ayrı bir güncellemeler dizini varsa, onu da belirtin (ör. /changelog).
Mümkünse Anında, Haftalık özet ve Aylık özet seçenekleri sunun. Kritik değişiklikler ve hızlı hareket eden ürünler için Anında iyi çalışır; yoğun paydaşlar için özetler daha uygundur.
Abonelikler, kullanıcıların aldıkları şeyi filtreleyebilmesi halinde daha değerlidir. Changelog etiket veya kategori kullanıyorsa (Billing, API, Security, Mobile gibi), abonelerin ilgilendikleri alanları seçmesine izin verin—sonra e-postanın alt bilgisinde nasıl değiştirilebileceğini anlatın.
Bir besleme yayımlıyorsanız, tahmin edilebilir ve kolay hatırlanır tutun (ör. /rss veya /changelog/rss). Abone ol butonunun yanında bağlantı verin ve "RSS feed" olarak etiketleyin ki teknik olmayan kullanıcılar bunun isteğe bağlı olduğunu anlasın.
Bir changelog ancak bulunabiliyorsa işe yarar—aram motorları, uygulama içi bağlantılar ve destek ekiplerinin "site:yourdomain.com" sorguları sayesinde. Buradaki iyi SEO pazarlama hilesi değil; açıklık ve tutarlılıkla ilgilidir.
Her sürüm notunu, kullanıcıların aradığı (ve tarayıcı sekmelerinde göreceği) biçimde açıklayıcı bir başlıkla ayrı bir sayfa olarak ele alın. Değişmeyecek temiz, okunabilir URL'ler kullanın.
Örnek:
/changelog/new-permissions-controlsHer gönderi için benzersiz bir meta açıklama ekleyin. Basit tutun: ne değişti, kimi etkiliyor ve ana fayda nedir.
Changelog sayfasının net bir yapısı olsun:
Görünür bir yayın tarihi her zaman gösterin (ve formatını tutarlı tutun). Arama motorları ve kullanıcılar hem tazelik hem de bağlam için buna güvenir.
Küçük yayınlar bile iki soruyu yanıtlamalı: ne değişti ve neden önemli. Kurulum gerekiyorsa destekleyen dokümanlara bağlanın (yalnızca göreli yollarla), ör. /docs/roles-and-permissions veya /guides/migrate-api-keys.
Bir changelog dizini sayfası oluşturun (ör. /changelog) ve burada başlıklar, tarihler, kısa özetler ve sayfalandırma listeleyin. Bu indeksleme için yardımcı olur, eski güncellemelerin bulunmasını sağlar ve değerli notların sonsuz kaydırmaya gömülmesini önler.
Changelog ancak insanlar hızlıca tarayabiliyor, neyin değiştiğini anlayabiliyor ve sorunsuz gezinebiliyorsa faydalıdır. İyi tasarım süs değil—açıklık içindir.
Okunabilir tipografi kullanın: rahat bir gövde yazı boyutu (gövde metni için 16–18px), net satır yüksekliği ve metin ile arka plan arasında güçlü kontrast. Sürüm notları genellikle yoğun ayrıntı içerir; geniş boşluk başlıkları, tarihleri ve madde işaretlerini taramayı kolaylaştırır.
Başlıklar tutarlı olsun (ör. versiyon/tarih → özet → detaylar). Uzun, tam genişlik paragraflardan kaçının; kısa metin blokları hem masaüstü hem mobilde daha okunur.
Changelog’u fare olmadan da kullanılabilir kılın. Tüm etkileşimli öğelerin — arama, filtreler, etiket butonları, “Daha fazla yükle” ve sayfalandırma — Tab tuşuyla mantıklı bir sırayla erişilebilir olduğundan emin olun.
Bağlantı ve butonlarda erişilebilir etiketler kullanın. “Daha fazlasını oku” yerine “API iyileştirmeleri hakkında daha fazlasını oku” gibi bağlam sağlayan etiketler tercih edin. Sadece simge içeren butonlar varsa aria-label ekleyin.
Ekran görüntüleri ekliyorsanız, alt metin olarak ne değiştiğini açıklayın, görüntünün nasıl göründüğünü değil (ör. “Yıllık planlar için yeni faturalama ayarı anahtarı”). Yalnızca resim içinde sunulan metinden kaçının: bir güncellemenin okunması yalnızca bir ekran görüntüsüne bağlıysa, birçok kullanıcı erişimde sorun yaşar.
Tarihleri net biçimde gösterin; 2025-12-26 gibi belirsiz olmayan formatlar kullanın. Bu küresel kullanıcılar için karışıklığı önler ve destek ekiplerinin doğru referans vermesini sağlar.
Filtreler ve tablolar küçük ekranlarda çalışmalı. Filtreler paneline dar ekranlarda katlanabilir bir yapı tercih edin, etiketler düzgünce kaymalı ve tablolar gerekirse kart görünümlerine dönüşmeli. Kullanıcı telefonunda “Bug fixes”i hızlıca bulamazsa, changelog’unuzun bakım görmediğini düşünebilir.
Changelog yalnızca öngörülebilir olduğunda güven kazanır. Bu, sık olması gerekmediği anlamına gelir—ama kullanıcıların ne bekleyeceğini bilmesi gerekir: güncellemeler nasıl yazılır, kim onaylar ve yayınlandıktan sonra bir şey değişirse ne olur.
İş akışınız platform seçimiyle başlar:
Ekip alışkanlıklarınıza uyanı seçin. “En iyi” araç, her sürümde gerçekten kullanacağınız araçtır.
Eğer sıfırdan inşa ediyorsanız, Koder.ai gibi bir platform ilk uygulamayı hızlandırabilir: sohbet içinde istediğiniz sayfaları (ör. /changelog, arama, etiketler, RSS, e-posta aboneliği) tarif ederek React tabanlı bir ön yüz ve Go + PostgreSQL arka ucu üretebilirsiniz. Bu, özel bir changelog deneyimi istiyor ama haftalarca mühendislik ayırmak istemiyorsanız özellikle kullanışlıdır.
Aşamaları açık tutun ki hiçbir şey birinin kafasında kalmasın. Yaygın, hafif bir akış:
Taslak → İnceleme → Onay → Yayınla → Gerekirse Güncelle
Her aşamanın ne anlama geldiğini (bir cümleyle) ve işin nerede gerçekleştiğini (doküman, issue, CMS taslağı, pull request) yazın. Tutarlılık biçimden daha önemlidir.
Aşamalı dağıtımlar yapıyorsanız bunu açıkça yansıtın:
Bu, “Ben bu özelliğe sahip değilim” şeklindeki destek taleplerini önler.
Düzenlemeler normaldir—sessizce yeniden yazma ise önerilmez. Şunu kararlaştırın:
Changelog'un herkesin işi olup da kimsenin işi olmamasına izin vermeyin: kim yazıyor, kim onaylıyor ve zaman içinde kategoriler/etiketler kim tarafından yönetiliyor belirleyin.
Changelog ancak kullanılırsa değer üretir—ve zamanla güvenilir kalır. Hafif bir ölçüm planı ve basit bir bakım rutini, kullanıcıların neye önem verdiğini görmenizi, destek yükünü azaltmanızı ve eski notların düzenli kalmasını sağlar.
Harekete geçebileceğiniz birkaç göstergeyle başlayın:
Ürün içindeki “What’s new” bağlantısı varsa, tıklama oranını ve kullanıcıların hangi girdileri açtığını da ölçün.
Sürüm notlarınız açık ve yeterliyse tekrar eden sorular azalır. Her büyük sürüm sonrası şunları izleyin:
Eğer bilet hacmi düşmüyorsa, bunu yazım sorunu (eksik bağlam, belirsiz etki) veya keşif sorunu (kullanıcılar ilgili notu bulamıyor) olarak değerlendirin.
Her girdide okuyucuya bir sonraki adımı verin:
Geri bildirim hafif tutun. Genellikle tek bir açık metin kutusu, karmaşık anketlerden daha iyidir.
Aylık (veya daha küçük ürünler için üç aylık) olarak:
Geçmişi silmeyin. Bunun yerine:
İyi bakılmış bir arşiv güvenilirlik oluşturur ve ekibinizi aynı değişiklikleri tekrar açıklamaktan kurtarır.
Bir SaaS changelog sitesi, ürün güncellemelerinin kolayca gezilebilen bir arşivini tutan halka açık bir sayfa (veya küçük bir site) dir — ne değişti, ne zaman değişti ve kısaca neden önemli. Kullanıcıların bir şeyin hata mı yoksa kasıtlı bir değişiklik mi olduğunu doğrulamasına yardımcı olur ve ürünün aktif olarak bakıldığını gösterir.
Changelog girdileri genellikle kısa ve kolay taranabilir (ör. Added, Improved, Fixed, Deprecated) ve “Ne yayınlandı?” sorusunu yanıtlar. Sürüm notları ise bağlam ve rehberlik ekler — kim etkilendi, değişikliği nasıl kullanmalı ve yapılması gereken herhangi bir işlem var mı — yani “Bu benim için nasıl etki eder?” sorusunu yanıtlar. Birçok ekip, özetin üstte olduğu ve detayların açılabilir olarak bulunduğu aynı sayfada her ikisini de yayınlar.
İyi yönetilen bir changelog şunları yapabilir:
Eğer tek bir şeyi ölçmekle başlayacaksanız, büyük değişiklikler etrafındaki destek talebi hacmini izleyin.
Çoğu ürün birden fazla hedef kitleye hizmet eder:
Birincil hedef kitle için yazın; gerekirse “Kim etkilendi?” gibi ek bölümler ekleyin.
Şeffaflık ve paylaşılabilir bağlantılar önem taşıyorsa varsayılan olarak halka açık yapın; notlar hassas kurumsal özellikler, müşteri-özel işler veya indekslenmemesi gereken güvenlik ayrıntıları içerebiliyorsa giriş-kilidi tercih edin.
Pratik bir uzlaşı: ana changelog’u halka açık tutun, bazı gönderileri yalnızca kimlik doğrulamalı kullanıcılar için ayırın.
Yapıyı basit ve akılda kalıcı tutun:
Ayrıca footer, uygulama içi yardım menüsü ve yardım merkezi ana sayfasından link verin ki kullanıcılar hızlıca bulabilsin.
Tutarlı bir “her zaman dahil et” seti genellikle şöyle görünür:
Destek hassasiyet gerektiren durumlarda versiyonları kullanın (mobil/masaüstü uygulamalar, API'ler, self-hosted). Sürekli teslimat ve feature-flag roll-out'ları için tarih-temelli sürümler daha uygun olabilir.
İyi bir hibrit: okunabilirlik için önce tarih, destek amacıyla küçük metinde build/versiyon gösterimi.
Küçük, sabit bir kategori kümesiyle başlayın (ör. New, Improved, Fixed, Deprecated, Security) ve UI sözlüğünüzle eşleşen ürün-alanı etiketleri (Billing, API, Dashboard, Mobile) kullanın.
Etiket çoğalmasını önlemek için:
Abone olmak için birkaç yol sunun:
Mümkünse kullanıcılara Hemen, Haftalık özet veya seçenekleri ve etiket/kategori bazlı tercihler sunun.
Tutarlılık, changelog’unuzu duyurular akışı yerine güvenilir bir dizine dönüştürür.