22 Januari 2019 – Catatan Hangout Bantuan Google

Minggu ini John berada di Big Apple, NYC. Bergabung dengan IRL, dari kiri ke kanan, oleh Martin Splitt dari tim Java Script di Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala dan Quason Carter. Minggu ini ada beberapa pertanyaan bagus tentang Cloudfare, The QRG, dan The New Page Speed ​​Tool. Tautan ke video dan transkrip lengkap dapat ditemukan di bawah!

Apakah Cloudflare terkadang memblokir Googlebot?

7:58

"Ya, saya tidak tahu bagaimana pengaturan Cloudflare saat ini, tetapi saya tahu di masa lalu mereka memblokir orang-orang yang memalsukan Googlebot. Jadi jika Anda menggunakan, seperti milik Anda, saya tidak tahu, Screaming Katak atau semacamnya-- Anda berkata, saya menggunakan agen pengguna Googlebot, lalu mereka akan memblokirnya karena mereka dapat mengatakan, seperti, ini bukan Googlebot yang sah. Kami dapat memblokirnya. Tetapi sebagian besar, saya pikir mereka telah latihan yang cukup untuk mengenali Googlebot normal dan membiarkannya merangkak secara normal."

Ringkasan: Terkadang, saat pengujian, Cloudflare mungkin terlihat memblokir Googlebot. Apa yang mungkin terjadi di sini adalah Cloudflare memblokir orang-orang yang berpura-pura menjadi Googlebot. Jadi, jika Anda menggunakan alat seperti Screaming Frog dan memilih Googlebot sebagai agen pengguna, Anda mungkin tidak dapat merayapi situs menggunakan Cloudflare .

Bisakah tautan tidak wajar masih merusak situs secara algoritme? Jika demikian, dapatkah penggunaan alat penolakan membantu?

14:01

"Saya pikir itu pertanyaan yang bagus. Jadi dari sudut pandang saya, apa yang akan saya lihat di sana, di satu sisi, pasti kasusnya adalah di mana ada tindakan manual. Tapi juga, kasus di mana Anda juga ingin melakukannya. melihat banyak tindakan manual akan berkata, yah, jika tim spam web melihat ini sekarang, mereka akan memberi Anda tindakan manual. Jenis kasus di mana Anda akan mengatakan, tindakan manual lebih merupakan masalah waktu dan bukan semacam itu didasarkan pada sesuatu yang telah dilakukan-- Saya tidak tahu-- di mana itu jelas dilakukan beberapa tahun yang lalu, dan itu semacam batas tidak. Tapi jenis hal di mana Anda melihatnya dan katakan, jika seseorang dari tim spam web mendapatkan ini sebagai tip, mereka akan mengambil tindakan manual, dan itu pasti jenis hal di mana saya akan membersihkannya dan melakukan penolakan untuk itu Ya, saya pikir sulit untuk mengatakan apakah ada timeline tertentu. Tetapi secara umum, jika tim webspam melihat ini dan berkata, seperti, semuanya telah pindah. Ini jelas d satu beberapa tahun yang lalu. Itu tidak sepenuhnya berbahaya. Maka mereka mungkin tidak akan mengambil tindakan manual untuk itu. "

Dan saya berasumsi Anda mungkin tidak dapat menjawab ini, tetapi apakah ada cara yang-- seperti, jadi katakanlah kita tidak mendapatkan tindakan manual, atau mereka tidak mendapatkan tindakan manual. Bisakah tautan itu melukai mereka secara algoritmik? Karena kami merasa kami melihat beberapa peningkatan di beberapa situs, Anda tahu, setelah menolak. Jadi, sekali lagi, saya tahu itu selalu-- tidak pernah hitam dan putih.

Itu pasti bisa. Jadi itu adalah sesuatu di mana algoritme kami ketika kami melihatnya dan mereka melihat, oh, mereka adalah sekelompok tautan yang sangat buruk di sini, maka mungkin mereka akan sedikit lebih berhati-hati sehubungan dengan tautan secara umum untuk situs web. Jadi jika Anda membersihkannya, maka algoritme melihatnya dan berkata, oh, ada-- ada semacam-- tidak apa-apa. Itu tidak buruk.

Ringkasan: Jika Anda memiliki tautan yang dibuat khusus hanya untuk SEO, dan Anda memiliki banyak tautan, itu dapat menyebabkan algoritme Google tidak mempercayai semua tautan Anda. Sebaiknya disavow untuk kasus seperti ini.

Bagaimana algoritme Google mengukur EAT penerbit?

33:40

"Saya tidak tahu. Saya pikir itu mungkin sulit untuk dipecahkan secara algoritmik. Dan jika ada hal teknis apa pun yang harus Anda lakukan, maka kami akan memberi tahu Anda. Jadi jika ada hal-hal seperti markup kepengarangan yang kami memiliki beberapa poin yang kami pikir akan berguna untuk sesuatu seperti ini, kami pasti akan membawanya ke sana. Tetapi banyak hal yang sebenarnya lebih merupakan faktor kualitas lunak yang kami coba cari tahu, dan itu bukan sesuatu yang teknis yang Anda 'sedang melakukan atau tidak melakukan. Ini lebih seperti, mencoba mencari tahu bagaimana pengguna mungkin melihat ini. Jadi bukan sesuatu yang spesifik yang bisa saya tunjukkan. "

Ringkasan: Ada banyak "faktor kualitas lunak" yang dilihat Google. Lihatlah sesuatu dari sudut pandang pengguna. Selain itu, markup kepengarangan dapat membantu Google memahami berbagai hal dengan lebih baik.

Jika ada sesuatu dalam Pedoman Penilai Kualitas, apakah masuk akal untuk berasumsi bahwa Google ingin hal ini tercermin dalam algoritme mereka?

34:44

Saya pikir, secara umum, mungkin praktik yang baik untuk mencapai itu. Saya menghindari mencoba terlalu fokus pada apa yang mungkin digunakan Google sebagai faktor algoritmik dan melihatnya lebih sebagai-- kami pikir ini bagus untuk web, dan, oleh karena itu, kami akan mencoba untuk pergi ke arah itu dan melakukan ini jenis hal. Jadi tidak seperti saya membuat situs web yang bagus hanya agar saya dapat peringkat lebih baik, tetapi saya membuat situs web yang bagus karena ketika saya muncul di pencarian, saya ingin orang-orang memiliki pengalaman yang baik. Dan kemudian mereka akan kembali ke situs web saya, dan mungkin mereka akan membeli sesuatu. Jadi itu arah yang saya lihat, bukan sebagai, seperti, melakukan ini untuk menentukan peringkat, tetapi melakukan ini untuk memiliki hubungan jangka panjang yang sehat di web.

Ringkasan: Pikirkan apa yang terbaik untuk pengguna. Meskipun tidak semua yang ada di QRG saat ini tercermin dalam algoritme Google, ini semua adalah langkah bagus untuk meningkatkan kualitas secara keseluruhan.

