Mobile-First İndeksleme ve Mobil Uyumluluk Kontrol Listesi

Mobile-first indeksleme, Google'ın sitenizi öncelikle mobil sürümü üzerinden taraması, indekslemesi ve değerlendirmesi anlamına gelir. Bu yüzden asıl soru artık sayfanın telefonda düzgün görünüp görünmediği değil, mobil sürümün masaüstündeki içerik, meta veri ve link yapısını eksiksiz taşıyıp taşımadığıdır.

Bu kontrol listesi, "mobil uyumlu mu" sorusunu "mobil sürüm tam mı" sorusuna çevirir. Önce kavramı ve iki sorunun farkını netleştirir, ardından içerik, meta veri, görsel, gezinme ve robots başlıklarında mobil ile masaüstü arasındaki farkları nasıl bulacağınızı anlatır. Sayfanın JavaScript ile oluşturulan kısmı ayrı bir konudur; onu JavaScript SEO ve rendering yazısında ele aldık.

Mobile-First İndeksleme Nedir

Google'ın Search Central belgesine (yeni sekmede açılır) göre mobile-first indeksleme, bir sitenin içeriğinin Google tarafından akıllı telefon tarayıcısıyla taranıp indeksleme ve sıralama için kullanılması demektir. Yani sistemin gördüğü "gerçek" sayfa, masaüstü tarayıcıda gezdiğiniz sayfa değil, telefon tarayıcısına sunulan sayfadır. Belge, bu kapsamda bir mobil sürümün Arama'da yer almak için zorunlu olmadığını, ancak çok güçlü biçimde önerildiğini de söyler.

Bu tanım üç pratik sonuç doğurur:

• Masaüstünde olup mobilde olmayan metin, görsel veya link, Google'ın gördüğü sayfada yoktur.
• Mobil sürümdeki başlıklar, title ve meta description değerleri indeksleme için esas alınan veridir.
• Mobil sürümü robots kuralıyla, giriş duvarıyla ya da hatalı yönlendirmeyle erişilemez bırakmak, doğrudan taranabilirliği etkiler.

Belge, sitelerin tek tek "mobile-first indekslemeye alındığı" bir çerçeveden söz eder ve genel bir tamamlanma tarihi vermez. Bu nedenle sitenizin durumunu varsaymayın; Search Console'dan kendiniz kontrol edin. Hangi Googlebot türünün sayfayı taradığına URL Denetimi aracından bakabilirsiniz.

Bir şeyi baştan ayıralım: Mobile-first indeksleme, "mobil sıralama ayrı, masaüstü sıralama ayrı" demek değildir. İndeks tek bir indekstir; fark, o indekse hangi sürümün içeriğinin girdiğidir. Mobil sürüm eksikse eksik içerik girer. Bu yüzden asıl sorun genellikle tasarımda değil, eksik kalan parçalardadır.

Mobil Uyumluluk ile Mobil Sürüm Paritesi Farkı

"Mobil uyumlu" ifadesi çoğunlukla görünüm ve kullanım için söylenir: yazı okunuyor mu, düğmelere dokunulabiliyor mu, sayfa yana kayıyor mu. "Mobil parite" ise içerik eşitliğini ifade eder: masaüstü sürümdeki bilgi mobilde de var mı. İki ölçüt bağımsızdır. Güzel görünen bir mobil sayfa, masaüstündeki tabloyu, SSS bölümünü veya ürün özelliklerini kırpmışsa pariteyi bozmuş olabilir.

Basit bir ayrım tablosu düşünün:

• Uyumluluk sorusu: Kullanıcı bu sayfayı telefonda rahatça kullanabilir mi?
• Parite sorusu: Google, telefon sürümünde masaüstündeki tüm indekslenecek bilgiyi görebilir mi?

