Dapatkah Anda sekarang mempercayai Google untuk merangkak situs Ajax?

Ringkasan:

Pada 14 Oktober, Google mengumumkan bahwa mereka tidak lagi merekomendasikan skema perayapan Ajax yang mereka terbitkan pada tahun 2009. Ini menimbulkan pertanyaan apakah Anda dapat mempercayai Google untuk berhasil merangkak dan mengindeks situs AJAX.

Poin -Poin Kunci:

1. Desainer dan insinyur web lebih suka menggunakan AJAX untuk membangun aplikasi satu halaman (SPA) dengan kerangka kerja seperti Angular dan React.
2. AJAX memungkinkan aplikasi web yang halus dan interaktif yang berkinerja seperti aplikasi desktop.
3. Di spa, konten HTML pada awalnya tidak dimuat ke dalam browser. Sebaliknya, AJAX menggunakan JavaScript untuk berkomunikasi secara dinamis dengan server web dan membuat HTML.
4. Google telah dapat merangkak beberapa konten JavaScript, tetapi SEO untuk situs Spa Ajax murni telah menimbulkan tantangan.
5. Pada tahun 2009, Google memperkenalkan solusi Ajax Crawlable, yang melibatkan penggunaan URL “fragmen yang dilarikan” atau tag meta untuk menginstruksikan Google untuk mengambil versi halaman yang pra-render dengan HTML lengkap.
6. Terlepas dari kemampuan Google untuk merangkak javascript, banyak situs yang memungkinkan Google merangkak situs Ajax spa mereka mengalami keberhasilan yang terbatas.
7. Beberapa situs bahkan melihat penurunan yang signifikan dalam lalu lintas organik setelah beralih ke implementasi AJAX.
8. Pada 14 Oktober, Google mengumumkan bahwa mereka tidak lagi merekomendasikan proposal perayapan Ajax lama mereka, tetapi mereka masih mendukungnya.
9. Ada kesalahpahaman bahwa Google sekarang dapat merangkak situs Ajax tanpa masalah, tetapi penting untuk dicatat bahwa mereka menyatakan bahwa mereka “secara umum dapat” membuat dan memahami halaman web seperti browser modern.
10. Sangat penting untuk mempertimbangkan bahasa yang digunakan oleh Google dan tidak hanya mengandalkan asumsi bahwa mereka dapat sepenuhnya memahami halaman AJAX.

Pertanyaan:

1. Bisakah Google berhasil mengindeks situs AJAX?
2. Apa tujuan menggunakan Ajax dalam desain web?
3. Apa yang terjadi saat spa dimuat pada awalnya?
4. Tantangan apa yang dihadapi situs AJAX secara historis berkaitan dengan SEO?
5. Apa metode yang diusulkan oleh Google pada tahun 2009 untuk membuat Ajax merayap?
6. Apakah memungkinkan Google merangkak situs Ajax menghasilkan pengindeksan yang berhasil untuk banyak situs web?
7. Dampak negatif apa yang dialami beberapa situs setelah menerapkan AJAX?
8. Apa yang diumumkan Google pada 14 Oktober tentang rekomendasi merangkak Ajax mereka?
9. Apakah akurat untuk percaya bahwa Google sekarang dapat merangkak situs Ajax secara efektif?
10. Mengapa penting untuk mempertimbangkan bahasa Google dalam pengumuman mereka?
11. Dapatkah Anda mempercayai Google untuk sepenuhnya memahami dan merangkak situs AJAX Anda?
12. Bagaimana desainer dan insinyur web menggunakan AJAX dalam membangun aplikasi web?
13. Apa peran JavaScript dalam proses rendering situs AJAX?
14. Mengapa beberapa situs web menggunakan snapshot HTML pra-render?
15. Kesalahpahaman apa yang ada tentang kemampuan Google untuk merangkak situs Ajax?

Jawaban:

