Oluşturma

TL;DR — Oluşturma, bir arama motorunun bitmiş sayfayı oluşturmak ve böylece içeriğinizi ve bağlantılarınızı görebilmek için JavaScript dâhil sayfanızın kodunu bir tarayıcıda çalıştırdığı adımdır. Google bunu Web Rendering Service içinde temelde her sayfa için yapar ve genellikle işe yarar. Sitenizin HTML’yi nasıl ürettiği (sunucuda, tarayıcıda veya derleme zamanında) ne kadar güvende olduğunuzu belirler.

Oluşturma nedir

Bir sayfayı açtığınızda tarayıcınız bir miktar HTML indirir, ardından gördüğünüz sayfayı oluşturmak için CSS ve JavaScript’i çalıştırır. Arama motorları da aynı şeyi yapar. Oluşturma, bir arama motorunun içeriği okuyabilmek ve bağlantıları sizin gibi izleyebilmek için sayfanın son sürümünü oluşturmak üzere sayfanızın kodunu çalıştırdığı adımdır.

Google’ın bir sayfayı ele alışının ortasında yer alır:

1. Tarama — Google URL’nizin ham HTML’sini indirir.
2. Oluşturma — Google bitmiş sayfayı oluşturmak için sayfanın JavaScript’ini tarayıcıda çalıştırır.
3. Dizine ekleme — Google bitmiş sayfayı okur ve kaydeder.

İçeriğiniz yalnızca JavaScript çalıştıktan sonra görünüyorsa Google’ın onu görebilmesi için sayfayı başarıyla oluşturması gerekir. Oluşturma, bir sayfayı getirmek ile onu anlamak arasındaki köprüdür.

Google gerçek (ama alışılmadık) bir tarayıcıda oluşturur

Google’ın oluşturucusuna Web Rendering Service (WRS) denir. Bu, “evergreen” bir headless Chrome’dur; yani güncel Chrome sürümünü takip eder ve modern web özelliklerini destekler. Dolayısıyla eski korku — “Google JavaScript çalıştıramaz” — doğru değildir. Çalıştırabilir. Evidence for this claim Google Search runs JavaScript with an evergreen version of Chromium. Scope: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

Yalnızca alışılmadık bir tarayıcıdır. Kaydırmaz veya tıklamaz, sayfalar arasında her şeyi unutur (oturum açmış kalmaz) ve dosyaları sıkı biçimde önbelleğe alır. Sürprizlerin çoğu bu özelliklerden kaynaklanır; Advanced sekmesi bunları ele alır.

Büyük seçim: HTML’niz nerede oluşturuluyor

SEO için en önemli tek karar, sayfanızın HTML’sinin nerede üretildiğidir:

• Tarayıcıda (istemci tarafı oluşturma) — sunucu neredeyse boş bir sayfa gönderir ve JavaScript her şeyi oluşturur. Arama için en riskli seçenek.
• Sunucuda (sunucu tarafı oluşturma) — sunucu eksiksiz bir sayfa gönderir. Güvenlidir.
• Derleme zamanında (statik / önceden oluşturma) — sayfalar bir kez, önceden oluşturulur. En güvenli ve en hızlı seçenek.

Modern çerçevelerin çoğu bunları birlikte kullanır. Temel kural şudur: önemli içeriğiniz herhangi bir JavaScript çalışmadan önce HTML’deyse (veya neredeyse hemen geliyorsa) iyi durumdasınız.

Daha derin sürüm için — Web Rendering Service’in gerçekte nasıl davrandığı, “iki dalgalı dizine ekleme” fikrinin hâlâ geçerli olup olmadığı ve her oluşturma seçeneğinin tam karşılaştırması — Advanced sekmesine geçin. Pratik JavaScript sorunları ve düzeltmeleri için JavaScript SEO sayfasına bakın.

TL;DR — Google JS’nizi evergreen, headless Chromium olan Web Rendering Service içinde oluşturarak dizine eklediği DOM’u kurar. Bu neredeyse tüm sayfalarda gerçekleşir ve genellikle saniyeler ile dakikalar içinde tamamlanır; bu nedenle “iki dalgalı dizine ekleme” büyük ölçüde eskimiştir ve sayfa başına oluşturma bütçesi yoktur. WRS durum bilgisi tutmaz, izin istemlerini reddeder, sayfayla etkileşime girmez ve agresif biçimde önbelleğe alır. Oluşturma seçeneğiniz SEO riskinizi belirler: SSR / statik / önceden oluşturma / hydration düşük risklidir; tam CSR risklidir; dinamik oluşturma ise Google’ın karşı çıktığı bir geçici çözümdür. Bunun doğurduğu pratik JS sorunları için JavaScript SEO sayfasına bakın.

Oluşturma nerede yer alır

