Oda Kapanınca Kapanış Arayüzü SEO’su: 404/410 Yerine Eşik Geçiş Modeli ile Indexi Doğru Yönetme

Chat sitesinde bir oda kapanınca geriye “ne olacağı” belirsiz bir URL akışı kalır. Tam da bu noktada kapanış arayüzü (redirect/kapanış sayfası/placeholder endpoint) SEO açısından kritik hale gelir. Özellikle Chat sitesinde oda kapanınca ‘kapanış arayüzü’ SEO’da nasıl konumlanır: 404/410 yerine eşik geçiş modeli yaklaşımı, kapanan odaların URL’lerini körlemesine 404/410’a göndermek yerine kontrollü bir yaşam döngüsüne almayı amaçlar.

Bu yazı; teknik ekiplere, growth/technical growth ekiplerine ve SEO uzmanlarına, kapanış anında ortaya çıkan sayfaların indekslenebilirliğini “tek seferlik bir policy” ile değil, zaman ve kalite sinyalleri gibi ölçülebilir metriklerle yöneten bir eşik geçiş modeli kurmaları için adım adım rehberlik eder. Hedefimiz iki yönlü: Indexi koruyacak kadar esnek, kaliteyi düşürmeyecek kadar disiplinli; aynı zamanda tarama maliyetini yönetilebilir tutacak bir sistem tasarlamak.

Problemin Tanımı: Oda kapanınca URL ne olur? “Kapanış arayüzü” tam olarak hangi sayfa/endpoint

Chat mimarisinde odalar genellikle bir room_id veya slug üzerinden adreslenir. Kullanıcı oda içinde WebSocket/long-poll ile sohbet eder; oda kapanınca aynı route artık “mesaj akışı” hizmet edemez. Bu durumda çözülmesi gereken şey sadece kullanıcı ekranı değil; arama motorunun önüne çıkan HTTP davranışıdır.

“Kapanış arayüzü” derken aslında birkaç farklı senaryodan bahsediyoruz: (1) aynı URL üzerinde dinamik içerik üreten “oda kapandı” sayfası, (2) oda kapanınca başka bir URL’ye yönlendiren redirect akışı, (3) ayrı bir endpoint olan “/room-closed” gibi placeholder route, (4) client tarafında (JS) bir fallback gösterilirken server’ın 200 döndürmeye devam ettiği durumlar. Bu varyasyonların SEO etkisi aynı değildir; önce hangi varyasyonun sizde çalıştığını netleştirmek gerekir.

Örneğin /r/abc123 adresi canlıyken SSR ile içeriği (başlık, meta, ilk mesaj snippet’i) sağlayabiliyorsanız, kapanınca aynı route üzerinde “Oda kapanmıştır” metniyle bir ekran render edebilirsiniz. Ya da server 302/301 ile /r/abc123/closed’a taşıyabilirsiniz. Buradaki seçim, indexin “ne kadar yaşayacağı” üzerinde doğrudan etkiye sahip olur.

404 vs 410 vs 3xx Redirect vs Noindex/HTTP (kısaca) ve neden tek politika yetmez

404, aramanın “kaynak bulunamadı” sinyalini almasını sağlar; birçok senaryoda hızlı şekilde tekrar taramayı azaltmaya yardımcı olur. 410 ise daha net bir “kalıcı olarak gitti” sinyali taşır; özellikle kısa ömürlü ama geri gelmeyecek sayfalarda tercih edilebilir. 3xx redirect ise içeriğin taşındığını anlatır; doğru yapılandırılmadığında 404/410’dan daha fazla belirsizlik yaratabilir.

Noindex ise indekslemeyi engeller; ancak crawl bütçesi ve tarama sıklığı yönetimi açısından tek başına çoğu zaman yeterli değildir. Çünkü noindex’li endpoint’ler yine taranır, yalnızca indekslenmez. Chat dünyasında ise kapanış arayüzü “çok sayıda URL” üretebilir; bu durumda crawl bütçesi maliyeti büyüyebilir.

