Entity-Based Search Nedir? Keyword Tabanlı Arama Motorlarından Entity Temelli Yaşam Rehberlerine Geçiş Süreci ve Entity-Optimised Content Üretimi

Entity’ler, 2018 itibari ile sıklıkla Search Community tarafından konuşuldu. 2019’da ise tüm Search Engine Teorilerinin ana gündemi haline geldi. Aynı dönemde Google, dil algoritmasını değiştirdi, kendi domaininden local domain uzantılarını kaldırdı, sesli aramalara (eye-free search) ve milyonlarca değişkeni bulunan yapay zeka programlarına ağırlık verdi, internete bağlanabilen her cihaza yerleşerek (ambient computing) kendisini bir yaşam zorunluluğu haline getirmenin ilk aşamasını gerçekleştirdi. Peki, Entity’ler Google’ın bir arama motorundan, kişisel yaşam rehberi haline gelişinde hangi noktada devreye girdi? Entity-based Search’ü, Keyword-based Search’ten ayıran temel farklar nedir?

Ben Koray Tuğberk GÜBÜR, her zaman Holistic SEO Expertise’ın yarattığı farka inandım.  Makalenin temel konusunu anlamak için Search Engine Theories hakkında bilgi sahibi olunması gerektiği için bu kounda da ihtiyaç duyacağınız bilgileri Guideline içine yerleştirdim. Academic ve Holistic bir Search Engine kaynağının bulunması amacıyla bu içeriği yazarken oldukça haz aldım. Read-o-Meter’a göre makalenin toplam okunma süresi 63 Dakika 45 saniyedir. Toplamda 63 alt başlıktan oluşan Complete, Comprehensive, Entity-based Content Optimization Guideline’ı okuduğunuzda, Search Engine Building hakkında da bazı fikirleriniz olacak.

Geleneksel SEO’yu ve ‘Write Great Content’, ‘Keyword intent daha önemli olacak’ gibi tek değişkenli yapay zeka cümlelerini bir kenara bırakmaya hazırsanız, Holistic SEO’nun bilimsel, bütüncül ve pratikle teoriyi birleştiren vizyonuyla, geçmişten bugüne, entity’lerin yolculuğuna birlikte eşlik edebiliriz.

Devam etmeden önce aşağıdaki soruları okuyarak, kaçını düzgünce yanıtlandırabileceğinizi test etmeniz, konunun özet haline olan hakimiyetinizi değerlendirmenizi sağlayacaktır.

1- Bir entity’i bir keyword’den ayıran temel özellikler nedir?

2- Google, entity extraction patentlerinin ortak özelliği nedir?

3- Google’ın Entity-based Search’e geçerken temel amacı nedir?

4- Entity’lerin varlığından ve Google’ın amacının Entity-based Web Data-base oluşturmak olduğundan ilk kim ne zaman bahsetti?

5- İçeriklerinizi bir entity’e göre nasıl optimize edebilirsiniz?

6- Entity’ler arasındaki Confidence Score’lar nedir?

7- Google’ın Natural Language Processor’u nasıl çalışmaktadır?

8- Entity’ler arasındaki ilişkiyi Google nasıl anlamaktadır?

9- Entity’ler ve Structured Data arasındaki ilişki nedir?

10- Firmanızın bir entity olup olmadığını nasıl anlayabilirsiniz?

11- Google, sadece yazılardan mı entity extraction gerçekleştirebilir? Ses ve Görüntü, entity içerebilir mi?

12- Brand-Entity ve Entity-Query Matching kavramları nedir?

13- Brand-Entity’nin belirli kategorilerde iyileştirilmesi için Entity Association Score Nasıl Kullanılabilir?

14- Natural Language Processor’e göre en uyumlu içerik nasıl yazılabilir?

15- X’in Search Term ve Entity hali a arasındaki fark nedir?

16- Phrase-based Search Engine yapısı, Entity-based Search Engine’e destek olabilir mi?

17- Semantic Image Search, Object ve Attribute Entity’ler Nedir?

18- Local Search Entity Classification, Web Search’ü nasıl etkilemektedir?

19- Link Clustering ve Entity Clustering arasındaki bağlantı nedir?

20- Concept-based Indexing ve Disambiguation Effect (Belirsizlik Etkisi) nedir?

21- Entity-based Content Optimization için Belirsizlik Etkisi nasıl azaltılabilir?

22- Google Translate API için kullanılan dil algoritmaları ve Google’ın İçerik Algısı ne derecede paraleldir?

23- Topical Layer ve Topical Authority Nedir? Nasıl oluşturulur?

24- CID Number nedir? Nasıl bulunur? 

25- Google’a göre kaç tür content kategorisi vardır? Google NLP API, Content Categorization’ı neye göre yapmaktadır.

26- Google, bir konunun E-A-T gereklilik düzeyini neye göre belirlemektedir?

27- Google, Sosyal Medyayı bir Entity’i daha iyi tanımak için nasıl kullanmaktadır?

28- Google, ilk kez gördüğü bir WebPage’in hangi Entity’i hangi otoritede/kapsamda anlattığına ve hangi Query’lerin ihtiyacını karşıladığına nasıl karar vermektedir?

29- Ambient Computing ve Entity-based Search arasındaki ilişki nedir?

30- Google, Duygu Analizini nasıl yapmakta ve bir Brand-Entity’nin Sentiment Profilini nasıl çıkarmaktadır?

31- Domain-based SEO yerine Brand-Entity Based SEO’nun doğuşu neden Holistic SEO’yu zorunlu kılmıştır?

32- Bir Search Term ve Search Topic arasındaki temel fark nedir? Entity-based Content Optimization sürecinde hangisini hangi durumda hedeflemek gerekmektedir?

Google ve Entity’ler Hakkında İlk Konuşmalar, Değişimi Haber Verenler

Google’ın Entity Recognition temalı patentlerini aldığı ilk yıl 2007 yılıydı. Şaşırılmaması gereken biçimde Google’ın bundan 13 yıl önce, Entity-based Search hayalinden ilk bahseden kişi de Bill Slawski’ydi.. (Ben 2010’a kadar geriye doğru scrape ederek gitmiş olsam da.)

Makalenin başlangıcında, Bill Slawski, Cindy Krum ve Mordy Oberstein’a teşekkürlerimi sunarım.

2020 yılına gelinirken, Google, keywordleri farklı entity’ler ile birleştirmektedir. Yani bu süreç hala devam etmektedir. Özellikle Amerikan İngilizcesi için daha büyük ölçüde tamamlanmış olan bu süreç, PPA yani People Also Ask For bölümünde, SERP içinde daha fazla entity-based sonuçların verilmesini sağlamaktadır. Ancak bu, aşağıda görebileceğiniz gibi aynı zamanda bazı hatalara da neden olmaktadır.

Diğer bir deyiş ile entity-query matching’in localleştirilmesi ve SERP Map içine doğru bir kullanıcı algısıyla yerleştirilmesi daha da vakit alacaktır. Aşağıda bir başka örnek daha bulabilirsiniz.

Durum bununla da bitmemekte… Local Search sorgularında yakın zaman içinde bazı ülkelerde, hava durumu gösterilmeye başlandı. Havanın güneşli ya da yağmurlu olmasına göreyse ‘X şehrinde gezilecek yerler’ sorgusu değişiklik göstermektedir. Yani, yağmurlu havada kapalı mekanlar, güneşli havalarda ise açık alanlar üste çıkmaktadır. Peki, Google hava durumuna göre gitmek isteyeceğiniz/isteyebileceğiniz yeri nasıl anlamaktadır? Bütün bu veriyi nasıl toplamakta ve aradığınızı değil aramak isteyebileceğinizi size göstermektedir?

İşte bu noktada, yeniden Google Patentlerine, tam 13 yıl önceye giderek bugünleri haber verenleri anlamak gerekli!

Google için Related-Entity’lerin Hangi Sorgu ile Eşleştiğini Nasıl Anlayabilirsiniz?

Yukarıdaki şema, Google’ın Entity Relations hakkında aldığı ilk patentlerden birisine aittir. Bu noktada, birbiriyle ilgili entity’lerin ilgi yönünü hesaplayarak, hangi türdeki sorgulara yanıt vermesi gerektiği düşünülmektedir.  Buna göre izlenecek adımlar şu yöndedir:

1. Kullanıcının cihazından ilgili sorguyu al.
2. Search Engine Index’inden ilgili entity’leri edin.
3. Entity’ler arasından ‘odak’ entity’i bul.
4. Odak Entity ve Diğer Entity’ler arasındaki ilişkileri çıkart.
5. Sorgudaki ikincil entity isteğine göre aradaki ilişkiyi yanıt olarak veren Web Page’leri sıralamada yükselt/içer.

Bu formülü kısa bir örnek ile gözümüzde canlandıralım.

Sorgu -> “Türkiye Cumhuriyeti Devleti’ni kim kurmuştur?”

Named Entity Recognition süreci bu noktada başlamaktadır. ‘Türkiye Cumhuriyeti Devleti’ burada farklı yazım türleri bulunabilecek bir entity’dir. Entity olarak seçilen örnek bir ‘State’tir’. Her State Entity’si, eğer sorgudaki ‘odak’ ise onu niteleyen alt entity’lere sahiptir. Örneğin, bir ‘founder’, ‘president’, ‘regime’, ‘energy policy’ ve diğerleri… Sorgudaki ikinci yani ‘ilgili entity’ ise ‘founder’ ile eşleşmektedir.

Google, ‘Information Extraction from a Database’ adlı patentinde buna benzer bir duruma değinerek, internetteki belirgin sözcük ve bilgi örneklemlerinin dizilimlerine işaret etmektedir. Buna göre, aynı dizilimler, aynı bilgiyi veya aynı tipteki bilgiyi sunmaktadır. Bu bağlamda, Google, Türkiye Cumhuriyeti Devleti’nin kurucusu kendi databesi’nde onu bir ‘Search Term’ olmaktan öteye bir Entity olarak addetmeye yetecek veriye sahiptir. 

Google’ın ‘Veri Doğrulama ve Çıkartma’ patentinin bir bölümündendir.

Girilen sorguya göre, Google, Mustafa Kemal Atatürk ve Türkiye biçimindeki iki ayrı entity arasındaki olası ilişkiyi çıkartarak, doğrudan bir ilişki görmekte ve girilen ‘Kurucusu Kimdir’ sorgusundan yola çıkarak olası yanıtı ya kendisi Knowledge Graph ile veya doğrudan bir biçimde Featured Snippet’ler ile vermektedir. Eğer yeterli Confidence Score ve ‘anlaşılırlık’ yok ise normal bir web page ile de yanıt verebilmektedir.

Bir diğer örneği ise yukarıda görmektesiniz. Michelle Obama’nın kocası kimdir, dediğimizde, Principal veya Odak Entity olan Michelle Obama’nın ‘Husband’ attribute’ünü görmektesiniz. Ayrıca, güzel bir farklı örnek olarak da Barack Obama için de ‘Daughter’ gibi farklı attribüte’leri diğer ‘Related Entities’ ile birlikte görmektesiniz.

Bir diğer örnek olarak ise Google’ın ‘Related Entities’ patentinden örnek bir şema görmektesiniz.  Bu örnekte ise Roald Dahl adındaki bir yazarın, alt entity’lerini yani attribüte’lerini ilgili biçimde görmektesiniz. Tabii ki bu noktada, hem Patentte hem de gerçek örnekte, ‘Wikipedia’ örneğinin var olması tesadüf değildir.

Örneğin, buradaki verilerin tamamı, Wikipedia’dan alınmıştır.

Bunu İçerikbulutu’nda düzenlediğim YMYL Siteleri İçin Core Güncellemeleri ve SEO Stratejisi webinar’ında da iletmiştim. Wikipedia, Google çalışanlarını etkileyen bir entity ve içerik ağına sahiptir, bu nedenle John Mueller başta olmak üzere her Googler büyük bir ilgi ile incelemekte hatta John Mueller, Wikipedia API için bir Python scripti yazmış ve yer yer de bu scripti kullanarak elde ettiği ‘link-based’ ve ‘content-based’ trend etkilerini paylaşmaktadır. Knowledge Graph ekibi ise düzenli biçimde, Wikipedia’yı tarayarak kendi veri tabanlarını Wikipedia’dan bağımsız bir hale getirmektedir.

Barrack Obama’nın Knowledge Panelini sahiplenmek istediğinizde ise Google, onunla ilgili olabilecek Sosyal Ağ ve Web Entity’lerini size sıralamakta ve sahiplenmenizi istemektedir. Bu noktada, Confidence Score’un iki ayrı Facebook sayfası arasında kararsız kaldığını söyleyebiliriz. Çünkü, her iki facebook hesabı da ‘Business Account’ olup, bunlardan İspanyolca olanı da Google tarafından eşit derecede tanınmış durumdadır. Ayrıca, söz konusu sayfanın Title’ı ise şudur:
→ Yeterince açık değil mi?

Diğer bir deyiş ile Sosyal Medya, Entity Recognition için bir etkendir. Sosyal Medya, Entity-Relation için bir etkendir. Sosyal Medya, Entity-Query Matching için bir etkendir.

Şu ana kadar anlattıklarımızın daha büyük bir delilini yukarıdaki şemada da görebilirsiniz.

‘Sufficient Number of Resources identified by the search results are authoritative resources for a particular entity?’ — > ‘Classify the search query as being directed to the particular entity’

Bölümü, doğruca bir özettir. (Bir Entity için yeterince sayıda güvenilir ve belirgin bilgiye sahip kaynak var mı? → Var ise ilgili sorguları doğruca belirli yönleri ile o entity’ye ve attribüte’lerine bağla)

Search Term ve Entity Arasındaki Fark Nedir? İkisi Arasındaki Farkı Nasıl Anlayabilirsiniz?

Search term olarak Mustafa Kemal Atatürk ve entity olarak Mustafa Kemal Atatürk arasındaki fark nedir? Bir şeyin Search Term mü yoksa Entity olarak mı arandığı nasıl ayırt edilir? Sonuç sayfaları bundan nasıl etkilenir? Hiç SERP’ü incelerken bu duruma dikkat ettiniz mi?

Herhangi bir entity’i, Search Term’den ayırmak için kullanabileceğiniz iki temel araç bulunmaktadır. Bunlar:

1. Google Trends
2. Google Knowledge Graph API

Bunun dışında, SERP’i de kullanabilir ve sonuçları izleyebilirsiniz.

Google trends’e girdiğinizde arama çubuğunda şu yazının yazdığını göreceksiniz.

A Search Term ya da bir Topic…

Öncelikle, sözcük anlamlarından yola çıkalım… Bir arama sözcüğü ile bir konuyu birbirinden ayıran şey nedir? Yavaş yavaş, içeriklerinizi farklı Arama Motorlarının farklı algılama biçimlerine girmekteyiz. Türkçe’de bir arama terimi, herhangi bir bilgiyi edinmek için kullanılan sözcük olabilir ancak ‘konu’, donuk olmayan ve farklı etkileşimlere ve güncellemelere sahip olan bir dinamizmi ifade eder.

Burada bir alt başlık açacağız.

Keyword-Based Arama Motoru ve Entity-Based Arama Motoru Arasındaki Fark Nedir?

Öncelikle, Google entity-based veya keyword-based bir arama motoru değildir. Google, her şeyden önce Hypertextual bir Arama Motoru veya Yaşam Rehberidir. Yeni içerikleri, linkler aracılığı ile bulur, içeriğinizin ne ile ilgili olabileceğini daha içeriğinizi okumadan link profiliniz ile anlayabilir ve bu profil aracılığı ile güvenilirliğinizi de değerlendirebilir. Entity-based Search temelli olmasa da, Google için bu yeni gelişen ve tüm dünya için yeni olan bir başka Moden Search özelliğidir.

Alta Vista, 2003 yılında Yahoo tarafından satın alınmadan önce keyword-based temelli bir arama motoruydu. Link-based Google tarafından yenilmeden önce 1995 erken döneminde kurulduğunda sıklıkla kullanılmaktaydı. Alta Vista’da yaptığınız bir sorgu ise Arama Motoru tarafından şu şekilde yorumlanmaktaydı:

‘X ve Y arasındaki ilişki nedir?’ → X ve Y sözcüklerini içeren web page’leri sırala → En yüksek ilgi düzeyine sahip olanı en üste taşı.

