Chat Arşivinde Private (Kişiye Özel) Oda İçin Güvenli Teaser + Noindex Tasarımı (Mimari ve Kontrol Checklist’i)

Chat arşivinde private (kişiye özel) oda sayfalarını arama motorlarından uzak tutmak, yalnızca “noindex yazdım bitti” yaklaşımına indirgenmeyecek kadar kritik bir konudur. Çünkü mesele sadece dizin durumu değil; snippet, önbellek, SSR/edge render, log/abonelik akışları ve en önemlisi sızıntı riski (PII/mesaj metni) etrafında şekillenir. Bu yazıda hedefimiz şu vaadi netleştirmek: Private oda arşivlerini güvenli şekilde noindexleyip sızdırmadan, kullanıcı değerini koruyan indexlenebilir teaser katmanını kontrollü biçimde kurgulamak.

Bu rehberin ana anahtarı şu: chat arşivinde kişiye özel oda (private) için güvenli teaser tasarımı ile noindex nasıl yapılır. “Güvenli teaser” yaklaşımı, private içerikten farklı bir veri sözleşmesi (data contract) ve farklı bir erişim/derleme akışı gerektirir. Aksi hâlde noindex sinyali tek başına, mesaj içeriğinin başka yüzeylerden görünmesini engellemeye yetmeyebilir.

Kapsam ve terimler: private oda, teaser, chat arşivi, sızıntı riski ve noindex vs erişim kontrolü

Private oda: Yalnızca yetkili kullanıcıların erişebildiği; üyelik, rol ya da ülke bazında kısıtlanan sohbet alanı. Private oda çoğu zaman “unlisted” gibi görünse bile, güvenlik modelinin omurgası erişim kontrolü olmalıdır.

Teaser: Kullanıcıya oda hakkında güvenli bir özet veren (ör. oda adı maskeli, son aktivite zamanı gibi) ama mesaj gövdesi veya PII içermeyen “public-safe” ön yüz. Teaser’ı indexletmek, kullanıcı keşfini artırır; fakat teaser’ın veri sözleşmesi private içeriği taşımamalıdır.

Chat arşivi: Kullanıcının geçmiş konuşmalarını görüntülediği yüzey. Arşivdeki private oda sayfalarının indexlenmesini istemezken; teaser sayfalarının indexlenebilir olması mümkün (ve bazen tercih edilen) bir senaryodur.

Sızıntı riski (PII/mesaj metni): Private oda içeriği yanlışlıkla taranır, snippet olarak dışarı çıkar ya da cache/CDN üzerinden “yetkisiz” izlenebilir hâle gelirse ortaya çıkar. Bu risk, noindex ile “tam olarak” çözülmeyen mimari bir problemdir.

Noindex vs erişim kontrolü: Noindex, “arama motoru indeksleme yapmasın” demektir; erişim kontrolü ise “yetkisiz kullanıcının içeriği alamaması”dır. Güvenlik için iki katman birlikte çalışmalıdır: teaser page public-safe; room page auth-gated; index sinyali de buna göre yönetilmelidir.

Neden tek başına noindex yetmeyebilir? (Risk haritası)

Noindex, doğru uygulanmadığında veya başka yüzeyler yanlış yapılandırıldığında sızıntıyı engellemez. Aşağıdaki risk haritası, private oda bağlamında sık yaşanan “noindex var ama sorun yok sanıldı” senaryolarını gösterir.

