Site Haritası "URL'ye İzin Verilmiyor" Hatası Nasıl Çözülür?

Site haritası URL'ye izin verilmiyor hatası ne demek?

Site haritası "URL'ye izin verilmiyor" hatası, site haritası dosyanızın içinde, o dosyanın konumuna göre kapsam dışında kalan adreslerin bulunduğunu söyler. Adres farklı bir alan adına, farklı bir protokole ya da dosyanın bulunduğu klasörün üstüne işaret ediyor olabilir. Google bu satırları işlemez.

Search Console yardım sayfasında bu durum EN arayüzde "URL not allowed" adıyla geçer. TR ve DE arayüzde çeviri biraz farklı görünebilir, bu yüzden ekranınızda benzeri bir uyarı görürseniz aynı sorunu düşünün. Biz bu yazıda İngilizce adı parantezle veriyoruz.

Önemli bir ayrım var: bu hata dosyanın açılamamasıyla ilgili değildir. Google dosyayı açabilir, ancak içindeki bazı adresler dosyanın kapsamına uymaz. Dosya hiç okunamıyorsa farklı bir sorun vardır; onu site haritası okunamadı hatası yazımızda anlattık, burada tekrar etmiyoruz.

Search Console bu hatayı hangi durumlarda gösterir?

Google'ın Search Console yardım sayfası nedeni kısaca tarif eder: site haritası, dosyadan daha üst seviyede ya da farklı bir alan adında olan adresler içeriyor. Bu tarifin içinden gerçek hayatta dört tipik durum çıkar.

• Site haritası bir alt klasörde duruyor, ama içinde kök dizine ya da kardeş klasörlere ait adresler var.
• Adreslerin alan adı, site haritasının alan adından farklı yazılmış.
• Protokol uyuşmuyor; dosya bir protokolde, adresler diğerinde.
• Eklenti ya da CMS, taşıma sonrasında eski alan adını adreslere yazmaya devam ediyor.

Bu dört durumun ortak noktası şudur: adresin başlangıcı, site haritasının bulunduğu yerle birebir örtüşmez. Dolayısıyla çözümün yarısı doğru teşhistir. Hangi satırın hangi nedenle takıldığını bulduktan sonra düzeltme çoğu zaman kısa sürer.

Site haritasının konumu neden kapsamı belirler?

Google'ın site haritası oluşturma rehberi şunu söyler: Search Console üzerinden göndermediğiniz sürece bir site haritası yalnızca bulunduğu klasörün altındaki adresleri etkiler. Yani dosyanın adresi, kapsamın başlangıç noktasıdır.

Örnek bir senaryo kuralım. Site haritanız example.com/blog/sitemap.xml adresinde duruyor. Bu dosyanın doğal kapsamı example.com/blog/ ve altındaki sayfalardır. İçine example.com/hakkimizda/ gibi bir adres koyarsanız, o adres dosyadan daha üst seviyede kalır.

Bu yüzden Google, site haritasını kökte tutmanızı önerir. Kökte duran bir dosya, aynı alan adı altındaki tüm yolları kapsar. Böylece klasör kaynaklı hataların büyük kısmını baştan önlersiniz.

Bir noktayı da netleştirelim: bu kuralın Search Console üzerinden gönderimde nasıl işlediğini yardım sayfaları farklı cümlelerle anlatır. Biz kesin bir istisna iddia etmiyoruz. Güvenli yol, her durumda dosyayı kökte tutmak ve içine yalnızca o kapsama giren adresleri yazmaktır.

Hangi URL biçimleri site haritası URL'ye izin verilmiyor hatasını tetikler?

Search Console yardım sayfasındaki örnekleri iki gruba böleriz: dosyadan üst seviyedeki adresler ve farklı alan adındaki adresler. Aşağıdaki tablo bu örnekleri, kendi senaryolarımızla birleştirip özetler. Dosyanın https://www.example.com/sitemap.xml adresinde olduğunu varsayın.