Burada diyelim ki sadece ‘Y’ sözcüğünü içeren bir Web Page’e sahipsiniz. Muhtemelen, Algoritma, X → True, Y → False, Relevance Score → %50 diyecektir. Aynı zamanda, diyelim ki hem X hem Y içeriğinizde var, böyle bir durumda aşağıdaki yapı harekete geçecektir.

X in Title → True, Y in Title → True, X and Y both in Headings → True, X and Y both in URL → False… Relevance Score → %82. Daha sonrasında ise X ve Y’yi kaç kere geçirdiğiniz devreye girecektir.

İlerleyen dönemlerde, Arama Motorları genel olarak iki farklı yönteme başvururlar. Bunlar arasında, ‘geçmişte kalmış’ keyword-density, yani bir keyword’ün nerede kaç kez kullanıldığına bakmak veya eş anlamlarına bakmak gibi… Hatta Query2vec veya Word2vec gibi farklı dil algoritmaları devreye girdiğinde, X ve Y arasındaki ilişkiyi en iyi tanımlayan web page’lerde geçen ek bir kavram olan Z sözcüğünün kullanım sıklığına ağırlık vermek de Arama Motorlarının çözümleri arasındaydı. Özellikle de 2011 yılından sonra alınan Google Patentleri, kaliteli içerikleri anlamaktan çok spam belirtilerini anlamak ve cezalandırmak üzerineydi. Belki de kalıcı çözümü bu sayede, yani entity’ler ile bulmuşlar ancak uygulanmasını beklemekteydiler…

Mayıs 2013 tarihinde alınan ve Spam Query’ler ile Spam İçerikleri keşfetmeyi amaçlayan bir Google Patenti, kendisinden yaklaşık bir ay sonra Spam Query’ler aracılığı ile Web Spam Page’lerin cezalandırıldığı Payday Loan Update’in mimarıydı. Matt Cutts, burada özellikle Türkçe sorguların %5’inin spam olduğunu belirtmişti.

Dikkat ederseniz, Arama Motorları her zaman için Algoritmaları her açığa çıktığında suistimal edilen ve bu nedenle de optimize edilmesi daha zor ve daha çok vakit alan ancak aynı zamanda da daha az sayıdaki ek parametreleri, algoritmalarına sokan organizmalar. → Herkes, kullanılmayan <meta name=’keyword’ content=’…> elementini hatırlayacaktır. Veya bir keyword’e değil onun eş anlamlılarına odaklanmak → Term Frequency veya Inverse Document Frequency gibi farklı metodlar da bu yöntemlerin içindedir.

Bütün bu anlatılan keyword-based Search Engine örneğinde ise kesinlikle anlaşılması gereken ortak bir nokta vardır:

Keyword based Search Engine, Keyword’leri veya İçeriği anlamamaktadır. Sadece, ‘sözcük’ taklidi ile relevance score hesaplamaya çalışan ve kolayca manipüle edilebilir bir Arama Motoru modelidir. 

Yani Keyword-based Search Engine, aranan sorguya göre content’e, True veya False ya da Boolean değerler atayan bir modeldir. Entity-based Search Engine ise bir entity’i hafızasında webi tarayarak veya kendi ekibinin hafızasına eklediği veriler ile tanımlamakta ve kullanıcının/içeriğin duygu ve odak analizini yaparak ona aranan sorgu ile en ilgili içeriği sunmayı amaçlamaktadır. 

Hali ile Google için internetteki her şey, keyword’lerden yani Search Term’lerden Entity’lere dönüşmektedir… Bir başka alt başlık daha açarak, bir Search Term ve Entity arasındaki farka daha derin değineceğiz.

Keywordler ve Entityler Arasındaki Temel Farklar Nedir?

İki kavram arasındaki temel fark birisinin dile bağımlı, diğerinin ise dile bağımlı olmamasıdır. Diğer bir deyiş ile bir keyword tamamen bir coğrafyaya veya bir dile, topluma aitken bir entity, herhangi bir düşünen canlıya ya da sese bağlı olmadan varlığını sürdürebilen anlam bütünüdür. 

Hali ile entity-based bir Searrch Engine, keyword temelli olmaktan çıktığında, İngiltere’deki Search Feed’i ile Türkiye’deki Search Feed’i arasındaki ilişkiyi geliştirebilmekte ve iki topluluktan aldığı feedback’i birleştirerek daha iyi bir algoritma yaratmaktadır.

A/B testlerinde bazı ufak değişikliklerin etkilerini anlamanız için ihtiyaç duyduğunuz kullanıcı sayısı, değişikliğin küçüklüğüne göre artmaktadır. Örneğin, trilyonlarca arama sorgusu için trilyonlarca web-page’i milyonlarca algoritmadan oluşan bir Arama Motoru için düzenlemek istiyorsanız, ihtiyaç duyduğunuz data büyük ölçüde artmaktadır.

Yandex ve Bing’in ya da diğer olası rakiplerin daha iyi bir algoritma üretemediği için daha genel geçer ve eskide kalmış Arama Motoru geleneklerini kullanmalarının temel nedeninin, feedback eksikliği olduğunu (yatırım eksikliği değil) size daha önce Webinar sırasında da söylemiştim. Haliyle, Google, Entity-based bir Search Engine haline gelerek, elindeki feedback’i büyük ölçüde birleştirmiş ve çok daha ayrıntılı testler yaparak kullanıcıları daha küçük segmentlere bölmeye başlamış, insanlığın neural ağını ve düşünüş alışkanlıklarını daha da iyi anlayabilir bir hale gelmiştir.

Öyle ki, ‘You searched for X’ten, ‘You also may search for’’a geçilerek olası aramalarınızı, arama ihtimallerini hesaplayarak size farklı içerikler de sunmaktadır. ‘Related Search Activities’ bölümünde SERP’te gözlemleyebileceğimiz gibi Google Patentleri üstünde de ‘Systems to Generate Related Search Queries’ ile inceleyebiliriz.

Aynı zamanda, Related Search Activities ve Related Search Entities de birbiriyle ve bu konu ile doğrudan ilgili patenterdir.

Entity’ler ve Keywordler arasındaki tek fark ‘dil agnostiklik’ farkı değildir. Aynı zamanda, ‘duygu farkı’ da bulunmaktadır. Google, bu noktada bazı aldığı patentler ile Yaşam Rehberliğinde daha da ileriye gitmeyi amaçlamaktadır.

Keyword’ler ayrıcalığı ile yansıtılabilecek duygular ancak Query ve Content içinde eşlenik geçirildikleri takdirde relevance oluşturarak ortaya çıkarılmaktadır. Ancak, Google Entity-Based Search ayrıcalığı ile duyguların da birer entity olduğunu algılamakta ve onları tanımlayarak, sorgulara, içeriklere farklı türde duygusal yönler tanımlayabilmektedir. Bu noktaya daha sonra değineceğiz ancak özellikle Google’a ait olmasa dahi IBM’e ait bir patente ve bir kavrama değinmek istiyorum.

(Ek olarak, YMYL sitelerinde ‘istiyorum, istemiyorum, yapıyoruz gibi edilgen olmayan cümleler kullanmamalısınız.’ Bu içerikteki dil bir örnek temsili değildir.)

Bir telefon kamerasından ya da telefonundan veya konumundan, hava durumundan ya da dinlenilen son müzikten, kullanıcının duygu analizini yaparak ve bunu Historical Data of the User patentiyle birleştirerek, kullanıcının belirli duygu modellemelerini çıkararak, browser sorgularındaki sonuçların Search Engine tarafından değiştirilmesini amaçlayan IBM Patenti, Google’ın Natural Language Processor’e yerleştirdiği ‘Sentiment Analysis’ ile aynı amaca sahiptir.

Natural Language Processor, sözcüklerin yansıttığı duyguları analiz ederek, kullanıcı sorgusuyla eşleşip eşleşmediğine bakmaktadır. Diğer bir deyiş ile kullandığınız duygu içerikli sözcükler, içeriğinizin sıralamasını etkilemektedir. YMYL siteleri için bir önerim ise her zaman için duygu içermeyen ve NLP tarafından gri olarak işaretlenen içeriklere sahip olmanızdır.

Burada, Google’ın değer verdiği duygu profilini de anlamak önemlidir. Keza, NLP içinde yaptığım deneylerde gördüğüm yegane şey özellikle sağlık içeriklerinde olumlu cümle kullanımının olumsuz cümle kullanımının önüne geçtiğidir.

Bu ilaçları alırken bunları yiyemezsiniz değil → Bu ilaçları alırken bunları yememelisiniz.

Bu ilaçları almazsanız ölürsünüz değil → Bu ilaçları almanız hayati öneme sahiptir.

Bu tipteki farklılıklar, Google için daha resmi, düzgün yazılmış ve kullanıcıyı olumsuz ruh haline sürüklemeyen duygu profilindeki içerikleri keşfetmesini sağlamaktadır. Aynı zamanda, Google bazı sözcükler tarafından triggerlanmaktadır. Bu konuda, RankRanger CMO’su ve MobileMoxie CEO’su ile SEO Police adındaki hesap arasında geçen ve Twitter üstünde karşılaştığım bir deneyi sizinle de üst kısımda paylaşmak isterim.

Görebileceğiniz gibi, Google, ‘Ölmeyi çok seviyorum’ cümlesini dahi olumlu yorumlamaktadır. ‘Nazilerden nefret ediyorum’u’ (Google, Nazi, IŞİD veya Politik İftira veya İftira benzeri her konuda, otomatik depromosyon’a sahiptir. Bu noktada, bir nebze de olsa Baidu’yu andırıyorlar.) olumsuz yorumlamaktadır.

Bunun temel nedeni ise bir cümledeki ‘çok’, diğer cümledeki ise ‘nefret’ sözcüğüdür. Belirli sözcüklerin belirli duygu yönlerinde ağır yükleri bulunmakta ve o cümleyi farklı sözcüklerle birleşerek farklı yönlere çekmektedir. Bu nedenle, SERP incelemesi yaparak, rakiplerinizin bu kavramları kullanıp kullanmadığına ve duygusal etkilerine bakmanızı tavsiye ederim.

Keyword’ler ile Entity’ler arasındaki, language-agnostic ve sentiment-included gibi farklara değindikten sonra, bahsedeceğimi belirttiğim bir diğer noktaya geçmekte fayda görüyorum.

Search Engine ve Belirsizlik Etkisi

Search Engine’lerin giderek ‘daha küçük ve optimize edilmesi daha zor etkenlere’ ağırlık vermesinin temel nedeni kalitenin gerçek göstergeleri olmaları ve süreklilik/emek istemeleri ile manipüle edilmelerinin zorluğudur. Örneğin, Youtube’un ağırlık verdiği algoritma parçacıkları kronolojik olarak aşağıdaki gibidir:

Views → Likes → Subscriber → Watch Time → Shares → Comments

Diğer bir deyiş ile daha az sayıda olan ve gerçekleştirilmesi daha zor olan, manipüle edilmesi zor olan elde edilmesi ve manipüle edilmesi kolay olanın önüne geçmektedir. Google için farklı bir durum daha bulunmaktadır. O da, SEO’ların veya Web Sitesi sahiplerinin pek çok Google Guideline’nını çiğnemeleri nedeni ile Google’ın kendi etkenlerini ‘komut’ değil ‘hint’ olarak ele aldığında daha az masraf etmesi ve web’i daha iyi taramasıdır.

Enrique Alfonseca, Keith Hall ve arkadaşlarının, NLP API oluşturulurken belirsizlik etkisini nasıl azalttıklarını anlatan çalışmalarının bir örneğidir.

Çalışmanın giriş kısmındaki işaretli kısım, ana eksiği ve ihtiyacı belirtmektedir.

Örneğin, Canonical, Nofollow ve Pagination noktalarında, Google giderek geri adım atmış ve bunları birer komut olmaktan çıkararak hint durumuna geçirmiştir. Pagination noktasında ise gene kendi içgüdülerine güvenmiştir. Aynı şey, ‘Javascript Rendering’ için de geçerlidir. Eğer Render sonucu oluşan sayfa, sayfanın bir önceki taranmış halinden çok farklı değilse Google, daha az masraf oluşturmak için iç güdülerine güvenerek render sürecini bazen ‘skip’ edebilir. Bartosz Goralewicz, bu noktada doğal olarak yapay zekanın içgüdülerine güvenmek yerine farklı Rendering Type’larını IT ekiplerine tanıtmanın faydalı olacağını söylemiştir.

Belirsizlik Etkisi, Arama Motorlarının giderek daha az önemli etkenlere odaklanarak daha büyük sonuçları, daha geniş zaman dilimlerinde çıkararak, sıralama sonuçlarını daha uzun sürede, daha kalıcı biçimde değiştirme çabasıyla ortaya çıkmıştır. Özellikle de güçlü komutlar yerine pek çok küçük etkeni bir arada paralel değerlendirme ilkesi, Search Engine’lere daha fazla ve derin sinyalleri sürekli verme ihtiyacını yaratmıştır. Bu nedenle, Entity-Based bir Search Engine’e doğru mesajı vermek için, Keyword-based bir Search Engine’e göre daha da fazla çabalamanız gerekmektedir.

‘Keyword değil Entity-based olduğu için sorgunun İngilizce karşılığını verebilen Google, LyricFind’ı Source olarak alırken Yello’dan bir örneği gösteriyor. Halbuki ben, Green Day’in Oh Yeah şarkısını arıyorum. Veya David Guetta’nın? Nitekim, bu sonuçlar da aşağıda Web Search’te ‘Relavent’ olarak karşımıza çıkıyor.

Confidence Score’lara baktığımızda da Oh Yeah 1. Sırada ve 2. Sırada benim aradığım şarkılardan ikisi de yok…

Arama Motorları için her entity’nin tahmin edebileceğimizden çok daha fazla anlamı var…

Brand-Entity Authority kavramına ise belirsizlik etkisi kapsamında daha sonra değinilecektir. Şimdi, bir üst başlığa geri dönme zamanı… Bir Search Term ve Topic arasındaki fark nedir? Nasıl anlaşılır ve Google’ın düşünüş biçimini bu noktadan nasıl çıkarabilirsiniz?

Google Trends ile Search Term ve Entity Arasındaki Farkı Anlama

Keyword-based, Entity-based Search Engine farkını, keyword-entity farkını ve Belirsizlik Etkisini, IBM ve Google patentleriyle, duygu analizleriyle ve Related Search Activities and Entities gibi farklı kavramlarla geride bıraktık. Sırada, Search Term ve Entity arasındaki farkı anlatarak, nasıl ikisinin birbirinden ayırt edilebileceğini göstermeye geldi…

Google Guideline’ına göre bir Search Term, belirli bir dile özgüdür ve related search query’ler entity-related bir biçimde algılanmak yerine daha çok Query2vec yani keywordlerin vectorel aralığını ölçen algoritmayı andıran bir biçimde sıralanmaktadır.

Örneğin, Banana Sandwich Search Term’ü, banana for lunch veya peanut butter sandwich gibi farklı Search Term’ler ile de ilişkili görünmektedir. Query2vec’in ne olduğunu anlamak için İçerikbulutu ile gerçekleştirdiğim webinarı izleyebilirsiniz, konunun dağılmaması için bu noktada anlatmak yerine sadece içeriğini temsil eden bir görsel bırakmaktayım.

Bir Search Term’in aksine Topic ise dil agnostiktir. Google’ın deyimi ile bir concept’i yani bir entity’i ifade etmektedir. Bu nedenle, London’un hangi dildeki sorgusunu gerçekleştirirseniz gerçekleştirin, sürecin sonunda aslında bir Entity’nin Search Volume’ünü ve related search activity’lerini görüyor olacaksınız.

Peki, Google Trends’ten yola çıkarak bir Topic’in, Entity olduğunu nasıl mı kanıtlayabiliriz?
Çok kolay… 

Daha önce de belirttiğim gibi, yazı sırasında kullandığınız ‘derece’ ve ‘nitelik’ bildiren sözcükler yani entity’ler Google için trigger’dır. Teori ile pratiği birleştirmek için ‘çok kolay’ söz öbeğini, ‘it is so easy’ olarak Google Doc. üstünden Google NLP Api’sine bağladım. Görüldüğü gibi duygunun şiddetli ve olumlu olduğu düşünüldü. Öğretim veya YMYL makalelerinde, ‘neutr’ duyguları yansıtmanız tavsiye tarafımdan tavsiye edilir.

