JavaScript SEO sorunlarını tespit etmek için kullanıcının tarayıcıda gördüğü sayfayı, sunucunun ilk yanıtta gönderdiği HTML'i ve Google'ın render ettiği çıktıyı karşılaştırın. Ana içerik, iç bağlantılar, canonical, robots direktifleri veya yapılandırılmış veri bu çıktılardan birinde kayboluyor ya da değişiyorsa sorunun hangi aşamada oluştuğunu kanıtlayabilirsiniz.
Bir sitenin React, Vue, Angular veya başka bir JavaScript altyapısı kullanması tek başına SEO problemi değildir. Teşhis edilmesi gereken durum, önemli bir SEO sinyalinin JavaScript nedeniyle keşfedilememesi, eksik render edilmesi veya çelişkili hale gelmesidir. Bu rehber, genel bir teknik SEO audit anlatmak yerine bu farkı nasıl bulacağınızı ve geliştiriciye doğrulanabilir bir bulgu olarak nasıl aktaracağınızı açıklar.
JavaScript kullanan her site SEO sorunu yaşar mı?
Hayır. Google, JavaScript çalıştırabilir ve render edilmiş HTML'deki içeriği indeksleyebilir. Google'ın JavaScript SEO dokümanında açıkladığı süreç tarama, render ve indeksleme aşamalarından oluşur. İlk HTML yanıtında bulunmayan içerik, sayfa render edildikten sonra Google tarafından görülebilir.
Risk, kritik içeriğin JavaScript'e bağımlı olmasından çok bu bağımlılığın güvenilir çalışmamasıdır. Engellenen bir kaynak, başarısız API isteği, kullanıcı etkileşimi bekleyen bileşen veya ilk ve son HTML arasında değişen indeks direktifi, sayfanın tarayıcıda düzgün görünmesine rağmen Google'a eksik ulaşmasına neden olabilir.
Bu nedenle “İçerik kaynak HTML'de yok” bulgusu tek başına hata değildir. İçerik Google'ın render edilmiş HTML çıktısında bulunuyor ve indekslenebiliyorsa yalnızca bir render bağımlılığı tespit etmiş olursunuz. Sorun tanısı koymak için bağımlılığın görünürlük veya keşif kaybı oluşturduğunu ayrıca göstermek gerekir.
Teşhise üç farklı sayfa çıktısıyla başlayın
JavaScript SEO incelemesinde aynı URL'nin üç farklı çıktısı karşılaştırılır. Bu çıktılar aynı sayfaya ait olsa da aynı bilgileri taşımayabilir.
| Çıktı | Ne gösterir? | Nereden incelenir? |
|---|---|---|
| İlk HTML yanıtı | JavaScript çalışmadan önce sunucunun gönderdiği içerik ve SEO sinyalleri | Sayfa kaynağı veya doğrudan HTTP yanıtı |
| Tarayıcı DOM'u | JavaScript çalıştıktan sonra kullanıcının tarayıcısında oluşan belge yapısı | Tarayıcı geliştirici araçlarındaki Elements bölümü |
| Google render çıktısı | Googlebot ve Web Rendering Service çalıştıktan sonra Google'ın erişebildiği HTML, kaynaklar ve ekran görüntüsü | Search Console URL Denetimi veya Zengin Sonuçlar Testi |
İlk HTML yanıtı ile tarayıcı DOM'u arasındaki fark, hangi öğelerin JavaScript tarafından eklendiğini gösterir. Tarayıcı DOM'u ile Google render çıktısı arasındaki fark ise kullanıcının gördüğü ancak Google'ın göremediği öğeleri ortaya çıkarır. Teşhis açısından daha kritik olan ikinci farktır.
Hangi belirtiler JavaScript sorununa işaret eder?
JavaScript incelemesine yalnızca sitede JavaScript bulunduğu için başlanmamalıdır. Önce görünür bir belirti belirleyin ve bu belirtinin JavaScript dışında hangi nedenlerden kaynaklanabileceğini de hesaba katın.
| Belirti | Olası JavaScript nedeni | Kontrol edilmesi gereken diğer nedenler |
|---|---|---|
| Kullanıcı içeriği görüyor, Google indekslemiyor | Ana içerik Google render çıktısında oluşmuyor | İçerik kalitesi, canonical, noindex, kopya sayfa veya düşük iç link desteği |
| Sitemap'teki URL'ler crawler tarafından bulunamıyor | İç bağlantılar yalnızca JavaScript olayıyla çalışıyor | Yetim sayfalar, eksik navigasyon veya hatalı sitemap |
| Ürün ya da yazı listelerinin devamı keşfedilmiyor | Sonsuz kaydırma gerçek URL ve HTML bağlantısı üretmiyor | Sayfalama, canonical veya robots kuralları |
| Search Console soft 404 bildiriyor | SPA hata sayfası sunucudan 200 yanıtı alıyor | Zayıf ya da boş içerik, yanlış yönlendirme veya sunucu yapılandırması |
| Başlık veya canonical beklenenden farklı | JavaScript ilk sinyali sonradan değiştiriyor | CMS şablonu, eklenti çakışması veya Google'ın başlık seçimi |
| Schema tarayıcıda var, test aracında yok | JSON-LD üreten kod çalışmıyor veya gecikiyor | Geçersiz işaretleme ya da görünür içerikle uyumsuz veri |
Örneğin “Tarandı, şu anda dizine eklenmiş değil” durumu doğrudan JavaScript hatası anlamına gelmez. Bu durumun bütün olası nedenleri tarandı fakat dizine eklenmedi hatası rehberinde ayrı olarak değerlendirilir. JavaScript incelemesi, yalnızca render veya keşif farkı kanıtlandığında bu teşhisin parçası olur.
Test edilecek URL örneklerini doğru seçin
Tek bir URL'nin düzgün render edilmesi bütün sitenin sorunsuz olduğunu göstermez. JavaScript problemleri çoğunlukla sayfa şablonuna, bileşene veya veri kaynağına bağlıdır. Bu nedenle önemli her şablondan en az bir temsilci URL seçin.
- Ana sayfa
- Hizmet veya kategori sayfası
- Ürün ya da ilan detay sayfası
- Blog yazısı
- Sayfalama veya sonsuz kaydırma kullanan liste
- Filtre ya da arama sonucu gibi dinamik URL
Belirti yalnızca belirli bir sayfa grubunda görülüyorsa örneklemi o şablonda yoğunlaştırın. Bir ürün sayfasındaki hata tekil bir içerik problemiyken bütün ürün şablonunda tekrarlanan hata binlerce URL'yi etkileyebilir. Bulgunun URL'ye mi, bileşene mi yoksa şablona mı ait olduğunu ayırmak uygulama önceliğini değiştirir.
Ham HTML ile tarayıcı DOM'unu karşılaştırın
İlk kontrol, SEO açısından önemli öğelerin sayfa kaynağında bulunup bulunmadığını belirlemektir. Tarayıcıdaki “Sayfa kaynağını görüntüle” seçeneği sunucunun ilk HTML yanıtını; geliştirici araçlarındaki Elements bölümü ise JavaScript çalıştıktan sonraki DOM'u gösterir.
Aynı öğeyi iki çıktıda da arayın. Karşılaştırmada yalnızca kelime sayısına bakmak yerine şu sinyalleri kontrol edin:
- Sayfanın H1 başlığı ve ana metni
- Ürün adı, fiyat, stok veya hizmet açıklaması gibi ana bilgiler
- Diğer sayfalara giden gerçek bağlantılar
- Title ve meta description
- Canonical ve robots direktifleri
- Yapılandırılmış veri
- Görsel adresleri ve alternatif metinleri
- Sayfalama ve devam bağlantıları
Ana içerik ilk HTML'de yok ancak DOM'da bulunuyorsa sayfa JavaScript render'ına bağımlıdır. Bu durumun sorun olup olmadığını anlamak için bir sonraki adımda Google'ın çıktısını kontrol etmek gerekir. DOM'da da bulunmayan öğe ise SEO probleminden önce kullanıcı tarafındaki uygulama veya veri yükleme sorununa işaret eder.
Google'ın render ettiği HTML'i inceleyin
Search Console URL Denetimi içindeki canlı test, Google'ın URL'yi nasıl aldığını ve render ettiğini kontrol etmek için temel araçtır. Google'ın JavaScript sorun giderme dokümanı, URL Denetimi veya Zengin Sonuçlar Testi üzerinden render edilmiş HTML'in, yüklenen kaynakların ve JavaScript hatalarının incelenmesini önerir.
Canlı test tamamlandığında şu kontrolleri yapın:
- Render edilmiş ekran görüntüsünde ana içerik ve sayfanın temel bileşenleri görünüyor mu?
- Render edilmiş HTML içinde H1, ana metin ve kritik ürün ya da hizmet bilgileri bulunuyor mu?
- İç bağlantılar beklenen hedeflerle ve gerçek
hrefdeğerleriyle oluşmuş mu? - Canonical, robots ve yapılandırılmış veri beklenen biçimde mi?
- Yüklenemeyen JavaScript, CSS, görsel veya API kaynağı var mı?
- Konsol çıktısında ana bileşenlerin çalışmasını durduran hata bulunuyor mu?
Canlı test ile Google'ın daha önce indekslediği sürüm aynı anı temsil etmez. Canlı test bugünkü çıktıyı, indeks bilgisi ise Google'ın son işlediği sürümü gösterebilir. Bu nedenle yeni düzeltilmiş bir sayfada iki görünümün hemen eşleşmemesi mümkündür. Test tarihini ve son tarama zamanını kayda ekleyin.
İç bağlantıların gerçekten taranabildiğini doğrulayın
Kullanıcının tıklayabildiği her öğe Google açısından bağlantı değildir. Tarama ve URL keşfi için bağlantının uygun bir <a> öğesi ve erişilebilir bir href değeri taşıması gerekir. Yalnızca onclick olayıyla yönlendirme yapan düğmeler, önemli sayfaları kullanıcıya açarken crawler için güvenilir bir keşif yolu oluşturmayabilir.
Menü, ürün kartı, kategori bağlantısı, sayfalama ve “daha fazla yükle” bileşenlerindeki hedefleri hem ilk HTML'de hem de Google render çıktısında arayın. Bir URL yalnızca sitemap'te bulunuyor ancak site içindeki bağlantılarla keşfedilemiyorsa sorun JavaScript bağlantı yapısından veya bilgi mimarisinden kaynaklanabilir.
Tek sayfa uygulamalarında her önemli içerik görünümünün ayrı ve doğrudan açılabilir bir URL'si olmalıdır. #/urunler gibi fragment tabanlı görünümler yerine tarayıcıda doğrudan açıldığında aynı içeriği döndüren gerçek URL'ler kullanılmalıdır.
Lazy loading ve kullanıcı etkileşimini test edin
Googlebot sayfadaki içeriği ortaya çıkarmak için kullanıcı gibi kaydırma, tıklama veya izin verme davranışına güvenmez. İçerik yalnızca kullanıcı hareketinden sonra yükleniyorsa Google'ın render ettiği HTML'de bulunmayabilir.
Bu risk özellikle sonsuz kaydırma, sekmeler, akordeonlar, “daha fazla göster” düğmeleri ve istemci tarafında yüklenen ürün listelerinde görülür. Her içerik parçasının mutlaka ilk HTML'de bulunması gerekmez; ancak görünür olması gereken noktaya gelindiğinde kullanıcı etkileşimine ihtiyaç duymadan yüklenebilmesi ve önemli sayfa kümelerinin gerçek bağlantılarla keşfedilebilmesi gerekir.
Google'ın lazy-loaded içerik rehberi, önemli içeriğin kaydırma veya tıklama gibi kullanıcı hareketlerine bağlı kalmamasını önerir. Sonsuz kaydırmada ayrıca her içerik bölümünün doğrudan erişilebilir URL'sini ve sıralı bağlantılarını kontrol edin.
Canonical ve robots sinyallerinin değişip değişmediğini kontrol edin
JavaScript yalnızca görünen metni değil, canonical ve robots gibi indeksleme sinyallerini de değiştirebilir. İlk HTML yanıtında ve render edilmiş HTML'de farklı canonical adresleri bulunması, Google'a sayfanın asıl sürümü hakkında çelişkili bilgi verir.
Daha kritik örnek, ilk HTML yanıtında noindex bulunması ve JavaScript'in bunu daha sonra index olarak değiştirmesidir. Google, ilk noindex direktifini gördüğünde sayfayı render kuyruğuna almadan işlemeyi bırakabilir; JavaScript ile yapılan değişiklik hiç görülmeyebilir. İndekslenmesi gereken sayfalarda temel direktifleri ilk yanıtta doğru ve tutarlı sunmak daha güvenlidir.
Canonical sorununu yalnızca etiketin varlığıyla değerlendirmeyin. Canonical hedefinin 200 yanıtı verdiğini, indekslenebilir olduğunu, sitemap ve iç bağlantı sinyalleriyle çelişmediğini de kontrol edin. Canonical kararlarının ayrıntıları canonical etiketi yanlış kullanıldığında oluşabilecek sorunlar içeriğinde ele alınır.
Durum kodlarını ve SPA hata sayfalarını inceleyin
Tek sayfa uygulamalarında sunucu, var olmayan URL'lere de uygulama kabuğunu ve 200 durum kodunu gönderebilir. JavaScript daha sonra kullanıcıya “sayfa bulunamadı” mesajı gösterse bile Google sunucu tarafında başarılı yanıt görür. Bu yapı soft 404, gereksiz indekslenme ve tarama israfı oluşturabilir.
Var olmayan bir ürün, kategori ve rastgele oluşturulmuş URL ile test yapın. Gerçekten bulunmayan içerik sunucu düzeyinde 404 veya 410 yanıtı vermeli ya da uygun durumda güvenilir bir noindex sinyali taşımalıdır. Kullanıcıya gösterilen hata mesajı ile HTTP durum kodunu ayrı ayrı kontrol edin.
Yönlendirmeler için de aynı yaklaşım geçerlidir. JavaScript ile tarayıcı tarafında yapılan yönlendirme yerine mümkün olduğunda sunucu tarafında doğru 3xx durum kodu kullanılmalıdır. Böylece kullanıcı ve crawler aynı hedefe açık bir HTTP sinyaliyle ulaşır.
Engellenen kaynakları ve veri isteklerini araştırın
Google ana HTML dosyasına ulaşsa bile sayfayı oluşturan JavaScript veya CSS kaynaklarına erişemiyorsa eksik render oluşabilir. robots.txt kuralları, CDN güvenlik ayarları, kimlik doğrulama, coğrafi kısıtlar ve başarısız API istekleri bu farkın yaygın nedenleridir.
URL Denetimi ve tarayıcı geliştirici araçlarında aşağıdaki durumları arayın:
- 403, 404 veya 5xx yanıtı veren JS, CSS ve API istekleri
- robots.txt tarafından engellenen gerekli kaynaklar
- İçeriği oluşturmak için oturum, çerez veya local storage bekleyen bileşenler
- Yalnızca kullanıcı izni verildiğinde çalışan özellikler
- Uzun süren veya zaman aşımına uğrayan veri istekleri
- Eski JavaScript dosyasının önbellekten gelmesine neden olan sürümleme sorunları
Google'ın Web Rendering Service ortamında çerezler ve tarayıcı depolama verileri sayfa yüklemeleri arasında korunmaz. Ana içeriğin bunlara bağımlı olması tutarsız sonuç oluşturabilir. Kritik veri WebSocket veya benzeri bir bağlantıyla geliyorsa HTTP üzerinden erişilebilir bir alternatif de değerlendirilmelidir.
Site genelinde JavaScript açık ve kapalı taramayı karşılaştırın
Tekil URL testleri sorunun biçimini gösterir; site taraması ise yaygınlığını belirler. Screaming Frog, Sitebulb veya benzer bir crawler ile aynı örnek URL kümesini önce metin tabanlı, sonra JavaScript render açık biçimde tarayabilirsiniz.
İki tarama arasında şu değerleri karşılaştırın:
| Karşılaştırma alanı | Aranacak fark | Olası anlam |
|---|---|---|
| Keşfedilen URL sayısı | JavaScript taramasında çok daha fazla URL bulunması | İç bağlantıların önemli bölümü render'a bağımlı olabilir. |
| Metin ve başlıklar | Ana içerik yalnızca render sonrasında oluşuyor | İçerik render başarısına bağımlıdır. |
| İç bağlantı sayısı | Ham taramada bağlantıların eksik kalması | Keşif ve iç link sinyalleri gecikebilir veya kaybolabilir. |
| Canonical ve robots | İki taramada farklı değerler görülmesi | JavaScript indeksleme kararını değiştiriyor olabilir. |
| Yapılandırılmış veri | İşaretlemenin yalnızca render sonrasında bulunması | Uygulama çalışmadığında veya geciktiğinde veri kaybolabilir. |
| Durum ve hata sayfaları | Var olmayan URL'lerin 200 dönmesi | SPA kaynaklı soft 404 riski vardır. |
Büyük bir siteyi doğrudan tam JavaScript taramasına almak yerine önce temsilci URL listesiyle başlayın. Bulgu belirli bir şablonda doğrulanırsa taramayı o şablonun kapsamına genişletin. Bu yöntem hem kaynak kullanımını azaltır hem de binlerce yüzeysel uyarı yerine tekrarlanabilir problemi ortaya çıkarır.
Bulgunun gerçekten JavaScript kaynaklı olduğunu kanıtlayın
Bir JavaScript SEO bulgusu, yalnızca ekran görüntüsüne veya crawler uyarısına dayanmamalıdır. Sağlam bir teşhis üç parçadan oluşur:
- Beklenen durum açıkça tanımlanır. Örneğin kategori şablonundaki ürün bağlantılarının crawler tarafından keşfedilmesi gerekir.
- Görülen fark tekrar üretilebilir. Bağlantılar tarayıcı DOM'unda bulunurken Google render çıktısında yer almıyordur.
- SEO etkisi ilgili veriyle desteklenir. Alt ürün URL'leri site taramasında keşfedilemiyor veya Googlebot erişimi beklenen şablona ulaşmıyordur.
Bu üç parçadan biri eksikse bulguyu kesin hata yerine araştırılması gereken risk olarak kaydedin. Özellikle ham HTML ile render edilmiş HTML arasındaki her farkı sorun olarak sınıflandırmayın. JavaScript'in amacı zaten belgeyi değiştirmektir; SEO açısından önemli olan, gerekli içeriğin ve sinyallerin Google'a tutarlı biçimde ulaşıp ulaşmadığıdır.
JavaScript SEO bulgusunu geliştiriciye nasıl aktarmalısınız?
“Google içeriği göremiyor” açıklaması geliştiricinin sorunu tekrar üretmesi için yeterli değildir. Bulgu, hangi şablonun hangi koşulda ne ürettiğini gösterecek biçimde yazılmalıdır.
| Alan | Yazılacak bilgi |
|---|---|
| Etkilenen yapı | Şablon, bileşen veya URL grubu |
| Örnek URL | Sorunun tekrar üretilebildiği tam adres |
| Beklenen çıktı | Google'ın görmesi gereken içerik, bağlantı veya direktif |
| Görülen çıktı | Ham HTML, DOM ve Google render sonuçları arasındaki fark |
| Kanıt | Test tarihi, araç, HTML parçası, ekran görüntüsü veya hata kaydı |
| Muhtemel neden | Engellenen kaynak, başarısız API, etkileşim bağımlılığı veya sinyal değişimi |
| Beklenen düzeltme | Tek bir teknoloji dayatmadan ulaşılması gereken teknik sonuç |
| Yeniden test ölçütü | Düzeltmenin başarılı sayılması için görülmesi gereken çıktı |
Örneğin “Kategori kartları JavaScript kullanıyor” yerine şu bulgu daha uygulanabilirdir: “Kategori şablonundaki ürün bağlantıları tarayıcı DOM'unda oluşuyor; ancak test tarihinde alınan URL Denetimi canlı çıktısının render edilmiş HTML bölümünde bulunmuyor. Google'ın ürün URL'lerini keşfedebileceği gerçek bağlantıların kullanıcı etkileşimi gerektirmeden render çıktısında yer alması bekleniyor.”
Bu örnek bir bulgu yazım biçimidir; gerçek bir siteye ait sonuç gibi kullanılmamalıdır. Yayınlanacak vaka veya performans iddiası, ilgili URL ve test verisiyle doğrulanmalıdır.
Her render sorununda SSR kullanmak gerekir mi?
Hayır. Çözüm, sorunun nerede oluştuğuna göre belirlenmelidir. Gerçek bağlantı yerine JavaScript olayı kullanılması yalnızca bağlantı bileşeninin düzeltilmesini gerektirebilir. Engellenen kaynak robots.txt veya CDN ayarıyla çözülebilir. Ana içeriğin tamamı istemci tarafındaki başarısız veri isteğine bağlıysa sunucu tarafında render, statik üretim veya uygun hydration yaklaşımı değerlendirilebilir.
Google, dynamic rendering yöntemini uzun vadeli bir çözüm olarak önermiyor; bunu geçici bir yöntem olarak tanımlıyor ve sunucu tarafında render, statik render veya hydration seçeneklerine yönlendiriyor. Bu nedenle botlara ayrı HTML üretmek otomatik çözüm olarak sunulmamalıdır. Google'ın dynamic rendering açıklaması güncel çözüm sınırını açıkça belirtir.
Teknik öneri hazırlanırken uygulamanın altyapısı, içerik değişim sıklığı, önbellek yapısı, geliştirme maliyeti ve kullanıcı deneyimi birlikte değerlendirilmelidir. SEO bulgusu hangi çıktının eksik olduğunu kanıtlar; mimari çözüm geliştirme ekibiyle bu kanıta göre belirlenir.
Düzeltme sonrasında aynı testi yeniden çalıştırın
Görevin tamamlanma ölçütü kodun yayına alınması değil, beklenen çıktının Google tarafından görülebilmesidir. Düzeltmeden sonra ilk teşhiste kullanılan örnek URL'leri ve aynı kontrol sırasını yeniden uygulayın.
- Sunucunun ilk HTML yanıtını yeniden alın.
- Tarayıcı DOM'unda ana içerik ve bağlantıları kontrol edin.
- URL Denetimi canlı testini çalıştırın.
- Render edilmiş HTML, ekran görüntüsü ve kaynak hatalarını yeniden inceleyin.
- JavaScript açık ve kapalı crawler sonuçlarını karşılaştırın.
- Sorunun görüldüğü diğer şablon örneklerini test edin.
İndeks ve performans değişimleri teknik doğrulamadan daha geç görülebilir. Bu nedenle önce Google'ın doğru çıktıyı alabildiğini kanıtlayın, ardından tarama, indekslenme ve organik performans verisini izleyin. Aynı anda çok sayıda değişiklik yapıldıysa hangi düzenlemenin sonucu etkilediğini ayırmak zorlaşır; bulguları şablon ve değişiklik bazında kaydetmek bu nedenle önemlidir.
JavaScript SEO teşhisi kanıtla tamamlanır
Doğru JavaScript SEO incelemesi, kullanılan framework'ü suçlamakla başlamaz. Önce kullanıcı, sunucu ve Google çıktıları arasındaki fark belirlenir; ardından bu farkın içerik, bağlantı veya indeks sinyali kaybına neden olup olmadığı doğrulanır.
Ham HTML, tarayıcı DOM'u ve Google render çıktısı aynı kritik bilgileri taşıyorsa JavaScript kullanımı tek başına problem değildir. Bu çıktılardan biri eksikse etkilenen şablon, tekrar üretme koşulu ve SEO etkisi birlikte kaydedilmelidir. Böylece teknik SEO değerlendirmesi, genel bir hata listesi yerine geliştiricinin uygulayabileceği ve sonrasında yeniden doğrulanabilecek bulgular üretir.
