JavaScript SEO: Google JavaScript Sayfalarını Nasıl İşler?

Biz Talha Aslan ve ekibi olarak teknik denetimlerde en çok bu noktada sürpriz yaşıyoruz. Örneğin tarayıcıda kusursuz görünen bir ürün listesi, Google'ın gördüğü ilk HTML içinde neredeyse boş olabiliyor. Bu rehberde JavaScript SEO konusunu Google'ın resmi belgelerine dayanarak adım adım anlatıyoruz. Ayrıca Search Console'daki URL Denetleme aracıyla Google'ın gördüğü sayfayı nasıl kontrol edeceğinizi gösteriyoruz.

Google JavaScript sayfasını hangi üç aşamada işler?

Google, JavaScript SEO temelleri belgesinde süreci üç ana aşamaya ayırıyor: tarama (crawling), işleme (rendering) ve dizine ekleme (indexing). Bu ayrım önemlidir, çünkü her aşamada farklı bir hata türü ortaya çıkar. Dolayısıyla sorunu doğru aşamaya bağlamadan çözüm de bulamazsınız.

• Tarama: Googlebot adrese istek gönderir, sunucunun döndürdüğü ham HTML'i alır ve robots.txt kurallarını kontrol eder.
• İşleme: Google, sayfadaki JavaScript kodunu güncel bir Chromium tabanlı ortamda çalıştırır ve ortaya çıkan DOM yapısını oluşturur.
• Dizine ekleme: Google, render sonrası HTML içindeki metni, linkleri ve etiketleri değerlendirir, sonra sayfayı dizine alıp almayacağına karar verir.

Kısacası tarayıcıda gördüğünüz sayfa ile Google'ın ilk aldığı yanıt aynı şey değildir. Arada bir işleme adımı vardır ve bu adım hem zaman hem kaynak gerektirir. Bu yüzden JavaScript SEO çalışmasının özü, iki sürüm arasındaki farkı küçültmektir.

Tarama aşamasında Googlebot ilk olarak neyi görür?

Googlebot ilk istekte yalnızca sunucunun döndürdüğü ham HTML'i alır. Bu HTML içinde başlık, meta etiketleri, linkler ve metin hazır geliyorsa Google sayfayı daha ilk bakışta anlar. Öte yandan içerik tamamen tarayıcıda oluşuyorsa ham HTML çoğu zaman boş bir kapsayıcı ve birkaç dosya referansından ibaret kalır.

Tarama aşamasında Googlebot önce robots.txt dosyasına bakar. Adres engelliyse Google o sayfaya hiç istek göndermez, dolayısıyla işleme adımına da geçmez. Ardından ham HTML içindeki href değerlerini çıkarır ve bulduğu yeni adresleri tarama kuyruğuna ekler. Bu nedenle linklerin ilk HTML'de bulunması keşfi hızlandırır.

Örnek senaryo: example.com adlı bir mağazanın kategori sayfası, ürün kartlarını bir API çağrısıyla sonradan getiriyor. Bu durumda Googlebot ilk taramada ürün adlarını da ürün linklerini de göremez. Ürünler ancak işleme tamamlandığında ortaya çıkar. Bu gecikme, yeni ürünlerin keşfini doğrudan yavaşlatır.

İşleme (render) kuyruğu nedir ve neden gecikme yaratır?

Google'ın resmi belgesine göre Googlebot, 200 HTTP durum koduyla yanıt veren sayfaları işleme için kuyruğa alır. Ancak robots meta etiketi ya da başlığı sayfanın dizine eklenmemesini söylüyorsa Google bu adımı atlayabilir. Google kuyruktaki sayfayı, kaynakları uygun olduğunda işler; bu bekleme süresi her site için farklıdır.

Google bu bekleme için sabit bir süre açıklamıyor. Dolayısıyla "Google JavaScript'i kaç saniyede işler" sorusuna sağlam bir rakam veremeyiz. Bilinen tek şey, işlemenin taramadan ayrı bir adım olduğu ve sayfanın hangi aşamada beklediğinin dışarıdan her zaman belli olmadığıdır.

