Kullanıcı Raporu (Complaint) Sonrası Oluşan Sayfalar: Noindex mi Redirect mi? SEO Karar Rehberi

Chat/sohbet platformlarında moderasyon akışları büyüdükçe “complaint” (kullanıcı raporu) sonrasında otomatik olarak oluşan sayfa sayısı da ister istemez artıyor. Bu noktada asıl mesele şu: Hangi durumda noindex uygulanmalı, hangi durumda redirect (yönlendirme) yapılmalı? Çünkü hedefimiz sadece tek tek URL’ler değil; bu URL’lerin arama motoru açısından amacı ve değer/erişilebilirlik dengesini doğru kurmak.

Elinizdeki karar çerçevesi de bu yüzden “her zaman şunu yap” gibi tek bir reçeteye değil, senaryoya göre doğru aksiyona odaklanmalı. Sayfa patlaması, ince içerik, duplicate/low-value ve indeksleme bütçesi gibi sorunlar, hep complaint sonrası URL’nin “neden üretildiği” ekseninde yönetilince daha kontrol edilebilir hale geliyor.

Sorun Tanımı: Complaint sonrası hangi URL’ler oluşur ve neden SEO riski doğurur?

Complaint süreci çoğu chat platformunda birkaç aşamadan oluşur: raporun alınması, moderasyon incelemesi, aksiyonun (ban/engelleme/sınırlama) uygulanması ve bazı durumlarda kullanıcıya “sonuç/işlem durumu” gösterimi. Bu adımlar, uygulamanın güvenlik ve doğruluk için oluşturduğu “durum sayfaları” ya da “ticket sayfası” gibi URL’lere dönüşebilir.

Örneğin moderasyon paneli içinde kullanılmak üzere üretilen bir akış, kullanıcıya gösterim amacıyla dışarıya da açılırsa arama motoru botları açısından “oturum/rol gerektiren ince içerik” üretme riski ortaya çıkar. Bunun sonucu olarak indekslemeye değmeyecek sayfalar birikir; aynı/benzer içerik farklı ticketId’lerle çoğalır ve crawl/behavior sinyalleri gereksiz yere gürültülenir.

Ek riskler de var: Sayfa içeriği bazen tek satırlık “durum” bilgisinden ibaret olabilir. Bazen kullanıcı raporunun gerekçesi kişisel veri niteliğine yakın içerikler barındırabilir. Bazı sayfalar yalnızca ilgili kullanıcıya erişilebilir olmasına rağmen genel erişimde 200 döndürmeye devam edebilir. Bu tablo hem güvenlik hem de SEO açısından “low-value” sinyali üretir.

Kavramlar: noindex, redirect (301/302/307/308) ve canonical arasındaki farklar (bu senaryoda)

Bu yazıda noindex kararını sadece meta robots etiketi olarak okumamak gerekir. Complaint sonrası sayfalar bazen sadece ilgili kullanıcıya görünür kılınır; bazen de “mülakat/inceleme” gibi geçici bir süreçte üretilir. O yüzden iki farklı katmanı ayırmak önemlidir: (1) sayfaya uygulanan robots noindex ve (2) sunucudan gelen HTTP redirect davranışı.

noindex (meta robots veya X-Robots-Tag) sayfanın Google tarafından indekslenmemesini ister. Buna karşılık redirect sayfanın yerini değiştirir; Google çoğu durumda yeni hedefi takip eder ve eski URL’nin indekslenme olasılığı azalır. canonical ise “hangi sayfanın öncelikli sürüm olduğu” bilgisini verir; ama düşük değerli bir sayfada canonical kullanmak çoğu zaman tek başına yeterli olmaz. Complaint sonrası URL’nin “erişilebilirlik” ya da “doğrudan yönlendirme” ihtiyacı varsa, canonical tek başına kurtarmaz.

