Haber Yazılımı: Kapsamlı Rehber ve Seçim Kılavuzu

Haber Yazılımı Nedir?

Haber yazılımı, süreli yayıncılık için tasarlanmış bir içerik yönetim sistemidir. Genel amaçlı bir CMS "içerik" kavramını tek bir soyut nesne olarak ele alır: bir başlık, bir gövde, bir yayın tarihi. Haber yazılımı ise içeriğin haber olduğunu bilir ve bu bilgiyi sistemin her katmanına yayar. Haberin bir spotu, bir sürmanşet ihtimali, bir muhabiri, bir editör onayı, bir güncelleme geçmişi, bir kaynağı ve bir hukuki sorumlusu vardır.

Bu farkın pratik karşılığı şudur: genel amaçlı bir sistemde "manşete al" diye bir kavram yoktur, siz onu bir etiket ya da özel alan uydurarak kurarsınız. Haber yazılımında manşet birinci sınıf bir kavramdır; sıralaması, süresi, görsel oranı ve kimin değiştirebileceği sistemin içinde tanımlıdır. Aynı şey arşiv, tarih damgası, künye ve rol ayrımı için de geçerlidir.

Haber Sitesi Yazılımı ile Genel Amaçlı CMS Arasındaki Sekiz Yapısal Fark

Aradaki fark özellik listesi uzunluğu değildir; veri modelinin haberciliği tanıyıp tanımamasıdır. Sekiz başlıkta toplanabilir.

• Zaman kavramı. Genel CMS'te tek bir yayın tarihi vardır. Haberde ilk yayım anı, güncelleme anları ve bazen bir olay zamanı ayrı ayrı anlam taşır; üçü de saklanmalı ve gösterilebilmelidir.
• Öncelik kavramı. Blogda içerikler kronolojiktir. Haberde sürmanşet, manşet, ikinci sıra ve kategori vitrini gibi editoryal öncelikler vardır ve gün içinde defalarca değişir.
• Rol ayrımı. Blogda yazar ve yönetici yeter. Haberde muhabir, editör, sayfa sekreteri, yayın yönetmeni ve sorumlu müdür farklı yetkilere sahiptir ve kimin neyi yayımladığı iz bırakmalıdır.
• Hacim. Bir blog beş yılda beş yüz yazı üretir. Bir yerel haber sitesi aynı sürede elli bin habere ulaşabilir; arama, listeleme ve arşiv bu ölçekte tasarlanmalıdır.
• Trafik deseni. Blog trafiği düzdür. Haber trafiği ani zirveler hâlinde gelir; sistem ortalama yüke değil zirveye göre kurulur.
• Kaynak ve atıf. Haberde ajans beslemesi, alıntı, arşiv görseli ve muhabir üretimi ayrı ayrı izlenmelidir; telif sorumluluğu buna bağlıdır.
• Değişmezlik. Blog yazısı serbestçe düzenlenir. Yayımlanmış haberin sonradan değiştirilmediğinin kanıtlanabilmesi gerekir.
• Hukuki yükümlülük. Blogda künye zorunluluğu yoktur. İnternet haber sitesinde künye, tarih damgası ve arşiv saklama kanunla düzenlenmiştir.

Son madde çoğu zaman en geç fark edilenidir ve en pahalıya mal olanıdır. Türkiye'de bir internet haber sitesi işletiyorsanız 5187 sayılı Basın Kanunu'nun süreli yayınlar için öngördüğü yükümlülükler size de uygulanır; bunların bir kısmı doğrudan yazılımın karşılaması gereken kalemlerdir. Bu rehberin altıncı bölümü tamamen bu konuya ayrıldı.

Bir Haber Merkezinin Günü ve Yazılımın Her Adımda Yaptığı İş

Yazılımı değerlendirmenin en dürüst yolu, özellik listesine bakmak yerine bir günü baştan sona yürütmektir. Aşağıdaki akış, yerel bir haber sitesinin sıradan bir gününü tarif ediyor; her adımda yazılımın üstlendiği işi ayrı ayrı yazdım.

Sabah: gündem toplantısı ve görev dağıtımı

Gün, ne yazılacağının belirlenmesiyle başlar. İyi bir haber yazılımı bu aşamada bir görev listesi ya da en azından taslak atama mekanizması sunar: hangi muhabir hangi konuyu takip ediyor, hangi haber hangi saatte bekleniyor. Bu olmadığında koordinasyon mesajlaşma uygulamalarına kayar ve iz kalmaz; akşam "bu haberi kim atlatmıştı" sorusunun cevabı olmaz.

Gün içi: haber girişi

Muhabir haberi girer. Burada yazılımın işi kolaylaştırmak kadar hata yapmayı zorlaştırmaktır: zorunlu alanlar (spot, kategori, görsel alt metni) boş bırakılamamalı, görsel yüklenirken otomatik olarak boyutlandırılmalı, başlık uzunluğu arama sonucunda nasıl görüneceğine dair geri bildirim vermelidir. Muhabirin yayımlama yetkisi olmamalıdır; haber taslak olarak editöre düşmelidir.

Gün içi: editör kontrolü ve yayın

Editör metni düzeltir, kategoriyi doğrular, görseli onaylar ve yayımlar. Yayımlama anında sistem birden fazla iş yapar: sayfa üretilir, önbellek ısıtılır, site haritası güncellenir, arama motorlarına bildirim gönderilir, sosyal medya paylaşım kartı hazırlanır, gerekiyorsa push bildirimi kuyruğa alınır ve içerik arşive kaydedilir.

Öğleden sonra: manşet düzeni

Sayfa sekreteri ya da yayın yönetmeni manşeti yeniden dizer. Bu iş gün içinde onlarca kez tekrarlanır ve sürükle-bırak bir arayüzle yapılabilmelidir; her değişiklik için haber düzenleme ekranına girmek zorunda kalmak, günde yarım saat kaybettirir.

Akşam: son dakika

Bir son dakika haberi girilir. Trafik dakikalar içinde on katına çıkar. Bu anın testi şudur: site ayakta kalıyor mu, haber arama sonuçlarında ne kadar sürede beliriyor ve push bildirimi kaç saniyede okura ulaşıyor? Üçü de mimarinin sonucudur, ayar meselesi değildir.

Gece: raporlar

Gün kapanırken hangi haberin ne kadar okunduğu, okurun nereden geldiği ve hangi kategorinin çalıştığı görülmelidir. Bu veri ertesi günün gündem toplantısının girdisidir; haftalık rapor beklemek çok geçtir.

Manşet Yönetimi: Editoryal Kontrolün Merkezi

Manşet, bir haber sitesinin en değerli alanıdır. Ana sayfanın üst kısmı okurun ilk beş saniyesini belirler ve o beş saniye tıklama oranını, oradan da toplam trafiği belirler. Yazılımın bu alanı ne kadar iyi yönettiği, doğrudan ticari sonuç üretir.

İyi bir manşet yönetimi şunları sağlar:

• Sürükle-bırak sıralama. Haberleri açmadan, tek ekranda yeniden dizebilmek.
• Görsel önizleme. Manşete alınan haberin görselinin o alanda nasıl kırpılacağını önceden görmek.
• Zamanlanmış manşet. Bir haberin belirli saatte manşete girip belirli saatte düşmesi.
• Alan bazlı yetki. Sürmanşeti yalnızca yayın yönetmeninin değiştirebilmesi.
• Geri alma. Yanlış dizilen bir manşeti bir önceki hâline döndürebilmek.
• A/B başlık denemesi. Aynı haber için iki başlığın performansını karşılaştırabilmek.

Son madde çoğu sistemde yoktur ve olmaması hayati bir eksiklik değildir; ancak varsa, başlık yazma pratiğinizi veriyle beslediği için zamanla ölçülebilir fark yaratır. KEYDAL'ın manşet, ızgara, dergi ve liste düzenleriyle bu alanı nasıl kurguladığını haber yazılımı sayfasında ekran görüntüleriyle görebilirsiniz.

İçerik Üretim Akışı: Taslaktan Yayına

Haber üretimi tek kişilik bir iş değildir ve yazılım bunu varsaymamalıdır. Sağlıklı bir akış en az üç durak içerir: taslak, kontrol, yayın. Küçük ekiplerde ikinci durak atlanabilir ama sistem bunu desteklemelidir; çünkü ekip büyüdüğünde akışı değiştirmek, alışkanlığı değiştirmekten kolaydır.

Akışın her durağında sorulacak sorular şunlardır:

Son satır özellikle önemlidir. Bir haberin siteden kaldırılması, o haberin arşivden silinmesi anlamına gelmemelidir; kanun yayımlanmış içeriğin saklanmasını arıyor. Kaldırma ile silme arasındaki farkı gözetmeyen bir yazılım, iyi niyetli bir editör hatasıyla hukuki bir soruna dönüşebilir.

Rol ve Yetki Mimarisi

Yetki yönetimi, haber yazılımlarında en çok küçümsenen ve en çok soruna yol açan başlıktır. Sebebi basit: küçük ekipte herkes her şeyi yapabilir ve bu bir süre sorun çıkarmaz. Ekip on kişiyi geçtiğinde ya da bir stajyer manşeti değiştirdiğinde sorun aniden görünür hâle gelir.

Bir haber merkezinde en az beş rol ayrışmalıdır:

• Muhabir: Haber girer, kendi taslaklarını düzenler, yayımlayamaz.
• Editör: Kendi alanındaki haberleri düzenler ve yayımlar; manşete müdahale edemez.
• Sayfa sekreteri: Manşet ve vitrin düzenini yönetir; metne dokunmaz.
• Yayın yönetmeni: Tüm yayın yetkisi; kategori ve rol tanımlarını yönetir.
• Sorumlu müdür: Kaldırma, düzeltme ve cevap süreçlerinde son söz; hukuki sorumluluğun muhatabı.

Son rolün yazılımda karşılığı olması yalnızca düzen meselesi değildir. 5187 sayılı Kanun her süreli yayının bir sorumlu müdürü bulunmasını arar ve bu kişi için özel şartlar sayar. Sorumlu müdürün sistemde tanımlı olması, cevap ve düzeltme taleplerinin doğru kişiye düşmesini sağlar; bu şartların ayrıntısını haber sitesi kurulum rehberinde madde madde yazdık.

Yetki mimarisinin ikinci boyutu izlenebilirliktir. Kimin neyi ne zaman değiştirdiği kayıt altında olmalıdır. Bu, ekip içi güven için değil, bir haberin sorgulanması hâlinde ne olduğunu gösterebilmek için gereklidir.

Kategori, Etiket ve Konu Mimarisi

Haber sitelerinde en sık yapılan bilgi mimarisi hatası, kategori ile etiketi karıştırmaktır. Kategori bir hiyerarşidir: her haber tam olarak bir yere aittir ve o yer bir arşiv sayfası üretir. Etiket bir çapraz bağdır: aynı haber birden çok etikete sahip olabilir ve etiketler zamanla çoğalır.

Kategori sayısını az tutmak neredeyse her zaman doğrudur. On beş kategorili bir yerel haber sitesinde çoğu kategori yılda birkaç haber alır; bu, hem okur için boş bir sayfa hem arama motoru için zayıf bir sinyaldir. Beş ile sekiz arasında kategori, çoğu yayın için doğru aralıktır.

Üçüncü bir kavram daha vardır ve iyi haber yazılımlarını ayıran şey çoğu zaman budur: konu ya da dosya. Bir deprem, bir seçim, bir dava süreci aylarca sürer ve onlarca haber üretir. Bunları tek bir konu sayfasında toplamak, hem okurun süreci takip etmesini sağlar hem de arama motorunda o konuda otorite sinyali üretir. Etiketle konu arasındaki fark, konunun kendi açıklama metnine, kendi kronolojisine ve kendi kapak görseline sahip olmasıdır.

• Kategori: Asayiş, Ekonomi, Spor, Kültür — az sayıda, kalıcı, hiyerarşik.
• Etiket: Kişi ve kurum adları, yer adları — çok sayıda, otomatik üretilebilir.
• Konu/dosya: "2026 Yerel Seçimleri", "Depremin Birinci Yılı" — az sayıda, editoryal kararla açılır, kendi sayfası olur.

Arşiv ve Arama: Elli Bin Haberde Ne Oluyor?

Demo kurulumunda yirmi haber vardır ve her sistem hızlıdır. Gerçek test, arşiv büyüdüğünde başlar. Beş yıllık bir yerel haber sitesi kolaylıkla otuz-elli bin habere ulaşır ve bu ölçekte üç şey bozulmaya başlar: kategori sayfalarının ikinci-üçüncü sayfaları, site içi arama ve yönetim panelindeki haber listesi.

