Google SEO'da JavaScript içerik nasıl indekslenir?

Google, JavaScript içeriğini URL’yi tarayıp kodu oluşturduktan sonra indeksler. Kritik metin, bağlantı ve meta veriler oluşturulan HTML içinde görünmüyorsa sayfa eksik indekslenebilir.

React, Vue ve Angular kullanmak tek başına SEO sorunu oluşturmaz. Asıl belirleyici, Googlebot’un aldığı yanıt ile JavaScript çalıştıktan sonra oluşan belgenin erişilebilir ve tutarlı olmasıdır.

Google JavaScript içeriğini hangi aşamalarda indeksler?

Google, JavaScript sayfalarını tarama, oluşturma ve indeksleme olarak üç ayrı aşamada işler. Bir URL’nin taranması, ekrandaki bütün içeriğin hemen Google dizinine girdiği anlamına gelmez.

1. Tarama: Googlebot URL’ye istek gönderir. Sunucunun döndürdüğü durum kodunu, başlangıç HTML’ini, robots kurallarını ve bağlantıları inceler.
2. Oluşturma: Google’ın Web Rendering Service sistemi gerekli JavaScript dosyalarını çalıştırır. React, Vue veya Angular bileşenleri bu aşamada belgeye eklenebilir.
3. İndeksleme: Oluşturulan sayfadaki ana içerik, başlıklar, bağlantılar, canonical işareti ve diğer sinyaller değerlendirilir. Uygun bulunan bilgiler Google dizinine alınır.

Tarama ile oluşturma aynı anda tamamlanmak zorunda değildir. JavaScript oluşturma ek kaynak gerektirdiği için işlem daha sonra gerçekleşebilir. Bunun kesin süresi site, sayfa ve tarama koşullarına göre değişir.

Sunucudan yalnız boş bir <div id="root"> dönüyorsa Google önce sınırlı bir belge görür. İçerik ancak paketler indirilip başarıyla çalıştırılırsa oluşur. Dosya hatası, API kesintisi veya robots engeli bu zinciri bozar.

İndeksleme ayrıca garanti edilen bir sonuç değildir. Google bir URL’yi tarayabilir, oluşturabilir ve yine de dizine eklemeyebilir. Yinelenen içerik, yanlış canonical, noindex işareti veya düşük içerik değeri buna yol açabilir.

Bu nedenle yalnız sunucu erişim kayıtlarında Googlebot isteği görmek yeterli değildir. URL’nin oluşturulan HTML’i ve Google tarafından seçilen canonical adresi ayrıca kontrol edilmelidir.

Googlebot JavaScript ile yüklenen içeriği görebilir mi?

Googlebot, erişilebilir JavaScript dosyaları hatasız çalıştığında sonradan yüklenen içeriği görebilir. Ancak kullanıcı tarayıcısında görünen her öğenin Google tarafından da görüleceği varsayılmamalıdır.

Google’ın oluşturma sistemi modern web özelliklerinin büyük bölümünü destekler. Yine de kullanıcı oturumu, konum izni, çerez onayı veya kaydırma gibi etkileşimlere bağlı içerikler güvenilir biçimde oluşmayabilir.

Örneğin ürün açıklaması yalnız kullanıcı bir sekmeye tıklayınca API’den getiriliyorsa ilk oluşturulan belgede bulunmayabilir. Kritik içerik, kullanıcı hareketi beklemeden URL açıldığında yüklenmelidir.

Benzer risk sonsuz kaydırma düzeninde görülür. Googlebot sayfayı bir insan gibi sürekli kaydırmaz. Her ürün veya yazı grubu, taranabilir ve benzersiz bir URL üzerinden de erişilebilir olmalıdır.

Bağlantılar gerçek HTML bağlantısı olarak üretilmelidir. <a href="/urun/izmir-kahve"> biçimi keşfedilebilir. Yalnız onclick olayı kullanan düğmeler, Google’a güvenilir bir URL ilişkisi sunmaz.

