Entity SEO ve kişisel markalaşma

Kendi adımı arama motorunda arattığımda karşıma çıkan sonuçlar bir süre beni rahatsız etti: bir profilde "veri analisti", başka birinde "yazılım geliştirici", bir dizinde ise yıllar önce kullandığım bir unvan duruyordu. Hiçbiri yanlış değildi ama hepsi bir arada tutarlı bir kişi anlatmıyordu. Entity SEO dediğimiz yaklaşım tam bu sorunla ilgileniyor: arama motorunun sizi bir anahtar kelime yığını olarak değil, tanımlı bir varlık (entity) olarak tanıması; o varlığın adı, unvanı, açıklaması ve profilleri arasında bağ kurabilmesi.

Bu yazıda bir kişi ya da küçük bir marka için tutarlı kimlik kurarken izlediğim yolu anlatıyorum: aynı ad, aynı unvan ve aynı açıklamayı her yerde kullanmak; bunu schema.org Person ve Organization işaretlemesiyle makine okunur hâle getirmek; profiller arasında sameAs bağlarını kurmak ve sonra bu bağların gerçekten çalışıp çalışmadığını küçük bir betikle denetlemek.

Bir de üzerinde özellikle durmak istediğim bir ayrım var: yapılandırılmış veriye yazdığınız her şey bir iddiadır. Arama motoru bu iddianın bir kısmını başka kaynaklardan doğrulayabilir, bir kısmını ise hiçbir zaman doğrulayamaz. Neyin kanıtlanabilir, neyin yalnızca beyan olduğunu baştan ayırmak, boşa emek harcamanızı önlüyor.

Entity ne demek, anahtar kelimeden farkı ne

Klasik SEO'da bir sayfayı belirli sorgular için düzenleriz. Entity yaklaşımında ise odak sayfa değil, sayfanın anlattığı şeydir: bir kişi, bir şirket, bir ürün. Google'ın Knowledge Graph'ı bu türden varlıkları aralarındaki ilişkilerle birlikte tutar; "kim, nerede çalışıyor, hangi konularda yazıyor, hangi profiller ona ait" gibi sorulara buradan cevap üretmeye çalışır.

Küçük bir marka ya da tek kişilik bir danışmanlık için bunun pratik karşılığı şu: arama motoru sizin hakkınızda kaç farklı kaynaktan aynı bilgiyi görüyorsa, sizi o kadar güvenle tek bir varlık olarak ele alıyor. Çelişen bilgi ise güveni düşürüyor; sistem hangi sürümün doğru olduğunu bilemediği için ikisini de zayıf tutuyor. Bunun bir benzerini Docker Compose proje adlandırması yazısında anlatmıştım: aynı yığını iki farklı adla ayağa kaldırdığınızda ortaya iki ayrı, birbirinden habersiz kopya çıkar. Kimlik tutarsızlığı da web üzerinde tam olarak bunu yapıyor.

Tutarlı kimlik: aynı ad, aynı unvan, aynı açıklama

İşin en sıkıcı ama en etkili kısmı burası. Kendi kurulumumda önce tek bir "kimlik kartı" yazdım ve her profili bu karta göre düzelttim:

• Ad: Her yerde aynı yazım. Ne bir profilde kısaltma, ne başka bir yerde ikinci ad. Türkçe karakterler de dahil; "Degirmenci" ile "Değirmenci" arama motoru için aynı dize değildir.
• Unvan: Tek bir tanım seçin ve ona sadık kalın. Ben "veri ve otomasyon danışmanı" ifadesini seçtim; LinkedIn başlığı, GitHub biyografisi, site altbilgisi ve konuşmacı profilleri aynı cümleyi taşıyor.
• Açıklama: İki-üç cümlelik kısa bir biyografi. Platformun karakter sınırına göre kısaltılabilir ama ilk cümle her yerde aynı kalmalı.
• Görsel: Aynı fotoğraf ya da aynı logo. Görsel eşleşmesi, metin eşleşmesi kadar önemli bir sinyal.
• Ana adres: Tüm profillerin "web sitesi" alanı tek bir URL'ye, tercihen kök alan adına işaret etmeli.

Bu listeyi basit bir tabloya dökmenizi öneririm: satırlar profiller, sütunlar alanlar. Boş ya da farklı olan hücreler, yapılacak iş listenizdir. Benim tablomda ilk turda en çok "unvan" sütunu kırmızıydı; yıllar içinde her platformda o günkü işe göre farklı bir şey yazmışım.

schema.org Person ve Organization işaretlemesi

