Mobil Uyumluluk Testi Nasıl Yapılır? Sitenizin Mobil SEO Kontrolü

Bir müşterim geçen ay şunu sordu: "Mobil uyumluluk testi yapmak istedim ama Google'ın aracı artık açılmıyor, şimdi ne yapacağım?" Bu soruyu son iki yılda çok sık duyuyorum. Eski tek tıklık araç artık yok; ancak mobil SEO kontrolü hiç olmadığı kadar önemli. Bu yazıda güncel test yollarını, hangi aracın neyi gösterdiğini ve kendi ekibimle kullandığım kontrol listesini anlatıyorum.

Mobil uyumluluk testi nedir ve bugün hangi yollarla yaparsınız?

Mobil uyumluluk testi, bir sayfanın telefon ekranında okunabilir, dokunarak kullanılabilir ve masaüstüyle aynı içeriği sunar durumda olup olmadığını ölçen kontroldür. Bugün bu testi tek araçla değil; Lighthouse, Chrome DevTools cihaz modu, Search Console URL Denetleme aracı ve gerçek telefon denemesiyle birlikte yaparsınız.

Kısacası "geçti" ya da "kaldı" diyen tek bir düğme artık yok. Bunun yerine her aracın farklı bir soruyu cevapladığı küçük bir test seti kuruyorsunuz. Lighthouse teknik sorunları listeler. DevTools ekranı farklı cihaz boyutlarında gösterir. URL Denetleme ise Google'ın sayfanızı telefondan nasıl gördüğünü ortaya koyar.

Benim sahadaki gözlemim şu: bu dört adımı düzenli yapan işletmeler, mobil sorunları müşteri şikâyetinden önce fark ediyor. Üstelik bu işin maliyeti neredeyse sıfır, çünkü araçların hepsi ücretsiz.

Google'ın Mobil Uyumluluk Testi aracına ne oldu?

Google, Mobil Uyumluluk Testi aracını, bu aracın API'sini ve Search Console içindeki Mobil Kullanılabilirlik raporunu 1 Aralık 2023 itibarıyla kapattı. Kapatma kararını aylar önce duyurmuştu. Gerekçe olarak da mobil kullanılabilirliği değerlendiren daha güçlü kaynakların, özellikle Chrome'un Lighthouse aracının artık yaygın olmasını gösterdi.

Bu karar mobil uyumluluğun önemsizleştiği anlamına gelmiyor. Google'ın sayfa deneyimi rehberi hâlâ "İçeriğiniz mobil cihazlarda iyi görünüyor mu?" sorusunu soruyor. Aynı sayfa, mobil kullanılabilirlik dahil sayfa deneyimi iyileştirmeleri için Lighthouse'u öneriyor.

Yani araç gitti, kriter kaldı. Sahada gördüğüm en yaygın hata da burada başlıyor. Bazı site sahipleri "Google aracı kaldırdıysa artık bakmıyordur" diye düşünüp mobil kontrolü tamamen bırakıyor. Oysa arama motoru sitenizi zaten telefon gözüyle tarıyor.

Bir de şu ayrıntıyı ekleyeyim: eski araçla ilgili rehberleri hâlâ internette görebilirsiniz. Bu yazılardaki adımlar artık işe yaramaz, çünkü araç adresi kapalı. Bu nedenle bir rehberi okurken tarihine bakmanızı öneririm. Aralık 2023 öncesine ait bir mobil test anlatımı, büyük ihtimalle kapanmış bir araca dayanıyor. Üstelik bazı üçüncü taraf siteler aynı adı kullanarak kendi araçlarını sunuyor; bunlar Google'ın resmi görüşünü yansıtmaz.

Mobil öncelikli dizine ekleme sitenizi nasıl değiştiriyor?

Google, Ekim 2023'te mobil öncelikli dizine ekleme geçişinin büyük ölçüde tamamlandığını duyurdu. Ardından 5 Temmuz 2024 sonrasında masaüstü tarayıcıyla taranan son siteleri de akıllı telefon tarayıcısına taşıdı. Bu nedenle Google sitenizi artık neredeyse tamamen mobil sürüm üzerinden değerlendiriyor.