Sorunun kaynağı genellikle aynıdır: listeleme sorguları arşiv büyüdükçe doğrusal olarak yavaşlar, çünkü veritabanı her seferinde tüm kayıtları sıralamak zorunda kalır. Çözüm iki katmanlıdır — doğru indeksleme ve sayfalama stratejisi. Klasik OFFSET tabanlı sayfalama, derin sayfalarda (örneğin 400. sayfa) ciddi maliyet üretir; imleç tabanlı sayfalama bunu ortadan kaldırır.

Site içi arama ayrı bir konudur. Veritabanının LIKE sorgusuyla yapılan arama, Türkçe için özellikle zayıftır: "çocuk" araması "cocuk" yazılmışsa sonuç vermez, kök bulma yapmaz, alaka sıralaması üretmez. Ciddi bir haber sitesi tam metin arama altyapısı ister ve bu altyapı Türkçe karakter normalizasyonu ile gövdeleme yapabilmelidir.

• Türkçe karakter duyarsız arama ("şişli" ile "sisli" aynı sonucu vermeli)
• Kök bulma ("seçim" araması "seçimler" ve "seçimin" içeriklerini de bulmalı)
• Alaka sıralaması (başlıkta geçen, gövdede geçenden önce gelmeli)
• Tarih ve kategori süzgeci
• Yazım hatasına tolerans
• Arama sonucu sayfasının kendisinin de hızlı olması

Medya Yönetimi: Görsel, Video ve Galeri

Haber sitelerinde sayfa ağırlığının büyük bölümünü görseller oluşturur ve görsel yönetimi hem performansın hem telifin kesiştiği yerdir. İyi bir haber yazılımı yüklenen her görseli otomatik olarak birden çok boyutta üretir, modern formata çevirir ve doğru boyutu doğru yerde sunar.

• Otomatik boyutlandırma. Manşet, kart, liste ve haber içi için ayrı ölçüler.
• Modern format. WebP ya da AVIF üretimi; eski tarayıcılar için geri düşüş.
• Tembel yükleme. Ekran dışındaki görsellerin sonradan yüklenmesi.
• Alt metin zorunluluğu. Hem erişilebilirlik hem görsel araması için.
• Kaynak ve telif alanı. Görselin nereden geldiği kayıt altında olmalı.
• Odak noktası seçimi. Kırpma sırasında yüzün kesilmemesi için.

Telif alanı çoğu sistemde yoktur ve en pahalı eksikliklerden biridir. Bir görselin nereden alındığı kayıtlı değilse, yıllar sonra gelen bir telif talebinde savunma üretmek neredeyse imkânsızdır. Ücretsiz görsel kaynaklarının lisans koşullarındaki tuzakları ayrı bir yazıda, sosyal medyadaki fotoğrafların haberde kullanımını ise burada ele aldık.

Video tarafında kritik karar barındırma yeridir. Videoyu kendi sunucunuzda tutmak bant genişliği açısından pahalıdır ve oynatıcı deneyimi zayıf kalır; harici bir platformda tutmak ise o platformun kurallarına bağımlılık yaratır. Düzenli video üreten yayınlar için doğru cevap genellikle transcoding destekli ayrı bir video altyapısıdır.

Performans: Son Dakika Trafiğini Kaldırmak

Haber sitesi performansı, ortalama yükle değil zirveyle ölçülür. Sıradan bir günde saatte iki bin ziyaretçi alan bir yerel haber sitesi, büyük bir olayda on dakika içinde yirmi bin ziyaretçi görebilir. Sistem bu ana göre kurulmamışsa, tam da en değerli anda çöker.

Önbellek: en önemli tek karar

Haber sayfaları neredeyse tamamen statiktir; bir haber yayımlandıktan sonra içeriği çok nadir değişir. Bu, önbelleklemeyi son derece etkili kılar. İyi kurulmuş bir önbellek katmanında, aynı haberi okuyan yirmi bin kişi için uygulama sunucusu o sayfayı bir kez üretir; kalan istekler önbellekten karşılanır.

Önbellek katmanları üst üste gelir ve her biri farklı bir işi yapar:

Kritik nokta geçersiz kılma (invalidation) stratejisidir. Bir haber güncellendiğinde yalnızca o haberin değil, onu listeleyen ana sayfanın, kategori sayfasının ve varsa konu sayfasının da tazelenmesi gerekir. Bunu yapmayan sistemlerde "düzelttim ama sitede eski hâli görünüyor" şikâyeti kronikleşir.

Ölçülebilir hedefler

Performans tartışmasını somutlaştırmak için hedef koyun. Google'ın Core Web Vitals ölçütleri iyi bir başlangıçtır ve haber sitelerinde özellikle iki tanesi zorlayıcıdır: en büyük içerik boyamasının hızlı olması ve sayfa yerleşiminin kaymaması. İkincisi haber sitelerinde genellikle reklam alanları yüzünden bozulur; reklam kutularına sabit yükseklik vermek bu sorunu büyük ölçüde çözer.

• Manşet görselinin görünmesi: ilk 2,5 saniye içinde
• Sayfa yerleşim kayması: eşiğin altında, reklam alanlarına sabit yükseklik verilerek
• Sunucu ilk bayt süresi: önbellekten karşılanan sayfalarda birkaç yüz milisaniye
• Son dakika anında hata oranı: sıfıra yakın

Veri Katmanı: Neden Tek Veritabanı Yetmiyor?

Küçük ölçekte tek bir veritabanı her işi görür. Ölçek büyüdüğünde üç ayrı iş birbirinden ayrışır ve aynı araçla üçünü birden iyi yapmak zorlaşır:

• Kayıt tutmak. Haber, kullanıcı, kategori gibi verinin güvenle ve tutarlı biçimde saklanması. Burada ilişkisel bir veritabanı doğru araçtır.
• Hızlı erişmek. Manşet, oturum, sayaç gibi sık okunan küçük verilerin bellekten karşılanması. Burada bir bellek içi depo doğru araçtır.
• Çok satır saymak. "Bu ay hangi kategori kaç okundu" gibi milyonlarca satır tarayan raporlar. Burada sütun tabanlı bir analitik veritabanı doğru araçtır.

Üçünü tek bir ilişkisel veritabanına yaptırmak mümkündür ama üçüncüsü diğer ikisini yavaşlatır: ağır bir rapor sorgusu çalışırken sitenin kendisi yavaşlar. Ayrıştırma, raporun siteyi etkilememesini sağlar. KEYDAL'da bu ayrımın nasıl kurulduğunu — kayıt için PostgreSQL, hızlı erişim için Valkey, raporlar için ClickHouse — ve her katmanda hangi aracın neden seçildiğini teknoloji sayfasında tek tek açıkladık.

Uygulama Katmanı: Node.js Tabanlı Bir Haber Yazılımı Ne Değiştirir?

Uygulamanın hangi teknolojiyle yazıldığı, tek başına iyi ya da kötü bir haber yazılımı üretmez. Ancak haber trafiğinin kendine özgü deseni, bazı mimarileri diğerlerinden daha uygun hâle getirir.

Node.js, JavaScript'i sunucuda çalıştıran bir ortamdır ve olay güdümlü, engellemeyen giriş-çıkış modeliyle bilinir: çok sayıda eşzamanlı bağlantıyı tek iş parçacığıyla verimli karşılar. Haber sitesinin son dakika anı tam olarak bu senaryodur — çok sayıda okur, kısa ömürlü istekler, ağır hesaplama yerine yoğun giriş-çıkış.

• Eşzamanlılık. Her istek için ayrı bir işlem açılmaz; bağlantılar aynı olay döngüsünde yönetilir.
• Gerçek zamanlı yayın. Canlı anlatım, anlık manşet güncellemesi ve push bildirimi mimarinin doğal parçasıdır, sonradan eklenen bir modül değil.
• Tek dil. Sunucu ve tarayıcı tarafı aynı dili konuşur; ekip tek kod tabanında hareket eder, geliştirme döngüsü kısalır.
• Ekosistem. Görsel işleme, akış yönetimi ve arama entegrasyonları için olgun kütüphane havuzu.

Burada dürüst olmak gerekir: PHP ile yazılmış bir haber yazılımı da hızlı olabilir; PHP 8 modern çalışma ortamıyla birlikte hatırı sayılır bir performans sunar ve "PHP yavaştır" cümlesi bugün doğru değildir. Belirleyici olan dil değil, uygulamanın etrafındaki katmanlardır: önbellek stratejisi, veri ayrımı, dağıtım ağı ve arama motoruna bildirim düzeni. Seçenekler arasındaki farkı haber scripti ve hazır haber sitesi karşılaştırmasında ayrıntılı ele aldık.

Arama Motoru Görünürlüğü: Haber Sitesinde En Pahalı Kayıp Gecikmedir

Genel bir web sitesinde arama motoru optimizasyonu aylara yayılan bir çalışmadır. Haber sitesinde ise bir boyut daha vardır: zaman. Bir son dakika haberi, yayımlandıktan on beş dakika sonra indekslendiğinde çoğu değerini kaybetmiş olur; çünkü o konuyu arayan okur ilk yarım saat içinde arar ve ilk indekslenen sonuçları görür. Haber sitesinde en pahalı kayıp, yazılan haberin geç bulunmasıdır.

Bu yüzden haber yazılımında SEO, sonradan eklenen bir eklenti değil mimarinin parçası olmalıdır. Aşağıdaki başlıklar, yazılımın karşılaması gereken kalemleri sıralıyor.

Teknik temeller

• Temiz ve kalıcı adresler. Haber adresi yayımlandıktan sonra değişmemeli; değişirse eski adres yeni adrese kalıcı yönlendirilmeli.
• Kanonik adres. Aynı haberin kategori altından, etiketten veya parametreli adresten erişilebildiği durumlarda tek bir asıl adres bildirilmeli.
• Site haritası. Otomatik üretilmeli ve yeni haber eklendiğinde güncellenmeli.
• Haber site haritası. Son iki günün haberlerini içeren ayrı bir harita, Google'ın haber tarafı için ayrı bir sinyaldir.
• robots.txt. Panelin, arama sonucu sayfalarının ve süzgeç parametrelerinin taranmaya kapatılması.
• Sayfalama işaretleri. Derin kategori sayfalarının taranabilir kalması.
• Mobil uyum. Google mobil öncelikli indeksleme yapar; masaüstünde iyi görünen ama mobilde bozulan bir tema doğrudan sıralama kaybıdır.

Bu kalemlerin çoğu bir kez doğru kurulur ve sonra kendiliğinden çalışır. Yazılımı değerlendirirken sorulacak soru "SEO desteği var mı" değil, "bunların hangileri otomatik, hangileri elle yapılıyor" olmalıdır. Elle yapılan her kalem, günlük yayın temposunda er geç atlanır.

Başlık ve açıklama

Haber sitelerinde sayfa başlığı iki farklı yerde iş görür: sitenin kendi manşetinde ve arama sonucunda. İkisinin aynı olması zorunlu değildir ve çoğu zaman aynı olmamalıdır. Manşet başlığı merak uyandırmak için kısa ve çarpıcı olabilir; arama sonucundaki başlığın ise arananı içermesi gerekir.

İyi bir haber yazılımı bu ikisini ayrı tutmanıza izin verir: bir h1 başlığı, bir de arama için başlık alanı. Google'ın kendi rehberi başlık için katı bir karakter sınırı koymaz; önemli olan başlığın sayfayı doğru tarif etmesi ve önemli kısmın başta olmasıdır. Uzun başlıklar arama sonucunda kırpılabilir, bu bir ceza değil görüntüleme tercihidir.

Meta açıklama sıralama faktörü değildir ama tıklama oranını etkiler. Haber yazılımı, açıklama boş bırakıldığında haberin spotunu kullanacak şekilde kurulmalıdır; boş açıklama, Google'ın sayfadan rastgele bir cümle seçmesine yol açar.

Yapılandırılmış veri

Yapılandırılmış veri, arama motoruna sayfanın ne olduğunu makine tarafından okunabilir biçimde söyler. Haber sitesinde en az üç tür kullanılır:

Yapılandırılmış veride en sık yapılan hata, sayfada olmayan bir şeyi bildirmektir. Google'ın yapılandırılmış veri politikaları bunu açıkça yasaklar: işaretlediğiniz içerik kullanıcıya da görünmelidir. Özellikle puanlama işaretlemesi konusunda dikkatli olun — gerçek bir değerlendirme toplamıyorsanız aggregateRating eklemek politika ihlalidir ve elle işlem riski taşır.

