JavaScript SEO denetimi: 2026 için adım adım denetim rehberi

JavaScript SEO denetimi neden ayrı bir süreç ister?

JavaScript SEO denetimi, klasik HTML kontrolünden ayrı düşünülmelidir çünkü Google bir sayfayı tek adımda değerlendirmez. Resmi rehberde anlatıldığı gibi süreç önce crawl, sonra render, ardından index kararına gider; bu yüzden sayfa tarayıcıda düzgün açılıyor olsa bile kritik alanlar Google tarafında eksik kalabilir (Google Search Central). Özellikle ana içerik, iç linkler veya canonical yalnızca sonradan oluşuyorsa sorun görünmez değil, gecikmiş görünürlük şeklinde ortaya çıkar.

Ticari niyeti yüksek URL’lerde bu fark daha pahalıya mal olur. Kategori, ürün, hizmet ve lead toplama sayfalarında görünmeyen içerik; bozuk snippet, zayıf başlık eşleşmesi ve geç keşfedilen alt sayfalar demektir. Kısacası sorun yalnızca index almak değildir; doğru URL’nin doğru başlıkla, doğru içerikle ve doğru bağlantı ağıyla görünmesi gerekir. JavaScript yüzünden title, meta description, heading veya structured data geç ekleniyorsa tıklanma ve dönüşüm kalitesi de etkilenir.

2026 itibarıyla risk alanı yalnızca Google ile sınırlı değil. Google dışındaki AI görünürlük katmanları ve çeşitli crawler akışları, pratikte ham HTML’i ve doğrudan erişilebilir metni daha çok önemser. Bu nedenle rendered DOM kusursuz görünse bile ilk HTML zayıfsa görünürlük zinciri kırılabilir. Terminolojiyi ekip içinde ortaklaştırmak istiyorsanız SEO terimleri sözlüğü bu denetimlerde iyi bir referans noktasıdır.

Aynı URL’yi üç gözle test edin: ham HTML, DOM ve canlı test

En pratik denetim, aynı URL’yi üç panelde yan yana açmaktır: View Source ile ham HTML, tarayıcı geliştirici araçlarında render edilmiş DOM ve Search Console’da canlı test. Bu yaklaşım sorunu teoriden çıkarır. Hangi öğenin sunucudan geldiğini, hangisinin yalnızca tarayıcıda üretildiğini ve hangisinin Google’ın canlı testinde hâlâ eksik kaldığını aynı anda görürsünüz.

İlk bakmanız gereken alanlar nettir: ana içerik bloğu, iç linkler, rel=canonical, title, meta description, heading yapısı ve JSON-LD. Google Search Console yardım dokümanında, canlı testte ekran görüntüsü, raw HTML, HTTP headers, JavaScript console çıktısı ve yüklenen sayfa kaynaklarının görülebildiği açıkça belirtilir (URL Inspection Tool). Bu ekran, render sonrası gerçekten ne kaldığını doğrulamak için en kritik kanıttır.

Uygulamalı denetimde asıl fark, sayısal boşluğu görünür kılmaktır. Örneğin ham HTML’de yalnızca 6 kategori linki varken DOM’da 24 link oluşuyorsa, keşif neredeyse tamamen render aşamasına bırakılmıştır. Benzer şekilde DOM’da görünen meta description canlı testte yoksa genelde geç çalışan bir bundle, bloklanan bir kaynak ya da API timeout problemi vardır. Tek URL, üç çıktı, tek karar notu yaklaşımı ekip içinde en az tartışmayla en çok netlik üreten yöntemdir.

• Ham HTML kontrolü: İçerik, kritik linkler ve canonical gerçekten kaynakta var mı?
• DOM kontrolü: Tarayıcı son durumda hangi başlıkları, kartları ve metinleri ekliyor?
• Canlı test kontrolü: Googlebot benzeri görünümde ekran görüntüsü, kaynak ve console hataları tutarlı mı?
• Fark analizi: Kaybolan öğe içerik mi, link mi, meta alanı mı, yoksa schema mı?