Tablodaki sonuç basit: Google adresleri tam yazıldığı gibi tarar. Rehberde de "tam nitelikli, mutlak URL kullanın" yönünde bir öneri bulunur. Bu nedenle adresi kısaltmak ya da tahmin edilmesini beklemek hatayı büyütür.

www, http ve https farkı bu hatayı nasıl yaratır?

Bir adresin başındaki küçük farklar bile Google için ayrı bir kaynak demektir. Tarayıcıda hepsi aynı sayfaya gidebilir, ama site haritası kapsam kontrolü adresin yazılış biçimine bakar.

Tipik hikaye şöyle gelişir. Site yıllarca http ile yayındaydı, sonra SSL kurdunuz ve https'e geçtiniz. Yönlendirmeler çalışıyor, Search Console'da yeni mülkü https olarak eklediniz. Fakat site haritası eklentisi hâlâ eski ayarla çalışıp adreslere http yazıyor olabilir.

Aynı durum www için de geçerlidir. Mülkü www'li eklediyseniz ama adresler www'siz üretiliyorsa, satırların büyük kısmı kapsam dışı kalır. Üstelik bu sorunu çoğu zaman tek tek sayfalarda değil, tüm dosyada görürsünüz.

Çözümün ilk adımı, sitenizin tercih ettiği tek adres biçimini belirlemektir. Buna kanonik biçim diyoruz. Hangi biçimi seçtiğinizi canonical etiketlerinizle, yönlendirmelerinizle ve site haritanızla aynı tutun. Canonical konusunu ayrıntılı bilmek isterseniz canonical hatalarını Search Console'da tespit etme rehberimize bakın.

Alt alan adı ve klasör farkı site haritası kapsamını nasıl etkiler?

Alt alan adı, yani blog.example.com gibi bir adres, ana alan adından ayrı bir host sayılır. Dolayısıyla www.example.com üzerindeki bir site haritasına blog.example.com adresleri yazarsanız, bu satırlar farklı alan adı gerekçesiyle takılabilir.

Çoğu ekip bu hatayı büyüme aşamasında yapar. Ekip blogu ayrı bir alt alan adına taşıyor, ama ana siteyi üreten eklenti hâlâ tüm yazıları kendi dosyasına ekler. Sonuçta ana dosyada yüzlerce yabancı host satırı birikir.

Çözüm basittir: her host için kendi site haritasını kendi kökünde yayınlayın. Blog alt alan adının dosyası blog.example.com kökünde, ana sitenin dosyası ana sitenin kökünde dursun. Search Console'da da her mülke kendi dosyasını gönderin.

Klasör senaryosu ise şöyledir: dosya /tr/ klasöründeyse, /en/ klasöründeki sayfaları taşıyamaz. Çok dilli sitelerde bu yaygın bir tuzaktır. Dil klasörleri için ya kökte tek bir dizin dosyası kullanın ya da her dilin dosyasını kökte yayınlayın.

Taşıma sonrası eklenti yanlış alan adıyla site haritası üretir mi?

Evet, üretebilir ve bu, sahada en sık gördüğümüz nedenlerden biridir. Test ortamından canlıya, ya da eski alan adından yeniye taşıma yaptığınızda veritabanında eski adres kalmış olabilir. Eklenti, adresleri bu kayıtlı değerden üretir.

Belirtiler genellikle şunlardır:

• Site haritasını tarayıcıda açtığınızda adresler eski ya da geçici alan adıyla başlıyor.
• Dosya yeni alan adında duruyor, ama içindeki satırların tamamı başka bir host'u gösteriyor.
• Search Console, çok sayıda satırı aynı nedenle kapsam dışı sayıyor.

Düzeltme için önce sitenin genel ayarlarındaki site adresi alanlarını kontrol edin. Ardından eklentinin kendi ayarlarında sabit bir alan adı olup olmadığına bakın. Bazı eklentiler önbellekte eski dosyayı tutar; ayarı düzelttikten sonra dosyayı yeniden oluşturmak gerekir. Önbellek eklentisi kullanıyorsanız onu da temizleyin.

