Index Bloat Nedir? Dizin Şişmesi Nasıl Tespit Edilir ve Çözülür?

Index bloat nedir?

Index bloat, yani dizin şişmesi, Google dizininde sitenizin değer taşımayan sayfalarının, değerli sayfalarından çok daha fazla yer tutması durumudur. Filtre parametreleri, etiket arşivleri, sayfalama ve kopya URL'ler bu şişmeyi besler. Sonuçta Google, görmesini istediğiniz sayfaları kalabalık bir havuzda tartar.

Kavramı tek cümleyle özetleyelim: dizindeki URL sayısı, sitenizde gerçekten olması gereken sayfa sayısından belirgin biçimde büyükse index bloat vardır. Burada sorun sayının kendisi değil, o sayfaların niteliğidir.

Örneğin 400 ürünlü bir e-ticaret sitesinin dizininde 12.000 URL görüyorsanız, fazlalığın büyük bölümü muhtemelen filtre ve sıralama kombinasyonlarıdır. Bu, ekibimizin sahada en sık karşılaştığı teknik SEO tablolarından biridir. Üstelik sahibi çoğu zaman bunu fark etmez, çünkü site dışarıdan gayet düzgün görünür.

Kavramın bir de görünmeyen yüzü var. Dizindeki her gereksiz sayfa, sitenizin "ne hakkında olduğu" mesajını biraz daha bulandırır. Bu yüzden index bloat yalnızca teknik bir temizlik işi sayılmaz, aynı zamanda bir içerik stratejisi meselesidir.

Index bloat neden SEO için sorun yaratır?

Sorun üç katmanda ortaya çıkar. Birincisi tarama kaynağının boşa harcanması, ikincisi kalite sinyalinin seyrelmesi, üçüncüsü de aynı sorguya kendi sayfalarınızın birbiriyle yarışmasıdır.

• Tarama israfı: Googlebot değersiz URL'lerde vakit harcar, yeni ve önemli sayfalarınıza geç gelir.
• Kalite seyrelmesi: İnce ve tekrar eden sayfalar, sitenin genel kalite algısını aşağı çeker.
• Kendi kendine rekabet: Aynı niyete hizmet eden birden fazla URL, sıralama sinyallerini böler.
• Raporlama kirliliği: Search Console verisi gürültüyle dolar, gerçek sorunları fark etmek zorlaşır.

Ancak şunu da dürüstçe söyleyelim: Google, tarama bütçesinin asıl olarak çok büyük ve sık güncellenen siteler için bir konu olduğunu belirtiyor. Bu ayrıntı için tarama bütçesi rehberina bakabilirsiniz. Küçük sitelerde bloat çoğu zaman tarama sorunundan çok kalite ve kafa karışıklığı sorunudur.

Yani her site için alarm vermeye gerek yok, ama sorunu görmezden gelmek de doğru değil. Buna karşılık, yüzlerce sayfası olan bir siteniz varsa ve dizin sayısı sayfa sayınızın üç katını aşıyorsa, konuyu ciddiye almanız gerekir.

Index bloat ile tarama bütçesi arasındaki fark nedir?

İki kavram birbirine karışır ama aynı şey değildir. Tarama, Googlebot'un sayfayı ziyaret etmesidir. Dizine ekleme ise Google'ın o sayfayı arama sonuçlarında çıkabilecek havuza almasıdır. Bir URL taranıp dizine eklenmeyebilir, hatta taranmadan da dizine girebilir.

Bu ayrım çözüm seçimini doğrudan etkiler ve birçok hatanın kaynağını açıklar. Taramayı azaltmak istiyorsanız robots.txt devreye girer. Dizinden çıkarmak istiyorsanız noindex gerekir. İkisini aynı anda uygulamak ise çoğu zaman ters teper, bunu ilerleyen bölümde ayrıntılı anlatacağız.

Dolayısıyla "Googlebot bu sayfaları görmesin" ile "bu sayfalar dizinde olmasın" farklı hedeflerdir. Önce hangisini istediğinize karar verin, sonra aracı seçin. Bu küçük ayrım, yıllarca süren yanlış müdahalelerin önüne geçer. Kısacası her zaman önce amacı, sonra yöntemi belirleyin.

