6 Temmuz 2026
JavaScript SEO, sayfanın içerik, bağlantı ve meta verilerinin taranabilir ve doğru işlenebilir olmasını denetler. Bu yüzden framework adına veya sayfanın tarayıcıda sorunsuz çalışmasına değil, Google’ın gördüğü çıktıya bakın. Bu sayfa rendering mimarisi ve denetim akışına odaklanır; eski botlara özel prerender kurulumlarını ise aşağıdaki dynamic rendering bölümünde ele alıyoruz.
Google’ın işlemesini doğru yorumlayın
Google JavaScript sayfalarını tarama, rendering ve indeksleme süreçlerinden geçirir. Google, tarama izni olan ve 200 dönen sayfaları render kuyruğuna alır; kuyruğun ne zaman işleneceği kaynaklara bağlıdır ve sabit gün/hafta takvimi verilmez. noindex yönergesi Google’ın rendering adımını atlamasına yol açabilir. Render edilmiş olmak da indekslenmeyi garanti etmez. Google JavaScript SEO temelleri bu aşamaları ve sınırlamaları açıklar.
İlk HTML, kaynak erişimi ve render sonrası DOM’u karşılaştırın. Dizine eklenmeme raporu yalnız JavaScript hatası kanıtı değildir; erişim, canonical, içerik ve indeksleme politikası da incelenmelidir.
Mimari seçimi: sayfa ihtiyacını esas alın
| Model | İçerik nerede hazırlanır? | İncelenecek risk |
|---|---|---|
| CSR | Tarayıcıda JavaScript ile | Kaynak/veri erişimi, etkileşim bağımlılığı, ilk içerik |
| SSR | İstek sırasında sunucuda | TTFB, önbellek, kişisel veri ve hydration tutarlılığı |
| SSG | Derleme sırasında | Yeniden yayın gereği ve eski içerik |
| Yeniden üretim/hibrit | Platforma göre | Cache invalidation, içerik güncelliği, gerçek adapter desteği |
SEO açısından tek evrensel kazanan yoktur. İlk HTML’de hazır kritik içerik erişim bağımlılığını azaltabilir; bütün metrikleri veya indekslemeyi otomatik iyileştirmez. CSR kullanılabilir; davranış ve kaynak erişimi doğrulanmalıdır. Giriş gerektiren paneli indeksleme hedefiyle karıştırmayın.
SSG’de içerik güncelliğini, SSR’de ilk yanıt süresini ayrıca ölçün. Fiyat/stok değişen ürün, yayımlanmış blog ve kişisel hesap ekranı için aynı cache kuralını uygulamayın. Framework sürümü ve hosting adapter’ına göre destek değişir; örneğin Astro’da istek anında SSR için uyumlu bir server adapter gerekir. Eski Pages Router kodunu App Router örneği olarak vermeyin.
Denetim kayıt tablosu
| Boyut | HTML ve DOM’da karşılaştırılacak bilgi |
|---|---|
| İçerik | Ana başlık, kullanıcı işini çözen metin, ürün bilgisi |
| Keşif | Gerçek a href bağlantıları ve hedef durumları |
| Kimlik | URL, canonical, title, dil alternatifi |
| İndeks politikası | HTTP durum, robots meta/header ve kaynak engeli |
| İstemci geçişi | Doğrudan URL açılışı ile router geçişi aynı içeriği veriyor mu? |
JavaScript’in ürettiği gerçek a href bağlantıları render sonrası keşfedilebilir. Yalnız onclick içeren öğeyi aynı kabul etmeyin. Google bağlantı kuralları açısından sonuç HTML’ini inceleyin; bileşen adı yeterli değildir.
Üç somut test senaryosu
- Bir kategori alt sayfasını yeni sekmede doğrudan açın. Uygulama yalnız ana sayfadan router geçişinde çalışıyorsa sunucu fallback/rota davranışını araştırın. Bulunmayan rota, bütün sitede kullanılan boş uygulama kabuğunu (shell) 200 koduyla döndürmesin.
- Infinite scroll’un ikinci içerik grubuna ayrı URL ve gerçek href üzerinden ulaşın. Yalnız bir “Daha fazla” butonu bulunması, arama motorunun ona tıklayacağı anlamına gelmez; sayfalama hedeflerini HTML’de ve sitemap politikasında değerlendirin.
- Görünür içerikle canonical/robots değerlerini ilk yanıtta ve render sonrasında karşılaştırın. İlk yanıttaki noindex’i JavaScript ile kaldırmayı güvenilir indeksleme stratejisi saymayın.
Google’ın sayfayla etkileşim yapmasını gerektiren içerikleri ayrıca değerlendirin. Lazy loading görsel için uygun olabilir; kritik metni tıklama veya kaydırma (scroll) arkasına koymak erişim bağımlılığı yaratır. Her durumu otomatik görünmez ilan etmeden gerçek çıktı ve Google test kanıtını inceleyin.
SPA’de bulunmayan rota ve soft 404
İstemci tarafı router bilinmeyen bir adres için uygulama kabuğunu 200 ile döndürüp sayfada yalnız “bulunamadı” yazarsa gerçek 404 yerine soft 404 oluşabilir. Tercih edilen çözüm, sunucunun bulunmayan rotaya anlamlı 404 yanıtı vermesidir. CSR mimarisi bunu pratik biçimde üretemiyorsa Google, iki alternatif tarif eder: kullanıcıyı sunucuda 404 dönen bir adrese yönlendirmek veya hata görünümü belirlendiğinde JavaScript ile noindex eklemek. Bunlar mimariye bağlı seçeneklerdir; her SPA’ya körlemesine aynı kuralı uygulamayın.
| Durum | Beklenen kontrol |
|---|---|
| Geçerli ve indekslenmesi amaçlanan rota | Doğru içeriği, kendi URL’sini gösteren canonical’ı ve indeksleme iznini doğrula. İlk HTML’deki noindex değerini JavaScript ile sonradan kaldırmaya güvenme; Google bu yönergeyi görünce rendering’i atlayabilir. |
| Gerçekten bulunmayan rota | Sunucu 404’ünü doğrula. Sunucu bunu üretemiyorsa, uygulanan redirect veya JavaScript noindex seçeneğini ve son DOM’u ayrı kaydet; hata rotasını geçerli sayfa gibi canonical/sitemap’e ekleme. |
| API/geçici veri hatası | Ürünün gerçekten kaldırıldığını varsayma. Kullanıcıya hata/yeniden deneme göster; noindex veya 404 kararını yalnız iş kuralı bu URL’nin artık geçerli olmadığını belirliyorsa ver. |
Kabul testinde hem geçerli bir detay URL’sini hem bulunmayan bir rotayı doğrudan açıp yenileyin. İlk HTTP yanıtı, ilk HTML robots/canonical değerleri ve son DOM’u karşılaştırın. Geçersiz ürün kimliğinde yalnız istemci tarafı görünümü uygulayan örnek, gerçek Seobify davranış testi sayılmaz.
Rota ve hydration kontrolü
SSR çıktısı olsa bile hydration sırasında başlık, ürün verisi veya bağlantılar değişebilir; bu yüzden ilk yanıtı ve son DOM’u aynı URL için kaydedin. Bu karşılaştırma uygulamanın kendi tutarlılığını gösterir; Google’ın seçtiği canonical veya indeks durumunu ayrıca doğrulayın.
| Test | Yapılacak kontrol | Kabul kaydı |
|---|---|---|
| Canonical tutarlılığı | İlk HTML’deki canonical’ı DOM’daki değerlerle karşılaştır. Mevcut canonical’ı JavaScript ile başka bir hedefe değiştirme; JS ile ekleniyorsa tek bir canonical üret. | İlk ve son değerler, etiket sayısı, farkın nedeni |
| Ayrı sayfa rotası | Ayrı içerik için yalnızca /#/urun gibi fragment rotasına dayanma. Gerçek href ve History API ile URL üret; aynı URL’nin doğrudan açılışını ve yenilenmesini de kontrol et. | İlk HTTP durumu, başlık/içerik ve router geçişi sonucu |
| Hydration sonrası içerik | Kritik metin, href, robots ve canonical’ı script çalışmadan önce ve sonra kaydet. | Alan bazında önce/sonra karşılaştırması ve tarayıcı hata kaydı |
| Kaynak erişimi | İçeriği oluşturan JS ve veri isteklerinin başarısını incele; robots engellerini ayrı kaydet. Bir kaynak tarayıcıda açılıyor diye Google tarafından erişilebilir yazma. | Kaynak URL, HTTP sonucu, robots politikası ve Google test sonucu varsa bağlantısı |
Google’ın JavaScript SEO belgesi, canonical tutarlılığı ve ayrı içerik için fragment yerine History API kullanımını açıklar. Bölüm içi normal #başlık bağlantıları ayrı sayfa rotası değildir.
Kısa kontrol listesi:
- Temsilî bir detay sayfası, bir liste sayfası ve var olmayan bir adres seçin.
- Her biri için ilk HTML’i; adresi doğrudan açınca, site içinden tıklayarak gidince ve sayfayı yenileyince görülen sonucu karşılaştırın.
- Beklenen metni, başlığı, canonical ve robots değerlerini kaydedin.
- Var olmayan adreste gerçek 404 mü, 404 dönen bir adrese yönlendirme mi, yoksa JavaScript ile eklenen
noindexmi uygulandığını belirleyin. - Testin ortamını ve zamanını not edin; Search Console erişiminiz yoksa Google’daki dizin durumunu ve seçilen canonical’ı “bilinmiyor” olarak bırakın.
Dynamic rendering: eski kurulumu denetleme ve çıkış planı
Dynamic rendering, bot isteklerine sunucuda render edilmiş HTML, kullanıcılara istemci uygulaması sunan bir geçici çözümdür. Google dynamic rendering belgesi bunu uzun vadeli çözüm olarak önermez; ek karmaşıklık ve kaynak gerektiren bir ara çözüm olarak tanımlar ve yerine SSR, statik rendering veya hydration önerir. Benzer içerik sunan dynamic rendering genellikle cloaking sayılmaz; bu, her bot ayrımının veya her prerender servisinin otomatik onaylandığı anlamına gelmez.
Dynamic rendering, SSR veya edge üzerinde HTML üretimiyle aynı şey değildir. SSR/SSG’de içerik herkese hazır HTML olarak sunulur; edge yalnızca HTML’in üretildiği yerdir. Dynamic rendering’de ise isteği yapanın bot olup olmamasına göre sunum yolu değişir ve iki yolun eşitliği ayrıca doğrulanmalıdır.
Hâlâ botlara özel bir prerender proxy’si çalışıyorsa temsilî URL’lerde şunları kaydedin:
| Kontrol | Kaydedilecek kanıt |
|---|---|
| İçerik eşitliği | Aynı URL’de başlık, ana metin, ürün fiyatı/stok ve bağlantı farkları |
| Meta eşitliği | Canonical, robots, hreflang ve JSON-LD farkları |
| Cache | Bot/kullanıcı varyantları ve kişisel içerik izolasyonu |
| Hata yönetimi | Timeout, origin hatası ve geçersiz URL durumları |
| Güncellik | Yayın sonrası prerender cache yenilemesi |
| Maliyet | Render sayısı, kuyruk, gecikme ve işletim ihtiyacı |
Google, dynamic rendering sırasında oluşan hata sayfalarını cloaking saymaz ve diğer hata sayfaları gibi ele alır. Bu, hatalı yanıtı başarılı sayfa gibi döndürmenin gerekçesi değildir: geçerli bir URL’nin renderer timeout’u yüzünden boş bir 200 sayfaya dönüşmediğini, kaldırılmış bir URL’nin de eski prerender cache’inden içerik sunmadığını doğrulayın.
User-Agent metni kimlik doğrulama değildir; bot string’i eşleşti diye özel içeriğe erişim vermeyin. Prerender servisine cookie, Authorization veya tüm gelen başlıkları otomatik iletmeyin ve oturum gerektiren sayfaları kamuya açık render cache’ine almayın.
Kademeli çıkış planı:
- Kamuya açık şablonların ve gerçek render sorunlarının envanterini çıkarın.
- Bir temsilci URL grubunda herkese tutarlı ilk HTML sunan SSR veya SSG seçeneğini uygulayın.
- Eski ve yeni HTML/DOM, HTTP yanıtı ve temel kullanıcı akışını karşılaştırın.
- Veri güncelliğini ve cache yenilemesini kontrollü bir değişiklikle test edin.
- Botlara özel yolu yalnız kabul edilen grup için kaldırın; geri alma kuralını hazır tutun.
Taşıma sırasında URL’leri gereksiz yere değiştirmeyin. Sorun veri erişimi, taranamayan bağlantılar veya şablon hatasıysa yeni bir prerender servisine geçmeden önce onu çözün.
Seobify kaynak örneği ve sınırı
Bu projede bloglar Astro içerik kaynağından üretiliyor; yayın filtresi gelecekteki tarihleri production çıktısından çıkarıyor. Dolayısıyla astro dev’de görünmesi yayında olduğunun kanıtı değildir. Build çıktısındaki gerçek HTML ve rota kontrol edilir. Yeni bir yayın için yeniden build/deploy gerekir.
Bu mimari gözlem, alan performansı veya Googlebot canlı test sonucu değildir. Astro’da eklenen scriptler ve istemci adaları ayrıca incelenir. Core Web Vitals rehberi performans kabulünü ayrı ele alır.
Sık sorulan sorular
SSR’ye geçmek zorunlu mu?
Hayır. Önce gözlenen sorunu bulun. Kritik içeriği hazır HTML’de sunmak seçeneklerden biridir; taşıma maliyeti ve güncellik ihtiyacı hesaba katılır.
Rich Results Test indekslemeyi kanıtlar mı?
Hayır. Desteklenen yapılandırılmış veri ve render incelemesine yardımcı olabilir; Search Console indekslenmiş URL durumu ve canlı test de ayrı kontrollerdir.
JS yönlendirmesi her zaman yanlış mı?
Sunucu yönlendirmesi mümkünse daha doğrudan sinyaldir. İstemci yönlendirmesinin işlenmesi rendering’e bağlı olabilir; HTTP yöntemi ve kalıcı/geçici kararını ihtiyaca göre seçin.
Taşıma planı gerekiyorsa site taşıma (migration) rehberine, hizmet kapsamı için SEO danışmanlığına geçin.