Taşımayı planlıyorsanız adres, yönlendirme ve site haritası kontrollerini baştan listeye alın. SEO migration ve site taşıma kontrol listemiz bu adımları sırayla toplar.

Hata mesajını gördüğünüzde ilk 10 dakikada ne yapmalısınız?

Panik gerekmez; bu hata genellikle sitenizi çökertmez, yalnızca ilgili satırların işlenmesini engeller. Yine de net bir sırayla ilerlemek zaman kazandırır. İlk adımlar şunlardır.

1. Search Console'da ilgili mülkü açın ve site haritası raporunda hatalı dosyanın ayrıntısına girin.
2. Hata örneğindeki satırı kopyalayın; adresin başlangıcını (protokol, www, alan adı) dikkatle okuyun.
3. Gönderdiğiniz mülkün tipini kontrol edin: alan adı mülkü mü, URL öneki mülkü mü?
4. Site haritası dosyasını tarayıcıda açın ve ilk birkaç adresin başlangıcını mülkle karşılaştırın.
5. Farkı bulun: http ve https, www, alt alan adı ya da klasör.
6. Kaynağı düzeltin; yani eklenti ayarını ya da dosyayı güncelleyin.
7. Düzelttikten sonra dosyayı yeniden gönderin ve raporu izleyin.

Bu sırayı izlerseniz tahminle ayar değiştirmekten kurtulursunuz. Kurtarma garantisi veremeyiz, ancak nedeni bulmak çoğu durumda mümkündür. Yardım sayfasının tarifi de aynı mantığa dayanır: adresler, dosyanın alan adı ve protokol seviyesiyle uyuşmalıdır.

Hatanın kaynağını nasıl teşhis edersiniz?

Teşhis, üç parçayı yan yana koymaktan ibarettir: Search Console mülkünüz, site haritasının adresi ve dosyanın içindeki adresler. Üçü aynı alan adı ve protokol ile başlamalıdır.

Önce mülk tipine bakın. Alan adı mülkü tüm alt alan adlarını ve protokolleri kapsayan bir görünüm sunar. URL öneki mülkü ise yalnızca yazdığınız öneki kapsar. Bu fark, hatanın görünürlüğünü etkileyebilir; çünkü öneki http olan bir mülke https dosyası göndermek ayrı bir sorundur.

Sonra dosyayı inceleyin. Küçük bir site için tarayıcıda açmak yeter. Büyük bir siteyse kaynak görünümünü kullanın ve ilk, orta ve son satırlara bakın. Eklentiler bazen birden fazla alt dosya üretir; her alt dosyayı ayrı kontrol edin.

Son olarak yönlendirmeleri sınayın. Dosyadaki bir adres başka bir adrese yönleniyorsa, nihai adres kapsam dışında kalabilir. Bu kontrolü ücretsiz yönlendirme denetleyici aracımızla hızlıca yapabilirsiniz.

Site haritası URL'ye izin verilmiyor hatası WordPress ve eklentilerde nasıl düzelir?

Çoğu sitede dosyayı bir SEO eklentisi ya da CMS'in kendi özelliği üretir. Bu durumda dosyayı elle düzenlemezsiniz; kaynağı düzeltirsiniz. Menü adları sürüme göre değiştiği için kesin buton adı vermeyeceğiz, ilgili ayar bölümünü kendi panelinizde bulmanız gerekir.

Kontrol edeceğiniz yerler şunlardır:

• Sitenin genel ayarlarındaki site adresi ve ana sayfa adresi alanları.
• Eklentinin site haritası ayarlarında özel bir alan adı ya da temel adres alanı olup olmadığı.
• Dil eklentisinin her dil için ayrı alan adı ya da klasör kullanıp kullanmadığı.
• Önbellek ve CDN katmanında eski dosyanın tutulup tutulmadığı.
• Sunucu yönlendirmesinin tercih ettiğiniz www ve https biçimine yönlendirip yönlendirmediği.

Bu ayarları düzelttikten sonra site haritasını tarayıcıda yeniden açın. Adreslerin yeni biçimde geldiğinden emin olun. Yalnızca bundan sonra Search Console'a dönün; çünkü eski dosya önbellekte kaldıysa aynı hatayı tekrar görürsünüz.

