Chat Sitelerinde Offset Tabanlı Sayfa Üretiminde Crawl Döngülerini Server Log’dan Tespit Etme Rehberi

Chat sitelerinde “indekslenebilirlik” hedefiyle sayfa üretimi yaparken, “pagination yok ama yine de sayfa dolaşımı var” senaryosu oldukça sık karşımıza çıkıyor. Özellikle offset tabanlı URL parametreleri (ör. ?offset=0&limit=20) üzerinden yeni mesaj/sayfa varyantları üretiliyorsa, tarama döngüsü pagination olmadığı halde yine de oluşabiliyor. Bu rehberde chat sitesi sayfa üretiminde (pagination yerine offset) tarama döngülerini logdan tespit etme odağında, loglardan kanıt üretip bunu aksiyona nasıl dönüştürebileceğinizi adım adım ele alacağım.

Buradaki hedef, sadece “genel indekslenebilirlik” anlatmak değil. Server log üzerinden döngü davranışını ölçmek, hangi işaretlerin crawl israfı yarattığını yakalamak ve doğru aksiyon setini (rate limit, canonical/noindex, crawl budget, offset guardrail) kararlı biçimde hayata geçirmek. Offset/pagination benzeri parametrelerle ardışık isteklerin nasıl döngüye dönüştüğünü; bot/insan ayrımını ve chat oda/sonuç sayfası türlerinin etkisini de pratik örneklerle birlikte göreceğiz.

1) Problem Tanımı: Pagination Yoksa Offset ile Crawl İ israfı Nasıl Oluşur?

Pagination’ın olmadığı bir chat deneyiminde kullanıcılar genellikle “daha fazla mesaj” veya sonsuz liste mantığıyla ilerler. Uygulama tarafı bu veriyi üretirken çoğu zaman offset/limit ya da cursor gibi parametreleri kullanır. Tarayıcı/robot bu parametreleri fark ettiğinde, her istekte yeni bir sayfa varyantı üretmiş olursunuz. Pagination yoksa bile sonuç URL’leri ardışık offsetlerle genişleyebilir; bu da crawl davranışının zamanla bir döngüye evrilmesine yol açar.

Bu noktada kritik bir fark var: Offset tabanlı sayfa üretimi, içeriğin “aynı sayfanın farklı dilimleri” olduğunu varsayabilir; ancak arama motoru açısından her offset değeri ayrı bir URL/çeşit gibi görünür. Sonuç olarak crawl budget israf olur, yanlış indekslenebilir sayfalar çoğalır ve hatta bazı durumlarda çoğu kez hata kodlarıyla (404/410 gibi) dönen boş/erişim kısıtlı sayfaların da taranması gündeme gelir.

2) Loglarda Aranacak URL Parametreleri ve Normalizasyon

Log analizi yaparken ilk adım, offset tabanlı üretim yapan URL desenlerini netleştirmektir. Chat sitelerinde bu yaklaşım çoğu zaman farklı isimlerle görünür: offset, skip, start, page, cursor, continue veya seq. Bu parametrelerin URL’de nasıl yer aldığını ve hangi sayfa türünü etkilediğini tek tek haritalamanız gerekir.

İkinci adım “normalizasyon”dur. Aynı bot döngüsü göstergesi çıkarabilmek için parametre varyantlarını tek biçime indirgeriz. Örneğin offset=0 yerine offset=00 veya offset=0&limit=20 ile limit hiç görünmeden gelen varsayılan değerlerin aynı kabul edilmesi gerekir. Aksi halde döngü işaretleri parçalanır ve yanlış negatif görürsünüz.

• Parametre setini çıkarın: offset/limit (veya skip/start), cursor/continue, page/pageSize, sort/dir gibi yardımcı parametreler.
• Varsayılanları normalize edin: limit yoksa “varsayılan limit” değerini logdan/konfigürasyondan çıkarıp birlikte hesaplayın.
• URL canonicalization mantığı kurun: trailing slash, URL encoded parametreler, büyük-küçük harf farklarını tek forma getirin.
• Sayfa türü etiketleyin: oda sayfası, canlı (live) akış, arşiv (archive), arama sonuçları, üye/etiket sayfaları gibi ayrımları çıkarın.

3) Tarama Döngüsü İşaretleri: Ardışık Offset Serileri ve Başarısız Tekrar