Bu yüzden tek bir politika çoğu zaman yetmez. Kullanıcı oda kapanınca ne arıyor sorusu ile arama motorunun “bu URL artık hangi değeri temsil ediyor?” sorusu aynı anda düşünülmelidir. Kalite sinyalleri düşüyorsa hızlı noindex/410 mantıklı olabilir; ama dışarıdan değerli trafik/bağlantı geliyorsa, kısa bir süreliğine “eşik geçişi” ile daha akıllı yönetmek çoğu zaman daha iyi sonuç verir.

Eşik Geçiş Modeli: Hot/Warm/Cold aşamaları (zaman, mesaj sayısı, etkileşim, dış link, talep yoğunluğu)

Eşik geçiş modelinin mantığı basittir: Oda kapanır, fakat URL’nin “değeri” kapanma anında aynı seviyede değildir. Bazı odalar kapanır ama kısa süre içinde az mesaj ürettiği için “ince içerik riski” taşır. Bazıları kapanır ama backlink, marka araması veya önceki kullanıcı etkileşimi nedeniyle hâlâ arama niyetiyle ziyaret alır. Sistemi bu farkı gözeterek kademelendirirsiniz.

Önerilen üç faz:

• Hot (Kısa süreli sıcak pencere): Oda kapanır kapanmaz oluşan kapanış arayüzü. Amaç, tarama motorlarının “güncel durumu” görmesini sağlamak ve kalite sinyalleri (ör. dış trafik) devam ediyorsa kontrollü biçimde indeks sinyali toplamaya izin vermektir.
• Warm (Eşik geçişi): Mesaj/kalite sinyallerine göre “indexte kalabilir mi?” sorusu daha netleşir. Burada ya noindex’e geçilir ya da sınırlı indeks kalır.
• Cold (Soğuk/uzun dönem): Odaların çoğu bu aşamada ya noindex/HTTP politikasına alınır ya da 410/kalıcı durum stratejisiyle tarama maliyeti azaltılır. Indexte kalması gerekenler ise sadece yüksek kalite sinyali taşıyanlar olur.

Bu fazlarda kullanılabilecek parametreler: kapanmadan sonra geçen süre, toplam mesaj sayısı, son mesajın yaşı, katılımcı sayısı, kullanıcı etkileşimi (beğeni/cevap bağlantıları), arama sonuçlarında görünen fragment kalitesi, dışarıdan gelen trafik (referer/backlink sinyali), sosyal paylaşımlar ve hatta “talep yoğunluğu” (tarama/istek hacmi).

Kapanış arayüzü için teknik mimari akışı (örnek endpoint/route mantığı)

Örneğin oda route’unuz şu şekilde olsun: /room/{roomSlug}. Oda açıkken normal sohbet akışı vardır. Oda kapandığında ise aynı route üzerinde bir “durum switch” ile yanıt verirsiniz. Ancak bu switch’i körlemesine 200 ile sürdürmek yerine, aşamaya göre HTTP status ve meta robots ile davranışı bilinçli şekilde değiştirmek gerekir.

Örnek route mantığı:

1. RoomController oda durumunu kontrol eder: isClosed, closedAt, messageCount, lastActiveAt.
2. Policy Engine eşiğe göre fazı belirler (Hot/Warm/Cold).
3. Faz’a göre yanıt şeması uygulanır: 200 + canonical + robots, ya da 410, ya da 302/307 ile kapanış sayfasına yönlendirme (yönlendirmede index sinyali tutarlılığı korunur).
4. İsteğe/erişime göre “kalite açıklaması” gösterilir: kullanıcıya net bilgi, arama motoruna ise indekslemeye uygun meta ve içerik kalitesi.

Burada önemli bir mimari karar var: Kapanış arayüzünü ayrı bir endpoint olarak tasarlayabilirsiniz (/room/{slug}/closed). Bu yaklaşım, internal link ve canonical kontrolünü kolaylaştırır. Alternatif olarak aynı endpoint üzerinde render edebilirsiniz; fakat bu durumda HTTP meta davranışını daha dikkatli yönetmeniz gerekir.

SEO Kontrol Planı: robots meta, X-Robots-Tag, canonical, HTTP status seçimi (200/3xx/410/noindex), index sinyali tutarlılığı

