Chat Sitelerinde “Room Sidebar” Crawl’i: Featured/Ads Taraması Nasıl Kontrol Edilir ve Crawl Bütçesi Nasıl Korunur?

Chat sitelerinde kullanıcı deneyimini zenginleştiren “room sidebar” alanı (featured/ads, öneriler, kampanyalar) çoğu zaman farkında olmadan crawler’ın oda sayfası dışına taşıdığı bir tarama yüzeyi oluşturur. Özellikle link yoğunluğu yüksekse, içerik sık değişiyorsa ya da linkler UTM/parametre gibi yollarla çoğalıyorsa, crawl bütçesi saniyeler içinde dağılabilir. Bu yazıda chat sitesi room sidebar bileşenleri (featured/ads) crawl ediliyor mu crawl bütçesi nasıl korunur sorusunu modül modül ele alacağız.

Genel “craw budget” yazılarından farklı olarak oda yan bileşenlerini (featured/ads) hedefleyen bir kontrol-değişiklik-doğrulama akışı kuracağız. Hedefimiz net: Botun gerçekten hangi URL setini taradığını görmek, istenmeyen taramayı kısmi olarak durdurmak ve kalan taramayı oda ana içeriğine daha verimli yönlendirmek.

Sorun Tanımı: Sidebar Featured/Ads Neden Crawl Bütçesi Tüketir?

Room sidebar içindeki featured/ads modülleri, oda ana içeriğine göre daha hızlı değişen ve daha çok “link hedefleyen” bir katman gibi çalışır. Bu katmanda çoğu zaman her oda için çok sayıda kart (teklif, öneri, kampanya) görürsünüz. Sonuç şu: crawler aynı oda sayfasını ziyaret etse bile, sidebar’ın ürettiği yeni URL’ler tarama derinliğini ve çeşitliliğini artırır.

Bir de işin “UI tarafı” var. Birçok chat uygulaması sidebar’ı kullanıcı etkileşimi ve görsel/medya yükleme ile zenginleştirir. Bu da sonsuz kaydırma (infinite scroll), “daha fazla gör” davranışı ya da lazy-load ile ortaya çıkan linklerin bot için de (render edebiliyorsa) yeni tarama yollarına dönüşebilmesi demek. Böyle olunca crawl bütçesi sadece tek bir sayfaya değil, tüm oda ekosistemine yayılır.

Room Sidebar’ın Muhtemel Crawl Akışları (SSR/CSR, prefetch, lazy-load tetikleme)

Room sidebar’ın tarama davranışı, uygulamanın render mimarisine doğrudan bağlıdır. Bazı sistemlerde oda sayfası SSR (Server-Side Rendering) ile gelir; sidebar kartları HTML’in ilk yanıtında hazır olur. Diğerlerinde CSR (Client-Side Rendering) baskındır; botun taramayı doğru yapabilmesi için ya JS’i çalıştırması gerekir ya da içerik görünmeden URL’ler “ortaya çıkmaz”.

Genelde karşınıza çıkan üç akış var: (1) SSR varsa, linkler ilk HTML’de hazırdır; crawler bunu görür ve hızlıca keşfeder. (2) CSR’de bot JS’i render edemiyorsa sidebar linkleri görünmez; bu senaryoda tarama daha sınırlı kalır ama raporlama eksik olur. (3) Lazy-load/prefetch/viewport tetiklemeleri devreye giriyorsa, bot belirli bir scroll veya iş akışını “taklit ederse” sidebar kartları link üretir ve tarama seti büyür.

• SSR: Sidebar featured/ads linkleri HTML içinde yer aldığı için tarama ve keşif doğrudan olur.
• CSR + render: Bot JS çalıştırabiliyorsa, sidebar linkleri DOM’a eklenir ve discovery artar.
• Lazy-load: Linkler viewport’a gelince üretilir; botun davranışına göre tarama değişkenleşir.
• Prefetch: Kullanıcıya yakın kartlar önceden çekilirse, crawler keşfetmeden linkleri “hat” üzerinden yakalayabilir.

Ön Kontrol: URL’ler Gerçekten Taranyor mu? (Bot Erişimi, Render Durumu, Log İpuçları)

