Chat’te Bildirim Ayarları URL Parametresine Dönüyorsa Canonical Nasıl Sabitlenir? Varyantlar Crawl Etmesin Teknik Kılavuz

Chat uygulamalarında kullanıcı, “bildirim ayarları”nı (kanal/oda kapsamı, sıklık, yalnızca mention, sessize alma vb.) değiştirdiğinde, frontend çoğu zaman bu tercihi URL parametrelerine yazar. Dışarıdan bakınca bu, sadece “parametre eklemek” gibi görünür. Ama SEO tarafında her kombinasyon ayrı bir varyant URL demektir ve farkında olmadan ince içerik riskini büyütebilir. Bu yazıda chat sitesinde bildirim ayarları URL parametreye yansırsa canonical nasıl sabitlenir ve varyantlar crawl etmez hedefini, canonical teklemesiyle crawl izolasyonunu birlikte ele alarak adım adım kuracağız.

Özellikle SEO mühendisleri için kritik olan nokta şudur: Canonical teklemesi yalnızca “index” sorununu azaltmakla kalmaz; aynı zamanda “crawl bütçesi” ve log davranışları üzerinden varyantların taranmasını da kontrol etmeniz gerekir. Aksi halde GSC’de Coverage dalgalanabilir ve gerçek sayfaların taranma sıklığı düşebilir. Bu yüzden rehber; HTML/HTTP uygulama adımlarını, doğrulama yöntemlerini ve ölçümle doğrulama senaryolarını beraber sunar.

Sorun Tanımı: Bildirim Ayarları Neden URL’ye Düşer ve İnce İçerik Riski Nasıl Oluşur?

Bildirim ayarı parametresi URL’ye düştüğünde, örneğin ?notif=mentions-only veya ?freq=low gibi değerler aynı oda için farklı sayfa görünümleri üretir. Çoğu durumda bu fark “tamamen kişisel tercih”tir; yani içerik gövdesi, mesaj listesi ya da oda metaverisi aslında aynı kalabilir. Arama motoru açısından ise her farklı sorgu parametresi yeni bir URL gibi çalışır.

Bu durum ince içerik riskini tetikler: aynı oda sayfasının “benim bildirimlerime göre” üretilen varyantlarını arama motoru keşfetmeyi kolayca öğrenebilir. Fakat gerçek anlamlı farklılık üretmediği için index kalitesi zamanla düşebilir. Üstelik chat sayfaları dinamik olduğu için crawl bütçesi daha hassastır; botlar gereksiz varyantları tararsa “ana” sayfanın güncellik sinyalleri gecikebilir.

Varyant Kataloğu: Bildirim Ayarı Parametrelerinin Tipleri (mute, channel/room scope, event türü, sıklık, read/unread, cihaz tipi vb.)

Tek bir notif parametresi her şeyi kapsıyor gibi görünse de, pratikte bildirim ayarları farklı eksenlerde modellenir. Aşağıdaki katalog, varyant sayısının nasıl büyüdüğünü anlamanız için iyi bir başlangıçtır:

• On/Off & kapsam: all-off, mentions-only, channel-scope=room / room-scope=123
• Event türü: events:message, events:reply, events:reaction
• Sıklık/frequency: freq=low, freq=balanced, freq=high veya “daily digest” benzeri modlar
• Mute/Session tipi: “1 saat sessize al”, “süreli mute”, “device-specific mute” gibi zaman pencereleri
• Okunma durumu etkisi: unread=only veya okunmamış mesaj vurgusu (bazı uygulamalarda içerik etkiler)
• Cihaz tipi/akış: device=web, device=ios gibi istemci davranışı farkları

Bu eksenlerin kombinasyonu varyant sayısını hızlıca katlayabilir. Bu yüzden canonical kararını sadece “notif var/yok” üzerinden değil, hangi alanların gerçekten içerik farkı ürettiğini hesaba katarak vermelisiniz.

Hedef URL Tasarımı: Tek bir ‘ana’ canonical adresi nasıl seçilir (parametrelerin hangi grubu canonical’e dahil edilir/edilmez?)

