Mobile-first indexing için hosting tarafında yapılacaklar

Mobile-first indexing, Google’ın siteleri öncelikle mobil görünüm ve performans sinyalleriyle değerlendirmesine dayanır. Ancak çoğu sorun kullanıcı tarafı değil; sunucu gecikmesi, cache ayarı, yönlendirme davranışı, TLS/HTTP sorunları ve yanlış içerik teslimi gibi hosting kaynaklı sebeplerden çıkar. Bu rehberde, hosting ve sunucu tarafında mobile-first indexing etkisini somut şekilde artıracak yapılandırmaları ve kontrol adımlarını bulacaksınız. Hedef; mobil sayfaların daha hızlı yüklenmesi, hatasız render edilmesi ve Googlebot mobil tarayıcısının tutarlı içerik görmesidir.

1) Googlebot mobil sayfası doğru içeriği görüyor mu?

Mobile-first indexing’te temel şart, mobil cihaz için sunulan içerik ile masaüstündeki içerik arasında gereksiz fark olmamasıdır. Hosting tarafı bu farkların kaynağı olabilir.

1.1 Mobil/masaüstü ayrımı varsa tekil ve tutarlı mı?

Sunucu katmanında şu senaryolar sık görülür: - Kullanıcı-agent’a göre farklı HTML döndürme (yanlış yapılandırılmış WAF/edge kuralı) - Cache anahtarında kullanıcı-agent veya ekran genişliği farklılaşması (aynı URL farklı içerik üretir) - CDN/edge üzerinde “mobil optimizasyon” adıyla yapılan agresif HTML dönüşümleri

Net kontrol: - Aynı URL için mobilde görünen içerik ile masaüstünde görünen içerik arasında başlıklar, meta açıklamalar, yapılandırılmış veri (schema), canonical ve iç bağlantılar uyumlu olmalıdır. - Özellikle canonical (canonical) ve robots (robots.txt) kuralları mobilde farklı olmamalıdır.

1.2 3xx yönlendirmeler mobilde de aynı mı?

Hosting tarafında yapılan yönlendirme (redirect) kuralları çoğu zaman mobilde daha fazla zincir oluşturur. Zincir redirect’ler gecikmeyi artırır.

Net kontrol (hedef: 1. adımda doğru hedef): - Bir URL mobilde 301/302 ile farklı bir sayfaya gidiyor ve ardından başka bir redirect daha çalışıyorsa zincir oluşur. - Mobilde 200 dönmeden önce 3+ istek oluşması mobile-first raporlarına yansır.

Pratik hedef: - Her sayfa için mobilde toplam redirect adedi: 0 veya 1.

2) TTFB ve cache: mobilde gecikmeyi en çok nereden düşürürsünüz?

Mobile-first indekslemede hız sinyallerinin bir kısmı TTFB (Time To First Byte) ve ilk içerik teslimiyle ilgilidir. Hosting tarafında en büyük kazanım genellikle cache katmanının doğru kurgulanmasıdır.

2.1 Reverse proxy/CDN var mı ve cache doğru mu?

Aşağıdaki mimarilerden hangisini kullandığınız önemlidir: - Sadece uygulama sunucusu (PHP-FPM/Node) ile tek katman - Reverse proxy (Nginx/Apache) + uygulama - CDN (Content Delivery Network) + cache katmanı

Net öneri: - Statik dosyalar (CSS/JS/img/font) için CDN cache header’ları doğru ayarlanmalıdır. - HTML sayfalar için sayfanın dinamikliği durumuna göre edge cache stratejisi uygulanmalıdır.

Kontrol listesi: - Cache-Control değerleri statiklerde makul sürede (ör. 1 hafta–1 ay) olmalıdır. - HTML’de aşırı uzun cache yerine, sayfanın güncellenme sıklığına göre kısa/orta TTL seçilmelidir. - Eş zamanlı olarak stale-while-revalidate gibi yöntemler (varsa) kullanılırsa mobilde yükleme daha stabil olur.

2.2 Uygulama cache (object cache) sadece WordPress değil, mantık olarak önemli

Object cache (Redis/Memcached) sunucu tarafında backend işlemlerini azaltır. Mobile-first raporlarındaki gecikmenin bir kısmı “sunucu önce hesaplıyor” gerçeğinden gelir.

Net etki: - Aynı sorgular/variantlar sık görülüyorsa object cache backend süresini düşürür. - Mobilde daha az bant genişliği olduğundan geciken yanıtlar daha belirgin fark yaratır.

Somut hedef: - PHP tabanlı sistemlerde (WordPress dahil) sayfa üretimi için backend işlem süresi düşmeli; TTFB iyileşmelidir.

3) Mobil render’ı etkileyen hosting ayarları: görsel, CSS/JS ve kompresyon

Google’ın mobilde aldığı “ilk render” deneyimi, sunucunun teslim ettiği içerik biçiminden etkilenir.

3.1 Görselleri gerçekçi ölçülerde sunun

Hosting tarafında görsel optimizasyonu “dosyayı barındırma” kadar “format ve teslim” meselesidir.

Net uygulamalar: - WebP/AVIF destekleniyorsa ilgili formatlar otomatik tercih edilmelidir. - Orijinal boyutla kullanıcının gerçek ekranında gösterilecek boyut arasında aşırı fark olmamalıdır. - srcset ile doğru boyutlar servis edilmelidir.

3.2 HTTP sıkıştırma (gzip/br) açık mı?

Mobil bağlantılarda veri boyutu çok daha kritiktir. Sıkıştırma kapalıysa sayfa daha yavaş görünür.

