Artık Google’a Ajax sitelerini taramak için güvenebilir misiniz??

Özet:

14 Ekim’de Google, 2009’da yayınladıkları Ajax tarama planını artık önermediklerini açıkladı. Bu, bir Ajax sitesini başarılı bir şekilde taramak ve endekslemek için Google’a güvenip güvenemeyeceğiniz sorusunu gündeme getirir.

Anahtar noktaları:

1. Web tasarımcıları ve mühendisleri, Angular ve React gibi çerçevelerle tek sayfalık uygulamalar (SPA) oluşturmak için Ajax’ı kullanmayı tercih ediyor.
2. Ajax, masaüstü uygulamaları gibi performans gösteren pürüzsüz, etkileşimli web uygulamalarına izin verir.
3. Bir spada, HTML içeriği başlangıçta tarayıcıya yüklenmez. Bunun yerine Ajax, web sunucusuyla dinamik olarak iletişim kurmak ve HTML’yi oluşturmak için javascript kullanır.
4. Google bazı JavaScript içeriğini tarayabildi, ancak Pure Spa Ajax siteleri için SEO zorluklar yarattı.
5. 2009 yılında Google, Google’ın sayfanın tam HTML ile önceden oluşturulmuş bir sürümünü getirmesini talimat vermek için “Kaçan Parçalı” URL’leri veya meta etiketleri kullanmayı içeren Ajax Cwrawlable Solution’ı tanıttı.
6. Google’ın JavaScript’i tarama yeteneğine rağmen, Google’ın spa ajax sitelerini taramasına izin veren birçok site sınırlı başarı yaşadı.
7. Bazı siteler, Ajax uygulamasına geçtikten sonra organik trafikte önemli bir düşüş gördü.
8. 14 Ekim’de Google, artık eski Ajax tarama tekliflerini önermediklerini açıkladı, ancak yine de destekliyorlar.
9. Google’ın artık Ajax sitelerini sorunsuz bir şekilde sürünebileceğine dair bir yanlış kanı var, ancak modern tarayıcılar gibi web sayfalarını oluşturma ve anlayabildiklerini belirtmek önemlidir.
10. Google tarafından kullanılan dili düşünmek çok önemlidir ve yalnızca Ajax sayfalarını tam olarak anlayabilecekleri varsayımına güvenmez.

Sorular:

1. Google Ajax sitelerini başarıyla dizine ekleyebilir?
2. Ajax’ı web tasarımında kullanmanın amacı nedir?
3. Bir spa başlangıçta yüklendiğinde ne olur?
4. SEO ile ilgili olarak Ajax siteleri tarihsel olarak ne gibi zorluklar var??
5. Ajax’ı tarar hale getirmek için 2009 yılında Google tarafından önerilen yöntemler nelerdi??
6. Google’ın AJAX sitelerini taramasına izin verdi mi, birçok web sitesi için başarılı bir dizin oluşturmaya neden oldu?
7. Ajax’ı uyguladıktan sonra bazı siteler ne olumsuz etkileri yaşadı??
8. Google, 14 Ekim’de Ajax tarama tavsiyeleri hakkında ne duyurdu??
9. Google’ın artık Ajax sitelerini etkili bir şekilde tarayabileceğine inanmak doğru mu??
10. Google’ın dilini duyurusunda düşünmek neden önemlidir??
11. Ajax sitenizi tam olarak anlaması ve taraması için Google’a güvenebilir misiniz??
12. Web tasarımcıları ve mühendisler AJAX’ı oluştururken Web uygulamalarında nasıl kullanıyor??
13. Bir Ajax sitesinin oluşturma sürecinde JavaScript’in rolü nedir??
14. Neden bazı web siteleri bir çözüm olarak önceden oluşturulmuş HTML anlık görüntülerine başvurdu??
15. Google’ın Ajax sitelerini tarama yeteneği hakkında ne yanlış anlama var?

Yanıtlar:

