Teknik SEO

SEO Uyumlu Haber CMS Seçimi 2026: Technical SEO, Core Web Vitals, JSON-LD ve Modern Standartlar

30 yıllık Türk pazar SEO/AEO/GEO architect tecrübesiyle hazırlanmış SEO uyumlu haber CMS seçim rehberi. Core Web Vitals, JSON-LD native destek, SSR/ISR/edge rendering, NewsArticle subtype'ları, hreflang, IndexNow ve schema.org standartları.

Kağan Onaran4 Mayıs 202619 dakika okuma
haberyazilimpaketi.comHaberlendin CMS · AI-Native Yerel Haber Yazılımı

Sorudan-doğrudan-cevap (Hızlı Yanıt)#

SEO uyumlu haber CMS seçimi 2026 itibarıyla artık temada güzel görünmek değil; technical SEO, Core Web Vitals, JSON-LD native üretim ve AEO/GEO standartları üzerine kurulu mimari bir karardır. Haber yayıncılığında sıralama sinyalleri son üç yılda kökten değişti: Google'ın 2024 Mart core update'i ve Google News yeniden yapılandırması, structured data coverage'ı doğrudan rich result eligibility kriteri yaptı; LCP, CLS ve INP eşikleri field data üzerinden ölçülmeye başladı; ChatGPT, Perplexity ve Gemini gibi cevap motorları schema.org NewsArticle subtype'larını ve Speakable spec'ini parse ederek kaynak gösterdi. 30 yıl Türk pazar technical SEO pratiğimde, doğru CMS seçimi yapmayan haber portallarının 6-9 ay içinde organik trafiklerinin %40-60'ını kaybettiğini, doğru seçimi yapanların ise Top Stories carousel ve People Also Ask gösterimleri ile organik trafiklerini 2-3 katına çıkardığını sahada birinci ağızdan gözlemledim. Bu rehber, 15 kriter × 4 platform karşılaştırması, Core Web Vitals threshold tablosu, NewsArticle subtype haritası ve production-ready bir mimari checklist'i içerir.

Bilgilendirme: Bu rehber, 30 yıllık Türk dijital medya teknik SEO tecrübesi ile JSON-LD native CMS mimarisi uzmanlığı birleştirilerek hazırlandı. Her portalın trafik hacmi, içerik tipi (son dakika ağırlıklı vs evergreen ağırlıklı) ve hedef kitle dili farklı sonuç doğurabilir; kendi senaryonuz için technical SEO uzmanımız ile demo görüşmesi talep etmenizi öneririz. Belirtilen metrik ve eşikler 2026 piyasa koşullarına göre yazılmıştır; resmi teklif için Fiyatlandırma sayfasını inceleyiniz.


1. SEO Uyumlu Haber CMS Nedir? — Tanım ve Checklist#

SEO uyumlu haber CMS, sayfa içeriğini ve metadata'sını arama motorlarının, cevap motorlarının ve sosyal platformların doğrudan parse edebildiği structured form'da, performans bütçesi içinde ve technical SEO best practice'lerine uyumlu şekilde üreten yayın platformudur. Bu tanım, klasik bir "iyi tema + Yoast plugin" anlayışından kökten farklıdır; çünkü 2026 itibarıyla SEO sinyallerinin %60'tan fazlası sayfa düzeyi yerine structured data ve performans düzeyinde değerlendirilir.

1.1 Pratikteki En Yaygın Yanılgılar#

30 yıllık tecrübemde sektörde gördüğüm en yaygın yanılgılar şunlardır:

  1. "Tema mobil uyumlu olduğu sürece SEO sorunu olmaz." Yanlış. Mobil uyumluluk minimum kriterdir; field LCP, field INP ve CLS eşikleri tutturulmadan sıralama düşer. Lighthouse skoru 90+ olsa bile field data 'Poor' kategorisindeyse Google sıralamada cezalandırır.
  2. "Schema markup eklenebilen bir plugin yeterli." Yanlış. Eksik subtype, hatalı @id referansları ve eksik inLanguage/isPartOf property'leri rich result eligibility'yi siler. Google Search Console "Sayfa indekslendi ama enhancement uygun değil" uyarısı tam olarak budur.
  3. "AI cevap motorları haber sitemizi nasıl olsa bulur." Yanlış. ChatGPT, Perplexity ve Gemini'nin kaynak gösterme algoritması NewsArticle JSON-LD, Speakable spec ve /llms.txt varlığına bağlıdır. Bu üç dosya yoksa, sitenizin trafiği yüksek bile olsa kaynak gösterme sıfıra yakın kalır.
  4. "Server-side rendering eski moda; client-side daha modern." Yanlış. Modern haber CMS mimarisi server-first yaklaşıma döndü; Next.js App Router (RSC), Astro, Remix, SvelteKit ve Qwik hep server-first. Client-side rendering haber yayını için anti-pattern haline geldi.

1.2 Minimum Kriter Checklist'i (15 Madde)#