Crawl döngüsünü “rastgele çok istek”ten ayıran şey, davranış düzenidir. Offset tabanlı sayfa üretiminde döngü çoğu zaman şu örüntülerle kendini belli eder: Aynı bot aynı URI şablonuna sabit aralıklarla farklı offset değerleri gönderir; her offset yeni bir sayfa varyantı oluşturur ve bot “durmaz”. Bunun yanında yanıtlar çoğu kez başarıya değil, hata ya da boş içerik varyantlarına kayar.

Aşağıdaki göstergeler döngü teşhisinde en temel sinyallerdir. Özellikle chat sitelerinde oda/akış sayfası canlıyken “sonsuz akış” hissi veren bir davranış ortaya çıkabildiğinden, botun sürekli ileri dilimlere gitmesi crawl israfının net kanıtı olabilir.

• Ardışık offset yoğunluğu: 0, 20, 40, 60… gibi artışların belli bir adım ile tekrarlanması.
• Aynı sayfa yerine sürekli yeni sayfa üretimi: her offset farklı “sayfa varyantı” ve her biri indekslenebilir yanıt döndürüyor olabilir.
• Başarısızlık oranı: 200 yerine 404/410/403 gibi kodların ağırlıklı olması (özellikle “mevcut değil” offsetlerde).
• Düşük tekrar/başarısızlık farkı: Aynı offsetleri tekrar taramak yerine ileri offsetlere kaymak; “dizinleme keşfi” gibi görünse bile aslında bir döngüdür.
• Derinlik artışı: botun aynı oda/arama bağlamında arama derinliğini sürdürmesi (ortalama “offset maksimum” değerinin sürekli yükselmesi).

4) Analiz Mimarisi: Log Veri Kaynakları, Zaman Penceresi ve Bot/İnsan Ayrımı

Analiz mimarisini kurarken önce hangi loglara eriştiğinizi netleştirmeniz gerekir. Minimum set genellikle şu alanları içerir: zaman damgası (timestamp), istemci IP, User-Agent, istek yöntemi (method), istenen URL ve query string, yanıt kodu (status), yanıt süresi (response time/latency), bytes sent ve request_id/trace_id varsa hata ayıklama için. Referer varsa yönlendirme analizi için ayrıca değerlidir.

Zaman penceresi seçimi de kritik. Offset döngüsü bazen birkaç saat içinde “tam döngü” şeklinde görünür; ama bazı botlar daha seyrek çalışır. Bu yüzden kısa pencerelerde kaçırma riski artar. Genellikle 7 gün + günlük segment yaklaşımı veya en az 24-48 saatlik pencerelerle “haftalık/çalışma günü” dalgalanmaları kontrol edilmelidir.

Bot/insan ayrımı tek bir kuralla değil, kümeli bir yaklaşımla yapılmalıdır: IP reputation/ASN, User-Agent sınıflandırması, hız (RPS), davranış (offset adımı düzeni), cookie varlığı (varsa), oturum/istek sıklığı. Log erişiminiz varsa CDN/WAF katmanından “edge log” ile uygulama logunu birleştirmek, gerçek bot davranışını daha net görmenizi sağlar.

5) Metik Seti: Döngü Uzunluğu, Sıralı Offset Yoğunluğu, İsraf Oranı

Aşağıda döngüyü ölçmek için kullanabileceğiniz pratik metrikleri öneriyorum. “İndekslenebilirlik bozuldu” gibi nitel yargılar yerine, logdan sayısallaştırılmış ölçümlerle ilerlemek aksiyon kararını ciddi şekilde güçlendirir.

Metrik	Nasıl Hesaplanır?	Yorum
Döngü uzunluğu (Loop length)	Bot/IP+UA+oda bağlamında benzersiz offset sayısı veya offset maksimum-minimum farkına göre “adım sayısı”	Yüksek değer = “tarama döngüsü” olasılığı artar
Sıralı offset yoğunluğu (Sequential density)	Ardışık isteklerde offset farkının beklenen adım (örn. 20) ile uyum oranı	0-20-40… düzen = döngü kanıtı
İsraf oranı (Waste rate)	200/304 dışındaki yanıtların (404/410/403) toplam istek içindeki payı + “boş içerik” durumları (varsa özel kodlar)	Yüksek oran = yanlış/korumalı offsetlerin tarandığını gösterir
Ortalama tarama derinliği	Belirli bir oda/arama bağlamında ulaşılan ortalama offset maksimum değeri	Derinlik artışı = crawl budget israfı riski

