Sefa Şalgam'da 620 indeksleme hatasını nasıl bulduk ve düzelttik?

Bu yazı bir vaka çalışması. Kendi sitelerimizden biri olan Sefa Şalgam'ın (sefasalgam.tr) site taramasında 620 indeksleme hatası çıktı. Hepsinin arkasında tek bir şablon hatası vardı: header ve footer'daki, başında eğik çizgi olmayan göreli bağlantılar. Aşağıda sorunu nasıl fark ettiğimizi, kök nedeni nasıl bulduğumuzu, 8 Kasım 2026'da 27 PHP dosyasında yaptığımız düzeltmeyi ve aynı gün yapılan yeniden taramada sayının 620'den 8'e inmesini adım adım anlatıyoruz.

Yazıdaki her sayı kendi tarama kayıtlarımızdan geliyor. Tahmin, ortalama ya da genelleme yok. Amacımız, aynı hatayı kendi sitesinde yaşayan biri için izlenebilir bir yol bırakmak.

Sefa Şalgam, özel PHP ile yazılmış bir e-ticaret sitesi. Ürün sayfaları, kurumsal sayfalar, blog ve çerez, KVKK, gizlilik gibi yasal sayfalardan oluşuyor. Sayfaların hepsi aynı header ve footer şablonunu paylaşıyor. Bu, küçük ve orta ölçekli PHP sitelerinde çok yaygın bir yapı: Bir menü bağlantısını değiştirmek için tek bir dosyayı düzenlemek yetiyor.

Site Otopilot'ta bir proje olarak ekliydi ve düzenli olarak taranıyordu. Taramalar sitedeki bağlantıları izleyerek ulaşılabilen bütün adresleri okuyor; her adresin durum kodunu, canonical etiketini, robots işaretlerini ve içeriğini kontrol ediyor. Bu taramanın nasıl çalıştığını site denetimi ve SEO örümceği rehberinde ayrıntılı anlattık.

Sorun ilk bakışta büyük görünmüyordu. Site açılıyordu, ürünler satılıyordu, ziyaretçilerin şikâyet ettiği bir şey yoktu. Ama tarama raporundaki "dizine eklenemiyor" satırı 620 kayda ulaşmıştı ve bu sayı sitenin gerçek sayfa sayısıyla hiçbir şekilde uyuşmuyordu.

620 indeksleme hatası raporda nasıl göründü?

Raporda bu bulgular "dizine eklenemiyor" (NOT_INDEXABLE) türünde listeleniyordu. Bu tür, taranan bir adresin arama motoru dizinine girmeye uygun olmadığı anlamına gelir. Sebep bir noindex işareti, başka bir adresi gösteren canonical etiketi ya da benzeri bir durum olabilir.

Tek tek bakıldığında her kayıt makul görünüyordu: Adres açılıyor, sayfa içerik gösteriyor, ama canonical etiketi başka bir adresi gösteriyor. Asıl ipucu adreslerin kendisindeydi. Listede şuna benzer adresler vardı:

• /urun/4/cerez-politikasi
• Aynı kalıpta, bir ürün ya da içerik yolunun altına eklenmiş yasal ve kurumsal sayfa adları

Sitede böyle bir sayfa yoktu. Çerez politikası sitenin kökünde, /cerez-politikasi adresinde duruyordu. Bir ürün yolunun altında çerez politikası açılması, bir bağlantının yanlış çözüldüğünün işaretiydi.

Kök neden: Başında eğik çizgi olmayan göreli linkler

Header ve footer şablonlarını açtığımızda nedeni bulduk. Bağlantıların bir kısmı href="cerez-politikasi" biçiminde, başında eğik çizgi olmadan yazılmıştı. Bu tür bir bağlantı sitenin köküne göre değil, bulunduğu sayfanın klasörüne göre çözülür. Ana sayfada sorun görünmez, çünkü ana sayfanın klasörü zaten köktür. Ama bir ürün sayfasında aynı footer, aynı bağlantıyı ürün yolunun altına ekler.

Sunucu bu adresler için 404 döndürmüyordu. Adres açılıyor, sayfa içerik gösteriyor, canonical etiketi ise asıl sayfayı gösteriyordu. Yani her ürün ve içerik sayfası, footer'daki her göreli bağlantı için yeni bir kopya adres üretiyordu. Tarayıcı bu adresleri izledikçe kopyalar çoğalıyor, her biri raporda ayrı bir indeksleme hatası olarak görünüyordu.

Göreli bağlantıların nasıl çözüldüğünü ve bu tuzağın genel hâlini kopya sayfalar ve göreli link tuzağı yazısında tablolarla anlattık. Bu vaka, o yazıdaki örneğin gerçek bir sitede yaşanmış hâli.

