Jam Kerja SEO – 8 Oktober 2021

Inilah rangkuman pertanyaan dan jawaban paling menarik dari Google SEO Office Hours bersama John Mueller pada 8 Oktober 2021.

Jumlah halaman yang diindeks vs. otoritas situs

03:52 “Jadi, Anda telah merekomendasikan beberapa kali di masa lalu bahwa situs besar […] fokus pada kumpulan halaman yang lebih kecil […]. Situs yang sedang saya kerjakan sekarang, kami memiliki […] seperti 1.000 halaman yang tidak mendapatkan lalu lintas, yang sudah tua, jadi saya menyarankan untuk menghapusnya. Namun ada pertanyaan yang diajukan oleh tim pengembang kami bahwa mereka mendapat kesan bahwa semakin banyak halaman yang telah diindeks oleh Google dari situs Anda, semakin tinggi otoritas yang diberikannya ke situs tersebut, dan enggan untuk menghapus halaman apa pun. Bisakah Anda menjelaskan hal itu? ”

Seperti yang dikatakan John, “Ini jelas tidak terjadi jika Anda memiliki lebih banyak halaman yang diindeks, yang menurut kami situs web Anda lebih baik. […] Terkadang, masuk akal untuk memiliki banyak halaman yang diindeks. Terkadang, itu adalah halaman yang berguna untuk diindeks seperti itu. Tapi itu bukan tanda kualitas sehubungan dengan berapa banyak halaman yang diindeks. Dan terutama jika Anda berbicara tentang […] 1.000, 2.000, 5.000 halaman, itu angka yang cukup rendah untuk sistem kami secara umum. Dan bukan berarti kami akan mengatakan 5.000 halaman lebih baik dari 1.000 halaman. Bagi kami, itu semua seperti, yah, ini adalah situs web kecil, dan kami melakukan apa yang dapat kami lakukan di sana. Dan tentu saja, website kecil itu relatif. Ini tidak seperti mengatakan itu adalah situs web yang tidak relevan. Mungkin kecil, tapi mungkin masih sangat berguna […]”.

Mengevaluasi tujuan utama situs web

10:03 “Terakhir kali kami berbicara tentang beberapa masalah dengan situs web […] – ini adalah situs web e-niaga di mana kami memiliki hal-hal informasional dan hal-hal transaksional. […] Saran Anda adalah untuk memisahkan konten ini sedikit menjadi halaman berorientasi transaksi dan berorientasi informasi. Jadi saya punya pertanyaan lain tentang ini. Jika Anda memiliki, katakanlah, situs web e-niaga, dan Anda memiliki blog besar, atau majalah, atau sesuatu seperti itu di mana Anda memiliki banyak hal informasi, tetapi itu adalah bagian lama. Dan di sisi lain, Anda memiliki semua halaman produk ini, dan kategori, dan seterusnya. Jadi, apakah blok besar dengan hal-hal informasi murni ini akan memberikan sentuhan atau karakter informasi kepada seluruh situs web sehingga Google berkata, oh, kami tidak yakin apakah ini […] sesuatu di mana orang bisa mendapatkan informasi daripada membeli barang, atau evaluasi ini dilakukan pada basis per halaman?”

John berkata: “[…] Pemahaman saya adalah bahwa ini lebih merupakan hal tingkat halaman. […] Banyak situs web hanya memiliki campuran berbagai jenis konten. Dan kemudian Anda mencoba mencari tahu halaman mana yang cocok dengan maksud pencari dan mencoba memberi peringkat dengan tepat. […]

Maksud saya, Anda sering melihatnya dengan situs web berita. […] Mereka memiliki acara terbaru, tetapi mereka juga memiliki bagian untuk acara lama yang terjadi, atau […] untuk acara besar lainnya, mereka memiliki bagian arsip yang terisolasi. Dan itu adalah maksud yang sangat berbeda, jika Anda benar-benar menginginkan sesuatu yang sekarang sedang terjadi atau jika Anda menginginkan semacam penelitian informasi, konten tipe evergreen.

[…] Kami agak harus melihatnya pada basis per halaman , dan tidak mengatakan, oh, ini adalah situs web penelitian karena ada beberapa konten penelitian di sini”.

Pengalihan tautan