• Snippet sızıntısı: Search bot sayfayı fetch edip meta description/title gibi metriklerden snippet üretebilir. Noindex olsa bile bazı durumlarda görsel/önizleme davranışları beklenenden farklı olabilir.
• SSR ön-yükleme ve cache: Yetkilendirme öncesi server/edge tarafında private içerik render edilip CDN’de cache edilirse, noindex olsa bile yanlış içerik yayımlanabilir.
• Yanlış erişim statüsü: 200 dönen bir auth duvarı (ör. login sayfasına redirect edilmeyen “gizli içerik” 200 ile dönmesi) botların yanlış sinyallerle sayfayı “normal” kabul etmesine yol açabilir.
• CDN vary/anahtar hatası: Vary (Authorization/Cookie) cache-key’e katılmıyorsa, private içerik başkalarının erişimine açık görünebilir.
• Log/önbellek/thumbnail pipeline: Noarchive bile yetmeyebilir; sosyal paylaşım önizlemeleri, görsel indexleme veya ikinci bir endpoint’in (ör. metadata/preview) indexlenmesi sızıntı doğurur.

Hedef mimari: Teaser katmanı (public-safe) + private içerik katmanı (auth-gated) + arayüz/endpoint ayrımı

En sağlıklı yaklaşım, private oda için “aynı URL’de farklı içerik” fikrini bırakıp iki ayrı arayüz/endpoin tasarlamaktır: biri public-safe teaser, diğeri auth-gated private oda. Böylece hem erişim kontrolü hem de indeks sinyalleri daha net ayrışır.

Örneğin önerilen endpoint ayrımı şu şekilde olmalıdır:

• /room/{roomId}/teaser → Public-safe teaser (noindex veya opsiyonel index; veri sözleşmesi güvenli)
• /room/{roomId} → Auth-gated oda sayfası (noindex + erişim duvarı)

Bu ayrımın amacı, teaser’da asla mesaj metni veya katılımcı listesi gibi veri taşımamaktır; private endpoint’te ise botların bile erişemeyeceği bir yetkilendirme akışı kurulmalıdır. Böylece “teaser indexlenebilir ama mesaj sızmaz” vaadi gerçek hayatta çalışır hale gelir.

URL/parametre tasarımı: oda kimliği varyantları, kullanıcı bazlı varyantlar ve canonical/noindex etki alanı

Private oda teaser’ı indexlenecekse URL tasarımı kritikleşir. Oda kimliği bazında varyant üretmek (ör. farklı kullanıcıya farklı teaser) çoğaltmayı artırır ve yanlış indekslenme riskini büyütebilir. Bu yüzden teaser’ı genellikle oda düzeyi ile sınırlandırmak, kullanıcı bazlı kişiselleştirmeyi de “zorunlu olmadıkça” kaldırmak daha iyi bir tercihtir.

Pratik bir tasarım yaklaşımı:

1. Oda sabit teaser URL’si: /room/{roomId}/teaser şeklinde odaID ile tekil bir teaser sürümü.
2. Kullanıcı bazlı bilgi gerekiyorsa: teaser yerine “kullanıcıya özel görünüm”i client-side olarak ve auth sonrası üretin; public-safe teaser JSON’unda bu alanları hiç bulundurmayın.
3. Canonical alanı: teaser URL’si teaser’ın canonical’ı olmalıdır; private oda sayfasında canonical verilse bile noindex ile çakışma yönetimi ayrıca yapılmalıdır.

Özellikle “private oda sahibinin değişmesi” gibi olaylarda roomId sabit kalmalı; teaser içeriği aynı veri sözleşmesine göre güncellenmeli, ama PII geçmişi saklı tutulmalıdır.

Güvenli teaser veri sözleşmesi: teaser’e hangi alanlar asla girmez?

Güvenli teaser tasarımının kalbi teaser veri sözleşmesidir. Buradaki hedef “private içeriği kısmen göstermek” değil; teaser’ın private içeriğin taşıyıcısı olmamasını sağlamaktır.

Teaser payload’ta kesinlikle bulunmaması gereken alanlar:

• Mesaj gövdesi: son mesaj metni, alıntı, mesaj içeriğinin parçaları.
• PII: kullanıcı adı/telefon/e-posta, kullanıcı etiketleri, profil açıklamaları, görünen takma adlar.
• Katılımcı listesi: kimlerin üye olduğu, rol dağılımı, okuma durumu.
• Erişimle ilişkili gizli sinyaller: kullanıcıya özel “kaç mesaj okudun”, “silinmiş mesajlar var” gibi durumlar.
• Soft-delete detayları: hangi mesajın ne zaman silindiği, silinen mesajların kim tarafından görüldüğü.