Pratikte bunun anlamı şudur: kritik içeriği ve linkleri JavaScript'e bıraktığınızda keşif ve dizine ekleme bir adım daha uzar. Haber, kampanya ya da stok gibi hızlı değişen içeriklerde bu farkı daha belirgin hissedersiniz. Ayrıca işleme sırasında hata alan bir betik, içeriğin tamamen eksik kalmasına yol açabilir.

Dizine ekleme aşamasında render sonrası HTML neden belirleyicidir?

Google sayfayı işledikten sonra dizine ekleme kararını render sonrası HTML üzerinden verir. Yani sıralamaya aday olan sürüm, kullanıcının tarayıcısında açılan son hal değil, Google'ın işleme ortamında oluşan haldir. Bu iki sürüm çoğu zaman aynıdır; fakat zaman aşımı, engelli dosya ya da hatalı kod farkı büyütebilir.

Google ayrıca render sonrası HTML içindeki linkleri de yeniden çıkarır ve yeni bulduğu adresleri taramaya gönderir. Böylece JavaScript ile eklenen linkler de keşfedilebilir. Yine de bu keşif ikinci turda gerçekleşir. Kısacası Google'ın kesin olarak göreceği tek şey, işleme sonunda DOM içinde gerçekten bulunan içeriktir.

Dizine eklenmeyen sayfaların genel teşhisi bu yazının konusu değil. Bunun için indexlenmeyen sayfaları Search Console ile tespit etme rehberimize bakabilirsiniz. Burada yalnızca JavaScript kaynaklı nedenlere odaklanıyoruz.

İstemci tarafı ve sunucu tarafı oluşturma arasındaki fark nedir?

İstemci tarafı oluşturma (client-side rendering, CSR), HTML'in kullanıcının tarayıcısında JavaScript ile oluştuğu yöntemdir. Sunucu tarafı oluşturma (server-side rendering, SSR) ise HTML'i sunucuda hazırlar ve tarayıcıya dolu bir sayfa gönderir. Statik oluşturma (static rendering) sayfaları önceden üretir; hidrasyon (hydration) ise sunucudan gelen HTML'i tarayıcıda etkileşimli hale getirir.

Tablodan çıkan sonuç açık: arama trafiği bekleyen sayfalarda içeriği ilk yanıtta göndermek, JavaScript SEO risklerinin büyük kısmını baştan kaldırır.

Siteniz için hangi oluşturma yöntemi daha uygundur?

Doğru yöntem, sayfanın amacına bağlıdır. Örneğin kullanıcı girişinden sonra açılan bir yönetim paneli arama sonuçlarında yer almayacağı için istemci tarafı oluşturma ile sorunsuz çalışır. Buna karşılık kategori, ürün, hizmet ve blog sayfaları organik trafik taşıdığından içeriği sunucuda ya da derleme sırasında hazırlamak daha güvenlidir.

Vue tabanlı projelerde sunucu tarafı oluşturmanın nasıl kurulduğunu Nuxt ve Vue SSR yazımızda ayrıca anlattık. React ya da başka bir çerçeve kullanıyorsanız da mantık aynıdır: arama için önemli sayfalar ilk yanıtta anlamlı HTML döndürmelidir.

Biz karar verirken üç soru soruyoruz. Birincisi, bu sayfa arama sonuçlarından ziyaretçi bekliyor mu? İkincisi, içerik ne sıklıkla değişiyor? Üçüncüsü, ekip sunucu tarafında kod çalıştırmayı sürdürebilir mi? Bu üç cevabın kesiştiği nokta genellikle doğru yöntemi gösterir. Böylece teknik borcu da baştan sınırlarsınız.

Dinamik oluşturma (dynamic rendering) hâlâ mantıklı mı?

Dinamik oluşturma, botlara sunucuda hazırlanan HTML, kullanıcılara ise JavaScript ağırlıklı sürüm göndermektir. Google dinamik oluşturma belgesinde bu yöntemi önerilen bir çözüm değil, geçici bir çalışma yolu (workaround) olarak tanımlıyor. Gerekçe olarak ek karmaşıklığı ve kaynak ihtiyacını gösteriyor.