13:21 “Kami melihat bahwa orang-orang menautkan ke […], katakanlah, subkategori halaman kami. Dan masalahnya adalah bahwa […] konten kami datang dan pergi, yang berarti terkadang, ada lebih banyak konten yang muncul di beberapa kategori. Terkadang, konten dihapus. Dan subkategori dapat dibuat dan dapat menghilang juga. Dan kami melihat banyak referensi dari backlink karena mereka menautkan ke subkategori yang sudah tidak ada lagi. Pertanyaan saya di sini adalah: apakah boleh mengarahkan […] tautan ini ke kategori induk. Dan jika kita melakukannya, bagaimana kita melakukannya – dengan 302, misalnya? Seperti pengalihan sementara, karena di masa mendatang, subkategori ini mungkin diisi dengan konten lagi, […] itu bukan pengalihan permanen”.

John menjawab: “Jadi jika kami melihat ini terjadi pada skala yang lebih besar yang Anda arahkan ke tingkat induk, kami mungkin akan melihatnya sebagai 404 lunak. […] Dan alih-alih kode 404, Anda mengarahkan ulang, dan mungkin itu lebih baik untuk pengguna, tetapi kami melihatnya sebagai 404. […] Jika masuk akal dari sudut pandang pengguna untuk mengarahkan ulang, maka saya akan melakukannya.

[…] Sehubungan dengan 301 atau 302, saya pikir itu tidak penting di sana, karena kita akan melihat ini sebagai soft 404, atau kita akan melihatnya sebagai pertanyaan kanonikalisasi. Jika soft 404, maka kodenya tidak masalah. Jika ini adalah pertanyaan kanonikalisasi, maka akan turun ke URL mana yang kami tampilkan di hasil pencarian. Dan biasanya, level yang lebih tinggi akan memiliki sinyal yang lebih kuat, dan kami akan fokus pada level yang lebih tinggi. Jadi tidak masalah apakah itu 301 atau 302 dalam kasus itu.

[…] Jika kami melihatnya sebagai soft 404, […] kami akan memperlambat perayapan URL tertentu karena tidak ada apa-apa di sini […]. Jika kita melihatnya sebagai redirect […], kita tidak perlu meng-crawl ini setiap hari, karena kita fokus pada URL utama. Jadi saya pikir dalam kedua kasus itu, kami akan memperlambat perayapan URL itu sampai kami mendapatkan sinyal baru yang memberi tahu kami, sebenarnya, ini mungkin sesuatu yang baru lagi. […] Itu akan seperti tautan internal, atau file peta situs […]. Dan itu akan menjadi tanda yang lebih kuat bagi kita untuk merangkak lagi. Tapi saya pikir perlambatan perayapan akan serupa dalam semua kasus ini.

[…] Saya pikir [memperbarui] peta situs saja mungkin tidak cukup. Saya benar-benar akan memastikan bahwa tautan internal juga jelas ”.

Pemulihan dari pembaruan inti

18:34 “Jadi sekitar setahun yang lalu, kami melihat beberapa penurunan lalu lintas yang signifikan. Setelah audit, […] semua sinyal menunjuk ke situs yang memiliki masalah kualitas situs. Kami dapat mengatasi masalah tersebut pada bulan Februari tahun ini. Dan pada pembaruan inti bulan Juni, kami melihat beberapa peningkatan. Tapi masih belum ke level dulu sebelum turun sekitar setahun lalu. Jadi pertanyaan saya adalah masalah kualitas situs, jika memang demikian, apakah ini pemulihan yang dapat kami harapkan, atau dapatkah kami mengharapkan lebih banyak pemulihan jika kami pikir kami telah mengatasi semua masalah yang diidentifikasi […]?”

John berkata: “[…] Kami tidak akan menganggapnya sebagai situasi di mana Anda harus memperbaiki sesuatu. Melainkan […] jika Anda berupaya meningkatkan relevansi situs web Anda, maka […] Anda memiliki situs web yang lebih baik. Jadi bukan […] kita akan mengubahnya kembali ke keadaan sebelumnya. […] Ini tidak sama atau sebanding dengan sebelumnya, jadi agak sulit untuk mengharapkannya berubah ke keadaan sebelumnya […].