Apakah ada skema untuk membantu situs tampil lebih tinggi untuk hasil pencarian suara?

36:10

Aku tidak tahu. Saya tidak bisa memikirkan apa pun begitu saja. Jadi ada markup yang dapat diucapkan yang dapat Anda gunakan, yang mungkin masuk akal untuk-- jenis melihat ke dalam untuk melihat di mana masuk akal pada halaman. Saya rasa kita belum akan menggunakannya di semua lokasi.

Ringkasan: Markup yang dapat diucapkan belum digunakan di semua lokasi geografis. Tapi, ini adalah tempat yang baik untuk memulai.

Beberapa kiat untuk memenangkan cuplikan unggulan

38:03

Tetapi cuplikan unggulan, khususnya, saya rasa kami tidak memiliki jenis markup apa pun yang khusus untuk itu. Jadi itu adalah sesuatu di mana jika Anda memiliki jenis struktur yang jelas pada halaman, itu sangat membantu kami. Jika kita dapat mengenali tabel seperti pada halaman, maka kita dapat menariknya dengan lebih mudah. Sedangkan jika Anda menggunakan HTML dan CSS yang mewah untuk membuatnya terlihat seperti tabel, tetapi sebenarnya itu bukan tabel, maka itu jauh lebih sulit bagi kita untuk menariknya.

Ringkasan: Tidak ada markup yang dapat Anda tambahkan untuk memenangkan cuplikan unggulan. Namun, penggunaan tag h yang baik dan tabel HTML biasa dapat sangat membantu.

Haruskah skema lokasi ditambahkan ke semua halaman?

50:47

Answer 51:42 - Sejauh yang saya tahu, itu hanya halaman rumah. Aku tidak tahu. Apakah kalian ada di antara kalian yang tahu?

Answer from Liz 51:4 7 - Seharusnya hanya satu halaman biasanya dengan organisasi dan perusahaan. Itu umumnya rekomendasi.

MARTIN SPLITT 52:00 - Saya kira tidak masalah yang mana-- tidak masalah sebanyak halaman mana, sama seperti jangan meletakkannya di setiap halaman yang Anda punya, saya kira, adalah bagian yang lebih penting. Saya pikir itu tergantung pada-- jika Anda adalah situs berita, mungkin masuk akal untuk meletakkannya di halaman kontak, atau halaman tentang, atau sesuatu. Sedangkan di website toko atau restoran, mungkin boleh saja ditaruh di homepage.

JOHN 52:20 - Saya pikir juga, dalam hal ini, itu tidak terlalu penting bagi kita karena kita harus dapat menemukannya di suatu tempat seperti halaman rumah atau halaman kontak. Tetapi jika kita memilikinya di tempat lain, itu tidak mengubah apa pun bagi kita. Jadi hal besar yang tidak bisa dibandingkan adalah markup ulasan di mana kita kadang-kadang melihat orang-orang menaruh seperti ulasan perusahaan di semua halaman situs web dengan harapan mendapatkan bintang dan hasil pencarian untuk setiap halaman di situs mereka. Dan itu akan buruk bagi kita. Tapi informasi kontak, jika Anda sudah menandainya, itu-- Saya tidak melihat ada masalah dengan itu.

Ringkasan: Itu tidak terlalu penting. Itu harus ada di halaman kontak dan mungkin halaman tentang dan halaman beranda Anda. Memiliki skema lokasi di seluruh situs bukanlah masalah, tetapi juga tidak mungkin diperlukan.

Mengapa alat PageSpeed ​​Insights baru, berdasarkan Lighthouse jauh lebih sulit saat menilai situs web?

53:05

Marie Haynes: Ini bukan pertanyaan saya, tetapi untuk memberikan beberapa konteks, data Lighthouse baru untuk kecepatan halaman jauh lebih kasar daripada Wawasan Kecepatan Halaman sebelumnya. Jadi sesuatu yang memiliki skor seperti 80 di Page Speed ​​Insights mungkin menjadi 29 merah di Lighthouse. Jadi itu pertanyaan yang bagus. Apakah itu mungkin menyebabkan-- karena kami tahu bahwa di seluler, situs yang sangat lambat dapat diturunkan. Jadi, apakah baik jika kita mengatakan, Anda tahu, jika Anda berada di zona merah dalam tes Lighthouse, bahwa kita harus benar-benar memperbaiki keadaan karena hal itu dapat menyebabkan penurunan pangkat, atau adakah pemotongan?

Answer 54:07 - Jadi kami tidak memiliki pemetaan satu-ke-satu dari alat eksternal dan semua yang kami gunakan untuk sosial. Ya, itu membuatnya sangat sulit untuk dikatakan, tetapi dalam penelusuran, kami mencoba menggunakan campuran data uji lab yang sebenarnya, apa itu, yang seperti uji Lighthouse, dan data laporan Chrome UX, di mana pada dasarnya apa yang kami ukur adalah apa yang akan dilihat oleh pengguna situs web.

MARTIN SPLITT 55:37 - Penting juga untuk melihat bahwa Lighthouse, misalnya, secara khusus mengukur koneksi 3G di ujung median-- atau seperti ponsel kinerja menengah, ya. Jadi, pada dasarnya, jika Anda menggunakan Apple McIntosh baru-baru ini atau komputer Windows cepat baru-baru ini dengan koneksi kabel yang sangat bagus atau koneksi Wi-Fi yang sangat bagus di kantor Anda, tentu saja, Anda melihat waktu buka dua detik, tetapi pengguna nyata dengan telepon mereka di alam liar mungkin tidak melihat itu. Jadi ini salah satu kasus seperti tidak ada salahnya untuk membuat situs web Anda lebih cepat, tetapi ini benar-benar sulit untuk mengatakan seperti apa tampilannya dari perspektif bagian dalam, karena kami menggunakan metrik yang sangat spesifik yang tidak harus memetakan satu ke satu dengan apa yang diekspos oleh alat tersebut.... tentu saja penting untuk memperbaikinya, karena Anda tidak ingin pengguna Anda menunggu di situs web Anda selamanya. Itu akan menyakitimu. Itu akan merugikan pengguna Anda. Itu hanya akan merugikan Anda dalam pencarian. Tapi saya tidak membayar-- Saya akan mengatakan lihat saja alat-alatnya. Jika alat memberi tahu Anda bahwa Anda melakukannya dengan baik, maka Anda tidak perlu terlalu khawatir tentang hal itu. Jika alat memberi tahu Anda bahwa Anda benar-benar tidak baik, maka saya pikir waktu yang dihabiskan untuk mencari tahu mengapa dikatakan-- seperti, jika apa yang dikatakan relevan, itu sia-sia. Anda sebaiknya melihat membuat situs lebih cepat.