Keşif ve erişilebilirlik kontrolleri: linkler, içerik blokları ve lazy loading

Keşfedilebilirlik tarafında ilk soru şudur: Google yeni URL’leri gerçekten bağlantı olarak görebiliyor mu? Menü, filtre, kategori kartı veya pagination elemanları yalnızca click, hover ya da custom event sonrası oluşuyorsa keşif güvenilirliği düşer. Link metninin görünmesi yetmez; gerçek bir href üretmesi gerekir. Özellikle SPA yapılarda buton gibi duran ama URL üretmeyen öğeler, insan için çalışsa bile crawler için kör nokta oluşturur.

Burada ikinci kontrol routing katmanıdır. History API kullanan SPA yapılarında temiz URL üretmek faydalıdır; ancak fragment tabanlı yapılar, eksik sunucu yanıtları ve sitemap’te yer almayan derin sayfalar görünürlük kaybı yaratır. Kategori 2, kategori 3 veya ürün varyasyonları yalnızca istemci tarafı geçişle açılıyor; sunucu aynı URL’lerde anlamlı HTML dönmüyorsa o sayfalar keşif ve indexleme arasında sıkışır. Soft 404 riski de özellikle hata rotalarının her istekte 200 dönmesiyle büyür.

Lazy loading ise performans için faydalı olabilir ama kritik içerik ona emanet edilmemelidir. MDN’nin lazy loading rehberinde bu yaklaşımın çoğunlukla scroll ve navigation gibi etkileşimler sırasında devreye girdiği anlatılır (MDN Web Docs). SEO açısından problem tam da budur: açıklama metni, ürün listesi ya da iç link bloğu yalnızca scroll sonrası doğuyorsa crawler aynı derinliği göremeyebilir. Görseli lazy load etmek başka, metni ve linki lazy load etmek başka bir karardır.

• İç linkler: Tıklama beklemeden doğrudan href ile üretildiğinden emin olun.
• Pagination: Her sayfa ayrı URL, ayrı içerik ve sitemap izi taşımalıdır.
• Routing: Sunucu, halka açık rotalara boş kabuk değil anlamlı HTML döndürmelidir.
• Lazy loading: Kritik metin ve link blokları scroll bağımlı olmamalıdır.
• Kaynak erişimi: API timeout, engelli JS ve bloklanan CSS kritik bölümleri gizlememelidir.

URL Inspection, Rich Results Test ve loglarla doğrulama akışı

Bu aşamada amaç, sorunun gerçekten render mı, crawl mı, indexleme mi olduğunu ayırmaktır. URL Inspection’da önce indexed result ile live test arasındaki farkı okuyun. Search Console yardım sayfası, ilk ekrandaki sonucun canlı sürüm değil, Google’ın en son indexlediği sürüm olduğunu açıkça söyler; güncel sayfayı görmek için Live Test gerekir (Google Search Console Help). Bu ayrım kritik, çünkü ekipler sıklıkla eski index verisini canlı durum sanıp yanlış yere müdahale eder.

Ardından Rich Results Test ile schema ve render sonrası kaynak kodu doğrulayın. Google’ın resmi dökümantasyonuna göre araç, rendered source code üzerinden bulunan zengin sonuç türlerini, hata ve uyarıları gösterir; ayrıca varsayılan user agent smartphone’dur ve tüm kaynakların anonim kullanıcıya açık olması gerekir (Rich Results Test). Bu yüzden canlı sitede çalışan ama giriş, firewall veya robots engeline takılan kaynaklar testte görünmeyebilir. Schema’nın DOM’da görünmesi yetmez; test aracının onu gerçekten çözebilmesi gerekir.

