Open Graph, Meta Veri Hijyeni ve Derin Bağlantılar için Stabil Çapalar

Open Graph, Meta Veri Hijyeni ve Derin Bağlantılar için Stabil Çapalar

Yazan: Lukas Richter, Kıdemli İçerik Otomasyonu Stratejisti

Bir sayfa faydalı olabilir ve yine de bir asistanın bulması, tanımlaması veya iyi bir şekilde atıfta bulunması zor olabilir. Çözüm gizli bir “yapay zeka meta verisi” hilesi değildir. Açık sinyallerden oluşan küçük bir settir: sayfanın neyi kapsadığını belirten bir başlık, o sayfa için tek bir tutarlı URL ve düzenlemelerden sonra bile çalışmaya devam eden bölüm bağlantıları.

Bu sinyaller farklı işler yapar. Meta veriler, bir sistemin bir sayfayı anlamasına ve etiketlemesine yardımcı olabilir. Kanonik bir URL, tercih edilen sürüme işaret edebilir. Bir çapa, bir okuyucuyu belirli bir bölüme götürebilir. Hiçbiri bir asistanı sayfaya atıfta bulunmaya zorlayamaz.

Üç iş: keşif, kimlik ve iniş

Derin bağlantı alıntılarını üç adımda düşünün:

1. Keşif: Asistan veya arama sistemi sayfaya erişebilir mi?
2. Kimlik: Ana sürümün hangi URL olduğunu anlayabilir mi?
3. İniş: Bir bölüme bağlantı veriyorsa, o bölüm hala var mı ve doğru yerde mi açılıyor?

Erişim önce gelir. OpenAI, ChatGPT aramasında web sitelerini yüzeye çıkarmak için OAI-SearchBot'un kullanıldığını belirtiyor. Google, sayfaların dizine eklenmesi ve yapay zeka arama özelliklerinde bir snippet ile görünmeye uygun olması gerektiğini söylüyor. Meta veriler, engellenen bir tarayıcıyı veya erişilemeyen bir sayfayı telafi edemez. OpenAI crawler documentation (developers.openai.com) Google’s AI features guidance (developers.google.com)

Erişilebilir bir sayfa bile alıntılanmayabilir. 10 Ekim 2026 tarihli, üretim asistanı cevaplarını izleyen bir ön baskı, alım ve atfın ayrı adımlar olduğunu bulmuştur: sistemler aday sayfaları alır, sonra sadece bazılarını alıntılar. Bulgularını gözlemsel olarak, belirli bir meta veri değişikliğinin atıflara neden olduğuna dair bir kanıt olarak değil ele alın. The preprint on AI citation behavior (arxiv.org)

Pratik amaç basittir: kaçınılabilir kafa karışıklığını ortadan kaldırın. Sayfanın kendisi soruyu cevaplayamazken meta verileri parlatmak için saatler harcamayın.

Bir sayfanın anlamlı olmasına yardımcı olan meta veriler

Açık bir başlık yazın

HTML <title>, görünür <h1> ve og:title etiketlerini aynı sayfa konusuna odaklanmış tutun. Kelimesi kelimesine kopyalar olmaları gerekmez, ancak farklı şeyler vaat etmemelidirler.

Google, arama sonucu başlığını oluşturmak için <title>, görünür sayfa başlığı, başlıklar, og:title, sayfa metni ve bağlantıları kullanabileceğini belirtiyor. Ayrıca, yanlış olduğunu düşündüğü bir başlığı yeniden yazabilir. Bu, başlığı sayfayla eşleştirmek için iyi bir nedendir – her asistanın bu alanları aynı şekilde kullandığının garantisi değildir. Google’s title-link documentation (developers.google.com)

Faydalı bir başlık, konuyu ve mümkünse okuyucunun görevini belirtir:

• Açık: “Derin Bağlantılar için Open Graph Meta Verileri ve Stabil Çapalar”
• Daha az açık: “Size Her Şeye Mal Olacak Küçük Meta Veri Hatası”

İkinci başlık merak uyandırır ama sayfanın neyi açıklayacağı hakkında pek bir şey söylemez. Merak, faydalı bir etiketle aynı şey değildir.

Meta açıklamaya gerçek bir iş verin

O sayfanın kısa, belirli bir özetini yazın. Anahtar kelimelerle doldurmayın veya her gönderide aynı açıklamayı yeniden kullanmayın.