Performa seluler adalah faktor yang sangat penting bagi pengguna Anda, serta yang lainnya. Jadi saya akan mengatakan pastikan bahwa situs web Anda berkinerja baik dalam kondisi dunia nyata. Bahkan mungkin mendapatkan telepon murah dan mencoba situs web sesekali, dan jika-- itu adalah sesuatu yang saya suka lakukan, dan dulu saya lakukan sebelum saya bergabung dengan Google dengan tim pengembangan tempat saya bekerja. Saya, seperti, lihat, apakah Anda ingin menggunakan situs web ini di ponsel ini? Rasanya seperti, oh, ini mengerikan. Saya seperti, mhm, ya, jadi mungkin kita harus melakukan sesuatu.

JOHN - Di Chrome, Anda dapat mengaturnya dan mencoba kecepatan koneksi yang berbeda. Emulator seluler. Saya pikir itu hal yang sangat bagus untuk dilihat, dan juga, seperti, melihat basis pengguna Anda. Lihatlah data analitik Anda jika Anda melihat bahwa orang-orang hanya menggunakan situs web Anda dengan iPhone kelas atas, maka mungkin itu bukan masalah daripada jika Anda melihat bahwa orang-orang terhubung ke situs Anda dari koneksi pedesaan acak, yaitu lambat, dan mereka memiliki perangkat kelas bawah, maka mungkin itu lebih.

Ringkasan: Lighthouse mengukur kecepatan untuk koneksi 3G, sehingga sebagian besar situs akan bekerja jauh lebih cepat daripada yang ditampilkan di sini untuk sebagian besar sesi. Catatan: Setelah hangout ini selesai, Martin melanjutkan dengan mengatakan bahwa itu adalah "cat kepuasan pertama" yang paling penting dalam kaitannya dengan potensi penurunan peringkat.

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 dan Transkrip Lengkap

Pertanyaan 1:32 - Saya ingin tahu apakah Anda memiliki panduan lebih lanjut atau sudut pandang lain tentang pengujian dengan cara yang dapat digunakan SEO untuk lebih tepat dan lebih percaya diri melaporkan ke bisnis. Kami mencoba hal ini, dan itu membuat dampaknya. Dan kami melakukannya dengan cara yang pasti, seperti yang akan direkomendasikan oleh Google.

Answer 3:20 - Jadi dari sudut pandang saya, saya mencoba untuk memisahkan hal-hal jenis yang lebih teknis dari jenis perubahan jenis kualitas. Jadi apa pun yang benar-benar merupakan hal teknis yang jelas, Anda cukup banyak menguji apakah itu berfungsi atau tidak. Ini bukan masalah apakah itu berhasil atau tidak, tetapi banyak hal teknis ini, terutama ketika Anda melihat rendering, atau ketika Anda melihat apakah Google benar-benar mengindeks konten ini, itu sesuatu yang berhasil atau tidak. Di mana menjadi rumit adalah segala sesuatu di mana itu tentang-- itu diindeks, tapi bagaimana itu muncul di peringkat? Dan saya pikir untuk banyak hal itu, tidak ada cara mutlak untuk benar-benar mengujinya. Karena jika Anda mengujinya dalam situasi yang terisolasi, seperti Anda membuat situs pengujian, dan Anda mengaturnya dengan rekomendasi apa pun yang Anda miliki, Anda tidak dapat benar-benar berasumsi bahwa situs pengujian akan bekerja dengan cara yang sama seperti situs web biasa. Terkadang ada hal-hal sederhana, seperti jika ini adalah situs pengujian, maka mungkin kami tidak akan melakukan rendering penuh karena kami pikir tidak masuk akal untuk menghabiskan begitu banyak waktu untuk ini dan ini, karena, seperti, tidak ada yang melihatnya. Itu tidak pernah muncul di hasil pencarian, mengapa kita harus repot-repot menempatkan begitu banyak sumber daya di balik itu? Sedangkan jika Anda melakukannya di situs web biasa, itu akan bekerja sangat berbeda. Jadi itu adalah sesuatu di mana saya tidak benar-benar memiliki panduan yang jelas tentang apa yang harus Anda lakukan atau apa yang tidak boleh Anda lakukan. Tampaknya lebih seperti hal di mana Anda melihat tren umum di mana Anda melihat situs web itu muncul, jenis perubahan peringkat yang Anda lihat untuk kueri tersebut, dan mencoba menerapkan praktik terbaik di sana.

Pertanyaan 5:21 - Jadi mungkin jika-- contoh konkret mungkin Anda dapat menggunakannya untuk-- mungkin itu akan membantu, jadi sesuatu seperti tes tag judul, bukan? Jika Anda melakukan itu-- apa, jika ada, yang harus kita cari? Atau adakah sesuatu yang harus dilihat untuk diurai-- apakah ini karena pengujian kami atau ini karena sesuatu yang berubah tentang server, algo, dinamika persaingan? [TERTAWA] Dengan asumsi bahwa kita melakukan hal lain untuk melihat eksternalitas tersebut.

Jawaban 5:56 - Saya pikir perubahan tag judul sebenarnya cukup rumit di pihak kita karena ada semacam interaksi apakah Google menggunakan tag judul yang sebenarnya Anda berikan, di satu sisi, untuk peringkat, di sisi lain sisi lain, untuk ditampilkan dalam hasil pencarian. Seperti untuk desktop dan seluler, kami memiliki jumlah ruang yang berbeda, jadi kami mungkin menampilkan tag judul yang sedikit berbeda. Pengguna mungkin menanggapinya dengan cara yang berbeda. Jadi Anda bisa memberi peringkat dengan cara yang sama, tetapi pengguna mungkin berpikir, oh, ini adalah halaman yang bagus. Saya akan menunjukkannya lebih tinggi-- atau saya akan mengkliknya di hasil pencarian karena terlihat seperti halaman yang bagus. Dan kemudian Anda memiliki lebih banyak lalu lintas. Tapi sebenarnya peringkatnya sama. Jadi apakah itu seperti hal yang baik? Mungkin, saya kira. Jika Anda hanya melihat peringkat, maka itu akan terlihat seperti, Anda tidak mengubah apa pun dari apa pun, dan kami baru saja mendapatkan lebih banyak lalu lintas.

Tapi itu adalah sesuatu di mana ada banyak aspek berbeda yang mengalir di sana. Jadi itu adalah sesuatu yang menurut saya, sebagai SEO, berguna, di satu sisi, untuk memiliki pemahaman teknis tentang apa yang terjadi, tetapi juga untuk memiliki pemahaman pemasaran dan kualitas yang lebih tentang bagaimana reaksi pengguna terhadap perubahan, apa adalah perubahan jangka panjang yang dapat kami pengaruhi dengan pengguna, bagaimana Anda dapat mendorongnya untuk memastikan bahwa situs kami dilihat sebagai situs yang paling relevan dalam situasi di mana orang mencari sesuatu yang terkait dengan itu. Dan saya pikir itu adalah sesuatu yang sangat sulit untuk diuji. Ini, seperti, bahkan dalam pemasaran tradisional di mana mereka telah berlatih bertahun-tahun, sangat sulit untuk menguji, seperti, apakah ini benar-benar berdampak besar atau tidak? Ini adalah sesuatu di mana mereka akhirnya melihat gambaran yang lebih besar atau melakukan studi pengguna, yang dapat Anda lakukan sebagai SEO juga. Maaf. [TAWA]