Index bloat en çok hangi nedenlerle oluşur?

Kaynakların çoğu CMS ayarlarından, filtre mantığından ve unutmuş olduğunuz eski yapılardan gelir. Aşağıdaki liste, sitelerde en sık gördüğümüz nedenleri özetler.

• Filtre, sıralama ve arama parametreli URL'ler.
• Etiket, yazar, tarih ve kategori arşivleri.
• Oturum kimliği ve takip parametreleri.
• Sayfalama ve "tümünü göster" varyantları.
• HTTP/HTTPS, www/non-www ve sonda eğik çizgi kopyaları.
• Test, staging ve eski tema kalıntıları.
• Ek dosya (attachment) sayfaları.
• Boş kategori ve stoğu bitmiş ürün sayfaları.

Bu nedenlerin her biri ayrı bir çözüm ister ve her birinin riski farklıdır. Bu yüzden kör bir "hepsini noindex yap" refleksi yerine, önce hangi kaynağın ne kadar URL ürettiğini ölçmeniz gerekir.

Ayrıca birden fazla neden genellikle aynı anda çalışır. Örneğin bir filtre sayfası hem parametre üretir hem de sayfalama ekler, üstüne bir de takip parametresi taşır. Kaynakları tek tek ayırmazsanız, hangi düzeltmenin işe yaradığını anlayamazsınız.

Parametreli URL'ler index bloat'a nasıl yol açar?

Bir filtre bağlantısı her tıklamada yeni bir URL üretir. Renk, beden, fiyat ve sıralama seçeneklerini birleştirdiğinizde birkaç yüz ürünlük bir katalog, binlerce kombinasyona dönüşebilir. Googlebot bu bağlantıları iç linklerden bulur ve taramaya başlar.

Örnek hesap: 5 renk, 6 beden, 4 sıralama ve 3 fiyat aralığı seçeneği tek bir kategoride 5 x 6 x 4 x 3 = 360 kombinasyon eder. Kategori sayınız 30 ise 10.000'in üzerinde ulaşılabilir URL ortaya çıkar. Bu rakam yalnızca mantığı göstermek için kurguladığımız bir hesaptır, gerçek bir müşteri verisi değildir.

Google, bu sorun için Google Search Central facet dokümanında net bir öncelik sırası veriyor. Facet URL'lerin taranmasını engellemek için robots.txt en etkili yöntem olarak geçiyor. Canonical ve nofollow ise daha zayıf ve uzun vadeli seçenekler olarak anlatılıyor.

Konunun tamamı için parametreli URL yazımızna göz atın. Orada parametre türlerini ve her birinin SEO etkisini ayrıntılı işledik. Bu yazıda ise parametrelerin dizine nasıl sızdığına ve sızıntıyı nasıl kapatacağınıza odaklanıyoruz.

Etiket, arşiv ve sayfalama URL'leri neden dizini şişirir?

WordPress gibi sistemler, bir yazıyı kategori, etiket, yazar ve tarih arşivlerinde ayrı ayrı listeler. Her arşiv sayfası, aynı yazı özetlerini farklı bir dizilimle tekrar eder. Tek bir yazı böylece dört beş URL'nin içinde yer alır.

Etiketler özellikle tehlikelidir. Bir yazıya on etiket eklerseniz ve her etiketin altında yalnızca bir iki yazı varsa, ortaya on tane ince içerikli sayfa çıkar. Bu sayfaların çoğu hiçbir sorguya cevap vermez.

Sayfalama ise ayrı bir dengedir. Kategori sayfası 2, 3 ve 4, ürünlere ulaşmak için gerekli olabilir. Yani sayfalamayı topluca noindex yapmak, derindeki ürünlerin keşfini zayıflatabilir. Her sitede karar, iç link mimarisine göre şekillenir.

Pratik bir kural önerelim: bir arşiv sayfası, arama yapan birine gerçekten yardımcı olacak bir liste sunmuyorsa dizinde kalmamalıdır. Yazar arşivi tek yazarlı bir blogda ana sayfanın kopyasından farksızdır. Tarih arşivleri ise neredeyse hiçbir zaman bir arama niyetini karşılamaz.