Google, arama snippet'lerini genellikle sayfa içeriğinden oluşturduğunu, ancak daha iyi bir özet verdiğinde meta açıklamayı kullanabileceğini belirtiyor. Snippet'ler arama sorgusuna göre de değişebilir. Bu nedenle, açıklamayı her arama sisteminin görüntülemesi gereken sabit bir başlık olarak değil, yardımcı bir önizleme olarak değerlendirin. Google’s snippet guidance (developers.google.com)

Bir kanonik URL seçin

Kanonik URL, benzer kopyalar veya URL varyasyonları mevcut olduğunda bir sayfa için tercih edilen adrestir. Google, kanonik etiketi bir ipucu olarak ele alır, bir komut olarak değil, ve farklı bir URL seçebilir. Yine de, tarayıcılara ve bağlantı kuruculara tek bir açık seçenek sunmak, sinyalleri izleme URL'lerine, eski yollara ve alternatif versiyonlara dağıtmaktan daha iyidir. Google’s canonicalization guidance (developers.google.com)

Aşağıdaki yerlerde aynı temiz sayfa URL'sini kullanın:

• rel="canonical" etiketi
• Open Graph'ın og:url'si
• Site haritanız
• Dahili bağlantılarınız

Sayfanın kanonik URL'sini parçasız tutun. #section-id öğesini, bölümü açması gereken derin bağlantıya koyun, sayfanın ana kimliğine değil. Open Graph protokolü og:url'yi nesnenin kalıcı grafik kimliği olarak tanımlar. Bu, tutarlı sayfa kimliği için faydalıdır; bu, asistanların o URL'yi veya bir bölüm parçasını alıntılamak zorunda olduğu anlamına gelmez. Open Graph protocol (ogp.me)

Open Graph etiketlerini tutarlı tutun

Open Graph etiketleri, bir sayfayı paylaşılabilir bir nesne olarak tanımlamaya yardımcı olur. Protokolün gerekli alanları arasında og:title, og:type, og:image ve og:url bulunur. Ayrıca og:description'ı kısa bir açıklama olarak tanımlar. Google, arama sonucu başlığını oluştururken og:title'ı dikkate alabilir, ancak bu, her asistanın Open Graph etiketlerini bir alıntı sinyali olarak kullandığını kanıtlamaz. Open Graph protocol (ogp.me) Google’s title-link documentation (developers.google.com)

İşte basit bir kalıp:

html

<meta name="description" content="Learn how clear metadata, one canonical URL, and stable section IDs make deep links easier to identify and use."

Daha kısa, gerçek odaklı başlıklar tıklama tuzağını yener mi?

Mevcut kamu kanıtları, sadece daha kısa başlıkların daha fazla asistan alıntısı kazandığını göstermiyor. Daha güçlü sinyal, bir başlığın insanların sorduğu sorularla eşleşip eşleşmediğidir.

10 Ekim 2026 tarihli ön baskı, aynı web sitelerindeki sayfaları iki pazarda karşılaştırdı. Başlık-sorgu eşleşmesinin genel olarak daha fazla atıfla ilişkili olduğunu buldu. Ancak motor sonuçları farklıydı: başlık eşleşmesi Gemini ve Perplexity'den daha fazla atıfla ilişkilendirilirken, çalışma ChatGPT için belirgin bir başlık eşleşmesi etkisi bulamadı. Çalışma ayrıca başlık uzunluğundan güvenilir bir etki bulamadı. Bunlar, tıklama tuzağı ile gerçeklere dayalı başlıkların rastgele bir testinin sonuçları değil, ilişkilerdir. The citation-behavior preprint (arxiv.org)

Eylül 2026 tarihli, 1.000 aramayı kapsayan bir sektör raporu da, kısa başlık sonuçlarının tekrarlanan testlerde tutarlı olmadığını buldu. Tıklama tuzağı stilini gerçeklere dayalı stilden ayırmadı ve sonuçları son bir kural olarak değil, bir satıcının gözlemsel çalışması olarak okunmalıdır. The report’s methodology and findings (getomnipresence.com)

Dolayısıyla dürüst karar “kısa kazanır” veya “tıklama tuzağı kaybeder” değildir. Şudur: önce başlığı doğru ve ilgili yapın; tonu ve uzunluğu kendi sayfalarınızda test edin. Gerçek odaklı başlıkları tıklama tuzağı başlıklarından açıkça ayıran ve asistan alıntı olasılığını ölçen kontrollü bir kamu testi bulamadım.