Yanlış: İçerik tarayıcıda göründüğü için Google kesinlikle görür. Doğru: İçerik, Googlebot koşullarında oluşturulan HTML içinde aranmalı ve bağlantılarıyla birlikte doğrulanmalıdır.

API uç noktalarının da Googlebot’a açık olması gerekir. Kimlik doğrulama isteyen, hız sınırına takılan veya bölgesel olarak engellenen API yanıtları boş bileşenler üretebilir.

Giriş yapmış kullanıcıya özel panellerin indekslenmesi beklenmez. Buna karşılık kategori açıklaması, hizmet metni ve ürün bilgisi gibi organik arama içeriği oturum açmadan alınabilmelidir.

CSR, SSR ve SSG arasında SEO açısından ne fark vardır?

SSR ve SSG, kritik içeriği başlangıç HTML’inde sunduğu için yalnız istemci taraflı oluşturmaya göre daha düşük indeksleme riski taşır. Doğru uygulanmış CSR ise yine indekslenebilir.

CSR modelinde sunucu genellikle temel kabuğu ve JavaScript paketlerini gönderir. Tarayıcı paketleri çalıştırır, API verisini alır ve içeriği DOM içine yazar. Zincirdeki her bağımlılık yeni hata noktasıdır.

SSR, HTML’i her istek sırasında sunucuda oluşturur. Kullanıcı ve Googlebot ana metni daha erken alır. Ancak yavaş veri kaynakları, sunucu süresini ve ilk yanıt gecikmesini artırabilir.

SSG, sayfaları derleme aşamasında üretir. Çok sayıda ve sık değişen ürün bulunan yapılarda her değişiklik için tam derleme verimsiz olabilir. Artımlı üretim veya seçici yenileme bu durumda değerlendirilir.

Hibrit yaklaşım çoğu işletme sitesi için daha kontrollüdür. Hizmet, kategori ve içerik sayfaları SSR veya SSG kullanabilir. Teklif hesaplayıcı gibi etkileşimli araçlar istemci tarafında çalışabilir.

Dinamik oluşturma, Googlebot’a ayrı HTML sürümü gönderme yöntemidir. Bu yaklaşım kalıcı mimari yerine geçici çözüm sayılmalıdır. İki farklı çıktıyı eşit tutmak bakım yükü ve tutarsızlık riski doğurur.

Seçim yalnız framework adına göre yapılmamalıdır. URL sayısı, güncelleme sıklığı, API yanıt süresi ve içerik türü ölçülmelidir. Her rota için aynı oluşturma yöntemi zorunlu değildir.

React, Vue ve Angular sayfaları SEO için nasıl yapılandırılır?

React, Vue ve Angular sayfalarında kritik içerik ilk HTML’e alınmalı, her ekran benzersiz URL taşımalı ve meta veriler rota düzeyinde üretilmelidir. Framework varsayımları ayrıca test edilmelidir.

React projelerinde yalnız tarayıcıda çalışan temel kurulum yerine sunucu veya statik oluşturmayı destekleyen bir mimari seçilebilir. Framework seçimi kadar sayfanın gerçek HTTP çıktısı önemlidir.

Vue tarafında sunucu oluşturma ya da statik üretim kullanılabilir. Angular projelerinde de sunucu taraflı oluşturma uygulanabilir. Ancak özellik etkinleştirildikten sonra bütün rotaların doğru üretildiği ayrıca doğrulanmalıdır.

Her indekslenebilir rota, doğrudan açıldığında 200 durum kodu döndürmelidir. Sunucu bütün bilinmeyen adreslere aynı uygulama kabuğunu ve 200 kodunu gönderirse soft 404 sorunları oluşabilir.

Sayfa başlığı, meta açıklaması ve canonical etiketi rota değişince güncellenmelidir. Yalnız ana sayfanın etiketlerini taşıyan binlerce URL, arama motoruna sayfaların farkını yeterince anlatmaz.

