5 Maret 2019 – Catatan Hangout Bantuan Google

Kami bergabung dengan John Mueller di rumahnya di Hangout Bantuan Webmaster ini. Kami memiliki beberapa pertanyaan bagus tentang Kecepatan Halaman, hreflang, dan Tautan Balik. Video dan transkripsi lengkap dapat ditemukan setelah musim panas kami. Jika Anda menyukai ini, pertimbangkan untuk mendaftar ke buletin mingguan kami! Kami merangkum artikel SEO terbaik minggu ini dalam gigitan yang mudah dicerna.

Bisakah Anda menjelaskan masalah dengan menggunakan json - ld melalui pengelola tag?

11:18

Jadi saya pikir apa yang telah kita bicarakan cukup sering dan banyak hangout ini juga dan ada posting blog baru yang ditulis tentang ini juga dari berbagai orang termasuk Barry juga. Tapi pada dasarnya itu kembali ke, bagi kita untuk dapat menarik konten dari pengelola tag berarti kita harus dapat membuat proses JavaScript file skrip dari pengelola tag dan menampilkan tulisan di sana dan menyertakan sisi pengindeksan. Jadi itu adalah sesuatu yang selalu membutuhkan banyak pekerjaan untuk sistem kami dan tidak selalu sesuatu yang kami lakukan untuk semua halaman, khususnya ketika kami melihat bahwa halaman tersebut akan sama, maka agak sulit bagi sistem kami untuk membenarkannya. kita juga perlu memproses semua JavaScript ini. Dan di atas semua itu, banyak alat pengujian yang tidak memproses tag manager dan output sehingga sangat sulit bagi alat untuk mengonfirmasi bahwa markup ini berfungsi dengan benar. Diperlukan waktu lebih lama untuk diproses dalam pencarian. Ini mungkin sedikit terkelupas dan Anda tidak benar-benar tahu persis apa yang diindeks pada waktu tertentu. Jadi itu semua alasan mengapa saya dari sudut pandang saya boleh saja menggunakan tag manager untuk hal lain. Tidak apa-apa menggunakannya untuk ini juga untuk JsonLD untuk data terstruktur dalam pencarian, tetapi perlu diingat bahwa ini bukan pendekatan yang bagus untuk data terstruktur terutama dalam pencarian. Ini adalah cara yang jauh lebih mudah untuk menyediakan data struktur langsung di halaman web, memudahkan pemeliharaan, memudahkan pelacakan untuk menguji semua itu. Jadi itulah yang saya sarankan untuk melakukan itu, saya tidak mengatakan Anda tidak dapat menggunakan tag manager di sini untuk ini Anda pasti dapat menggunakannya dan kami akan mencoba yang terbaik untuk mengambilnya dan menggunakannya dan semacamnya tetapi itu tidak cukup tingkat kecepatan dan fleksibilitas yang sama, keamanan ketika benar-benar menyediakan struktur data langsung di halaman.

Ringkasan: Meskipun dimungkinkan untuk menggunakan JSON-LD dan data terstruktur lainnya melalui Google Pengelola Tag, ini bukan pendekatan terbaik. Agar Google menarik formulir konten Pengelola Tag dan harus merender JavaScript. Proses script dari Tag Manager dan output tulisannya lalu index. Ada cara mudah untuk menyediakan data terstruktur langsung di halaman yang memudahkan di Google.

Bagaimana cara Google memilih URL untuk ditampilkan di Penelusuran?

15:20

Jadi jenis ini masuk ke pertanyaan umum tentang bagaimana Google memilih URL untuk ditampilkan dalam pencarian dan di satu sisi ada aspek dalam hal ini seperti halaman arahan untuk gambar 1 memiliki rel kanonik yang disetel untuk melihat semua halaman, akan berarti halaman-halaman ini tidak setara. Jadi semacam hit atau miss kita akan mengambil dan menggunakan kanonik itu sama sekali, itu saya pikir satu aspek yang perlu diingat. Hal lain yang perlu diingat adalah bahwa meskipun kami memahami bahwa halaman-halaman ini dapat dilihat sebagai setara, itu adalah masalah kami menggunakan beberapa faktor untuk menentukan halaman mana yang benar-benar kanonik. Jadi untuk itu, kami menggunakan rel canonical, kami menggunakan redirect jika ada. Kami menggunakan tautan eksternal internal, kami menggunakan hal-hal seperti peta situs, tautan hreflang, semua itu membantu kami memahami URL mana yang harus kami tampilkan dan jika URL kanonik yang Anda tentukan adalah salah satu yang tidak pernah Anda gunakan dalam sisanya dari situs web Anda, maka kemungkinan besar kami akan mengatakan, menjadikan tautan itu rel kanonik adalah kesalahan yang sebenarnya tidak dimaksudkan oleh webmaster, dan mungkin kami harus memilih URL yang berbeda sebagai kanonik. Jadi saya kira apa yang akan terjadi di sini adalah apakah kita akan mengabaikan rel canonical karena ini bukan hal yang sama atau kita akan memilih salah satu halaman lain yang ada sebagai gantinya karena itu salah satu halaman yang seperti sangat terkait di dalam situs web. Jadi saya tidak berpikir pengaturan khusus ini akan berguna dalam kasus Anda.

