Chat Sitelerinde Link Önizleme (OG Preview) İndekslenir mi? SERP Değerini ve UGC Spam Riskini Azaltma Rehberi

Kapsam ve Terminoloji: OG preview / link preview / zengin snippet nasıl oluşur?

Chat sitelerinde kullanıcılar bir bağlantıyı (URL) paylaştığında, mesajın içinde otomatik bir “zengin önizleme kartı” belirebilir. Bu kart; başlık, açıklama, görsel ve bazen ikon gibi öğeleri bir arada sunar. Ürün ekipleri buna “link preview” derken SEO ve tarayıcı davranışı tarafında daha teknik ifadeler öne çıkar. Kafa karıştırıcı gibi görünse de aslında aynı ihtiyacı farklı dillerle anlatıyoruz.

Chat sitesinde mesajda link önizleme (OG preview) indekslenir mi? Spam/ince içerik riskini azaltma sorusunun cevabı, kartın nasıl üretildiğine (server-side mı client-side mı), hangi HTML’in crawler tarafından görülebildiğine ve Google’ın sayfayı hangi bölüm olarak temsil ettiğine göre değişir. Bu yazı; chat yöneticileri, SEO uzmanları ve anti-spam ekiplerinin aynı masada konuşabilmesini sağlayacak bir rehber gibi düşünülmüştür.

OG preview çoğu zaman “Open Graph (OG) meta etiketleri” üzerinden üretilir. Mesela hedef sayfa og:title, og:description ve og:image gibi etiketler sağlar. Chat uygulaması bu etiketleri okur ve kullanıcıya kart olarak gösterir. Burada kritik nokta şudur: Kart, kullanıcıya göre farklılaşıp “her seferinde bambaşka” bir şeye dönüşüyorsa ya da tekil bir DOM bloğu olarak standartlaşmıyorsa, botların indekslediği şey beklediğiniz gibi tekil bir sayfa değil; “çok sayıda benzer kartlı ince sayfa kümeleri” olabilir.

Zengin snippet ise daha çok arama sonuçlarında görsel/ek bilginin zenginleşmesiyle ilgilidir. Chat içeriğiniz doğrudan SERP’te “zengin sonuç” olarak görünmese bile, crawler’ın sayfayı nasıl temsil ettiği (snippet benzeri seçilim) üzerinde dolaylı etkiler oluşabilir.

Google-bot ve crawler’lar mesaj içeriğini nasıl işliyor? HTML render, statik vs dinamik

Chat uygulamaları çoğu zaman tek sayfa uygulaması (SPA) yaklaşımıyla çalışır. Bu yaklaşımın en büyük farkı şudur: crawler yalnızca gönderilen ilk HTML’i görebilir ya da “render” yaparak JavaScript ile DOM’u oluşturmaya çalışabilir. Ancak pratikte render gecikmeleri, kapasite sınırları ve botların davranış farklılıkları nedeniyle her içerik her zaman aynı şekilde görünmez.

Link preview kartı iki yaklaşımla üretilebilir: (1) Sunucu tarafında (server-side render) OG etiketleri çekilir ve HTML’e gömülür, (2) Tarayıcı tarafında (client-side) bir API çağrısı ile OG verisi alınır ve kart sonradan basılır. Birinci yaklaşım crawler için genellikle daha “görünür”dür; ikinci yaklaşımda crawler kartı hiç göremeyebilir ya da sadece kısmi bir görünüm yakalayabilir.

Bu yüzden “indekslenir mi?” sorusu aslında iki alt soruya ayrılır: (a) Google kartın bulunduğu DOM’u gerçekten görebiliyor mu? (b) Kartı görse bile bu kart, sayfanın indexlenebilir ana içeriği gibi mi değerlendirilir, yoksa sayfa temsiline dahil edilmeyecek bir yan öğe mi kalır?

İndekslendiğini düşündüren senaryolar: HTML’de bulunma, ayrı OG tag’leri, sayfa içi crawl edilebilirlik

Aşağıdaki durumlar, link preview kartlarının crawler tarafından “gerçek içerik” gibi algılanmasına zemin hazırlayabilir. Bu özellikle çok sayıda kullanıcı aynı URL’yi paylaştığında daha belirgin hale gelir; çünkü tekrar sayısı riskin büyümesine doğrudan etki eder.