Kimlik kartı hazır olunca sıra onu makinelerin okuyacağı biçime çevirmeye geliyor. Bunun için JSON-LD formatında schema.org işaretlemesi kullanıyorum; sayfanın head bölümüne tek bir script etiketiyle giriyor ve görünen içeriği hiç etkilemiyor. Aşağıdaki örnek, kişisel sitemin ana sayfasında kullandığım yapının sadeleştirilmiş hâli:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://ekremdegirmenci.com/#person",
  "name": "Ekrem Değirmenci",
  "url": "https://ekremdegirmenci.com/",
  "jobTitle": "Veri ve Otomasyon Danışmanı",
  "description": "Küçük ve orta ölçekli işletmeler için veri toplama, raporlama ve süreç otomasyonu kurar.",
  "image": "https://ekremdegirmenci.com/img/profil.jpg",
  "knowsAbout": ["Veri otomasyonu", "Python", "Power BI"],
  "sameAs": [
    "https://www.linkedin.com/in/kullanici-adi",
    "https://github.com/kullanici-adi"
  ],
  "worksFor": { "@id": "https://ekremdegirmenci.com/#org" }
}
</script>

Birkaç noktaya dikkat edin. @id alanı varlığa sabit bir adres veriyor; site içindeki başka sayfalarda aynı kişiye atıf yaparken bu adresi kullanıyorsunuz, böylece her sayfa yeni bir Person üretmek yerine aynı düğüme bağlanıyor. sameAs listesi "bu profiller de bana ait" beyanıdır. knowsAbout ve jobTitle ise düpedüz iddiadır; buna birazdan döneceğim. Google'ın yapılandırılmış veri dokümanında ayrıca ProfilePage türü tanımlı; hakkımda sayfasını bu türle işaretleyip mainEntity ile Person düğümüne bağlamak, "bu kişiyi anlatan sayfa budur" demenin en açık yolu.

Bir marka için aynı mantık Organization tipiyle kurulur. Tek kişilik bir işletmede ben kişiyi ve markayı ayrı düğümler olarak tanımlayıp founder ve worksFor ile birbirine bağlamayı tercih ediyorum:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://ekremdegirmenci.com/#org",
  "name": "Ekrem Değirmenci Danışmanlık",
  "url": "https://ekremdegirmenci.com/",
  "logo": "https://ekremdegirmenci.com/img/logo.png",
  "founder": { "@id": "https://ekremdegirmenci.com/#person" },
  "sameAs": [
    "https://www.linkedin.com/company/kullanici-adi"
  ]
}

Google İşletme Profili kaydınız varsa Organization düğümündeki ad, adres ve telefon bilgisi orada yazanla birebir aynı olmalı. Google Haritalar'dan işletme verisi toplarken en sık karşılaştığım tutarsızlık tam olarak buydu: sitede bir telefon, haritada başka bir telefon, dizinde üçüncü bir adres. Bu üçlü uyuşmadığında arama motorunun hangisine güveneceğini bilmesi mümkün değil.

sameAs bağlarını denetlemek

sameAs yazmak kolay; asıl soru bağın öbür ucunun da size işaret edip etmediği. Bir profil sizin sitenize link veriyor ve sitedeki JSON-LD o profile sameAs ile dönüyorsa ortada iki yönlü bir bağ var demektir. Tek yönlü bağ zayıf bir sinyal; herkes herhangi bir profili kendi sameAs listesine yazabilir. Bu yüzden listeye yalnızca gerçekten kontrol ettiğiniz ve "web sitesi" alanına adresinizi yazabildiğiniz profilleri ekleyin.

Bunu elle kontrol etmek birkaç profilde kolay, ama profiller ve sayfalar çoğalınca unutuluyor. Ben aşağıdaki küçük Python betiğini kullanıyorum; yalnızca standart kütüphaneyle çalışıyor, sayfadan JSON-LD bloğunu çekiyor, sameAs listesindeki her adresi açıp orada site adresinin ve isminizin geçip geçmediğine bakıyor:

import json
import re
import sys
import urllib.request

BASLIK = {"User-Agent": "Mozilla/5.0 (entity-kontrol)"}
LD = re.compile(r'<script[^>]+application/ld\+json[^>]*>(.*?)</script>', re.S | re.I)


def getir(url):
    istek = urllib.request.Request(url, headers=BASLIK)
    with urllib.request.urlopen(istek, timeout=15) as yanit:
        return yanit.status, yanit.read().decode("utf-8", "ignore")


def varlik_bul(html):
    for blok in LD.findall(html):
        try:
            veri = json.loads(blok)
        except json.JSONDecodeError:
            continue
        adaylar = veri.get("@graph", [veri]) if isinstance(veri, dict) else veri
        for aday in adaylar:
            if isinstance(aday, dict) and aday.get("@type") in ("Person", "Organization"):
                return aday
    return None