Şöyle bir durumu düşünün (örnek senaryo): küçük bir yazılım şirketi, ürün sayfasındaki teknik özellik tablosunu mobilde yer kazanmak için tamamen kaldırıyor. Sayfa hızlı ve temiz görünüyor, dokunma hedefleri yeterli. Ancak "entegrasyon listesi" gibi aranan terimler yalnızca o tabloda geçiyordu. Mobil sürüm görsel olarak başarılı, indeks açısından eksiktir.

Bu yüzden denetimi iki ayrı tur olarak yapmak mantıklıdır. İlk tur kullanıcı deneyimine bakar; ikinci tur, mobil ve masaüstü kaynak kodunu içerik, meta, link ve yapısal veri açısından karşılaştırır. Bu yazı ağırlıklı olarak ikinci turu anlatıyor; ilk turda tarayıcının cihaz modu ve gerçek telefon denemesi yeterli temel verir.

Duyarlı Tasarım, Dinamik Sunum ve Ayrı Mobil URL

Google belgesi üç yapılandırmayı sayar. Hangisini kullandığınız, hangi kontrollerin gerekli olduğunu belirler.

1. Duyarlı tasarım: Aynı URL, aynı HTML; görünüm CSS ile cihaza uyar. Belge bunu uygulaması ve bakımı en kolay desen olarak önerir ve içerik ile meta verinin iki sürümde zaten aynı olduğunu belirtir.
2. Dinamik sunum: Aynı URL, ama cihaza göre farklı HTML. Sunucu kullanıcı aracısına bakar ve Vary başlığı kullanılması gerekir.
3. Ayrı mobil URL: Örneğin m. alt alan adı. Farklı URL, farklı HTML ve kullanıcı aracısına göre yönlendirme vardır.

Belgedeki parite önerileri özellikle dinamik sunum ve ayrı URL için geçerlidir; duyarlı tasarımda iki sürüm zaten aynı kaynak koddur. Bu nedenle, yeni bir site kuruyorsanız duyarlı tasarım hem bakım yükünü hem de parite hatası riskini azaltır.

Ayrı mobil URL kullanıyorsanız belge birkaç özel kural verir:

• Masaüstü URL kanoniktir; mobil sayfa masaüstüne canonical ile, masaüstü sayfa mobile alternate link ile (uygun medya sorgusuyla) bağlanmalıdır.
• Hata sayfası davranışı iki sürümde aynı olmalıdır.
• Mobil URL'lerde parça tanımlayıcı (#) kullanılmamalıdır.
• Farklı içerikli masaüstü sayfaları mobil ana sayfaya toplu yönlendirilmemelidir.
• Her iki sürüm de Search Console'da doğrulanmalı, hreflang masaüstüne masaüstünü, mobile mobili göstermelidir.

Bu kuralların çoğu "iki ayrı site yönetmenin" bedelidir. Bakım ekibiniz iki sürümü senkron tutamıyorsa, ayrı URL yapısından duyarlı tasarıma geçmek, uzun vadede kontrol listesini ciddi biçimde kısaltır.

Mobilde Eksik Kalan İçerik ve Gizlenen Bölümler

En sık parite sorunu, mobilde "sadeleştirme" adı altında içeriğin kırpılmasıdır. Yaygın örnekler şunlardır:

• Uzun açıklama metninin mobilde kısaltılması veya tamamen çıkarılması
• Ürün özellikleri, karşılaştırma tabloları ve SSS bölümlerinin gizlenmesi
• Kenar çubuğu veya alt bölümdeki ilgili içerik bloklarının mobilde kaldırılması
• Yorum ve değerlendirmelerin yalnızca masaüstünde yüklenmesi

Google belgesi mobil sitenin masaüstündeki ana içeriği taşımasını ister. Aynı belge, düzen için akordeon ve sekme kullanmanın kabul edilebilir olduğunu söyler; yani içerik katlanmış bir panelde durabilir, ama sayfada bulunmalıdır. Sorun, içeriğin yalnızca bir tıklamadan sonra istek atılarak yüklenmesidir. Bu durumu "Mobilde Lazy Load" bölümünde ayrıca ele alıyoruz.