Ringkasan: Google menggunakan rel kanonik, pengalihan, tautan internal, peta situs, hreflang untuk memahami dengan URL adalah yang harus ditampilkan oleh Google. Tetapi jika URL kanonik yang ditentukan adalah salah satu yang tidak pernah digunakan dalam sisa situs Anda, Google dapat mengabaikan rel kanonik dan memilih halaman lain yang sangat terkait secara internal.

Apakah ide yang baik untuk menyertakan penulis di posting blog daripada pengguna editor umum?

17:38

Saya pikir itu langkah yang baik seperti terutama jika Anda tahu siapa yang menulis artikel itu awalnya dan Anda dapat memperlakukannya seperti halaman arahan penulis, saya pikir itu langkah yang bagus. Bahkan hanya dari sudut pandang pengguna murni jika seseorang pergi ke situs web Anda dan mereka tiba-tiba melihat oh artikel ini ditulis oleh Barry, bukan hanya editor dan Anda memiliki halaman arahan untuk penulis itu maka itu bisa menjadi tanda bahwa itu lebih baik untuk pengguna yang bisa menjadi sesuatu yang diambil pengguna atau mereka pergi ke halaman arahan penulis dan melihat oh penulis ini sebenarnya ahli di bidang ini dan telah aktif di sana selama beberapa tahun itu, saya pikir selalu berguna untuk memiliki situs web di umum, dan sehubungan dengan peringkat Google, sulit untuk mengatakan apakah itu akan memiliki efek langsung sama sekali. Tetapi setidaknya efek tidak langsung adalah bahwa pengguna mungkin lebih mempercayai konten Anda seperti yang direkomendasikan atau saya pikir itu adalah sesuatu yang diharapkan.

Ringkasan: Ya! Memiliki halaman arahan penulis adalah cara untuk menunjukkan MAKAN penulis Anda. Ini juga akan meningkatkan pengalaman pengguna secara umum dibandingkan dengan memiliki "Editor" atau "Admin" generik

Apa rekomendasinya jika UI Anda dapat diterjemahkan ke bahasa lain tetapi konten tambahan, seperti konten yang dibuat pengguna, tetap dalam bahasa lain?

21:48

Jadi ini adalah sesuatu yang cukup sering terjadi terutama untuk konten yang dibuat pengguna. Jadi jika Anda memiliki forum atau blog atau sesuatu dan orang-orang berkomentar dalam satu bahasa tetapi Anda telah menyiapkannya sehingga UI dapat berubah ke bahasa lain. Kemudian Anda dengan cepat memiliki situasi di mana UI bisa dalam bahasa Prancis atau Jerman tetapi kontennya mungkin masih dalam bahasa Spanyol misalnya karena semua orang berkomentar dalam bahasa Spanyol dan itu pada dasarnya adalah sesuatu yang dapat Anda tangani dengan berbagai cara. Jadi Anda dapat mengatakan bahwa versi kanonik saya adalah versi Spanyol dan semuanya sama seperti versi Spanyol, itulah salah satu opsi yang dapat Anda lakukan. Anda dapat menggunakan anotasi hreflang di antara versi-versi itu untuk mengatakan ini adalah versi paling Prancis dari konten saya yang dapat saya berikan, konten utama bukan dalam bahasa Prancis tetapi UI dalam bahasa Prancis sehingga pengguna yang membuka halaman akan dapat bernavigasi di sekitar website saya itu sesuatu yang bisa Anda lakukan. Dan pada dasarnya itu adalah variasi berbeda yang dapat Anda berikan di sana untuk memberi tahu kami sedikit lebih banyak tentang preferensi Anda. Dari sudut pandang praktis itu pada akhirnya lebih terserah Anda sehubungan dengan bagaimana Anda ingin ditampilkan dalam pencarian. Jadi, jika menurut Anda itu berguna bagi pengguna Prancis untuk datang ke situs Anda dan membuka halaman dengan konten dalam bahasa Spanyol dan UI dalam bahasa Prancis, lalu gunakan anotasi hreflang di antara versi tersebut. Jika Anda berpikir bahwa pengguna di Prancis akan mengalami kesulitan menavigasi situs Anda sama sekali jika konten utama dalam bahasa Spanyol meskipun UI dalam bahasa Prancis, maka mungkin masuk akal untuk hanya menyimpan versi Spanyol dengan UI Spanyol yang diindeks. Jadi pada akhirnya terserah Anda, saya pikir tidak satu pun dari ini adalah solusi sempurna. Terkadang itu sedikit tergantung pada seberapa seragam konten Anda, seberapa jelas Anda memahami versi bahasa mana yang ingin Anda indeks dan versi mana yang diharapkan pengguna untuk dilihat dalam hasil pencarian. Jadi misalnya jika Anda adalah forum yang sangat internasional dan orang-orang memposting dalam semua jenis bahasa yang berbeda maka mungkin sulit untuk mengatakan seperti Anda hanya ingin versi UI ini diindeks mungkin masuk akal untuk memiliki semua versi UI diindeks. Kelemahan tentu saja memiliki semua versi UI yang diindeks adalah mengalikan jumlah url Anda yang tiba-tiba dimiliki situs Anda. Jadi itu berarti kami harus merayapi lebih banyak dan jika itu adalah situs konten buatan pengguna yang besar itu berarti kami harus merayapi, di satu sisi semua konten yang dibuat pengguna dan kemudian kami harus merayapi semua kelipatannya untuk masing-masing yang berbeda versi bahasa, yang saya tidak tahu apakah itu berguna, jika itu terlalu banyak merayapi situs web Anda jika itu mencegah konten yang mungkin lebih baru muncul dengan cepat di hasil pencarian. Itu sesuatu yang lain untuk ditimbang di sana. Jika Anda hanya berbicara tentang beberapa ribu artikel, itu mungkin bukan masalah.

