Content SEO Nedir? People-First İçerik, "Kim, Nasıl, Neden" Soruları ve Search Engine-First Uyarı İşaretleri

Sürüm notu: Bu yazı Google Search Central'ın people-first içerik rehberinin, spam policy'lerinin ve generative AI içerik rehberinin (son değişiklik 1 Ekim 2026) Kasım 2026 hâlini esas alır.

Önce Tahmin Et

Bookstore ekibinin teknik blog'u bir yıldır yayında. Çeyrek planlamasında içerikten sorumlu ekip arkadaşın üç öneri getiriyor: (1) her hafta AI ile 20 yeni yazı üretelim, konuları Google Trends'te o hafta yükselen terimlerden seçelim; (2) her yazı en az 2.500 kelime olsun, çünkü "Google uzun içeriği seviyor"; (3) eski yazıların tarihini her ay bugüne çekelim ki "taze" görünsünler. Sence bu üç maddeden hangisi Google'ın kendi rehberinde açıkça uyarı işareti olarak geçiyor? Hangisi, yalnız sıralamaya yaramamakla kalmayıp sitenin bütününe zarar verebilir?

Cevap: üçü de. Nedenini görmek için önce tanımları netleştirelim. SEO (Search Engine Optimization; bir sitenin arama motorlarında bulunması ve sorgulara cevap olarak seçilmesi için yapılan çalışmalar) işinin içerik tarafına content SEO diyoruz.

Content SEO Nedir? Teknik SEO'dan Farkı

SEO işini iki katmanda düşünmek işe yarıyor. Teknik katman sayfanın bulunabilmesini sağlar: crawl edilebilir URL'ler, doğru status code'lar, canonical, sitemap, hreflang, render. Bunların hepsini Teknik SEO serisinde ASP.NET Core üzerinde kurduk. İçerik katmanı ise bulunan sayfanın bir sorguya cevap olarak seçilmesini sağlar: sayfa doğru soruya mı cevap veriyor, cevap güvenilir mi, okur aradığını bulup gidiyor mu?

Altyapı kusursuz olabilir, ama index'te duran bir sayfa, okura bir şey katmıyorsa sıralamada bir yere gelmez. Tersi de doğru: çok iyi bir yazı, crawl edilemiyorsa kimseye ulaşmaz. Google'ın SEO Starter Guide'ı bu konuda net: rehberdeki bütün maddeler arasında arama görünürlüğünü en çok etkileyecek şey, ilgi çekici ve faydalı içerik. Content SEO bu yüzden "metne keyword serpiştirmek" değil; doğru konuyu, doğru niyet için, doğru yapıda yazmak ve yazdığını zaman içinde canlı tutmak.

Bu seri yedi yazıda bunu adım adım işliyor: ne yazacağına karar vermek (keyword research ve search intent), yazdıklarını organize etmek (content architecture ve internal linking), yazmak ve sürdürmek (cevap veren sayfa ve içerik bakımı). Çalışan örnek, okuduğun site: mertozen.com'un kategori, seri ve yazı yapısı. Crawl, index ve ranking mekanizmasını SEO Temelleri serisinin ilk ve üçüncü yazılarında anlattık; burada yalnız içerik tarafına bakıyoruz.

Google'ın People-First İçerik Rehberi Ne Söylüyor?

Google'ın "Creating helpful, reliable, people-first content" sayfası tek bir fikrin etrafında kurulu: ranking system'ler, arama motorunu etkilemek için değil, insanlara faydalı olmak için üretilmiş içeriği öne çıkarmaya çalışıyor. Sayfa bunu ölçen bir algoritma tarif etmiyor; onun yerine içerik üreticisinin kendine sorabileceği soru grupları veriyor. Bu soruları madde madde kopyalamak yerine, ne sorduklarını kendi cümlelerimizle anlatalım:

• İçerik ve kalite: Yazı özgün bilgi, araştırma veya analiz içeriyor mu? Başka kaynakları özetliyorsa üstüne bir şey ekliyor mu? Başlık içeriği dürüstçe anlatıyor mu, abartıyor mu?
• Uzmanlık: Okur, bilginin nereden geldiğini ve yazanın neden bu konuda konuştuğunu görebiliyor mu? Kolayca doğrulanabilecek bir hata var mı?
• Sunum: Metin özensiz ya da seri üretim izlenimi veriyor mu? Reklam veya dikkat dağıtan öğeler içeriğin önüne geçiyor mu?
• Karşılaştırma: Bu sayfa, aynı sorgu için çıkan diğer sonuçlardan daha fazla değer veriyor mu? Okur sayfadan çıktığında aradığını bulmuş oluyor mu, yoksa tekrar aramak zorunda mı kalıyor?