1) Preview HTML’de gömülü olduğunda: Mesajın içinde preview bileşeni server-side üretilir. Botlar, kart için API çağrısı yapmaya gerek kalmadan doğrudan kart HTML’ini okuyabilir.

2) Ayrı meta/OG tag’leri oluşturulduğunda: Chat sayfası dinamik olarak og:title/og:description üretebilir. Böylece sayfa, URL’nin “önizlemesi eklenmiş” bir şeye dönüşür. Botlar bu meta sinyalleriyle sayfayı farklı şekillerde temsil edebilir.

3) Sayfa içi crawl edilebilirlik (link ekosistemi) varsa: Eğer chat mesajları oda/konu arşivi gibi alanlarda taranabiliyorsa ve preview kartları her mesajda benzer bir düzenle (hatta benzersiz bir fark yaratmadan) sunuluyorsa, indeksleme için “çok sayıda benzer sayfa adayı” oluşabilir.

4) Aynı URL için farklı kullanıcılar farklı varyasyonlar görüyorsa: Örneğin farklı görsel boyutu, farklı açıklama kırpması, dil değişimi gibi mikro farklılıklar ortaya çıkabilir ve sonuç olarak “paralel OG çıktıları” üretilebilir. Bu da ince içerik kümelerine dönüşme riskini artırır.

SERP değerine etkisi: zengin sonuçlar/snippet, title/description sinyalleri, sayfa temsiline katkı

Link preview kartı her zaman arama sonuçlarında “zengin snippet” olarak görünmez; ama iki önemli SEO etkisi olabilir. Birincisi, sayfanın metin içeriği büyür: Başlık ve açıklama metinleri, sayfa içinde indekslenebilecek kelimeler haline gelir. İkincisi, Google sayfanın “temasını” bu kart metninden kısmen çıkarabilir.

Bu etki doğru tasarımla faydalı olabilir. Örneğin chat mesajınızın bağlamı (kullanıcı yorumu) gerçekten değerliyse ve preview yalnızca destekleyici bir bileşen olarak kalıyorsa, sayfanın genel anlamı güçlenebilir. Fakat anti-spam tarafında durum tersine dönebilir: Kullanıcılar sadece link bırakıyorsa, preview metni tek başına sayfayı doldurur ve “link odaklı düşük değer” sinyali artar.

Title/description sinyalleri açısından kritik nokta şudur: Chat sayfası için doğru canonical ve meta robots kararları yoksa, preview kartı sayfanın temsiline beklenmedik derecede ağırlık verebilir. Ayrıca sayfalar arasında (ör. aynı oda içinde farklı mesaj aralıkları) tekrar eden OG başlık/açıklamalar, “duplicate-ish” sayfa temsilleri oluşturarak kalite algısını düşürebilir.

Spam/ince içerik risk haritası: otomatik link üretimi, birbirine benzeyen OG sonuçları, düşük değerli sayfa kümeleri

OG preview kartlarının en büyük riski, spammer’ların “daha fazla taranabilir metin” üretmek için link göndermeyi bir içerik stratejisine dönüştürebilmesidir. Eğer her gönderi OG kartını görünür ve indekslenebilir hale getiriyorsa, saldırganın amacı doğrudan sayfa sayısını artırmak olur.

Örnek mesaj senaryosu: Aynı URL’nin farklı kullanıcılar tarafından paylaşılması. Bir oda içinde 200 kişi aynı bağlantıyı gönderdiğinde, preview kartı 200 mesajda da üretir. Eğer kartlar crawler tarafından görülebiliyor ve sayfa bölümlendirmesi (noindex/canonical/robots) doğru kurgulanmıyorsa, indeks içinde URL bazlı tekrarlar ve ince içerik kümeleri oluşabilir.

Spam/ince içerik riskini artıran tipik pattern’lar şunlardır:

• Tek kelimelik mesajlar: Kullanıcı sadece “link” bırakır; bağlam yoktur.
• Benzer OG çıktıları: Bir URL aynı OG title/description’ı üretir; farklı mesajlar aynı metni tekrar eder.
• Bot-hacmi: Rate limit yoksa kısa sürede yüzlerce mesaj üretilebilir.
• Sayfa kümelenmesi: Oda arşivi gibi ekranlar taranır; aynı kartlar farklı permalinks’e yayılır.
• Raporlama/ceza sonrası temizlenmeme: Spam link kaldırılınca OG kartı gecikmeli güncellenirse eski içerik kalabilir.