site = sys.argv[1].rstrip("/")
durum, html = getir(site)
varlik = varlik_bul(html)
if not varlik:
    sys.exit("JSON-LD icinde Person/Organization bulunamadi")

print(f"{varlik['@type']}: {varlik.get('name')} - {varlik.get('jobTitle', '')}")
ad = (varlik.get("name") or "").lower()
for profil in varlik.get("sameAs", []):
    try:
        kod, govde = getir(profil)
        geri = "evet" if site in govde else "HAYIR"
        ad_var = "evet" if ad in govde.lower() else "HAYIR"
        print(f"  {kod}  geri-link={geri}  ad={ad_var}  {profil}")
    except Exception as hata:
        print(f"  HATA  {profil}: {hata}")

Çıktı her satırda HTTP durum kodunu, geri linkin bulunup bulunmadığını ve adın geçip geçmediğini gösteriyor. Dürüst olmak gerekirse betiğin sınırları var: LinkedIn gibi platformlar anonim isteklere profil içeriği vermez, orada "HAYIR" ya da hata görürseniz elle bakmanız gerekir. Tek seferlik bir "HAYIR" alarm değildir; asıl sinyal, geçen hafta "evet" olan bir satırın bu hafta değişmesidir. Bu yüzden betiği haftalık zamanlanmış göreve bağlayıp çıktıyı tarihli bir dosyada biriktiriyorum; fark, iki dosyayı yan yana koyunca ortaya çıkıyor.

Neyi kanıtlayabilirsiniz, neyi sadece iddia edersiniz

Yapılandırılmış veriyle ilgili en yaygın yanılgı, oraya yazılanın arama motoru tarafından doğru kabul edileceği. Öyle değil. Google'ın yapılandırılmış veri yönergeleri, işaretlemenin sayfada görünen içerikle örtüşmesi gerektiğini ve zengin sonuç garantisi olmadığını açıkça söylüyor. Kendi kurulumlarımda şu ayrımı yapıyorum.

Kanıtlanabilir olanlar, üçüncü bir tarafın ya da teknik bir mekanizmanın onayladığı şeylerdir:

• Alan adının size ait olması. Search Console doğrulaması, DNS kaydı ve sitedeki içerik bunu gösterir.
• İki yönlü sameAs bağları. Profil siteye, site profile işaret ediyorsa bağ makine tarafından izlenebilir.
• Tarihli, sürekli içerik. Aynı sitede yıllara yayılan yazılar, aynı imzayla açık kaynak katkıları, kayıtlı konuşmalar.
• Başkalarının sizden söz etmesi. Bir etkinlik sayfasının sizi konuşmacı olarak listelemesi, bir yayının adınızı geçirmesi; bunları siz yazmadınız, o yüzden ağırlığı fazla.

Yalnızca iddia olanlar ise sizin yazdığınız ve kimsenin teyit etmediği alanlar:

• jobTitle, description ve knowsAbout. Bunlar sizi tanımlar ama doğrulamaz. "Uzman" yazmak sizi uzman yapmaz; sistem bu alanı olsa olsa görünen içerikle karşılaştırır.
• Kaynağı gösterilmeyen ödül, sertifika ve sayılar. award alanına yazılan bir ödülün web üzerinde karşılığı yoksa boş bırakmak daha iyidir.
• Tek yönlü sameAs. Size ait olmayan ama prestijli görünen bir profili listeye eklemek, tutarsızlık olarak geri döner.

Buradan çıkan pratik kural basit: işaretlemeye yalnızca sayfada zaten görünen ve başka bir yerden teyit edilebilen bilgiyi yazın. İddia olan alanları da doldurabilirsiniz, ama onların sizi taşımasını beklemeyin; taşıyacak olan, o iddiayı destekleyen içeriktir. Bir bilgi paneli ya da zengin sonuç çıkıp çıkmayacağını kimse size garanti edemez; garanti edilebilen tek şey, tutarsızlıkların ortadan kalkmış olmasıdır.

Entity SEO'nun kişisel markalaşma tarafı gösterişli bir teknikten çok bir disiplin: tek bir kimlik kartı, o kartın her profile aynı şekilde işlenmesi, JSON-LD ile makine okunur hâle getirilmesi ve bağların düzenli denetlenmesi. Kendi sitemde bu yapı bir ana sayfa düğümü, bir hakkımda sayfası ve haftalık çalışan bir betikten ibaret; büyük bir altyapı gerektirmiyor.

Kendi kimliğinizi ya da markanızı bu şekilde düzenlemek, profilleriniz arasındaki tutarsızlıkları bulmak veya denetim betiğini kendi kurulumunuza uyarlamak isterseniz iletişim bölümünden yazabilirsiniz; nereden başlayacağınıza birlikte bakarız.