Ringkasan: Anda dapat memilih satu versi bahasa sebagai versi kanonik atau Anda dapat menambahkan anotasi hreflang di antara versi bahasa tersebut.

Haruskah saya menolak sejumlah besar url acak yang tertaut ke situs saya?

27:58

Tidak, itu pada dasarnya adalah langkah yang tepat untuk dilakukan dan terutama jika itu adalah sesuatu yang benar-benar Anda khawatirkan. Jadi saya pikir untuk sebagian besar situs web tidak masuk akal untuk pergi ke sana dan menolak hal-hal yang seperti rapuh dan aneh karena sebagian besar kita mengabaikannya. Jadi khususnya berkaitan dengan tautan, jika itu adalah sesuatu yang ketika Anda melihatnya Anda katakan dengan baik, ini dapat dilihat karena tautan ini dibeli oleh kami, seperti yang secara alami ditempatkan di sana oleh kami, jika seseorang dari tim situs web akan mengambil lihat ini secara manual dan mereka akan berasumsi bahwa, ini adalah kami melakukan sesuatu yang bodoh, itu adalah hal di mana saya akan mengatakan mungkin menolak mereka atau menghapusnya akan menjadi langkah yang tepat di sana tetapi sebaliknya jika itu hanya tautan yang rapuh dan itu sepertinya ada jutaan tautan lain di sana seseorang menjalankan alat dan menjatuhkan banyak tautan ke forum ini, maka itu adalah sesuatu yang sudah diketahui oleh algoritme kami. Jadi itu bukan sesuatu yang saya tidak khawatirkan.

Ringkasan: Google pandai mencari tahu tautan mana yang harus diabaikan. Tapi lebih baik aman daripada menyesal ketika harus mengingkari.

Seberapa penting kecepatan halaman bagi Google?

42:30

Apa kebijakan saat ini? Jadi kecepatan adalah sesuatu yang cukup penting bagi kami dan memiliki efek besar pada pengguna jadi itu adalah sesuatu yang saya pribadi akan menganggapnya cukup serius dan saya pikir bagian yang bagus tentang kecepatan adalah ada berbagai alat yang memberi Anda ukuran yang cukup objektif di sana yang benar-benar dapat Anda kerjakan. Sehubungan dengan banyak dari kita atau masalah lain seputar SEO seperti, saya tidak tahu kualitas konten mereka, hal-hal seperti kecepatan itu adalah sesuatu yang cukup terukur dan sesuatu yang dapat Anda kerjakan, dan itu juga harus sesuatu yang kami gunakan merupakan efek langsung dari perilaku pengguna Anda dalam situs web Anda. Jadi itu bukan hanya sesuatu yang dari sudut pandang Google seperti yang kami katakan kecepatan itu penting, ini adalah pelacak peringkat, tetapi itu adalah sesuatu yang akan Anda lihat secara langsung ketika pengguna datang ke situs web Anda dan situs web Anda tiba-tiba membutuhkan waktu beberapa detik lebih lama untuk memuat pengguna tersebut. akan bereaksi sangat berbeda di situs web Anda dan Anda akan mengalami lebih banyak masalah dalam mengubahnya menjadi pelanggan bagaimanapun Anda mendefinisikan pelanggan di situs web Anda.

Ringkasan: Kecepatan sangat penting dalam kaitannya dengan Google. Ini adalah salah satu metrik yang mudah dilacak dan ditindaklanjuti dengan mudah. Ada alat hebat yang memberikan wawasan hebat tentang kinerja situs Anda dan apa yang dapat Anda lakukan untuk membantu meningkatkan kecepatan halaman.

Jika saya membayar untuk Google Ads, apakah peringkat saya akan lebih baik atau lebih buruk?

47:24