Google News ve Discover

Google News'te görünmek için ayrı bir başvuru yapmak bugün zorunlu değildir; Google haber içeriğini kendi tarayıcısıyla keşfeder. Ancak Yayıncı Merkezi üzerinden yayın kimliğinizi tanımlamak, logo ve bölüm düzeninizi bildirmenizi sağlar.

Discover ise farklı çalışır: aramaya değil, kullanıcının ilgi alanına dayanır. Discover'da görünmenin en belirleyici teknik şartı yüksek çözünürlüklü görseldir; küçük görselli haberler bu akışa neredeyse hiç düşmez. Yazılımın her haber için geniş formatlı bir kapak görseli üretebilmesi bu yüzden önemlidir.

• Her haberde geniş formatlı, yüksek çözünürlüklü kapak görseli
• Yazar bilgisi ve yayın tarihinin açıkça görünmesi
• Tıklama tuzağı başlıklardan kaçınmak — Discover bunu doğrudan cezalandırır
• Sayfanın mobilde hızlı açılması

Hızlı indeksleme: IndexNow ve bildirim düzeni

Arama motorunun yeni haberi bulmasını beklemek yerine, haberi ona bildirmek mümkündür. IndexNow protokolü tam olarak bunu yapar: bir adres yayımlandığında ya da güncellendiğinde arama motorlarına anında bildirim gönderilir. Protokolü destekleyen motorlar bu bildirimi tarama sırasına alır.

Bunun haber sitesindeki karşılığı doğrudan gelir etkisidir. Bir son dakika haberinin indekslenme süresinin yarım saatten birkaç dakikaya inmesi, o haberin ilk sayfada görünüp görünmemesini belirleyebilir. Yazılımınızın yayımlama anında hangi bildirimleri gönderdiğini sorun:

• IndexNow bildirimi (destekleyen motorlara)
• Site haritasının güncellenmesi
• Haber site haritasının güncellenmesi
• RSS akışının tazelenmesi
• Dağıtım ağı önbelleğinin ilgili sayfalarda temizlenmesi

AMP hâlâ gerekli mi?

AMP, mobilde hızlı açılan sadeleştirilmiş sayfa formatıdır. Bir dönem Google'ın Top Stories karuselinde görünmenin ön şartıydı; bu şart kaldırıldı. Bugün AMP kullanmak bir sıralama avantajı sağlamaz.

Buna rağmen AMP'nin hâlâ anlamlı olduğu durumlar var: ana temanız ağırsa ve kısa vadede hafifletemiyorsanız, AMP mobil okur için gözle görülür bir hız farkı yaratır. Ancak doğru yol, AMP'yi bir yama olarak kullanmak yerine asıl temayı hafifletmektir. Yazılım AMP üretebiliyorsa iyidir; üretemiyor diye elenmemelidir.

Push bildirim

Push bildirim, haber sitelerinde arama motoruna bağımlılığı azaltan en etkili kanaldır. Okur bir kez izin verdiğinde, son dakika haberini doğrudan ona ulaştırabilirsiniz. Ancak yanlış kullanıldığında en hızlı okur kaybettiren kanaldır da.

• İzin isteme zamanlaması. Siteye girer girmez izin istemek, izin oranını düşürür. Okur en az bir haberi okuduktan sonra sorun.
• Sıklık sınırı. Günde birkaç bildirimi geçmeyin; son dakika dışında bildirim göndermeyin.
• Segment. Mümkünse kategori bazlı abonelik sunun; spor okuru ekonomi bildirimi istemez.
• Geri bildirim. Hangi bildirimin kaç tıklama aldığını ölçün.
• Kolay iptal. Abonelikten çıkmak zorlaştırıldığında okur siteyi tamamen terk eder.

Sosyal paylaşım kartları

Bir haber sosyal ağda paylaşıldığında görünen görsel, başlık ve açıklama, sayfadaki paylaşım etiketlerinden okunur. Bu etiketlerin eksik olması, paylaşımda boş bir kutu ya da rastgele bir görsel çıkması demektir; tıklama oranını doğrudan düşürür.

Yazılımın her haber için otomatik olarak doğru boyutta bir paylaşım görseli üretmesi ve görsel yoksa büyük kart yerine küçük kart bildirmesi gerekir. Büyük kart vaat edip görsel vermemek, paylaşımda boş kutu üretir.

Ölçümleme ve trafik raporları

Haber merkezinin ihtiyacı olan rapor, genel analitik araçlarının sunduğundan farklıdır. Gazeteci "oturum süresi" değil "bu haber kaç kişi tarafından okundu ve nereden geldi" bilgisini ister ve bunu ertesi gün değil o anda ister.

• Canlı okur sayısı ve o an en çok okunan haberler
• Haber bazlı okunma, kaynak kırılımı ve ortalama okuma oranı
• Muhabir ve kategori bazlı performans
• Arama, sosyal, doğrudan ve push kaynak ayrımı
• Haftalık ve aylık karşılaştırma

Bu raporların site performansını etkilememesi için ayrı bir analitik veri deposunda üretilmesi gerekir; aksi hâlde ay sonu raporu çalışırken sitenin kendisi yavaşlar.

Mevzuat: Yazılımın Karşılamak Zorunda Olduğu Yükümlülükler

Türkiye'de haber yazılımı seçimini diğer ülkelerden ayıran şey budur. 13/10/2022 tarihli 7418 sayılı Kanun, 5187 sayılı Basın Kanunu'nun 2. maddesinin (c) bendini değiştirerek internet haber sitelerini süreli yayın tanımının içine aldı. Bunun sonucu şudur: yazılı basın için yıllardır var olan yükümlülüklerin bir kısmı artık internet haber sitelerine de uygulanıyor ve bunların birkaçı doğrudan yazılımın karşılaması gereken teknik kalemler.

Aşağıdaki üç başlık, bir haber yazılımının olmazsa olmazlarıdır. Demo sırasında üçünü de gözünüzle görmeden satın almayın.

Künye — m.4/3

Kanun'un 4. maddesine 7418 ile eklenen fıkra, internet haber sitelerinde belirli bilgilerin kullanıcıların ana sayfadan doğrudan ulaşabileceği şekilde ve "iletişim" başlığı altında bulundurulmasını arıyor. Altı kalem sayılmış:

• Faaliyet gösterilen iş yeri adresi
• Ticari unvan
• Elektronik posta adresi
• İletişim telefonu
• Elektronik tebligat adresi
• Yer sağlayıcısının adı ve adresi

Buradaki iki ayrıntı sık atlanır. Birincisi elektronik tebligat adresi: sıradan bir e-posta değil, tebligata elverişli kayıtlı adrestir. İkincisi yer sağlayıcısının adı ve adresi: sitenizi kimin barındırdığını künyede yazmanız gerekir; kendi sunucunuzu kullanıyorsanız bile bu bilgi eksik bırakılamaz.

Yazılım tarafındaki karşılığı, künyenin serbest metin bir sayfa olarak değil yapılandırılmış alanlar olarak tutulmasıdır. Serbest metinde bir kalem silindiğinde kimse fark etmez; alan bazlı tutulduğunda sistem eksiği gösterebilir. Künyenizi künye üreteci ile hazırlayıp künye denetleyicisiyle eksik kalıp kalmadığını ölçebilir, ayrıntılı açıklaması için künye şablonu yazısına bakabilirsiniz.

Tarih damgası — m.4/4

Aynı maddeye eklenen dördüncü fıkra ayrı bir yükümlülük getiriyor: bir içeriğin ilk kez sunulmaya başlandığı tarih ile sonraki güncelleme tarihleri, her erişildiğinde değişmeyecek şekilde içeriğin üzerinde belirtilir.

"Her erişildiğinde değişmeyecek şekilde" ifadesi teknik bir şart koyuyor. Pek çok haber teması tarihi "3 saat önce", "dün" gibi göreli biçimde gösterir; bu ifade her sayfa açılışında değişir ve tek başına yeterli değildir. Sabit tarih görünmelidir. Göreli ifadeyi tamamen kaldırmak zorunda değilsiniz; sabit tarihin yanında ek bilgi olarak kalabilir.

İkinci ayrıntı, güncelleme tarihlerinin de gösterilmesidir. Yazılımın ilk yayım anını ve güncelleme anını ayrı alanlarda tutması, ikisini de basabilmesi gerekir. Tek bir "tarih" alanı tutup güncellemede onu ezen bir sistem bu şartı karşılayamaz.

İki yıllık arşiv — m.10

Kanun'un 10. maddesine 7418 ile eklenen fıkra şunu arıyor: internet haber sitesinde yayınlanan içerikler, gerektiğinde talep eden Cumhuriyet Başsavcılığına teslim edilmek üzere doğruluğu ve bütünlüğü sağlanmış şekilde iki yıl süre ile muhafaza edilir. Aynı maddenin devamı, yargı mercileri tarafından yayının soruşturma veya kovuşturma konusu olduğu yazılı olarak bildirilirse, bu işlemler sonuçlanana kadar o yayın kaydının saklanmasını zorunlu kılıyor.

Buradaki kritik ifade "doğruluğu ve bütünlüğü sağlanmış şekilde"dir. Yalnızca içeriği bir yerde tutmak yetmez; o içeriğin sonradan değiştirilmediğini gösterebilmek gerekir. Pratikte bunun anlamı, arşivin salt okunur olması ve her kaydın bir bütünlük özeti taşımasıdır.

Yazılım tarafında sorulacak sorular şunlardır:

• Yayımlanan her sürüm ayrı ayrı saklanıyor mu, yoksa yalnızca son hâli mi duruyor?
• Arşiv kaydı, içerik değiştirilmeden mi tutuluyor? Bütünlük özeti üretiliyor mu?
• Siteden kaldırılan bir haber arşivde kalıyor mu?
• Talep gelmesi hâlinde arşiv hangi formatta teslim edilebiliyor?
• İki yıllık arşiv ne kadar disk alanı tutuyor?

Son soru bütçe kalemidir ve sık atlanır. Görselleriyle birlikte iki yıllık arşiv, orta ölçekli bir yerel haber sitesinde ciddi bir depolama ihtiyacı üretir; ne kadar yer gerektiğini arşiv boyutu hesaplayıcısıyla önden görebilir, hangi kanıtların saklanması gerektiğini içerik arşivi bütünlük aracıyla çıkarabilirsiniz.

Cevap ve düzeltme — m.14

Kişilik hakkı zarar gören kişinin cevap ve düzeltme hakkı, basın hukukunun en eski kurumlarından biridir ve internet haber sitelerine de uygulanır. Yazılım açısından iki gereklilik doğar: gelen talebin kaydı ve yayımlanan düzeltmenin ilgili haberle bağlantılı olarak gösterilmesi.

Süreler kısadır ve kaçırılması ayrı bir sorumluluk üretir. Talep geldiğinde saymaya başlayan süreleri cevap ve düzeltme dilekçesi yazısında ele aldık; hangi tarihte ne yapmanız gerektiğini panelden çıkmadan hesaplamak için ilgili araçları araçlar sayfasında topladık.

KVKK ve okur verisi

Haber sitesi, okurundan veri toplar: yorum yazarken e-posta, bültene abone olurken ad-soyad, ziyaret sırasında çerez. Bunların her biri 6698 sayılı Kanun kapsamında kişisel veri işlemedir ve yazılımın buna uygun araçlar sunması gerekir.

• Aydınlatma metninin ilgili formlarda gösterilmesi
• Çerez yönetim aracı ve tercihlerin saklanması
• Veri sahibi başvurularının kaydı
• Yorum ve abonelik verilerinin dışa aktarılabilmesi ve silinebilmesi
• Erişim kayıtlarının makul bir süreyle sınırlı tutulması

Gazetecilik faaliyetinin KVKK karşısındaki konumu ayrı ve incelikli bir konudur; istisnanın kapsamını ayrı bir yazıda ele aldık. Kayıt yükümlülüğü tarafında ise VERBİS kaydının gerekip gerekmediğini erken kontrol etmekte fayda var.

Yorumlar ve sorumluluk

Okur yorumu açmak, okur bağlılığı için değerlidir ama sorumluluk tarafı vardır. Yazılımın sunması gereken asgari araçlar şunlardır: yayın öncesi onay seçeneği, kelime süzgeci, bildirme (şikâyet) düğmesi, yorum sahibinin bağlantı kaydının tutulması ve toplu moderasyon ekranı.