Rehber iki pratik öneri daha ekliyor: içeriği sitenle ilgisi olmayan, dürüst fikir verecek birine değerlendirtmek ve trafiği düşen sayfalardan başlayarak bir denetim yapmak. İkincisini serinin son yazısında Search Console verisiyle yapacağız.

Bir not: Google 2024'te ayrı bir "helpful content system" kullanmayı bırakıp bu sinyalleri core ranking system'lerine kattı (SEO Temelleri serisinin "SEO Mitleri ve Gerçekler" yazısında anlattık). Yani bu sorular ayrı bir filtrenin değil, sıralamanın genel mantığının parçası.

Bir Yazıya Uygulamak: mertozen.com'dan Örnek

Soruları soyut bırakmamak için sitedeki gerçek bir yazıya uygulayalım: Structured Data ve Schema.org serisinin ilk yazısı, "Structured Data Nedir? Schema.org, JSON-LD ve Google'ın Bununla Gerçekte Ne Yaptığı".

Tablonun değeri sağ sütunda: helpful content soruları bir puan vermiyor, yapılacak iş listesi çıkarıyor. Bu örnekte iş listesi kısa ve somut: byline'ı yazar sayfasına bağlamak, kaynakları okurun ulaşabileceği biçimde vermek ve üretim sürecinin nasıl anlatılacağına karar vermek.

Who, How, Why: Kim, Nasıl ve Neden?

Who: Kim yazdı?

Rehberin "Who, How, Why" bölümü, kalite sorularını üç somut başlığa indiriyor. İlki yazar. Google'a göre okurun, içeriği kimin ürettiğini kolayca görebilmesi gerekiyor; okurun byline beklediği yerde byline olmalı ve byline, yazar hakkında daha fazla bilgiye götürmeli. Teknik blog'da bu, yazının başında bir isim ve o ismin bir "Hakkımda" sayfasına bağlanması demek. O sayfada da yazarın neyle uğraştığı, hangi teknolojilerde çalıştığı ve dış profilleri yer alır.

mertozen.com'da byline bugün sitenin adı olarak, düz metin hâlinde görünüyor; JSON-LD tarafında ise yazı bir BlogPosting, author bir Person ve Hakkımda sayfası ProfilePage olarak işaretli. Yani makine için bağlantı kurulmuş, okur için kurulmamış. Byline'ı Hakkımda sayfasına link yapmak tek satırlık bir Razor değişikliği ve rehberin önerisiyle birebir örtüşüyor.

Rehberin bu bölümdeki uyarısı da önemli: AI ile üretilmiş profil fotoğrafları, uydurma isimler veya gerçek olmayan unvanlarla sahte yazar kimliği oluşturmak okuru yanıltır ve düşük kalite işaretidir. Ekip blog'larında "Bookstore Engineering" gibi bir ekip adı kullanmak sorun değil; sorun, var olmayan bir kişi uydurmak.

How: Nasıl üretildi?

İkinci başlık üretim süreci. Google bu soruyu özellikle ürün incelemeleri için açıyor: kaç ürün denendi, test sonuçları ne, fotoğraflar nerede? Teknik blog için karşılığı belli: kod çalıştırıldı mı, çıktı gerçek mi, hangi sürümle denendi? Okur bir hata mesajıyla geldiğinde, yazıdaki çözümün kendi ortamında çalışıp çalışmayacağını bu bilgilerden anlar. mertozen.com'daki her yazının ilk satırı olan "Sürüm notu" tam olarak bu sinyal: kodun hangi .NET sürümüyle derlendiğini ve hangi paket sürümleriyle denendiğini söylüyor. Gösterilen derleyici uyarısının, HTTP yanıtının, test çıktısının gerçek bir koşudan gelmesi de aynı sinyalin devamı. Uydurma bir çıktı, okurun ilk denemesinde fark edilir.

Otomasyon ve AI konusunda rehber şunu söylüyor: içeriğin önemli bir kısmı otomasyonla veya AI ile üretildiyse, okurun bunu merak edeceği yerde nasıl ve neden kullanıldığını açıklamak doğru. Google'ın Şubat 2023 tarihli AI içerik yazısı iki ayrıntı ekliyor: AI'ı byline'a yazar olarak koymak önerilen açıklama biçimi değil ve AI ile üretilmiş içerik ne özel bir avantaj ne de özel bir ceza alıyor; ölçüt yine faydalı, özgün ve güvenilir olması. Teknik blog'da açıklamanın doğal yeri, zaten üretim sürecini anlatan sürüm notu satırı ya da sitenin genel bir "Bu blog nasıl yazılıyor?" bölümü.