Redirect türleri de aynı değildir: 301 genellikle kalıcı değişikliklerde; 302 geleneksel olarak geçici değişikliklerde kullanılır. Modern pratikte 307/308 yöntemi/semantiği koruma (HTTP method davranışı) açısından daha doğru bir seçime dönüşebiliyor. Complaint senaryosunda “inceleme sürüyor” gibi geçici durumlar için 302/307 daha anlamlı olabilir; “artık erişim yok, kalıcı olarak başka sayfaya gönderiyoruz” gibi durumlarda 301/308 tercih edilir.

Karar Çerçevesi: Sayfanın arama motoru için değeri var mı?

Complaint sonrası oluşan her URL’ye aynı muameleyi yapmak yerine, önce sayfanın “amacını” sınıflandırın. Kararınızı üç soruya dayandırın: (1) Arama motoru kullanıcıları bu sayfada gerçek bir değer bulur mu? (2) Sayfa içerik üretimi sürekli tekrarlayan “ticketId varyasyonu” mu yaratıyor? (3) Sayfa erişimi aslında rol/oturum gerektiriyor ve genel bot erişiminde de “anlamlı içerik” döndürmüyor mu?

Önerilen yaklaşım şöyle şekilleniyor: Eğer sayfa “sonuç bekleyen bir durum gösterimi” gibi geçici ise ve belirli bir süre sonra ana akışa dönüşecekse, redirect ile kullanıcıyı doğru yere yönlendirmek daha temiz bir kullanıcı deneyimi sağlar. Eğer sayfanın arama motoru tarafından keşfedilmesi dahi istenmiyorsa, noindex ile hem indekslemeyi durdurur hem de geçiş hedefi yaratmadan gürültüyü azaltırsınız.

Özet bir mantık: Redirect, sayfanın “yerini” başka bir kaynağa taşıyorsa; noindex, sayfa geçersiz/low-value kalsın ama indekslenmesin diyorsanız daha uygundur. Ancak bu ikisini de, complaint sonrası URL’nin “tekrar üretilme” karakteriyle birlikte değerlendirmek gerekiyor.

Redirect mi Noindex mi? (Artı/Eksi ve risk matrisi)

Aşağıdaki matris pratik karar vermenize yardımcı olur. Burada kritik unsur şu: Sayfanın nihai olarak değişeceği mi, yoksa sadece arama motoru için bir süre “saklanacağı” mı.

Complaint sonrası URL tipi	Arama motoru değeri	Önerilen yaklaşım	Risk notu
/user/{id}/complaint/{ticketId} (ticket’a özel durum)	Genellikle düşük (rol/oturum gerekir, ince içerik)	Noindex + iç linklemeyi kes	Discover olabilir; crawl bütçesi etkilenmesin
Complaint sonucu kullanıcı profil erişimi kalıcı kapandıysa	Yeni amaç: erişim yok/yardım	301 redirect (profile → erişim yok/yardım)	Eski URL’ler indexlenmişse toparlamak için daha iyi
“İnceleniyor” durumu geçici	Orta düzey (kısa süreli durum)	302/307 veya noindex (politika)	Yanlışsa tekrar tekrar farklı hedef üretilebilir
Complaint’e bağlı “neden/durum” sayfası tek bir şablonla üretiliyorsa	Düşük/duplicate	Noindex veya “tek master sayfaya redirect”	TicketId varyasyonları page explosion yaratır

Matristen çıkan en temel çıkarım şu: Hedef URL’nin “yerini” başka bir kaynağa taşımak gerekiyorsa redirect mantıklı; içerik zaten arama motoru için anlamlı olmayacaksa noindex daha güvenli. En sık hata da burada: Sayfa değeri yokken canonical ile “idare etmeye çalışma” ve aynı anda sitemap/internal link ile keşfi hızlandırma.

Senaryo Bazlı Analiz (En az 4 senaryo) — 1) Kalıcı erişim değişikliği (ceza/kalıcı ban/aktif olmayan kullanıcı)