Google, JavaScript uygulamalarının üç aşamadan geçtiğini açıkça söylüyor: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (terjemahan) “Google, JavaScript web uygulamalarını üç ana aşamada işler: 1. Tarama 2. Oluşturma 3. Dizine ekleme.” Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Oluşturma köprüdür. Tarama ham HTML’yi getirir; oluşturma bitmiş DOM’u kurmak için JavaScript’i çalıştırır; dizine ekleme bu oluşturulmuş DOM’u okur ve oluşturucunun bulduğu yeni bağlantılar yeniden taramaya gönderilir. Google’ın sözleriyle: “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (terjemahan) “Tarama sırasında Google sayfayı oluşturur ve bulduğu JavaScript’i, tarayıcınızın ziyaret ettiğiniz sayfaları oluşturmasına benzer şekilde, Chrome’un güncel bir sürümünü kullanarak çalıştırır.”

Web Rendering Service

Google, Web Rendering Service (WRS) içinde oluşturma yapar — evergreen bir headless Chrome: “While Google Search runs JavaScript with an evergreen version of Chromium…” (terjemahan) “Google Arama JavaScript’i evergreen bir Chromium sürümüyle çalıştırırken…” güncel Chrome’u takip eder; bu nedenle modern JavaScript ve CSS özellikleri çalışır.

Ancak WRS tuhaf bir tarayıcıdır ve tuhaflıkları gerçek sorunların çoğuna neden olur:

• Durum bilgisi tutmaz. JavaScript SEO rehberimde söylediğim gibi, “Google loads each page stateless like it’s a fresh load.” (terjemahan) “Google her sayfayı yeni bir yükleme gibi, durum bilgisi olmadan yükler.” Google’ın belgeleri ayrıntıları açıklar: “Local Storage and Session Storage data are cleared across page loads” (terjemahan) “Local Storage ve Session Storage verileri sayfa yüklemeleri arasında temizlenir” ve “HTTP Cookies are cleared across page loads.” (terjemahan) “HTTP çerezleri sayfa yüklemeleri arasında temizlenir.” İçeriğinizi sunmak için istemci tarafında kalıcı olan hiçbir şeye güvenmeyin.
• İzinleri reddeder. “Expect Googlebot to decline user permission requests.” (terjemahan) “Googlebot’un kullanıcı izin isteklerini reddetmesini bekleyin.” Coğrafi konum, bildirim veya kamera isteminin arkasındaki içerik oluşturulmaz.
• Etkileşime girmez. Kaydırma, tıklama veya üzerine gelme yoktur; bu olaylardan yalnızca biriyle yüklenen içerik varsayılan olarak görünmez. (Tembel yükleme ve sonsuz kaydırma hatalarının çoğu bunun kökünden çıkar; düzeltmeler JavaScript SEO sayfasındadır.)
• Agresif biçimde önbelleğe alır. “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (terjemahan) “Googlebot ağ isteklerini ve kaynak kullanımını azaltmak için agresif biçimde önbelleğe alır. WRS önbellek başlıklarını yok sayabilir.” Bu, Google’ın JS veya CSS’nizin güncel olmayan bir sürümünü çalıştırabileceği anlamına gelir. Dosya parmak izi kullanarak düzeltin — dosya adlarını sürümleyin (app.4f2a9c.js); böylece içerik değişikliği yeni bir getirmeyi zorunlu kılar.

2026 deneyi: beş saniye kesin bir yürütme duvarı değildir

Temmuz 2026’da bildirilen üçüncü taraf bir WRS deneyi, beş saniyelik bir zaman aşımı varsaymak yerine gecikmiş JavaScript’i ve ağ etkinliğini test etti. Gözlemlenen oluşturucu sanal bir saat kullandı ve gerçek zamanda yaklaşık 6–12 saniye süren gecikmiş istekleri tamamladı. Kullanışlı sonuç sınırlıdır: tam olarak beş saniye sonra gerçekleşen her şeyin Google için otomatik olarak görünmez olduğu yaygın denetim kuralıyla çelişir. Her gecikmiş bağımlılığın tamamlanacağını, Google’ın süresiz beklediğini veya yavaş istemci tarafı tesliminin güvenli olduğunu kanıtlamaz.

Read the experiment and its methodology as third-party evidence alongside Google’s official statement that render-queue timing has no published fixed delay. In practice, test the final DOM and requested resources. A missing API response, interaction requirement, blocked script, or state dependency remains a real rendering failure even when a stopwatch-based “five-second rule” is not.

“İki dalgalı dizine ekleme” hâlâ geçerli mi?

Yıllarca zihinsel model “iki dalgalı dizine ekleme” idi: Google önce ham HTML’yi dizine ekler, sonra günler veya haftalar sonra JavaScript içeriğini oluşturup dizine eklemek için geri dönerdi. Bu model artık büyük ölçüde eskimiştir. Martin Splitt, iki dalga fikrinin giderek daha az rol oynadığını, birçok sayfanın JavaScript’e bağlı olmasa bile oluşturma aşamasından geçtiğini ve tarama, oluşturma ile dizine eklemenin zaman içinde yakınsadığını söyledi.