Why: Neden var?

Üçüncü başlık en temel olanı: bu sayfa neden üretildi? Rehberin cevabı açık. Asıl amaç, siteye doğrudan gelen okura yardım etmek olmalı. Asıl amaç arama motorundan ziyaret çekmekse içerik Google'ın ödüllendirmeye çalıştığı şeyle örtüşmüyor; otomasyonu sıralamayı manipüle etmek için kullanmak ise spam policy ihlali.

Pratikte şu testi kullanabilirsin: bu yazıyı, arama motorlarından hiç trafik gelmeyeceğini bilsen de yazar mıydın? Bir seriyi tamamlayan, okurun bir sonraki adımda ihtiyaç duyacağı bir yazı için cevap "evet". "Bu kelime çok aranıyormuş, bir şey yazalım" diye açılmış bir yazı için cevap genellikle "hayır".

Search Engine-First Uyarı İşaretleri

Rehber, içeriğin arama motoru için üretildiğini gösteren işaretleri de soru olarak sıralıyor. Teknik blog'daki karşılıklarıyla birlikte bakalım:

Trend kovalamak. Konuyu, mevcut okur kitlene uyduğu için değil, o hafta popüler olduğu için seçmek. Bookstore'un .NET blog'unda bir anda kripto borsa incelemesi çıkması bunun örneği. Planlamadaki ilk öneri, yani konuları Trends'te yükselen terimlerden seçmek, bu işarete doğrudan uyuyor.

Uzmanlık olmadan yeni bir alana girmek. Trafik vaat ettiği için hiç çalışmadığın bir konuda yazmak. Bir .NET ekibinin, hiç kullanmadığı bir mobil framework hakkında karşılaştırma yazması gibi.

Kelime sayısı hedefi. Google'ın tercih ettiği bir kelime sayısı yok; rehber bunu açıkça söylüyor. "Her yazı 2.500 kelime" kuralı, kısa cevabı olan sorularda yazıyı dolgu metniyle şişirmeye iter. İkinci öneri buraya düşüyor.

Tarihi değiştirerek tazelik. İçerikte esaslı bir değişiklik yapmadan yayın tarihini güncellemek veya yalnız "taze görünsün" diye içerik ekleyip çıkarmak. Rehber bunun işe yaramadığını söylüyor. Üçüncü öneri tam olarak bu.

Başkalarının içeriğini yeniden anlatmak. Microsoft Learn'deki bir sayfayı Türkçe'ye aktarıp üstüne hiçbir deneme, ölçüm veya yorum eklememek. Okur aynı bilgiye kaynağın kendisinden daha iyi ulaşır.

Var olmayan bir cevabı vaat etmek. Henüz duyurulmamış bir sürüm için ".NET 12 çıkış tarihi" başlıklı bir yazı açıp içinde tarih vermemek.

Çok konuda ağır otomasyon. Birçok konuyu kapsasın diye otomatik araçlarla seri hâlinde sayfa üretmek. Bu işaret bizi spam policy'lerine götürüyor.

Ölçek Sınırı: Scaled Content Abuse

Google'ın spam policy'leri arasındaki scaled content abuse, okura yardım etmek yerine esas olarak sıralamayı etkilemek için çok sayıda sayfa üretmeyi tanımlıyor. Policy'nin kilit noktası, içeriğin nasıl üretildiğinin önemli olmaması: elle de, şablonla da, AI ile de üretilmiş olsa, az değer katan çok sayıda sayfa ihlal sayılıyor. Policy'nin örnekleri arasında generative AI ile çok sayıda düşük değerli sayfa üretmek, arama sonuçlarını veya feed'leri alıp eş anlamlı kelimelerle ya da çeviriyle dönüştürmek ve farklı sayfalardan parçaları değer katmadan birleştirmek var.

Google'ın generative AI içerik rehberi bu çizgiyi pratik adımlara çeviriyor: AI çıktısı yayından önce doğrulanmalı ve gözden geçirilmeli; bu yalnız gövde metni için değil, title, meta description, structured data ve görsel alt metinleri için de geçerli. Rehber 1 Ekim 2026'da güncellendi ve artık, toplu üretilmiş içeriği ve az emekle, az özgünlükle üretilmiş içeriği değerlendiren Search Quality Rater Guidelines bölümlerine de atıf yapıyor. Rater'ların değerlendirmesi sıralamayı doğrudan değiştirmiyor, ama Google'ın neyi düşük kalite saydığını gösteriyor.

