22 มกราคม 2019 – บันทึกแฮงเอาท์ความช่วยเหลือของ Google

สัปดาห์นี้ John อยู่ที่ Big Apple, NYC เข้าร่วม IRL จากซ้ายไปขวา โดย Martin Splitt จากทีม Java Script ที่ Google, Chris Love, Lily Ray, Marie Haynes, Dave Minchala และ Quason Carter สัปดาห์นี้มีคำถามดีๆ เกี่ยวกับ Cloudfare, The QRG และ The New Page Speed ​​Tool ลิงก์ไปยังวิดีโอและการถอดเสียงแบบเต็มอยู่ด้านล่าง!

บางครั้ง Cloudflare บล็อก Googlebot หรือไม่

7:58

"ใช่ ฉันไม่รู้ว่าตอนนี้มีการตั้งค่า Cloudflare อย่างไร แต่ฉันรู้ว่าก่อนหน้านี้พวกเขาเคยบล็อกคนที่แอบอ้าง Googlebot ดังนั้นถ้าคุณใช้ เช่น ของคุณเอง ฉันไม่รู้ กรี๊ด กบหรืออะไรก็ตาม - คุณพูดว่า ฉันใช้ตัวแทนผู้ใช้ Googlebot แล้วพวกเขาจะบล็อกสิ่งนั้น เพราะพวกเขาบอกได้ อย่างเช่น นี่ไม่ใช่ Googlebot ที่ถูกต้อง เราสามารถบล็อกสิ่งนั้นได้ แต่ส่วนใหญ่ ฉันคิดว่าพวกเขามี ฝึกฝนให้เพียงพอเพื่อให้รู้จัก Googlebot ปกติและปล่อยให้รวบรวมข้อมูลได้ตามปกติ"

สรุป: ในบางครั้ง เมื่อทำการทดสอบ อาจดูเหมือนว่า Cloudflare กำลังบล็อก Googlebot สิ่งที่น่าจะเกิดขึ้นที่นี่คือ Cloudflare กำลังบล็อกผู้ที่แอบอ้างเป็น Googlebot ดังนั้น หากคุณใช้เครื่องมืออย่าง Screaming Frog และเลือก Googlebot เป็นตัวแทนผู้ใช้ คุณอาจไม่สามารถรวบรวมข้อมูลไซต์โดย ใช้ Cloudflare

ลิงก์ที่ผิดธรรมชาติยังคงทำร้ายเว็บไซต์ด้วยอัลกอริธึมได้หรือไม่ ถ้าใช่ การใช้เครื่องมือปฏิเสธสามารถช่วยได้ไหม

14:01

“ฉันคิดว่านั่นเป็นคำถามที่ดี ดังนั้นจากมุมมองของฉัน สิ่งที่ฉันจะดูคือด้านหนึ่ง กรณีที่แน่ชัดคือที่ที่มีการดำเนินการโดยเจ้าหน้าที่ แต่กรณีที่คุณต้องการเช่นกัน การเห็นการดำเนินการโดยเจ้าหน้าที่จำนวนมากจะบอกว่า ถ้าทีมงานเว็บสแปมดูตอนนี้ พวกเขาจะให้คุณดำเนินการโดยเจ้าหน้าที่ กรณีที่คุณพูด การดำเนินการโดยเจ้าหน้าที่เป็นเรื่องของ เวลาและไม่ใช่แบบว่ามันขึ้นอยู่กับสิ่งที่ทำไปแล้ว -- ฉันไม่รู้ -- เห็นได้ชัดว่ามันทำที่ไหนเมื่อสองสามปีที่แล้ว และมันก็ไม่ใช่แนวเขต แต่แบบที่คุณมองดู และบอกว่า ถ้ามีคนจากเว็บสแปมทีมได้เคล็ดลับนี้ พวกเขาจะดำเนินการโดยเจ้าหน้าที่ และนั่นคือสิ่งที่ฉันจะทำความสะอาดและทำเหมือนเป็นการปฏิเสธสำหรับสิ่งนั้น ใช่ ฉันคิดว่า มันยากที่จะบอกว่ามีเหมือนไทม์ไลน์ที่เจาะจงหรือเปล่า แต่โดยทั่วไป ถ้าทีมเว็บสแปมดูนี่แล้วบอกว่าแบบว่า อะไรๆ ก็ดำเนินไป นี่มันชัดเจนแล้ว หนึ่งสองสามปีที่ผ่านมา มันไม่ได้เป็นอันตรายโดยสิ้นเชิง จากนั้นพวกเขาอาจจะไม่ดำเนินการด้วยตนเองสำหรับสิ่งนั้น "

และฉันคิดว่าคุณคงตอบไม่ได้ แต่มีวิธีใดบ้าง เช่น สมมติว่าเราไม่ได้รับการดำเนินการโดยเจ้าหน้าที่ หรือพวกเขาไม่ได้รับการดำเนินการโดยเจ้าหน้าที่ ลิงก์เหล่านั้นสามารถทำร้ายพวกเขาด้วยอัลกอริธึมได้หรือไม่? เนื่องจากเรารู้สึกว่าเราเห็นการปรับปรุงบางอย่างในบางไซต์ หลังจากที่ปฏิเสธไปแล้ว อีกครั้ง ฉันรู้ว่ามันเป็นเสมอ ไม่เคยเป็นขาวดำ

แน่นอนสามารถเป็นกรณี ดังนั้นมันจึงเป็นสิ่งที่อัลกอริธึมของเราเมื่อเราดูมัน และพวกเขาเห็น โอ้ พวกมันเป็นลิงก์ที่ไม่ดีจริงๆ ที่นี่ บางทีพวกมันอาจจะระมัดระวังมากขึ้นเล็กน้อยเกี่ยวกับลิงก์โดยทั่วไปสำหรับเว็บไซต์ ดังนั้น ถ้าคุณล้างข้อมูลนั้น อัลกอริทึมจะดูและพูดว่า โอ้ มีบ้าง ไม่เป็นไร ไม่เลว.

สรุป: หากคุณมีลิงก์ที่สร้างขึ้นสำหรับ SEO โดยเฉพาะ และคุณมีลิงก์จำนวนมาก ลิงก์เหล่านี้อาจทำให้อัลกอริทึมของ Google ไม่เชื่อถือลิงก์ทั้งหมดของคุณ ดีที่สุดที่จะปฏิเสธกรณีเช่นนี้

อัลกอริทึมของ Google วัด EAT ของผู้เผยแพร่โฆษณาได้อย่างไร

33:40

“ไม่รู้สิ ฉันคิดว่าคงยากที่จะคิดออกอัลกอริธึม และหากมีเรื่องทางเทคนิคอะไรที่คุณควรทำ เราจะแจ้งให้คุณทราบ ดังนั้นหากมีเรื่องเช่นมาร์กอัปการประพันธ์ที่เรา มีบางจุดที่เราคิดว่าน่าจะมีประโยชน์สำหรับสิ่งนี้เราจะนำสิ่งนั้นออกมาอย่างแน่นอน แต่หลาย ๆ อย่างเป็นปัจจัยด้านคุณภาพที่นุ่มนวลกว่าที่เราพยายามคิดออกและไม่ใช่เทคนิคที่คุณ กำลังทำหรือไม่ทำ มากกว่า เช่น พยายามคิดให้ออกว่าผู้ใช้จะมองสิ่งนี้อย่างไร เลยไม่ได้ชี้เฉพาะเจาะจงอะไร "

สรุป: มี "ปัจจัยด้านคุณภาพที่อ่อนนุ่ม" มากมายที่ Google พิจารณา มองสิ่งต่าง ๆ จากมุมมองของผู้ใช้ นอกจากนี้ มาร์กอัปผู้แต่งอาจช่วยให้ Google เข้าใจสิ่งต่างๆ ได้ดีขึ้น

หากมีบางสิ่งอยู่ในหลักเกณฑ์ของผู้ประเมินคุณภาพ มีเหตุผลหรือไม่ที่จะสรุปว่า Google ต้องการให้สิ่งนี้สะท้อนให้เห็นในอัลกอริทึมของพวกเขา

34:44

ฉันคิดว่าโดยทั่วไปแล้ว อาจเป็นแนวปฏิบัติที่ดีที่จะตั้งเป้าหมายให้เป็นเช่นนั้น ฉันหลีกเลี่ยงไม่เน้นมากเกินไปกับสิ่งที่ Google อาจใช้เป็นปัจจัยด้านอัลกอริทึม และมองมันให้มากขึ้น -- เราคิดว่านี่เป็นสิ่งที่ดีสำหรับเว็บ ดังนั้น เราจะพยายามไปในทิศทางนั้นและทำสิ่งเหล่านี้ ชนิดของสิ่งต่างๆ ไม่มากเท่ากับว่าฉันกำลังสร้างเว็บไซต์ที่ดีเพียงเพื่อจะได้อันดับดีขึ้น แต่ฉันกำลังทำเว็บไซต์ที่ดีเพราะเมื่อฉันปรากฏในการค้นหา ฉันต้องการให้ผู้คนมีประสบการณ์ที่ดี แล้วพวกเขาจะกลับมาที่เว็บไซต์ของฉัน และบางทีพวกเขาอาจจะซื้ออะไรซักอย่าง นั่นเป็นแนวทางที่ฉันเห็นว่าไม่ใช่ทำเพื่อจัดอันดับ แต่ทำเพื่อให้มีความสัมพันธ์ที่ดีในระยะยาวบนเว็บ

สรุป: คิดว่าสิ่งที่ดีที่สุดสำหรับผู้ใช้ แม้ว่าปัจจุบันไม่ใช่ทุกสิ่งที่อยู่ใน QRG สะท้อนอยู่ในอัลกอริทึมของ Google สิ่งเหล่านี้ล้วนเป็นขั้นตอนที่ดีในการปรับปรุงคุณภาพโดยรวม