Canonical sabitlemenin ilk adımı “ana URL”yi doğru seçmektir. Chat senaryosunda genelde oda/konuşma kimliğini taşıyan “çıplak” URL ana kabul edilir: örneğin /chat/room/123. Bildirim parametreleri ise kullanıcı tercihi olduğu için çoğu zaman canonical’e dahil edilmemelidir.

Pratik bir karar kuralı şu şekilde önerilebilir: Tercih parametreleri (mute, mentions-only, frequency, device) içerik gövdesini değiştirmiyorsa canonical dışı kalmalı; anlamlı içerik parametreleri (gerçek filtreleme, farklı mesaj seti/erişim düzeyi, dil gibi içerik değişimi) ise ayrı canonical mantığı gerektirebilir. Ancak bu yazının odağı “bildirim ayarları” olduğu için varsayılan hedefimiz şu: bildirim parametrelerini canonical’e sokmadan ana URL’ye teklemek ve botların varyantları taramasını azaltmak.

Canonical Sabitleme Stratejisi: Aynı içerik/ağır farklılık ayrımı + canonical tag kuralları (view-source seviyesinde doğrulama)

Canonical sabitleme stratejiniz iki katmanlı olmalı: (1) index teklemesi, (2) crawl izolasyonu. Önce index teklemesini kurun: her varyant sayfasında canonical değeri aynı “ana oda” URL’si olmalıdır.

“Ağır farklılık” durumunu da ayrıca netleştirin: Eğer bildirim parametresi gerçekten kullanıcıya farklı bir mesaj akışı (ör. sadece mention’ları gösteren ayrı liste) veriyorsa, bu fark içerik değişimine dönüşür. Bu durumda iki seçenek vardır: ya bu varyantı tamamen noindex/crawl-isolate edecek şekilde konumlayıp ana URL’yi tercih edersiniz ya da gerçekten farklı ve erişilebilir bir içerik sunuyorsanız (ve index hedefiniz varsa) canonical’i yine ana URL’ye değil, bu “mention view” gibi farklı bir kurala bağlarsınız. Chat’te çoğu ürün için mention filtreleme bile çoğu zaman kişiselleştirilmiş bir görünüm olduğundan genellikle index hedefi olmaz.

Doğrulama tarafında en kritik yöntem view-source seviyesinde kontrol etmektir. Response render’dan sonra değil, doğrudan HTML çıktısında <link rel="canonical"> değerini varyant URL üzerinden açıp karşılaştırın. Aynı oda için ?notif=all-off veya ?notif=mentions-only çağrılarında canonical’in /chat/room/123 olarak döndüğünü “gerçek HTML” üzerinde doğrulayın.

Hreflang/Homolog Varyantlar (Varsa): Dil/cihaz/tema gibi diğer parametrelerle çakışmayı önleme

Bildirim parametrelerini canonical’e gömmek, farklı boyutlarla çakışma riskini artırabilir. Örneğin cihaz tipi device=web ile tema/renk şeması gibi görsel tercih parametreleri aynı anda URL’ye yazılıyorsa, canonical yanlış kombinasyonlarla tekil olmayan bir hal alabilir.

Bu yüzden eğer dil/ülke varyantları varsa (ör. /chat/room/123?lang=tr) canonical’i dil karşılaştırmasıyla uyumlu kurun; hreflang ilişkilerini dil parametrelerine bağlayın, bildirim parametrelerini ise canonical kararında yok sayın. Cihaz/tema gibi homolog parametreleri de SEO boyutundan ayırın: gerekirse sadece HTTP cache/behavior için kullanın, HTML canonical’e etkilerini minimumda tutun.

Crawl İzolasyonu: Sadece noindex değil, varyantların taranmasını azaltmak için pratik yöntemler

Noindex kullanmak indexi durdurabilir ama crawl bütçesini otomatik olarak kesmez. Google botu “noindex” gördüğü URL’yi tarayabilir; özellikle dinamik parametreler, botun keşif döngüsünü artırabilir. Hedefiniz “varyantlar crawl etmesin” ise hem taramayı hem keşfi azaltan sinyalleri birlikte tasarlamanız gerekir.

Aşağıdaki yöntemler tipik olarak beraber uygulanır:

1. robots meta / x-robots-tag: Bildirim varyantları için noindex, follow yerine “nofollow”u da düşünün. Eğer sayfa içinde SEO açısından yeni keşif linkleri yoksa, taramayı azaltmak için internal link davranışını kontrol edin.
2. Sitemap’tan hariç tutma: Bu varyantları sitemap’a eklemeyin. Sadece ana oda URL’leri indexlenme ve keşif için hedef olmalı.
3. Internal link stratejisi: Uygulama UI, “bildirim ayarı mevcutken” farklı URL’lere link üretmesin. Navigasyon/geri butonları ana URL’ye dönsün ya da linkleri query’siz üretin.
4. Link parametresi yönetimi: Benzer parametreler (utms, cihaz, tema) URL üretimini artırıyorsa “SEO rotası” üretmeyin. Arama motoru için stabil canonical rotası tek olmalı.
5. Watched behavior + rate limiting: Botların varyant URL keşfini artırdığı loglarda görülüyorsa, aynı varyant ailesine yönelik WAF/edge seviyesinde rate-limit uygulayın.

Bu yaklaşım, crawl davranışını yalnızca “noindex”e bırakmak yerine log/Index Coverage sinyalleriyle ölçülebilir hale getirir.

HTTP Seviyesi Uygulama Örnekleri: X-Robots-Tag / HTTP header üzerinden kontrol

HTTP header ile kontrol, özellikle CDN/edge tarafında performanslı ve tutarlı bir yöntemdir. Bildirim parametresi algılandığında response’a X-Robots-Tag ekleyebilirsiniz. Ama önemli bir nokta var: header ve HTML canonical/robots meta uyumu sağlamalıdır; aksi halde bazı tarayıcılar tutarsız sinyal görebilir.

Örnek karar şu şekilde düşünülebilir: /chat/room/123?notif=mentions-only gibi varyantlarda canonical ana URL’ye dönsün; ama indexlenmesin ve idealde crawl davranışı da azaltılsın. Header yaklaşımında örnek mantık:

• Bildirim varyantı ise: X-Robots-Tag: noindex, nofollow (ürün link keşfi yoksa)
• Ana URL ise: normal indexlenebilir response

Cache davranışı da kritik: CDN aynı URL varyantlarını yanlış cache’leyebilir. Cache anahtarına bildirim parametresini dahil etmeden ilerlerseniz, yanlış içeriğin ana sayfaya servis edilmesi riski doğar. Bu yüzden varyant response’larında “aynı HTML body” üretmeyi hedefliyorsanız bile, header düzeyinde sinyalin doğru geldiğini doğrulamalısınız.

HTML Seviyesi Uygulama Örnekleri: canonical link elementi, robots meta, parametreye göre içerik farkı minimum stratejisi

HTML seviyesinde canonical link elementini varyant sayfalarında da aynı değere sabitleyin. Bunun yanında robots meta veya <meta name="robots"> kullanabilirsiniz. Eğer HTTP header ile X-Robots-Tag veriyorsanız, HTML meta ile de uyumlu tutun.

Parametreye göre içerik farkını minimumda tutmak iyi bir güvenlik katmanı olur. Örneğin bildirim ayarı sadece bildirim panelindeki UI durumunu etkiliyorsa, sayfa mesaj listesini aynı bırakın. Eğer sayfa body’si hiç değişmiyorsa canonical/noindex ayrımı daha net yönetilir: canonical tek ana URL, varyantlar noindex (ve idealde taranmasın) şeklinde ele alınır.

İç Linkleme ve Navigation: Kullanıcı etkileşimlerinden üretilen URL’leri ‘SEO rotası’ haline getirmeme

Chat uygulamalarında kullanıcı bildirim ayarını değiştirdiğinde URL güncellenebilir. Buradaki risk: bu yeni URL’nin uygulama içinde “link” olarak dağıtılmasıdır. Örneğin sohbet listesinden oda sayfasına geçişte “notif parametresi ile” gidilirse, botlar için keşif çarpanı oluşur.

Çözüm: SEO rotası tek olsun. UI navigasyonunu mümkünse ana oda URL’si üzerinden yapın; bildirim ayarını client-state, cookie veya POST/başlık gibi yöntemlerle taşıyın. URL zorunluysa bile, linklerin canonical rotayı bozmadığını ve internal link üretilen anchor’larda parametre taşınmadığını doğrulayın.