Mustafa Kemal Atatürk sorgusunu girdiğinizde, karşınıza doğrudan sorguyu içeren 4 yanıt gelmektedir. Bunlardan birisi sadece Mustafa Kemal Atatürk’ü Türkçe sonuçlarda ve farklı konularda adını geçiren arama terimleri için geçerlidir. Diğeri Mustafa Kemal Atatürk’ün ‘Former President of Turkey’ olarak Main Entity halidir. Bir diğeri onun adını taşıyan ve ayrı bir entity olan üniversitedir. Sonuncu ise ‘Former President of Turkey’ gibi ‘Military Career’ biçiminde, Mustafa Kemal Atatürk’ün related-entity sonucudur. Google, tanıdığı ve tanımladığı entity’leri size sorgu sonuç sayfalarında belirtmektedir. Bu sonuçların dil agnostik olduğunu hatırlamalısınız.

Bunun dışında, Search Term ve Entity arasındaki farkı, URL’lerde de görebilirsiniz. Aşağıdaki iki URL’i inceleyiniz.

https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F04t6f_

https://trends.google.com/trends/explore?geo=US&q=Mustafa%20Kemal%20Atat%C3%BCrk

Bu URL’lerden ilki, entity olan Mustafa Kemal Atatürk içindir. Nereden mi anlıyoruz?

FM 2F04F6f kısmına dikkatle bakın. Şimdi gelin Knowledge Graph API’ye gidip ufak bir veri çekelim.

ID kısmına dikkatle bakın. Gördüğünüz karakterler, 04t6f karakterleri, Google Trends’te yer alan URL ile aynıdır. Aynı zamanda, söz konusu sorgunun söz konusu Entity ile birleştirilmesi sırasında 18,633’lük bir confidence score oluşmuş durumda. Dürüst olmak gerekirse, bu Google’ın doğru sonuç sunup sunmadığı noktasında, webi tararken gördüğü info modellerini örnekleyerek elde ettiği score’dur.

Örneğin, Mustafa Kemal Atatürk’ü anlatan 1958 yapımı bir belgesel film için verilen confidence score ise 440’tır. Ancak belirli sorgu sözcüklerine göre söz konusu Entity, Entity-Relation ve Personal Historic Data’ya göre, bir önceki entity’nin önüne sonuç sayfalarında geçebilir.

Örneğin, doğruca filmin adını aradığımızda, filmin confidence score’unda %200’den fazla artış yaşanmaktadır. Böylece yavaş yavaş makalelerinizde Entity’leri nasıl kullanmanız ve nasıl hesaplamalar yapmanız gerektiğini anlıyor olmalısınız.

Google’a ait Entity-Query Matching konusundaki her patentten buna benzer insight’ları sadece pratik olarak değil teorik olarak da almanız mümkündür. Yukarıdaki, şema yeterince açık, ancak Query-Entity, Entity-Query matching sisteminin çift yönlü yaşanmasına, browser, cihaz bilgisine ve Entity-Sub Entity ilişkilerine, Query Suggestion profilinin sürece dahil edilmesine de dikkat etmenizi tavsiye ederim. 

Google Natural Language Processor’üne göre içerik yazmaya geçmeden önce Google’ın yıllar süren istikrarlı patent paralelindeki ilerlemesine, Entity ve Link bazlı olarak dikkat çekmekte fayda var.

Link-based Clustering ve Entity-based Clustering ile Entity-Based İçerik Optimizasyonu

Google’ın Link-based bir Arama Motoru olduğunu, yeni içerikleri Linklerle keşfettiğini, içeriklerin birbirleriyle olan ilgi bağını, otoriterliğini ve kalitesini de linkler aracılığı ile belirlediğini daha önce söylemiştik. Bu noktada, Entity-based Clustering’in devreye girmesi ile Google, Link-based algısına daha da güçlü ayrıntılar kazandırmaya başlamış bulunmaktadır.

Link-based Clustering ve Reduced Link Graph gibi farklı Google Patentleri, ‘Seed Pages’ adı verilen kaynak sayfalara olan yakınlığın ve benzerliğin bir içeriğin kalitesini gösterdiğini belirtmektedir. (Buradaki yakınlık kavramı, backlink projelerinde kullanılabileceği için girilmeyecektir.) 

Link-based Clustering Nedir?

Google, Entity-based değil Keyword-based bir Search Engine iken özellikle Synonim sözcüklerin kazandırabileceği context gücüne ihtiyaç duymaktaydı. TF-IDF gibi kavramların yanı sıra, karşısında temelde iki sorun bulunmaktaydı.

Search Engine Building ve Search Analyst konularına ilgi duyuyorsanız mutlaka, The Vocabulary Problem in Human System eserini okumanızı tavsiye ederim.

1. Temel sorun → İnsanların aynı sözcükleri kullanarak farklı şeyler anlatmaları.

2. Temel Sorun → İnsanların farklı sözcüklerle aynı şeyleri anlatmaları.

Google, Keyword-Based bir Arama Motoru olduğu dönemde, bu soruna şu an herhangi bir Entity için herhangi bir Query’de yeterli Confidence Score oluşmadığında yanıt verdiği gibi yanıt vermeyi amaçlamaktadır. Belirli sorgularda farklı sonuçları aynı anda göstermek…

Google, kullanıcıları kendi istediklerinden ilgisiz sonuçlara yönlendirmemek için Link-Clustering of Hyperlinked Documents adlı patentini aldı.

Aşağıdaki görselde, Saturn Arabaları, Saturn Gezegeni ve Saturn Oyunları biçiminde farklı konulara göre Link-Based gerçekleştirdiği cluster’ları görmektesiniz.

Eski bir Blackhat yöntemi ise herhangi bir sorgu için olan otoritenizi sarsmak, ilgi skorunuzu yok etmek için sizi mümkün olan en benzer konularda Google’ın ayırt edemeyeceği kadar benzer anchor textlerle linklemekti. Bu noktada, ‘Seed Pages’e’ olan yakınlığınız önem taşımaktadır.

Örneğin, Saturn Arabaları noktasındaki en otoriter ve ilgili internet sitesine, Link Graph içindeki benzerliğiniz ve yakın konumunuz sizin Saturn Oyunları sorgusundan muaf tutmak ve relevance score’nuzu korumak için en önemli göstergedir. Daha pratik bir örnek için, bir bahis sitesinin ‘Nakit Avans’ sözcüğü ile bir Kredi Kartı web sitesine link çıktığını hayal edebilirsiniz… Bu tipteki ince örneklerin bir kısmı hala etki etse dahi, 2019 öncesindeki eski Blackhat fırtınasını göremeyeceğiz. (Neyseki…)

İlerleyen dönemde, Google Link-Clustering temasındaki tüm patentlerini, ‘People Also Ask For’ veya ‘Related Searches’ ya da ‘Did you mean this’ gibi farklı özelliklerle birleştirdi. Ardından Knowledge-Graph’larla, video sonuçlarla veya image sonuçlarıyla, haritalarla ve news eklentileriyle bu durumu, görseldeki upuzun SERP yerine mobil cihazlara dahi uyumlu bir biçimde uyguladı.

Entity-Clustering Nedir?

Entity Clustering ise Keyword-based Search Engine olmaktan çıkılan süreçte, Link-Graph’ın Knowledge-Graph’a dönüştürülmesi ve birbirini besleyen bir biçimde kullanılmasıyla ortaya çıktı. Bu noktada, Topic Clusters, Topical Layers ve Topical Authority gibi çok daha farklı kavramları, webinar sırasında aktardım ancak tek cümlelik olarak sonuç kısmında gene de yer alacaklar.

Entity-Clustering ve Definition için farklı bir örnektir.

Entity Clustering için Clustering Search Results adında ayrı bir patent kullanıldı. Bunun için Search Items’ların gruplandırılması ve ilişkilerinin sınıflandırılması amaçlandı.

Örneğin, Cep Telefonu sorgusunda karşınıza çıkan, Product’lar, Kıyaslamalar, Görseller, Markalar, E-ticaret siteleri, bilgi ve öneri içeren siteler, haritalardaki satıcılar, bloglar ve dahası tamamen Search Items olarak tanımlandı. Ardından, bu itemlerin tamamı product, person, organisation, book, blog, newspaper, localbusiness vs. biçiminde entity-based olarak toplandı. Sonrasında ise otoriterliklerine ve ilgililiklerine göre sınıflandırıldılar.

Patent içinden gördüğünüz bu görselde, aynı işlem AppStore’da gerçekleştirilen halini göstermektedir. Entity Clustering içerisinde, Similarity Score adında farklı score’lar ve Entity Ontology gibi farklı sistemler de mevcut.

Örneğin, Entity Ontology, bir Entity ile diğerinin Sinonym olup olmadığını ya da aralarında Parent/Child veya Similarly Different ilişkisi olup olmadığına bakmaktaydı.

Bütün bunları bildiğinizde, Arama Motorunun bir içeriği nasıl algılayacağını ve Named Entity Recognition sürecini nasıl kurgulayacağını daha iyi anlayacağınıza inanıyorum.

Basitleştirerek anlattığım sürecin, daha karmaşık bir halini görmektesiniz. Kavramları daha sıkı bir biçimde anlatabilirim, örneğin Cluster Assigments, bir Entity için metadata, description, link, sinonyms, documents ve dahası ile tüm Search Item’ların depolandığı yerdir. Ardından, Entity olduğuna karar verilen yapılar, Knowledge Base’e kaydedilmektedir. Overlap Score ise Search Item’lardan kaçının duplicate olduğunu ölçümler… Gerisi için tavsiyem patentin en açıklayıcı şemasını doğruca okumanız: 

Gelelim, Google NLP öncesi son alt başlığımıza…

Entity-based ve Link-based Clustering Arasındaki Temel Fark Nedir?

Temel fark, birisinin ilgili içeriğe Entity-Profilini kullanarak diğerinin ise Link-Graph’taki konumunu kullanarak ilgili relevance, authority ve confidence scorelarını atamasıdır. Temelde, Entity-based Cluster’lar kendi sistemleri içinde de linkleri kullandığı ve tüm Google sisteminin linkler üzerine kurulu olduğunu düşünürsek, ikisinin bir ölçüde farklı noktalara odaklanarak birbirini tamamladığını belirtebiliriz. Buradaki amaç, birisini bırakıp diğerine geçmek değil, ikisinin de eksikliklerini tamamlayarak, daha iyi sonuç sayfaları sunmaktır.

Örneğin, Google’da sadece ‘F’ harfini aradığımızda, Google sizin ne aradığınızı anlamadığı için tamamen birbirinden farklı sonuçlar sunmaktadır. Bunu yaparken, F Harfi, Fahrenayt gibi entity’leri, video sonuçlarını veya çoğu kişinin sergilediği, f harfini yazıp Facebook’a girmek davranışını, F harfi ile başlayan hisse senetlerini üst kısımda göstermektedir.

Alt kısımda ise, içinde F geçen araç modelleri, F harfi hakkında akademik bilgiler, semboller ve F Caddesinden geçen duraklar gibi çok ilgisiz sonuçlar görünmektedir.

Google, The Vocabulary Problem’ın aktif olduğu her yerde hem Link Graph’ı hem de Entity Clusterları kullanmaktadır. Böylece, farklı kullanıcı segmentlerinden topladığı sonuçları birleştirebilmektedir. Videolar kısmındaki müziklere ve çizgi filmlere ise hiç girmiyorum ki aynı sonuç farklılığının görsellerde daha az olduğunu göreceksiniz. F biçiminde kolyeler, Facebook logosu, F16 ve bazı kıyafet seçeneklerini Google ilgili olarak sunmaktadır.

Haberlerde ise daha çok F16’ları, Fenerbahçeyi veya F adındaki bir sanat galerisini görüyoruz, tabii ki haberlerin tamamı son 24 saatten…

Diğer bir deyiş ile Google, en kılcal arama sorgularında dahi kullanıcı bazlı olarak ilgili farklılıkları keşfetmek ve sunmak istemektedir. Eğer misafir sekmesini açıp biraz Chrome hafızası oluşturursanız, F ile ilgili size sunulan sonuçların değişeceğini göreceksiniz.

Google, F ile en ilgili içerikleri, link-based ve entity based biçimde kullanıcının küresel verilerini değerlendirerek seçmiştir.

Bu noktada, entity-based bir içerik optimizasyonundan, Google’ın Link-based bir graph’a sahip olduğunu ve Entity’leri bunlarla tanımladığını, Entity-based bir search içinde de her entity’nin farklı attribüte’leri, child elementleri ve relationları olduğu gerçeklerini asla çıkarmamalısınız.

Google Natural Language Processor Nedir? Entity-based Content Optimizasyonu ve Google’ın İçerik Algısı

Yapay zeka araştırmalarının en önemli bölümlerinden birisi bir metnin içeriğini anlama, özetini çıkarma ya da konusunu çözümleme biçimindeki amaçları barındıran NLP’dir. Bir Arama Motorundan daha fazla Natural Language Processor’e ihtiyaç duyabilecek herhangi bir olgu ise ilk bakışta aklıma gelmemektedir. (Belki, CIA?) 

Arama Motorları Dışında, NLP’ye ihtiyaç duyan iş alanları: 

• Haber şirketleri, haber makalelerini yapay zekaya yazdırmaya başladı.
• Review siteleri ise sahte yorumları, yapay zeka sayesinde yakalamayı amaçlıyor. 
• İnsan Kaynakları firmaları ise CV’leri farklı iş pozisyonları ile birleştiriyor. 
• Hukuk şirketleri, sözleşmeleri taramak, Sosyal Medya şirketleri ise nefret söylemlerini ayıklamak için Natural Language Processing sürecinin içinde. 

Ancak hiç birisi, belirttiğimiz gibi, hangi makalenin, cümlenin ya da text parçacığının hangi konuda, hangi kullanıcıya daha da lazım olduğu veya hangi kullanıcının hangi sesli sorguda neyi aradığını anlamak, farklı metinlerin kalitelerini ve güvenilirliklerini kıyaslamak gibi Arama Motorlarına özgü amaçlara/ihtiyaçlara sahip değil. Bu nedenle, Google kendi NLP ve Dil Algoritmalarını düzenli bir biçimde yeniledi, geliştirdi.

Google, Keyword temelli olmaktan çıkıp Entity temelli olmaya geçerken, Desktop temelli olmaktan da çıkarak kullanıcı davranışlarını çok daha iyi (Android İşletim Sistemi ve AppStore, Gmail ve dahası ile…) inceleyebileceği mobil cihazları temel alan  bir yapıya geçti. Mobil First Indexing’i bu bağlamda, Entity-First indexing olarak görmek gerektiğini de webinar sırasında belirttim.

Image Source: Mobilemoxie.com, Cindy Krum, Entity Disambiguation’ın yarattığı SERP Çeşitliliğine bir örnek.

Danny Sullivan, burada Keyword-based Index’lerin, Entity-based olarak değiştirilmesini aynı kitapların farklı teknolojilerle sunulmasına benzetmektedir. BERT ile yeni Entity Network daha da geliştirildi. Bunun temelde üç ayrı aşaması vardır:

• Named Entity Recognition (NER): Bir metindeki entity’lerin extract edilmesi için oluşturulan süreçtir.
• Next Sentence Prediction (NSP): Bir metindeki, cümlelerin aşamalı olarak silinmesi ve yapay zeka tarafından doğru tahminle doldurulması sürecidir.
• Masked Language Model (MLM): Bir metindeki ‘token’ların (yani sözücklerin) silinmesi ve yerine eşanlamlılarının konularak anlam farklılığının yaşanıp yaşanmadığının denetlenmesidir.

BERT, ortalama olarak %6 ile %9 oranında bu farklı deneylerde, Çift Yönlü okuma sayesinde gelişme sağlamıştır. Böylece, mobil cihazların baz alınması ile yaşanan kullanıcı segmentlerinin daraltılması, entity-based Search Engine ile daha da daraltılmıştır. Bu noktada, Google’ın Natural Language Processor’ü de, ilerleme kaydetmiştir.

Google Natural Language Processor API ve Metin İşleme Süreçleri

Google’ın NLP API’si, Google tarafından devasa boyuttaki metin testleri ile eğitildiği için, kullanıcılarca açık biçimde kullanılabilmektedir. Herhangi bir sorgudaki, en kaliteli sayfaların içeriklerini çekerek NLP API’den geçirebilir ve çeşitli incelemeler yaparak da içerik süreçlerinizi nasıl yönetmeniz gerektiğini anlayabilirsiniz.

Google NL’den, AutoML NL seçeneğini gösteren bir kesit.