มีสคีมาเพื่อช่วยให้ไซต์ปรากฏสูงขึ้นสำหรับผลการค้นหาด้วยเสียงหรือไม่

36:10

ฉันไม่รู้. ฉันไม่สามารถคิดอะไรได้ทันที ดังนั้นจึงมีมาร์กอัปที่พูดได้ที่คุณสามารถใช้ได้ ซึ่งน่าจะสมเหตุสมผลสำหรับ-- การพิจารณาเพื่อดูว่ามันเหมาะสมที่ใดบนหน้าเว็บ ฉันไม่คิดว่าเราจะใช้มันในทุกสถานที่

สรุป: มาร์กอัป Speakable ยังไม่ได้ใช้ในสถานที่ตั้งทางภูมิศาสตร์ทั้งหมด แต่นี่เป็นจุดเริ่มต้นที่ดี

เคล็ดลับบางประการในการชนะตัวอย่างข้อมูลแนะนำ

38:03

แต่โดยเฉพาะอย่างยิ่งตัวอย่างข้อมูลแนะนำ ฉันไม่คิดว่าเรามีมาร์กอัปประเภทใดที่เจาะจงสำหรับสิ่งนั้น นั่นคือสิ่งที่ถ้าคุณมีโครงสร้างที่ชัดเจนในหน้า ซึ่งช่วยเราได้มาก หากเรารู้จักเหมือนตารางในหน้า เราก็จะดึงมันออกมาได้ง่ายขึ้นมาก แม้ว่าคุณจะใช้ HTML และ CSS แฟนซีเพื่อทำให้ดูเหมือนตาราง แต่จริงๆ แล้วมันไม่ใช่ตาราง ก็ยากที่เราจะดึงออกมา

สรุป: ไม่มีมาร์กอัปที่คุณสามารถเพิ่มเพื่อรับรางวัลตัวอย่างข้อมูลเด่นได้ แต่การใช้แท็ก h และตาราง HTML ปกติสามารถช่วยได้จริงๆ

ควรเพิ่มสคีมาสถานที่ในทุกหน้าหรือไม่

50:47

คำตอบ 51:42 - เท่าที่ฉันรู้ มันเป็นแค่โฮมเพจ ฉันไม่รู้. ท่านใดทราบบ้างครับ?

คำตอบจาก Liz 51:4 7 - ปกติแล้วมันควรจะเป็นเพียงหน้าเดียวสำหรับองค์กรและองค์กร นั่นเป็นคำแนะนำโดยทั่วไป

MARTIN SPLITT 52:00 - ฉันเดาว่ามันไม่สำคัญหรอกว่าหน้าไหนไม่สำคัญเท่ากับว่าอย่าใส่มันในทุกหน้าที่คุณมี ฉันคิดว่าเป็นส่วนสำคัญมากกว่า ฉันคิดว่ามันขึ้นอยู่กับ -- หากคุณเป็นไซต์ข่าว มันอาจจะเหมาะสมที่จะใส่ไว้ในหน้าติดต่อ หน้าเกี่ยวกับ หรืออะไรก็ตาม ในขณะที่ในเว็บไซต์ของร้านค้าหรือร้านอาหาร การวางบนหน้าแรกอาจเป็นเรื่องปกติ

JOHN 52:20 - ฉันคิดว่าในกรณีนี้ มันไม่สำคัญสำหรับเราเท่าเพราะเราต้องสามารถหามันได้จากที่ไหนสักแห่งเช่นโฮมเพจหรือหน้าการติดต่อ แต่ถ้าเรามีมันที่อื่นก็ไม่เปลี่ยนแปลงอะไรสำหรับเรา ดังนั้นสิ่งสำคัญที่ไม่ควรเปรียบเทียบก็คือมาร์กอัปบทวิจารณ์ที่บางครั้งเราเห็นผู้คนใส่คำวิจารณ์ของบริษัทในทุกหน้าของเว็บไซต์ด้วยความหวังว่าจะได้ดาวและผลการค้นหาสำหรับทุกหน้าในเว็บไซต์ของตน และนั่นจะเป็นสิ่งที่ไม่ดีสำหรับเรา แต่ข้อมูลติดต่อ ถ้าคุณมาร์กอัปไว้ แสดงว่าฉันไม่พบปัญหา

สรุป ไม่เป็นไรจริงๆ ควรอยู่ในหน้าติดต่อและอาจเป็นหน้าเกี่ยวกับและหน้าแรกของคุณ การมีสคีมาตำแหน่งทั่วทั้งไซต์ไม่ใช่ปัญหา แต่ก็ไม่จำเป็นเช่นกัน

เหตุใดเครื่องมือ PageSpeed ​​Insights ใหม่ซึ่งอิงจาก Lighthouse จึงเข้มงวดกว่ามากเมื่อให้คะแนนเว็บไซต์

53:05

Marie Haynes: ไม่ใช่คำถามของฉัน แต่เพื่อให้บริบท ข้อมูล Lighthouse ใหม่สำหรับความเร็วหน้าเว็บนั้นรุนแรงกว่า Page Speed ​​Insights ที่เคยเป็นมา ดังนั้นบางอย่างที่มีคะแนนเท่ากับ 80 ใน Page Speed ​​Insights อาจเป็นสีแดง 29 คะแนนใน Lighthouse นั่นเป็นคำถามที่ดี มีแนวโน้มว่าจะเป็นสาเหตุหรือไม่ เพราะเรารู้ว่าในอุปกรณ์เคลื่อนที่ ไซต์ที่ช้ามากอาจถูกลดระดับลงได้ จะดีไหมถ้าเราจะพูดว่า ถ้าคุณอยู่ในการทดสอบ Lighthouse ว่าเราควรจะปรับปรุงสิ่งต่างๆ ให้ดีขึ้นจริง ๆ เพราะมันอาจทำให้เกิดการลดระดับ หรือมีข้อยุติหรือไม่

คำตอบ 54:07 - ดังนั้นเราจึงไม่มีการทำแผนที่แบบตัวต่อตัวของเครื่องมือภายนอกและทั้งหมดที่เราใช้สำหรับโซเชียล ใช่ นั่นทำให้พูดยากจริงๆ แต่ในการค้นหา เราพยายามใช้ข้อมูลจริงผสมกัน มันคืออะไร ข้อมูลการทดสอบในห้องปฏิบัติการ ซึ่งคล้ายกับการทดสอบ Lighthouse และข้อมูลรายงาน Chrome UX โดยพื้นฐานแล้วคืออะไร เรากำลังวัดสิ่งที่ผู้ใช้เว็บไซต์จะได้เห็น

มาร์ติน สปลิต 55:37 - สิ่งสำคัญเช่นกันที่จะต้องเห็นว่า Lighthouse นั้น วัดกันโดยเฉพาะสำหรับการเชื่อมต่อ 3G ที่ค่ามัธยฐาน หรือเช่นโทรศัพท์ประสิทธิภาพปานกลาง ใช่ โดยพื้นฐานแล้ว หากคุณใช้ Apple McIntosh รุ่นล่าสุดหรือคอมพิวเตอร์ Windows ที่เร็วล่าสุดที่มีการเชื่อมต่อแบบมีสายที่ดีจริงๆ หรือการเชื่อมต่อ Wi-Fi ที่ดีจริงๆ ในสำนักงานของคุณ แน่นอนว่าคุณจะเห็นเวลาโหลดเป็นสองวินาที แต่ ผู้ใช้จริงที่มีโทรศัพท์อยู่ในป่าอาจไม่เห็นสิ่งนั้น ดังนั้นมันจึงเป็นหนึ่งในกรณีเหล่านี้ที่ไม่ทำให้เว็บไซต์ของคุณเร็วขึ้น แต่นี่เป็นเรื่องยากจริงๆ ที่จะพูดว่าจะมีลักษณะเป็นอย่างไรจากมุมมองของคนวงใน เนื่องจากเราใช้เมตริกที่เจาะจงมากซึ่งไม่จำเป็นต้องจับคู่กับ สิ่งหนึ่งที่เครื่องมือกำลังเปิดเผย....แน่นอนว่าการแก้ไขเป็นสิ่งสำคัญ เพราะคุณไม่ต้องการให้ผู้ใช้ของคุณรอเว็บไซต์ของคุณตลอดไป ที่จะทำร้ายคุณ ที่จะทำร้ายผู้ใช้ของคุณ ที่จะทำร้ายคุณในการค้นหา แต่ฉันไม่จ่าย -- ฉันจะบอกว่าแค่ดูที่เครื่องมือ หากเครื่องมือกำลังบอกคุณว่าคุณทำได้ดี คุณก็ไม่ควรกังวลกับมันมากเกินไป ถ้าเครื่องมือกำลังบอกคุณว่าคุณทำได้ไม่ดีจริงๆ ฉันคิดว่าเวลาที่ใช้ไปกับการหาเหตุผลว่าทำไมมันถึงบอกว่า อย่างเช่น ถ้ามันเกี่ยวข้องกัน มันก็สูญเปล่า คุณควรดูที่การทำให้ไซต์เร็วขึ้น

ประสิทธิภาพมือถือเป็นปัจจัยที่สำคัญมากสำหรับผู้ใช้ของคุณ เช่นเดียวกับทุกสิ่งทุกอย่าง ดังนั้นผมจะบอกว่าต้องแน่ใจว่าเว็บไซต์ของคุณทำงานได้ดีในสภาพการใช้งานจริง บางทีอาจจะซื้อโทรศัพท์ราคาถูกและลองใช้เว็บไซต์เป็นระยะๆ และถ้า- นั่นคือสิ่งที่ฉันชอบทำ และฉันเคยทำมาก่อนจะเข้าร่วม Google กับทีมพัฒนาที่ฉันทำงานด้วย ฉันชอบดู คุณต้องการใช้เว็บไซต์นี้บนโทรศัพท์เครื่องนี้หรือไม่ มันแบบว่า โอ้ นี่มันน่ากลัว ฉันก็แบบ อืม ใช่ บางทีเราควรทำอะไรกับมันบ้าง