Kontrol stratejileri (SEO + anti-spam birlikte): noindex/nofollow, canonical, robots, render kısma, etkileşimle yükleme

En iyi yaklaşım “tek bir etiketle her şeyi çözmek” değil. Preview kartı hem SEO hem spam riskini etkileyen bir bileşen olduğu için, tek tek ayarların değil; birlikte çalışan sinyallerin doğru kurulması gerekiyor. Aşağıdaki kontrol seti, ürün ve teknik ekibin aynı dili konuşmasına yardımcı olur.

En iyi yaklaşım “tek bir etiketle her şeyi çözmek” değil. Preview kartı hem SEO hem spam riskini etkileyen bir bileşen olduğu için, tek tek ayarların değil; birlikte çalışan sinyallerin doğru kurulması gerekiyor. Aşağıdaki kontrol seti, ürün ve teknik ekibin aynı dili konuşmasına yardımcı olur.

1. Hedef sayfayı belirleyin: Mesaj sayfası indexleniyor mu, yoksa sadece oda arayüzünde mi kalmalı?
2. Preview’un görünürlüğünü ayarlayın: Bot görecekse ölçün; görmeyecekse JS render’e güvenin ama tek başına “garanti” kabul etmeyin.
3. Robots meta kararlarını uygulayın: Gerekli sayfalarda noindex ve nofollow düşünün; canonical ile index kararını netleştirin.
4. Canonical’i preview’dan bağımsız kurgulayın: Aynı içeriğin birden çok varyantı oluşuyorsa canonical sabit kalmalı.
5. Render/kısmi DOM politikası uygulayın: Önizlemeyi içerik değeri ve kullanıcı güven skoru belirlesin.
6. Spam akışını tasarlayın: Link raporlandı/engellendiğinde preview’u kaldırın ya da yerine “removed by moderation” bileşeni koyun.

Aşağıdaki tablo, hangi sinyalin neyi etkilediğini ve hangi koşulda daha mantıklı olduğunu hızlıca görmenizi sağlar.

Kontrol sinyali	Ne sağlar?	OG preview etkisi	Önerilen kullanım
robots.txt / meta robots	Crawl veya index kararını yönlendirir	Bot kartı görse bile indekslemeyi azaltır	Mesaj arşivi gibi toplu sayfalarda
noindex	Sayfa indeksini kapatır	Preview’ın sayfa bazlı “SERP materyali” olmasını sınırlar	Yeni/karma UGC sayfalarında
nofollow	Link sinyalini kısar	Spammer’ın link etkisini azaltır	Şüpheli kullanıcı/raporlanmış linklerde
canonical	Tekil temsil URL’si seçer	Benzer OG çıktılarıyla tekrar oluşumunu azaltır	Varyant URL’lerde (parametre/oturum türevi)

Ürün tasarım seçenekleri: preview’ı kim/hangi koşulda gösterelim?

Teknik etiketlerden önce ürün tasarımında “preview gating” (önizleme kapısı) kurmak en pratik hamlelerden biridir. Çünkü bot görünürlüğünü kontrol etmek, spam riskini de doğrudan düşürür.

Örnek 2: Yeni üyeler için preview’ı geciktirme/önizlemeyi kapatma; onaylı hesaplar için preview izin verme. Bu yaklaşım, spammer’ların toplu link üretimini verimsiz hale getirir. Aynı zamanda gerçekten etkileşim kuran kullanıcıların deneyimi de daha korunur.

Üç pratik gating yöntemi:

• Hesap eşiği: doğrulanmış e-posta, yaş sınırı, hesap yaşına göre OG kartını aç.
• Mesaj bağlamı eşiği: Mesaj sadece linkten ibaretse preview yerine “Open link” göster; kullanıcı yorumu varsa preview’u aç.
• Rate limit: Aynı hesap/oda için kısa sürede çok sayıda benzersiz URL eklendiğinde preview’u kıs.

Teknik uygulama örnekleri: server-side render mı, client-side render mı? OG meta üretimi nasıl tetiklenir?

Teknik tasarım seçimi, crawler’ın gördüğü içerik ile kullanıcı deneyimi arasındaki dengeyi belirler. Bu yüzden “hangi taraf OG’yi üretmeli?” sorusunu bir karar matrisine bağlamak genelde en doğru yol olur.