1. Google dapat merangkak situs Ajax, tetapi keberhasilan pengindeksan bervariasi dan tidak dijamin.
2. Ajax digunakan dalam desain web untuk membangun aplikasi satu halaman (SPA) yang memberikan pengalaman pengguna yang lancar dan interaktif mirip dengan aplikasi desktop khusus.
3. Saat spa dimuat pada awalnya, konten HTML tidak diambil dan diterjemahkan. Sebaliknya, browser bergantung pada JavaScript untuk berkomunikasi dengan server dan secara dinamis membuat HTML.
4. Secara historis, situs Ajax menghadapi tantangan dengan SEO karena kemampuan Google untuk merangkak konten javascript terbatas. Hal ini menyebabkan kesulitan dalam halaman pengindeksan dan peringkat secara efektif.
5. Pada tahun 2009, Google mengusulkan dua metode untuk membuat Ajax merayap. Satu yang terlibat menggunakan URL “fragmen yang melarikan diri”, yang menghasilkan URL jelek. Metode lain menggunakan a Meta = “fragmen” Tag pada halaman untuk menginstruksikan Google untuk mengambil versi pra-render dengan HTML lengkap.
6. Mengizinkan Google merangkak situs Ajax tidak selalu menghasilkan pengindeksan yang berhasil untuk banyak situs web. Beberapa situs hanya melihat sebagian dari halaman mereka sepenuhnya diterjemahkan dan diindeks, sementara yang lain mengalami penurunan yang signifikan dalam lalu lintas organik.
7. Setelah menerapkan AJAX, beberapa situs web melihat dampak negatif pada lalu lintas organik mereka dan harus pulih dari penurunan pengunjung.
8. Pada 14 Oktober, Google mengumumkan bahwa mereka tidak lagi merekomendasikan proposal perayapan Ajax lama mereka, tetapi mereka terus mendukungnya. Ini berarti bahwa mereka tidak secara aktif menyarankan penggunaannya tetapi masih mengakui fungsinya.
9. Tidak akurat untuk berasumsi bahwa Google sekarang dapat merangkak situs Ajax secara efektif tanpa masalah. Sementara mereka menyatakan bahwa mereka “umumnya mampu” untuk merender dan memahami halaman web seperti browser modern, penting untuk mempertimbangkan bahasa yang digunakan dan tidak hanya mengandalkan pernyataan ini.
10. Penting untuk mempertimbangkan bahasa Google dalam pengumuman mereka karena mereka tidak memberikan jaminan pengindeksan yang mulus untuk situs AJAX. Ungkapan “umumnya mampu” menyiratkan potensi pembatasan dan tantangan dalam memahami sepenuhnya dan merangkak halaman AJAX.
11. Mempercayai Google untuk sepenuhnya memahami dan merangkak situs AJAX tidak disarankan tanpa pengujian dan pemantauan lebih lanjut. Keberhasilan pengindeksan dapat bervariasi, dan sangat penting untuk mempertimbangkan solusi alternatif seperti pra-rendering snapshot HTML.
12. Desainer dan insinyur web menggunakan AJAX untuk membangun spa dengan kerangka kerja seperti Angular dan React, memungkinkan pengembangan aplikasi web yang menawarkan pengalaman pengguna yang interaktif dan lancar mirip dengan aplikasi desktop khusus.
13. Javascript memainkan peran penting dalam proses rendering situs AJAX. Itu secara dinamis berkomunikasi dengan server web untuk membuat dan membuat konten HTML untuk berinteraksi dengan pengguna.
14. Situs web terpaksa melakukan snapshot HTML pra-rendering sebagai solusi karena beberapa kerangka kerja AJAX, seperti Angular, belum mendukung rendering sisi server. Pra-rendering memungkinkan penciptaan snapshot HTML yang disajikan untuk mesin pencari, memastikan pengindeksan penuh dan visibilitas.
15. Ada kesalahpahaman bahwa kemampuan Google untuk merangkak situs Ajax sekarang sempurna. Namun, penting untuk dicatat bahwa kemampuan mereka untuk memahami dan merangkak konten javascript telah meningkat, tetapi tantangan dan keterbatasan mungkin masih ada.

Dapatkah Anda sekarang mempercayai Google untuk merangkak situs Ajax

Dan kemudian, pada 14 Oktober, Google mengatakan ini:

Apakah Google Crawl AJAX Content? [tertutup]

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga berfokus pada satu masalah hanya dengan mengedit posting ini.

Ditutup 7 tahun yang lalu .

Di halaman beranda situs saya, saya menggunakan fungsi AJAX JQuery untuk menarik daftar aktivitas pengguna terbaru. Aktivitas terbaru ditampilkan pada halaman, dan setiap baris aktivitas terbaru mencakup tautan ke profil pengguna pengguna yang melakukan aktivitas. Akankah Google benar -benar melakukan panggilan AJAX untuk menarik info ini dan menggunakannya dalam menghitung halaman relevansi / link jus aliran? Saya berharap itu tidak Karena halaman profil pengguna tidak terlalu layak Google Index, dan saya tidak ingin semua tautan itu ke halaman profil pengguna yang melemahkan link jus halaman rumah saya mengalir dari tautan lain yang lebih penting.