JOHN - ใน Chrome คุณสามารถตั้งค่าและลองใช้ความเร็วการเชื่อมต่อที่แตกต่างกันได้ โปรแกรมจำลองมือถือ ฉันคิดว่านั่นเป็นสิ่งที่ดีจริงๆ ในการดู และดูฐานผู้ใช้ของคุณด้วย ดูข้อมูลการวิเคราะห์ของคุณหากคุณเห็นว่าผู้คนกำลังใช้เว็บไซต์ของคุณกับ iPhone ระดับไฮเอนด์เท่านั้น บางทีอาจไม่ใช่ปัญหาน้อยกว่าถ้าคุณเห็นว่าผู้คนกำลังเชื่อมต่อกับไซต์ของคุณจากการเชื่อมต่อแบบสุ่มในชนบท ซึ่งก็คือ ช้าและพวกเขามีอุปกรณ์ระดับล่าง บางทีอาจจะมากกว่านั้น

สรุป: Lighthouse วัดความเร็วสำหรับการเชื่อมต่อ 3G ดังนั้นไซต์ส่วนใหญ่จะทำงานได้เร็วกว่าที่แสดงที่นี่สำหรับเซสชันส่วนใหญ่ หมายเหตุ: หลังจากแฮงเอาท์นี้เสร็จสิ้น มาร์ตินกล่าวต่อไปว่านี่คือ "การลงสีเนื้อหาอย่างแรก" ที่สำคัญที่สุดในแง่ของการลดอันดับที่อาจเกิดขึ้น

ถ้าคุณชอบอะไรแบบนี้ คุณจะรักจดหมายข่าวของฉัน!

ฉันและทีมรายงานทุกสัปดาห์เกี่ยวกับการอัปเดตอัลกอริทึม ข่าวสาร และเคล็ดลับ SEO ล่าสุดของ Google

วิดีโอและการถอดเสียงแบบเต็ม

คำถามที่ 1:32 - ฉันสงสัยว่าคุณมีคำแนะนำเพิ่มเติมหรือมุมมองเพิ่มเติมเกี่ยวกับการทดสอบในลักษณะที่ SEO สามารถใช้เพื่อการรายงานที่แม่นยำและมั่นใจมากขึ้นกับธุรกิจหรือไม่ เราลองสิ่งนี้แล้วและมันก็ได้ผล และเราทำในลักษณะที่แน่นอน แบบที่ Google จะแนะนำ

คำตอบ 3:20 - จากมุมมองของฉัน ฉันพยายามแยกประเภททางเทคนิคออกจากการเปลี่ยนแปลงประเภทคุณภาพ ดังนั้นอะไรก็ตามที่เป็นเรื่องทางเทคนิคที่ชัดเจนจริงๆ คุณสามารถทดสอบได้ว่ามันทำงานหรือไม่ได้ผล ไม่ใช่เรื่องของการทำงานหรือใช้งานไม่ได้ แต่เป็นเรื่องทางเทคนิคมากมาย โดยเฉพาะอย่างยิ่งเมื่อคุณดูการเรนเดอร์ หรือเมื่อคุณดู Google สามารถจัดทำดัชนีเนื้อหานี้จริงๆ ได้ นั่นคือ สิ่งที่ใช้งานได้หรือไม่ ที่ที่มันยุ่งยากคือทุกอย่างที่เกี่ยวกับ-- มันถูกจัดทำดัชนี แต่มันจะแสดงในการจัดอันดับอย่างไร และฉันคิดว่าสำหรับหลายๆ เรื่องนั้น ไม่มีวิธีใดที่จะทดสอบได้อย่างแท้จริง เพราะหากคุณทดสอบในสถานการณ์ที่แยกออกมา เช่นคุณสร้างไซต์ทดสอบ และคุณตั้งค่าตามคำแนะนำที่คุณมี คุณไม่สามารถสรุปได้ว่าไซต์ทดสอบจะทำงานแบบเดียวกับที่เว็บไซต์ปกติจะทำ บางครั้งก็มีเรื่องง่ายๆ เช่น ถ้าเป็นไซต์ทดสอบ บางทีเราอาจจะไม่แสดงผลแบบเต็มเพราะเราคิดว่าการใช้เวลามากกับสิ่งนี้และสิ่งนี้ไม่สมเหตุสมผล เพราะไม่มีใครดู ไม่เคยปรากฏในผลการค้นหา เหตุใดเราจึงควรใส่ใจที่จะใส่ทรัพยากรจำนวนมากไว้เบื้องหลัง ถ้าคุณทำแบบนั้นบนเว็บไซต์ปกติ มันจะทำงานแตกต่างไปจากเดิมมาก นั่นคือสิ่งที่ฉันไม่มีคำแนะนำที่ชัดเจนจริงๆ เกี่ยวกับสิ่งที่คุณควรทำหรือสิ่งที่คุณไม่ควรทำ ดูเหมือนว่าคุณจะดูแนวโน้มทั่วไปที่คุณเห็นเว็บไซต์นั้นปรากฏขึ้น การเปลี่ยนแปลงในการจัดอันดับที่คุณเห็นสำหรับข้อความค้นหาเหล่านั้น และพยายามใช้แนวทางปฏิบัติที่ดีที่สุดที่นั่น

คำถามที่ 5:21 - ดังนั้นบางที ถ้า- ตัวอย่างที่เป็นรูปธรรม คุณอาจใช้สิ่งนั้นเพื่อ -- อาจมีประโยชน์ เช่น การทดสอบแท็กชื่อ ใช่ไหม ถ้าคุณทำอย่างนั้น-- เราควรมองหาอะไร? หรือมีอะไรที่ต้องพิจารณาเพื่อคลี่คลาย - นี่เป็นเพราะการทดสอบของเราหรือเป็นเพราะสิ่งที่เปลี่ยนแปลงเกี่ยวกับเซิร์ฟเวอร์, algo, พลวัตของการแข่งขัน? [หัวเราะ] สมมติว่าเรากำลังทำอย่างอื่นเพื่อดูสิ่งภายนอกเหล่านั้น

คำตอบ 5:56 - ฉันคิดว่าการเปลี่ยนชื่อแท็กนั้นค่อนข้างซับซ้อนในฝั่งของเรา เนื่องจาก Google ใช้แท็กชื่อที่คุณให้ไว้จริง ๆ ในด้านหนึ่งสำหรับการจัดอันดับใน อย่างอื่นเพื่อแสดงในผลการค้นหา เช่นเดียวกับเดสก์ท็อปและอุปกรณ์เคลื่อนที่ เรามีจำนวนห้องที่แตกต่างกัน ดังนั้นเราอาจแสดงแท็กชื่อที่แตกต่างกันเล็กน้อย ผู้ใช้อาจตอบสนองต่อสิ่งนั้นในรูปแบบต่างๆ ดังนั้น คุณจึงสามารถจัดอันดับในลักษณะเดียวกันได้ แต่ผู้ใช้อาจคิดว่า โอ้ นี่เป็นเพจที่ยอดเยี่ยม ฉันจะแสดงให้สูงขึ้น-- หรือฉันจะคลิกที่มันในผลการค้นหาเพราะมันดูเหมือนหน้าที่ยอดเยี่ยม แล้วคุณมีการเข้าชมมากขึ้น แต่อันดับก็เท่าเดิม แล้วมันเป็นสิ่งที่ดีหรือไม่? ก็น่าจะใช่นะผมว่า หากคุณเพียงแค่ดูอันดับ ก็จะดูเหมือนว่าคุณไม่ได้เปลี่ยนแปลงอะไรเลย และเราเพิ่งได้รับการเข้าชมมากขึ้น

แต่นั่นคือสิ่งที่มีหลายแง่มุมที่แตกต่างกันออกไป นั่นคือสิ่งที่ฉันคิดว่าในฐานะ SEO มีประโยชน์ในด้านหนึ่งที่จะมีความเข้าใจทางเทคนิคเกี่ยวกับสิ่งที่เกิดขึ้น แต่ยังต้องมีความเข้าใจด้านการตลาดและคุณภาพมากขึ้นว่าผู้ใช้ตอบสนองต่อการเปลี่ยนแปลงอย่างไร เป็นการเปลี่ยนแปลงระยะยาวที่เราอาจส่งผลกระทบกับผู้ใช้ คุณจะขับเคลื่อนสิ่งนั้นได้อย่างไร เพื่อให้แน่ใจว่าไซต์ของเราถูกมองว่าเป็นไซต์ที่เกี่ยวข้องมากที่สุดในสถานการณ์ที่ผู้คนกำลังค้นหาสิ่งที่เกี่ยวข้องกับสิ่งนั้น และฉันคิดว่านั่นเป็นสิ่งที่ยากต่อการทดสอบจริงๆ มันเหมือนกับว่าในการตลาดแบบเดิมๆ ที่พวกเขาฝึกฝนมาหลายปี มันยากจริงๆ ที่จะทดสอบ อย่างเช่น สิ่งนี้มีผลกระทบอย่างมากจริง ๆ หรือไม่? เป็นสิ่งที่พวกเขามองในภาพรวมหรือศึกษาผู้ใช้ ซึ่งคุณสามารถทำได้ในฐานะ SEO เช่นกัน เสียใจ. [เสียงหัวเราะ]