Soruyu cevaplayabilecek bir test

Uzunluğu tondan ayırmak için dört başlık stili kullanın:

Merak uyandıran başlıklar yine de doğru olmalıdır. Makalenin desteklemediği bir sorunu veya sonucu vaat etmeyin.

Faydalı bir test için:

1. Karşılaştırılabilir sayfalar kullanın. Aynı sitedeki eşleşen sayfalara başlık stilleri atayın. Sadece kelimeleri test etmek için bir makalenin kopya kopyalarını yayınlamayın; yinelenen URL'ler testi karıştırır.
2. Sadece başlık paketini değiştirin. Her sayfanın içeriğini, meta açıklamasını, kanonik URL'sini ve hedef sorgu setini stabil tutun. Sayfanın karışık sinyaller göndermemesi için <title>, <h1> ve og:title öğelerini hizalı tutun.
3. Değişikliğin tarayıcılar için görünür olmasını bekleyin. Arama sistemleri bir sayfayı yeniden taramak ve işlemek için zaman alabilir. Google, başlık bağlantısı değişikliklerinin görünmesinin günler hatta haftalar sürebileceğini belirtiyor. Google’s title-link documentation (developers.google.com)
4. Aynı istemleri birden fazla kez çalıştırın. Asistanı, istemi, tarihi ve alıntılanan URL'yi kaydedin. Cevaplar çalıştırmalar arasında değişebilir, bu nedenle tek bir sonuç bir karar değildir. Eylül raporu ayrıca tekrarlanan cevapların genellikle aynı sayfaları alıntılamadığını buldu. The report’s limitations (getomnipresence.com)
5. İki sonucu ayrı ayrı izleyin: sayfanın ne sıklıkta alıntılanması ve bir alıntının ne sıklıkta çalışan bir bölüm parçasına işaret etmesi. Tıklamaları da ayrı ayrı izleyin; dikkat çeken bir başlık otomatik olarak alıntı kazandıran bir başlık değildir.
6. Sadece bir sayfanız varsa, başlık değişimini bir pilot olarak değerlendirin. Bir seferde bir sürümü değiştirin ve sonuçları karşılaştırmadan önce yeni başlığın yeniden tarandığını doğrulayın. Bu, kendi siteniz için faydalı bir kanıttır, ancak temiz bir nedensel test değildir.

Çapa Kimliklerini kalıcı yapın

#canonical-url gibi bir URL parçası, bir tarayıcıyı o kimliğe sahip bir öğeye işaret eder. HTML standardı, kimliklerin belgede benzersiz olmasını gerektirir ve bir kimlikte boşluk karakterlerini yasaklar. Birçok formata izin verir, ancak basit, okunabilir bir adlandırma stili insanların kopyalaması ve sürdürmesi için daha kolaydır. WHATWG HTML Standard (html.spec.whatwg.org)

Bu kuralları kullanın:

• Bölümün anlamı için bir kimlik seçin, mevcut başlık metni için değil: canonical-url, how-canonical-urls-work değil.
• Tirelerle ayrılmış küçük harfli kelimeler kullanın. Boşluklardan, noktalama işaretlerinden ve section-4 gibi otomatik numaralı kimliklerden kaçının.
• Kimlikleri açıkça yazın. Bir aracın, bir editör başlığı her değiştirdiğinde bunları sessizce yeniden oluşturmasına izin vermeyin.
• Başlıklar değiştiğinde eski genel kimlikleri koruyun. Bir kimlik değişmek zorundaysa, eski konumda uyumlu bir takma ad bırakın ve bilinen bağlantıları güncelleyin.
• Sayfanın başka bir yerinde bir kimliği yeniden kullanmayın.
• Hedefi görünür yapın. Katlanmış bir panelde gizlenmiş metne veya sayfa yüklemesi sırasında kaldırılan bir öğeye bağlantı vermekten kaçının.
• JavaScript yüklendikten sonra bağlantıyı test edin. Hash'i kaldıran veya sayfayı en üste zorlayan bir komut dosyası derin bağlantıyı bozabilir.