Eşik geçiş modelinde amaç, arama motorunun sinyal setini (HTTP status, robots, canonical, internal link) tutarlı şekilde okuyabilmesini sağlamak. Çünkü Google aynı URL için “neden bugün indexleniyor, yarın neden değil?” gibi çelişkilere kısmen tolerans gösterebilir; fakat belirsizlik arttıkça kalite algısı ve crawl davranışı olumsuz etkilenebilir.

En sık kullanılan kontrol mekanizmaları:

• Robots meta: sayfa HTML içinde <meta name="robots" content="noindex,nofollow"> gibi.
• X-Robots-Tag: header üzerinden koşullu noindex (özellikle CDN/edge katmanında faydalı olur).
• Canonical: kapanış arayüzü başka bir sayfaysa canonical’i doğru hedefe bağlama.
• HTTP status: 200 ile noindex veya 410 ile kalıcı sinyal; redirect ile taşınma sinyali.

Aşağıdaki tablo, kapanış arayüzü için “faz”a göre somut karar eşleştirmesi örneği verir. Kritik nokta şu: robots ve status birlikte seçilmeli; canonical hedefi net olmalı.

Durum (Eşik / Faz)	HTTP Status	Robots / X-Robots-Tag	Canonical	Amaç
Hot: kapanış sonrası < 24s ve dış trafik yüksek	200	index,follow	Self (oda kapanış URL’si)	Kısa süreli indeks sinyali topla
Warm: mesaj sayısı < eşik veya kalite sinyali düşük	200	noindex,follow	Self veya kapanış canonical’i	İnce içerik indeksini durdur
Cold: kalıcı olarak değersiz (uzun süre + düşük etkileşim)	410	(opsiyonel) noindex zorunlu değil	Self (410 URL)	Crawl’ı ve tekrar taramayı azalt
Warm/Cold: çok güçlü backlink/arama niyeti	3xx (örn. 307/302 değil, mümkünse 308/301 tutarlı)	index,follow	Hedef kapanış sayfasına canonical	Doğru URL’de kaliteyi konsolide et

Burada hatırlatıcı bir prensip var: 3xx redirect kullanırken hem redirect hedefinin robots/canonical davranışı hem de kaynak URL’nin davranışı birbiriyle uyumlu olmalı. Aksi halde sinyal çakışması oluşur.

Kullanıcı Deneyimi ile SEO’nun birlikte yönetimi (yönlendirme vs bilgilendirme sayfası)

SEO burada yalnızca “botların okuduğu” bir şey değil; kullanıcı da kapanış anında doğru yönlendirilmek ister. Kullanıcıya “odanın bittiği” net anlatılmalı; isterseniz ilgili odalara veya arama/keşif akışına yönlendirme yapılabilir. Ancak bu öneri alanlarının indekslenebilirliği ayrıca düşünülmelidir.

Örneğin aynı kapanış arayüzü içinde “benzer odalar” listesi gösteriyorsanız, bu listeler yeni URL üretme eğiliminde olabilir. Yeni URL üretmeyen veya parametreli pagination yaratmayan bir yapı tercih edin; yoksa crawl budget gereksiz yere şişer. Kullanıcı deneyimi için gösterilen blokların SEO etkisi (internal link sayısı, anchor kalitesi, takip edilecek linkler) kontrol edilmelidir.

Redirect stratejisinde kullanıcıyı anında doğru sayfaya taşımak avantajlı olabilir. Fakat redirect ile noindex’i birlikte kullanmak bazı senaryolarda çakışma yaratabilir. Bu yüzden bilgilendirme sayfası + kontrollü index/noindex genellikle daha öngörülebilir bir yoldur; sadece bazı durumlarda redirect ile konsolidasyon tercih edilir.

Eşiklerin seçimi ve kalibrasyon: hangi metriği hangi eşiklerle kullanmalı (A/B veya kademeli roll-out)

Hot/Warm/Cold ayrımı için eşikleri “tahmin” ile değil, ölçüm ile belirlemek gerekir. Başlangıç için en pratik metrikler: kapanış sonrası geçen zaman, toplam mesaj sayısı, ortalama mesaj uzunluğu/boş içerik oranı ve etkileşim (beğeni/cevap/katılım yoğunluğu). Ek olarak dışarıdan gelen istek hacmi ve tarama istatistikleri (GSC + log) eşik kararını hızlandırır.