คำถามที่ 7:58 - ฉันมีคำถามตรงกว่านี้ ไซต์ของเราจำนวนหนึ่งที่ใช้ Cloudflare และเราสังเกตเห็นว่าไซต์เหล่านี้บล็อก Googlebot โดยตรงใช่ไหม แต่มันไม่ได้ส่งผลกระทบมากนักต่อการจัดอันดับของเรา ต่อการมองเห็นของเรา และอื่นๆ เป็นการพยายามหาวิธี เช่น คุณใช้บอทอื่นเพื่อรวบรวมข้อมูลดัชนีนอก Googlebot โดยตรงหรือไม่ และเราควรคิดอย่างไรเมื่อ CDN พยายามจะบล็อกบอท

คำตอบ 8:33 - ใช่ ฉันไม่รู้ว่าตอนนี้มีการตั้งค่า Cloudflare อย่างไร แต่ฉันรู้ว่าในอดีตพวกเขาเคยบล็อกคนที่แกล้งทำเป็น Googlebot ดังนั้น ถ้าคุณใช้ แบบของคุณเอง ไม่รู้สิ Screaming Frog หรืออะไรก็ตามที่คุณบอกว่า ฉันใช้ Googlebot user agent พวกเขาจะบล็อกสิ่งนั้น เพราะพวกเขาสามารถบอกได้ เช่น นี่ไม่ใช่สิ่งที่ถูกต้องตามกฎหมาย Googlebot เราสามารถบล็อกสิ่งนั้นได้ แต่โดยส่วนใหญ่ ฉันคิดว่าพวกเขามีแนวทางปฏิบัติเพียงพอที่จะรู้จัก Googlebot ปกติและปล่อยให้รวบรวมข้อมูลได้ตามปกติ

คำถามที่ 9:02 - ใช่ มันน่าสนใจ เพราะติดต่อกับเพื่อนร่วมงานจำนวนมากในหน่วยงานอื่น และพวกเขาก็จำลองสถานการณ์ที่คล้ายกัน แม้แต่ในไซต์ของตนเอง เช่น มีตั๋วสนับสนุนใน Cloudflare และนั่นก็ถูกบล็อกเช่นกันเมื่อฉันพยายามแสดงผลโดยตรงจาก Googlebot หรือสมาร์ทโฟน Googlebot

คำตอบ 9:21 - ตกลง ใช่ เราไม่มีวิธีแก้ปัญหา เช่น ถ้าเว็บไซต์บล็อกเรา แสดงว่าเราติดอยู่ แต่โดยปกติหากบริการอย่าง Cloudflare บล็อกเราโดยค่าเริ่มต้น นั่นก็จะส่งผลต่อเว็บไซต์จำนวนมาก และเราจะสังเกตได้ว่า เราน่าจะติดต่อ Cloudflare เกี่ยวกับเรื่องนั้น อาจเป็นได้ว่าพวกเขามีระดับการบริการที่แตกต่างกัน ดังนั้นมันเหมือนกับว่าคุณอยู่ชั้นล่าง ก็เหมือนกับบริการฟรี แต่เรามีข้อ จำกัด เกี่ยวกับปริมาณการรับส่งข้อมูล ฉันไม่รู้ว่าพวกเขามีแบบนั้นหรือเปล่า นั่นคือสิ่งที่ฉันเห็นกับผู้ให้บริการโฮสต์รายอื่น ซึ่งหากคุณตั้งค่าโฮสติ้งเริ่มต้นฟรี บางครั้งพวกเขาก็จำกัดการรับส่งข้อมูลและบล็อกสิ่งต่างๆ

มาร์ติน สปลิตต์: คุณอาจไม่เห็นในทันทีว่าในสถิติจากอันดับของคุณและอะไร เพราะโดยพื้นฐานแล้ว หากเรามีเนื้อหาจากคุณ และโดยพื้นฐานแล้ว เว็บไซต์ไม่ได้ -- ขึ้นอยู่กับสิ่งที่ถูกบล็อก ในกรณีนี้ หมายความว่าเพราะฉันไม่เห็นสิ่งนั้น และฉันใช้เว็บไซต์ไม่กี่แห่งที่อยู่เบื้องหลัง Cloudflare และฉันก็ไม่มีปัญหาใดๆ แต่แล้วอีกครั้ง ฉันไม่มีเว็บไซต์ขนาดใหญ่หรือชอบการเข้าชมจำนวนมากเพราะฉันใช้แผนบริการฟรี นั่นคือ -- แต่ถ้าคุณไม่ได้รับเหมือนข้อผิดพลาดจากฝั่งของเรา -- อาจเป็นเพราะเรากำลังเก็บเนื้อหาที่เราได้เห็นครั้งล่าสุด และนั่นก็อยู่ในอันดับที่ดี และก็ไม่เป็นไร

คำตอบ 12:09 - ใช่ ฉันคิดว่าจะเกิดอะไรขึ้นในกรณีเช่นคุณ เราจะชะลอการรวบรวมข้อมูล และเราจะพยายามเก็บเนื้อหาที่เราดึงข้อมูลได้มากขึ้นในดัชนี และเราจะรวบรวมข้อมูลให้นานขึ้นอีกหน่อย แต่นั่นก็หมายความว่าหากคุณทำการเปลี่ยนแปลงบนเว็บไซต์ของคุณ เราจะใช้เวลานานขึ้นกว่าจะแก้ไขได้ หากเราต้องรวบรวมข้อมูลใหม่อย่างมีนัยสำคัญ เช่น ฉันไม่รู้ AMP หรือคุณเพิ่มข้อมูลบางอย่างทั่วทั้งไซต์ นั่นจะใช้เวลานานกว่ามาก ดังนั้น หากคุณเห็นเป็นประจำว่าเราไม่สามารถรวบรวมข้อมูลด้วย Googlebot ปกติได้ นั่นคือสิ่งที่ฉันจะจัดการกับโฮสต์เพื่อให้เรามองเห็นได้

คำถาม 14:01 - เยี่ยมมาก ดังนั้น ฉันจึงมีคำถามเกี่ยวกับเครื่องมือปฏิเสธ ดังนั้นเราจึงได้คนที่ต้องการให้เราทำการตรวจสอบลิงก์อยู่ตลอดเวลา และนับตั้งแต่ Penguin 4.0 ในเดือนกันยายนปี 2016 ที่ Gary Illyes ได้กล่าวไว้ และฉันคิดว่าคุณก็พูดเช่นกัน เช่น Google เพิกเฉยต่อลิงก์ที่ผิดธรรมชาติได้ดีมาก ดังนั้น ความคิดของฉันในขณะนั้นก็คือ เราไม่ควรใช้เครื่องมือปฏิเสธเพื่อขอให้ Google เพิกเฉยต่อลิงก์ที่เพิกเฉยอยู่แล้ว เว้นแต่ว่าคุณมีการดำเนินการโดยเจ้าหน้าที่สำหรับลิงก์ที่ผิดปกติ ดังนั้นเราจึงแนะนำเฉพาะไซต์ที่มีการสร้างลิงก์ พยายามจัดการสิ่งต่างๆ สิ่งต่างๆ ที่เป็นลิงก์ที่ผิดธรรมชาติเท่านั้น แต่ฉันคิดว่ามีความสับสนมากมายในหมู่ผู้ดูแลเว็บ เพราะฉันเห็นคนอยู่ตลอดเวลา คุณรู้ไหม เรียกเก็บเงินเป็นจำนวนมหาศาลเพื่อการตรวจสอบ เพื่อปฏิเสธลิงก์ที่มีเหตุผล ฉันรู้ว่าพวกเขากำลังถูกเพิกเฉย ดังนั้นฉันจะชอบถ้าเราสามารถมีความกระจ่างขึ้นอีกหน่อย ดังนั้น ถ้าผมยกตัวอย่างให้คุณได้ เช่น ถ้ามีเจ้าของธุรกิจที่จ้างบริษัท SEO เมื่อสองสามปีก่อน และบริษัท SEO นั้นก็มีแขกมาโพสต์เพียงเพื่อขอลิงก์ มีคุณภาพปานกลาง ถ้าคุณรู้ว่าฉันหมายถึงอะไร ไม่ใช่ ultra spammy เรามั่นใจได้ไหมว่า Google เพิกเฉยต่อลิงก์เหล่านั้น หรือเราควรเข้าไปปฏิเสธดี?

คำตอบ 15:22 - ฉันคิดว่านั่นเป็นคำถามที่ดี ดังนั้นจากมุมมองของฉัน สิ่งที่ฉันจะดูในอีกด้านหนึ่งก็คือ กรณีที่มีการดำเนินการโดยเจ้าหน้าที่ แต่กรณีที่คุณอยากเห็นการดำเนินการโดยเจ้าหน้าที่เป็นจำนวนมากเช่นกัน ถ้าทีมงานเว็บสแปมดูตอนนี้ พวกเขาจะให้การดำเนินการโดยเจ้าหน้าที่แก่คุณ กรณีที่คุณบอกว่า การดำเนินการโดยเจ้าหน้าที่นั้นเป็นเรื่องของเวลามากกว่า และไม่ใช่แบบว่าอิงจากสิ่งที่ทำไปแล้ว-- ฉันไม่รู้-- เห็นได้ชัดว่ามันทำที่ไหนสักสองสามปี ที่แล้วและมันก็ไม่ใช่แนวเขต แต่ประเภทที่คุณดูและพูดว่า ถ้ามีคนจากเว็บสแปมทีมได้คำแนะนำแบบนี้ พวกเขาจะดำเนินการโดยเจ้าหน้าที่ และนั่นคือสิ่งที่ฉันจะทำความสะอาดและทำอย่างแน่นอน เหมือนเป็นการปฏิเสธสำหรับสิ่งนั้น ใช่ ฉันคิดว่ามันยากที่จะบอกว่ามีไทม์ไลน์เฉพาะหรือไม่ แต่โดยทั่วไปแล้ว หากทีมเว็บสแปมดูสิ่งนี้แล้วพูดว่า สิ่งต่างๆ ได้ดำเนินไป สิ่งนี้ทำอย่างชัดเจนเมื่อสองสามปีก่อน มันไม่ได้เป็นอันตรายโดยสิ้นเชิง จากนั้นพวกเขาอาจจะไม่ดำเนินการด้วยตนเองสำหรับสิ่งนั้น