Uygulamada oluşturma neredeyse her sayfa için gerçekleşir ve genellikle hızlıdır. Google’ın güncel belgeleri, taranmış bir sayfanın “may stay on this queue for a few seconds, but it can take longer than that” (terjemahan) “bu kuyrukta birkaç saniye kalabilir, ancak daha uzun sürebilir” olduğunu söyler — yayımlanmış sabit bir gecikme veya zaman aşımı yoktur. Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: 2026-07-25 Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. Tarihsel bir veri noktası olarak Google çalışanları (Martin Splitt ve Tom Greenaway) bir zamanlar bu değeri yaklaşık beş saniyelik medyan, 90. yüzdelik dilimi ise dakikalar olarak ifade etti — eski korkunun ima ettiği “haftalar” değil. Bu değere JavaScript SEO rehberimde yer veriyorum; ancak onu güncel yayımlanmış bir ölçüm değil, tarihli bir konferans veri noktası olarak ele alın — Google bunu devam eden bir sayı olarak yeniden yayımlamadı ve yukarıdaki kuyruk zamanlaması alıntısı güncel resmî çerçevedir.

Ayrıca insanların hayal ettiği anlamda oluşturma bütçesi yoktur. Google, korumanız gereken sayfa başına “oluşturulması ne kadar pahalıydı” puanını izlemez. Oluşturma Google ölçeğinde ucuzdur — hayalî bir oluşturma bütçesini değil, kullanıcılarınızı ve performansı optimize edin.

Oluşturma seçenekleri

“HTML nerede oluşturuluyor?” SEO riskinizi belirleyen sorudur. Tüm seçenekler şunlardır:

• İstemci tarafı oluşturma (CSR). Sunucu neredeyse boş bir kabuk gönderir; tarayıcı (veya WRS) her şeyi oluşturmak için JavaScript’i çalıştırır. Bu, “the most problematic one … full client-side rendering where all of the rendering happens in the browser.” (terjemahan) “en sorunlu olan … oluşturmanın tamamının tarayıcıda gerçekleştiği tam istemci tarafı oluşturma”dır. Çalışabilir, ancak her şeyi oluşturmanın başarılı olmasına bağlarsınız ve dizine eklenmesi en uzun seçenektir.
• Sunucu tarafı oluşturma (SSR). Sunucu her istek için tam HTML’yi oluşturur. İçerik ham HTML’dedir, bu nedenle arama için düşük risklidir.
• Statik site oluşturma (SSG) / önceden oluşturma. HTML dağıtım zamanında bir kez oluşturulur. En düşük risk — içerik ham HTML’dedir ve hızlıdır.
• Hydration (izomorfik / evrensel). İlk boyamayı SSR veya SSG ile yapar, ardından etkileşim eklemek için tarayıcıda JavaScript ile “hydrate” edersiniz. Modern çerçevelerin çoğu bunu yapar ve içerik için düşük risklidir — yalnızca içeriği boşaltan veya değiştiren hydration uyuşmazlıklarına dikkat edin.
• Artımlı statik yeniden oluşturma (ISR). Statik sayfalar bir programa göre veya isteğe bağlı olarak yeniden oluşturulur. SSG gibidir ama içerik daha günceldir — büyük kataloglar için iyidir.
• Edge oluşturma. CDN uç düğümlerinde çalışan SSR — SSR kadar düşük risklidir ve küresel kitle için ilk bayta daha hızlı süre sağlar.
• Streaming SSR. HTML hazır oldukça parçalara bölünerek tarayıcıya aktarılır. Düşük risklidir, ancak dizine eklenebilir içeriğin yalnızca geç veya ertelenmiş bir parçada mahsur kalmadığından emin olun.

JavaScript SEO rehberimden çıkaracağım sonuç şudur: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (terjemahan) “Her tür SSR, statik oluşturma ve önceden oluşturma kurulumu arama motorları için uygun olacaktır. Gatsby, Next, Nuxt vb. hepsi harikadır.” Gönderdiğiniz oluşturma modu, kullandığınız çerçeveden daha önemlidir — aynı Next.js uygulaması SSR/SSG veya tam CSR sunmanıza bağlı olarak güvenli ya da riskli olabilir.

Dinamik oluşturma — strateji değil, geçici çözüm

Dinamik oluşturma, botları algılayıp onlara önceden oluşturulmuş, JavaScript içermeyen bir sürüm sunarken kullanıcılara istemci tarafı sürümü sunmak demektir. Google artık açık konuşuyor: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” (terjemahan) “Dinamik oluşturma, arama motorlarındaki JavaScript ile oluşturulan içerik sorunları için bir geçici çözümdü ve uzun vadeli bir çözüm değildi” ve “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (terjemahan) “Dinamik oluşturma bir geçici çözümdür ve ek karmaşıklıklar ile kaynak gereksinimleri yarattığı için önerilen bir çözüm değildir.” Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: 2026-07-14 Google Search Central: Dynamic rendering as a workaround Katılıyorum ve her zaman katıldım — açıkçası bunu hiç önermedim; Google’ın artık buna karşı çıkmasına da sevindim. Botlara ve kullanıcılara farklı içerik sunmak gizlemeye tehlikeli biçimde yakındır. Bunun yerine SSR, statik oluşturma veya hydration’a başvurun.