Google'ın mobil öncelikli dizine ekleme rehberi bunu net söylüyor: dizine eklemede Google yalnızca mobil sitede görünen içeriği kullanır. Dolayısıyla masaüstünde görünen ama telefonda gizlediğiniz bir paragraf, bir tablo ya da bir SSS bölümü sıralama açısından yok hükmünde olabilir.

Pratikte bu şu anlama geliyor: mobil uyumluluk testi artık yalnızca kullanıcı deneyimi kontrolü değil, aynı zamanda bir dizine ekleme kontrolüdür. Telefonda eksik olan her şey, Google'ın gözünde de eksiktir.

Mobil uyumluluk testi için hangi araçları kullanmalısınız?

Tek bir araç her şeyi göstermez. Bu yüzden ben her denetimde aşağıdaki araçları birlikte kullanıyorum. Tablo, hangi aracın hangi soruya cevap verdiğini özetliyor.

Bu tablodaki araçların hiçbiri ücretli değil. Ancak her biri farklı bir kör noktayı kapatıyor. Örneğin Lighthouse size ödeme adımında klavyenin butonu kapattığını söylemez; bunu yalnızca gerçek telefonda görürsünüz.

Lighthouse ile mobil denetimi nasıl yaparsınız?

Lighthouse, Chrome tarayıcısının içinde gelen açık kaynaklı bir denetim aracıdır. Kullanmak için sayfayı Chrome'da açarsınız, geliştirici araçlarını F12 ile başlatırsınız ve Lighthouse sekmesine geçersiniz. Ardından cihaz olarak "Mobile" seçip analizi başlatırsınız.

Rapor dört kategori halinde gelir: performans, erişilebilirlik, en iyi uygulamalar ve SEO. Burada küçük ama önemli bir ayrıntı var. Lighthouse 12 sürümü, viewport ve yazı boyutu denetimlerini SEO kategorisinden "en iyi uygulamalar" kategorisine taşıdı. Eski dokunma hedefi denetiminin yerini de erişilebilirlik altındaki hedef boyutu denetimi aldı.

Dolayısıyla yalnızca SEO skoruna bakıp "100 aldık, mobilde sorun yok" demek yanıltıcı olur. Mobil sorunların önemli bir kısmı artık diğer kategorilerde çıkıyor. Ben raporu okurken şu sırayı izliyorum:

• En iyi uygulamalar: viewport etiketi ve okunaklı yazı boyutu uyarıları.
• Erişilebilirlik: dokunma hedefi boyutu, kontrast ve etiketsiz form alanları.
• Performans: LCP, CLS ve toplam engelleme süresi.
• SEO: taranabilirlik, meta açıklama ve bağlantı metinleri.

Bir ipucu daha: testi gizli pencerede çalıştırın. Aksi halde tarayıcı eklentileri sonuçları bozabilir.

Chrome DevTools cihaz modunda neye bakmalısınız?

Chrome DevTools cihaz modu, sayfanızı farklı telefon boyutlarında görmenizi sağlar. Geliştirici araçlarını açtıktan sonra cihaz simgesine tıklarsınız ya da Ctrl+Shift+M kısayolunu kullanırsınız. Ardından hazır cihaz listesinden bir model seçer veya genişliği elle girersiniz.

Burada benim ilk baktığım şey yatay kaydırmadır. Sayfa, ekran genişliğinden taşıyorsa kullanıcı içeriği sağa sola kaydırmak zorunda kalır. Bu sorunun kaynağı çoğu zaman sabit genişlikli bir tablo, büyük bir görsel ya da hatalı bir kenar boşluğu olur.

Ayrıca şu kontrolleri de cihaz modunda yaparsınız:

1. En dar ekranı deneyin: 320 ile 360 piksel arası genişlikte menü ve başlıklar bozuluyor mu?
2. Ağ kısıtlamasını açın: yavaş bağlantıda ilk ekran ne kadar sürede anlamlı hale geliyor?
3. Yatay konuma çevirin: sabit başlık ekranın yarısını kaplıyor mu?
4. Menüyü açıp kapatın: hamburger menü dokunmaya doğru tepki veriyor mu?