Moderasyonun zorunlu olup olmadığı ve sitenin yorumdan doğan sorumluluğunun sınırları sık sorulan bir konu; yorumlardan doğan sorumluluk ve moderasyon zorunluluğu yazılarında ayrıntılı ele aldık.

Telif: alıntı, görsel ve ajans içeriği

Haber üretiminin doğası gereği başkasının ürettiği içerikten yararlanırsınız: bir başka yayının haberinden alıntı, bir sosyal medya gönderisi, bir ajans fotoğrafı. Yazılım bu kullanımı izlenebilir kılmalıdır — her görselin kaynağı ve lisansı, her alıntının atfı kayıt altında olmalıdır.

Sınırlar sanıldığından dardır. Alıntının serbest olduğu hâller, ne kadar metin kullanılabileceği ve kaynak göstermenin izin yerine geçip geçmediği ayrı ayrı düzenlenmiştir; haber alıntılama, alıntı ölçüsü ve kaynak gösterme yazıları bu üç soruyu ayrı ayrı cevaplıyor.

Resmî ilan: yazılımın çözebildiği ve çözemediği

Resmî ilan yayımlama hakkı, birçok yerel yayın için en istikrarlı gelir kalemidir ve bu yüzden "yazılımınız BİK uyumlu mu" sorusu sık sorulur. Dürüst cevap iki parçalıdır.

Yazılımın çözebildiği kısım teknik şartlardır: içerik arşivinin düzgün tutulması, künyenin eksiksiz olması, sitenin kesintisiz erişilebilir olması, haber ve ziyaretçi trafiğinin ölçülebilmesi. Yazılımın çözemediği kısım ise personel şartıdır — asgari fikir işçisi kadrosu bir insan kaynağı meselesidir ve hiçbir yazılım bunu karşılayamaz.

Durumunuzu önden ölçmek için iki araç var: yayın yerinize göre hangi kategoriye düştüğünüzü medya kuruluşu nitelik aracı, kadro şartını karşılayıp karşılamadığınızı asgari kadro nitelik testi gösteriyor. Basın kartı tarafında kaç kişilik kontenjanınız olduğunu ise kontenjan hesaplayıcısı hesaplıyor.

Yükümlülüklerin tamamını dayanaklarıyla birlikte tek listede görmek isterseniz internet haber sitesi yasal uyum kontrol listesi maddeleri sırayla kapatmanızı sağlıyor.

Güvenlik: Haber Siteleri Neden Hedef?

Haber siteleri iki ayrı saldırgan grubunun ilgisini çeker. Birincisi otomatik tarayıcılardır: bilinen açıkları arayan, siteye özel bir husumeti olmayan botlar. İkincisi hedefli saldırganlardır: yayımlanan bir habere tepki olarak siteyi erişilemez kılmak ya da içeriği değiştirmek isteyenler. İkinci grup, sıradan bir kurumsal siteyi hedef almaz; haber sitesini alır.

Yazılım ve altyapı tarafında beklenen asgari önlemler şunlardır:

• Güncel çalışma ortamı. Uygulama ve bağımlılıklarının düzenli güncellenmesi; kim güncelliyor sorusunun net cevabı olması.
• İki aşamalı doğrulama. Panel girişlerinde, özellikle yayın yetkisi olan hesaplarda.
• Yetki sınırlaması. Her kullanıcının yalnızca ihtiyacı olan yetkiye sahip olması.
• Giriş denemesi sınırı. Kaba kuvvet saldırılarına karşı hız sınırlama.
• Web uygulaması güvenlik duvarı. Yaygın saldırı desenlerinin uygulamaya ulaşmadan durdurulması.
• DDoS koruması. Hacimsel saldırıların dağıtım ağı katmanında soğurulması.
• Yükleme denetimi. Panele yüklenen dosyaların türünün ve içeriğinin doğrulanması.
• Kayıt tutma. Kimin ne zaman ne yaptığının izlenebilmesi.

Bu listede en çok atlanan madde sonuncusudur. Bir olay yaşandığında en kritik soru "ne oldu" değil "ne zaman ve nereden oldu"dur; kayıt yoksa cevap da yoktur. Sunucu tarafındaki genel güvenlik pratiklerini güvenlik duvarı rehberinde ayrıca ele aldık.

Yedekleme ve Felaket Kurtarma

Yedek, alındığı için değil geri yüklenebildiği için yedektir. Haber sitelerinde yedekleme sorusu üç ayrı soruya ayrılır ve üçünün de yazılı cevabı olmalıdır.

Son satır belirleyicidir. Hiç test edilmemiş bir yedek, olmayan bir yedekle aynıdır; kriz anında bozuk çıktığını öğrenmek en kötü senaryodur. Sağlayıcınıza "en son ne zaman geri yükleme testi yaptınız" diye sorun.

En İyi Haber Yazılımı Nasıl Seçilir?

"En iyi haber yazılımı" sorusunun mutlak bir cevabı yoktur; çünkü doğru cevap yayının ölçeğine, ekibin teknik kapasitesine ve gelir modeline göre değişir. Ancak seçimi öznellikten çıkaran bir çerçeve kurulabilir. Aşağıdaki yedi eksende puanlayın; ağırlıkları kendi önceliğinize göre belirleyin.

Son eksen en az sorulan ama en önemli olanıdır. Bir sağlayıcıyla çalışmaya başlarken ayrılma senaryosunu konuşmak tuhaf gelebilir; ancak verinizi hangi formatta alabileceğinizi bilmek, ilişkinin sağlığını da belirler. İçeriğinizi standart bir formatta dışa aktaramıyorsanız, teknik olarak kilitlenmişsiniz demektir.

Kırmızı bayraklar

• Demo yalnızca hazır ekran görüntüleriyle yapılıyorsa
• "Sınırsız" ifadesi teknik bir açıklama olmadan kullanılıyorsa
• Referans site istendiğinde canlı adres verilemiyorsa
• Fiyat kalemleri ayrıştırılamıyorsa
• Sözleşmede veri sahipliği açıkça yazmıyorsa
• Güncellemelerin kim tarafından kurulacağı belirsizse
• Puanlama işaretlemesi gibi politika riski taşıyan "SEO numaraları" özellik olarak sunuluyorsa

Profesyonel Haber Sitesi Yazılımı: Kurumsal Ölçekte Ek Gereksinimler

Tek şehirlik bir yayınla ulusal ölçekte çalışan bir haber merkezinin ihtiyaçları aynı değildir. Profesyonel ölçekte şu başlıklar ek gereksinim olarak devreye girer:

• Çoklu yayın yönetimi. Aynı panelden birden fazla site ya da bölgesel sürüm yönetebilmek.
• Ajans beslemesi entegrasyonu. Gelen akışın otomatik alınması, editör onayına düşmesi, kaynak bilgisinin korunması.
• Redaksiyon ve dil denetimi. Yayın öncesi otomatik yazım denetimi ve stil kılavuzu uyarıları.
• Yayın planı. Haftalık ve aylık içerik takvimi, dosya planlaması.
• Gelişmiş yetki matrisi. Kategori ve bölge bazlı yetkilendirme.
• API erişimi. Mobil uygulama, ekran yayını ve iş ortakları için içerik sunumu.
• Denetim kaydı. Hukuki süreçlerde kullanılabilecek ayrıntılı işlem geçmişi.
• Test ortamı. Tema ve modül değişikliklerinin canlıya çıkmadan denenmesi.

Son madde profesyonel ölçeğin ayırt edici işaretidir. Canlı sitede deneme yapan bir yayın, er ya da geç okur önünde bozulur. Ölçeğe göre farklılaşan altyapı ihtiyacını ulusal haber portalı ve haber ajansı çözüm sayfalarında ayrı ayrı ele aldık; gazete, radyo ve web TV'yi birlikte yürüten kuruluşlar için yerel medya kuruluşu paketi dört bileşeni tek altyapıda topluyor.

Satın Alma Modelleri ve Fiyatlandırma

Haber yazılımı üç ayrı modelle satılır ve fiyatı karşılaştırılabilir kılmak için önce modeli netleştirmek gerekir.

• Tek seferlik lisans. Yazılım bedeli bir kez ödenir. Hosting, güncelleme ve destek genellikle ayrıdır.
• Abonelik. Aylık ya da yıllık ödeme; güncelleme ve destek dahildir.
• Lisans + barındırma paketi. Yazılım bedeli bir kez, işletme bedeli aylık; sunucu ve bakım sağlayıcıda kalır.

Teklifleri karşılaştırırken aynı kalemleri iki tarafta da doldurun. Aşağıdaki tablo, çoğu zaman gözden kaçan kalemleri içeriyor:

Bu on kalem doldurulduğunda ilk bakışta ucuz görünen teklifin üç yıllık toplamda pahalıya oturduğu sık görülen bir sonuçtur. KEYDAL tarafındaki güncel bedelleri ve hangi paketin neyi kapsadığını fiyatlandırma sayfasında topluca görebilirsiniz.

Taşıma: Mevcut Siteyi ve Arşivi Aktarmak

Çoğu yayın sıfırdan başlamaz; hâlihazırda çalışan bir sitesi ve yıllarca birikmiş bir arşivi vardır. Taşıma, yazılım değişikliğinin en riskli aşamasıdır ve iyi yönetilmediğinde yıllarca biriken arama motoru değerini bir haftada kaybettirir.

Sağlıklı bir taşıma şu adımları içerir:

• 1. Envanter. Mevcut adreslerin tam listesi çıkarılır; hangi sayfa hangi trafiği alıyor, ölçülür.
• 2. Adres eşlemesi. Her eski adresin yeni karşılığı belirlenir. Karşılığı olmayan adres için en yakın eşdeğer seçilir.
• 3. İçerik aktarımı. Haberler, görseller, kategoriler ve yazar bilgileri aktarılır; tarih alanları korunur.
• 4. Test ortamı. Yeni site geçici bir adreste kurulur; siz canlıda yayına devam ederken kopya üzerinde çalışılır.
• 5. Birlikte kontrol. Manşet, kategori, arama ve rastgele seçilmiş eski haberler karşılaştırılır.
• 6. Geçiş. Alan adı yönlendirilir, eski adresler kalıcı olarak yeni adreslere yönlendirilir.
• 7. Geçiş sonrası izleme. İlk hafta tarama hataları ve sıralama kayıpları günlük izlenir.

Altıncı adımdaki yönlendirme türü kritiktir: geçici yönlendirme kullanmak, arama motorunun eski adresi tutmaya devam etmesine yol açar. Kalıcı yönlendirme, biriken değeri yeni adrese aktarır. KEYDAL'ın taşıma sürecini — test kurulumu, birlikte kontrol ve geçiş adımlarıyla — site taşıma sayfasında anlattık.

Ekip, Eğitim ve Devreye Alma

En iyi yazılım bile kullanılmıyorsa işe yaramaz. Devreye alma sürecinde en sık yapılan hata, eğitimi tek bir toplantıya sıkıştırmaktır. Haber merkezleri yoğun çalışır; iki saatlik bir eğitimde anlatılanın büyük kısmı ertesi gün unutulur.

• Rol bazlı eğitim. Muhabire manşet yönetimi anlatmayın; ihtiyacı olanı anlatın.
• Kısa ve tekrarlı. Tek uzun oturum yerine haftaya yayılmış kısa oturumlar.
• Yazılı kılavuz. Ekran görüntülü, aranabilir, kendi sitenize özel.
• Bir iç uzman. Ekipten bir kişinin sistemi derinlemesine öğrenmesi, dış desteğe bağımlılığı azaltır.
• İlk hafta yakın destek. Geçişin ilk günlerinde hızlı yanıt, alışkanlığın oturmasını belirler.

Sık Yapılan On Hata

• Tema üzerinden karar vermek. Tasarım değişir; veri modeli değişmez.
• Demo verisiyle test etmek. Yirmi haberde her sistem hızlıdır.
• Mevzuat kalemlerini sonraya bırakmak. Sonradan eklemek her haber sayfasına dokunmayı gerektirir.
• Kategori enflasyonu. On beş kategorinin çoğu boş kalır.
• Yedeği test etmemek. Test edilmemiş yedek yedek değildir.
• Yetkileri ayırmamak. Herkesin her şeyi yapabildiği panel, er geç bir kazayla sonuçlanır.
• Push bildirimi aşırı kullanmak. En hızlı okur kaybettiren kanaldır.
• Görsel kaynağını kaydetmemek. Telif talebinde savunma üretilemez.
• Çıkış senaryosunu konuşmamak. Verinizi alamıyorsanız kilitlenmişsinizdir.
• Sahte puan işaretlemesi. Kısa vadeli tıklama, uzun vadeli elle işlem riski.

