HTTPS Geçişi ve SEO Etkisi: Bilmeniz Gerekenler

Yıllar önce bir müşterinin sitesini HTTP’den HTTPS’e geçirdikten sonra organic trafiğin %40 düştüğünü görünce ciddi bir panik yaşamıştık. O gün öğrendiklerim, bu geçişin ne kadar dikkatli yapılması gerektiğini bana çok net gösterdi. HTTPS geçişi artık bir tercih değil, zorunluluk. Ama yanlış yapıldığında SEO açısından felakete dönüşebilir.

HTTPS Geçişinin SEO Üzerindeki Temel Etkisi

Google, 2014’ten beri HTTPS’i bir sıralama sinyali olarak kullanıyor. Yani teorik olarak HTTPS’e geçmek SEO’ya katkı sağlamalı. Ama pratikte işler çok daha karmaşık. Geçiş sürecindeki her hata, arama motorlarının sitenizi yeniden indekslemesiyle birlikte sıralamalarınızı olumsuz etkileyebilir.

Temel mesele şu: Arama motorları için http://siteniz.com ve https://siteniz.com tamamen farklı iki URL’dir. Geçiş sırasında doğru yönlendirmeler yapılmazsa, Google iki ayrı site görür ve link juice’un büyük kısmı eski HTTP URL’lerinde kalır.

# Sitenizin mevcut HTTPS durumunu kontrol edin
curl -I http://siteniz.com
curl -I https://siteniz.com

# SSL sertifika bilgilerini görüntüleyin
openssl s_client -connect siteniz.com:443 -servername siteniz.com 2>/dev/null | openssl x509 -noout -dates

Geçiş Öncesi Yapılması Gerekenler

Geçişe başlamadan önce mevcut durumunuzu belgelemeniz şart. Hangi sayfaların sıralamada olduğunu, backlink profilinizi ve crawl verilerinizi kaydedin. Bu veriler olmadan geçiş sonrası neyin değiştiğini anlayamazsınız.

Mevcut HTTP URL Envanterini Çıkarın

# Sitemap'teki tüm URL'leri çekin ve kaydedin
wget -q -O - https://siteniz.com/sitemap.xml | grep -oP '(?<=<loc>)[^<]+' > http_urls_before.txt

# Mevcut sayfaları crawl edin ve response kodlarını kaydedin
while IFS= read -r url; do
    status=$(curl -o /dev/null -s -w "%{http_code}" "$url")
    echo "$status $url"
done < http_urls_before.txt > crawl_report_before.txt

Bu listeyi elinizde bulundurun. Geçiş sonrasında her URL için 301 yönlendirmesini doğrulamanız gerekecek.

Google Search Console Verilerini Dışa Aktarın

Geçiş öncesi performans verilerinizi mutlaka indirin. Impression sayıları, click-through rate’ler, hangi sorguların hangi sayfalardan geldiği gibi veriler geçiş sonrası karşılaştırma için altın değerinde.

Ayrıca mevcut backlink profilinizi de kaydedin. Ahrefs, Semrush veya benzeri araçlardan tüm backlink listesini CSV olarak indirin. Bu linklerin büyük çoğunluğu hâlâ HTTP’ye işaret edecek ve yönlendirme zinciriyle çalışacak, ama bir kısmını doğrudan HTTPS’e güncelleyebilirseniz link juice kaybını minimuma indirirsiniz.

301 Yönlendirme Yapılandırması

Bu aşama geçişin kalbi. Hatalı yapılan yönlendirmeler hem SEO’yu hem de kullanıcı deneyimini mahveder.

Apache için .htaccess Yapılandırması

# /etc/apache2/sites-available/siteniz.conf veya .htaccess dosyanıza ekleyin
<VirtualHost *:80>
    ServerName siteniz.com
    ServerAlias www.siteniz.com
    
    # Tüm HTTP trafiğini HTTPS'e yönlendir
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

Nginx için Yönlendirme Yapılandırması

# /etc/nginx/sites-available/siteniz.conf
server {
    listen 80;
    server_name siteniz.com www.siteniz.com;
    
    # Kalıcı yönlendirme - 302 değil 301 kullanın
    return 301 https://siteniz.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name siteniz.com;
    
    ssl_certificate /etc/letsencrypt/live/siteniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/siteniz.com/privkey.pem;
    
    # HSTS başlığı ekleyin (dikkatli kullanın, geri dönüşü zor)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    
    # Diğer yapılandırmalar...
}

