Lazy Loading ve SEO: Görsel, iframe, Kaydırma Rehberi

Lazy loading, yani bir kaynağı ihtiyaç duyulana kadar ertelemek, sayfa hızı çalışmalarının en sevilen hamlelerinden biridir. Ekranın altındaki görseller ilk yüklemede inmez, bant genişliği korunur, ilk görünüm hızlanır. Aynı hamle yanlış uygulandığında iki ayrı zarar üretir: ilk ekrandaki en büyük görsel geç gelir ve hız metriği kötüleşir, ya da içerik yalnızca bir kullanıcı eylemiyle yüklendiği için arama motoru onu hiç görmez. İki sorun da kodda küçük bir ayrıntıdan doğar ve çoğu zaman yalnızca ölçüm yapıldığında fark edilir.

Bu yazı frontend geliştiriciler, teknik SEO çalışanları ve içerik ekiplerine yöneliktir. Önce lazy loading'in ne zaman yarar sağladığını ayırır, ardından ilk ekran görselindeki klasik hatayı, Google'ın kaydırmayla yüklenen içeriği nasıl ele aldığını, iframe ve gömülü bileşenlerin durumunu, sonsuz kaydırmanın URL gereksinimlerini ve bir test rutinini anlatır. Görsel dosya biçimi, alt metin ve görsel site haritası gibi konular bu yazının odağı değildir; onlar için görsel SEO ve Google Görseller optimizasyonu yazısına bakın. Burada soru tek ve dardır: bir şeyin yüklenmesini ertelediğinizde, arama motoru ve kullanıcı onu yine de görüyor mu?

Arama hacmi, bir tekniğin sıralamaya sayısal etkisi ya da belirli bir hız kazancı rakamı verilmez. Bunlar siteden siteye değişir ve burada ölçülmüş bir veri yoktur. Yazıdaki bütün kurallar resmi dokümantasyona dayanır; dokümantasyonun söylemediği yerlerde bunu açıkça belirtiriz.

Lazy Loading Ne Zaman Fayda Sağlar, Ne Zaman Zarar Verir

Lazy loading, bir kaynağın ilk sayfa yüklemesinde değil, kullanıcıya yaklaştığında ya da gerektiğinde indirilmesidir. Mantık basittir: kullanıcı sayfanın en altına belki hiç inmeyecek, o halde en alttaki görseli neden ilk anda indirelim? Doğru kurulduğunda bu, ağ trafiğini azaltır ve tarayıcının ilk görünüm için gerçekten gerekli kaynaklara odaklanmasını sağlar.

Fayda sağladığı durumlar

Fayda en çok kaydırmadan sonra görünen, sayısı çok olan ve ağır kaynaklarda ortaya çıkar. Uzun bir blog yazısının alt kısmındaki görseller, ürün listesinin ilk ekranın dışında kalan kartları, sayfanın sonundaki gömülü harita ya da video oynatıcı bu gruptadır. Bir iframe tek başına bir sayfa kadar kaynak yükleyebildiği için ekran dışındaki gömülü bileşenleri ertelemek özellikle değerlidir. Tarayıcı düzeyinde erteleme hem görseller hem iframe'ler için desteklenir. Bu desteğin ayrıntıları web.dev'in tarayıcı düzeyinde lazy loading makalesinde (yeni sekmede açılır) tanımlanır: loading niteliğinin lazy değeri yüklemeyi görüntü alanına yaklaşana dek erteler, eager değeri ise varsayılan davranıştır ve kaynak konumundan bağımsız yüklenir.

Zarar verdiği durumlar

Zarar üç ayrı yoldan gelir. Birincisi, ilk ekranda görünen bir kaynağı ertelemektir; kaynak gereksiz yere geç gelir. İkincisi, ertelemenin mekanizmasının arama motorunun çalışma biçimiyle uyuşmamasıdır; örneğin içeriğin yalnızca belirli bir kullanıcı eylemi sonrasında yüklenmesi. Üçüncüsü, ertelenen kaynağa yer ayrılmamasıdır; görsel ya da iframe geldiğinde düzen kayar. İlk ikisi bu yazının ana konusudur, üçüncüsü ise kısaca aşağıda ele alınır.