Google bunun yerine sunucu tarafı oluşturma, statik oluşturma ya da hidrasyon kullanmanızı öneriyor. Ayrıca dinamik oluşturma tek başına gizleme (cloaking) sayılmıyor; ancak kullanıcıya ve tarayıcıya tamamen farklı içerik sunarsanız bu durum gizleme kapsamına girebilir. Dolayısıyla iki sürümün içeriği birbirine benzer kalmalıdır.

Elinizde eski bir dinamik oluşturma kurulumu varsa hemen kapatmanız gerekmez. Yine de yeni bir projede bu yolu seçmek yerine kalıcı çözümü planlamak daha mantıklıdır. Aksi halde iki ayrı sürümü sürekli eşitlemek zorunda kalırsınız ve hatalar bu eşitleme aralığında ortaya çıkar.

Linkleriniz neden a href biçiminde olmalı?

Google, linkleri yalnızca href özelliği taşıyan a elemanları olarak sağlam biçimde keşfeder. Taranabilir linkler belgesine göre JavaScript ile sonradan eklenen linkler de bu biçimi koruyorsa sorun yaşamazsınız. Sorun, tıklama olayına bağlı ama gerçek bir adres taşımayan öğelerde başlar.

Google'ın belgesindeki örneklere göre önerilen ve önerilmeyen biçimler şöyledir:

• Önerilen: href değeri gerçek bir adres olan a elemanı, örneğin /urunler/ayakkabi/ yolunu gösteren link.
• Önerilen: Hem gerçek href hem de onclick olayı taşıyan a elemanı; tarayıcı olayı çalıştırır, Google adresi izler.
• Önerilmeyen: href olmadan yalnız onclick ile yönlendiren a elemanı.
• Önerilmeyen: span ya da benzeri bir elemana href yazmak veya çerçeveye özel routerLink gibi özellikler kullanmak.
• Riskli: href değerinin javascript: ile başlaması.

Örneğin bir menüdeki kategoriler yalnız düğme olarak kodlanmışsa Google bu kategorilere giden yolu kolay bulamaz. Çözüm basittir: her gezinme öğesine gerçek bir adres verin, ardından tıklama davranışını JavaScript ile yönetin.

Tek sayfalık uygulamalarda URL yapısını nasıl kurmalısınız?

Tek sayfalık uygulamalar (single page application, SPA) farklı görünümleri aynı HTML dosyası içinde değiştirir. Eski yöntemde bu görünümler adresin # işaretinden sonraki parçasıyla ayrılırdı; örneğin example.com/#/urunler gibi. Google, farklı içerik yüklemek için bu parçalara (fragment) güvenmemenizi söylüyor.

Bunun yerine History API kullanmanızı öneriyor. Bu yöntemle her görünüm example.com/urunler/ gibi kendi gerçek adresine sahip olur. Ayrıca linkleri gerçek href ile yazar, gezinmeyi pushState ile yönetirsiniz. Böylece kullanıcı sayfayı yenilediğinde ya da adresi paylaştığında aynı içeriği görür.

Bir de şu kontrolü yapın: her görünümün adresi doğrudan açıldığında sunucu doğru içeriği döndürüyor mu? Bazı kurulumlarda ana sayfa dışındaki adresler doğrudan açılınca boş sayfa ya da hata çıkıyor. Bu durumda Googlebot o adresleri işleyemez, dolayısıyla dizine de ekleyemez.

JavaScript ile eklenen ya da kaldırılan noindex neden çalışmayabilir?

Google'ın resmi açıklamasına göre Google noindex etiketiyle karşılaştığında işleme ve JavaScript çalıştırma adımını atlayabilir. Bu nedenle ham HTML'de noindex bulunan bir sayfada etiketi JavaScript ile kaldırmak beklediğiniz sonucu vermeyebilir. Google sayfayı hiç işlemeden dışarıda bırakabilir.