Hydration sırasında sunucu HTML’i ile istemci çıktısı uyuşmalıdır. Uyuşmazlık olduğunda bileşenler yeniden oluşturulabilir veya içerik kaybolabilir. Tarayıcı konsolundaki hydration uyarıları bu nedenle SEO kontrolüne dahildir.

Yapılandırılmış veri de görünür içerikle aynı bilgiyi vermelidir. JavaScript ile eklenebilir, fakat oluşturulan sayfada bulunmalı ve kullanıcıya gösterilmeyen iddialar içermemelidir.

Çok dilli rotalarda dil işaretleri yalnız istemci durumuna bağlanmamalıdır. Her dil sürümü ayrı URL taşımalıdır. Uygulama ayrıntıları için Google SEO’da hreflang nasıl kurulur? rehberindeki karşılıklı etiket ve canonical kontrolleri uygulanabilir.

Framework yükseltmesinden sonra yalnız görsel test yapılmamalıdır. Başlangıç HTML’i, oluşturulan HTML, durum kodları ve dahili bağlantılar eski sürümle karşılaştırılmalıdır.

Uygulama kabuğu kullanmak indekslemeyi neden bozabilir?

Uygulama kabuğu, ana içerik JavaScript sonrasına bırakıldığında indekslemeyi bozabilir. Google ilk yanıtta yalnız menü, yükleniyor göstergesi ve boş içerik alanı görebilir.

Uygulama kabuğu tek başına hatalı değildir. Tekrarlanan üst menü, alt bilgi ve temel düzen kabuk içinde bulunabilir. Risk, sayfayı benzersiz yapan metnin ve bağlantıların yalnız API yanıtına bağlı olmasıdır.

Örneğin 300 hizmet URL’si aynı HTML kabuğunu döndürüyorsa başlangıç yanıtları birbirinden ayrılmaz. API başarısız olduğunda bütün sayfalar aynı boş belgeye dönüşür. Sorun yalnız Googlebot’u değil kullanıcıları da etkiler.

İskelet ekranlar da içerik yerine geçmez. Başlık alanında gri blok bulunması, gerçek <h1> metninin oluşturulduğunu göstermez. URL Denetleme testinde hizmet adı ayrıca aranmalıdır.

İçeriğin yalnız tarayıcı depolamasından alınması başka bir risktir. Googlebot yeni bir ziyaretçi gibi değerlendirilmelidir. localStorage içinde önceden bulunması gereken veriler indeksleme için güvenilir kaynak değildir.

Çerez duvarı veya konum seçimi ana içeriği tamamen kapatmamalıdır. İzmir seçilmeden hiçbir hizmet metni gösterilmiyorsa bölgesel sayfalar boş kalabilir. Varsayılan, taranabilir bir içerik sürümü sunulmalıdır.

Kabuk içindeki metni gereksiz biçimde çoğaltmak da çözüm değildir. Aynı paragrafı yüzlerce rotaya eklemek, her URL’yi benzersiz yapmaz. Google AI aramalarında özgün içerik neden önemli? içeriğinde açıklanan sayfa özgüllüğü burada da geçerlidir.

Anahtar kelimeleri JavaScript ile görünmez alanlara eklemekten kaçınılmalıdır. Kullanıcıya sunulmayan veya sayfayla ilgisiz metinler kalite sorunu doğurabilir. Google AI aramasında içerik spam sayılır mı? rehberindeki tekrar ve otomasyon ölçütleri de dikkate alınmalıdır.

En güvenli yaklaşım, sayfaya özgü ana metni ilk HTML’de sunmaktır. Fiyat hesaplama, filtreleme ve animasyon gibi ikincil işlevler daha sonra etkinleştirilebilir.

Google’ın oluşturduğu JavaScript sayfası nasıl test edilir?