Pertanyaan 7:58 - Saya punya pertanyaan yang lebih langsung. Jadi beberapa situs kami, Anda tahu, menggunakan Cloudflare, dan kami melihat mereka langsung memblokir Googlebot, bukan? Tapi itu tidak berdampak banyak pada peringkat kami, pada visibilitas kami, dan lain-lain. Jadi agak mencoba mencari tahu bagaimana, seperti, apakah kalian menggunakan bot lain untuk merayapi indeks di luar Googlebot secara langsung, dan bagaimana kita harus memikirkannya ketika CDN berusaha memblokir bot?

Answer 8:33 - Ya, saya tidak tahu bagaimana pengaturan dengan Cloudflare saat ini, tapi saya tahu di masa lalu mereka memblokir orang yang memalsukan Googlebot. Jadi jika Anda menggunakan, seperti milik Anda sendiri, saya tidak tahu, Screaming Frog atau sesuatu-- Anda berkata, saya menggunakan agen pengguna Googlebot, mereka akan memblokirnya karena mereka dapat mengatakan, seperti, ini tidak sah Googlebot. Kita bisa memblokir itu. Tetapi sebagian besar, saya pikir mereka memiliki cukup latihan untuk mengenali Googlebot normal dan membiarkannya merangkak secara normal.

Pertanyaan 9:02 - Ya, itu menarik. Karena menjangkau sekelompok kolega di agensi lain, dan mereka mereplikasi situasi serupa bahkan di situs mereka sendiri. Seperti, ada tiket dukungan di dalam Cloudflare, dan itu juga diblokir ketika saya hanya mencoba merender langsung dari Googlebot atau ponsel cerdas Googlebot.

Jawaban 9:21 - Oke, ya. Yah, kami tidak memiliki solusi. Seperti, jika situs web memblokir kami, kami seperti terjebak. Tetapi biasanya jika layanan seperti Cloudflare memblokir kami secara default, maka itu akan memengaruhi banyak situs web. Dan kami akan memperhatikan itu. Kami mungkin akan menghubungi Cloudflare tentang hal seperti itu. Mungkin saja mereka memiliki tingkatan layanan yang berbeda. Jadi seperti jika Anda berada di tingkat yang lebih rendah, maka itu seperti layanan gratis, tetapi kami memiliki batasan dengan jumlah lalu lintas. Saya tidak tahu apakah mereka memiliki sesuatu seperti itu. Itu adalah sesuatu yang saya lihat dengan beberapa penghosting lain, di mana jika Anda memiliki semacam pengaturan hosting default gratis, maka terkadang mereka hanya memiliki batasan lalu lintas, dan mereka memblokir banyak hal.

MARTIN SPLITT: Anda mungkin tidak langsung melihatnya dalam statistik dari cara Anda memeringkat dan sebagainya. Karena pada dasarnya, jika kami memiliki konten dari Anda, dan pada dasarnya, situs web tidak-- tergantung pada apa yang diblokir, dalam hal ini, artinya karena saya belum melihatnya. Dan saya menjalankan beberapa situs web di belakang Cloudflare, dan saya tidak punya masalah. Tetapi sekali lagi, saya tidak memiliki situs web raksasa atau menyukai lalu lintas dalam jumlah besar karena saya menggunakan paket gratis. Itu-- tetapi jika Anda tidak mendapatkan kesalahan seperti di pihak kami, itu-- mungkin saja kami menyimpan konten yang terakhir kali kami lihat. Dan itu hanya peringkat yang baik, dan tidak apa-apa.

Answer 12:09 - Ya, jadi saya pikir apa yang akan terjadi dalam kasus seperti Anda adalah kami akan memperlambat crawling. Dan kami akan mencoba menyimpan konten yang dapat kami ambil lebih banyak di indeks, dan kami hanya akan merayapi ulang sedikit lebih lama. Tapi itu juga berarti jika Anda membuat perubahan di situs web Anda, kami akan membutuhkan waktu lebih lama untuk mengambilnya. Jika kita harus meng-crawl ulang hal-hal secara signifikan, seperti, entahlah, AMP, atau Anda menambahkan semacam itu atau itu di seluruh situs, maka itu semua akan memakan waktu lebih lama. Jadi, jika Anda benar-benar sering melihat bahwa kami tidak dapat merayapi dengan Googlebot normal, maka itu adalah sesuatu yang saya ambil dengan host sehingga kami dapat melihatnya.

Pertanyaan 14:01 - Bagus. Jadi saya punya pertanyaan tentang alat penolakan. Jadi kami selalu mendapatkan orang-orang yang ingin kami melakukan audit tautan. Dan sejak Penguin 4.0, jadi September 2016, di mana Gary Illyes berkata, dan saya pikir Anda juga mengatakan, seperti, Google cukup bagus dalam mengabaikan tautan yang tidak wajar. Jadi pemikiran saya saat itu adalah, kita tidak perlu menggunakan alat penolakan untuk meminta Google mengabaikan tautan yang telah mereka abaikan, kecuali jika Anda memiliki tindakan manual untuk tautan yang tidak wajar. Jadi kami hanya merekomendasikannya untuk situs yang telah aktif, Anda tahu, membangun tautan, mencoba memanipulasi hal-hal, hal-hal yang tautannya tidak wajar. Tapi saya pikir ada begitu banyak kebingungan di antara webmaster karena saya melihat orang-orang sepanjang waktu, Anda tahu, membebankan banyak uang untuk mengaudit-- untuk menolak tautan yang hanya-- Saya tahu mereka diabaikan. Jadi saya akan senang jika kita bisa memiliki sedikit lebih banyak klarifikasi. Jadi mungkin jika saya bisa memberi Anda contoh, seperti, jika ada pemilik bisnis yang, beberapa tahun lalu, menyewa perusahaan SEO, dan perusahaan SEO itu melakukan banyak posting tamu hanya untuk tautan dan, Anda tahu, hal-hal itu adalah jenis kualitas menengah, jika Anda tahu apa yang saya maksud, bukan ultra spam, dapatkah kami yakin bahwa Google mengabaikan tautan tersebut? Atau haruskah kita masuk dan mengingkari?