Ek olarak yanıt kodu dağılımı, ortalama yanıt süresi ve “tekil sayfa sayısı / toplam istek” oranı da değerlidir. Döngülerde genellikle tekil URL sayısı artar; fakat aynı anda hata kodları da yükselir. Bu iki sinyal birlikte ele alındığında çok daha güçlü kanıt oluşur.

6) Örnek Log Sorguları ve Araçlar (NGINX/Apache Düz Format, ELK/Loki/BigQuery)

NGINX/Apache düz log biçimlerinde genellikle şu alanlar bulunur: %h (IP), %u (user), %t (time), %r (request line), %s (status), %b (bytes). Query string’i yakalamak ve offset/limit değerlerini çıkarmak için bir parse adımı gerekir. Bu parse adımı (regex/Grok/SQL UDF) olmadan döngü metriklerini güvenle hesaplamak oldukça zorlaşır.

Şu mantıkla sorgu kurun: önce oda/endpoint’i soyutlayın (path + sabit query parametreleri), sonra offset parametresini sayısal olarak çıkarın ve bot/IP+UA+bağlamında offset sırasını üretin. ELK için Kibana/ES query + runtime fields; Loki için LogQL; BigQuery için REGEXP_EXTRACT ve window functions ile döngü metrikleri üretilebilir.

1. URL şablonunu normalize edin: aynı endpoint’in parametre varyantlarını tek “template” olarak etiketleyin (örn. /chat/room + roomId).
2. Offset’i numeric extract edin: offset yoksa “NULL” olarak bırakın; böylece cursor tabanlı döngüleri offset döngüsünden ayırırsınız.
3. Bot/IP+UA+oda bazında sıralayın: timestamp’e göre sıralayın, bir sonraki offset ile farkı (delta) hesaplayın.
4. Loop metriklerini üretin: benzersiz offset sayısı, ardışık delta eşleşme oranı, 4xx/5xx oranı.

7) User-Agent / IP / ASN Kümeleri ile “Aynı Botun Tarama Döngüsü” Kanıtı

Tek bir IP’den gelen ardışık offset istekleri döngüye işaret edebilir; ancak daha güçlü kanıt “aynı botun aynı şablonda farklı IP/ASN kümeleriyle devam etmesi” ya da tersine “farklı IP’lerin aynı agent ile offset taraması yapması” şeklinde görünür. Buradaki amaç botnet mi var, yoksa CDN’in farklı egress IP’leri botu bölüyor mu gibi ayrımları ayırt edebilmek.

Logdan agent sınıflandırması yapın: User-Agent metnini normalize edip (versiyonları kırpma), bilinen crawler listeleriyle eşleştirin. Ardından aynı agentin belirli bir oda/endpoint üzerinde offset adımı düzenini sürdürebildiğini gösterin. Bu “kanıt” aksiyon alırken (rate limit/crawl budget) hem teknik hem operasyonel ekipleri ikna etmeye yardımcı olur.

Örnek: Farklı IP’lerin aynı agent ile offset taraması yapması (botnet vs CDN IP havuzu ayrımı için ipuçları). Örneğin 20 adımlık bir seri hem 203.x hem 198.x bloklarından aynı UA ile geliyorsa, bu “tek bot davranışı” kanıtı olabilir. Eğer aynı IP aralığında offset davranışı hiç görünmüyorsa, CDN varyansı veya farklı istemci türlerini eleyebilmek gerekir.

8) Chat/Oda Sayfa Türlerine Göre Ayırım: Live vs Archive, Durum Parametreleri, Auth/Noindex

Offset tabanlı döngüler her chat sayfasında aynı şiddette görünmez. Live (anlık sohbet) ve archive (arşiv mesajlar) sayfaları farklı erişim kuralları, farklı cache stratejileri ve farklı canonical/noindex kararları gerektirir. Live akış genellikle daha dinamik olduğu için, offset taraması canlıyken daha agresif görünebilir; archive ise daha “stabil” sayıldığından crawl performansı ve içerik tekrarları değişir.

Bu yüzden log analizinde endpoint’i ve sayfa türünü birlikte etiketleyin. Örneğin oda geçmişi için “archive endpoint’i” üzerinde döngü tespit ediyorsanız aksiyon önceliği değişebilir. Ayrıca auth gerektiren veya “yetkisiz görünüm” döndüren sayfalarda 403/404 oranları yükselir; bu da döngünün indekslenebilir içerik yerine korumalı varyantları taradığına işaret edebilir.