Ters yön de risklidir. Ham HTML'de noindex yokken JavaScript ile sonradan eklerseniz, Google'ın bunu hangi aşamada göreceği belirsizleşir. Kısacası dizine girmesini istediğiniz sayfaların orijinal kodunda noindex bulunmamalıdır; dizin dışı kalması gereken sayfalarda ise etiketi doğrudan sunucu yanıtına koymalısınız.

Search Console'da bu etiketle ilgili durumu görüyorsanız "noindex etiketi tarafından hariç tutuldu" yazımız durumu adım adım açıklıyor. Burada önemli olan, etiketin kaynağının sunucu mu yoksa betik mi olduğunu ayırt etmenizdir.

Tek sayfalık uygulamalarda soft 404 hatasını nasıl önlersiniz?

Soft 404, aslında bulunamayan bir sayfanın 200 durum koduyla yanıt vermesidir. Tek sayfalık uygulamalarda bu durumla sık karşılaşırsınız, çünkü sunucu her adrese aynı uygulama dosyasını gönderir ve hata mesajını tarayıcıdaki kod gösterir. Google'ın belgesi bu yapıda anlamlı durum kodu vermenin bazen imkânsız ya da pratik olmadığını kabul ediyor.

Google bu durum için iki yol öneriyor:

1. Bulunamayan içerik için kullanıcıyı, sunucunun gerçekten 404 durum kodu döndürdüğü bir adrese JavaScript ile yönlendirmek.
2. Hata görünümüne JavaScript ile noindex robots meta etiketi eklemek.

İkinci yol, yukarıdaki noindex uyarısıyla çelişiyor gibi görünebilir. Ancak burada amaç zaten sayfanın dizine girmemesidir; Google etiketi görürse sayfayı dışarıda bırakır. Bununla birlikte mümkün olduğunda sunucu tarafında gerçek 404 ya da 410 döndürmek her zaman en temiz çözümdür.

Başlık, meta açıklama ve yapısal veriyi JavaScript ile ekleyebilir misiniz?

Evet. Google'ın belgesine göre title elemanını ve meta açıklamayı JavaScript ile ayarlayabilir ya da değiştirebilirsiniz. Benzer şekilde JSON-LD biçimindeki yapısal veriyi de JavaScript ile oluşturup sayfaya ekleyebilirsiniz. Google bu durumda uygulamayı mutlaka test etmenizi öneriyor.

Yine de pratikte bu öğeleri ilk HTML'de göndermek daha az risk taşır. Çünkü sosyal medya önizlemeleri ve bazı başka tarayıcılar JavaScript çalıştırmayabilir. Ayrıca her sayfada aynı başlığın kalması gibi hatalara, istemci tarafında yönlendirme yapan uygulamalarda daha sık rastlıyoruz.

Örnek senaryo: example.com üzerindeki bir SPA, kullanıcı ürün sayfasına geçtiğinde başlığı güncellemeyi unutuyor. Bu durumda tüm ürün sayfaları ana sayfanın başlığını taşıyor. Biz bu tür hataları URL Denetleme aracında render sonrası HTML'e bakarak hızla yakalıyoruz. Bu kontrol birkaç dakika sürer ama büyük kayıpları önler.

robots.txt JavaScript dosyalarını engellerse ne olur?

Google, engellenen dosyalardaki ya da engellenen sayfalardaki JavaScript kodunu işlemiyor. Dolayısıyla sayfanın içeriğini üreten betik dosyası robots.txt ile kapalıysa Google sayfayı işlediğinde içerik eksik kalır. Aynı sonuç, verileri getiren API adresleri engellendiğinde de ortaya çıkar.

Ekipler bu hatayı çoğu zaman iyi niyetle yapar. Örneğin bir ekip, tarama bütçesini korumak için /api/ ya da /assets/ klasörünü kapatır ve sayfa içeriğinin buna bağlı olduğunu fark etmez. Sonuçta tarayıcıda dolu görünen sayfa Google için boş kalır.

Kontrol için URL Denetleme aracında yüklenen sayfa kaynaklarına bakın; engellenen bir kaynak varsa orada görürsünüz. robots.txt dosyasındaki diğer yaygın hataları ise robots.txt hataları yazımızda topladık. Kısacası içeriği üreten hiçbir kaynağı engellemeyin.