Örnek 1 karşılaştırması: Preview HTML’de gömülü (crawler görür) vs. sadece JS ile yüklenen (crawler göremeyebilir) iki varyasyon düşünün. Eğer hedef, SERP’teki ince içerik riskini azaltmaksa, server-side render yerine kademeli yükleme daha az taranabilir metin üretir. Ancak “tam garanti” değildir; bu yüzden başka sinyallerle desteklemek gerekir.

Server-side yaklaşımda tipik akış şöyledir: mesaj gönderilir → backend URL’yi alır → OG metaları çekilir ve önbelleğe alınır → mesaj HTML’i preview ile üretilir. Client-side yaklaşımda ise mesaj HTML’de sadece “placeholder” kalır → tarayıcı API’den preview verisini alır → kart basılır. Client-side için botların render davranışı değişken olabildiği için, “sadece JS ile gizledim oldu” yaklaşımı tek başına yeterince güvenli sayılmaz.

OG meta üretimi konusunda dikkat edilmesi gereken başka bir nokta daha var: Chat uygulaması kendi sayfasında OG etiketleri set ediyorsa (özellikle “dinamik og:description” gibi), bu etiketleri “hangi mesajı temsil ediyor?” sorusuna göre doğru seçmelisiniz. Yanlış temsil, SERP snippet benzeri seçimlerde spam etkisini daha görünür hale getirebilir.

Ölçüm ve izleme: indeks durumu, crawl istatistikleri, webmaster tools raporları, log analizi

Kontrol uyguladığınızda ölçmeden “indekslendi/indeklenmedi” varsayımı yapmak kolayca hata üretir. Bu iş için minimum bir ölçüm seti kurmalısınız: indeks durumunu doğrulama, crawler’ın ne gördüğünü anlama ve spam davranışının etkisini takip etme.

Önerilen izleme kaynakları: Search Console’da URL denetimi, site tarama raporları, “Görünüm”/“keşfedildi” sinyalleri ve sunucu loglarında bot user-agent davranışları. Ayrıca OG preview sağlayan endpoint’lerin hız/istek hacmini izleyerek botların kartı çekip çekmediğini dolaylı yoldan görebilirsiniz.

Ölçüm yaklaşımı şu ayrımdan geçmelidir: (a) Mesaj sayfası index alıyor mu, (b) Aynı URL için preview kartı hangi varyantta üretiliyor, (c) Bu varyantlar canonical/noindex kararlarıyla çakışıyor mu. Bu üç başlık birlikte ele alınmazsa yanlış optimizasyon yapmak çok kolay olur.

Yaygın hatalar: Kaçınılması gerekenler ve beklenen hatalar

En sık karşılaşılan sorun, preview’ı “gizleme” zannedip SEO/anti-spam sinyallerini tutarlı yönetmemektir. Aşağıdaki hatalar özellikle indekslenebilir UGC sayfalarında daha sık görünür.

• Tek hamleye bel bağlamak: Sadece “preview JS ile yükleniyor” demek çoğu senaryoda yetmez. İkinci bir sinyal (noindex/robots/canonical veya gating) eklenmelidir.
• Canonical’ı tutarsız yapmak: Preview varyantlarına göre canonical değişiyorsa, Google farklı URL’leri farklı temsil ediyor gibi algılayabilir.
• Raporlama/engelleme sonrası preview güncellenmemesi: Link kaldırılınca preview kaldırılmazsa, geride kalan kart metni taranabilir kalır.
• Benzer OG metinlerini sınırsız üretmek: Aynı URL’den yüzlerce kart üretmek, kalite sinyallerini düşürür ve “ince içerik kümeleri” riskini büyütür.

Örnekler: Kullanıcı davranışı, varyantlar ve anti-spam akışı

Örnek mesaj (çoğalma): Aynı URL’nin farklı kullanıcılar tarafından paylaşılması. Diyelim ki bir oda içinde 50 kişi aynı linki postaladı. Preview HTML’de gömülü ise, her mesajda aynı OG title/description tekrar eder. Bu tekrar, crawler’ın sayfayı “link toplayıcı” gibi değerlendirmesine zemin hazırlayabilir.