Son katman log ve hata verisidir. Google’ın JavaScript sorun giderme rehberi, Googlebot ve Web Rendering Service’in temel içeriğe katkı vermeyen bazı kaynakları çekmeyebileceğini ve istemci tarafı analytics verisinin tek başına tam resim vermeyebileceğini vurgular (Fix Search-related JavaScript problems). Pratik ayrım şudur: HTML isteği var ama içerik API’si 500 dönüyorsa bu render sorunudur; çocuk URL’lere hiç istek gitmiyorsa keşif sorunudur; canlı test temiz ama indexlenmiş sürüm eskiyse bu çoğu zaman yeniden tarama ve işleme sırası problemidir.

CSR, SSR, SSG ve prerender için 2026 karar matrisi

2026’da kamuya açık sayfalar için temel soru artık şudur: SEO sinyallerini ne kadarını ilk HTML’de garanti ediyorsunuz? web.dev’in 5 Ocak 2026 güncellenen rendering rehberi, birçok senaryoda tam rehydration yaklaşımı yerine server-side rendering veya static rendering düşünülmesini önerir (web.dev). Bunun nedeni yalnızca performans değil; içerik, link ve meta alanlarının daha erken ve daha kararlı görünmesidir.

Saf CSR, uygulama deneyimi için yanlış değildir; ancak halka açık landing page, kategori, ürün ve şehir sayfalarında risk daha yüksektir. React tabanlı projelerde halka açık route’lar için SSR, SSG veya prerender çoğu zaman daha güvenlidir. Next.js tarafında sunucu bileşenleri ve statik üretim avantaj sağlar ama client component bağımlılığı arttıkça risk geri gelir. Nuxt projelerinde route bazlı render kararları fark yaratır. Angular ya da benzeri saf CSR yapılarda ise en azından kritik rotalara prerender ya da SSR katmanı eklemek görünürlük tarafını belirgin biçimde güçlendirir.

Denetimde karar verirken üç metriğe bakın: ilk HTML’de içerik görünürlüğü, link keşfi güvenilirliği ve snippet tutarlılığı. Hydration gecikmesi, büyük JS paketleri ve render bloklayan üçüncü taraf bağımlılıklar bu üç alanı aynı anda bozabilir. Google’ın JavaScript SEO basics rehberi, canonical ve HTTP durum kodlarının ilk katmanda tutarlı olmasının önemini özellikle vurgular; SPA hata rotalarında soft 404 yönetimi de bunun parçasıdır (Google Search Central). Kısacası mimari tercihi geliştirici rahatlığına göre değil, URL tipine göre vermek gerekir.

• Landing page: SSR, SSG veya prerender daha güvenli tercihtir.
• Kategori ve ürün URL’leri: İlk HTML’de metin, link ve canonical görünmelidir.
• Giriş gerektiren uygulama ekranları: Saf CSR kabul edilebilir, SEO önceliği düşüktür.
• Büyük JS bundle’ları: Hydration gecikmesi ve meta tutarsızlığı üretebilir.

Adım Adım JavaScript tabanlı bir URL için SEO denetimi

Aşağıdaki akış, tek bir URL üzerinde hızlı ama savunulabilir bir denetim yapmanızı sağlar. Amaç aynı anda hem geliştiriciye net hata kaydı vermek hem de SEO tarafında hangi düzeltmenin önce yapılacağını belirlemektir.