[…] Dengan pembaruan inti, kami tidak terlalu fokus pada masalah individu saja, melainkan relevansi situs web secara keseluruhan . Dan itu dapat mencakup hal-hal seperti kegunaan, dan iklan di halaman, tetapi itu pada dasarnya adalah situs web secara keseluruhan. Dan biasanya, itu juga berarti fokus konten, cara Anda menyajikan sesuatu, cara Anda menjelaskan kepada pengguna apa yang ada di balik konten, seperti apa sumbernya […] . Jika Anda benar-benar ingin Google melihat situs web Anda sebagai sesuatu yang jauh lebih baik, Anda mungkin juga perlu bekerja di sisi konten .

[…] Pikirkan tentang di mana mungkin ada konten berkualitas rendah, di mana pengguna mungkin bingung ketika mereka membuka situs web saya. Dan apakah kebingungan itu dapat kami atasi dengan masalah teknis, dengan perubahan UX? Atau memang kami harus mengubah beberapa konten yang kami hadirkan?”

Tautan di posting tamu

28:24 “[…] Jika [sebuah situs web memiliki] kiriman tamu, dan Google tidak tahu apakah itu berbayar atau tidak, bagaimana Google kemudian menentukan bahwa [mereka harus] mengambil tautan ini atau membakar tautan ini? Apa jawabannya agar kita aman dari segala penjuru?”

Menurut John, “[…] Panduan kami untuk tautan dan kiriman tamu adalah bahwa tautan dan kiriman tamu tidak boleh diikuti . […] Saya hanya akan sangat berhati-hati untuk memastikan bahwa tautan tersebut tidak boleh diikuti sehingga Anda mendorong kesadaran, Anda berbicara tentang apa yang Anda lakukan, Anda membuatnya sehingga pengguna dapat membuka halaman. Tetapi pada dasarnya, ini adalah iklan untuk bisnis Anda. Jadi dari sudut pandang itu, saya hanya akan membuat mereka tidak mengikuti”.

Harga produk sebagai faktor peringkat

32:25 “Jika ada dua situs e-niaga yang bersaing yang menjual produk yang persis sama – satu situs web menawarkan produk seharga $500, yang lain $100, semua sinyal SEO adalah sama. Apakah situs web yang lebih murah memiliki peluang peringkat yang lebih baik karena ada perbedaan harga untuk produk yang sama persis?”.

John berkata: “Jadi murni dari sudut pandang pencarian web, tidak. Kami tidak akan mencoba mengenali harga pada halaman dan menggunakannya sebagai faktor peringkat. Jadi bukan berarti kami akan mengatakan bahwa kami akan mengambil yang lebih murah dan memberi peringkat yang lebih tinggi […].

Namun, banyak dari produk ini juga berakhir dalam jenis hasil pencarian produk, yang bisa jadi karena Anda mengirimkan umpan, atau bisa juga karena kami mengenali informasi produk di halaman ini. Dan hasil pencarian produk, saya tidak tahu bagaimana cara memesannya. Mungkin mereka mempertimbangkan harga atau hal-hal seperti ketersediaan […].

Jadi dari sudut pandang pencarian web, kami tidak memperhitungkan harga. Dari sudut pandang pencarian produk, itu mungkin . Dan bagian yang sulit, menurut saya, sebagai SEO adalah berbagai aspek pencarian ini sering digabungkan dalam satu halaman hasil pencarian, di mana Anda akan melihat hasil web normal, dan mungkin Anda akan melihat beberapa hasil produk di samping, atau mungkin Anda akan melihat beberapa campuran dari itu […]”.

Memindahkan URL di antara peta situs

34:04 “Jika kita memiliki 200 file peta situs, dan 20% hingga 30% dari URL melompat dari satu file ke file lain setiap minggu, seberapa buruk itu? Atau haruskah kita menyimpan URL kita secara ketat di file yang sama selamanya?”

“[…] Rekomendasi kami biasanya untuk menyimpan URL yang sama di file peta situs yang sama . Alasan utamanya adalah kami memproses file peta situs dengan kecepatan yang berbeda. Jadi, jika Anda memindahkan satu URL dari satu file peta situs ke file peta situs lainnya, mungkin kami memiliki URL yang sama di sistem kami dari beberapa file peta situs. Dan jika Anda memiliki informasi yang berbeda untuk satu URL ini – seperti tanggal perubahan yang berbeda, misalnya – maka kami tidak akan tahu atribut mana yang benar-benar digunakan.