Ayrıca, eğer Google NLP API sizin için yeterince esnek değilse Google AutoML Natural Language API’sini kullanarak da farklı konularda, ‘tune edilmiş’ özel dil işleme yapay zeka modellerini oluşturarak kullanabilirsiniz. Örneğin, sadece finans/kredi sektörü için bir optimizasyona ihtiyacınız var ise standart NLP yerine, modellenmiş bir Natural Language Processor kullanmanız gerekecektir. Başka bir makalenin konusu olan AutoML NL’yi kenara bırakarak NLP’nin çalışma prensiplerine/aşamalarına geçmeliyiz.

Google Natural Language Processor Çalışma İlkeleri

Tokenization

Bu aşama, herhangi bir browser’ın bir web sayfasını oluştururken de yaşadığı süreçtir. Browser, byte’ları, karakterlere, karakterleri de token’lara dönüştürürken NLP ise sadece herhangi bir cümleyi parçalarına ayırarak, bu parçaların anlamlı sözcükler oluşturabileceği hallerini almaktadır. Diğer bir deyiş ile bir cümleyi, sözcüklerine ayırmaktadır.

Parts-of-Speech Tagging

Belirlenen token’ların, sıfat, fiil, özne, nesne ya da farklı tümce ögeleri haline gelmesini sağlar. Bu yapılırken, NLP önceden kayıtlı hafızasını kullanarak bazı sözcükler için farklı alternatifleri deneyerek en doğrusuna karar vermektedir.

Mario Draghi’nin Entity olarak bulunduğu şehirler, hangi görev için bulunduğu, kaç yıl bulunduğu, kiminle bulunduğu, Entity-based Search Engine’de kayıtlıysa, makalelerinizde bunları belirterek hem Phrase-based hem Entity-based olarak tutarlılıkla/kalite sinyali verirsiniz. 

Lemmetization

Farklı biçimlerde yazılmış sözcüklerin, kök halini çıkarır. Çoğulları, tekilleştirir, farklı ekler almış sözcükleri sadeleştirir. Bu noktada, yazım hataları mevcutsa onları da hafızasındaki veriye dayanarak düzeltir.

Word Dependency

Sözcükler arasındaki anlam bağını çözerek, sıfatları nesnelere, nesneleri öznelere ve özneleri fiillere bağlayarak grammer kurallarına göre cümlenin içeriğini çözmektedir.

NLP API’de bir ‘person’, ‘organisation’, ‘event’ hakkındaki yazı, karakteristik farklara ve Entity-Network’te özel bağlara sahiptir. Bunları yazım sırasında, NLP API’den kontrol ederek, odak Entity’e göre bir yazım biçimi belirlemelisiniz.

Parse Label

Birbirine bağlanan sözcüklerin, cümleye olan etki çeperleri nitelenmektedir. Örneğin, bir sıfat sadece bir ya da iki nesneye etki ederken, özne veya fiil tüm cümleye yayılmaktadır. 

Parse Label aşamasını daha iyi anlamak için Stanford Dependencies Çalışmasını okuyabilirsiniz.

Named Entity Extraction

Herhangi bir cümle içindeki, Entity’lerin tanımlanması ve anlam bağlarının içeriğin context’ine dahil edilmesi sürecidir. Birbiri ile ilgili entity’leri bu nedenle makalenizde ilgi ve olası kullanıcı sorgusuna yönelik olarak geçirmeniz önemlidir. Temelde, her sözcük bir entity’dir ancak bu süreç daha çok adları olan ürünler, kişiler, yerler, kurumlar, hareketler, hayvanlar, cihazlar ve dahası için odaklanmıştır. Kullanacağınız herhangi bir bilimsel kavram veya kuruluş ya da yasa adı, içeriğinizin otoriterliğini Named Entity Extraction kısmında etkileyecektir.

Google geçtiğimiz dönemde, Pegasus adında bir yapay zeka modeli geliştirdi. 750 GB içeriği, 1.5 milyon makaleden ve 3.8 TB boyutundaki web sitesinden tarayarak 568 Milyondan fazla değişken ve parametreye sahip Pegasus ile ‘en iyi metin özetleyiciyi’ geliştirme unvanını aldı.

Salience Score

Bir metin içindeki ‘işaretçi’ sözcüklerin, belirli bir Entity’i işaret etme gücünü ifade eder. Diğer bir deyiş ile Hakkındalık veya İlgi Score’unu ölçümler. Related Entities ve Link Graph ağı, herhangi bir metnin tam olarak odaklandığı Entity’i keşfederek, herhangi bir sorgudaki odak entity ile olan ilgisini çözümler. NLP API içinde, işaretçi sözcüklerin niteleme biçimi de benzer şekilde verilmektedir. Bazı sıralaması yüksek metinleri, NLP API’ye sokarak, Salience Score’ları inceleyebilirsiniz. Hatta, metni değiştirerek score değişimlerini de gözlemlemelisiniz.

Entity-based Search Engine’in ‘Related Entities and Queries’ yardımıyla, doğru Entity’leri seçerek Document Classification gerçekleştirme şemasıdır.

Sentiment Analysis

Metin içinde yansıtılan duygudur. Buradaki duygunun olumluluk, olumsuzluk yanı olduğu gibi şiddet yanı da vardır. Şiddetli olumsuz, şiddetli olumlu gibi… Aynı zamanda, makalelerinizde, YMYL Sitelerinde mümkün olduğunca Neutral olmanızı tavsiye ettiğimi hatırlatırım. Aynı zamanda, sorgunun duygu analizi ile metnin duygu analizini yaklaştırmanız gerektiğini ve YMYL sitelerinde olumlu yapıdaki cümlelere ağırlık vermeniz gerektiğini de…

Subject Categorization

Google NLP API, yazıyı inceleyerek hangi kategoride değerlendirilmesi gerektiğini ele alır. Burada, birden fazla kategori farklı Confidence Score’larla size gösterilecektir. Bu bölümü inceleyerek hem Google’ın bir Entity’i ve Konuyu kaç ayrı bölüme ayırdığını anlayabilirsiniz hem de dilerseniz yazdığınız metni Google’ın hangi kategoride gördüğünü de çözümleyebilirsiniz. 

Eğer sağlık alanında yazdığınız bir içerik, sağlık turizmi kategorisinde daha yüksek bir confidence score’a sahipse, içeriğinizi düzenlemeniz gerekmektedir. 

Google’ın Entity Classification sistemini anlamak için ayrıca, Local Business Search’teki entity hiyerarşisini veya görsel entity’lerinin birbirine bağlanma biçimini de inceleyerek, içeriğinizi nasıl şekillendirmeniz gerektiğini anlayabilirsiniz. Eğer, bir kategoride daha yüksek Confidence Score alırsanız, o kategoriye dair sorgularda, rakibinize göre öne geçeceksinizdir.

Kötü haber ise ne yazık ki bu alanın sadece İngilizce’de kullanılabiliyor olması…

Makalenin devamında, daha pratik örnekler/çeşitlendirilmiş kavramlar yer alacaktır. Bu yüzden, bu örnekleri iyi incelemeniz gerekmektedir.

Text Classification

Boilerplate içi veya dışı tüm etkenlerin sınıflandırılması durumudur. Footer’daki, header’daki yazılar, yazar biyografisi ve dahası gruplandırılarak amacına uygun bir biçimde değerlendirilir. Aynı zamanda, metin içindeki content bölümlerinin yazılış amacı da kategorize edilerek, Subject Categorization’a son biçimi verilir.

Text ve Subject Categorization sürecini aktaran temsili bir şemadır.

Content Type Extraction

Bu bölüm, bir önceki iki bölümde yapılanların veya yapılamayanların denetlenmesidir. Yazı sırasında, belirsizlik etkisinden bahsetmiştik. Belirsizliği giderebilmek için küçük farklı ögelere bakan Arama Motoru, HTML yapınızdan, URL’nizden ya da yazı formatınızdan kategorinizi bir nebze anlayabilmektedir.

Örneğin, yazınızın bir yemek tarifi hakkında mı, bir event hakkında mı ya da bir sağlık operasyonu hakkında mı olup olmadığını Structured Data’ya ihtiyaç duymadan da anlayabilmektedir. Ancak her küçük noktadan paralel ve tutarlı bir mesajı Arama Motoruna iletmek, belirsizlik etkisini önemli ölçüde azaltacaktır.

Ana Metnin Yapısı ve İma Ettiği Olguların Çıkarımı

Google, URL, HTML Format, Page Segmentleri gibi olgulara baktığı gibi metindeki tablo miktarına, sayısal verilere veya listelere, numaralandırılmış alt başlıklara bakarak da contentin temel niyetini anlayabilmektedir.

Örneğin, YMYL Sitelerine baktığımızda çok fazla ‘2020’Deki xxxxx 30 şey’ biçimindeki içeriklerin sıralamalarda yeterince yer kazanamadığını görüyoruz. Keza, ‘Kanserin 2020’deki 30 Çözümü, Nedeni, Tedavisi, Önlemi vb.’ bir anlam ifade etmemektedir. Google, metnin ana yapısına bakarak da vermek istediğiniz mesajı hangi otoritede verdiğinizi anlayabilmektedir.

Buna ek olarak, hem webinarımda hem de çevremdeki arkadaşlarıma her zaman Semantic HTML kullanılmasını söylememi, daha geniş bir kapsamda ele alabilirsiniz.

Search Engine’in ‘Named Entity Recognition’ süreci, ‘New Concept Creation’ ile aktarılmıştır.

Google Görsel Sınıflandırması ve Görsellerden Entity Extraction Süreci

Google, sadece ‘text’teki anlamlara bakmak yerine günümüzde görsellerdeki anlamları da algılayarak sınıflandırmaya başlamış durumda. İçeriğinizin özgünlüğü kadar görsellerinizdeki özgünlük ve içerik ile olan uyumu da önemlidir. Google tıpkı NLP gibi ayrıca Vision AI adındaki bir uygulamaya sahip. Google Vision AI, tamamen görseller üzerine üretilmiş durumda ve ufak bir test yapmanız ise anasayfaları üstünden mümkün.

Google Vision AI Neleri Görebiliyor?

1. Eskiden sadece ‘alt etiketlerine’ bakan Google, günümüzde görsel üstündeki yazıyı okuyabiliyor.
2. Görsellerdeki nesneleri entity’ler ile bağdaştırabiliyor.
3. Entity’lerin duygusal durumunu çözümlüyor.
4. Kişilik sınıflandırmasını yapıyor.
5. Görselin reklam için mi yoksa fayda sağlamak amacıyla mı konduğunu anlıyor.
6. Görseldeki nesnelerle, yazıdaki nesnelerin uyumlu olup olmadığını algılayabiliyor.

Google Vision AI toplamda 6 tür veri sunmaktadır. Bunları inceleyerek Google’ın görsel algısını hangi yönde ilerlettiğini daha iyi anlayabiliriz.

Kendi fotoğrafımı, Vision AI’de arattığımda, benim en çok ilgili olduğum alanları görmekte ve benimle ilgili Entity’leri çıkarmaktadır. Bunu yaparken fotoğrafın bulunduğu diğer Web Sayfalarını ziyaret etmektedir. Eğer YMYL Sitesinde kullandığınız bir fotoğraf aynı zamanda, YMYL Dışı ciddiyetsiz bir sitede kullanılmış ise aynı fotoğrafın Web Entities bölümünde, kategori gücünüzü azaltan sınıflandırmalara maruz kalabilirsiniz.

Google Vısıon AI’nin Sunduğu Veriler ve Tipleri:

• Yüzler: Buradaki data tamamen görselde bulunan kişileri tanımlamak ve duygu analizini yapmak için kullanılmaktadır.
• Objects: Görselde bulunan nesneleri tanımlamak ve tiplerini belirtmek için kullanılmaktadır.
• Labels: Görseldeki ‘ufalanabilir’ her nesneyi ufalayarak en küçük haline kavramsal bir ad verir. Örneğin: Burun, sakal, kolye, çene, göz gibi… Aynı zamanda, davranış ve fonksyion isimleri de burada yer alır, selfie, flying ya da burning gibi…
• Web Entities: Fotoğraftaki kişi, nesne ya da varlığın ilgili olduğu kavramları ve ilgi düzeylerini sınıflandırır.
• Proporties: Baskın renkleri ve görselin oranlarını çıkarır. Bu tip bir veri, Google’ın kendi yapay zeka deneyleri için gerekmektedir. Örneğin, X Entity’sini taşıyan fotoğrafların % kaçı dominant olarak hangi renkte ve boyuttadır, yüzlerin neşe, zevk ya da öfke oranındaki hissi nedir? Gibi sorular, image’lerin daha belirgin ve kullanıcı dostu kategorize edilerek algoritmalarına dahil edilmesini sağlamaktadır.
• Safe Search: Gösterilen görselin, şiddet, cinsellik, ırkçılık gibi yasaklanması gereken ve Google tarafından depromote edilen içeriğe sahip olup olmadığını ölçümler. 1-5 arasında derecelendirilir, 1 en düşük 5 en yüksektir. Görselinizde bunlardan birisi 1’in üstünde ise değişmelisiniz.

Google, yukarıda göründüğü gibi Entity’ler arasındaki ilişkilere, hatta Entity’lerin söyledikleri sözlere dahi ‘Relationships’ veya ‘Quotes’ diyerek farklı attribüte sınıfları yaratmaktadır. Eğer, iki ayrı Entity’i aynı fotoğrafa koyduysanız aralarındaki ilişkiyi kolayca tanımlayacaktır. Bu noktada, ‘slander’ veya ‘dedikodu’ niteliği taşımayan ve bilimsel içeriği olan fotoğrafları kullanmanız YMYL Siteleri için şarttır.

Google’ın Semantic Görselleri Entity’lerle Eşleştirme Patentinden bir alıntıdır. Farklı fotoğraflar, aynı entity etrafında benzer şeyler söylemektedir.

Image Entity’ler ile ilgili Google Lens, Pixar veya Pinterest’in bazı rekabet içindeki Applerine değinmek gerekir ancak konunun daha kısa tutulması için sadece Google’ın Image Query’leri nasıl Map ettiği aktarılacaktır.

Eğer Görsel ile arama yaptıysanız:

• Görseldeki entity’ler tanımlanır.
• Entity’ler ile önceden bağdaştırılmış sorgular tanımlanır.
• Her query için farklı bir ilgi score’u atanır.
• Farklı score’daki sorgular birleştirilerek temsili ve yeni bir sorgu, görsele göre yaratılır.
• Yaratılan sorgudaki sonuçlar kullanıcıya sunulur.

Car sorgusunu, Türkçe dilini kullanan bir chrome’da arattığınızda, kolayca web search davranışlarının image search’ü etkilediğini göreceksiniz. Aynı sorguyu, trend değiştikçe tekrarladığınızda ‘Bubble’ların da değiştiğini deneyimleyeceksiniz. 

Eğer sorgu ile görsellerde arama yaptıysanız:

• Sorgudaki entity’ler listelenir.
• Entity’ler arası ilişki çıkarılır.
• Olası ve ilgili sorgular/entity’ler için geçerli olan Landing Page’ler, sorgunuzdaki sonuç sayfası ile karıştırılır.
• Sorgudaki genel kullanıcı davranışlarına göre en iyi Landing Page’ler sunulmaya başlanır.

Daha fazla bilgi için Medium üzerinde Görsel Araması ile ilgili  yazdığım bazı makalelere göz atabilirsiniz. Ancak, Görsel Aramaları görselin kalitesinden çok o görselin bulunduğu en kaliteli Landing Page için geçerlidir. Bu yüzden daha bulanık, kötü boyutlu bir görsel, image search’te sizden daha yukarıda yer alabilir.

Belirli sorgularda yükselmek için görsellerinizin, harita sonuçlarınızın, video sonuçlarınızın sıralamasının web sonuçlarını da etkilediğini hatırlamalısınız.

Google, Patentlerinde görselleri yapay zekalarına inceleterek, hayvanların yeme, yaşama ve diğer doğal özelliklerine yönelik çıkarımlar yapabileceklerini belirtmektedir.

Entity-based Image Search Hakkında Bazı Öneriler:

• Görsellerinizin üstüne Google’ın okuyabileceği ve tutarlı mesajlar veren, confidence ve relevance score arttırabilecek yazılar yazın.
• Görsellerdeki nesneler, konu ile ilgili entity’ler ile birleşmelidir. Araba fiyatları hakkında yazdığınız bir yazıya, araba süren birisini koyduğunuzda, söz konusu ‘birisi’ image’in entity classification’ınını değiştirebilir.
• Görselleriniz internette yaygınca kullanılmış ise Image Entity Classification, text entity classification’ı farklı bir yönde etkileyebilir. Örneğin, tatlı tarifi yazısına koyduğunuz bir fotoğrafta ünlü bir firmanın logosunun olması veya ‘semantic bir entity’ bulunması, yazınızın kategori scorunu etkileyebilir.
• Fotoğraflarınızda, ne olursa olsun asla ‘reklam’ entity’si olmamalı. (YMYL Sitesi iseniz.)
• Fotoğraflarınız asla ciddiyetsiz olmamalı. (YMYL Sitesi iseniz.)
• Fotoğraflarınız, asla mutsuz, öfkeli veya samimiyetsiz olarak Google Yapay zekası tarafından algılanmamalı. (Yüzlerden bahsediyorum.)
• Fotoğraflarınıza güvenilir ünlüleri, ilgili konularda tanınabilir şekilde özgün fotoğraflarla koyabilirsiniz.
• Fotoğraflarınızda, Google Guideline’ına aykırı olan, şiddet, çıplaklık, ırkçılık ögeleri asla bulunmamalı.
• Fotoğraflarınızın bir köşesine firmanızın logosunu koymanız, fotoğraflarınızın internete yayılması halinde, logonuzun Google tarafından ‘yaygın ve güvenilir’ olarak tanımlanmasını sağlayacaktır. Bu nedenle, firmanızın logosunu Vision AI ile tanınabilir bir hale getirtmek için önce Google’a onu pek çok farklı yerde göstermelisiniz.
• Fotoğraflarınızı seçerken, o fotoğrafın hangi ‘Representive Query’i’ ifade ettiğini, Google Görsel araması ile kontrol edin. Böylece, text ile olan Query uyumunu sağladığınızı veya sağlayamadığınızı göreceksiniz.

Bu kadarı yeterli…

Belki aynı şekilde, bir gazetecinin savunduğu görüşü, uzmanlık alanını, bir siyasi partinin müttefiklerini ya da karşıtlarını da algılayabilir.

Makalenin sonuna yaklaşırken, Entity-Related Search noktasında faydalanmamız gereken bir nokta daha var. O da Local Search.

Local Search ve Entity Ağı, Web Search’e Olan Etkisi

Eğer birisi Google, ilk hangi noktada Entity-based Search Engine olmaya karar verdi derse, yanıt olarak Local Search diyebilirsiniz. Özellikle de Local Search sorgu ve yanıt sayısı, mobil cihazların kullanımının artması ve Google’ın vizyoner biçimde mobile-first indexing’e veya entity-first indexing’e geçmesiyle ciddi oranda arttı.

Google’ın ‘Detection of Similar Local Entities’ patentinden, benzer local entity’leri Search Results ve Knowledge Graph Entity desteği ile bulunabileceğini gösteren bir şemadır.

Aynı sorguyu, masaüstü bir bilgisayardan çalıştırdığınızda, karşınıza bir harita sonucu çıkmasa da telefonla gerçekleştirdiğinizde, karşınıza bir harita çıkması daha olası… Google’ın çeşitli sorgularda, iş yerlerinin sıralamalarını değiştirmek için konum bilgisine ihtiyaç duyması ve yorum yaptığınız yerlere gerçekten gidip gitmediğinize bakması (foot-traffic), Mobile-Entity First Indexing’in daha kaliteli ve kişisel sonuçlar sunmaktaki gücünü arttırdı.

Local Search İçin Geçerli Entity’ler Nelerdir?

Rakibinizin kendisini Local Search içinde konumlandırdığı entity tipleri, Google’ın Brand-Entity’e yönelik sınıflandırmasını etkileyebilir. Google, bir haber/bilgi kaynağının belirli sorgularda sıralanmaya değer olup olmadığına, Brand-Entity’nin ana kategorilerine bakarak karar vermektedir. Örneğin, bir kredi/finans entity’si bir magazin içeriği yayınlasa dahi sıralamalarda bir umut beslememesi gerekmektedir. Bunu bazı noktalarda, Topical Authority ve Topical Layer, Related-Entities and Queries gibi farklı kavramlarla/patent şemalarıyla bu makalede veya webinar sırasında açıkladım.

Local Search Entity’nizi, Structured Datanız, Semantic HTML’iniz, Makale Yapınız yani Entity-Profile’iniz ile tutarlı bir hale getirmelisiniz. Peki, rakiplerinizin kullandığı Entity Search Class’ını nasıl anlayabilirsiniz?

Local Search ve Local Business Entity Sınıfları

Rakibinizin kullandığı Local Business Kategorilerini, Local Search Sonuçları üstünden bulmak için izlemeniz gereken adımlar aşağıdadır: 

Google ait Determining The Quality of Locations Based on Travel Time Investment, patentinden herhangi bir Local Entity’nin, yolculuğa değer olup olmadığını anlamaya çalışan algoritmanın bir şemasıdır.

CID Numaranızı bulmalısınız. Customer Identity Number, GMB tarafından kullanıcılara verilen numaradır. GMB Forumlarında, Google’ın size hitap etmek için kullandığı ve Entity’nizi local search için ifade edecek kod parçacığıdır.

CID’i bulabilmeniz için izlemeniz gereken iki yöntem mevcuttur.

1. Google Maps’te firma adınızı aratın.
2. Kaynak koduna giriş yapın.
3. CTRL+F ile ‘ludocid’ parçacığını aratın.
4. Ludocid\\u003d sonrası ve #lrd arasındaki sayı CID Numaranızdır.

Diğer yöntem ise:

1. Google Maps’te firma adınızı aratın.
2. URL’de 0x ile başlayan iki kısmı bulun.
3. İkincisini seçin ve ! işaretine kadar kopyalayın.
4. Hex Dec Converter’dan geçirin. 
5. İlk baştaki numarayı böylece elde edeceksiniz.

Ben aynı işlemi içerik bulutu için gerçekleştirdim. İçerikbulutu’nun CID Number’ı ‘11767470842038548597’. Peki bunun Entity’lerle ilgisi nedir?

Eğer, baktığınız kaynak kodunda CID Numarasını bulamıyorsanız, muhtemelen firmanın Entity Sınıflandırmasını da bulamayacaksınız demektir. Bunun temel nedeni, firmanın Google Maps sonucundan yani Entity-Listing’inden kaynak koduna girmek yerine bir Search Term’den kaynak koduna girmiş olmanızdır.

CID Numarası ve Brand-Local Entity Sınıflandırmasının İçerik Otoritesine Etkisi

İçerik Bulutu’nun Entity Class’ı ise aşağıdadır:

Sağdaki, GCID kavramı, seçilen kategorinin Google tarafından hangi dosyaya konduğunu belirtmektedir. Kaynak kodunda gördüğünüz ilk sınıflandırma, ‘Main Entity Class’tır.’ Tıpkı, NLP’nin Text Categorization kısmında gerçekleştirdiği gibi bir Main Entity, birden fazla class’a sahip olabilir.

Örneğin, ben Hangikredi için aşağıdaki Entity Class’ları seçmiştim.

• Finans Kurumu
• Sigorta Acentesi
• Kredi Danışmanlık Hizmeti
• İnternet Pazarlamacılığı Hizmeti

Google’ın tüm GCID Klasör adlarını İngilizce yazması ile tüm Entity-based sistemi yaratan Developer ekibinin dilini ve algı kaynağını da hayal edebilirsiniz. LocalSearch’te seçtiğiniz Entity Sınıfları, Domain Kategorizasyonu ve Brand-Entity’nin Topical Authority’si için önemlidir. Bir diğer altını çizeceğimiz nokta ise bu kategorilerin sınıflandırılışıdır.

[\”criminal_law_attorney\”]\n,[\”lawyer\”]\n,[\”justice\”]\n,[\”law_firm\”]\n,[\”legal_services\”]\n,[\”trial_attorney\”]\n,[\”business_service\”]\n,[\”personal_services\”]

[\”Handyman\”,\”Bathroom Remodeler\”,\”Business Service\”,\”Carpenter\”,\”Ceramics\”,\”Construction and Planning Services\”,\”Construction Company\”,\”Craft\”,\”Decoration\”,\”Dry Wall Contractor\”,\”Fence Contractor\”,\”Flooring Contractor\”,\”Furnishing\”,\”General Contractor\”,\”Home Furnishings\”,\”Home Services\”,\”Interior\”,\”Kitchen Remodeler\”,\”Kitchens\”,\”Machining\”,\”Services Companies\”,\”Tile Contractor\”,\”Tradesperson\”,\”Wood\”]

Hangikredi ve Rakip 1 arasındaki kategori kıyaslamasını görebilirsiniz. Seçtiğiniz Entity’lerin daha kapsamlı/tanımlayıcı olmasına ve Local Search’te daha geniş bir bölge hedeflemesiyle Web Search Hedeflerinizi ifade etmeniz, Search Engine için önemlidir.

Yukarıda, GMB Kategorilerinin, nasıl Entity Hiyerarşisi içine yerleştirildiğini görmektesiniz. Diğer bir deyiş ile Entity-Relations ve Entity Attribütes daha açık biçimde ortaya çıkmaktadır. LocalSearch’te belirli sorgularda hangi class’taki entity’lerin daha üst sırada yer aldığını anlayarak kendi Brand-Entity’niz ve aynı zamanda da NLP üstünden denetleyeceğiniz content’in temel sınıfının ne olması gerektiğini çözümleyebilirsiniz.

Ayrıca, yukarıda gördüğünüz karmaşık dosyalama biçimindeki her parantez içi kısım firmanın kullandığı kategori değildir. Kullandığı kategorilerin üst kategorileridir. Örneğin, bir hukuk firması, kendisi için Lawyer’ı seçtiğinde, ne tip bir Laywer olduğunu, firmanın Justice departmanı içinde bir Hukuk Firması olup, duruşmalara katıldığını, personal/business düzeyinde hizmet verdiğini doğruca anlayabilmektesiniz. 

Buraya, Bing’e ait bir patent yerleştirmek istedim. Patent adı, Rich Entity for Contextually Relevant Advertisements

Patentin işlevi ise bir sayfadaki Entity’i tanıdıktan sonra ‘Context’ini çıkararak, sayfadaki reklamların, context’e uygun olup olmadığını anlamak. Aynı şekilde, Search Engine’in, Brand-Entity’nin Local Context’i ile Web Context’i arasında bağlantı kurabileceğini düşünmeniz güç değildir. 

İşlerin, böylece Google için ne kadar kolaylaştığını düşünün… Tek tek her contentteki keyword’lerin sorgularla eşleşip eşleşmediğine spama maruz kalarak bakan, Keyword-based bir Search Engine yerine, önceden hafızasına yerleştirilmiş kavramlara göre interneti tarayan, contenti gerçekten anlayan bir Search Engine…

Görsellerle, harita sonuçlarıyla, videolarınızla, sosyal medya hesaplarınızla ve içeriklerinizle, tüm entity-based Search Engine alanlarında, ‘Belirsizlik Etkisi’ni’ en aza indirerek her zaman tutarlı bir Brand-Entity Topical Authority-Relevance sergilemelisiniz. İçeriklerinizi, GMB üstünden belirli entity’lere ve ‘hizmet alanına’ yönelik düzenli biçimde yayınlarsanız, web-map sonuçlarını paralel biçimde iyileştireceksiniz. 

Web sonuçları, Map’i, Map sonuçları Web’i, News sonuçları Web’i, Image Sonuçları News’ü diğer bir deyiş ile sosyal medyanın da dahil olduğu biçimde, her yerdeki sonuçlarınız, Entity-Based biçimde tüm markanızı etkilemektedir. Buna, AppStore, TV, Homespeaker’lar, Sesli Arama yapılabilen arabalar, kulaklıklar ve dahası dahildir!

Bütün bunları aktardıktan sonra, bazı Natural Language Processor API odaklı Entity-based Content Optimisation önerileri vererek makaleyi sonlandırmak istiyorum.

Google Natural Language API Verilerine Göre Kısa Content Önerileri

Sorularla Yanıtları, HTML ve Content Düzeyinde Yapılandırarak Birleştirmek

Diğer bir deyiş ile, Nasıl, Neden, Niçin, Nedir, Kim → [Entity] yapısından sonra,
[Entity] → ‘x,y,z,d,a,b,c’’dir.

Sorularınızla yanıtlarınız birbirine yakın biçimde konumlandırılmalı.

Örneğin, aşağıdaki gibi herhangi bir Entity hakkında yazarken, onun hakkında en çok sorulan soruları ve özellikle de son zamanlarda trend olan sorguları listelemeniz gerekmektedir.

Sorularla yanıtlarını content içinde, aralarına daha fazla ‘word dependency’ yerleştirmeden, kısa biçimde sıralamalı, Semantic HTML ve Structured Data içinde işaretlemelisiniz. Google, bir contentin neyi anlattığını ve hangi sorguya yanıt verdiğini en iyi, soru-yanıt odaklı ve yalın içeriklerle algılamaktadır. FAQ benzeri Schema Markup’ları öne geçirmesi ya da Featured Snippet’lerin genelde bu yapıda olması, tesadüf değildir.

Sözcük Sınıflandırmaları, Türleri ve Sorgu-Kalitesi

NLP’nin makale içindeki adımlarını daha önce sıraladığımız gibi Google’ın 516 milyon parameter’dan ve variable’dan oluşan gelişmiş yeni metin özetleyici yapay zekasından da bahsettik. Pegasus adlı bu yapay zeka ile Google, özellikle çağrı merkezlerinde her çalışan başına 2,6 saat verimlilik arttırmayı amaçlıyor. Peki, Google neden bu kadar kaliteli bir content özetleyiciye ihtiyaç duydu dersiniz?

Core Güncellemelerinin Google’ın ‘Cost Management’ı ile ilgili olduğunu belirtmiştim. Aynı nedenle, milyarlarca GB ağırlığındaki contenti daha öz biçimde algılamak isteyen Google’ın basit soru-yanıt biçimindeki rahat anlaşılabilir contentleri promote etmesi de tesadüf değil.

Sözcük Türlerinin Sözcük Sınıflandırmaları ile ilgisi nedir?

Diyelim ki birisi size, Mustafa Kemal Atatürk’ün boyunu sordu. (Google’da her sorgunun sonunda ‘?’ olmasa dahi, her sorgu aslında bir sorudur ve her sorgunun ardında çabuk giderilmesi gereken bir merak vardır, Mobile Web Stress testlerine göre Google, bir kullanıcıya 10 saniyeden kısa sürede yanıt veremediğinde, kullanıcıların yarısının odağını kaybettiğini gözlemlemiştir.) Böyle bir durumda, ‘sayı’ veya ‘uzunluk birimi’ kullanmadan yanıt vermeniz mümkün değildir.

Eğer, contentiniz içinde, santimetre, metre gibi birimler ve sayı birimleri geçmiyorsa, NLP kısa sürede contentinizin bu sorguya yanıt vermediğini anlayacaktır. 

Aynı zamanda, boy uzunluğu da bir Entity’nin child entity’si yani attribute’dür. Google’ın bu verileri çok daha ayrıntılı bir hale zamanla getireceğine eminim. Aynı zamanda, Wikipedia’ya olan Google Knowledge Graph güvenini de rahatça anlamak mümkün…

Benzer şekilde, tavuk için en doğru ‘pişirme sıcaklığı’ sorulduğunda temiz bir HTML-Content yapısı ve görsel üstünde yanıt veren ‘Sıcaklık’ derecesi içeren bir yazı ile yanıt görüyoruz. Aynı metni, NLP API’ye atarsanız, sıcaklık biriminin algılandığını göreceksiniz. Bu nedenle, bir sorguya yanıt verirken mutlaka ilgili birimleri ve kavramları metin içinde kullanın. Özellikle, fiyat başlığı attıysanız, para birimlerini ve fiyat aralıklarını sayısal biçimde, temiz bir tablolama ya da listeleme ile birleştirin.

Gördüğünüz gibi metin içinde verdiğiniz bilgiyi, görsel ile de vermeniz mümkün. Görsel SEO’su, alt etiketlerinden çok daha öteye geçmiş durumda…

Kısa ve Öz Yazmanın Entity Recognition ve Word Dependency’e Olan Katkısı

Google’ın Entity-based Search Engine olmasındaki temel amacının bir Star Trek Bilgisayarı olmak olduğunu daha önce belirttim. Mobil cihazlar üstünden özellikle sesli aramalara yanıt vermek istemesi, BERT Dil Algoritmasını kullanmaya başlamalarının temel nedeniydi çünkü sesli sorgular, yazılı sorgulara göre daha uzunlar. Haliyle Google kendisini bir ölçüde uzun sorguları anlayabilmek için entity-relations’larla yeterli hale getirdi.