Ancak şunu unutmayın: cihaz modu bir simülasyondur. Gerçek işlemci gücünü, gerçek dokunma hassasiyetini ve tarayıcı farklılıklarını tam olarak yansıtmaz. Bu yüzden son kontrolü mutlaka gerçek cihazda yaparsınız.

Search Console URL Denetleme aracı neyi gösterir?

URL Denetleme aracı, Google'ın sayfanızı nasıl gördüğünü doğrudan gösteren tek resmi yoldur. Google'ın URL Denetleme yardım sayfası, canlı testin akıllı telefon tarayıcısıyla çalıştığını belirtiyor. Bu yüzden eski mobil testin en yakın karşılığı bence bu araçtır.

Kullanım basit. Search Console'da üstteki arama çubuğuna adresi yapıştırırsınız ve "Canlı URL'yi test et" düğmesine basarsınız. Test bitince "Test edilen sayfayı görüntüle" bağlantısı belirir. Burada Google'ın gördüğü HTML'i, ekran görüntüsünü, HTTP başlıklarını, JavaScript konsol çıktısını ve yüklenemeyen kaynakları görürsünüz.

Benim en çok işime yarayan bölüm, yüklenemeyen kaynaklar listesidir. Örneğin robots.txt dosyası bir CSS ya da JavaScript klasörünü engelliyorsa, Google sayfayı bozuk bir düzende görür. Böyle bir durumda robots.txt oluşturucu ile kurallarınızı yeniden gözden geçirmenizi öneririm.

Yine de bir sınır var: araç, mülk başına günlük bir canlı test limiti uygular. Ayrıca olumlu sonuç, sayfanın arama sonuçlarında çıkacağını garanti etmez. Araç kaliteyi ve sıralamayı değil, teknik erişilebilirliği ölçer.

PageSpeed Insights ve Core Web Vitals verisini nasıl okumalısınız?

PageSpeed Insights, aynı ekranda iki farklı veri türünü birleştirir. Üst bölümde, yeterli trafik varsa Chrome UX Report'tan gelen gerçek kullanıcı verisi yer alır. Alt bölümde ise Lighthouse'un laboratuvar sonuçlarını görürsünüz.

Bu ayrımı bilmek önemlidir, çünkü iki veri çoğu zaman farklı sonuç verir. Laboratuvar testi tek bir cihaz ve bağlantı varsayımıyla çalışır. Saha verisi ise son 28 günde gerçek ziyaretçilerin yaşadığı deneyimi yansıtır. Google'ın sıralama tarafında dikkate aldığı sinyal saha verisidir.

web.dev'deki Core Web Vitals rehberi "iyi" eşikleri şöyle tanımlıyor: Largest Contentful Paint 2,5 saniye veya altı, Interaction to Next Paint 200 milisaniye veya altı, Cumulative Layout Shift 0,1 veya altı. Google bu eşikleri sayfa ziyaretlerinin 75. yüzdelik dilimine göre değerlendirir.

Öte yandan Mart 2024'ten itibaren INP, eski First Input Delay ölçümünün yerini aldı. Eski raporlarda FID görüyorsanız, karşılaştırma yaparken bu değişikliği hesaba katmalısınız.

Gerçek telefonda test neden hâlâ şart?

Hiçbir otomatik araç, bir müşterinin parmağıyla sitenizi kullanma deneyimini tam taklit edemez. Bu nedenle kritik sayfaları en az iki gerçek telefonda denerim: biri iOS, diğeri Android. Mümkünse biri de orta segment, yani biraz daha yavaş bir cihaz olur.

Gerçek cihazda ortaya çıkan sorunlar genellikle şunlardır: klavye açıldığında gönder butonunun kaybolması, sabit sohbet balonunun menüyü kapatması, çerez bandının ekranın yarısını kaplaması ve tarih seçicinin telefonda açılmaması. Lighthouse bunların hiçbirini "hata" olarak işaretlemez.