JavaScript indeksleme testi, başlangıç HTML’i ile Google’ın oluşturduğu HTML’i karşılaştırarak yapılır. Yalnız tarayıcıdaki görsel ekran görüntüsüne bakmak eksik sonuç verir.

1. İndekslenebilir URL’yi gizli tarayıcı penceresinde açın. Giriş, çerez veya önceden saklanan veri olmadan ana içeriğin geldiğini doğrulayın.
2. Sayfa kaynağını açın. Başlık, ana metin, canonical ve önemli bağlantıların başlangıç HTML’inde bulunup bulunmadığını kontrol edin.
3. Search Console URL Denetleme aracında canlı URL testi çalıştırın. Test edilen sayfanın HTML çıktısında benzersiz bir cümleyi arayın.
4. İndeksleme durumunda Google tarafından seçilen canonical adresini inceleyin. Seçilen adres, kullanıcı tarafından belirtilen canonical ile farklıysa nedenini araştırın.
5. Tarayıcı geliştirici araçlarında JavaScript hatalarını ve başarısız ağ isteklerini kaydedin. Özellikle 4xx, 5xx ve zaman aşımı alan API çağrılarını ayırın.
6. Mobil görünümde menü, sayfalama ve dahili bağlantıları deneyin. Bağlantıların gerçek href değerleri taşıdığını doğrulayın.

Test için sayfaya özgü bir cümle seçmek sonuçları hızlandırır. Menüde geçen marka adı uygun değildir. Hizmet açıklamasındaki sekiz veya on kelimelik benzersiz bir bölüm daha ayırt edicidir.

Sunucu kayıtları, Googlebot’un HTML ve JavaScript dosyalarına istek gönderip göndermediğini gösterir. Ancak günlük kayıtları oluşturulan DOM’u göstermez. Bu nedenle kayıt analizi, HTML incelemesinin yerine geçmez.

Tek URL’nin başarılı olması bütün şablonun sorunsuz olduğunu kanıtlamaz. Ana sayfa, kategori, ürün, yazı, konum ve 404 şablonlarından en az birer örnek ayrı test edilmelidir.

Dağıtım öncesi ve sonrası karşılaştırma yapılmalıdır. Başlık sayısı, iç bağlantı sayısı, canonical değeri ve metin uzunluğu otomatik testlerle izlenebilir. Kesin eşik yerine önceki çalışan sürüm referans alınmalıdır.

Arama sonucunda görünmeyen yeni bir URL için yalnız manuel indeksleme talebi göndermek yeterli değildir. Kaynak, oluşturma ve canonical hatası düzeltilmeden tekrar talep göndermek temel nedeni ortadan kaldırmaz.

Hangi teknik hatalar JavaScript içeriğinin indekslenmesini engeller?

JavaScript içeriğini en sık robots engelleri, hatalı durum kodları, noindex, canonical uyuşmazlığı ve başarısız API istekleri engeller. Hatalar çoğunlukla birlikte kontrol edilmelidir.

• JavaScript ve CSS dosyaları robots.txt üzerinden engellenmemelidir.
• İndekslenebilir URL, doğrudan açıldığında doğru HTTP durum kodunu vermelidir.
• Başlangıç HTML’inde yanlışlıkla noindex bulunmamalıdır.
• Canonical etiketi erişilebilir ve indekslenebilir hedefe yönelmelidir.
• API çağrıları oturum, çerez veya kullanıcı hareketi gerektirmemelidir.
• Dahili bağlantılar gerçek <a href> öğeleriyle oluşturulmalıdır.
• Lazy loading, yalnız kaydırma veya tıklama olayına bağımlı kalmamalıdır.
• 404 sayfaları 200 yerine uygun hata kodunu döndürmelidir.

Başlangıç HTML’ine noindex koyup JavaScript ile kaldırmak güvenilir değildir. Google noindex işaretini gördüğünde oluşturmayı atlayabilir. İndekslenmesi gereken sayfa ilk yanıtta bu etiketi taşımamalıdır.