Tema ve Tasarım Sistemi

Haber sitesi tasarımı, kurumsal site tasarımından farklı bir problemdir. Kurumsal sitede sayfa sayısı azdır ve her sayfa özel olarak tasarlanabilir. Haber sitesinde binlerce sayfa aynı şablondan üretilir; tasarım bu yüzden bir sayfa değil bir sistem olmak zorundadır.

İyi bir haber teması şu bileşenleri tutarlı biçimde tanımlar:

• Düzen ailesi. Manşet, ızgara, dergi ve liste gibi birden çok vitrin düzeni; kategoriye göre farklı düzen seçilebilmesi.
• Kart tipleri. Büyük manşet kartı, orta kart, küçük liste satırı — her biri farklı görsel oranıyla.
• Tipografi ölçeği. Başlık, spot, gövde ve alt bilgi için sabit bir ölçek; her sayfada aynı hiyerarşi.
• Reklam alanları. Sabit yükseklikli, yerleşimi kaydırmayan, mobilde ayrı tanımlı.
• Renk sistemi. Kategori renkleri, uyarı ve etiket renkleri; açık ve koyu tema karşılıkları.
• Boşluk ölçeği. Bileşenler arası mesafenin tek bir ölçekten türemesi.

Okunabilirlik tarafında haber sitelerinin en sık yaptığı hata gövde metnini fazla küçük ve fazla geniş dizmektir. Uzun bir haberin rahat okunması için satır uzunluğu makul tutulmalı, satır yüksekliği ferah olmalı ve gövde punto ölçüsü mobilde küçültülmemelidir. Bunlar estetik tercih değil, okuma süresini ve dolayısıyla sayfa değerini doğrudan etkileyen kararlardır.

Tema değişikliğinin en riskli yanı, mevzuat kalemlerinin tema katmanında durmasıdır. Künye bağlantısı ve tarih damgası temaya gömülüyse, tema değiştiğinde bunlar sessizce kaybolabilir. Sağlam bir haber sitesi yazılımında bu iki kalem tema seçiminden bağımsız olarak basılır.

Reklam Yönetimi ve Gelir Kalemleri

Haber yazılımının ticari tarafı, reklam alanlarını yönetme biçimidir. Burada iki ayrı ihtiyaç vardır: programatik reklam ağlarının kodlarını yerleştirmek ve doğrudan satılan reklamları panelden yönetmek.

Reklam alanı yönetimi

• Alan bazlı tanım: ana sayfa üst, haber içi, yan sütun, mobil yapışkan.
• Kampanya bazlı yükleme: başlangıç–bitiş tarihi, gösterim veya tıklama hedefi.
• Kategori hedefleme: yalnızca spor kategorisinde gösterilecek reklam.
• Gösterim ve tıklama sayacı: reklam verene rapor verebilmek için.
• Reklam engelleyici oranının ölçülmesi.
• Yedek içerik: kampanya bittiğinde alanın boş kalmaması.

Performans açısından kritik nokta, reklam kodlarının sayfa yüklenmesini engellememesidir. Reklam betikleri eşzamansız yüklenmeli, alanlar sabit yükseklikle rezerve edilmelidir; aksi hâlde reklam geldiğinde içerik aşağı kayar ve hem okur deneyimi hem Core Web Vitals ölçümü bozulur.

Sponsorlu içerik ve etiketleme

Doğrudan satılan içerik — advertorial, sponsorlu haber, iş birliği — haber sitelerinde önemli bir gelir kalemidir ve etiketleme kuralları vardır. Okurun bir içeriğin reklam olduğunu ilk bakışta anlaması gerekir; bunu gizlemek örtülü reklam sayılır ve yaptırıma tabidir.

Yazılım tarafında beklenen, sponsorlu içerik için ayrı bir içerik tipi ya da en azından görünür bir etiket alanıdır. Etiketin küçük puntoyla dipnota sıkıştırılması yeterli sayılmaz. Konunun ayrıntılarını advertorial etiketleme, örtülü reklam yaptırımı ve iş birliği bildirimi yazılarında ele aldık.

Gelir kalemlerinin dağılımı

Tek gelir kalemine bağlı bir haber sitesi kırılgandır. Sağlıklı bir yayın en az üç kalemi birlikte yürütür:

Resmî ilan kaleminin şartlarını ve yazılımın bu şartların hangi kısmını karşılayabildiğini yukarıda ayrıca ele aldık; durumunuzu medya kuruluşu nitelik aracıyla ölçebilirsiniz.

Bülten ve İzinli İletişim

E-posta bülteni, arama motoruna ve sosyal ağa bağımlılığı azaltan en dayanıklı kanaldır. Algoritma değişikliğinden etkilenmez ve okur listesi size aittir. Bu yüzden ciddi haber siteleri bülteni ikincil bir özellik değil ana kanal olarak kurgular.

Yazılım tarafında beklenenler:

• Abonelik formu ve çift onaylı kayıt
• Otomatik bülten derlemesi (günün öne çıkanları)
• Segment: kategori bazlı abonelik
• Açılma ve tıklama ölçümü
• Tek tıkla abonelikten çıkma
• Abone listesinin dışa aktarılabilmesi

Hukuki tarafı ihmal etmeyin. Ticari elektronik ileti göndermek izne tabidir ve iznin nasıl alındığının kanıtlanabilmesi gerekir; abonelikten çıkma yolu her iletide bulunmalıdır. Bülten göndermek için iznin şart olup olmadığını ve istisnaların sınırını ayrı bir yazıda ele aldık. Toplanan okur verisi için aydınlatma yükümlülüğünü ise okur verisi aydınlatma metni yazısında anlattık.

Canlı Anlatım ve Gelişen Haber

Deprem, seçim gecesi, önemli bir duruşma — bu olaylarda okur tek bir haber değil akan bir güncelleme dizisi bekler. Canlı anlatım (liveblog) formatı tam olarak bunu karşılar ve bir haber yazılımının en çok fark yarattığı özelliklerden biridir.

İyi bir canlı anlatım şunları sağlar:

• Zaman damgalı giriş. Her güncelleme kendi saatiyle, en yeni üstte.
• Otomatik yenileme. Okurun sayfayı yenilemeden yeni girişleri görmesi.
• Kalıcı bağlantı. Her girişin ayrı adresi olması, paylaşılabilmesi.
• Özet bloğu. Sayfaya sonradan gelen okur için "şu ana kadar ne oldu".
• Çoklu editör. Aynı anda birden fazla kişinin giriş yapabilmesi.
• Arşive dönüşme. Olay bittiğinde sayfanın normal habere dönüşmesi.

Teknik olarak canlı anlatım, sunucudan tarayıcıya sürekli bağlantı gerektirir. Bu, olay güdümlü mimarinin doğal olarak iyi yaptığı iştir; binlerce okurun aynı anda açık tuttuğu bağlantıları verimli yönetebilmek gerekir. Geleneksel istek-cevap modelinde her açık bağlantı bir kaynak tüketir ve ölçek hızla sorun hâline gelir.

Canlı anlatımın mevzuat tarafı da vardır: her giriş yayımlanmış içeriktir. Tarih damgası ve arşiv yükümlülükleri canlı anlatım girişleri için de işler; sistemin bunları tek tek arşivlemesi gerekir.

Mobil Uygulama ve API

Her haber sitesinin mobil uygulamaya ihtiyacı yoktur. Uygulama, yalnızca düzenli olarak geri gelen sadık bir okur kitlesi oluşmuşsa anlamlıdır; aksi hâlde indirilir, bir kez açılır ve silinir. Ancak o kitle oluştuğunda uygulama, push bildirim izin oranı ve okuma sıklığı bakımından mobil siteden belirgin biçimde iyidir.

Uygulama kararı verildiğinde asıl soru şudur: içerik uygulamaya nasıl akacak? Cevap bir APIdir. Haber yazılımının içeriği yapılandırılmış biçimde dışarıya sunabilmesi gerekir. Aynı API başka işleri de mümkün kılar:

• Mobil uygulama ve tablet sürümü
• Bina girişindeki ekran yayını, kurumsal ekranlar
• İş ortaklarına içerik besleme
• Ajans müşterilerine dağıtım
• Yapay zekâ ve arama servislerinin içeriği okuması
• Yedekleme ve dışa aktarma

API'nin varlığı kadar niteliği de önemlidir: sürümlenmiş mi, hız sınırı var mı, kimlik doğrulaması nasıl yapılıyor, hangi alanları döndürüyor? Özellikle son soru kritiktir — API haberin gövdesini döndürmüyorsa mobil uygulama yazmanın anlamı kalmaz.

Dışa aktarma açısından da API bir sigortadır. Sağlayıcıdan ayrılmak istediğinizde içeriğinizi standart bir formatta çekebiliyor olmanız, teknik bağımlılığı ortadan kaldırır.

Erişilebilirlik

Erişilebilirlik, haber sitelerinde en çok ihmal edilen başlıktır ve ihmalin iki maliyeti vardır. Birincisi doğrudan okur kaybıdır: ekran okuyucu kullanan, düşük görüşlü ya da yalnızca klavyeyle gezinen okurlar siteyi kullanamaz. İkincisi dolaylıdır: erişilebilirlik için yapılan pek çok düzenleme arama motoru için de iyidir.

• Görsel alt metni. Her görselin ne anlattığını yazan metin; dekoratif görsellerde boş bırakılır.
• Başlık hiyerarşisi. Sayfada tek bir birinci düzey başlık, altında sıralı alt başlıklar.
• Renk karşıtlığı. Metin ile arka plan arasında yeterli kontrast; gri üzerine açık gri okunmaz.
• Klavye ile gezinme. Menü, arama ve galeri klavyeyle kullanılabilmeli; odak göstergesi görünmeli.
• Bağlantı metni. "Buraya tıklayın" değil, nereye gittiğini söyleyen metin.
• Video altyazısı. Özellikle haber videolarında.
• Form etiketleri. Yorum ve abonelik formlarında her alanın etiketi olmalı.

Bağlantı metni maddesi hem erişilebilirlik hem SEO açısından aynı sonucu verir: bağlantının nereye gittiğini anlatan metin, hem ekran okuyucu kullanıcısına hem arama motoruna bilgi taşır. Haber sitelerinde en sık görülen hata, "devamı için tıklayın" gibi bağlamsız bağlantı metinleridir.

Yapay Zekâ: Nerede Yardım Eder, Nerede Risk Üretir?

Yapay zekâ araçları haber üretiminin bazı adımlarında gerçek fayda sağlar; bazılarında ise doğrudan risk üretir. Ayrımı net tutmak, hem editoryal hem hukuki açıdan gereklidir.

Faydalı olduğu yerler

• Uzun belgelerin özetlenmesi (meclis tutanağı, bilirkişi raporu, ihale şartnamesi)
• Başlık ve spot önerileri — son kararı editör verir
• Etiket ve kategori önerisi
• Yazım ve dil denetimi
• Arşiv içinde anlam bazlı arama
• Görsel alt metni taslağı
• Transkripsiyon: ses kaydının metne çevrilmesi

Riskli olduğu yerler

• Haberin tamamının üretilmesi — doğrulanmamış bilgi üretme riski yüksektir
• Kaynak ve alıntı uydurma — modeller var olmayan kaynak üretebilir
• Sayı ve tarih üretimi — doğrulanmadan yayımlanmamalı
• Görsel üretimi — haber görseli olarak kullanıldığında yanıltıcı olabilir

Google'ın konuya yaklaşımı nettir: içeriğin nasıl üretildiği değil, kime hizmet ettiği önemlidir. Arama sıralamasında öncelik, insanlara yardımcı olmak için üretilen özgün ve faydalı içeriğindir; sıralamayı manipüle etmek amacıyla ölçekli biçimde üretilen içerik, üretim yöntemi ne olursa olsun politikalara aykırıdır. Yani "yapay zekâ kullandık" tek başına sorun değildir; "denetimsiz ve seri üretim yaptık" sorundur.

Sorumluluk tarafında ise durum daha keskindir: yayımlanan haberden yazılım değil yayın sorumludur. Yapay zekâ ile yazılan bir haberde hatanın sorumlusunun kim olduğunu ayrı bir yazıda, yapay zekâ ile üretilmiş görselin haberde kullanılabilirliğini ise burada ele aldık.

İçerik Kaldırma ve Erişim Engelleme Talepleri