Ayrıca gerçek telefonda sayfayı mobil veriyle açmayı deneyin. Ofis Wi-Fi'ında hızlı görünen bir site, zayıf bir mobil bağlantıda bambaşka bir deneyim sunabilir. Kendi pratiğimde bu basit deneme, ekiplerin en çok şaşırdığı adım oluyor.

Kısacası araçlar size ölçüm verir; gerçek telefon ise size müşterinizin hissini verir. İkisine de ihtiyacınız var.

Test cihazı seçerken ekibinizin elindeki en yeni telefona güvenmeyin. Müşterilerinizin çoğu daha eski ve daha yavaş cihazlar kullanıyor olabilir. Bunu Google Analytics'teki cihaz raporundan kontrol edebilir, testi en yaygın model grubuna göre planlayabilirsiniz.

Mobil uyumluluk testi kontrol listesi: kendi ekibimle kullandığım maddeler

Aşağıdaki liste, her yeni sitede ve her büyük güncellemeden sonra uyguladığım mobil uyumluluk testi adımlarını içeriyor. Sırayla ilerlerseniz hiçbir temel noktayı atlamazsınız.

1. Viewport etiketi sayfada var mı ve genişliği cihaz genişliğine bağlıyor mu?
2. Gövde metnini yakınlaştırma yapmadan rahat okuyabiliyor musunuz?
3. Butonlar ve bağlantılar parmakla rahat dokunabileceğiniz boyutta ve aralıkta mı?
4. Sayfada yatay kaydırma oluşuyor mu?
5. Mobil sürümde masaüstündeki tüm ana içerik, başlıklar ve SSS bölümleri duruyor mu?
6. Title ve meta açıklama iki sürümde aynı mı?
7. Schema işaretlemesi mobil sürümde de mevcut mu?
8. Robots meta etiketleri iki sürümde aynı mı?
9. Ana içerik, kullanıcı dokunuşu beklemeden ekrana geliyor mu?
10. Pop-up pencereler içeriği kapatıyor mu?
11. Core Web Vitals saha verisi "iyi" eşiğinde mi?
12. Formu ve ödeme adımını gerçek telefonda sorunsuz tamamlayabiliyor musunuz?

Bu maddelerin detaylarını aşağıdaki bölümlerde tek tek açıyorum. Eğer bu listeyi kurumsal ölçekte düzenli uygulamak istiyorsanız, SEO danışmanlığı kapsamında bunu aylık bir rutine bağlayabiliriz.

Viewport, yazı boyutu ve dokunma alanlarını nasıl kontrol edersiniz?

İlk kontrol viewport etiketidir. Sayfanın kaynak kodunda head bölümünde width=device-width ifadesini içeren bir viewport meta etiketi olmalıdır. Bu etiket yoksa telefon, sayfayı masaüstü genişliğinde çizip küçültür ve metni okumak imkânsızlaşır. Lighthouse bu eksikliği en iyi uygulamalar altında gösterir.

İkinci kontrol yazı boyutudur. Lighthouse, sayfadaki metnin büyük bölümü okunaksız küçüklükteyse uyarı verir. Pratikte ben gövde metnini telefonda yakınlaştırma gerektirmeyecek büyüklükte tutarım ve satır aralığını da cömert bırakırım.

Üçüncü kontrol dokunma alanlarıdır. WCAG 2.2 standardının hedef boyutu kriteri, dokunma hedefleri için en az 24x24 CSS pikseli asgari eşik olarak tanımlıyor. Bu asgari sınırdır; rahat bir kullanım için ben butonları bundan belirgin biçimde büyük tasarlarım. Özellikle birbirine yakın duran footer bağlantıları bu testte sık sorun çıkarır.

Örneğin telefon numarası bağlantısı ile WhatsApp butonu yan yanaysa, kullanıcı yanlışlıkla diğerine dokunabilir. Bu küçük hata, doğrudan kaçan müşteri anlamına gelir.

Mobil ve masaüstü içerik eşitliğini nasıl doğrularsınız?

Mobil öncelikli dizinde en pahalı hata, içeriğin telefonda eksik olmasıdır. Bunu doğrulamanın en pratik yolu, URL Denetleme aracında Google'ın gördüğü HTML'i açıp kritik metinleri aramaktır. Masaüstünde gördüğünüz ana başlıklar, ürün açıklamaları ve SSS cevapları bu HTML'de yoksa sorun var demektir.

