JavaScript için SEO

TL;DR — JavaScript SEO tek bir soruyla ilgilidir: arama motorları içeriğinizi görebiliyor mu? Modern siteler sayfanın büyük bölümünü tarayıcıda JavaScript ile oluşturur. Önemli metniniz ve bağlantılarınız yalnızca betikler çalıştıktan sonra görünüyorsa Google’ın bunlara hâlâ ulaşabildiğini doğrulamanız gerekir. Google genellikle ulaşabilir — sorun ayrıntılardadır.

JavaScript SEO nedir

Birçok site sayfanın bir bölümünü (hatta tamamını) tarayıcınızda JavaScript ile oluşturur. Sunucu bir miktar HTML gönderir; ardından betikler içeriği doldurmak, daha fazla öğe yüklemek veya tam sayfa yeniden yüklemeden görünümleri değiştirmek için çalışır. JavaScript SEO, arama motorlarının bu içeriği hâlâ tarayabilmesini, oluşturabilmesini ve dizine ekleyebilmesini sağlamaktır.

Google için olayların gerçekleşme sırası şöyledir:

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

Google bunları JavaScript web uygulamalarını işlemek için üç ana aşama olarak belgeliyor.

İç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. Çoğu zaman bunu yapar. Yapamadığında içeriğiniz arama sonuçlarından sessizce kaybolabilir.

Önce iyi haber

JavaScript SEO için kötü değildir. Google güncel bir Chrome sürümünü çalıştırabilir ve ziyaretçilerinizin çalıştırdığı JavaScript’in aynısını yürütebilir. Eski korku — “Google JavaScript okuyamaz” — artık doğru değildir.

Yanlış gidebilecekler daha özeldir:

• İçeriğinizin yüklenmesi için tıklama veya kaydırma gerekir; Google tıklamaz veya kaydırmaz. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content
• Bağlantılarınız gerçek bağlantılar değildir (düğme veya tıklama işleyicisidir); bu yüzden Google onları izleyemez. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable
• JavaScript veya CSS dosyalarınızı yanlışlıkla robots.txt içinde engellemişsinizdir; bu nedenle Google sayfayı düzgün oluşturamaz.
• Sayfa tarayıcınızda düzgün görünür, ancak içerik Google’ın oluşturulmuş görünümünde hiç görünmez.

Basit kontrol listesi

• Ham HTML’nizi (sağ tıklayın → Kaynağı Görüntüle) oluşturulmuş HTML ile (Google Search Console’un URL Inspection aracı) karşılaştırın. Önemli içerik oluşturulmuş görünümde yoksa sorun budur.
• Bağlantıların <a href> bağlantıları olduğundan, <div> üzerindeki tıklama işleyicileri olmadığından emin olun.
• JavaScript veya CSS dosyalarınızı robots.txt içinde engellemeyin.
• Bir özelliğin içerik yüklemek için tıklama veya kaydırma gerektirmesi hâlinde, bu içeriğin başka bir yoldan da ulaşılabilir olduğundan emin olun.
• Kesinlikle sıralanması gereken içerik için, içeriğin ham HTML’de zaten bulunduğu sunucu tarafı oluşturmayı veya statik/önceden oluşturulmuş bir yapıyı tercih edin. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Daha derin sürüm için — gerçek hata biçimleri, iki sayfanın tek sayfa olarak dizine eklenmesine yol açan sonsuz kaydırma tuzağı ve oluşturulmuş HTML’yi test etme — Advanced sekmesine geçin. Google’ın oluşturucusunun nasıl çalıştığını ve hangi oluşturma kurulumunun seçileceğini görmek için rendering sayfasına bakın.

TL;DR — Google can run your JavaScript, so “can Google read JS?” is the wrong question. The failure modes are parity (raw vs. rendered DOM), interaction (Google doesn’t scroll or click), state (the renderer is stateless), and timing. Keep links as real <a href> anchors, don’t block JS/CSS, lazy-load on viewport not interaction, return real statuses for client-side 404s, and remember a raw noindex may prevent rendering before JavaScript can remove it. Combine directives that were actually processed, but do not assume a universal raw/rendered winner. Watch infinite scroll especially: a tall render viewport can trigger the loader and merge two URLs into one indexed page. For the renderer internals and which rendering mode to pick, see rendering.

Google JavaScript’i okuyabilir mi? Evet — soru bu değil

Google JavaScript uygulamalarını üç aşamada işler: “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.” Orta aşama, dizine eklenecek DOM’u oluşturmak için JS’yi evergreen, headless Chrome’da çalıştırır. “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (terjemahan) “Oluşturma önemlidir; çünkü web siteleri içeriği sayfaya getirmek için çoğu zaman JavaScript’e güvenir ve oluşturma olmadan Google bu içeriği göremeyebilir.”

Yani Google JavaScript’inizi çalıştırabilir. Yararlı sorular daha özeldir:

• Eşlik — oluşturulmuş DOM gerçekten içerdiğini düşündüğünüz şeyi içeriyor mu?
• Etkileşim — Google’ın gerçekleştirmeyeceği bir kaydırma veya tıklama gerekiyor mu?
• Durum — durum bilgisi tutmayan oluşturucunun temizlediği çerezlere veya localStorage’a mı güveniyorsunuz?
• Zamanlama — kritik içerik yavaş veya geç çalışan JavaScript’in arkasında mı erteleniyor?