Bir bölümün gerçekten mobilden çıkarılıp çıkarılmadığını anlamak için iki sürümün kaynağını karşılaştırın. Masaüstü sayfada görünen bir paragrafın bir cümlesini kopyalayıp mobil kaynak kodda aratın. Bulunmuyorsa kırpma vardır. Daha sistemli bir yol için, sayfa türü başına bir "ana içerik envanteri" tutun: başlıklar, tablolar, SSS, ürün özellikleri, iç linkler. Sonra her kalemi iki sürümde işaretleyin.

Karar ölçütü basit: kullanıcı mobilde de bu bilgiye ihtiyaç duyuyorsa, mobilde de olmalıdır. Yer sorunu yaşıyorsanız çıkarmak yerine katlayın: akordeon, "devamını oku" paneli ve sekmeler, içeriği DOM'da tutan çözümlerdir.

Meta Veri, Yapısal Veri ve Canonical Paritesi

İçerik görünürken meta veri paritesi gözden kaçar. Google belgesi, title ve meta description değerlerinin iki sürümde eşdeğer olmasını önerir. Yapısal veri için de aynı: iki sürümde aynı işaretleme bulunmalı ve işaretlemedeki URL'ler, mobil sürümde mobil URL'leri göstermelidir. Belge özellikle Breadcrumb, Product ve VideoObject gibi türleri öne çıkarır.

Denetlerken şunlara bakın:

1. Title ve meta description iki sürümde aynı mı, yoksa mobil şablon başka bir değeri mi basıyor?
2. Robots meta etiketi iki sürümde aynı mı? Mobilde fazladan bir noindex veya nofollow varsa, belge bunun tarama ve indekslemeyi engelleyebileceğini söyler.
3. Canonical iki sürümde tutarlı mı? Ayrı URL kullanıyorsanız mobil canonical masaüstünü göstermelidir.
4. Yapısal veri mobilde de var mı, yoksa şablonda yalnızca masaüstü bloğa mı eklenmiş?
5. Hreflang kullanıyorsanız mobil URL'ler mobil alternatifleri mi gösteriyor?

Yapısal veri konusunda bir ilke daha var: işaretleme görünür içerikle uyumlu olmalıdır. Mobilde görünmeyen bir içerik için işaretleme eklemek, eşitsizliği küçültmez, büyütür.

İpucu: Bu kontrolü sayfa türü başına bir kez yapmanız yeterlidir. Ürün, kategori, makale, ana sayfa gibi şablonlar aynı mantıkla çalışır. Bir şablonda düzelttiğiniz hata, o şablonu kullanan binlerce sayfayı düzeltir.

Mobil Sürümde Görsel, Video ve Lazy Load Sorunları

Google belgesinin görsel önerileri nettir: iki sürümde aynı alt metni kullanın, kaliteli ve desteklenen biçimde görseller sunun, görsel URL'lerini kararlı tutun. Belge, mobil sürümde farklı görsel URL'leri kullanmanın geçici görsel trafiği kaybına yol açabileceğini de belirtir. Yani "mobil için ayrı küçük görsel" adı altında URL'leri tamamen değiştirmek, görsel aramadaki konumu riske atar. Görsel optimizasyonunun tamamı için görsel SEO rehberine bakın.

Videoda benzer şekilde desteklenen biçimler, kararlı URL'ler ve video yapısal verisinin iki sürümde bulunması önerilir; mobilde video bulunması ve bulunabilir olması gerekir.

Lazy load ne zaman sorun olur