Jadi kami mendapatkan pertanyaan ini sesekali dan pertanyaan di sini seperti, apakah peringkat saya akan terpengaruh tetapi bagian yang lebih baik atau terburuk adalah sesuatu yang kami juga mendengar beberapa orang berkata, bahwa peringkat Anda tidak akan menjadi lebih baik jika Anda menggunakan Google Ads beberapa orang mengatakan peringkat Anda akan turun jika Anda menggunakan iklan Google karena kami ingin Anda membeli lebih banyak iklan dan tidak ada yang benar. Jadi, hasil penelusuran kami sepenuhnya independen dari apakah Anda menggunakan Google Ads atau tidak. Hasil penelusuran kami sepenuhnya independen dari teknologi yang Anda gunakan di situs web Anda. Jadi, jika Anda menggunakan sesuatu seperti analitik atau alat pelacak lain, itu terserah Anda. Jika Anda menghasilkan uang dengan Adsense atau jaringan iklan lainnya, terserah Anda. Jadi apakah Anda menggunakan produk Google dalam situs web Anda atau tidak, Anda menggunakan layanan Google lainnya untuk situs web Anda sepenuhnya terserah Anda. Itu adalah sesuatu yang kami lebih suka memiliki layanan ini yang berdiri sendiri dan jika Anda mengatakan satu alasan khusus ini layanan Google tidak bagus, saya tidak ingin menggunakannya maka jangan ragu untuk menggunakan sesuatu yang lain. Kami tidak ingin menempatkan Anda di dalam kotak di mana Anda seperti terjebak antara fokus pada situs web Anda dan melakukan apa yang menurut Anda tepat untuk pengguna Anda dan harus menggunakan produk yang satu ini. Jadi sebenarnya kami tidak mengikat ini bersama-sama dan kami melakukannya secara eksplisit dan kami bekerja keras untuk memastikan bahwa hal-hal ini bekerja dengan baik.

Ringkasan: Iklan Google tidak berpengaruh pada peringkat organik.

Jika Anda menyukai hal-hal seperti ini, Anda akan menyukai buletin saya!

Saya dan tim saya melaporkan setiap minggu tentang pembaruan algoritma Google terbaru, berita, dan tip SEO.

Video Lengkap dan Transkrip

Pertanyaan 1:14 - Dua minggu lalu situs web kami kehilangan 94% lalu lintas Google dalam semalam. Dengan lalu lintas pencarian yang konsisten selama 20 tahun terakhir dan tidak ada perubahan besar, kami menganggap sesuatu yang teknis dapat membagikan IPS atau SSL melalui CDN seperti cloudfare menyebabkan penurunan besar dalam lalu lintas secara algoritme. Kami menggali lebih dalam dan menemukan beberapa situs dengan konten yang tampaknya sangat berisiko pada IP yang sama. Kami dapat mengubah tema kami dan memiliki sertifikat khusus namun kami masih akan macet, apa yang bisa terjadi di sini?

Answer 2:01 - Tetapi secara umum hanya karena situs lain di-host di alamat ip yang sama umumnya tidak perlu dikhawatirkan. Jadi khususnya dengan hoster yang lebih besar, berbagi alamat IP adalah hal yang cukup umum dengan alamat IP bersama CDN adalah hal yang sangat umum. Dan itu adalah sesuatu yang berubah karena banyak CDN memiliki titik akhir di berbagai negara dan mereka berbagi titik akhir tersebut dengan berbagai situs web yang aktif di sana. Jadi pada dasarnya pengguna dan Jerman mungkin melihat alamat IP yang berbeda dibandingkan pengguna di AS misalnya, tetapi secara umum ini adalah praktik yang sangat umum, berbagi alamat IP, dan bukan sesuatu yang akan bermasalah. Pada awalnya, ini adalah sesuatu yang terkadang sangat berguna untuk mengenali tanggal dan tuan rumah. Dimana jika kita melihat satu alamat IP dan 9000 situs yang memiliki alamat statis dan semuanya berisi spam dan jika ada dua situs web lain di host yang sama maka itu mungkin sulit untuk kita sadari seperti, apakah kedua situs ini benar-benar menjadi lengkap? situs terpisah dibandingkan dengan 9.000 situs lainnya. Itu semacam situasi rumit untuk algoritma. Tetapi dalam kebanyakan kasus seperti ini kita akan melihat campuran dari semua jenis situs yang berbeda sehingga situs yang berbeda dalam bahasa yang berbeda untuk negara yang berbeda dengan pengguna target yang berbeda beberapa situs spam beberapa situs non spam pada alamat IP yang sama dan semua itu baik-baik saja . Jadi itu tidak akan menjadi alasan bagi kami untuk mengatakan, oh seperti karena ada satu situs spam di alamat IP ini yang akan menjadi masalah. Jadi saya tidak tahu secara spesifik apa yang terjadi di sini dengan situs web ini. Saya melihat bahwa secara umum juga jenis aspek situs web kami berjalan dengan baik dalam pencarian selama bertahun-tahun sebelum saya cenderung mengatakan itu bagus untuk Anda. situs tapi itu belum tentu sesuatu yang kita akan selalu tetap seperti itu.

Jadi hanya karena situs itu berjalan dengan baik di masa lalu dan pencarian tidak berarti itu akan terus berjalan dengan baik dalam pencarian di satu sisi ya harapan pengguna berubah di sisi lain algoritma Google berubah. Jadi hal-hal ini selalu dapat berubah dan dapat terjadi bahwa hal-hal terkadang berubah secara signifikan dan tujuan kami adalah seperti ini, situs web yang satu ini adalah algoritme yang buruk, melainkan untuk mengatakan bahwa kami telah menyadari bahwa mungkin kami telah melewatkan harapan pengguna atau kami telah melakukan hal-hal dengan cara yang tidak lagi sesuai dengan apa yang diharapkan pengguna sehingga algoritme kami berubah untuk mencoba menghadirkan hasil yang menurut pengguna dan relevan saat ini kembali ke hasil penelusuran. Jadi itu adalah sesuatu yang selalu bisa dimainkan tergantung pada jenis situs webnya.

