Mobile-first indexing: Hosting tarafında yapılacak net işler

Mobile-first indexing (mobil öncelikli dizinleme), Google’ın sayfaları değerlendirirken önce mobil kullanıcı deneyimini baz alması demektir. Sonuç olarak, sitenizin mobilde açılışı yavaşsa, içerik görünmüyorsa, önemli elementler engelleniyorsa veya sayfalar farklı sunuluyorsa arama performansı doğrudan etkilenir. Bu rehberde, hosting tarafında (VDS/VPS/web hosting ayarları ve sunucu katmanı) hangi kontrolleri yapmanız gerektiğini net bir listeyle anlatıyorum. Böylece “SEO ayarı var mı yok mu” tartışması yerine, somut teknik noktalarla sorunları kapatabileceksiniz.

1) Mobilde farklı içerik sunmamak: Hosting kaynaklı tipik sebepler

Mobile-first indexing’te en sık gözlenen hatalardan biri, mobil istemcinin farklı bir HTML almasıdır. Bu fark bazen temadan değil, hosting/CDN/otomatik yönlendirme kurallarından gelir.

Dinamik yönlendirme ve user-agent bazlı içerik kontrolü

Hosting tarafında şunlar mobilde farklı içerik üretebilir: - WAF (Web Application Firewall) veya güvenlik kuralları: Belirli user-agent’ları bot/şüpheli diye kısıtlayıp bazı içerikleri gizleyebilir. - CDN cache (edge cache): Mobil için ayrı cache policy uygulanıyorsa HTML farklı servis edilir. - Geolocation / device detection: Mobil sayfa farklı şablon döndürecek şekilde kurallara sahiptir. - Rewrite/redirect: .htaccess, Nginx try_files, uygulama bazlı redirect zincirleri mobilde farklı davranabilir.

Net kontrol yöntemi: 1. Chrome’da “Geliştirici Araçları → Network” ile mobil emülasyonda istekleri inceleyin. 2. Aynı URL için “mobil” ve “masaüstü” isteklerinin status code (200/403/301), HTML yanıtı ve ilk byte (TTFB) değerlerini karşılaştırın. 3. Mobilde 403/404 dönüyorsa veya HTML içinde kritik içerik eksikse sorun hosting katmanına kadar inmiş demektir.

2) Render engellerini hosting düzeyinde temizleyin

Googlebot’un sayfayı render ederken takıldığı durumlar, hosting kaynaklı olabilir. Render engeli en çok JavaScript/asset teslimatı, sıkı bot engelleri ve yanlış içerik türü (MIME) ayarlarında görülür.

Googlebot’a gereksiz blok uygulamıyor musunuz?

Şu senaryolar mobil-first etkisini büyütür: - Bot trafiği WAF tarafından “challenge” veya “tarayıcı doğrulama” ile durduruluyor. - Mobilde farklı bir hız limiti (rate limit) devreye giriyor ve bot daha sık “429 Too Many Requests” alıyor. - Nginx/Apache tarafında yanlış User-Agent allow/deny kuralı var.

Net kontrol: - Sunucu loglarında (Nginx access log veya uygulama logu) Googlebot için kaç istek geldiğini ve hangi HTTP kodlarının üretildiğini görüntüleyin. - WAF kullanıyorsanız “bot protection / managed rules” kısmında Googlebot veya “verified bots” için istisna tanımlayın.

MIME type ve sıkıştırma (gzip/brotli) ayarları

Yanlış MIME ayarı, tarayıcının (ve render aracının) JS/CSS dosyasını doğru yorumlamamasına yol açar. - JS için application/javascript (ya da text/javascript), CSS için text/css doğru olmalı. - Content-Encoding: gzip veya br ile gönderiyorsanız, içerik doğru sıkıştırılmalı.

Net kontrol: - Mobil emülasyonda Network sekmesinde JS/CSS dosyalarının yanında “Type” ve “Size” bilgilerini inceleyin. - Bir dosya “text/plain” döndürüyorsa bu çoğu zaman hosting config kaynaklıdır ve render kalitesini düşürür.

3) Mobil performansı hosting belirler: TTFB, cache ve CDN

Mobile-first indexing’in “mobil deneyim” boyutu pratikte iki şeye dayanır: hızlı yanıt ve hızlı asset teslimi. Hosting tarafında yapılacak en net işler cache tasarımını düzeltmek ve gecikmeyi azaltmaktır.