Kopya ve standart (canonical) sorunları dizini nasıl büyütür?

Aynı içeriğe birden fazla adresten ulaşılabiliyorsa, Google bunlardan birini standart (canonical) seçer. Siz seçimi açıkça belirtmezseniz, Google kendi kararını verir. Bazen de sizin istemediğiniz URL'yi seçer.

Tipik kopya kaynakları şunlardır:

1. http ve https sürümlerinin ikisinin de açık kalması.
2. www ve non-www sürümlerinin ayrı yaşaması.
3. Sonda eğik çizgi olan ve olmayan sürümler.
4. Büyük ve küçük harf farkıyla açılan adresler.
5. Yazdırma ve AMP benzeri eski sürümler.

Çözüm temiz bir canonical ve 301 düzenidir. yinelenen URL'leri birleştirme rehberi, bu birleştirmenin hangi yöntemlerle yapılacağını adım adım anlatıyor. Yönlendirmeleri doğrularken yönlendirme denetleyici aracımızndan ve yönlendirme zinciri yazımızndan yararlanabilirsiniz.

Canonical etiketinin bir öneri olduğunu unutmayın, emir değildir. Google, içerikler gerçekten farklıysa etiketinizi yok sayabilir. Bu yüzden canonical'ı kopya olmayan sayfaları birleştirmek için kullanmayın.

Staging, test ve eski sayfa kalıntıları dizinde nasıl yer alır?

Geliştirme ortamı kapatılmadan yayına alındıysa, Google bu kopyayı da dizine ekleyebilir. Staging adresi canlı sitenin bire bir aynısı olduğu için, tam bir kopya içerik havuzu oluşur. Bu durumla özellikle yeniden tasarım dönemlerinde karşılaşırsınız.

Eski kampanya sayfaları, silmiş olsanız da erişilebilir kalan PDF'ler ve terk ettiğiniz alt klasörler de aynı kategoriye girer. Bu sayfaları çoğu zaman siz unutmuşsunuzdur, ama Google unutmaz.

Staging için doğru koruma, parola ve IP kısıtlamasıdır. Sadece robots.txt engeli yetmez, çünkü engellediğiniz bir URL yine de başka sitelerin verdiği bağlantılar yüzünden dizinde görünebilir.

Yeniden tasarım sonrasında eski sayfaların durumunu da kontrol edin. Eski URL'ler 404 verecekse bunu bilinçli yapın. Trafik alan eski adresler için ise bir 301 planı hazırlayın, yoksa hem değer hem de temiz bir dizin kaybedersiniz.

Index bloat'u site: komutuyla nasıl tespit edersiniz?

En hızlı ilk kontrol, Google'da site:alanadiniz.com araması yapmaktır. Sonuç sayısı kabaca bir fikir verir, ancak kesin bir ölçüm değildir. Bu rakamı bir teşhis değil, bir ipucu olarak okuyun.

Komutu şu biçimlerde kullanabilirsiniz:

• site:alanadiniz.com inurl:? ile parametreli adresleri arayın.
• site:alanadiniz.com inurl:etiket ile arşiv yapılarını sorgulayın.
• site:alanadiniz.com -inurl:https ile güvensiz sürümleri arayın.
• site:alanadiniz.com intitle:"sayfa 2" ile sayfalama kalıntılarına bakın.

Bu operatörün gösterdiği sayı tahmindir ve değişebilir. Bu yüzden kararlarınızı site: sayısına değil, Search Console ve sunucu verisine dayandırın.

Yine de operatör, hızlı bir örneklem için çok değerlidir. Sonuç sayfalarında gördüğünüz tuhaf başlıklar, tekrar eden açıklamalar ve boş sayfalar size sorunun niteliği hakkında dakikalar içinde fikir verir. Bulduğunuz her deseni bir not dosyasına yazın, çünkü bu desenler sonraki adımda filtre listenizi oluşturur.

Search Console ile index bloat nasıl görünür hale gelir?