Dapatkah Anda sekarang mempercayai Google untuk merangkak situs Ajax?

Pada 14 Oktober, Google mengumumkan tidak lagi merekomendasikan skema perayapan Ajax yang mereka terbitkan pada tahun 2009. Kolumnis Mark Munroe menyelami pertanyaan apakah ini berarti Anda sekarang dapat mengandalkan Google untuk berhasil merangkak dan mengindeks situs AJAX.

Mark Munroe pada 13 November 2015 pukul 9:18 pagi | Waktu Membaca: 7 Menit

Desainer dan insinyur web menyukai Ajax untuk membangun aplikasi satu halaman (SPA) dengan kerangka kerja populer seperti Angular dan React. Implementasi AJAX murni dapat memberikan aplikasi web yang mulus dan interaktif yang lebih seperti aplikasi desktop khusus.

Dengan spa, secara umum, konten HTML tidak dimuat ke browser pada pengambilan awal halaman web. Ajax menggunakan JavaScript untuk berkomunikasi secara dinamis dengan server web untuk membuat HTML untuk membuat halaman dan berinteraksi dengan pengguna. (Ada teknik yang disebut “Rendering sisi server” Di mana JavaScript sebenarnya dieksekusi di server dan permintaan halaman dikembalikan dengan HTML yang diberikan. Namun, pendekatan ini belum didukung pada semua kerangka kerja spa dan menambah kompleksitas untuk pengembangan.)

Salah satu masalah dengan situs Spa Ajax adalah SEO. Google sebenarnya telah merangkak beberapa konten javascript untuk sementara waktu. Faktanya, serangkaian tes terbaru ini mengkonfirmasi Google’S Kemampuan untuk merangkak tautan, metadata, dan konten yang dimasukkan melalui JavaScript. Namun, situs web yang menggunakan kerangka Ajax Pure Spa Ajax secara historis mengalami tantangan dengan SEO.

Kembali pada tahun 2009, Google membuat solusi untuk membuat jax merangkak. Metode itu baik “melarikan diri dari fragmen” URL (URL jelek) atau lebih baru, URL bersih dengan a Meta =”pecahan” Tag di halaman.

URL fragmen yang melarikan diri atau tag fragmen meta menginstruksikan Google untuk keluar dan mendapatkan versi pra-render dari halaman yang telah mengeksekusi semua JavaScript dan memiliki HTML lengkap yang dapat diurai dan diindeks Google. Dalam metode ini, laba -laba menyajikan kode sumber halaman yang sama sekali berbeda (html vs. JavaScript).

Dengan berita bahwa Google Crawls JavaScript, banyak situs telah memutuskan untuk membiarkan Google merangkak situs Ajax spa mereka. Secara umum, itu belum terlalu berhasil. Dalam setahun terakhir, saya telah berkonsultasi untuk beberapa situs web dengan implementasi sudut Ajax. Google sukses, dan sekitar 30 persen halaman di google’S cache sepenuhnya diterjemahkan. 70 persen lainnya kosong.

Situs makanan populer beralih ke Angular, percaya bahwa Google dapat merangkaknya. Mereka kehilangan sekitar 70 persen dari lalu lintas organik mereka dan masih pulih dari bencana itu. Pada akhirnya, kedua situs tersebut pergi ke snapshot HTML pra-rendering, solusi merangkak Ajax yang direkomendasikan pada saat itu.

Dan kemudian, pada 14 Oktober, Google mengatakan ini:

Kami tidak lagi merekomendasikan proposal merangkak Ajax yang kami buat kembali pada tahun 2009.

Perhatikan bahwa mereka masih mendukung proposal lama mereka. (Ada beberapa artikel yang mengumumkan bahwa mereka tidak lagi mendukungnya, tetapi itu tidak benar – mereka tidak lagi merekomendasikan pendekatan itu.)

Dalam mencela rekomendasi lama, mereka tampaknya mengatakan bahwa mereka sekarang dapat merangkak jax.

Kemudian, hanya seminggu setelah pengumuman, klien dengan situs yang baru diluncurkan meminta saya untuk memeriksanya. Ini adalah situs sudut, sekali lagi implementasi spa ajax.

Setelah memeriksa Google’indeks dan cache, kami melihat beberapa halaman yang diindeks sebagian tanpa semua konten merangkak. Saya mengulangi rekomendasi saya sebelumnya menggunakan snapshot HTML atau peningkatan progresif.