Ancak bir de şöyle düşünün. Hangi content’i daha iyi anlayabildiği, anlamak için daha az vakit harcadığı ve hangi Query’lerle eşleştirilebileceği de aynı zamanda Crawl Budget/Efficiency meselesidir. Eğer uzun ve karmaşık cümleler kurarsanız, NLP API için belirttiğimiz Word Dependency ağının çok ciddi şekilde uzadığını göreceksiniz.

Aynı şeyi söyleyen iki cümle arasındaki, karmaşıklık ve Word Hoop düzeyi ortada değil mi?

Google’ın ‘noktalama’ işaretlerine dikkat ettiğini de kolayca fark edebilirsiniz. Merak edenler için ikinci cümle:

‘That can best express the very best cooking temperature for chicken is absolutely 155 degrees, which will provide fully cooked and restoring the flavor of the chicken.’

Arama Motoruna sade ve yalın bir yanıt sunmak, içeriğinizin hem kullanıcı hem de yapay zeka tarafından daha rahat anlaşılmasını sağlayacak.

İki cümle arasında, toplamda 20’den fazla ‘hop’ farkı bulunmakta ve sözcüklerin birbiri ile bağını çözmek için en uzun ‘hop’ 24 sözcük atlamaktadır. Optimum örnekte ise toplamda 9 hop bulunmakta ve en uzunu 4 sözcük uzunluğundadır. Yeni nesil Entity-based Content Optimizasyonunda ileride, daha sık duyabileceğiniz kavramlar ve kıyaslamalara bir örnek…

Kesin Verilerin Entity-based Search Engine Tarafından Algılanması

Google, herhangi bir şekilde bir datanın doğruluğunu veya yanlışlığını anlayamamaktadır ancak yazı içinde belirttiğimiz gibi belirli sinyalleri toplayarak bir confidence/relevance score’u çıkararak, Knowledge Base’e kaydettiği verileri güncellemekte ve doğru olarak varsaymaktadır.

Konu ile ilgili aşağıda Danny’nin bir tweetini göreceksiniz.

Google’ın özetleyici bakış açısında, sunduğunuzun verilerin doğruluğu otoriter ve yaygın bilgiye olan uyumun Entity Data Base’e paralel olup olmaması ile ölçülebilmektedir. Örneğin, bir önceki ‘Tavuk için en iyi pişirme sıcaklığı 155 derecedir.’ örneğini, Google’a ‘70 derecedir’ olarak değiştirerek girdiğinizde de karşınıza Featured Snippet çıkmaktadır. Farklı bilgiler sunan bu iki makaledeki verilerin aynı amaç için doğru kabul edilmesi durumu ise daha çok kullanıcının tercihlerine bırakılmış durumdadır. Ancak, Entity Base’e kayıtlı olan bir veri hakkında girdiğiniz yanlış veri doğruca E-A-T Değerinizi düşürecektir. Örneğin, bir ülkenin başkenti, bir politik partinin lideri, bir tarihi bilginin yanlış girilmesi, Google tarafından daha bariz bir hata olarak  görülecektir.

Google’ın ‘Phrase-based searching in an information retrieval system’ adlı patentinden bir bölümdür. Buna göre, ‘Bir metindeki kavramlar-söz öbekleri listelenir → Hangi query’leri yanıtladığı belirlenir → Bu query’leri en iyi yanıtlayan mevcut sayfalar alınır → Bu sayfalardaki ‘standart kavramlar ve söz öbekleri çıkarılır. → Sorgulanan metin buna göre değerlendirilerek indexe yerleştirilir. → Olası gelecek sorgular ve bilgi modelleri hafızaya alınır.’ Phrase-based Indexing ve Entity-based Search ile ilgisini, Bill Slawski ile kısa bir diyalog içinde, aşağıda bulacaksınız.

Phrase-based Search Patentleri, Entity-Based Search Network’ünü geliştirmektedir. Belirli söz öbekleri, cümleler veya ifadeler belirli konulardaki yazılarda sıklıkla geçiyor ise Google bu söz dizimlerini ‘check list’e’ eklemektedir. Bu noktada, Entity-based Search Engine, Phrase-based Search Kalıtımıyla, sonuçlarının doğruluk oranını arttırdığı gibi ‘index’ ve ‘crawl’ sürecini hızlandırmaktadır.

Tavuğun en uygun pişirme sıcaklığı için farklı dereceler girdiğinizde karşınıza çıkan Featured Snippet’lerin ise gruplandığını görmektesiniz. Örneğin, ‘Eksi 55’ derece veya ‘+ 999’ dereceli bir içerik herhangi bir şekilde Featured Snippet’e girememektedir. Böylece, milyonlarca parametreye sahip bir yapay zekanın her kullanıcı için en doğru seçimi her contenti tarayarak alabildiğini ve alabileceğini görmeliyiz.

Google NLP API için Yazılarınızda Kesin Veri Sunmanın Faydası Nedir?

Belirli bir sorguya uzun bir yanıt vermenizin önemi yoktur. Bilgiyi en kısa sürede en açık biçimde sunmalısınız aksi halde Google sorguya yanıt verdiğinizi veya vermediğinizi ya da doğru/doğruya yakın bir yanıt verip veremediğinizi göremeyecektir.

Sorgu: ‘Osmanlı İmparatorluğu ne zaman kurulmuştur.’
Yanlış Tutum: ‘Bu konuda çok farklı görüşler vardır. Bazıları …………………….. . Bir kısmı ise ……………….. . Ancak genel bilgiye göre 1299 …………….. yılında kurulduğu kabul edilmektedir.’

Doğru Tutum: ‘Osmanlı İmparatorluğu, 1299 yılında Osman(Ataman) Bey tarafından Söğüt’te kurulmuştur.’

Ardından, farklı alt başlıklar altında, farklı iddiaları gene sorular ve kısa-kesin yanıtlar halinde vermeniz Google’ın işini kolaylaştıracağı gibi daha geniş bilgi sunmanızı da sağlayacaktır. Kabul edilir ve kurulmuştur biçiminde cümle bitirme örnekleri de Google için farklı derecede ‘kesinlik’ bildirisidir. Aynı zamanda, Sentiment Analyze kısmında da bunları gözlemleyebilirsiniz.

Belirgin Özneler Kullanımının Entity-based Content Optimizasyonuna Etkisi

Sunduğunuz verilerin kısa, öz ve kesin biçimde sunulması gerektiği gibi öznelerin de kesin olması gerekmektedir. ‘O’, ‘Şu’, ‘Bu’ gibi sözcükler Google tarafından algılansa dahi cümlenin anlamındaki ‘Confidence Score’u’ düşürebilmektedir.

‘Öğretmen Kemal ve Dünyayı Kurtaran Adam filmlerinde, Cüneyt Arkın oynamıştır. Aynı zamanda O, 2000’li yıllarda yeniden çekim yapılması için yapımcılarla görüşmüştür.’

Burada ise Boston Red Sox’un yöneticilerinde ‘Babe Ruth’u görmektesiniz. Gerçekte ise Babe Ruth, bu takımda asla yöneticilik yapmadı. Google, Wikipedia’daki makaleyi yanlış algılayarak, yönetici olduğuna karar verdi. Muhtemelen burada Machine Learning, öğrenilmiş bir hatayı tekrarladı. Google’ın anlayabileceği biçimde, özneyi nitelemeniz, bu nedenle daha önemlidir.

Giriş cümlelerinin tamamında, özne’nin keskin bir biçimde belirtildiğini göreceksiniz. ‘Knowledge Graph’ içinde belirtilen yerlerin önemli kısmı Wikipedia’dan alıntıdır, tutarlı biçimde sunulan keskin ve kesin bilgiler, Knowledge Graph tarafından dosyalanmaktadır. ‘Chinese’ örneğinde ise invented entity’si için kullanılan kavram yapay zeka tarafından doğruca kabul edilmiştir.

Buradaki eksik Özne ve nesne kullanımları Google için verinin ‘kesin olmayan ve belirsiz olan’ olarak işaretlenmesine neden olacaktır. Birincisi, ‘O’ zamirinin, Cüneyt Arkın’ı niteleyip nitelemediği belirsizdir, ikincisi Cüneyt Arkın hangi filmin yeniden çekiminin yapılması için görüşmüştür? Hangi yapımcılarla görüşmüştür? 2000’li yıllarda ancak tam olarak hangi yılda görüşmüştür?

Gördüğünüz gibi belirsiz pek çok soru bulunmaktadır. 2 satırlık bir cümlede dahi Google’a girilen pek çok sorguya yanıt verebilirsiniz. Bu nedenle, her cümle birbirinden kesin bir şekilde ayrılmalı, her soruya kesin biçimde ve kısaca yanıt verilmeli. Google, böylece sizi daha fazla Featured Snippet’e koyabileceği gibi daha fazla sesli sorguda yanıt kaynağı olarak kullanacaktır. Bir süre sonra ise News Source ve Featured Snippet Kaynağı olarak güvenilir kaynaklardan birisi biçiminde, Arama Motoru tarafından nitelendirileceksiniz.

‘Wwii, Second World War’a göre yeterince belirgin bir entity ifadesi değil. Bu nedenle, belirgin entity kullanımı hem özne hem de nesne boyutunda, Arama Motorunun davranışını değiştirmektedir. İlk sonuç sayfasında, ayrıca WWII, yazı içinde ana ifade olarak geçmektedir. Google, aynı anlama gelen farklı yazılış biçimlerine göre de kullanıcının aradığı şeyin farklı olabileceğini düşünmektedir. ‘The Vocabulary Problem’…

Bir diğer örnek ise ‘Türk Sinemasını eleştiren Cüneyt Bey, yeni filmlerin eski vizyonu paylaşmadığını belirtti.’ cümlesi olabilir.

NLP Türkçeyi desteklemese dahi Google’ın algılama biçimini buraya kadar okuduysanız artık biliyor olmalısınız. Bu cümlede, çıkarılabilir tek Named Entity, ‘Türk Sinemasıdır.’ Cüneyt Bey’in kim olduğu, yeni filmlerin hangisi olduğu, eski filmlerin hangileri olduğu, vizyonlarının adlarının ne olduğu belirsizdir. Her birisini isimleri ile kesin biçimde yazarsanız, daha yüksek Confidence ve Relevance Score alacak ve daha fazla entity’i yazınızda içererek, Entity-Relation Profile’i ile daha ilgili görüneceksiniz.

Google İçin Doğru Yanıtı Önce Verin, Ayrıntıyı Sonra Ekleyin

Bu başlığı, ‘Doğru ve Öz Yazmak Yeterli Değil.’ biçiminde de okuyabilirsiniz. Öz yazı içinde eğer doğru yanıtı, bazı ‘gerekli ancak uzun’ yanıtların ardına koyduysanız, Google muhtemelen sizi Featured Snippet’lere, Sesli Sorgulara çıkaramayacağı gibi içeriğinizde sunduğunuz verinin yanıt olup olmadığını da anlayamayacaktır.

Örneğin → ‘Grip kaç günde geçer?’ sorgusuna ‘Kişiden kişiye değişir.’ yanıtı vermeniz ‘doğru’ ve ‘öz’dür. Ancak Google için yeterli bir giriş değildir. Burada yapmanız gereken belirli bir gün aralığını en önce Google’a gösterilebilecek kesin bir yanıt olarak verdikten sonra kişiden kişiye değişebileceğini ifade etmektir.

Gördüğünüz gibi alttaki yanıt daha da kesindir, nedeni içerikte kullanılan dildir ve Google buna güvenmektedir. Aynı zamanda, Google’ın farklı dillerde aynı SERP’i sunması, Entity-based Search Engine doğasından kaynaklanmaktadır. Bu nedenle NLP Türkçeyi desteklemiyor diyerek vazgeçmemelisiniz, keza Türkçe SERP’i de Entity’ler ile sınıflandırmakta, şekillendirmekte ve Entity’lerin ise dili yoktur…

Aynı şekilde → ‘İlk buluşma için gidilebilecek en uygun yerler’ sorgusuna ‘İlişkinizin geçmişi bu konuda etkendir.’ yanıtını ilk cümle olarak seçmeniz doğru ve özdür. Ancak, bunun yerine belirli yerleri listelemeniz, Google için çok daha değerli olacaktır. Keza, Google da Google kullanıcısı da yanıt istemektedir.

Salience Score’unuzu Arttırmanın Yollarını Deneyin

Keyword-based Search Engine’in Spama karşı olan savaşında TF-IDF, Related Keywords ve Eş Anlamlı sözcüklerin kullanımının sıklığına hem makale sırasında hem de webinarım sırasında değindim. Keyword-based Search Engine bir makalenin hangi sorgu ile ilgili olduğunu anlamak için Link-Graph’a baktığı gibi query’lerin davranış biçimine ve içerdikleri sözcüklere bakmaktaydı.

Salience Score ve Indıcator Entity arasındaki bağlantıyı aşağıdaki iki ayrı görsel ile daha iyi anlayacaksınız. ‘Rolling Stones → [Organisation(Magazine Entity)], Author → [Thing[Author Entity]), Suicide → (Event[Verb Entity]), Google bu sorguda, Brian Jones adında intihar eden bir Rolling Stones muhabirinden bahsetmektedir. İntihar olup olmadığını yeniden inceleyen bir haber yazısını ilgili seçim olarak göstermektedir.

Mevcut sorgu diziminin sonunda (Thing[Movie Entity]) konduğunda, Google, bir ‘film göstermesi’ gerektiğini düşünerek, size gösterdiğim-göstereceğim patentler aracılığı ile internetten topladığı verilerle oluşturduğu bir ‘Movie Entity’ olan ‘End of the Tour’u, Featured Snippet ile gösteriyor. Aradığınız şeyden tamamen emin olduğunda ise doğruca Knowledge Graph paneli göstermektedir. Burada, hem query hem de content içindeki ‘indicator entity’lerin’ etkisinin en yüzey üstündeki halini görmektesiniz.

Entity-based Search Engine ise Entity’ler arasındaki kullanım sıklığına ve ilişkilere bakmaktadır. Bu nedenle bir sorguyu hedeflediğinizde o sorgunun Entity’nin hangi yönüne odaklandığını görmeli ve makalenizin içine doğal biçimde o yön ile ilgili sub-entity’leri veya related entity’leri yerleştirmelisiniz.

Kullanıcının belirli bir amaca sahip olan ‘materialleri’ sorduğu düşünüldüğü için birbiri ile uyumlu tipteki materyalleri sıralamanız, odaktaki her bir entity’nin salience score’unu arttırmaktadır. Keza, yazılan maddelerin çoğu Google’dan alınmıştır. Aynı zamanda bu tip içerikleri  yazarken Images ve Shopping sıralamalarından, yoğunluğundan da faydalanabilirsiniz. Böylece, birlikte kullanacağınız Entity’ler için daha yüksek salience score’u elde etmenin yöntemlerini oluşturmanız kolaylaşacaktır.

Bu yüzden isimli entity’leri veya isimsiz entity’leri belirgin ve ilgili yönleriyle tam nitelendirmelerle ve kesin verilerle kullanmanız önemlidir. Keza, Google’ın NLP içinde gösterdiği her çaba, izlediği her adım, temelde bu amaç içindir.

Türkiye hakkındaki bir diğer makaleden alınmıştır. Makaleyi okumadan dahi konunun Türkiye’nin tarih içinde üye olduğu ve olmaya çalıştığı birliklerle ilgili olduğunu anlayabilirsiniz. Sunduğunuz temiz ve kesin verilere göre alacağınız Salience Score, ‘Hakkındalığınızı’ etkileyeceği için doğrudan bir sıralama faktörüdür.

Topical Layer ve Topical Authority ile Olası Sorguları SERP Mapping İle Birleştirmek

Topical Layer, belirgin bir isimli entity’nin alt entity’leri yani attribüte’leridir. Örneğin, Fenerbahçe sorgusunda, Fenerbahçe’nin oyuncuları, yöneticileri, maçları, ödülleri ve her birisi topical layer’lardır. Topical Authority ise belirgin bir entity’nin tamamını her yönü ile kapsayan içerik ağına sahip olmanın karşılığıdır.

Google, Fenerbahçe’yi sadece futbol takımı olarak tanımlamakta ve futbol oyuncularını sıralamaktadır. Basketbol veya farklı spor dallarındaki varlığını henüz yeterince confidence score’a sahip görmediği için/hafızasına almadığı için dizine koymamaktadır.