Belge net bir uyarı yapar: ana içeriği kullanıcı etkileşimi sonrasında yüklemeyin. Googlebot kaydırma, tıklama veya yazma gibi eylemleri yapmaz; bu yüzden "devamını yükle" düğmesinin arkasında kalan içerik görünmeyebilir. Tarayıcıda görünür alana girince yüklenen standart lazy load görsellerde genellikle sorun çıkarmaz; ama içerik metni, linkler ve önemli görseller bir tıklamaya bağlıysa risk başlar.

Hızlı bir görsel denetim

• Mobil kaynakta img etiketlerinde alt metin ve gerçek kaynak var mı, yoksa yalnızca yer tutucu mu?
• Ana içerik görselleri kullanıcı eylemi olmadan yükleniyor mu?
• Mobil ve masaüstü aynı görsel URL'sini mi kullanıyor?

Mobil Gezinme ve İç Link Farkları

Mobil menüler yer kazanmak için sadeleştirilir; bu sırada iç link yapısı zayıflayabilir. Masaüstünde mega menüyle ulaşılan yüzlerce kategori sayfasına, mobilde yalnızca birkaç ana bağlantı üzerinden ulaşılıyorsa, tarayıcı için sitenin yapısı küçülmüştür. Google'ın bağlantıları takip ederek sayfaları keşfettiğini düşünürsek, mobil sürümde olmayan link, keşfedilebilirlikten çıkar.

Denetim için şu noktalara bakın:

• Ana menü, alt bilgi ve ilgili içerik bloklarındaki linkler iki sürümde aynı mı?
• Filtre ve sayfalandırma bağlantıları mobilde "daha fazla yükle" düğmesine mi dönüştü? Bu durumda sonraki sayfalara gerçek bir link var mı? Kategori yapısı için kategori sayfalandırma rehberimizi inceleyin.
• Breadcrumb mobilde gizlenmiş mi?
• Önemli sayfalara giden bağlantılar yalnızca bir JavaScript olayıyla mı açılıyor, yoksa standart bir a href mi?

Mobil menüde yer sınırlıysa, bağlantıları kaldırmak yerine hiyerarşik bir yapıya (açılır alt menüler) alın; böylece kullanıcı sade bir arayüz görürken kaynak kod bağlantıları korur. İç link planının genel mantığı ve değeri için iç linkleme stratejisi yazısına bakabilirsiniz; burada önemli olan, mobil sürümün bu planın bir kısmını sessizce silmemesidir.

Robots, Kaynak Erişimi ve Mobil Taranabilirlik

Mobil sürümün taranabilir olması, içeriğin eşit olmasından önce gelir. Belge iki konuda net: mobil kaynak URL'lerini robots.txt ile engellemeyin, ve iki sürümde çoğu durumda aynı robots.txt kurallarını kullanın. Ayrıca robots meta etiketlerinin iki sürümde aynı olmasını ister.

Gerçek hayatta sık görülen hatalar:

• m. alt alan adının kendi robots.txt dosyasında tüm sitenin engellenmiş olması (geliştirme döneminden kalma)
• Mobil şablonun CSS veya JavaScript klasörlerini engelleyen bir kural taşıması
• Mobil sayfada gövde yerine bir giriş duvarı, çerez perdesi veya tam ekran bir uyarı çıkması
• Kullanıcı aracısına göre farklı HTTP durum kodu dönmesi

Bu kontrolü robots.txt'yi inceleyerek başlatın. Nasıl test edileceğini robots.txt testi yazımızda anlattık. Ardından Search Console'da URL Denetimi canlı testiyle Google'ın sayfayı nasıl işlediğini görün. Belge ayrıca ayrı URL kullananlarda mobil sitenin olası tarama hızı artışını karşılayacak sunucu kapasitesine sahip olmasını önerir.

Site haritanız da iki sürümü tutarlı yansıtmalı. Ayrı URL kullanıyorsanız site haritasına hangi URL'lerin girdiğini ve canonical ile uyumunu XML site haritası denetimi kontrol listesinden doğrulayabilirsiniz.

Mobil Kullanıcı Deneyimi Sinyalleri