Örnek: Live/archive canonical farklılığının döngüyü artırıp azaltması (logdan kanıt). Eğer live sayfasında canonical archive’a işaret ediyor ama bot yine de live offset parametreleriyle farklı dilimleri çekiyorsa, live endpoint’inde tarama döngüsü artabilir. Archive endpoint’inde canonical netleşince istek hacmi düşebilir. Bu değişimi logda delta ve loop length metrikleriyle doğrulayabilirsiniz.

9) Senaryolar: Döngüyü Netleştiren Uç Örnekler

Döngüyü anlatan soyut metriklerin yanında, belirli örüntülerin logdan nasıl okunacağını görmek çok daha hızlı teşhis sağlar. Aşağıdaki örnekler, brief’in işaret ettiği kanıt tiplerini karşılar.

Örnek 1 (ardışık offset): Aynı botun 0, 20, 40, 60… offset istekleriyle sayfa üretmesini tespit eden senaryo. Logda aynı UA+oda şablonunda offset adım farkı %80+ uyumlulukla sabitse, bu “sistematik sayfa taraması”dır. Pagination yok olsa bile döngü mantığı çalışıyordur.

Örnek 2 (200 yerine 404/410): 200 yerine çoğunlukla 404/410 dönen offset taraması. Bu, yanlış indekslenebilir sayfa üretimi göstergesi olabilir. Yanıt kodu dağılımında 404/410 payı yüksek ve döngü uzunluğu artıyorsa, botun aslında “olmayan dilimleri” denediği anlaşılır. Bu durum yanlış yönlendirme/guardrail eksikliği veya indekslenmemesi gereken varyantların erişilebilir olmasıyla ilişkili olabilir.

Örnek 3 (aynı agent + farklı IP): Farklı IP’lerin aynı agent ile offset taraması yapması (botnet vs CDN IP havuzu ayrımı için ipuçları). Burada ASN kümeleri ve request hızları kritik olur. Tek ASN içinden geliyorsa genelde CDN/egress; farklı ASN’ler genişliyorsa otomasyon şüphesi artar.

Örnek 4 (canonical etkisi): Live/archive canonical farklılığının döngüyü artırıp azaltması (logdan kanıt). canonical değişikliği sonrası live endpoint loop length düşüyor; archive endpoint yoğunlaşıyorsa doğru yöne yönlendirme gerçekleşmiş olabilir. Aksi halde canonical “etiket” olarak kalır ve tarama sürer. Bu değişimi metriklerle doğrulayın.

10) Yaygın Hatalar ve Beklenen Hatalar: Neyi Yanlış Ölçersiniz?

Offset döngüsü teşhisinde sık yapılan hatalar genellikle “döngüyü sayfa sayımı sanmak” ve “offset’i normalize etmeden metrik üretmek” ile ilgilidir. Örneğin offset parametresi hem ?offset=0 hem ?offset=0&limit=20 hem de limit varsayımıyla geldiğinde normalizasyon yapılmazsa, aynı döngü farklı fragmentlere ayrılır. Bu durumda sıralı offset yoğunluğu olduğundan düşük görünebilir.

Bir diğer yaygın hata, sadece 200/404 oranına bakıp kararı tek başına oraya bağlamaktır. Bot bazen gerçekten keşif yaparken bir süre 404/410 denemeleri yapabilir; fakat döngü uzunluğu ve ardışık delta düzeni yoksa bu “kısmi deneme” olabilir. Ayrıca User-Agent ile bot tespiti tek başına yeterli değildir: bazı yük dengeleme katmanları UA’yı değiştirebilir ya da insanlar benzer hızlarda istek üretebilir. Bu nedenle metrik setini birlikte değerlendirin.

• Hata: offset adımını yanlış beklemek (limit farklıysa beklenen offset farkı da değişir).
• Hata: oda bağlamını doğru eşleştirmemek (aynı template farklı roomId’lerle birleşirse döngü yanlış görülebilir).
• Hata: CDN edge log ile origin logu karıştırmak (aynı isteğin iki kez sayılması veya gecikme kaynaklı sıralama bozulması).

11) Aksiyon Rehberi: Bulguya Göre Hangi Müdahale?