Kendi dosyanızı elle oluşturuyorsanız XML sitemap oluşturucu aracımız adresleri tam biçimde yazmanıza yardım eder.

Tek site haritasıyla birden fazla siteyi göndermek mümkün mü?

Google'ın rehberi buna izin verir. Birden fazla siteye ait adresleri tek dosyada toplayabilirsiniz; bu siteler farklı alan adlarında da olabilir. Ancak bunun koşulları vardır ve çoğu kullanıcı bu koşulları atlayıp hata alır.

Rehberdeki ifade şudur: robots.txt üzerinden çapraz gönderim yaparken her sitenin kendi robots.txt dosyası, kendi site haritasını göstermelidir. Yani başka bir sitenin dosyasını yalnızca siz ilan ederek kapsamına katamazsınız. Her alan adı sahipliğini ve bildirimini kendi tarafında yapar.

Bu nedenle "tek dosya, hepsini kapsasın" fikri çoğu küçük ve orta ölçekli sitede gereksizdir. Basit ve güvenli yol, her host için ayrı bir dosyadır. Çoklu alan adı kullanan kurumsal yapılarda ise sahiplik doğrulamalarını ve robots.txt bildirimlerini önceden planlamak gerekir.

Dikkat edin: başkasının sitesine ait adresleri, izinsiz biçimde kendi dosyanıza eklemek de, onların dosyasını kendi hesabınıza göndermek de doğru değildir. Sahip olmadığınız bir mülk için kapsam hatasını atlatmaya çalışmayın; Google'ın sistemlerini aldatma girişimi olarak okunabilir.

robots.txt ile site haritası bildirmek bu hatayı çözer mi?

Hayır, tek başına çözmez. robots.txt içinde site haritasının adresini bildirmek, Google'ın dosyayı bulmasına yardım eder. Fakat dosyanın içindeki adreslerin kapsam uyumu sorunu, bildirim yöntemi değişince ortadan kalkmaz.

Rehber, robots.txt dosyasında site haritası satırını herhangi bir yere ekleyebileceğinizi söyler. Google bu satırı, robots.txt dosyasını bir sonraki taramasında bulur. Sınırsız sayıda site haritası ekleyebilirsiniz, her biri ayrı satırda yer alır.

Bu yöntemi tamamlayıcı olarak kullanın. Search Console'da gönderim size durum ve hata raporu verir, robots.txt ise otomatik keşif sağlar. İkisini birlikte kullandığınızda keşfi garanti etmiş olmazsınız, ama keşif şansını artırırsınız.

Robots.txt'nin kendisini temiz tutmak da önemlidir. Yanlış bir engelleme kuralı, site haritasındaki adreslerin taranmasını durdurabilir. Temel bilgi için robots.txt rehberimize göz atın.

Alan adı mülkü mü, URL öneki mülkü mü seçmelisiniz?

Search Console'da iki mülk tipi vardır: alan adı mülkü ve URL öneki mülkü. Alan adı mülkü, o alan adının tüm protokollerini ve alt alan adlarını tek çatı altında toplar. URL öneki mülkü ise yalnızca yazdığınız tam öneki kapsar.

Bu fark, hata teşhisinde işinizi kolaylaştırır. Örneğin yalnızca https ile www önekini eklediyseniz, diğer biçimlerin verisini bu mülkte görmezsiniz. Bu durumda yanlış biçimde yazdığınız adresler hem rapor hem kapsam açısından kafa karıştırır.

Bizim önerimiz şudur: sahipliği olan siteler için alan adı mülkünü ayrıca ekleyin, günlük işler için de ihtiyaç duyduğunuz öneki ayrı mülk olarak tutun. Böylece hangi biçimde sorun olduğunu iki ekrandan karşılaştırabilirsiniz.

Mülk tipi bir sihirli çözüm değildir. Ne seçerseniz seçin, site haritasındaki adresler dosyanın alan adı ve protokolüyle uyumlu kalmalıdır. Mülk tipi yalnızca teşhisi kolaylaştırır.