1. Google Ajax sitelerini tarayabilir, ancak endekslemenin başarısı değişir ve garanti edilmez.
2. Ajax, web tasarımında, özel masaüstü uygulamalarına benzer pürüzsüz ve etkileşimli bir kullanıcı deneyimi sağlayan tek sayfalık uygulamalar (SPA) oluşturmak için kullanılır.
3. Başlangıçta bir spa yüklendiğinde, HTML içeriği getirilmez ve oluşturulmaz. Bunun yerine, tarayıcı sunucu ile iletişim kurmak için JavaScript’e güvenir ve HTML’yi dinamik olarak oluşturur.
4. Tarihsel olarak, Ajax siteleri SEO ile zorluklarla karşılaştı çünkü Google’ın JavaScript içeriğini sürdürme yeteneği sınırlıydı. Bu, sayfaları etkili bir şekilde endeksleme ve sıralamada zorluklara yol açtı.
5. 2009 yılında Google, Ajax’ı taramak için iki yöntem önerdi. Biri, çirkin url’lerle sonuçlanan “kaçan parça” url’lerini kullanan. Diğer yöntem bir Meta = “fragman” Google’a tam HTML ile önceden oluşturulmuş bir sürümü getirmesini öğretmek için sayfada etiketleyin.
6. Google’ın Ajax sitelerini taramasına izin vermek, her zaman birçok web sitesi için başarılı bir dizin oluşturmaya yol açmadı. Bazı siteler sayfalarının sadece bir kısmını tam olarak işlenmiş ve endekslediler, diğerleri organik trafikte önemli bir düşüş yaşadı.
7. Ajax’ı uyguladıktan sonra, bazı web siteleri organik trafiği üzerinde olumsuz bir etki gördü ve ziyaretçilerdeki düşüşten kurtulmak zorunda kaldı.
8. 14 Ekim’de Google, artık eski Ajax tarama tekliflerini önermediklerini açıkladı, ancak bunu desteklemeye devam ediyorlar. Bu, kullanımını aktif olarak önermedikleri, ancak yine de işlevselliğini kabul ettikleri anlamına gelir.
9. Google’ın artık Ajax sitelerini herhangi bir sorun olmadan etkili bir şekilde sürünebileceğini varsaymak doğru değil. Modern tarayıcılar gibi web sayfalarını oluşturma ve anlayabildiklerini belirtirken, kullanılan dili dikkate almak ve yalnızca bu ifadeye güvenmek önemlidir.
10. Ajax siteleri için kesintisiz indeksleme garantisi vermedikleri için Google’ın dilini açıklamalarında düşünmek önemlidir. “Genel olarak mümkün” ifadesi, Ajax sayfalarını tam olarak anlama ve sürünmedeki sınırlamalar ve zorluklar potansiyelini ima eder.
11. Google’ın bir Ajax sitesini tam olarak anlamak ve taramak için güvenmek, daha fazla test ve izlemeden tavsiye edilmez. Endekslemenin başarısı değişebilir ve ön hazırlama HTML anlık görüntüleri gibi alternatif çözümleri dikkate almak çok önemlidir.
12. Web tasarımcıları ve mühendisler, Ajax’ı Angular ve React gibi çerçevelerle SPA oluşturmak için kullanırlar ve özel masaüstü uygulamalarına benzer etkileşimli ve sorunsuz bir kullanıcı deneyimi sunan web uygulamalarının geliştirilmesini sağlar.
13. JavaScript, bir Ajax sitesinin oluşturma sürecinde önemli bir rol oynar. Kullanıcının etkileşime girmesi için HTML içeriğini oluşturmak ve oluşturmak için web sunucusuyla dinamik olarak iletişim kurar.
14. Angular gibi bazı Ajax çerçeveleri henüz sunucu tarafı oluşturmayı desteklemediği için web siteleri bir çözüm olarak HTML anlık görüntülerine başvurdular. Ön hazırlama, arama motorlarına sunulan, tam indeksleme ve görünürlük sağlayan HTML anlık görüntülerinin oluşturulmasına izin verir.
15. Google’ın Ajax sitelerini tarama yeteneğinin artık kusursuz olduğuna dair bir yanlış kanı var. Bununla birlikte, JavaScript içeriğini anlama ve tarama yeteneklerinin geliştiğini, ancak zorlukların ve sınırlamaların hala var olabileceğini belirtmek önemlidir.

Artık Google’a Ajax sitelerini taramak için güvenebilir misiniz?

Ve sonra, 14 Ekim’de Google şöyle dedi:

Google Ajax içeriğini tarar mı? [kapalı]

Bu soruyu geliştirmek istiyorum? Soruyu, yalnızca bu yayını düzenleyerek bir soruna odaklanacak şekilde güncelleyin.

7 yıl önce kapalı .

Sitemin ana sayfasında, kullanıcıların son etkinliklerinin bir listesini çekmek için JQuery’nin Ajax işlevini kullanıyorum. Son etkinlik sayfada görüntülenir ve son etkinliğin her satırı, etkinliği yapan kullanıcının kullanıcı profiline bir bağlantı içerir. Google aslında bu bilgiyi aşağı çekmek ve sayfa alaka düzeyini hesaplamak için kullanacak / bağlantı suyu akışını kullanacak mı?? Bunu umuyorum değil Kullanıcı profili sayfaları çok Google dizinine layık olmadığından ve ana sayfamın bağlantı suyu akışını diğer önemli bağlantılardan uzaklaştıran kullanıcı profili sayfalarına tüm bu bağlantıları istemiyorum.