Robots.txt içinde paket dizinini engellemek de kritik bir hatadır. Google HTML’i tarasa bile bileşenleri oluşturamaz. Engelin kaldırılması sonrasında önemli URL’ler yeniden test edilmelidir.

Canonical değeri bütün rotalarda ana sayfayı gösteriyorsa Google alt sayfaları yinelenen sürüm sayabilir. Her benzersiz sayfa genellikle kendi tercih edilen URL’sini açıkça belirtmelidir.

İstemci yönlendirmeleri, sunucu yönlendirmelerine göre daha fazla bağımlılık taşır. Kalıcı adres değişikliklerinde uygun sunucu yönlendirmesi kullanmak, JavaScript çalışmasına bağlı kalmaz.

Parçacık işaretli adresler, örneğin /hizmet#seo, ayrı içerik URL’leri için güvenilir değildir. Ayrı indekslenmesi gereken hizmetler, sunucunun yanıtlayabildiği ayrı yollar kullanmalıdır.

Yerel açılış sayfalarında şehir ve semt içeriğinin API sonrasında kaybolması ayrıca kontrol edilmelidir. Bölgesel URL yapısı için İzmir’de yerel SEO nasıl yapılır? rehberindeki sayfa ayrımı uygulanabilir.

JavaScript SEO uygulama planı nasıl hazırlanır?

JavaScript SEO planı, önce kritik URL şablonlarını belirleyip sonra her şablonun HTML çıktısını ölçerek hazırlanır. Framework değişikliği ilk adım değil, test sonucudur.

İlk olarak organik aramada bulunması gereken sayfaları sınıflandırın. Hizmet, kategori, ürün, lokasyon ve içerik sayfalarını ayırın. Giriş gerektiren yönetim ekranlarını bu listenin dışında tutun.

İkinci olarak her şablondan örnek URL seçin. Başlangıç HTML’i, oluşturulan HTML, durum kodu, canonical, başlık ve dahili bağlantıları kaydedin. Böylece sorun tek URL’ye mi, şablona mı ait anlaşılır.

Üçüncü olarak içerik önceliği belirleyin. Ana başlık, açıklama, ürün bilgisi, fiyat koşulları ve temel bağlantılar ilk HTML’e alınmalıdır. Filtre animasyonları ve kişiselleştirme daha sonra çalışabilir.

Dördüncü olarak CSR, SSR, SSG veya hibrit yaklaşımı rota bazında seçin. Sık güncellenen kategori sayfası SSR kullanabilir. Sabit rehber SSG ile üretilebilir. Kullanıcı paneli CSR olarak kalabilir.

Beşinci olarak dağıtım kontrolünü otomatikleştirin. Her sürümde örnek URL’lerin durum kodu, canonical değeri ve benzersiz metni test edilebilir. Önceki sürüme göre kaybolan içerik dağıtımı durdurmalıdır.

Altıncı olarak Search Console verilerini şablon düzeyinde izleyin. Taranan ancak indekslenmeyen URL’leri ortak özelliklerine göre gruplayın. Tek tek indeksleme talebi yerine ortak teknik nedeni düzeltin.

Başarı yalnız indekslenen URL sayısıyla ölçülmemelidir. İndekslenen sayfanın doğru başlığı, doğru canonical adresi ve beklenen içeriği taşıması gerekir. Organik sorgular ile açılış sayfaları da karşılaştırılmalıdır.

• Kritik metin ilk HTML’de bulunuyor.
• Her içerik ekranının ayrı ve kalıcı URL’si var.
• Sunucu doğru 200, 301 veya 404 kodunu veriyor.
• Googlebot gerekli JavaScript ve API kaynaklarına erişebiliyor.
• Canlı testte benzersiz sayfa metni görülebiliyor.
• Canonical, noindex ve hreflang değerleri rota düzeyinde doğrulanıyor.