Bir ayrıntı var: Bing hâlâ dinamik oluşturmayı öneriyor. Microsoft, “bingbot is generally able to render JavaScript” (terjemahan) “bingbot genel olarak JavaScript oluşturabilir” diyor, ancak bunu ölçekte yapmanın zor olduğunu belirterek “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (terjemahan) “JavaScript’e ağır biçimde dayanan web siteleri için dinamik oluşturmayı harika bir alternatif olarak öneriyoruz.” Pratik sonuç: SSR/SSG her iki motoru da memnun eder ve tartışmanın tamamını atlatır.

Bunun içeriğiniz için anlamı

Rendering decides whether Google ever sees your JavaScript content — but seeing it is only half the job. Once the page is rendered, the practical concerns are real <a href> links, field-specific parity between raw and rendered HTML, robots-directive stage order, lazy content, infinite scroll, and soft-404s. Those all live on the JavaScript SEO page, with the testing workflow (URL Inspection’s rendered HTML, screenshot, and console).

Bu, arama akışının oluşturma aşamasıdır. Etrafındaki aşamalar için sayfaların nasıl getirildiğini anlatan tarama ve oluşturulmuş sayfaya sonra ne olduğunu anlatan dizine ekleme sayfalarına veya tüm yolculuk için How Search Works hub’ına bakın.

One audit rule is worth keeping here: rendered is a state, not a universal winner. For body content and crawlable links, the rendered DOM shows what successful JavaScript added or removed. For titles and descriptions, it shows additional inputs, while Google may still generate a title link or snippet from other sources. For robots directives, a raw noindex may prevent rendering, so JavaScript removal is asymmetric. For canonical, Google advises using one source or one JavaScript-set value rather than changing an existing value. And JavaScript cannot change the HTTP response status already received. Keep those columns separate in evidence and use Google’s current JavaScript SEO guidance for the field-specific behavior.

AI özeti

Advanced sürümün kısaltılmış özeti:

• Rendering = the bridge from crawling to indexing. Google runs your JS in an evergreen, headless Chromium — the Web Rendering Service — to build the DOM it indexes. Three phases: crawl → render → index.
• “Two waves of indexing” is largely outdated (Splitt). Rendering happens for essentially all pages, usually fast. Google’s current docs say a page “may stay on this queue for a few seconds, but it can take longer than that” — no fixed delay is published. (A ~5s median/minutes-90th-percentile figure exists, but it’s a dated conference data point, not a current metric.) There is no per-page render budget.
• The WRS is a weird browser: stateless (localStorage/cookies cleared between loads), declines permission prompts, does not scroll/click/hover, and caches JS/CSS aggressively (may ignore cache headers) → fingerprint your filenames.
• Rendering options, by SEO risk: SSG/prerender (lowest) ≈ SSR ≈ hydration ≈ ISR ≈ edge/streaming (low) ≪ full CSR (highest). Patrick: “SSR, static rendering, and prerendering … are all great”; full CSR is “the most problematic one.”
• Dynamic rendering is a workaround, Google advises against it (close to cloaking). Bing still recommends it — but SSR/SSG satisfies both.
• The framework doesn’t decide risk — the rendering mode does. The same app is safe or risky depending on whether you ship SSR/SSG or full CSR.
• Rendering is half the job — the practical JS problems (links, parity, lazy content, infinite scroll, soft-404s, testing) are covered on the JavaScript SEO page.

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• JavaScript SEO temellerini anlayın — üç aşama (tarama → oluşturma → dizine ekleme) ve evergreen Chromium oluşturucusu.
• Aramayla ilgili JavaScript sorunlarını düzeltin — WRS kısıtlamaları: durum bilgisiz depolama/çerezler, reddedilen izinler ve agresif önbelleğe alma.
• Geçici çözüm olarak dinamik oluşturma — dinamik oluşturmanın neden önerilen uzun vadeli çözüm değil, bir geçici çözüm olduğu.
• Google Arama’nın nasıl çalıştığına dair derinlemesine rehber — tarama → dizine ekleme → sunma akışında oluşturmanın yeri.

Bing / Microsoft

• bingbot Serisi: JavaScript, Dinamik Oluşturma ve Gizleme. Aman Tanrım! — Bing’in JS oluşturabildiği, ancak ölçekte dinamik oluşturmayı önerdiği görüşü.
• Yeni evergreen Bingbot — Chromium tabanlı Microsoft Edge’de Bingbot oluşturması.