Ölçüm ve Doğrulama: GSC (Coverage/URL Inspection), log analizi, crawl frequency sinyalleri, indexlenme oranı

“Varyantlar crawl etmesin” vaadini gerçek verilerle doğrulayın. Sadece canonical/noindex koyup beklemek tek başına yeterli değildir. GSC’de URL Inspection ile Submitted vs. Canonical uyuşmazlıklarını gözlemleyin; ayrıca Coverage raporunda varyant kümelerinin neden indexlenmediğini netleştirin.

Log analizi özellikle değerlidir: Web server/CDN loglarında ?notif= desenli URL’lerin request sayısını ve tarama periyodunu takip edin. Eğer noindex uyguladığınız halde varyantlar yüksek frekansta gelmeye devam ediyorsa, keşif kanallarını (internal link, dış referrer, sitemap) tekrar gözden geçirmek gerekir.

Ek olarak indekslenme oranı metriği tutun: “ana URL indexte mi, varyantlar index dışı mı” karşılaştırması yapın. Ortalama crawl frequency’de ana URL lehine artış görmeyi bekleyin. Bu da canonical teklemenin ötesinde crawl izolasyonunun gerçekten çalıştığını gösterir.

Kenar Durumlar: Kullanıcı oturumu/kısmi kişiselleştirme, koşullu içerik ve aynı URL’de görünür farklar

Chat’te oturum bazlı kişiselleştirme kaçınılmaz olabilir: aynı URL, farklı kullanıcı için farklı bildirim paneli durumuna sahip olur. Bu noktada SEO boyutuyla ürün boyutunu ayırmak gerekir. Arama motoru botlarının çoğu zaman oturum taşımadığını varsayarak “bot-state” için deterministik bir içerik üretmek daha sağlıklıdır.

Örneğin kullanıcı ayarı URL’de olsa bile sayfanın body içeriği değişmiyorsa canonical/noindex ayrımı daha stabil çalışır. Ama body gerçekten değişiyorsa (mention-only mesaj seti gibi) botun “temsil edilen içerik” görümü önem kazanır. Bu senaryolarda canonical kararınızı daha sıkı netleştirin ve gerekirse varyantları tamamen kapatın.

Yaygın Hatalar

İnce içerik ve crawl bütçesi sorunlarını büyüten tipik hatalar şunlardır:

• Parametreyi canonical’e dahil etmek: Örneğin canonical’i /chat/room/123?notif=mentions-only yaparsanız, arama motoru her varyantı farklı “ana” gibi algılamaya başlar. Bu, teklemenin tam tersi sonuç üretir.
• Sadece noindex ile yetinmek: Varyantlar crawl edilebilir ve keşif kanalları devam ederse loglarda sürekli istek görürsünüz. “Crawl etmesin” hedefi için robots/sitemap/internal link izolasyonu gerekir.

Buna ek olarak sık görülen bir başka hata da “header ile HTML meta tutarsızlığıdır”. Örneğin header’da noindex var ama HTML meta index dönüyorsa ya da canonical farklıysa, GSC’de uyuşmazlık görürsünüz ve düzeltme döngüsü uzar.

Örnekler

Aşağıdaki örnekler, bildirim ayarı parametreleri varyant ürettiğinde canonical kararını ve crawl izolasyonunu nasıl kurgulayacağınızı somutlaştırır.

Örnek 1: /chat/room/123?notif=all-off canonical sabitleme (ana varyant /chat/room/123 seçimi) ve varyantların indexlenmemesi

Varsayım: ?notif=all-off yalnızca bildirim panelini etkiliyor; mesaj listesinin gövdesi değişmiyor.

• Canonical: <link rel="canonical" href="https://site.com/chat/room/123">
• Index kontrol: HTTP header veya meta ile noindex, nofollow (ürün link keşfi yoksa)
• Sitemap: Bu varyant eklenmez.

Sonuç: Google botu varyantı tarasa bile ana sayfayı canonical olarak görür; indexte varyant kümelenmez ve crawl bütçesi ana URL’ye yönlenir.

Örnek 2: /chat/room/123?notif=mentions-only&freq=low kombinasyonu için canonical karar ağacı

Karar ağacı:

• Notif türü mention-only ise: genelde kişisel filtre. Body değişmiyorsa (sadece UI): canonical /chat/room/123
• Frequency low: mesaj içerik seti değişmiyorsa aynı mantık
• Body gerçek değişiyorsa (mention-only gerçek listeyi değiştiriyorsa): tercihen yine noindex yapıp ana URL’yi tek tutun; eğer gerçekten ayrı içerik istiyorsanız farklı stratejiye geçin.

Bu örnekte öneri: canonical ana URL; noindex/no-follow. notif + freq kombinasyonu canonical’e taşınmaz.

Örnek 3: /chat/room/123?notif=events:message,reply&device=web parametrelerinin ayrı varyantlar üretmesi ve crawl izolasyonu yaklaşımı

Bu varyant tipi iki farklı eksen içerir: event türü ve cihaz. Her biri URL’ye yazılıyorsa tarayıcılar farklı varyantlar keşfetmeye daha yatkın hale gelir.

• Canonical: yalnızca /chat/room/123
• Crawl izolasyonu: device ve event parametrelerinin olduğu tüm varyantlara robots meta/header ile noindex/no-follow
• Cache & determinism: bot-state’de mesaj listesi değişmiyorsa body’yi deterministik yapın; sinyal tutarlı olsun.

Önemli nokta: device parametresinin SEO kapsamı olmamalı. “Cihaz farklı” diye ayrı index hedefi oluşturmayın.

Örnek 4: Kullanıcının ayarı URL’de olmasına rağmen sayfanın body içeriğinin değişmemesi durumunda canonical/noindex ayrımı

Varsayım: URL’de ?notif=muted var ama mesaj listesi aynı; sadece bildirim panelinde “Muted” görünüyor.

• Canonical: yine ana oda URL’si
• Noindex: varyant URL’yi index dışı bırakın
• İdeal ek adım: internal linklerde parametre kullanılmasın; sitemap’a eklemeyin

Bu durumda canonical teklemesi çok net çalışır ve crawl izolasyonu “gereksiz keşif”i azaltır.

Kontrol Listesi (TL;DR): Uygulama adımları ve test kriterleri

Kurulumu planlarken aşağıdaki kontrol listesi hızlı bir çerçeve verir. Elinizdeki gerçek değerleri loglar ve GSC’de doğrulayın.

1. Varyant tespiti: notif, freq, device, events gibi parametrelerin varyant ürettiğini desen olarak belirleyin.
2. Canonical sabitleme: Varyant HTML çıktısında canonical’i her zaman ana URL’ye sabitleyin (/chat/room/ROOM_ID).
3. Noindex + crawl izolasyonu: Varyantlar için HTTP header (X-Robots-Tag) veya meta ile noindex, nofollow yaklaşımını uygulayın; sitemap hariç tutun ve internal linklerde parametre kullanımını kesin.
4. Cache/doğrulama: CDN cache anahtarında yanlış içerik sızıntısı olmadığını kontrol edin (view-source ve header doğrulaması).
5. Ölçüm: GSC URL Inspection ile Submitted vs. Canonical uyuşmazlığının düştüğünü; loglarda varyant isteklerinin azaldığını doğrulayın.

Nasıl kontrol edilir? Adım adım doğrulama adımları

Takımınızın canonical/noindex ve crawl izolasyonunu gerçekten doğru şekilde uyguladığını doğrulamak için aşağıdaki adımlar pratikte en hızlı sinyali verir:

1. Varyant URL’yi ve view-source’u karşılaştırın: /chat/room/123?notif=all-off gibi 2-3 varyanta gidin; HTML’de canonical’in her zaman /chat/room/123 olduğunu doğrulayın.
2. HTTP header doğrulayın: Aynı isteklerde X-Robots-Tag veya meta robots değerlerinin gerçekten noindex içerdiğini kontrol edin.
3. GSC URL Inspection: Submitted URL varyant olsa bile Canonical’in ana URL olarak raporlandığını görün; Coverage tarafında indexlenmeme nedenini izleyin.
4. Log analizi: Uygulama sonrası 1-2 hafta içinde ?notif= desenli request sayısının azaldığını ve ana URL’nin crawl frekansının göreli arttığını karşılaştırın.

Uygulama Oncelikleri: Hangi sinyal neyi çözer?