Parite, indeksin ham maddesini korur; kullanıcı deneyimi ise ziyaretçinin sayfada kalıp kalmayacağını belirler. Bu başlıktaki kontroller görünüm ve kullanım üzerinedir ve hız ayrıntısına girmez, çünkü sayfa hızı ve Core Web Vitals ayrı bir yazının konusudur.

• Görünüm alanı ayarı: Sayfanın viewport meta etiketi yoksa mobil tarayıcı masaüstü düzenini küçültür.
• Okunabilir yazı boyutu: Kullanıcı yakınlaştırmadan okuyabilmeli.
• Dokunma hedefleri: Bitişik bağlantı ve düğmeler yanlış dokunuşa yol açmayacak kadar ayrık olmalı.
• Yatay kaydırma: İçerik ekran genişliğine sığmalı; geniş tablolar kendi kaydırma alanında sunulmalı.
• Araya giren öğeler: Ekranın büyük bölümünü kaplayan açılır pencereler ve reklamlar, içeriğe erişimi zorlaştırır. Google belgesi de sayfanın üstünde mobil ekranda çok yer kaplayan reklamlardan kaçınmayı önerir.
• Formlar: Doğru klavye tipi, yeterli alan boyutu ve görünür etiketler.

Mobil kullanılabilirlik sorunlarını bulmak için araç listenizi güncel tutun. Tarayıcıların cihaz modu, gerçek bir telefon ve Lighthouse gibi araçlar işi görür; Search Console'da URL Denetimi canlı testi de sayfanın Google tarafından nasıl göründüğünü gösterir. Hangi aracın hâlâ sunulduğunu kullanmadan önce kontrol edin; arama araçları zaman içinde değişir.

Denetimi Düzenli Bir Sürece Bağlamak

Parite hataları çoğunlukla bir tasarım güncellemesi, yeni eklenti ya da tema değişikliğiyle geri gelir. Tek seferlik bir denetim yerine hafif ama düzenli bir süreç daha etkilidir.

1. Sayfa türü envanteri: Ana sayfa, kategori, ürün veya hizmet, makale gibi şablonları listeleyin.
2. Şablon başına referans sayfa: Her şablon için bir temsilî URL seçin.
3. Karşılaştırma turu: Referans sayfaların mobil ve masaüstü kaynağını içerik, meta, link, görsel ve yapısal veri açısından kıyaslayın.
4. Değişiklik tetikleyicileri: Tema güncellemesi, yeni eklenti, menü değişikliği ve kodlama sprinti sonrasında turu yeniden yapın.
5. Kayıt: Bulgular, tarih ve düzeltme sahibini bir tabloda tutun.

Aylık bir ritim çoğu site için yeterlidir; sık yayın yapan sitelerde yeni şablon çıktığında ek tur eklemek yeterlidir. Her turun sonunda Search Console'da kapsam ve tarama bilgilerinde olağan dışı bir değişiklik olup olmadığına bakın. Bu kayıtlar ekipte "bir şey değişti, bozulan ne?" sorusuna hızlı yanıt verir.

Örnek Şablon: Mobil ve Masaüstü Parite Kontrol Tablosu

Mobil ve masaüstü sürümü satır satır karşılaştıran bir kontrol tablosu aşağıda yer alıyor. İçindeki bulgular örnek değerlerdir ve bir ürün sayfası şablonu için kurgulanmıştır; yerine kendi şablonlarınızın bulgularını yazın.

Bu örnek senaryoda tabloyu dolduran ekip, mobilde SSS bölümünün tema ayarı yüzünden hiç basılmadığını ve görsellerin alt metninin mobil şablonda boş geldiğini fark ediyor. İkisi de ziyaretçiyi görsel olarak etkilemediği için aylarca gözden kaçmıştı. Tablonun işi tam olarak bu: görünmeyeni görünür kılmak. Açık kalan her satıra bir sorumlu atayın ve sonraki turda tabloyu yeniden doldurun.

