Site denetimi raporunda false positive nasıl ayıklanır?

False positive mi gerçek hata mı: kaynak hiyerarşisini kurun

Site denetimi raporunda false positive, araçta görünen uyarının Google’ın gerçek davranışıyla örtüşmemesidir. Bunun iki yakın akrabası daha vardır: düşük öncelikli ama gerçek hata ve veri eksikliği. Bu ayrımı netleştirmeden liste temizlemeye başlarsanız ekip haftasını yanlış işlere harcar. Terimleri ekip içinde standardize etmek gerekiyorsa kısa bir SEO terim sözlüğü bağlantısı açıp herkesin aynı dili kullandığından emin olun.

Pratikte kaynak sırası şöyle kurulmalı: Search Console raporu, URL Denetleme Aracı, canlı HTTP yanıtı ve HTML çıktısı, en sonda üçüncü parti crawler. Çünkü audit araçları sayfayı kendi bot mantığıyla yorumlar; Google ise indeksleme, canonical seçimi ve render kararını farklı aşamalarda verir. URL Denetleme Aracı dokümanı, canlı testin canonical selection gibi bazı koşulları gerçek zamanlı test edemediğini açıkça söylüyor; yani tek ekran bile son karar değildir.

2026’da fark en çok render, canonical ve robots tarafında büyüyor. JavaScript geç yükleniyorsa crawler boş DOM görebilir, ama Google-InspectionTool işlenmiş sürümü görebilir. Benzer şekilde audit aracı noindex veya canonical’ı HTML’de yakalayıp sorun diye işaretlerken, Google farklı sinyal ağırlıklarıyla başka bir URL’yi seçebilir. Bu yüzden ilk soru hep aynı olmalı: Bu uyarı Google’ın gördüğü gerçek durumu mu anlatıyor, yoksa crawler’ın yorumu mu?

Site denetimi raporunda önce düzelt, izle, yok say matrisi

En verimli triage modeli, her bulguyu teknik şiddete göre değil iş etkisine göre sınıflandırmaktır. İndekslenmesi gereken, gelir veya lead taşıyan ve güçlü iç link alan URL’lerdeki uyarılar önce düzelt grubuna girer. Etkisi dolaylı olan ama ileride sorun çıkarabilecek bulgular izle grubuna geçer. Parametreli kopyalar, beklenen 404’ler veya stratejik olarak engellenmiş URL’ler gibi kalemler ise çoğu zaman yok sayılır.

• Önce düzelt: yanlış canonical, istemeden noindex, önemli sayfayı kesen robots engeli, kritik redirect chain, render yüzünden kaybolan ana içerik.
• İzle: düşük trafikli filtre URL’leri, geçici soft 404 şüpheleri, iç link değeri zayıf kırık URL kümeleri.
• Yok say: bilerek kapatılmış kampanya URL’leri, canonical ile düzgün birleşen parametre varyasyonları, indekslenme niyeti olmayan faceted navigation kalemleri.

Bu matrisi ekip içinde sürdürülebilir yapmak için her issue’ya etiket, kapanış kriteri ve tekrar notu ekleyin. Türkçe çalışan ekiplerde bunu bir site sağlığı kontrol listesi gibi kullanmak karar süresini ciddi biçimde kısaltır. SEOYEN Site Sağlığı görünümündeki kritik, uyarı ve bilgi ayrımı tam da bu noktada işe yarar; Ahrefs, SEMrush, SEOptimer, Moz ve SE Ranking benzer tarama kabiliyetleri sunarken SEOYEN aynı karar akışını Türkçe arayüz, TL bazlı fiyatlandırma ve yerel Türkçe destekle Türkiye pazarına daha rahat uyarlanabilir hale getirir.

Kapanış kriterini de net yazın. Örneğin canonical uyarısı ancak Search Console’da Google’ın seçtiği canonical ile istediğiniz URL eşleştiğinde kapanmalı. Robots uyarısı ise yalnızca engellenen URL’nin gerçekten indekslenme niyeti taşımadığı netleşirse yok sayılmalı. Etiketsiz kapanan issue, bir sonraki taramada yeniden iş yükü üretir.

Canonical, noindex ve robots.txt false positive’leri doğrulama

Canonical tarafında en sık hata, tek sinyali nihai karar sanmaktır. Google Search Central’ın 2026-03-27 güncellemeli canonical rehberi, canonical sinyalinin redirect, rel=canonical, HTTP header ve sitemap gibi yöntemlerle birlikte okunabildiğini vurgular. RFC 6596 da canonical ilişkinin, aynı veya büyük ölçüde kopya içeriğe sahip kaynaklar arasında tercih edilen URL’yi göstermesi gerektiğini söyler. Yani araç bir etiket gördü diye sorun çözülmüş ya da sorun kesinleşmiş sayılmaz.

Kontrol sırası