Logdan kanıt ürettikten sonra aksiyonların “hangi bulguya hangi müdahale” ile eşleşmesi net olmalıdır. Aksi halde yanlış bir müdahale crawl israfını azaltmaz; hatta yanlışlıkla gerçek kullanıcı akışını bozabilir. Aşağıdaki karar akışını bir kontrol listesi gibi düşünün.

Kontrol listesi (adım adım doğrulama):

1. Doğrulama 1: Döngü metriklerini (loop length, sequential density, waste rate) aynı oda ve aynı UA/IP grupları için “önce” penceresinde kaydedin.
2. Doğrulama 2: Aksiyon adayını belirleyin: örn. offset varyantlarını erişilebilirlikten ayırma, rate limit, noindex/canonical kombinasyonu, robots kuralı veya cache/prerender ile indekslenebilir stabil sayfa oluşturma.
3. Doğrulama 3: Aksiyondan sonra 24-72 saat içinde loop length düşüyor mu, sequential density bozuluyor mu ve waste rate azalıyor mu kontrol edin.

• Bulgu: ardışık offset serileri + uzun loop → rate limit/guardrail: belirli offset aralıklarından sonra 429 veya daha az “varyant” döndürün.
• Bulgu: 404/410 ağırlığı → yanlış/korumalı varyantların crawl edilebilirliğini azaltın: noindex + canonical + gerekirse erişim kuralı (auth duvarı) ile koruyun.
• Bulgu: live/archive canonical davranışı döngüyü artırıyor → canonical yönlendirmesini sayfa türü bazında teyit edin. live endpoint’te indeks sinyallerini (noindex) veya varyantı stabilize edin.
• Bulgu: bot farklı IP’lerle aynı agent + sürekli keşif → bot kategorisine göre WAF/CDN seviyesinde kural uygulayın. Aynı UA için offset parametrelerine davranış bazlı limit koyun.
• Bulgu: döngü sadece belirli sayfa tiplerinde → chat/oda türlerine göre varyant üretimini sınırlandırın (ör. yalnızca archive için stable URL üretimi).

Önemli: noindex/canonical her zaman döngüyü “hemen durdurmaz”. Arama motoru keşfi sürdürür. Bu yüzden aksiyon sonrası log’da metriklerin nasıl değişmesi gerektiğini önceden tanımlayın: döngü uzunluğu azalmalı veya sequential density bozulmalı; waste rate düşmeli; hedeflenen endpoint dışındaki varyantlara yönelim artmamalı.

12) Doğrulama: Aksiyon Sonrası Log’ta Metrikler Nasıl Değişmeli?

Doğrulama, yalnızca “404 azaldı” gibi tek ölçüme indirgenmemelidir. Döngü tarifinin logta yaşayan karşılığını gözlemlemelisiniz. Örneğin sequential density yüksek bir seri kurulduysa, aksiyon sonrası bu adım düzeni zayıflamalı ya da bot daha erken durmalı.

Önerilen doğrulama metrikleri şunlardır: loop length (düşmeli), sequential density (düşmeli ya da düzensizleşmeli), waste rate (azalmaya meyilli), toplam istek sayısı (oda/endpoint bazında düşmeli), benzersiz offset sayısı (düşmeli). Eğer aksine bir değişim görüyorsanız, aksiyonun sadece “içerik sinyali” olduğunu ve botun erişilebilirliği hâlâ korunduğunu düşünebilirsiniz.

Örneğin “canonical/noindex uyguladım ama tarama döngüsü devam ediyor—neden?” sorusunda sık görülen sebep şudur: bot URL keşfini sürdürür. canonical yalnızca indekslemeyi yönlendirir; tarama davranışını her zaman otomatik olarak kısmaz. Bu durumda rate limit veya offset guardrail gibi crawl davranışını etkileyen önlemlerle tamamlamak gerekebilir.

13) Nasıl Kontrol Edilir? Pratik Kontrol Adımları (Kısa Kontrol Listesi)

Bu bölümde “nasıl kontrol edilir” sorusuna doğrudan uygulanabilir bir akış bırakıyorum. Hedef, teknik ekip için 1-2 gün içinde ilk teşhisi koymak ve kanıtı üretmek.