Kademeli roll-out önerisi: Önce yalnızca “Hot” penceresinde davranışı değiştirin. Warm’a geçtiğinizde noindex veya 410’a geçişi yavaşça devreye alın. Bu yaklaşım, yanlış eşiklerin tüm siteyi etkileyerek ani bir kalite düşüşü yaratmasını engeller.

A/B veya “segment bazlı” kalibrasyon yapabilirsiniz. Örneğin messageCount < 3 olan odaları Warm’da noindex’e alıp; messageCount ≥ 3 olanlarda ilk etapta indexte tutarak hangisinin daha iyi performans verdiğini izleyin. Buradaki denge kritik: “indexte kalma süresi” ile “kalite düşüşü” arasındaki ilişkiyi doğru okumak.

Crawl Bütçesi ve performans: taramayı nasıl kontrol ederiz, gereksiz tarama/tekrarları nasıl azaltırız

Kapanış arayüzü çok sayıda üretiyorsa (özellikle düşük ömürlü odalar), Googlebot ve diğer botlar aynı endpoint’leri tekrar tekrar taramaya yönelebilir. Bu durum hem sunucu maliyeti hem de indeks kalite oranı açısından risk yaratır. Eşik geçiş modelinin soğuk fazı tam burada devreye girer: düşük değerli URL’lerin tekrar taranmasını azaltırsınız.

Pratikte crawl kontrolü için şu katmanlar devreye alınır: (1) Cold faza geçen odalarda 410 uygulayarak “kalıcı gitti” sinyalini güçlendirmek, (2) noindex’li ama 200 dönen URL’lerde X-Robots-Tag ile net politika göstermek, (3) internal link’lerden kapanış URL’si veya benzer oda listelerini azaltmak.

Özellikle WebSocket tabanlı chat’lerde “arka planda” istek akışı yüksek olduğu için tarama maliyeti ayrıca bir problem olabilir. Botların sadece HTML alması hedeflenmeli; API uçları crawl’e açık olmamalıdır. Bu yüzden route seviyesinde ayrım şarttır.

İç linkleme stratejisi: oda bağlantıları kaldırılır mı, kapanışta nasıl güncellenir?

İç linkleme, indeks yönetiminin en sessiz ama en güçlü araçlarından biridir. Kapanış odasına link veren “odalar listesi”, “sidebar”, “featured” alanı gibi bileşenler devam ederse Googlebot kapanış URL’lerini daha sık görür. Bu durum, yanlış eşiklerle birleşince index israfını artırabilir.

Yapılması gereken: Faz’a göre internal link davranışını güncellemek. Örneğin Hot fazda bağlantı devam edebilir (kısa süre indeks sinyali toplamak için), Warm’da bağlantı azaltılır ya da benzer odalara kaydırılır, Cold’da kapanış odası linklenmez. Bu “link budget” mantığıyla da uyumludur.

Internal linklerin kaldırılması tek başına yeterli değildir; anchor metinlerinin niteliği de en az bunun kadar önemlidir. Anchor “odanın kapandığını” anlatan bir bağlamla verilirse kullanıcıya değer sağlar; ancak indexlenebilirliği düşürmek istediğiniz URL’lerde anchor yoğunluğunu azaltmalısınız.

Log/analytics ile doğrulama: GSC kapsam raporu, tarama istatistikleri, log analiziyle eşiklerin etkisini okuma

Eşik geçiş modelini başarılı yapan şey, “varsayımdan çıkıp veriyle doğrulamak”tır. GSC’de kapsam raporları (indexed/not indexed/excluded) kapanış sonrası davranış değişimini yansıtabilir. Ancak tek başına GSC bazen gecikmeli görünür; bu yüzden log analizini eklemek gerekir.

Doğrulama yaklaşımı:

1. GSC kapsam raporunu kapanış URL gruplarıyla eşleştirin (örn. URL pattern: /room/*, kapanış parametresi veya kapanış path’i).
2. Log’larda bot isteğini faz bazında etiketleyin: Hot/Warm/Cold geçişine göre istek sıklığı ve 200/410 dağılımını izleyin.
3. Index sonuçlarını zaman serisiyle izleyin: noindex’e geçtiğinizde indexed düşüşü var mı, 410’a geçtiğinizde crawl azalıyor mu?

Ek olarak sunucu tarafında cache hit oranları, CDN yanıt süreleri ve 3xx/200 oranları da takip edilmelidir. Çünkü yanlış policy bazen sadece SEO’yu değil performansı da bozar.

Örnek Senaryolar: üç farklı kapanış profilinde eşik modeli nasıl uygulanır?

Şimdi “eşik geçişi”nin nasıl karar ürettiğini üç senaryo üzerinden somutlaştıralım. Bu senaryolar, farklı kapanış profilinde 404/410’a direkt gömmek yerine kontrollü yönetmenin neden daha doğru olduğunu daha net gösterecek.

Örnek senaryo 1: Yeni kapanan oda (az mesaj + kısa süre geçti) → warm/cold geçiş zamanlaması ve noindex/redirect kararları

Oda kapanır kapanmaz Hot faz başlar. Diyelim ki messageCount=2 ve kapanış sonrası 6 saat geçmiş. Dış trafik düşükse (talep az), ama aramada “oda linki” tıklanıyor olabilir. Bu durumda Hot’ta 200 döndürüp kısa süre indeks sinyali toplamak (index,follow) mantıklı olabilir. Warm’a geçince (ör. 24 saat/3 saatlik ikinci eşik gibi), messageCount düşük kaldığı için noindex devreye alınır.

Cold’da artık linklenmemesi tercih edilir. İsterseniz Cold’da 410’a geçebilirsiniz; fakat bunu yapmadan önce loglarda crawl azalmasının gerçekten gerçekleştiğini doğrulayın. 410’a erken geçerseniz dış trafik “tam kapanıştan sonra” artarsa o sayfayı gereksiz yere kaybedebilirsiniz.

Örnek senaryo 2: Dışarıdan trafik alan (backlink/arama niyeti yüksek) kapanmış oda → eşik geçişiyle kısa süre indexte tutma/kalite sinyali

Bu senaryoda aynı mesaj sayısı az olabilir ama oda dışarıdan link alıyordur. Arama niyeti yüksek olduğu için kullanıcılar kapanmış odanın içeriğini görmek isteyebilir (ör. önemli bir tartışma veya çözüm). Burada Hot faz uzatılabilir veya Warm’da bile index kalabilir.

Kalite sinyalini artırmak için kapanış arayüzünde “son durum özeti” sunulur (en son mesaj özeti, konu başlığı, otomatik özet değil; metin bütünlüğü korunarak). Ardından sinyal hâlâ düşükse Warm’da noindex’e geçilir; ancak dış trafik sürüyorsa “indexi kısa süreli tutma” politikasını uygulayarak değer sinyalini boşa harcamazsınız. Böylece 404/410’a direkt geçişle değeri kaybetmeden yönetirsiniz.

Örnek senaryo 3: Çok mesajlı ancak artık canlı olmayan oda → mesaj/kalite eşiklerine göre indexlenebilir kalma tasarımı

messageCount 50+ ve etkileşim yüksekse, oda kapanmış olsa bile içerik “kalıcı bilgi” taşıyor demektir. Burada Cold faza geçince de indexlenebilir kalma tasarımı yapılabilir. Yani kapanış arayüzü 200 + index (ya da 200 + index,follow) ile uzun süre yaşayabilir.

Ancak burada da kalite filtreleri gerekir: çok düşük özgünlük (spam/tekrar), boş içerik veya aşırı ince mesajlar varsa noindex’e düşürülür. Böylece “kapanmış ama iyi” ile “kapanmış ama ince”yi net bir şekilde ayırırsınız.

Durum kodu + robots/canonical kombinasyonları: somut karar eşleştirmeleri

Aşağıdaki kısa örnekler, uygulama ekiplerinin hızlı karar vermesi için pratik bir referans gibi düşünülebilir. İki kritik tema var: (1) robots ve canonical aynı hedefi işaret etmeli, (2) redirect varsa hedef URL’nin sinyali de aynı politikayı desteklemeli.

• Hot (indexli): 200 + robots: index,follow + canonical=self + internal link listesi sınırlı.
• Warm (noindexli): 200 + robots: noindex,follow + canonical=self + internal link azalt.
• Cold (kalıcı gitti): 410 + canonical=self (veya canonical target) + internal link kaldır.
• Redirect konsolidasyonlu: kaynak 3xx, hedef 200 + index + doğru canonical. Kaynak URL’ye noindex eklemek bazı durumlarda gereksiz olabilir; asıl hedef URL’de politika net olmalı.

Yaygın hatalar

Bu bölüm, eşik geçiş modelini hayata geçirirken sık yapılan yanlışları toplar. Amaç “neden çalışmadığını” hızlıca teşhis etmektir.

• 404/410’a aniden geçmek: Oda kapanınca tüm URL’leri aynı gün 410 yapmak, dış trafik yüksekse kısa vadeli sinyali sıfırlar. Eşikleri önce Hot’ta etkileyip Warm/Cold’da kademeli ilerlemek daha güvenlidir.
• Noindex ile redirect’i çakıştırmak: Kaynak URL 302 ile kapanış sayfasına yönlendiriyor ama kaynakta noindex, hedefte index gibi çelişkiler oluşuyor. Bu durumda Googlebot hangi URL’nin kanonik olduğuna karar verirken zorlanabilir. Sinyal setini tutarlı kurun.
• Canonical’i unutmak veya yanlış hedef göstermek: Kapanış sayfası ayrı endpoint ise canonical mutlaka hedefe bağlanmalı. Self canonical ile hedefi yanlış göstermek “duplicate/uygunsuz kanonik” tartışmasına yol açabilir.
• Internal linki hiç güncellememek: Kapanışta sidebar veya keşif alanı kapanış URL’lerini sürdürürse crawl budget tüketilir; index kalitesi düşebilir.

Beklenen hatalar ve düzeltme yaklaşımı

Eşik geçişinde beklenen “küçük dalgalanmalar” normaldir. Ancak dalga büyürse bir şey yanlış demektir. Örneğin Warm’a geçtiğinizde GSC’de indexed düşüşü yavaşsa; bu ya noindex sinyalinin uygulanmadığını ya da canonical hedefinin karıştığını gösterir. Ayrıca 410’a geçtiğinizde crawl azalmıyorsa, cache/CDN katmanı yanlış status döndürüyor olabilir.

Bu gibi durumlarda ilk adım, sinyali katman katman doğrulamaktır: uygulama katmanı (policy engine), edge/CDN (X-Robots-Tag değişiyor mu), CDN cache varyasyonları ve en sonunda tarayıcı/robot görümleri. “Bir yerde doğru” ama “başka yerde yanlış” oldukça sık yaşanır.

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

Uygulama ve SEO birlikte çalıştığında en iyi sonuç “saha testi” ile gelir. Aşağıdaki kontrol listesi hem ölçüm hem de teknik doğrulama için kullanılabilir:

1. Bir kapanan oda örneği seçin ve Hot/Warm/Cold eşiklerini bilerek test edin. Tarayıcıyla HTML’i ve view kaynağını kontrol edin (robots meta var mı, canonical doğru mu?).
2. HTTP status ve header’ları doğrulayın: curl -I veya benzeri araçla X-Robots-Tag ve status’u teyit edin. CDN farklı davranıyor mu bakın.
3. GSC URL inspection yapın: “Googlebot bu URL’yi nasıl görüyor?” kısmını takip edin. Indexed/noindex/blocked durumunu eşik geçiş zamanlarıyla eşleyin.
4. Log’larda bot davranışını faz bazında kıyaslayın: Hot’ta crawl var mı, Warm’da azalıyor mu, Cold’da 410 ile düşüş var mı?
5. İç link listesini doğrulayın: kapanış odaları keşifte hâlâ link alıyor mu? Faz değişince anchor sayısı azalıyor mu?

Bu akış tamamlandığında modelin hem SEO hem performans hedefleriyle uyumlu olduğundan emin olursunuz.

SSS

Kapanış arayüzünü 404 mü yapmalıyız, yoksa noindex mi? Eşik geçişi ne zaman mantıklı olur?

Genel kural: içerik değeri yüksekse noindex ile daha yumuşak geçiş, değeri düşükse 410 ile daha net kalıcı sinyal düşünülebilir. Eşik geçişi ise “aynı URL tipi farklı kalite profilleri üretiyor” durumlarında daha anlamlıdır; chat odaları buna iyi örnektir.

Redirect (301/302) ile noindex aynı anda kullanılır mı? Ne zaman sorun çıkarır?

Evet kullanılabilir ama kaynak ve hedef sinyalleri çakışmamalı. Kaynak noindex + hedef index bazı durumlarda tutarsız algılanabilir. En temiz yaklaşım: redirect hedef URL’de politika net ve canonical uyumlu olacak şekilde tasarlamaktır.

Google kapanış sayfasını ne kadar süre indexler? Eşikler bunu etkiler mi?

Net bir süre verilemez; Google kalite sinyallerine ve tarama sıklığına göre karar verir. Eşikler etkiler: Warm’da noindex uyguladığınızda indexed listeden çıkış daha olası hale gelir; Cold’da 410 ile tekrar tarama ve index kalıcılığı azalır.

Canonical atamak kapanış arayüzünde doğru mu, hangi durumda değil?

Kapanış arayüzü başka endpoint ise canonical hedef URL’ye doğru atanmalı. Ancak tek URL üzerinde koşullu render yapıyorsanız canonical self olmalıdır. Kapanış sayfası ile asıl URL farklıysa ve canonical net değilse canonical hataları görülebilir.

Internal linkler kaldırılmazsa index israfı artar mı?

Evet. Özellikle kapanış URL’leri listelerde devam ediyorsa botlar daha çok tarar; ince/kalitesiz sayfalar indexlenme riskine girer. Faz bazlı iç link güncellemesi bu riski azaltır.

Eşikleri hangi metrikle belirlemek en iyisi: zaman mı mesaj sayısı mı kullanıcı etkileşimi mi?

Zaman + mesaj sayısı iyi bir başlangıçtır. Sonra kullanıcı etkileşimi ve dış trafik gibi sinyallerle kalibrasyon yapılmalıdır. En iyi sonuç genellikle kombinasyonla elde edilir: “kısa süre + düşük mesaj” ince içerik riski, “uzun süre + yüksek etkileşim” değer sinyalidir.

Crawl bütçesi için kapanış URL’leri nasıl yönetilmeli?

Hot/Warm/Cold fazlarıyla: Hot’ta gerektiği kadar erişime açık tutup, Warm’da noindex uygulayıp, Cold’da 410 veya başka kalıcı azaltma stratejileriyle crawl’ı düşürmek en sürdürülebilir yöntemdir. Ayrıca internal link ve taranabilir API endpoint’lerini kontrol etmeyi unutmayın.

Checklist + karar ağacı (hot/warm/cold → aksiyonlar)

Son olarak, ekiplerin uygulama sırasında kullanabileceği kısa bir karar ağacı paylaşalım. Bu akış, “404/410 tek hamle” yerine eşik geçiş modeli ile karar üretir.

• Hot’a düştü mü? (kapanış sonrası kısa pencere) → 200 + politika; dış trafik/kalite varsa index, düşük kalite sinyali varsa noindex hazırlığı.
• Warm’a geçti mi? (zaman + mesaj/kalite eşikleri) → düşük kalite ise 200 + noindex, yüksek kalite ise indexi kısa süreli tut ve internal linki ölç.
• Cold’a düştü mü? (uzun süre + düşük değer) → 410 (veya noindex + internal link kaldırma) ile tekrar taramayı azalt.
• Redirect kullanıyor musun? → redirect varsa hedefte canonical/robots tutarlı; kaynakta çakışan noindex/robots kullanma.
• Ölçüm var mı? → GSC + log ile faz bazlı crawl ve indexed değişimini doğrula.

Bu çerçeve, kapanış arayüzü sayfalarının SEO’da “aniden silinen” değil, kaliteye göre evrilen bir yaşam döngüsüyle konumlanmasını sağlar. Böylece hem kullanıcı deneyimi korunur hem de indeksin kalitesi ve crawl bütçesi birlikte yönetilir.