Hedef metrikleri belirleyin

Tek tek her değeri obsessif ölçmek yerine, hosting etkisini ayırın: - TTFB (Time To First Byte): Sunucunun HTML’i hızlı üretip üretmediğini gösterir. - LCP (Largest Contentful Paint): Mobilde ana görsel/metin ne kadar hızlı görünür. - CLS (Cumulative Layout Shift): Dinamik ölçüm/late font yükleme ve DOM kaymalarıyla ilgilidir.

TTFB yüksekse tipik hosting sebepleri: - Yanlış paket boyutu (CPU darboğazı) - Disk I/O gecikmesi (özellikle küçük diskli VPS/VDS) - PHP-FPM ayarları (worker sayısı, max_children) - Veritabanı gecikmesi - Cache yok veya yanlış cache katmanı

Cache katmanlarını doğru sıraya koyun

Aşağıdaki yapı mobil-first için en tutarlı sonuçları verir: - Uygulama cache (varsa) - Sunucu reverse proxy cache (varsa) - CDN edge cache

Net öneri: HTML’in önbelleklenmesi mümkünse, mobil trafiği için ayrı policy üretmeyin. Mobil için ayrı sürüm gerekiyorsa bile (ör. ayrı URL), cache key içinde doğru header’lar kullanılmalı.

Cache davranışını kontrol listesi

Vary header: Vary: User-Agent gibi başlıklar gereksizse mobil/masaüstü cache’i ayırabilir.
Önbellek atımı: Sık güncellenen sayfalarda “stale-while-revalidate” gibi ayarlar belirgin fark yaratır.
Compression: HTML/CSS/JS sıkıştırma etkin mi?

4) Mobil sayfa kaynakları: Görünürlük ve içerik teslimatı

Mobile-first indexing’te “içerik var ama mobilde kullanıcıya gelmiyor” gibi durumlar hosting yüzünden ortaya çıkabilir.

Fonts, görseller ve temeldeki kritik asset’ler mobilde geliyor mu?

CDN’den resimler doğru host edilir mi?
Görseller için Cache-Control yeterli mi?
JS/CSS dosyaları 404/403 dönüyor mu?

Net kontrol: - Mobil emülasyonda “Blocked” veya “Failed to load” hatalarını raporlayın. - Özellikle font dosyaları geç yükleniyorsa (ör. font-display ayarı) CLS etkilenebilir.

Lazy loading (sunucu tarafı) kullanıyorsanız kuralları denetleyin

Lazy loading, performansa katkı sağlar; ancak yanlış implementasyon “render sırasında görünür olması gereken” içeriği geciktirebilir. Hosting tarafında şu kontrol önemlidir: - Görselin src yerine sadece data-src kullanıldığı sistemlerde, render aracı gerekli zamanı bekler mi? - Sunucu tarafında kritik CSS/JS yükleme sırası gecikiyor mu?

Net karar kuralı: - LCP öğesi (LCP genellikle ilk ekran görseli/başlık bloğu) lazy yükleniyorsa, mobilde LCP gecikmesi doğar. Bu durumda LCP adayını “ilk yükleme” önceliğine almak hosting/tema ayarı gerektirir.

5) Teknik erişim ve güvenlik: robots, bot koruması, rate limit

Mobile-first indexing sadece hız değil erişilebilirlik demektir. Hosting tarafındaki güvenlik önlemleri, yanlış ayarlandığında Googlebot’un sayfaları taramasını zorlaştırır.

robots.txt ve WAF birlikte düşünülmeli

robots.txt dosyası doğruysa bile WAF/Firewall, bot trafiğini engelleyebilir.
Rate limit, özellikle mobilde daha sık tetikleniyorsa (CDN/WAF cache vary kaynaklı) Googlebot için sorun yaratabilir.

Net kontrol: - Googlebot ile test ettiğiniz isteklerde WAF loglarında “blocked/challenged” satırlarını tarayın. - İlgili URL’lerde 301/302 zinciri, 403 ve 5xx oranını ayrı raporlayın.

TLS ve yönlendirme zincirlerini sadeleştirin

Mobile-first etkisini azaltmak için şu standart uygulama gerekir: - HTTP → HTTPS 301 ile tek adımda bitmeli. - WWW/non-WWW yönlendirme zinciri tek hedefte sonlanmalı. - HSTS (HTTP Strict Transport Security) etkinleştirilecekse, ön koşullar doğru olmalı.