Situs ini dibangun dengan Angular, yang belum mendukung rendering sisi server (sekali lagi, dalam hal ini, server awalnya membuat halaman untuk menyajikan dokumen HTML), sehingga peningkatan progresif akan sulit didukung, dan snapshot HTML masih merupakan solusi terbaik untuk mereka.

Dia menjawab, “tapi kenapa? Semua yang saya baca memberi tahu saya google can crawl ajax.”

Bisakah mereka? Membiarkan’S Perhatikan lebih dalam rekomendasi baru sehubungan dengan Ajax.

Google’Rekomendasi AJAX baru

Dalam menjelaskan mengapa mereka mencela rekomendasi lama, kata mereka (penekanan milik saya):

Kita umumnya mampu untuk membuat dan memahami halaman web Anda seperti browser modern.

Banyak orang mungkin dengan cepat menyimpulkan bahwa mereka sekarang dapat merangkak ajax tanpa masalah. Tapi lihat bahasanya: “umumnya mampu”? Apakah Anda bertaruh pendapatan bisnis Anda pada pengetahuan bahwa Google “umumnya mampu” Untuk memahami halaman Anda?

Mungkinkah saya hanya memilih semantik? Membiarkan’S Periksa pengumuman lebih lanjut. Kemudian dalam pengumuman mereka, mereka menyatakan sehubungan dengan Ajax:

Karena asumsi untuk proposal 2009 kami tidak lagi valid, kami sarankan mengikuti prinsip -prinsip peningkatan progresif.

Mereka tidak’Teja dalam pengumuman mereka, tetapi dengan merekomendasikan peningkatan progresif (yang memuat beberapa HTML untuk browser yang tidak’t mendukung javascript), mereka tampaknya secara implisit mengatakan, “Mengenakan’t mengandalkan kami merangkak javascript Anda.” Mengapa merekomendasikan metode ini jika memang Google dapat secara konsisten merangkak situs Ajax Spa?

Saya khawatir bahwa saya mungkin terlalu menganalisis google’kata -kata s, tapi kemudian…

John Mueller mengkonfirmasi Google masih memiliki masalah dengan Ajax

Pada tanggal 27 Oktober (kurang dari dua minggu setelah pengumuman Google), John Mueller, di Webmaster Central Hangout -nya, mengkonfirmasi bahwa Google memang masih memiliki masalah dengan Ajax.

Anda dapat melihat pertukaran sekitar 1:08:00 ke dalam video, di mana ada pertanyaan yang berkaitan dengan implementasi sudut tertentu:

Mereka masih mengalami kesulitan dalam rendering, dan mereka berharap menjadi lebih baik dari waktu ke waktu. John merekomendasikan beberapa tindakan untuk membantu men -debug masalah.

Pada akhirnya, ia merekomendasikan menggunakan snapshot HTML sampai Google menjadi lebih baik di AJAX (ya, metode yang baru saja diusingkan secara resmi).

Jadi, apa yang harus dilakukan?

• Peningkatan progresif. Rendering sisi server akan diperlukan untuk peningkatan progresif, dan belum didukung oleh Angular. Namun, sudut 2 yang akan datang.0 akan mendukung rendering sisi server. React sebenarnya, mendukung rendering sisi server hari ini. Namun, ini lebih banyak pekerjaan daripada sekadar membuat snapshot HTML. Anda perlu memastikan Anda membuat tautan yang diperlukan sehingga Google dapat merangkak dan mengindeks konten tambahan yang dimuat ke dalam halaman. Namun demikian, untuk situs yang menggunakan kerangka AJAX, ini akan menjadi pendekatan yang saya rekomendasikan. (Dan, tentu saja, ini adalah google’S yang direkomendasikan.)
• Snapshot HTML pra-rendering. Sekali lagi, Don’T bingung jika Anda telah mendengar atau membaca bahwa Google tidak lagi mendukung metode ini. Mereka akan terus mendukungnya di masa mendatang. Mereka tidak lagi merekomendasikannya. Metode ini berfungsi; Namun, menulis kode untuk pra-render dan menyajikan snapshot tidak sepele. Kabar baiknya adalah, ada beberapa vendor di luar sana seperti prelender.io siapa yang akan melakukan pekerjaan untuk Anda dengan biaya yang relatif rendah. Itu mungkin pendekatan paling sederhana. Metode ini tidak ideal. Melayani kode sumber yang berbeda untuk crawler vs. browser (html vs. JavaScript) bisa menjadi masalah. Ini dapat dianggap sebagai teknik yang menyeluruh, dan tidak selalu jelas apa yang disajikan bot. Dia’S penting untuk memantau Google’S cache untuk memastikan bahwa mereka tidak dilayani halaman yang salah. Namun demikian, jika Anda menggunakan platform yang tidak mendukung rendering sisi server, maka ini mungkin satu-satunya solusi Anda.

