React için SEO

TL;DR — React SEO için kötü değildir — ancak çoğu React uygulamasının kurulma şekli kötüdür. Varsayılan olarak React, sayfayı ziyaretçinin tarayıcısında oluşturur; bu nedenle bir arama motoru URL’nizi ilk getirdiğinde neredeyse boş bir sayfa alır. Google, JavaScript’inizi çalıştırarak boşlukları genellikle doldurabilir, ancak bu, bitmiş HTML’i teslim etmekten daha yavaş ve risklidir. Çözüm, sayfalarınızı bir sunucuda veya derleme zamanında oluşturmaktır — genellikle Next.js gibi bir çerçeve ile.

React neden farklıdır

Çoğu web sitesi — örneğin bir WordPress blogu — arama motoruna eksiksiz bir sayfa gönderir: sunucu HTML’i oluşturur ve başlığıyla birlikte gönderir. Standart bir React uygulaması ise tam tersini yapar. Sunucu neredeyse boş bir kabuk (temelde boş bir <div>) gönderir ve ardından JavaScript tarayıcıda çalışarak gerçek sayfayı oluşturur.

Bu, şık, uygulama benzeri deneyimler için harikadır. SEO için bir sorundur, çünkü bir tarayıcının indirdiği ilk şey o boş kabuktur. İçeriğiniz henüz orada değildir — içerik yalnızca JavaScript çalıştıktan sonra görünür.

Google JavaScript’i çalıştıramaz mı?

Evet — Google arka planda gerçek, güncel bir Chrome sürümü çalıştırır ve bitmiş sayfayı görmek için JavaScript’inizi çalıştırabilir. Yani React içeriği dizine eklenebilir. Evidence for this claim Googlebot uses an evergreen Chromium rendering engine and can execute JavaScript. Scope: Google Search; successful execution still depends on accessible resources and application behavior. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Ancak bazı püf noktaları var:

• Gecikmelidir. Google, oluşturmayı daha sonra, sıraya alınmış ayrı bir adımda yapar. Bu nedenle içeriğinizin aramada görünmesi daha uzun sürebilir.
• Başarısız olabilir. Sayfanız içeriğini yüklemekte yavaşsa, Google’ın oluşturucusu içerik görünmeden önce vazgeçebilir — ve boş sayfaya benzer bir sayfayı dizine ekleyebilir.
• Diğer tarayıcılar değişir. Bing, JavaScript’i daha az güvenilir şekilde işler ve yapay zeka sağlayıcıları tek bir paylaşılan oluşturma sözleşmesi yayınlamaz. Yalnızca ilk HTML’i getiren herhangi bir tarayıcı, varsayılan bir React uygulamasını boş olarak görür.

Basit çözüm

İçeriğinizi tarayıcıya ulaşmadan önce HTML’e ekleyin. İki yol:

• Sunucu tarafı oluşturma (SSR) — bir sunucu her istek için tam sayfayı oluşturur.
• Statik site oluşturma (SSG) — sayfalar önceden bitmiş HTML olarak oluşturulur. Evidence for this claim React supports server rendering APIs and can be used by frameworks that generate HTML outside the browser. Scope: React server APIs; build-time generation is a framework/build-system capability rather than a React mode by itself. Confidence: high · Verified: 2026-07-14 React: Server APIs

Her ikisine de en kolay yol Next.js’tir; React üzerine kurulu ve bunu sizin için yapan bir çerçevedir. (Remix de iyi bir seçenektir.) SSR veya SSG ile React siteniz tarayıcılara eksiksiz bir sayfa sunar — ve herhangi bir normal web sitesi kadar arama dostudur.

Doğru yapılması gereken birkaç şey daha