คำถาม 16:43 - และฉันคิดว่าคุณอาจไม่สามารถตอบคำถามนี้ได้ แต่มีวิธีใดบ้าง เช่น สมมติว่าเราไม่ได้รับการดำเนินการโดยเจ้าหน้าที่ หรือพวกเขาไม่ได้รับการดำเนินการโดยเจ้าหน้าที่ ลิงก์เหล่านั้นสามารถทำร้ายพวกเขาด้วยอัลกอริธึมได้หรือไม่? เนื่องจากเรารู้สึกว่าเราเห็นการปรับปรุงบางอย่างในบางไซต์ หลังจากที่ปฏิเสธไปแล้ว อีกครั้ง ฉันรู้ว่ามันเป็นเสมอ ไม่เคยเป็นขาวดำ

คำตอบ 17:03 - เป็นเช่นนั้นแน่นอน ดังนั้นมันจึงเป็นสิ่งที่อัลกอริธึมของเราเมื่อเราดูมัน และพวกเขาเห็น โอ้ พวกมันเป็นลิงก์ที่ไม่ดีจริงๆ ที่นี่ บางทีพวกมันอาจจะระมัดระวังมากขึ้นเล็กน้อยเกี่ยวกับลิงก์โดยทั่วไปสำหรับเว็บไซต์ ดังนั้น ถ้าคุณล้างข้อมูลนั้น อัลกอริทึมจะดูและพูดว่า โอ้ มีบ้าง ไม่เป็นไร ไม่เลว.

คำถามที่ 17:24 - โดยทั่วไปแล้วการปฏิเสธเพียงเพื่อป้องกันการดำเนินการโดยเจ้าหน้าที่ยังคงดีอยู่ใช่หรือไม่

คำตอบ 17:29 - ฉันคิดว่าถ้าคุณอยู่ในกรณีที่ชัดเจนว่าทีมเว็บสแปมจะให้การดำเนินการโดยเจ้าหน้าที่ตามสถานการณ์ปัจจุบัน นั่นคือสิ่งที่ฉันจะไม่ปฏิเสธ

คำถามที่ 17:37 - เป็นการดีที่จะคิดแบบ Google เหมือนคนในทีมสแปมของ Google แค่คิดว่า อย่างเช่น คุณรู้ไหม ถ้าพวกเขาดูนี่ พวกเขาจะทำอย่างไรหากพวกเขาทำ

คำตอบ 17:47 - ใช่

คำถาม 17:48 - ปัญหาอยู่ที่คนส่วนใหญ่ไม่รู้ ฉันหมายความว่า เจ้าของธุรกิจทั่วไปไม่รู้ว่าลิงก์ใดที่ทีมสแปมของเว็บจะ-- ฉันหมายความว่ามีหลักเกณฑ์อยู่ แต่ที่จริงแล้ว มันยากที่จะตีความสิ่งเหล่านั้น ฉันคิดว่า -- ฉันหมายความว่า ฉันมีข้อกังวลอยู่สองสามข้อ แต่ข้อกังวลหลักของฉันคือมีคนใช้เงินมากมายไปกับการตรวจสอบลิงก์ที่ฉันคิดว่าไม่คุ้มค่า ในทางกลับกัน เราอาจไม่ได้ทำการตรวจสอบลิงก์และปฏิเสธบางไซต์ที่อาจได้รับประโยชน์จากมัน ดังนั้น ฉันชอบที่จะ ฉันคิดว่าสิ่งที่คุณพูดได้ช่วยไว้มาก เพื่อที่เราจะ-- คุณก็รู้ว่าดี

คำตอบ 18:22 - ใช่ ฉันคิดว่าสำหรับไซต์ส่วนใหญ่ที่มีการผสมผสานแบบปกติซึ่งเหมือนกับว่าคุณทำตามคำแนะนำที่ไม่ดีในอดีต และมันเหมือนกับว่าคุณได้ดำเนินการต่อไป และตอนนี้สิ่งต่างๆ ค่อนข้างเป็นธรรมชาติ แล้วพวกเขาก็ไม่จำเป็นต้องทำอย่างนั้นจริงๆ นั่นคือเป้าหมายของสิ่งเหล่านี้ และนั่นเป็นสาเหตุที่เครื่องมือปฏิเสธไม่เหมือนกับคุณลักษณะหลักใน Search Console คุณมองหามันอย่างชัดเจน ทั้งหมดนี้ทำโดยตั้งใจเพราะสำหรับไซต์ส่วนใหญ่ คุณไม่จำเป็นต้องเน้นที่ลิงก์มากนัก สิ่งที่ฉันชอบเกี่ยวกับเครื่องมือปฏิเสธคือถ้าคุณกังวลเกี่ยวกับเรื่องนี้ คุณยังสามารถไปที่นั่นและเป็นแบบ โอเค ฉันรู้ว่ามีเพียงไม่กี่สิ่งที่เราทำเมื่อสองสามปีมานี้ ที่ผ่านมา และฉันกังวลมากเกี่ยวกับเรื่องนั้น ถ้าอย่างนั้นการปฏิเสธพวกเขาในมุมมองของฉันก็ไม่ใช่ปัญหา ฉันจะไม่ออกไปค้นหาทุกสิ่งโดยเฉพาะ แต่ถ้าคุณรู้เรื่องนี้แล้วและกังวลเรื่องนั้นจริงๆ คุณก็สามารถดูแลมันได้

คำถาม 19:27 - ฉันมีคำถามเกี่ยวกับหนึ่งในเว็บไซต์ลูกค้าของเรา พวกเขามีสโมสรอยู่ -- พวกเขามีสโมสรในสามเมืองในนิวเซาท์เวลส์ และแต่ละสโมสรมีโดเมนย่อยบนเว็บไซต์ ตอนนี้ เมื่อพวกเขาเพิ่มหน้าใดๆ ลงในเว็บไซต์ของตน พวกเขาจะสร้างหน้าสำหรับโดเมนย่อยแต่ละโดเมน เมื่อเร็วๆ นี้ พวกเขาได้เพิ่มเพจ ซึ่งเกี่ยวกับกิจกรรมของสโมสร และพวกเขาได้เพิ่มหน้านี้ใน-- โดเมนย่อยทั้งหมดของพวกเขา ดังนั้นจึงหมายความว่าโดเมนย่อยทั้งหมดมีเนื้อหาเหมือนกัน ยกเว้นชื่อหน้าต่างกัน เพราะเมื่อพวกเขาเพิ่มใน--สำหรับซิดนีย์ พวกเขาเพิ่มชื่อที่ตั้งของตนในแท็กชื่อ เมื่อพวกเขาเพิ่มสำหรับ Newcastle พวกเขาเพิ่ม Newcastle ในแท็กชื่อ แต่เนื้อหาที่เหลือในหน้านั้นเหมือนกัน แล้วจะเป็นปัญหาไหมเพราะมี 50 โดเมนย่อย และสร้าง 50 หน้า ซึ่งมีเนื้อหาเหมือนกันยกเว้นชื่อ?

คำตอบ 20:36 - ฟังดูไม่ค่อยมีประสิทธิภาพเท่าไหร่ ฉันหมายความว่า คุณกำลังพูดถึงมันแล้ว และแบบว่า มันดูเหมือนบางอย่างที่สามารถทำได้แตกต่างออกไป ฉันคิดว่าถ้าคุณอยู่ในกรณีที่คุณมี 50 โดเมนย่อยที่มีเนื้อหาเหมือนกัน และคุณเพียงแค่เปลี่ยนแท็กชื่อ แสดงว่าคุณอาจไม่ได้ให้เนื้อหาที่เป็นประโยชน์มากมายแก่เรา นั่นคือสถานการณ์ที่ฉันจะพูด การรวมสิ่งต่าง ๆ และสร้างหน้าที่แข็งแกร่งจริงๆ แทนที่จะทำให้สิ่งต่าง ๆ เจือจางในโดเมนย่อยมากขึ้น

คำถามที่ 21:44 - แล้วการสร้างหน้าหนึ่งแล้วใช้ Canonical URL ไปยังหน้าตำแหน่งอื่นล่ะ ฉันต้องการสร้างหน้าเดียว ซึ่งเราจะพูดถึงกิจกรรมของพวกเขา และฉันจะใช้ลิงก์นี้เป็น URL ตามรูปแบบบัญญัติไปยังหน้าสถานที่อื่นๆ

คำตอบ 22:10 - ที่ตั้ง-- ใช่ ฉันคิดว่ามันน่าจะสมเหตุสมผลเพราะคุณรวมสิ่งต่าง ๆ เข้าด้วยกันอีกครั้ง จากนั้น คุณกำลังสร้างหน้าที่แข็งแกร่งเพียงหน้าเดียว แทนที่จะเป็นหน้าเจือจางหลายหน้า

คำถาม 22:20 - เนื่องจากจะเกิดอะไรขึ้นเมื่อมีผู้เยี่ยมชมเว็บไซต์ และเลือกตำแหน่งของตน บุคคลนั้นจะเปลี่ยนเส้นทางบุคคลนั้นไปยังโดเมนย่อยที่พวกเขาระบุไว้สำหรับตำแหน่งที่แน่นอนของตนโดยอัตโนมัติ นั่นคือเหตุผลที่พวกเขาต้องการเพจในโดเมนย่อยนั้น ฉันคิดว่านั่นเป็นเหตุผลว่าทำไมถ้าเราเก็บหน้าเดียวและเพิ่ม URL ตามรูปแบบบัญญัติ นั่นจึงมีเพียงตัวเลือกเดียวที่เรามีในขณะนี้