Kısaca durum şuydu:

Düzeltme: 27 PHP dosyasında kökten bağlantılar

Çözüm teknik olarak basitti ama dikkat istiyordu. 8 Kasım 2026'da header, footer ve aynı göreli bağlantı kalıbını taşıyan diğer şablon dosyalarını tek tek gözden geçirdik. Toplam 27 PHP dosyasında bağlantıları sitenin köküne göre çözülecek biçime çevirdik. href="cerez-politikasi" gibi bağlantılar href="/cerez-politikasi" oldu.

Bu tür bir değişiklikte izlediğimiz sıra şuydu:

• Önce yedek. Değiştirilecek bütün dosyaların bir kopyası ayrı bir klasöre alındı. Bir sorun çıkarsa tek komutla eski hâline dönmek mümkündü.
• Sözdizimi kontrolü. Her PHP dosyası değişiklikten sonra php -l ile kontrol edildi. Tek bir eksik tırnak bütün sayfayı beyaz ekrana çevirebilir.
• Önbellek. Sunucuda PHP kod önbelleği (OPcache) değişen dosyaları kendiliğinden okumayacak biçimde ayarlıydı. Değişikliğin yayına yansıması için PHP-FPM yeniden yüklendi.
• Canlı kontrol. Ana sayfa, birkaç ürün sayfası ve yasal sayfalar tarayıcıda açılıp footer bağlantılarının nereye gittiğine bakıldı.

Kendi sitenizde aynı hatayı aramak

Aynı kalıbı kendi PHP sitenizde aramak için büyük araçlara gerek yok. Şablon dosyalarında şu kontrolleri yapabilirsiniz:

1. Header, footer ve menü dosyalarında href=" ile başlayıp ardından eğik çizgi, http, #, mailto: ya da tel: gelmeyen bağlantıları listeleyin. Bunlar bulunulan klasöre göre çözülen bağlantılardır.
2. Sayfa başında bir <base> etiketi olup olmadığına bakın. Bu etiket bütün göreli bağlantıların çözüleceği adresi değiştirir ve hatayı gizleyebilir ya da büyütebilir.
3. Sitede gerçekte olmayan bir adresi, örneğin bir ürün yolunun sonuna rastgele bir kelime ekleyerek tarayıcıda açın. Sunucu 404 yerine sayfa gösteriyorsa, yanlış çözülen her bağlantı yeni bir kopya adres üretebilir.
4. Bir ürün ya da blog sayfasını açıp footer'daki her bağlantının üzerine gelin ve tarayıcının gösterdiği tam adresi kontrol edin.

Bu dört kontrol birkaç dakika sürer. Hatayı tarama raporunda yüzlerce satır olarak görmeden önce yakalamanın en ucuz yolu budur.

Burada bilinçli olarak yapmadığımız bir şey de var: Kopya adresleri tek tek yönlendirmeye ya da noindex ile kapatmaya çalışmadık. Sorunun kaynağı bağlantılardı. Bağlantı düzelince bu adreslere giden yol kapanır ve yeni kopya üretilmez. Kopya adreslerin her birine ayrı çare aramak, kaynağı açık bırakıp sonuçla uğraşmak olurdu.

Sonuç: Aynı gün yeniden tarama ve 620'den 8'e

Düzeltmeden sonra aynı gün siteyi yeniden taradık. Rapordaki indeksleme hatası sayısı 620'den 8'e indi. Göreli bağlantılardan doğan kopya adresler taramada artık bulunmuyordu, çünkü hiçbir sayfa onlara bağlantı vermiyordu.

Kalan 8 bulgu bu göreli link sorunundan bağımsız; bu yazıda onların ayrıntısına girmiyoruz. Asıl kazanç sayının düşmesinden çok, raporun yeniden okunabilir hâle gelmesi oldu. 620 satırın arasında gerçek bir sorun kolayca kaybolabiliyordu. Şimdi listede kalan her satır gerçek bir sayfaya ait.

Bu vakadan çıkardığımız genel ders şu: Bir taramada aynı türden yüzlerce bulgu görüyorsanız, önce bunların ortak bir kaynağı olup olmadığına bakın. Şablon düzeyindeki tek bir hata, sitenin bütün sayfalarına aynı anda yayılır ve rapora yüzlerce satır olarak yansır. Bu satırları tek tek düzeltmeye çalışmak hem uzun sürer hem de kaynağı açık bıraktığı için sorun bir sonraki taramada geri gelir. Kaynağı bulup tek yerden düzeltmek ise bütün satırları birden kapatır. Sefa Şalgam'da 620 bulgunun 27 dosyadaki bağlantı düzeltmesiyle kapanması bunun somut bir örneği.