Özellikle zamanlama konusunda: Google, taranmış bir sayfayı (200 döndürmüş bir sayfayı) oluşturma kuyruğuna alır ve “the page may stay on this queue for a few seconds, but it can take longer than that.” (terjemahan) “sayfa bu kuyrukta birkaç saniye kalabilir, ancak daha uzun sürebilir.” Yayımlanmış sabit bir gecikme veya zaman aşımı yoktur — ayrıca 200 olmayan bir durum döndüren ya da başlangıçta bir noindex yönergesi taşıyan sayfa, JavaScript’in bunu değiştirmesini beklemek yerine oluşturma kuyruğunu atlayabilir.

Google’ın nasıl oluşturduğunun mekanikleri — Web Rendering Service, durum bilgisizliği, önbelleğe alma ve “iki dalga” efsanesi — rendering sayfasında. Burada pratik sorunlara ve düzeltmelere odaklanacağım.

Bağlantılar gerçek <a href> öğeleri olmalı

Bu, en yaygın JS SEO hatasıdır. “Google can only discover your links if they are <a> HTML elements with an href attribute.” (terjemahan) “Google bağlantılarınızı yalnızca href özniteliğine sahip <a> HTML öğeleri ise keşfedebilir.” <div> işleyicisine sahip tıklanabilir bir onclick, Google için bağlantı olarak görünmez — izlenmez ve keşif için ona bağlı olan sayfalar taranmadan kalabilir. JavaScript ile bağlantı eklemek tamamen uygundur; yeter ki bunlar oluşturulmuş DOM’da gerçek <a href> öğelerine dönüşsün. Ancak bu oluşturulmuş öğeler JavaScript çalıştıktan sonra ayrıştırılır — oluşturulmuş DOM’a girmeleri bağlantıyı keşfedilebilir yapar, URL’nin ham HTML’deki bir bağlantıyla aynı şekilde taranacağının, dizine ekleneceğinin veya değerlendirileceğinin garantisini vermez.

Tembel yüklenen ve etkileşimle açılan içerik

Oluşturucu meraklı bir kullanıcı gibi davranmaz: “Google Search does not interact with your page.” (terjemahan) “Google Arama sayfanızla etkileşime girmez.” Kaydırma, tıklama veya üzerine gelme yoktur. Bu olaylardan yalnızca biriyle yüklenen içerik görülmez.

Google’ın tavsiyesi şudur: içeriği kullanıcı harekete geçtiğinde değil, görünüm alanına girdiğinde yükleyin — “make sure that your lazy-loading implementation loads all relevant content whenever it is visible in the viewport,” (terjemahan) “tembel yükleme uygulamanızın ilgili tüm içeriği görünüm alanında görünür olduğu her anda yüklediğinden emin olun” ve “don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page.” (terjemahan) “kullanıcı bir sayfayı açtığında büyük olasılıkla hemen görünür olacak içeriğe tembel yükleme eklemeyin.” Görseller için IntersectionObserver veya yerel loading="lazy" kullanın — kaydırma ya da tıklama işleyicisi kullanmayın; böylece içerik normal bir oluşturma sırasında yüklenir.

Sonsuz kaydırma: iki sayfanın tek sayfa olarak dizine eklenmesi

Bu, neredeyse hiç kimsenin açıklamadığı ve tek başına bütün bu bölümü hak eden noktadır.

Googlebot, tipik bir tarayıcı penceresinden çok daha yüksek bir görünüm alanında oluşturma yapabilir. Google kesin bir oluşturma görünüm alanı boyutu yayımlamıyor — bu boyut değişebilir — bu nedenle belirli bir sayıya göre tasarım yapmayın; bunun yerine kendi uygulamanızı test edin. Önemli olan mekanizmadır: sonsuz kaydırma yükleyiciniz kaydırma konumuna veya görünüm alanı yüksekliğine göre çalışıyorsa, beklenenden yüksek bir oluşturma görünüm alanı oluşturma sırasında yükleyiciyi kendisi tetikleyebilir ve sonraki makalenin veya ürün sayfasının içeriği aynı DOM’a eklenebilir. Böylece iki farklı URL’nin içeriği birlikte oluşturulur ve Google bunları tek sayfa olarak dizine ekleyebilir. Kendi deneyimimde, “occasionally, two pages get indexed as one” (terjemahan) “bazen iki sayfa tek sayfa olarak dizine ekleniyor” — “dizine eklenmedi” olarak bildirilen bazı sayfalar aslında “when Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (terjemahan) “Google görünüm alanını uzatmak için yeniden boyutlandırdığında … sonsuz kaydırmayı tetikledi ve oluşturma sırasında başka bir makale yüklediği” için başka bir sayfanın (genellikle akıştaki önceki gönderinin) parçası olarak dizine eklenmişti. Kısa bir yerde durmasını beklediğiniz bir sayfanın URL Inspection oluşturulmuş HTML’sini kontrol ederek kendi kurulumunuzun bunu yapıp yapmadığını doğrulayın — bir boyut varsaymayın ve güvende olduğunuzu varsaymayın.