Doğru kaynak, Search Console'daki Sayfa dizine ekleme raporudur. Raporun ayrıntılarını Sayfa dizine ekleme raporu yardım sayfasında bulabilirsiniz. Burada "Dizine eklendi" sayısını, sitenizin olması gereken URL sayısıyla karşılaştırın.

Bakmanız gereken ilk sinyaller şunlardır:

• Dizine eklenen sayfa sayısının sitemap'teki URL sayısından çok büyük olması.
• "Crawled - currently not indexed" sayısının hızla artması.
• "Duplicate without user-selected canonical" başlığında binlerce URL görünmesi.
• "Alternate page with proper canonical tag" grubunun beklenenden fazla büyümesi.

Rapor arayüzünüzün diline göre bu başlıkların adı farklı görünebilir. Ayrıca Ayarlar bölümündeki Tarama İstatistikleri raporu, Googlebot'un hangi URL türlerine zaman harcadığını gösterir. Genel kullanım için Search Console rehberimizne de bakın.

Bir başlığa tıkladığınızda, Search Console size örnek URL'leri listeler. Bu listeyi dışa aktarın ve desenlere göre ayırın. İlk bakışta rastgele görünen yüzlerce adresin aslında üç dört şablondan geldiğini fark edeceksiniz.

Sitemap ve dizin sayısını karşılaştırarak bloat nasıl ölçersiniz?

Basit ama güçlü bir yöntem var: sitemap'inizdeki URL sayısını, dizine eklenen URL sayısıyla yan yana koyun. Sitemap, "dizinde olmasını istediğim sayfalar" listesidir ve bu yüzden karşılaştırma için en doğru referanstır. Fark büyükse, dizinde istemediğiniz sayfalar var demektir.

Örnek hesap: sitemap'te 1.200 URL var ve Search Console 4.800 dizinli sayfa gösteriyor. Demek ki 3.600 URL sitemap dışında kalıyor. Bu fazlalığı kaynağına göre gruplamanız gerekir: parametre, arşiv, kopya ve diğer.

Bu ölçüm için sitemap'in temiz olması şarttır; aksi halde kıyaslama anlamını yitirir. Sitemap'e noindex veya yönlendirmeli URL koymak, karşılaştırmayı bozar. XML sitemap oluşturucu aracımız ve sitemap lastmod yazımız bu temizliğe yardımcı olur.

Oranı da hesaplayın. Dizin sayısını sitemap sayısına böldüğünüzde 1,0 civarında bir değer beklersiniz. Saha tecrübemize dayalı başlangıç aralığı olarak, bu oran 1,5'i geçiyorsa incelemeye başlarız. Bu eşik bir garanti veya resmi kural değildir, yalnızca bir uyarı işaretidir.

Sunucu logları index bloat hakkında ne söyler?

Log dosyaları, Googlebot'un gerçekte hangi URL'lere gittiğini gösteren tek kesin kaynaktır. Search Console örneklem verir, log ise ham gerçeği verir. Bu nedenle büyük sitelerde bloat analizinin temeli loglardır.

Logdan şu soruların cevabını çıkarabilirsiniz. Bu sorular, tarama israfını rakamla gösterdiği için karar vericilere anlatması da kolaydır:

• Googlebot isteklerinin yüzde kaçı parametreli URL'lere gidiyor?
• Hangi klasör en çok tarama alıyor?
• 404 ve 301 dönen hangi URL'leri Googlebot sürekli yokluyor?
• Yeni yayınladığınız sayfayı Googlebot kaç günde ilk kez ziyaret ediyor?

Son sorunun cevabı uzuyorsa, tarama israfı gerçek bir etki yaratıyor olabilir. Bu tabloyu tarama sıklığı düşüşü yazımıznda farklı bir açıdan anlattık.

Logları analiz ederken Googlebot'u doğru tanımladığınızdan emin olun. Kullanıcı aracısı (user agent) taklit edilebilir, bu yüzden ters DNS doğrulaması yapın. Aksi halde sahte botların isteklerini Googlebot sanarsınız ve yanlış sonuca varırsınız.