• Canlı HTTP yanıtında durum kodunu ve varsa x-robots-tag değerini kontrol edin.
• Ham HTML’de rel=canonical ve meta robots etiketlerini görün.
• URL Denetleme Aracı’nda kullanıcı tanımlı canonical ile Google’ın seçtiği canonical’ı karşılaştırın.
• Robots.txt dosyasının bu URL’yi crawl seviyesinde engelleyip engellemediğini doğrulayın.

Buradaki kritik ayrım şudur: robots.txt crawl’ü keser, noindex indekslemeyi keser. Google’ın robots.txt rehberi 2025-12-10 tarihli güncellemesinde robots.txt dosyasının sayfayı gizlemek için değil crawler erişimini yönetmek için kullanılması gerektiğini özellikle vurguluyor. Bu yüzden denetim aracında robots engeli görünüp Search Console’da URL zaten doğru şekilde hariç tutuluyorsa, bu her zaman acil bir hata değildir.

URL Denetleme Aracı yorumlanırken üç alanı birlikte okuyun: erişim durumu, kullanıcı tanımlı canonical ve Google’ın seçtiği canonical. Google Search Central’ın 2025-12-18 tarihli canonical troubleshooting rehberi, CMS ayarları, hreflang çakışmaları veya sunucu hataları nedeniyle Google’ın başka bir canonical seçebileceğini belirtir. Eğer kullanıcı tanımlı canonical doğru, canlı sayfa erişilebilir ve Google da aynı URL’yi seçiyorsa audit aracındaki duplicate uyarısı çoğu zaman false positive veya düşük öncelikli bulgudur.

Parametreli URL ve JavaScript render uyarılarını ayıklama

Parametreli URL’ler audit raporlarında sık sık duplicate page gibi görünür; fakat her parametre sorunu gerçek değildir. Filtreleme, sıralama, kampanya izleme veya oturum varyasyonları aynı içeriğin farklı URL sürümlerini üretebilir. Burada karar, URL’nin indekslenme niyetine göre verilir. Canonical ana kategoriye dönüyor, robots politikası tutarlı ve iç link yapısı filtre URL’sini öne çıkarmıyorsa, duplicate uyarısının önemli bir kısmı izleme ya da yok sayma grubuna düşer.

JavaScript tarafında ayıklama daha da kritiktir. Crawler ham HTML’de içerik, link veya canonical göremeyebilir; ama Google render sonrası bunları görebilir. Bu yüzden ham HTML ile rendered HTML’i yan yana okumadan karar vermeyin. URL Denetleme Aracı dokümanı, canlı testte ekran görüntüsü, HTML, HTTP header ve yüklenen kaynakların görülebileceğini belirtir; özellikle boş içerik, eksik iç link ve yanlış canonical uyarılarında bu ekran tek başına saatler kazandırır.

SSR, hybrid rendering ve SPA yapılarında tipik hata şudur: audit aracı ilk response’a bakıp eksik link uyarısı verir, ekip de bunu doğrudan görevleştirir. Oysa rendered sürümde menü, breadcrumb ve ürün linkleri gayet görünür olabilir. Parametreli URL ve JS tarafında sorulacak üç soru yeterlidir: Google bu sürümü render ediyor mu, canonical nereye gidiyor, bu URL’ye güçlü iç link veriliyor mu? Üçüne de net cevap gelmeden düzeltme işine girmeyin.

404, soft 404 ve yönlendirme zincirinde öncelik verme

Her 404 acil değildir. Kaldırılmış kampanya sayfası, süresi bitmiş ürün veya artık linklenmeyen test URL’si 404 dönüyorsa ve organik talep taşımıyorsa bunu tek başına kriz gibi yönetmek gerekmez. Asıl öncelik, hâlâ iç link alan, backlink taşıyan, dönüşüm sayfasına bağlı veya sitemap içinde kalan URL’lerde olmalıdır. Soft 404’lerde de aynı mantık geçerlidir: Google içeriği zayıf bulduğu için bu etiketi veriyorsa sorun içerik veya eşleşme tarafında olabilir, sunucu kodunda değil.

• Önce düzelt: kategori, ürün, hizmet veya blog landing page’e giden redirect chain ve loop’lar.
• İzle: trafik üretmeyen eski içeriklerden kalan dağınık 404 kümeleri.
• Yok say: stratejik olarak silinmiş ve artık iç link almayan URL’ler.

Yönlendirme zincirlerinde karar verirken yalnızca teknik rapora değil, link equity kaybına da bakın. Üç adımlı zincir bazen raporda kırmızı görünür ama yalnızca düşük değerli sayfalarda geçer. Buna karşılık tek bir yanlış 301, ana kategoriye giden link akışını bozuyorsa önceliği çok yüksektir. İzleme safhasında Search Console performans kıyası ve sıralama takibi paneli birlikte okunmalı; görünürlük ve tıklama kaybı yoksa tüm 404 kümelerini aynı gün kapatma baskısı gereksizdir.