Bir haber sitesi yeterince uzun süre yayın yaparsa kaldırma talebi alır. Bu talepler farklı kaynaklardan gelir — doğrudan kişiden, avukattan, mahkemeden — ve her birinin hukuki ağırlığı farklıdır. Yazılım tarafında beklenen, bu sürecin izlenebilir olmasıdır.

Operasyonel bir akış kurun:

• 1. Kayıt. Talep tarihi, kimden geldiği, hangi içeriğe ilişkin olduğu kaydedilir.
• 2. Sınıflandırma. Mahkeme kararı mı, idari karar mı, kişisel talep mi?
• 3. Değerlendirme. Haberin doğruluğu, güncelliği ve kamu yararı gözden geçirilir.
• 4. Karar. Kaldırma, güncelleme, düzeltme yayımlama ya da reddetme.
• 5. Uygulama. Karar uygulanır; içerik siteden kaldırılsa bile arşivde korunur.
• 6. Bildirim. Talep sahibine sonuç bildirilir ve kayda geçirilir.

Üçüncü adım en çok atlanandır. Gelen her talebi otomatik olarak kabul etmek, arşivinizi zamanla eritir ve gelecekteki taleplerin de kabul edileceği beklentisi yaratır. Talebi reddetmenin sonuçlarını ve süreçlerin nasıl işlediğini kaldırma talebi geldiğinde ne yapmalı ve talebi reddedersem ne olur yazılarında ele aldık. Erişim engelleme kararlarının uygulanma süresini ise burada anlattık.

Yazılım açısından kritik ayrım yine aynı: siteden kaldırmak ile arşivden silmek aynı şey olmamalıdır. Kaldırma talebini yerine getirirken saklama yükümlülüğünü ihlal etmemek, ancak bu ayrımı yapan bir sistemde mümkündür.

Barındırma Seçimi: Yazılım Kadar Belirleyici

En iyi haber yazılımı bile yetersiz bir sunucuda yavaş çalışır. Barındırma kararı, yazılım kararının ayrılmaz parçasıdır ve üç seçenek arasında yapılır.

Haber sitelerine özgü iki ek kriter vardır. Birincisi ani yük dayanımı: paylaşımlı hosting paketlerinde eşzamanlı bağlantı sınırı vardır ve son dakika anında bu sınıra ilk çarpan yine haber siteleridir. İkincisi veri lokasyonu: hangi veri merkezinde barındığınız sözleşmenizde yazmalıdır; Türkiye'de tutulması gereken veriler için Türkiye lokasyonu tercih edilir.

Seçenekleri ve kapasiteleri web hosting ve bulut sunucu sayfalarında karşılaştırabilir, ölçeğinize göre hazırlanmış paketleri yerel haber sitesi çözümünde görebilirsiniz.

Sözleşme ve Hizmet Düzeyi

Teknik değerlendirme tamamlandığında geriye sözleşme kalır ve burada bakılacak maddeler bellidir. Bu maddeler sıkıcı görünür; ancak sorun çıktığında elinizde olan tek şey bunlardır.

• Veri sahipliği. İçerik, görseller ve okur verisi kime ait? Açıkça yazmalı.
• Dışa aktarma. Ayrılmak istediğinizde veri hangi formatta, ne kadar sürede, ücretli mi?
• Çalışma süresi taahhüdü. Yıllık erişilebilirlik oranı ve ihlal hâlinde ne oluyor?
• Destek yanıt süresi. Kritik arıza ve sıradan talep için ayrı süreler.
• Bakım pencereleri. Planlı kesintiler ne zaman, ne kadar önce haber veriliyor?
• Yedekleme taahhüdü. Sıklık, saklama süresi ve geri yükleme süresi.
• Fiyat artışı. Yenilemede artış nasıl belirleniyor, tavanı var mı?
• Fikri mülkiyet. Özel geliştirmeler kime ait?
• Alt yükleniciler. Hangi hizmetler üçüncü taraflardan alınıyor?
• Fesih. Hangi sürede, hangi şartlarla, veriler ne oluyor?

İlk iki madde en kritiğidir. Verinizin size ait olduğu ve onu standart bir formatta alabileceğiniz yazılı değilse, teknik olarak ne kadar iyi bir sistem seçerseniz seçin ticari olarak kilitlenmiş olursunuz.

Yerel Haber Sitelerine Özel Modüller

Yerel yayıncılıkta trafiğin önemli bir kısmı haberden değil servis sayfalarından gelir. Bu sayfalar günlük olarak aranır, düzenli olarak geri gelinir ve rekabeti düşüktür. Ulusal yayınların ilgilenmediği, yerel yayının doğal olarak sahip olduğu alandır.

Bir yerel haber sitesi yazılımından beklenen servis modülleri:

• Nöbetçi eczane. Günlük güncellenen, ilçe bazlı liste. Yerel aramaların en istikrarlı kalemlerinden biridir.
• Vefat ilanları. Yerel yayının en çok okunan bölümlerinden; hem trafik hem toplumsal işlev üretir.
• Hava durumu. Şehir bazlı, ana sayfada görünür.
• Etkinlik takvimi. Konser, tiyatro, festival; belediye ve kültür merkezi verisiyle beslenir.
• Ulaşım ve yol durumu. Otobüs saatleri, kapalı yollar.
• İhale ve resmî ilan arşivi. Yayımladığınız ilanların aranabilir arşivi.
• Yerel spor fikstürü. Şehir takımının maç takvimi ve sonuçları.
• Acil numaralar ve nöbetçi kurumlar.

Bu modüllerin ortak özelliği, düzenli güncellenmeleri gerektiğidir. Elle güncellenen bir nöbetçi eczane sayfası bir hafta içinde unutulur ve yanlış bilgi vermeye başlar — bu, güven açısından hiç sayfa olmamasından kötüdür. Yazılımın bu verileri otomatik kaynaklardan çekebilmesi ya da en azından güncellenmediğinde uyarı vermesi gerekir.

Resmî ilan yayımlayan yayınlar için ilan arşivi ayrıca önemlidir: yayımlanan ilanların aranabilir biçimde tutulması hem okur hizmetidir hem denetimlerde işinizi kolaylaştırır. Tarife arşivini ve yıllara göre değişimi ayrı bir yazıda derledik; basılı yayında yüzölçümü hesabını ise gazete yüzölçümü aracıyla yapabilirsiniz.

Video, Podcast ve Çoklu Format

Haber üretimi artık yalnızca metin değildir. Aynı olay bir metin haberi, bir kısa video, bir podcast bölümü ve bir sosyal medya kartı olarak üretilebilir. Yazılımın bu formatları ayrı ayrı içerik tipleri olarak tanıması, hepsini "haber" kalıbına sıkıştırmasından iyidir.

• Video haber. Kendi oynatıcısı, altyazı desteği, küçük resim seçimi.
• Kısa dikey video. Mobil için ayrı oran; sosyal ağlara aktarım.
• Podcast. Bölüm listesi, RSS akışı, dinleme platformlarına dağıtım.
• Galeri. Sıralı görseller, her birinde altyazı ve telif bilgisi.
• İnfografik. Büyük görselin mobilde okunabilir kalması.

Video tarafında en kritik teknik karar barındırma ve dönüştürmedir. Yüklenen videonun farklı çözünürlüklere dönüştürülmesi ve okurun bağlantı hızına göre uygun olanın sunulması gerekir; tek bir yüksek çözünürlüklü dosyayı doğrudan sunmak, mobil okurun izlemeyi bırakmasına yol açar.

Podcast için ise standart bir RSS akışı üretebilmek yeterlidir; dinleme platformları içeriği bu akıştan alır. Yazılımın bölüm bazlı süre, açıklama ve kapak görseli alanlarını desteklemesi gerekir.

Bölgesel Sürümler ve Çoklu Yayın

Birden fazla ilde yayın yapan kuruluşlar için iki mimari seçenek vardır: her il için ayrı site kurmak ya da tek site içinde bölgesel sürümler oluşturmak.

Çoğu durumda ikinci seçenek doğrudur: tek panel, tek arşiv, ama ana sayfası ve manşeti bölgeye göre değişen bir yapı. Okur konumuna ya da seçimine göre kendi ilinin manşetini görür; ortak haberler her sürümde yayımlanır. Bu yapının yazılım tarafındaki karşılığı, kategori ve manşetin bölge boyutuna sahip olmasıdır.

Mevzuat açısından dikkat edilecek nokta şudur: yayın türünüz — yaygın, bölgesel ya da yerel — yayımlandığınız yer ölçütüne göre belirlenir ve resmî ilan kategoriniz buna bağlıdır. Bölgesel sürüm açmak bu tanımı etkileyebilir; medya kuruluşu nitelik aracı hangi kategoriye düştüğünüzü gösterir.

Hangi Göstergeleri İzlemelisiniz?

Haber merkezlerinde ölçüm çoğu zaman tek bir sayıya indirgenir: günlük ziyaretçi. Bu sayı tek başına yanıltıcıdır; viral tek bir haber günü kurtarır ama yayının sağlığını göstermez. İzlenmesi gereken gösterge kümesi şudur:

Bu göstergeler içinde en çok ihmal edileni doğrudan trafik payıdır. Arama ve sosyal ağ trafiği algoritmalara bağlıdır ve bir gecede değişebilir; doğrudan gelen okur ise markanızın kendisidir. Bir yayının uzun vadeli sağlığı, bu payın büyümesiyle ölçülür.

Ölçümün ikinci boyutu editoryal geri bildirimdir: hangi muhabirin haberleri okunuyor, hangi kategori büyüyor, hangi saatte yayımlanan haber daha çok okunuyor. Bu veri günlük gündem toplantısının girdisi olduğunda değer üretir; ay sonunda raporda görülen veri geç kalmış veridir.

Ürün Yol Haritası: Yazılımın Geleceğini Değerlendirmek

Bir haber yazılımı seçerken bugünkü hâline bakarsınız; ancak onunla üç-beş yıl çalışacaksınız. Bu yüzden ürünün nereye gittiğini de değerlendirmek gerekir. Sorulacak sorular:

• Son bir yılda hangi özellikler eklendi? Sürüm notları yayımlanıyor mu?
• Yol haritası paylaşılıyor mu, yoksa özellikler sürpriz olarak mı geliyor?
• Müşteri talepleri yol haritasına nasıl giriyor?
• Güncellemeler ne sıklıkla çıkıyor ve nasıl uygulanıyor?
• Geriye dönük uyumluluk korunuyor mu? Bir güncelleme temamı bozar mı?
• Kullanılan teknolojiler güncel mi, yoksa desteği bitmiş sürümler mi?

Son madde teknik borcun göstergesidir. Desteği bitmiş bir dil sürümü ya da veritabanı üzerinde çalışan bir yazılım, bugün sorunsuz görünse bile güvenlik açısından zamana karşı yarışıyor demektir. KEYDAL'da planlanan geliştirmeleri yol haritası sayfasında, yayımlanan değişiklikleri ise sürüm notlarında açık biçimde yayımlıyoruz.

Yol haritasını değerlendirirken vaat edilen özelliklerin sayısına değil, geçmişte verilen sözlerin tutulup tutulmadığına bakın. Bir yıl önce duyurulmuş ama hâlâ çıkmamış özellikler, o yol haritasının ne kadar bağlayıcı olduğunu gösterir.

Kurulumdan İlk Yıla: Doksan Günlük Plan

Yazılım seçimi tek başına sonuç üretmez; devreye alma planı üretir. Aşağıdaki üç aylık plan, yeni kurulan ya da yeni platforma geçen bir yayının hangi işi ne zaman yapması gerektiğini sıralıyor.

İlk 30 gün: temel

• Alan adı, barındırma ve yazılım kurulumu tamamlanır.
• Sorumlu müdür belirlenir, beyanname verilir, alındı belgesi saklanır.
• Künyenin altı kalemi yayımlanır ve ana sayfadan erişilebilir hâle getirilir.
• Tarih damgası her haber şablonunda doğrulanır.
• Kategori yapısı kurulur — beş ile sekiz arasında tutulur.
• Roller tanımlanır: muhabir yayımlayamaz, editör yayımlar.
• Yedekleme kurulur ve bir kez geri yükleme testi yapılır.
• Site haritası, Search Console ve arama motoru bildirimleri devreye alınır.

31–60 gün: yayın ritmi