Sıkça Sorulan Sorular

Mobile-first indexing ne demek?

Mobile-first indexing, Google'ın bir sitenin mobil sürümünü akıllı telefon tarayıcısıyla tarayıp indeksleme ve sıralama için esas almasıdır. Masaüstü sürümde olup mobilde bulunmayan içerik değerlendirmeye girmeyebilir. Bu yüzden mobil sürümün, indekslenmesini istediğiniz içeriğin tamamını taşıması gerekir.

Sitem mobile-first indekslemeye geçti mi, nasıl anlaşılır?

Search Console'daki URL Denetimi aracında sayfanın hangi Googlebot türüyle tarandığına bakarak anlaşılır; akıllı telefon tarayıcısı görünüyorsa site mobil sürüm üzerinden değerlendiriliyordur. Ayrıca Ayarlar bölümündeki tarama bilgisini inceleyin. Ayrı mobil URL kullanıyorsanız her iki sürümü de ayrı mülk olarak doğrulayın.

Site mobil uyumlu nasıl yapılır?

En kolay yol, her cihazda aynı HTML'i sunan duyarlı tasarım kullanmaktır; Google da bunu önerir. Ardından metin, görsel, meta veri ve linklerin mobilde masaüstüyle eşit olduğunu doğrulayın. Dokunma hedefleri, okunabilir yazı boyutu ve yatay kaydırma gerektirmeyen düzen kullanılabilirliği tamamlar.

Mobil ve masaüstü içeriği aynı olmak zorunda mı?

Birebir aynı görünmek zorunda değil, ancak indekslenmesini istediğiniz ana içerik iki sürümde de bulunmalı. Google, mobil sitenin masaüstündeki ana içeriği taşımasını önerir. Mobilde akordeon veya sekme kullanmak düzen açısından kabul edilebilir; asıl sorun içeriği mobilden tamamen çıkarmaktır.

Mobil kullanılabilirlik sorunları nasıl bulunur?

Tarayıcı geliştirici araçlarının cihaz modunda sayfayı küçük ekranda gezerek ve gerçek bir telefonda temel sayfaları deneyerek bulunur. Search Console'daki URL Denetimi canlı testi, Google'ın sayfayı nasıl işlediğini gösterir. Lighthouse gibi araçlar ek ipuçları verir; sonuçları elle doğrulayın.

Mobilde lazy load SEO'ya zarar verir mi?

Doğru uygulanırsa zarar vermez; önemli olan içeriğin kaydırma, tıklama veya yazma gibi kullanıcı eylemi beklemeden yüklenebilmesidir. Google, ana içeriğin kullanıcı etkileşimiyle yüklenmemesini önerir; çünkü Googlebot bu eylemleri yapmaz. Ekran dışı görsellerde standart lazy load yaklaşımı genellikle sorunsuzdur.

Sonuç ve Sonraki Adım

Mobile-first indeksleme, mobil sürümü bir vitrin olmaktan çıkarıp indeksin esas kaynağı yapar. Bu yüzden önce sitenizin yapılandırmasını (duyarlı, dinamik, ayrı URL) netleştirmek, ardından içerik, meta veri, görsel, link ve robots başlıklarında iki sürümü karşılaştırmak ve bulguları şablon bazında düzeltmek gerekir. Kullanılabilirlik denetimi ayrı bir tur olarak eklenir.

Denetimde açıklama metinleri, SSS bölümleri ya da kategori girişleri eksik çıkarsa yazı hizmetleri bölümünden bunları yeniden yazdırmak mümkün: ürünü seçersiniz, sepet ve ödemeyi tamamlarsınız, satıcı onaylar, teslimat bildirilir; sorun olursa itiraz yolu açıktır. Neyin eksik olduğunu bilmeden içerik sipariş etmek zaman kaybettirir, o yüzden parite tablosunu önce doldurun.