Net kontrol: - Sunucu veya reverse proxy katmanında br (Brotli) veya gzip aktif olmalıdır. - HTML/CSS/JS sıkıştırılmalı, görseller zaten sıkışık olduğundan her zaman tekrar sıkıştırma gerekmez.

3.3 CSS/JS teslimi “bloklayıcı” hale geliyor mu?

Hosting tarafında dosya birleştirme/erteleme (minify/defer) uygulamalarına dikkat edilmelidir. Yanlış ayarlarla mobilde LCP (Largest Contentful Paint) uzar.

Net kontrol: - İlk görünümde kritik CSS gereksiz yere gecikmemeli. - Büyük JS dosyaları gerekmedikçe ilk istekte engelleyici hale getirilmemeli.

4) Sunucu performansını ölçülebilir hale getirin (hosting kaynaklı testi)

Mobile-first indexing için yapılacakların “tahmin” değil “ölçüm” tarafı olmalı. Hosting kararlarını metriklerle verin.

4.1 Hangi ölçümü takip edeceksiniz?

Şunlar mobil performansla doğrudan ilişkilidir: - TTFB (Time To First Byte) - LCP (Largest Contentful Paint) - Sayfa yüklendikten sonra ilk etkileşim süresi (özellikle JS ağırlığı varsa) - Mobil hataları (4xx/5xx)

Net yöntem: - Aynı URL’yi düzenli aralıklarla test edin (en az 3 farklı zaman dilimi). - CDN açık/kapalı ve cache dolu/dolu değilken karşılaştırın.

4.2 NetKıyas yaklaşımı: doğru plan seçimi nasıl etkiler?

Hosting planı (paylaşımlı/sunucu/VDS) doğru değilse mobilde gecikme artar. Örneğin: - CPU paylaşımı yüksek yoğunlukta TTFB yükseltir - Yavaş disk/yanlış IOPS TTFB ve uygulama yanıt süresini bozar - RAM yetersizse swap (takas) artar; bu da mobilde “takılma” hissi yaratır

Somut karşılaştırma (plan seçimi mantığı): - Statik ağırlıklı siteler: CDN + yeterli bant genişliği - Dinamik içerik ve sık sorgu: yeterli CPU/RAM + hızlı depolama + doğru cache

5) Mobil-first için teknik güvenlik ayarı “içerik teslimi”ni bozuyor mu?

WAF (Web Application Firewall) kuralları, botlara veya mobil tarayıcı IP aralıklarına sert davranabilir. Bu, Googlebot mobil tarayıcısında farklı içerik veya hata görmeye yol açar.

5.1 403/429 gibi durumlar var mı?

Mobile-first indexing’e giden yolda Googlebot mobil tarayıcısı engellenirse sağlıklı değerlendirme olmaz.

Net kontrol: - Web sunucusu loglarında ve WAF olaylarında 403/429 artışı var mı? - Rate limit (istek sınırı) kuralları bot trafiğini de etkiliyor mu?

Uygulama notu: - Özellikle kısa aralıklarla çok istek atan modüller varsa (bazı güvenlik eklentileri) rate limit ayarını Googlebot’a göre optimize edin.

5.2 TLS/HTTP protokolü mobilde daha mı kötü?

Mobil ağlarda bağlantı kurma (handshake) gecikmeye neden olur. HTTP/2 ve HTTP/3 destekleri (varsa) avantaj sağlar.

Net kontrol: - TLS sürümleri güncel olmalı. - HTTP/2 aktif olmalı (ters proxy doğru yapılandırılmalı). - Uygunsa HTTP/3 (QUIC) kullanımı test edilmelidir.

6) Hosting tarafında “uygulama sonrası” kontrol listesi

Aşağıdaki kontrol listesi, değişiklik yaptıktan sonra mobile-first indexing etkisini doğrulamak içindir. Her maddeyi tek tek kontrol edin.

6.1 Önce temel: yönlendirme ve durum kodları

• [ ] Mobilde aynı URL için 301/302 zinciri yok (0–1 adım hedef)
• [ ] Mobilde 200 dönüyor, 4xx/5xx artışı yok

6.2 Sonra teslim: cache ve sıkıştırma

• [ ] Statik dosyalarda CDN ve cache header doğru
• [ ] HTML/CSS/JS için gzip veya br aktif
• [ ] Object cache (kullanıyorsanız) beklenen hit oranlarına ulaşıyor

6.3 Sonra içerik: render bütünlüğü

• [ ] Mobilde metin, başlıklar, structured data (schema), canonical aynı
• [ ] Görseller WebP/AVIF ve doğru boyutta teslim ediliyor

6.4 Son olarak ölçüm: LCP/TTFB ve sunucu yanıt süresi

• [ ] TTFB iyileşiyor (cache tam etkisiyle birlikte ölçüm)
• [ ] Mobil LCP değeri düşüyor
• [ ] Trafik artınca performans bozulmuyor (CPU/RAM doyumu yok)

Sonuç: Mobile-first indexing için tek hamle değil, hosting kaynaklı kök nedeni hedefleyin

Mobile-first indexing’te hosting tarafında en hızlı sonuç genellikle cache teslimi, sıkıştırma, görsel formatı/ölçüsü ve yönlendirme/robots tutarlılığıyla gelir. İlk aksiyon olarak; Googlebot mobilin gördüğü içerik ile gerçek mobil kullanıcı deneyimini aynılaştırın, redirect ve durum kodlarını düzeltin, ardından TTFB/LCP metriklerini ölçerek cache ve kompresyonu optimize edin. Son adımda ise WAF ve güvenlik kurallarının bot trafiğini bozmadığını loglarla doğrulayın. Bu sırayla ilerlerseniz, değişiklikleri “görünür” performans kazanımına bağlayarak doğru hosting/sunucu kararını da netleştirirsiniz.