• Günlük yayın temposu oturur; gündem toplantısı rutini kurulur.
• Arşiv saklama düzeni doğrulanır; kaldırma ile silme ayrımı test edilir.
• Bülten kurulur, çift onaylı kayıt açılır.
• Push bildirim devreye alınır; sıklık sınırı baştan belirlenir.
• Servis sayfaları (nöbetçi eczane, vefat, hava durumu) yayına alınır.
• İlk performans ölçümü yapılır; manşet görseli yükleme süresi ölçülür.
• Reklam alanları sabit yükseklikle tanımlanır.

61–90 gün: derinleşme

• İlk konu/dosya sayfası açılır ve mevcut haberler ona bağlanır.
• İç bağlantı düzeni kurulur: her haber en az bir ilgili habere bağlanır.
• Ölçüm göstergeleri panosu oluşturulur; doğrudan trafik payı izlenmeye başlanır.
• Resmî ilan şartları değerlendirilir; kadro durumu ölçülür.
• Yorum politikası yazılır ve sitede yayımlanır.
• İlk üç aylık içerik denetimi: hangi kategori çalıştı, hangisi kapatılmalı.

Bu planın en kritik maddesi ilk aydaki geri yükleme testidir. Yedeğin çalıştığını ilk aydan bilmek, üçüncü ayda öğrenmekten farklıdır; çünkü üçüncü ayda öğrenmek genellikle bir kayıp yaşandığı anlamına gelir.

Terimler Sözlüğü

Bu rehberde geçen ve satın alma görüşmelerinde sık duyacağınız terimler:

Son Söz: Doğru Soruyu Sormak

Haber yazılımı pazarında satıcıların çoğu aynı cümleleri kurar: hızlı, güvenli, SEO uyumlu, mobil uyumlu. Bu cümleler karar vermenize yardım etmez çünkü hepsi doğrulanmamış vaatlerdir. Karar veren şey, sorduğunuz sorunun niteliğidir.

"En iyi haber yazılımı hangisi" sorusunun cevabı yoktur; ama "benim ölçeğimde, benim ekibimle, benim gelir modelimle hangisi doğru" sorusunun cevabı vardır ve bu rehberdeki çerçeve o cevabı üretir. Profesyonel haber sitesi yazılımı arayan bir kurumsal yayınla, ilk sitesini kuran bir yerel yayının doğru cevabı aynı olmak zorunda değildir — ve olmaması normaldir.

Değerlendirmeyi üç somut teste indirgeyin. Birincisi: demo üzerinde sıradan bir günü baştan sona yürütün. İkincisi: künye, tarih damgası ve iki yıllık arşivi gözünüzle görün. Üçüncüsü: otuz altı aylık toplam maliyeti hesaplayın ve çıkış senaryosunu sözleşmede yazılı görün. Bu üç testi geçen bir sistem, sizin için yeterince iyidir.

KEYDAL Haber Yazılımı: Panelde Ne Var?

Buraya kadar anlatılan ölçütlerin somut bir üründe nasıl karşılandığını görmek isterseniz, bu bölüm KEYDAL haber yönetim sistemini örnek üzerinden anlatıyor. Amaç bir özellik listesi dizmek değil; yukarıdaki her başlığın panelde nereye düştüğünü göstermek. Ayrıntılı kullanım belgelerinin tamamı keydal.wiki adresinde açık biçimde yayımlanıyor — satın almadan önce okuyabilirsiniz.

KEYDAL indirilip kurulan bir haber scripti değildir. Uygulama Node.js üzerinde çalışır, yayın ve panel ayrı bileşenler hâlinde Kubernetes üzerinde durur, her sitenin verisi kendi veritabanında yalıtılır. Sipariş sonrası kurulum otomatiktir: veritabanı, servisler ve içerik dağıtım ağı sizin için hazırlanır.

Panel ve gezinme

Haber sitesi paneline tarayıcıdan girilir, kurulum gerekmez. Oturum güvenli bir çerezde tutulur; bu çerez tarayıcının JavaScript'inden okunamaz, dolayısıyla site üzerinden çalınamaz. Oturum varsayılan olarak 12 saat açık kalır.

Menü, işleri gruplara ayırır ve yetkinize göre süzülür — yetkiniz olmayan bölüm hiç görünmez. Bu, yukarıda anlatılan rol ayrımının arayüzdeki karşılığıdır:

İki ayrıntıya dikkat edin. Birincisi Kurumsal → Künye: künye, tema içine gömülü serbest bir metin değil, panelde kendi sayfası olan yapılandırılmış bir kayıttır — yukarıda anlatılan m.4/3 yükümlülüğünün doğrudan karşılığı. İkincisi Kurumsal → Denetim: kimin ne zaman ne yaptığını gösteren denetim günlüğü.

Üst şeritte canlı bir bağlantı göstergesi bulunur. Panel sunucuyla açık bağlantı tuttuğu için başka bir editörün yaptığı değişiklik siz sayfayı yenilemeden görünebilir; bu, gerçek zamanlı mimarinin editör tarafındaki somut faydasıdır.

Birden çok yayın yönetiyorsanız panel tek bir aktif site üzerinde çalışır ve sol şeritten site değiştirirsiniz. Her sitenin yanında o sitedeki rolünüz yazar; aynı kişi bir yayında sahip, başka bir yayında muhabir olabilir. Bölgesel sürümleri ya da grup yayınlarını tek panelden yönetmek bu şekilde mümkün olur.

Giriş güvenliği

• İki adımlı doğrulama (2FA). E-posta ile ya da kimlik doğrulayıcı uygulamayla altı haneli kod.
• Kurtarma kodu. Cihazınıza erişemediğinizde daha önce kaydettiğiniz kodla giriş.
• Geçici kilit. Çok sayıda hatalı denemede hesap kısa süreli kilitlenir; kaba kuvvet denemeleri böyle durur.
• Rol rozeti. Üst şeritte hangi kimlikle ve hangi rolle çalıştığınız her zaman görünür.

İçerik üretimi

Haber girişi Sade ve Detaylı olmak üzere iki modda çalışır. Sade mod muhabirin hızlı giriş yapmasını sağlar; detaylı mod editör ve SEO sorumlusunun ihtiyaç duyduğu alanları açar. Etiketleme, öneri listesi sunan çip tabanlı bir etiket oluşturucuyla yapılır.

İçerik grubundaki Planlama sayfası yayın takvimini, Manşet sayfası vitrin düzenini, Yazarlar sayfası imza yönetimini taşır. RSS ve Anketler aynı grupta yer alır.

Haber sitesi SEO araçları

SEO tarafı iki katmanda çalışır: haber editörünün içinde ve site genelinde. Editör içinde, odak anahtar kelime girdiğinizde 0–100 arası canlı bir SEO puanı belirir ve dört grupta denetim yapar — odak kelime yerleşimi, başlık ve meta uzunlukları, içerik yapısı, okunabilirlik. Sistemin ideal kabul ettiği eşikler belgelenmiştir:

Arama önizlemesi haberinizin sonuç sayfasında nasıl görüneceğini Google, Bing, Yandex ve DuckDuckGo için ayrı ayrı gösterir; her motorun kendi kırpma uzunluğu uygulanır. Başlık sayacı 60 karakterde sararır, 70'te kırmızıya döner.

Her haber için meta başlık, meta açıklama, canonical adres, robots direktifi, paylaşım görseli ve hedef kelimeler ayrı ayrı belirlenebilir; boş bırakılanlar için sistem varsayılanı kullanır. Google'da gizle (noindex) anahtarı tek tıkla çalışır. Yapılandırılmış veride sistem NewsArticle işaretlemesini otomatik üretir; özel bir işaretleme gerekiyorsa kendi JSON-LD'nizi yazabilirsiniz.

Site genelinde ise robots.txt ve site haritaları otomatik üretilir. Google Haber tarafı için ayrı bir adres vardır:

Yukarıda "adresler değişirse kalıcı yönlendirme kurulmalı" dedik; panelde bunun karşılığı Yönlendirmeler ekranıdır ve dört tür destekler: kalıcı taşıma için 301, geçici taşıma için 302 ve 307, kalıcı olarak kaldırılan sayfalar için 410. Web katmanı bir adres için sayfa bulamadığında 404 döndürmeden önce yönlendirme tablosuna bakar.

Bunun tamamlayıcısı 404 İzleyicidir: okurun istediği ama var olmayan adresler kaç kez istendiğiyle birlikte kaydedilir. Sık isabet alan bir adrese yönlendirme tanımladığınızda ilgili kayıt otomatik olarak "çözüldü" işaretlenir. Bu ikili, denetimlerde en sık karşılaşılan "site haritasında var ama 404 veriyor" sorununu görünür kılar.

Medya ve dağıtım

Medya kütüphanesinde görseller klasörlere ayrılır; her görsele alt metin ve telif bilgisi alanı eklenir. Yukarıda "görselin nereden geldiği kayıtlı değilse telif talebinde savunma üretilemez" demiştik; telif alanı tam olarak bu boşluğu kapatır.

Her siteye otomatik olarak bir içerik dağıtım ağı kurulur: medya adresleri site.keydal.io üzerinden sunulur ve Bunny CDN dağıtımıyla okura coğrafi olarak yakın kenar sunuculardan gelir. Görsel optimizasyon modülü açıkken yüklenen görseller WebP'ye çevrilir ve otomatik boyut türevleri üretilir.

Tema

Görünüm bir tema kataloğundan seçilir; varsayılan bir tema her zaman tanımlıdır ve premium temalar katalogda ayrıca yer alır. Tema değişikliğinin künye ve tarih damgası gibi mevzuat kalemlerini etkilememesi, bu kalemlerin tema katmanında değil sistemde tutulmasıyla sağlanır.

Modüller ve plan kademeleri

Özellikler Kurumsal → Modüller ekranından tek tek açılıp kapatılır. Modüller sekiz kategoriye ayrılır: İçerik & Medya, Okur & Etkileşim, Analitik & Gelir, SEO & Entegrasyon, Sosyal Medya, Dağıtım & Yayın, Pazarlama ve Yapay Zekâ. Hangi modülü açabileceğiniz plan kademenize bağlıdır ve kademeler kapsayıcıdır:

Birkaç modül, bu rehberde ayrı ayrı ele aldığımız başlıklara doğrudan karşılık gelir. SEO index-push, yayımlanan haberi Google ve Bing'e anında bildirir — indeksleme gecikmesi bölümünde anlattığımız iş. Revizyon geçmişi, her düzenlemede sürüm tutar ve eski hâle dönmeyi sağlar. Abonelik modülü ücretli üyelik ve paywall açar. Omni, tek haberden push, X, Instagram ve WhatsApp dağıtımı yapar. Ajans (AA) modülü ajans akışını kategori eşlemesiyle içeri alır ve otomatik ya da onaylı yayına düşürür — haber ajansı beslemesi kullanan yayınların aradığı şey budur. Podcast ve Flipbook/dergi modülleri çoklu format tarafını karşılar.

Bir modülü kapatmak, o özelliğin ürettiği veriyi silmez; yalnızca özelliği devre dışı bırakır. Revizyon geçmişini kapatmak eski sürümleri yok etmez, yeni sürüm tutmayı durdurur. Her modül değişikliği denetim günlüğüne kim ve ne zaman bilgisiyle yazılır.

Veri yalıtımı ve altyapı

Çok kiracılı sistemlerde en kritik soru veri yalıtımıdır: sizin haberleriniz başka bir müşterinin verisiyle aynı tabloda mı duruyor? KEYDAL'da her site kendi veritabanında yalıtılır; panel yazar, yayın okur ve ikisi tek doğruluk kaynağı üzerinde çalışır. Bağlantılar bir havuzlayıcı köprü üzerinden yönetilir.

Altyapı katmanlarının tamamı — sunucu sağlayıcıları, konteyner dağıtımı, veri katmanı, dağıtım ağı ve arama motoru bildirim araçları — teknoloji sayfasında tek tek açıklanır. Aynı şeffaflığı belgelerde de sürdürüyoruz: kullanım dokümantasyonu satın almadan önce herkese açıktır.

Sipariş ve kurulum

Sipariş sonrası kurulum otomatiktir: sitenizin veritabanı, servisleri ve dağıtım ağı hazırlanır, faturalandırma ve abonelik yenilemesi sipariş sistemiyle eşitlenir. Plan yükseltmesi yaptığınızda üst kademedeki modüller kendiliğinden açılabilir hâle gelir.

Ölçeğe göre hazırlanmış paketleri yerel haber sitesi, ulusal haber portalı ve haber ajansı çözüm sayfalarında; gazete, radyo ve web TV'yi birlikte yürüten kuruluşlar için hazırlanan bütünleşik paketi ise yerel medya kuruluşu sayfasında görebilirsiniz. Mevcut sitenizi arşiviyle taşımak isterseniz süreç site taşıma sayfasında adım adım anlatılıyor.