Bir topic için her layer’da içerik yazmanız da tek başına yeterli değildir. Kullanılan hedef Entity’nin genişlik düzeyine göre SERP’te inceleme yapmalısınız. SERP sonuçları değişmeye başladığında muhtemelen farklı bir Topic Layer’ına geçilmiş ve farklı Sub-Entity’ler Arama Motorundan listeleniyor olacaktır.

Bu nedenle, Topical Autohirty yaratmak için bir Topical Layer’da ilgili tüm sorguları, SERP incelemesi ile content’inze yerleştirmelisiniz. Google, her content’te tek bir soru sormaktadır.

‘Bu WebPage, kaç farklı kullanıcı tipinin kaç farklı ihtiyacını/sorgusunu hangi hızda ve düzeyde tatmin etmektedir?’

Bu yüzden, içeriklerinizi sorularla ve kullanıcının ihtiyaç duyduğu fonksiyonlarla, Google’ın Entity-Query Map anlayışıyla oluşturarak birbirine bağlamalısınız. 

Image Source: Maximilian Nickel, Knowledge Graph Entity Mapping.

Eğer Mevduat Faizi ile ilgili bir ürününüz var ise informational kısmına, içinde mevduat faizi kavramını geçirebilecek tüm sorguları yanıtlandıran bir içerik yerleştirmeniz, Relevance ve Quality Score’nuzu arttıracaktır. Bu noktada, Eoghan Enn’in Güneş Gözlükleri üstüne gerçekleştirdiği SEO Case Study’sini de okuyabilirsiniz. 

Entity’leri Belirginleştirme ve Yardımcı Entity’leri İçerik İçinde Kullanma

Aynı isimde iki kitap, aynı adda iki şehir veya iki film bulunabilir. Bu durumunda, hangi Entity’den bahsettiğiniz Google için bir karmaşadır. Böyle durumlarda, confidence score ikiye bölünecektir. Bu yüzden, Entity’leri belirginleştirmek için daha önceki Cüneyt Arkın örneklerinde belirttiğimiz gibi yardımcı entity’leri de aynı cümle içinde kullanmalısınız.

Ancak bunu Meta Etiketleriniz, HTML Structure’nız, Structure Data’nız, Content Structure’nız ile destekleyerek yapmalısınız. Entity’niz ile ilgili en belirgin Related ve Sub-Entity ögelerini ilgili biçimde kullanmalısınız. Bu noktada, özellikle Google’ın Fat Check Explorer adlı toolundaki sonuçları kullanabilirsiniz. Çünkü E-A-T Kavramını birebir yansıtan bu sayfalar, aynı zamanda içerdikleri Entity’ler hakkındaki en ince ayrıntıları dahi vererek rehber örneğindedir.

Özellikle de yer adlarında bu tip sorunlar yaşanmaktadır. Örneğin, Brighton hem UK’de hem de US’de bulunan bir şehirdir. Bu bağlamda, Michigan Entity’sini veya England Entity’sini aynı cümle içinde geçirmeniz gerekmektedir. (Aynı makale içinde geçirmek, yeterince özelleştirme sağlamayabilir.)

Buna benzer bir örneği, Google’ın Computerized Systems and Methods for Enriching a Knowledge Base Search Queries adlı patentinde de bulabilirsiniz.

Buradaki patent şemasındaki durum, görseller için geçerli olsa da text içindeki Entity Recognition süreci için de geçerlidir. Buna göre Google, bir görseldeki objeleri parçalara ayırmakta, entity’leştirmekte ve ardından Knowledge Base’de kayıtlı bir attribüte ile birleştirmektedir. Image Entities bölümünde buna benzer bilgileri farklı dayanaklarla verdim. Görseller için de somut bir örnek vererek son bölüme geçelim.

New York’u görsellerde aradığınızda, Mariott Marquis Hotel için bir alan olduğunu göreceksiniz. Otelin New York’ta olduğunu gösteren sayısız görsel ve o görsellerle uyumlu ‘caption’ ifadesi bulunmaktadır ancak Google, görseldeki object entity’i tanıyarak onu knowledge base’indeki New York’a ait bir alt entity ile yani attribüte entity ile de birleştirmektedir.

Knowledge Graph’ta ise Marriott Marquis Hotel, Whisky Feast, GLADD, 2020 Qatar Grosskopf gibi farklı ‘event entity’lerin ‘location entity’si olarak New York içinde olduğu belirtilerek en güvenilir kaynaklarca geçirilmektedir. Böylece, görsellerle ve textlerle dünyanın hemen hemen her yerinde Marriot Marquis Hotelleri olmasına rağmen özellikle New York için böyle bir ‘bubble semantic query’ söz konusudur.

Entity-based Content Optimizasyonu İçin Diğer Öneriler

Main Topic Dışına Çıkmayan Piramit İçerikler

Topic-Cluster ve Pillar-Cluster Content (webinar sırasında aktarmıştım, complete, comprehensive, guideline niteliğindeki içerikler ve konu bütünleri) seçimini gerçekleştirdikten sonra, content içeriğinin başka bir topic cluster parçacığını içermemesine dikkat etmelisiniz. 

Google için bir webpage content’i, Main Content, Supplementary Content ve Ads.’ten oluşmaktadır. Main Content, Google’ın algısındaki bir Topic Cluster’ı tamamen kapsamalı ancak bir diğerine geçmemelidir. Supplementary Content’te ise diğer Topic Cluster’dan kısaca bahsedebilir ve contextual anchor linkler kullanabilirsiniz. Böylece, her entity ve o entity ile eşleşen query’lerin hangi sayfanızda yanıtlandırıldığı Google için temiz biçimde belli olacaktır.

Listeler, Tablolar, Entity Proximity ve Semantic HTML Kullanımı

Google Rater Guideline’a uygun bir biçimde içerik yazan ve buna rağmen sıralamalarda düşen pek çok site mevcut. Bunlardan bazıları, özellikle sağlık alanında hizmet vermekte… E-A-T Kavramının kendisi olsalar dahi, Technical SEO sorunlarını çözseler dahi her Core Güncellemesinde daha kötüye giden siteler de mevcut.

Google, Automatic Query Pattern Generation Patentinden bir şemadır. Query Mapping-Entity Matching için okumanızı tavsiye ederim.

Bu örneklerden birisi geçtiğimiz Core Güncellemelerinde konu olan WebMD için geçerliydi. İçeriklerinde otoriterlik, uzmanlık veya güvenilirlik sorunları yoktu ancak ciddi biçimde karmaşa içinde, bilgi mimarisinden ve yapılandırılmışlıktan uzak, uzun cümlelerle dolu ve topic-cluster’ların iç içe geçtiği contentler mevcuttu. Bu karmaşa nedeniyle kaybettikleri trafiklerini sonraki güncellemeler için yaptıkları değişikliklerle düzeltebildiler.

Document ranking based on semantic distance between terms in a document adlı, adı ve açıklaması  gayet net bir Google Patentindendir.

Google NLP API için Semantic HTML Kullanımı

Semantic HTML, Google’a ve diğer arama motorlarına hangi sayfa bölümünün ne için olduğunu söyleyen ve belirsizlik etkisini daha da azaltan bir araçtır. Content içinde kullanılması, Google’ın hangi bölümün ne için olduğunu anlamasını kolaylaştıracaktır. Özellikle de ‘section’, ‘header’, ‘main’, ‘aside’, ‘quote’, ‘author’ ve benzeri Semantic HTML kod örnekleriyle Google’a her şeyi temiz biçimde iletebilirsiniz.

Image Source: Seekbrevity.

Özellikle de hangi Query’nin hangi entity için hangi başlık altında olduğunu anlatabilmeniz için HTML ile sınırlandırılmış bir içerik Google için fast-food kavramını ifade eder.

Google NLP API için Listeler ve Tablolar

NLP için yazmak aynı zamanda Featured Snippet için yazmaktır. Makalelerinizde mümkün olduğunca unordered veya ordered listeler kullanabilirsiniz. Bu listelerin düzgün bir HTML yapısına sahip olmasına dikkat etmelisiniz. Ayrıca, her liste mutlaka belirgin bir soruya sahip Heading altında yer almalıdır. Liste üstündeki cümlenin uzun tutulması veya listenin heading’ten uzaklaştırılması durumunda featured snippetlerin kaybedildiğini gözlemledim. Burada, bir alt başlık açacağız:

Hybrid Content Structure Nedir?

Aynı konuyu daha iyi anlatıyor olabilirsiniz. Aynı Entity için daha iyi yapılandırılmış content’e de sahip olabilirsiniz. Ancak, bazı sorgular ‘sentimental’ anlamda, ‘öz ve gerekli’ yanıtlar istemektedir. Google, bu nedenle aynı amacı karşılayan en iyi iki içerikten, sorgunun doğasına daha uygun olanı seçecektir.

Aynı zamanda, rakipleriniz bu tipteki sorgu biçimlerini yanıtlandırarak Query2vec veya Word2vec mantığındaki pek çok sorgu tipinde, Google’a kendisini şartlandırmış olabilir. Örneğin, bir sözlük sitesi, ‘ne demek, nedir, x dilinde nedir’ sorgularını hedefleyen bir content structure ile çok geniş bir sorgu ağını ele geçirmiş olabilir. Bu durumda, her sorgu tipini ve kullanıcı tipini hedefleyen içerikleri uygun bir yapıda barındırmalısınız. Buna  ise Hybrid Content Structure denmektedir.

Google için belirli sorular sorulduğunda, onları adım adım veya madde madde açıklayan listeler, table body ve table head bölümlerine sahip (HTML Codes) düzgün yapılandırılmış ve kullanıcının aradığı terimlere sahip content parçalarını doğruca içerikte sunmak, Google için kesinlik, yapılandırılmışlık, hakkındalık, ilgililik scorelarının tamamını yükseltmektedir.

Bu noktada, mobil üzerinde tablolara sahip Featured Snippetlerin görüntülenememesi sorunu mevcut olsa da ilerleyen süreçte Google’ın çözeceğinden eminim.

Entity-Proximity ve Main-sub Entity İlişkisi

Google için bir cümlede ne anlattığınız, bir sonraki cümlede ne anlattığınız, bir sonraki paragrafta ne anlattığınız, bir sonraki başlık altında ne anlattığınız, bir sonraki URL’de ne anlattığınız, bunların arasındaki konu bağlantıları ve hangi sorguları yanıtladıkları önemlidir. Eğer bir önceki heading’teki konuyu bir sonrakinde tekrar anlatıyorsanız, belirli sorgulara yönelik confidence ve relevance scorelarınızın düştüğünü göreceksiniz. 

Bunu engellemek için seçtiğiniz Main Entity’i ilgili subheading’lerde barındırırken, sub-entity’i de barındırarak her makale bölümünün Main Entity’nin neyi ile ilgili olduğunu daha rahat biçimde anlatabilirsiniz.

Örneğin: Osmanlı İmparatorluğu ve Ekonomi, Osmanlı İmparatorluğu ve Sosyal Yaşam, Osmanlı İmparatorluğu ve Padişahlar veya İhtiyaç Kredisi Faizleri, İhtiyaç Kredisi Veren Bankalar, İhtiyaç Kredisi Başvuru Şartları gibi…

Böylece, hangi heading’in ne ile ilgili olduğu ve bir Entity’nin ne kadarını hangi content bölümlerinde nasıl kapsadığı net anlaşılacaktır. Proximity ise ilgili konu parçacıklarının, birbirine ne kadar yakın anlatıldığı ve ilgili Entity/Child-Entity kullanımının birbirine cümle içinde ne kadar yakın gerçekleştirildiği ile ilgilidir. Önerim, en yüksek Proximity’i yakalamanızdır. Böylece, daha az sözcükle daha fazla şeyi daha belirgin biçimde anlatıyor olacaksınız. Bu durum ise Google için daha yüksek Salience Score ve Entity Profile Analizi anlamına gelmektedir.

Structured Data Kullanımı ve Entity Extraction

Ben bu makaleyi yazarken Google, yeni bir içerik yayınladı. ‘Product’ Entity’lerini E-Ticaret sitelerinden toplayarak gruplandırabileceği bir yeni bir ‘İnternet versus Google’ kaçınılmazlığını gündeme getiren çalışmayla, kendisini E-ticaret platformu haline getirdi. Düzenlediğim webinar sırasında, Google Wallet, Google Pay, Google Play ve TV ile dahasına değinmiştim. 

Structured Data ve Ambient Computing İlişkisi

Google için her şey ‘Ambient Computing’ kavramıyla ilgili. Her yerde, her zaman her şekilde her bilgi ve tüketim ihtiyacınızı karşılamak artık Google’ın temel amacı. Bu yüzden Holistic SEO’yu ‘Bir Brand-Entity’nin tüm search görünürlüğünü ve dönüşümünü tüm cross-media çalışmalarıyla iyileştirmek’ biçiminde tanımlıyorum. Artık, ‘Modern Search is Everywhere’ sözünü ajanslarınıza asmalısınız. Çalışanlarınızın zihnine kazımalısınız. Kesit aldığım SERP’te görünen videoları izlemenizi tavsiye ederim…

Structured Data, neyin ne olduğunu, ne için gerektiğini, gerekmediğini, ne kadar olduğunu, rengini, boyutunu, fiyatını, işlevini en temiz biçimde Google’a tanıtan ve JSON-LD ile kullanıldığında parser-blocker etkisi de yaratmayan, ‘anlaşılabilirlik’, ‘taranabilirlik’ standartlarında iyileşme yaratan bir Arama Motoru ile iletişim metodudur. ‘Sesle okunabilir contentinizi’, ‘offline yüklenebilir contentinizi’, ‘eventlerinizi ya da superior holding firmalarınızı’ ve dahasını rahatlıkla Google’a iletebilirsiniz.

Structured Data ve Content Optimizasyonu ile ilişkisine gelir isek ‘Belirsizlik Etkisini’ azaltmak ve ‘Süreklilik içinde Arama Motoruna, tutarlı mesaj vermek için’ içeriklerinizde Structured Data kullanmalısınız. Böylece, Entity Extraction ve Entity Attribution Relation sürecini kolaylaştıracaksınız.

Sentiment Analysis ve Category Classification Süreci

Entity-based Content Optimizasyonunun en önemli parçalarından son ikisi, Duygu ve Kategori Analizi. Makalenizi yazdırırken/yazarken hedeflediğiniz Topic/Entity Cluster’daki ilk sırada yer alan makale kümelerinin Google tarafından hangi kategoride bulunduğu ve hangi ‘Confidence Score’ ile bu kategoriye yerleştirildiği önemlidir. Eğer yazdığınız makale, SERP’teki başarı göstergesi olan makalelerle aynı kategoride veya aynı confidence score’da değilse zararlı Hybrid Content Yapısına sahip veya Belirsizlik Etkisini olması gerektiği kadar azaltamamış olabilirsiniz.

Aşağıda, Google NLP API’ye göre var olan pek çok Content/Entity veya Topic Cluster Kategorilerini göreceksiniz.

Bu kadar ayrıntılı düşünen bir Arama Motoru için siz ne kadar ayrıntılı düşünüyorsunuz? Doğal olun gerisi gelir diyorsanız, bekleyebilirsiniz… Ancak, Entity-based Search Engine, sizin için çok uzun süre beklemeyecektir…

Google NLP API Content Kategorileri ve E-A-T Kavramı

Bir diğer konu ise Sentiment Analysis… Google için herkes E-A-T Kavramını tamamen kısaltmanın uzun açılımı kadar ele alarak mümkün olduğunca ayrıntı verin, doğal olun demekte… Ancak, E-A-T Kavramı kategoriden kategoriye değişmektedir. Eğer, kişisel bir anı anlatıyorsanız, sahip olduğunuz E-A-T en üst düzeyde algılanacaktır. Eğer bir yemek tarifi yazıyorsanız, E-A-T Standartlarına bir Rhinoplasty Surgery yazarı kadar ihtiyaç duymayacaksınız. E-A-T konudan konuya ve yazardan yazara, konunun işlenen yönüne göre değişecektir.

Bu nedenle, kategori analizi yapmanız daha da önemli, Real Estate veya Retailer kategorisindeki bir contentin yazarının Güvenilirliği daha öndeyken, bir Law/Justice Makalesinde ise Uzmanlığı da aynı derecede öne geçecektir. Ancak bir Hobi Yazısında, E-A-T Kavramının tanımı çok daha farklı olacaktır. Bu bölümdeki bilgiler doğrudan Google Rater Guideline’ındandır. Aşağıdaki işaretlenen kısma bakabilirsiniz: (Life Experience, kavramına dikkat etmelisiniz. Bazı kategorilerde, öne çıkmaktadır.)