Google'ın rehberi burada birkaç konuda açık: mobil sitede masaüstüyle aynı içerik, aynı başlıklar, eşdeğer title ve meta açıklama, aynı schema işaretlemesi ve aynı robots meta etiketleri bulunmalı. Ayrıca rehber, ana içeriği kullanıcı etkileşimine bağlı olarak tembel yüklememenizi (lazy load) istiyor.

Bu yüzden tasarım ekibinin "mobilde sadeleştirelim" kararlarını dikkatle incelerim. Sadeleştirme iyi bir niyettir; ancak içerik silmek yerine içeriği akordeon ya da sekme içinde tutmak daha güvenlidir. Böylece metin HTML'de kalır ve Google onu görür.

Title ve meta açıklamanın telefonda nasıl göründüğünü görmek için Google SERP önizleme aracı işinize yarar. Eksik etiketleri tamamlamak için de meta tag oluşturucu ile hızlıca taslak çıkarabilirsiniz.

Pop-up pencereler ve reklamlar mobil deneyimi nasıl bozar?

Google'ın sayfa deneyimi rehberi, müdahaleci geçiş reklamlarından kaçınmanızı açıkça öneriyor. Telefonda bu sorun masaüstünden çok daha belirgindir, çünkü küçük ekranda bir pop-up pencere içeriğin tamamını kapatabilir.

Sahada en sık gördüğüm üç örnek şunlar: sayfayla birlikte ekrana gelen bülten kayıt penceresi, ekranın büyük kısmını kaplayan çerez bandı ve kapatma düğmesi zor bulunan kampanya bildirimi. Yasal zorunluluk olan çerez bildirimini elbette kaldırmazsınız; ancak onu içeriği tamamen kapatmayacak biçimde tasarlayabilirsiniz.

Ayrıca sabit öğeleri de sayın. Sabit üst menü, sabit alt bar, sohbet balonu ve çerez bandı aynı anda ekrandaysa, içerik için neredeyse yer kalmaz. Ben mobil testte ekranın ne kadarının gerçekten içeriğe ayrıldığına bakarım.

Bu konunun dönüşüm tarafını kurumsal sitede hemen çıkma oranını düşürme yazımda daha ayrıntılı anlattım. Özetle, ziyaretçi ilk saniyede içerik yerine engel görürse geri döner.

Görselleri, lazy loading'i ve schema işaretlemesini mobilde nasıl denetlersiniz?

Görseller, mobil hızın en büyük yüküdür. Telefon ekranına 400 piksel genişlikte çizilen bir görseli 3000 piksel genişlikte göndermek, hem bant genişliğini hem LCP süresini boşa harcar. Bu yüzden görselleri ekran boyutuna uygun sürümlerle sunmanızı ve sıkıştırmanızı öneririm. Hızlı bir çözüm için resim küçültme aracı işinizi görür.

Lazy loading konusunda ise bir dengeye dikkat edin. Ekranın altındaki görselleri geç yüklemek iyi bir uygulamadır. Ancak ilk ekrandaki ana görseli, yani çoğu zaman LCP öğesini geç yüklemek sayfayı yavaşlatır. Lighthouse bu durumu performans uyarıları arasında gösterir.

Schema işaretlemesi tarafında kontrol basittir: masaüstünde bulunan Breadcrumb, Product ya da FAQ işaretlemesi mobil HTML'de de yer almalıdır. Bunu URL Denetleme aracının gösterdiği HTML'de veya zengin sonuçlar testinde doğrularsınız.

Öte yandan görsellerin alt metinleri de iki sürümde aynı olmalı. Bu ayrıntı Google'ın mobil öncelikli dizin rehberinde ayrıca geçiyor.

Formları ve dönüşüm adımlarını mobilde nasıl test edersiniz?

Mobil SEO trafiği getirir; ancak o trafiği müşteriye çeviren şey formlar ve ödeme adımlarıdır. Bu nedenle mobil uyumluluk testi bence formla bitmelidir. Ben her kritik formu gerçek telefonda baştan sona doldurup gönderirim.