Örnek 1 (HTML gömülü vs JS): Bir varyasyonda kart DOM’da baştan görünür; diğerinde kart yalnızca JS ile API’den gelir. İkinci varyasyonda crawler’ın görme ihtimali düşer; ancak render kapasitesi ve bot davranışı değişken olduğundan eş zamanlı noindex/canonical stratejisiyle desteklemek gerekir.

Örnek 2 (gating): Yeni üyeler için preview geciktirilir veya hiç gösterilmez. Onaylı hesaplarda preview aktif kalır. Böylece spammer’ların “kullanıcı eşiği”ni aşmak için ekstra maliyet ödemesi gerekir.

Örnek 3 (raporlama akışı): Kullanıcı linki raporlanınca preview’u otomatik kaldırma/replace etme. Uygulamada; moderation event tetiklenir → mesaj state güncellenir → preview DOM’u “removed” bileşeniyle değiştirilir. Böylece eski OG metinleri sayfa üzerinde kalmaz.

Nasıl kontrol edilir? Adım adım doğrulama (indekslenip indekslenmediğini ve sinyalleri test edin)

Aşağıdaki kontrol adımları, “OG preview indeksleniyor mu?” sorusunu pratikte doğrulamanızı sağlar. Amaç sadece Google’ın index’lediğini görmek değil; crawler’ın kartı gerçekten görüp görmediğini ve hangi sayfa sinyallerinin devrede olduğunu anlamaktır.

1. Bir test oda/mesaj seçin: Aynı URL’yi birden fazla kullanıcıyla paylaşın (ideal olarak hem yeni hesap hem güvenli hesap).
2. “Görünen HTML”i doğrulayın: Sayfa kaynağında preview HTML’i var mı? Yoksa placeholder mı görünüyor? (View-source / DOM inspection)
3. Google URL denetimi ve canlı test çalıştırın: Search Console’da ilgili URL için “tarandı mı, ne görünüyor” sinyallerini inceleyin.
4. Robots/noindex/canonical etkisini doğrulayın: Mesaj sayfasında meta robots kararları ve canonical değişiyor mu kontrol edin.
5. Log/endpoint ölçümü yapın: Botlar preview API’nizi çağırıyor mu? Çağırmıyorsa, JS yaklaşımı gerçekten bot için kısmi görünürlük yaratıyor demektir.
6. Moderasyon sonrası tekrar test edin: Link raporlanıp kaldırıldıktan sonra preview’ın DOM’u değişiyor mu? Eski kartın cache’lenip dönmediğini doğrulayın.

Kural seti ve karar matrisi: Hangi koşulda preview gösterilsin/gizlensin/indekslensin?

Son adım, bir “policy” oluşturmaktır. Aşağıdaki karar matrisi; preview’un kimin gördüğünü, botların neyi taradığını ve hangi sayfaların index alacağını birlikte düşünmenizi sağlar.

Koşul	Preview görünürlüğü	Sayfa indeksi	Link sinyali
Yeni üye + mesaj sadece tek URL	Gecikmeli veya kapalı (placeholder)	noindex (veya robots ile kısıt)	Şüpheli ise nofollow
Onaylı hesap + mesajda bağlam var	Aktif preview	Duruma göre (oda/arama politikası)	Gerekirse indexlenen sayfalarda normal follow
Raporlanan/engellenen link	Otomatik kaldır/replace	noindex + canonical sabitle	noindex/no-follow ile tutarlı
Aynı URL yüksek tekrar (hızlı çoğalma)	Rate limit + gating (kıs)	İçerik küme riskine göre index’i azalt	Bot odaklı kısıt

Bu matrisi kurgularken sayfa mimarisine dair diğer UGC kontrollerini de eşleştirin. Örneğin mesaj eylem butonları gibi DOM parçalarının bot-safe tasarımı, benzer ince içerik/DOM şişmesi problemlerini tetikleyebilir. Bu konuyu şu rehberle birlikte düşünmenizi öneririm: Chat Mesajında Eylem Butonları (Beğen/Cevapla/Paylaş) Bot-Safe HTML Nasıl Tasarlanır? SEO’da İndekslenmemesi/İndekslenmesi Gereken DOM Bölümleri.