Kullanıcının complaint sonrası profiline erişimi kalıcı olarak kapandıysa, bu URL’nin arama motorları için “anlamlı bir varlık” olma ihtimali düşer. Örneğin profil artık gizlenmiş ya da tamamen pasif hale getirilmişse, /profile/{id} sayfasında içerik “erişim yok”a dönüşür. Bu noktada redirect, kullanıcının beklentisini yönetir ve botların eski kaynağa takılmasını azaltır.

Bu senaryoda 301 çoğu zaman daha uygundur: değişiklik kalıcıdır ve Google’ın uzun vadede yeni hedefi konsolide etmesini bekleriz. Yeni hedef olarak örneğin “yardım” ya da “erişim bulunamadı” gibi bir sayfa tasarlayın. Aksi halde noindex ile sadece indekslemeyi durdurmak yetmeyebilir; çünkü URL zaten keşfedilmiş ve indekslenmiş olabilir. Redirect, indekslenmiş sayfaların “dönüşümünü” de yönetir.

Senaryo Bazlı Analiz — 2) Geçici aksiyon (inceleniyor durumları)

“İnceleniyor” gibi geçici durumlar, çoğunlukla zaman içinde değişecektir: complaint sonucunda ban/ceza uygulanabilir ya da kullanıcıya erişim geri dönebilir. Burada iki olasılık var: Ya noindex ile sayfanın indekslenmesini kalıcı olarak kapatır, ya da kısa süreli redirect ile kullanıcıyı “durum sayfası yerine” doğru akışa yönlendirirsiniz.

Redirect seçerseniz 302/307 daha anlamlı olabilir; çünkü süreç geçicidir ve semantik olarak “bir süre sonra farklı bir duruma dönecek” sinyalini daha doğru taşır. Ancak önemli bir risk var: İnceleniyor sürecinde URL’ler sürekli farklı ticketId’lerle üretiliyorsa ve her biri redirect zinciri kuruyorsa, crawl davranışı karışabilir. Bu yüzden “tek bir durum endpoint’i” tasarlamak ya da ticketId varyasyonlarını en azından noindex yapmak iyi bir adımdır.

Senaryo Bazlı Analiz — 3) Rapora bağlı “neden/durum” sayfası var mı yok mu?

Complaint sonrası kullanıcıya “raporun nedeni” ya da moderasyonun durumu gibi bilgiler gösteren bir sayfa bulunuyorsa, bu sayfanın içerik kalitesi belirleyici hale gelir. Eğer sayfa sadece “inceleniyor” gibi soyut bir meta içerik üretiyor ve her ticketId için benzer şablonlar oluşuyorsa duplicate/low-value etkisi hızlanır. Arama motoru tarafında bu tür sayfaların değeri de sınırlı kalır.

Bu durumda noindex daha güvenli bir başlangıçtır: robots meta veya X-Robots-Tag ile indekslemeyi durdurursunuz. Ek olarak internal linkleri keserek (ör. kullanıcı paneli dışına yönlendirmeyi kısıtlayarak) botların bu URL’leri keşfetmesini azaltın. Eğer gerçekten “her complaint için farklı ve değerli bir içerik” üretebiliyor ama yine de güvenlik/rol gereği erişimi sınırlandırıyorsanız, redirect yerine noindex + erişim denetimi kombinasyonu daha dengeli olabilir.

Senaryo Bazlı Analiz — 4) Complaint tek seferlik akış mı, kullanıcıya erişilebilir portal gibi mi?

Complaint akışı yalnızca bildirim amaçlı “tek seferlik” bir olay ise, URL’lerin uzun süre yaşaması gerekmeyebilir. Örneğin kullanıcı “rapor oluşturdu”ktan sonra yalnızca bir doğrulama ekranı görüyor ve sonrasında her şey tek bir “hesap durumu” alanına bağlanıyorsa, complaint endpoint’lerini kısa ömürlü ve noindex politikalı tasarlamak mantıklı olur.