1. Ham HTML çıktısını alın ve kaydedin. View Source, curl veya JS kapalı görünümle sayfanın ilk HTML’ini saklayın. Ana metin, iç linkler, canonical, title, meta description ve structured data gerçekten sunucudan geliyor mu bunu işaretleyin. İlk HTML boşsa veya yalnızca uygulama kabuğu dönüyorsa sorun büyük ihtimalle mimari düzeydedir.
2. Render edilmiş DOM ile farkları eşleyin. Tarayıcıda son DOM’u açın ve ham HTML’de olmayan öğeleri tek tek not edin. İçerik kartları, breadcrumb, ürün açıklaması, filtre linkleri veya FAQ blokları yalnızca burada görünüyorsa bunlar render bağımlıdır. Bu fark, keşif mi yoksa yalnızca snippet kalitesi mi etkilenecek sorusunun temel cevabını verir.
3. İç link ve routing akışını test edin. Menü, kategori, pagination ve kart tıklamalarının gerçek URL üretip üretmediğini kontrol edin. Buton görünümlü ama href üretmeyen öğeler, fragment tabanlı rotalar ve 200 dönen hata sayfaları özellikle not edilmelidir. Sitemap’te yer alan URL’lerin sunucudan anlamlı HTML dönmesi, bu adımın geçme koşuludur.
4. Meta, canonical ve schema’yı doğrulayın. Title, description, canonical ve JSON-LD alanlarını hem ilk HTML’de hem DOM’da karşılaştırın. İlk HTML ile render sonrası değerler farklıysa Google tutarsız sinyal alabilir. Canonical’ın sonradan başka URL’ye çevrilmesi, client-side soft 404 mantığı ve eksik structured data çoğu projede aynı kökten gelir.
5. Canlı test ve rich result kontrollerini çalıştırın. URL Inspection canlı testinde ekran görüntüsü, rendered HTML, HTTP headers ve JavaScript console çıktısını inceleyin. Sonra Rich Results Test ile schema’nın gerçekten parse edilip edilmediğini kontrol edin. Kaynak yüklenmiyorsa, robots veya erişim problemi varsa bunu render sorunu gibi değil kaynak erişim sorunu gibi etiketleyin.
6. Bulguları önceliklendirin ve tekrar ölçün. Trafik kaybı üreten eksikleri önce kapatın: görünmeyen ana içerik, keşfedilemeyen iç linkler, soft 404 ve canonical çakışmaları. Ardından düzeltme sonrası aynı URL’yi tekrar üç gözle test edin. Değişiklik yalnızca tarayıcıda değil, canlı test ve yeniden tarama sinyallerinde de görünmüyorsa iş tamamlanmış sayılmaz.

Bulguları önceliklendirme ve SEOYEN ile tekrar denetim planı

Bulgu listesi tamamlandığında hepsini aynı torbaya atmayın. Önce etkisi yüksek, doğrulaması kolay hataları ayırın: ilk HTML’de görünmeyen ana içerik, keşfedilemeyen iç linkler, canonical çakışması, noindex hatası ve soft 404 rotaları genelde ilk sıradadır. İkinci sırada lazy loading yüzünden eksik kalan destekleyici bloklar, render sonrası bozulan structured data ve timeout’a giren API bileşenleri yer alır. Bu sıra, mühendislik eforunu en yüksek görünürlük geri dönüşüne bağlar.

Tekrar ölçüm tarafında iş akışını ikiye ayırmak verimlidir. Teknik ekip düzeltmeleri kapatırken pazarlama ekibi sonuç etkisini izlemelidir. Bu noktada site audit raporu teknik kırılımları tek yerde toplamaya yardımcı olurken, AI görünürlük analizi ham HTML fallback’i zayıf sayfaların Google dışındaki görünürlüğünü ayrıca takip etmeyi kolaylaştırır. SEOYEN’in farkı burada belirginleşir: tüm SEO araçlarını tek platformda toplar, Türkçe arayüz sunar, TL bazlı fiyatlandırma kullanır ve yerel Türkçe destekle teknik ekip ile pazarlama ekibi arasındaki yorum farkını azaltır.

Ahrefs veya SEMrush benzeri geniş araç setlerinden gelen ekipler için esas fark, aynı denetim disiplinini Türkiye pazarına uyarlanmış daha sade bir iş akışında bulabilmektir. Rakip araçlar pek çok işi yapar; SEOYEN bunu yerel ekiplerin daha hızlı karar vereceği biçimde bir araya getirir. Paket karşılaştırmasını içerikte sabitlemek yerine güncel fiyat ve paket seçenekleri sayfasına bakmak daha sağlıklıdır; böylece denetim planı fiyat değişse de güncelliğini korur.

Sıkça Sorulan Sorular