Pertanyaan 5:49 - Beberapa waktu yang lalu tentang situs yang tampaknya mengungguli kami pada dasarnya mencuri konten kami dan kemudian memodifikasinya sehingga mereka tidak melanggar hak cipta dan kemudian mengungguli kami. Kami melihat polanya ketika kami melihat ke belakang dan melakukan beberapa penelitian yang tampaknya seperti akan mendesain ulang situs kami, meningkatkan kualitas kami, meningkatkan peringkat kemudian mereka akan menyalinnya dan sekitar satu atau dua bulan ke depan kemudian mereka akan mulai peringkat kami dan um tampaknya kami seperti entah bagaimana algoritme bingung dan memberikan kredit situs itu untuk menjadi pencetus konten alih-alih kami dan kemudian menekan kami di peringkat sebagai hasilnya.

Answer 6:37 - Saya tidak tahu, saya harus melihat situsnya untuk melihat apa yang sebenarnya terjadi di sana. Jadi itu agak rumit dari sudut algoritme untuk mengatakan itu, seperti algoritme kami akan selalu memilih situs itu daripada situs Anda untuk kueri tersebut. Tapi apa yang biasanya saya ingin lakukan di sana adalah jika situs-situs ini menyalin konten Anda, lalu coba temukan cara untuk mengatasi hal itu di akarnya untuk mendorong mereka agar tidak menyalin konten Anda. Jadi mungkin melihat hal-hal seperti keluhan DMCA, saya tidak tahu apakah itu relevan dalam kasus Anda atau tidak, tetapi apa pun untuk mencoba menanganinya sedemikian rupa sehingga pencarian tidak harus menebak versi mana dari konten harus diberi peringkat untuk kueri tersebut.

Pertanyaan 11:18 - Bisakah Anda menjelaskan masalah penggunaan json-ld melalui pengelola tag? Pengelola tag digunakan untuk memverifikasi konsol pencarian dan mungkin analitik, jadi pasti cukup stabil.

Answer 11:33 - Jadi saya pikir apa yang telah kita bicarakan cukup sering dan banyak dari hangouts ini juga dan ada posting blog baru yang ditulis tentang ini juga dari berbagai orang termasuk Barry juga. Tapi pada dasarnya itu kembali ke, bagi kita untuk dapat menarik konten dari pengelola tag berarti kita harus dapat membuat proses JavaScript file skrip dari pengelola tag dan menampilkan tulisan di sana dan menyertakan sisi pengindeksan. Jadi itu adalah sesuatu yang selalu membutuhkan banyak pekerjaan untuk sistem kami dan tidak selalu sesuatu yang kami lakukan untuk semua halaman, khususnya ketika kami melihat bahwa halaman tersebut akan sama, maka agak sulit bagi sistem kami untuk membenarkannya. kita juga perlu memproses semua JavaScript ini. Dan di atas semua itu, banyak alat pengujian yang tidak memproses tag manager dan output sehingga sangat sulit bagi alat untuk mengonfirmasi bahwa markup ini berfungsi dengan benar. Diperlukan waktu lebih lama untuk diproses dalam pencarian. Ini mungkin sedikit terkelupas dan Anda tidak benar-benar tahu persis apa yang diindeks pada waktu tertentu. Jadi itulah semua alasan mengapa saya dari sudut pandang saya, boleh saja menggunakan tag manager untuk hal lain. Tidak apa-apa menggunakannya untuk ini juga untuk JsonLD untuk data terstruktur dalam pencarian, tetapi perlu diingat bahwa ini bukan pendekatan yang bagus untuk data terstruktur terutama dalam pencarian. Ini adalah cara yang jauh lebih mudah untuk menyediakan data struktur langsung di halaman web, memudahkan pemeliharaan, memudahkan pelacakan untuk menguji semua itu. Jadi itulah yang saya sarankan untuk melakukan itu, saya tidak mengatakan Anda tidak dapat menggunakan tag manager di sini untuk ini, Anda pasti dapat menggunakannya dan kami akan mencoba yang terbaik untuk mengambilnya dan menggunakannya dan semacamnya tetapi ternyata tidak tingkat yang sama dari jenis kecepatan dan fleksibilitas, keamanan ketika datang untuk benar-benar menyediakan data struktur langsung di halaman.

Pertanyaan 14:00 - Seorang klien melakukan migrasi HTTPs dengan berpindah menggunakan 302 bukannya 301 apakah mereka perlu mengubahnya menjadi 301? Berapa lama waktu yang dibutuhkan Google untuk memahami bahwa ini adalah pengalihan permanen?