Index bloat çözümünde hangi yöntemi ne zaman seçersiniz?

Tek bir sihirli yöntem yoktur. Her URL türünün amacına göre ayrı bir araç seçersiniz. Aşağıdaki tablo, karar verirken bize yol gösteren temel eşleşmeleri özetler.

Bu tablo bir reçete değil, bir başlangıç çerçevesidir. Sitenizin altyapısı, CMS sınırları ve geliştirici kapasitesi de seçimi etkiler. Her satır için sayfanın trafiği ve bağlantı değerini kontrol etmeden karar vermeyin.

Örneğin bir etiket sayfası trafik alıyorsa onu noindex yapmadan önce durun. Önce o sayfanın hangi sorgularda göründüğüne bakın. Gerçek bir konu sayfasına dönüştürmek, bazen silmekten daha kârlı bir seçimdir.

noindex ile robots.txt birlikte kullanılırsa ne olur?

En sık yapılan hata budur. Bir sayfaya noindex ekler, sonra aynı sayfayı robots.txt ile engellersiniz. Googlebot sayfayı tarayamadığı için noindex etiketini hiç göremez.

Google'ın noindex dokümanı bunu açıkça belirtir: noindex kuralının çalışması için sayfa robots.txt ile engellenmemeli ve tarayıcıya erişilebilir olmalıdır. Engellediğiniz bir sayfa, başka sitelerden aldığı bağlantılar yüzünden sonuçlarda görünmeye devam edebilir.

Doğru sıra şudur: önce noindex ekleyin, sayfaların dizinden çıktığını Search Console'da doğrulayın, ancak ondan sonra gerekiyorsa robots.txt ile taramayı kapatın. robots.txt dosyanızı hazırlarken robots.txt oluşturucu aracımıznı, sık yapılan yanlışlar için robots.txt hataları yazımıznı kullanabilirsiniz.

Noindex'i iki şekilde verebilirsiniz: HTML içindeki meta robots etiketiyle veya X-Robots-Tag HTTP başlığıyla. PDF gibi HTML olmayan dosyalarda yalnızca başlık yöntemi çalışır. Hangisini seçerseniz seçin, Search Console'daki URL Denetleme aracıyla Googlebot'un direktifi gördüğünü test edin.

Dizinden temizliği adım adım nasıl yaparsınız?

Planlı ilerlerseniz riski küçültür, sonucu hızlandırırsınız. Ekibimizin önerdiği akış şöyledir:

1. Dizindeki URL'leri dışa aktarın ve türlerine göre gruplayın.
2. Her grubun trafik, bağlantı ve gelir katkısını kontrol edin.
3. Değeri olmayan gruplar için 404, 410, 301, canonical veya noindex kararı verin.
4. Kaynağı kapatın: filtre bağlantıları, etiket sayfaları ve şablon hataları.
5. Temiz bir sitemap gönderin.
6. Sonuçları 4-8 hafta boyunca haftalık izleyin.

Dördüncü adım en çok atlanan adımdır. Kaynağı kapatmazsanız, temizlediğiniz URL'leri sistem birkaç hafta içinde yeniden üretir. Bu yüzden bloat çözümü, bir defalık temizlik değil, şablon düzeyinde bir düzeltmedir.

Google dizin durumunu bazen yavaş günceller. Kısacası sabır gerekir, ancak ilerlemeyi Search Console'daki trend çizgisiyle görebilirsiniz.

Değişiklikleri kademeli yapmanızı öneririz. Önce tek bir URL grubunda deneyin, sonuçları gözleyin, sonra diğer gruplara geçin. Böylece yanlış bir kural yüzünden değerli sayfalarınızı kaybetme riskini azaltırsınız.

İçerik budama ile index bloat temizliği aynı şey midir?

Hayır, ama birbirini tamamlarlar. İçerik budama, sitenizdeki gerçek içerik sayfalarını değerlendirir: güncelle, birleştir, yönlendir ya da sil. Index bloat temizliği ise çoğunlukla sistemin ürettiği teknik URL'lerle ilgilenir.