“Sidebar crawl ediliyor mu?” sorusunun cevabı tahminle bulunmaz; önce ölçmek gerekir. İlk adım, botun room page’e erişip erişmediğini ve sidebar modülünün ürettiği linklerin gerçekten HTTP isteklerine dönüp dönmediğini doğrulamaktır. Bunun için iki paralel kanal kullanın: (a) log analizi (hangi URL’lere bot geldi) (b) render durumu testi (bot JS çalıştırdı mı, DOM’a ekleme oldu mu).

Uygulama bot user-agent’ına özel davranıyorsa (ör. “bot modu”, “render fallback”), tarama davranışı gerçek kullanıcıdan sapabilir. Bu sapmayı anlamadan koyacağınız kısıtlamalar oda ana içerik kalitesini de etkileyebilir. O yüzden ön kontrol hem keşif hem istek seviyesinde yürütülmeli.

Crawl Edilebilirlik Tasarım Kararları: Index mi, Noindex mi, Follow mu, Nofollow mu, Sadece Kullanıcı için mi?

Önce “crawled” (keşfedilen) ile “indexed” (arama sonuçlarında görünen) ayrımını netleştirin. Featured/ads kartları bot tarafından keşfedilse bile indexlenmek zorunda değildir. Ama crawl bütçesini genellikle tüketen şey keşif derinliği olur; nofollow bazı durumlarda discovery’yi azaltır fakat sınırsız link setini tamamen durdurmak her zaman mümkün olmayabilir.

Bu yüzden bir karar matrisi kurun: Featured/ads URL’leri için (1) indekslenmeyecek mi, (2) crawl edilemeyecek mi, (3) sadece kullanıcı için mi üretilecek? Reklam/featured sayfaları çok sık değişiyor ve benzersiz bir “SEO değeri” taşımıyorsa, genelde noindex + follow/no-follow + robots kısıtı dengesini kurmak en sağlıklısıdır. Buradaki kritik nokta şu: “crawled bile olsa” bile sınırlayıcı sinyal vererek keşfi daraltmak.

Robots Meta / robots.txt Stratejileri (Sayfa Bazlı ve Bölüm Bazlı Pratikler)

robots.txt, taramayı kaba bir seviyede kontrol eder. Ancak sidebar içindeki featured/ads için pratik yaklaşım çoğu zaman iki katmanlı olur: sayfa bazlı noindex / X-Robots-Tag ile indekslemeyi kapatmak, robots.txt veya uygun rota kısıtları ile crawl keşfini daraltmak.

Özellikle uygulama dinamik üretilen sayfa varyantları (UTM/parametre) oluşturuyorsa, robots.txt ile tüm parametreli yolları tek tek hedeflemek zorlaşır. Bu noktada sayfa bazlı HTTP header veya meta etiketlerini yönetmek daha operasyoneldir. Böylece featured/ads URL’leri taranabilirlikte “görünse” bile indeks için kapanır; keşif kalabalığı ise link mimarisiyle azaltılır.

Link Mimarlığı: Sidebar’da Internal Link Azaltma/Threshold Yaklaşımı ve Featured/Ads Modelleme

Crawl bütçesini korumanın en güçlü yolu “linkleri azaltmak”tır. Sidebar’da her oda için 20 featured link üretmek, oda sayfası başına discovery sayısını 20x artırır. Bu, özellikle aynı botun çok odada gezindiği senaryolarda crawl bütçesinin hızla tükenmesi demek olur. Burada threshold yaklaşımı devreye girer: Bir oda için gösterilen featured kart sayısını sınırlayın ve kartları “stabil” seçin.

Bir noktayı net söylemek gerekiyor: Botun keşfettiği link sayısı ile kullanıcı deneyiminin istediği kart sayısı aynı olmak zorunda değil. Kullanıcıya 20 kart gösterip, SEO tarafında sadece ilk N kartın HTML’de link olarak bulunmasını sağlamak ya da geri kalan kartları kullanıcı etkileşimiyle (link üretimi sonrası) ortaya çıkarmak bir optimizasyondur. Yine de “bot lazy-load tetikler mi?” sorusunun cevabı test gerektirir.

Önbellekleme ve Değişim Sıklığı: Ads/Featured İçeriklerinin Cache ve Varyant Etkisi

Featured/ads içerikleri sık değişiyorsa cache davranışı crawl bütçesini de etkiler. Örneğin aynı URL farklı kullanıcı için farklı içerik döndürüyorsa veya varyant sayfalar (cihaz, dil, kampanya kimliği) üretiyorsa, bot aynı rota üzerinde bile tekrar tekrar farklı içerik keşfedebilir. Bu da “page freshness” kaynaklı daha fazla tarama/yenileme anlamına gelir.