Yer ayırmadan lazy loading yapmayın

Aynı web.dev makalesi, img etiketlerine genişlik ve yükseklik niteliklerinin verilmesini öneriyor. Nedeni iki yönlüdür. Boyut bilinmiyorsa tarayıcı yer ayıramaz ve kaynak geldiğinde düzen kayar, bu da düzen kayması (CLS) metriğini bozar. Makale ayrıca, boyutsuz görsellerin başlangıçta sıfıra sıfır ölçüde sayılabileceğini ve bu yüzden bir galerideki görsellerin hepsinin birden yüklenerek erteleme amacını boşa çıkarabileceğini belirtir. Yani boyut nitelikleri hem düzen kararlılığı hem de erteleme mantığının çalışması için gereklidir.

Hangi kaynak ertelenir, hangisi ertelenmez

Tablo bir karar çerçevesidir. Gerçek sayfada hangi kaynağın ilk ekranda kaldığı, cihaz genişliğine göre değişir; bu yüzden karar mobil ve masaüstü görünümde ayrı ayrı sınanmalıdır.

İlk Ekran (LCP) Görselini Lazy Yapma Hatası

Lazy loading hatalarının en yaygını, görüntü alanında ilk anda görünen bir görsele loading="lazy" eklemektir. Genellikle sebep iyi niyetlidir: bir araç, eklenti ya da şablon tüm görsellere nitelik ekler ve istisna tanımlanmaz. Sonuç, ilk ekranın en büyük öğesinin geç yüklenmesidir.

Resmi kılavuz ne diyor

web.dev'in tarayıcı düzeyinde lazy loading makalesi, sayfa yüklendiğinde görüntü alanında olması muhtemel görsellerin, özellikle LCP görselinin ertelenmemesini; bunlar için varsayılan eager yüklemenin kullanılmasını söyler. loading="lazy" yalnızca ilk görünümün dışındaki görseller için ayrılır. Google'ın lazy-loaded içerik kılavuzu da aynı doğrultuda, kullanıcıların hemen göreceği içeriğin ertelenmemesini ister. İki kaynak da ortak bir kural sunar: erteleme, ilk ekran dışındaki kaynaklar içindir.

LCP optimizasyon kılavuzu (yeni sekmede açılır) bu konuda daha da net konuşur ve LCP görselinin hiçbir koşulda lazy yüklenmemesini söyler. Aynı kılavuz, LCP süresini dört alt parçanın toplamı olarak tanımlar: ilk bayta kadar geçen süre, kaynak yükleme gecikmesi, kaynak yükleme süresi ve öğe oluşturma gecikmesi. Ertelenmiş bir LCP görseli esas olarak kaynak yükleme gecikmesini büyütür, çünkü tarayıcı görseli, düzen hesaplanıp görselin görüntü alanında olduğu anlaşılana kadar indirmeye başlamaz. Bu ayrıntıyı, kılavuzun genel mantığından yapılan bir çıkarım olarak okuyun; belge bu cümleyi aynen kurmaz.

Görseli bulunabilir tutun

LCP kılavuzu, LCP kaynağının başlangıç HTML'inde bulunabilir olmasını da önerir; böylece tarayıcının ön tarama mekanizması onu erken fark eder. img etiketinde src ya da srcset varsa bu sağlanır. CSS arka plan görseli HTML'den keşfedilemez; bu durumda kılavuz preload kullanılmasını öneriyor. Script ile sonradan eklenen ya da yalnızca harici CSS ve JS içinde başvurulan görseller, ilgili kod çalışana dek beklemek zorunda kalır. Önemli görselde fetchpriority="high" kullanılabilir; kılavuz bunu bir ya da iki görselden fazlasına vermenin etkisini düşürdüğünü de belirtir. web.dev makalesine göre fetchpriority="high" ile loading="lazy" birlikte anlamlı değildir, çünkü görsel ekran dışındayken yine ertelenir.