Jadi dari sudut pandang itu, jika Anda selalu memilikinya dalam file peta situs yang sama, maka jauh lebih mudah bagi kami untuk mengatakan, oh, kami memiliki informasi untuk URL ini di sini, dan kami dapat mempercayai informasi itu karena hanya ada di sana. Jadi itu adalah sesuatu di mana saya mencoba untuk menghindari [...] URL ini acak-acakan. Tetapi pada saat yang sama, biasanya tidak akan menghentikan pemrosesan file peta situs Anda. Dan itu pasti tidak akan memiliki efek peringkat di situs web Anda. Jadi tidak ada dalam sistem peta situs kami yang memetakan kualitas situs web ”.

Konten multi-regional

38:13 “Saya bekerja di vertikal berita. Tim saya ingin memperluas kehadiran internasional kami, dan telah melakukan pekerjaan untuk menyiapkan subdirektori multi-regional. Untuk sebagian besar, halaman di berbagai edisi multi-regional akan terlihat sama. Halaman beranda dan halaman rubrik seperti politik atau gaya hidup akan memiliki konten serupa tanpa beberapa bagian yang unik untuk wilayah tersebut.

Artikel-artikelnya rumit. Tidak banyak yang dapat kami bedakan di subdirektori multi-regional di luar modul dengan tautan terkait, yang membuat kami khawatir tentang masalah konten duplikat. Bagaimana cara Google menangani konten duplikat di ruang berita? […] Kontennya tetap sama, tetapi elemen templatenya berbeda. Haruskah hanya ada satu kanonik di semua situs web multi-regional?”

Tanggapan John adalah: “[…] Kedengarannya ini adalah wilayah yang berbeda di negara yang sama, dan konten bahasa yang sama. […] Jika ini adalah negara yang berbeda, maka Anda memiliki aspek penargetan geografis, yang berperan jika ini adalah bahasa yang berbeda. Jadi jika Anda bekerja, katakanlah, di Eropa, dan Anda meliputi Jerman, dan Prancis, dan Italia, atau sesuatu, maka Anda juga memiliki bahasa yang berbeda.

[…] Tetapi jika Anda berbicara tentang di negara yang sama, konten bahasa yang sama, maka […] itu sedikit lebih mudah karena Anda tidak perlu khawatir tentang semua koneksi teknis ini. Namun di sisi lain, masalah duplikat konten jauh lebih terlihat. Dan ketika menyangkut duplikat konten, aspek rumit di situs seperti ini adalah Anda pada dasarnya bersaing dengan diri sendiri. Dan jika Anda memiliki satu artikel berita yang Anda terbitkan di […] lima atau enam situs web regional yang berbeda, maka semua situs web regional yang berbeda ini mencoba memberi peringkat untuk artikel yang sama persis. Dan itu bisa mengakibatkan artikel itu tidak mendapat peringkat sebaik yang seharusnya.

Karena itu, saya akan merekomendasikan untuk mencoba menemukan URL kanonik untuk masing-masing artikel ini sehingga Anda benar-benar dapat mengatakan 'baik, saya memiliki satu artikel ini di lima situs web regional saya, tetapi ini adalah versi pilihan saya yang ingin saya lihat di Cari'. Dan kemudian kita dapat memusatkan semua energi kita, semua sinyal kita, pada satu versi yang disukai itu, dan kita dapat mencoba memberi peringkat yang sedikit lebih baik. Tidak harus selalu dalam versi yang sama. Jadi dapat dipastikan bahwa Anda memiliki satu artikel berita yang berada dalam satu wilayah semacam kanonik, artikel berita yang berbeda lebih kanonik untuk wilayah lain. Bagaimana Anda memilih wilayah mana yang Anda pilih sebagai kanonik sepenuhnya terserah Anda. […] Biasanya, Anda akan mencoba mencari tahu di mana itu yang paling relevan, dan memilih yang itu sebagai versi kanonik. Jadi itu untuk masing-masing artikel itu sendiri.