Çok dilli sitelerde site haritası kapsamını nasıl kurarsınız?

Çok dilli sitelerde iki yaygın düzen vardır: dil klasörleri (örneğin /tr/ ve /en/) ya da dil başına ayrı alan adı. Her düzenin kendine özgü bir tuzağı var. Bu tuzakları bilmek, kapsam hatasını baştan önler.

Klasör düzeninde en güvenli yol, site haritasını kökte yayınlamaktır. Dil klasörünün içine konan bir dosya, kardeş dil klasörlerindeki adresleri taşıyamaz. Bu yüzden her dilin sayfalarını kökteki bir dosyada ya da kökten bağlanan bir dizin dosyasında toplayın.

Ayrı alan adı düzeninde ise her alan adı kendi dosyasını kendi kökünde yayınlar. Bir alan adının dosyasına diğerinin adreslerini yazmayın. Örneğin ülkeye özel alan adlarında bu hatayı çok sık görürüz.

Hreflang gibi dil işaretleri başka bir konudur. Burada yalnızca dosyanın kapsamıyla ilgileniyoruz. Dil sürümlerinizi ilişkilendirirken de adreslerin tam ve tutarlı yazıldığına dikkat edin.

Örnek senaryo: taşıma sonrası hatayı nasıl çözersiniz?

Aşağıdaki, gerçek bir müşteri değil, anlatım amaçlı kurguladığımız bir örnek senaryodur. Küçük bir firma sitesini test adresinden asıl alan adına taşıyor. Taşıma sonrası Search Console, site haritasının çoğu satırı için kapsam hatası veriyor.

Teşhis sırası şöyle ilerler. Önce dosyayı açarsınız ve adreslerin test alan adıyla başladığını görürsünüz. Sonra genel site adresi ayarına bakarsınız; orada hâlâ test adresini bulursunuz. Böylece eklenti, adresleri yanlış kaynaktan üretmektedir.

Düzeltme de üç adımdır: ayarı asıl alan adına çevirmek, önbelleği temizlemek ve dosyayı yeniden oluşturmak. Ardından dosyayı aynı mülke yeniden gönderirsiniz. Sonucu birkaç gün izlemeniz gerekir.

Bu örnekte ayrıca dikkat çeken bir nokta var: hata mesajı, sorunun kaynağını doğrudan söylemez. Mesaj yalnızca kapsam uyumsuzluğunu bildirir. Nedeni bulmak için dosyadaki adreslerle mülkü karşılaştırmak gerekir. Bu yüzden her taşıma sonrası ilk iş, site haritasını açıp birkaç adresin başlangıcına bakmak olmalıdır.

Bu senaryonun dersi şudur: sorun çoğu zaman sitenin kendisinde değil, taşıma sırasında unutulan bir ayardadır. Taşıma öncesinde hazırladığınız kontrol listesi bu tür unutkanlıkları azaltır.

Büyük sitelerde site haritası dizin dosyası kullanmak gerekir mi?

Sayfa sayısı büyüdükçe birden fazla site haritası dosyası üretmek yaygın bir pratiktir. Bu dosyaları tek bir dizin dosyasında toplamak yönetimi kolaylaştırır. Ancak dizin dosyasının kapsam kuralları da aynı mantıkla işler.

Dizin dosyası kökte durur ve alt dosyalara bağlantı verir. Alt dosyalar farklı bir alan adında ya da protokolde yer alırsa kapsam hatası yeniden doğabilir. Bu nedenle dizin dosyasındaki her bağlantıyı da aynı alan adı ve protokolle yazın.

Alt dosya sayısını ve sınırları resmi rehberden kontrol edin; bu konuda rakam yazmıyoruz, çünkü değişebilir. Dosya yönetimini sadeleştirmek için bölümleri içerik türüne göre ayırabilirsiniz: sayfalar, yazılar ve ürünler gibi.