Kritik nokta: 302 geçici yönlendirme kullanmayın. Google, 302 yönlendirmelerde link juice’u orijinal URL’de tutar. 301 kalıcı yönlendirme, arama motorlarına “bu URL artık burada” mesajını net olarak verir.

www ve non-www Tutarlılığı

Birçok sitede www ve non-www versiyonlarının ikisi de aktif çalışıyor olur. Bu, geçiş sonrası duplicate content sorununa zemin hazırlar.

# Hangi versiyonun canonical olduğunu test edin
curl -Ls -o /dev/null -w "%{url_effective}" http://www.siteniz.com
curl -Ls -o /dev/null -w "%{url_effective}" http://siteniz.com

# Her iki versiyonu da HTTPS'in doğru versiyonuna yönlendirin
# Örneğin www olmayan versiyonu tercih ediyorsanız:
# http://www.siteniz.com -> https://siteniz.com (301)
# http://siteniz.com -> https://siteniz.com (301)

Mixed Content Sorunu ve SEO Etkisi

HTTPS’e geçtikten sonra en sık karşılaşılan problem mixed content. Sayfanız HTTPS üzerinden sunuluyor ama içinde HTTP’den yüklenen resimler, scriptler veya CSS dosyaları var. Bu durum hem tarayıcı güvenlik uyarılarına hem de Google’ın sitenizi tam güvenli kabul etmemesine yol açar.

# Sitenizdeki mixed content sorunlarını tespit edin
# wget ile sayfaları çekip HTTP referanslarını arayın
wget -q -O - https://siteniz.com | grep -E 'http://[^s]' | grep -E '(src|href|action)='

# Daha kapsamlı tarama için Python kullanabilirsiniz
python3 -c "
import urllib.request
import re

url = 'https://siteniz.com'
response = urllib.request.urlopen(url)
content = response.read().decode('utf-8')
http_refs = re.findall(r'http://[^s"']+', content)
for ref in http_refs:
    print(ref)
"

WordPress’te Mixed Content Düzeltmesi

WordPress kullanıyorsanız, veritabanındaki HTTP referanslarını toplu olarak güncellemek gerekir.

# WP-CLI ile veritabanındaki URL'leri güncelle
wp search-replace 'http://siteniz.com' 'https://siteniz.com' --all-tables --dry-run

# Dry run sonuçlarına bakın, sorun yoksa çalıştırın
wp search-replace 'http://siteniz.com' 'https://siteniz.com' --all-tables

# Önbelleği temizleyin
wp cache flush

Bu komut çalıştırıldığında veritabanındaki tüm tablolarda http://siteniz.com ifadesini bulup https://siteniz.com ile değiştirir. Media URL’leri, widget ayarları, sayfa içerikleri dahil her yerde güncelleme yapar.

Geçiş Sonrası Doğrulama Süreci

Geçişi yaptıktan sonraki ilk 48 saat kritik. Bu sürede yapmanız gerekenler sıralı şekilde şöyle:

Yönlendirme Zincirlerini Kontrol Edin

# Yönlendirme zincirlerini kontrol et - zincir uzunluğu 1'den fazla olmamalı
check_redirects() {
    local url="$1"
    echo "Checking: $url"
    curl -sI -L "$url" | grep -E "^(HTTP|Location)"
    echo "---"
}

# Test edilecek URL listesi
urls=(
    "http://siteniz.com"
    "http://www.siteniz.com"
    "http://siteniz.com/kategori/ornek-sayfa/"
    "http://www.siteniz.com/iletisim"
)

for url in "${urls[@]}"; do
    check_redirects "$url"
done

İdeal senaryo şu olmalı: http://siteniz.com doğrudan https://siteniz.com‘a yönlenmeli, arada başka bir durak olmamalı. Her ekstra hop, hem sayfa hızını düşürür hem de teorik olarak link juice kaybına yol açar.

Canonical Tag Kontrolü

# Canonical tag'lerin HTTPS olduğunu doğrula
curl -s https://siteniz.com | grep -i "canonical"

# Birden fazla sayfayı kontrol etmek için
while IFS= read -r url; do
    echo "URL: $url"
    curl -s "$url" | grep -i "canonical"
    echo "---"
done < https_urls_after.txt

Canonical tag’lerin HTTPS URL’leri işaret etmesi şart. HTTP’ye işaret eden canonical tag varsa, Google sitenizin hangi versiyonunu indeksleyeceği konusunda kafa karışıklığı yaşar.