Sinyal	Hedef	Bildirime Özgü Uygunluk
Canonical (HTML link)	Index teklemesi / Submitted vs. Canonical tutarlılığı	Yüksek: Bildirim varyantlarında ana oda URL’ye sabitle
X-Robots-Tag / robots meta	Indexlemeyi durdurma (noindex) ve keşif davranışını azaltma	Yüksek: Varyantlarda noindex (tercihen nofollow)
Sitemap’tan çıkarma	Keşif yüzeyini azaltma	Orta-Yüksek: Bildirim varyantlarını ekleme
Internal link parametre yönetimi	Crawl’in ana sayfa dışına taşmasını engelleme	Yüksek: Navigasyon ana URL’ye dönsün

Sık Sorulan Sorular (FAQ)

1) Canonical’i yalnızca noindex ile mi yönetmeliyim? Crawl yine de olur mu?
Noindex indexi durdurur ama crawl’ü otomatik olarak azaltmayabilir. Crawl bütçesi hedefliyorsanız canonical teklemesine ek olarak robots meta/header, sitemap hariç tutma ve internal link parametre temizliği gerekir.

2) Bildirim ayarı parametresi içerik değiştiriyorsa (gerçekten farklı mesaj akışı) canonical yine aynı URL mi olmalı?
İçerik gerçekten farklı bir “liste” üretmiyorsa ve bu fark kullanıcı tercihi kaynaklıysa genellikle index hedefi olmaz: ana URL’ye canonical, varyantlara noindex mantığı çoğu chat ürününde daha güvenlidir. Eğer gerçekten ayrı içerik stratejiniz varsa, farklı canonical kuralları gerekebilir.

3) GSC’de canonical uyuşmazlığı (Submitted vs. Canonical) nasıl anlaşılır?
GSC URL Inspection’da Submitted URL varyant görünür, Canonical alanında ana URL referans edilir. Buradaki amaç: tutarlı bir şekilde varyantların canonical’e bağlanması ve Coverage raporunda “indexlenmeme” nedenlerinin tutarlı görünmesidir.

4) robots meta ile noindex kullanmak yeterli mi, tarama bütçesi için ek adım gerekir mi?
Yeterlilik “rawl behavior”ınıza bağlıdır. Loglarda varyantların tarandığı görülüyorsa ek adım gerekir: sitemap hariç tutma, internal link temizliği ve (gerekirse) edge seviyesinde keşfi azaltma.

5) Parametreyi canonical’e dahil edersek nasıl bir risk oluşur?
Varyantlar “alternatif ana sayfalar” gibi değerlendirilebilir; teklemeniz bozulur. Bu da index kalitesini ve varyant yayılımını artırabilir.

6) Aynı sayfada kişisel ayar varsa (muted), URL’yi indexe açık bırakmak doğru mu?
Muted gibi kişisel bildirim tercihlerinin SEO değeri genelde düşüktür. URL’yi indexe açık bırakmak ince içerik ve gereksiz indexlenme riskini artırır; canonical ana URL’ye, varyantlara noindex yaklaşımı daha uygundur.

7) Sitemap’a bu varyantları eklemek/eklememek nasıl etkiler?
Eklemek keşfi artırır ve botların varyantları daha sık ziyaret etmesine yol açabilir. Bildirim varyantları index hedefi değilse sitemap’a eklememek daha doğrudur.

Son Değerlendirme: Bildirim varyantlarında “tek canonical + crawl izolasyonu” birlikte çalışmalı

Bildirim ayarlarının URL’ye yansıması, chat sitelerinde sık karşılaşılan “ince içerik + crawl dağılımı” problemlerinden biridir. Doğru yaklaşım, canonical’i ana oda URL’sine sabitlemek ve varyantları sadece noindex ile değil; robots/header, sitemap ve internal link stratejileriyle crawl yüzeyinden uzaklaştırmaktır.

En önemlisi: tüm kararları “görünür canonical etiketi doğru mu?” kadar “loglarda varyantlar azalıyor mu, GSC’de Coverage istikrarlı mı?” sorularıyla doğrulayın. Böylece chat sitesinde bildirim ayarları URL parametreye yansırsa canonical nasıl sabitlenir ve varyantlar crawl etmez vaadini; uygulama + ölçüm düzeyinde güvenilir şekilde kapatmış olursunuz.