Artık Google’a Ajax sitelerini taramak için güvenebilir misiniz??

14 Ekim’de Google, 2009’da yayınladıkları Ajax tarama planını artık önermediğini açıkladı. Köşe yazarı Mark Munroe, bunun bir Ajax sitesini başarılı bir şekilde taramak ve endekslemek için Google’a güvenebileceğiniz sorusuna dalmaktadır.

13 Kasım 2015 tarihinde Mark Munroe, 09:18 | Okuma Süresi: 7 Dakika

Web tasarımcıları ve mühendisleri, Angular ve React gibi popüler çerçevelerle tek sayfalık uygulamalar (SPA) oluşturmak için Ajax’ı seviyor. Pure Ajax uygulamaları.

Bir spa ile genellikle, HTML içeriği web sayfasının ilk getirisinde tarayıcıya yüklenmez. Ajax, sayfayı oluşturmak ve kullanıcı ile etkileşim kurmak için html oluşturmak için web sunucusuyla dinamik olarak iletişim kurmak için javascript kullanır. (Denilen bir teknik var “Sunucu tarafı oluşturma” JavaScript’in aslında sunucuda yürütüldüğü ve sayfa isteği oluşturulan HTML ile döndürülür. Bununla birlikte, bu yaklaşım henüz tüm SPA çerçevelerinde desteklenmez ve kalkınmaya karmaşıklık katar.)

SPA AJAX siteleriyle ilgili sorunlardan biri SEO oldu. Google aslında bir süredir bazı JavaScript içeriğini sürünüyor. Aslında, bu son test dizisi Google’ı onayladı’s JavaScript aracılığıyla eklenen bağlantıları, meta verileri ve içeriği tarama yeteneği. Ancak, Pure Spa Ajax çerçevelerini kullanan web siteleri, SEO ile tarihsel olarak zorluklar yaşadı.

2009 yılında Google, Ajax’ı taramak için bir çözüm buldu. Bu yöntem ya yaratır “Kaçan Parça” URL’ler (Çirkin URL’ler) veya daha yakın zamanda, URL’leri bir Meta =”fragman” Sayfadaki etiket.

Kaçan Parçalı URL veya Meta Fragment Etiketi, Google’a tüm JavaScript’i yürütmüş olan ve Google’ın ayrıştırabileceği ve dizine ekleyebileceği tam HTML’ye sahip olan sayfanın önceden oluşturulmuş bir sürümünü almasını söyler. Bu yöntemde, örümcek tamamen farklı bir sayfa kaynak kodu sunar (html vs. JavaScript).

Google’ın JavaScript’i taradığı sözüyle, birçok site Google’ın SPA AJAX sitelerini taramasına izin vermeye karar verdi. Genel olarak, bu çok başarılı olmadı. Geçen yıl, Ajax Angular uygulaması olan birkaç web sitesine danıştım. Google’ın biraz başarılı oldu ve Google’daki sayfaların yaklaşık yüzde 30’u’s önbellek tamamen oluşturuldu. Diğer yüzde 70’i boştu.

Google’ın onu sürünebileceğine inanarak açısal olan popüler bir gıda sitesi. Organik trafiğinin yaklaşık yüzde 70’ini kaybettiler ve hala bu felaketten kurtuluyorlar. Nihayetinde, her iki site de ön plana çıkma HTML anlık görüntülerine gitti, o zaman önerilen Ajax tarama çözümü.

Ve sonra, 14 Ekim’de Google şöyle dedi:

Artık 2009’da yaptığımız Ajax tarama teklifini önermiyoruz.

Hala olduklarını unutmayın destekleyici Onların eski teklifleri. (Artık onu desteklemediklerini açıklayan bazı makaleler var, ancak bu doğru değil – artık bu yaklaşımı önermiyorlar.)

Eski tavsiyeden ötürü, şimdi Ajax’ı tarayabileceklerini söylüyorlardı.

Sonra, duyurudan sadece bir hafta sonra, yeni başlatılan bir siteye sahip bir müşteri, kontrol etmemi istedi. Bu açısal bir siteydi, yine bir spa ajax uygulaması.

Google’ı inceledikten sonra’S index ve önbelleği, tüm içerikler taranmadan kısmen dizinlenmiş bazı sayfalar gördük. HTML anlık görüntülerini veya aşamalı geliştirmeyi kullanma önerimi tekrarladım.