Pratik denetim

• Sayfanın ilk ekran görüntüsünü alın ve görünen bütün img öğelerini listeleyin; bunlardan hiçbirinde loading="lazy" olmamalı.
• Şablonda ya da eklentide "tüm görsellere lazy ekle" ayarı varsa ilk görseli hariç tutan bir istisna tanımlayın.
• Mobil ve masaüstü ilk ekranları ayrı ayrı kontrol edin; masaüstünde ilk ekranda olan üç görselin mobilde ikisi aşağı kalabilir.
• Ana görsel CSS arka plan olarak veriliyorsa gerçek bir img öğesine çevirmeyi ya da preload kullanmayı değerlendirin.
• Görsellere gerçek genişlik ve yükseklik değerlerini verin.

Hız tarafının geniş çerçevesi, ölçüm araçları ve eşikler sayfa hızı ve Core Web Vitals rehberinde anlatılıyor. Burada yalnızca lazy loading'in o çerçeveye nasıl bağlandığına bakıyoruz: ertelenmesi gereken şey ilk ekranın dışındakilerdir, ilk ekranın içindekiler değil.

Google Kaydırmayla Yüklenen İçeriği Nasıl Görür

Asıl SEO riski burada başlar. Bir görsel geç gelirse yalnızca hız kaybedilir; içerik hiç yüklenmezse sayfa arama motoru için o içerik olmadan var olur. Google'ın lazy-loaded içerik kılavuzu (yeni sekmede açılır), uygulamanın görüntü alanına giren tüm ilgili içeriği yüklemesi gerektiğini söyler.

Kılavuzun temel kuralları

Kılavuzun özeti üç cümleyle verilebilir. Birincisi, yanlış kurulmuş erteleme içeriği Google'dan gizleyebilir. İkincisi, güvenli yöntemler tarayıcının yerleşik lazy loading'i, IntersectionObserver arayüzü ve içeriği görüntü alanına girdiğinde yükleyen bir JavaScript kütüphanesidir. Üçüncüsü, içeriğin yüklenmesi kullanıcı eylemine bağlı olmamalıdır. Kılavuz bunu doğrudan bu kelimelerle değil, içeriğin görüntü alanına girince yüklenmesi ilkesiyle ifade eder; dolayısıyla "tıkla, sonra yüklensin" ya da "kaydır, sonra yüklensin" kalıpları riskli bölgeye girer.

Bu kuralın pratik anlamı şudur: sayfa, bir robotun kullanıcı gibi davranmasına güvenmemelidir. Görüntü alanına giren her şeyin yüklenmesi, tarayıcının bir sayfayı yalnızca açıp belirli bir boyutta ekranda göstermesi yeterli olacak biçimde kurgulanmalıdır. Kaydırma olayını dinleyen ve yalnızca fare tekerleği hareket ettiğinde tetiklenen bir kod bu şartı karşılamaz. Aynı işi IntersectionObserver ile yapan kod karşılar, çünkü tetik olayı kullanıcı eylemi değil, öğenin görüntü alanıyla kesişmesidir.

İşleme (render) ve neden önemli

Google'ın JavaScript SEO temelleri (yeni sekmede açılır) belgesi, 200 durum koduyla dönen sayfaların JavaScript içersin içermesin işleme kuyruğuna alındığını anlatır. Sayfa kuyrukta birkaç saniye ya da daha uzun bekleyebilir; kaynaklar uygun olunca başsız bir Chromium sayfayı işler. Google işlenmiş HTML'den bağlantıları ayıklar ve yeni URL'leri tarama kuyruğuna ekler; sayfayı dizine alırken de işlenmiş HTML'yi kullanır. Belge ayrıca yalnızca işlenmiş HTML'de görünen içeriğin dizine alınabileceğini söyler. Lazy loading açısından sonuç doğrudan: erteleme kodunuz işleme sırasında içeriği HTML'ye getirmiyorsa, o içerik dizinde yoktur.

