JavaScript SEO: Menghindari Jebakan Rendering Sisi Server

JavaScript SEO saat ini menjadi salah satu topik hangat di industri SEO, seiring dengan berkembangnya web modern dan semakin banyak situs web yang diluncurkan kembali atau dibangun di atas aplikasi web berbasis JavaScript, sebagian besar di React atau AngularJS. Dengan ini, lebih banyak kerumitan ditambahkan ke SEO, karena kami perlu memastikan bahwa Google mampu merender JavaScript secara efektif, sehingga halaman dapat diindeks dan diberi peringkat dengan benar. Ini dapat dicapai dengan menggunakan rendering sisi server. Namun, ini tidak datang tanpa risiko. Dalam artikel ini, saya membahas lima kesalahan rendering sisi server dan menjelaskan bagaimana Anda dapat menghindarinya.

Jika Anda mencari dukungan dalam pengoptimalan teknis situs web Anda, mengapa tidak membuat janji temu yang tidak mengikat dengan konsultan Grup Strategi Digital kami dan mencari tahu di mana mereka dapat membantu Anda?

Minta janji!

Apa saja jenis rendering sisi server yang ada?

Pra-render situs web Anda untuk Google di server Anda (render sisi server, SSR) adalah salah satu opsi untuk memastikan bahwa situs web JavaScript Anda ramah-Googlbot. Dengan cara ini, Anda dapat mengirimkan versi HTML situs web yang telah dirender sebelumnya ke Google, sementara pengguna mendapatkan versi browser normal (belum dirender).

Namun, ketika menyangkut rendering sisi server, ada juga cara berbeda untuk merender, seperti yang dapat Anda lihat dari bagan berikutnya, yang telah disediakan dengan sangat membantu oleh Google, dengan beberapa tambahan yang berguna dari Jan-Willem Bobbink.

Ada tiga cara utama untuk menyiapkan dan menjalankan rendering sisi server:

1. Render sisi server dengan HTML dinamis

Render sisi server membuat versi HTML yang dirender dari setiap URL sesuai permintaan.

2. Render statis dengan HTML statis

Pada dasarnya, ini membuat versi HTML pra-render (statis) dari URL sebelumnya dan menyimpannya di cache.

3. Render sisi server dengan (kembali) hidrasi dengan HTML dinamis dan JS/DOM

Server menyediakan versi HTML statis dari URL dan klien (browser, dll.) yang sudah menyertakan mark-up Model Objek Dokumen (DOM) terstruktur. Klien mengambil ini dan mengubahnya menjadi DOM dinamis yang dapat bereaksi terhadap perubahan sisi klien dan membuatnya lebih interaktif.

Google menerbitkan ikhtisar yang bagus tentang rendering web, dengan semua pro dan kontra, ditambah penjelasan yang lebih dalam jika Anda tertarik. Tetapi pertama-tama, jika Anda mencari bantuan tentang topik JavaScript SEO atau Server Side Rendering, pastikan untuk menghubungi kami di sini di Grup Strategi Digital Searchmetrics.

Berhubungan!

Kesalahan saat merender situs web JavaScript melalui server

Kami baru-baru ini menemukan beberapa masalah RSK dengan salah satu klien kami. Mereka menjalankan situs web mereka di Angular JS dan merendernya dengan Rendertron melalui Chrome Tanpa Kepala.

Mereka menggunakan pendekatan render SSR statis, yang berarti mereka merender halaman dan menyimpan HTML yang di-cache di server (sebelumnya). HTML yang di-cache tidak akan diganti secara otomatis tetapi didasarkan pada logika rendering. Berikut ini adalah lima masalah yang kami temui saat bekerja di situs web ini. Saya membagikannya dengan Anda di sini, sehingga jika Anda memiliki tantangan serupa, Anda akan memiliki ide bagaimana menghadapinya. Namun ini dapat dianggap sebagai daftar yang belum selesai/dapat diperluas.

1. Ketika Anda tidak melakukan apa-apa

Ketika Anda tidak peduli dan tidak memperhatikan bagaimana Google merender halaman Anda, maka izinkan saya menunjukkan kepada Anda bagaimana Google merender (sebenarnya melihat) halaman Anda. Ini didasarkan pada situs web yang dibangun di atas Aplikasi Satu Halaman (SPA) menggunakan kerangka kerja JavaScript, tanpa rendering sisi server.

Ini tidak terlihat sangat menjanjikan, bukan? Itulah mengapa penting untuk menggunakan SSR, karena akan terlihat seperti ini:

2 . paginasi

