Search Console HTTPS Raporu: Sayfalarınız Neden HTTPS Olarak Sunulmuyor?

Kısacası bu rapor, HTTPS geçişinizin Google tarafında gerçekten tamamlanıp tamamlanmadığını gösteren bir aynadır. Tarayıcıda kilit simgesini görmeniz yeterli değildir. Çünkü Google bazı sayfalarınızın eski HTTP sürümünü hâlâ asıl adres olarak seçmiş olabilir. Biz Talha Aslan ve ekibi olarak teknik denetimlerde bu raporu ilk açtığımız ekranlardan biri olarak kullanıyoruz.

Google'ın resmi HTTPS raporu yardım sayfası, ideal durumu da açıkça tanımlıyor: raporda hiç HTTP URL'si görünmemeli. Yani hedefiniz, listedeki HTTP sayısını sıfıra yaklaştırmaktır.

HTTPS raporunu nerede bulursunuz, hangi mülklerde çalışır?

Raporu Search Console içinde tüm raporlar ve araçlar bölümünden (All reports and tools) açarsınız. Ancak her mülk türünde bu ekranı bulamazsınız. Google'a göre HTTPS raporu yalnız alan adı mülklerinde (Domain property) ve HTTPS ile başlayan URL öneki mülklerinde çalışır.

Bu ayrım pratikte önemlidir. Örneğin yıllar önce yalnız http://example.com için bir URL öneki mülkü açtıysanız raporu o mülkte bulamazsınız. Böyle bir durumda alan adı mülkü eklemenizi öneririz. Böylece HTTP, HTTPS, www ve www olmayan tüm sürümleri tek ekranda görürsünüz.

• Alan adı mülkü: raporu açabilirsiniz, rapor tüm protokol ve alt alan sürümlerini kapsar.
• HTTPS URL öneki mülkü: raporu açabilirsiniz, rapor yalnız o önekin altını kapsar.
• HTTP URL öneki mülkü: rapor bu mülkte yer almaz.

Search Console'u yeni kullanıyorsanız temel kurulum için Google Search Console rehberimize göz atabilirsiniz. Mülk doğrulaması tamam olmadan bu rapordaki veriye güvenmek doğru olmaz.

HTTPS raporundaki sayılar size tam olarak ne anlatıyor?

Rapor iki temel sayı gösterir: dizindeki HTTPS URL'leri ve dizindeki HTTP URL'leri. Ardından HTTP tarafındaki adresleri sorun nedenlerine göre gruplar. Bu nedenle ilk bakışta oranı, ikinci bakışta hata dağılımını okursunuz.

Yalnız bir noktayı gözden kaçırmayın. Google, raporun tüm URL'lerin eksiksiz listesi olmadığını, bir örnek (sample) gösterdiğini belirtiyor. Dolayısıyla listede 40 adres görmeniz, sorunun yalnız 40 sayfada olduğu anlamına gelmez. Raporu bir belirti haritası gibi okuyun; kök nedeni sunucu ayarında, CMS ayarında ya da şablonda arayın.

Pratikte listedeki adresleri türlerine göre ayırmak işinizi kolaylaştırır. Örneğin blog yazıları, ürün sayfaları ve kategori sayfaları ayrı şablonlardan geliyorsa hatanın hangi şablonda yoğunlaştığını hemen görürsünüz. Böylece düzeltmeyi tek noktada yapar, etkisini tüm grupta izlersiniz.

Bir de karşılaştırma mantığına dikkat edin. Rapor her HTTP adresi için parametreleri yok sayarak birebir aynı yoldaki HTTPS adresine bakar. Öte yandan farklı bir URL yapısı kullanan alternatif bir HTTPS sürümünü dikkate almaz. Örneğin http://example.com/urun?id=5 adresini https://example.com/urunler/5 adresine taşıdıysanız rapor bu eşleşmeyi kurmaz.

Sayfalarınız neden HTTPS olarak sunulmuyor, başlıca nedenler neler?