Her alt dosyayı ayrı ayrı denetlemek zahmetli, ama hatalı satır genellikle tek bir alt dosyada toplanır. Search Console raporu hangi dosyanın sorunlu olduğunu gösterdiği için aramayı daraltabilirsiniz.

Site haritası URL'ye izin verilmiyor hatasında hangi yanlışlardan kaçınmalısınız?

Bu hatayı gören ekipler panikle yanlış hamleler yapabilir. En sık gördüğümüz yanlışları ve doğru alternatiflerini kısaca sıralayalım.

• Hatalı satırları rastgele silmek yerine, önce nedenini bulun ve kaynağı düzeltin.
• Her denemede yeni bir mülk eklemek yerine, doğru mülkü bir kez belirleyin.
• Başkasına ait bir siteyi kendi dosyanıza katmaya çalışmayın; bu kuralları aşma girişimidir.
• Hatayı gizlemek için yeni bir hesap ya da sahte sahiplik doğrulaması denemeyin.
• Dosyayı yalnızca elle düzenleyip eklentiyi atlamayın, çünkü eklenti dosyayı yeniden ürettiğinde eski hata geri gelir.

Bu yanlışların ortak sebebi acele etmektir. Oysa site haritası URL'ye izin verilmiyor uyarısı, tek bir ayar farkından çıkar. Sakin bir teşhis, çoğu durumda tek bir düzeltmeyle sonuçlanır.

Düzeltmeden sonra site haritasını nasıl yeniden gönderirsiniz?

Düzeltme tamamlandıktan sonra güncel dosyayı Search Console'da aynı mülke yeniden gönderirsiniz. Önce dosyanın canlı adresinde yeni içeriği gördüğünüzden emin olun; ardından gönderimi yapın.

Sıra şöyle olmalı:

1. Dosyayı tarayıcıda açın ve birkaç adresin başlangıcını kontrol edin.
2. Önbellek ya da CDN kullanıyorsanız temizleyin.
3. Search Console'da doğru mülkü seçin.
4. Site haritası bölümünde dosyanın adresini yeniden gönderin.
5. Rapordaki durumu birkaç gün boyunca izleyin.

Süre konusunda söz vermiyoruz. Google'ın yeniden işlemesi site büyüklüğüne ve tarama sıklığına göre değişir. Resmi kaynaklarda net bir gün sayısı verilmediği için bir süre uydurmuyoruz. Durum raporu değişmezse önce dosyanın gerçekten güncellendiğini yeniden doğrulayın.

Eski, hatalı dosyaları silmeyi unutmayın. Raporda kalan eski bir dosya, bitmiş sorunu hâlâ açıkmış gibi gösterebilir. Gereksiz kayıtları temizlemek raporu sade tutar.

Bu hata dizine eklemeyi ve sıralamayı etkiler mi?

Doğrudan sıralama cezası değildir. Hata, yalnızca kapsam dışı kalan adreslerin site haritasından işlenmemesi anlamına gelir. Google bu sayfaları başka yollarla, örneğin iç bağlantılar üzerinden yine bulabilir.

Yine de yan etkisi vardır. Site haritası, Google'a sayfalarınızın listesini sunan bir ipucudur. İpucu eksik kalırsa özellikle yeni ve az bağlantılı sayfaların keşfi gecikebilir. Bunun ne kadar sürdüğüne dair genel bir rakam veremeyiz; her site farklıdır.

Dolayısıyla önceliklendirme şöyle olmalıdır. Önce önemli sayfalarınızın site haritasında doğru adresle yer aldığından emin olun. Ardından iç bağlantı ve canonical yapınızı kontrol edin. Sayfaların neden dizine girmediğini ayrıca araştırmak istiyorsanız indexlenmeyen sayfaları tespit etme rehberimiz yol gösterir.

Bir de izleme alışkanlığı önerelim. Site haritası raporunda keşfedilen sayfa sayısını düzenli takip edin. Sayı beklenmedik biçimde düşerse, dosyada yine bir kapsam sorunu çıkmış olabilir. Böylece hatayı haftalar sonra değil, ilk günlerde fark edersiniz. Özellikle sık içerik yayınlayan sitelerde bu takip kıymetlidir.