Bu site, sunucu tarafı oluşturmayı henüz desteklemeyen açısal olarak oluşturulmuştur (yine, bu durumda, sunucu başlangıçta HTML belgesini sunmak için bir sayfa oluşturur), bu nedenle ilerici geliştirmenin desteklenmesi zor olur ve HTML anlık görüntüleri hala en iyi çözümdür.

O cevap verdi, “Ama neden? Okuduğum her şey bana Google’ın Ajax’ı tarayabileceğini söylüyor.”

Yapabilirler mi? İzin vermek’S ajax ile ilgili yeni tavsiyeye daha derin bir şekilde bak.

Google’S Yeni Ajax Önerileri

Neden eski tavsiyeden kullanımdan kaldırıldıklarını açıklarken, (benim maddesi vurgu) diyorlar:

Biz Genellikle Modern tarayıcılar gibi web sayfalarınızı oluşturmak ve anlamak için.

Birçok insan şimdi Ajax’ı sorunsuz bir şekilde sürünebilecekleri sonucuna varabilir. Ama dile bakın: “Genellikle”? Google’ın olduğu bilgisine iş gelirinize bahse girer misiniz? “Genellikle” Sayfanızı anlamak için?

Sadece anlambilim seçiyor muyum? İzin vermek’duyuruyu daha fazla inceleyin. Daha sonra duyurusunda Ajax ile ilgili olarak belirtiyorlar:

2009 teklifimizin varsayımları artık geçerli olmadığından, ilerici geliştirme ilkelerini takip etmenizi öneririz.

Yapmıyorlar’t duyurularında heceleyin, ancak aşamalı geliştirme önererek (’t Destek JavaScript), dolaylı olarak diyorlar, “Giymek’Javascript’inizi sürünerek bize güvenin.” Gerçekten Google Spa Ajax sitelerini sürekli olarak tarayabilirse neden bu yöntemi öneririz?

Belki Google’ı aşırı analiz ettiğimden endişelendim’S kelimeleri, ama sonra…

John Mueller, Google’ın Ajax ile hala sorun yaşadığını doğruladı

27 Ekim’de (Google duyurusundan iki haftadan kısa bir süre sonra), Web Yöneticisi Central Hangout’unda John Mueller, Google’ın Ajax ile hala sorunları olduğunu doğruladı.

Değişimi saat 1: 08:00 civarında, belirli bir açısal uygulamayla ilgili bir sorunun bulunduğu videoya görüntüleyebilirsiniz:

Hala oluşturma konusunda sorun yaşıyorlar ve zamanla daha iyi olmayı bekliyorlar. John, sorunların hata ayıklamasına yardımcı olacak bazı eylemler öneriyor.

Nihayetinde, Google Ajax’ta daha iyi hale gelene kadar HTML anlık görüntülerini kullanmayı önerdi (evet, resmen kullanımdan kaldırılmış yöntem).

Öyleyse ne yapmalı?

• Aşamalı geliştirme. Aşamalı geliştirme için sunucu tarafı oluşturma gerekecek ve henüz açısal tarafından desteklenmiyor. Ancak, yaklaşan açısal 2.0 sunucu tarafı oluşturmayı destekleyecek. React, aslında bugün sunucu tarafı oluşturmayı destekliyor. Ancak bu, sadece HTML anlık görüntüleri oluşturmaktan daha fazla iş. Google’ın sayfaya yüklenen ek içeriği tarayabilmesi ve endeksleyebilmesi için gerekli bağlantıları oluşturduğunuzdan emin olmanız gerekir. Bununla birlikte, bir Ajax çerçevesi kullanan siteler için bu benim önerilen yaklaşım olurdu. (Ve elbette Google’Önerilen yaklaşım.)
• HTML ön görüntüleri. Yine Don’Google’ın artık bu yöntemi desteklemediğini duymuş veya okuduysanız kafanız karışır. Öngörülebilir gelecek için desteklemeye devam edecekler. Artık tavsiye etmiyorlar. Bu yöntem çalışır; Ancak, ön render için kodu yazmak ve anlık görüntüleri sunmak önemsiz değildir. İyi haber şu ki, prerender gibi birkaç satıcı var.İşi sizin için nispeten düşük bir maliyetle yapacak. Muhtemelen en basit yaklaşım budur. Bu yöntem ideal değil. Trawlers VS’ye farklı kaynak kodu sunmak. tarayıcılar (html vs. Javascript) sorunlu olabilir. Bir gizleme tekniği olarak düşünülebilir ve botların ne sunulduğu açık değildir. BT’Google’ı izlemek önemli’yanlış sayfa sunulmadığından emin olmak için s önbellek. Bununla birlikte, sunucu tarafı oluşturmayı desteklemeyen bir platform kullanıyorsanız, bu tek çözümünüz olabilir.