Bunu doğru yapmanın iki katmanı vardır.

Öncelikle sonsuz kaydırmayı arama dostu hâle getirin. Sonsuz kaydırmanın altında sayfalandırılmış yüklemeyi destekleyin. Her parçanın “its own persistent, unique URL,” (terjemahan) “kendine ait kalıcı ve benzersiz bir URL’si” olmalı; her URL’deki içerik her yüklemede aynı kalmalı; ?date=yesterday gibi göreli parametrelerden kaçınmalı; arama motorlarının sayfalandırılmış bir kümedeki URL’leri keşfedebilmesi için “link sequentially to the individual URLs so that search engines can discover the URLs in a paginated set,” (terjemahan) “tek tek URL’lere sırayla bağlantı vermeli”; yeni bir parça kaydırmayla yüklendiğinde “update the displayed URL using the History API.” (terjemahan) “görüntülenen URL’yi History API kullanarak güncellemelisiniz.” Gerçek <a href> sayfalandırma bağlantıları ve benzersiz URL’ler kullanın — sayfa numaraları için “don’t use URL fragment identifiers” (terjemahan) “URL parça tanımlayıcılarını kullanmayın” (yani # işaretinden sonraki bölümü), çünkü Google bunları yok sayar. JavaScript SEO rehberimde söylediğim gibi, “if you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (terjemahan) “sonsuz kaydırma kurulumunuz varsa Google’ın hâlâ düzgün tarayabilmesi için sayfalandırılmış bir sürümü yine de öneririm.”

Hatalı bir yükleyici sayfaları aktif olarak birleştiriyorsa, en hızlı düzeltme kesindir: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (terjemahan) “işlevin tetiklenememesi için sonsuz kaydırmayı yöneten JavaScript dosyasını engelleyin.” Yükleyici oluşturma sırasında çalışamıyorsa sonraki sayfanın içeriğini ekleyemez ve her URL yeniden kendisi olarak oluşturulur.

Soft-404s after client-side routing

Tek sayfalı uygulamalar HTTP durum kodunu değiştirmeden içeriği değiştirebilir; bu nedenle “bulunamadı” görünümü yine de 200 döndürebilir. Google döndürülen içeriği değerlendirdikten sonra bu yanıtı soft 404 olarak sınıflandırabilir, ancak yalnızca statik bir getirme Google’ın bu sınıflandırmayı yaptığını kanıtlayamaz. İki düzeltme vardır: görünümleri History API ile değiştirin ve gerçekten bulunamayan bir durum için ya gerçek bir 404 durumu döndüren bir URL’ye yönlendirin ya da bir noindex etiketi ekleyin. Yönlendirme için URL parçalarına da güvenmeyin — “the AJAX-crawling scheme has been deprecated since 2015, so you can’t rely on URL fragments to work with Googlebot.” (terjemahan) “AJAX tarama şeması 2015’ten beri kullanımdan kaldırılmıştır; bu nedenle URL parçalarının Googlebot ile çalışacağına güvenemezsiniz.”

İstemci tarafı yönlendirmenin de aynı kanıt sorunu vardır: ilk yanıt JavaScript çalışana kadar 200 olarak kalabilir. Google, sunucu tarafı veya meta-refresh yönlendirmeleri mümkün olmadığında JavaScript yönlendirmelerini yalnızca geri dönüş olarak destekler. Statik durumu ve oluşturulmuş gezinmede gözlemlenen değişikliği ayrı ayrı raporlayın; denetimde HTTP durumunu yeniden yazmayın ve oluşturulmuş URL’deki her değişikliğe yönlendirme demeyin.

JavaScript veya CSS’yi robots.txt içinde engellemeyin

Google engellenen dosyalardaki veya engellenen sayfalardaki JavaScript’i oluşturmaz. Paketinizin (ya da paketin bulunduğu robots.txt, /_next/, /static/ dizininin) erişimini engelleyen bir /assets/ kuralı oluşturmayı bütünüyle bozabilir — Google kabuğu getirir, betikleri çalıştıramaz ve boş bir sayfayı dizine ekler. Engellenen bir şey olup olmadığını görmek için URL Inspection’ın sayfa kaynaklarını kontrol edin.

DOM eşliği ve aşamaya duyarlı robots yönergeleri

Ham HTML’nizi (Kaynağı Görüntüle) oluşturulmuş HTML ile (URL Inspection) karşılaştırın. Yalnızca oluşturulmuş HTML’de bulunan içerik, oluşturuluyorsa yine de dizine eklenebilir. İkisinde de bulunmayan içerik Google için mevcut değildir.

Google’ın doğrudan belgelediği bir aşama sırası riski vardır: “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (terjemahan) “Google noindex etiketiyle karşılaştığında oluşturmayı ve JavaScript yürütmesini atlayabilir; bu da robots meta etiketini noindex değerinden değiştirmek veya kaldırmak için JavaScript kullanmanın beklendiği gibi çalışmayabileceği anlamına gelir.” Ham HTML’niz JavaScript ile değiştirmeyi amaçladığınız ilk bir noindex değerini gönderiyorsa Google bu ham noindex değerine göre hareket edebilir ve onu kaldıracak betiği hiç çalıştırmayabilir.

Bunu evrensel bir “oluşturulmuş sürüm kazanır” kuralına dönüştürmeyin. Uzlaştırma alana özeldir:

Bu matris, denetçinin kaynak, oluşturulmuş sürüm, yanıt başlıkları ve gözlemlenen arama durumunu tek bir “etkin” değerde birleştirmek yerine ayrı tutmasının nedenidir.

İçeriği DOM’a koyan bir oluşturma modu seçin

JS SEO riskinin çoğu HTML’nin nasıl üretildiğine iner. Kısa sürüm şudur: SSR, statik/önceden oluşturma ve hydration içeriği DOM’a koyar (veya hızla koyar); bu da görünürlüğün oluşturucunun başarılı olmasına ne kadar bağlı olduğunu azaltır. Tam istemci tarafı oluşturma ise her seferinde oluşturmanın doğru ve zamanında tamamlanmasına daha fazla yük bindirir. Dinamik oluşturma eşdeğer bir seçenek değil, bir geçici çözümdür — Google’ın Aralık 2025’te güncellenen rehberinde dinamik oluşturmayı uzun vadeli çözüm yerine geçici çözüm olarak anlatır ve bunun yerine sunucu tarafı oluşturmayı, statik oluşturmayı veya hydration’ı önerir. JavaScript SEO rehberimde söylediğim gibi, “any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (terjemahan) “Her tür SSR, statik oluşturma ve önceden oluşturma kurulumu arama motorları için uygun olacaktır.” CSR, SSR, SSG, hydration, ISR, edge, streaming ve dinamik oluşturmayı içeren seçeneklerin tamamı ile ödünleşim tablosu rendering sayfasında. Google ayrıca sunucu tarafı oluşturmayı veya önceden oluşturmayı kullanıcılar ve tarayıcılar için iyi bir fikir olarak tanımlar. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Nasıl test edilir

Search Console’daki URL Inspection gerçeğin kaynağıdır: canlı bir test çalıştırın, ardından neyin yüklendiğini ve neyin başarısız olduğunu görmek için oluşturulmuş HTML’ye, ekran görüntüsüne ve sayfa kaynaklarına / konsol mesajlarına bakın. Rich Results Test hızlı bir oluşturulmuş HTML kontrolü sağlar. Ölçekli olarak, ham ve oluşturulmuş sürümleri sitenin tamamında karşılaştırmak için JavaScript çalıştıran bir tarayıcı kullanın (Ahrefs Site Audit, JS oluşturma modundaki Screaming Frog).

JavaScript SEO için kötü değildir ve şeytan da değildir. SEO uzmanlarının çoğunun alışık olduğundan yalnızca farklıdır. Geliştiricilerinizle birlikte çalışın, önemli içeriğinizi DOM’a koyun ve neyin oluşturulduğuna dair hakem olarak varsayımlarınızı değil Google’ın kendi araçlarını kullanın.

Sırada ne var: JavaScript SEO kümesi

Bu hub haritadır. Aşağıdaki konuların her biri kendi derinlemesine incelemesidir:

Oluşturma ve mimari

• Headless CMS için SEO — ayrıştırılmış ön yüzlerin tarama, oluşturma, meta verileri, site haritalarını ve canonical etiketlerini nasıl etkilediği; hangi oluşturma modunun seçileceği ve bilmeniz gereken headless’a özgü hata biçimleri.

Çerçeveye özel rehberler

• React SEO — CSR öncelikli React’in neden dizine ekleme riski yarattığı, Google’ın React uygulamalarını nasıl oluşturduğu, React Router ve History API, meta etiketleri için react-helmet-async ve Next.js’e ne zaman başvurulacağı.
• Angular SEO — Angular’ın SPA varsayılanları, @angular/ssr (Angular Universal’ın halefi), yerleşik Title ve Meta servisleri, önceden oluşturma ve modern Angular’da artımlı hydration.
• Next.js SEO — Pages Router ile App Router, Metadata API, next/image ve CWV, ISR zamanlaması ve Googlebot, site haritaları ve en yaygın Next.js SEO hataları.
• Nuxt SEO — varsayılan olarak SSR, useSeoMeta(), Nuxt’un oluşturma modları, @nuxtjs/seo modül ekosistemi ve Nuxt’un dizine eklenebilirlik bakımından yalın Vue ile karşılaştırması.
• Vue SEO — Vue 3’ün varsayılan CSR’ı ve bunun tarayıcılar için anlamı, createWebHistory(), @unhead/vue, meta-çerçeve olmadan önceden oluşturma seçenekleri ve Nuxt’un doğru tercih olduğu durumlar.
• Svelte SEO — Svelte ile SvelteKit karşılaştırması, SvelteKit’te varsayılan SSR, <svelte:head>, adapter-static + ssr: false tuzağı, adapter seçenekleri ve AI tarayıcılarının etkileri.
• Astro SEO — varsayılan olarak sıfır JS, adalar mimarisi, @astrojs/sitemap, astro:assets, View Transitions ve History API, Server Islands geri dönüş davranışı ve Astro’nun Core Web Vitals avantajları.

AI özeti

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

• “Can Google read JS?” is the wrong question — it can. The failure modes are parity (raw vs. rendered), interaction (Google doesn’t scroll/click), state (stateless renderer), and timing.
• Timing has no fixed delay — Google queues a 200 page for rendering and may wait “a few seconds” or longer, with no published timeout; a non-200 status or an initial noindex can skip the render queue entirely.
• Links must be real <a href> anchors — onclick on a <div> is invisible as a link. Injecting links with JS is fine if they end up as anchors, but rendered anchors are parsed after JS runs — discoverable, not a crawl/index guarantee.
• Lazy-load on the viewport, not interaction — Google “does not interact with your page.” Use IntersectionObserver / native lazy-load; don’t gate content behind scroll or click.
• Infinite scroll can merge two pages into one — Googlebot can render at a taller viewport than a typical browser (no exact published size — test your own setup), and that gap can trigger the loader and append the next page’s content. Fix: paginated URLs + real <a href> links + History API; if a loader is merging pages, block its JS file.
• Soft-404s after client-side routing — return a real 404 or noindex; don’t index empty shells; don’t rely on URL fragments (AJAX-crawling deprecated 2015).
• Don’t block JS/CSS in robots.txt — Google won’t render from blocked files.
• noindex can block its own removal — Google may skip rendering when it sees an initial noindex, so JS meant to remove it may never run.
• DOM parity + stage order (robots meta tags) — diff raw vs. rendered, but remember an initial raw noindex may stop rendering. Apply combination rules only to directives actually processed; test canonical parity under its own rules.
• Rendering mode changes dependency, not outcome — SSR/static/prerender/hydration put content in the DOM sooner, reducing reliance on rendering; full CSR relies on it most; dynamic rendering is a dated Google workaround, not a peer option. Full breakdown on the rendering page.
• Test with URL Inspection (rendered HTML + screenshot + console), Rich Results Test, and a JS-rendering crawler.

Resmî belgeler

Arama motorlarının birincil kaynak belgeleri.

Google

• JavaScript SEO temellerini anlayın — üç aşama, taranabilir bağlantılar ve oluşturulmuş HTML’yi test etme.
• Aramayla ilgili JavaScript sorunlarını düzeltin — soft-404 işleme, History API ve oluşturucu kısıtlamaları.
• Tembel yüklenen içeriği düzeltin — etkileşim yerine görünüm alanında yükleme ve arama dostu sonsuz kaydırma.
• E-ticaret sayfalandırması ve artımlı sayfa yükleme — benzersiz URL’ler, <a href> bağlantıları ve Google’ın URL parça tanımlayıcılarını neden yok saydığı.
• 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şturma ve dinamik oluşturma hakkındaki görüşü.

Kaynaktan alıntılar

Google’dan (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 ve bağlantılar

• “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
• “Google can only discover your links if they are <a> HTML elements with an href attribute.” (terjemahan) “Google bağlantılarınızı yalnızca href özniteliğine sahip <a> HTML öğeleri ise keşfedebilir.” 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.” (terjemahan) “Oluşturma önemlidir; web siteleri içeriği sayfaya getirmek için çoğu zaman JavaScript’e güvenir ve oluşturma olmadan Google bu içeriği göremeyebilir.” 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ında, yayımlanmış sabit gecikme yoktur. Alıntıya git
• “When Google encounters the noindex tag, it may skip rendering and JavaScript execution, which means using JavaScript to change or remove the robots meta tag from noindex may not work as expected.” (terjemahan) “Google noindex etiketiyle karşılaştığında oluşturmayı ve JavaScript yürütmesini atlayabilir; bu da robots meta etiketini noindex değerinden değiştirmek veya kaldırmak için JavaScript kullanmanın beklendiği gibi çalışmayabileceği anlamına gelir.” Alıntıya git

Google — etkileşim, tembel yükleme ve sonsuz kaydırma

• “Google Search does not interact with your page.” (terjemahan) “Google Arama sayfanızla etkileşime girmez.” Alıntıya git
• “…loads all relevant content whenever it is visible in the viewport.” (terjemahan) “…görünüm alanında görünür olduğu her anda ilgili tüm içeriği yükler.” Alıntıya git
• “Give each chunk its own persistent, unique URL.” — arama dostu sonsuz kaydırma. Alıntıya git
• “Don’t use URL fragment identifiers (the text after a # in a URL) for page numbers in a collection. Google ignores fragment identifiers.” (terjemahan) “Bir koleksiyondaki sayfa numaraları için URL parça tanımlayıcılarını (URL’de # işaretinden sonraki metni) kullanmayın. Google parça tanımlayıcılarını yok sayar.” Alıntıya git

Google — soft-404 ve yönlendirme

• “We recommend using the History API to load different views.” (terjemahan) “Farklı görünümleri yüklemek için History API kullanmanızı öneririz.” Alıntıya git

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

• Özellikle meta robots etiketleri hakkında: “With meta robots tags, Google is always going to take the most restrictive option it sees — no matter the location… Google will choose the most restrictive statements between HTML and the rendered version of a page.” (terjemahan) “Meta robots etiketlerinde Google, konumdan bağımsız olarak gördüğü en kısıtlayıcı seçeneği her zaman alır… Google, HTML ile bir sayfanın oluşturulmuş sürümü arasındaki en kısıtlayıcı ifadeleri seçer.”
• “If you have an infinite scroll setup, I still recommend a paginated page version so that Google can still crawl properly.” (terjemahan) “Sonsuz kaydırma kurulumunuz varsa Google’ın hâlâ düzgün tarayabilmesi için sayfalandırılmış bir sürümü yine de öneririm.”
• Birleştirme hakkında: “occasionally, two pages get indexed as one” — “Google resized the viewport to be longer … it triggered the infinite scroll and loaded another article in when it was rendering.” (terjemahan) “bazen iki sayfa tek sayfa olarak dizine ekleniyor” — “Google görünüm alanını uzatmak için yeniden boyutlandırdığında … sonsuz kaydırmayı tetikledi ve oluşturma sırasında başka bir makale yükledi.” Çözüm: “block the JavaScript file that handles the infinite scrolling so the functionality can’t trigger.” (terjemahan) “işlevin tetiklenememesi için sonsuz kaydırmayı yöneten JavaScript dosyasını engelleyin.”

JavaScript SEO kontrol listesi

Google’ın JS’ye bağlı içeriğinizi oluşturup dizine ekleyebildiğini hızlıca doğrulamak için:

• Önemli içerik oluşturulmuş HTML’de görünür (yalnızca Kaynağı Görüntüle’yi değil, URL Inspection’ı kontrol edin).
• Bağlantılar <a href> öğeleridir — onclick/<div> üzerindeki <span> işleyicileri değildir.
• JavaScript ve CSS dosyaları robots.txt içinde engellenmemiştir.
• Hiçbir içerik tıklama, kaydırma veya üzerine gelme koşulunun arkasında değildir (Google etkileşime girmez); IntersectionObserver veya loading="lazy" aracılığıyla görünüm alanında tembel yükleme yapar.
• Görünüm alanının üst kısmındaki içerik tembel yüklenmez.
• Robots yönergeleri ham ve oluşturulmuş HTML arasında aynıdır (JS noindex eklemiyor) — Google en kısıtlayıcı olanı alır.
• Eksik bir kaynağa ulaşan istemci tarafı rota değişiklikleri gerçek bir 404 veya noindex döndürür (soft-404 kabukları yoktur).
• Sonsuz kaydırmanın benzersiz <a href> URL’leri ve History API güncellemeleri olan sayfalandırılmış bir sürümü vardır — ayrıca yüksek bir görünüm alanında sayfaları birleştirmiyordur.
• Sıralanması gereken içerik tam CSR yerine SSR / statik oluşturma / önceden oluşturma kullanır (oluşturma sayfasına bakın).
• URL Inspection canlı testinde oluşturulmuş ekran görüntüsünü ve konsol hatalarını örneklemeyle kontrol ettiniz.

Zihinsel modeller

1. “Google JS’yi çalıştırabilir mi?” yanlış sorudur. Çalıştırabilir. Gerçek sorular eşlik, etkileşim, durum ve zamanlama ile ilgilidir:

• Eşlik — oluşturulmuş DOM düşündüğünüz içeriği içeriyor mu?
• Etkileşim — Google’ın gerçekleştirmeyeceği bir kaydırma/tıklama gerekiyor mu?
• Durum — durum bilgisi tutmayan oluşturucunun temizlediği çerezlere/localStorage’a mı güveniyorsunuz?
• Zamanlama — kritik içerik yavaş/geç çalışan JS’nin arkasında mı erteleniyor?

2. Oluşturulmuş DOM’da değilse mevcut değildir. Kaynağı Görüntüle ham HTML’yi; URL Inspection ise oluşturulmuş DOM’u gösterir. Dizine ekleme kararları oluşturulmuş DOM’a göre verilir — bu nedenle her seferinde kontrol edilmesi gereken çıktı odur.

3. Gerçek bağlantılar ya da hiç bağlantı yok. Keşif <a href> öğeleri üzerinden gerçekleşir. Hiçbir zaman bir bağlantı üretmeyen tıklama işleyicileri, düğmeler ve JS gezinmesi tarama için çıkmaz sokaklardır.

4. Sayfaya hiç dokunmayan bir bot için tasarlayın. Kaydırma yok, tıklama yok, üzerine gelme yok. İçeriğin görünmesi için bir eylem gerekiyorsa Google’ın onu görmeyeceğini varsayın — bunun yerine görünüm alanında yükleyin.

5. Sonsuz kaydırmada uzun görünüm alanı tuzağını test edin. Googlebot tipik bir tarayıcıdan daha yüksek bir görünüm alanında oluşturma yapabilir (sabit bir boyut yayımlanmadığı için belirli bir sayıya göre tasarım yapmayın); bu nedenle kaydırma/yükseklikle tetiklenen bir yükleyici oluşturma sırasında çalışabilir ve sonraki sayfayı içeriye katabilir. Bunun için tasarlayın: sayfalandırılmış URL’ler + gerçek bağlantılar + History API; etkin olarak birleştiriyorsa yükleyicinin JS’sini engelleyin.

6. Kararı araçlara bırakın. Tarayıcınız Googlebot değildir. URL Inspection’ın oluşturulmuş HTML’si, ekran görüntüsü ve konsolu — “benim makinemde düzgün görünüyor” değil — gerçeğin kaynağıdır.

JavaScript SEO tuzakları — kopya kâğıdı

Hangi oluşturma modu? (oluşturmanın başarılı olmasına bağlılık)

Bu, sonucun garantisi değildir — SSR/SSG/hydration yine de doğru oluşturulmalı ve bu makaledeki diğer tüm kontrolleri geçmelidir. ISR, edge, streaming, dinamik oluşturma ve ödünleşimlerin tam dökümü rendering sayfasındadır.

Googlebot’un gördüğünü görün

Oluşturma hataları ham HTML (sunucunun gönderdiği) ile oluşturulmuş HTML (JS çalıştıktan sonra var olan) arasındaki farkta gizlenir. Tam bir tarayıcıya başvurmadan önce birkaç hızlı komut satırı kontrolü yapabilirsiniz.

Ham HTML’yi getirir (herhangi bir JS çalışmadan önce dönen şey)

macOS / Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

Metin raw.html içinde yok ama tarayıcınızda görünüyorsa JavaScript tarafından ekleniyordur — yani oluşturulmaya bağlıdır. (Oluşturulmuş HTML için URL Inspection’ın “Taranan sayfayı görüntüle → oluşturulmuş HTML” seçeneğini veya headless Chrome tarayıcısını kullanın; yalın bir curl JS çalıştıramaz.)

robots.txt içinde JS/CSS’yi engellemediğinizi doğrulayın

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

JavaScript veya CSS’nizle eşleşen bir Disallow Google’ın sayfayı düzgün oluşturamayacağı anlamına gelir — neredeyse her zaman bir hatadır. (URL Inspection engellenen sayfa kaynaklarını da listeler; grep yalnızca bariz olanları hızlıca yakalar.)

JavaScript SEO hata ayıklama araçları

Render Gap ile ham HTML ve Google’ın oluşturduğu sürüm arasındaki farkı görün:

1. Test etmek istediğiniz sayfanın tam URL’sini yapıştırın — JavaScript ağırlıklı bir şablon sayfası en belirgin sonucu verir.
2. Kötüye kullanım önlemini temizleyip Sayfayı test et düğmesine basın; araç önce ham HTML’yi getirir ve yalnızca bu HTML boş bir kabuk gibi göründüğünde headless Chrome’da oluşturma yapar.
3. Renk kodlu sonucu okuyun, ardından değişti olarak işaretlenmiş satırlar için İlk HTML ile Oluşturulmuş DOM tablosunu tarayın.
4. JavaScript’in ne eklediğini veya kaldırdığını satır satır görmek için Ham ve oluşturulmuş fark sekmesine geçin.

• URL Inspection (Google Search Console) — gerçeğin kaynağıdır. Bir canlı test çalıştırın; ardından oluşturulmuş HTML’yi, ekran görüntüsünü, sayfa kaynaklarını (ne yüklendi, ne engellendi) ve JavaScript konsol mesajlarını görüntüleyin.
• Rich Results Test — siteyi doğrulamadan bir URL’nin oluşturulmuş HTML’sini ve yapılandırılmış verilerini hızlıca kontrol eder.
• Chrome DevTools — Kaynağı Görüntüle (ham HTML) ile Elements panelini (oluşturulmuş DOM) karşılaştırın; Konsol, içeriği boşaltabilecek JS hatalarını gösterir.
• JavaScript oluşturan tarayıcılar — Ahrefs Site Audit ve Screaming Frog SEO Spider (JS oluşturma modu) JS’yi çalıştırarak ham ve oluşturulmuş sürümleri ölçekte karşılaştırabilir.
• Oluşturulmuş kaynağı görüntüleme araçları — hızlı örneklemeler için oluşturulmuş DOM’u ham sürümün yanında gösteren tarayıcı uzantıları.
• Sunucu günlük analizi — Googlebot’un JS/CSS kaynaklarınızı gerçekten getirip getirmediğini doğrulayın (günlük dosyası analizi bölümüne bakın).

JavaScript SEO tanısı için istemler

Ham ve oluşturulmuş HTML’yi karşılaştırın

Aynı URL için ham yanıtı ve oluşturulmuş DOM’u yapıştırın. Önce müşteri verilerini ve belirteçleri kaldırın.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

Bir rota örneğini önceliklendirin

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

Bir JavaScript SEO değişikliğini doğrulayın

JavaScript’ten önce rota içeriğinin var olduğunu kanıtlayın

Çalıştırılacak test: Temsilî rotaları curl ile getirin ve yanıt gövdesini inceleyin. Beklenen sonuç: Her yanıt kendi benzersiz başlığını, ana başlığını, metnini ve taranabilir bağlantılarını içerir. Başarısızlık yorumu: Dağıtım hâlâ ortak bir uygulama kabuğu sunuyor. İzleme penceresi: Anında. Geri alma tetikleyicisi: Daha önce sunucuda görünen bir rota oluşturulmaya bağımlı hâle gelir.

Yönergelerin işleme aşamaları arasında uyuştuğunu kanıtlayın

Çalıştırılacak test: robots ve canonical etiketleri için ham HTML’yi URL Inspection’ın oluşturulmuş HTML’siyle karşılaştırın. Beklenen sonuç: Her iki yerde de amaçlanan tek bir yönerge kümesi görünür; ham kabukta daha kısıtlayıcı bir değer bulunmaz. Başarısızlık yorumu: JavaScript bir dizine ekleme sinyalini çok geç geçersiz kılmaya çalışıyor. İzleme penceresi: Yerel oluşturmada anında; Search Console’da yeniden taramadan sonra. Geri alma tetikleyicisi: Her iki aşamada da noindex veya yanlış bir canonical görünür.

Bağlantıların taranabilir kaldığını kanıtlayın

Çalıştırılacak test: JavaScript’i devre dışı bırakın ve temsilî rotalara giden gezinmeyi inceleyin. Beklenen sonuç: Hedefler gerçek bağlantı href özniteliklerinde kalır. Başarısızlık yorumu: Keşfi bağlantılar değil, istemci işleyicileri yönetiyor. İzleme penceresi: Anında. Geri alma tetikleyicisi: Betikler başarısız olduğunda önemli rotalar bağlantı grafiğinden kaybolur.

Zaman ayırmaya değer kaynaklar

İlgili yazılarım

• JavaScript SEO: Kesin Rehber — oluşturma, DOM eşliği, en kısıtlayıcı yönerge kuralı, sonsuz kaydırma ve iki sayfanın tek sayfa olması sorununa dair tam rehberim. Bu makale, kaynak bağlantıları bulunan kısaltılmış sürümdür.
• Teknik SEO için Başlangıç Rehberi — JavaScript SEO’nun daha büyük resme oturduğu yer.

Konuşmalarım

• How Search Works (SlideShare) — tarama, oluşturma, 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

• r/TechSEO — oluşturma/dizine ekleme sorunlarını hata ayıklama topluluğu.
• web.dev — Web’de oluşturma — Chrome ekibinden oluşturma ödünleşimlerinin temel açıklaması.
• Google Search Central — JavaScript SEO — üç aşamalı süreç, taranabilir bağlantılar ve oluşturulmuş HTML’yi test etme hakkında resmî birincil kaynak belgeleri.
• Onely — JavaScript SEO hub — uzman bir ajansın oluşturma, iki dalgalı dizine ekleme ve JS SEO denetimi üzerine derin teknik yazıları.
• Martin Splitt’in JavaScript SEO oynatma listesi — Google’ın web ekosistemi ekibi tarafından hazırlanmış, her JS SEO kavramını anlatan resmî Google video serisi.
• Search Engine Journal — JavaScript SEO kapsamı — JS oluşturma sorunları ortaya çıktıkça sektör haberleri ve uygulamacı rehberleri.

Podcast’ler

• Search Off the Record (Google Search Relations) — Martin Splitt, John Mueller ve Gary Illyes JavaScript SEO ile oluşturmayı düzenli olarak içeriden ele alır. Dinle

Videolar

• Google Search Central (YouTube) — Martin Splitt’in JavaScript SEO serisi, Google’ın 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 2026-03-04 tarihinde güncellediği kendi belgeleri, taranmış bir 200 sayfasını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 ve 200 olmayan bir durum döndüren ya da başlangıçta noindex taşıyan sayfalar oluşturmayı bütünüyle atlayabilir. Alıntıya git
• 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ı anlattı — eski korkunun ima ettiği “haftalar” değildi. Buna JavaScript SEO rehberimde yer veriyorum. Bunu o konuşmadan kalma tarihsel bir veri noktası olarak ele alın, güncel yayımlanmış bir ölçüm olarak değil — Google bunu devam eden bir değer olarak yeniden yayımlamadı ve yukarıdaki kuyruk zamanlaması alıntısı güncel resmî çerçevedir.
• Martin Splitt’e göre “dizine eklemenin iki dalgası” zayıflıyor (2019 açıklamaları). Splitt, John Mueller ile Ağustos 2019’da yaptığı bir konuşmada, oluşturma ucuzladıkça ve tarama, oluşturma ve dizine ekleme yakınsadıkça iki dalgalı dizine eklemenin “play[s] less and less of a role” (terjemahan) “giderek daha az rol oynadığını” söyledi — bunun tamamen ne zaman sona ereceğine dair bir zaman çizelgesi vermedi. Kapsam Bu, belirli bir konuşmadaki Splitt yorumudur; tarihli, alıntılanabilir bir Google spesifikasyonu değildir — bunu güncel bir garanti değil, yönlendirici bağlam olarak kullanın.

Google JavaScript uygulamalarını tarama, oluşturma ve dizine ekleme aşamalarından geçirir. Evidence for this claim Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Scope: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Bağlantılar href özniteliğine sahip anchor öğeleri olduğunda genel olarak onları tarar. Evidence for this claim Google can reliably discover links only when they are HTML anchor elements with an href attribute. Scope: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Confidence: high · Verified: 2026-07-14 Google Search Central: Make your links crawlable Google, sunucu tarafı oluşturmayı veya önceden oluşturmayı kullanıcılar ve tarayıcılar için iyi bir fikir olarak tanımlar. Evidence for this claim Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Scope: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Google Arama ayrıca içeriği tetiklemek için sayfayla etkileşime girmez. Evidence for this claim Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Scope: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix lazy-loaded content

Değişiklik günlüğü