Bir not daha: Bu sonuç Otopilot'un kendi tarama raporundan. Google'ın kendi tarafında, Search Console'daki Sayfalar raporunda kopya adreslerin kaybolması zaman alır. Google'ın bu adresleri yeniden tarayıp güncel durumu görmesi gerekir. O yüzden Search Console tarafını ayrıca, birkaç hafta boyunca izlemek gerekiyor. Sayfa bazında dizin durumunu adım adım kontrol etmek için indekslenmeme teşhis botu rehberine bakabilirsiniz.

Pixel yerine PHP bağlayıcısı: Düzeltmeler artık sunucuda

Bu vakanın ikinci dersi, düzeltmelerin siteye nasıl ulaştığıyla ilgili. Sefa Şalgam'da Otopilot'un hazırladığı SEO düzeltmeleri başta Pixel üzerinden uygulanıyordu. Pixel sayfaya eklenen küçük bir betik. Düzeltmeyi ziyaretçinin tarayıcısında, sayfa açıldığında uygular. Yani düzeltme yalnız biri sayfayı ziyaret ettiğinde devreye giriyordu.

Bugün aynı sitede düzeltmeler PHP bağlayıcısı üzerinden, sunucu tarafında uygulanıyor. Bağlayıcıda 230 kural tanımlı. Sayfa kim isterse istesin, ister bir ziyaretçi ister bir arama motoru botu, sunucu düzeltilmiş HTML'i gönderiyor.

Pixel yönteminin bir zayıflığı da düzeltmenin görünürlüğüdür. Arama motoru botları sayfayı her zaman bir tarayıcı gibi çalıştırmaz; betiğin değiştirdiği başlık ya da açıklama, botun okuduğu ilk HTML'de yer almayabilir. Sunucu tarafı bağlayıcıda bu belirsizlik yoktur, çünkü düzeltme daha sayfa gönderilmeden HTML'in içine yazılır. Site sahibi açısından da doğrulama kolaylaşır: Sayfanın kaynağını açmak, düzeltmenin yerinde olup olmadığını görmeye yeter.

Bu fark, şablon düzeyindeki bir hatayla birlikte düşünüldüğünde daha da önemli hâle geliyor. Göreli link sorunu gibi şablon hataları bir betikle çözülemez, kodda düzeltilmesi gerekir. Başlık, açıklama ve benzeri sayfa düzeyindeki düzeltmelerin ise sunucu tarafında, her istekte uygulanması gerekir. Neden bazı düzeltmelerin siteye ulaşmadığını ve hangi kanalın ne zaman uygun olduğunu SEO düzeltmesi siteye uygulanmıyor yazısında anlattık. Özel PHP siteler için bağlayıcı kurulumu PHP entegrasyonu sayfasında anlatılıyor.

Sık sorulan sorular

Göreli link her zaman indeksleme hatası üretir mi?

Hayır. Göreli bağlantılar doğru kullanıldığında sorun çıkarmaz. Sorun, her sayfada tekrar eden header, footer ve menü bağlantılarının bulunulan klasöre göre çözülmesi ve sunucunun var olmayan adreslerde 404 yerine sayfa açmasıyla başlar.

Bu hatanın sitemde olup olmadığını nasıl anlarım?

Site taramanızda aynı sayfa adının farklı yolların altında tekrar ettiği adresler arayın. Bu adreslerden birini tarayıcıda açıp footer bağlantılarının nereye gittiğine bakın. Otopilot'un site denetimi bu adresleri "dizine eklenemiyor" bulgusu olarak listeler.

Kopya adresleri tek tek yönlendirmem gerekir mi?

Bu vakada gerekmedi. Kaynak bağlantılar düzeltilince kopya adreslere giden yol kapandı ve yeniden tarama bunları bulmadı. Daha önce dışarıdan bağlantı almış bir kopya adres varsa ona ayrıca bakmak gerekebilir.

Pixel ile PHP bağlayıcısını birlikte kullanabilir miyim?

Otopilot'ta bir sitenin düzeltmeleri bağlı kanal üzerinden uygulanır. Özel PHP sitelerde sunucu tarafı bağlayıcı, düzeltmeyi botlara da ulaştırdığı için tercih edilen yoldur.

620'den 8'e düşüş Google'da hemen görünür mü?

Hayır. Bu sayılar Otopilot'un kendi taramasından. Google'ın kopya adresleri yeniden tarayıp Search Console raporunu güncellemesi zaman alır.

Kaynaklar

• Google: Kopya URL'leri birleştirme
• Google: Taranabilir bağlantılar
• Google Search Console Yardım: Sayfa dizine ekleme raporu
• MDN: Göreli adreslerin çözümlenmesi
• PHP kılavuzu: OPcache yapılandırması