Jawaban 14:14 - Jadi mungkin kami akan menemukan bahwa banyak orang menggunakan tag pengalihan yang salah untuk pemindahan situs dan kami masih berusaha untuk mencari tahu dengan benar. Cara cepat untuk melihat apa yang terjadi adalah dengan memeriksa di konsol pencarian untuk melihat apakah sesuatu diindeks dengan benar. Jadi, jika domain baru berfungsi dengan baik, itu mungkin sudah tidak apa-apa. Yang mengatakan jika Anda telah mengenali masalah seperti ini atau masalah teknis lainnya di situs web yang mudah diperbaiki dan merasa seperti itu mungkin berdampak besar, maka kami akan melanjutkan dan memperbaikinya. Terutama jenis pengalihan yang salah, seperti perubahan satu baris dalam file htaccess di sebagian besar situs web. Jadi itu adalah sesuatu yang sangat mudah untuk diperbaiki. Sehingga Anda tidak perlu khawatir mesin pencari menafsirkannya dengan cara yang salah.

Pertanyaan 15:20 - Galeri gambar kami memiliki URL unik untuk gambar seperti /gallery/image1 atau /image2 atau /image 3 dan kami ingin menambahkan galeri /lihat semua dan menggunakan ini sebagai url kanonik tetapi kami tidak memiliki tautan ini di mana saja di situs kita bisa melakukan itu? Apakah semua tampilan harus terlihat oleh pembaca?

Jawaban 15:46 - Jadi pertanyaan umum seperti ini tentang bagaimana Google memilih URL untuk ditampilkan dalam pencarian dan di satu sisi ada aspek dalam hal ini seperti halaman arahan untuk gambar 1 yang memiliki set kanonik rel ke melihat semua halaman, berarti halaman-halaman ini tidak setara. Jadi semacam hit atau miss kita akan mengambil dan menggunakan kanonik itu sama sekali, itu saya pikir satu aspek yang perlu diingat. Hal lain yang perlu diingat adalah bahwa meskipun kami memahami bahwa halaman-halaman ini dapat dilihat sebagai setara, itu adalah masalah kami menggunakan beberapa faktor untuk menentukan halaman mana yang benar-benar kanonik. Jadi untuk itu kami menggunakan rel canonical, kami menggunakan redirect jika ada apa-apa. Kami menggunakan tautan eksternal internal, kami menggunakan hal-hal seperti peta situs, tautan hreflang, semua itu membantu kami memahami URL mana yang harus kami tampilkan dan jika URL kanonik yang Anda tentukan adalah salah satu yang tidak pernah Anda gunakan dalam sisanya dari situs web Anda, maka kemungkinan besar kami akan mengatakan, menjadikan tautan itu rel kanonik adalah kesalahan yang sebenarnya tidak dimaksudkan oleh webmaster, dan mungkin kami harus memilih URL yang berbeda sebagai kanonik. Jadi saya kira apa yang akan terjadi di sini adalah apakah kita akan mengabaikan rel canonical karena ini bukan hal yang sama atau kita akan memilih salah satu halaman lain yang ada sebagai gantinya karena itu salah satu halaman yang seperti sangat terkait di dalam situs web. Jadi saya tidak berpikir pengaturan khusus ini akan berguna dalam kasus Anda.

Pertanyaan 17:38 - Apa rekomendasi Anda untuk situs yang memiliki banyak konten yang ingin mereka sediakan untuk bahasa dan negara lain tetapi mereka hanya menerjemahkan antarmuka sejauh ini, jadi bukan konten utama.

Answer 17:55 - Jadi ini adalah sesuatu yang sering terjadi terutama untuk konten yang dibuat pengguna. Jadi jika Anda memiliki forum atau blog atau sesuatu dan orang-orang berkomentar dalam satu bahasa tetapi Anda telah menyiapkannya sehingga UI dapat berubah ke bahasa lain. Kemudian Anda dengan cepat memiliki situasi di mana UI bisa dalam bahasa Prancis atau Jerman tetapi kontennya mungkin masih dalam bahasa Spanyol misalnya karena semua orang berkomentar dalam bahasa Spanyol dan itu pada dasarnya adalah sesuatu yang dapat Anda tangani dengan berbagai cara. Jadi Anda dapat mengatakan bahwa versi kanonik saya adalah versi Spanyol dan semuanya sama seperti versi Spanyol, itulah salah satu opsi yang dapat Anda lakukan. Anda dapat menggunakan anotasi hreflang di antara versi-versi itu untuk mengatakan ini adalah versi paling Prancis dari konten saya yang dapat saya berikan, konten utama bukan dalam bahasa Prancis tetapi UI dalam bahasa Prancis sehingga pengguna yang membuka halaman akan dapat bernavigasi di sekitar website saya itu sesuatu yang bisa Anda lakukan. Dan pada dasarnya itu adalah variasi berbeda yang dapat Anda berikan di sana untuk memberi tahu kami sedikit lebih banyak tentang preferensi Anda. Dari sudut pandang praktis itu pada akhirnya lebih terserah Anda sehubungan dengan bagaimana Anda ingin ditampilkan dalam pencarian. Jadi, jika menurut Anda itu berguna bagi pengguna Prancis untuk datang ke situs Anda dan membuka halaman dengan konten dalam bahasa Spanyol dan UI dalam bahasa Prancis, lalu gunakan anotasi hreflang di antara versi tersebut. Jika Anda berpikir bahwa pengguna di Prancis akan mengalami kesulitan menavigasi situs Anda sama sekali jika konten utama dalam bahasa Spanyol meskipun UI dalam bahasa Prancis, maka mungkin masuk akal untuk hanya menyimpan versi Spanyol dengan UI Spanyol yang diindeks. Jadi pada akhirnya terserah Anda, saya pikir tidak satu pun dari ini adalah solusi sempurna. Terkadang itu sedikit tergantung pada seberapa seragam konten Anda, seberapa jelas Anda memahami versi bahasa mana yang ingin Anda indeks dan versi mana yang diharapkan pengguna untuk dilihat dalam hasil pencarian. Jadi misalnya jika Anda adalah forum yang sangat internasional dan orang-orang memposting dalam semua jenis bahasa yang berbeda maka mungkin sulit untuk mengatakan seperti Anda hanya ingin versi UI ini diindeks mungkin masuk akal untuk memiliki semua versi UI diindeks. Kelemahan tentu saja memiliki semua versi UI yang diindeks adalah mengalikan jumlah url Anda yang tiba-tiba dimiliki situs Anda. Jadi itu berarti kami harus merayapi lebih banyak dan jika itu adalah situs konten buatan pengguna yang besar itu berarti kami harus merayapi, di satu sisi semua konten yang dibuat pengguna dan kemudian kami harus merayapi semua kelipatannya untuk masing-masing yang berbeda versi bahasa, yang saya tidak tahu apakah itu berguna, jika itu terlalu banyak merayapi situs web Anda jika itu mencegah konten yang mungkin lebih baru muncul dengan cepat di hasil pencarian. Itu sesuatu yang lain untuk ditimbang di sana. Jika Anda hanya berbicara tentang beberapa ribu artikel, itu mungkin bukan masalah.