Benzer şekilde; kullanıcı ayar parametreleri URL’ye taşınıyorsa ve canonical temizliği doğru yapılmazsa preview varyantlarıyla birlikte index israfı büyüyebilir. Parametre/kanonik yaklaşımı için şu bağlantıyı inceleyin: Chat Sitelerinde Kullanıcı Ayar Parametreleri URL’ye Yazılırsa SEO Ne Olur? (Tema/Dil/Bildirim) — Parametre Temizliği ve Canonical Stratejisi.

İsterseniz, reply thread gibi parent-child URL tasarımlarında indeks/krawl kontrolleri nasıl birleşiyor onu da paralel düşünün; çünkü mesaj zincirleri preview’la birlikte “tek sayfada çok fazla bağlam metni” üretme eğilimindedir: Chat Sitelerinde Reply Thread (Cevap/Zincir) İndeksleme: Parent-Child URL Tasarımı, Canonical ve Crawl Kontrolleri.

SSS

OG preview’un indekslenip indekslenmediğini nasıl anlayabilirim?

Search Console’da URL denetimi yapın, ayrıca sayfa kaynağında preview HTML’i gerçekten görünüyor mu kontrol edin. Ek olarak sunucu loglarında botların preview API’sine çağrı yapıp yapmadığını inceleyin. Eğer preview yalnızca JS ile geliyorsa ve bot çağrı yapmıyorsa, indeksleme ihtimali düşer; yine de noindex/robots/canonical gibi sinyallerle doğrulamayı unutmayın.

Link preview içeriği sayfanın canonical/robots kararını nasıl etkiler?

Link preview, sayfanın temsil edilen metnini artırır. Bu nedenle robots/noindex ve canonical kararları preview’a göre sabit ve tutarlı olmalı. Varyantlar arasında canonical değişiyorsa, Google aynı mesaj bağlamını farklı URL’lerde temsil edebilir. Preview’u kaldırmak veya placeholder’a indirmek, temsil metnini dengeleyerek riski azaltır.

Preview’ı JS ile geciktirmek tek başına yeterli mi?

Hayır. JS geciktirme “görünürlüğü azaltır” ama garanti sağlamaz. Bot render davranışı, crawl bütçesi ve cache gibi unsurlar sonucu değiştirebilir. Bu yüzden gating (ürün), noindex/robots (sayfa politikası) ve canonical (varyant kontrolü) birlikte kurgulanmalıdır.

Nofollow/noindex kullanmak her durumda spam riskini azaltır mı?

Azaltır, ancak tek başına “tam çözüm” değildir. Spammer’lar için asıl maliyet, taranabilir ve indekslenebilir düşük değerli sayfa üretimini zorlaştırmaktır. Rate limit, hesap eşiği, raporlama sonrası preview kaldırma gibi aksiyonlar nofollow/noindex’in etkisini tamamlar.

Zengin snippet oluşması SEO’yu artırır mı yoksa spam’i mi görünür yapar?

Bağlam gerçekten kaliteliyse SEO’ya katkı verebilir; ama bağlam yoksa (tek URL + tekrarlı OG metni) spam görünürlüğünü artırma riski vardır. Bu nedenle preview’ı bağlam eşiğiyle açmak (kullanıcı yorumu varsa göster) daha güvenli bir tasarımdır.

Rate limit ve preview gating (kimler görebilir?) nasıl ölçülür?

Preview API istek oranlarını, preview gösterilen kullanıcı yüzdesini ve bot user-agent’ların erişim durumunu ölçün. Ayrıca moderation olaylarından sonra preview’un ne kadar sürede kaldırıldığını takip edin. Ölçüm raporları, gating politikanın etkisini sayısal hale getirir.

Kontrol listesi (kısa): OG preview indeksleme + anti-spam ayarlarını belirleyin

Son olarak, bir ekip odasında uygulanabilir pratik kontrol listesiyle bitirelim. Bu listeyi “tasarım inceleme” dokümanına dönüştürmek, yanlış karar riskini düşürür.

• Preview server-side mı client-side mı? Crawl ile görünen HTML doğrulandı mı?
• Mesaj sayfaları için noindex/robots/canonical kararları tutarlı mı?
• Preview gating var mı (yeni üye eşiği, bağlam eşiği, rate limit)?
• Raporlama/engelleme sonrası preview otomatik kaldırılıyor mu (replace edilir mi)?
• Aynı URL’nin yüksek tekrarında indeks riski azalıyor mu (küme kontrolü)?
• Search Console + log analiziyle gerçek indeks durumu doğrulandı mı?