Google yardım sayfası nedenleri belirli hata adlarıyla sınıflandırır. Türkçe arayüzdeki adlar zaman zaman değişebildiği için İngilizce adları da parantez içinde veriyoruz. Raporda en sık karşılaşacağınız gruplar şunlardır:

1. HTTP sayfası canonical etiketiyle işaretli (HTTP marked with canonical tag).
2. HTTPS sürümünde geçersiz sertifika var (HTTPS has invalid certificate).
3. Site haritası HTTP adresini gösteriyor (Sitemap points to HTTP).
4. HTTPS adresi yönlendiriyor (HTTPS has redirect).
5. HTTPS adresi robots.txt ile engelli (HTTPS URL is roboted).
6. Google HTTPS sürümünü değerlendiremedi (HTTPS not evaluated).
7. Diğer sorunlar (Other issues).

Bu grupların çoğu tek bir şablon ya da sunucu kuralından doğar. Örneğin tek bir yanlış canonical ayarı binlerce sayfayı aynı anda etkiler. Bu yüzden listeyi sayfa sayfa düzeltmek yerine önce ortak nedeni bulmanızı öneririz. Sıradaki bölümlerde her nedeni ayrı ayrı açıyoruz.

"HTTP marked with canonical tag" hatası ne anlama gelir?

Bu hata, HTTP sayfanızın rel="canonical" etiketiyle kendini asıl sürüm olarak işaret ettiğini söyler. Yani sayfa HTTPS üzerinden açılsa bile içindeki etiket Google'a "asıl adresim HTTP" diyor. Google da bu sinyali dikkate alıp HTTP sürümünü dizinde tutabilir.

Bu durumla özellikle eski temalarda ve elle hazırlanan şablonlarda karşılaşırsınız. Örneğin canonical adresi sabit bir "http://" önekiyle üretiliyorsa, HTTPS geçişinden sonra bile etiket eski protokolü basmaya devam eder. Benzer şekilde CMS ayarlarında site adresi HTTP olarak kalmışsa eklentiler de yanlış canonical üretir.

Çözüm, HTTPS sürümünü canonical olarak bildirmektir. Google, eksik HTTPS sorunlarında da önerilen çözüm olarak HTTPS sürümünü açıkça canonical işaretlemeyi gösteriyor. Etiketin genel mantığını canonical etiketi rehberimizde anlattık. Ayrıca sitedeki canonical tutarsızlıklarını toplu bulmak için canonical hatalarını Search Console ile tespit etme yazımıza bakabilirsiniz.

Geçersiz sertifika hatasını nasıl giderirsiniz?

Bu hata, HTTPS adresinin geçersiz bir SSL sertifikasına sahip olduğunu gösterir. Google'ın notuna göre sertifika sorunu genellikle tek sayfayı değil, sitenin tamamını etkiler. Bu nedenle listede bu hatayı görüyorsanız önce sertifikanın kendisine bakın.

Sık rastladığımız nedenleri şöyle sıralayabiliriz:

• Sertifikanın süresi dolmuş ve otomatik yenileme çalışmamış.
• Sertifika www sürümünü kapsıyor ama www olmayan sürümü kapsamıyor ya da tersi.
• Ara sertifika (zincir) eksik, bazı istemciler bağlantıyı reddediyor.
• Alan adını başka bir sunucuya taşıdınız ama eski sertifika orada kaldı.

Düzeltme için sertifikayı yenileyin ve tüm alt alan sürümlerini kapsadığından emin olun. Ardından birkaç farklı tarayıcı ve cihazla siteyi açın. Sertifikanın temel işleyişini SSL sertifikası nedir yazımızda anlattık. Barındırma şirketiniz sertifikayı yönetiyorsa yenileme ayarını onlarla birlikte kontrol edin.

Site haritası HTTP adresleri gösteriyorsa ne yapmalısınız?

Bu hata, site haritanızın HTTP bir URL listelediğini ve Google'ın o HTTP adresini canonical olarak dizine aldığını söyler. Google'a göre bu hata yalnız ilgili HTTP adresi başarıyla taranıp dizine eklendiyse görünür. Yani site haritası Google'a hâlâ eski adresi öneriyor demektir.