Lebih baik aman daripada menyesal

Bahkan jika saya telah melihat bukti bahwa Google secara konsisten merangkak situs Ajax, saya masih akan waspada. Dibutuhkan lebih banyak sumber daya dan lebih banyak waktu untuk sepenuhnya membuat halaman daripada sekadar melayani HTML.

Apa yang akan terjadi pada situs dengan ratusan ribu atau jutaan halaman? Bagaimana hal itu akan berdampak pada anggaran merangkak? Akankah tingkat perayapan tetap konsisten?

Sebelum merekomendasikan pendekatan ini, saya’D lebih suka menunggu dan melihat bukti kuat bahwa Google dapat dan secara konsisten merangkak aplikasi satu halaman AJAX yang besar dan murni tanpa dampak negatif pada tingkat perayapan, pengindeksan dan peringkat. Tolong bagikan pengalaman Anda sendiri.

Pendapat yang diungkapkan dalam artikel ini adalah pendapat penulis tamu dan tidak harus mendarat mesin pencari. Penulis staf terdaftar di sini.

Bagaimana JavaScript dan Ajax Mempengaruhi Pengindeksan di Google?

Seiring waktu, Google telah meningkatkannya Pengindeksan JavaScript dan Ajax. Pada awalnya, itu tidak’t indeks apapun, atau mengikuti tautan apa pun yang muncul di dalam konten yang dimuat melalui kerangka kerja ini. Tapi kemudian, sedikit demi sedikit, itu mulai mengindeks beberapa implementasi, dan meningkatkan kemampuannya. Saat ini, dapat mengindeks banyak implementasi yang berbeda, dan ikuti tautan yang dimuat Ajax atau API FETCH. Namun demikian, Masih akan ada kasus di mana ia mungkin gagal melakukannya.

Untuk menganalisis kasus -kasus di mana Google dapat berakhir tidak mengindeks situs kami, pertama -tama kita perlu memahami konsep Rendering sisi klien (CSR). Itu menyiratkan itu HTML dicat sisi klien dengan JavaScript, biasanya menggunakan Ajax Berlebihan. Awalnya, situs web selalu melukis sisi server HTML (Rendering sisi server atau SSR), tetapi untuk beberapa waktu sekarang, CSR telah menjadi populer, dengan kedatangan kerangka kerja JavaScript seperti Angular, React and Vue. Namun, CSR secara negatif mempengaruhi pengindeksan, Situs web memberikan kinerja, dan akibatnya, SEO.

Seperti yang kita’VE sudah dijelaskan sebelumnya, untuk memastikan pengindeksan di semua mesin pencari dan situasi, Selain mencapai kinerja yang baik, Solusi terbaik adalah menggunakan kerangka kerja universal, Seperti halnya langkah -langkah ini kita berakhir dengan sesuatu yang disebut Rendering hibrida. Itu terdiri dari Melukis situs web di server pada beban pertama, dan kemudian pada klien melalui JavaScript dan Ajax saat navigasi bergerak ke tautan yang mengikuti. Meskipun, pada kenyataannya, ada lebih banyak situasi di mana penggunaan istilah rendering hibrida juga valid.

Terkadang, perusahaan pengembangan menggunakan CSR dan tidak’t Tawarkan kepada kami pilihan untuk menggunakan kerangka kerja universal. Ini Pengembangan web berbasis CSR akan membuat kita mendapat masalah, ke tingkat yang lebih besar atau lebih kecil, tergantung pada crawler dan algoritma peringkatnya. Dalam posting ini, kami akan menganalisis Apa masalah ini dengan google’c crawler adalah dan bagaimana menyelesaikannya.

Masalah CSR selama beban awal halaman

Pertama, kita akan menganalisis masalah pengindeksan yang terjadi Segera setelah kami memasukkan URL di luar situs web, dan saat HTML diberikan sisi klien dengan JavaScript.

Masalah sebagai hasil dari rendering lambat

Google’Proses pengindeksan S melalui langkah -langkah berikut:

1. Merangkak: GoogleBot meminta URL ke server.
2. Gelombang pengindeksan pertama: Ini mengindeks konten yang dilukis di server secara instan, dan mendapatkan tautan baru untuk merangkak.
3. Ini menghasilkan sisi klien yang dicat html dengan menjalankan javascript. Proses ini secara komputasi mahal (dapat dilakukan pada saat ini, atau memakan waktu beberapa hari, bahkan, menunggu untuk mendapatkan sumber daya yang diperlukan untuk melakukannya).
4. Gelombang kedua pengindeksan: Dengan sisi klien yang dicat html, konten yang tersisa diindeks, dan tautan baru yang akan dirangkak diperoleh.

