Bir haber sitesinde trafik ile gelir aynı şey değildir, ama birbirine bağlıdır — ve bu bağ ters yönde de çalışır. Daha fazla reklam alanı kısa vadede RPM'i yükseltir; sayfa yavaşlar; Core Web Vitals bozulur; Discover ve Top Stories görünürlüğü düşer; trafik düşer; toplam gelir düşer. Magazin Burada'da hem SEO danışmanı hem monetize manager olarak bu döngünün iki ucunu da yönetmek zorundaydım.
RPM'in yalan söylediği üç durum
- Trafik kaynağı değişince: Discover trafiği düşüp arama trafiği artarsa RPM yükselmiş görünebilir — çünkü kalan trafik daha "değerli" sayfalarda geziyordur. Gelir toplamda düşerken RPM'in artması, panoda yeşil görünen bir kırmızı alarmdır.
- Görünürlük (viewability) şişince: Sayfanın altına itilen içerik kullanıcıyı kaçırırken, kalan sabırlı azınlık daha çok reklam gördüğü için sayfa başı gelir artar. Metrik iyileşir, iş kötüleşir.
- Sezon etkisinde: Q4'te reklamveren talebi her şeyi yukarı çeker. Ekimde yapılan kötü bir yerleşim değişikliği, artan CPM'lerin gölgesinde aylarca fark edilmez; fatura ocakta gelir.
Haber SEO'su farklıdır
Klasik SEO'nun "anahtar kelime, backlink" mantığı haberde tek başına çalışmaz. Hız, yapısal veri (NewsArticle), yayın ritmi, iç bağlantı ve Discover'a uygun görsel/başlık yapısı belirleyicidir. Discover trafiği bir anahtar kelime sıralaması değil, sinyaldir; site yavaşsa o sinyal kesilir.
Discover'ın kırılganlığı
Discover, haber sitelerinin en büyük ve en az güvenilir trafik kaynağıdır: bir hafta trafiğin yarısını taşır, ertesi hafta sessizce çekilir. Bu kırılganlıkla yaşamanın yolu onu yok saymak değil, ona yaslanmamaktır. Pratikte üç şey yaptık: yayın ritmini Discover'dan bağımsız sabit tuttuk (algoritma dalgalansa da üretim dalgalanmaz), arama ve doğrudan trafiği büyüten kalıcı içerik tiplerine yatırım yaptık ve büyük düşüşlerde panik değişiklik yasağı koyduk — çünkü Discover düşüşlerinin çoğu sizin yaptığınız bir şeyden değil, algoritmanın kendi salınımından gelir ve paniкle yapılan şablon değişikliği asıl hasarı yaratır.
Haber sitesine özgü Core Web Vitals sorunları
- CLS — zıplayan içerik: Baş suçlu, yeri önceden ayrılmamış reklam alanlarıdır. Her reklam slotuna sabit yükseklik rezervasyonu koymak, CLS'i düzeltmenin en ucuz yoludur; reklam gelmezse alan boş kalır, kimse ölmez.
- LCP — geç gelen kapak görseli: Haberde en büyük görsel öğe neredeyse her zaman kapak fotoğrafıdır. Öncelikli yükleme (fetchpriority), doğru boyut ve modern format çoğu sorunu çözer.
- INP — betik kalabalığı: Yıllar içinde şablona eklenmiş üçüncü taraf betikler (eski analytics kodları, sosyal eklentiler, terk edilmiş araçlar) etkileşimi kilitler. Altı ayda bir "betik envanteri" çıkarıp kullanılmayanı silmek, bakım değil gelir çalışmasıdır.
Reklam yükleme sırası
En büyük kazanım reklam sayısını azaltmaktan değil, yükleme sırasını değiştirmekten geldi: ekranda görünen içerik önce, reklamlar sonra ve tembel (lazy) yükleme ile. Şablondaki gereksiz betikler temizlendi. Aynı reklam sayısıyla daha iyi Core Web Vitals mümkün.
Yerleşim testi nasıl yapılır
Yerleşim kararları toplantıda değil, testte verilir. İşleyen düzen şu: tek seferde tek değişken (bir slotun yeri ya da bir slotun varlığı), şablon bazlı uygulama (testi tüm sitede değil, tek içerik şablonunda aç), en az iki hafta veri (haftaiçi/haftasonu döngüsü tamamlansın) ve üç metrikte birlikte okuma — RPM, sayfa hızı, sayfa/oturum. Üçünden ikisi iyileşmeden hiçbir yerleşim kalıcı olmaz. "RPM arttı ama kullanıcı daha az sayfa geziyor" sonucu, kazanç değil erozyondur.
Tek pano
Trafik (Search Console, GA4), hız (CrUX) ve gelir (AdSense/programatik RPM) aynı panoda izlenmeye başlandı. Bir yerleşim testi yapıldığında sadece RPM'e değil, üç metriğe birlikte bakıldı. "RPM arttı" cümlesi tek başına karar gerekçesi olmaktan çıktı.
Bir testin anatomisi: örnek senaryo
Somutlaştırayım. Diyelim makale şablonunda, içeriğin ilk paragrafından hemen sonraki reklam slotunun kaldırılması test edilecek. Birinci hafta: değişiklik yalnızca makale şablonunda yayında; anasayfa ve galeri şablonlarına dokunulmadı. Panoda üç satır izleniyor: makale RPM'i, makale LCP/CLS değerleri, makaleden ikinci sayfaya geçiş oranı. İkinci hafta sonunda tablo netleşiyor: RPM bir miktar düştü, sayfa hızı belirgin iyileşti, sayfa/oturum yükseldi. Üçüncü adım hesap: artan sayfa görüntüleme, slot başına kaybedilen geliri karşılıyor mu? Karşılıyorsa değişiklik kalıcı olur ve bir sonraki şablona taşınır; karşılamıyorsa slot geri gelir ama bu kez tembel yüklemeyle. Bu döngünün tamamı — tek değişken, şablon kapsamı, iki hafta, üç metrik, hesap — her yerleşim kararının şablonudur. Toplantıda "bence oradan reklam kaldırmayalım" cümlesinin yerini bu tablo alır.
Hız-gelir denetim listesi
- Her reklam slotunun sabit yükseklik rezervasyonu var mı? (CLS)
- Kapak görseli öncelikli ve doğru boyutta mı? (LCP)
- Şablondaki üçüncü taraf betik envanteri son altı ayda çıkarıldı mı? (INP)
- Ekran altı reklamlar tembel mi yükleniyor?
- Trafik, hız ve gelir aynı panoda mı okunuyor?
- Yerleşim testleri tek değişkenli ve en az iki haftalık mı?
- Discover payı toplam trafikte izleniyor ve bağımlılık planı var mı?
Ders
Monetizasyon bir SEO kararıdır ve SEO bir monetizasyon kararıdır. İkisini ayrı ekipler, ayrı panolar ve ayrı hedeflerle yönetirseniz, birbirlerini yerler. Aynı masaya oturtun. Ve o masada tek bir soru sorun: bu değişiklik, bir ay sonraki toplam geliri artırıyor mu — bugünkü RPM'i değil.
Kısa sorular, kısa cevaplar
Önce hız mı, önce gelir mi? Yanlış ikilem: önce ölçüm. Üç metrik tek panoda okunana kadar verilen her karar tahmindir.
AMP ya da benzeri çözümler şart mı? Hayır; iyi optimize edilmiş normal bir mobil şablon yeterli. Belirleyici olan format değil, reklam yükleme sırası ve betik disiplinidir.
Video reklamlar değer mi? RPM'i en hızlı yükselten ve sayfayı en hızlı çökerten format aynı anda. Video için tek kuralım: kendi başlatılmayan (autoplay dışı), yeri rezerve edilmiş, tembel yüklenen oynatıcı — yoksa hiç olmasın.