Kontrol ettiğim noktalar şunlar:

• Telefon alanında sayısal klavye çıkıyor mu?
• E-posta alanında @ işaretli klavye geliyor mu?
• Hata mesajları alanın yanında ve net biçimde görünüyor mu?
• Klavye açıkken gönder butonu erişilebilir durumda kalıyor mu?
• Gönderimden sonra teşekkür ekranı geliyor ve dönüşüm etiketi tetikleniyor mu?

Bu listedeki son madde çoğu zaman gözden kaçar. Form telefonda çalışır; fakat teşekkür sayfası yönlendirmesi bozuk olduğu için reklam paneli dönüşüm görmez. Yönlendirme zincirlerini yönlendirme denetleyici ile kontrol edebilirsiniz. Form tasarımının ayrıntıları için de randevu, teklif ve demo formu tasarımı yazıma göz atabilirsiniz.

Test sonuçlarında önce hangi sorunu düzeltmelisiniz?

Bir mobil denetimden genellikle onlarca uyarı çıkar. Hepsini aynı anda düzeltmeye çalışmak ekibi yorar ve önemli işleri geciktirir. Bu yüzden ben bulguları üç gruba ayırırım.

İlk grup, dizine eklemeyi etkileyen sorunlardır: mobilde eksik içerik, engellenen CSS veya JavaScript dosyaları ve farklı robots etiketleri. Bunlar Google'ın sayfayı yanlış anlamasına yol açar, dolayısıyla önceliğiniz bunlar olur.

İkinci grup, kullanımı engelleyen sorunlardır: yatay kaydırma, içeriği kapatan pop-up pencereler, çalışmayan menü ve gönderilemeyen formlar. Bu sorunlar doğrudan müşteri kaybettirir.

Üçüncü grup ise performans ve cilalama işleridir: Core Web Vitals iyileştirmeleri, görsel optimizasyonu ve küçük erişilebilirlik uyarıları. Bunlar önemlidir; ancak ilk iki grup çözülmeden bunlara odaklanmak, çatısı akan evin duvarını boyamaya benzer.

Bu önceliklendirme mantığı, UX ve SEO dengesi üzerine yazdığım yazıdaki yaklaşımla da örtüşüyor.

Mobil uyumluluk testini ne sıklıkla tekrarlamalısınız?

Mobil uyumluluk testi tek seferlik bir iş değildir. Tema güncellemesi, yeni bir eklenti, bir kampanya bandı ya da yeni bir sohbet aracı, dün sorunsuz olan sayfayı bugün bozabilir. Bu nedenle testi takvime bağlamanızı öneririm.

Benim kullandığım ritim saha tecrübesine dayanıyor, garanti değil; ama çoğu işletme için iyi bir başlangıç: her tasarım veya eklenti değişikliğinden sonra kritik sayfalarda Lighthouse ve gerçek telefon kontrolü, ayda bir Search Console Core Web Vitals raporuna bakış, üç ayda bir de tüm şablonlar için tam denetim.

Site yenileme dönemleri ise ayrı bir risk taşır. Yeni tasarım yayına girmeden önce mobil testi mutlaka tamamlamalısınız. Bu konudaki tüm adımları site yenileme sürecinde SEO koruma yazımda topladım.

Ayrıca test sonuçlarını basit bir tabloda saklayın. Tarih, sayfa, araç ve bulgu sütunları yeterlidir. Böylece bir sorun tekrar ettiğinde neyin değiştiğini hızla bulursunuz.

Mobil uyumluluk testi hangi sayfalarda öncelikli olmalı?

Her sayfayı her ay test etmek gerçekçi değildir. Bu yüzden ben önce şablonları test ederim. Bir e-ticaret sitesinde ana sayfa, kategori sayfası, ürün sayfası, sepet ve ödeme adımı genellikle beş temel şablondur. Bir şablondaki sorun, o şablonu kullanan yüzlerce sayfayı aynı anda etkiler.