Ancak platform “complaint geçmişi”, “ticket portalı” ya da “sonuç arşivi” gibi daha geniş bir kullanıcı deneyimi sunuyorsa durum değişir: burada sayfanın değerini artıran faktörler (detaylı içerik, anonimleştirme, kullanıcıya özel ama düzenli) devreye girebilir. Yine de genel arama motoru erişimi hedeflenmiyorsa noindex + erişim kontrolü doğru strateji kalır. Sadece arşiv gerçekten aranabilir ve benzersiz içerik üretiyorsa “tek bir arşiv sayfasına konsolidasyon” gibi redirect stratejileri değerlendirilir.

Redirect mi Noindex mi? Her birinin artı/eksi ve risk matrisi (özet)

• Noindex artıları: düşük değerli şablonların indeksini engeller, crawl/indeks gürültüsünü azaltır; hedef endpoint’e “yer değiştirme” zorunluluğu yoktur.
• Noindex eksileri: sayfa keşfedilebilir; Google URL’yi keşfettiği için yeniden tarayabilir (özellikle dış bağlantı veya internal görünürlük varsa). Internal link kesilmezse etki zayıflar.
• Redirect artıları: kalıcı değişiklikte indekslenmiş URL’leri toplar; kullanıcı ve bot aynı hedefe yönlenir. “Profil artık yok” gibi durumlarda daha net sonuç alınır.
• Redirect eksileri: yanlış kod seçimi veya zincirler crawl’ü yavaşlatır; geçici durumlarda sürekli redirect dalgalanması yaşanabilir.

Dolayısıyla en doğru seçim, “URL’nin amacı”nı net tanımlamakla başlar: kullanıcıyı farklı bir ekrana taşımak mı istiyorsunuz (redirect), yoksa aynı ekranda kalıp arama motoru indeksini mi kapatmak istiyorsunuz (noindex)?

Eğer Redirect seçilirse: Doğru kod (301/302/307/308), zincirlerden kaçınma ve geçiş hedef stratejisi

Redirect kullanacağınızda, kod türünü “kalıcılık” ve “HTTP method davranışı” açısından seçin. Kalıcı erişim değişikliği senaryolarında 301 (veya gerektiğinde 308) tercih edin. Geçici “inceleniyor” senaryolarında 302 veya uygulama diline/stack’e göre 307 kullanmak daha temiz olabilir.

Zincirlerden kaçının: A→B→C gibi bir akış oluşursa hem crawl bütçesi hem de doğrulama süreçleri karmaşır. Yapmanız gereken: complaint endpoint’ini doğrudan nihai hedefe bağlamak (tek sıçrama), ara “bridge” URL’leri üretmemek ve mümkünse aynı hedefi sabit tutmak. Ayrıca hedef URL’nin kendisi de noindex/robots ile çakışmamalı; aksi halde bot yeni hedefi keşfetse bile indeksleyemez.

Aşağıdaki örnek URL senaryosu bu stratejiyi somutlaştırır. /user/{id}/complaint/{ticketId} (ticket’a özel sayfa) gibi bir endpoint için redirect ancak “yerine başka sayfa koyma” ihtiyacı varsa düşünülmelidir; çoğu durumda noindex + erişim kontrolü daha uygundur.

Eğer Noindex seçilirse: robots meta vs X-Robots-Tag, sitemap/robots ve iç linklemeyi kesme

Noindex uygulaması için iki yaygın seçenek vardır: meta robots etiketi (örn. <meta name="robots" content="noindex,nofollow">) veya HTTP yanıt başlığı olarak X-Robots-Tag. Complaint sonrası URL’lerde uygulamanın mimarisine (SSR/SPA), CDN katmanına ve endpoint türüne göre hangisinin daha stabil olduğuna karar verin.

Burada kritik nokta: noindex kararı sitemap ve robots ayarlarıyla desteklenmelidir. Sayfaları sitemap.xml’e eklemeyin. robots.txt ile engelleme yapacaksanız (endpoint’i tamamen kapatma) noindex yerine geçmez; çünkü Google noindex isteğini her zaman okuyamayabilir. Bu yüzden “noindex yeterli mi, robots ile de engellemek gerekir mi?” sorusu senaryoya bağlıdır. Eğer sayfa zaten oturum gerektiriyorsa ve bot erişimi anlamsız ise robots ile engelleme bir seçenek olabilir; ama çoğu ekip önce noindex + internal link kesme ile ilerler.