• Normal görünümlü URL’ler kullanın (/products), karma URL’ler değil (/#/products) — Google karma olanları güvenilir şekilde dizine ekleyemez.
• Bağlantılarınızı gerçek bağlantılar yapın (<a href>), tıklanabilir <div>’ler değil.
• Her sayfaya, sayfa değiştiğinde güncellenen kendi başlığını ve açıklamasını verin.

Daha derin sürümü ister misiniz — Google’ın oluşturucusunun gerçekte nasıl çalıştığı, yinelenen sayfalar oluşturan oluşturma zaman aşımı tuzağı, oluşturma stratejisi karşılaştırması ve Google’ın ne gördüğünü nasıl test edeceğiniz? Gelişmiş sekmesine geçin.

TL;DR — React’in SEO sorunu React’in kendisi değil — varsayılan olarak istemci tarafı render’dır. CRA ve Vite + React boş bir kabuk gönderir ve DOM’u tarayıcıda oluşturur, bu yüzden bir tarayıcının getirdiği ham HTML’de içerik yoktur. Google, Web Rendering Service (daima güncel Chromium) aracılığıyla bunu render edebilir, ancak render ayrı bir kuyruğa alınır, gecikebilir ve zaman aşımına uğrayabilir — Gary Illyes, yalnızca şablon içeren ve ardından kopya olarak işaretlenen sayfalarla sonuçlanan render zaman aşımlarını belgelemiştir. Bing, JS’i daha az güvenilir şekilde render eder; AI tarayıcı render’ı sağlayıcıya göre değişir. Çözüm render stratejisidir: SSR veya SSG (en kolayı Next.js veya Remix) içeriği ilk HTML’e koyar — ve sunucu tarafından render edilmiş işaretlemeyi hydrate ediyorsanız, hydrateRoot kullanın (createRoot değil) ve sunucu/istemci uyumsuzluğunu bastırılacak bir uyarı değil, bir hata olarak ele alın. Ardından History API yönlendirmesi (hash URL’ler değil) ve gerçek <a href> bağlantıları kullanın. <head> meta verileri için: React 19 <title>/<meta>/<link> öğelerini yerel olarak yukarı taşır; React 18’de veya gelişmiş ihtiyaçlar için react-helmet-async kullanın (bakımı yapılmayan orijinal react-helmet’i asla kullanmayın). Doğru HTTP durum kodlarını ayarlayın. SSR için sıralama bonusu yoktur — yalnızca içeriğin güvenilir şekilde dizine eklenmesini sağlar. Genel render mekaniği için JavaScript SEO ve headless CMS konularına bakın.

React’i SEO için gerçekten zorlaştıran şey

React, bileşen tabanlı bir JavaScript kütüphanesidir ve kutu dışında — Create React App, Vite + React — istemci tarafında çalışır. Sunucu, neredeyse boş bir belge (ünlü bir şekilde yalnızca bir <div id="root"></div>) artı bir JavaScript paketi döndürür ve tarayıcı, DOM’u oluşturmak için bu JavaScript’i çalıştırır. Bunu, tam HTML’in — içerik, başlıklar, bağlantılar — ilk yanıtta geldiği sunucu tarafından render edilmiş bir sayfayla (WordPress, bir Rails uygulaması) karşılaştırın.

Yani her şeye karar veren soru şudur: herhangi bir JavaScript çalışmadan önce ham HTML’de ne var? Varsayılan bir React uygulaması için cevap “neredeyse hiçbir şey”dir. Bir CRA uygulamasında Sağ Tık → Kaynak Görüntüle’ye tıklayın ve kabuğu görürsünüz, içeriği değil. Bir tarayıcının ilk getirmesinde aldığı tam olarak budur.

Sorumluluğun gerçekte nerede olduğu konusunda kesin olmak gerekirse: React kütüphanesi yalnızca CSR değildir. React DOM, istemci render’ı (createRoot), sunucu render’ı (akış ve statik API’ler) ve hydration API’leri sunar — kütüphane hepsini destekler. Boş kabuk sorunu, varsayılan araç zincirinin (Create React App, sunucusuz Vite + React) bir özelliğidir; bu zincir yalnızca istemci API’lerini bağlar ve sunucuda HTML’e render eden hiçbir şeyi bağlamaz. Araç zincirini değiştirin — Next.js, Remix veya React’in kendi sunucu render API’leri — ve aynı kütüphane ilk yanıtta tam HTML gönderir.

Bu, daha geniş JavaScript SEO sorununun React’e özgü uygulamasıdır — genel hata modları (parite, etkileşim, durum, zamanlama) için oraya gidin. Burada React’e özgü olana ve nasıl düzeltileceğine odaklanacağım.

Google bir React uygulamasını gerçekte nasıl işler

Google, JavaScript’i üç aşamada işler: tarama → render → dizine ekleme. Googlebot URL’yi getirir, render edilmiş DOM daha sonra Web Rendering Service (WRS) tarafından oluşturulur — Chrome ile aynı motor olan, daima güncel bir Chromium sürümü — ve ardından render edilmiş çıktı dizine eklenir ve bağlantıları çıkarılır. Evidence for this claim Google processes JavaScript pages through crawling, rendering, and indexing using its Web Rendering Service. Scope: Google Search rendering behavior. Confidence: high · Verified: 2026-07-14 Google: JavaScript SEO basics

Önemli nüans, render’ın ne zaman gerçekleştiğidir. Render, kaynak yoğun bir işlemdir, bu yüzden ilk taramadan ayrı olarak kuyruğa alınır. Martin Splitt akışı açıkça anlattı: “bir HTTP isteği yaparız ve bir şey geri alırız … biraz çıplak HTML ve tek yaptığı JavaScript’i yüklemek ve JavaScript’i çalıştırmak. Ardından, bu HTML … render’a gider. Render, JavaScript’i çalıştırır — boom!, daha önce orada olmayan bir sürü içerik oluşur.” Bir CSR React sayfası için, “boom” tüm sayfanızdır — hiçbiri bu render adımı çalışana kadar var olmaz.

Taşınmaya değer bir uyarı: eski “iki dalga indeksleme” modeline aşırı odaklanmayın. Splitt’in kendisi bunu geri adım atarak dalgayı “aşırı basitleştirme” olarak nitelendirdi. Pratik çıkarım “tanımlanmış zamanlamalı resmi bir Dalga 2 var” değil — işlemenin ayrı, ertelenebilir, hata yapabilir bir adım olduğu ve CSR’ın içeriğinizin %100’ünü bunun yanlış tarafına koyduğudur.

React uygulamalarını özellikle etkileyen işleyici hakkında iki gerçek daha:

• Durumsuzdur. Googlebot, sayfa yüklemeleri arasında localStorage, sessionStorage veya çerezleri saklamaz. İstemci tarafı durumuna bağlı herhangi bir içerik veya yönlendirme, tarayıcı için görünmezdir.
• Vazgeçebilir. İşleyici bir zaman aşımı uygular. Ana içeriğiniz yavaş yüklenirse — büyük paketler, API çağrılarının şelaleleri — işleme, içeriğiniz gelmeden önce bitebilir ve Google eksik sayfayı dizine ekler.

İşleme zaman aşımı tuzağı (ve neden kopyalar oluşturur)

Bu hata modu nadiren iyi açıklanır ve React uygulamaları için en zarar verici olanıdır. Gary Illyes bunu doğrudan anlattı: “Gelen kutumda, merkez parçanın yüklenmesinin sonsuza kadar sürdüğü ve işlemenin zaman aşımına uğradığı bir sürü e-postam var … ve elimizde yalnızca şablon içeren bir sürü sayfa kaldı. Yalnızca şablonla, bu sayfalar kopyadır.”

Bunun bir CSR React uygulaması için ne anlama geldiğini adım adım inceleyin. Başlığınız, gezinme çubuğunuz ve altbilginiz hızlı yüklenen şablonlardır. Gerçek sayfa içeriğiniz — her URL’yi benzersiz kılan kısım — JavaScript tarafından getirilir ve işlenir ve yavaş yüklenir. İşleme zaman aşımına uğrar. Google, her URL’de başlık + gezinme + altbilgi ile kalır. Artık her sayfa aynı görünür ve Google bunları Search Console’da birbirlerinin kopyaları olarak işaretler.

Illyes’in kendi çözümü uygulanabilir kısımdır: “İçerik (marjinal şablon dahil) önce yüklenecek şekilde js çağrılarını yeniden yapılandırmayı deneyin ve bunun yardımcı olup olmadığına bakın.” Ancak daha kalıcı cevap, ana içeriğiniz için işleme adımına hiç bağımlı olmamaktır — bu da SSR veya SSG anlamına gelir.

React için işleme stratejileri

Bu, en etkili tek karardır. Seçenekler, SEO için kabaca en kötüden en iyiye:

• CSR (varsayılan React). Sunucu kabuğu gönderir; tarayıcı her şeyi oluşturur. İçerik, işleme kuyruğu tarafından geciktirilir ve zaman aşımına maruz kalır. SEO için en kötüsü. Dizine eklenmesini istemediğiniz kimlik doğrulamalı panolar için uygundur. Evidence for this claim Client-only React rendering constructs UI in the browser; server rendering APIs produce HTML before browser hydration. Scope: React rendering mechanics; SEO impact depends on what the initial response contains. Confidence: high · Verified: 2026-07-14 React: hydrateRoot React: Server APIs
• Ön işleme. Tam bir SSR çerçevesi olmadan derleme zamanı işleme — react-snap gibi araçlar veya bir ön işleme hizmeti uygulamanızı tarar ve statik HTML kaydeder. Daha hafiftir; daha basit, çoğunlukla statik siteler için çalışır.
• SSG (Statik Site Oluşturma). HTML dağıtım sırasında bir kez oluşturulur ve statik dosyalar olarak sunulur. En hızlısı, içerik her zaman ham HTML’de bulunur. Son derece dinamik veya kullanıcı başına içerik için sınırlıdır; büyük siteler yavaş derlemeler alır.
• SSR (Sunucu Tarafı İşleme). Sunucu, istek başına React’i çalıştırır ve tam HTML gönderir. İçerik tarayıcılar için hemen kullanılabilir; her zaman günceldir. Bir Node.js sunucusu ve biraz daha yüksek TTFB gerektirir.
• Hibrit / ISR (Artımlı Statik Yeniden Oluşturma). Statik sayfaları arka planda yeniden oluşturan bir Next.js özelliği — statik hız ve periyodik tazelik.

Ve yeni yapılarda atlanacak bir strateji: dinamik oluşturma — tarayıcı kullanıcı aracısını algılayıp kullanıcılara CSR sunarken önceden oluşturulmuş bir sürüm sunmak. Google artık buna “bir geçici çözüm ve uzun vadeli bir çözüm değil” ve “ek karmaşıklıklar ve kaynak gereksinimleri yaratır” diyor ve bunun yerine sunucu tarafı oluşturma, statik oluşturma veya hydration öneriyor. (Bing, 2018’de dinamik oluşturmayı önermişti, ancak bu rehberlik eski — 2019’dan beri Bingbot, Microsoft Edge / Chromium üzerinden oluşturuyor ve SSR/SSG de orada doğru tercih.)

Burada öldürülmeye değer bir efsane var: SSR bir sıralama artışı değildir. John Mueller’ın dediği gibi, “bunu şu ya da bu şekilde uygulamanın SEO sıralama bonusları yoktur” — farklı yöntemler “içeriği dizine eklenebilir yapmanın sadece farklı yollarıdır.” SSR’ın değeri güvenilir dizine eklenebilirliktir (ve genellikle daha hızlı İlk İçerikli Boyama’dan daha iyi Core Web Vitals), sihirli bir sıralama kolu değil.

Hydration tam olarak eşleşmelidir — bu bir hata sınırıdır, bir SEO tekniği değil

SSR ve SSG’nin her ikisi de tarayıcıya içeriğinizi zaten içeren HTML verir. React daha sonra istemcide bu işaretlemeye bağlanmak zorundadır ve bu, düz bir istemci oluşturmadan farklı bir API’dir:

• createRoot React’i sıfırdan bir DOM düğümüne oluşturur — mevcut işaretleme beklenmez. Yalnızca CSR uygulamaları için kullanın.
• hydrateRoot React’i react-dom/server’ın zaten oluşturduğu HTML’e bağlar ve istemcinin ilk oluşturmasının sunucunun gönderdiğiyle aynı çıktıyı üretmesini bekler. SSR/SSG kullanıyorsanız, hydrateRoot değil createRoot istersiniz — sunucu tarafından oluşturulmuş işaretlemede createRoot çağırmak, React’in onu atması ve sıfırdan yeniden oluşturması anlamına gelir, SSR/SSG’yi kurarken elde etmek istediğiniz SEO avantajını çöpe atar.

Sunucu ve istemci çıktıları arasındaki uyumsuzluklar, SEO düzeltmeleri yapan React uygulamalarında gerçek bir risktir — bir başlıkta Date.now(), yerel ayara bağlı bir biçim, bir if (typeof window !== 'undefined') dalı. React’in kendi belgeleri o zaman ne olacağı konusunda açık sözlüdür: geliştirme sırasında uyumsuzluklar hakkında uyarır, ancak “uyumsuzluk durumunda öznitelik farklılıklarının düzeltileceğine dair hiçbir garanti yoktur.” Rehberlik, uyumsuzluklara hata olarak davranmak ve bunları düzeltmektir — uyarıyı bastırmak ve içerik eşitliğini varsaymak değil. SEO için özellikle: sayfa tarayıcıda doğru görünüyor diye oluşturulan içeriğinizin ve meta verilerinizin sunucunun gönderdiğiyle eşleştiğini varsaymayın. Sunucu HTML’ini doğrudan hydration sonrası DOM ile karşılaştırın (aşağıdaki test bölümündeki Kaynağı Görüntüle ile Öğeyi İncele kontrolü bunun hızlı versiyonudur) temiz bir konsola güvenmek yerine.

React Router ve URL yapısı

React Router, tarayıcıda sunucu gidiş-dönüşleri olmadan gezinmeyi yönetir; bu, SEO için doğru yapılandırılırsa sorun değildir:

• History API’yi kullanın, hash yönlendirmeyi değil. BrowserRouter pushState kullanır ve temiz, taranabilir URL’ler üretir (/products). HashRouter /#/products üretir ve Google hash tabanlı URL’leri güvenilir şekilde çözemez — onları çalıştıran eski AJAX tarama düzeni kullanımdan kaldırılmıştır. History API’yi kullanın.
• Sunucu da bu URL’leri işlemelidir. History API yönlendirmesiyle, her “sayfa”nın sunucunun yanıt verebileceği gerçek bir URL’ye ihtiyacı vardır — SSR için kritiktir ve /products üzerinde doğrudan bir isabet veya yenilemenin 404 vermemesi için gereklidir.
• <Link> gerçek bir bağlantı oluşturur. React Router’ın <Link> bileşeni, taranabilir olan bir <a href> çıktısı verir. Bağlantı olmadan onClick işleyicileri üzerine kurulu gezinme taranabilir değildir — Google yalnızca gerçek <a href> bağlantılarını takip eder.

Meta verileri yönetme: react-helmet, react-helmet-async ve React 19’un yerel etiketleri

React 18’e kadar React, rota değişikliklerinde belge <head> öğesini yerel olarak hiç güncellemedi — her rotanın <title>, meta açıklaması, canonical ve Open Graph / Twitter etiketlerinin bir kütüphane tarafından ayarlanması gerekiyordu. React 19 bunu değiştirdi: bileşenler <title>, <meta> ve <link> etiketlerini doğrudan oluşturabilir ve React bunları kendi başına <head> öğesine taşır — istemci tarafı uygulamalar, akışlı SSR ve Sunucu Bileşenleri ile birlikte çalışır. React 19.2, 2026 ortası itibarıyla mevcut kararlı sürümdür, bu nedenle bu artık güncel bir React sürümündeki her uygulama için geçerlidir.

Bu, doğru cevabın React sürümünüze ve gerçekten neye ihtiyacınız olduğuna bağlı olduğu anlamına gelir:

• React 19, bağımsız uygulama, yalnızca temel etiketler. <title>/<meta>/<link> öğelerini doğrudan bileşenlerinizde oluşturun — kütüphaneye gerek yok.
• React 19, ancak htmlAttributes/bodyAttributes, SSR context serileştirmesi, onChangeClientState, prioritizeSeoTags veya titleTemplate gerekiyor. Yerel taşıma bunları kapsamaz — react-helmet-async kullanın. Kendi belgeleri bunu doğrudan belirtir: bu belirli ihtiyaçlar olmadan, React 19’da pakete hiç ihtiyacınız olmayabilir.
• React 18 veya daha eski, bağımsız uygulama. Yerel taşıma henüz mevcut değil — react-helmet-async kullanın. Aktif olarak bakımı yapılıyor (ana sürüm 3 ve React sürümünüzü çalışma zamanında algılar) ve SSR’yi destekler.
• Orijinal react-helmet. Hiçbir React sürümünde kullanmayın. Bakımı yapılmıyor — 2020’den beri sürüm yok — ve React 18’in eşzamanlı oluşturma altında bilinen hataları var.
• Next.js uygulamaları. React sürümünden bağımsız olarak Next’in kendi Metadata API’sini (metadata dışa aktarımı / App Router’da generateMetadata) kullanın — Helmet eklemeyin ve yerel React etiketi taşımasına da güvenmeyin. Çerçeve, bir Next.js uygulamasında belgeyi sahiplenir.

Genel olarak JavaScript SEO’dan devralınan bir güvenilirlik kuralı, yukarıdakilerden hangisini kullanırsanız kullanın geçerlidir: HTML düzeyindeki meta veriler, JS ile enjekte edilen meta verilerden daha iyidir. İstemci tarafı JavaScript ile enjekte edilen bir canonical etiketi, sunucu tarafından oluşturulan HTML’de bulunandan çok daha az güvenilirdir — bu da SSR/SSG için başka bir argümandır.

AI tarayıcıları bunu acil hale getiriyor

2026’daki pürüz: GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot ve diğer aracılar için oluşturma davranışı sağlayıcıya ve sürüme özgüdür. Bir CSR React uygulaması her tarayıcıya ilk Googlebot getirmesinin gördüğü aynı boş kabuğu gönderir ve mevcut sağlayıcı dokümantasyonu, onu dolduracak tek bir paylaşılan oluşturma adımı oluşturmaz. Üretken motorlar daha büyük bir keşif yüzeyi haline geldikçe, SSR/SSG yalnızca Google’a özgü bir endişe olmaktan çıkar: ham HTML, evrensel bir tarayıcı sınırlaması varsaymadan kapsamı en üst düzeye çıkarır. (Headless CMS konusu bu AI tarayıcı gerçeğini daha derinlemesine ele alır.)

Google’ın gerçekte ne gördüğünü test etme

Tarayıcınıza güvenmeyin — DevTools Denetçiniz oluşturulmuş DOM’u (JavaScript sonrası) gösterir, bu da JavaScript olmayan bir tarayıcının görmediği şeydir. Doğru araçları kullanın:

• Kaynağı Görüntüle ile Öğeyi İncele. Kaynağı Görüntüle ham HTML’dir (tarayıcıların JS’den önce aldığı). Öğeyi İncele oluşturulmuş DOM’dur. İçerik İncele’de varsa ancak Kaynağı Görüntüle’de yoksa, JavaScript’e bağımlıdır.
• URL İnceleme Aracı (Search Console) — en yetkili kontrol. Canlı bir test çalıştırın ve oluşturulmuş HTML, ekran görüntüsü ve sayfa kaynakları / konsol mesajlarına bakarak Google’ın gerçekte ne oluşturduğunu ve neyin yüklenemediğini görün.
• Zengin Sonuçlar Testi — siteyi doğrulamadan hızlı bir oluşturulmuş HTML kontrolü.
• DevTools’ta JavaScript’i devre dışı bırakın ve yeniden yükleyin — JS çalıştırmayan bir tarayıcının hızlı bir simülasyonu (ve AI tarayıcılarının gördükleri için iyi bir vekil).
• Search Console Kapsam raporu — “Keşfedildi, şu anda dizine eklenmedi” bir oluşturma kuyruğu birikimini gösterebilir; yinelenen sayfa kümeleri, oluşturma zaman aşımı şablon tuzağını gösterebilir.
• JS oluşturan tarayıcılar — Ahrefs Site Audit ve Screaming Frog (JS oluşturma modu) sayfaları ölçekte oluşturur, böylece tüm sitede ham ve oluşturulmuş arasındaki farkı görebilirsiniz.

Next.js ve Remix (pratik cevap)

SEO önemliyse ve ham CSR React kullanıyorsanız, sunucuda render eden bir framework’e geçmek genellikle doğru hamledir. Next.js bunun için özel olarak tasarlanmıştır — SSR ve SSG kutudan çıkar, ISR, App Router, yerleşik Metadata API, otomatik kod bölme ve görsel optimizasyonu sunar. Remix ise web standartlarına dayalı alternatiftir; fetch/Request/Response üzerine kuruludur, varsayılan olarak SSR kullanır ve güçlü bir aşamalı iyileştirme hikayesine sahiptir. Next.js kendi derinlemesine incelemesini hak ediyor — burada bilerek kısa tutuyorum. React SEO için asıl nokta daha dardır: framework, içeriğinizi yalnızca tarayıcıda çalışan render adımından çıkarıp ilk HTML’e taşımak için vardır.

React, render’ı sonradan akla gelen bir şey değil de mimari bir karar olarak ele aldığınızda SEO için iyidir. Sıralamada yer alması gereken her şey için SSR veya SSG seçin, bağlantılarınızı ve yönlendirmelerinizi dürüst tutun, her rota için meta verileri yönetin ve gerçekte neyin render edildiğini tarayıcınızın değil, Google’ın kendi araçlarının söylemesine izin verin.

AI özeti

Gelişmiş sürümün yoğunlaştırılmış bir değerlendirmesi:

• React SEO için kötü değildir — varsayılan olarak CSR kötüdür. React kütüphanesi istemci, sunucu, statik ve akışkan render’ı destekler; varsayılan CRA/Vite araç zinciri (sunucusuz) boş bir <div id="root"> kabuğu gönderir ve DOM’u tarayıcıda oluşturur, bu nedenle bir tarayıcının getirdiği ham HTML’de içerik yoktur.
• Google, React’i Web Rendering Service (daima yeşil Chromium) aracılığıyla render edebilir, ancak render ayrı olarak kuyruğa alınır, gecikebilir ve durumsuzdur (yüklemeler arasında çerez/localStorage/sessionStorage yoktur).
• Render zaman aşımı tuzağı: ana içerik yavaş yüklenirse, render zaman aşımına uğrar ve Google yalnızca şablon içeren bir sayfayı dizine ekler. Birçok URL’de bunlar aynı görünür ve kopya olarak işaretlenir (Gary Illyes’in belgelenmiş hata modu). Çözüm: önce içeriği yükleyin — veya daha iyisi, render adımına bağımlı olmayın (SSR/SSG).
• SEO için render stratejileri, en iyiden en kötüye: SSG (en düşük risk) ≈ SSR ≈ ön-render > ISR/hibrit > CSR (en yüksek risk). Dinamik render kullanımdan kaldırıldı — Google, SSR, statik render veya hidrasyon önerir.
• SSR için sıralama bonusu yok — Mueller: “no SEO ranking bonuses for implementing it one way or another.” (çeviri) «Bunu şu ya da bu şekilde uygulamanın SEO sıralama bonusu yoktur.» Bu yalnızca içeriğin güvenilir şekilde dizine eklenebilir olmasını sağlar.
• Hidrasyon bir hata sınırıdır, bir teknik değil: SSR/SSG uygulamaları hydrateRoot ( createRoot değil) ile hidrate olur; bu, istemcinin ilk render’ının sunucununkiyle birebir eşleşmesini bekler. React, geliştirme modunda uyumsuzluklarda uyarır ancak bunları düzeltmeyi garanti etmez — uyumsuzlukları hata olarak ele alın ve sunucu ile hidrasyon sonrası DOM’u doğrudan doğrulayın.
• React Router: History API (BrowserRouter) kullanın, hash yönlendirme değil; sunucu bu URL’leri işlemelidir; <Link> taranabilir <a href> oluşturur — yalnızca onClick ile çalışan gezinme oluşturmaz.
• Meta veriler: React 19, yalnızca temel ihtiyaçları karşılayan bağımsız uygulamalar için <title>/<meta>/<link> öğelerini yerel olarak <head> öğesine taşır. React 18’de veya gelişmiş ihtiyaçlar için (SSR bağlamı, titleTemplate) react-helmet-async kullanın — 2020’den beri bakımı yapılmayan orijinal react-helmet asla kullanmayın. Next.js’de React sürümünden bağımsız olarak Metadata API kullanın. HTML düzeyi, JS ile enjekte edilenden daha iyidir.
• AI tarayıcı render’ı sağlayıcıya özeldir — CSR React, her tarayıcının destekleyip desteklemeyebileceği istemci yürütmesine bağlıdır. SSR/SSG içeriği ilk HTML’e koyar ve kapsamı en üst düzeye çıkarır.
• Şunlarla test edin: Kaynağı Görüntüle ile İncele, URL İnceleme (URL Inspection) (render edilmiş HTML + ekran görüntüsü + konsol), Zengin Sonuçlar Testi, JS devre dışı yeniden yükleme ve JS render eden bir tarayıcı.
• Next.js / Remix pratik çözümdür — içeriği ilk HTML’e taşırlar.

Resmi dokümantasyon

Arama motorlarından birincil kaynak dokümantasyonu.

Google

• JavaScript SEO Temellerini Anlayın — tarama → işleme → dizinleme hattı, SPA’lar, History API, JavaScript ile kanonik URL’ler ve anlamlı HTTP durum kodları.
• Aramayla İlgili JavaScript Sorunlarını Düzeltin — SPA’larda yumuşak 404 işleme, durumsuz işleyici (çerezler/localStorage yok) ve URL Inspection ile test etme.
• Dinamik İşleme (kullanımdan kaldırılmış geçici çözüm) — Google’ın bunu neden kullanımdan kaldırdığı ve yerine ne kullanılacağı (SSR, statik işleme, hidrasyon).
• Yeni bir JavaScript SEO video serisi tanıtımı — Martin Splitt’in serisi, özellikle React, Angular ve Vue’yu kapsar.
• Google Arama’nın Nasıl Çalıştığına Dair Kapsamlı Rehber — işlemenin tarama → dizinleme → sunma hattında nerede yer aldığı.

Bing / Microsoft

• Yeni sürekli güncellenen Bingbot (Microsoft Edge) — Bingbot’un JavaScript’i Googlebot ile aynı Chromium platformu üzerinden işlemesi.
• bingbot Serisi: JavaScript, Dinamik İşleme ve Cloaking — Bing’in eski (2018) görüşü; tarihsel dinamik işleme önerisi için faydalı.

Teknik referans

• React v19 (sürüm notları) — bileşenlerde <title>, <meta> ve <link> etiketlerini işlemek için yerel destek, otomatik olarak <head>’e yükseltilir.
• createRoot / hydrateRoot (React belgeleri) — istemci işleme ile hidrasyon API’si arasındaki ayrım ve uyumsuzlukların düzeltileceğinin garanti edilmediği uyarısı.
• react-helmet-async (npm) — bağımsız React uygulamalarında <head> yönetimi için bakımı yapılan çatal, React 18 veya ileri düzey React 19 ihtiyaçları için.

Kaynaktan alıntılar

Google’ın Arama ekibinden kayıtlı açıklamalar. Her arama motoru derin bağlantısı, kaynak sayfadaki alıntılanan pasaja atlar; aşağıdaki personel alıntıları, bunları yayınlayan kapsamaya bağlanmıştır.

Google belgeleri — SPA’lar ve dinamik işleme

• “Single-page applications (SPA) are websites that load an HTML document once and fetch any additional content using JavaScript APIs.” (çeviri) «Tek sayfalık uygulamalar (SPA), bir HTML belgesini bir kez yükleyen ve ek içerikleri JavaScript API’leri kullanarak getiren web siteleridir.» — Google Search Central belgeleri. Alıntıya git
• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (çeviri) «Dinamik işleme, arama motorlarındaki JavaScript ile üretilen içerik sorunları için geçici bir çözümdü ve uzun vadeli bir çözüm değildi.» — Google Search Central belgeleri. Alıntıya git

Martin Splitt, Google — JavaScript sayfalarının nasıl dizinlendiği

• “What we do is we do an HTTP request, and we get something back, right — some HTML, maybe it’s a barebone HTML and all it does is load the JavaScript and run the JavaScript. Then, this HTML that we got from the original HTTP GET request from the crawl, goes into rendering. Rendering runs JavaScript — boom!, a lot of content happens that wasn’t there before.” (çeviri) «Yaptığımız şey bir HTTP isteği göndermek ve karşılığında bir şey almak, değil mi — biraz HTML, belki de sadece JavaScript’i yükleyip çalıştıran çıplak bir HTML. Ardından, taramadan aldığımız orijinal HTTP GET isteğinden gelen bu HTML, işlemeye girer. İşleme JavaScript’i çalıştırır — boom!, daha önce orada olmayan bir sürü içerik ortaya çıkar.” Kapsamı okuyun (Search Engine Journal)
• İki dalga modelinin kesin olmadığına dair: “there’s no such thing as the second wave of crawling-ish. The wave is an oversimplification.” (çeviri) «Tarama benzeri ikinci bir dalga diye bir şey yok. Dalga, aşırı basitleştirmedir.» Kapsamı okuyun (Search Engine Roundtable)

Gary Illyes, Google — işleme zaman aşımına uğramış yinelenen içerik tuzağı

• “I have a bunch of emails in my inbox where the issue is that the centerpiece took forever to load, so rendering timed out (my most likely explanation) and we were left with a bunch of pages that only had the boilerplate. With only the boilerplate, those pages are dups.” (çeviri) «Gelen kutumda, ana içeriğin yüklenmesinin çok uzun sürdüğü ve bu yüzden işlemenin zaman aşımına uğradığı (en olası açıklamam bu) ve elimizde yalnızca şablon metin içeren bir sürü sayfa kaldığı sorununu anlatan bir sürü e-postam var. Yalnızca şablon metinle, bu sayfalar kopyadır.»
• “Do you have a JavaScript-heavy site and you see lots of dups reported in Search Console? Try to restructure the js calls such that the content (including marginal boilerplate) loads first and see if that helps.” (çeviri) «JavaScript ağırlıklı bir siteniz var mı ve Search Console’da çok sayıda kopya bildirildiğini görüyor musunuz? İçerik (marjinal şablon metin dahil) önce yüklenecek şekilde js çağrılarını yeniden yapılandırmayı deneyin ve bunun yardımcı olup olmadığına bakın.» Gönderiyi okuyun (LinkedIn)

John Mueller, Google — işleme yöntemi seçimi için sıralama bonusu yok

• “There are no SEO ranking bonuses for implementing it one way or another.” They’re “just different ways of making the content indexable (as is client side rendering).” (çeviri) «Bunu şu ya da bu şekilde uygulamanın SEO sıralama bonusları yoktur.» Bunlar “içeriği dizine eklenebilir kılmanın (istemci tarafı işleme gibi) yalnızca farklı yollarıdır.” Kapsamı okuyun (Search Engine Roundtable)

React SEO kontrol listesi

Tarayıcıların React uygulamanızı görebildiğini ve dizine ekleyebildiğini doğrulamak için bir geçiş:

• Önemli içerik View Source (ham HTML) içinde görünüyor, yalnızca işlenmiş DOM’da değil — eksikse, CSR’ye bağımlısınız demektir.
• Sıralanması gereken sayfalar SSR veya SSG (Next.js, Remix veya ön işleme adımı) kullanıyor, ham istemci tarafı işleme değil.
• Ana içerik hızlı ve önce yükleniyor — işleme zaman aşımını tetikleyip yalnızca şablon içeren bir sayfaya düşürebilecek yavaş API şelaleleri yok.
• Yönlendirme History API (BrowserRouter) kullanıyor, HashRouter / #/ URL’leri değil.
• Sunucu her istemci tarafı rotaya yanıt verebiliyor (doğrudan erişimde veya yenilemede 404 yok).
• Gezinme gerçek <a href> bağlantıları (React Router <Link>) kullanıyor, yalnızca onClick işleyicileri olan <div>/<button> değil.
• Her rota, gezinme sırasında güncellenen benzersiz bir <title>, meta açıklama, canonical ve OG etiketleri ayarlıyor.
• Meta veriler sürümünüzle eşleşiyor: React 19 yerel <title>/<meta>/<link> etiketleri temel ihtiyaçlar için, react-helmet-async React 18 veya gelişmiş ihtiyaçlar için (kullanımdan kaldırılmış react-helmet asla), veya Next.js kullanıyorsanız Next.js Metadata API.
• Sunucu tarafında işleniyorsa, hydrateRoot ile hidrasyon yapıyorsunuz (createRoot değil), ve geliştirme modundaki herhangi bir hidrasyon uyumsuzluğu uyarısı düzeltilmesi gereken bir hata olarak ele alınıyor.
• İstemci tarafı “bulunamadı” rotaları gerçek bir 404 (veya noindex) döndürüyor, 200 durumuyla yumuşak 404 değil.
• JavaScript ve CSS robots.txt içinde engellenmemiş (Google engellenen dosyalardan işleme yapmaz).
• Kritik içerik çerezler / localStorage / sessionStorage’a bağlı değil (işleyici durumsuz).
• URL Inspection içinde doğrulandı: işlenmiş HTML ve ekran görüntüsü gerçek içeriğinizi gösteriyor.
• Kapsam raporu “Discovered, currently not indexed” (işleme kuyruğu) ve yinelenen kümeler (işleme zaman aşımı tuzağı) için kontrol edildi.

Zihinsel modeller

1. Önemli olan tek soru: ham HTML’de ne var? Herhangi bir JavaScript çalışmadan önce View Source, ilk getirme tarayıcısının — ve çoğu AI tarayıcısının, sonsuza dek — gördüğü şeydir. İçeriğiniz orada değilse, tarayıcınızda sayfa ne kadar iyi görünürse görünsün, bir React SEO sorununuz var demektir.

2. İşleme ayrı, hataya açık bir adımdır. Tarama → işleme → dizinleme. CSR, içeriğinizin %100’ünü işleme adımının ötesine koyar; bu adım kuyruğa alınır, erteleme, durumsuz ve zaman aşımına uğrayabilir. SSR/SSG içeriğinizi bu adımın öncesine taşır. “İki dalga” modeline aşırı güvenmeyin — Splitt bunu aşırı basitleştirme olarak adlandırdı.

3. Şablon-yinelenen başarısızlık modu. Yavaş içerik + işleme zaman aşımı = her URL yalnızca başlık/gezinme/alt bilgi olarak işlenir = Google yinelenenleri görür. Çözüm yapısaldır: önce içeriği yükleyin veya işleme adımına bağımlı olmayı bırakın.

4. İşleme karar ağacı.

• Sıralanması veya AI tarafından alıntılanması gereken herkese açık içerik → SSG (statik) veya SSR (taze).
• Çoğunlukla statik (blog, dokümantasyon, pazarlama) → SSG veya zamanlayıcılı ISR.
• Sık değişen, taze olması gereken → SSR.
• Giriş yapılmış panel, dizinlenmesi amaçlanmayan → CSR uygundur.
• SEO gerektiren yeni derleme → dinamik işleme yerine Next.js / Remix’e ulaşın.

5. Her SEO sinyali için HTML-önce, JS-sonra. İçerik, bağlantılar, canonicals, başlıklar, yapılandırılmış veri — bunları sunucu tarafından işlenmiş HTML’e ekleyin. JS ile enjekte edilen SEO sinyallerini (JS canonical etiketleri ve CSR’de react-helmet dahil) bir plan değil, yedek olarak ele alın: Google bunları geç görür ve AI tarayıcıları hiç görmez.

React SEO — hızlı başvuru

İşleme modlarına bir bakış

Yaygın React SEO hataları → çözümler

Hızlı kurallar

• İşleyici her zaman güncel Chromium’dur, kuyruklu, durumsuz ve zaman aşımına uğrar.
• SSR için sıralama bonusu yok — önemli olan güvenilir dizinlenebilirliktir (Mueller).
• AI tarayıcı işlemesi sağlayıcıya göre değişir → ham HTML en güvenli kapsam tabanıdır.
• Next.js’te Metadata API kullanın — React Helmet değil.
• Bing JS’i (Edge aracılığıyla) işler ancak daha az güvenilir; SSR/SSG orada da güvenli tercihtir.

React çalışmadan önce sunucunun ne gönderdiğini kontrol edin

Temsili dizinlenebilir rotaları urls.txt içine koyun. Bu, ham yanıtta CSR kabuklarını ve eksik sunucu tarafından işlenmiş başlık işaretlemesini bulur:

while IFS= read -r url; do
  html=$(mktemp)
  status=$(curl -sS -o "$html" -w '%{http_code}' "$url")
  bytes=$(wc -c < "$html" | tr -d ' ')
  title_count=$(grep -Eio '<title>[^<]*</title>' "$html" | wc -l | tr -d ' ')
  canonical_count=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$html" | wc -l | tr -d ' ')
  printf '%s\t%s\tbytes=%s\ttitles=%s\tcanonicals=%s\n' "$status" "$url" "$bytes" "$title_count" "$canonical_count"
  rm -f "$html"
done < urls.txt

Küçük bayt boyutu yalnızca bir inceleme sinyalidir, kendi başına bir hata değildir. İşaretlenen ham yanıtları işlenmiş HTML ile karşılaştırın ve birincil metin ile taranabilir bağlantıların mevcut olduğunu doğrulayın.

React SEO denetimi için araçlar

• Kaynağı Görüntüle vs. Öğeyi İncele — en hızlı ilk kontrol. Kaynağı Görüntüle ham HTML’dir (bir tarayıcının JS’den önce aldığı); Öğeyi İncele işlenmiş DOM’dur. Öğeyi İncele’de olup Kaynağı Görüntüle’de olmayan içerik JavaScript’e bağımlıdır.
• URL İnceleme (Google Search Console) — gerçeğin kaynağı. Canlı test çalıştırın, ardından işlenmiş HTML’i, ekran görüntüsünü, sayfa kaynaklarını (yüklenen vs. engellenen) ve konsol mesajlarını görüntüleyerek Google’ın tam olarak ne işlediğini görün.
• Zengin Sonuçlar Testi — siteyi doğrulamadan tek bir URL için hızlı bir işlenmiş HTML ve yapılandırılmış veri kontrolü.
• Chrome DevTools — JavaScript’i devre dışı bırakın (Komut Menüsü → “Disable JavaScript”) ve yalnızca HTML alan bir getiricinin ne aldığını incelemek için yeniden yükleyin. Bu bir kapsam kontrolüdür, adı geçen herhangi bir AI tarayıcısının güncel işleme davranışının kanıtı değildir.
• Search Console Kapsam raporu — “Keşfedildi, şu anda dizinlenmedi” (işleme birikimi) ve yinelenen kümeleri (işleme zaman aşımı şablon tuzağı) izleyin.
• JS işleyen tarayıcılar — Ahrefs Site Audit ve Screaming Frog SEO Spider (JS işleme modu) JavaScript’i çalıştırır, böylece site genelinde ham vs. işlenmiş HTML’i karşılaştırabilirsiniz.

React ekiplerinin gerçekten yaptığı hatalar

CSR React uygulamalarında yayınlanan ve varsayımsal olmayan, sürekli gördüğüm somut kalıplar. Her biri bir önleme hamlesidir — size dizinleme kaybettirmeden önce yakalayın.

Sıralanması gereken sayfalar için ham CRA/Vite CSR göndermek

Ekipler, pazarlama sayfaları, blog yazıları veya ürün sayfaları için Create React App veya Vite + React’i doğrudan üretime gönderiyor — arama sonuçlarında görünmesi gereken tam içerik. Neden yanlış: sunucu neredeyse boş bir <div id="root"> kabuğu gönderir; gerçek içeriğiniz yalnızca JavaScript çalıştıktan sonra var olur, bu nedenle Google’ın işleme kuyruğu tarafından geciktirilir ve istemci yürütmesi olmadan ilk HTML’i getiren herhangi bir AI tarayıcısı için görünmez olabilir. Bunun yerine ne yapmalı: sıralanması veya alıntılanması gereken her şeyi SSR veya SSG’ye taşıyın — Next.js veya Remix en kolay yollardır — ve ham CSR’yi panolar gibi oturum açmış, dizinlenmeyen yüzeyler için ayırın.

Karma URL’lerde yönlendirme (HashRouter)

React Router’ın HashRouter’ına yönelmek, en az dirençli yol olduğu için — sunucu yapılandırması gerekmez, herhangi bir statik hostta çalışır. Neden yanlış: Google, /#/products tarzı URL’leri güvenilir şekilde çözemez; hash parçalarını taranabilir yapan eski AJAX tarama düzeni kullanımdan kaldırılmıştır. Bunun yerine ne yapmalı: BrowserRouter (History API) kullanın ve sunucunun ürettiği her rotaya yanıt verdiğinden emin olun; derin bir bağlantıya doğrudan erişim veya yenileme dahil.

Gezinmeyi gerçek bağlantılar yerine onClick üzerine kurmak

Gezinmeyi bir onClick veya <div> üzerindeki <button> işleyicileriyle bağlamak, genellikle stil vermek veya varsayılan bağlantı davranışından kaçınmak daha kolay olduğu için. Neden yanlış: Google yalnızca gerçek <a href> bağlantılarını takip eder — tıklama işleyicisi olan bir <div>, fare için nasıl davranırsa davransın, tarama için görünmezdir. Bunun yerine ne yapmalı: React Router’ın <Link> bileşenini kullanın; bu, perde arkasında gerçek bir <a href> oluşturur veya harici gezinme için düz bir çapa etiketi kullanın.

Ana içeriği yavaş bir API şelalesinin arkasına yüklemek

Başlığı ve gezinmeyi hızlıca getirip, ardından gerçek sayfa içeriği — her URL’yi benzersiz yapan kısım — görünmeden önce birkaç API çağrısını zincirlemek. Neden yanlış: Google’ın Web Rendering Service’i bir zaman aşımı uygular; ana içeriğiniz yavaş yüklenirse, işleme içerik gelmeden biter ve Google yalnızca şablon sayfalarını dizine ekler; bunlar daha sonra birbirlerinin kopyaları olarak işaretlenir — Gary Illyes’in tam olarak tanımladığı hata modu. Bunun yerine ne yapmalı: Ana içeriğin önce yüklenmesi için istekleri yeniden yapılandırın veya SSR/SSG ile istemci tarafı işlemeye olan bağımlılığı tamamen kaldırın.

Hâlâ orijinal react-helmet kullanmak

Rota başına react-helmet ve meta etiketleri için <title>’e yönelmek çünkü her eski eğitimin önerdiği kütüphane bu. Neden yanlış: orijinal paket bakımsız — 2020’den beri sürüm yok — ve React 18’in eşzamanlı işleme ve SSR’si altında bilinen sorunları var. Bunun yerine ne yapmalı: React 19’da <title>/<meta>/<link> öğelerini doğrudan bileşenlerinizde oluşturun ve React’in bunları yukarı taşımasına izin verin (temel ihtiyaçlar için kütüphaneye gerek yok). React 18’de veya SSR bağlam serileştirme veya titleTemplate gibi gelişmiş ihtiyaçlar için bakımı yapılan çatal olan react-helmet-async kullanın. Next.js’de yerleşik Metadata API’sini kullanın ve üzerine Helmet eklemeyin.

robots.txt içinde JavaScript veya CSS’i engellemek

/static/js/ içinde robots.txt veya bir paketleyicinin varlık klasörünü engellemek, bazen eski bir tarama bütçesi endişesinden veya başka bir sitenin yapılandırmasından kopyalanmış olabilir. Neden yanlış: Google, getirmesine izin verilmeyen şeyi işleyemez — engellenen bir paket, kaynak kodunuz iyi olsa bile Web Rendering Service’in eksik (veya boş) bir DOM oluşturması anlamına gelir. Bunun yerine ne yapmalı: Tarayıcıların JS ve CSS’inizi getirmesine izin verin ve URL Inspection aracının sayfa kaynakları kontrolü ile kritik hiçbir şeyin engellenmediğini doğrulayın.

Kendinizi test edin: React SEO

React uygulamalarını taranabilir ve dizine eklenebilir yapmakla ilgili beş hızlı soru. Her biri için bir cevap seçin, ardından kontrol edin.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• React SEO: SEO Dostu Yapmak İçin En İyi Uygulamalar (Ahrefs) — incelediğim Ahrefs’teki React SEO rehberi; bu makale daha derin, kaynak bağlantılı bir incelemedir.
• JavaScript SEO: Kesin Bir Rehber (Ahrefs) — temel işleme mekaniklerine dair tam rehberim: DOM eşitliği, en kısıtlayıcı yönerge kuralı, canonical ve meta etiket işleme ve işleme seçenekleri. React’e özel düzeltmelerin arkasındaki genel durum için bunu okuyun.
• Teknik SEO’ya Başlangıç Rehberi (Ahrefs) — React/JavaScript SEO’nun büyük resimde nereye oturduğu.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and ranking. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Sektörden

• Understand JavaScript SEO Basics (Google) — SPA’lar, History API ve canonical/status-code işleme hakkında birincil kaynak belgeler.
• Dynamic Rendering (deprecated) (Google) — dinamik oluşturmanın neden uzun vadeli bir çözüm değil de bir geçici çözüm olduğu.
• Martin Splitt Explains How JavaScript Sites Are Indexed (Search Engine Journal) — tarama → oluşturma → dizinleme akışının “barebone HTML … boom” açıklaması.
• Gary Illyes on JS-heavy sites and duplicate content (LinkedIn) — oluşturma zaman aşımından yinelenen içeriğe uzanan hata modu, kendi sözleriyle.
• How to fix technical SEO issues on client-side React apps (Search Engine Land) — bir CSR React uygulamasını denetleme ve düzeltme üzerine gerçek dünya vaka çalışması.
• SSR vs. dynamic rendering — no ranking difference (Search Engine Roundtable) — Mueller’ın “no SEO ranking bonuses” ifadesi.
• react-helmet-async (npm) — bağımsız React için bakımı yapılan head yönetim kütüphanesi.
• The new evergreen Bingbot (Microsoft Edge) (Bing) — Bingbot’un Googlebot gibi Chromium üzerinden JS oluşturması.

Videolar

• Google Search Central — JavaScript SEO series (YouTube) — Martin Splitt’ın resmi video serisi, React, Angular ve Vue için SEO’yu özel olarak ele alır; tarama → oluşturma → dizinleme sürecini ve yaygın düzeltmeleri adım adım anlatır. Seri duyurusu · Kanal

Değişiklik günlüğü