Bir örnekle ayıralım. Eski bir blog yazısını güncellemek budama kararıdır. Etiket arşivlerini noindex yapmak ise bloat kararıdır. İkisi de dizinin kalitesini yükseltir, fakat farklı ekip ve farklı araç gerektirir.

İçerik tarafındaki karar ağacı için içerik budama rehberimizna bakın. Bu iki işi aynı takvimde yürütürseniz, sitenizin dizin profili daha hızlı toparlanır.

Sıralamayı da şöyle planlayın: önce teknik kaynağı kapatın, sonra içerik budamaya geçin. Teknik sızıntı açıkken içerik temizlemek, kovayı doldururken deliği tıkamamaya benzer.

Index bloat'u önlemek için hangi alışkanlıkları edinmelisiniz?

Temizlik kadar önleme de önemlidir, çünkü yayındaki bir siteye her yeni özellik eklendiğinde bloat yeniden doğabilir. Sorunu kaynağında engelleyen alışkanlıklar, yıllar sonra bile sitenizi sağlıklı tutar.

• Yeni bir filtre veya arşiv türü eklemeden önce SEO etkisini değerlendirin.
• Her şablon için canonical ve robots kuralını açıkça tanımlayın.
• Takip parametrelerini iç linklerde kullanmayın.
• Staging ortamını parola ile koruyun.
• Üç ayda bir dizin ve sitemap sayısını karşılaştırın.
• Yeni yayına alma öncesinde teknik bir kontrol listesi uygulayın.

Bu alışkanlıkların çoğu geliştirici ile SEO ekibi arasındaki iletişime dayanır. Yani asıl çözüm, teknik süreci yazılı hale getirmektir.

Yayın öncesi kontrol listesine, küçük görünse de çok değerli olan şu soruyu ekleyin: bu değişiklik yeni bir URL türü üretiyor mu? Cevap evetse, o URL türünün dizinde olup olmayacağına baştan karar verin. Bu tek soru, bloat vakalarının büyük bölümünü kaynağında keser.

E-ticaret sitelerinde index bloat neden daha sık görülür?

E-ticaret siteleri, doğası gereği URL üreten makinelerdir. Her filtre, her sıralama seçeneği ve her stok durumu yeni bir adres doğurabilir. Bu nedenle ürün sayısı küçük kalsa bile dizin sayısı hızla büyür.

Ayrıca ürün varyantları da ayrı bir kaynaktır. Aynı ürünün renk ve beden seçenekleri, her biri için ayrı URL açıyorsa, içerik neredeyse birebir tekrarlanır. Canonical burada genellikle doğru araçtır, çünkü kullanıcı varyantı seçebilmelidir.

• Stoğu tükenen ürünler için sayfayı koruyun ve benzer ürünler önerin.
• Kalıcı olarak kalkan ürünlerde 301 ile en yakın kategoriye yönlendirin.
• Sıralama parametrelerini canonical ile ana kategoriye bağlayın.
• Dahili arama sonuç sayfalarını noindex yapın.

Bu alanda ekibimizle çalışmak isterseniz e-ticaret danışmanlığı sayfasına göz atın. Teknik temizlik ve katalog mimarisi çoğu zaman birlikte ele alınır.

Temizlikten sonra hangi metrikleri izlersiniz?

Başarıyı yalnızca dizin sayısının düşmesiyle ölçmeyin. Sayının düşmesi iyi bir işaret olabilir, ancak yanlış sayfalar düşüyorsa kötü bir işarettir. Bu yüzden birden fazla metriği birlikte okuyun.

• Dizinli sayfa sayısı: Sitemap sayısına doğru yaklaşmasını bekleyin.
• Organik tıklama: Önemli sayfalarınızın tıklaması düşmemeli.
• Tarama istatistikleri: Değerli klasörlerin taranma payı artmalı.
• Yeni sayfaların dizine girme süresi: Kısalmasını bekleyin.

Değişikliği yaptığınız tarihi bir not olarak kaydedin. Böylece trafik dalgalanmasını yorumlarken neyin neye yol açtığını ayırt edersiniz. Dalgalanma ilk haftalarda normaldir, panik yapmadan trendi izleyin.