Eşeği sağlam kazığa bağlamak

Google’ın Ajax sitelerini sürekli olarak süründüğüne dair kanıt görsem bile, yine de dikkatli olurum. Bir sayfayı tam olarak oluşturmak için çok daha fazla kaynak ve çok daha fazla zaman gerektirir.

Yüz binlerce veya milyonlarca sayfaya sahip sitelere ne olacak? Tarama bütçesini nasıl etkileyecek? Tarama oranı tutarlı kalacak mı?

Bu yaklaşımı önermeden önce’D Google’ın tarama oranı, endeksleme ve sıralamalar üzerinde olumsuz etkisi olmayan büyük, saf Ajax tek sayfalık uygulamaları sürekli olarak sürünebileceğine ve sürdürebileceğine dair güçlü kanıtlar görün. Lütfen kendi deneyimlerinizi paylaşın.

Bu makalede ifade edilen görüşler konuk yazarın görüşleridir ve Mutlak Arama Arazisi Mutlaka Değil. Personel yazarları burada listelenmiştir.

JavaScript ve Ajax Google’da Dizinlemeyi Nasıl Etkiler??

Zamanla Google, JavaScript ve Ajax indekslenmesi. Başlangıçta’t herhangi bir şeyi dizin veya bu çerçevelerden yüklenen içerik içinde görünen bağlantıları izledi. Ama sonra, yavaş yavaş, bazı uygulamaları endekslemeye ve yeteneklerini iyileştirmeye başladı. Günümüzde, birçok farklı uygulamayı dizine ekleyebilir, ve yüklenen bağlantıları takip edin Ajax veya API Getir. Yine de, Hala yapamayacağı durumlar olacak.

Google’ın sitemizi dizine eklemeyeceği durumları analiz etmek için önce İstemci tarafı oluşturma (KSS). Bunu ima ediyor HTML, javascript ile istemci tarafı boyalı, Genellikle kullanıyor Ajax fazla. Başlangıçta, web siteleri her zaman html sunucu tarafını boyadı (Sunucu tarafı oluşturma veya SSR), ama bir süredir, CSR, Angular, React ve Vue gibi JavaScript çerçevelerinin gelişiyle popüler hale geldi. Fakat, CSR indekslemeyi olumsuz etkiler, Web sitesi oluşturma performansı ve sonuç olarak SEO.

Biz’daha önce açıklanmış, Tüm arama motorlarında ve durumlarda indekslemeyi sağlamak için, iyi performans elde etmenin yanı sıra, En iyi çözüm evrensel bir çerçeve kullanmaktır, Bu önlemlerde olduğu gibi, Melez oluşturma. İçinden oluşuyor Web sitesini ilk yükte sunucuda ve ardından JavaScript ve Ajax aracılığıyla istemcide, navigasyon izleyen bağlantılara geçerken boyamak. Her ne kadar, gerçekte, hibrit oluşturma teriminin kullanımının da geçerli olduğu daha fazla durum var.

Bazen geliştirme şirketi KSS kullanır ve’T bize evrensel bir çerçeve kullanma seçeneğini sunmak. Bu CSR tabanlı web geliştirme bizi belaya sokacak, daha fazla veya daha az derecede, Paletli ve sıralama algoritmalarına bağlı olarak. Bu yazıda analiz edeceğiz Google ile ilgili bu sorunlar’S praw.

Bir sayfanın ilk yükü sırasında CSR sorunları

İlk olarak, gerçekleşen endeksleme problemlerini analiz edeceğiz Web sitesinin dışında bir URL girer girmez, ve html javascript ile istemci tarafı oluşturulduğunda.

Yavaş oluşturma sonucunda sorunlar

Google’S indeksleme işlemi aşağıdaki adımlardan geçer:

1. Emekleme: GoogleBot sunucuya bir URL ister.
2. İlk indeksleme dalgası: Sunucuda boyanmış içeriği anında dizine ekler ve tarama için yeni bağlantılar alır.
3. JavaScript’i çalıştırarak HTML boyalı istemci tarafını oluşturur. Bu süreç hesaplamalı maliyetlidir (şu anda yapılabilir veya birkaç gün sürebilir, hatta bunu yapmak için gerekli kaynakları elde etmek için bekleyebilir).
4. İkinci indeksleme dalgası: HTML boyalı istemci tarafı ile kalan içerik dizine eklenir ve taranması gereken yeni bağlantılar elde edilir.

