Bir sayfanın Google indeksinden kaybolması otomatik olarak penalty anlamına gelmez. Aynı şekilde bu durum tek başına platform geneline yayılmış doğrulanmış bir olayın kanıtı da değildir. Daha güvenli başlangıç sırası şudur: kaybı Search Console’da doğrulayın, teknik nedenleri izole edin, canonical ve overlap sinyallerini inceleyin, sonra URL için fix, merge, noindex, retire veya bırak kararını verin.

Bu yazıda ne öğreneceksiniz

  • Bir URL’nin gerçekten Google indeksinden çıkıp çıkmadığını nasıl doğrulayacağınızı.
  • Indexing kaybını sıradan ranking düşüşünden nasıl ayıracağınızı.
  • İçerik silmeden veya yeniden yazmadan önce hangi teknik kontrollerin yapılması gerektiğini.
  • Bir URL için fix, merge, noindex, retire veya bırak kararının nasıl verileceğini.

“Deindexed” ne demektir, ne demek değildir?

Bir URL daha önce indexed durumdayken artık Google indeksinde görünmüyorsa bu bir indexing diagnosis problemidir. Bu durum otomatik olarak manual action, sitewide penalty veya doğrulanmış bir Google geneli olay anlamına gelmez.

Aynı zamanda URL’nin hemen silinmesi gerektiği anlamına da gelmez. Bazı sayfalar teknik olarak bloklanır, bazıları başka canonical hedefe kayar, bazıları zayıf veya örtüşen yapıya sahiptir, bazıları ise zaten geri zorlanmaya değmez.

Önce kaybı Search Console’da doğrulayın

Template değiştirmeden, sayfa silmeden veya toplu request indexing denemeden önce Search Console’a bakın.

Page indexing report

URL’nin `Crawled – currently not indexed`, `Discovered – currently not indexed`, `Excluded by noindex`, `Blocked by robots.txt`, `Duplicate` veya `Soft 404` gibi bir duruma taşınıp taşınmadığını kontrol edin.

URL Inspection

Özel olarak ilgili URL için URL Inspection kullanın. Google’ın URL’yi crawl edip edemediğini, farklı bir canonical seçip seçmediğini ve incelenen URL’nin gerçekten indexable olup olmadığını doğrulayın.

Indexing düşüşünü ranking düşüşünden ayırın

Ranking düşüşü ile indexing kaybı aynı olay değildir.

  • URL hâlâ indexed ise ama görünürlük kaybettiyse ana sorun bu flowchart’ın konusu değildir.
  • URL artık indexed değilse neden çıktığını veya neden tutulmadığını teşhis etmeniz gerekir.

Bu ayrım önemlidir çünkü indexed sayfalar için kullanılan ranking düzeltmeleri, indeksten çıkan sayfalar için kullanılan teşhis sırasıyla aynı değildir.

Teşhis flowchart’ı

Aşağıdaki akışı sırayla kullanın. Amaç tek sebebi tahmin etmek değildir. Amaç, en somut açıklamaları önce elemek veya doğrulamaktır.

Flowchart adımı Soru Evetse Hayırsa
Başlangıç URL daha önce indexed idi ve şimdi kayıp mı? Search Console doğrulamasına geçin Önce bunu hiç indexed olmama veya non-indexing sorunu olarak ele alın
Doğrulama Search Console URL’yi kayıp veya excluded gösteriyor mu? Teşhis dallarına geçin Sorunun aslında ranking düşüşü olup olmadığını kontrol edin
Dal 1 Manual Action, Security Issue veya policy problemi var mı? Önce bunu çözün Devam edin
Dal 2 URL noindex, robots.txt, redirect, canonical veya soft 404 sinyalleriyle bloklanıyor mu? Teknik kısıtı önce düzeltin Devam edin
Dal 3 Google başka canonical seçiyor mu veya sayfayı duplicate ya da overlap olarak mı görüyor? Sayfanın rolünü netleştirin veya birleştirin Devam edin
Dal 4 Sayfa zayıf, thin, eski veya çok benzer mi? Değere göre iyileştirin, birleştirin veya emekli edin Devam edin
Dal 5 Crawl yolu, sitemap sinyali veya internal link desteği zayıf mı? Discovery ve destek sinyallerini iyileştirin URL’nin tutulmaya değip değmediğine karar verin

Flowchart’ı uyguladınız ve hâlâ sayfa kaybediyor musunuz? Herhangi bir şeyi silmeden önce gerçek crawl ve index veriniz üzerinden teknik teşhis alın.