Bu yüzden cache stratejisini crawl açısından da değerlendirin: (1) mümkünse featured/ads içeriklerini daha stabil hale getirin, (2) URL varyantı çoğaltmayın, (3) CDN cache anahtarlarında aşırı dinamik parametreleri kullanmayın. Bu yaklaşım hem performansı artırır hem de botun gereksiz yeni URL’ler üretmesini azaltır.

İndeksleme Kontrolü: Canonical, Noindex, X-Robots-Tag ve Sayfa Parametreleri

Featured/ads URL’leri arama sonuçlarında yer almayacaksa noindex uygulanmalıdır. Ancak noindex tek başına crawl bütçesini tüketmeyi tamamen engellemez; bot yine de keşfedebilir. Bu yüzden canonical/noindex ile indekslemeyi kapatırken, link mimarisi ve robots stratejisiyle keşfi yönetmek birlikte düşünülmelidir.

Parametre varyantları (UTM, kampanya kodu, oda kimliği) varsa canonical etiketini doğru normalize edin ve mümkün olduğunca tek bir “tercih edilen” URL formunu seçin. Header bazlı X-Robots-Tag: noindex kullanmak, tüm endpoint’lerde tutarlılığı sağlar. SSR/CSR farklarının etiket uygulamasını etkilediği durumlarda bu tutarlılık özellikle önem kazanır.

Modül / URL Tipi	Keşif (Crawl) Davranışı	İndeksleme (Index) Hedefi	Önerilen Kontrol
Room Sidebar Featured Linkleri (içerik kartları)	Bot keşfedebilir; link sayısı belirleyicidir	Genelde noindex	HTML’de link sayısını threshold ile azalt + noindex
Ads/Promosyon Landing Page’leri (kampanya)	Keşif derinliği riskli (varyant çoğalabilir)	Genelde noindex veya kontrollü index	UTM/parametre sadeleştir + canonical normalize + robots
Oda ana içerik sayfası	Öncelikli keşif	Index	İç link önceliği oda içeriğine yönlendir + featured’ı ikincil yap

JavaScript/Render Davranışı: Bot Render Edebiliyor mu? Lazy-Load Nasıl Davranır? Prerender Gerekir mi?

Chat uygulamalarında sidebar içeriği çoğu zaman JS ile doldurulur. Bot JS’i çalıştırabilirse lazy-load ile viewport’a gelen kartlar da keşfedilebilir. JS çalıştıramazsa sidebar linkleri keşfedilmeyebilir. Bu yüzden bazen “taranmıyor” gibi görünen durumlar yanıltır: aslında bot oda sayfasını tarıyordur ama sidebar URL’leri görünmediği için keşfetmiyordur.

Bu nedenle üç test yapın: (1) bot erişiminde oda sayfasının ilk HTML’i sidebar link içeriyor mu? (2) render edebilen bot senaryosunda DOM’a link ekleniyor mu? (3) lazy-load tetikleniyor mu, yoksa sadece kullanıcı scroll’unda mı görünüyor? Prerender çözümü düşünüyorsanız, featured/ads linklerini SSR/Prerender ile “mecburen” HTML’e koymak crawl’i büyütebilir; bu yüzden kapsamı seçici tutun.

Ölçüm Planı: Search Console Crawl Stats + Log Analizi + Modül Bazlı URL Örnekleme

Ölçüm planının merkezinde “modül bazlı sinyal çıkarımı” olmalı. Search Console tarafında doğrudan “sidebar modülü crawlandı” gibi bir ifade bulamazsınız; ama URL setleri ve keşif oranları üzerinden çıkarım yapabilirsiniz. Log analizi ise doğrudan hangi endpoint’lerin tarandığını gösterir ve sidebar’ın yönlendirdiği landing page’leri ayrıştırmanızı sağlar.