Sitemap Güncellemesi

# Sitemap'teki tüm URL'lerin HTTPS olduğunu doğrula
curl -s https://siteniz.com/sitemap.xml | grep -o 'http://[^<]*' | head -20

# HTTP URL varsa sitemap'i yeniden oluşturun
# WordPress için
wp post list --post_type=any --field=ID | xargs -I{} wp post generate --count=0

# Sitemap XML'ini doğrudan düzenlemek için
sed -i 's|http://siteniz.com|https://siteniz.com|g' /var/www/html/sitemap.xml

Google Search Console’da Yeni Property Ekleme

Bu adımı atlayan çok sysadmin gördüm. HTTPS geçişi sonrası Google Search Console’da yeni bir property oluşturmanız gerekiyor. HTTPS ve HTTP, GSC’de ayrı property’ler olarak değerlendiriliyor.

Yapmanız gerekenler:

HTTPS versiyonu için yeni property ekleyin: https://siteniz.com ayrıca doğrulanmalı
Yeni sitemap gönderin: HTTPS URL’lerini içeren sitemap’i yeni property’ye ekleyin
Change of Address aracını kullanın: GSC’de “Change of Address” özelliği ile Google’a geçişi resmi olarak bildirin

Change of Address aracı, Google’a “bu eski site artık yeni adreste” mesajı gönderir ve geçişi hızlandırır. Bunu yapmadan da Google siteleri ilişkilendirir ama bu araçla süreci aylar yerine haftalarla bitirebilirsiniz.

Hız ve Core Web Vitals Etkisi

HTTPS geçişi, doğru yapılmadığında sayfa hızını olumsuz etkileyebilir. SSL handshake süresi, ek yük getirir. Bu yükü minimize etmek için:

# OCSP Stapling aktifliğini kontrol edin
openssl s_client -connect siteniz.com:443 -status 2>/dev/null | grep -A 10 "OCSP Response"

# TLS versiyonunu kontrol edin (TLS 1.2 minimum, 1.3 ideal)
curl -vI https://siteniz.com 2>&1 | grep "SSL connection using"

# HTTP/2 desteğini doğrula
curl -I --http2 https://siteniz.com 2>&1 | grep "HTTP/2"

Nginx’te OCSP Stapling ve HTTP/2 yapılandırması:

# /etc/nginx/sites-available/siteniz.conf içine ekleyin
server {
    listen 443 ssl http2;
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;
    
    # Modern TLS yapılandırması
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    
    # SSL session cache
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
}

Bu yapılandırma SSL handshake süresini ciddi ölçüde kısaltır. OCSP Stapling sayesinde tarayıcı, sertifika geçerliliğini ayrıca sorgulamak zorunda kalmaz.

Backlink Profili ve Link Equity

Geçiş sonrası en büyük SEO kaygısı backlink profilidir. İnternette binlerce site, eski HTTP URL’lerinize link vermiş olabilir. Bu linkler 301 yönlendirme sayesinde çalışmaya devam eder ama en iyi senaryoda link juice’un bir kısmı her zaman kaybolur.

Yapabileceğiniz şeyler:

Yüksek kaliteli backlink sahiplerine ulaşın: Domain authority’si yüksek sitelerden gelen linkleri doğrudan HTTPS URL’ye güncellemeleri için iletişime geçin
Kendi kontrolünüzdeki profilleri güncelleyin: Sosyal medya profilleri, Google My Business, dizin listeleri gibi kendinizin sahip olduğu alanlarda URL’yi güncelleyin
İç linkleri güncelleyin: Siteniz içindeki tüm iç linkler HTTPS olmalı, yönlendirmeye güvenmek performansı düşürür

# Sitedeki tüm iç HTTP linklerini bul
grep -r "http://siteniz.com" /var/www/html/ --include="*.html" --include="*.php" -l

# Bu dosyalarda toplu güncelleme yap
find /var/www/html/ -type f ( -name "*.html" -o -name "*.php" ) -exec 
    sed -i 's|href="http://siteniz.com|href="https://siteniz.com|g' {} ;

Geçiş Sonrası İzleme

İlk ayda haftalık olarak takip etmeniz gereken metrikler var. Bu izlemeyi otomatize etmek için basit bir script yazabilirsiniz:

#!/bin/bash
# https_seo_monitor.sh
# Cronjob ile haftalık çalıştırın

SITE="https://siteniz.com"
LOG_FILE="/var/log/seo_monitor.log"
DATE=$(date +%Y-%m-%d)