Pertanyaan 21:25 - Kami memiliki blog yang berjalan bersama situs web e-commerce kami sejak awal posting blog ditandai sebagai ditulis oleh pengguna editor umum. Melihat pedoman kualitas dan EAT kami ingin mengganti editor dengan nama asli penulis posting, apakah operasi semacam ini positif atau mungkinkah melihat spam?

Answer 21:48 - Saya pikir itu langkah yang bagus terutama jika Anda tahu siapa yang menulis artikel itu awalnya dan Anda dapat memperlakukannya seperti halaman arahan penulis. Saya pikir itu langkah yang bagus. Bahkan hanya dari sudut pandang pengguna murni jika seseorang pergi ke situs web Anda dan mereka tiba-tiba melihat oh artikel ini ditulis oleh Barry, bukan hanya editor dan Anda memiliki halaman arahan untuk penulis itu maka itu bisa menjadi tanda bahwa itu lebih baik untuk pengguna yang bisa menjadi sesuatu yang diambil pengguna atau mereka pergi ke halaman arahan penulis dan melihat oh penulis ini sebenarnya ahli di bidang ini dan telah aktif di sana selama beberapa tahun itu, saya pikir selalu berguna untuk memiliki situs web di umum, dan sehubungan dengan peringkat Google, sulit untuk mengatakan apakah itu akan memiliki efek langsung sama sekali. Tetapi setidaknya efek tidak langsung adalah bahwa pengguna mungkin lebih mempercayai konten Anda seperti yang direkomendasikan atau saya pikir itu adalah sesuatu yang diharapkan.

Pertanyaan 22:58 - Skema markup dengan versi desktop dan amp, apakah boleh jika versi desktop diimplementasikan menggunakan microdata tetapi versi amp menggunakan json-ld?

Answer 23:09 - Tentu tidak apa-apa. Berkenaan dengan format atau yang digunakan di sana, saya tidak melihat masalah dengan itu, satu-satunya hal yang perlu diingat adalah sejauh yang saya tahu beberapa jenis data terstruktur hanya tersedia di json-ld. Jadi itu mungkin sesuatu di mana Anda perlu memeriksa ulang jenis data terstruktur yang Anda gunakan tetapi memiliki satu versi situs Anda menggunakan satu jenis data struktur di versi lain menggunakan jenis yang berbeda, bahkan dalam desktop seluler yang sama variasi aplikasi, itu pasti mungkin jadi misalnya jika Anda memiliki blog mungkin, saya tidak tahu, direktori produk di situs web dan situs e-niaga Anda dan situs e-niaga memiliki ulasan yang menggunakan json-ld dan blog Anda menggunakan markup artikel yang menggunakan data mikro, saya tidak tahu apakah itu cara yang tepat untuk melakukannya, tetapi itu akan baik-baik saja.

Pertanyaan 24:19 - Mengenai tampilan konten tersembunyi: tidak ada yang oke, dukungan Google dan telah menyebutkan bahwa font putih latar belakang putih atau ukuran font nol akan melanggar pedoman tetapi bagaimana dengan tampilan: tidak ada?