Jawaban 15:22 - Saya pikir itu pertanyaan yang bagus. Jadi dari sudut pandang saya, apa yang akan saya lihat adalah, di satu sisi, pasti kasusnya adalah di mana ada tindakan manual. Tetapi juga, kasus di mana Anda juga ingin melihat banyak tindakan manual akan mengatakan, nah, jika tim spam web melihat ini sekarang, mereka akan memberi Anda tindakan manual. Jenis kasus di mana Anda akan mengatakan, baik, tindakan manual lebih merupakan masalah waktu dan tidak seperti itu didasarkan pada sesuatu yang telah dilakukan-- Saya tidak tahu-- di mana itu jelas dilakukan beberapa tahun lalu, dan itu semacam batas tidak. Tapi jenis hal di mana Anda melihatnya dan berkata, jika seseorang dari tim spam web mendapatkan ini sebagai tip, mereka akan mengambil tindakan manual, dan itu pasti jenis hal di mana saya akan membersihkannya dan melakukannya seperti pengingkaran untuk itu. Ya, saya pikir sulit untuk mengatakan jika ada seperti timeline tertentu. Tetapi secara umum, jika tim webspam melihat ini dan berkata, seperti, semuanya telah berubah. Ini jelas dilakukan beberapa tahun yang lalu. Itu tidak sepenuhnya berbahaya. Maka mereka mungkin tidak akan mengambil tindakan manual untuk itu.

Pertanyaan 16:43 - Dan saya berasumsi Anda mungkin tidak dapat menjawab ini, tetapi apakah ada cara yang-- seperti, jadi katakanlah kita tidak mendapatkan tindakan manual, atau mereka tidak mendapatkan tindakan manual. Bisakah tautan itu melukai mereka secara algoritmik? Karena kami merasa kami melihat beberapa peningkatan di beberapa situs, Anda tahu, setelah menolak. Jadi, sekali lagi, saya tahu itu selalu-- tidak pernah hitam dan putih.

Jawaban 17:03 - Itu pasti bisa. Jadi itu adalah sesuatu di mana algoritme kami ketika kami melihatnya dan mereka melihat, oh, mereka adalah sekelompok tautan yang sangat buruk di sini, maka mungkin mereka akan sedikit lebih berhati-hati sehubungan dengan tautan secara umum untuk situs web. Jadi jika Anda membersihkannya, maka algoritme melihatnya dan berkata, oh, ada-- ada semacam-- tidak apa-apa. Itu tidak buruk.

Pertanyaan 17:24 - Menolak pada dasarnya tetap baik untuk mencegah tindakan manual, bukan?

Jawaban 17:29 - Saya pikir jika Anda berada dalam kasus di mana sangat jelas bahwa tim spam web akan memberi Anda tindakan manual berdasarkan situasi saat ini, maka itulah yang akan saya tolak.

Pertanyaan 17:37 - Jadi bagus untuk berpikir seperti di Google-- seperti seseorang di tim spam Google hanya berpikir, seperti, Anda tahu, jika mereka melihat ini, apa yang akan mereka lakukan jika mereka melakukannya?

Jawaban 17:47 - Ya.

Pertanyaan 17:48 - Masalahnya, kebanyakan orang tidak tahu. Maksud saya, rata-rata pemilik bisnis tidak tahu tautan mana yang akan ditautkan oleh tim spam web-- Maksud saya, ada pedoman, tetapi sangat-- Anda tahu, sulit untuk menafsirkannya. Jadi saya pikir-- Maksud saya, saya memiliki beberapa kekhawatiran, tetapi perhatian utama saya adalah ada orang yang menghabiskan banyak uang untuk audit tautan yang menurut saya tidak sepadan. Di sisi lain, kami mungkin tidak melakukan audit tautan dan menolak beberapa situs yang dapat mengambil manfaat darinya. Jadi saya ingin, Anda tahu, saya pikir apa yang Anda katakan telah banyak membantu sehingga kami akan-- Anda tahu, itu bagus.

Answer 18:22 - Ya, saya pikir untuk sebagian besar situs semacam itu memiliki campuran normal dari hal-hal di mana Anda seperti mengikuti beberapa nasihat buruk di masa lalu, dan sepertinya Anda pindah, dan semuanya cukup alami sekarang, maka mereka benar-benar tidak perlu melakukan itu. Itulah tujuan dari semua ini, dan itulah mengapa alat penolakan tidak seperti fitur utama di Search Console. Anda agak mencarinya secara eksplisit. Itu semua dilakukan dengan sengaja karena untuk sebagian besar situs, Anda benar-benar tidak perlu terlalu fokus pada tautan. Apa yang saya suka tentang alat penolakan, adalah bahwa jika Anda khawatir tentang ini, Anda masih bisa pergi ke sana dan menjadi seperti, OK, saya tahu ada beberapa hal seperti ini yang kami lakukan beberapa tahun lalu, dan saya sangat khawatir tentang itu. Kemudian mengingkarinya, dari sudut pandang saya, bukanlah masalah. Saya tidak akan keluar dan secara khusus mencari semua barang itu. Tetapi jika Anda mengetahuinya, dan Anda benar-benar mengkhawatirkannya, maka Anda bisa mengatasinya.

Pertanyaan 19:27 - Saya memiliki pertanyaan tentang salah satu situs web klien kami. Jadi mereka memiliki klub-- mereka memiliki klub di tiga kota di New South Wales. Dan setiap klub memiliki subdomain di website. Sekarang ketika mereka menambahkan halaman apa pun ke situs web mereka, mereka membuat halaman untuk setiap subdomain. Jadi baru-baru ini, mereka telah menambahkan halaman, yaitu tentang aktivitas klub mereka, dan mereka telah menambahkan halaman ini ke-- semua subdomain mereka. Jadi artinya semua subdomain memiliki konten yang sama, kecuali judul halaman yang berbeda. Karena ketika mereka menambahkan ke-- untuk Sydney, mereka menambahkan nama lokasi mereka di tag judul. Ketika mereka menambahkannya untuk Newcastle, mereka menambahkan Newcastle di tag judul, tetapi konten lainnya di halaman itu sama. Jadi apakah akan menjadi masalah karena mereka memiliki 50 subdomain, dan mereka telah membuat 50 halaman, yang isinya sama kecuali judulnya?

Answer 20:36 - Kedengarannya seperti sesuatu yang sedikit tidak efisien, saya rasa. Jadi maksud saya, Anda sudah membicarakannya dan seperti mengatakan, ini sepertinya sesuatu yang bisa dilakukan secara berbeda. Saya pikir jika Anda berada dalam kasus di mana Anda memiliki 50 subdomain yang semuanya memiliki konten yang sama, dan Anda hanya mengubah tag judul, maka Anda mungkin tidak memberi kami banyak konten yang sangat berguna. Jadi itulah situasi di mana saya akan mengatakan, lebih masuk akal untuk menggabungkan hal-hal dan membuat halaman yang sangat kuat daripada melemahkan hal-hal di lebih banyak subdomain.

Pertanyaan 21:44 - Bagaimana dengan membuat satu halaman dan kemudian menggunakan URL kanonik ke halaman lokasi lain. Saya hanya ingin membuat satu halaman, yang akan kita bicarakan tentang aktivitas mereka, dan saya akan menggunakan link tersebut sebagai URL kanonik ke halaman lokasi lain.

Jawaban 22:10 - Lokasi-- ya. Saya pikir itu masuk akal karena Anda menggabungkan hal-hal lagi. Kemudian Anda membuat satu halaman yang kuat daripada sekumpulan halaman yang diencerkan.