Kategorilerdeki Confidence Score’ları çözümlerken, Credit Calculation’ Entity’sini kullandığınızda, sıralamalarda/sonuç sayfalarında ilerledikçe kategorilerin değiştiğini veya confidence score’un azaldığını göreceksiniz.

Sentiment Analysis ve İçerik Duygu Profilinin İçerik Güvenilirliğine Yansıması

Keyword/Entity Based Search Engine’ler arasındaki temel farklardan birisinin duygu analizi yetisi olduğunu belirtmiştik. NLP API adımlarını açıklarken, Google’ın hangi sözcüklerden ne şekilde duygu çıkarımı yaptığını da aktarmıştık. Bu bağlamda, belirli ve güçlü sözcüklerden belirli olumlu, olumsuzluk veya tarafsızlık biçiminde etkilenen Google için -1-0-1 arasında belirtilen derecelerde ve ‘magnitude’ kavramının ifade ettiği şiddette duygular bulunmaktaydı.

Kategorilendirme ve Confidence Score örneklerinde olduğu gibi Sentiment Analyze için de belirli kavramlardaki sonuç sayfalarını incelemeniz gerekmektedir. Google, çoğunlukla ticari/sağlıkla ilgili ve news kaynağı Brand-Entity’lerde tarafsız duyguların yansıtılmasından yana. Bu nedenle mümkün olduğunca resmi/ciddi bir dil kullanmanızı tavsiye etmeliyim. Ancak E-A-T Kavramının Life Experience-Personal Hobbies düzleminde değiştiği noktalarda, kullanıcının aradığı hissi veriyor olmanız da önemlidir. Aranan Entity’nin ve Query’nin yansıttığı duygu tonunun içerikte bulunması, uyuşması da aynı şekilde önemlidir.

Google’ı dava etmek istiyorum, sorgusunun bazı sonuçları…

Özellikle News Source Brand-Entity’lerde duygu yansıtılmaması ve saldırgan dil kullanılmaması önem taşımaktadır. Google, ‘slander’, ‘nefret’, ‘şiddet’ içerikli her içeriğe ve içerik parçacığına karşıdır. Web-Stress kavramıyla uyuşan ve insan sağlığını yavaş siteler gibi web üstünden tehdit eden her konu, yazı biçimi, sözcük kullanımı bu bağlamda Google için hem Sentiment hem de Context bağlamında önemlidir.

Slander, nefret ve yaralayıcı iddia haberlerini Google’ın depromote etmesinin temel nedenlerinden birisi, hakkında şu ana kadar açılan sayısız dava oldu. Aynı zamanda, siyasi çatışmalarda taraf olmak istememesi ve çoğunlukla bu tarz haberlerin tarafsız olmayan yayınlarca yapılması da gösterilen diğer nedenlerdendi. Aşağıda, Trump’a, ‘pure evil, childish, white nationalist, woman enemy’ gibi kavramlar kullanan bir haber makalesinin Sentiment Analyse’ini göreceksiniz.

Demo üstünden gerçekleştirilen hızlı bir kontrolde, makale, haberler/politika kısmında yer alsa dahi haber niteliği taşımadığı için confidence score’u oldukça düşük, aynı zamanda yansıttığı her duygu negatif işaretlenmiş durumda ve magnitude değerleri ise aynı derecede yüksek…

Aşağıda ise çok daha güvenilir bir Haber Kaynağından farklı bir kategorilendirme ve sentiment analyse göreceksiniz.

Burada dikkat ederseniz, Health/Health Condition/Cancer, News/Politics’den daha öncelikli bir kategori ve confidence score daha yüksek. Temel nedeni ise asıl incelemenin ‘Kanserin azalmasında Trump’ın rolü veya rolü olup olmaması üzerine’ olması… Böyle durumlarda kullanılan ‘Cancer, Medicine’ veya konuya özel farklı kurum/ilaç adları makalenin kategori değerini etkilemektedir. Gördüğünüz gibi bilimsel ancak kısmen de politik olan bir konu %90 oranında NEUTR duygularla ele alınmış.

Deducive’in Twitter üzerinden gerçekleştirdiği bir deney ve sonuçları. Mükemmel değil ancak dikkatli olunursa, anlatılabilir.

150.000 URL’i olan bir web sitesi iseniz ve sitenizde %80 oranında belirli yönde duygular sergiliyorsanız bu sizin Brand-Entity’niz için olumlu olmayacaktır. Google, Brand-Entity’lerin Domain-based ve Web-based olarak duygu/kişilik profilini çıkarabilmektedir. Makalelerinizde, yapay zekanın ve kullanıcıların duygularına hitap etmeden, marketing dili, espiri ve mizah dili kullanmadan ciddiyetle yazmanız daha doğru olacaktır. Bu nedenle, belirttiğimiz gibi:

‘Bu ilaçları içmezseniz ölürsünüz veya x ameliyatını olanların %25’inde y, z, d sorunları görünmektedir.’ değil → ‘X, d, c ilaçlarının alımı Doktor [Person(Entity)] ve Kurum [Organisation(Entity)] tarafından tavsiye edilmektedir. Yapılan Deney [Event(Entity)] sonrası, y, z, ve d durumlarına şu nedenlerle rastlanmıştır.’ benzeri bir üslup izlenmelidir.

Google NLP API, Google’ın Dil Algoritmaları ve Google Translate (Google’ın İçerik Algısı)

Google’ın kullandığı her dil algoritmasında ve geliştirmesinde, en büyük ümidi tüm local/keyword farklılıklarını ortadan kaldırarak algoritmasını besleyebilecek global bir feedback sistemi oluşturmaktı. Bunu zaten, Keyword/Entity Based Search Engine Farklarında belirttik. Peki, Google Translate’in Entity-based Content Optimizasyonundaki önemi nedir? Google, entity’leri ve local search farklılıklarını daha iyi anlamak ve Query-Entity Relation/Mapping sürecine dahil etmek için Translate API’si üstünde düzenli bir şekilde çalışmaktadır. Henüz bebek adımları attığı dönemde, Google’ın Translate üstüne ilk övündüğü şey ‘Arapça-İngilizce’ çevirisi yapabilmekti. Çünkü, İngilizce ve İngilizce bağlantılı dillerin tamamında erken dönemlerde dahi iyi bir iş çıkarabilmekteydi.

Yukarıda, Google Translate API’nin desteklediği dillerin bir kısmını görmektesiniz. Peki, bu dillerde Translate API’yi kullanmanız size ne gibi bir katkı sunabilir?

Yapmanız gereken Google’ın anlamakta/çevirmekte en usta olduğu dil (İngilizce) ile bağlantılı biçimde yazdığınız içeriğin dilini Google Translate API’den geçirmek ve Google’ın içeriği ne kadar güzel çevirdiğine bakmaktır. Eğer dikkatli bir biçimde SERP’i incelerseniz, SERP’teki ilk sırada/sayfada yer alan kaliteli içeriklerin noktalama işaretlerine kadar dikkat edilerek yazıldığını ve bunun dahi Google’ın yaptığı çevirilerde, doğru çeviri yapılabilmesi için etkili olduğunu göreceksiniz. 

Bazı noktalarda soru işareti olanlar için…

Diğer bir deyiş ile eğer yazdığınız makaleyi Google düzgün biçimde translate edemiyor ise düzgün bir biçimde de yapay zeka makalenizi anlamıyor/anlayamıyor demektir. Bu noktada, daha belirgin cümleler kurmanız, noktalama hatalarını düzeltmeniz, cümlelerinizi kısaltmanız ve aralarındaki geçişleri, neden sonuç ve nesne-sıfat-özne-fiil bağlantılarını basitleştirmeniz gerekmektedir. 

Google için kolay çevirisi yapılabilir metin, Google için kolay anlaşılabilir metindir. Bu nedenle, Google NLP API ile birlikte Google Translate API’yi de Google’ın içerik algısını değerlendirmek için kullanmalısınız.

İsterseniz, önemli sorgularda, yüksek sıralamaya sahip içerikler için Google Translate’i kullanarak ardından ise kalitesiz/düşük sıralamaya sahip içerikleri Google Translate’ten geçirerek sağlamasını yapabilirsiniz.

Google NLP API-Google Translate API ve Entity-based Content Optimization İçin Son Küçük Öneriler

• Her entity’nin birden fazla synonym’i ve yazım  biçimi bulunmaktadır. Bunları mutlaka ilgi yönünü belirterek yazı içinde kullanmalısınız. (Dance, dancing, dances, moving in choreography, music and moving/ Second World War, WWII, wwii, Second Global War, Major Second War, War of the Nations)
• Rakip içeriklerin/Brand-Entity’lerin içerdiği tüm kavramları, doğal biçimde ve ilgi yönleriyle, kısa ve öz biçimde mutlaka yazınızda içermelisiniz.

Google Guideline’ından hangi birimin hangi biçimde yazılması gerektiğini gösteren bir bölümdür.

• Common Term kullanımından kaçınmalısınız. (History, Painting yerine History of X veya Painting of Y gibi. Buradaki X bir devlet, meyve veya kişi olabilir, Y bir ressam, şehir ya da sanat akımı olabilir.)
• Google Patentlerinde ve NLP API Adımlarında, Google’ın her sözcüğün farklı yazım biçimlerini kontrol ettiğinden bahsetmiştim. Çoğul/tekil kullanımında ileride olsalar da farklı türdeki eklerde biraz zorlanan bir NLP API’yi yormamak için, Google Translate API’den bazı kontroller yapabilirsiniz. Arama Motorunun daha rahat anladığı ek ve sözcük biçimleri kullanmanız fayda sağlayacaktır.
• Olumluluk ve Olumsuzluk ekleri, Google için ‘veya’ ‘and’, ‘not’ benzeri Search Operatorleri ile birlikte kullanılmaktadır. Bu nedenle, cümlelerin karar kıldığı özneleri ve nesneleri mümkün olduğunca tekil/belirgin biçimde girerek nitelemek daha faydalıdır.
• Arama Motoru, Google Translate API’den bahsederken söylediğimiz gibi noktalama ve yardımcı işaretçilere önem vermektedir. Kontrol gerçekleştirerek Google Translate API’nin rahatça anlayabileceği kısa ve düzgün kodlanmış cümleler kullanmanız fayda sağlayacaktır.

Google’ın cümle arasındaki boşluklara, çoğul veya aidiyet eklerine, & işaretinin kullanımına değinen Guideline bölümlerinden bazı kesitlerdir.

Entity-Based Content Optimizasyonu İçin Hangi Toollar Kullanılabilir?

Dürüst olmak gerekirse doğrudan bu iş için kullanabileceğiniz tek kaynak şu an için Google Natural Language Processor API ya da Google AutoML Language API… Bunun dışındaki her çalışmanızı, Featured Snippetleri inceleyen ve Google Patentlerini okuyan, Google Dil Algoritmalarını ve gelişmelerini takip eden Holistic SEO Zihninizle ve içerik yazarlarınıza vereceğiniz kısa eğitimlerle gerçekleştirebilirsiniz. Özellikle de Featured Snippet Hunting ve Google Translate API bu konuda en önemli yardımcılardandır.. 

Bing’e ait ‘Entity Detection and Disambiguation’ Patentidir. Google’ın aynı noktadaki patentlerine metodoloji olarak benzese dahi adım sayısı ve detay daha azdır. Ancak ‘Karşılaştırmalı Patent’ incelemeleri, Search Engine Building noktasında bilgi sahibi olmanızı sağlayacaktır.

Entity-based Content Optimizasyonu ile ilgili bir tool tasarlama fikri ise ilk olarak yeri ve vizyonu benim için ayrı olan Doğuş Yayın Grubu Head Of SEO’su Ramazan Buldu ile gerçekleştirdiğimiz bir sohbet sırasında oluştu. Google’ın hem E-A-T için Rater Guideline’ında hem de Pegasus’u geliştirirken News Source’lara büyük önem verdiğini görmekteyiz. Bu nedenle, Entity Relation’ları çıkaran ve Confidence Score’ları, Kategorilendirmeleri ve Sentiment Analyse’i gerçekleştirerek yazarları yönlendiren, Google’ın İçerik Algısı ile anlık iletişim kuran bir tool hayalini birlikte kurduk, en azından pseudo kodlarla yazdık. Kim bilir belki, bir patent de bizden gelir…

Entity-Based Content Optimizasyonu Hakkında Kısa Çıkarımlar

Entity-based Search Engine’in doğasında, başarı elde etmek için Entity-based düşünmeye başlamalısınız. Keyword-based düşünen bir SEO zihni, ne yazık ki geçen yılda kaldı. Hemen hemen her etkinliğimde Geleneksel SEO ve Holistic SEO farkına değinmekteyim. Browser’ın nasıl çalıştığını bilmeden nasıl bir sayfayı hızlandıracağınızı bilemezsiniz. Search Engine’in yapısını bilmeden de asla sıralamalarda yükselemeyeceksiniz. Keyword ve URL temelli tekil yaklaşımlar yerine, bütün bir konuyu(entity)i her mecrada her branding/coding olanağı ile hedeflemek ve Search Engine için belirsizlik etkisini azaltarak tutarlılık, süreklilik, anlaşılırlık ve taranabilirlik ilkeleriyle hareket etmek, 2020 ve ötesindeki başarı şansınızın temel kaynağıdır.

Google’ın Related Entities Patentinde, Entity Extraction için Authorative Source ve Indexed WebPages’lerin kullanım biçimini anlatan bir bölüm.

Makaleyi bitirmeden önce son bir kaç sözle yazım sürecinden bahsetmek istiyorum. Makalenin son kısımlarında, özellikle NLP API sonrasında, konuları mümkün olduğunca kapsamlı ancak bir o kadar da kısa tutmaya çalıştım. Bu nedenle, her noktanın olması gerektiği kadar ayrıntılı aktarıldığını düşünmüyorum. Ancak gene de İçerikbulutu Akademi’de ve Türkiye’de Complete, Comprehensive ve Guideline niteliğinde geniş bir Entity-Based Search Engine rehberi yaratmak istedim. Eğer bazı kavramları/konuları daha iyi öğrenmek veya anlamak isteyenler olursa, mutluluk duyarım. 

Source: Grensom, Ambient Computing and Search Engine

Son olarak:

Geleneksel SEO’nun artık gerçekten SEO ihtiyaçlarını karşılamadığını belirtmek zorundayım. Daha fazla keyword-intent, otorite, content quality, content is king, keyword planner ile başlayan ve hiç bir somut SEO Çalışmasını iyileştiremeyen-iyileştiremeyecek anlamsız sözlerin ve sayısız söz yazarının gerçekten SEO adına bir değer üretmediğini ve tek değişkenli bir yapay zeka gibi (papağan) sürekli aynı şeyi tekrarladığını fark etmeliyiz.

Önümüzdeki dönemde SEO iki ayrı yöne doğru genişleyerek evriliyor. Diğer bir deyiş ile ‘ölmüyor.’ Bunlardan birisi SEO’nun Holistic SEO’ya dönüşerek Online-Offline Pazarlamanın her alanı ile birleşmesi ya da temas etmesidir. Bir diğeri ise Holistic SEO’nun giderek Yazılım ve WebApı geliştirme teknolojileri ile iç içe geçerek, Data Science ve UX çalışmalarıyla da birleşerek ‘mevcut süreçlerin otomatikleştirilmesidir.’ Eğer hala ‘2020’de Voice Search veya Keyword-intent, LSI’ konuşmak istiyorsanız, zamanı sizin için biraz daha geri almak zorundayız. Holistic SEO geleneğini, ülkemizde oluşturabilmek ve Uluslararası Sektörün önüne geçebilmek dileğiyle…

“Modern Search is Everywhere, Modern Search Engine Optimisation has to be everywhere”

Koray Tuğberk Gübür

Koray Tuğberk GÜBÜR, Holistic SEO & Digital'ın kurucusudur. Kendi ekibiyle birlikte, Küresel SEO ve Dijital Pazarlama Sektörüne açılmaktadır. Temel uzmanlık alanı, Google Çekirdek Güncellemeleri, E-A-T Building, Technical SEO, Entity-based Search ve Dijital Marketing Yönetimidir. Tüm İçerikleri Görüntüle