İç linkleme durdurulmazsa noindex’in etkisi azalır: Bot bu URL’leri daha sık görür, “discovered” olur ama “indexed” olmaz. Bu da loglarda crawl aktivitelerini artırabilir. Bu nedenle complaint sonrası UI’da botların keşfini kolaylaştıran linkleri sınırlandırın.

Örnek URL senaryoları (kararı netleştiren gerçekçi örnekler)

Örnek 1: /user/{id}/complaint/{ticketId} (ticket’a özel sayfa) — noindex/redirect kararı. TicketId bazlı sayfalar genellikle şablon ve düşük içerik üretir. Eğer sayfa yalnızca ilgili kullanıcıya görünüyorsa ve arama motoru için anlamlı bir “sonuç” barındırmıyorsa noindex uygulayın. Eğer sayfa “kısa süreli durum” gösterip daha sonra tek bir “hesap durumu” sayfasına dönüşüyorsa, kısa süreli redirect düşün (örn. 302/307), fakat zincir üretmemeyi hedefleyin.

Örnek 2: Complaint sonrası kullanıcı profili artık gizlenmişse /profile/{id} → redirect hedefi. Burada redirect çoğu zaman daha doğru olur: “erişim yok/ yardım” sayfasına 301 ile yönlendirin. Böylece eski profil URL’leri indekslenmişse bile sinyal toparlanır. Redirect hedefinin de “kişisel bilgi” ifşa etmeyecek anonim ve güvenli bir içerik olduğundan emin olun.

Örnek 3: “İnceleniyor” durumu geçiciyse redirect mi noindex mi? Eğer sayfa birkaç gün içinde sonuçlanacaksa ve içerik kalıcı değer taşımıyorsa noindex ile başlayıp sonuç geldiğinde hedefi güncelleyin. Alternatif olarak geçici redirect kullanacaksanız 302/307 ile “durum akışı”na yönlendirin; zaman geçince tekrar davranış değişebilir. Burada ölçüm şart.

Örnek 4: Aynı complaint sonucunda benzer/aynı şablon içerikler üretiliyorsa canonical/redirect/noindex etkileşimi. Canonical, düşük değerli şablonların indeksini tek başına çözmez. Aynı şablon farklı ticketId’lerde oluşuyorsa ya tüm varyasyonlarda noindex uygulayın ya da sadece tek bir “özet durum” endpoint’ine taşıyın. Canonical eklenseniz bile indeks bütçesi gereksiz gürültüyle dolabilir.

Crawl bütçesi ve indexleme bütçesiyle ilişkisi (diğer yazılara köprü)

Complaint sonrası URL’ler bir “page generation” mekanizması gibi çalışıyorsa, crawl ve indexleme bütçesi üzerinde doğrudan etkileri olur. Google noindex olsa bile keşif/yeniden tarama için bazı sinyallerle URL’leri tekrar görebilir. Bu nedenle amacınız sadece indekslemeyi durdurmak değil; gereksiz keşfi de yavaşlatmak olmalı.

Bu noktada internal linklemeyi kesme, sitemap’e eklememe ve gerekirse endpoint’i robots ile kısmi engelleme gibi yöntemler birlikte düşünülmeli. Konuyu daha geniş bağlamda yönetmek için Chat Sitelerinde Launch Ramp (Yeni Oda Açma Hızı) ile Crawl Bütçesini Yönetme Rehberi yaklaşımından ilham alabilirsiniz; ancak complaint akışında kontrol, daha çok “olay bazlı URL üretimi” üzerine odaklanır.