Pertanyaan 22:20 - Karena apa yang terjadi ketika seseorang mengunjungi situs web, dan mereka memilih lokasi mereka, mereka secara otomatis mengarahkan orang itu ke subdomain yang mereka tunjukkan untuk lokasi tertentu mereka. Jadi itulah alasan mereka membutuhkan halaman di subdomain itu. Jadi saya pikir itu sebabnya jika kita menyimpan satu halaman dan menambahkan URL kanonik, itu-- itu satu-satunya pilihan yang kita miliki saat ini.

Answer 23:08 - OK, tapi saya pikir jika Anda memiliki halaman terpisah yang Anda perlukan untuk alasan teknis di situs, dan Anda menempatkan kanonik, itu pendekatan yang baik.

Pertanyaan 23:21 - Apakah itu seperti-- seperti bisnis yang memiliki banyak waralaba di lokasi berbeda yang pada dasarnya memiliki konten yang sama untuk setiap waralaba akan berada di kota atau kotapraja yang berbeda, atau apa pun, dan jenis saluran yang berasal dari Anda sudut pandang kembali ke satu halaman?

Jawaban 23:34 - Saya pikir itu selalu sedikit rumit karena Anda menyeimbangkan orang yang mencari bisnis semacam itu di lokasi tertentu dengan jenis halaman informasi seputar bisnis itu secara langsung. Jadi itu adalah sesuatu yang terkadang masuk akal untuk memisahkannya untuk bisnis. Terkadang masuk akal untuk memiliki semacam informasi umum di tempat sentral dan memiliki seperti-- seperti halaman arahan lokasi yang lebih fokus pada alamat, jam buka, hal-hal semacam itu.

Pertanyaan 24:12 - Ya, saya punya-- Saya punya pertanyaan terkait dengan poin kanonik yang Anda buat. Ini adalah pertanyaan yang saya dan tim saya miliki selama beberapa tahun. Dan kami masih belum tahu persis solusinya. Jadi jika Anda menangani situs e-commerce besar dengan banyak, banyak produk dan banyak, banyak kategori. Katakanlah Anda berada di halaman kategori yang memiliki banyak filter dan faset berbeda dan hal-hal semacam itu yang sedikit mengubah konten halaman, tetapi mungkin tidak cukup untuk membenarkan memiliki URL sendiri. Tapi mungkin dalam beberapa kasus dengan filter tertentu, itu membenarkan memiliki URL situs. Jadi bagaimana Anda menangani perayapan dalam situasi itu? Seperti apakah tag kanonik berfungsi? Apakah ini solusi menyeluruh untuk hanya membuat satu halaman yang diindeks? Atau haruskah Anda melihat, Anda tahu, tanpa pengindeksan aspek dan filter tertentu, atau menggunakan robot, atau bagaimana Anda mengontrolnya untuk situs e-niaga besar?

Jawaban 24:57 - Itu rumit. Saya tidak berpikir kami memiliki panduan yang benar-benar jelas tentang itu saat ini. Jadi itu adalah sesuatu di mana semua jenis metode yang berbeda bisa masuk akal. Secara umum, saya mencoba menghindari penggunaan robots.txt untuk itu karena yang bisa terjadi adalah kita menemukan URL-nya. Kami hanya tidak tahu apa yang ada di sana. Jadi kecuali Anda benar-benar melihat masalah yang menyebabkan terlalu banyak beban di server, saya mencoba menggunakan hal-hal seperti no index, gunakan rel canonical. Mungkin Anda menggunakan rel no-follow dengan tautan internal ke semacam saluran untuk membuatnya sedikit lebih jelas tentang apa yang harus kita jelajahi indeks daripada menggunakan robots.txt. Tetapi jenis keputusan tentang kapan harus menggabungkan berbagai hal ke dalam halaman tingkat indeks dan kapan harus memblokirnya dari pengindeksan, kapan harus mengarahkannya dengan lembut ke arah seperti satu URL kanonik, itu-- terkadang sangat rumit.

Pertanyaan 25:53 - Karena terkadang kanonik diabaikan jika konten halaman terlalu berbeda.

Jawaban 25:57 - Tepat. Jika kontennya berbeda, maka kita dapat mengatakan, yah, ini adalah halaman yang berbeda. Kita seharusnya tidak menggunakan kanonik. Padahal Anda mungkin berkata, yah, ini benar-benar sesuatu yang tidak ingin saya indeks. Mungkin tanpa indeks lebih masuk akal daripada kanonik. Anda juga dapat menggabungkan keduanya. Kami tidak menyarankan untuk menggabungkannya karena sangat sulit bagi kami untuk mengatakan, apa maksud Anda? Apakah Anda mengatakan ini sama, tetapi yang satu dapat diindeks dan yang lainnya tidak dapat diindeks, maka keduanya tidak sama. Tapi itu adalah sesuatu di mana saya membayangkan selama tahun ini akan memiliki beberapa panduan yang jelas tentang apa yang bisa berhasil di sana. Tetapi terutama dengan situs e-commerce yang sangat besar, sisi perayapan bisa sangat menantang.

Pertanyaan 26:46 - Jadi ada skenario yang saya coba cari tahu dengan beberapa pelanggan saya belakangan ini. Kami mencoba mencari tahu mengapa pada dasarnya kami tidak dapat membuang situs yang masih menggunakan HTTP dan sedikit banyak terlihat ditinggalkan karena halaman belum diperbarui untuk sementara waktu, dan kontennya lama, usang, dan umumnya agak kurus, jadi saya punya beberapa teori tentangnya. Sebagian darinya, saya pikir, mungkin sudah lama ada di indeks sehingga Anda semua memiliki faktor kepercayaan yang dibangun dengan mereka. Dan agak sulit untuk menggeser mereka. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

Pertanyaan 42:29 - Itu tentang situs web agen perjalanan untuk bepergian. Kami memilih pencarian internal untuk menampilkan konten dinamis, seperti 10 hotel paling murah teratas di kota pencarian, oke? Jadi bingkai halaman dimuat dalam sekejap. Tetapi 10 hasil hotel termurah teratas dimuat secara dinamis dalam waktu 30 detik sejak pencarian dilakukan karena situs web harus melakukan pencarian ini di belakang dan kemudian membandingkan dan menyaring hasil untuk membuat daftar, bagi pencari, 10 teratas murah hotel. Jadi butuh sedikit waktu untuk mendaftar mereka. Jadi saat ini, Googlebot hanya melihat latar belakang halaman. Kemudian 10 placeholder kosong itu di mana hasilnya akan dimuat sedikit kemudian setelah pencarian internal dilakukan. Jadi karena ini adalah tren situs web perjalanan untuk membawa informasi sesegar mungkin dan seakurat mungkin, saya berpikir, apa yang dilakukan Google tentang hal ini. Tentu saja, kami dapat membuat daftar beberapa konten statis di halaman ini seperti yang dilakukan semua situs web lain saat ini untuk Google, jika boleh saya katakan demikian. Tapi itu mengalahkan tujuan dari apa yang kebanyakan pengguna ingin lihat sekarang, segar dan murah.