คำตอบ 23:08 - โอเค แต่ฉันคิดว่าถ้าคุณมีหน้าแยกกัน ซึ่งคุณจำเป็นต้องมีหน้าเหล่านั้นด้วยเหตุผลทางเทคนิคบนไซต์ และคุณใส่ตามรูปแบบบัญญัติ นั่นเป็นวิธีที่ดี

คำถามที่ 23:21 - จะเป็นเช่นไรไหม เช่น ธุรกิจที่มีแฟรนไชส์หลายแห่งในสถานที่ต่างกันซึ่งโดยพื้นฐานแล้วจะมีเนื้อหาเหมือนกันสำหรับแฟรนไชส์แต่ละแห่งจะอยู่ในเมืองหรือเขตการปกครองที่แตกต่างกัน หรืออะไรก็ตาม และประเภทของช่องทางจากคุณ มุมมองกลับไปที่หน้าเดียว?

คำตอบ 23:34 - ฉันคิดว่ามันค่อนข้างยุ่งยากอยู่เสมอ เพราะคุณกำลังสร้างสมดุลให้ผู้คนที่กำลังมองหาธุรกิจประเภทนั้นในสถานที่ตั้งเฉพาะกับหน้าข้อมูลประเภทรอบๆ ธุรกิจนั้นโดยตรง นั่นคือสิ่งที่บางครั้งควรแยกส่วนสำหรับธุรกิจออกจากกัน บางครั้ง การมีข้อมูลทั่วไปประเภทหนึ่งไว้ตรงกลางก็สมเหตุสมผลแล้ว และต้องมีหน้า Landing Page ของตำแหน่งที่เหมือนกัน เช่น ที่เน้นที่ที่อยู่ เวลาทำการ สิ่งของประเภทนั้นมากกว่า

คำถามที่ 24:12 - ใช่ ฉันมี-- ฉันมีคำถามที่เกี่ยวข้องเกี่ยวกับประเด็นบัญญัติที่คุณกำลังทำอยู่ นี่เป็นคำถามที่ผมและทีมมีมานานหลายปี และเรายังไม่รู้วิธีแก้ปัญหาอย่างแน่นอน ดังนั้น หากคุณกำลังจัดการไซต์อีคอมเมิร์ซขนาดใหญ่ที่มีผลิตภัณฑ์มากมายและหลายประเภท สมมติว่าคุณอยู่ในหน้าหมวดหมู่ที่มีตัวกรองและแง่มุมต่างๆ มากมาย และสิ่งต่างๆ ที่มีลักษณะเช่นนั้นซึ่งเปลี่ยนเนื้อหาของหน้าเล็กน้อย แต่อาจไม่เพียงพอที่จะพิสูจน์ว่ามี URL ของตัวเอง แต่ในบางกรณีด้วยตัวกรองบางตัว อาจเป็นเหตุให้มี URL ของไซต์ คุณจะจัดการกับการรวบรวมข้อมูลในสถานการณ์นั้นอย่างไร? แท็กตามรูปแบบบัญญัติทำงานอย่างไร เป็นโซลูชันแบบครอบคลุมหรือไม่ในการสร้างหน้าเดียวที่จัดทำดัชนี หรือคุณควรดู คุณรู้หรือไม่ว่าไม่มีการจัดทำดัชนีแง่มุมและตัวกรองบางอย่าง หรือใช้โรบ็อต หรือคุณจะควบคุมสิ่งนั้นสำหรับไซต์อีคอมเมิร์ซขนาดใหญ่ได้อย่างไร

คำตอบ 24:57 - นั่นเป็นเรื่องยาก ฉันไม่คิดว่าเรามีคำแนะนำที่ชัดเจนในตอนนี้ นั่นคือสิ่งที่วิธีการต่าง ๆ ทั้งหมดเหล่านี้สามารถเข้าใจได้ โดยทั่วไป ฉันพยายามหลีกเลี่ยงการใช้ robots.txt เพราะสิ่งที่อาจเกิดขึ้นคือเราค้นหา URL เราแค่ไม่รู้ว่ามีอะไรบ้าง ดังนั้น ถ้าคุณไม่พบปัญหาที่ทำให้โหลดบนเซิร์ฟเวอร์มากเกินไป ฉันพยายามใช้สิ่งต่าง ๆ เช่น ไม่มีดัชนี ใช้ rel canonical บางทีคุณอาจใช้ rel no-follow กับลิงก์ภายในไปยังประเภทของ funnel เพื่อให้ชัดเจนขึ้นเล็กน้อยว่าเราควรรวบรวมข้อมูลดัชนีอะไร แทนที่จะใช้ robots.txt แต่ประเภทของการตัดสินใจว่าจะรวมสิ่งต่าง ๆ ไว้ในหน้าระดับดัชนีเมื่อใด และเมื่อใดควรบล็อกจากการจัดทำดัชนี เมื่อต้องแนะนำอย่างนุ่มนวลไปยัง URL ตามรูปแบบบัญญัติหนึ่งๆ นั่น-- บางครั้งมันก็ยุ่งยากจริงๆ

คำถาม 25:53 - เพราะบางครั้ง Canonicals จะถูกละเว้นหากเนื้อหาของหน้าแตกต่างกันมากเกินไป

คำตอบ 25:57 - ถูกต้อง หากเนื้อหาแตกต่างกัน เราอาจกล่าวได้ว่า หน้าเหล่านี้ต่างกัน เราไม่ควรใช้บัญญัติ ในขณะที่คุณอาจบอกว่า นี่คือสิ่งที่ฉันไม่ต้องการที่จะจัดทำดัชนีจริงๆ บางทีการไม่มีดัชนีก็สมเหตุสมผลมากกว่าบัญญัติ คุณยังสามารถรวมทั้งสองอย่างเข้าด้วยกัน เราไม่แนะนำให้รวมมันเข้าด้วยกันเพราะมันเป็นเรื่องยากสำหรับเราที่จะพูดว่า คุณหมายถึงอะไร คุณกำลังบอกว่าสิ่งเหล่านี้เหมือนกัน แต่มีอันหนึ่งที่จัดทำดัชนีได้ และอีกอันหนึ่งไม่สามารถจัดทำดัชนีได้ แล้วมันไม่เหมือนกัน แต่มันเป็นสิ่งที่ฉันคิดว่าตลอดทั้งปีจะมีคำแนะนำที่ชัดเจนเกี่ยวกับสิ่งที่สามารถทำงานได้ที่นั่น แต่โดยเฉพาะอย่างยิ่งกับไซต์อีคอมเมิร์ซขนาดใหญ่ ด้านการรวบรวมข้อมูลอาจค่อนข้างท้าทาย

คำถามที่ 26:46 - มีสถานการณ์หนึ่งที่ฉันพยายามคิดหาลูกค้าสองสามรายเมื่อเร็วๆ นี้ เรากำลังพยายามหาสาเหตุว่าทำไมเราจึงไม่สามารถทิ้งเว็บไซต์ที่ยังคงใช้ HTTP อยู่ได้ และดูเหมือนว่าจะถูกละทิ้งไปเพราะหน้าเว็บไม่ได้รับการอัปเดตมาระยะหนึ่งแล้ว และเนื้อหาก็เก่า ล้าสมัย และโดยทั่วไป ค่อนข้างบาง ฉันจึงมีทฤษฎีสองสามข้อเกี่ยวกับเรื่องนี้ ฉันคิดว่าส่วนหนึ่งอาจเป็นเพราะอยู่ในดัชนีมานานจนคุณต่างก็มีปัจจัยที่ไว้ใจได้ในตัวพวกเขา และเป็นการยากที่จะแกะที่นั่งออก 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.

คำถามที่ 42:29 - เป็นเรื่องเกี่ยวกับเว็บไซต์ตัวแทนท่องเที่ยวสำหรับการเดินทาง เราเลือกการค้นหาภายในเพื่อแสดงเนื้อหาแบบไดนามิก เช่น 10 อันดับโรงแรมที่ถูกที่สุดในเมืองค้นหา โอเคไหม ดังนั้นเฟรมหน้าจะโหลดในทันที แต่ผลการค้นหาโรงแรมที่ถูกที่สุด 10 อันดับแรกโหลดแบบไดนามิกใน 30 วินาทีนับตั้งแต่มีการค้นหาเนื่องจากเว็บไซต์ต้องทำการค้นหานี้ที่ด้านหลังแล้วเปรียบเทียบและปรับแต่งผลลัพธ์เพื่อแสดงรายการสำหรับผู้ค้นหา 10 อันดับราคาถูก โรงแรม ดังนั้นจึงต้องใช้เวลาเล็กน้อยในการแสดงรายการ ดังนั้นตอนนี้ Googlebot จะเห็นเฉพาะพื้นหลังของหน้าเท่านั้น จากนั้นตัวยึดตำแหน่งว่าง 10 ตัวจะเป็นตำแหน่งที่ผลลัพธ์จะโหลดในภายหลังเล็กน้อยหลังจากดำเนินการค้นหาภายในแล้ว ดังนั้น เนื่องจากนี่เป็นเทรนด์สำหรับเว็บไซต์ท่องเที่ยวที่จะนำเสนอข้อมูลที่สดใหม่ที่สุดและแม่นยำที่สุด ฉันกำลังคิดว่า Google กำลังทำอะไรเกี่ยวกับเรื่องนี้ แน่นอน เราสามารถแสดงรายการเนื้อหาคงที่ในหน้าเหล่านี้ได้เช่นเดียวกับเว็บไซต์อื่น ๆ ทั้งหมดที่ทำในปัจจุบันสำหรับ Google ถ้าฉันอาจพูดอย่างนั้น แต่นั่นเป็นการเอาชนะจุดประสงค์ของสิ่งที่ผู้ใช้ส่วนใหญ่ต้องการเห็นในตอนนี้ ทั้งสดและราคาถูก