URL Denetleme aracında render sonrası HTML'i nerede görürsünüz?

Search Console'daki URL Denetleme Aracı (URL Inspection), Google'ın sayfanızı nasıl gördüğünü kontrol etmenin resmi yoludur. Search Console Yardım sayfasına göre araç, ham HTML'i, HTTP başlıklarını, JavaScript konsolu çıkışını ve yüklenen sayfa kaynaklarını gösterir. JavaScript SEO teşhisinde izleyeceğiniz adımlar şöyledir:

1. Search Console'da ilgili mülkü açın ve üstteki arama kutusuna sayfanın tam adresini yazın.
2. Dizindeki sürümü görmek için "Taranan sayfayı göster" (View crawled page) seçeneğini açın.
3. Güncel hali görmek için "Canlı URL'yi test et" (Test live URL) düğmesini kullanın, ardından "Test edilen sayfayı göster" (View tested page) bölümünü açın.
4. HTML sekmesinde ürün adı, ana metin ve linkler gibi kritik içeriğin bulunup bulunmadığını arayın.
5. Ekran görüntüsünü inceleyin; Yardım sayfasına göre ekran görüntüsünü yalnız canlı testte alırsınız.
6. "Daha fazla bilgi" (More info) bölümünde yüklenemeyen kaynakları ve JavaScript konsolu çıkışını kontrol edin.

Ek yanıt bilgilerini her durumda göremezsiniz. Yardım sayfasına göre dizindeki sürümde bu bilgiler yalnız URL Google'dayken çıkar. Canlı testte ise URL Google'ın erişimine açıksa bu bilgilere ulaşırsınız.

Ham HTML ile render sonrası HTML'i nasıl karşılaştırırsınız?

Karşılaştırmanın amacı, Google'ın işleme sonrası gördüğü içeriğin tarayıcıda gördüğünüzle örtüşüp örtüşmediğini anlamaktır. Önce tarayıcınızda sayfanın kaynak kodunu açın; bu, sunucunun gönderdiği ham HTML'dir. Ardından URL Denetleme aracındaki test edilen sayfanın HTML çıktısına bakın; bu da işleme sonrası haldir.

Biz karşılaştırmada şu öğelere tek tek bakıyoruz:

• Sayfa başlığı ve meta açıklama her iki sürümde de doğru mu?
• Ana metin, ürün adları ve fiyat gibi kritik bilgiler render sonrası HTML'de var mı?
• Canonical ve robots meta etiketleri sunucu yanıtıyla çelişiyor mu?
• Gezinme ve iç linkler href taşıyan a elemanı olarak yer alıyor mu?
• Yapısal veri render sonrası HTML'de eksiksiz yer alıyor mu?

Canonical etiketinin JavaScript ile değiştiği durumlarda Google farklı bir sürümü seçebilir. Bu tür çelişkileri canonical hataları rehberimizde ayrıntılı ele aldık. Karşılaştırmayı her şablon için bir kez yapmanız çoğu zaman yeterlidir.

Önbellek ve dosya parmak izi neden önemlidir?

Google'ın belgesine göre Googlebot, ağ isteklerini ve kaynak kullanımını azaltmak için agresif biçimde önbellekleme yapıyor. Ayrıca işleme hizmeti (Web Rendering Service, WRS) önbellek başlıklarını göz ardı edebiliyor. Bu nedenle Google, sayfanızı eski bir JavaScript ya da CSS dosyasıyla işleyebilir.

Google'ın önerdiği çözüm, içerik parmak izidir (content fingerprinting). Bu yöntemde dosya adına içeriğin özetini eklersiniz; örneğin main.2bb85551.js gibi. Dosya değiştiğinde adı da değişir, böylece Google yeni dosyayı yeni bir kaynak olarak alır. Modern derleme araçlarının çoğu bunu varsayılan olarak yapar.

Örnek senaryo: example.com yeni bir sürüm yayınlıyor, ancak betik dosyasının adı aynı kalıyor. Yeni HTML eski betikle uyuşmadığında işleme sırasında hata çıkıyor ve içerik eksik kalıyor. Dosya adlarını parmak iziyle üretmek bu riski büyük ölçüde ortadan kaldırır.

