Modern web uygulamalarının önemli bir bölümü; içerik üretimini, yönlendirmeyi (routing), veri çekmeyi ve etkileşimleri büyük ölçüde JavaScript (JS) ile gerçekleştirir. Bu mimari; kullanıcı arayüzlerinde akıcılık, bileşen tabanlı geliştirme ve hızlı iterasyon gibi avantajlar sunarken, arama motoru görünürlüğü açısından klasik HTML tabanlı sitelere kıyasla daha karmaşık bir problem alanı doğurur. “JavaScript SEO” diye anılan bu alan, yalnızca Googlebot’un JavaScript çalıştırıp çalıştırmamasıyla sınırlı değildir; tarama (crawling), oluşturma (rendering), dizine ekleme (indexing), kanonikleştirme, yapılandırılmış veri çıkarımı, performans bütçesi ve hata dayanıklılığı gibi bir dizi bileşenin birlikte yönetilmesini gerektirir.
JavaScript SEO’nun Temel Problemi: “Görünen” ile “İndekslenen” Arasındaki Fark
Kullanıcı tarayıcısı ile arama motoru botu, aynı sayfayı aynı koşullarda deneyimlemez. Kullanıcı tarafında güçlü cihazlar, hızlı ağlar, önbellek, service worker, kullanıcı etkileşimi ve tarayıcı optimizasyonları devreye girer. Bot tarafında ise tarama bütçesi, kaynak kısıtları, zaman aşımı (timeout), üçüncü taraf istekler, güvenlik politikaları ve botların “her şeyi tıklayıp doldurmayacağı” gerçeği bulunur. Bu nedenle JS tabanlı bir sayfada şu durum sıkça görülür:
Kullanıcı sayfayı açtığında içerik ekranda var
Ancak bot sayfayı taradığında, içerik ilk HTML içinde yok
JS çalıştırma, veri çekme veya kullanıcı etkileşimi gerektiren bir adım yüzünden içerik render edilemiyor
Sonuç: içerik geç indeksleniyor, eksik indeksleniyor veya hiç indekslenmiyor
JavaScript SEO’yu doğru yönetmek, “botun sayfayı nasıl gördüğünü” sürekli doğrulayan ve sayfayı bot için daha deterministik hale getiren bir mühendislik disiplinidir.
Tarama, Oluşturma ve Dizine Ekleme: Google’ın İşleyiş Mantığı
JavaScript SEO’yu anlamanın en doğru yolu, Google Search’ün bir URL ile karşılaştığında genel olarak nasıl davrandığını, yani “işleme hattını” kavramaktır. Bu hat, pratikte üç ana aşamada düşünülür:
Tarama (Crawling)
Googlebot URL’yi ziyaret eder, HTML’i alır, sayfadaki bağlantıları keşfeder ve kaynaklara (CSS/JS/resim) erişim durumunu değerlendirir. Tarama aşamasında temel riskler şunlardır:
robots.txt veya meta robots ile kaynakların engellenmesi
HTTP hata kodları, yönlendirme zincirleri
Aşırı ağır sayfalar nedeniyle tamamlanamayan istekler
Düşük kaliteli iç linkleme nedeniyle önemli URL’lerin keşfedilememesi
Oluşturma / Render (Rendering)
HTML içeriğinin ötesinde, sayfanın JS ile çalıştırılıp tarayıcı benzeri bir ortamda “oluşturulması”dır. Burada Googlebot, modern Chromium tabanlı bir render altyapısı kullanır; ancak bu, her JS sitesinin sorunsuz indeksleneceği anlamına gelmez. Render aşamasında sorun üreten tipik alanlar:
İçeriğin yalnızca kullanıcı etkileşimiyle yüklenmesi
API çağrılarının bot ortamında başarısız olması
Uzun JS görevleri ve performans darboğazları
Hatalı lazy-load kurguları ve sonsuz kaydırma
Dizine Ekleme (Indexing) ve Kanonikleştirme
Google, oluşturduğu içeriği değerlendirir; kanonik URL seçimi yapar; sayfanın metnini, başlıklarını, linklerini, yapılandırılmış verisini, görsellerini ve diğer sinyallerini çıkarır. Bu aşamada sıkça görülen JS SEO problemleri:
Başlık (title), meta description, canonical, hreflang gibi kritik etiketlerin yalnızca JS ile sonradan üretilmesi ve botun bunu tutarlı şekilde alamaması
Aynı içeriğin birden fazla URL altında üretilmesi ve kanonik karmaşası
Parametreli URL’lerde kopya içerik ve index şişmesi
Bu üç aşama, JS SEO stratejisinin nerede kırıldığını teşhis etmek için temel haritadır: Sorun taramada mı, render’da mı, indekslemede mi?
Googlebot “Evergreen” Gerçeği ve Yanlış Güven Hissi
Googlebot’un evergreen Chromium kullanması, modern web özellikleriyle uyumluluğu artırmıştır. Ancak uygulamada üç kritik sınır vardır:
Botun kaynakları sınırsız değildir: render maliyeti, özellikle çok sayıda URL içeren sitelerde önemli bir darboğazdır.
Bot bir kullanıcı değildir: form doldurmaz, butona tıklamaz, sonsuz kaydırmada sayfayı sonuna kadar “mutlaka” indirmez.
Bot ortamı gerçek kullanıcı dağılımını temsil etmez: bazı üçüncü taraf scriptler, anti-bot mekanizmaları veya farklı içerik servisleri, botu farklı bir akışa sokabilir.
Dolayısıyla “Google JS çalıştırıyor, o halde sorun yok” varsayımı çoğu projede gerçeği yansıtmaz. JS SEO, “çalıştırabiliyor” öncülünden değil, “tutarlı ve ölçekli biçimde oluşturabiliyor mu?” sorusundan başlar.
JavaScript SEO Mimari Seçenekleri: CSR, SSR, SSG, ISR ve Hydration
JS SEO kararları, çoğu zaman geliştirmenin temel mimarisine dayanır. Bu nedenle SEO ekibi ile geliştirme ekibi arasında “render stratejisi” ortak dili kurulmalıdır.
Client-Side Rendering (CSR)
Sayfa ilk etapta boş veya minimal HTML ile gelir; içerik tarayıcıda JS ile üretilir.
CSR’ın SEO açısından tipik riskleri:
Bot render aşamasında takılırsa içerik görünmez
İçerik geç oluştuğu için indeksleme gecikebilir
İlk HTML boş kaldığından link keşfi zayıflayabilir
Meta etiketler JS ile geç gelirse sinyal kaybı yaşanabilir
CSR ne zaman makul?
İçerik kritik değilse (ör. kapalı dashboard)
Arama görünürlüğü hedefi sınırlıysa
Yine de temel “shell” içinde anlamlı içerik sunulabiliyorsa
Server-Side Rendering (SSR)
Sunucu, her istekte sayfanın HTML’ini üretir ve istemciye tam içerik gönderir; JS daha sonra etkileşim için devreye girer.
SSR’ın avantajları:
Bot ilk HTML’de içerik görür; indeksleme güvenilirleşir
Link keşfi hızlanır
LCP gibi metriklerde doğru uygulamayla kazanım mümkündür
SSR’ın maliyetleri:
Sunucu yükü artar
Cache stratejisi tasarımı zorlaşır
Uygulama karmaşıklığı ve hata yüzeyi büyür
Static Site Generation (SSG)
Sayfalar build zamanında statik HTML olarak üretilir; CDN üzerinden hızlı servis edilir.
SSG’nin SEO avantajları:
En deterministik indeksleme modeli
Çok güçlü performans profili
Daha düşük operasyonel risk
SSG kısıtları:
Çok sık değişen içerikte build maliyeti artar
Kişiselleştirilmiş sayfalarda sınırlıdır
Incremental Static Regeneration (ISR) / Hibrit Modeller
Bazı sayfalar statik üretilir, belirli aralıklarla veya talep oldukça yeniden üretilir.
SEO açısından hedef:
Statik deterministik içerik + güncellik gereksinimini dengelemek
Üretim maliyetini kontrol ederken bot için stabil HTML sağlamak
Hydration ve Partial Hydration
SSR/SSG ile gelen HTML’nin etkileşim kazanması için JS’nin “hydrate” olması gerekir. Ancak hydration maliyeti yüksekse INP/performans sorunları doğabilir. Bu nedenle “partial hydration”, “islands architecture” gibi yaklaşımlar; sadece gereken bileşenleri hydrate ederek hem UX hem SEO’yu iyileştirebilir.
Mimari seçim özetinde şu prensip pratikte güvenlidir: Arama görünürlüğü kritikse, botun ilk HTML’de anlamlı içerik alması hedeflenmelidir. Bu, çoğu durumda SSR/SSG/ISR’ı doğal aday haline getirir.
Dynamic Rendering Neden Riskli ve Neden “Workaround” Olarak Konumlanıyor?
Geçmişte “dinamik render” yaklaşımı, botlara sunucu tarafı ön-render edilmiş HTML, kullanıcılara CSR sunarak JS sorunlarını aşma yöntemi olarak kullanıldı. Ancak bu yaklaşımın iki temel problemi vardır:
Bot ve kullanıcıya farklı içerik sunma riski (cloaking şüphesi doğurabilecek kontrolsüzlük)
Operasyonel karmaşıklık: user-agent tespiti, render servisleri, cache tutarlılığı, hata ayıklama
Google dokümantasyonu, dinamik render’ı uzun vadeli çözüm olarak önermeyen ve daha çok geçici bir “workaround” olarak tanımlayan bir çizgide konumlandırır. Bu yüzden modern JS SEO uygulamalarında temel yönelim SSR/SSG/hydration tabanlı deterministik çözümlerdir.
JavaScript SEO’da En Sık Görülen Sorun Kümeleri
Aşağıdaki başlıklar, JS SEO projelerinde tekrar eden “yüksek etkili” problem alanlarını kapsar. Her birinde amaç, sorunu bot perspektifinden görünür kılmak ve kök nedene göre kalıcı çözüm üretmektir.
İçeriğin yalnızca kullanıcı etkileşimiyle yüklenmesi
Örnek desenler:
“Daha fazla yükle” butonu ile gelen kritik içerik
Tab’lar içinde saklanan ana metin
Sonsuz kaydırma ile getirilen ürün listesi
SEO açısından risk:
Bot etkileşim yapmadığı için içerik hiç görülmeyebilir
İçeriğin önemli bölümü indeks dışında kalır
Çözüm yaklaşımı:
Kritik içerik “ilk render”da HTML içinde olmalı
Sonsuz kaydırma varsa paginasyon ve erişilebilir URL’ler tasarlanmalı
Tab içeriği yine HTML’de bulunmalı; sadece görsel olarak gizlenmeli (erişilebilirlik ilkeleri korunarak)
API çağrılarının bot ortamında başarısız olması
Sık nedenler:
API’nın yalnızca tarayıcı session’ına veya özel header’a bağlı çalışması
Rate limit ve bot kaynaklı kısıtlar
CORS, auth veya anti-bot duvarları
Çözüm yaklaşımı:
SSR/SSG ile veri sunucuda çekilip HTML’e gömülebilir
Botun render ettiği istemci API çağrılarına bağımlılık azaltılmalı
Kritik içerik için “fail-open” stratejisi (en azından temel metin) uygulanmalı
Render-blocking JS ve ağır bundle’lar
JS ağırlığı; botun render süresini uzatır, zaman aşımı ihtimalini artırır, ayrıca kullanıcı metriklerini (CWV) bozar.
Pratik iyileştirmeler:
Code-splitting, route bazlı chunk’lar
Üçüncü taraf script hijyeni (gerçekten gerekli mi?)
Critical JS’yi minimize edip kalanını geciktirme
Uzun görevleri parçalama, ana thread’i boşaltma
Lazy-loading’in yanlış uygulanması
Lazy-load, performans için değerlidir; fakat kritik içerikte yanlış kullanılırsa indekslenebilirlik bozulur.
Tipik hatalar:
Hero görseli veya ana içerik lazy-load yapılır
İçerik IntersectionObserver ile yüklenir ama bot bunu tetikleyemez
Placeholder ile gerçek içerik yer değiştirdiği için CLS artar
Çözüm:
LCP öğesi asla geç yüklenmemeli
Lazy-load yalnızca “kritik olmayan” alt içeriklerde uygulanmalı
Bot testlerinde “rendered HTML” içinde içerik görüldüğü doğrulanmalı
Router ve URL yönetimi problemleri (SPA’ler)
Single Page Application yapılarında, route değişimi çoğu zaman gerçek bir HTML yanıtı üretmez.
Riskler:
Her route’un indekslenebilir URL olarak tanımlanmaması
Canonical ve meta etiketlerin route bazında güncellenmemesi
Parametre ve filtre URL’lerinin kontrolsüz index şişmesi yaratması
Çözüm:
Her route’un benzersiz, paylaşılabilir, kanonik URL’si olmalı
SSR/SSG ile route bazında HTML üretmek ideal
Filtre/parametre stratejisi (index/noindex, canonical) netleştirilmeli
Meta etiketlerin ve yapılandırılmış verinin JS ile sonradan yazılması
Title, meta description, canonical, robots, hreflang ve schema markup; arama motoru sinyallerinin çekirdeğidir.
Risk:
Bot zamanında alamazsa yanlış sinyalle indeksler
Paylaşım önizlemeleri ve snippet kalitesi bozulur
Canonical hatası kopya içerik üretir
Çözüm:
Bu etiketler mümkünse SSR/SSG ile ilk HTML’de gelmeli
SPA’de route değişiminde head yönetimi doğru yapılmalı
Search Console testleri ile doğrulanmalı
Render Bütçesi ve Crawl Budget: JS Sitelerde Neden Daha Çabuk Tükenir?
Arama motorları, büyük siteleri tararken kaynaklarını optimize eder. JS ile ağır render gereken sayfalar, aynı tarama bütçesi içinde daha az URL’nin işlenmesine yol açabilir. Bu durum özellikle şu senaryolarda görünür hale gelir:
E-ticarette on binlerce ürün + filtre URL’leri
Haber sitelerinde hızla büyüyen arşiv
Programatik sayfalar (lokasyon/sunum varyantları)
Çok sayıda iç link üreten faceted navigation
Önlem seti:
Önemli sayfaların iç linkleme ile öne çıkarılması
Parametreli URL’lerin kontrollü kısıtlanması (noindex/canonical/robots)
SSG/ISR gibi render maliyeti düşük yaklaşımlar
Sunucu performansı ve caching ile TTFB düşürme
Site haritasının (sitemap) temizlik ve öncelik mantığıyla yönetimi
JavaScript SEO İçin Teknik Kontrol Listesi
Aşağıdaki liste, JS tabanlı sitelerde “minimum SEO güvenlik standardı” olarak kullanılabilir. Liste, tamamen maddelerden oluşmayacak şekilde, uygulamada nasıl ele alınacağına dair kısa notlarla verilmiştir.
İçerik erişilebilirliği
Kritik metin ve başlıklar ilk HTML’de mevcut mu?
Ürün adı, fiyat, stok, kategori gibi ana unsurlar bot için görünür mü?
İçerik yalnız etkileşimle mi geliyor? Geliyorsa alternatif URL var mı?
Link keşfi ve navigasyon
İç linkler gerçek
<a href>mi, yoksa JS event handler mı?Önemli sayfalar en fazla 3–4 tık derinlikte mi?
Faceted navigation index şişmesi yaratıyor mu?
Head etiketleri ve sinyaller
Title, meta description, canonical, robots ilk HTML’de mi?
Hreflang varsa tutarlı mı ve render sonrası doğru mu?
Structured data sayfa türüne uygun ve render’da bozulmuyor mu?
Performans ve render dayanıklılığı
JS bundle boyutu ve üçüncü taraf script sayısı kontrol altında mı?
API çağrıları bot ortamında başarısız olduğunda fallback var mı?
Lazy-load stratejisi kritik içerikten ayrılmış mı?
Hata yönetimi
404/soft-404 ayrımı net mi?
Yönlendirme zincirleri ve SPA route hataları var mı?
Sunucu log’larında Googlebot erişimi ve yanıt kodları stabil mi?
Teşhis ve Doğrulama: “Google Ne Görüyor?” Sorusu Nasıl Cevaplanır?
JS SEO’da teşhis, araçlardan çok “metodoloji” meselesidir. Aşağıdaki akış, pratikte hızlı ve güvenilir sonuç verir.
Search Console URL Inspection ile render kontrolü
URL’yi inceleyin, “canlı URL’yi test et” ile Googlebot’un anlık görümünü alın
“Rendered HTML” ve ekran görüntüsünü kontrol edin
Kritik içerik (başlık, ana metin, ürün bilgisi) gerçekten görünür mü?
Canonical seçimi beklediğiniz URL mi?
Bu test, özellikle “kullanıcı görüyor ama bot görmüyor” problemlerini netleştirir.
Page source vs. rendered DOM karşılaştırması
“View Source” ilk HTML’yi gösterir
DevTools Elements paneli render sonrası DOM’u gösterir
Eğer içerik yalnız DOM’da varsa, SSR/SSG’ye ihtiyaç ihtimali yükselir. Ancak yalnızca DOM’da olması tek başına sorun kanıtı değildir; botun render ile bunu alıp almadığı Search Console testleriyle doğrulanmalıdır.
Log analizi ile tarama davranışı
Googlebot hangi URL’lere gidiyor?
Kaç tane 200/301/404 alıyor?
Render gerektiren sayfalarda sık tekrar veya time-out var mı?
Log analizi, crawl budget ve render bütçesinin nerede tıkandığını gerçek veriye dayalı görmenizi sağlar.
Yapılandırılmış veri doğrulama
Rich Results Test ve schema doğrulama araçlarıyla markup’ın render sonrası bozulmadığını kontrol edin
Ürün, makale, breadcrumb gibi şemalarda kritik alanlar eksiksiz mi?
Framework Bazlı Pratikler: Next.js, Nuxt, Angular, React SPA, Vue SPA
JS SEO sorunları çoğu zaman “framework seçimi” değil, framework’ün nasıl yapılandırıldığıyla ilgilidir. Bununla birlikte bazı genel eğilimler vardır:
SSR/SSG destekleyen framework’lerde SEO hedefleri daha deterministik şekilde karşılanır.
Tam CSR SPA’lerde route bazlı HTML üretmek zorlaşır; head yönetimi ve indekslenebilirlik daha kırılgan olur.
Hydration maliyeti yüksek uygulamalarda performans (özellikle INP) hızlı bozulur; SEO ile UX aynı anda zarar görür.
Uygulama düzeyinde en iyi sonuç veren yaklaşım, “SEO kritik sayfaları SSR/SSG ile deterministik kılmak, geri kalan etkileşim katmanını JS’ye bırakmak” şeklindeki hibrit düşüncedir.
JavaScript SEO ile Core Web Vitals İlişkisi: Aynı Problemin İki Yüzü
JS ağırlığı arttıkça:
LCP, render gecikmesi ve ağır görsellerle bozulur
INP, ana thread blokajı ve uzun görevlerle bozulur
CLS, dinamik bileşen yerleşimleriyle bozulur
Bu nedenle JS SEO optimizasyonu ile CWV optimizasyonu çoğu zaman aynı teknik borç havuzuna dokunur: bundle küçültme, kritik kaynakları öne alma, gereksiz üçüncü tarafları temizleme, render-blocking azaltma. SEO ekipleri için önemli çıkarım şudur: JS SEO’yu yalnız “indekslenme” sorunu olarak değil, “kullanıcı deneyimi” ile birlikte ele almak daha sürdürülebilir kazanım üretir.
Operasyonel Yol Haritası: Uygulamada JS SEO Projesi Nasıl Yönetilir?
JavaScript SEO çalışmasını “tek seferlik teknik audit” yerine bir ürün geliştirme programı gibi yönetmek, özellikle orta ve büyük sitelerde fark yaratır.
Envanter çıkarma ve sayfa türü bazında sınıflandırma
Şablonları belirleyin: ana sayfa, kategori, ürün, içerik, arama, filtre, hesap sayfaları
Hangi şablonlar SEO için kritiktir? Hangileri indekslenmemelidir?
Her şablon için render stratejisini (SSR/SSG/CSR) netleştirin
Önceliklendirme
Trafik ve gelir etkisi yüksek şablonlar önce
Search Console’da “Indexed but not content” benzeri belirtiler gösteren URL grupları önce
Yüksek hacimli ama düşük performanslı sayfalar (ör. kategori sayfaları) önce
Uygulama ve doğrulama döngüsü
Her düzeltme sonrası URL Inspection ile canlı test
Sonra saha verisi (Search Console, CrUX/RUM) ile trend doğrulama
Regresyon önleme: release sonrası minimum Lighthouse/SEO smoke test
JavaScript SEO, arama motorlarının “JS çalıştırma kapasitesine” güvenip geri kalanını tesadüfe bırakabileceğiniz bir alan değildir. Başarılı bir JS SEO stratejisi; botun ilk HTML’de anlamlı içerik almasını hedefleyen mimari seçimlerle (SSR/SSG/ISR), deterministik sinyal üretimiyle (head etiketleri, canonical, hreflang, schema), render maliyetini düşüren performans disipliniyle ve düzenli doğrulama süreçleriyle mümkündür. Dinamik içerik; doğru kurgulandığında zengin kullanıcı deneyimi sunarken, yanlış kurgulandığında görünmez içerik, geciken indeksleme, kopya URL patlaması ve ciddi organik kayıplar üretebilir. Bu rehberdeki yaklaşım; “sorun çıktığında düzeltme” değil, “başından itibaren indekslenebilirlik tasarımı”dır. Uzun vadede sürdürülebilir organik performans, JS uygulamalarında bu tasarım disiplinine dayanır.
Bu içerik, Invictus Wiki editoryal ilkelerine uygun olarak hazırlanmış; güvenilir ve doğrulanabilir kaynaklar temel alınarak yayımlanmıştır. Bilgi güncelliği düzenli olarak gözden geçirilir.
İçerik Bilgisi
Invictus Wiki editoryal ekibini temsil eden kolektif bir yazarlık imzasıdır. IW imzasıyla yayımlanan içerikler; çok kaynaklı araştırma, editoryal inceleme ve tarafsızlık ilkeleri doğrultusunda hazırlanır.