Kısacası, hatayı ciddiye alın ama abartmayın. Doğru adresleri yayınlamak ucuz bir düzeltmedir ve gelecekteki keşif sorunlarını azaltır.

Bu hata "site haritası okunamadı" hatasından nasıl farklıdır?

İki hata farklı katmanlarda çalışır. "Okunamadı" türü uyarılar (EN arayüzde benzeri bir "Couldn't fetch" uyarısı) dosyaya erişimle ilgilidir. "URL'ye izin verilmiyor" ise dosya açıldıktan sonra içeriğin kapsamıyla ilgilidir.

Dosya hem erişim hem kapsam sorunu taşıyabilir. Önce erişimi çözün, ardından kapsamı denetleyin. Erişim tarafı için site haritası okunamadı hatası rehberimizi kullanın.

Site haritasının ne olduğunu ve nasıl hazırlandığını baştan öğrenmek isterseniz site haritası (sitemap) nedir yazımız temel bilgileri anlatır.

Aynı hatayı tekrar yaşamamak için hangi kontrol listesini uygularsınız?

Tekrarı önlemenin en etkili yolu, değişiklik yaptığınız her seferinde küçük bir kontrol rutini uygulamaktır. Özellikle taşıma, SSL geçişi, dil ekleme ve alt alan adı açma işlemlerinden sonra bu listeyi çalıştırın.

• Tercih ettiğiniz tek adres biçimini (https, www durumu) yazılı hale getirin.
• Site haritasını kökte yayınlayın ve alt klasöre koymaktan kaçının.
• Dosyadaki adreslerin tam ve mutlak olduğunu doğrulayın.
• Her alt alan adı için ayrı dosya ve ayrı mülk tanımlayın.
• Eklenti ayarlarındaki sabit alan adlarını taşıma sonrası güncelleyin.
• Önbellek ve CDN'i temizleyin.
• robots.txt içindeki site haritası satırını güncel adresle eşleştirin.

Bu listeyi takım içinde paylaşın; değişikliği yapan kişi de, onu denetleyen kişi de aynı sayfaya baksın. Ayrıca kalıcı bir not tutun: hangi mülk hangi dosyayı alır. Böylece aylar sonra yeni biri aynı hatayı yeniden üretmez.

Ekipçe izlediğimiz bir alışkanlık da şudur: büyük bir değişiklikten sonra Search Console site haritası raporunu bir kez açıp bakmak. Bu birkaç dakikalık kontrol, haftalarca sürebilecek bir fark edilmeyen hatayı yakalar.

Hangi durumda uzman desteği almak mantıklıdır?

Çoklu dil, çoklu alan adı ya da büyük katalog yapılarında hatanın kaynağı birden fazla katmanda saklanabilir. Eklenti, sunucu yönlendirmesi, CDN ve mülk tanımları aynı anda devreye girer. Bu noktada tek tek ayar değiştirmek, yeni hatalar üretebilir.

Talha Aslan ve ekibi olarak 2012'den beri saha içinde çalışıyoruz ve bu tür teşhisleri düzenli yapıyoruz. Sonuç garantisi vermeyiz; ancak sorunun kaynağını belgeleyip adım adım düzeltme planı çıkarmak mümkündür.

Genel bir SEO yol haritası arıyorsanız SEO danışmanlığı hizmetimizi inceleyebilirsiniz. Search Console'u baştan öğrenmek isterseniz Google Search Console rehberimiz iyi bir başlangıçtır.

Aynı partideki diğer Search Console durumlarına da göz atın: Core Web Vitals raporunda yeterli kullanım verisi yok uyarısı ve Google'ın benzer bazı girişleri çıkardık uyarısı ayrı yazılarda anlatıyoruz.

Not: Bu yazı genel bilgi içerir. Resmi arayüz metinleri ve menü adları değişebilir; güncel ayrıntıyı Google Search Central ve Search Console Yardım sayfalarından kontrol edin.