Googlebot hangi tarayıcı özelliklerini kullanmaz?

Google'ın JavaScript sorun giderme belgesi, Googlebot'un bazı tarayıcı davranışlarını kullanıcı gibi sürdürmediğini belirtiyor. İçeriğiniz bu davranışlara bağlıysa Google onu göremeyebilir. Bu yüzden aşağıdaki maddeleri tasarım aşamasında hesaba katmanız gerekir:

• İzin istekleri: Googlebot kamera gibi izin isteklerini reddeder; içerik izne bağlı olmamalıdır.
• Durum saklama: Yerel depolama, oturum depolama ve HTTP çerezleri sayfa yüklemeleri arasında kalmaz.
• Bağlantı türleri: Googlebot WebSocket ve WebRTC bağlantılarını desteklemez; HTTP ile alternatif yol sunmalısınız.
• Özellik desteği: Örneğin WebGL desteklenmiyor; kritik API'ler için özellik algılama ve yedek çözüm kullanın.
• Web bileşenleri: İşleme sırasında Google ışık ve gölge DOM yapısını birleştirir; slot kullanmayan bileşenlerde içerik kaybolabilir.

Örneğin dil ya da çerez onayı seçimini depolamaya kaydedip içeriği buna göre gösteren bir site, Googlebot'a her seferinde ilk ekranı gösterir. Dolayısıyla ana içerik, hiçbir kullanıcı etkileşimi olmadan da sayfada bulunmalıdır.

Tembel yükleme ve sonsuz kaydırma içeriği gizler mi?

Tembel yükleme (lazy loading), görselleri ve bazı içerikleri kullanıcı onlara yaklaştığında yükler. Google bu yöntemi bant genişliği ve performans için iyi bir strateji olarak görüyor; ancak Google'ın tembel yükleme yönergelerine uymanızı istiyor. Sorun, içeriğin yalnız kaydırma ya da tıklama gibi bir etkileşimle ortaya çıktığı kurulumlarda başlar.

Googlebot sayfada kullanıcı gibi dolaşmaz. Bu nedenle "daha fazla göster" düğmesine bağlı ürünler ya da kaydırınca gelen yorumlar render sonrası HTML'de görünmeyebilir. Çözüm olarak sayfalı listelerde her sayfaya gerçek bir adres verin ve bu adreslere a href ile link verin.

Görsellerde tembel yüklemenin doğru kurulumunu lazy load rehberimizde anlattık. JavaScript'in sayfa hızına etkisini ise JavaScript ve site hızı yazımızda ele aldık. Bu yazıda hız değil, görünürlük üzerinde duruyoruz.

JavaScript SEO hatalarını nasıl kayıt altına alırsınız?

Google'ın sorun giderme belgesi, kullanıcılarda ve Googlebot'ta oluşan JavaScript hatalarını toplamak için genel bir onerror işleyicisi kullanabileceğinizi söylüyor. Ancak aynı belge, ayrıştırma (parse) hatası gibi bazı hata türlerinin bu yöntemle kaydedilemeyeceğini de belirtiyor. Yani bu kayıt yararlı bir ipucudur, eksiksiz bir liste değildir.

Bunun yanında Zengin Sonuçlar Testi (Rich Results Test) ve URL Denetleme aracı da yüklenen kaynakları, JavaScript konsolu çıkışını ve işlenmiş DOM yapısını gösteriyor. Biz düzenli bakımda önce bu araçlara, ardından sunucu günlüklerine bakıyoruz. Böylece hatanın betikten mi yoksa sunucudan mı kaynaklandığını ayırabiliyoruz.

Düzeltmeyi yaptıktan sonra aynı testi yeniden çalıştırın. Google da bu son adımı açıkça öneriyor. Ayrıca sayfanın genel teknik durumuna hızlı bir göz atmak isterseniz SEO analiz aracımızla başlık, meta ve link yapısını kontrol edebilirsiniz.

JavaScript kullanmak SEO açısından zararlı mı?