Aynı Şeyin Farklı Adları: Terminoloji Karmaşası

Bu pazarda aynı ürün en az on farklı adla anılıyor ve bu, teklif karşılaştırmayı gereksiz yere zorlaştırıyor. Bir satıcının "haber CMS" dediğiyle bir diğerinin "haber sitesi programı" dediği çoğu zaman aynı şey; bazen ise tamamen farklı bir teslim modeli. Aşağıdaki tablo, arama yaparken karşınıza çıkacak adlandırmaların pratikte ne anlama geldiğini gösteriyor.

Pratik sonuç şudur: teklif alırken satıcının kullandığı ada değil, üç soruya bakın — sunucu kimde, güncellemeyi kim kuruyor, veriler kime ait? Bu üç sorunun cevabı teslim modelini kesin olarak belirler; adlandırma belirlemez.

Haber sitesi kurulumu ve altyapısı ayrı kalemlerdir

Sık karıştırılan bir başka nokta da kurulum ile altyapının aynı şey sanılmasıdır. Haber sitesi kurulumu bir kerelik bir iştir: yazılımın ayağa kaldırılması, kategorilerin açılması, temanın seçilmesi, künyenin doldurulması. Haber sitesi altyapısı ise süreklidir: sunucu, dağıtım ağı, yedek, güncelleme ve izleme.

Teklifleri karşılaştırırken bu ikisinin ayrı ayrı fiyatlandırılıp fiyatlandırılmadığını sorun. Bazı sağlayıcılar kurulumu ücretsiz gösterip altyapıyı pahalı fiyatlar; bazıları tersini yapar. Toplamı görmeden karşılaştırma yapmak mümkün değildir.

Haber sitesi hosting: yazılımdan ayrı mı alınmalı?

Script satın alıyorsanız haber sitesi hosting ayrı bir karardır ve yukarıda anlattığımız ani yük dayanımı ölçütüne göre seçilmelidir. Platform satın alıyorsanız barındırma genellikle pakete dahildir; bu durumda sorulacak soru "hangi kapasiteye kadar dahil" ve "aşarsam ne oluyor" sorularıdır. İkisinin cevabı yazılı değilse, ilk büyük gündemde sürpriz yaşarsınız.

Haber sitesi teması: ne kadar değiştirilebilir?

Tema kararında üç ihtimal var: katalogdan hazır tema seçmek, hazır temayı özelleştirmek ya da tamamen özel tasarım yaptırmak. Yeni başlayan bir yayın için doğru cevap neredeyse her zaman birincisidir; özgün tasarım, marka oturduktan ve hangi düzenin işe yaradığı ölçüldükten sonra anlamlı olur.

Sorulacak kritik soru şudur: yaptığım tema değişiklikleri sistem güncellemelerinde korunuyor mu? Korunmuyorsa her güncelleme sonrası tasarım işini yeniden yapmanız gerekir ve bu, görünmeyen bir maliyet kalemidir.

Mobil haber uygulaması gerekli mi?

Trafiğinizin büyük kısmı zaten mobil tarayıcıdan geliyorsa, mobil haber uygulaması bir zorunluluk değildir. Uygulama yalnızca geri dönen sadık okur kitlesi oluştuktan sonra anlamlıdır; öncesinde indirilir, bir kez açılır ve silinir. Uygulama kararı verdiğinizde de asıl mesele tasarım değil, içeriğin uygulamaya nasıl akacağıdır — bunun cevabı yukarıda anlattığımız API katmanıdır.

Demo isteyin, sunum değil

Satın alma sürecinde en çok işe yarayan tek adım, haber sitesi demo ortamında kendi elinizle bir gün yürütmektir. Slayt sunumu yerine size bir deneme paneli açılmasını isteyin ve şunları kendiniz yapın: bir haber girin, editör onayıyla yayımlayın, manşete alın, bir görsel yükleyip alt metin ve telif bilgisi ekleyin, künyeyi doldurun, bir adres için yönlendirme tanımlayın ve haberi güncelleyip tarih damgasının değiştiğini görün.

Bu yedi adım, bu rehberdeki ölçütlerin neredeyse tamamını on beş dakikada test eder. Bir sağlayıcı deneme paneli açmıyorsa, sebebini sormaya değer.

Satın Alma Öncesi Kontrol Listesi

Aşağıdaki listeyi demo görüşmesine yanınızda götürün. Her maddeyi "var/yok" değil, "gösterildi/gösterilmedi" diye işaretleyin.

Editoryal

• Muhabir–editör–yayın akışı çalışıyor, muhabirin yayımlama yetkisi yok
• Manşet sürükle-bırak ile diziliyor, geri alınabiliyor
• Zamanlanmış yayın ve zamanlanmış manşet var
• Sürüm geçmişi tutuluyor, kim ne değiştirdi görünüyor
• Kaldırma ile silme birbirinden ayrı
• Konu/dosya sayfası açılabiliyor

Teknik

• Otuz bin haberlik kurulumda kategori ve arama sayfası ölçümü paylaşıldı
• Önbellek katmanları ve geçersiz kılma stratejisi açıklandı
• Görseller otomatik boyutlandırılıyor ve modern formata çevriliyor
• Türkçe karakter duyarsız, kök bulan site içi arama var
• Raporlar site performansını etkilemiyor
• Test ortamı sağlanıyor

Mevzuat

• Künyenin altı kalemi yapılandırılmış alan olarak tutuluyor
• İlk yayım ve güncelleme tarihleri ayrı tutuluyor ve sabit olarak basılıyor
• Yayımlanan içerik bütünlüğü korunarak arşivleniyor
• Siteden kaldırılan haber arşivde kalıyor
• Cevap ve düzeltme talepleri kayıt altına alınabiliyor
• Çerez ve aydınlatma metni araçları var

Arama motoru

• Site haritası ve haber site haritası otomatik üretiliyor
• Yayımlama anında IndexNow bildirimi gidiyor
• NewsArticle ve BreadcrumbList işaretlemesi basılıyor
• Paylaşım kartı görseli otomatik üretiliyor, yoksa küçük kart bildiriliyor
• Adresler kalıcı, değişirse kalıcı yönlendirme kuruluyor

Ticari

• On fiyat kalemi ayrı ayrı yazılı olarak verildi
• Otuz altı aylık toplam maliyet hesaplandı
• Veri sahipliği sözleşmede açıkça yazıyor
• Dışa aktarma formatı ve süresi belirtildi
• Destek yanıt süresi taahhüt edildi
• Canlı referans site adresleri verildi

Sık Sorulan Sorular

Haber yazılımı ile haber scripti aynı şey mi?

Hayır. Script, indirip kendi sunucunuza kurduğunuz bir dosya paketidir; sunucu, güncelleme ve güvenlik sizin sorumluluğunuzdadır. Haber yazılımı platform olarak satıldığında çalışır hâlde bir sistem alırsınız ve işletme sağlayıcıda kalır. İkisinin maliyet ve sorumluluk dağılımını ayrı bir karşılaştırmada ele aldık.

WordPress ile haber sitesi kurulur mu?

Kurulur, ancak varsayılan kurulum haberciliğe özgü kalemleri karşılamaz. Manşet yönetimi, rol ayrımı, tarih damgası, arşiv bütünlüğü ve künye ayrı ayrı kurulmalıdır. Bunları eklentilerle çözmek mümkündür; bedeli, her güncellemede bu çözümlerin bozulup bozulmadığını denetleme yüküdür.

Haber sitesi kurmak için izin gerekir mi?

İzin ya da lisans gerekmez. Ancak internet haber siteleri süreli yayın sayıldığı için, yönetim yerinin bulunduğu yer Cumhuriyet Başsavcılığına beyanname verilir. Süreci adım adım kurulum rehberinde anlattık.

Haber yazılımı SEO'yu tek başına çözer mi?

Hayır. Yazılım teknik temelleri kurar: temiz adresler, site haritası, yapılandırılmış veri, hızlı indeksleme bildirimi ve performans. Ancak sıralamayı belirleyen asıl unsur içeriğin kendisidir. İyi bir yazılım, iyi haberciliğin önündeki teknik engelleri kaldırır; yerine geçmez.

AMP kullanmazsam Google'da geriye düşer miyim?

Hayır. AMP bir sıralama şartı değildir ve Top Stories için zorunluluğu kaldırılmıştır. Önemli olan sayfanın mobilde hızlı açılmasıdır; bunu AMP ile de sağlayabilirsiniz, hafif bir temayla da.

Arşivimi iki yıl saklamak zorunda mıyım?

5187 sayılı Kanun'un 10. maddesi, internet haber sitesinde yayınlanan içeriklerin doğruluğu ve bütünlüğü sağlanmış şekilde iki yıl süreyle muhafaza edilmesini arıyor. Ayrıca bir yayının soruşturma veya kovuşturma konusu olduğu yazılı olarak bildirilirse, o kaydın işlemler sonuçlanana kadar saklanması zorunlu.

Kaç kişilik bir ekip gerekir?

Teknik olarak tek kişiyle yayın yapılabilir. Ancak resmî ilan yayımlamak istiyorsanız asgari kadro şartı devreye girer ve bu bir yazılım meselesi değil personel meselesidir. Durumunuzu asgari kadro nitelik testiyle ölçebilirsiniz.

Mevcut sitemi taşırken trafiğimi kaybeder miyim?

Adres eşlemesi doğru yapılır ve kalıcı yönlendirme kurulursa kayıp sınırlı ve geçici olur. Kayıp kalıcı hâle geliyorsa neredeyse her zaman sebebi aynıdır: eski adreslerin bir kısmı eşlenmemiş ya da geçici yönlendirme kullanılmıştır.

Kendi tasarımımı kullanabilir miyim?

Platform çözümlerinde bu, sağlayıcının tema mimarisine bağlıdır. Satın almadan önce sorulacak soru şudur: hazır temayı ne kadar değiştirebiliyorum, tamamen özel bir tasarım uygulanabiliyor mu ve bu değişiklikler güncellemelerde korunuyor mu?

Yazılım BİK uyumu sağlar mı?

Kısmen. Teknik şartların bir bölümünü — arşiv, künye, erişilebilirlik, trafik ölçümü — yazılım karşılar. Personel ve süreklilik şartlarını karşılamaz. "%100 uyumlu yazılım" ifadesi bu ayrımı gizlediği için yanıltıcıdır.

Google News'e nasıl girilir?

Ayrı bir başvuru yapmak bugün zorunlu değil; Google haber içeriğini kendi tarayıcısıyla keşfediyor. Yapmanız gereken, haberin teknik olarak taranabilir ve hızlı indekslenebilir olması: temiz adres yapısı, haber site haritası, yapılandırılmış veri ve yayımlama anında bildirim. Yayıncı Merkezi üzerinden yayın kimliğinizi, logonuzu ve bölüm düzeninizi tanımlamak ise görünümünüzü iyileştirir.

Yazılımı kendim geliştirmeli miyim?

Sıfırdan haber yazılımı geliştirmek, sürekli bir bakım taahhüdüdür: güvenlik yamaları, arama motoru değişiklikleri ve mevzuat güncellemeleri yayın hayatınız boyunca sizin sorumluluğunuzda kalır. Bunu üstlenebilecek kalıcı bir geliştirici ekibiniz yoksa, hazır bir sistemi ihtiyacınıza göre özelleştirmek neredeyse her zaman daha ucuz ve daha dayanıklı olur.

Özet

Haber yazılımı seçimi, bir yazılım kararından çok bir işletme kararıdır. Karar verirken üç eksene bakın: editoryal akış günlük işi ne kadar hızlandırıyor, teknik mimari zirve trafiği ve büyüyen arşivi ne kadar taşıyor, mevzuat kalemleri sistemin içinde mi yoksa sonradan mı eklenecek.

Bu üç ekseni ölçmenin yolu özellik listesi okumak değil, demo üzerinde gerçek bir günü yürütmek ve üç mevzuat kalemini — künye, tarih damgası, iki yıllık arşiv — gözünüzle görmektir. Fiyatı otuz altı aylık toplam üzerinden karşılaştırın, çıkış senaryosunu baştan konuşun ve satın almadan önce canlı referans isteyin.

Son olarak: hiçbir yazılım kötü habercilikten iyi bir yayın çıkaramaz. Yazılımın işi, haber merkezinizin zamanını sistemle uğraşmaktan alıp habere çevirmektir. Bu ölçütü karşılayan her seçenek sizin için doğru seçenektir.