Benzer şekilde mesaj/oda gibi diğer dinamik içeriklerde de index kararı complaint ile benzer prensipleri paylaşır. Bu rehber de kavramsal destek sunar: Chat Sitelerinde Mesaj İçeriği Index mi Noindex mi? (SEO ve Kullanıcı Değeri Dengesi için Karar Rehberi).

Yaygın Hatalar

En sık görülen hata, complaint sonrası sayfalara “noindex” uygulayıp aynı anda bu URL’leri sitemap’e eklemek veya UI’da güçlü internal linklerle botların keşfini artırmaktır. Bu durumda Google sayfayı sık görür; indekslemez ama log ve discovery maliyeti artar.

Diğer yaygın hata, redirect kodunu yanlış seçmek veya zincir üretmektir. Örneğin inceleniyor durumunda 301 kullanıp kalıcı sinyal üretmek, ileride erişim geri döndüğünde yönlendirme politikasını değiştirmek zorunda kalmanıza neden olur. Bu da hem kullanıcı deneyimini hem de SEO performansını dalgalandırır.

Uygulama Kontrol Listesi (Go-live öncesi/sonrası)

Aşağıdaki listeyi bir şablon gibi kullanın. “complaint sonrası URL’nin amacı” netleşmeden kod yazmayın.

1. URL sınıflandırması yapın: ticketId bazlı sayfa mı, profile değişikliği mi, inceleniyor akışı mı?
2. İçerik değerini değerlendirin: benzersizlik var mı, şablon mu? Kişisel veri ifşası riski var mı?
3. Hedef sayfayı belirleyin: redirect ise nihai hedef tek olmalı (bridge URL yok).
4. Noindex uygulamasını doğrulayın: meta robots mu X-Robots-Tag mi; endpoint’te gerçekten çalışıyor mu?
5. Sitemap/internal linkleri gözden geçirin: complaint URL’lerini sitemap’e eklemeyin; UI’da bot keşfini azaltın.
6. Geçici durum için zaman planı yapın: inceleniyor → sonuçlandığında davranış ne olacak?
7. Log ve GSC izleme için ölçüm planı ekleyin: değişiklik sonrası index/discovery eğrileri nasıl ilerliyor?

Ölçüm ve Doğrulama: GSC raporları, log analizi, index durumu izlemi

Adım adım doğrulama yapmadan kararınızı “kalıcı” hale getirmeyin. Aşağıdaki doğrulama adımları özellikle complaint sonrası dinamik endpoint’lerde hızlı geri bildirim sağlar.

1. GSC URL Denetleme: complaint endpoint örnekleri için “Indexleme” durumunu kontrol edin; “noindex uygulanıyor mu” etkisini görmek için canlı URL testleri yapın.
2. Log analizi: botların complaint URL’lerini ne sıklıkla ziyaret ettiğini ölçün (değişiklik öncesi/sonrası karşılaştırma). Keşif azalıyor mu?
3. Index durumu trendleri: GSC’de “Indexed, not submitted” / “Discovered, not indexed” gibi kategorilerin dağılımını izleyin; politikanın keşif ama indeksleme üretip üretmediğini anlayın.
4. Redirect zinciri kontrolü: HEAD/GET ile redirect zinciri uzunluğunu test edin; tek sıçrama hedefleyin. Farklı kullanıcı rolleriyle aynı davranış oluşuyor mu inceleyin.

Sık Sorulan Sorular (SSS)

Complaint sonrası sayfalar 404/410 olmalı mı, yoksa noindex/redirect yeterli mi?

Çoğu durumda 404/410 yalnızca “sayfa gerçekten yok” ise anlamlıdır. Complaint ticket’ları rol/oturumla erişilebilir olabilir ama botlar için anlamsızsa 404/410 yapmak gereksiz “gerçeklik sinyali” üretip yanlış beklentilere yol açabilir. Noindex/redirect daha kontrollü bir çözümdür. Ancak erişim kalıcı olarak bitiyorsa (ör. kesin silme, kalıcı gizlilik), 410 bile tercih edilebilir; burada ürün ve yasal gereklilikler belirleyicidir.