echo "=== SEO Monitor Report: $DATE ===" >> $LOG_FILE

# Ana sayfa response kodu
HTTP_STATUS=$(curl -o /dev/null -s -w "%{http_code}" "$SITE")
echo "Ana sayfa HTTP status: $HTTP_STATUS" >> $LOG_FILE

# Sayfa yükleme süresi
LOAD_TIME=$(curl -o /dev/null -s -w "%{time_total}" "$SITE")
echo "Sayfa yükleme süresi: ${LOAD_TIME}s" >> $LOG_FILE

# SSL sertifika geçerlilik tarihi
CERT_EXPIRY=$(openssl s_client -connect siteniz.com:443 -servername siteniz.com 2>/dev/null 
    | openssl x509 -noout -enddate | cut -d= -f2)
echo "SSL sertifika sona erme: $CERT_EXPIRY" >> $LOG_FILE

# HTTP yönlendirmesi çalışıyor mu?
REDIRECT_TARGET=$(curl -Ls -o /dev/null -w "%{url_effective}" "http://siteniz.com")
echo "HTTP redirect hedefi: $REDIRECT_TARGET" >> $LOG_FILE

echo "===================================" >> $LOG_FILE

Bu script’i crontab’a ekleyerek haftalık otomatik rapor alabilirsiniz:

# Crontab'a ekle
crontab -e
# Her Pazartesi sabah 09:00'da çalıştır
0 9 * * 1 /usr/local/bin/https_seo_monitor.sh

Yaygın Hatalar ve Gerçek Senaryolar

Yıllar içinde en çok karşılaştığım hatalar şunlar:

Staging ortamında test edilmeden production’a geçiş: Bir e-ticaret sitesinde geçiş doğrudan canlı ortamda yapıldı ve ödeme sayfasındaki hard-coded HTTP URL’ler nedeniyle checkout sürecinin tamamı bozuldu. İki gün içinde organik trafik %30 düştü çünkü Google bot sayfaları gezmeye çalışıyor ama hata alıyordu.

HSTS’yi acelesiyle etkinleştirmek: HSTS başlığı aktifleştirildiğinde, belirlenen süre boyunca tarayıcılar o siteyi kesinlikle HTTPS üzerinden yükler. SSL sertifikasında sorun olursa siteye erişim tamamen engellenir. max-age değerini önce düşük tutun, her şey stabil olduğuna emin olduktan sonra artırın.

Canonical tag’leri güncellemeyi unutmak: Yönlendirmeler kusursuz çalışıyor ama sayfa kaynaklarındaki canonical tag’ler hâlâ HTTP’ye işaret ediyor. Google bu durumda genellikle canonical’ı dikkate alır ve HTTP versiyonunu “tercih edilen” sayfa olarak görmeye devam eder.

XML Sitemap’i güncellemeden GSC’ye göndermek: HTTP URL’leri içeren sitemap’i HTTPS property’sine göndermek, Google’ın kafasını karıştırır. Sitemap her zaman property’nin versiyonuyla uyumlu olmalı.

Sonuç

HTTPS geçişi, doğru yapıldığında SEO’ya net katkı sağlar ve teknik olarak zorunlu bir adımdır. Yanlış yapıldığında ise aylarca sürebilecek sıralama kayıpları yaşanabilir. Ben genellikle bu geçişi trafik açısından düşük dönemlerde, örneğin hafta sonları yaparım ve geçiş sonrası 72 saat boyunca Analytics ve Search Console’u saatlik takip ederim.

Özetle dikkat etmeniz gereken kritik noktalar:

301 yönlendirme zincirlerini kısa tutun: Her ekstra hop kayıptır
Mixed content’i temizleyin: Tek bir HTTP kaynağı bile güvenlik uyarısı tetikler
GSC’de yeni property açın ve Change of Address bildirimi yapın
Canonical tag’leri ve sitemap’i güncellemeyi unutmayın
İlk ay boyunca düzenli izleme yapın

Geçiş bir an meselesi değil, bir süreç. Acele edilmeden, test edilerek ve adım adım yapıldığında SEO kaybı minimum düzeyde kalır, hatta orta vadede sıralama kazanımları yaşanır. Google, HTTPS siteleri tercih ediyor. Siz de doğru geçişi yaparak bu avantajdan yararlanabilirsiniz.

HTTPS Geçişi Sonrası SEO Nasıl Etkilenir