คำตอบ 44:00 - ดังนั้นถ้ามันไม่โหลดที่นั่น เราก็สร้างดัชนีไม่ได้ แต่โดยปกติ นั่นเป็นเรื่องของเราไม่สามารถประมวลผล JavaScript หรืออาจถูกบล็อกไม่ให้เข้าถึงเนื้อหาที่นั่นจริงๆ จึงเป็นสิ่งที่คุณสามารถทำได้ในลักษณะที่จะทำงาน ไม่ใช่เพราะการออกแบบที่จะใช้งานไม่ได้ นั่นคือสิ่งที่คุณสามารถเจาะลึกรายละเอียดโดยใช้สิ่งต่างๆ เช่น การทดสอบความเหมาะกับอุปกรณ์เคลื่อนที่ เพื่อดูว่ามีข้อผิดพลาด JavaScript เกี่ยวข้องหรือไม่ หากสิ่งต่างๆ ถูกบล็อก และปรับแต่งจากที่นั่น ดังนั้นจึงไม่ใช่เรื่องที่เป็นไปไม่ได้ แต่ต้องใช้เวลาสักหน่อย

คำถาม 44:42 - จอห์น ฉันเจาะลึกสิ่งนั้นเพื่อให้แน่ใจว่าไม่มีสิ่งใดถูกบล็อกจาก Google สิ่งเดียวที่เราต้องการให้ Google ทำคือรอสักครู่เพื่อให้เนื้อหาแบบไดนามิกโหลดเข้าสู่หน้าเว็บ คุณรู้หรือไม่ นี่คือขั้นตอนต่อไป ถ้าฉันจะพูดอย่างนั้น เพราะถึงแม้หน้านี้จะไม่เหมือนกับการเลื่อนที่ไม่มีที่สิ้นสุด สมมติว่า Facebook เป็นหน้าผลลัพธ์ 10 หน้าแบบจำกัด ดังนั้นจึงมีขอบเขต มีจำนวนจำกัด สิ่งนั้นคือ Google ควรจะรอเล็กน้อยสำหรับเนื้อหาแบบไดนามิก ฉันแค่ยกตัวอย่างให้คุณ แต่ฉันแน่ใจว่ามีตัวอย่างอื่นๆ มากมายในป่า และเนื่องจากเป็นแนวโน้มที่ผู้คนจะเห็นเนื้อหาแบบไดนามิก เพราะพวกเขาจัดเรียงสิ่งต่าง ๆ และเวลาที่พวกเขาใช้จ่ายน้อยลง ผู้คนใช้เวลาบนเว็บไซต์น้อยลงและน้อยลง และพวกเขาต้องการค้นหาอย่างรวดเร็วที่สุด ผลลัพธ์ที่สมบูรณ์แบบถ้าฉันจะพูดอย่างนั้น ฉันสงสัยว่าพวกคุณกำลังมองหาการเพิ่มประสิทธิภาพนี้หรือไม่

คำตอบ 45:55 - เราจึงรอการแสดงผลเล็กน้อย แต่ถ้าคนใจร้อน ก็เป็นสัญญาณว่าคุณควรเร็วขึ้นอยู่ดี นั่นคือสิ่งที่ฉันจะตรวจสอบต่อไป แต่ฉันคิดว่าเมื่อดูจากภาพหน้าจอ อย่างเช่น สิ่งของทั้งหมดที่นั่นถูกบล็อกไว้ในกล่องสีเทา ดังนั้นมันจึงให้ความรู้สึกเหมือนเป็นปัญหาทางเทคนิคมากกว่าที่จะเป็นเพียงแค่การหมดเวลา

มาร์ติน สปลิตต์ : ครับ ฉันกำลังจะพูดว่า เราเห็นเนื้อหาไดนามิกมากมายที่ได้รับการจัดทำดัชนีโดยไม่มีปัญหา แม้ว่ามันจะใช้เช่น JavaScript และสิ่งของต่างๆ ดังนั้น หากเราหมดเวลา คุณอาจมีปัญหาในแง่ของระยะเวลาในการค้นหา และอาจสะท้อนให้เห็นในส่วนอื่นๆ ด้วยเช่นกัน เรารอสักครู่เพื่อให้เนื้อหาเสร็จสิ้น

คำถาม 46:48 - คุณ -- ขอกรอบเวลาหน่อยได้ไหม? รอเท่าไรครับ?

มาร์ติน สปลิตต์ : มันยากมากจริงๆ เพราะโดยพื้นฐานแล้ว ประเด็นก็คือ เหตุผลที่เราไม่สามารถให้กรอบเวลากับคุณได้ก็เพราะเวลา และนี่จะฟังดูแปลกจริงๆ และอดทนกับผมสักครู่ . เวลาในการแสดงผลของ Googlebots นั้นพิเศษและไม่จำเป็นต้องเป็นไปตามหลักการของ Einstein [หัวเราะ] ผมเลยพูดอะไรมากไม่ได้จริงๆ สิ่งที่ฉันสามารถพูดได้คือถ้าเครือข่ายไม่ว่างและเครือข่ายเป็นคอขวด เราอาจรอ แต่เรารอเพียงนานเท่านั้น ดังนั้นหากคุณใช้เวลาราวหนึ่งนาทีหรือ 30 วินาที แสดงว่าเราอาจหมดเวลาระหว่างนั้น แต่ไม่ยากหรอก ถ้าฉันบอกคุณ 10 วินาที มันอาจจะใช่หรือไม่ได้ผล ถ้าฉันบอกคุณ 30 วินาที มันอาจจะใช่หรือไม่ก็ได้ เลยไม่อยากพูดเป็นตัวเลข สิ่งที่ฉันจะพูดพยายามที่จะได้รับมันโดยเร็วที่สุดเท่าที่จะทำได้ และถ้าคุณไม่สามารถทำได้อย่างรวดเร็ว ให้ลองใช้บางอย่างเช่นการแคชผลการค้นหาเพื่อให้การค้นหามีมากขึ้นหรือน้อยลงหรือสร้างผลลัพธ์บนหน้าเว็บให้เกิดขึ้นทันทีมากขึ้นหรือน้อยลง หรือลองเรนเดอร์แบบไดนามิกที่ด้านข้างของคุณซึ่งอาจเป็นวิธีแก้ปัญหาสำหรับสิ่งนี้ สิ่งที่คุณสามารถลองได้คือคุณสามารถลองชอบวางไว้ที่ฝั่งเซิร์ฟเวอร์และพยายามสร้างเนื้อหาให้ได้มากที่สุดในรอบแรก นั่นคือสิ่งที่เป็นประโยชน์ต่อผู้ใช้ของคุณ โดยเฉพาะอย่างยิ่งหากพวกเขาอยู่ในเครือข่ายที่ช้า ใช่เลย ขออภัย ฉันไม่มีคำตอบง่ายๆ แต่เวลาใน Googlebot นั้นขี้ขลาด

คำตอบ 49:29 - ฉันคิดว่ามันอาจจะขึ้นอยู่กับสิ่งที่เว็บไซต์ทำจริงๆ สิ่งหนึ่งที่ยากกับความเร็วในการเรนเดอร์ก็คือ เราสามารถแคชของหลายอย่างที่ส่งจากเซิร์ฟเวอร์มากกว่าที่จะเป็นในเบราว์เซอร์ เพราะเราสามารถใช้ดัชนีของเราสำหรับสิ่งเหล่านี้ได้มากมาย ดังนั้นบางครั้งถ้า JavaScript ถูกแคชไว้ทางฝั่งเรา เราก็ไม่ต้องดึงมันออกมา หากคุณเปรียบเทียบเวลาอีกครั้ง เวลานั้นจะไม่ตรงกับที่ผู้ใช้เห็น จะไม่ตรงกับสิ่งที่คุณเห็นในหน้าเว็บtest.org มันจึงค่อนข้างยุ่งยาก และในส่วนที่เรารู้ว่าใช้เวลานานกว่านั้น เราจะอดทนมากขึ้นอีกนิด แต่มันทำให้ยากต่อการทดสอบ นั่นเป็นเหตุผลที่เรามีเครื่องมือทดสอบเหล่านี้ทั้งหมดที่แสดงข้อผิดพลาดให้ได้มากที่สุดเท่าที่จะเป็นไปได้ อย่างเช่น มันไม่ทำงานเลยใช่หรือไม่ บางครั้งมันใช้งานได้หรือไม่และบางครั้งปัญหาที่เกิดขึ้นอยู่ที่ไหน

คำถาม 50:29 - สำหรับเว็บไซต์ขนาดใหญ่มาก ลำดับของ URL ในแผนผังเว็บไซต์ XML มีความสำคัญหรือไม่

คำตอบ 50:34 - ไม่ เราไม่สน มันเป็นไฟล์ XML เราดึงข้อมูลทั้งหมด เราประมวลผลทั้งหมดพร้อมกัน

คำถาม 50:44 - แล้วพารามิเตอร์ลำดับความสำคัญในแผนผังเว็บไซต์ล่ะ