Selain fakta itu Halaman mungkin membutuhkan waktu lebih lama untuk sepenuhnya diindeks, sehingga menunda pengindeksan halaman berikutnya yang ditautkan dari mereka, jika rendering halaman lambat, GoogleBot’S Renderer dapat meninggalkan bagian yang tidak dicat. Kami’ve menguji ini menggunakan opsi “tepat seperti Google” Disediakan oleh Google Search Console, dan tangkapan layar yang dihasilkannya tidak’t melukis apa pun yang membutuhkan waktu lebih dari 5 detik untuk ditampilkan. Namun, itu menghasilkan HTML yang memakan waktu lebih lama dari 5 detik. Untuk memahami mengapa ini terjadi, kita harus mengingatnya Konsol pencarian Google’S Renderer Pertama Membangun HTML Menjalankan JavaScript dengan GoogleBot’S renderer, dan kemudian melukis halaman’S piksel. Tugas pertama adalah tugas yang harus dipertimbangkan untuk pengindeksan, yang kami rujuk dengan istilah CSR. Di Google Search Console kita dapat melihat HTML yang dihasilkan selama gelombang pertama pengindeksan, dan bukan yang dihasilkan oleh GoogleBot’S Renderer.

Di Google Search Console kami tidak dapat melihat HTML dicat oleh JavaScript, dijalankan oleh GoogleBot �� dan digunakan dalam fase pengindeksan terakhir. Untuk melakukan ini, kita harus menggunakan alat ini: https: // pencarian.Google.com/test/mobile-friendly �� Klik untuk tweet

Dalam tes kami’ve dilakukan, ketika rendering html membutuhkan waktu lebih dari 19 detik, itu tidak’t Mendapatkan Indeks apapun. Meskipun ini adalah waktu yang lama, dalam beberapa kasus dapat dilampaui, terutama jika kita menggunakan Ajax secara intensif, dan dalam kasus ini Google’S Renderer, sama seperti renderer mana pun, sungguh, harus menunggu langkah -langkah berikut terjadi:

1. Html diunduh dan diproses Untuk meminta file yang ditautkan dan membuat DOM.
2. CSS diunduh dan diproses, untuk meminta file yang tertaut dan membuat CSSOM.
3. Javascript diunduh, disusun dan dijalankan, untuk meluncurkan permintaan Ajax.
4. Permintaan AJAX dipindahkan ke antrian permintaan, menunggu untuk ditanggapi, bersama dengan file yang diminta lainnya.
5. Permintaan AJAX diluncurkan, dan harus melakukan perjalanan melalui jaringan ke server.
6. Server menanggapi permintaan melalui jaringan, dan akhirnya, Kami harus menunggu JavaScript dijalankan, untuk melukis konten halaman’S HTML Template.

Waktu permintaan dan unduhan proses yang baru saja kami jelaskan bergantung pada jaringan dan beban server selama waktu itu. Lebih-lebih lagi, GoogleBot hanya menggunakan http/1.1, yang lebih lambat dari http/2, karena permintaan ditangani satu demi satu, dan tidak semua pada waktu yang bersamaan. Dia’s perlu bahwa klien dan server memungkinkan HTTP/2 untuk digunakan, itulah sebabnya GoogleBot hanya akan menggunakan http/1.1, bahkan jika server kami memungkinkan HTTP/2. Untuk meringkas, ini berarti GoogleBot menunggu setiap permintaan selesai untuk meluncurkan yang berikutnya, dan itu’S mungkin itu menang’T coba paralelis dengan permintaan tertentu dengan membuka berbagai koneksi, seperti yang dilakukan browser (meskipun kami tidak’Aku tahu persis bagaimana melakukannya). Karena itu, kita berada dalam situasi di mana Kami bisa melebihi 19 detik ini yang kami perkirakan sebelumnya.

Bayangkan, misalnya, bahwa dengan gambar, CSS, JavaScript, dan permintaan AJAX, lebih dari 200 permintaan diluncurkan, masing -masing mengambil 100 ms. Jika permintaan AJAX dikirim ke bagian belakang antrian, kami’mungkin melebihi waktu yang diperlukan untuk konten mereka diindeks.