Dal 1: Manual action, security issue veya policy problemi

Bu en hızlı doğrulanacak daldır.

Manual Actions ve Security Issues

Search Console bir Manual Action veya Security Issue gösteriyorsa bunu birincil neden olarak ele alın. Önce asıl enforcement veya güvenlik sorununu çözmeden canonical, sitemap veya içerik kalitesi üzerinde saatler harcamayın.

Manual Action ve Security Issue yoksa buna penalty demeyi bırakın. Bu dil teşhise netlik değil panik ekler.

Dal 2: Teknik indexability problemleri

Teknik nedenler somuttur, test edilebilir ve çoğu zaman başlanacak en temiz alandır.

noindex, robots.txt, redirect ve canonical tuzakları

URL’nin şu durumlardan birine girip girmediğini kontrol edin:

  • `noindex` ile excluded olması,
  • `robots.txt` ile blocklanması,
  • redirect vermesi,
  • farklı bir URL’ye canonical göstermesi,
  • HTML, sitemap ve internal link tarafında birbiriyle çelişen canonical sinyalleri taşıması.

soft 404

Bir sayfa teknik olarak başarılı yanıt döndürebilir ama içerik çok zayıf, çok genel veya verdiği vaatle uyuşmuyorsa soft 404 gibi değerlendirilebilir.

Dal 3: Canonical, duplicate ve overlap problemleri

Her kayıp URL teknik olarak bozuk değildir. Bazıları daha güçlü URL’ler lehine canonicalize edilir veya duplicate/overlap olarak sıkıştırılır.

Duplicate ve overlap incelemesi

Şunlara bakın:

  • aynı intent’i hedefleyen birbirine çok benzeyen sayfalar,
  • ana landing page’lerle yarışan tag veya filtre sayfaları,
  • aynı yazının eski sürümleri,
  • zayıf farklılaşan thin location veya programatik sayfalar.

Başka bir URL açık biçimde daha güçlü canonical aday ise, zorla yeniden indexlettirmeye çalışmak çoğu zaman yanlış hedeftir. Consolidation daha temiz sonuç verir.

Dal 4: Quality, usefulness ve thin-content sinyalleri

Indexability ile usefulness aynı soru değildir. Bir sayfa teknik olarak indexable olabilir ama indeks içinde tutulacak kadar güçlü bir aday olmayabilir.

Thin ve örtüşen içerik

Şunları gözden geçirin:

  • sayfa yakın URL’lerden gerçekten farklı bir şey söylüyor mu,
  • gerçek bir arama ihtiyacını net cevaplıyor mu,
  • yeterli kanıt, özgüllük ve yapı içeriyor mu,
  • ayrı bir URL olarak yaşamayı gerçekten hak ediyor mu.

Birçok ekip burada aşırı tepki verir. Her kayıp sayfanın geri getirilmesi gerektiğini varsayar. Oysa bazı sayfalar iyileştirilmelidir, bazıları birleştirilmelidir, bazıları ise zaten indeks alanı için zorlanmamalıdır.

Dal 5: Crawl, sitemap ve internal linking sorunları

Discovery ve destek sinyalleri, özellikle derin veya zayıf sayfalarda hâlâ önemlidir.

sitemap ve internal linking

URL’nin:

  • XML sitemap içinde hâlâ yer alıp almadığını,
  • anlamlı internal link alıp almadığını,
  • navigasyonda çok derine gömülüp gömülmediğini,
  • zayıf veya orphan benzeri keşif kalıplarına dayanıp dayanmadığını kontrol edin.

Sayfa önemliyse bulunmasını ve bağlam içinde anlaşılmasını kolaylaştırın.

Deindexing teşhis tablosu