Çözüm basittir: site haritalarını HTTPS sürümleri listeleyecek şekilde güncellersiniz. Ancak sorunun kaynağı çoğu zaman elle eklenen eski bir harita dosyasıdır. Örneğin sitede hem eklentinin ürettiği dinamik harita hem de yıllar önce birinin yüklediği statik bir dosya durabilir.

Google'ın site taşıma rehberi de yeni HTTPS adresleri içeren bir site haritası oluşturup Search Console'a göndermenizi öneriyor. Eski haritayı ardından kaldırabilirsiniz. Haritayla ilgili okuma sorunları yaşıyorsanız site haritası okunamadı hatası yazımız yardımcı olur.

HTTPS adresi HTTP'ye yönleniyorsa sorun nerede?

Bu hata, HTTPS adresinin var olduğunu ama ziyaretçiyi HTTP bir adrese yönlendirdiğini gösterir. Google'ın önerisi nettir: yönlendirmeyi kaldırın ya da bir HTTPS sayfasına yönlendirin. Aksi halde Google güvenli sürümü asıl adres olarak seçemez.

Peki bu ters yönlendirme nereden çıkar? Çoğunlukla eski bir sunucu kuralından, CDN ayarından ya da CMS'teki site adresi alanından doğar. Örneğin sunucu HTTP'yi HTTPS'e yönlendirirken CMS her isteği tekrar HTTP adresine gönderiyorsa döngü oluşur. Böyle bir döngüyü yönlendirme döngüsü hatası rehberimizde ayrıca ele aldık.

Bu yüzden her ayarı tek tek kontrol etmeniz gerekir: sunucu kuralları, CDN ayarları, CMS'teki site adresi ve eklentilerin yönlendirme listesi. Ardından tarayıcının geliştirici araçlarıyla tüm yönlendirme adımlarını izleyin. Son adres HTTPS olmalı; arada HTTP adımı olmamalı.

robots.txt HTTPS adresini engelliyor olabilir mi?

Evet, rapor bunu da ayrı bir hata grubu olarak listeler. HTTPS adresi robots.txt kuralıyla taramaya kapalıysa Google güvenli sürümü okuyamaz. Dolayısıyla elindeki tek okunabilir sürüm olan HTTP sayfasını dizinde tutar.

Bu sorun genellikle iki şekilde ortaya çıkar. Birincisi, HTTP ve HTTPS sürümleri farklı robots.txt dosyaları sunar; örneğin geliştirme döneminden kalan "her şeyi engelle" kuralı yalnız HTTPS tarafında kalmıştır. İkincisi, bir dizini engelleyen kural geçişten sonra yeni URL yapısını da kapsar hale gelir.

Çözüm için iki protokolde de robots.txt dosyasını açıp karşılaştırın. Ardından engelleyen kuralı düzeltin. Sık yapılan robots.txt hatalarını robots.txt hataları yazımızda listeledik. Kuralı değiştirdikten sonra Search Console'daki robots.txt raporundan dosyanın güncel halinin okunduğunu doğrulayın.

"HTTPS not evaluated" uyarısını nasıl çözersiniz?

Bu grup, Google'ın HTTPS sürümünü değerlendiremediğini söyler. Google yardım sayfası birkaç olası neden sayar. Örneğin eşdeğer HTTPS adresi hiç yoktur ya da 404, kimlik doğrulama gibi 4XX veya 5XX hatası döndürür. Ya da iki sürüm de vardır ama Google HTTP sürümünü canonical seçmiştir.

Öte yandan başka nedenler de mümkündür. Google çok fazla hatayla karşılaşıp sıradaki URL'leri işlemeyi durdurmuş olabilir. Site genelindeki bir sertifika hatası değerlendirmeyi engelliyor olabilir. Ya da Google adresi henüz görmemiş ve taramamıştır.

Google'ın önerdiği sıra şöyledir: rapordaki diğer hatalar çoksa önce onları düzeltin, çünkü bu işlem kuyruğu açabilir. Adres yeni tarandıysa bir gün bekleyip tekrar bakın. Diğer hata azsa site geneli HTTPS sorunlarını, tarama istatistikleri raporundaki erişilebilirlik sorunlarını ve sayfa dizine ekleme raporundaki 404'leri kontrol edin. Dizine girmeyen sayfaları toplu bulmak için dizine eklenmeyen sayfalar rehberimizi kullanabilirsiniz.