Hayır, JavaScript kullanmak tek başına SEO açısından zararlı değildir. Google güncel bir Chromium tabanlı ortamla JavaScript kodunu çalıştırır ve modern çerçevelerle kurulan pek çok site aramada sorunsuz yer alır. Sorun dilin kendisinde değil, içeriğin ve linklerin yalnız tarayıcıda ortaya çıkmasında başlar.

Biz denetimlerde JavaScript'i iki gruba ayırıyoruz. Birinci grup, etkileşimi zenginleştiren kodlardır: filtre animasyonu, sepet penceresi, form doğrulama gibi. Bu kodlar genellikle SEO riski taşımaz. İkinci grup ise içeriği ve gezinmeyi üreten kodlardır. Asıl dikkat isteyen bu ikinci gruptur, çünkü Google'ın göreceği metin doğrudan bu kodlara bağlıdır.

Dolayısıyla "JavaScript'i kaldıralım" demek çoğu zaman gereksiz bir karardır. Bunun yerine ana içeriği ilk yanıtta gönderip etkileşimi JavaScript'e bırakmak hem kullanıcı deneyimini hem de görünürlüğü korur. Teknik SEO'nun diğer temel adımlarını ise teknik SEO ipuçları yazımızda topladık.

JavaScript SEO kontrol listesini adım adım nasıl uygularsınız?

Aşağıdaki sırayı her yeni şablon ya da büyük sürüm öncesinde uyguluyoruz. Sıra önemlidir, çünkü ilk adımlardaki bir sorun sonraki adımların sonucunu da bozar.

1. Arama trafiği bekleyen sayfa türlerini listeleyin: ana sayfa, kategori, ürün, hizmet ve blog.
2. Her tür için ham HTML'e bakın; başlık, ana metin ve linkler ilk yanıtta var mı kontrol edin.
3. İçerik ilk yanıtta yoksa sunucu tarafı ya da statik oluşturmaya geçişi planlayın.
4. Tüm gezinme öğelerinin gerçek href taşıyan a elemanı olduğundan emin olun.
5. # ile ayrılan görünümleri History API ile gerçek adreslere taşıyın.
6. robots.txt dosyasında içerik üreten betik ve API adreslerinin açık olduğunu doğrulayın.
7. noindex, canonical ve başlık etiketlerini ham HTML'de doğru biçimde gönderin.
8. Bulunamayan sayfalar için gerçek 404 ya da noindex çözümünü kurun.
9. Dosya adlarında içerik parmak izi kullanın.
10. URL Denetleme aracında canlı test yapın ve render sonrası HTML'i ham HTML ile karşılaştırın.

Tek bir sayfada hızlı kontrol için bir sayfanın SEO kontrolünü 10 dakikada yapma rehberimizden de yararlanabilirsiniz.

JavaScript SEO sorununu sitenizde kim çözer ve takip eder?

JavaScript SEO sorunları çoğu zaman tek bir ayarla kapanmaz. Geliştirme ekibi, içerik ekibi ve SEO tarafının aynı tabloya bakması gerekir. Bu nedenle biz Talha Aslan ve ekibi olarak önce şablon bazında ham ve render sonrası HTML farkını çıkarıyor, ardından geliştiricilere uygulanabilir bir düzeltme listesi veriyoruz.

Düzeltmeler yayına girdikten sonra iş bitmiyor. Search Console verilerinde dizine ekleme durumunu, taranan sayfa sayısını ve işleme hatalarını haftalar boyunca izliyoruz. Bu sürecin kapsamını SEO danışmanlığı hizmet sayfamızda bulabilirsiniz. Sıralama garantisi vermiyoruz; ancak Google'ın sayfanızı eksiksiz görmesi için gereken teknik zemini birlikte kuruyoruz.

Sitenizde benzer bir sorun olduğundan şüpheleniyorsanız birkaç örnek adresle bize ulaşın. Sitenize özel kapsamı ve süreci içeren teklifi SEO danışmanlığı sayfamızdan isteyebilirsiniz. Böylece sorunun JavaScript'ten mi yoksa başka bir teknik nedenden mi kaynaklandığını netleştiririz.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.