Belirti Nerede kontrol edilir Olası neden Gerekli kanıt Daha güvenli sonraki adım
URL daha önce indexed idi, şimdi kayıp Search Console ve URL Inspection Gerçek indeks kaybı, canonical kayması veya exclusion Geçmiş indexed durumu ve güncel durum URL’yi değiştirmeden önce dalı doğrulayın
Crawled – currently not indexed Page indexing report Zayıf usefulness, overlap, soft quality sinyali veya belirsiz sayfa rolü Inspection sonucu ve sayfa karşılaştırması Değere göre iyileştirin, birleştirin veya bırakın
Discovered – currently not indexed Page indexing report, crawl yolları, internal links Zayıf discovery, düşük destek, düşük crawl önceliği Internal link haritası ve sitemap durumu Zorlamadan önce discovery’yi güçlendirin
Duplicate veya canonical uyuşmazlığı URL Inspection ve HTML sinyalleri Çelişkili canonical veya overlap Selected canonical ve declared canonical Sinyalleri hizalayın veya birleştirin
Excluded by noindex Page indexing report ve kaynak incelemesi Kasıtlı veya yanlış noindex Meta veya header direktifi Ancak sayfa gerçekten indexing hak ediyorsa kaldırın
Blocked by robots.txt robots.txt incelemesi ve URL testi Crawl engeli Path’i etkileyen robots kuralı Crawl erişimi gerekiyorsa engeli kaldırın
Redirected URL URL Inspection ve doğrudan fetch Redirect zinciri veya emekli sayfa Son hedef ve intent uyumu Consolidation doğruysa redirect’i koruyun
Soft 404 Page indexing report ve sayfa incelemesi Thin veya düşük değerli deneyim İçerik derinliği ve sayfa amacı İçeriği güçlendirin veya retire edin
Thin veya overlap içerik Sayfa karşılaştırması Benzer sayfalar aynı rol için yarışıyor Yan yana overlap incelemesi Merge, rewrite veya scope daraltma
Zayıf internal links Crawl map ve template incelemesi Sitenin geri kalanından zayıf destek Link sayısı ve yerleşim Anlamlı internal link ekleyin
Sitemap’ten çıkmış URL Sitemap ve CMS akışı Zayıf bakım veya yanlış kaldırma Sitemap varlığı ve zaman damgası Ancak URL indekslenmeye değiyorsa geri ekleyin

Karar: fix, merge, noindex, retire veya bırak

Varsayılan karar “geri getir” olmamalıdır. Doğru karar sayfanın değeri, nedeni ve site içindeki rolüne bağlıdır.

Karar Ne zaman kullanılır Gerekli kanıt Yanlışsa risk Sonraki adım
Fix URL yaşamalı ve sorun teknik Açık indexability veya sinyal hatası Yanlış dala zaman harcamak Sorunu düzeltin ve izleyin
Merge veya consolidate Aynı intent’i daha güçlü başka URL zaten karşılıyor Overlap, duplicate, zayıf farklılaşma Cannibalization’ı sürdürmek Değeri güçlü URL’ye taşıyın
Improve and resubmit Sayfa önemli ama zayıf veya belirsiz Quality veya usefulness boşluğu Merge edilmesi gereken sayfayı gereksiz yere yeniden yazmak Sayfayı iyileştirin, sonra yeniden kontrol edin
noindex intentionally Sayfa erişilebilir kalmalı ama indexed olmamalı Net iş veya mimari gerekçe Hâlâ değerli sayfayı gizlemek Bilinçli uygula ve belgeleyin
Retire veya delete Sayfanın iş veya arama değeri yok Düşük değer ve geri kazanım gerekçesi yok Değerli varlığı erken silmek Temiz redirect, arşiv veya kaldırma kararı verin
Leave alone Zorlanmaya değmez Düşük stratejik değer ve zayıf geri dönüş ihtimali Önemsiz URL’lere gereksiz zaman harcamak Belgeleyin ve ilerleyin

Bir şeyi silmeden önce neyi belgelemelisiniz?

Erken silme, kanıtı da siler. Önce belgeleyin.

  • Güncel Search Console durumu
  • URL Inspection sonucu
  • Declared ve selected canonical
  • noindex veya robots bulguları
  • redirect davranışı
  • sitemap varlığı
  • URL’ye giden internal links
  • yarışan veya örtüşen sayfalar
  • sayfanın hâlâ iş değeri taşıyıp taşımadığı

Üç örnek teşhis senaryosu

Senaryo 1: teknik neden

Örnek bir durumda daha önce indexed olan sayfa kaybolur, URL Inspection başka canonical seçildiğini gösterir ve internal linkler de yanlış hedefi güçlendirir. Bu durumda ilk hareket toplu içerik yeniden yazımı değil, sinyal hizalamasıdır.

Senaryo 2: kalite ve overlap nedeni

Anonim bir desende birkaç sayfa aynı intent’i çok benzer biçimde hedefler. Google daha güçlü URL’yi tutar, zayıf olanları bırakır. Böyle bir durumda consolidation, tüm sayfaları geri zorlama denemesinden daha güvenlidir.

Senaryo 3: silmek için erken bir vaka