Di sisi lain, karena masalah kinerja CSR ini, Kami akan mendapatkan tanda yang lebih buruk untuk metrik FCP (Contentful Paints pertama) di Pagespeed dalam hal rendering dan WPO -nya, dan sebagai akibatnya, peringkat yang lebih buruk.

Masalah pengindeksan:

Saat mengindeks konten yang dicat sisi klien, GoogleBot dapat mengalami masalah berikut, yang akan mencegah pengindeksan HTML yang dihasilkan JavaScript:

• Mereka menggunakan a Versi JavaScript crawler tidak’t mengenali.
• Mereka menggunakan a JavaScript API Tidak dikenali oleh GoogleBot (saat ini, kami tahu soket web, WebGL, WebVR, IndexedDB dan WebSQL tidak didukung – informasi lebih lanjut di https: // pengembang.Google.com/pencarian/dokumen/panduan/rendering).
• File JavaScript diblokir oleh robot.txt.
• File JavaScript disajikan melalui http saat situs web menggunakan https.
• Ada javascript kesalahan.
• Jika aplikasi meminta izin pengguna untuk melakukan sesuatu, dan di atasnya tergantung rendering konten utama, ia menang’t dicat, karena googleebot menolak izin apa pun’S diminta secara default.

Untuk mengetahui apakah kami menderita masalah ini, kami harus menggunakan Google’S tes ramah seluler. Ini akan menunjukkan kepada kita tangkapan layar tentang bagaimana sebuah halaman dilukis di layar, mirip dengan Google Search Console, tetapi juga menunjukkan kepada kita Kode html yang dihasilkan oleh renderer (Seperti yang disebutkan sebelumnya), log register kesalahan dalam kode javascript, Dan Fitur javascript yang belum bisa ditafsirkan oleh renderer. Kami harus menggunakan alat ini untuk menguji semua URL yang mewakili setiap templat halaman di situs web kami, untuk memastikan situs web dapat diindeks.

Kita harus mengingat bahwa di Html dihasilkan oleh alat sebelumnya, semuanya metadata (termasuk URL kanonik) akan diabaikan oleh GoogleBot, karena hanya mempertimbangkan informasi saat itu’S dicat di server.

Masalah CSR sehubungan dengan navigasi ke halaman berikutnya

Sekarang, biarkan’s lihat apa yang terjadi ketika kita menggunakan tautan untuk menavigasi, begitu kita’sudah ada di situs web, dan html dicat sisi klien.

Masalah pengindeksan

Berlawanan dengan CSR selama beban awal, Navigasi ke halaman berikutnya beralih konten utama melalui JavaScript lebih cepat dari SSR. Tapi kita’ll memiliki masalah pengindeksan jika:

• Tautan don’t memiliki url yang valid mengembalikan 200 ok di dalamnya Atribut HREF.
• Server mengembalikan kesalahan saat mengakses URL secara langsung, tanpa JavaScript, atau dengan JavaScript diaktifkan dan menghapus semua cache. Hati -hati dengan ini: Jika kita menavigasi ke halaman dengan mengklik tautan, itu mungkin terlihat’s berfungsi, karena dimuat oleh javascript. Bahkan saat mengakses secara langsung, jika situs web menggunakan pekerja layanan, situs web dapat mensimulasikan respons yang benar, dengan memuat cache -nya. Tapi GoogleBot adalah crawler tanpa kewarganegaraan, alasan mengapa itu tidak’T memperhitungkan cache pekerja server, atau teknologi javascript lainnya seperti penyimpanan lokal atau penyimpanan sesi, jadi itu akan mendapatkan kesalahan.

Selain itu, agar situs web dapat diakses, URL harus berubah menggunakan JavaScript dengan API Sejarah.

Apa yang terjadi dengan fragmen sekarang karena Google dapat mengindeks Ajax?

Fragmen adalah bagian dari URL yang dapat muncul di akhir, didahului oleh hash #. Misalnya:

http: // www.humanlevel.com/blog.Contoh HTML#

URL semacam ini tidak pernah mencapai server, mereka hanya dikelola sisi klien. Ini berarti bahwa ketika meminta URL di atas ke server, itu akan mendapatkan permintaan “http: // www.humanlevel.com/blog.html”, Dan di klien, browser akan menggulir ke fragmen dokumen yang dirujuk. Ini adalah penggunaan umum dan awalnya dimaksudkan untuk URL ini, umumnya dikenal sebagai Jangkar HTML. Dan jangkar, pada kenyataannya, adalah tautan apa pun ( “A” Tag di HTML berasal jangkar). Namun, kembali di masa lalu, Fragmen juga digunakan untuk memodifikasi URL melalui JavaScript pada halaman Ajax-loaded, bermaksud membiarkan pengguna menavigasi melalui riwayat penelusuran mereka. Itu diimplementasikan dengan cara ini, karena saat itu fragmen itu adalah satu -satunya bagian dari URL yang dapat kami ubah menggunakan JavaScript, itulah sebabnya pengembang mengambil keuntungan dari ini untuk menggunakannya dengan cara yang mereka lakukan’t dimaksudkan. Ini berubah dengan kedatangan API Sejarah, karena memungkinkan memodifikasi seluruh URL melalui JavaScript.

Kembali saat google tidak bisa’T Indeks Ajax, jika URL mengubah kontennya melalui AJAX, berdasarkan bagian fragmen, kami tahu itu hanya akan mengindeks URL dan konten tanpa mempertimbangkan fragmen tersebut. Jadi … apa yang terjadi pada halaman dengan fragmen sekarang karena Google dapat mengindeks jax? Perilakunya persis sama. Jika kami menautkan halaman dengan fragmen, dan itu mengubah kontennya saat diakses melalui fragmen, ia akan mengindeks konten yang mengabaikan fragmen, dan popularitas akan masuk ke URL ini, Karena Google mempercayai fragmen akan digunakan sebagai jangkar, dan tidak mengubah konten, sebagaimana mestinya.

Namun, Google saat ini mengindeks URL dengan hashbang (#!). Ini dapat diimplementasikan dengan sederhana menambahkan tanda seru atau Bang, dan Google akan membuatnya bekerja, untuk mempertahankan kompatibilitas ke belakang dengan spesifikasi usang untuk membuat AJAX dapat diindeks. Namun, praktik ini tidak dianjurkan, karena sekarang harus diimplementasikan dengan API sejarah, dan selain itu, Google tiba -tiba bisa berhenti mengindeks URL hashbang kapan saja.

Memblokir pengindeksan respons parsial melalui AJAX

Saat An Ajax Permintaan dikirim ke URL dari API istirahat atau graphql, Kami’kembali kembali a Json atau sepotong halaman yang kami jangan’T ingin diindeks. Karena itu, kita harus memblokir pengindeksan URL yang diarahkan permintaan ini.

Kembali pada hari itu kita bisa memblokirnya menggunakan robot.txt, Tapi sejak googleebot’S Renderer menjadi ada, kami tidak dapat memblokir sumber daya apa pun yang digunakan untuk melukis html.

Saat ini, Google sedikit lebih pintar dan itu tidak’t biasanya mencoba mengindeks tanggapan dengan jsons, tetapi jika kita ingin memastikan mereka tidak’t diindeks, Solusi universal yang berlaku untuk semua mesin pencari adalah membuat semua URL yang digunakan dengan AJAX untuk hanya menerima permintaan yang dibuat melalui metode POST, karena itu bukan’t digunakan oleh crawler. Ketika permintaan dapat mencapai server, itu harus mengembalikan kesalahan 404. Dalam hal pemrograman, itu tidak’t memaksa kita untuk menghapus parameter dari URL’s querystring.

Ada juga kemungkinan menambahkan http “X-Robots-Tag: NoIndex” Header (diciptakan oleh Google) ke respons AJAX, atau untuk membuat tanggapan ini dikembalikan dengan 404 atau 410. Jika kami menggunakan teknik ini pada konten yang dimuat langsung dari HTML, ia menang’t diindeks, sama seperti jika kita telah memblokirnya melalui robot.file txt. Namun, Mengingatnya’S lukisan JavaScript respons pada halaman, Google tidak’T membangun hubungan antara respons ini dan lukisan JavaScript, Jadi itu melakukan persis seperti yang kita harapkan dari itu. Dan yaitu: bukan mengindeks respons parsial dan sepenuhnya mengindeks HTML yang dihasilkan. Hati -hati dengan ini, karena perilaku ini dapat berubah suatu hari nanti, dan begitu juga semua konten kami dimuat melalui Ajax jika kami menerapkan teknik ini.

Kesimpulan

Google sekarang dapat mengindeks JavaScript dan Ajax, tetapi itu pasti menyiratkan a Biaya yang lebih tinggi untuk pengindeksan HTML yang sudah diproses di server. Ini berarti SSR adalah dan akan terus menjadi pilihan terbaik untuk beberapa waktu. Jika Anda tidak memiliki alternatif lain selain berurusan dengan situs web CSR, sepenuhnya atau sebagian, Anda sekarang tahu bagaimana melakukan ini.