Bir haber CMS'in 2026 itibarıyla "SEO uyumlu" sayılabilmesi için minimum sağlaması gereken kriterler:

  1. SSR veya edge rendering (CSR-only kabul edilmez)
  2. ISR / segmented cache (kategori, anasayfa, evergreen)
  3. JSON-LD native (22+ @type, NewsArticle subtype'ları dahil)
  4. Sitemap-news.xml + standart sitemap.xml otomatik üretim
  5. IndexNow protokol entegrasyonu
  6. WebP/AVIF responsive image pipeline (srcset, sizes, lazy)
  7. Core Web Vitals field eşikleri: LCP < 2.5s, CLS < 0.1, INP < 200ms
  8. Canonical tag her sayfada, parametre handling tutarlı
  9. Hreflang (en az tr-TR self-referencing + x-default)
  10. Internal linking (related haber, breadcrumbs, etiket cluster)
  11. URL kebab-case, ≤4 segment, anahtar kelime barındırır
  12. Robots.txt AI crawler izinleri (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot)
  13. /llms.txt ve gerekirse /llms-full.txt
  14. FAQPage schema (her makalenin 5-10 Q&A'sı için)
  15. Speakable schema (headline + summary için)

Bu 15 maddenin tamamını native sağlayan CMS sayısı 2026 itibarıyla TR pazarında oldukça sınırlıdır; çoğu platform plugin/eklenti ekosistemine bağımlıdır ve bakım maliyeti zamanla artar.


2. Core Web Vitals: LCP, CLS, INP (2026 Standartları)#

Core Web Vitals, 2020'de Google tarafından tanıtılan ve 2024'te FID metriğinin yerini INP'nin alması ile finalize edilen kullanıcı deneyimi metrik setidir. 2026 itibarıyla bu üç metrik field data (CrUX) üzerinden ölçülür ve 75th percentile değeri sıralama sinyali olarak kullanılır. Lab data (Lighthouse) yalnızca development sürecinde anlamlıdır; field data'yı temsil etmez.

2.1 Largest Contentful Paint (LCP)#

LCP, sayfanın görüntü alanındaki en büyük görsel öğenin render edilme süresini ölçer. Haber sitelerinde bu öge genellikle hero görseli veya ana başlıktır. 2026 eşikleri (resmi web.dev/vitals referansı):

  • Good: ≤ 2.5 saniye
  • Needs Improvement: 2.5 – 4.0 saniye
  • Poor: > 4.0 saniye

Haber CMS'inde LCP'yi etkileyen kritik faktörler: TTFB (server response time), hero image format (WebP/AVIF) ve boyut (responsive srcset), font loading stratejisi (font-display: swap), CSS render-blocking ve above-the-fold JavaScript miktarı. Modern bir CMS bu faktörlerin tümünü default olarak optimize etmelidir.

2.2 Cumulative Layout Shift (CLS)#

CLS, sayfa yüklenirken meydana gelen beklenmedik layout kaymalarının toplam puanıdır. Reklam yüklenmesi, web font swap, gec yüklenen image (sabit boyut tanımlanmamışsa) en yaygın CLS kaynaklarıdır. Eşikler:

  • Good: ≤ 0.1
  • Needs Improvement: 0.1 – 0.25
  • Poor: > 0.25

Haber sitelerinde reklam slot'larının min-height ile rezerve edilmesi, image'lerin width + height veya aspect-ratio ile sabit boyutlanması ve font-display stratejisi (swap yerine optional veya fallback adjustment) CLS'i 0.05'in altına indirebilir.

2.3 Interaction to Next Paint (INP)#

INP, kullanıcı etkileşimi (tıklama, tap, klavye) sonrası bir sonraki paint'e kadar geçen sürenin 75th percentile değeridir. 2024 Mart'ta FID'in yerini aldı ve haber siteleri için en kritik Core Web Vital haline geldi (özellikle infinite scroll, comment widget, video player varsa). Eşikler:

  • Good: ≤ 200 milisaniye
  • Needs Improvement: 200 – 500 milisaniye
  • Poor: > 500 milisaniye

INP'yi düşürmenin en etkili yolları: ana thread'i tıkayan üçüncü parti script'leri defer/async ile yüklemek, long task'leri yieldTask veya scheduler.yield() API'si ile bölmek, React/Vue render'larını useTransition veya startTransition ile non-urgent kategoride çalıştırmak. Modern bir CMS, third-party widget yöneticisi ile bu optimizasyonu default olarak uygulamalıdır.

2.4 Core Web Vitals Threshold Tablosu#

Metrik Good Needs Improvement Poor Ölçüm Yöntemi
LCP (Largest Contentful Paint) ≤ 2.5 s 2.5 – 4.0 s > 4.0 s Field (CrUX 75p) + Lab (Lighthouse)
CLS (Cumulative Layout Shift) ≤ 0.1 0.1 – 0.25 > 0.25 Field (CrUX 75p) + Lab
INP (Interaction to Next Paint) ≤ 200 ms 200 – 500 ms > 500 ms Field (CrUX 75p) — lab tahmini
TTFB (Time to First Byte) ≤ 600 ms 600 – 1500 ms > 1500 ms Field + Lab
FCP (First Contentful Paint) ≤ 1.8 s 1.8 – 3.0 s > 3.0 s Field + Lab

Field-data uyarısı: Google sıralamasında field data kullanır. Lighthouse skoru 95 olsa bile gerçek kullanıcı verisi 'Poor' kategorisindeyse sıralama düşer. Search Console > Core Web Vitals raporunu haftalık kontrol edin.


3. Server-Side Rendering (SSR) vs Client-Side Rendering (CSR)#

Haber yayıncılığında rendering stratejisi, SEO sonuçlarını doğrudan belirleyen mimari karardır. 30 yıllık pratiğimde, CSR-only mimariye geçen haber sitelerinin 6 ay içinde organik trafiklerini %50'ye kadar kaybettiğine defalarca tanık oldum.

3.1 SSR'ın SEO Avantajları#

Server-Side Rendering, HTML'in sunucuda render edilip browser'a hazır gönderildiği yaklaşımdır. SEO için kritik avantajları:

  • İlk HTML response'unda tam içerik — Googlebot, Bingbot, GPTBot ilk fetch'te tüm makaleyi görür
  • Meta tag'ler ve JSON-LD ilk response'ta — dynamic injection beklemek zorunda değil
  • TTFB optimize edilebilir — edge cache, ISR, full-route cache kombinasyonları
  • JavaScript bağımsız content — crawler JS render etmek zorunda kalmaz
  • Social media unfurl (Open Graph, Twitter Card) ilk response'ta hazır

3.2 CSR'ın Haber Sitesi İçin Sorunları#

Client-Side Rendering, ilk response'unda boş HTML iskelet gönderip içeriği browser'da JavaScript ile dolduran yaklaşımdır. Haber sitesi için temel sorunları:

  • İlk HTML'de içerik yok → "soft 404" ve thin content sinyali
  • GPTBot, ClaudeBot, PerplexityBot çoğu durumda JS render etmez → kaynak gösterme sıfır
  • Google JS render'ı queue'da bekler → indeksleme 1-2 hafta gecikir
  • TTFB iyi olsa bile LCP kötü → field metrik 'Poor'
  • Open Graph dinamik → Facebook/Twitter unfurl başarısız

3.3 Karar Matrisi#

Senaryo Önerilen Strateji
Son dakika haberi (yüksek tazelik) SSR + edge cache (10-30s revalidate)
Anasayfa SSR + ISR (60s revalidate)
Kategori sayfaları SSR + ISR (60-300s revalidate)
Evergreen rehber/dosya makalesi SSG + ISR (1h revalidate)
Live blog SSR + streaming (RSC) veya edge function
Comment widget Client-side hydration (third-party load defer)
Anket / kişiselleştirilmiş içerik Edge runtime + Server Actions

Modern Next.js App Router veya Astro, bu stratejilerin tamamını tek codebase'de uygular. Tek mimariye sıkışmak gerekmez; route-segment level rendering strategy doğru yaklaşımdır.


4. Edge Rendering ve ISR (Next.js, Astro Patterns)#

Edge rendering, sayfa render'ının kullanıcıya en yakın CDN node'unda gerçekleştirilmesidir. ISR (Incremental Static Regeneration), statik üretimin sıralama avantajını dinamik tazelik ile birleştiren tekniktir. Doğru kombinasyon, haber sitesinde TTFB < 200ms ve LCP < 1.5s hedeflerini gerçekçi kılar.

4.1 Edge Rendering'in Haber İçin Faydası#

  • TTFB ortalama 50-150ms (origin SSR'da 400-800ms)
  • Coğrafi olarak dağıtık (Türkiye için İstanbul + Ankara + Frankfurt + Doğu Avrupa node'lar)
  • Cold start sorunu yok (lambda'larda olduğu gibi 1-2s cold start beklemez)
  • Streaming desteği (RSC ile makale gövdesi parça parça gönderilebilir)
  • Cookie-based personalization edge'de yapılabilir (oturum, kişiselleştirme)

Vercel Edge Functions, Cloudflare Workers, Netlify Edge Functions ve AWS CloudFront Functions bu mimariyi destekler. Modern bir haber CMS bu altyapıların en az birine native deploy edilebilir olmalıdır.

4.2 ISR Pattern'ları (Next.js App Router)#

Next.js App Router'da ISR yaklaşımları:

  1. Time-based revalidation: export const revalidate = 60 (60 saniyede bir cache invalidate)
  2. On-demand revalidation: revalidatePath('/haber/slug') veya revalidateTag('haber-2025') — yayın eyleminde tetiklenir
  3. Tag-based granular cache: Her haberin kendi tag'i, kategori tag'i, anasayfa tag'i — tek haber update'ı tüm anasayfayı invalidate etmez
  4. Stale-while-revalidate: Background'da yeni versiyon hazırlanırken kullanıcıya stale versiyonu gönderir (TTFB sabit kalır)

4.3 Astro Islands Yaklaşımı#

Astro, "islands architecture" ile statik HTML üzerinde sadece interaktif component'lerin JavaScript yüklediği yaklaşımdır. Haber sitesi için faydası:

  • Default zero JS → INP otomatik düşük
  • Per-component hydration (client:load, client:idle, client:visible)
  • Static generation + ISR-benzeri rebuilds (Vercel/Netlify)

Evergreen ağırlıklı haber sitesinde Astro, son dakika ağırlıklı sitede Next.js daha iyi performans sergiler. Hibrit kullanım (Next.js core + statik export segmentleri) en yaygın production pattern'ıdır.


5. JSON-LD Native Destek: 22+ @type Neden Standart Olmalı#

JSON-LD (JavaScript Object Notation for Linked Data), W3C standardı olan ve schema.org tarafından kullanılan structured data formatıdır. Microdata ve RDFa'ya göre render performansı, HTML temizliği ve iç içe nesting kabiliyeti açısından üstündür ve Google'ın resmi olarak önerilen formatıdır. Detaylar için Google Search Central — Introduction to structured data dokümanı referanstır.

5.1 Modern Haber CMS'i İçin Minimum @type Listesi#

Haber yayını için 2026 itibarıyla minimum kapsanması gereken @type'lar:

@type Amaç Schema.org URL
NewsArticle Haber detay sayfası https://schema.org/NewsArticle
OpinionNewsArticle Köşe yazısı https://schema.org/OpinionNewsArticle
AnalysisNewsArticle Derin analiz https://schema.org/AnalysisNewsArticle
ReportageNewsArticle Saha haberi https://schema.org/ReportageNewsArticle
BlogPosting Blog formatı https://schema.org/BlogPosting
LiveBlogPosting Canlı blog (deprem, seçim) https://schema.org/LiveBlogPosting
FAQPage SSS sayfaları + makale sonu Q&A https://schema.org/FAQPage
BreadcrumbList Hiyerarşik gezinti https://schema.org/BreadcrumbList
Person Yazar https://schema.org/Person
Organization Yayıncı https://schema.org/Organization
NewsMediaOrganization Haber yayıncı subtype https://schema.org/NewsMediaOrganization
ImageObject Hero + inline görseller https://schema.org/ImageObject
VideoObject Embed video https://schema.org/VideoObject
WebSite + searchAction Sitelinks searchbox https://schema.org/WebSite
WebPage Generic sayfa https://schema.org/WebPage
ItemList Anasayfa + kategori listing https://schema.org/ItemList
Place Lokasyon entity https://schema.org/Place
Event Etkinlik haberi https://schema.org/Event
HowTo Rehber tarzı içerik https://schema.org/HowTo
QAPage Tek soru-cevap sayfaları https://schema.org/QAPage
Speakable (SpeakableSpecification) Sesli asistan optimize https://schema.org/SpeakableSpecification
Comment Kullanıcı yorumları https://schema.org/Comment

5.2 @id Referans Discipline'ı#

Modern JSON-LD implementasyonun en kritik kuralı @id referans tutarlılığı'dır. Yazar, organizasyon, görsel ve site nesneleri bir kez tanımlanır ve diğer @type'larda { "@id": "https://..." } referansıyla kullanılır. Bu pattern'a @graph kullanımı denir ve schema.org / Google Search Central tarafından best practice olarak önerilir.

Yanlış: Her sayfada yazar ve organizasyon tam objesi tekrarlanır → JSON-LD payload şişer, @id referansları parçalanır. Doğru: Site genelinde tek @id ile yazar + organizasyon, sayfa-spesifik NewsArticle bunlara referans ile bağlanır.


6. Schema.org NewsArticle Subtype'ları (Opinion / Analysis / Reportage / Blog)#

NewsArticle base type'ı, 2018 sonrası eklenen subtype'lar ile zenginleşti. Yanlış subtype seçimi, Google News'te yanlış kategoride gösterilmeye veya opinion content'in factual content gibi değerlendirilmesine yol açar. Schema.org spec'i için https://schema.org/NewsArticle referans dokümandır.

6.1 OpinionNewsArticle — Köşe Yazısı#

Kullanım: Yazar görüş bildiren, factual claims yerine analiz ve yorum içeren içerik. Köşe yazıları, başyazılar, op-ed'ler.

Kritik property'ler: author.@type = "Person", articleSection = "Köşe", inLanguage = "tr-TR". Google News, opinion content'i Top Stories'te factual news'tan ayrı segmente koyar; doğru subtype kullanımı bu ayrımı sağlar.

6.2 AnalysisNewsArticle — Derin Analiz#

Kullanım: Haber arkasındaki nedenleri, etkileri ve uzun vadeli eğilimleri inceleyen, tipik olarak 1500+ kelime, multiple kaynak gösteren içerik. Ekonomi analiz, jeopolitik analiz, sektör analiz makaleleri.

Bu subtype, "Knowledge Panel" ve "In-depth articles" gösterimi için sinyal sağlar. Citation ve external link discipline'ı kritiktir.

6.3 ReportageNewsArticle — Saha Haberi#

Kullanım: Olay yerinden, tanık röportajları, lokasyon-spesifik bilgi içeren saha gazeteciliği. Spec'i için https://schema.org/ReportageNewsArticle referans alınmalıdır.

Kritik property: contentLocation (Place) — saha haberinin coğrafi konumu. Doğru implementasyonla yerel SEO ve Google News yerel kapsama yüksek skor alır.

6.4 BlogPosting — Blog Formatı#

Kullanım: Personal opinion ağırlıklı, ticari/tanıtım içerikli veya hobi konulu içerik. Tam haber değil ama içerikli post.

Haber sitesinin rehber, dosya, marka tanıtım sayfaları için BlogPosting kullanılır; "haber" iddiasında değildir.

6.5 Subtype Karar Akışı#

İçerik Tipi Doğru Subtype
Son dakika faktual haber NewsArticle
Köşe yazısı / başyazı OpinionNewsArticle
1500+ kelime sektör analizi AnalysisNewsArticle
Saha röportajı / tanık haberi ReportageNewsArticle
Marka rehber / SaaS makale BlogPosting
Canlı blog (deprem, seçim, transfer) LiveBlogPosting
Tek soru-cevap (forum benzeri) QAPage

CMS'in editör panelinde "Yazı tipi" dropdown'u olmalı ve seçilen tipe göre JSON-LD otomatik üretilmelidir. Manuel kod yazımı 100K+ haberlik arşivde sürdürülemez.


7. Sitemap, Robots.txt ve IndexNow Otomatik Üretim#

Discoverability'nin temel üç bileşeni — sitemap, robots ve IndexNow — birlikte çalıştığında haber CMS'iniz dakikalar içinde Bing/Yandex/Google'a yeni haberleri tanıtır. Eksik veya hatalı implementasyon, son dakika haberlerinin saatlerce indekslenememesine yol açar.

7.1 Sitemap Mimarisi#

Modern haber CMS'inin üretmesi gereken sitemap dosyaları:

  • /sitemap.xml — sitemap index (alt sitemap'lere referans)
  • /sitemap-news.xml — son 48 saat içindeki en fazla 1000 haber (Google News spec'i)
  • /sitemap-haber-YYYY-MM.xml — aylık arşiv (50K URL limiti)
  • /sitemap-kategori.xml — kategori sayfaları
  • /sitemap-yazar.xml — yazar sayfaları
  • /sitemap-etiket.xml — etiket cluster sayfaları
  • /sitemap-static.xml — anasayfa, kunye, iletişim, hakkımızda

Her sitemap, <lastmod> (ISO 8601 tarih) içermelidir. Google ve Bing bu alanı re-crawl prioritization için kullanır. Yanlış lastmod (her sayfada bugünün tarihini koymak) anti-pattern'dır ve trust signal kaybına yol açar.

7.2 Robots.txt — AI Crawler İzin#

2026 itibarıyla AI crawler'ları için açık izin/yasak beyan etmek gereklidir. Standart konfigürasyon:

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /

Google-Extended özellikle Bard/Gemini için ayrı user-agent'tır; Googlebot izniyle aynı değildir. Bu user-agent'ı bloklamak SEO sıralamasını etkilemez ama Gemini'de kaynak gösterilmeyi engeller.

7.3 IndexNow Protokolü#

IndexNow, Microsoft tarafından başlatılan ve Bing, Yandex, Seznam ve giderek daha fazla arama motoru tarafından desteklenen push-based indekslemeyi sağlayan açık protokoldür. Resmi dokümantasyon https://www.indexnow.org/ adresindedir.

Çalışma şekli: Site root'unda {key}.txt dosyası (örn. 7417c54a506fe3c8ec0f12925177ad55.txt) host edilir, yayın anında bu key ile birlikte URL Bing/Yandex API'sine POST edilir. Ortalama 5-15 dakika içinde indekslenmeye başlar. Son dakika haberlerinde rakipten 30-60 dakika önde olmak demektir.

Modern CMS, yayın eylemi tetiklendiğinde IndexNow ping'ini otomatik atmalıdır; bu işlev plugin'e bağlı kalmamalıdır.


8. Image Optimization (WebP/AVIF, Responsive, Lazy Loading)#

Haber sitelerinde sayfa ağırlığının %60-80'i image'lerden gelir. Yanlış image stratejisi LCP'yi 'Poor' segmente atar ve mobil veri planlarında ciddi bandwidth maliyeti yaratır.

8.1 Format Stratejisi#

  • AVIF (AV1 Image File Format): En iyi sıkıştırma oranı, %50'ye kadar küçük. Safari 16+, Chrome 85+, Firefox 93+ destekler. 2026 itibarıyla browser desteği %95+.
  • WebP: AVIF fallback. %30 küçük JPEG'e göre. Tüm modern browser'lar destekler.
  • JPEG: Legacy fallback (IE, çok eski Android). Modern haber CMS'inde default kapatılabilir.
  • PNG: Sadece transparency gerektiren ikonlar; foto için kullanılmaz.
  • SVG: Logo, ikon ve illustration için. Inline SVG render-blocking değildir.

<picture> element'i ile cascade: AVIF → WebP → JPEG fallback. Modern CMS bu cascade'i otomatik üretir; içerik editörü tek dosya yükler, sistem 6-8 varyant üretir.

8.2 Responsive Images (srcset + sizes)#

Kullanıcının ekran genişliğine göre doğru boyutta image servis etmek bandwidth ve LCP için kritiktir:

  • 320w, 480w, 768w, 1024w, 1280w, 1920w varyantları
  • sizes attribute ile viewport-conditional seçim
  • loading="lazy" (above-the-fold dışında)
  • decoding="async" (parser-blocking değil)
  • width + height attribute'ları (CLS prevention için zorunlu)

Next.js <Image> ve Astro <Image> component'leri bu pattern'ı default uygular. Custom CMS'te aynı pattern'ı manuel kurmak haftalarca dev efforu gerektirir.

8.3 LCP Image Özel Stratejisi#

Above-the-fold (genellikle hero) image için:

  • loading="eager" (lazy yapılmaz)
  • fetchpriority="high"
  • Preload link tag'i (<link rel="preload" as="image">)
  • Inline critical CSS ile hero container boyutu
  • AVIF/WebP ile maksimum sıkıştırma (kalite 75-80)

Bu optimizasyonlar LCP'yi 2.5s eşiği altına çekmek için kritiktir.


Internal linking, hem kullanıcı navigation'ı hem de link equity dağıtımı için temel araçtır. 30 yıllık tecrübemde, doğru internal linking yapısı kuran haber sitelerinin organik trafiklerinin %30-40'a kadar arttığını gördüm.

Modern CMS, her haberin altına 3-5 related haber koymalıdır. Algoritma şu sinyalleri kullanır:

  • Aynı kategori (5 puan)
  • Ortak entity (kişi, kurum, lokasyon — Wikidata bridge varsa) (3 puan/entity)
  • Ortak etiket (2 puan/etiket)
  • Yayın tarihi yakınlığı (24 saat içinde +1, 7 gün içinde +0.5)
  • Yazar aynılığı (1 puan)

Top-N skorlama ile related haber seçimi 2026 standardıdır. Sadece "aynı kategori son 5 haber" yaklaşımı yetersizdir.

9.2 Breadcrumb Pattern#

Her haber detay ve kategori sayfasında breadcrumb gerekir:

Anasayfa › Kategori › Alt Kategori (varsa) › Haber Başlığı

JSON-LD'de BreadcrumbList schema ile işaretlenmeli, mikroformat'ta <nav aria-label="breadcrumb"> ve <ol> ile semantik render edilmelidir. Schema.org spec için https://schema.org/BreadcrumbList referans alınır.

9.3 Etiket Cluster ve Topic Hub#

Etiket sayfaları topic hub olarak konumlanmalıdır:

  • Etiket başlığı + 2-3 paragraf editorial intro
  • Son 20 haber kronolojik
  • İlgili etiketler (related tags)
  • ItemList JSON-LD

"Boş etiket sayfası" (sadece haber listesi, hiç editorial yok) thin content cezası alır. Modern CMS'te etiket editorial intro alanı zorunlu olmalıdır.

9.4 Anchor Text Discipline#

Internal link'lerde anchor text descriptive olmalı; "buraya tıklayın" veya "devamı" yerine hedef sayfanın anahtar kelimesi kullanılmalıdır. Örnek: "2026 yerel seçim sonuçları" — "buraya tıklayın" değil.


10. URL Structure ve Canonical Tag Yönetimi#

URL yapısı, sıralama sinyali olmasa da kullanıcı tıklama oranı (CTR), sosyal paylaşım ve arşiv yönetimi için kritiktir. Yanlış URL yapısı, 100K+ haberlik arşivde migration cehennemi yaratır.

10.1 URL Best Practices#

  • Kebab-case (boşluk → tire): /haber/yeni-yasa-tasarisi-meclise-sunuldu
  • Lowercase (büyük harf yasak)
  • Türkçe karakter normalize (ş→s, ğ→g, ı→i, ç→c, ö→o, ü→u)
  • Maksimum 4 segment (/kategori/alt-kategori/slug yeterli)
  • Tarih içermez (/2024/03/haber yerine /haber/slug — evergreen güncellenebilir)
  • ID + slug hibrit (slug değişse bile ID ile redirect): /haber/12345/slug
  • Stop word minimal (ve, ile, için)

10.2 Canonical Tag Discipline#

Her sayfa kendi canonical URL'ini bildirmelidir. Yanlış canonical, sayfanın indekslenmemesine yol açar. Kritik kurallar:

  • Self-referencing canonical (her sayfa kendine canonical) default
  • URL parametre (utm, fbclid, gclid) canonical'da yok, asıl URL var
  • Pagination canonical'ı first page'e veya kendine (Google rel="next/prev" deprecated)
  • AMP/mobil ayrı URL artık önerilmez (responsive design)
  • Hreflang ile birlikte self-referencing

10.3 301 Redirect Disipline#

URL değişiminde mutlaka 301 redirect kurulmalı; 302 değil. Modern CMS, URL değiştiğinde otomatik 301 redirect tablosu üretmelidir. Eski URL → yeni URL eşleşmesi DB'de tutulmalı, runtime'da query'lenmelidir.

Slug değişimi sırasında redirect chain maksimum 1 hop olmalıdır. 2+ redirect chain LCP'yi etkiler ve crawler budget'i tüketir.


11. Multi-language Hreflang (TR-tr Default, EN-us Gelecek)#

Türk haber sitesinin tek dilli olması bile hreflang implementasyonu yapmamak için yeterli sebep değildir. Doğru hreflang altyapısı gelecek garantisi sağlar.

11.1 Self-Referencing Hreflang (Tek Dilli Site)#

Tek dilli site için bile her sayfada self-referencing hreflang ve x-default eklenmeli:

<link rel="alternate" hreflang="tr-TR" href="https://example.com/haber/slug" />
<link rel="alternate" hreflang="x-default" href="https://example.com/haber/slug" />

Bu pattern, Google'a "site dilinin Türkçe olduğunu" net olarak bildirir; Türkçe arama sonuçlarında prioritize edilir.

11.2 Multi-language Migration Hazırlığı#

İleride EN-us veya AR eklenecekse altyapı bugünden kurulmalı:

  • DB schema'da language kolonu (ISO 639-1: tr, en, ar)
  • Slug bazında translation_id (aynı haberin farklı dil versiyonlarını birleştirir)
  • Subdirectory pattern (/en/news/slug) > subdomain (en.example.com) — link equity için önerilir
  • Hreflang tüm versiyonları cross-reference eder
  • Schema.org'da inLanguage property ("tr-TR", "en-US")

11.3 İçerik Çevirisi Best Practice#

Otomatik makine çevirisi (Google Translate API çıktısı doğrudan yayın) anti-pattern'dır; thin content/duplicate content cezası alır. Doğru yaklaşım:

  • AI base translation → human editor revision → publish
  • translator field metadata
  • originalLanguage Person schema property
  • Speakable schema dil-spesifik

12. Performans Test Araçları ve İzleme#

Performans bir kez kurulup unutulan bir metrik değildir; sürekli izlenmeli ve regression alarmları kurulmalıdır.

12.1 Lab Tools (Sentetik)#

12.2 Field Tools (Gerçek Kullanıcı / RUM)#

  • Google Search Console > Core Web Vitals — CrUX data (Google sıralaması bunu kullanır)
  • Vercel Analytics — Next.js deployment'lar için entegre
  • Cloudflare Web Analytics — privacy-friendly, ücretsiz
  • SpeedCurve — enterprise RUM
  • CrUX BigQuery dataset — tarihsel field data (advanced)

12.3 Schema Validator ve Rich Results Test#

JSON-LD doğruluğunu test etmek için:

Production deploy öncesi her schema değişikliği mutlaka validator'dan geçirilmelidir. Modern CMS, build sırasında otomatik schema validation step'i içermelidir.

12.4 Monitoring + Alarm#

  • LCP regression alarmı (75p > 3.0s → Slack notification)
  • INP regression alarmı (75p > 300ms → alert)
  • CLS regression alarmı (75p > 0.15 → alert)
  • Core Web Vitals 7 günlük trend dashboard'u
  • Schema validation failure → CI/CD blocker

13. CMS Karşılaştırma: SEO Checklist (15 Kriter × 4 Platform)#

Aşağıdaki tablo, 15 kriterin TR pazarındaki dört temel platform kategorisinde hangi seviyede karşılandığını gösterir. Modern AI-native platformlar, bu raporu yayına hazırlayan ekibin de mensup olduğu yeni nesil mimaridir.

Kriter WordPress + Yoast/RankMath Drupal + Schema.org modülü Geleneksel haber CMS'leri Modern AI-native CMS
SSR / Edge rendering Plugin'lerle hibrit (yarım) Var (server-rendered) Var (PHP monolit, edge yok) Native (Next.js/Astro + edge)
ISR / segmented cache Yarım (cache plugin'leri) Var (Varnish/Memcached config) Yok / sınırlı Native (route-segment)
22+ JSON-LD @type Plugin bağımlı, eksik subtype Konfigürasyonla kapsanır Temel NewsArticle, eksik Native, tüm subtype
NewsArticle subtype'ları (Opinion / Analysis / Reportage) Premium plugin gerekir Custom dev gerekir Yok Native, editör seçer
Sitemap-news.xml Plugin (News SEO addon) Modülle Sınırlı / yok Native otomatik
IndexNow protokolü Plugin Modülle / custom Yok Native otomatik
WebP/AVIF responsive image Plugin (ShortPixel, Imagify) Modülle JPEG ağırlıklı Native pipeline
Core Web Vitals (LCP/CLS/INP) Aggressive tuning gerekir Konfigürasyonla iyi Çoğunlukla 'Needs Improvement' 'Good' default
Canonical tag yönetimi Yoast/RankMath Modülle Sınırlı Native discipline
Hreflang Multilingual plugin Translation modülü Yok Native
Internal linking + related haber Plugin Modülle Basit (aynı kategori) Entity-aware algoritma
URL kebab-case + ≤4 segment Konfigürasyonla Konfigürasyonla Çoğunlukla legacy URL Native
Robots.txt + AI crawler izinleri Manuel düzenleme Manuel Çoğunlukla eksik Native default
/llms.txt + Speakable Yok / plugin yeni Custom dev Yok Native
FAQPage schema Plugin Modülle Yok Native (frontmatter)

Not: Bu tablo "ortalama TR pazar" deneyimimi yansıtır; her kategori içinde istisnalar vardır. WordPress'i ileri düzey kurulumla 13/15'e çıkarmak mümkündür ancak bakım maliyeti modern alternatiflere göre 3-5 kat yüksektir.


14. Pilot Program ve Geçiş Yaklaşımı#

30 yıllık tecrübemde, technical SEO migration'larının %60'ı kötü planlama yüzünden organik trafik kaybıyla sonuçlanır. Doğru pilot programla bu risk minimize edilebilir.

14.1 Plan ücretleri ve Pro Pilot tarifesi#

K-On Tech bünyesinde sunulan haber CMS plan ücretleri: Starter ₺20.000/ay (günlük 30 AI üretim kredisi), Pro ₺50.000/ay (günlük 100 AI üretim kredisi), Pro+ ₺85.000/ay (günlük 250 AI üretim kredisi), Enterprise T1 ₺175.000/ay (5 site, günlük 500 AI üretim kredisi toplam), T2 ₺350.000/ay (10 site, günlük 1.500 AI üretim kredisi). Pro Pilot tarifesi ₺30.000/ay ilk 5-10 müşteri için pilot fiyattır; sabit fiyat garantisi ödeme frekansına bağlıdır: yıllık peşin ödemede 12 ay sabit fiyat garantisi + ek %15 indirim, aylık ödemede olağanüstü kur veya altyapı maliyet değişimi 60 gün önceden yazılı bildirimle yansıtılabilir (max %50/yıl cap). Setup fee Pro paketi için tek seferlik ₺50.000; bu kapsamda mevcut arşiv migration'ı, JSON-LD coverage audit'i ve Core Web Vitals baseline ölçümü yapılır.

Standart AI değil — Yapay zekâ herkesinki. Ses sizinki.

14.2 Migration Checklist#

Geçiş sürecinde mutlaka tamamlanması gereken adımlar:

  1. Mevcut URL envanteri (Screaming Frog veya Sitebulb ile)
  2. Mevcut JSON-LD coverage (Schema.org validator + Rich Results Test)
  3. Mevcut Core Web Vitals baseline (CrUX field data export)
  4. Slug-preserving migration plan (eski URL'ler korunur)
  5. 301 redirect tablosu (her URL değişikliği için)
  6. Sitemap geçiş planı (eski sitemap valid kalır, yeni eklenir)
  7. IndexNow ping (yayın eyleminde otomatik)
  8. Search Console & Bing Webmaster Tools yeni site kayıt
  9. Cutover sonrası 30 gün günlük monitoring
  10. Rollback planı (kritik regression için)

Sıkça Sorulan Sorular#

Q: WordPress haber sitesi SEO için yeterli mi? A: WordPress + Yoast/RankMath kombinasyonu klasik bir blog için yeterli olabilir; ancak modern haber sitesi için 2026 standartlarının gerisinde kalır. Sebepler: Core Web Vitals eşiklerini (LCP < 2.5s, INP < 200ms) yüksek trafik altında tutturmak için ekstra cache katmanı, CDN, image optimization plugin'leri ve performance tuning gerekir; default WordPress JSON-LD coverage'ı NewsArticle subtype'larını (Opinion, Analysis, Reportage), Speakable ve LiveBlogPosting'i kapsamaz; sitemap-news.xml otomatik üretmez ve IndexNow desteği plugin bağımlıdır. Mümkün, fakat aylık 50K+ pageview'da bakım maliyeti modern alternatifleri geçer.

Q: Next.js mi Astro mu daha SEO uyumlu? A: Her ikisi de modern haber CMS için uygun temel sunar; tercih içerik update sıklığına bağlıdır. Next.js (App Router + RSC) ISR, edge rendering, streaming ve dinamik metadata API ile son dakika haber + live blog senaryolarında üstündür. Astro 'islands' mimarisiyle statik ağırlıklı içerikte (rehber, evergreen makale) daha düşük JavaScript payload sunar. Haber sitesinin %70'i son dakika içeriği ise Next.js, %70'i evergreen ise Astro. Uygulamada hibrit kullanım (Next.js core + edge cache + statik export segmentleri) en iyi sonucu verir.

Q: Core Web Vitals nasıl ölçülür? A: İki temel ölçüm yöntemi vardır: Lab (sentetik) ve Field (gerçek kullanıcı). Lab için Lighthouse, PageSpeed Insights ve WebPageTest kullanılır. Field için Chrome User Experience Report (CrUX) ve Real User Monitoring (RUM) tool'ları (Vercel Analytics, Cloudflare Web Analytics, SpeedCurve) gerçek ziyaretçi verisini gösterir. Google Search Console "Core Web Vitals" raporu CrUX field verisini özetler — sıralama sinyali olan veri budur. Lab skorları yüksek olsa bile field metrikler 'Poor' segmentinde ise sıralama düşer.

Q: JSON-LD ne kadar kritik? A: Modern arama ve cevap motorları (Google News, ChatGPT, Perplexity, Gemini, Bing Copilot) sayfa içeriğini değil structured data'yı (JSON-LD) parse eder. Schema.org NewsArticle, FAQPage, Speakable, BreadcrumbList, ImageObject ve LiveBlogPosting olmayan sayfalar Top Stories carousel'inde, Knowledge Panel'da, Featured Snippet'te ve cevap motoru kaynak listesinde görünmez. JSON-LD eksikliği 2026 itibarıyla artık 'eksik bonus' değil; doğrudan 'eksik temel' kategorisindedir.

Q: Hangi CMS'in JSON-LD desteği iyidir? A: Modern AI-native haber CMS platformları 22+ schema.org @type'ı default üretir; haber yayını için kritik tüm subtype'ları (NewsArticle, OpinionNewsArticle, AnalysisNewsArticle, ReportageNewsArticle, BlogPosting) ve yardımcı tipleri (Speakable, LiveBlogPosting, FAQPage, Person.sameAs, Organization, ImageObject, VideoObject) kapsar. WordPress'te bu coverage için Yoast SEO Premium + News SEO addon + Schema Pro plugin kombinasyonu gerekir ve bakım gerektirir. Drupal Schema.org modülü güçlü ama konfigürasyon eğrisi diktir. Geleneksel haber CMS'leri çoğunlukla yalnızca temel NewsArticle üretir.

Q: Server-Side Rendering haber sitesi için zorunlu mu? A: Evet, modern haber sitesi için SSR veya edge rendering pratik olarak zorunludur. Sebep: Googlebot, Bingbot ve özellikle GPTBot/ClaudeBot/PerplexityBot client-side rendered içeriği indekslemekte tutarsızdır; ilk HTML response'unda anlamlı içerik yoksa 'soft 404' veya thin content sinyali oluşur. Ayrıca son dakika haberlerinde TTFB (Time To First Byte) < 600ms hedefi CSR ile yakalanamaz. Server-Side Rendering + edge cache + ISR kombinasyonu 2026 standardıdır.

Q: ISR (Incremental Static Regeneration) ne zaman kullanılır? A: ISR, statik üretimin sıralama avantajını dinamik içerik tazeliği ile birleştiren tekniktir. Haber sitelerinde anasayfa ve kategori sayfaları (60 saniye revalidate), arşiv ve evergreen rehber sayfaları (1 saat revalidate) ve canlı blog dışındaki haber detay sayfaları için idealdir. Live blog, anketler ve kullanıcıya özel içerik için ISR kullanılmaz; SSR streaming veya Server Actions tercih edilir. Doğru ISR konfigürasyonu LCP'yi %40-60 düşürür.

Q: IndexNow protokolünü kullanmak gerekli mi? A: 2026 itibarıyla son dakika haberleri için IndexNow neredeyse zorunlu hâle geldi. Bing, Yandex ve giderek daha fazla arama motoru bu protokolü destekliyor; URL push edildikten sonra ortalama 5-15 dakika içinde indexlemeye giriyor. Geleneksel sitemap polling yöntemi 1-6 saat gecikme yaratır — son dakika haber rekabetinde bu süre rakibe kaybetmek demektir. CMS'inizin yayın eylemi tetiklendiğinde otomatik IndexNow ping atması default olmalı.

Q: Hreflang tag'i tek dilli haber sitesi için gerekli mi? A: Tek dilli (TR-tr) bir site için hreflang teknik olarak zorunlu değildir; ancak 'tr' (dil) ile 'tr-TR' (dil + ülke) ayrımını x-default ile birlikte yayınlamak best practice'tir. İleride EN-us veya AR ekleme planınız varsa hreflang altyapısını başından kurun; sonradan retrofit etmek 100K+ URL'lik arşivde haftalar süren bir migration gerektirir. Self-referencing hreflang ekleme alışkanlığı, schema.org inLanguage property'si ile birlikte LLM'lerin dil filtreleme kalitesini de artırır.

Q: Sitemap-news.xml ile normal sitemap.xml farkı nedir? A: Sitemap-news.xml, Google News tarafından özel olarak tüketilen bir formattır ve yalnızca son 48 saat içinde yayınlanmış 1000'e kadar haberi içerir. Standart sitemap.xml ise tüm sayfaları (kategori, etiket, yazar, evergreen) kapsar ve 50K URL limiti vardır. Modern haber CMS'i her ikisini de otomatik üretir, sitemap index'le birleştirir ve robots.txt'ye doğru referansları ekler. Eksik news sitemap, Google News'te görünmemenin en yaygın sebebidir.


İlgili Makaleler#


Kaynaklar ve Referanslar#

Sıkça Sorulan Sorular

FAQPage
WordPress + Yoast/RankMath kombinasyonu klasik bir blog için yeterli olabilir; ancak modern haber sitesi için 2026 standartlarının gerisinde kalır. Sebepler: Core Web Vitals eşiklerini (LCP < 2.5s, INP < 200ms) yüksek trafik altında tutturmak için ekstra cache katmanı, CDN, image optimization plugin'leri ve performance tuning gerekir; default WordPress JSON-LD coverage'ı NewsArticle subtype'larını (Opinion, Analysis, Reportage), Speakable ve LiveBlogPosting'i kapsamaz; sitemap-news.xml otomatik üretmez ve IndexNow desteği plugin bağımlıdır. Mümkün, fakat aylık 50K+ pageview'da bakım maliyeti modern alternatifleri geçer.

İlgili Makaleler

Tüm makaleler
Demo Talep Et

Haberlendin CMS'i kendi haber portalınızda görmek ister misiniz?

30 dakikalık birebir demo + 14 gün ücretsiz değerlendirme + ROI raporu. K-On Tech ekibi 12+ kişiyle her sürecinizde yanınızda.

18 uzman makale · Türkiye'nin ilk AI-native haber CMS'i