Kaynaktan alıntılar

Google ve Bing’den (ve kendi yazılarımdan birkaçından) kayda geçmiş ifadeler. Her arama motoru bağlantısı, kaynak sayfada alıntılanan bölüme atlayan derin bir bağlantıdır.

Google — oluşturma akışı

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (terjemahan) “Google, JavaScript web uygulamalarını üç ana aşamada işler: 1. Tarama 2. Oluşturma 3. Dizine ekleme.” Alıntıya git
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (terjemahan) “Tarama sırasında Google sayfayı oluşturur ve bulduğu JavaScript’i, tarayıcınızın ziyaret ettiğiniz sayfaları oluşturmasına benzer biçimde, Chrome’un güncel bir sürümünü kullanarak çalıştırır.” Alıntıya git
• “While Google Search runs JavaScript with an evergreen version of Chromium…” (terjemahan) “Google Arama JavaScript’i evergreen bir Chromium sürümüyle çalıştırırken…” Alıntıya git
• “The page may stay on this queue for a few seconds, but it can take longer than that.” — oluşturma kuyruğu zamanlaması hakkındaki güncel resmî çerçeve; sabit gecikme yayımlanmamıştır. Alıntıya git

Google — Web Rendering Service

• “Local Storage and Session Storage data are cleared across page loads.” (terjemahan) “Local Storage ve Session Storage verileri sayfa yüklemeleri arasında temizlenir.” Alıntıya git
• “HTTP Cookies are cleared across page loads.” (terjemahan) “HTTP çerezleri sayfa yüklemeleri arasında temizlenir.” Alıntıya git
• “Expect Googlebot to decline user permission requests.” (terjemahan) “Googlebot’un kullanıcı izin isteklerini reddetmesini bekleyin.” Alıntıya git
• “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (terjemahan) “Googlebot ağ isteklerini ve kaynak kullanımını azaltmak için agresif biçimde önbelleğe alır. WRS önbellek başlıklarını yok sayabilir.” Alıntıya git

Google — dinamik oluşturma

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (terjemahan) “Dinamik oluşturma, arama motorlarındaki JavaScript ile oluşturulan içerik sorunları için bir geçici çözümdü ve uzun vadeli bir çözüm değildi.” Alıntıya git
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (terjemahan) “Dinamik oluşturma bir geçici çözümdür ve ek karmaşıklıklar ile kaynak gereksinimleri yarattığı için önerilen bir çözüm değildir.” Alıntıya git

Microsoft Bing

• “bingbot is generally able to render JavaScript…” (terjemahan) “bingbot genel olarak JavaScript oluşturabilir…” Alıntıya git
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (terjemahan) “JavaScript’e ağır biçimde dayanan web siteleri için dinamik oluşturmayı harika bir alternatif olarak öneriyoruz.” Alıntıya git

Martin Splitt, Google (Onely’nin 2019 Webmaster Central hangout dökümü üzerinden aktarıldı)

• İki dalga modeli hakkında: Splitt bunun giderek daha az rol oynadığını, birçok sitenin JavaScript olmadan bile oluşturma aşamasından geçtiğini ve tarama, oluşturma ile dizine eklemenin yakınsadığını söyledi. Kapsamı okuyun

Patrick Stox (kendi çalışmam — JavaScript SEO: Kesin Rehber)

• “Google loads each page stateless like it’s a fresh load.” (terjemahan) “Google her sayfayı yeni bir yükleme gibi, durum bilgisi olmadan yükler.”
• “pages went to the renderer at a median time of five seconds” (90. yüzdelik dilimi dakikalar) — güncel yayımlanmış metrik değil, tarihli bir konferans dönemi veri noktasıdır; yukarıdaki güncel resmî kuyruk zamanlaması alıntısına bakın.
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (terjemahan) “En sorunlu olan, oluşturmanın tamamının tarayıcıda gerçekleştiği tam istemci tarafı oluşturma olacaktır.”
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (terjemahan) “Her tür SSR, statik oluşturma ve önceden oluşturma kurulumu arama motorları için uygun olacaktır. Gatsby, Next, Nuxt vb. hepsi harikadır.”

Zihinsel modeller

1. Tarama → oluşturma → dizine ekleme. Oluşturma köprüdür. Tarama ham HTML’yi getirir; oluşturma DOM’u kurmak için JS’yi çalıştırır; dizine ekleme bu DOM’u okur. JS içeriği kaybolduğunda hangi adımın başarısız olduğunu sorun — getirildi mi, oluşturuldu mu, oluşturulmuş DOM içeriği içeriyor mu?

2. Oluşturucu hafızasını kaybetmiş gerçek bir tarayıcıdır. Evergreen Chrome’dur, ancak durum bilgisi tutmaz (sayfalar arasında çerezleri/depolamayı unutur), etkileşime girmez (kaydırmaz veya tıklamaz) ve önbelleği sever (eski JS/CSS çalıştırabilir). Her ziyareti yeni, dokunulmamış bir ilk yükleme gibi tasarlayın.