Pratikte işe yarayan bir örnekleme yaklaşımı şöyle: (a) featured linkleriyle ilişkili belirli bir path şablonu (örn. /rooms/{id}/featured/* benzeri) varsa bunu filtreleyin, (b) ads landing page’ler için query parametrelerini (utm_source gibi) ayrı ayrı inceleyin, (c) botun oda sayfası ziyareti sonrası hangi arama derinliğine çıktığını zaman penceresiyle yorumlayın. Böylece crawl bütçesinin “oda içeriğinden” çok “sidebar bağlantı ağına” akıp akmadığını net görürsünüz.

Deney Tasarımı: A/B veya Kademeli Rollout ile Crawl Bütçesi Farkını Ölçme

Tek seferlik ayar yerine kontrollü bir deney tasarımı kurun. Örneğin sidebar’da featured link sayısını bir grupta 20’den 8’e indirin; başka bir grupta yalnızca ilk N kartı HTML’de link olarak gösterip geri kalan kartları etkileşim sonrası üretin. Alternatif olarak ads modülü landing sayfalarında noindex ya da canonical normalize değişikliklerini kademeli rollout ile devreye alın.

Metrics setiniz net olsun: (1) botun taradığı URL sayısı (log), (2) oda başına keşfedilen featured/ads URL oranı, (3) Search Console benzeri sinyallerde odak endpoint’lerde iyileşme, (4) tarama derinliği (aynı ziyaret zinciri içinde). Deney sonrası “kontrol-değişiklik-doğrulama” akışını kapatmak için aynı bot penceresinde kıyas yapın.

Örnek 1: Sidebar’da Her Oda için 20 Featured Link (Neden Bütçeyi Böler) ve Threshold Uygulaması

Diyelim ki her oda için featured kartlardan 20 link üretmek istiyorsunuz. SEO açısından botun keşfedeceği yeni URL sayısı oda sayısı ile çarpılır. 50.000 oda ziyaretinde bot 1.000.000 featured URL discovery’ine yaklaşabilir. Bu, crawl bütçesini oda ana içerik indeksinden uzaklaştırır ve güncellemelerde tekrar tekrar tarama maliyeti doğurur.

Çözüm: Threshold yaklaşımı. Örneğin HTML’de ilk 6 kartı link olarak gösterin; diğerlerini “daha fazla” aksiyonu ile kullanıcı tetiklesin. Ayrıca link seçimini stabil tutun (ör. rastgele yerine haftalık/istatistik bazlı sabit set). Böylece botun keşif yüzeyi daralır; kullanıcı deneyimi de kontrollü biçimde korunur.

Örnek 2: Ads Modülünün Benzersiz URL’lere Yönlendirmesi (UTM/Parametre Varyantları) ve Sadeleştirme

Ads modülü çoğu zaman “kampanya değişkenleri” ile URL üretir: UTM parametreleri, oda id’si, cihaz tipi, varyant anahtarları. Her kombinasyon benzersiz görünüyorsa, crawler binlerce URL formunu keşfetmeye başlar. Noindex deseniz bile crawl bütçesi tüketimi sürer; çünkü asıl problem keşif genişlemesidir.

Sadeleştirme hedefi şudur: tek bir canonical rota. Örneğin ads landing page endpoint’i yalnızca /ads/{campaignSlug} gibi tekil bir forma indirgenebilir; UTM’ler ya form içinde saklanır ya da oturum bazlı analitik olarak başka kanala yazılır. Böylece sidebar farklı oda sayfalarından aynı ads kampanyasını işaret ederken URL çeşitliliği azalır.

Örnek 3: Sidebar İçeriği SSR Olmaması Nedeniyle Crawler’ın Farklı URL Seti/eksik Link Görmesi

Üçüncü senaryoda sidebar SSR değil. Oda sayfası ilk HTML’de sidebar linklerini içermiyor; JS ile DOM’a ekleniyor. Bot JS’i render edemiyorsa featured/ads linkleri hiç keşfedilmeyebilir. Bu durumda loglarda “ads URL’leri yok” görürsünüz; ama bu her zaman “sorun bitti” anlamına gelmez.

Yorumlama nasıl olmalı? Eğer hedefiniz crawl bütçesini korumaksa iki olasılık var: (1) Bot gerçekten keşfetmiyorsa tarama bütçesi korunuyor demektir. (2) Render edebilen bot (veya güncelleme sonrası render kapasitesi değişen bot) keşfederse sorun tekrar ortaya çıkabilir. O yüzden testleri hem non-render hem render benzeri koşullarda yapın ve kararlarınızı tek bir bot davranışına dayandırmayın.

Yaygın Hatalar (ve Kaçınılması Gerekenler)

Kaçınılması gereken hata 1: Sadece noindex uygulayıp linkleri kontrol etmemek. Bot yine keşfeder; crawl bütçesi tüketimi devam eder. Özellikle sidebar’da link sayısı yüksekse, noindex “indeks”i kapatır ama “keşif” maliyetini azaltmayabilir.

Kaçınılması gereken hata 2: SSR/prerender kapsamını sorgusuz genişletmek. Sidebar’ın HTML’e geçmesi featured/ads discovery’yi artırabilir. Prerender kullanıyorsanız featured/ads linklerini azaltma veya kullanıcı etkileşimi ile üretme gibi güvenlik bariyerlerini ekleyin.

Kaçınılması gereken hata 3: Parametre varyantlarını canonical ile normalize etmemek. UTM ve kampanya parametreleri URL’leri çoğaltır; sonuç “aynı kampanyanın farklı URL’leri” olur. Crawl bütçesi bu varyantlarda erir.

Nasıl Kontrol Edilir? Adım Adım Doğrulama (Kontrol Listesi)

Aşağıdaki “adım adım doğrulama” akışıyla room sidebar featured/ads crawl’ini güvenli biçimde ölçüp kontrol edebilirsiniz:

1. Bot Erişimi ve Render Durumu Testi Yapın: Oda sayfasının ilk HTML’inde sidebar linkleri var mı? Loglarda botun oda sayfası sonrası ads/featured endpoint’lerine istek atıp atmadığını inceleyin.
2. URL Setini Modül Bazında İzole Edin: Featured/ads için path veya query şablonları oluşturun. Botun en çok taradığı featured/ads URL örneklerini çıkarın (en az 50 örnek).
3. Link Mimarisi Değişikliği Uygulayın: Sidebar link sayısını threshold ile azaltın (örn. 20 → 6). Geri kalan kartları kullanıcı etkileşimiyle üretin veya SSR yerine client action ile açın.
4. İndeksleme Kontrollerini Uyumlayın: Featured/ads landing page’lerde noindex (meta veya X-Robots-Tag) + canonical normalize uygulayın. Parametre varyantlarını sadeleştirin.
5. Rollout Sonrası Doğrulayın: Loglarda modül bazlı istek sayısı ve keşif derinliği düşüyor mu? Search Console’da crawl/keşif sinyalleri oda ana içerik lehine toparlıyor mu kontrol edin.

Kontrol Sonrası Sonuçları Nasıl Yorumlamalıyım?

Ölçüm sonrası iki yaygın yanlış yorum vardır: (1) “Ads/featured URL’leri loglarda görünmüyorsa sorun yoktur” demek. Render kapasitesi değiştiğinde sorun geri gelebilir. (2) “noindex uyguladık, crawl bütçesi kurtuldu” demek. Crawl bütçesi keşif ve istek hacminden etkilenir; noindex sadece indeksleme tarafını yönetir.

Doğru yorum için modül bazlı kıyas yapın. Sidebar threshold düşürülürken botun oda ana içerik URL’lerinde tarama oranı artıyorsa bu iyi bir işaret. Aksi durumda keşif yine başka UI bileşenleri üzerinden genişliyordur: örneğin notification paneli, search suggestions veya “benzer oda” modülü gibi diğer dinamik alanlar aynı risk grubuna girmiş olabilir.

Sık Sorulan Sorular (FAQ)

Room sidebar linkleri nofollow olsa bile crawl bütçesi tüketir mi?

Evet, çoğu senaryoda tüketebilir. nofollow bağlantının PageRank akışını veya bazı discovery davranışlarını etkileyebilir; ancak crawler’ın URL’leri keşfetmesini tamamen ortadan kaldırmak garanti değildir. Crawl bütçesi için asıl belirleyici, botun link sayısı üzerinden keşfe gidecek olmasıdır. Bu yüzden nofollow tek başına yeterli değildir; link sayısını threshold ile azaltmak ve robots/noindex kombinasyonunu doğru kurmak gerekir.

Ads/featured içerikleri değişiyorsa canonical/noindex nasıl yönetilir?

Kampanya veya featured öğe değişse bile URL’nin formunu sabitlemeye çalışın. Noindex uygulayacaksanız içerik değişiminin canonical üzerinde karmaşıklaşmasına izin vermeyin. Eğer bazı sayfalar kontrollü indekslenecekse, canonical tekil kurala bağlanmalı ve varyantlar (UTM/parametre) sadeleştirilmelidir.

Bot client-side render yapmıyorsa, yine de sidebar URL’leri taranır mı?

Genellikle hayır ya da çok sınırlı olur; çünkü SSR olmayan sidebar linkleri ilk HTML’de görünmez. Ancak render edebilen botlar veya farklı tarayıcı davranışları varsa URL seti yine de değişebilir. Bu nedenle render durumu testini şart koşun ve kararlarınızı tek bir davranışa göre vermeyin.

Lazy-load/scroll ile üretilen linkleri nasıl ölçeriz (loglarda mı, render trace’te mi)?

Önce loglarda botun ads/featured endpoint’lerine istek atıp atmadığını görün. Eğer loglarda görünmüyorsa ama kullanıcı deneyimi “link üretildi” diyorsa, render trace veya DOM/console benzeri izleme ile link üretiminin koşullarını doğrulayın. En güvenlisi ikisini birlikte kullanmaktır: keşif mi olmuyor yoksa keşif oluyor da istek mi atılmıyor?

Search Console’da crawl bütçesi etkisini nasıl yorumlamalıyım; hangi raporlar yeterli?

Search Console doğrudan “crawl budget” metrikleri vermeyebilir; ama trend ve URL seti bazında sinyaller değerlidir. En doğrusu log analiziyle doğrulayıp ardından Search Console’daki kapsama/keşif eğilimleriyle ilişkilendirmektir. Yalnızca tek bir rapora bakmak yanıltıcı olabilir; modül bazlı URL örneklemesi şart.

Robots.txt ile modül bazlı kısıtlama mümkün mü, pratikte ne yapılıyor?

Mümkün; ama modül bazında kısıt için endpoint tasarımının bu kısıtı desteklemesi gerekir. Örneğin featured/ads landing page’leri ayrı path altında toplanıyorsa robots.txt ile kısıt uygulanabilir. Eğer her şey aynı oda sayfası içinde ve parametrelerle gidiyorsa, robots.txt tek başına zorlaşır; sayfa bazlı noindex / X-Robots-Tag ve link mimarisiyle ilerlemek daha pratik olur.

Sidebar’i kısıtlamak odanın ana içerik indeksini olumsuz etkiler mi?

Doğru kurgulanırsa genellikle hayır. Sidebar’i kısıtlamak “oda ana içeriğini” gömmemeli; oda ana içeriğine giden internal link mimarisi korunmalı. Kritik nokta: threshold ile sidebar linklerini azaltırken, oda içeriğini güçlendirecek başka sinyalleri (ör. ana içerik bağlantıları, stabil canonical) zedelememektir.

İlgili Konular (İç Bağlantılar)

Room sidebar crawl riskini yönetirken duplicate üretim ve indeks dalgalanması gibi yan etkileri de göz önünde bulundurmalısınız. Aşağıdaki rehberler, crawl bütçesini etkileyen diğer dinamikleri anlamanıza yardımcı olur:

Chat Sitesi Konu/Etiket Sayfalarında “Popüler” Sıralaması Değişince İndeks Dalgalanması Nasıl Azaltılır? (Model + Ölçüm Planı)

Login Wall Arkasındaki Chat Odası için Pre-render Cache İinvalidasyonu: Etiketli/Kimlik Tabanlı Varyant Stratejisi ve Kontrol Listesi

crawl bütçesini korumak için oda eşiği yaklaşımı

Kapanış: Featured/Ads Crawl’ini Kontrol Edip Bütçeyi Oda Ana İçeriğine Geri Taşıyın

Room sidebar bileşenleri (featured/ads) crawl bütçesini tüketebilir; çünkü link yoğunluğu ve değişim sıklığı keşif derinliğini artırır. Bu yüzden yaklaşımınız “noindex yapıldı bitti” değil; modül bazında URL setini ayırmak, render/lazy-load davranışını test etmek, link mimarlığını threshold ile daraltmak ve canonical/robots stratejilerini birlikte uygulamak olmalı.

Son adımda kontrol-değişiklik-doğrulama akışını mutlaka tamamlayın. Log + Search Console korelasyonu ile gerçek etkisini görün; ardından crawl bütçesini daha anlamlı olan oda ana içerik indeksine geri yönlendirdiğinizi kanıtlayın.