Untuk kategori, dan bagian, dan halaman beranda, sepertinya itu akan menjadi sesuatu di mana kontennya lebih unik, dan lebih spesifik untuk masing-masing wilayah. Dan karena itu, saya akan mencoba untuk memisahkan tingkat indeks tersebut. Jadi, jika Anda memiliki lima situs web regional yang berbeda, halaman berandanya, bagian kategorinya, semuanya akan diindeks satu per satu. Dan artikel berita itu sendiri akan dipetakan ke salah satu wilayah yang berbeda ini. Jadi itu jenis pendekatan yang kami rekomendasikan di sana […].

Dan pendekatan ini juga […] bekerja di berbagai nama domain. Jadi, jika Anda memiliki domain yang berbeda untuk masing-masing wilayah, tetapi semuanya merupakan bagian dari grup berita yang sama, Anda masih dapat melakukan pemindahan kanonik ini di seluruh versi yang berbeda. Jika Anda melakukannya dalam domain yang sama dengan subdirektori, tidak apa-apa juga”.

Pengalihan dalam pemindahan situs

44:34 “Apa tindakan terbaik yang harus diambil ketika Anda harus mengalihkan semua URL ke 301 URL baru? Jumlah halaman akan lebih dari satu juta, dan Anda ingin meminimalkan efek kotak pasir? Jika ada efek sandbox, berapa lama itu bisa terjadi? Apakah kami akan kehilangan peringkat yang mungkin tidak akan pernah kami pulihkan? Kami berencana melakukan pengalihan satu-ke-satu, dan telah meminta pengalihan batch, tetapi itu tidak mungkin, jadi halaman, gambar, URL, dll. harus dibalik pada saat yang bersamaan”.

Seperti yang dikatakan John: “Bagi saya, ini terdengar seperti situasi pemindahan situs tradisional. Anda berpindah dari satu domain ke domain lain, dan Anda mengalihkan semua URL dari situs lama Anda ke situs baru, dan kami harus menanganinya […]. Jelas tidak ada yang didefinisikan sebagai efek kotak pasir di pihak kami dalam hal pemindahan situs . Jadi jika Anda harus melakukan pemindahan situs, maka lakukan pemindahan situs, dan arahkan ulang semua halaman Anda. Seringkali pendekatan termudah adalah dengan mengarahkan ulang semua halaman sekaligus. Sistem kami juga sedikit menyesuaikannya untuk mencoba mengenalinya. Jadi, ketika kami melihat bahwa sebuah situs web mulai mengalihkan semua halaman ke situs web yang berbeda, maka kami akan mencoba memproses ulang itu sedikit lebih cepat sehingga kami dapat memproses pemindahan situs itu secepat mungkin. Dan itu jelas bukan kasus yang kami katakan, oh, mereka melakukan pemindahan situs, oleh karena itu, kami akan memperlambatnya […]”.

API dan anggaran perayapan

46:13 “Saya memiliki situs web yang terhubung ke API di sisi klien untuk mendapatkan data. Apakah URL tersebut termasuk dalam anggaran perayapan? Jika Anda melarang URL tersebut, […] apakah itu akan menimbulkan masalah?”

“[…] Jika API ini disertakan saat halaman dirender, maka ya, mereka akan disertakan dalam perayapan, dan pada dasarnya akan diperhitungkan dalam anggaran perayapan Anda karena kami harus merayapi URL tersebut untuk merender halaman. Anda dapat memblokirnya dengan robots.txt jika Anda menginginkannya tidak dirayapi atau tidak digunakan selama rendering. Terserah Anda jika Anda lebih suka melakukan itu. Terutama jika Anda memiliki API yang agak mahal untuk dipelihara atau membutuhkan banyak sumber daya, terkadang hal itu masuk akal.