คำตอบ 50:47 - เราไม่ใช้มันเลย นั่นคือสิ่งที่ในตอนแรก เราคิดว่า โอ้ นี่อาจเป็นประโยชน์ในการหาว่าเราควรรวบรวมข้อมูลหน้าเว็บบ่อยแค่ไหน แต่กลายเป็นว่าถ้าคุณถามเว็บมาสเตอร์ พวกเขาแบบว่า ทุกอย่างมีความสำคัญ มันสำคัญที่สุด และในทำนองเดียวกัน ฉันคิดว่าการเปลี่ยนแปลงความถี่ในแผนผังเว็บไซต์ ซึ่งเรายังสังเกตเห็นว่า เช่น มีคนบอกเราว่าสิ่งต่างๆ เปลี่ยนแปลงอยู่ตลอดเวลา แต่อัปเดตล่าสุดเมื่อปีที่แล้ว ดังนั้นหากคุณมีความถี่ในการเปลี่ยนแปลงและวันที่ เราก็จะได้ข้อมูลนั้นจากวันที่อยู่ดี ดังนั้นเราจึงละเว้นความถี่การเปลี่ยนแปลง
คำถาม 51:35 - ควรเพิ่มสคีมาขององค์กรในหน้าแรก หน้าติดต่อ หรือทุกหน้าหรือไม่

คำตอบ 51:42 - เท่าที่ฉันรู้ มันเป็นแค่โฮมเพจ ฉันไม่รู้. ท่านใดทราบบ้างครับ?

คำตอบจาก Liz 51:4 7 - ปกติแล้วมันควรจะเป็นเพียงหน้าเดียวสำหรับองค์กรและองค์กร นั่นเป็นคำแนะนำโดยทั่วไป

MARTIN SPLITT 52:00 - ฉันเดาว่ามันไม่สำคัญหรอกว่าหน้าไหนไม่สำคัญเท่ากับว่าอย่าใส่มันในทุกหน้าที่คุณมี ฉันคิดว่าเป็นส่วนสำคัญมากกว่า ฉันคิดว่ามันขึ้นอยู่กับ -- หากคุณเป็นไซต์ข่าว มันอาจจะเหมาะสมที่จะใส่ไว้ในหน้าติดต่อ หน้าเกี่ยวกับ หรืออะไรก็ตาม ในขณะที่ในเว็บไซต์ของร้านค้าหรือร้านอาหาร การวางบนหน้าแรกอาจเป็นเรื่องปกติ

JOHN 52:20 - ฉันคิดว่าในกรณีนี้ มันไม่สำคัญสำหรับเราเท่าเพราะเราต้องสามารถหามันได้จากที่ไหนสักแห่งเช่นโฮมเพจหรือหน้าการติดต่อ แต่ถ้าเรามีมันที่อื่นก็ไม่เปลี่ยนแปลงอะไรสำหรับเรา ดังนั้นสิ่งสำคัญที่ไม่ควรเปรียบเทียบก็คือมาร์กอัปบทวิจารณ์ที่บางครั้งเราเห็นผู้คนใส่คำวิจารณ์ของบริษัทในทุกหน้าของเว็บไซต์ด้วยความหวังว่าจะได้ดาวและผลการค้นหาสำหรับทุกหน้าในเว็บไซต์ของตน และนั่นจะเป็นสิ่งที่ไม่ดีสำหรับเรา แต่ข้อมูลติดต่อ ถ้าคุณมาร์กอัปไว้ แสดงว่าฉันไม่พบปัญหา
คำถามที่ 53:05 -การทดสอบความเร็วเว็บไซต์ Google ที่เราใช้ได้รับการบันทึกช้ามาก เวลาในการโหลดหน้าเว็บ แต่การทดสอบอิสระที่เราทำกับเพื่อนร่วมงานในต่างประเทศแสดงเวลาในการโหลดหน้าเว็บที่เร็วมาก การบันทึกที่ผิดพลาดนี้ มาตรการของ Google ส่งผลต่อการจัดอันดับไซต์ในอัลกอริทึมของ Google หรือไม่

Marie Haynes: ไม่ใช่คำถามของฉัน แต่เพื่อให้บริบท ข้อมูล Lighthouse ใหม่สำหรับความเร็วหน้าเว็บนั้นรุนแรงกว่า Page Speed ​​Insights ที่เคยเป็นมา ดังนั้นบางอย่างที่มีคะแนนเท่ากับ 80 ใน Page Speed ​​Insights อาจเป็นสีแดง 29 คะแนนใน Lighthouse นั่นเป็นคำถามที่ดี มีแนวโน้มว่าจะเป็นสาเหตุหรือไม่ เพราะเรารู้ว่าในอุปกรณ์เคลื่อนที่ ไซต์ที่ช้ามากอาจถูกลดระดับลงได้ จะดีไหมถ้าเราจะพูดว่า ถ้าคุณอยู่ในการทดสอบ Lighthouse ว่าเราควรจะปรับปรุงสิ่งต่างๆ ให้ดีขึ้นจริง ๆ เพราะมันอาจทำให้เกิดการลดระดับ หรือมีข้อยุติหรือไม่

คำตอบ 54:07 - ดังนั้นเราจึงไม่มีการทำแผนที่แบบตัวต่อตัวของเครื่องมือภายนอกและทั้งหมดที่เราใช้สำหรับโซเชียล ใช่ นั่นทำให้พูดยากจริงๆ แต่ในการค้นหา เราพยายามใช้ข้อมูลจริงผสมกัน มันคืออะไร ข้อมูลการทดสอบในห้องปฏิบัติการ ซึ่งคล้ายกับการทดสอบ Lighthouse และข้อมูลรายงาน Chrome UX โดยพื้นฐานแล้วคืออะไร เรากำลังวัดสิ่งที่ผู้ใช้เว็บไซต์จะได้เห็น

มาร์ติน สปลิต 55:37 - สิ่งสำคัญเช่นกันที่จะต้องเห็นว่า Lighthouse นั้น วัดกันโดยเฉพาะสำหรับการเชื่อมต่อ 3G ที่ค่ามัธยฐาน หรือเช่นโทรศัพท์ประสิทธิภาพปานกลาง ใช่ โดยพื้นฐานแล้ว หากคุณใช้ Apple McIntosh รุ่นล่าสุดหรือคอมพิวเตอร์ Windows ที่เร็วล่าสุดที่มีการเชื่อมต่อแบบมีสายที่ดีจริงๆ หรือการเชื่อมต่อ Wi-Fi ที่ดีจริงๆ ในสำนักงานของคุณ แน่นอนว่าคุณจะเห็นเวลาโหลดเป็นสองวินาที แต่ ผู้ใช้จริงที่มีโทรศัพท์อยู่ในป่าอาจไม่เห็นสิ่งนั้น ดังนั้นมันจึงเป็นหนึ่งในกรณีเหล่านี้ที่ไม่ทำให้เว็บไซต์ของคุณเร็วขึ้น แต่นี่เป็นเรื่องยากจริงๆ ที่จะพูดว่าจะมีลักษณะเป็นอย่างไรจากมุมมองของคนวงใน เนื่องจากเราใช้เมตริกที่เจาะจงมากซึ่งไม่จำเป็นต้องจับคู่กับ สิ่งหนึ่งที่เครื่องมือกำลังเปิดเผย....แน่นอนว่าการแก้ไขเป็นสิ่งสำคัญ เพราะคุณไม่ต้องการให้ผู้ใช้ของคุณรอเว็บไซต์ของคุณตลอดไป ที่จะทำร้ายคุณ ที่จะทำร้ายผู้ใช้ของคุณ ที่จะทำร้ายคุณในการค้นหา แต่ฉันไม่จ่าย -- ฉันจะบอกว่าแค่ดูที่เครื่องมือ หากเครื่องมือกำลังบอกคุณว่าคุณทำได้ดี คุณก็ไม่ควรกังวลกับมันมากเกินไป ถ้าเครื่องมือกำลังบอกคุณว่าคุณทำได้ไม่ดีจริงๆ ฉันคิดว่าเวลาที่ใช้ไปกับการหาเหตุผลว่าทำไมมันถึงบอกว่า อย่างเช่น ถ้ามันเกี่ยวข้องกัน มันก็สูญเปล่า คุณควรดูที่การทำให้ไซต์เร็วขึ้น

ประสิทธิภาพมือถือเป็นปัจจัยที่สำคัญมากสำหรับผู้ใช้ของคุณ เช่นเดียวกับทุกสิ่งทุกอย่าง ดังนั้นผมจะบอกว่าต้องแน่ใจว่าเว็บไซต์ของคุณทำงานได้ดีในสภาพการใช้งานจริง บางทีอาจจะซื้อโทรศัพท์ราคาถูกและลองใช้เว็บไซต์เป็นระยะๆ และถ้า- นั่นคือสิ่งที่ฉันชอบทำ และฉันเคยทำมาก่อนจะเข้าร่วม Google กับทีมพัฒนาที่ฉันทำงานด้วย ฉันชอบดู คุณต้องการใช้เว็บไซต์นี้บนโทรศัพท์เครื่องนี้หรือไม่ มันแบบว่า โอ้ นี่มันน่ากลัว ฉันก็แบบ อืม ใช่ บางทีเราควรทำอะไรกับมันบ้าง

JOHN - ใน Chrome คุณสามารถตั้งค่าและลองใช้ความเร็วการเชื่อมต่อที่แตกต่างกันได้ โปรแกรมจำลองมือถือ ฉันคิดว่านั่นเป็นสิ่งที่ดีจริงๆ ในการดู และดูฐานผู้ใช้ของคุณด้วย ดูข้อมูลการวิเคราะห์ของคุณหากคุณเห็นว่าผู้คนกำลังใช้เว็บไซต์ของคุณกับ iPhone ระดับไฮเอนด์เท่านั้น บางทีอาจไม่ใช่ปัญหาน้อยกว่าถ้าคุณเห็นว่าผู้คนกำลังเชื่อมต่อกับไซต์ของคุณจากการเชื่อมต่อแบบสุ่มในชนบท ซึ่งก็คือ ช้าและพวกเขามีอุปกรณ์ระดับล่าง บางทีอาจจะมากกว่านั้น