Karışık içerik HTTPS raporunu etkiler mi?

Karışık içerik (mixed content), HTTPS ile açılan bir sayfanın görsel, betik ya da stil dosyası gibi kaynakları HTTP üzerinden yüklemesidir. HTTPS raporu karışık içeriği ayrı bir hata grubu olarak listelemez. Ancak bu sorun, geçişin yarım kaldığının en güçlü işaretlerinden biridir.

web.dev'in karışık içerik açıklamasına göre tarayıcılar bazı HTTP kaynakları engeller, bazılarını ise uyarıyla yükler. Sonuçta sayfa bozuk görünebilir ya da kilit simgesi kaybolabilir. Ziyaretçi açısından bu güven kaybıdır.

Karışık içerik çoğunlukla veritabanında kayıtlı eski içerik adreslerinden doğar. Örneğin yıllar önce yazılan blog yazılarındaki görseller "http://" ile kaydedilmiştir. Bu yüzden şablonu düzeltmek tek başına yetmez; içerikteki eski adresleri de güvenli biçimde güncellemeniz gerekir. Toplu değişiklikten önce mutlaka veritabanı yedeği alın.

Karışık içeriği bulmak için tarayıcının geliştirici araçlarındaki konsol sekmesi iyi bir başlangıçtır. Sayfayı açtığınızda HTTP üzerinden yüklenen kaynaklar burada uyarı olarak listelenir. Ardından aynı kontrolü farklı şablonlardan seçtiğiniz birkaç sayfada tekrarlayın; böylece sorunun şablonda mı, içerikte mi olduğunu ayırırsınız.

Canonical ve 301 yönlendirmeyi birlikte nasıl kurmalısınız?

En sağlam yapı, sinyallerin hepsinin aynı adresi göstermesidir. Google'ın yinelenen URL'leri birleştirme rehberi de canonical seçiminde birden fazla sinyalin rol oynadığını anlatır. Yönlendirme, canonical etiketi, site haritası ve iç linkler aynı yönde olmalıdır.

Uygulamada şu düzeni öneriyoruz:

• Her HTTP adresi sunucu tarafında kalıcı yönlendirmeyle (301 veya 308) aynı yoldaki HTTPS adresine gider.
• Her HTTPS sayfası kendi HTTPS adresini canonical olarak gösterir.
• Site haritası yalnız HTTPS adreslerini listeler.
• İç linkleriniz doğrudan HTTPS adreslerini gösterir, yönlendirmeden geçmez.

Yönlendirme türleri arasındaki farkı 301, 302, 307 ve 308 farkı yazımızda anlattık. Ayrıca zincir halinde birden fazla yönlendirme varsa bunları tek adıma indirin.

Hangi HTTPS raporu hatası hangi düzeltmeyi ister?

Aşağıdaki tablo, Google yardım sayfasındaki hata gruplarını ve önerilen düzeltmeleri özetliyor. Ekibimiz teknik denetimde bu tabloyu bir başlangıç haritası olarak kullanır.

Tablo bir sıralama da önerir. Önce site geneli sorunları (sertifika, yönlendirme) çözersiniz, ardından şablon sorunlarına (canonical, harita) geçersiniz. Son olarak tekil adreslere bakarsınız.

Bir öneri daha ekleyelim: her düzeltmeyi tarih ve kısa açıklamayla bir değişiklik günlüğüne yazın. Böylece raporda bir değişim gördüğünüzde hangi adımın etkili olduğunu kolayca ilişkilendirirsiniz. Ayrıca ekipte farklı kişiler çalışıyorsa aynı ayarı iki kez değiştirme riskini de azaltırsınız.

Adım adım HTTPS düzeltme kontrol listesi nasıl olmalı?