İkinci öncelik, trafik ve gelir getiren sayfalardır. Search Console'daki Performans raporunda cihazı "mobil" olarak filtreleyip en çok tıklama alan sayfaları listeleyebilirsiniz. Böylece test emeğinizi gerçekten ziyaret edilen sayfalara yönlendirirsiniz.

Üçüncü öncelik ise reklam açılış sayfalarıdır. Google Ads'e para ödediğiniz her tıklamanın büyük kısmı telefondan geliyorsa, o sayfadaki her mobil hata doğrudan bütçe kaybıdır. Teknik tarafı daha geniş ele almak isterseniz yapay zeka sonrası teknik SEO yazım iyi bir tamamlayıcı olur.

Mobil uyumluluk testini tasarım aşamasına nasıl taşırsınız?

En ucuz mobil düzeltme, hiç yazmadığınız hatalı koddur. Bu yüzden ben mobil kontrolü tasarım aşamasına taşımayı öneririm. Tasarım dosyası hazırlanırken önce telefon görünümünü çizmek, sonra masaüstüne genişletmek birçok sorunu baştan önler.

Ayrıca geliştirme sürecinde her sayfa şablonu için basit bir kabul kriteri belirleyin: yatay kaydırma yok, ana içerik mobil HTML'de var, butonlar rahat dokunulabilir, Lighthouse en iyi uygulamalar kategorisinde viewport ve yazı boyutu uyarısı yok. Bu kriterleri karşılamayan şablon yayına çıkmaz.

Kendi web tasarım projelerimde bu kuralı uyguluyorum. Sonuç olarak yayın sonrası mobil düzeltme listesi çok daha kısa kalıyor ve müşteri ilk günden telefonda düzgün çalışan bir siteyle başlıyor.

Mobil SEO kontrolünde en sık yaptığım gözlemler nelerdir?

Yıllar içinde yaptığım mobil denetimlerde bazı hatalar neredeyse her sitede karşıma çıkıyor. Bunları bilmek, test sürenizi kısaltır; çünkü nereye bakacağınızı önceden bilirsiniz.

• Masaüstü için hazırlanmış büyük bir karşılaştırma tablosunun telefonda ekranı taşırması.
• Mobil menüde bazı kategori bağlantılarının hiç yer almaması; bu durum iç bağlantı yapısını zayıflatır.
• Telefonda gizlenen müşteri yorumları ve SSS blokları.
• Sabit sohbet balonunun gönder butonunun üstüne oturması.
• Mobil sürümde farklı bir alan adı ya da alt alan adı kullanan eski sitelerde yönlendirme karmaşası.

Bu hataların ortak noktası şu: hiçbiri tek bir otomatik skorda net görünmez. Örneğin Lighthouse bir tablonun taşmasını her zaman yakalamaz; ancak DevTools cihaz modunda iki saniyede fark edersiniz. Benzer biçimde mobil menüdeki eksik bağlantıyı yalnızca menüyü açıp tek tek kontrol ettiğinizde görürsünüz.

Dolayısıyla araç çıktılarını bir başlangıç noktası olarak görün. Asıl bulguları, sayfayı bir müşteri gibi kullandığınızda yakalarsınız. Ben her denetimde en az on dakikayı sadece telefonda gezinmeye ayırırım ve not alırım.

Sonuç: mobil SEO kontrolünü bir rutine dönüştürün

Google'ın eski mobil test aracı artık yok; ancak mobil uyumluluk hiç bu kadar belirleyici olmamıştı. Google sitenizi telefon gözüyle tarıyor, dizine ekliyor ve değerlendiriyor. Dolayısıyla mobil kontrol, SEO'nun kenar işi değil, merkezidir.

Özetle yol haritanız şu: Lighthouse ile teknik uyarıları görün, DevTools ile görünümü farklı ekranlarda deneyin, URL Denetleme ile Google'ın gözünden bakın, PageSpeed Insights ile gerçek kullanıcı verisini okuyun ve son sözü gerçek telefona bırakın. Kontrol listesini takvime bağlarsanız, sorunları müşterileriniz fark etmeden yakalarsınız.

Siteniz için bu denetimi birlikte yapmak isterseniz bana ulaşabilirsiniz. İlk görüşmede en kritik üç şablonunuza birlikte bakarız.