Chat Sitelerinde Canonical Otomatik Üretim Hataları: Hash ve Oturum Parametrelerini Doğru Ele Alma

Chat siteleri büyüdükçe URL varyantları da istemeden çoğalır: aynı “oda” bazen farklı kullanıcılar için farklı görünebilir; sohbetin durumu, kullanıcıyı izleme veya oturum takibi gibi detaylar da URL’nin içine taşınır. Bu noktada en kritik risklerden biri, chat sitelerinde canonical otomatik üretim hataları: query string değil hash/oturum parametresi kaynaklı sinyali yanlış kanonikleştirmek olur.

Özellikle SPA mimarilerde (ya da hash tabanlı yönlendirmede) canonical etiketinin otomatik üretilmesi, her kullanıcı/oturum için değişen bir “kanıt” üretir. Sonuç? Arama motorları aynı içeriği farklı URL’ler sanır; varyantlar çoğalır, crawl/bütçe gereksiz yere harcanır. Bu rehberde, hash (#) ile oturum/track parametrelerinin canonical’e nasıl yansıdığını adım adım ve teknik açıdan ele alacağız.

Sorun Haritası: Query string değil hash/oturum kaynaklı URL varyasyonları (örnek senaryolar)

Chat sitelerinde URL varyasyonu çoğu zaman “gerçek sayfa” değişiminden değil; gezinme durumu ve izleme/oturum mekaniklerinden gelir. Hash (#) ve oturum parametreleri kullanıcı deneyimini kesintisiz tutmak için sık kullanılır; ama canonical sinyali doğru kurulmazsa SEO tarafı bundan ciddi şekilde etkilenir.

Aşağıdaki senaryolar, canonical otomatik üretiminin nerede kırıldığını gösterir. Burada anlatım “query string” üzerinden değil; oda/room hash yapısı ile session/track parametrelerinin etkisi üzerinden ilerler.

• Hash ile oda durumu: Kullanıcı odanın hangi alt sekmesinde olduğuna göre URL değişir: https://site.com/chat#/%2Fchat/room1 → https://site.com/chat#/%2Fchat/room2. İki URL’de de aynı template çalışır; içerik oda bağlamına göre farklılaşır. Ancak canonical üretimi hash’i “içeriğin kendisiymiş” gibi sabitlemeye kalkarsa, varyant sayısı ister istemez artar.
• Oturum/izleme parametresi ile sayfa varyasyonu: https://site.com/room/room1?sid=ABC veya ?sessionId=ABC. Aynı oda için içerik aynı kalırken oturum bilgisi URL’ye eklenir. Canonical üretimi “oturum bilgisini koruyacağım” diye hareket ederse, aslında canonical’i yanlış yerde değiştirir.
• Client-side yönlendirme ile canonical değişimi: İlk HTML’de canonical doğru basılır; ardından JS router oda değiştirir ve canonical’i yeniden yazar. Yanlış zamanda yazılan canonical, “her oda değiştiğinde” farklı self-referencing sinyali üretir.
• Edge/middleware’de canonical üretimi: Bazı mimarilerde canonical, istek objesine bakılarak dinamik üretilir. Oturum parametresi veya hash değişince üretim de değişir; aynı içerik farklı canonical’lere bölünür.

Canonical’in amacı ve hash/oturumun canonical sinyali üzerindeki etkisi

Canonical etiketinin temel amacı arama motorlarına şunu söylemektir: “Bu varyantlar arasında ağırlık verilecek ana URL hangisi?” Chat sitelerinde ise varyantlar sadece “sayfa içeriği farklı” olduğu için oluşmaz; çoğu zaman navigasyon/oturum durumu değiştiği için görünür hale gelir.

Hash (#) çoğu senaryoda tarayıcı tarafında çalışır; sunucu tarafı çoğu zaman aynı path’i görür. Fakat canonical üreticisi hash’i “URL’nin bir parçası” gibi ele alırsa Google, her hash varyantını ayrı bir kanonik aday gibi değerlendirebilir. Benzer şekilde sessionId/sid gibi parametreler her istekte değişebilir; canonical sinyali de aynı şekilde “her oturumda farklı” hale gelir.

Bu durum iki ciddi probleme yol açar: (1) yanlış canonical ile oda/konuşma yerine “oturum varyantı” kanonik olur, (2) aynı oda içeriği birden çok canonical URL’ye bölündüğü için indeksleme ve crawl verimliliği düşer. Beklenti şudur: canonical gerçek “kanıt/kaynak sayfa”yı temsil etmelidir; oturum veya sadece UI durumunu değil.

Hash URL’ler için doğru yaklaşım (canonical, log/analytics, JS router etkileri)

Hash tabanlı navigasyonda en güvenli kural şudur: hash’i canonical’den tamamen dışarıda bırak (amaç, aynı kaynağı işaret etmek). Hash, kullanıcı arayüzünü ve SPA iç navigasyonu taşır; kanonikleştirme ise mümkün olduğunca “sabit bir permalink” üzerinden yapılmalıdır.

Pratikte iki yaklaşım görürüz:

• Oda/permalink tabanlı canonical: Hash ne olursa olsun canonical oda için sabit bir URL formatına yönelir. Örn. https://site.com/room/room1.
• Hash ile aynı sayfa template’i kullanılsa bile: canonical mutlaka sabit kalır; yalnızca gerçekten içerik farklıysa (ör. room1 vs room2 gibi) canonical farklılaşır. Buradaki ayrım “room kimliği” üzerinden yapılmalıdır; hash’in alt durum parçaları üzerinden değil.

Öte yandan loglama ve analytics tarafında hash’i saklamak çoğu zaman sorun değildir. Ancak canonical, paylaşım/izleme için üretiliyorsa “log seviyesinde doğru” olan şey “SEO sinyali seviyesinde doğru” olmayabilir. Bu yüzden analytics amaçlı hash/track toplama ile canonical üretiminin sorumluluğunu birbirinden ayırın.

Kötü örnek: Hash tabanlı sayfada canonical’in farklı hash’lere göre değişmesi (örn. #/chat/room1 iken canonical ...#/%2Fchat/room1, #/chat/room2 iken canonical ...#/%2Fchat/room2). Eğer içerik gerçekten room’a göre ayrışmıyorsa bu durum “yanlış kanonikleştirme” üretir. İçerik room’a göre ayrışsa bile, canonical içinde hash formatını taşımak yerine oda permalink’ine gitmek genellikle daha temiz bir sinyaldir.

İyi örnek: Hash’i canonical’den tamamen çıkarın; kullanıcıyı aynı oda kaynağına götüren sabit canonical URL üretin. Örn. hash ne olursa olsun canonical: https://site.com/room/room1.

Oturum/track parametreleri için canonical normalizasyon stratejileri (normalize etme, drop etme, sabitleme)

Oturum/izleme parametreleri (örn. sid, sessionId, utm_* ya da özel trackId) her istekte farklı gelebilir. Canonical üretiminde hedef, bu parametreleri “kaynak sayfanın kimliği” gibi kullanmamak ve canonical’i sabitlemektir.

Bu noktada üç yaklaşım öne çıkar: (1) normalizasyon (parametreleri kanonik forma indirgemek), (2) drop etme (canonical’den tamamen kaldırma), (3) sabitleme (canonical’i kurala göre tek bir kalıba bağlama). Chat odalarında genellikle en başarılı kombinasyon: room/permalink kimliğini koru, session/track/izleme parametrelerini drop et.

Kötü örnek: Her oturumda değişen canonical (örn. ?sid=ABC yerine canonical de sid’i taşıyor). Kullanıcı oturumu yenilendikçe canonical de değiştiği için arama motorları aynı oda için bile yüzlerce canonical varyant görür.

İyi örnek: Farklı kullanıcı/oturumlara aynı canonical sinyali. Örn. https://site.com/room/room1?sid=ABC ve https://site.com/room/room1?sid=XYZ ikisinde de canonical: https://site.com/room/room1.

Otomatik canonical üretim hataları: template kuralları, client-side render, middleware/edge üretimi

Canonical’in otomatik üretildiği sistemlerde hata “yazılımın niyetinde” değil, kanonikleştirme kurallarında saklanır. Örneğin bir template, istek URL’sini olduğu gibi alıp canonical’i basarsa; bu kez hash/oturum gibi değişkenler canonical’e taşınır.

En sık görülen hatalar şunlardır: (a) URL normalizasyon kuralının eksik olması, (b) canonical’i render ederken yanlış kaynağın kullanılması, (c) client-side router’ın canonical’i geç güncellemesi ve (d) middleware/edge katmanında istek bazlı canonical üretilmesidir.

Kötü örnek: Canonical üreticisinde yanlış normalizasyon (query string temizleniyor ama hash/oturum korunuyor). Ekip “query string problemi çözüldü” sanıp canonical’den ?utm_* gibi parametreleri atar; ama sid/sessionId ya da hash canonical’de kalır. Böylece doğru hamle yarım kalır ve asıl SEO riski devam eder.

Bu sınıfta ayrıca kritik bir detay var: canonical üretimi “server render” ile başlar ama client-side hydration sonrası canonical yeniden hesaplanabilir. Eğer JS, örneğin oda değiştirme event’inden sonra canonical’i güncellemeye çalışıyorsa ve bu sırada session/track alanları değişiyorsa, canonical her hareketle oynar.

SPA ve server-side rendering (SSR) farkları: canonical’in nerede basılması gerektiği

SPA mimarilerde canonical çoğu zaman ilk sayfa yüklenince çalışır; fakat gerçek içerik (oda seçimi, mesaj akışı, alt sayfa durumu) JS ile değişir. Bu yüzden canonical’i sadece “nerede bastığınız” değil, “hangi aşamada güncellediğiniz” de çok önemlidir.

Genel kural olarak: canonical’i mümkünse server’da (veya prerender/SSR sırasında) sabitleyin. Client-side’de canonical’i değiştirmek ancak gerçekten yeni bir “kaynak sayfaya” geçişte (örn. room/permalink değişiyor) ve doğru canonical kurallarıyla yapılmalıdır. Aksi halde canonical’in gereksiz yere oynaması, Google’ın sinyali tutarsız görmesine neden olabilir.

SSR/prerender kullanan sistemlerde canonical üretimi daha deterministik olur. Ancak edge/middleware katmanında canonical üretimi “istek parametrelerine” bağımlıysa bu determinism bozulur. Bu nedenle oda kimliği (room id/permalink) ve canonical formatını tek bir canonical normalizasyon fonksiyonuyla ele alın.

robots.txt, noindex ve canonical birlikte nasıl düşünülür? (doğru sinyal kombinasyonları)

Canonical sinyali “izlenecek/indekslenecek ana varyant” mesajı verir; robots.txt ise “crawl erişimi” için bir çit oluşturur. Chat sitelerinde bazı varyantların indekslenmemesi (örn. çok dinamik mesaj URL’leri) gerekir; burada doğru kombinasyon, canonical ile çelişmemelidir.

Pratikte şu yaklaşım daha güvenlidir:

• İndekslensin: canonical’i doğru basın, gerekirse robots.txt ile engellemeyin.
• İndekslensin ama sinyal yönlendirilsin: canonical’i sabitleyin; “varyant indekslense bile” oda/permalink ana URL olsun.
• İndekslensin istemiyorsanız: noindex kullanın. Bu durumda canonical yine de belirleyici olabilir; fakat amaç çoğunlukla “noindex sayfayı çoğaltmamak” olmalıdır.
• Crawl erişimini kesmek istiyorsanız: robots.txt ile engellemek noindex’e göre daha serttir. Crawl engeline gidiyorsanız, canonical sinyalinin anlamı azalabilir; çünkü Google sayfayı görmeden karar verir.

En önemli nokta şudur: canonical ile noindex’i “çakıştırmak” değil; kullanım niyetini netleştirmektir. Chat odalarında hem indekslenebilir arşiv sayfaları hem de izleme/oturum varyantları aynı URL ailesinde yaşar. Bu yüzden hangi sayfanın indeksleneceği (ve hangi sinyalin hangi katmanda uygulanacağı) önceden planlanmalıdır.

Otomatik denetim tablosu: hash/oturum canonical doğrulama puanları

Kontrol Noktası	Beklenen Davranış	Hata Belirtisi
Canonical içinde # var mı?	Hash tamamen dışarıda olmalı	.../chat#/%2Fchat/room1 benzeri canonical görülebilir
Canonical içinde sid/sessionId var mı?	Oturum/track parametreleri canonical’den drop edilmeli	Aynı oda için canonical her kullanıcı/oturumda değişiyor
Oda değiştiğinde canonical güncelleniyor mu?	Sadece oda/permalink değişiminde doğru canonical	Yanlış zamanda canonical yeniden yazılıyor ve dalgalanıyor
Varyant URL’ler arası canonical tutarlılığı	Varyantlar aynı canonical’e yönlenmeli	İki farklı varyant farklı self-referencing canonical üretiyor

Yaygın hatalar (Beklenen hatalar dahil): hash/oturum kaynaklı canonical bozulmaları

Chat sitelerinde canonical bozulması çoğu zaman “yanlış canonical” şeklinde değil, “tutarsız canonical” şeklinde görünür: aynı oda farklı oturumlarda farklı canonical üretir. Bu da Google’ın kanonikleştirme sinyalini zayıflatır.

En yaygın üç hata paterni şunlardır:

• Template tabanlı kanonik üretim: Otomasyon, istek URL’sini birebir alıp canonical basar; hash ve oturum parametrelerini normalize etmez.
• Client-side canonical yeniden yazımı: JS router yeni oda durumuna geçerken canonical’i de günceller; ama canonical normalizasyon fonksiyonu oturum parametresini temizlemez.
• Yanlış normalizasyon önceliği: Önce query string temizlenir, sonra hash ve oturum “kalan” gibi görüldüğü için canonical’e taşınır. Bu, ekipler “query string çözüldü” diye doğrulama yapmadan sistemdeki varyantları genişlettiklerinde sık yaşanır.

İzleme ve doğrulama: hangi kontrollerle hatayı hızlı tespit edersiniz?

Yanlış canonical’i bulmanın en iyi yolu, sistemden “gerçek kullanıcı davranışını” taklit eden bir dizi test URL’si üretmek ve canonical etiketinin tutarlılığını ölçmektir. Aşağıdaki “doğrulama adımları” teknik ekip ile SEO analistinin aynı dili konuşmasına yardımcı olur.

1. Varyant seti oluşturun: Aynı oda için en az 3-5 varyant URL hazırlayın. Örn. farklı sid/sessionId değerleri ve farklı hash alt durumları (ama mümkünse aynı room/permalink).
2. Canonical’i hem başlangıç hem de SPA sonrası yakalayın: Sayfa ilk yüklendiğinde canonical’i kontrol edin; ardından JS ile oda durumunu değiştirin ve canonical’in değişip değişmediğini doğrulayın. (Client-side’de yeniden yazım var mı?)
3. Normalize kuralını kanıtlayın: Hash’in canonical’de hiç görünmemesi ve oturum parametrelerinin canonical’de hiç taşınmaması beklenir. Canonical room/permalink’e sabit mi? Aynı oda varyantları aynı canonical’e gidiyor mu?
4. Log/analytics ayrımını doğrulayın: Hash/sid sadece izleme için mi kaydediliyor, yoksa canonical üretiminde mi kullanılıyor? Canonical üretim fonksiyonu “istek ham URL’si” yerine “canonical kaynak modeli” mi kullanıyor?

Bu testlerin çıktısını küçük bir rapor formatında tutarsanız (örn. oda başına canonical varyant sayısı), hatayı sadece “bulmak”la kalmazsınız; aynı zamanda “önlemek” için de kullanırsınız. Çünkü doğru normalizasyon fonksiyonu oturtulduğunda, ileride yapılan template güncellemeleri de bu testten geçerek korunur.

İçerik mimarisinde özel notlar: odalar, arşiv ve crawl bütçesi ilişkisi

Canonical doğru olsa bile crawl bütçesini korumak gerekir; çünkü chat sitelerinde oda içeriği, mesaj akışı ve durum değişimleri “çok hızlı” üreyen varyantlar yaratır. Özellikle çok sayıda odanın açıldığı dönemlerde indeksleme baskısı artar.

Bu yüzden canonical ile birlikte şu kararlara da bakın: mesaj URL’leri indekslenmeli mi, hangi sayfalar arşivlenmeli ve hangi endpoint’ler crawl edilmemeli? Eğer indekslenmeyecek mesaj türleri varsa, canonical’i düzeltmek tek başına yetmez; “erişim ve indeksleme stratejisi” de eşlik etmelidir.

İlgili teknik kontroller için şu kılavuzlar yardımcı olabilir:

• Chat Sitelerinde Mesaj İçeriği Index mi Noindex mi? (SEO ve Kullanıcı Değeri Dengesi için Karar Rehberi)
• Chat Sitelerinde Launch Ramp (Yeni Oda Açma Hızı) ile Crawl Bütçesini Yönetme Rehberi
• Chat Sitelerinde İndekslenebilir Oda Arşivi Mimarisı (AJAX’siz SSR/Prerender ile) — Şablon, URL, İç Linkleme ve Sitemap Stratejisi

Kombinasyon stratejileri: canonical + prerender + edge kontrolü

Özellikle edge/middleware kullanan chat platformlarında canonical üretimi “istek anı”na sıkı bağlı olabiliyor. Bu durumda canonical normalizasyon fonksiyonunu (hash drop, sid drop, room kimliği çekme) tek bir yerde tanımlayın; hem server hem de client aynı kuralı kullansın.

Ayrıca prerender/SSR kullanıyorsanız canonical’in HTML içinde ilk anda var olduğundan emin olun. Eğer ilk anda canonical yoksa ve sonradan basılıyorsa, Google’ın sinyali yakalaması gecikebilir ya da SPA durumuna göre tutarsız görünebilir. Bu nedenle canonical’i “mümkün olan en erken aşamada” basmak kritik bir tasarım kararıdır.

Son olarak, otomatik canonical üretiminde “self-referencing” mantığını doğru düşünün. Self-referencing her zaman kötü değildir; ancak self-referencing yerine varyantlar arasında doğru kanonik ilişki kurulmalı. Yani aynı oda için farklı session/hash varyantları aynı canonical’e gitmelidir; aksi halde sistem sürekli çoğalan bir kanonik evren yaratır.

Sık Sorulan Sorular (SSS)

Hash URL’ler Google’da ayrı URL gibi mi değerlendirilir? Canonical nasıl davranmalı?

Hash bileşeni genellikle tarayıcı tarafı durumunu taşır; ancak canonical üretimi hash’i kanonik URL’nin parçası haline getirirse pratikte farklı hash varyantları farklı kanonik adaylar gibi algılanabilir. Bu yüzden hash’i canonical’den dışarıda bırakmak en güvenli yaklaşımdır. Canonical oda/permalink gibi sabit bir kaynak URL’yi işaret etmelidir.

Oturum parametrelerini canonical’de tamamen temizlemek mi gerekir, yoksa sadece belirli sayfalarda mı?

Çoğu durumda oturum/track parametrelerini canonical’den tamamen temizlemek gerekir. Çünkü sessionId/sid çoğu zaman içerik kimliği değildir; yalnızca kullanıcı durumudur. Yalnızca oturumun gerçekten içerik ürettiği (ve farklı içerik doğurduğu) özel bir mimaride ayrıca değerlendirmeniz gerekir.

Client-side üretilen canonical ile server-side üretilen canonical arasındaki farklar nelerdir?

Server-side canonical daha deterministik ve erken sinyaldir. Client-side canonical ise SPA durumuna bağlı olarak gecikebilir; doğru zamanda güncellenmezse tutarsızlık üretir. İdeal senaryo: canonical server’da sabit basılır; yalnızca gerçekten kaynak değiştiğinde (room/permalink) client tarafında güncelleme yapılır.

Sohbet odaları gibi çok sayıda varyantta canonical mi noindex mi daha doğru?

İndekslenecek “oda arşivi” ve indekslenmeyecek “çok dinamik mesaj/oturum varyantları” ayrımı yapın. Çok dinamik varyantlarda noindex daha doğru olabilir; canonical ise indekslenebilir oda arşivinin doğru sinyalini vermelidir. İkisi birlikte kullanılabilir, ancak amaç çakışmamalıdır.

Canonical’de query string bırakılmalı mı, hash bırakılmalı mı?

Bu rehber query string anlatımı üzerinden gitmese de pratikte şunu söyleyelim: query string içeriğin kimliğini temsil etmiyorsa temizlemek iyi olur. Hash ise canonical’de bırakılmamalıdır. Canonical’in amacı “aynı kaynağa giden sabit kimlik” sağlamaktır.

Canonical doğru olsa bile crawl bütçesini nasıl koruruz?

Canonical tek başına crawl bütçesini garanti etmez. Crawl bütçesini korumak için indekslenmeyecek sayfalarda noindex/erişim kısıtı stratejisi, crawl’i artıran dinamik linklerin kontrolü ve oda/arşiv mimarisinin (sitemap + iç link + SSR/prerender) doğru tasarımı gerekir. Ayrıca launch ramp gibi hız politikaları da crawl bütçesini etkiler.

Kapanış: Hash ve oturum varyantlarına karşı kanonikleştirme disiplinini kurun

Chat sitelerinde canonical otomatik üretim hataları genellikle “yanlış bir etiketi yazmaktan” çok, değişken bir URL’yi canonical’in kimliği gibi ele almaktan kaynaklanır. Hash (#) ve oturum/track parametreleri içerik kimliği değildir; bu yüzden canonical sinyalini oda/permalink tabanlı sabit bir modele bağlamak gerekir.

Özetle: hash’i canonical’den dışarıda bırakın, sessionId/sid gibi parametreleri drop edin, canonical’in hem server’da hem de client-side akışında aynı kural setini kullandığından emin olun. Ardından varyant setiyle hızlı doğrulama testleri yaparak hatayı erken yakalayın. Böylece arama motorlarının kanonikleştirme kararı tutarlı hale gelir, crawl bütçesi korunur ve büyüme sürdürülebilir kılınır.