Raporda hata gördüğünüzde aşağıdaki sırayı izlemenizi öneririz. Bu sıra, büyük etkili sorunları önce kapatır ve gereksiz tekrar işini azaltır.

1. Sertifikanın geçerli olduğunu ve tüm alt alan sürümlerini kapsadığını doğrulayın.
2. HTTP'den HTTPS'e kalıcı yönlendirmenin tek adımda çalıştığını test edin.
3. HTTPS adreslerin hiçbir koşulda HTTP'ye geri yönlenmediğini kontrol edin.
4. Şablondaki canonical etiketinin HTTPS adres ürettiğini görün.
5. CMS'teki site adresi ayarını HTTPS olarak güncelleyin.
6. Site haritasını HTTPS adreslerle yeniden oluşturup Search Console'a gönderin.
7. İki protokolde robots.txt dosyasını karşılaştırın.
8. İçerikteki eski HTTP kaynak adreslerini ve iç linkleri güncelleyin.
9. Birkaç örnek adresi URL Denetimi aracında canlı test edin.
10. Raporu birkaç hafta boyunca düzenli izleyin.

Bu listeyi her geçişte aynı sırayla uygularsanız sorunların büyük kısmını erken yakalarsınız. Yine de her sitenin altyapısı farklıdır; liste bir çerçevedir, garanti değildir.

Düzeltmeyi URL Denetimi aracıyla nasıl test edersiniz?

Google yardım sayfası, canonical hatasını test etmek için URL Denetimi aracını önerir. Raporda ilgili adresin yanındaki denetim simgesine tıklarsınız. Ardından URL Denetimi'ni seçip canlı testi (Live test) çalıştırırsınız.

Canlı test tamamlanınca test edilen sayfayı görüntüle (View tested page) bölümünü açarsınız. Burada Google'ın gördüğü HTML kodunda canonical etiketini ararsınız. Etiket HTTPS adresi gösteriyorsa Google şablon düzeltmenizi okumuş demektir.

Ayrıca aynı araçta Google'ın seçtiği canonical adresi ile sizin bildirdiğiniz canonical adresi karşılaştırabilirsiniz. İki adres farklıysa sinyallerden biri hâlâ çelişkilidir. Bu durumda iç linkleri, site haritasını ve yönlendirmeleri yeniden gözden geçirin. Google'ın yardım sayfası raporda ayrı bir doğrulama özelliğinden söz etmediği için canlı test en pratik kontrol yöntemidir.

Bazı hatalar neden kendiliğinden kaybolur?

Google, bazı hataların zamanla kendiliğinden düzeldiğini belirtir. Bunun nedeni basittir: Google HTTP sayfayı, HTTPS sayfa yayına girmeden ya da taranmadan önce taramış olabilir. Dolayısıyla rapor bir süre eski durumu yansıtır.

Bu yüzden yeni bir geçişten hemen sonra rapordaki her satıra panikle müdahale etmeyin. Çünkü aceleyle yapılan değişiklikler, sorunsuz çalışan bir ayarı da bozabilir ve tabloyu daha karmaşık hale getirebilir. Bunun yerine sakin bir sırayla ilerleyin. Önce yapısal kontrolleri tamamlayın. Ardından Google'ın siteyi yeniden taramasına zaman tanıyın. Yalnız birkaç haftadan sonra hâlâ aynı adreslerde aynı hata kalıyorsa kalıcı bir nedeni araştırın.

Öte yandan Google bir uyarı daha yapar. Google, denediği ilk HTTPS adreslerinde çok sayıda 404 alırsa HTTPS sayfaları taramaktan vazgeçebilir. Bu durumda rapor "HTTPS crawling issue" ve diğer sorunlar gibi hatalar gösterebilir. Kısacası geçişi yarım bırakmak, beklemekten çok daha fazla zarar verir.

HTTPS geçişinden önce hangi hazırlıkları yapmalısınız?

Raporda hata görmemenin en kolay yolu, geçişi baştan planlı yapmaktır. Google'ın site taşıma rehberi, HTTPS geçişlerinde hem HTTP hem HTTPS sürümlerini Search Console'da doğrulamanızı önerir. Ayrıca HTTP'den HTTPS'e geçişte adres değişikliği aracını (Change of Address) kullanmanız gerekmediğini belirtir.