Answer 24:32 - Konten tersembunyi umumnya bukanlah sesuatu yang kami hargai. Secara khusus itu muncul sebagai situs yang mencoba memasukkan kata kunci ke dalam indeks Google yang sebenarnya tidak terlihat di halaman itu sendiri. Jadi itu adalah sesuatu yang saya benar-benar akan hindari. Anda menyebutkan desain responsif dan sisa pertanyaan Anda, saya pikir itulah satu-satunya aspek yang berperan di sini. Jadi jika Anda menggunakan desain responsif untuk membuat konten ini terlihat oleh pengguna seluler atau pengguna desktop, maka itu tidak masalah. Tetapi jika konten ini pada dasarnya selalu tidak terlihat seperti font dengan nol atau font putih pada latar belakang putih atau font hitam pada latar belakang hitam maka itu adalah hal-hal yang sistem kami akan ambil dan katakan dengan baik mungkin teks ini di sini tidak relevan seperti sebaliknya dan dari sudut pandang praktis Anda mungkin tidak akan mendapatkan tindakan manual dari untuk sesuatu seperti ini. Tetapi selain dengan mencoba mencari tahu ini dan mereka akan mencoba untuk mendevaluasi konten itu ketika datang ke pencarian. Sehingga kecil kemungkinannya untuk ditampilkan dalam cuplikan, kecil kemungkinannya untuk diperlakukan sebagai sangat penting di halaman tersebut.

Pertanyaan 25:55 - Setelah tautan tindakan manual, berapa lama Google memperlakukan domain setelah permintaan pertimbangan ulang diterima tetapi tidak mendapatkan kembali potensi peringkat mereka dalam lalu lintas?

Answer 26:08 - Jadi saya pikir mereka adalah dua aspek di satu sisi jika tindakan manual diselesaikan maka hampir secara langsung situs itu akan terlihat dalam pencarian tanpa tindakan manual itu. Jadi, ada satu pengecualian di sini di mana jika sebuah situs dihapus karena alasan spam murni, maka pada dasarnya situs tersebut akan dihapus dari indeks kami sepenuhnya. Jadi bukan berarti kami dapat menyalakannya kembali dan menampilkannya lagi. Ini akan mengharuskan kami untuk benar-benar merayapi ulang dan terkadang kami memproses situs tersebut yang memerlukan waktu beberapa minggu, tetapi untuk semua tindakan manual lainnya, tindakan manual tersebut diselesaikan dan hal-hal lain kembali ke keadaan sebelumnya bukan karena Google menyimpan dendam dan mengatakan baik ada tindakan manual di sini atau jadi saya harus ekstra hati-hati itu benar-benar diselesaikan itu diselesaikan. Sehubungan dengan tautan, tentu saja jika situs Anda diberi peringkat artifisial dalam hasil pencarian karena tautan yang tidak wajar dan Anda mendapat tindakan manual dan Anda memperbaikinya dengan menghapus tautan tidak wajar ini, maka tentu saja situs Anda tidak akan diberi peringkat lebih tinggi secara artifisial karena tautan tidak wajar itu telah hilang sekarang. Jadi itu adalah sesuatu di mana akan sangat normal untuk melihat perubahan visibilitas setelah menyelesaikan sesuatu seperti itu, sama halnya jika jika sebuah situs terlihat secara tidak wajar karena hal-hal lain di situs web Anda dan Anda menyelesaikannya dengan menghapus hal-hal lain itu maka jelas situs Anda akan terlihat alami lagi tetapi tidak akan terlihat tidak wajar karena hal-hal yang Anda hapus jadi itu sesuatu yang perlu diingat.

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

Answer 47:34 - Jadi kami mendapatkan pertanyaan ini sesekali dan pertanyaan di sini seperti, apakah peringkat saya akan terpengaruh tetapi bagian yang lebih baik atau terburuk adalah sesuatu yang kami juga mendengar beberapa orang berkata, bahwa peringkat Anda tidak akan didapat lebih baik jika Anda menggunakan Google Ads beberapa orang mengatakan peringkat Anda akan lebih rendah jika Anda menggunakan iklan Google karena kami ingin Anda membeli lebih banyak iklan dan tidak ada yang benar. Jadi, hasil penelusuran kami sepenuhnya independen dari apakah Anda menggunakan Google Ads atau tidak. Hasil penelusuran kami sepenuhnya independen dari teknologi yang Anda gunakan di situs web Anda. Jadi, jika Anda menggunakan sesuatu seperti analitik atau alat pelacak lain, itu terserah Anda. Jika Anda menghasilkan uang dengan Adsense atau jaringan iklan lainnya, terserah Anda. Jadi apakah Anda menggunakan produk Google dalam situs web Anda atau tidak, Anda menggunakan layanan Google lainnya untuk situs web Anda sepenuhnya terserah Anda. Itu adalah sesuatu yang kami lebih suka memiliki layanan ini yang berdiri sendiri dan jika Anda mengatakan satu alasan khusus ini layanan Google tidak bagus, saya tidak ingin menggunakannya maka jangan ragu untuk menggunakan sesuatu yang lain. Kami kami tidak ingin menempatkan Anda di kotak di mana Anda seperti terjebak antara fokus pada situs web Anda dan melakukan apa yang menurut Anda tepat untuk pengguna Anda dan harus menggunakan produk yang satu ini. Jadi sebenarnya kami tidak mengikat ini bersama-sama dan kami melakukannya secara eksplisit dan kami bekerja keras untuk memastikan bahwa hal-hal ini bekerja dengan baik.