Yanı sıra Sayfaların tamamen dizin yapılması daha uzun sürebilir, böylece bir sayfanın oluşturulması yavaşsa, onlardan bağlantılı sonraki sayfaların dizine eklenmesini geciktirebilir, GoogleBot’S Renderer boyasız parçaları bırakabilir. Biz’bunu seçeneğini kullanarak test etti “Google olarak getir” Google Arama Konsolu tarafından sağlanan, ve ürettiği ekran görüntüsü’t 5 saniyeden daha uzun süren herhangi bir şeyi görüntülenmek. Ancak, 5 saniyeden daha uzun süren HTML’yi üretir. Bunun neden olduğunu anlamak için, Google Arama Konsolu’S Renderer ilk olarak googlebot ile javascript çalıştıran html’yi oluşturur’S Renderer ve sonra sayfayı boyar’s piksel. İlk görev, CSR terimine atıfta bulunduğumuz endeksleme için dikkate alınması gereken görevdir. Google Arama Konsolu’nda, Googlebot tarafından oluşturulan ilk dizin dalgası sırasında oluşturulan HTML’yi görebiliriz’Sinverer.

Google arama konsolunda, googlebot tarafından çalıştırılan ve son dizinleme aşamasında kullanılan JavaScript tarafından boyanmış HTML’yi göremiyoruz. Bunu yapmak için şu aracı kullanmalıyız: https: // Ara.google.com/test/mobil dostu �� Tweet’e tıklayın

Testlerde biz’ve HTML renderliği 19 saniyeden fazla sürdüğünde yürütüldü,’herhangi bir şeyi endeksle. Bu uzun bir süre olsa da, bazı durumlarda, özellikle Ajax’ı yoğun bir şekilde kullanırsak ve bu durumlarda Google’S Renderer, tıpkı herhangi bir oluşturucu gibi, aşağıdaki adımların gerçekleşmesini beklemek zorundadır:

1. HTML indirildi ve işlendi Bağlantılı dosyalar istemek ve DOM oluşturmak için.
2. CSS indirildi ve işlendi, Bağlantılı dosyalar istemek ve CSSOM oluşturmak için.
3. Javascript İndirildi, Ajax isteklerini başlatmak için derlenmiş ve çalıştırılmış.
4. Ajax isteği bir istek kuyruğuna taşındı, Talep edilen diğer dosyalarla birlikte yanıtlanmayı bekliyorum.
5. Ajax isteği başlatıldı ve ağdan sunucuya seyahat etmek zorunda.
6. Sunucu, isteklere ağ üzerinden yanıt verir ve son olarak, Sayfanın içeriğini boyamak için JavaScript’in çalıştırılmasını beklemeliyiz’S html şablonu.

Az önce tarif ettiğimiz işlemin isteği ve indirme süreleri, o zaman boyunca ağ ve sunucu yüküne bağlı. Dahası, GoogleBot yalnızca HTTP/1 kullanır.1, HTTP/2’den daha yavaş olan, çünkü istekler birbiri ardına ele alınır ve aynı anda değil. BT’Hem istemcinin hem de sunucunun HTTP/2’nin kullanılmasına izin vermesi gerekir, bu yüzden GoogleBot yalnızca HTTP/1 kullanır.1, sunucumuz HTTP/2’ye izin verse bile. Özetlemek gerekirse, bu, Googlebot’un bir sonrakini başlatmak için her isteğin bitmesini beklediği anlamına gelir ve’Mümkün kazanıldı’T tarayıcıların yaptığı gibi çeşitli bağlantılar açarak belirli istekleri paralelleştirmeye çalışın (olmasına rağmen’tam olarak nasıl yaptığını biliyorum). Bu nedenle, bir durumdayız Daha önce tahmin ettiğimiz bu 19 saniyeyi aşabiliriz.

Örneğin, görüntüler, CSS, JavaScript ve Ajax istekleri ile 200’den fazla istek başlatıldığını ve her biri 100 ms alarak hayal edin. Ajax istekleri kuyruğun arkasına gönderilirse, biz’Muhtemelen ll İçeriklerinin endekslenmesi için gerekli süreyi aşmak.

Öte yandan, bu KSS performans sorunları nedeniyle, PagePeed’de FCP (ilk içerikli boya) metriği için render ve WPO’su açısından daha kötü bir işaret alacağız ve sonuç olarak daha kötü sıralamalar.

İndeksleme Sorunları:

İçeriğin boyalı istemci tarafını dizine eklerken, GoogleBot, JavaScript tarafından oluşturulan HTML’nin indekslenmesini önleyecek aşağıdaki sorunlarla karşılaşabilir:

• Bir kullanırlar JavaScript sürümü paletli değil’T tanıyın.
• Bir kullanırlar JavaScript API Googlebot tarafından tanınmıyor (şu anda Web soketleri, WebGL, WebVR, indexedDB ve WebSQL’i desteklemiyor – https: // geliştiriciler adresinden daha fazla bilgi verilmiyor.google.com/arama/dokümanlar/kılavuzlar/oluşturma).
• JavaScript dosyaları robotlar tarafından engellenir.txt.
• Web sitesi HTTPS kullanırken JavaScript dosyaları HTTP aracılığıyla sunulur.
• JavaScript var hatalar.
• Uygulama talep ederse kullanıcı izni bir şeyler yapmak ve üzerinde ana içeriğin oluşturulmasına bağlıdır, kazandı’t boya alın, çünkü Googlebot herhangi bir izni reddetti’varsayılan olarak istenir.

Bu sorunlardan herhangi birinden muzdarip olup olmadığımızı öğrenmek için Google’ı kullanmalıyız’S Mobil Dostu Test. Bize Google Arama Konsolu’na benzer şekilde bir sayfanın ekranda nasıl boyandığına dair bir ekran görüntüsü gösterecek, ancak aynı zamanda bize Oluşturucu tarafından oluşturulan html kodu (daha önce belirtildiği gibi), JavaScript kodundaki hataların günlük kayıtları, Ve JavaScript özellikleri, oluşturucunun henüz yorumlayamayacağı. Web sitemizdeki her bir sayfa şablonunu temsil eden tüm URL’leri test etmek için bu aracı kullanmalıyız, web sitesinin endekslenebilir olduğundan emin olmak için.

Bunu aklınızda bulundurmalıyız HTML önceki araç tarafından üretildi, hepsi meta veriler (kanonik url dahil) Googlebot tarafından göz ardı edilecek, çünkü yalnızca bilgiyi dikkate alırken’sunucuda boyanmış.

Sonraki sayfada gezinme ile ilgili CSR sorunları

Şimdi izin ver’Bir kez gezinmek için bir bağlantı kullandığımızda ne olacağını görün’Zaten web sitesinde ve HTML istemci tarafı boyanmış.

İndeksleme Sorunları

İlk yük sırasında KSS’nin aksine, Bir sonraki sayfada gezinme JavaScript aracılığıyla ana içeriği değiştirme SSR’den daha hızlı. Ama biz’Aşağıdakiler varsa dizinleme sorunları var

• Bağlantılar Don’T geçerli bir URL’si var Href özniteliği.
• Sunucu, URL’ye doğrudan, JavaScript olmadan veya JavaScript etkinken ve tüm önbellekleri silme ile bir hata döndürür. Buna dikkat edin: Bir bağlantıya tıklayarak sayfaya gidersek, görünüşe göre görünebilir’s çalışıyor, çünkü JavaScript tarafından yüklendi. Doğrudan erişirken bile, web sitesi bir hizmet çalışanı kullanıyorsa, web sitesi önbelleğini yükleyerek doğru bir yanıtı simüle edebilir. Ancak Googlebot, vatansız bir tarayıcıdır, neden olmasının nedeni’T herhangi bir sunucu çalışanı önbelleğini veya yerel depolama veya oturum depolama gibi diğer herhangi bir JavaScript teknolojisini dikkate alın, böylece bir hata alacaktır.

Ayrıca, web sitesinin erişilebilir olması için, URL’nin JavaScript kullanarak değişmesi gerekir Tarih API.

Google’ın Ajax’ı dizine ekleyebileceği parçalarda ne oluyor?

Parçalar, sonunda bir karma # ‘dan önce görünebilen bir URL’nin bir parçasıdır. Örneğin:

http: // www.insanlık seviyesi.com/blog.html#örnek

Bu tür URL’ler asla sunucuya ulaşmaz, Yalnızca müşteri tarafı yönetilirler. Bu, yukarıdaki URL’yi sunucuya talep ederken, talebi alacağı anlamına gelir “http: // www.insanlık seviyesi.com/blog.HTML”, ve istemcide tarayıcı, atıfta bulunulan belgenin parçasına kaydırır. Bu, bu URL’ler için yaygın ve başlangıçta amaçlanan kullanımdır, yaygın olarak bilinir HTML Ankrajları. Ve bir çapa, gerçekte herhangi bir bağlantıdır ( “A” HTML’deki etiket geliyor Çapa). Ancak eski günlerde, Ajax yüklü sayfalarda JavaScript aracılığıyla URL’leri değiştirmek için parçalar da kullanıldı, Kullanıcının göz atma geçmişinde gezinmesine izin vermek niyetinde. Bu şekilde uygulandı, çünkü o zamanlar parça, URL’nin JavaScript kullanarak değiştirebileceğimiz tek kısmıydı, bu yüzden geliştiriciler bunları kullanmak için bundan faydalandı’T Amaçlı. Bu, tarih API’sının gelişiyle değişti, çünkü JavaScript aracılığıyla tüm URL’nin değiştirilmesine izin verdi.

Google olmadığında’T index ajax, bir URL, parçalı bölüme dayanarak Ajax aracılığıyla içeriğini değiştirdiyse, sadece parçayı dikkate almadan url ve içeriği dizine ekleyeceğini biliyorduk. Öyleyse… Google Ajax’ı dizine ekleyebileceğine göre parçalara sahip sayfalara ne oluyor? Davranış tamamen aynı. Bir sayfayı bir parça ile bağlarsak ve parçadan erişildiğinde içeriğini değiştirirse, parçayı görmezden gelen içeriği dizine ekler ve popülerlik bu URL’ye gidecektir, Çünkü Google, parçanın bir çapa olarak kullanılacağına ve içeriği değiştirmek için kullanılmayacak şekilde kullanılacağına güveniyor.

Ancak Google, şu anda bir Hashbang (#!). Bu, ünlem işaretini basit ekleyerek veya patlama, Ve Google, Ajax’ı endekslenebilir hale getirmek için eski bir spesifikasyonla geriye dönük uyumluluğu korumak için çalıştıracak. Ancak bu uygulama önerilmez, çünkü şimdi tarih API’sı ile uygulanmalıdır ve ayrıca, Google aniden Hashbang URL’lerini her zaman endekslemeyi durdurabilir.

Ajax aracılığıyla kısmi yanıtların endekslenmesini engellemek

Ne zaman Ajax İstek gönderildi Bir dinlenme veya grafiğin url’leri, Biz’yeniden döndü Json veya bir sayfa parçası yapmıyoruz’dizin olmasını istemiyorum. Bu nedenle yapmalıyız Bu isteklerin yönlendirildiği URL’lerin indekslenmesini engelleyin.

Gün içinde robotları kullanarak onları engelleyebiliriz.txt, Ama Googlebot’tan beri’S Renderer var, HTML boyamak için kullanılan herhangi bir kaynağı engelleyemeyiz.

Şu anda Google biraz daha akıllı ve değil’T genellikle JSONS ile yanıtları endekslemeye çalışın, ancak yapmadıklarından emin olmak istiyorsak’d indekslenin, Tüm arama motorları için geçerli olan evrensel çözüm, Ajax ile kullanılan tüm URL’leri yalnızca posta yöntemi aracılığıyla yapılan istekleri kabul etmek için yapmaktır, Çünkü değil’T tarayıcılar tarafından kullanılır. Bir GET isteği sunucuya ulaştığında, 404 hatası döndürmelidir. Programlama açısından,’T bizi parametreleri URL’den kaldırmaya zorlayın’SNESSTRING.

HTTP ekleme olasılığı da var “X-Robots-Tag: Noindex” Başlık (Google tarafından icat edildi) AJAX yanıtlarına veya bu yanıtların 404 veya 410 ile döndürülmesini sağlamak için. Bu teknikleri doğrudan HTML’den yüklenen içerik üzerinde kullanırsak, kazandı’tıpkı robotlardan bloke etmiş gibi endekslenin.txt dosyası. Fakat, verildiğinde’s javascript resim sayfadaki yanıtı resim, Google değil’t Bu yanıt ile JavaScript Boyama İçeriği Boyama arasında bir ilişki kurun, Yani tam olarak beklediğimiz şeyi yapıyor. Ve yani: kısmi yanıtı dizin değil ve oluşturulan HTML’yi tamamen indeksleyin. Buna dikkat edin, çünkü bu davranış bir gün değişebilir ve bu tekniği uygularsak tüm içeriğimiz Ajax aracılığıyla yüklenir.

Çözüm

Google artık JavaScript ve Ajax’ı dizine ekleyebilir, ancak kaçınılmaz olarak bir Sunucuda halihazırda işlenmiş HTML indeksleme için daha yüksek maliyet. Bu, SSR’nin bir süredir en iyi seçenek olduğu ve olmaya devam edeceği anlamına gelir. Bir CSR web sitesi ile uğraşmaktan başka alternatifiniz yoksa, tamamen veya kısmen, şimdi bunu nasıl yapacağınızı biliyorsunuzdur.