3. Riskinizi çerçeve değil, oluşturma modu belirler. SSR, statik oluşturma, önceden oluşturma ve hydration içeriği DOM’a koyar (veya hızla koyar) — düşük risk. Tam CSR her şeyi oluşturmanın başarısına bağlar — en yüksek risk. Aynı Next.js uygulaması hangi modu sunduğunuza bağlı olarak güvenli veya risklidir.

4. “İki dalga” eski haritadır. Günler sonra ertelenmiş ikinci bir oluşturma dalgası üzerine plan yapmayın. Oluşturma neredeyse tüm sayfalarda, genellikle saniyeler ile dakikalar içinde gerçekleşir — dağıtılacak bir oluşturma bütçesi yoktur.

5. Dinamik oluşturma bir belirti, strateji değildir. Botlara kullanıcılardan farklı HTML sunmak Google’ın karşı çıktığı bir geçici çözümdür (ve gizlemeye yakındır). Ona başvuruyorsanız gerçek düzeltme genellikle SSR/SSG’dir.

6. İçeriği DOM’a koyun, sonra doğrulayın. İçeriği hızla oluşturulmuş DOM’a koyan bir mod seçin ve ardından URL Inspection’ın oluşturulmuş HTML’siyle doğrulayın. Tarayıcınız Googlebot değildir.

Oluşturma seçenekleri — SEO ödünleşimleri

Web Rendering Service — hızlı bilgiler

Oluşturma hazırlığı denetim listesi

Önemli içeriğinizin oluşturma aşamasından gerçekten sağ çıktığını doğrulamak için bir geçiş:

• Birincil içerik ve ana gezinme bağlantıları ham HTML yanıtında bulunur (DevTools’un incelenmiş DOM’u değil, kaynağı görüntüleyin) — yalnızca JavaScript çalıştıktan sonra eklenmez.
• Okuyucunun izlemesi gereken her iç bağlantı gerçek bir <a href="..."> öğesidir — <div onclick>, yalnızca hash kullanan bir rota (#/page) veya eşleşen bağlantı olmadan istemci tarafında durum gönderen bir düğme değildir.
• Kritik JS veya CSS dosyaları robots.txt içinde engellenmemiştir (engellenen bir paket WRS’nin oluşturması gereken sayfayı kuramamasına yol açabilir).
• Kaydırma, üzerine gelme veya tıklama ile yüklenen içerik, etkileşim olmadan da oluşturulan bir yola sahiptir — WRS kaydırmaz, tıklamaz veya üzerine gelmez.
• Önemli hiçbir şey localStorage, sessionStorage veya istekler arasında kalıcı çerezlere bağlı değildir — WRS durum bilgisi tutmaz ve bunların tamamını sayfa yüklemeleri arasında temizler.
• Önemli hiçbir şey coğrafi konum, bildirim veya kamera izin isteminin arkasında değildir — WRS bunları varsayılan olarak reddeder.
• Değişiklikte yeni bir getirmeyi zorlamak için JS/CSS dosya adlarına parmak izi eklenmiştir (app.4f2a9c.js); böylece WRS’nin agresif önbelleğinden eski sürüm sunulmaz.
• Google Search Console’daki URL Inspection’ın oluşturulmuş HTML’si/ekran görüntüsü, kendi tarayıcınızda gördüğünüz içerik ve bağlantıları gösterir.
• Site, CSR sorununa yanıt olarak dinamik oluşturma kullanmıyordur — düzeltme botlara farklı bir sürüm sunmak değil, SSR, statik oluşturma veya hydration’dır.

Gerçekte zarar veren oluşturma hataları

Sayfanın oluşturulması için gereken JS veya CSS’yi robots.txt içinde engellemek. WRS, sayfanın bağlı olduğu bir betiği veya stil sayfasını getiremiyorsa doğru bir oluşturulmuş DOM kuramaz — istediğiniz sayfa yerine bozuk veya boş bir oluşturma elde edersiniz. Bunun yerine JS/CSS varlıklarınızın taranmasına izin verin; robots.txt botları düşük değerli alanlardan uzak tutmalı, kendi sayfalarınızın ihtiyaç duyduğu kaynakları değil.

İçerik açısından kritik sayfaları geri dönüş olmadan tam istemci tarafı oluşturma (CSR) olarak sunmak. CSR, “the most problematic one … full client-side rendering where all of the rendering happens in the browser” (terjemahan) “en sorunlu olan … oluşturmanın tamamının tarayıcıda gerçekleştiği tam istemci tarafı oluşturma”dır — tüm sayfanın oluşturulmasının başarılı olmasına bel bağlar ve dizine eklenmesi en yavaş seçenektir. Bunun yerine içerik ham HTML’de (veya çok hızlı biçimde onun içinde) bulunsun diye SSR, statik oluşturma/önceden oluşturma veya hydration kullanın.

Yalnızca gezinme için hash tabanlı rotalara (#/product/123) güvenmek. WRS gerçek <a href> bağlantılarını izler; yalnızca istemci tarafı durumunu değiştiren ve sunucu tarafından oluşturulmuş eşdeğer bir URL’si olmayan bir hash parçası, oluşturucuya devam edebileceği hiçbir şey vermez. Bunun yerine, istemci ağırlıklı bir uygulamada bile sunucunun doğrudan yanıt verebileceği gerçek yollar (/product/123) kullanın.

İçeriği ona etkileşim dışı bir yol olmadan tembel yüklemek. WRS “doesn’t scroll, click, or hover,” (terjemahan) “kaydırmaz, tıklamaz veya üzerine gelmez”; bu olaylardan yalnızca birinden sonra görünen içerik varsayılan olarak görünmezdir. Bunun yerine üst kısımdaki ve görünüm alanına makul ölçüde yakın içeriği etkileşim gerektirmeden yükleyin; gerçek anlamda ekranın altında kalan içerik için uygun JS’siz geri dönüşle gerçek tembel yüklemeyi saklayın.

Dinamik oluşturmayı bir geçici çözüm yerine uzun vadeli düzeltme olarak görmek. Google, “dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements” (terjemahan) “dinamik oluşturmanın ek karmaşıklıklar ve kaynak gereksinimleri yarattığı için bir geçici çözüm ve önerilen bir çözüm olmadığını” açıkça söyler — botlara kullanıcılardan farklı içerik sunmak da rahatsız edici biçimde gizlemeye yakındır. Bunun yerine oluşturma modunun kendisini (SSR/statik/hydration) düzeltin; CSR sorununu bir bot algılama katmanıyla çevrelemeyin.

Doğrulama testleri

Bir oluşturma düzeltmesinin gerçekten etkili olduğunu doğrulayan başarılı/başarısız kontroller — bunları sürekli sağlık metriği olarak değil, değişikliği yayımladıktan sonra çalıştırın.

Test: içerik artık oluşturulmuş DOM’da görünüyor

• Çalıştırılacak test — URL’yi Google Search Console’un URL Inspection aracına gönderin ve “Canlı URL’yi test et” seçeneğini kullanın; ardından oluşturulmuş HTML sekmesini açın (veya ham ve oluşturulmuş HTML’yi doğrudan karşılaştırmak için sayfayı Render Gap aracından geçirin).
• Beklenen sonuç — Eklediğiniz veya düzelttiğiniz içerik yalnızca kendi tarayıcınızın geliştirici araçlarında değil, oluşturulmuş HTML/DOM görünümünde de görünür.
• Başarısızlık yorumu — Sayfa normal görüntülendiğinde var olduğu hâlde oluşturulmuş HTML’de hâlâ yoksa WRS onu kuramıyordur — düzeltmenin işe yaradığını varsaymadan önce engellenen JS/CSS kaynağı, yalnızca etkileşimle yükleme veya istemci depolaması bağımlılığı arayın.
• İzleme penceresi — Anında; URL Inspection canlı testi URL’nin güncel durumunu hemen yansıtır.
• Geri alma tetikleyicisi — Düzeltmeden sonra oluşturulmuş HTML hâlâ içeriği içermiyor veya canlı test daha önce vermediği yeni bir tarama/oluşturma hatası veriyor.

Test: önemli bağlantılar oluşturmadan sağ çıkıyor

• Çalıştırılacak test — URL Inspection veya Render Gap’te oluşturulmuş HTML’yi inceleyerek okuyucunun izlemesi gereken her bağlantının çevresinde yalnızca görünür tıklanabilir öğeler değil, gerçek <a href> etiketleri olduğunu kontrol edin.
• Beklenen sonuç — Oluşturulmuş DOM’daki her bağlantı çözümlenebilir bir href değerine ve gerçek, taranabilir bir URL’ye yönelir.
• Başarısızlık yorumu — Çalışıyor gibi görünen bir bağlantıdaki eksik veya boş href genellikle istemci tarafı tıklama işleyicisine sahip bir <div>/<button> ve sunucu tarafından oluşturulabilir yolu olmayan bir öğe olduğu anlamına gelir — WRS onu izleyemez.
• İzleme penceresi — Anında.
• Geri alma tetikleyicisi — Değişiklikten önce önemli olan bağlantılar oluşturulmuş çıktıda href özniteliklerini kaybediyor veya yalnızca hash kullanan bir parçaya yöneliyor.

Test: düzeltme sonraki dağıtımda sessizce gerilemiyor

• Çalıştırılacak test — Bu sayfanın şablonlarına veya derleme akışına dokunan bir sonraki dağıtımdan sonra oluşturulmuş HTML kontrolünü (URL Inspection canlı testi veya Render Gap) yeniden çalıştırın.
• Beklenen sonuç — İlk doğruladığınız zamanki içerik ve bağlantılar oluşturulmuş DOM’da hâlâ bulunur.
• Başarısızlık yorumu — Var olan içerik yeniden kaybolduysa sonraki bir değişiklik istemciye özel bir bağımlılığı geri getirmiş veya sunucu tarafından oluşturulan bir yolu bozmuş olabilir.
• İzleme penceresi — Etkilenen şablonlara dokunan her dağıtımdan sonra yeniden kontrol edin; tek seferlik bir kontrol değildir.
• Geri alma tetikleyicisi — Var olduğu doğrulanan içerik veya bağlantılar yeniden oluşturulmuş DOM’dan çıkar.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• JavaScript SEO: Kesin Rehber — oluşturma, oluşturma modları, DOM eşliği, sonsuz kaydırma ve iki sayfanın tek sayfa olması sorununa dair tam rehberim.
• Teknik SEO için Başlangıç Rehberi — oluşturmanın tarama ile dizine ekleme arasındaki yeri.

Konuşmalarım

• How Search Works (SlideShare) — tarama, oluşturma (WRS, durum bilgisiz yüklemeler, etkileşim yok), dizine ekleme ve sıralama üzerine anlatımım. (Sabit uyarım geçerlidir: “Bu, sistemleri anlayışımdır… %100 eksiksiz veya doğru olmayacak.”)

Başkalarından

• web.dev — Web’de oluşturma — Chrome ekibinden CSR / SSR / SSG / hydration ödünleşimlerinin temel açıklaması.
• Onely — Google’ın iki dalgalı dizine eklemesi — Martin Splitt’in çalışma saatleri oturumunun, iki dalga modelinin neden zayıfladığını açıklayan döküm tabanlı kapsamı; makalenin gövdesinde alıntılanmıştır.
• Search Engine Roundtable — Google: Sayfa başına arama maliyeti yok — dağıtılacak sayfa başına tarama/oluşturma/dizine ekleme maliyeti olmadığını açıklayan Google temsilcisi.
• Search Engine Journal — JavaScript SEO — JS SEO en iyi uygulamaları, test iş akışları ve çerçeve konularının sektör kapsamı.
• Vercel — Oluşturma stratejileri — gerçek bir proje için CSR, SSR, SSG, ISR ve streaming SSR arasında seçim yaparken kullanılabilecek Next.js/edge oluşturma belgeleri.
• r/TechSEO — oluşturma/dizine ekleme sorunlarını hata ayıklama topluluğu.

Videolar

• Google Search Central (YouTube) — Martin Splitt’in JavaScript SEO serisi ile oluşturma açıklamaları, Web Rendering Service’in JS’nizi nasıl ele aldığını anlatan en iyi resmî video turudur. Kanal

Alıntılamaya değer istatistikler

• Güncel resmî çerçeve: sabit gecikme yok. Google’ın belgeleri, taranmış bir sayfanın “may stay on this queue for a few seconds, but it can take longer than that” (terjemahan) “bu kuyrukta birkaç saniye kalabilir, ancak daha uzun sürebilir” olduğunu söyler — oluşturma kuyruğu için yayımlanmış sabit bir gecikme veya zaman aşımı yoktur.
• Tarihli tarihsel veri noktası — yaklaşık 5 saniyelik medyan oluşturma gecikmesi. Daha önceki konferans konuşmalarında Google çalışanları (Martin Splitt ve Tom Greenaway), sayfaların oluşturucuya yaklaşık 5 saniyelik medyanla ve 90. yüzdelik dilimde dakikalar içinde ulaştığını belirtti — eski iki dalga korkusunun ima ettiği “haftalar” değil. Buna JavaScript SEO rehberimde yer veriyorum; ancak bunu güncel yayımlanmış bir ölçüm değil, tarihsel bir veri noktası olarak ele alın — Google bunu devam eden bir değer olarak yeniden yayımlamadı.
• İki dalgalı dizine ekleme zayıflıyor. Martin Splitt’e göre tarama, oluşturma ve dizine ekleme yakınsadıkça iki dalga modeli giderek daha az rol oynuyor — oluşturma artık neredeyse tüm sayfalarda gerçekleşiyor. Kapsam
• Sayfa başına oluşturma bütçesi yok. Google, tek bir sayfanın taranmasının, oluşturulmasının, dizine eklenmesinin veya sunulmasının ne kadar pahalı olduğunu izlemediğini belirtti — bu nedenle tarama bütçesi tartışmalarındaki gibi korunacak bir “oluşturma bütçesi” yoktur. Kapsam

Kendinizi sınayın: Oluşturma

Google’ın sayfaları nasıl oluşturduğu hakkında beş kısa soru. Her biri için bir yanıt seçin, sonra kontrol edin.

Değişiklik günlüğü