İstemci Tarafı JavaScript Framework'leri
React, Vue, Angular, Svelte ve SolidJS ortak bir SEO sorununu paylaşır: istemci tarafında oluşturma boş bir kabuk gönderir. Çözüm örüntüsü de ortaktır: head yönetimi ve bir oluşturma stratejisi.
Diller
React, Vue, Angular, Svelte ve SolidJS, varsayılan olarak neredeyse boş bir HTML kabuğu gönderen ve sayfayı tarayıcıda oluşturan (istemci tarafında oluşturma) UI kütüphaneleridir. Bu, JavaScript çalışana kadar tarayıcıların boş bir sayfa aldığı anlamına gelir; Google sayfayı oluşturabilir, ancak bunu gecikmeli bir kuyrukta yapar ve diğer tarayıcılar (Bing, yapay zekâ botları) çok daha az güvenilirdir. Çözüm beşinde de aynıdır: (1) meta etiketlerin her rota için mevcut olmasını sağlayan bir head yönetimi paketi ve (2) önceden oluşturma, SSR veya eşleşen meta-framework'e geçiş gibi bir oluşturma stratejisi. Bu merkez, ortak sorunu ve ortak çözümü açıklar, ardından sizi her framework'e özgü ayrıntılı rehberlere yönlendirir.
TL;DR — React, Vue, Angular, Svelte ve SolidJS, geliştiricilerin etkileşimli siteler oluşturmak için kullandığı araçlardır. Varsayılan olarak tarayıcıya neredeyse boş bir HTML sayfası gönderir, ardından asıl içeriği JavaScript ile oluştururlar. Bu, kullanıcılar için harikadır ancak SEO açısından risklidir; bir arama tarayıcısı boş bir sayfayla karşılaşabilir. Çözüm hepsi için aynıdır:
<title>ve meta etiketlerinizi her sayfa için yönetin ve içeriğinizin JavaScript çalışmadan önce HTML’de bulunduğundan emin olun.
İstemci tarafı framework’ler nedir?
İstemci tarafı framework’ler, ilk HTML yanıtından sonra rota içeriğini tarayıcıda oluşturabilir. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks Google JavaScript’i işleyebilir, ancak kaynakların kullanılabilirliği ve oluşturma süreci, hangi içeriğin işlendiğini yine de etkiler. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
Bir istemci tarafı framework, sayfayı ziyaretçinizin tarayıcısında oluşturan bir JavaScript kütüphanesidir. En sık karşılaşacağınız beş tanesi React, Vue, Angular, Svelte ve SolidJS’dir. Modern web uygulamalarının ve panoların çoğu bunlarla oluşturulur.
Buradaki püf noktası istemci tarafı ifadesidir. Bu framework’ler varsayılan olarak kabaca şöyle görünen küçük bir HTML dosyası gönderir:
<body>
<div id="root"></div>
<script src="/bundle.js"></script>
</body>Bu HTML’de içerik yoktur; yalnızca boş bir kapsayıcı ve bir betik bulunur. Tarayıcı betiği indirip çalıştırır ve başlık, metin, bağlantılar ve diğer her şey ancak ondan sonra görünür. Bu varsayılan davranışa istemci tarafında oluşturma (CSR), bu şekilde oluşturulan bir siteye de çoğunlukla tek sayfalı uygulama (SPA) denir.
Bu neden SEO açısından bir sorundur?
Bir arama tarayıcısı, sayfada tıklayarak dolaşan bir insan değildir. Googlebot veya başka bir tarayıcı sayfanızı getirdiğinde ilk aldığı şey bu boş kabuktur. Tarayıcı JavaScript’inizi çalıştırmazsa boş bir sayfa görür; dizine eklenecek içerik yoktur.
Google JavaScript’i çalıştırabilir, dolayısıyla genellikle içeriğinizi eninde sonunda görür. Ancak:
- Bu işlem gecikmeli gerçekleşir (oluşturma, ayrı ve kuyruğa alınan bir adımdır).
- Bing ve ChatGPT gibi araçları besleyen yapay zekâ tarayıcıları dâhil diğer tarayıcılar, JavaScript çalıştırma konusunda çok daha az güvenilirdir.
Dolayısıyla “tarayıcımda çalışıyor” demek, “arama motorları bunu görebiliyor” demek değildir.
Çözüm beşinin tümü için aynıdır
Hangi framework’ü seçmiş olursanız olun, çözüm iki bölümden oluşur:
- Head bölümünü yönetin. Her sayfanın kendine ait bir
<title>ve meta açıklaması olmalıdır. Sade bir CSR uygulamasında tek bir HTML dosyası bulunduğundan, ek önlem alınmazsa tüm sayfalar aynı başlığı paylaşır. Her framework’ün bunu düzelten küçük bir paketi vardır (ayrıntılar Advanced sekmesinde). - Bir oluşturma stratejisi seçin. İçeriğinizi JavaScript çalışmadan önce HTML’ye yerleştirin: önceden oluşturma (statik HTML’yi önceden derleme), sunucu tarafında oluşturma (SSR) veya framework’ün eşleşen meta-framework’üne geçiş (React için Next.js, Vue için Nuxt vb.).
Her framework’e özgü ayrıntıları; hangi head paketinin, hangi oluşturma seçeneğinin kullanılacağını ve Google’ın bu uygulamaları gerçekte nasıl ele aldığını mı öğrenmek istiyorsunuz? Advanced sekmesine geçin, ardından framework’ünüze özel rehbere gidin.
TL;DR — React, Vue, Angular, Svelte ve SolidJS, varsayılan olarak istemci tarafında oluşturma kullanan UI kütüphaneleridir: neredeyse boş bir HTML kabuğu gönderir ve DOM’u tarayıcıda oluştururlar. SEO sorunu beşinde de aynıdır; tarayıcılar boş bir kabuk alır ve içerik ancak JS çalıştıktan sonra var olur. Google bu uygulamaları işler, ancak bunu gecikmeli ve kuyruğa alınmış biçimde yapar; Bing ve yapay zekâ tarayıcıları çok daha az güvenilirdir. Çözüm de aynıdır: (1) head yönetimi (
<title>/meta için rota başına bir paket) ve (2) bir oluşturma stratejisi (önceden oluşturma, SSR veya eşleşen meta-framework’e geçiş). Framework’ler arasındaki farklar çoğunlukla hangi paketin ve hangi stratejinin kullanılacağıdır; bunlar aşağıdaki ayrıntılı rehberlerde ele alınmaktadır.
Bunlar eksiksiz framework’ler değil, kütüphanelerdir; sorunun kökü de budur
Framework mimarileri farklılık gösterdiğinden, istemci tarafında oluşturma otomatik olarak dizine ekleme başarısızlığı anlamına gelmez. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: MDN: Client-side frameworks Sunucuda oluşturma veya önceden oluşturma, dizine eklenmeyi garanti etmeksizin tarayıcı tarafında JavaScript çalıştırılmasına olan bağımlılığı azaltır. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript SEO basics
React, Vue, Angular, Svelte ve SolidJS öncelikle UI oluşturma kütüphaneleridir. Görevleri, verilerinizi DOM’a dönüştürmek ve durum değiştikçe DOM’u eşzamanlı tutmaktır. Kutudan çıktığı hâliyle bu DOM tarayıcıda oluşturulur; onları hızlı ve uygulama benzeri hissettiren de SEO sorununu yaratan da tam olarak budur.
Varsayılan bir derleme; boş bir bağlama düğümü (<div id="root">, <div id="app">, <app-root>) içeren bir HTML kabuğu ve bir JavaScript paketi gönderir. Arama motorunun önemsediği her şey; başlıklar, gövde metni, dahili bağlantılar ve yapılandırılmış veriler, paket indirilip çalıştırıldıktan sonra eklenir. JS çalışmadan önce orada hiçbir şey yoktur.
Bu, yalın kütüphanelere bir meta-framework veya derleme zamanında önceden oluşturma adımı eklenmeden önce kutudan çıktığı hâliyle görülen istemci tarafında oluşturma davranışıdır. Bu bir hata değildir; başlangıçtaki varsayılan davranıştır. Ancak “varsayılan”, “kalıcı” veya “evrensel” demek değildir: varsayılan davranış sürüme ve kullanılan CLI ya da başlangıç şablonuna göre değişir; aynı uygulamadaki iki rota, oluşturulma biçimlerine bağlı olarak farklı oluşturma modları kullanabilir (önceden oluşturulmuş bir pazarlama sayfası ve saf CSR olarak bırakılmış bir pano gibi). Bir framework’ün davranışını adından çıkarmayın; belirli bir derlemedeki belirli rotanın gerçekte ne gönderdiğini kontrol edin.
Ortak sorun: boş bir kabuk
Google, JS uygulamalarını tarama, oluşturma ve dizine ekleme aşamalarında işlediğini ve “without rendering Google might not see that content.” ifadesiyle oluşturma yapılmadan içeriği göremeyebileceğini açıkça belirtir. Bir CSR uygulamasında içeriğin tamamı bu oluşturma adımının arkasındadır. Bunun üç sonucu vardır:
- Oluşturma gecikir ve bekleme süresi sabit değildir. Oluşturma, taramadan sonra gerçekleşen ayrı ve kuyruğa alınmış bir adımdır. Google tarama, oluşturma ve dizine eklemeyi üç ayrı aşama olarak belgeler ancak her sayfa için geçerli tek bir bekleme süresi taahhüt etmez. Gecikme URL’ye ve Google’ın o andaki kaynaklarına göre değişir; ilgili sayfa için ne kadar sürerse sürsün, oluşturma tamamlanana kadar içeriğiniz dizine eklenmek üzere mevcut değildir.
- Google dışındaki tarayıcıların desteği kesin değildir. Bing JavaScript’i tutarsız biçimde işler; çoğu yapay zekâ tarayıcısı (LLM’ler ve yapay zekâ araması için sayfaları getiren botlar) ise JS’i çok az çalıştırır veya hiç çalıştırmaz. Bunlar ayrı altyapılara sahip ayrı şirketlerdir; bu nedenle Google’ın belgelerinden genelleme yapılamaz. Her sağlayıcının güncel davranışını, Google ile veya geçen yılki bir testle aynı olduğunu varsaymak yerine doğrulayın. Yalnızca CSR kullanan bir site, oluşturma yapmayan tarayıcılar için neredeyse görünmez olma riski taşır ve yapay zekâ tarayıcılarının trafikteki payı giderek artmaktadır.
- Sayfaya özgü metadata eksiktir. Tek bir HTML dosyası, head bölümünü her rota için etkin biçimde yönetmediğiniz sürece tüm rotalarda tek bir
<title>ve tek bir meta açıklaması kullanılması demektir.
Ortak çözüm, 1. bölüm: head yönetimi
Bir SPA tek bir HTML belgesine sahip olduğundan, kullanıcı (ve tarayıcının oluşturucusu) rotalar arasında geçiş yaptıkça belgenin head bölümünü güncelleyen bir koda ihtiyacınız vardır. Her framework bunun için standart bir pakete veya yerleşik API’ye sahiptir:
- React →
react-helmet-async(veya Next.js’e geçtiyseniz framework’ün metadata API’si). - Vue →
@unhead/vue(Nuxt’ın SEO araçlarının arkasındaki altyapı). - Angular →
@angular/platform-browserpaketindeki yerleşikTitleveMetaservisleri; ek bağımlılık gerekmez. - Svelte → yerleşik
<svelte:head>öğesi. - SolidJS →
@solidjs/meta(SSR yolu için de SolidStart).
Head yönetimi doğru ve benzersiz meta etiketleri sağlar, ancak boş kabuk sorununu tek başına çözmez. Etiketler yine yalnızca JS çalıştıktan sonra görünür. Bu nedenle 2. bölüme de ihtiyacınız vardır.
Ortak çözüm, 2. bölüm: oluşturma stratejisi
Gerçek içeriği (ve head etiketlerini) JavaScript çalışmadan önce HTML’ye yerleştirmek için üç yaklaşımdan birini seçersiniz. Kaldırdıkları SEO riski miktarına göre sıralama şöyledir:
- Önceden oluşturma / statik üretim (SSG). Her rota için derleme zamanında statik HTML oluşturun. İstek başına değişmeyen içerik açısından en düşük riskli seçenektir. Her kütüphanenin bir önceden oluşturma yolu vardır (ör. SolidJS’in yerleşik prerender özelliği, Vue prerender eklentileri ve Angular’ın prerendering özelliği).
- Sunucu tarafında oluşturma (SSR). Her istek için HTML’yi sunucuda oluşturun, ardından tarayıcıda hydrate edin. Meta-framework’ler burada devreye girer: Next.js (React), Nuxt (Vue), Angular SSR (eski adıyla Angular Universal), SvelteKit (Svelte) ve SolidStart (SolidJS). Sıralama alması gereken çoğu içerik sitesi için eşleşen meta-framework’ü benimsemek en temiz çözümdür.
- Tam CSR kullanmaya devam edin ancak taranabilir hâle getirin. Sıralama alması gerekmeyen, oturum açma arkasındaki uygulama benzeri yüzeyler için bazen kabul edilebilir; ancak aramada görünmesini istediğiniz herhangi bir şey için kötü bir varsayılandır.
Bu kararı uygulama başına değil, rota başına verin. Aynı kod tabanındaki bir pazarlama sayfası ile oturum açılmış bir pano, makul biçimde bu listenin farklı satırlarında yer alabilir. Her rota için şunları sorun:
- Çıktı — içeriğin ilk yanıtta bulunması gerekiyor mu, yoksa JS çalıştıktan sonra görünmesi yeterli mi?
- Güncellik — bir kez oluşturulabilecek kadar sabit mi (prerender), yoksa her istekte değişiyor mu (SSR)?
- Kişiselleştirme — her ziyaretçi için farklı mı? Önceden oluşturma burada yardımcı olamaz; SSR ile CSR arasında seçim yaparsınız.
- Sunucu maliyeti — SSR her istekte işlem maliyeti ekler; önceden oluşturma ise bu maliyeti derleme zamanına taşır.
- JS bağımlılığı — rotanın yararlılığının ne kadarı istemci JavaScript’inin çalışmasına bağlıdır?
- Hata davranışı — JS başarısız olur veya engellenirse rota kullanılabilir bir şeye mi, yoksa hiçliğe mi dönüşür?
Framework ne olursa olsun karar aynı soruya dayanır: Bu içeriğin sıralama alması veya kaynak gösterilmesi gerekiyor mu? Evetse içeriği sunucuda oluşturulmuş ya da önceden oluşturulmuş HTML’ye yerleştirin. Tamamen etkileşimli bir uygulama arayüzüyse CSR uygundur.
Google bu uygulamaları nasıl ele alır (ve diğerleri neden aynı şeyi yapmaz)?
Google bu framework’lerin her birini işleyebilir; sürekli güncel, headless Chrome çalıştırır ve JS’inizi yürütür. Ancak bunu ertelenmiş bir kuyrukta yapar ve oluşturucu durumsuzdur (kalıcı çerezler/localStorage, service worker’lar veya etkileşim yoktur; kaydırma ya da tıklama yapmaz). Bu nedenle JavaScript SEO merkezindeki aynı JS-SEO kuralları framework seçimine ek olarak geçerlidir: gerçek <a href> bağlantıları, ham ve oluşturulmuş DOM arasında eşdeğerlik, etkileşim arkasına gizlenmemiş içerik ve JS ile eklenmemiş noindex.
Google dışında tablo daha kötüdür. Bing’in JS oluşturma desteği daha düzensizdir ve yapay zekâ tarayıcıları büyük ölçüde hiç oluşturma yapmaz. Bir CSR uygulamasında bu, içeriğinizin Google için (eninde sonunda) mevcut olduğu ancak Bing veya giderek daha fazla kişinin arama yapmak için kullandığı yapay zekâ araçları için mevcut olmadığı anlamına gelebilir. SSR veya önceden oluşturma, bu açığı yalnızca Google için değil herkes için kapatır; yalnızca CSR içeriği göndermemek için en güçlü gerekçe budur.
Beş framework’e genel bakış
| Framework | Varsayılan | Head yönetimi | SSR / meta-framework | SEO notu |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js (Metadata API) | En yaygın CSR öncelikli SPA; Next.js standart SEO çözümüdür |
| Vue | CSR | @unhead/vue | Nuxt (useSeoMeta()) | Nuxt varsayılan olarak SSR kullanır; yalın Vue için prerender veya Nuxt gerekir |
| Angular | CSR (SPA) | yerleşik Title/Meta servisleri | Angular SSR (eski adı Universal) | Büyük SPA’lar; modern Angular, SSR + artımlı hydration ekler |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit (varsayılan SSR) | SvelteKit varsayılan olarak SSR kullanır; ssr:false statik tuzağına dikkat edin |
| SolidJS | CSR | @solidjs/meta | SolidStart | İnce taneli reaktivite; SolidStart, SSR + prerender ekler |
Örüntü tutarlıdır: varsayılan CSR, bir head paketi ve bir oluşturma stratejisi (genellikle eşleşen meta-framework). Değişenler adlar ve birkaç kritik ayrıntıdır.
Sonraki adım: ayrıntılı framework rehberleri
Bu merkez bir yol haritasıdır. Her framework’ün belirli paketleri, yapılandırmaları ve dikkat edilmesi gereken noktaları içeren kendi rehberi vardır:
- React SEO — CSR öncelikli React’in neden dizine ekleme riski yarattığı, React Router ve History API,
react-helmet-asyncve ne zaman Next.js kullanılacağı. - Vue SEO — Vue 3’ün varsayılan CSR davranışı,
createWebHistory(),@unhead/vue, meta-framework olmadan önceden oluşturma ve Nuxt’ın ne zaman doğru seçim olduğu. - Angular SEO — Angular’ın SPA varsayılanları,
@angular/ssr, yerleşikTitleveMetaservisleri, önceden oluşturma ve artımlı hydration. - Svelte SEO — Svelte ile SvelteKit karşılaştırması, SvelteKit’te varsayılan SSR,
<svelte:head>,adapter-static+ssr: falsetuzağı ve yapay zekâ tarayıcılarına etkileri. - SolidJS SEO — SolidJS’in varsayılan CSR davranışı,
@solidjs/meta, SSR ve önceden oluşturma için SolidStart ve ince taneli modelinin oluşturulmuş çıktıyı nasıl etkilediği.
Oluşturma modlarının kendisi (CSR, SSR, SSG, ISR, hydration, dinamik oluşturma) ve daha geniş oluşturma/eşdeğerlik kuralları için üst düzey JavaScript SEO merkezine bakın.
Yapay zekâ özeti
Advanced sürümünün kısa özeti:
- Ortak bir başlangıç noktası. React, Vue, Angular, Svelte ve SolidJS kutudan çıktığı hâliyle varsayılan olarak istemci tarafında oluşturma kullanır: DOM’u tarayıcıda oluşturan, neredeyse boş bir HTML kabuğu (
<div id="root">+ bir paket). Bu varsayılan; sürüme, başlangıç şablonuna ve meta-framework’e göre değişir, hatta aynı uygulamada rotadan rotaya farklılık gösterebilir. Framework’ün adından varsayım yapmak yerine belirli bir rotanın gerçekte ne gönderdiğini kontrol edin. - Google işler ancak bekleme süresi sabit değildir. Oluşturma, taramadan sonra gerçekleşen ayrı ve kuyruğa alınmış bir adımdır; Google her sayfa için tek bir evrensel gecikme taahhüt etmez, süre URL’ye göre değişir. Oluşturucu ayrıca durumsuzdur ve kaydırma/tıklama yapmaz.
- Diğer tarayıcıların desteği kesin değildir. Bing JS’i tutarsız biçimde işler; çoğu yapay zekâ tarayıcısı hiç oluşturma yapmaz. Bunlar ayrı şirketlerdir; dolayısıyla Google’ın belgelerinden genelleme yapılamaz. Her sağlayıcının güncel davranışını doğrulayın.
- İki bölümlü ortak bir çözüm. (1) Head yönetimi —
<title>/meta için rota başına bir paket:react-helmet-async(React),@unhead/vue(Vue), yerleşikTitle/Meta(Angular),<svelte:head>(Svelte),@solidjs/meta(SolidJS). (2) Bir oluşturma stratejisi — prerender/SSG, SSR veya eşleşen meta-framework’e geçiş (Next.js / Nuxt / Angular SSR / SvelteKit / SolidStart). - Head yönetimi tek başına yeterli değildir — etiketler yine yalnızca JS çalıştıktan sonra görünür; kabuğu doldurmak için yine bir oluşturma stratejisi gerekir.
- Kararı rota başına verin; çıktı zamanlamasını, güncelliği, kişiselleştirmeyi, sunucu maliyetini, JS bağımlılığını ve hata davranışını değerlendirin; uygulama başına karar vermeyin. Bir rotanın sıralama alması veya kaynak gösterilmesi gerekiyorsa içeriği sunucuda ya da önceden oluşturulmuş HTML’ye yerleştirin. Oturum açma arkasındaki, yalnızca uygulamaya ait bir arayüzse CSR uygundur.
Resmî belgeler
Arama motorları ve framework’lerden birincil kaynak belgeleri.
- Understand the JavaScript SEO basics — tarama → oluşturma → dizine ekleme aşamaları, taranabilir bağlantılar ve oluşturulmuş HTML’nin test edilmesi.
- Fix Search-related JavaScript problems — istemci tarafı yönlendirmeden sonra soft-404 yönetimi, History API ve oluşturucu kısıtlamaları.
- In-Depth Guide to How Google Search Works — oluşturmanın tarama → dizine ekleme → sunma sürecindeki yeri.
Bing / Microsoft
- bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! — Bing’in JS oluşturma yaklaşımı ve dinamik oluşturmanın neden var olduğu.
Framework’ler (head + oluşturma)
- React docs — CSR öncelikli SPA’yı yaygınlaştıran kütüphane; ayrıca Next.js metadata belgesine bakın.
- Vue.js — Rendering / SSR ve Nuxt SEO utilities.
- Angular — Server-side rendering ve
Title/Metaservisleri. - SvelteKit — Page options (SSR/prerender) ve
<svelte:head>. - SolidStart — SSR & prerendering ve
@solidjs/meta.
Kaynaktan alıntılar
Ortak CSR sorununu ve çözümünü temellendiren, kayda geçmiş açıklamalar. Her arama motoru bağlantısı, doğrudan alıntılanan bölüme gider.
Google — oluşturma ve kabuğun neden önemli olduğu
- “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” Alıntıya git
- “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” Alıntıya git
- “Google can only discover your links if they are <a> HTML elements with an href attribute.” — her framework’ün yönlendiricisi için geçerlidir. Alıntıya git
- “Google Search does not interact with your page.” — oluşturucu, içeriği ortaya çıkarmak için kaydırma veya tıklama yapmaz. Alıntıya git
Patrick Stox (kendi çalışmam — JavaScript SEO: A Definitive Guide)
- “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” — bu merkezdeki her framework için ortak ilke.
- Oluşturucu, ham ve oluşturulmuş HTML’deki robots yönergeleri arasından en kısıtlayıcı olanı uygular; dolayısıyla istemci tarafında
noindexekleyen bir framework, kabukindexdese bile bir sayfayı dizinden çıkarabilir.
İstemci tarafı framework SEO kontrol listesi
React, Vue, Angular, Svelte ve SolidJS’in tümü için geçerlidir:
- Uygulamanızın bugün CSR, SSR veya önceden oluşturulmuş olup olmadığını biliyorsunuz (Kaynağı Görüntüle’yi kontrol edin: içerik ham HTML’de mi, yoksa yalnızca boş bir bağlama düğümü mü var?).
- Sıralama alması veya kaynak gösterilmesi gereken içerik, yalnızca JS çalıştıktan sonra eklenmek yerine sunucuda ya da önceden oluşturulmuş HTML’de bulunuyor.
- Her rota için
<title>ve meta açıklaması yönetiliyor (head paketi veya yerleşik API) ve bunlar oluşturulmuş HTML’de her sayfa için benzersiz. - Yönlendirici bağlantıları gerçek
<a href>bağlantılarıdır (History API yönlendirmesi;#parçası yönlendirmesi veya bir<div>üzerindekionclickdeğil). - JavaScript ve CSS,
robots.txtiçinde engellenmiyor (Google engellenen dosyalardan oluşturma yapamaz). - Hiçbir içerik kaydırma, tıklama veya fareyle üzerine gelme etkileşiminin arkasına gizlenmiyor.
- İstemci tarafındaki “bulunamadı” görünümleri gerçek bir
404döndürüyor veyanoindextaşıyor (soft-404 kabuğu yok). - Hiçbir JS, ham HTML ile çelişen bir
noindexeklemiyor (Google en kısıtlayıcı olanı uygular). - Yalnızca Google’ı değil, Bing ve yapay zekâ tarayıcılarını da dikkate aldınız; onlar için tek güvenilir yanıt SSR/prerender’dır.
- Yalnızca kendi tarayıcınızda değil, URL Denetimi içinde de doğrulama yaptınız (oluşturulmuş HTML + ekran görüntüsü + konsol).
Bu kontroller birkaç farklı çıktıyı tek bir sayfada birleştirir. Her aşamayı ayrı ayrı doğrulayın; bir rota bir aşamayı geçip sonrakinde başarısız olabilir:
| Aşama | Kontrol edilecekler |
|---|---|
| Doğrudan yanıt (JS devre dışı/engelli) | URL’yi JS kapalıyken getirin. Benzersiz başlığınız ve gövde metniniz ham HTML’de mi, yoksa yalnızca bağlama düğümü mü var? |
| Akışla gelen parçalar (akış varsa) | İçerik aşamalı olarak mı geliyor, yoksa yavaş bir parça kendisinden sonraki her şeyi geciktiriyor mu? |
| Oluşturulmuş DOM (JS çalıştırıldı) | Paket çalıştıktan sonra nihai DOM eksiksiz mi; başlıklar, bağlantılar ve yapılandırılmış verilerin tümü mevcut mu? |
| Hydration | İstemci kontrolü sorunsuz biçimde devralıyor mu, yoksa konsol hataları/hydration uyuşmazlıkları mı görülüyor? |
| İstemci navigasyonu | Uygulama içindeki rota değişikliği URL’yi, başlığı ve canonical’ı doğrudan yüklemeyle aynı şekilde güncelliyor mu? |
| Durum kodları | Gerçek bir 404/410/5xx rotası, 200 yanıtındaki istemcide oluşturulmuş bir mesaj yerine doğrudan ilgili durum kodunu döndürüyor mu? |
| Metadata | Oluşturulmuş <title>, açıklama, canonical ve robots yönergesi yalnızca mevcut olmakla kalmayıp her rota için doğru mu? |
Framework’ler → çözümler, genel bakış
| Framework | Varsayılan oluşturma | Head yönetimi | SSR / meta-framework | Prerender yolu |
|---|---|---|---|---|
| React | CSR | react-helmet-async | Next.js | Next.js SSG / react-snap |
| Vue | CSR | @unhead/vue | Nuxt | Nuxt nuxi generate / prerender eklentisi |
| Angular | CSR (SPA) | yerleşik Title / Meta | Angular SSR (eski adı Universal) | ng build prerender |
| Svelte | CSR (Svelte) / SSR (SvelteKit) | <svelte:head> | SvelteKit | adapter-static (ssr:false seçeneğine dikkat edin) |
| SolidJS | CSR | @solidjs/meta | SolidStart | SolidStart prerender |
İki bölümlü çözüm (bunu ezberleyin)
- Head yönetimi → her rota için benzersiz
<title>/ meta. - Oluşturma stratejisi → prerender (SSG) veya SSR veya eşleşen meta-framework. Head yönetimi tek başına boş kabuğu doldurmaz.
Risk basamakları (en düşük → en yüksek SEO riski)
| Yaklaşım | SEO riski | Kullanım durumu |
|---|---|---|
| Prerender / SSG | En düşük | İçerik istekler arasında sabit |
| SSR (meta-framework) | Düşük | Sıralama alması gereken, istek başına değişen / dinamik içerik |
| Hydration (izomorfik) | Düşük | Uygulama + içerik karması |
| Tam CSR | En yüksek | Sıralama alması gerekmeyen, oturum açma arkasındaki uygulama arayüzü |
Tarayıcılar için gerçeklik kontrolü
| Tarayıcı | JS’inizi çalıştırıyor mu? |
|---|---|
| Googlebot | Evet; ancak gecikmeli, kuyrukta ve durumsuz |
| Bingbot | Tutarsız biçimde |
| Yapay zekâ tarayıcıları (LLM / yapay zekâ araması) | Çoğunlukla hayır |
Yalnızca CSR kullanılan içerik, Google dışında her yerde bir kumardır; Google’da bile gecikmeli işlenir. SSR/prerender bu belirsizliği hepsi için ortadan kaldırır.
Yaygın istemci tarafı framework SEO sorunları
Arama araçları boş bir sayfa veya yalnızca uygulama kabuğunu gösteriyor
Belirti: Ham HTML yalnızca #root, #app veya app-root gibi bir bağlama öğesi içerirken görünür sayfada asıl metin bulunur. Olası neden: Rota tamamen istemci tarafında oluşturuluyordur. Çözüm: Sabit rotaları önceden oluşturun veya rotayı framework’ün SSR destekli meta-framework’üne taşıyın. URL’yi JavaScript devre dışıyken getirip yanıtta benzersiz başlığını ve gövde metnini bularak çözümü doğrulayın.
Her rota aynı title veya canonical değerine sahip
Belirti: Birkaç URL farklı görünümler oluşturmasına rağmen aynı title, açıklama veya canonical değerini sunar. Olası neden: Head bölümü ortak HTML kabuğuna aittir ve rota değişiklikleri bu bölümü güncellemez. Çözüm: Framework’e özgü head API’sini kullanın ve metadata’yı rota verilerinden ayarlayın. Her rotanın nihai DOM’unda kendisine referans veren tek bir canonical ve kendine ait bir title bulunduğunu doğrulayın.
Bağlantılar kullanıcılar için çalışıyor ancak tarayıcılar rotaları keşfedemiyor
Belirti: Navigasyon tarayıcıda çalışır ancak bağlantı verilen rotalar keşfedilmez. Olası neden: Düğmelerdeki veya div öğelerindeki tıklama işleyicileri taranabilir bağlantıların yerini almıştır. Çözüm: Gerçek <a href="..."> bağlantıları oluşturun ve yönlendiricinin bunları geliştirmesine izin verin. Tıklama yapmadan, hedefin oluşturulmuş DOM’da bir href olarak göründüğünü doğrulayın.
Konsol hydration hataları veya uyuşmayan içerik gösteriyor
Belirti: Sunucuda ya da önceden oluşturulmuş HTML doğru görünür, ancak tarayıcı konsoluna hydration uyarıları kaydedilir veya içerik yüklemeden hemen sonra kısa süreliğine yanıp değişir. Olası neden: Sunucu çıktısı ile istemcinin ilk oluşturması uyuşmuyordur; bunun nedeni çoğunlukla tarih/yerel ayar biçimlendirmesi, rastgele kimlikler veya ilk oluşturma sırasında çalışan window bağımlı koddur. Çözüm: Sunucu ve istemcinin aynı girdi için deterministik biçimde oluşturma yapmasını sağlayın; yalnızca tarayıcıya özgü mantığı hydration sırasında değil, sonrasında çalışacak şekilde taşıyın. Rotayı JS etkin olarak yükleyip konsolda sıfır hydration hatası bulunduğunu kontrol ederek doğrulayın.
Bir rota tarayıcıda durum değiştiriyor ancak doğrudan URL aynı sonucu vermiyor
Belirti: Uygulamada tıklayarak ilerlemek çalışan bir sayfa üretir, ancak aynı URL’yi doğrudan istemek (veya yenilemek) farklı bir sonuç döndürür: genel bir kabuk, yanlış durum kodu ya da eski metadata. Olası neden: İstemci navigasyonu, eşleşen bir sunucu tarafı rota işleyicisi olmadan tarayıcı içindeki görünümü güncelliyordur; dolayısıyla istemci geçişinden sonra var olan durum hiçbir zaman gerçek ve bağımsız olarak istenebilir bir sayfa olmamıştır. Çözüm: Kullanıcının navigasyonla ulaşabildiği her rotanın doğrudan da istenebildiğinden ve aynı içeriği, durumu ve metadata’yı döndürdüğünden emin olun. URL’yi tıklayarak açmak yerine doğrudan ve önce JS devre dışı, ardından etkin olarak yükleyip doğrulayın.
Kendinizi sınayın: İstemci tarafı framework’ler
React, Vue, Angular, Svelte ve SolidJS’in ortak SEO sorunu ve çözümü hakkında beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.
Zaman ayırmaya değer kaynaklar
İlgili yazılarım
- JavaScript SEO: A Definitive Guide — oluşturma, DOM eşdeğerliği, en kısıtlayıcı yönerge kuralı ve oluşturma düzeni seçimiyle ilgili eksiksiz rehberim. Bu merkezdeki her framework’ün temelini oluşturur.
- The Beginner’s Guide to Technical SEO — istemci tarafında oluşturmanın ve JavaScript SEO’nun büyük resimdeki yeri.
Konuşmalarım
- How Search Works (SlideShare) — tarama, oluşturma, dizine ekleme ve sıralama sürecine ilişkin anlatımım. (Her zamanki sorumluluk reddim geçerlidir: “This is my understanding of systems… not going to be 100% complete or accurate.”)
Sektörden kaynaklar
- web.dev — Rendering on the Web — Chrome ekibinin CSR, SSR, SSG ve hydration karşılaştırmasını açıklayan standart kaynağı; çözümün oluşturma stratejisi bölümüne yönelik, framework’den bağımsız en iyi zihinsel model.
- Google Search Central — JavaScript SEO basics — tarama → oluşturma → dizine ekleme süreci ve taranabilir bağlantılar hakkında resmî birincil kaynak belgeleri.
- Google Search Central — Fix search-related JavaScript problems — her SPA yönlendiricisini ilgilendiren, istemci tarafı yönlendirmeden sonraki yumuşak bulunamadı hataları ve History API.
- Martin Splitt’s JavaScript SEO playlist — Google’ın JS uygulamalarını nasıl ele aldığına dair, framework’den bağımsız resmî video serisi.
- Onely — JavaScript SEO hub — uzman bir ajansın oluşturma ve JS-SEO denetimleri üzerine ayrıntılı teknik yazıları.
Değişiklik günlüğü
9 Ağu 2026 tarihinde güncellendi.
Editoryal özet ve kaydedilen değişiklik ayrıntıları.Değişiklik ayrıntıları
-
Ayrıntılı değişiklik notları şu anda İngilizce olarak mevcut.
Tam karşılaştırma kullanılamıyor — bu sürüm için önceki anlık görüntü arşivlenmemiş.
8 Ağu 2026 tarihinde güncellendi.
Editoryal özet ve kaydedilen değişiklik ayrıntıları.Değişiklik ayrıntıları
-
Ayrıntılı değişiklik notları şu anda İngilizce olarak mevcut.
Tam karşılaştırma kullanılamıyor — bu sürüm için önceki anlık görüntü arşivlenmemiş.
17 Tem 2026 tarihinde güncellendi.
Editoryal özet ve kaydedilen değişiklik ayrıntıları.Değişiklik ayrıntıları
-
Ayrıntılı değişiklik notları şu anda İngilizce olarak mevcut.
-
Ayrıntılı değişiklik notları şu anda İngilizce olarak mevcut.
-
Ayrıntılı değişiklik notları şu anda İngilizce olarak mevcut.
Tam karşılaştırma kullanılamıyor — bu sürüm için önceki anlık görüntü arşivlenmemiş.