Noindex seçersem Google bu URL’yi crawl etmeye devam eder mi; crawl budget nasıl etkilenir?

Evet, noindex çoğu zaman keşfi tamamen durdurmaz. Google URL’yi keşfettiği için yeniden ziyaret edebilir; ancak indekslemez. Crawl budget etkisi, internal linkler, external link varlığı ve endpoint’in ne kadar “çekici” olduğuyla ilgilidir. Bu yüzden noindex yanında sitemap dışlama ve internal link azaltma önemlidir.

301 redirect ne zaman uygun, 302 ne zaman daha doğru?

301 erişim/şema kalıcı şekilde değiştiğinde; 302 sürecin geçici olduğu durumlarda sık kullanılır. Daha kesin semantik için 307/308 tercih edilebilir. Complaint “inceleniyor” gibi geçiciyse 302/307 daha mantıklı olur.

Redirect zinciri olursa SEO performansı ve crawl nasıl etkilenir?

Zincirler gecikme yaratır ve botların hedefe ulaşması uzar. Bu da tarama maliyetini artırabilir; bazen de yönlendirme sinyallerinin zayıflamasına neden olabilir. Tek sıçrama hedefleyin ve bridge URL kullanmayın.

Bu sayfaları sitemap’e eklemek doğru mu?

Genellikle hayır. Complaint sonrası low-value veya ticketId varyasyonlu sayfaları sitemap’e eklemek indekslenmeyi hızlandırmayabilir; ama keşfi artırır. Daha doğru yaklaşım: sitemap’e sadece gerçek içerik ve arama motoru değeri üreten URL’leri koymaktır.

Internal linkler durdurulmazsa noindex kararının etkisi azalır mı?

Evet. Noindex indexlemeyi durdurur ama keşfi azaltmak iç link politikasına bağlıdır. Eğer UI ve yönlendirmelerle bu URL’ler botlar için kolay bulunuyorsa, “discovered” sayısı artabilir.

GSC’de “Indexed, not submitted” veya “Discovered, not indexed” hangi senaryoda beklenir?

“Indexed, not submitted” genellikle URL’nin sitemap veya açık gönderimle değil, discovery ile indekslendiğini gösterir. Complaint URL’lerinde internal link veya dış kaynak etkisi varsa görülebilir. “Discovered, not indexed” ise noindex uygulamasının çalıştığı veya sayfanın düşük değer nedeniyle indekslenmediği senaryolarda beklenir.

Sonuç: Complaint sonrası URL’lerde net aksiyon planı

Complaint sonrası oluşan sayfalar için doğru SEO kararı, “noindex mi redirect mi?” ikileminden önce “bu URL’nin amacı nedir?” sorusunu yanıtlamaktan geçiyor. Kalıcı erişim değişikliklerinde redirect ile hedefi sabitlemek; geçici “inceleniyor” akışlarında noindex veya geçici kodlarla kontrollü yönlendirme; ticketId varyasyonlu şablon sayfalarda ise noindex + sitemap dışı yaklaşımı tercih etmek genellikle en güvenli yoldur.

En kritik pratik kural da şu: Kod seçiminizi ölçümle destekleyin. GSC ve log verileriyle keşif/indeks durumunu izleyin; redirect zinciri ve internal link keşfi gibi yan etkileri erken yakalayın. Böylece complaint sonrası URL’ler sayfa patlamasına dönüşmeden, hem moderasyon akışınızı hem de SEO sağlığınızı korursunuz.

İsterseniz bir sonraki adım olarak platformunuzdaki complaint endpoint’lerinin URL üretimini ve erişim kurallarını (rol/oturum) birlikte çıkarıp, hangi gruba redirect hangi gruba noindex uygulayacağınızı netleştirelim. Bunun için şu odak rehberi de yardımcı olabilir: Moderasyon Notları İndeklenmeli mi? (Rules & Ban Reason Sayfaları) SEO Etkisi ve En İyi Uygulamalar.