1. URL şablonlarını tanımlayın: offset parametresi geçen endpoint’leri ve chat/oda türlerini ayırın.
2. Logdan agent + oda bağlamını çıkarın: UA/IP ve oda/arama bağlamı eşleştirmesi yapın, normalize edin.
3. Offset seri analizi uygulayın: ardışık offset delta dağılımını ve sequential density’yi hesaplayın.
4. Yanıt kodu ve israf oranını ölçün: 200 dışı pay + (varsa) boş içerik/korumalı varyant sinyali.
5. Ön/son karşılaştırma yapın: aksiyon sonrası loop length ve waste rate düşüşünü beklenen pencerede doğrulayın.

Bu kontrol planını uyguladıktan sonra, aksiyon karar ağacını devreye alabilir ve “offset kapatma/guardrails” gibi daha sert müdahalelerin gerekip gerekmediğini kanıtla karar verebilirsiniz.

14) İlgili Okumalar (Aksiyonla bağlantılı konular)

Offset döngüsü teşhisinden çıkan aksiyonlar çoğu zaman indekslenebilirlik/kanoniklik ve sayfa varyant yönetimiyle birleşir. Aşağıdaki rehberler, logdan gördüğünüz davranışı davranışsal (crawl) ve indeksleme sinyalleri (canonical/noindex) tarafından tamamlamaya yardımcı olur:

• Live vs Archive canonical davranışının crawl üzerindeki etkisi
• Dinamik chat oda sayfalarında noindex geçici mi kalıcı mı? Google’ın yeniden tarama davranışı
• Chat odası boşken 0 mesaj: noindex / 410 / crawl karar rehberi
• Sponsor/featured bloklar crawl ediliyor mu? Sayfa bölümü bazlı robots kurgusu

15) Sık Sorulan Sorular (FAQ): Offset Döngüleri ve Log Analizi

Offset tabanlı URL’lerde hangi parametreler log analizinde kritik?
Offset/limit (ya da skip/start + pageSize), cursor/continue ve sıralama/sort gibi deterministik değişkenler kritiktir. Ayrıca sayfa türünü belirleyen sabit path parçaları ve oda/arama kimliği gibi bağlam anahtarları olmadan döngü metrikleri bozulur.

Döngü taraması bot mu insan mı nasıl ayırt edilir?
En güçlü ayırt edici sinyal “offset adımı düzeni”dir: 0,20,40… gibi sıralı tarama genelde otomasyondur. Buna hız (kısa aralık), düzenli UA ve/veya aynı oda bağlamında sürekli derinleşme eklendiğinde bot olasılığı belirgin biçimde artar.

Crawl israfı metrikleri için hangi eşikler kullanılmalı (ör. offset adımı, süre)?
Tek bir evrensel eşik yok; ancak pratik başlangıçlar şunlar olabilir: sequential density %60-70+ ve loop length 10+ gibi. Waste rate (200 dışı) yüksekse (ör. %40+) ve eş zaman penceresinde artıyorsa israf riski büyüktür.

Canonical/noindex uyguladım ama tarama döngüsü devam ediyor—neden?
Canonical/noindex genellikle indekslemeyi etkiler, taramayı her zaman durdurmaz. Log’da tarama devam ediyorsa bot keşif davranışını sürdürüyordur; rate limit/guardrail veya erişilebilirlik kısıtlarıyla davranışı da etkilemeniz gerekir.

Archive/live davranışı offset taramasını nasıl etkiler?
Archive çoğu zaman daha stabil olduğundan tarama daha “tamamlayıcı” görünür; live ise daha değişken olduğundan bot daha erken sapabilir veya daha agresif deneme yapabilir. Logdan live ve archive endpointlerini ayrı ölçün.

Log’ta eksik alanlar varsa (referrer, request_id) analizi nasıl tamamlarız?
Referrer yoksa yönlendirme analizi yapamayabilirsiniz; ancak offset seri, UA/IP ve endpoint bağlamı yine döngü kanıtı üretir. request_id yoksa da kronolojik sıralama ve request fingerprint (method+path+param normalize) ile bot davranışı izlenebilir.

Aksiyon olarak rate limit mi canonical mi noindex mi? Karar ağacı nasıl kurulur?
Önce bulguyu sınıflayın: (1) Tarama davranışı düzenli ve uzunsa rate limit/guardrail, (2) Hata kodları yüksek ve varyantlar “olmaması gereken” içerikse noindex + canonical + erişim kuralı, (3) Live/archive yönlendirmesi karışık ise canonical/noindex stratejisi ve endpoint bazlı davranış düzeltmesi. Ardından aksiyon sonrası metriklerde beklenen düşüşleri doğrulayın.