Teaser’da izinli alanlar ise örneğin oda adı maskeli, aktivite zamanı, dil/tema gibi “kullanıcı için güvenli” özetler olabilir. Oda adının maskelenmesi bile PII’nin bir türevi olabilir; burada “maskeli ama anlamlı” yaklaşımı kullanın.

Teaser render akışı: SSR/CSR farkları, yetkilendirme kontrolü ve edge/CDN davranışı

Teaser katmanını public-safe yapmanın tek yolu backend filtreleri değildir; render akışının da “private veri asla render edilmesin” garantisi vermesi gerekir. Bu nedenle SSR/CSR farkını ve edge davranışını detaylı ele almak önemlidir.

SSR (Server-Side Rendering) kullanıyorsanız: /room/{roomId}/teaser endpoint’i yalnızca public-safe veri üretmeli; yetkilendirme öncesi bile hiçbir private alan çekilmemeli, hatta servis çağrıları “secret-scope” olmamalıdır. SSR’da bile güvenlik, data contract kadar önemlidir.

CSR (Client-Side Rendering) kullanıyorsanız: teaser HTML’i minimal kalmalı; public-safe endpoint’ten gelen payload harici kaynaklarla genişletilmemelidir. Örneğin son mesajı “teaser”te göstermek istiyorsanız, bu planı iptal edin; bunun yerine private endpoint’ten auth sonrası çekilen ayrı bir bileşen tasarlayın.

Edge/CDN davranışı: Teaser endpoint’i cache edilebilir olabilir; fakat private endpoint cache’e girmemelidir. En kritik konu, private endpoint’te “cache-key” ve “Vary” ayarlarının düzgün olmasıdır. Teaser için de yanlış cache-key her kullanıcıya farklı şey dönmesini tetikleyebilir; bu yüzden teaser’ı oda düzeyinde tekilleştirin.

Noindex uygulaması: meta robots ve HTTP header senaryoları (+ noarchive/nosnippet/noimageindex)

Noindex uygulaması tek bir yerden yapılmamalı; bot önceliği ve farklı crawler davranışları nedeniyle meta robots + HTTP header kombinasyonu pratikte daha sağlam bir kontrol sağlar. Ayrıca noarchive/nosnippet/noimageindex gibi sinyallerle “kopya/önizleme” yüzeylerini azaltın.

Örnek bir response seti (private oda sayfası için öneri):

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store, max-age=0
Pragma: no-cache
X-Robots-Tag: noindex, noarchive, nosnippet

Redirect kullanacaksanız akış değişir. Botların “redirect ile login duvarına gitmesi” doğru yönetilmeli; bazı senaryolarda teaser daha doğru bir hedef olur. Aşağıda yönlendirme ilkelerini netleştiriyoruz.

Teaser için ise iki yaklaşım vardır:

• Teaser indexlenebilir olsun: robots’ta noindex vermeyin; teaser veri sözleşmesini sımsıkı uygulayın ve snippet riskini düşürmek için meta description’ı da güvenli tutun.
• Teaser da indexlenmesin ama kullanıcıya dahili gösterilsin: teaser’a da noindex koyun; bu durumda crawl bütçesi ve keşif etkisi azalır.

Görsel/önizleme riskleri için noimageindex ve sosyal paylaşım kartlarının (Open Graph/Twitter cards) private veriyi beslemediğinden emin olun.

Yetkilendirme ve erişim kontrolü ile birlikte çalışma: 401/403/302 davranışları ve bot akışı

Botların davranışlarını “HTTP durumu” belirler. Private oda sayfası /room/{roomId} için erişim kontrolü noindex’ten bağımsız olarak doğru olmalıdır.

Genel öneri:

• Yetkilendirme gerektiriyorsa: botlar veya kullanıcılar için 401 ile challenge etmek ya da 302 ile login’e yönlendirmek planlanır. Burada hedef, private içeriğin hiçbir şekilde 200 ile döndürülmemesi ve cache’e girmemesidir.
• Yasaklı ise: oda üyesi olmayanlar için 403 daha net bir sinyaldir.
• Redirect sonrası içerik: login sayfasında da private bilgi bulunmamalı; ayrıca SSR ile login sonrası private içeriğin yanlışlıkla render edilmesine izin verilmemelidir.

Bot trafiği için özel akış: Bazı ekipler bot user-agent’larını ayrı tutmaz; genel erişim kontrolünü yine aynı mantıkla yürütür. Botlara özel “public content” vermek yerine, güvenli teaser’ı botların görebileceği endpoint olarak sunmak çoğu zaman daha tutarlı olur.

Robots.txt/robots meta/HTTP header önceliği ve pratik karar matrisi

Robots sinyalleri arasında öncelik ve kapsam davranışı önemlidir. Pratikte şu kuralı ekip seviyesinde standartlaştırın: robots.txt crawl’ı etkiler; noindex ise indekslemeyi. Private oda güvenliği için robots.txt kullanımı “ek katman” gibi düşünülmeli; asıl güvenlik erişim kontrolü olmalıdır.

Aşağıdaki tablo, teaser vs private oda sayfaları için hızlı bir karar matrisi sağlar.

Yüzey	Önerilen URL	Noindex/Index	Header/Meta	Erişim
Public-safe teaser	/room/{roomId}/teaser	Opsiyonel (indexlenebilir olabilir)	Index uygunsa: X-Robots-Tag yok / no-snippet düşünülür	Public (auth gerektirmez)
Private oda	/room/{roomId}	Mutlaka noindex	X-Robots-Tag: noindex, noarchive, nosnippet (+ noimageindex)	Auth-gated (401/403/302 + no-store)

Hangi sinyali tercih edeceksiniz sorusuna pratik bir yanıt: Eğer altyapınızda HTTP header yönetimi standartsa X-Robots-Tag kullanın; ayrıca meta robots ile ikinci katman ekleyin. robots.txt ile kapatmak, keşfi azaltır ama index güvenliğini tek başına garanti etmez; yine erişim kontrolünü esas alın.

Kanonik strateji: teaser sayfası vs özel oda sayfası canonical/noindex nasıl birleştirilir?

Canonical stratejisi, “aynı içerik iki farklı URL’de varmış gibi algılanmasın” diye tasarlanmalıdır. Teaser ile private oda aynı veri seti değildir; bu nedenle canonical çakışmasını doğru kurmak gerekir.

Örnek kombinasyon senaryosu:

• Teaser sayfasında canonical = teaser URL’si: /room/{roomId}/teaser canonical, “teaser kendi varlığıyla” değerlendirilir.
• Private oda sayfasında canonical = kendi URL’si veya “teaser’a kanonik vermek yerine” canonical self tutmak daha güvenli olabilir; çünkü private sayfalara ait sinyaller zaten noindex’tir.

Bu yaklaşım, “private URL canonical olarak teaser’a işaret ederse, indeks sinyalleri karışır” gibi riskleri azaltır. Yine de uygulama davranışınıza göre test ederek doğrulama yapın.

Özet kural: Teaser → canonical teaser, Private → noindex + canonical self (veya kurumsal SEO standardınıza uygun ama noindex ile uyumlu bir varyant).

Ölçüm ve doğrulama: Search Console, URL Inspection, test robots fetch, log analizi ve index durum metrikleri

Bu mimarinin çalıştığını sadece “kod çalışıyor” diyerek anlayamazsınız. Doğrulama; Search Console raporları, URL inspection, crawler simülasyonu ve log analizi kombinasyonuyla yapılmalıdır.

Kontrol listesi ile adım adım doğrulama:

1. URL Inspection ile noindex doğrulayın: /room/{roomId} için “dizin dışı bırakıldı (noindex)” veya benzeri sinyallerin göründüğünden emin olun.
2. Robots fetch testi yapın: Bot benzeri fetch ile HTTP header ve meta robots’un gerçekten döndüğünü doğrulayın (noarchive/nosnippet var mı?).
3. Log analizi yapın: Googlebot/diğer botlar private endpoint’e erişiyor mu; erişiyorsa kaç kez, hangi cache sonuçlarıyla dönüyor (200 mi 401/403 mü)?
4. Index metriklerini izleyin: teaser URL’leri beklenen şekilde indexleniyor mu, private URL’ler indexleniyor mu? Bunun için haftalık örnekleme raporu üretin.

Bu noktada güvenlik doğrulaması da şart: teaser payload’ında mesaj metni/PII alanı yanlışlıkla var mı? Payload şeması ile otomatik kontroller ekleyin.

Hız ve cache: CDN önbellek anahtarı, Vary ve private-teaser caching politikası

Cache stratejisi, private içeriğin kazara yayınlanmaması için en kritik hızlandırma unsurudur. Private endpoint’te no-store ve uygun status/redirect davranışı olmalı; teaser’da ise oda düzeyi tekilleştirme sayesinde cache’i kontrollü hale getirin.

Önerilen ilke: Teaser endpoint’i cache’e girebilir; fakat Vary anahtarı “yetkilendirmeyi” etkileyen parametreleri içermiyorsa bile teaser public-safe olduğu için yanlış kişiye içerik sızdırmamalıdır. Private endpoint’te ise mutlaka cache’i devre dışı bırakın.

Pratikte cache-key / vary şu mantıkla kurgulanır:

• /room/{roomId}/teaser: cache-key = roomId bazlı; Vary gereksiz olabilir ama uygulama güvenliğini artırmak için Authorization/Cookie yoksa bile sabit tutun.
• /room/{roomId}: cache-key’e Authorization/Cookie eklemek tek başına yeterli değildir; yine de no-store ile “hiç cache’e alma” daha güvenli ve basittir.

Bu ayrım, SSR/edge cache kaynaklı hataları dramatik biçimde azaltır.

Örnek teaser payload JSON şeması (izinli alanlar ile)

Güvenli teaser tasarımında “payload şeması” bir sözleşme gibi ele alınır. Aşağıdaki örnek; oda adı maskeli olabilir, katılımcı listesi yoktur ve son mesaj metni dahil edilmez.

{
  "roomId": "abc123",
  "roomNameMasked": "Oda ••••",
  "language": "tr",
  "topicTag": "genel",
  "participantCountApprox": 3,
  "lastActivityAt": "2026-04-21T10:12:30Z"
}

Burada bilinçli olarak şunlar yok: “son mesaj”, “son mesajı yazan kullanıcı”, “mesaj içeriğinden alıntı”, “üyelerin kullanıcı adları” ve “silinmiş mesaj kanıtı”. Bu yokluk, mimarinin güvenli olmasının temel nedenlerinden biridir.

Örnek SSR hatası: yetkilendirme öncesi içerik render edilip CDN’de cache olması durumunda düzeltme

Gerçek hayatta yaşanan yaygın bir hata şu zincirle oluşur: /room/{roomId} sayfası SSR ile render edilir; auth guard middleware geç çalışır; private mesaj içeriği bir defa render olup HTML içinde çıkar; hemen ardından CDN cache bunu 200 olarak saklar. Noindex olsa bile aynı cached HTML, yetkisiz erişimlerde görülebilir.

Düzeltme akışı:

1. Auth guard’ı render öncesine taşıyın: SSR sırasında private içerik hiç üretilmesin. Auth yoksa 401/302 ile kesip “empty/placeholder” dönün.
2. Cache-Control’i doğrulayın: Private endpoint yanıtlarında no-store/ max-age=0 zorunlu olsun.
3. CDN cache purge uygulayın: Hatayı fark ettiğiniz anda ilgili roomId URL’leri için purge/ban yapın.
4. Edge testleri ekleyin: Auth’sız request’i simüle eden test, payload’da mesaj içerik alanı olmadığını otomatik doğrulasın.

Bu düzeltmeler, “search motoru indekslemedi ama yine de sızıntı oldu” türü senaryoların önüne geçer.

Sık senaryolar: oda sahibi değişimi, oda kaldırma/soft delete, mesaj silme, üyelik iptali

Private oda teaser mimarisi, sadece “ilk kurulum” sırasında değil, yaşam döngüsü boyunca güvenli kalmalıdır. Örneğin oda sahibi değiştiğinde (rol transferi), teaser’da maskeli adlar veya aktivite zamanları güncellenebilir; ancak geçmiş mesajlardan türetilmiş hiçbir iz teaser’a taşınmamalıdır.

Oda kaldırma/soft delete: Private oda /room/{roomId} artık erişilemez olmalı. Teaser hâlâ cache’te kalmış olabilir; bu yüzden teaser endpoint de artık 404/410 veya güvenli “silindi” temsili dönmelidir. Hangi statüye döneceğiniz (404 vs 410) arama performansı ve hukuki gerekliliklere bağlıdır.

Mesaj silme: Private endpoint’te mesaj silinmesi, teaser tarafına etkide bulunmamalıdır. Çünkü teaser zaten mesaj içeriği taşımıyorsa, silme operasyonu teaser cache invalidation gerektirmeyebilir. Ancak “lastActivityAt” gibi meta alanlar değişiyorsa, invalidation planı olmalıdır.

Üyelik iptali: Kullanıcı yetkisini kaybettikten sonra private endpoint’te 401/403 ile erişim kesilmeli. Log’larda erişim denemeleri görülür ve no-store davranışı sürdürülür. Teaser indexlenmiş olsa bile teaser veri sözleşmesi mesaj/PII taşımadığı için güvenli kalır.

Yaygın hatalar

Private oda + güvenli teaser mimarisinde en sık yaşanan problemler genellikle “küçük” gibi görünür ama büyük sızıntılara yol açabilir.

• Teaser’da “son mesaj”ı maskeleyeyim derken gizli içerik taşımak: Mesaj metninin bir kısmı bile tokenization/substring yüzünden PII riski oluşturabilir. Teaser veri sözleşmesi bu yüzden alan bazında yasak listesi içermelidir.
• SSR/edge cache ile yetkili içeriği public teaser’a bağlamak: Örneğin aynı komponenti teaser ve room sayfasında kullanıp auth guard öncesi render almak ciddi hatadır.
• Robots sinyallerini eksik uygulamak: Sadece meta robots koyup HTTP header’ı ihmal etmek, bazı botlarda davranış farklılığı doğurabilir. Noarchive/nosnippet gibi sinyallerin yokluğu da önizleme riskini artırır.
• Vary/cache-key yetersizliği: Private endpoint’te no-store olmadan Vary ile “idare edeceğim” demek tehlikelidir.

Bu hataları azaltmak için özellikle payload doğrulama (schema linting), e2e fetch testleri ve log analizi birlikte çalışmalıdır.

Nasıl kontrol edilir? (Adım adım doğrulama & kontrol listesi)

Uygulamanızın gerçekten güvenli ve SEO uyumlu olup olmadığını anlamak için “tekrar edilebilir” bir doğrulama rutini kurun.

1. HTTP düzeyi doğrulama: /room/{roomId} için noindex/noarchive/nosnippet header’larının geldiğini ve Cache-Control: no-store bulunduğunu test edin.
2. Görünürlük doğrulama: Auth’sız request ile /room/{roomId} HTML’inde mesaj metni/PII arayın (otomatik metin taraması veya belirli regex’ler).
3. Teaser payload doğrulama: /room/{roomId}/teaser JSON şemasında mesaj/katılımcı/PII alanlarının bulunmadığını otomatik kontrol edin.
4. Search Console doğrulaması: URL Inspection raporunda “dizin dışı bırakıldı (noindex)” sinyallerinin oluştuğunu ve teaser URL’lerinin beklenen şekilde değerlendirildiğini izleyin.