Aynı belgenin bir başka kuralı bağlantılarla ilgilidir: Google yalnızca href niteliği olan a öğelerindeki bağlantıları keşfedebilir. Kaydırınca yüklenen bir "daha fazla" bileşeni, bağlantıyı tıklanabilir bir div ya da düğme olarak üretiyorsa, o bağlantı keşfedilmeyebilir. Belge ayrıca farklı içerik göstermek için URL parçalarının (#/urunler gibi) kullanılmamasını, gerçek URL'ler için History API'nin tercih edilmesini söyler.

Belgenin söylemedikleri

Lazy loading belgesi, görüntü alanı boyutunun nasıl belirlendiğini, kaydırma olaylarının işlenip işlenmediğini ya da noscript içeriğinin nasıl ele alındığını anlatmaz. Bu ayrıntıları kesin bilgi gibi aktaran yazılara şüpheyle yaklaşın. Bilinen şudur: önerilen yöntemler, ilgili içeriğin görüntü alanına girdiğinde yüklenmesini sağlar; kullanıcı eylemi bekleyen yöntemler önerilen yöntemler arasında yer almaz. Belgede olmayan bir davranışa güvenmek yerine, aşağıdaki test bölümündeki yöntemle sayfanızın işlenmiş hâlini kendiniz görün.

Kurgusal örnek: Yorumlar bölümü

Kurgusal örnek: bir ürün sayfasındaki yorumlar, kullanıcı "Yorumları göster" düğmesine bastığında bir istekle çekiliyor. Yorum metni ürünün güven sinyali ve özgün içeriğidir. Düğme basılmadıkça yorumlar HTML'de yer almadığından, arama motorunun gördüğü sayfada yorum yoktur. İki çözüm düşünülebilir: yorumların ilk bölümünü sunucu tarafında doğrudan HTML'ye yazmak, ya da yorum bölümünü görüntü alanına girdiğinde yükleyen bir IntersectionObserver kurgusuna taşımak. Hangisinin seçileceği yorum sayısına ve sunucu maliyetine bağlıdır. Bu örnek rakamsızdır ve yalnızca karar mantığını gösterir.

Görseller ve iframe'ler İçin Güvenli Uygulama

Pratikte iki mekanizma kullanılır: tarayıcının kendi desteği ve JavaScript ile kurulan özel çözümler. Hangisi seçilirse seçilsin hedef aynıdır: içerik görüntü alanına girince yüklenmeli ve arama motorunun işlenmiş HTML'sinde bulunabilmelidir.

Yerleşik loading niteliği

Görsel ve iframe için loading niteliği en az sorun çıkaran yöntemdir, çünkü kaynak adresi HTML'de zaten yazılıdır. web.dev makalesine göre görseller için destek Chrome 77, Edge 79, Firefox 75 ve Safari 15.4 ile başlar; iframe desteği Chrome 77, Edge 79, Firefox 121 ve Safari 16.4 ile başlar. Desteklemeyen tarayıcılar niteliği yok sayar, yani eklemek zarar vermez. Aynı makale birkaç uyarı daha içerir: erteleme yalnızca JavaScript etkinken çalışır, CSS arka plan görselleri bu nitelikten yararlanamaz, display none ile gizlenen görsel yüklenmez ama opacity 0 ile gizlenen yüklenir ve sayfa yazdırılırken bütün görseller hemen yüklenir. Tarayıcının erteleme mesafesi eşikleri sabit kodludur ve bu eşikler zaman içinde değişmiştir; belirli bir piksel değerine bağlı bir tasarım kurmayın.

CSS arka plan görselleri ayrı bir konu

Google'ın görsel SEO kılavuzu (yeni sekmede açılır), görsellerin img öğesinin src niteliğinden bulunduğunu, picture içindeki img için de bunun geçerli olduğunu, CSS görsellerinin ise dizine alınmadığını söyler. Bu yüzden indekslenmesini istediğiniz bir görseli arka plan olarak verip üstüne lazy yöntemi eklemek iki katman risk üretir. İçerik görseli ise gerçek bir img öğesi olmalıdır. Responsive görselde srcset ya da picture kullanılabilir ama kılavuz, bazı tarayıcıların ve tarayıcı botlarının bu nitelikleri desteklemediğini hatırlatarak src'li bir img yedeğinin bırakılmasını ister.

JavaScript ile kurulan çözümler

Özel çözümlerde en sık görülen kalıp, gerçek adresi data-src gibi bir niteliğe koyup src'yi boş bırakmaktır. Bu kalıp, kütüphane çalıştığında adresi src'ye taşır. Sorun, işleme sırasında kütüphanenin çalışmaması ya da tetikleyicinin hiç gerçekleşmemesi halinde HTML'de hiçbir görsel adresinin olmamasıdır. Google'ın lazy loading belgesi, test aşamasında görsel ve video URL'lerinin işlenmiş HTML'deki img ve video öğelerinin src niteliklerinde görünmesini kontrol etmeyi söyler. Bu, kalıbın başarılı olup olmadığını anlamanın en doğrudan yoludur. Yeni bir proje başlıyorsanız yerleşik niteliği tercih edin; özel kütüphane yalnızca gerçekten ek davranış (örneğin bulanık önizleme) gerekiyorsa mantıklıdır.

İframe ve gömülü bileşenler

İframe'lerde ertelemek performans açısından en kazançlı alanlardan biridir, ama SEO açısından iki soruyu birlikte sormak gerekir. Birincisi, iframe'in içeriği sizin sayfanızın bir parçası olarak mı değerlendirilmeli? Harita, takvim ya da video gibi gömülü içerikler çoğu zaman o sayfanın asıl metni değildir; ertelense de sayfanın dizine alınmasını etkilemez. İkincisi, sayfanın asıl içeriği iframe içinde mi? Eğer ana metin başka bir kaynaktan iframe ile geliyorsa, o metin sizin sayfanızın içeriği olarak değerlendirilmeyebilir; bu, lazy loading'den bağımsız ayrı bir mimari sorudur ve bu yazıda kesin hüküm verilmez.

Pratik kural: ana içeriğin iframe içinde olmasından kaçının, ertelenen iframe'e anlamlı bir title verin ve ilk ekranda yer alan bir iframe'i ertelemeyin. Video gömüleri için bir "tıklayınca oynat" ön yüzü sık kullanılır; böyle bir kurulumda sayfanın videoyla ilgili metin, başlık ve yapılandırılmış bilgisi HTML'de görünür kalmalı, yalnızca ağır oynatıcı ertelenmelidir. Video bulunabilirliği ayrı bir konudur ve video SEO ve YouTube rehberinde ele alınır.

Sonsuz Kaydırma ve Sayfalandırma Bağlantıları

Sonsuz kaydırma, kullanıcı aşağı indikçe yeni öğeleri aynı sayfaya ekleyen bir kalıptır. Kullanıcı için akıcıdır; arama motoru için ise her öğe grubunun ulaşılabilir bir adresi olması gerekir. Google'ın lazy-loaded içerik belgesi bu konuda net bir çözüm sunar.

Her parçaya kalıcı bir URL

Belge, içeriğin her bölümüne kalıcı ve benzersiz bir URL verilmesini ister. URL'nin içeriği her yüklemede aynı olmalıdır; bunun için ?page=12 gibi mutlak sayfa numaraları örnek verilir. ?date=yesterday gibi göreli parametreler, aynı adresin zamanla farklı içerik göstermesine yol açtığı için uygun değildir. Parçaların birbirine sırayla bağlanması da gerekir, böylece tarayıcılar serideki sayfaları keşfedebilir. Yeni bir parça ana görünür içerik olduğunda, adres çubuğu History API ile güncellenmelidir; böylece kullanıcı sayfayı yenilediğinde ya da paylaştığında aynı noktaya döner.

Bu kuralın kategori sayfalarındaki karşılığı

E-ticaret listelerinde bu, her "daha fazla yükle" adımının arkasında gerçek bir sayfa URL'si bulunması demektir. Düğme tıklandığında içerik getirilebilir, ama aynı içerik /kategori?page=2 gibi ayrı bir adreste de erişilebilir olmalıdır ve o adres, a öğesiyle, href niteliğiyle bağlanmalıdır. Sayfalandırmanın kanonik, bağlantı yapısı ve filtre kombinasyonları açısından ayrıntıları kategori sayfalandırma SEO rehberinde ele alınır; bu yazıda yalnızca lazy loading bağlantısını kuruyoruz.

Üç yaygın kurgu ve sonuçları

Tablodaki üçüncü satır, sayfalandırmayı temel alıp kaydırma deneyimini bunun üstüne kurmanın "aşamalı geliştirme" yaklaşımıdır. Bu ad Google belgesinden gelmez, kurguyu tanımlamak için burada kullanılan bir ifadedir. Önce çalışan, bağlantılı sayfalandırma gelir; sonra JavaScript bunu kullanıcı için akıcı hale getirir.

Kurgusal örnek: Blog arşivi

Kurgusal örnek: bir blog arşivi yeni yazıları kaydırdıkça ekliyor. Arşivin ikinci ve sonraki "sayfaları" yalnızca JavaScript'in çağırdığı bir uç noktada yaşıyor ve tarayıcı adres çubuğu değişmiyor. Eski yazılara ancak sitenin başka yerlerinden bağlantı varsa ulaşılabiliyor. Çözüm, arşive /blog?page=2 gibi gerçek sayfalar eklemek, ilk sayfanın sonunda bu sayfaya href'li bir bağlantı bırakmak ve sonsuz kaydırma kodunu bu sayfaları getiren bir katman olarak kullanmaktır. Bu örnek rakam içermez.

Test: URL Denetimi ve İşlenmiş HTML Karşılaştırması

Lazy loading hataları kodu okuyarak her zaman görünmez; çünkü çoğu hata ancak belirli bir görüntü alanı genişliğinde, belirli bir yükleme sırasında ya da belirli bir ağ koşulunda ortaya çıkar. Güvenilir yöntem, Google'ın sayfayı nasıl işlediğine bakmaktır. Google'ın lazy loading belgesi de bunu önerir: URL Denetimi aracıyla tüm içeriğin yüklendiğini doğrulayın.

URL Denetimi aracı ne gösterir

Search Console'daki URL Denetimi aracı (yeni sekmede açılır) iki ayrı görünüm sunar. Dizinlenmiş sürüm, Google'ın en son dizine aldığı hâli yansıtır ve güncel sayfadan farklı olabilir. Canlı test ise URL'yi o anda getirir; sonuçları dizinlenmiş sürümden farklı olabilir. Yardım sayfasına göre, ham HTML, HTTP başlıkları, JavaScript konsol çıktısı ve yüklenen kaynaklar, dizinlenmiş sürüm için "Taranan sayfayı görüntüle", canlı test için "Test edilen sayfayı görüntüle" bağlantılarıyla görülür. İşlenmiş sayfanın ekran görüntüsü ise yalnızca başarılı bir canlı testte sunulur.

Aracın sınırları da bellidir. Canlı test site haritalarını ve yönlendiren sayfaları denetlemez, kanonik seçimini belirlemez ve bir yönlendirme izlense bile son adresi göstermez. Bir "URL Google'da" sonucu uygunluk anlamına gelir, arama sonuçlarında görüneceğinin garantisi değildir. Mülk başına günlük limit vardır. Ayrıca sunucu ya da DNS hataları geçici olabilir; bu yüzden canlı testteki bir hata ile gerçek tarama sırasındaki durum farklı olabilir.

Adım adım kontrol

1. Sorunlu olduğundan şüphelendiğiniz URL'yi Search Console'da denetleyin ve canlı test çalıştırın.
2. "Test edilen sayfayı görüntüle" ile işlenmiş HTML'yi açın.
3. Ertelenen bölümün metnini HTML içinde arayın. Metin yoksa içerik yüklenmemiş demektir.
4. Ertelenen görsel ve videoların adreslerini img ve video öğelerinin src niteliklerinde arayın; Google'ın belgesi bunu açıkça kontrol noktası olarak verir.
5. Ekran görüntüsünde ertelenen bölümlerin boş ya da yer tutucu olarak görünüp görünmediğine bakın.
6. Kaynak ve konsol bölümünde engellenmiş dosya ya da hata olup olmadığını inceleyin; engellenen bir betik ertelenmiş içeriğin hiç yüklenmemesine yol açabilir.
7. Sonsuz kaydırma kullanıyorsanız ikinci, üçüncü sayfa URL'lerini ayrı ayrı denetleyin.

Araç dışı hızlı kontroller

Search Console erişiminiz yoksa ya da yayına almadan önce bir ön kontrol istiyorsanız, tarayıcının geliştirici araçları işe yarar. Ağ sekmesinde sayfayı ilk açtığınızda hangi görsellerin indiğine bakın; ilk ekranda görünen bir görsel gecikiyorsa bu LCP sorununun işaretidir. Sayfayı kaydırmadan elementler sekmesinde ertelenen img öğelerinin src niteliğini inceleyin. Bu, Google'ın işleme sonucunun yerine geçmez, yalnızca geliştirme sırasında hızlı bir ön eleme sağlar.

İşlenmiş HTML ile kaynak HTML'yi karşılaştırın

Sayfanın kaynak HTML'si ile işlenmiş HTML'sini yan yana koymak, hangi içeriğin yalnızca JavaScript sonrasında geldiğini gösterir. Kaynak HTML'de bulunan her şey ek bir işleme adımına bağımlı değildir ve en güvenli konumdur. Yalnızca işlenmiş HTML'de bulunan içerik ise Google'ın işleme adımına bağlıdır; JavaScript SEO belgesine göre bu adım kuyrukta beklemeyi içerebilir. Bu fark küçük bir yardımcı metin için sorun olmayabilir; ürün açıklaması, ana metin ya da önemli bağlantılar için ise mümkün olduğunca kaynak HTML'de tutulması savunulabilir. İşlemenin genel mantığı ve teşhis yöntemi JavaScript SEO, işleme ve indeksleme yazısında daha geniş anlatılıyor.

Yayın sonrası düzenli kontrol

Lazy loading ayarları şablon güncellemeleri, eklenti sürümleri ve yeni bileşenlerle sessizce değişir. Yayın sonrasında ilk ekran görseli, ilk ürün listesi ve en az bir sayfalandırılmış URL için aynı denetimi kısa bir kontrol listesine bağlayın. Kontrol, tek bir doğru sonuç aramak yerine "ertelenen her şeyin işlenmiş HTML'de bulunduğunu" doğrulamayı hedeflemelidir.

Sık Yapılan Hatalar

• Tüm görsellere toplu lazy eklemek: İlk ekran görseli de dâhil edilir ve LCP süresi uzar. İstisna tanımlayın.
• Boyut vermeden ertelemek: Görsel geldiğinde düzen kayar; boyutsuz görseller galeride hepsi birden de yüklenebilir.
• İçeriği düğme ya da kaydırma olayına bağlamak: Kullanıcı eylemi bekleyen içerik, arama motorunun işlenmiş HTML'sinde yer almayabilir.
• Gerçek adresi yalnızca data niteliğinde tutmak: Kütüphane çalışmazsa HTML'de görsel adresi hiç bulunmaz.
• İçerik görselini CSS arka plan yapmak: Google CSS görsellerini dizine almaz; içerik görseli img olmalıdır.
• Sonsuz kaydırmada URL vermemek: Sonraki öğelere ulaşan bir bağlantı ya da adres yoksa, o öğeler keşfedilemez.
• Bağlantıyı div ile üretmek: href'siz bağlantılar keşfedilmeyebilir.
• Test etmemek: Kod doğru görünse bile işlenmiş sonuç farklı olabilir; URL Denetimi bu farkı gösterir.

Sıkça Sorulan Sorular

loading="lazy" Google'ın görseli dizine almasını engeller mi?

Doğru kullanıldığında engellemez. Google'ın kılavuzu tarayıcının yerleşik lazy loading'ini güvenli yöntemlerden biri olarak sayar. Önemli olan, görsel adresinin HTML'de img öğesinin src niteliğinde bulunması ve işlenmiş HTML'de görünmesidir. Bunu URL Denetimi aracındaki işlenmiş sayfadan doğrulayın.

İlk ekrandaki görsele lazy loading eklemeli miyim?

Hayır. web.dev, görüntü alanında ilk anda görünmesi muhtemel görsellerin, özellikle LCP görselinin ertelenmemesini ve varsayılan eager yüklemenin kullanılmasını söyler. Erteleme yalnızca ilk görünümün dışındaki görseller için uygundur.

Kaydırmayla ya da düğmeyle yüklenen içerik dizine alınır mı?

Garanti edilemez. Google, içeriğin görüntü alanına girdiğinde yüklenmesini ve kullanıcı eylemine bağlı olmamasını ister. Yalnızca düğme tıklanınca ya da bir kaydırma olayında gelen içerik işlenmiş HTML'de yer almayabilir; IntersectionObserver gibi yöntemler daha güvenlidir.

Sonsuz kaydırmada SEO için ne gerekir?

Her içerik parçasının kalıcı, benzersiz ve her yüklemede aynı içeriği veren bir URL'si olmalıdır. Örneğin mutlak sayfa numarası kullanılır. Bu sayfalar href'li a öğeleriyle sırayla bağlanmalı ve yeni bölüm görünür olunca adres History API ile güncellenmelidir.

Lazy loading'in çalıştığını nasıl test ederim?

Search Console'da URL Denetimi aracıyla canlı test yapın, test edilen sayfanın HTML'ine bakın ve ertelenen metnin ile görsel adreslerinin işlenmiş HTML'de bulunduğunu doğrulayın. Ekran görüntüsünü ve konsol çıktısını da inceleyin.

Sonuç

Lazy loading, doğru yerde kullanıldığında hız kazandıran, yanlış yerde kullanıldığında hem hızı hem görünürlüğü zedeleyen bir araçtır. Kural iki cümlede toplanır: ilk ekrandaki kaynağı, özellikle LCP görselini ertelemeyin; ertelediğiniz her içerik görüntü alanına girince, kullanıcı eylemi beklemeden yüklensin ve Google'ın işlenmiş HTML'sinde görünsün. Görsel ve iframe için yerleşik loading niteliği, sonsuz kaydırma için gerçek ve href'li sayfa adresleri, doğrulama için URL Denetimi bu kuralın pratik karşılıklarıdır.

Hiçbir teknik belirli bir sıralama ya da hız skoru garanti etmez; amaç, hem ziyaretçinin hem arama motorunun sayfanın tamamını görebilmesidir. Teknik düzeni kurduktan sonra, görseller ve sayfa metinleri için profesyonel destek isterseniz Akua Adforce'ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.