Google'ın “Daha fazla oku” derin bağlantıları için yönergeleri de, hedef içeriği görünür tutmayı ve sayfa yüklemesi sırasında parçayı kaldırmamayı tavsiye eder. Google’s snippet and deep-link guidance (developers.google.com)

Örnek:

html

Parça, bölümü açmayı ve doğrulamayı kolaylaştırır. O bölümü ayrı bir kanonik sayfaya dönüştürmez. Google genellikle URL parçalarını, bir sayfanın içeriğini arama dizinleme için değiştirmek amacıyla kullanmaz. Google’s URL structure guidance (developers.google.com)

Bir kimlik bozulmadan önce regresyon testleri ekleyin

Genel çapa kimliklerini sayfanın bağlantı sözleşmesinin bir parçası olarak ele alın. Bir başlık değişebilir; insanların zaten paylaştığı bir bağlantı sessizce çalışmayı bırakmamalıdır.

Aşağıdaki Playwright testleri, kanonik URL ve og:url'nin eşleştiğini, genel kimliklerin mevcut ve benzersiz kaldığını ve doğrudan bir parçanın görüntü alanında açıldığını kontrol eder. Playwright, bu tür kontroller için toBeInViewport() ve locator.evaluateAll() gibi web odaklı onaylamaları belgeler. Playwright assertions (playwright.dev) Playwright locator documentation (playwright.dev)

js import { test, expect } from "@playwright/test";

const articleUrl = "http://127.0.0.1:3000/guides/open-graph-deep-links/";

const publicAnchorIds = [ "metadata-hygiene", "canonical-url", "stable-anchor-ids", ];

test("page metadata uses one page identity", async ({ page }) => { await page.goto(articleUrl);

const canonical = await page .locator('link[rel="canonical"]') .getAttribute("href");

const ogUrl = await page .locator('meta[property="og:url"]') .getAttribute("content");

expect(new URL(canonical, articleUrl).href).toBe( new URL(articleUrl).href ); expect(new URL(ogUrl, articleUrl).href).toBe( new URL(canonical, articleUrl).href );

await expect(page).toHaveTitle(/Open Graph/i);

const description = await page .locator('meta[name="description"]') .getAttribute("content");

expect(description?.trim()).toBeTruthy(); });

test("public anchor IDs stay unique and present", async ({ page }) => { await page.goto(articleUrl);

const ids = await page.locator("[id]").evaluateAll((elements) => elements.map((element) => element.id) );

expect(new Set(ids).size).toBe(ids.length);

for (const id of publicAnchorIds) { await expect(page.locator(#${id})).toHaveCount(1); } });

test("a direct deep link opens at its target", async ({ page }) => { await page.goto(${articleUrl}#canonical-url);

await expect(page.locator("#canonical-url")).toBeInViewport(); await expect(page).toHaveURL(/#canonical-url$/); });

publicAnchorIds'i versiyon kontrolünde tutun ve önerilen her kaldırmayı genel bir API'deki bir değişiklik gibi gözden geçirin. Parçaları bir kimlikle eşleşmeyen aynı sayfa bağlantıları için ayrı bir kontrol ekleyin. Büyük siteler için bu kontrolleri yayınlanmış sayfalarda otomatik olarak çalıştırın.

Meta veri ritüeli değil, küçük sistemi inşa edin

İyi bir içerik iş akışı, onaylanmış bir brifingden sayfa başlığı ve açıklama taslağı oluşturabilir, ardından eksik meta veriler, eşleşmeyen URL'ler, yinelenen kimlikler ve bozuk parçalar için kontroller yapabilir. Sistem hataları yakalamalıdır; makalenin destekleyemeyeceği bir iddiayı icat etmemelidir.

AutoPod için Oluşturucu, Kitle ve Beğeni girişleri, her makalenin bakış açısını yönlendirmeye yardımcı olur. Teknik kontroller farklı bir iş yapar: tamamlanmış sayfanın açık bir kimliğe ve çalışan bağlantılara sahip olmasını sağlamaya yardımcı olurlar.

Kural basit: sayfayı bulması kolay, tanımlaması kolay ve doğrulaması kolay hale getirin. Gerçek odaklı başlıklar yazın çünkü gerçeği açıkça söylerler – kimse bir asistan alıntısı kazanacaklarını garanti edemez. Stabil çapalar, bir asistan veya okuyucu bir bölüme bağlantı verdiğinde bir alıntıyı daha kullanışlı hale getirir.