Answer 44:00 - Jadi jika tidak dimuat di sana, maka kami tidak dapat mengindeksnya. Tapi biasanya, itu lebih karena kita tidak bisa memproses JavaScript atau mungkin diblokir untuk benar-benar mengakses konten di sana. Jadi itu adalah sesuatu yang dapat Anda lakukan dengan cara yang akan berhasil. Bukan karena desainnya itu tidak akan pernah berhasil. Jadi itu adalah sesuatu di mana Anda dapat menggali detailnya menggunakan hal-hal seperti tes ramah seluler untuk melihat apakah ada kesalahan JavaScript yang terlibat, jika ada yang diblokir, dan semacam memperbaikinya dari sana. Jadi bukan tidak mungkin, tapi butuh sedikit kerja keras.

Pertanyaan 44:42 - John, saya menyelidikinya dengan memastikan tidak ada yang diblokir dari Google. Satu-satunya hal yang kami ingin Google lakukan adalah menunggu sebentar hingga konten dinamis dimuat ke halaman, Anda tahu? Ini adalah langkah selanjutnya, jika boleh saya katakan demikian karena sementara halaman ini tidak seperti gulungan tanpa akhir, katakanlah Facebook, ini adalah halaman hasil terbatas 10. Jadi itu terbatas. Ini terbatas. Masalahnya adalah Google harus menunggu sedikit untuk konten dinamis. Saya hanya memberi Anda contoh. Tapi saya yakin ada banyak contoh lain di luar sana di alam liar. Dan karena ini adalah tren bagi orang untuk melihat konten dinamis karena mereka entah bagaimana menyortir sesuatu dan waktu yang mereka habiskan semakin sedikit-- orang-orang semakin sedikit menghabiskan waktu di situs web, dan mereka ingin menemukan secepat mungkin hasil yang sempurna, jika boleh saya katakan begitu. Saya bertanya-tanya apakah kalian melihat ke arah peningkatan ini.

Answer 45:55 - Jadi kami menunggu sebentar untuk rendering. Tetapi jika orang tidak sabar, maka itu tandanya Anda harus lebih cepat pula. Jadi itu adalah sesuatu di mana saya akan melihat ke dalamnya. Tapi saya pikir melihat tangkapan layar, seperti, semua item di sana diblokir hanya dalam kotak abu-abu. Jadi itu terasa seperti sesuatu yang lebih merupakan masalah teknis daripada hanya waktu istirahat.

MARTIN SPLITT : Ya. Saya akan mengatakan, seperti, kami melihat banyak konten dinamis yang diindeks tanpa masalah, bahkan jika itu menggunakan JavaScript dan sejenisnya. Jadi, jika kita kehabisan waktu, maka Anda mungkin memiliki masalah dalam hal berapa lama pencarian berlangsung, dan itu mungkin juga mencerminkan di tempat lain. Kami menunggu cukup lama hingga konten selesai.

Pertanyaan 46:48 - Dapatkah Anda-- dapatkah Anda memberi saya kerangka waktu? Berapa banyak Anda menunggu?

MARTIN SPLITT : Ini benar-benar rumit karena pada dasarnya-- jadi masalahnya, alasan mengapa kami tidak dapat memberi Anda kerangka waktu adalah karena waktu-- dan ini akan terdengar sangat aneh, dan bersabarlah sebentar . Waktu dalam rendering Googlebots adalah khusus dan tidak selalu mengikuti prinsip Einstein. [TERTAWA] Jadi saya tidak bisa berkata banyak. Yang bisa saya katakan adalah jika jaringannya sibuk dan jaringannya macet, kami mungkin menunggu, tetapi kami hanya menunggu begitu lama. Jadi jika Anda membutuhkan waktu satu menit atau 30 detik, maka kita mungkin mengatur waktu di antaranya. Tapi tidak sulit-- jika saya beri tahu Anda 10 detik, itu mungkin berhasil atau tidak. Jika saya memberi tahu Anda 30 detik, itu mungkin berhasil atau tidak. Jadi saya lebih suka tidak menyebutkan angkanya. Apa yang akan saya katakan, cobalah untuk mendapatkannya secepat mungkin. Dan jika Anda tidak bisa mendapatkannya dengan cepat, cobalah sesuatu seperti cache hasil pencarian sehingga pencarian menjadi lebih atau kurang di-- atau menghasilkan hasil pada halaman menjadi lebih dan lebih-- kurang lebih instan. Atau coba rendering dinamis di pihak Anda yang mungkin menjadi solusi untuk ini. Apa yang Anda juga dapat mencoba adalah Anda dapat mencoba untuk meletakkannya di sisi server dan pada dasarnya mencoba untuk menghasilkan konten sebanyak mungkin di pass pertama. Itu adalah sesuatu yang juga menguntungkan pengguna Anda, terutama jika mereka berada di jaringan yang lambat. Jadi ya. Maaf saya tidak punya jawaban sederhana, tapi waktu di Googlebot itu funky.

Answer 49:29 - Saya pikir itu mungkin tergantung pada apa yang sebenarnya dilakukan situs web itu. Salah satu hal yang rumit dengan kecepatan dalam rendering adalah kita dapat menyimpan banyak hal yang dikirim dari server lebih banyak daripada yang ada di browser, karena kita dapat menggunakan indeks untuk banyak hal ini. Jadi terkadang jika JavaScript di-cache di pihak kita, kita tidak perlu mengambilnya. Kemudian jika Anda membandingkan waktunya lagi, maka itu tidak akan cocok dengan apa yang dilihat pengguna. Itu tidak akan cocok dengan apa yang Anda lihat di pagestest.org. Jadi ini agak rumit, dan untuk bagian yang kami tahu butuh waktu lebih lama, kami akan sedikit lebih sabar. Tapi itu membuatnya sulit untuk diuji. Itu sebabnya kami memiliki semua alat pengujian ini sekarang yang menunjukkan kesalahan sebanyak mungkin untuk memungkinkan untuk mengetahui, seperti, apakah itu tidak berfungsi sama sekali? Apakah terkadang berhasil dan di mana terkadang masalah yang muncul?

Pertanyaan 50:29 - Untuk situs web yang sangat besar, apakah urutan URL dalam peta situs XML penting?

Jawaban 50:34 - Tidak. Kami tidak peduli. Ini adalah file XML. Kami menarik semua data. Kami memproses semuanya sekaligus.

Pertanyaan 50:44 - Lalu bagaimana dengan parameter prioritas di peta situs?

