Entity netliği neden önemlidir
Generative görünürlük, sıralamalar bozulmadan çok önce kırılmaya başlar.
Bir marka kategori terimlerinde sıralama alabilir, güçlü içerik üretebilir ve buna rağmen AI yanıtlarında hiç yer almayabilir, yanlış sınıflandırılabilir ya da zayıf şekilde referans gösterilebilir. Bunun nedeni çoğu zaman prompt sorunu değildir. Sorun entity tarafındadır.
Entity SEO, bir şirketi web genelinde ayrı ve tutarlı bir varlık olarak okunabilir hale getirme disiplinidir: ne olduğu, ne yaptığı, hangi ürünleri sunduğu, hangi kategoriye ait olduğu, kime hizmet verdiği, hangi iddiaları destekleyebildiği ve bu iddiaların güvenilir kaynaklarla nasıl ilişkilendiği.
Bu kritik bir konu çünkü GEO yalnızca sayfa bazlı alaka düzeyi üzerine kurulmaz. AI sistemleri yanıtları retrieval, ranking, summarization ve synthesis katmanları üzerinden oluşturur. Markanız bu katmanlar boyunca tutarsız temsil ediliyorsa, model de aynı kafa karışıklığını devralır.
Bunu basitçe şöyle çerçeveleyebiliriz:
| Katman | Arama motorlarının ihtiyaç duyduğu şey | AI sistemlerinin ihtiyaç duyduğu şey | Entity sinyalleri zayıf olduğunda ne bozulur |
|---|---|---|---|
| Crawl/index katmanı | Erişilebilir sayfalar, canonicalization, structured markup | Kimlik sinyalleri net olan stabil kaynak dokümanlar | Sayfalar markadan kopar veya yanlış yorumlanır |
| Retrieval katmanı | Keyword relevance, topical coverage, internal linking | Marka + kategori + use case + kanıt ilişkisini güçlü biçimde kuran dokümanlar | Marka, yüksek niyetli sorgularda retrieval set’ine girmez |
| Understanding katmanı | Structured data, on-page semantics, external corroboration | Kaynaklar arasında tutarlı eşleşmeler | Model şirketinizi yakın kategorideki araçlarla veya jenerik kavramlarla karıştırır |
| Yanıt üretim katmanı | Featured snippet’e uygun formatlama, kısa ve net tanımlar | Yüksek güvenli gerçekler ve desteklenebilir iddialar | Marka hiç geçmez, yanlış tanımlanır veya düşük güvenle alıntılanır |
Bu yazının temel tezi net: GEO, entity katmanını düzelterek başlar.
Şirketiniz ana sayfada, ürün sayfalarında, Crunchbase profilinde, app store listelemesinde, analist yorumlarında ve partner ekosistemi sayfalarında beş farklı şekilde tanımlanıyorsa, modeller bunu “kendiliğinden” temiz biçimde çözmez. Dağınık bir graph’ı olasılıksal olarak uzlaştırırlar. Bazen doğru sonuca ulaşırlar. Çoğu zaman ise nüansı düzleştirir, eski tanımlara fazla ağırlık verir ya da markayı tamamen görmezden gelirler.
Bu yüzden entity çalışması bileşik etki yaratır. Evet, klasik arama performansını iyileştirir. Ama daha önemlisi, şirketinizin ChatGPT, Perplexity, Gemini ve Claude gibi AI aracılı keşif ortamlarında doğru şekilde retrieve edilme ve temsil edilme ihtimalini yükseltir. İşte bu, SEO ile GEO arasındaki köprüdür.
Pratikte “entity SEO” tam olarak ne anlama gelir?
Taktik seviyede entity SEO, sadece “schema eklemek” değildir.
Bu, dört sinyal grubunu hizalamaya yönelik operasyonel bir çalışmadır:
-
Kimlik sinyalleri
Resmi adınız, tüzel şirket adınız, marka adınız, ürün adlarınız, domain’iniz, logo, sosyal profiller, kuruluş tarihi, şirket türü ve coğrafi kapsamanız. -
Kategori sinyalleri
Sahiplenmek istediğiniz pazar kategorisi, içinde yer aldığınız komşu kategoriler ve müşterilerin ya da üçüncü tarafların sizi tanımlarken kullandığı dil. -
Attribute sinyalleri
Yetenekler, özellikler, entegrasyonlar, hedef segmentler, fiyatlandırma modeli, deployment modeli, uyumluluk standartları, diller, platformlar ve farklılaştırıcı unsurlar. -
Kanıt sinyalleri
Case study’ler, müşteri logoları, yorumlar, atıflar, benchmark’lar, analist yorumları, ödüller, dokümantasyon, help center içeriği, araştırmalar ve uzman yazarlığı.
B2B ekiplerin çoğunda bunların parçaları vardır. Ama çok az ekip bunları gerçek anlamda hizalamıştır.
Ana sayfa “gelir ekipleri için AI workspace” der. App store “sales enablement software” yazar. G2 sizi “conversation intelligence platform” olarak listeler. Kurucu biyografisi “go-to-market operating system” ifadesini kullanır. Ürün sayfaları forecasting, coaching ve call transcription’dan bahseder. Bir yayın sizi “CRM analytics software” diye referans gösterir.
Bu ifadelerin her biri belirli ölçüde doğru olabilir. Ama birlikte ele alındığında zayıf entity sınırları oluştururlar.
AI sistemleri tutarlılığı tercih eder. Aynı entity’yi sürekli olarak aynı çekirdek kategori ve stabil bir attribute set’iyle ilişkilendiren kaynakları ödüllendirir.
GEO neden entity katmanına bağlıdır?
Large language model’ler, şirketiniz için tertemiz ve vendor onaylı bir profil tutmaz. Elde bulunan sinyallerden bir profil oluştururlar.
Bu sinyaller genelde şu kaynakların karışımından gelir:
- web siteniz
- structured data
- bilgi tabanları ve business profilleri
- review platformları
- ilgiliyse app store’lar
- yayıncı ve analist referansları
- teknik ürünlerde developer docs ve GitHub
- sosyal profiller ve community referansları
- search index’ler ve retrieval sistemleri üzerinden erişilen veri setleri
Bu kaynaklar birbiriyle uyumlu olduğunda model daha yüksek güven duyar. Çeliştiklerinde ise genelde şu üç durumdan biri yaşanır:
-
Marka genelleştirilir
“Ticari müteahhitler için inşaat proje yönetim yazılımı” olmak yerine sadece “bir proje yönetim aracı” haline gelirsiniz. -
Marka daha güçlü bir komşu entity içinde erir
Daha küçük vendor’lar çoğu zaman kategori liderinin çerçevesine çekilir. Özellikleri lider markanın terminolojisiyle anlatılır ya da yanıtlardan tamamen dışarıda kalırlar. -
Marka öneri setlerinin dışında kalır
Retrieval zinciri şirketinizi sorgunun kategorisi, use case’i veya proof threshold’u ile güvenle eşleştiremiyorsa, yanıt katmanına hiç ulaşamazsınız.
Bu durum özellikle şu prompt sınıflarında çok görünür hale gelir:
- “Best SOC 2 compliance tools for mid-market SaaS”
- “Alternatives to Gong for smaller sales teams”
- “Which employee scheduling apps support union rules?”
- “Top mobile attribution tools for gaming apps”
- “What are the best HIPAA-compliant intake platforms for clinics?”
Bu tür yanıtlarda görünmek için yalnızca bir keyword’e optimize edilmiş web sayfası yeterli değildir. Doğru kategori, attribute ve kanıtlarla bağlantılı stabil bir entity gerekir.
AI sistemleri marka kimliğini nasıl çıkarır?
Hiçbir dış model kendi ağırlıklandırmasını tam olarak açıklamaz. Ancak pratikte AI yanıt sistemleri, üst üste binen retrieval ve confidence pattern’larına dayanır.
Tekrarlanan kategori birlikte-geçişi
Markanız güvenilir dokümanlarda sürekli aynı kategori ifadelerinin yakınında yer alıyorsa, ilişki gücü artar.
Örneğin bir şirket sürekli şu ifadelerle birlikte anılıyorsa:
- “cloud cost optimization”
- “Kubernetes cost visibility”
- “FinOps platform”
- “AWS cost allocation”
retrieval katmanı bu entity’yi, bu kavramlarla yalnızca tek bir solutions sayfasında bir kez geçmesine kıyasla çok daha yüksek güvenle eşleştirebilir.
Named-entity disambiguation
Belirsiz isimlere sahip markalar en yaygın hata senaryolarından biridir.
Şirketinizin adı “Ramp”, “Pilot”, “Mercury” veya “Branch” ise; common noun’larla, diğer markalarla ve bazen bilimsel ya da coğrafi entity’lerle aynı anda rekabet ediyorsunuz demektir. Bu durumda netlik sinyalleri daha da kritik hale gelir:
- organization schema
- sameAs referansları
- resmi profiller
- branded anchor text
- tekrarlanan “Brand + category” kullanımı
- güçlü About ve press sayfaları
- tam marka adı ve açıklayıcı descriptor kullanan publisher referansları
Kaynaklar arası doğrulama
Web sitenizde bir kez belirtilen bir iddia sadece bir iddiadır. Aynı iddia tekrarlandığında ve dış referanslarla desteklendiğinde bir attribute’a dönüşür.
Örneğin:
- “Used by 3,000+ clinics”
- “Supports Epic integration”
- “Available on iOS and Android”
- “SOC 2 Type II certified”
- “Built for multi-location retail”
Bunlar, birden fazla doğrulayıcı kaynakta yer aldığında AI sistemlerinin çok daha güvenli biçimde özetleyebildiği gerçeklerdir.
Query-attribute eşleşmesi
Modern keşif giderek daha fazla attribute odaklı hale geliyor.
Kullanıcılar artık yalnızca kategori liderlerini sormuyor. Şunları soruyorlar:
- 50 kişinin altındaki ekipler için en iyi araçlar
- offline mode sunan yazılımlar
- HIPAA compliance olan araçlar
- franchise işletmeler için platformlar
- çok dilli onboarding sunan uygulamalar
- saha satış ekiplerine uygun CRM’ler
Bu da şu anlama gelir: entity’nizin sadece kategori kapsaması değil, attribute kapsaması da olmalı. Bu attribute’lar PDF dokümanlarda, satış deck’lerinde ya da dağınık release note’larda saklıysa, yeterince retrieve edilemezsiniz.
Tutarsız entity temsiliyetinin gerçek maliyeti
Çoğu ekip bunun olumsuz etkisini olduğundan küçük görür çünkü yorumlama kalitesine değil organik trafiğe bakar.
Asıl maliyet daha az görünür şekillerde ortaya çıkar:
AI yanıt setlerine daha düşük dahil olma oranı
Kategori, segment ve use case bazında prompt’ları sistematik şekilde test etmiyorsanız, ne kadar sık dışarıda kaldığınızı fark etmeyebilirsiniz.
Bir marka sağlıklı search trafiğine sahip olabilir ama yüksek niyetli AI önerilerinin yalnızca küçük bir bölümünde yer alabilir.
Zayıf citation kalitesi
Adınız geçebilir ama doğru bağlamda geçmez.
Örnek:
- Siz “SMB finans ekipleri için expense management software” olarak alıntılanmak istiyorsunuz
- Model sizi “bir corporate card provider” olarak alıntılıyor
Bu, retrieval yüzeyini daraltır ve alıcı algısını değiştirir.
Kategori kayması
Dış kaynaklar sizi zaman içinde tutarsız tanımlıyorsa, AI sistemleri sizi yanlış pazara eşleyebilir.
Bu durum özellikle şunlardan sonra yaygındır:
- repositioning
- merger’lar
- ürün genişlemesi
- yeniden adlandırma
- upmarket’e geçiş
- eski footprint yeniden yazılmadan enterprise özelliklerinin eklenmesi
Kırılgan branded görünürlük
Entity katmanı zayıf olduğunda branded prompt’lar bile bozulabilir:
- “What does [Brand] do?”
- “Who are [Brand] competitors?”
- “Is [Brand] SOC 2 compliant?”
- “Does [Brand] integrate with HubSpot?”
Model temkinli, eksik veya güncelliğini yitirmiş ifadelerle yanıt veriyorsa, sorun çoğunlukla entity governance tarafındadır.
Neleri audit etmelisiniz?
Kısa cevap doğru: şirket açıklamaları, schema, dış profiller ve destekleyici sayfalar önemlidir.
Ama kapsamlı audit daha geniştir. Burada değerlendirmeniz gereken şey, pazarın tek bir şirketi net biçimde görüp görmediği ya da onun birden fazla tutarsız versiyonunu mu algıladığıdır.
1. Sahip olunan sayfalardaki şirket açıklamaları
Önce retrieve edilme veya referans gösterilme ihtimali en yüksek sayfalardan başlayın:
- ana sayfa
- about sayfası
- ürün overview sayfaları
- solutions / industry sayfaları
- pricing sayfası
- integrations sayfaları
- docs / help center
- careers sayfası
- press sayfası
- founder bio / leadership sayfaları
- uygunsa app store listelemeleri
Tutarlılığı şu başlıklarda kontrol edin:
- ana kategori
- hedef alıcı
- temel use case’ler
- farklılaştırıcı unsurlar
- kanıt iddiaları
- ürün isimlendirme kuralları
İyi uygulama nasıl görünür?
Bir şirket tek bir stabil cümleyle, genişletilmiş tek bir paragrafla ve tek bir attribute set’iyle tanımlanabilmelidir.
Örnek:
Tek cümlelik versiyon:
“Acme, mid-market çoklu entity finans ekipleri için accounts payable automation platformudur.”
Genişletilmiş versiyon:
“Acme, finans ekiplerinin invoice capture, approval workflow’ları, vendor management ve ERP reconciliation süreçlerini birden fazla entity genelinde otomatikleştirmesine yardımcı olur. Genellikle karmaşık AP operasyonlarına, dağıtık onay süreçlerine ve NetSuite veya Sage Intacct ortamlarına sahip şirketler tarafından kullanılır.”
Attribute set’i:
- kategori: AP automation
- hedef segment: mid-market
- buyer: controller / finance ops
- deployment: cloud
- entegrasyonlar: NetSuite, Sage Intacct, QuickBooks
- kanıt: 1.200+ finans ekibi, SOC 2 Type II
Aynı yapı, sadece sayfaya özgü nüanslar değişecek şekilde farklı sayfalarda tekrar etmelidir.
Yaygın hata kalıpları
- Ana sayfa kategori dili yerine marka sloganı kullanır
- Ürün sayfaları dış dünyadaki kategori terimleri yerine şirket içi feature isimleri kullanır
- About sayfası kuruluş hikâyesini tekrarlar ama pazar konumunu vermez
- Rebrand sonrasında docs eski ürün isimlerini kullanmaya devam eder
- Careers sayfası, daha açık ve sade copy içerdiği için kategori terimlerinde ürün sayfalarından iyi sıralama alır
- App store metadata’sı web deneyiminden farklı bir kategoriyi hedefler
2. Schema ve structured data sinyalleri
Schema tek başına authority yaratmaz. Ama belirsizliği azaltır.
B2B şirketlerde temel set genellikle şunları içerir:
- Organization
- WebSite
- BreadcrumbList
- Uygunsa Product veya SoftwareApplication
- İçerik gerçekten uygunsa FAQPage
- Editoryal içeriklerde Article / BlogPosting
- Uygun olduğunda kilit uzmanlar veya kurucular için Person
- Yalnızca geçerli ve search guideline’larına uygunsa Review / AggregateRating
Entity netliği için yüksek değerli schema alanları
| Schema type | Önceliklendirilecek alanlar | Neden önemli |
|---|---|---|
| Organization | name, alternateName, url, logo, sameAs, description, foundingDate, founders, areaServed | Kimliği ve dış profil eşleşmesini stabilize eder |
| Product / SoftwareApplication | name, applicationCategory, operatingSystem, offers, description, aggregateRating | Ürün türünü ve app/platform bağlamını netleştirir |
| WebSite | name, url, potentialAction | Site düzeyinde kimlik ve search anlayışını destekler |
| Article / BlogPosting | author, publisher, datePublished, dateModified, about, mentions | Topical context ve authorship sinyallerini güçlendirir |
| FAQPage | acceptedAnswer, mainEntity | Dikkatli kullanıldığında extract edilebilir tanımlar için faydalıdır |
Mobil ürünlerde bu konu doğal olarak ASO ile kesişir. App store metadata’sı ile software/application schema iki farklı ürünü anlatmamalıdır.
Teknik olarak neyi kontrol etmelisiniz?
- Her yerde aynı canonical organization description mı kullanılıyor?
- Product entity’leri, parent organization’dan doğru şekilde ayrılmış mı?
- “sameAs” referansları resmi ve güncel profillere mi gidiyor?
- Logo markup’ı güncel mi ve marka varlıklarıyla tutarlı mı?
- Software category alanları hedeflediğiniz pazar kategorisiyle uyumlu mu?
- Structured data açıklamaları jenerik boilerplate mi, gerçekten bilgi verici mi?
- Eski subdomain’ler, eski markalar veya satın alınmış varlıklar hâlâ çelişkili schema yayıyor mu?
3. Dış profiller ve publisher referansları
En büyük boşluklar genelde burada ortaya çıkar.
Entity’niz sizin söylediğiniz şey değildir. Web’in tekrar tekrar üzerinde uzlaştığı şeydir.
Retrieval ve trust’ı etkileyebilecek her kaynağı audit edin:
- Crunchbase
- LinkedIn şirket sayfası
- G2 / Capterra / TrustRadius
- GitHub org profili
- Apple App Store / Google Play
- Product Hunt
- CB Insights veya sektör veri tabanları
- Uygunsa ve kriterleri karşılıyorsa Wikipedia / Wikidata
- partner directory’leri
- integration marketplace’leri
- analist raporları
- review siteleri
- müşteri ekosistemi sayfaları
- podcast, etkinlik ve guest post’lardaki kurucu biyografileri
- PR kapsamı ve press release syndication
Neleri normalize etmelisiniz?
- şirket adı
- tagline / açıklama
- kategori etiketleri
- merkez ofis
- kuruluş yılı
- çalışan sayısı aralıkları
- website URL
- ürün adları
- müşteri segmenti iddiaları
- sertifikasyon ve compliance iddiaları
Pratik bir örnek
Dental practice’lere yönelik bir vertical SaaS şirketi düşünün.
Web genelinde şu şekilde tanımlanıyor olsun:
- “practice management software”
- “patient communication app”
- “dental CRM”
- “appointment reminder platform”
- “revenue cycle software”
Bunların hepsi doğru olabilir. Ancak şirket dental practice management software etrafındaki prompt’larda kazanmak istiyorsa, bu kategori dış profil katmanında baskın olmalıdır. Destekleyici fonksiyonlar, rakip kimlikler olarak değil attribute olarak konumlanmalıdır.
4. Kategori sorularını yanıtlayan destekleyici sayfalar
Entity SEO ile topical coverage’ın birleştiği nokta tam da burasıdır.
Bir marka, yalnızca bir kategoriye ait olduğunu iddia ettiğinde değil, o kategorinin çevresindeki pazarı da açıkladığında daha kolay retrieve edilir.
Bu da şu soruları net biçimde yanıtlayan sayfalar oluşturmak demektir:
- kategori nedir
- kimler içindir
- nasıl çalışır
- komşu kategorilerden farkı nedir
- segment bazında hangi özellikler kritiktir
- alıcılar seçenekleri nasıl karşılaştırır
- ne zaman point solution yeterlidir, ne zaman platform gerekir
- implementasyon nasıl görünür
- hangi entegrasyonlar, compliance gereksinimleri veya workflow’lar kritiktir
Bu sayfalar aynı anda iki iş yapar:
- Kategori soruları için retrieval fırsatları yaratır.
- Entity’nizin o kategori ve ana attribute’larla ilişkisini güçlendirir.
Bu yüzden güçlü SEO programları, yapılan işe “GEO” etiketi yapıştırılmasa bile GEO performansını sıklıkla iyileştirir.
Entity audit framework’ü
Audit’i yürütmenin kullanışlı bir yolu, markayı beş boyutta puanlamaktır.
Boyut 1: Kimlik tutarlılığı
Sorular:
- Şirket adı tutarlı kullanılıyor mu?
- Eski marka kalıntıları var mı?
- Ürün adları parent brand’e net bağlanıyor mu?
- Domain ve subdomain kuralları temiz mi?
Şu durumlarda düşük puan verin:
- yakın dönem rebrand sonrası eski açıklamalar yayında kaldıysa
- satın alınan ürünlerde çelişkili terminoloji varsa
- parent brand ile product brand mimarisi net değilse
Boyut 2: Kategori netliği
Sorular:
- Dışarıdan biri 5 saniye içinde hangi pazarda olduğunuzu anlayabiliyor mu?
- Tek bir baskın kategori var mı?
- Komşu kategoriler bilinçli biçimde çerçevelenmiş mi?
Şu durumlarda düşük puan verin:
- headline copy yaratıcı ama açıklayıcı değilse
- her sayfa yeni bir kategori etiketi sunuyorsa
- review siteleri sizi kendi sitenizden farklı sınıflandırıyorsa
Boyut 3: Attribute bütünlüğü
Sorular:
- Kritik buyer filtreleri açıkça belirtilmiş mi?
- Segment, use case, sektör, entegrasyonlar, güvenlik, platform desteği ve deployment modeli net şekilde ifade ediliyor mu?
Şu durumlarda düşük puan verin:
- önemli nitelikler docs içine gömülüyse
- product marketing spesifik detaylardan kaçınıyorsa
- use-case kapsamı geniş ama yüzeyselse
Boyut 4: Kanıt yoğunluğu
Sorular:
- İddialar case study, review, sertifikasyon, araştırma veya publisher referanslarıyla destekleniyor mu?
- Bu kanıtlar yüksek otoriteli sayfalarda görünür mü?
Şu durumlarda düşük puan verin:
- iddialar desteklenmiyorsa
- müşteri hikâyelerinde somut sonuç yoksa
- üçüncü taraf referansları seyrek veya eskiyse
Boyut 5: Extractability
Sorular:
- Bir makine en önemli gerçekleri kolayca çıkarabiliyor mu?
- Tanımlar, karşılaştırmalar ve özellik açıklamaları net yazılmış mı?
- Önemli yanıtlar görsellerin, sekmelerin veya gated PDF’lerin içinde mi sıkışmış?
Şu durumlarda düşük puan verin:
- sayfalar görsel olarak güçlü ama semantik olarak zayıfsa
- içerik jargon ve sloganlara fazla dayanıyorsa
- taranabilir tablolar, FAQ’lar veya kısa tanımlar yoksa
Basit bir scorecard yardımcı olur:
| Boyut | Puan 1-5 | Notlar | Öncelik |
|---|---|---|---|
| Kimlik tutarlılığı | |||
| Kategori netliği | |||
| Attribute bütünlüğü | |||
| Kanıt yoğunluğu | |||
| Extractability |
Entity katmanı nasıl düzeltilir?
Çoğu ekibin altı aylık teorik bir çalışmaya ihtiyacı yoktur. İhtiyaç duydukları şey bir operating model’dir.
Adım 1: Canonical entity anlatısını tanımlayın
Tek bir source-of-truth dokümanı oluşturun. Net olduğu sürece tek sayfa yeterlidir.
Şunları içermelidir:
- resmi şirket adı
- tercih edilen marka adı
- kısa açıklama
- orta uzunlukta açıklama
- uzun açıklama
- ana kategori
- ikincil kategoriler
- kaçınılması gereken kategori dışı descriptor’lar
- ürün adları ve hiyerarşi
- buyer persona’lar / job title’lar
- temel use case’ler
- hedef sektörler
- ana entegrasyonlar
- proof point’ler
- compliance ve sertifikasyonlar
- resmi URL’ler ve sosyal profiller
- PR ve iş ortaklıkları için onaylı şirket boilerplate’i
Bu doküman version control altında olmalıdır. Bunu marka gösterisi gibi değil, ürün dokümantasyonu gibi ele alın.
Adım 2: En yüksek otoriteli owned surface’leri standardize edin
Entity anlayışını en çok etkileyebilecek sayfaları güncelleyin:
- ana sayfa
- about sayfası
- ürün overview sayfası
- en önemli industry sayfaları
- en önemli integration sayfaları
- docs ana sayfası
- pricing sayfası
- app store listelemeleri
- structured data katmanı
Buradaki amaç tüm sayfaları aynı yapmak değildir. Birbirlerini güçlendiren bir yapı kurmaktır.
Adım 3: Dış referansları temizleyin
Bu iş genelde gösterişsizdir ama ROI’si yüksektir.
Önce kontrol ettiğiniz profilleri güncelleyin:
- Crunchbase
- G2 / Capterra / TrustRadius
- Product Hunt
- app store açıklamaları
- partner marketplace listelemeleri
- sosyal bio’lar
- founder bio’ları
Ardından düzenlenmesi mümkün üçüncü taraf sayfaları önceliklendirin:
- partner sayfaları
- etkinlik konuşmacı sayfaları
- podcast açıklamaları
- guest post author bio’ları
- eski ajans case study’leri
- affiliate / reseller sayfaları
Adım 4: Kategoriyi destekleyen içerik üretin
En hızlı kazanımlar genelde markanızı buyer dili ve retrieval attribute’larıyla bağlayan sayfalardan gelir.
Örnekler:
- “What is cloud cost optimization?”
- “ERP integration requirements for AP automation”
- “Best field service software for HVAC companies”
- “MDM vs EMM vs UEM for healthcare devices”
- “How to evaluate call center QA tools for BPO teams”
Bu sayfalar boş thought leadership metinleri olmamalıdır. Net tanımlar, karşılaştırmalar ve implementasyon detayları içeren decision-support içerikleri olmalıdır.
Adım 5: Modellerin alıntılayabileceği kanıt ekleyin
Görünür kanıtla desteklenmeyen iddialar zayıftır.
Şunlara öncelik verin:
- sayısal veriler içeren case study’ler
- adı belirtilen roller ve şirket tipleriyle müşteri yorumları
- benchmark verileri
- implementation guide’lar
- sertifikasyon sayfaları
- integration dokümantasyonu
- belirsiz üstünlük iddiaları yerine olgulara dayalı comparison sayfaları
- gerçek uzmanlık bilgilerine sahip yazarlar tarafından hazırlanmış içerikler
Kanıtınız varsa, bunu extract edilebilir formatta yayınlayın. Tablolar, kısa yanıt blokları ve net etiketlenmiş bölümler bu konuda yardımcı olur.
Adım 6: AI temsilini doğrudan izleyin
Sıralamalar hareket etti diye iyileştirmelerin çalıştığını varsaymayın.
Markanızın şu ortamlarda nasıl göründüğünü takip edin:
- ChatGPT
- Perplexity
- Gemini
- Claude
- mevcutsa Google AI Overviews
Şu alanlarda prompt set’leri kullanın:
- branded sorular
- kategori soruları
- rakip karşılaştırma prompt’ları
- use-case prompt’ları
- attribute filtreli prompt’lar
- “best tools for X” prompt’ları
Şunları dokümante edin:
- inclusion rate
- kullanılan kategori etiketi
- bahsedilen attribute’lar
- görünen citation’lar
- factual error’lar
- competitor set içindeki konum
Güçlü bir entity mimarisi nasıl görünür?
Olgun bir şirket genelde marka, ürün ve içerik ilişkileri için açık bir mimariye ihtiyaç duyar.
Parent brand ve product entity ayrımı
B2B’de yaygın sorunlardan biri şudur: şirket ve ürün, ayrılması gerekirken birbirinin yerine kullanılır.
Örneğin:
- Şirket: “Acme, Inc.”
- Ürün paketi: “Acme Revenue Cloud”
- Modüller: “Forecasting,” “Conversation Intelligence,” “Deal Inspection”
Tüm sayfalar “Acme” adını gevşek biçimde kullanıyorsa, model organizasyonu software suite’ten veya modül adlarından ayırmakta zorlanabilir.
Daha iyi bir yapı şudur:
- organization page şirketi tanımlar
- product hub suite’i tanımlar
- ayrı product page’ler modül bazlı fonksiyonları tanımlar
- schema bu hiyerarşiyi yansıtır
- internal linking parent-child ilişkilerini güçlendirir
Kategori hiyerarşisi
Kategori hiyerarşisini de açık biçimde tanımlamalısınız.
Bir siber güvenlik şirketi için örnek:
- ana kategori: cloud security posture management
- komşu kategoriler: CNAPP, CSPM, cloud compliance
- use-case attribute’ları: AWS, Azure, Kubernetes, misconfiguration detection
- segment attribute’ları: enterprise, regulated industries, DevSecOps teams
Bu yapı, kimliğinizi parçalamadan hem geniş hem de attribute-spesifik prompt’ları hedeflemenizi sağlar.
Sektör ve use-case eşlemesi
Gelişmiş retrieval çoğu zaman kategori ile bağlamın kesişiminde gerçekleşir.
Örnekler:
- “expense management software for nonprofits”
- “CRM for independent insurance agencies”
- “fleet maintenance software for municipalities”
- “translation management platform for e-commerce brands”
Entity katmanınız, bu kombinasyonları özel sayfalar ve tekrar eden terminolojiyle desteklemelidir.
Yaygın failure mode’lar
GEO programlarının çoğu tam burada tıkanır.
Temizlik yapmadan repositioning
Bir şirket “tool”dan “platform”a, SMB’den enterprise’a ya da bir kategoriden diğerine geçer. Ana sayfa değişir. Geri kalan her şey eski kalır.
Sonuç:
- karışık dış referanslar
- eski review site kategorileri
- yeni mesajların önüne geçen eski blog yazıları
- önceki konumlandırmayı alıntılayan AI yanıtları
Aşırı branding, yetersiz açıklama
Product marketing ekipleri proprietary language’i sever:
- “Revenue engine”
- “Customer intelligence cloud”
- “Unified engagement layer”
Bu dil sitede yaşayabilir. Ama kategori netliğinin yerini alamaz.
Bir makine kullandığınız dili bilinen bir pazar kategorisine eşleyemiyorsa, discoverability düşer.
Parçalı ürün isimlendirmesi
Birden çok ürünü olan şirketler çoğu zaman içeride şık ama dışarıdan kaotik görünen isimlendirme sistemleri kurar.
Örnekler:
- suite adı iki kez değişti
- modüller soyut isimler kullanıyor
- docs kısaltmalar kullanıyor
- sales deck’leri dikeyleşmiş isimler kullanıyor
- app listelemeleri migration’da rating’ler sıfırlanmasın diye eski ürün adlarını koruyor
Bu durum entity sprawl yaratır.
Desteklenmeyen farklılaşma iddiaları
“En doğru”, “lider”, “en iyi” veya “AI-powered” gibi ifadeler, kanıtla desteklenmediği sürece fazla işe yaramaz.
Modeller şu tip ifadeleri tekrar etmeye daha yatkındır:
- “supports X integration”
- “used by Y customer type”
- “offers Z deployment mode”
- “certified for A standard”
genel marketing süperlatiflerinden ziyade.
Zayıf üçüncü taraf doğrulaması
Tüm güçlü iddialar yalnızca owned media üzerinde yer alıyorsa, entity güveni sınırlı kalır.
Anlatının en azından bir kısmını doğrulayan dış yüzeylere ihtiyacınız vardır:
- yorumlar
- analistler
- müşteri referansları
- partner listelemeleri
- implementation partner’ları
- bağımsız karşılaştırmalar
- sektör yayınları
Sahada görülen entity karışıklığı örnekleri
Birkaç gerçekçi senaryo bunu iyi anlatır.
Örnek 1: Kategorileri çakışan bir fintech
Bir şirket şunları sunuyor:
- corporate card’lar
- spend management
- AP automation
- procurement workflow’ları
Ana sayfasında “finance operations platform” yazıyor. Review siteleri onu expense management ve procurement arasında bölüyor. Gazeteciler ise fintech card startup’ı olarak tanımlıyor.
“best AP automation tools for mid-market finance teams” prompt’unda bu marka dışarıda kalıyor çünkü AP ile ilişkisi, dedicated AP vendor’lara kıyasla zayıf temsil ediliyor.
Çözüm:
Product page’ler, integrations, implementation içerikleri, case study’ler, dış profiller ve doğrulayıcı referanslar üzerinden daha güçlü AP entity ilişkileri kurun.
Örnek 2: Belirsiz marka adına sahip developer tool
“Branch” adlı bir startup feature flagging software satıyor. Search ve AI sistemleri başka markalarla, common noun’la ve alakasız developer tool’larla karşılaşıyor.
Branded prompt’lar eksik yanıtlar üretiyor. Kategori prompt’larında şirket neredeyse hiç görünmüyor.
Çözüm:
Organization markup’ını sıkılaştırın, “Branch feature flagging platform” birlikte-geçişini güçlendirin, dış bio’ları güncelleyin, tanımlayıcı kategori içeriği oluşturun ve tam, ayırt edici ifade kullanan üçüncü taraf referanslar elde edin.
Örnek 3: Web ve app kimliği bölünmüş mobile SaaS
Bir B2B mobile app’in web sitesi “field service management software” hedefliyor. App store’lar ise “job scheduling app” vurgusu yapıyor. Review’larda route optimization ve technician tracking öne çıkıyor. AI araçları da ürünü daha geniş FSM değerlendirmelerinde değil, yalnızca scheduling bağlamında öneriyor.
Çözüm:
Entity’nin hem geniş kategori hem de temel attribute’larda sıralama alabilmesi için app metadata’sını, website category language’ini, software schema’yı ve destekleyici içeriği hizalayın.
İşte tam bu noktada koordineli ASO ve GEO çalışması ekiplerin beklediğinden daha önemli hale gelir.
Entity SEO’nun GEO’yu iyileştirip iyileştirmediğini gerçekten gösteren metrikler
Trafik çok kaba bir metriktir. Sıralamalar eksik kalır. Temsil metriklerine ihtiyacınız vardır.
Temsil metrikleri
Şunları takip edin:
- branded answer accuracy rate
- branded answer completeness rate
- doğru ana kategorinin kullanıldığı prompt oranı
- ilk 3 farklılaştırıcının göründüğü prompt oranı
- AI sistemleri genelinde factual error rate
- owned kaynaklara karşı üçüncü taraf kaynaklardan citation sıklığı
Basit bir puanlama modeli iş görür:
- 0 = yok
- 1 = yanlış şekilde bahsedilmiş
- 2 = kısmen bahsedilmiş
- 3 = doğru şekilde bahsedilmiş
- 4 = güçlü kanıtla doğru temsil edilmiş
Inclusion metrikleri
Prompt library’ler oluşturun ve aylık test edin:
- kategori prompt’ları
- alternatives prompt’ları
- buyer segment prompt’ları
- industry prompt’ları
- integration prompt’ları
- compliance prompt’ları
- “best for” prompt’ları
Ölçün:
- inclusion rate
- öneri setlerindeki ortalama sıra / konum
- citation sayısı
- competitor overlap
Search destek metrikleri
Entity çalışması geleneksel search sinyallerini de iyileştirmelidir:
- branded CTR
- kategori + attribute sorgularında non-branded impression’lar
- knowledge panel veya brand SERP tutarlılığı
- tanımlayıcı sayfalarda featured snippet kazanımı
- tutarlı açıklayıcı anchor text kullanan referring domain sayısındaki artış
İçerik extractability metrikleri
Destekleyici sayfalarda şunları izleyin:
- snippet capture
- AI citation frequency
- Ahrefs, Semrush ve Google Search Console pattern’ları gibi araçlarda passage-level retrieval görünürlüğü
- decision-support sayfalarındaki etkileşim
- organik trafikten docs sayfası giriş oranları
Operasyonel metrikler
Sadece sonucu değil, sistemi de ölçün:
- canonical narrative’e göre güncellenen öncelikli owned page yüzdesi
- hizalanmış kontrol edilebilir dış profil yüzdesi
- tamamlanmış ve valide edilmiş schema coverage yüzdesi
- sayısal sonuç içeren case study sayısı
- yayımlanan kategori/use-case sayfalarının sayısı
Önerilen araçlar
Hiçbir araç entity SEO’yu tek başına kusursuz yönetmez. Bir stack kullanın.
İçerik ve SERP analizi için
- Ahrefs: query cluster’ları, rakip sayfalar, link bağlamı, brand mention keşfi
- Semrush: topic coverage, görünürlük trendleri ve rakip karşılaştırmaları
- Google Search Console: query phrasing, sayfa bazlı impression değişimleri, branded CTR
- AlsoAsked / AnswerThePublic / Glimpse: kategori ve attribute soru pattern’ları
Structured data ve teknik doğrulama için
- Google Rich Results Test
- Schema Markup Validator
- Screaming Frog: schema alanları ve açıklama tutarlılığı için custom extraction ile
- Sitebulb: ölçekli içerik ve teknik audit için
Dış profil yönetimi için
- kontrol edilen profiller için manuel spreadsheet audit’i
- Ahrefs Alerts, Google Alerts veya Mention ile brand mention izleme
- mümkün olan yerlerde review platform export’ları
AI görünürlük takibi için
Bu kategori hâlâ olgunlaşma aşamasında ama şu yaklaşımlar faydalı:
- spreadsheet veya iç dashboard’larda prompt library’leri
- büyük AI sistemleri genelinde versiyonlanmış aylık testler
- mevcutsa AI brand monitoring platform’ları
- Perplexity ve search-entegre sistemlerde retrieval/citation log’lama
- answer quality için yapılandırılmış insan değerlendirmesi
Buradaki anahtar tutarlılıktır. Tek seferlik prompt kontrolleri sahte bir güven üretir.
Pratik bir 90 günlük uygulama planı
B2B markaların çoğu bir çeyrek içinde anlamlı ilerleme kaydedebilir.
Gün 1-15: Audit ve anlatının tanımlanması
- en önemli owned page’leri envanterleyin
- kontrol edilebilir dış profilleri envanterleyin
- mevcut şirket açıklamalarını toplayın
- kategori varyansını ve eski iddiaları tespit edin
- canonical entity anlatısını tanımlayın
- ana ve ikincil kategorileri haritalayın
- temel attribute ve proof point’leri listeleyin
Teslimat:
- entity source-of-truth dokümanı
- boşluklar ve önceliklerle birlikte audit spreadsheet’i
Gün 16-30: Yüksek öncelikli düzeltmeler
- ana sayfa, about ve product overview copy’sini yeniden yazın
- kritik structured data’yı güncelleyin
- app store ve marketplace açıklamalarını hizalayın
- LinkedIn, Crunchbase ve büyük review profillerini düzeltin
- founder ve company boilerplate’lerini güncelleyin
Teslimat:
- en önemli kontrol edilen yüzeylerde hizalanmış kimlik katmanı
Gün 31-60: Destekleyici içerik ve kanıt
- kategori tanım sayfaları yayınlayın veya yenileyin
- comparison ve use-case sayfaları yayınlayın
- uygunsa integration ve compliance detayları ekleyin
- muğlak müşteri hikâyelerini sayısal case study’lere dönüştürün
- extractability zayıfsa FAQ ve glossary bölümleri oluşturun
Teslimat:
- retrieval ve answerability’yi güçlendiren kategori destek katmanı
Gün 61-90: Ölçüm ve genişleme
- prompt library’yi büyük AI sistemlerinde test edin
- inclusion, kategori doğruluğu ve citation’ları kaydedin
- eksik üçüncü taraf doğrulamalarını belirleyin
- partner/profile/publisher güncellemelerini takip edin
- segment ve sektör bazlı sayfalara genişleyin
Teslimat:
- baseline GEO entity scorecard’ı
- bir sonraki çeyrek için önceliklendirilmiş roadmap
Bu çalışmanın ölçülebilir görünürlük artışına nasıl dönüştüğüne dair bir model görmek istiyorsanız, genel geçer best-practice listeleri yerine gerçek vaka analizlerini incelemek daha faydalıdır.
Ekibinizin yeterince çalışıp çalışmadığını nasıl anlarsınız?
Yönetici seviyesinde doğru soru “GEO yapıyor muyuz?” değildir.
Doğru soru şudur:
Bir makine, kamuya açık kanıtları kullanarak, alıcının şirketimiz hakkında sorduğu en önemli on soruyu doğru biçimde yanıtlayabiliyor mu?
Bu sorular genellikle şunları içerir:
- hangi kategorideyiz?
- kimler için varız?
- hangi problemleri çözüyoruz?
- bizi farklı kılan nedir?
- hangi entegrasyonları destekliyoruz?
- hangi sektörlere hizmet veriyoruz?
- hangi kanıtlar mevcut?
- alternatiflerimiz kimler?
- hangi ölçekte kullanılmak üzere tasarlandık?
- hangi compliance veya platform gereksinimlerini karşılıyoruz?
Bu yanıtlar AI sistemleri arasında tutarsızsa, entity katmanınız yeterince olgun değildir.
Asıl temel sorun budur. Prompt değil. Model değil. Soyut bir “AI discoverability” gizemi hiç değil.
Bir markayı anlamak kolaylaştığında, onu önermek de kolaylaşır.
Ve bu genellikle disiplinli, bazen sıkıcı ama etkisi yüksek işlerle başlar: açıklamaları netleştirmek, schema’yı temizlemek, dış profilleri hizalamak, kategoriyi destekleyen sayfalar yayınlamak ve kanıtı extract edilebilir hale getirmek. Bu temel dengesizse, ne kadar içerik üretirseniz üretin GEO kırılgan kalır. Entity katmanınızı stres test etmek ve search ile AI yüzeylerinde bileşik etki yaratan bir program kurmak istiyorsanız, bir görüşme planlayın.