Hazırlık aşamasında şu soruları cevaplamanızı öneririz:

• Sitedeki tüm alt alan adlarının listesi elinizde mi?
• Sertifika bu alt alanların hepsini kapsıyor mu?
• CMS, CDN ve sunucu katmanlarından hangisi yönlendirmeyi yönetecek?
• Şablonlar canonical ve iç linkleri doğru HTTPS adresle üretiyor mu?
• Eski site haritaları, harici servislerdeki adresler ve reklam hedef adresleri listenizde var mı?

Bu listeyi önceden kapatırsanız geçiş gününde sürprizle karşılaşma olasılığınız düşer. Üstelik geçişten sonra HTTPS raporunu okumak çok daha kolaylaşır, çünkü kalan hatalar gerçekten istisnai durumları gösterir.

HTTP ve HTTPS sürümleri aynı anda açık kalırsa ne olur?

İki sürüm de 200 yanıtı veriyorsa Google aynı içeriğin iki kopyasını görür. Google'a göre bir sayfa iki protokolde de varsa Google HTTPS sürümünü dizine almayı tercih eder. Ancak bu tercih, diğer sinyaller çelişmediği sürece anlam taşır.

Örneğin HTTP sürümü kendi canonical etiketini taşıyorsa, iç linkler HTTP'yi gösteriyorsa ve site haritası HTTP listeliyorsa Google HTTP sürümünü seçebilir. Bu durumda raporda "HTTPS not evaluated" grubunda adresler görürsünüz. Google yardım sayfası da bu nedeni açıkça sayar: iki sürüm de vardır ama Google HTTP sürümünü canonical seçmiştir.

Bu yüzden iki sürümü uzun süre paralel açık bırakmayın. Geçiş gününde kalıcı yönlendirmeyi devreye alın. Böylece Google'ın elinde tek bir okunabilir sürüm kalır ve sinyaller tek adreste birleşir. Ayrıca ziyaretçileriniz de her zaman güvenli bağlantıya ulaşır.

İç linkler ve harici bağlantılar HTTPS raporunu nasıl etkiler?

İç linkler, Google'ın sayfalarınızı keşfetme yolunun önemli bir parçasıdır. Menü, alt bilgi ya da içerik içindeki linkler HTTP adresi gösteriyorsa Google her taramada önce HTTP adrese gider. Yönlendirme çalışsa bile bu durum gereksiz bir adım ekler ve canonical seçimine zayıf ama çelişkili bir sinyal verir.

Bu nedenle iç linkleri doğrudan HTTPS adreslere çevirmenizi öneririz. Özellikle şu alanlara bakın:

• Ana menü ve alt bilgi linkleri.
• Eski blog yazılarındaki içerik içi linkler.
• Ürün açıklamaları ve kategori metinleri.
• Yapılandırılmış veri içindeki adresler.

Harici sitelerdeki eski linkleri ise tek tek değiştiremezsiniz. Yine de önemli iş ortaklarınızdan ve kendi sosyal medya profillerinizden gelen linkleri güncellemek kolaydır. Geri kalanlar için kalıcı yönlendirme işi üstlenir; bu yüzden yönlendirmeyi uzun süre açık tutun. Bu konuyu 301 yönlendirme ne kadar süre kalmalı yazımızda ayrıca inceledik.

HTTPS raporunu hangi sıklıkla kontrol etmelisiniz?

Geçişten hemen sonraki haftalarda raporu sık kontrol etmenizi öneririz. Çünkü bu dönemde Google eski ve yeni adresleri yeniden tarar, rapor da hızla değişir. Daha sonra aylık kontrol çoğu site için yeterlidir.

Bununla birlikte bazı olaylar raporu yeniden kontrol etmenizi gerektirir. Örneğin tema değişikliği, sunucu taşıma, CDN kurulumu, sertifika sağlayıcısını değiştirme ya da yeni bir dil sürümü ekleme bunlardan bazılarıdır. Bu tür değişikliklerden sonra birkaç gün içinde raporu açın.