Bookstore'un ilk önerisine dönersek: haftada 20 AI yazısı kendi başına ihlal değil. İhlal olup olmadığını, her yazının okura ne kattığı ve yayından önce kimin neyi doğruladığı belirliyor. Çalıştırılmış kod, gerçek çıktı ve bir insanın yaptığı kontrol olmadan çıkan 20 yazı, policy'nin tarif ettiği şeye çok yakın.

Üretimde Dikkat

CMS'e (içerik yönetim sistemi) bir yayın öncesi kontrol adımı ekle. Yazı formunda üç zorunlu alan yeterli: yazar (gerçek kişi veya ekip), doğrulama notu (sürüm, ortam, çalıştırılan komutlar) ve yazının hangi okur sorusuna cevap verdiği. Üçüncü alan boş kalıyorsa yazının "Why" sorusuna cevabı yok demektir.

AI kullanıyorsan iş akışını kayıt altına al. Taslağı kim üretti, kodu kim çalıştırdı, kaynakları kim kontrol etti? Bu bilgi hem açıklama metni yazarken hem de bir hata çıktığında kökünü bulurken işine yarar.

Sayı sınırı koy. İçerik üreten bir pipeline'ın günlük veya haftalık bir üst sınırı ve yayından önce bir insan onayı olsun. Ölçek sorunu genellikle kimse fark etmeden büyür.

Tarih alanlarını CMS'te ayır. Yayın tarihi değişmez; güncelleme tarihi yalnız içerikte esaslı bir değişiklik olduğunda ilerler. Editörün "tarihi bugüne çek" düğmesi olmamalı. Bu konuya serinin son yazısında ayrıntılı döneceğiz.

Sık Düşülen Tuzaklar

"SEO için yazmak" ile "okur için yazıp bulunur kılmak" arasındaki farkı kaybetmek. İlki konuyu ve metni arama motoruna göre seçer; ikincisi okurun sorusuna göre yazar, sonra o yazının bulunabilmesi için teknik ve içerik tarafındaki engelleri kaldırır. Rehberin "What about SEO?" bölümü de SEO'yu ikinci anlamda, yani people-first içeriğe uygulanan bir destek olarak görüyor.

E-E-A-T'yi (Experience, Expertise, Authoritativeness, Trustworthiness; deneyim, uzmanlık, otorite ve güvenilirlik) doğrudan bir ranking factor sanmak. Hem people-first rehberi hem SEO Starter Guide bunun belirli bir ranking factor olmadığını söylüyor. Google, iyi E-E-A-T'ye işaret eden bir dizi faktörü kullanıyor; "E-E-A-T puanını yükseltmek" diye bir iş yok. Ayrıntısı SEO Temelleri serisinin "Google Nasıl Sıralar? Ranking System'ler, Core Update'ler ve E-E-A-T" yazısında.

AI kullanımını açıklamanın ceza getireceğini düşünmek. Google'ın ölçütü üretim biçimi değil, içeriğin değeri. Saklamak ise okurun güvenini riske atar.

Self-assessment sorularını bir kontrol listesi gibi işaretleyip geçmek. Soruların amacı "evet" toplamak değil, her yazı için yapılacak somut işi bulmak; yukarıdaki tablonun sağ sütunu gibi.

Küçük Bir Deneme

★☆☆ Kendi blog'undan veya ekibinin dokümantasyonundan bir sayfa seç ve yukarıdaki tabloyu o sayfa için doldur. Sağ sütunda en az iki somut iş çıkıyor mu?

★★☆ Son altı ayda yayımladığın yazıların başlıklarını listele ve her birinin yanına "Why" sorusunun cevabını tek cümleyle yaz. Cevabı "çok aranıyordu" olanları işaretle ve bu yazıların okura ne kattığını yeniden değerlendir.

★★★ Kullandığın CMS'te veya bir ASP.NET Core yayın endpoint'inde, yazar, doğrulama notu ve hedef okur sorusu alanları boşsa yayını engelleyen bir kontrol yaz. AI ile üretilen taslaklar için ayrıca bir onay alanı ekle.

Bu yazıda neyi yazmamamız gerektiğini ve iyi içeriğin Google tarafından nasıl tarif edildiğini gördük. Sıradaki soru, neyi yazacağımız: bir sonraki yazıda teknik bir blog için konu ve sorgu bulmayı, Search Console'daki kendi verimizden Keyword Planner'a kadar her kaynağın neyi gösterip neyi göstermediğiyle birlikte ele alıyoruz.