Ek olarak, ekip içi geliştirme sırasında staging ortamında crawl simülasyonu yapın ve prod’a taşımadan önce “bot-safe” davranışı kanıtlayın.

SSS

Noindex koymak tek başına yeterli mi, snippet yine de görünebilir mi?
Tek başına yeterli değildir. Noindex indekslemeyi durdurur; ancak snippet üretebilen bazı önizleme davranışları meta içerik ve crawler cache davranışlarından etkilenebilir. Bu yüzden noarchive/nosnippet/noimageindex ekleyin ve teaser veri sözleşmesini güvenli kurun.

Private oda teaser’ı indexlense bile mesaj metni sızmaması için veri setini nasıl kurgulamalıyım?
Mesaj gövdesi, son mesaj alıntısı ve PII ile ilişkili tüm alanları teaser şemasından tamamen yasaklayın. Teaser’ı oda düzeyinde public-safe meta ile sınırlayın ve JSON şemasına schema-level validasyon ekleyin.

SSR/edge cache private içeriği kazara yayınlar mı? Vary/Cache-Key nasıl olmalı?
Evet, guard render’dan sonra çalışırsa kazayla yayınlar. Private endpoint’te en doğrusu no-store + auth guard render öncesi kırılma; teaser’da ise oda düzeyi tekillik ve cache-key’in doğru olmasıdır.

Meta robots mı HTTP header mı tercih edilmeli, botların önceliği nasıl?
İkisini birlikte kullanmak en pratik yaklaşımdır. HTTP header (X-Robots-Tag) daha güçlü bir sinyal olabilir; meta robots ise tamamlayıcı ikinci katman görevi görür. Öncelik bot davranışlarına göre değişebilir, bu yüzden iki katman hedefleyin.

Canonical ile noindex çakışır mı? Hangi sayfayı canonical vermeliyim?
Canonical ile noindex doğrudan “çakışma” yaratmasa da sinyal karışıklığı riski vardır. Teaser canonical’ı teaser’a self verin; private sayfada da canonical self ve noindex birlikte tutarlı olmalıdır.

Search Console’da “dizin dışı bırakıldı (noindex)” nasıl doğrulanır?
URL Inspection ile ilgili sayfayı inceleyin. Ayrıca robots fetch ve header doğrulaması yaparak noindex sinyalinin gerçekten üretildiğini kanıtlayın.

401 mi 403 mü dönmeliyim; botlar hangi durumda ne yapar?
Yetkilendirme gerektiriyorsa 401; erişim yasak ise 403 tercih edin. Botların tekrar deneme davranışını ve crawl etkisini gözlemlemek için log analizi ile doğrulayın.

Teaser sayfalarında “login sonrası farklı içerik” olursa nasıl güvenli hale getirilir?
Public teaser’da login sonrası farklı içerik üretmeyin ya da üretecekseniz bile bu içerik mesaj/PII içermemeli. En güvenli yöntem teaser endpoint’ini public-safe data contract ile sabit tutmaktır; farklı içerik gerekiyorsa onu private endpoint’te üretin.

İç bağlantılar (ek okuma)

Bu yazıdaki mimari yaklaşımı desteklemek için şu rehberler de yol göstericidir:

• Kişiye Özel (Private) Chat Odaları Google’da Görünsün mü? Noindex/Yetkilendirme + Güvenli Teaser Tasarımı (Private/Unlisted Oda Rehberi)
• Oda eşiği ve teaser/noindex seçim mantığı
• Topluluk güncellemesi ile keşif kurgusu (teaser/özet içerik stratejisine ilham)