Ayrıca HTTPS raporunu tek başına okumayın. Sayfa dizine ekleme raporu, tarama istatistikleri raporu ve site haritaları raporu birlikte daha net bir tablo çizer. Google da "HTTPS not evaluated" hatalarında bu raporlara bakmanızı önerir. Kısacası HTTPS raporu, teknik SEO takibinizin düzenli bir parçası olmalıdır.

Çok dilli ve alt alan adlı sitelerde HTTPS raporu nasıl okunur?

Çok dilli sitelerde dil sürümleri çoğu zaman ayrı klasörlerde ya da alt alan adlarında durur. Bu yüzden HTTPS raporunu okurken önce hangi sürümün etkilendiğini ayırın. Örneğin yalnız en.example.com altındaki adresler listede çıkıyorsa sorun büyük olasılıkla o alt alanın sertifikasında ya da yönlendirme kuralındadır.

Ayrıca hreflang etiketlerindeki adresleri de kontrol edin. Dil sürümleri birbirini HTTP adreslerle gösteriyorsa Google'a yine çelişkili bir sinyal gider. Kısacası canonical, hreflang, site haritası ve iç linkler aynı protokolü kullanmalıdır.

Alan adı mülkü bu tür sitelerde büyük kolaylık sağlar. Tüm alt alanları tek ekranda görür, sorunun nerede yoğunlaştığını hızla anlarsınız. Ardından her alt alan için ayrı bir URL öneki mülkü açarak ayrıntılı inceleme yapabilirsiniz.

Örnek senaryo: HTTP sürümü neden hâlâ dizinde kalır?

Bu bölüm gerçek bir müşteri vakası değil, eğitim amaçlı bir örnek senaryodur. Bir işletme example.com sitesini HTTPS'e taşıyor ve sunucuya yönlendirme kuralı ekliyor. Ancak birkaç hafta sonra HTTPS raporunda yüzlerce HTTP adresi görüyor.

İnceleme sırasında üç ortak neden çıkıyor. Birincisi, tema canonical adresini sabit "http://" önekiyle üretiyor. İkincisi, kök dizinde eski statik bir site haritası duruyor ve Search Console'da hâlâ o harita kayıtlı. Üçüncüsü, ürün kategorilerindeki iç linkler veritabanında HTTP olarak kayıtlı.

Düzeltme sırası da bellidir. Önce canonical şablonunu düzeltiyorsunuz, ardından eski haritayı kaldırıp yenisini gönderiyorsunuz. Son olarak iç linkleri güncelliyorsunuz. Böylece yönlendirme, canonical, harita ve iç linkler aynı HTTPS adresini gösteriyor. Rapordaki HTTP sayısının ne hızda düşeceği ise Google'ın tarama takvimine bağlıdır; burada süre vaat etmek doğru olmaz.

HTTPS raporu sorunlarını ne zaman uzmana bırakmalısınız?

Hata tek bir şablondan geliyorsa çoğu zaman kendiniz düzeltebilirsiniz. Ancak sunucu, CDN ve CMS katmanları birbirine karıştıysa, döngüler ya da çelişkili canonical sinyalleri varsa işi bir uzmanla yürütmek zaman kazandırır. Özellikle e-ticaret ve çok dilli sitelerde tek bir yanlış kural binlerce sayfayı etkiler.

Biz Talha Aslan ve ekibi olarak SEO danışmanlığı kapsamında HTTPS raporunu, yönlendirme yapısını, canonical sinyallerini ve site haritasını birlikte inceliyoruz. Bu sorunu sitenizde biz çözer, ardından Search Console üzerinden düzenli takip ederiz. Sıralama garantisi vermiyoruz; ancak teknik engelleri kaynağında temizleyip ilerlemeyi şeffaf biçimde raporluyoruz.

Sitenizin HTTPS raporunda çözemediğiniz hatalar varsa SEO danışmanlığı sayfamızdan teklif alabilirsiniz. Kısa bir ön bilgi formu doldurmanız yeterli; ekibimiz sitenize özel kapsamı belirleyip size döner.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.