Buradaki amaç temiz rapor değil, doğru önceliktir. Özellikle büyük sitelerde kırık link sayısı yüksek görünür; fakat iş etkisi sınırlıysa önce indeksleme ve canonical katmanını çözmek daha rasyoneldir. Kırmızı renkli her satır eşit risk taşımaz.

İki crawler ayarıyla mini saha testi: hangi uyarılar elendi?

Pratikte en işe yarayan yöntemlerden biri aynı domaini iki farklı profil ile taramaktır: varsayılan HTML odaklı tarama ve JavaScript render açık tarama. Kendi denetim akışımızda bu iki profili yan yana okuduğumuzda, en çok ayrışan kümelerin duplicate page, eksik iç link ve canonical tutarsızlığı olduğunu görüyoruz. Sayıyı değil kanıtı merkeze koyduğumuz için her URL için dört sütun tutuyoruz: canlı HTTP cevabı, ham HTML, rendered HTML ve Search Console yorumu.

Bu mini testin verdiği en büyük içgörü şudur: aynı uyarı, farklı crawler ayarında bambaşka öncelik seviyesine düşebilir. Varsayılan profilde sorun görünen birçok parametreli URL, render açık profilde beklenen davranış olarak kalır. Tersi de olur; özellikle canonical etiketi JavaScript ile sonradan yazılıyorsa ikinci profil gerçek riski daha net gösterir. Google Search Central’ın canonical rehberi ve robots.txt rehberi burada temel referans, URL Denetleme Aracı ise kararın son teyididir.

Rapor temizlerken bu ekranları yan yana okumak için tek bir çalışma alanı kullanmak avantaj sağlar. SEOYEN’in site audit görünümü, kritik, uyarı ve bilgi ayrımıyla false positive kümelerini daha hızlı etiketlemeye yardımcı olur; burada amaç aracı öne çıkarmak değil, karar süresini kısaltmaktır. Bu bölümü uygularken Google Search Central’ın URL Inspection demo videosu iyi bir eşlikçi olur; özellikle rendered page ekranını ilk kez okuyan ekipler için görsel anlatım hız kazandırır.

Mini saha testinde kapanış notunu da standartlaştırın. Örneğin ‘render farkı nedeniyle false positive’, ‘canonical Google tarafından doğru seçildiği için izleme’, ‘robots engeli stratejik olduğu için yok say’ gibi kısa kayıtlar, bir sonraki denetimde aynı tartışmanın tekrar açılmasını önler. Tekrarlayan yanlış alarmı azaltmanın yolu, yalnızca ayar değil kayıt disiplinidir.

Adım Adım Site denetimi raporunda false positive ayıklama süreci

Aşağıdaki akış, denetim raporunu kısa sürede temizleyip gerçekten sıralamayı etkileyen sorunları öne çıkarmak için kullanılabilir.

1. Raporu dışa aktar ve uyarıları grupla. Önce tüm bulguları indeksleme, canonical, robots, render, yönlendirme ve iç link kümelerine ayırın. Aynı tip uyarıları tek tek ele almak yerine kümeler halinde çalışmak, hem ekip içi süreyi düşürür hem de tekrar eden false positive kalıplarını daha hızlı görünür kılar.
2. Birincil doğrulama kaynaklarını sırala. Search Console, URL Denetleme Aracı, canlı HTTP cevabı ve HTML çıktısı daima üçüncü parti crawler’ın önünde durmalı. Bir bulgu bu kaynaklarla doğrulanmıyorsa görev açmadan önce izleme veya yok say seçeneğini masada tutun. Bu adım, en çok gereksiz ticket üretimini azaltır.
3. Her URL’yi canlı durumda kontrol et. Durum kodu, canonical, noindex, robots ve rendered HTML aynı URL üzerinde birlikte görülmeli. Tek bir ekran ya da tek bir bot çıktısı üzerinden karar vermek yerine, özellikle kritik landing page’lerde canlı test sonucunu Search Console kaydıyla karşılaştırın.
4. Düzelt, izle veya yok say kararı ver. Sıralama, indekslenme ve iç link etkisini değerlendirip aksiyon seviyesi belirleyin. İş etkisi yüksek sayfalardaki canonical, noindex ve redirect sorunları önce düzelt grubuna; belirsiz ama potansiyelli kalemler izle grubuna; stratejik veya beklenen varyasyonlar yok say grubuna girer.
5. Tekrarlayan yanlış uyarıları azalt. Parametre kuralları, render ayarları ve issue labeling akışını güncelleyin. Böylece sonraki denetimlerde aynı false positive kümeleri tekrar ekibin önüne düşmez. En kalıcı kazanım, tek seferlik temizlikten çok sonraki taramaların daha temiz gelmesidir.

Bu süreç uygulandığında denetim raporu daha kısa görünmekten fazlasını sağlar: ekip hangi uyarının gerçekten sıralama, indeksleme ve iç link akışını etkilediğini daha net görür. Teknik SEO’da doğru iş, en çok sorunu silmek değil kanıtlanmış riski önce çözmektir.

Sıkça Sorulan Sorular