Örnek çözülmemiş vakada sayfa kayıptır, manual action yoktur, bariz teknik blok da görünmez ve sayfa hâlâ değerli bir iş akışını destekler. Bu durumda doğru cevap hızlanmak değil, kanıtı toplamak ve teşhis tamamlanmadan silmemektir.

Ekran görüntüsü checklist’i

Ekran görüntüsü Neden alınmalı Nereden alınmalı Gizlenecek alanlar
Page indexing report Güncel durumu doğrulamak Search Console Query’ler, hesap etiketleri, hassas path’ler
URL Inspection sonucu Canonical ve indexability ipuçlarını göstermek Search Console Hassas property detayları
Manual Actions veya Security Issues Enforcement ihtimalini hızlı elemek Search Console Marka açısından hassas uyarılar
robots.txt veya noindex kanıtı Teknik exclusion’ı göstermek Kaynak kodu, header veya robots dosyası İç ortam detayları
Karar matrisi görseli Verilen kararı kayıt altına almak Editoryal görsel veya audit deck Müşteri adı ve URL listeleri

Ekran görüntüsü placeholder notları

  • Tam sayfa deindexing teşhis flowchart’ı placeholder
  • Search Console Page indexing report ekran görüntüsü placeholder
  • URL Inspection ekran görüntüsü placeholder
  • Manual Actions ve Security Issues ekran görüntüsü placeholder
  • Canonical, noindex ve robots kontrolü ekran görüntüsü placeholder
  • Fix, merge ve retire karar matrisi görsel placeholder
  • İndirilebilir PNG veya PDF flowchart placeholder

Kaçınılması gereken yaygın hatalar

  • Her kayıp URL’yi penalty diye etiketlemek.
  • Ranking düşüşü ile indexing kaybını aynı problem sanmak.
  • Canonical, noindex, redirect ve sitemap kanıtını toplamadan sayfa silmek.
  • Request indexing işlemini tüm strateji sanmak.
  • Her kayıp sayfanın geri dönmesi gerektiğini varsaymak.
  • Her kayıp sayfanın teknik problem olduğunu varsaymak.

Son öneri

Panik dili değil, teşhis sırası kullanın. Durumu Search Console’da doğrulayın, teknik nedenleri ayırın, overlap ve usefulness sinyallerini karşılaştırın, sonra URL için fix, merge, noindex, retire veya bırak kararını verin.

Search Console arayüzü ve raporlama akışı için Search Console generative AI report guide faydalı olabilir; fakat bu yazı indeks kaybı teşhisine odaklı kalmalıdır.

Flowchart’ı uyguladınız ve hâlâ sayfa kaybediyor musunuz? Herhangi bir şeyi silmeden önce gerçek crawl ve index veriniz üzerinden teknik teşhis alın.

FAQ

2026 deindexing dalgası bir Google penalty’si mi?

Varsayılan olarak hayır. Manual Action veya Security Issue yoksa buna kanıtsız biçimde penalty demeyin.

Search Console neden Crawled – currently not indexed diyor?

Bu ifade genelde Google’ın sayfayı crawl ettiğini ama indeks içinde tutmadığını gösterir. Neden; overlap, zayıf usefulness, soft quality sinyali veya başka bir işaret olabilir. Tek bir evrensel açıklama yoktur.

Deindexed sayfaları silmeli miyim?

Hayır. Önce URL’nin hâlâ iş değeri taşıyıp taşımadığını, teknik olarak excluded olup olmadığını ve merge seçeneğinin silmekten daha güvenli olup olmadığını doğrulayın.

Request indexing deindexing sorununu çözer mi?

Tek başına hayır. Gerçek bir düzeltmeden sonra yardımcı bir takip adımı olabilir ama kendi başına teşhis veya recovery stratejisi değildir.

Düzeltmeden sonra reindexing ne kadar sürer?

Garantili bir süre yoktur. Önce alttaki nedeni düzeltin, sonra sabit zaman vaadi vermek yerine URL’yi izleyin.

Canonical etiketleri deindexing’e yol açabilir mi?

Evet. Canonical sinyalleri Google’ı başka URL’ye yönlendiriyorsa, incelenen sayfa normal açılıyor olsa bile indexed durumunu kaybedebilir.

Bir sayfayı ne zaman fix etmek yerine merge etmeliyim?

Başka bir URL aynı intent’i zaten daha iyi karşılıyorsa ve kayıp sayfa çoğunlukla duplicate, thin veya zayıf biçimde farklılaşmışsa merge daha doğru karardır.

Kaynak notları