Bir aylık izlemeden sonra, hâlâ dizinde kalan istenmeyen URL'leri yeniden gruplayın. Kalan grup küçükse süreç işliyor demektir. Büyükse, kaynağı tam kapatamamışsınız demektir.

Index bloat hakkında hangi yanlış anlamalar yaygındır?

Konu etrafında birkaç kalıcı yanılgı dolaşıyor. Bunları bilmek, gereksiz müdahalelerden sizi korur.

• "Dizin ne kadar büyükse o kadar iyi." Hayır, önemli olan dizinlenen sayfaların kalitesidir.
• "robots.txt dizinden çıkarır." Hayır, yalnızca taramayı engeller.
• "Canonical kesin kuraldır." Hayır, Google için bir ipucudur.
• "Search Console'daki Dizine eklenmedi sayısı kötüdür." Her zaman değil, bu sayfaların çoğu zaten dizinde olmamalıdır.

Son madde özellikle önemlidir, çünkü Search Console'un kırmızı ve gri sayıları sık sık yanlış yorumlanır. Dizine eklenmeyen sayfaların çoğu sorun değil, doğru çalışan bir sistemin sonucudur. Kaynağı yüzlerce alternatif sayfa olan bir sitede, bu sayfaların dizine girmemesi beklenen bir durumdur. Dolayısıyla her kırmızı sayıdan korkmayın, önce nedenini okuyun.

Ayrıca dizinlenmeyen değerli sayfalarınız varsa, bu ayrı bir sorundur. O durumda indexlenmeyen sayfalar yazımızndaki teşhis adımlarını uygulayın.

Örnek bir index bloat vakasında öncelikleri nasıl belirlersiniz?

Varsayımsal bir örnekle süreci somutlaştıralım. Bu bir örnek hesaptır, gerçek bir müşteri vakası değildir. 800 sayfalık bir kurumsal blog ve hizmet sitesi düşünün; Search Console'da 3.100 dizinli URL görünüyor.

Dışa aktarılan listeyi gruplarsanız şuna benzer bir dağılım çıkabilir: 800 gerçek sayfa, 1.400 etiket ve arşiv sayfası, 600 parametreli URL, 300 sayfalama ve ek dosya sayfası. Yani dizinin yaklaşık dörtte üçü aslında gereksizdir.

1. Önce 600 parametreli URL'nin kaynağını bulun ve iç linkleri temizleyin.
2. Ardından etiket sayfalarını değerlendirin; trafik almayanları noindex yapın.
3. Ek dosya sayfalarını ana içeriğe yönlendirin.
4. Son olarak sayfalama kararını iç link yapısına göre verin.

Öncelik sırası, kazanç büyüklüğü ve risk dengesine göre belirlenir. Parametre temizliği hem büyük hem de düşük risklidir. Bu yüzden listenin başına gelir. Etiket kararları ise trafik verisi gerektirdiği için ikinci sıradadır.

Bu tür bir temizlikte, kazanımı tahmin etmek yerine ölçmek gerekir. Sonuçlar siteden siteye büyük farklılık gösterir, o yüzden hiçbir örneği vaat olarak okumayın.

Hangi durumda profesyonel destek almalısınız?

Küçük bir blogda bloat çoğu zaman birkaç ayar değişikliğiyle çözülür. Ancak binlerce URL üreten bir e-ticaret veya çok dilli bir yapıda, yanlış bir noindex toplu trafik kaybına yol açabilir. Riskin yükseldiği yer burasıdır.

Şu işaretler, dışarıdan bir göz için iyi bir zamanı gösterir: dizin sayısı sitemap'in birkaç katı, organik trafikte açıklanamayan düşüş, yeni sayfaların haftalarca dizine girmemesi. Bu durumlarda SEO danışmanlığı hizmetimiz kapsamında teknik denetim yapıyoruz.

Genel çerçeve için teknik SEO rehberimiznı da okuyabilirsiniz. Bu yazıdaki adımları kendi başınıza uygulayacaksanız, ilk hafta yalnızca ölçüm yapın ve hiçbir şeyi silmeyin.