Bagaimana cara menangani halaman Anda yang diberi halaman dalam hal rendering? Yah, terutama dalam penerbitan, halaman yang diberi halaman masih bisa menjadi hal yang baik untuk melayani Google dengan artikel Anda (terbaru) saat Google merayapi mereka. Jika Anda melihat file log Anda, Anda akan melihat bagaimana Google mengakses pagination Anda, sehingga Anda tahu di mana masuk akal untuk menyediakan versi yang telah dirender (Spoiler: Anda tidak perlu memberikan 399 URL dengan versi yang dirender )

Saat klien kami merender dengan pendekatan SSR statis, mereka hanya merender halaman pertama dan mencerminkan versi cache dari Halaman 1 hingga halaman 10. Tanpa versi yang dirender dari halaman 11 dan seterusnya. Berikut adalah dua tangkapan layar yang menunjukkan masalah dengan cukup baik, dengan konten yang sama persis dari halaman 1 juga disediakan di halaman 2-10.

Artinya Anda memberikan Google 10 Pages dengan konten dan artikel yang sama. Idealnya, Anda ingin Google merender semua halaman sebagai unik dengan artikel yang diberi halaman dengan benar.

3 . Perbarui versi halaman kategori yang dirender setelah artikel/produk baru diterbitkan

Klien kami telah meningkatkan peringkatnya di hampir setiap properti Google Berita dengan cukup signifikan, seperti AMP Carousel, Google News Box, dan Mobile News Box, dengan pengecualian Publisher Carousel. Kami mulai menyelidiki ini dan ternyata klien kami tidak memperbarui versi cache mereka ketika ada artikel baru yang diterbitkan. Kami menemukan bahwa mereka memperbarui versi cache kategori utama seminggu kemudian:

dan pada subkategori bahkan sebulan kemudian.

Ini mengarah pada fakta bahwa mereka masih memiliki artikel lama tentang topik Brexit dalam versi pra-render mereka, tetapi mereka tidak memiliki semua artikel baru yang diterbitkan tentang topik tersebut. Asumsi kami di sini adalah, karena masalah ini, tidak ada cukup artikel baru bagi Google untuk mengisi carousel dan ini memiliki dampak negatif yang besar pada kinerjanya. Kami masih menyelidiki dampak dari perubahan tersebut.

4 . Rendering dapat menyebabkan duplikat konten dan kanonikalisasi yang salah

Menyediakan versi pra-render dari URL dapat menyebabkan masalah berbasis sistem. Saat klien kami mengirimkan laman pra-render, masing-masing dengan URL sendiri yang dibuat oleh mesin render, URL ini memiliki parameter “p=1; render=1” dan dapat diindeks sepenuhnya:

Bahkan ada pengaturan kanonik baru oleh mesin SSR untuk URL itu. Cukup menyeramkan, ya?

Idealnya, Anda ingin mengecualikan parameter ini dari perayapan Google.

5 . Judul halaman berubah saat rendering

Kami juga menemukan bahwa judul halaman saat ini dirender melalui JavaScript. Ini dilakukan dengan cara yang berarti judul meta HTML selalu menunjukkan nama merek saat JavaScript dinonaktifkan. Dan ketika agen pengguna bukan Googlebot, itu hanya merender judul halaman HTML. Lihat dua contoh berikut di bawah ini. Yang pertama menunjukkan URL dengan JavaScript dinonaktifkan. Yang kedua adalah URL yang sama, tetapi dengan JavaScript diaktifkan.

Untuk memastikan bahwa metadata selalu dirender dengan benar, Anda harus menyertakannya dalam versi URL yang tidak dirender (JavaScript).

Kesimpulan

Render sisi server tidak dapat digunakan sebagai pendekatan cookie-cutter untuk merender aplikasi satu halaman. Perhatian khusus diperlukan untuk pendekatan statis di mana Anda hanya memberikan snapshot. Seperti yang dapat Anda lihat dari contoh klien kami, Anda perlu memastikan bahwa mesin SSR selalu menyediakan versi URL yang terbaru, jika tidak, Google tidak akan melihat dan menangkap artikel terbaru Anda, dan Anda akan kehilangan lalu lintas yang berharga.

Sebelum meluncurkan kembali dari situs web berbasis HTML ke kerangka kerja berbasis JavaScript, pastikan bahwa rendering sisi server disertakan dan itu selalu disajikan secara dinamis!

Jika Anda mengalami masalah JavaScript atau sedang mencari dukungan dalam pengoptimalan teknis situs web Anda, mengapa tidak membuat janji temu yang tidak mengikat dengan konsultan Grup Strategi Digital kami dan mencari tahu di mana mereka dapat membantu Anda?

Minta janji!