Answer 50:47 - Kami tidak menggunakannya sama sekali. Jadi itu sesuatu yang pada awalnya kami pikir, oh, ini mungkin berguna untuk mengetahui seberapa sering kami harus merayapi halaman. Tapi ternyata jika Anda bertanya kepada webmaster, mereka seperti, semuanya adalah prioritas. Ini yang paling penting. Dan serupa juga dengan, saya pikir, frekuensi perubahan di peta situs, di mana kami juga memperhatikan bahwa, seperti, orang-orang memberi tahu kami seperti hal-hal yang berubah sepanjang waktu, tetapi itu terakhir diperbarui tahun lalu. Jadi jika Anda memiliki frekuensi perubahan dan tanggal, maka kami akan tetap mendapatkan informasi itu dari tanggal. Jadi kita mengabaikan perubahan frekuensi.
Pertanyaan 51:35 - Haruskah skema perusahaan ditambahkan hanya ke halaman beranda, halaman kontak, atau semua halaman?

Answer 51:42 - Sejauh yang saya tahu, itu hanya halaman rumah. Aku tidak tahu. Apakah kalian ada di antara kalian yang tahu?

Answer from Liz 51:4 7 - Seharusnya hanya satu halaman biasanya dengan organisasi dan perusahaan. Itu umumnya rekomendasi.

MARTIN SPLITT 52:00 - Saya kira tidak masalah yang mana-- tidak masalah sebanyak halaman mana, sama seperti jangan meletakkannya di setiap halaman yang Anda punya, saya kira, adalah bagian yang lebih penting. Saya pikir itu tergantung pada-- jika Anda adalah situs berita, mungkin masuk akal untuk meletakkannya di halaman kontak, atau halaman tentang, atau sesuatu. Sedangkan di website toko atau restoran, mungkin boleh saja ditaruh di homepage.

JOHN 52:20 - Saya pikir juga, dalam hal ini, itu tidak terlalu penting bagi kita karena kita harus dapat menemukannya di suatu tempat seperti halaman rumah atau halaman kontak. Tetapi jika kita memilikinya di tempat lain, itu tidak mengubah apa pun bagi kita. Jadi hal besar yang tidak bisa dibandingkan adalah markup ulasan di mana kita kadang-kadang melihat orang-orang menaruh seperti ulasan perusahaan di semua halaman situs web dengan harapan mendapatkan bintang dan hasil pencarian untuk setiap halaman di situs mereka. Dan itu akan buruk bagi kita. Tapi informasi kontak, jika Anda sudah menandainya, itu-- Saya tidak melihat ada masalah dengan itu.
Pertanyaan 53:05 -Tes kecepatan situs web Google yang kami gunakan mencatat waktu pemuatan halaman yang sangat lambat, tetapi tes independen yang kami lakukan dengan rekan kerja di luar negeri menunjukkan waktu pemuatan halaman yang sangat cepat. Apakah tindakan Google yang salah merekam ini memengaruhi peringkat situs kami dalam algoritme Google?

Marie Haynes: Ini bukan pertanyaan saya, tetapi untuk memberikan beberapa konteks, data Lighthouse baru untuk kecepatan halaman jauh lebih kasar daripada Wawasan Kecepatan Halaman sebelumnya. Jadi sesuatu yang memiliki skor seperti 80 di Page Speed ​​Insights mungkin menjadi 29 merah di Lighthouse. Jadi itu pertanyaan yang bagus. Apakah itu mungkin menyebabkan-- karena kami tahu bahwa di seluler, situs yang sangat lambat dapat diturunkan. Jadi, apakah baik jika kita mengatakan, Anda tahu, jika Anda berada di zona merah dalam tes Lighthouse, bahwa kita harus benar-benar memperbaiki keadaan karena hal itu dapat menyebabkan penurunan pangkat, atau adakah pemotongan?

Answer 54:07 - Jadi kami tidak memiliki pemetaan satu-ke-satu dari alat eksternal dan semua yang kami gunakan untuk sosial. Ya, itu membuatnya sangat sulit untuk dikatakan, tetapi dalam penelusuran, kami mencoba menggunakan campuran data uji lab yang sebenarnya, apa itu, yang seperti uji Lighthouse, dan data laporan Chrome UX, di mana pada dasarnya apa yang kami ukur adalah apa yang akan dilihat oleh pengguna situs web.

MARTIN SPLITT 55:37 - Penting juga untuk melihat bahwa Lighthouse, misalnya, secara khusus mengukur koneksi 3G di ujung median-- atau seperti ponsel kinerja menengah, ya. Jadi, pada dasarnya, jika Anda menggunakan Apple McIntosh baru-baru ini atau komputer Windows cepat baru-baru ini dengan koneksi kabel yang sangat bagus atau koneksi Wi-Fi yang sangat bagus di kantor Anda, tentu saja, Anda melihat waktu buka dua detik, tetapi pengguna nyata dengan telepon mereka di alam liar mungkin tidak melihat itu. Jadi ini salah satu kasus seperti tidak ada salahnya untuk membuat situs web Anda lebih cepat, tetapi ini benar-benar sulit untuk mengatakan seperti apa tampilannya dari perspektif bagian dalam, karena kami menggunakan metrik yang sangat spesifik yang tidak harus memetakan satu ke satu dengan apa yang diekspos oleh alat tersebut.... tentu saja penting untuk memperbaikinya, karena Anda tidak ingin pengguna Anda menunggu di situs web Anda selamanya. Itu akan menyakitimu. Itu akan merugikan pengguna Anda. Itu hanya akan merugikan Anda dalam pencarian. Tapi saya tidak membayar-- Saya akan mengatakan lihat saja alat-alatnya. Jika alat memberi tahu Anda bahwa Anda melakukannya dengan baik, maka Anda tidak perlu terlalu khawatir tentang hal itu. Jika alat memberi tahu Anda bahwa Anda benar-benar tidak baik, maka saya pikir waktu yang dihabiskan untuk mencari tahu mengapa dikatakan-- seperti, jika apa yang dikatakan relevan, itu sia-sia. Anda sebaiknya melihat membuat situs lebih cepat.

Performa seluler adalah faktor yang sangat penting bagi pengguna Anda, serta yang lainnya. Jadi saya akan mengatakan pastikan bahwa situs web Anda berkinerja baik dalam kondisi dunia nyata. Bahkan mungkin mendapatkan telepon murah dan mencoba situs web sesekali, dan jika-- itu adalah sesuatu yang saya suka lakukan, dan dulu saya lakukan sebelum saya bergabung dengan Google dengan tim pengembangan tempat saya bekerja. Saya, seperti, lihat, apakah Anda ingin menggunakan situs web ini di ponsel ini? Rasanya seperti, oh, ini mengerikan. Saya seperti, mhm, ya, jadi mungkin kita harus melakukan sesuatu.

JOHN - Di Chrome, Anda dapat mengaturnya dan mencoba kecepatan koneksi yang berbeda. Emulator seluler. Saya pikir itu hal yang sangat bagus untuk dilihat, dan juga, seperti, melihat basis pengguna Anda. Lihatlah data analitik Anda jika Anda melihat bahwa orang-orang hanya menggunakan situs web Anda dengan iPhone kelas atas, maka mungkin itu bukan masalah daripada jika Anda melihat bahwa orang-orang terhubung ke situs Anda dari koneksi pedesaan acak, yaitu lambat, dan mereka memiliki perangkat kelas bawah, maka mungkin itu lebih.