Bagian yang sulit, saya kira, adalah jika Anda melarang perayapan titik akhir API Anda, kami tidak akan dapat menggunakan data apa pun tentang pengembalian API untuk pengindeksan. Jadi, jika konten laman Anda murni berasal dari API, dan Anda melarang perayapan API, kami tidak akan memiliki kontak itu. […] Jika API hanya melakukan sesuatu yang melengkapi halaman, seperti mungkin menggambar peta atau […] grafik tabel numerik yang Anda miliki di halaman, […] maka mungkin tidak masalah jika konten itu tidak ' tidak termasuk dalam pengindeksan. Hal lainnya adalah terkadang, tidak sepele bagaimana halaman berfungsi saat API diblokir. Khususnya, jika Anda menggunakan JavaScript dan panggilan API diblokir karena robots.txt, maka Anda harus menangani pengecualian itu. Dan tergantung pada bagaimana Anda menyematkan JavaScript pada halaman, apa yang Anda lakukan dengan API, Anda perlu memastikan bahwa itu masih berfungsi. Jadi, jika panggilan API itu tidak berfungsi, dan rendering halaman lainnya berhenti total, maka kita tidak dapat mengindeks banyak karena tidak ada yang tersisa untuk dirender.

Namun, jika panggilan API terputus, dan kami masih dapat mengindeks sisa halaman Anda, maka itu mungkin baik-baik saja. […] Saya pikir itu lebih sulit jika Anda menjalankan API untuk orang lain, karena jika Anda melarang perayapan, Anda memiliki efek urutan kedua ini bahwa situs web orang lain mungkin bergantung pada API Anda. Dan tergantung pada apa yang dilakukan API Anda, lalu tiba-tiba, situs web mereka tidak memiliki konten yang dapat diindeks. Dan mereka mungkin tidak menyadarinya karena mereka tidak menyadari bahwa tiba-tiba, Anda menambahkan larangan di sana. Dan itu mungkin menyebabkan semacam efek tidak langsung […]”.

JavaScript dan cache Google

49:36 “Jadi ada dua halaman yang berasal dari domain yang sama. URL sedikit berbeda, yang merupakan bagian dari struktur direktori yang sama. Dan […] mereka dihasilkan oleh NextJS. Jadi NextJS adalah kerangka reaksi yang diberikan sisi server. Dan mereka sedang diindeks, tetapi saya melihat satu halaman di cache Google, dan halaman kedua tidak ada di cache Google. Dan saya melihat pola yang sama terlepas dari bagaimana saya membuat halaman […]. Sebagian besar halaman saya ada di cache Google, tetapi sekarang saya khawatir karena saat ini saya sedang berpindah dari tumpukan teknologi berbasis Java, yang menghasilkan semua halaman ini, ke Google NextJS. […] Saat saya melakukan debug, saya menemukan bahwa ini juga merupakan masalah dengan tumpukan Java lama yang kami gunakan.

Jadi pertanyaannya adalah dua bagian. Pada dasarnya, mengapa perilaku ini? Dan kedua, apakah perilaku ini akan memengaruhi peringkat saya? Saya melihat halaman-halaman itu muncul di hasil pencarian yang tidak ada di cache Google”.

John menjawab: “[…] Halaman cache benar-benar terpisah dari apa yang kami indeks. Jadi jika ada halaman cache atau tidak, tidak masalah sama sekali untuk peringkat, tidak masalah sama sekali untuk pengindeksan . Terkadang, ada alasan teknis mengapa kami tidak memiliki halaman cache. Terkadang, kami tidak memiliki halaman cache untuk URL individual. Hal lain adalah jika halaman menggunakan kerangka JavaScript, maka apakah JavaScript berjalan di halaman cache terkadang rumit, karena halaman cache dihosting di domain Google. Bergantung pada jenis JavaScript yang Anda miliki, di mana ia menarik file JavaScript, terkadang JavaScript tidak dapat berjalan di domain Google.

[…] Halaman cache bukanlah halaman yang dirender. Ini pada dasarnya hanya file HTML yang kami minta, dan salinannya. Dan jika file HTML menunjukkan sesuatu, tidak apa-apa. Jika menggunakan JavaScript, dan JavaScript tidak berjalan karena ini adalah halaman cache, itu juga tidak masalah. Anda hanya tidak melihatnya di halaman cache. Jadi jika halaman cache tidak muncul, saya tidak akan khawatir tentang itu. Itu bukan pertanda masalah apa pun. Dan seringkali, […] Anda tidak dapat mengontrol apakah ada halaman cache atau tidak. Saya akan mengabaikannya begitu saja”.

https://www.youtube.com/watch?v=Vd0rEQrwHDc