Net kontrol: - Mobilde aynı URL için kaç yönlendirme oluyor sayın (örn. 2 ardışık redirect sorunu hız düşürür). - Sertifika hataları (expired/chain) mobilde farklı CDN yolu nedeniyle daha görünür hale gelebilir.

6) Hosting tarafında uygulanacak “net” kontrol planı (sıralı)

Aşağıdaki planı sırayla uygularsanız, mobile-first indexing kaynaklı sorunların büyük kısmı hosting katmanında net biçimde kapanır.

Adım 1: Aynı URL’de mobil/masaüstü farkını kanıtlayın

5 kritik URL seçin (ana sayfa, kategori, ürün/makale, giriş/landing, önemli bir kampanya sayfası).
Her URL için mobil emülasyonda:
HTML status code
İlk 10 istek (hangi CSS/JS gecikiyor)
Redirect sayısı
403/429 var mı

Adım 2: TTFB’yi ölçün ve sunucu darboğazını ayırın

CDN devredeyse ve TTFB yüksekse, HTML’in cachelenip cachelenmediğini kontrol edin.
HTML cache yoksa:
Uygulama (PHP) worker ayarı
Veritabanı sorgu gecikmesi
Disk I/O
Uzak backend çağrıları

Adım 3: Cache vary kurallarını sadeleştirin

Mobil/masaüstü için gereksiz Vary başlıklarını kaldırın.
HTML’i CDN’de cachelemek mümkünse enable edin (sayfaya göre istisnalarla).

Adım 4: WAF ve bot korumasını doğrulayın

Googlebot için engel/challenge olmadığını logla kanıtlayın.
Mobilde farklı rate limit uygulanıyorsa aynı kuralları uygulayın veya verified bots için ayrı limit kullanın.

Adım 5: Render engeli olabilecek dosyaları listeleyin

404/403 dönen JS/CSS/font dosyaları
Yanlış MIME type dönen dosyalar
Brotli/gzip sıkıştırma hataları

Karşılaştırma Tablosu: Hosting ayarı türüne göre etkiler

Aşağıdaki tablo, hangi hosting davranışının mobile-first performansına direkt etki ettiğini hızlı görmenize yardımcı olur.

Hosting kaynaklı ayar	Tipik sorun	Mobilde etkisi	Net çözüm
CDN/edge cache policy	Mobil/desktop farklı HTML döner	Dizine uygun içerik gecikir veya eksik görünür	Mobil varyasını sadele, HTML cache key’i düzelt
WAF bot koruması	Bot challenge/403 alır	Taramalar boşa gider, render kalitesi düşer	Verified bots istisnası, rate limit düzeni
PHP-FPM/Nginx ayarları	Yükte TTFB yükselir	LCP gecikir	Worker/memory tuning, uygun paket seçimi
Yanlış gzip/brotli/MIME	JS/CSS yorumlanmaz	Render engeli oluşur	MIME type + sıkıştırma config doğrula
Lazy loading uygulaması	LCP öğesi geç görünür	LCP kötüleşir	LCP adayını önceliklendir, kritik görseli lazy’den çıkar
Redirect zinciri	Ek round-trip oluşur	TTFB/etkileşim gecikir	Tek redirect kuralı, yönlendirme zincirini kapat
Veritabanı gecikmesi	Dinamik sayfalar yavaş döner	Mobil ilk yük yavaşlar	Query optimizasyonu, uygun DB kaynakları

Sonuç: En hızlı etkiyi nereden alırsınız?

Mobile-first indexing’te hosting kaynaklı kazanım alanları genellikle “erişim engeli” ve “mobil hız” başlıklarında toplanır. İlk 1 günde yapmanız en yüksek geri dönüşü sağlar: (1) mobil/masaüstü aynı URL’de HTML ve HTTP kod farkını kontrol edin, (2) CDN cache ve Vary davranışını sadeleştirin, (3) WAF/rate limit loglarında bot engeli olmadığını doğrulayın, (4) TTFB ve 404/403/mime problemlerini düzeltin. Bu kontrolleri tamamladıktan sonra Search Console tarafında tarama ve performans sinyalleri daha stabil hale gelir. Bu rehberdeki adımları, seçtiğiniz 5 kritik URL ile başlayarak uygulayın; sonuçları log ve mobil emülasyon kanıtlarıyla ölçün.