8 มีนาคม 2019 – Google Help Hangout Notes

สัปดาห์นี้ John ตอบคำถามดีๆ เกี่ยวกับ Page Speed, Anchor Text, Java Script เช่นเคย วิดีโอฉบับเต็มและการถอดเสียงอยู่ด้านล่าง!

เนื้อหาที่แปลได้รับการปฏิบัติอย่างไร?

0:33

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

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

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

3:10

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

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

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

9:16

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

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

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

18:00 น.

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

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

ความเร็วมีความสำคัญสำหรับไซต์เวอร์ชันมือถือของคุณหรือไม่?

21.00 น.

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

สรุป : ความเร็วเป็นเพียงหนึ่งในปัจจัยการจัดอันดับที่ Google ใช้ การที่เว็บไซต์ยอดนิยมอาจไม่เร็วไม่ได้หมายความว่าไม่สำคัญสำหรับเว็บไซต์ของคุณ

Google ควรใช้มาร์กอัปสคีมาประเภทใด เราควรใช้ JSON หรือ micro-data, micr-formats อันไหนดีกว่ากัน?

22:30 น.

ขณะนี้เราชอบมาร์กอัป JSON-LD ฉันคิดว่าข้อมูลที่มีโครงสร้างประเภทใหม่ส่วนใหญ่ออกมาสำหรับ JSON-LD ก่อน นั่นคือสิ่งที่เราต้องการ

สรุป: Google ต้องการ JSON-LD

Anchor Text สำคัญแค่ไหน?

25:10

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

สรุป: Anchor Text มีความสำคัญมาก เนื่องจากจะให้บริบทแก่ Google เกี่ยวกับเนื้อหาของหน้าเว็บ Anchor text เช่น "คลิกที่นี่เพื่อดูข้อมูลเพิ่มเติม" ไม่ได้ให้ข้อมูลแก่ Google มากนัก แต่ Anchor Text เช่น "คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับหน้าผลิตภัณฑ์นี้" บอก Google ว่าหน้านี้เกี่ยวกับหน้าผลิตภัณฑ์นี้

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

Google มองเห็นหน้าเว็บของคุณอย่างไร

39:00

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

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

คุณสามารถสลับ URL ด้วย Javascript ได้หรือไม่?

43:00 น.

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

สรุป : Google สามารถรับได้หากมีการเปลี่ยน URL หลังจากโหลดหน้าแล้ว สิ่งเดียวที่ต้องระวังคือต้องแน่ใจว่าไม่มีการเปลี่ยน URL เมื่อผู้ใช้ดำเนินการบางอย่าง

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

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

คำถาม 0:33 - คำถามเกี่ยวกับการแปล ฉันรู้ว่าถ้าฉันแปลเนื้อหาภาษาอังกฤษเป็นภาษารัสเซียหรือยูเครน และคนส่วนใหญ่ใช้เฉพาะการแปลของ Google และเพียงแค่ใส่เนื้อหาลงไป แต่เหมือนว่า 90% ต้องการการแก้ไขหากคุณอ่านในฐานะเจ้าของภาษา ฉันสนใจสองประเด็น ถ้าฉันต้องการทำเวอร์ชันอื่นหรือภาษาอื่นในเว็บไซต์ของฉัน เช่น อังกฤษ รัสเซีย หรือยูเครน โอเคไหม ประการที่สอง ฉันพบบทความที่น่าสนใจเกี่ยวกับเฉพาะของฉันและฉันต้องการแปลมัน ดีหรือไม่? ฉันจำเป็นต้องปรับตัวให้เข้ากับผู้อ่านในประเทศหรือไม่?

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

คำถามที่ 3:10 - Google รวบรวมข้อมูลและจัดทำดัชนีเนื้อหาในสองขั้นตอน อย่างแรกคือการแสดงผลฝั่งเซิร์ฟเวอร์ และอันดับที่สองคือการแสดงผลฝั่งไคลเอ็นต์ ตามข้อความก่อนหน้านี้ อาจใช้เวลาหลายวันหรือหลายสัปดาห์กว่าที่กระบวนการนี้จะเสร็จสมบูรณ์ สำหรับไซต์ที่ใช้ Javascript อาจประสบปัญหาร้ายแรงหากการจัดทำดัชนีเป็นช่วงเวลาที่สำคัญ ฉันจะบอกได้อย่างไรว่าจะใช้เวลานานแค่ไหน?

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

คำถามที่ 6:17 - และตอนนี้เรามีคำถามยาวมากเกี่ยวกับการทำความเข้าใจประเภทการตั้งค่าสถานะในคอนโซลการค้นหา เนื่องจากเมื่อเราตั้งค่าสถานะบางอย่างว่า 'Google ซ้ำกันเลือกรูปแบบบัญญัติที่แตกต่างจากผู้ใช้" หรือ "URL ที่ส่งซ้ำกันและไม่ได้เลือกเป็นปัญหาตามรูปแบบบัญญัติ .

[ผู้ใช้ Chimes ใน] มันเป็นหน้า Javascript มีการแสดงผลล่วงหน้า เนื้อหาทั้งหมดอยู่ใน HTML แบบคงที่ แต่ Google ยังคงพยายามเรียกใช้หน้าเว็บ และเรากำลังพบว่าในสภาพแวดล้อมอีคอมเมิร์ซนี้ว่าหน้าผลิตภัณฑ์ที่ไม่ซ้ำกันเหล่านี้ที่มีคำอธิบายที่ไม่ซ้ำกันและเนื้อหาที่มีความหมายถูกตั้งค่าสถานะเป็น Google เป็นเนื้อหาที่ซ้ำกัน เราคิดว่านี่เป็นความล้มเหลวในการแสดง JavaScript บางประเภท โดยที่ Googlebot ยังคงเห็นหน้าแสดงข้อผิดพลาดเดิมหรืออะไรทำนองนั้นอยู่เรื่อยๆ จึงคิดว่าเป็นการแสดงซ้ำ - เราจะเข้าใจได้อย่างไรว่าบริการแสดงผลเว็บจบลงด้วยสิ่งนั้น อาจทำให้เนื้อหาดูซ้ำกับ Google bot

คำตอบ 7:43 - ฉันจะต้องดูตัวอย่างจริง ๆ ดังนั้นหากคุณสามารถส่งตัวอย่างมาให้ฉันได้จะมีประโยชน์มาก

คำถาม 8:00 - Google ทราบถึงปัญหาที่กำลังดำเนินอยู่หรือไม่

คำตอบ 8:00 - ไม่... ฉันเคยได้ยินจากบางไซต์ที่บ่นเกี่ยวกับเรื่องนี้มากกว่าที่อื่นๆ ดังนั้นหากคุณส่งตัวอย่างมาบ้างก็จะเป็นประโยชน์

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

คำตอบ 8:41 - ไม่ใช่ตอนนี้ นั่นเป็นสิ่งที่สมเหตุสมผลมากที่จะมี สำหรับไซต์ส่วนใหญ่นั้นไม่สำคัญ แต่กรณีแบบนี้ก็น่าใช้นะครับ

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

คำตอบ 10:04 - ฉันคิดว่าคุณกำลังพูดถึงทรัพยากรแบบฝังตัวที่ถูกดึงมาเพื่อการทดสอบโดยเฉพาะใช่ไหม เช่นเดียวกับไฟล์ JS CSS การตอบสนองที่แตกต่างกันแบบนั้น? ฉันคิดว่ามีแง่มุมหนึ่งที่ค่อนข้างซับซ้อนในขณะนี้ ในแง่ที่ว่าเรามีลำดับความสำคัญที่แตกต่างกันสำหรับการทดสอบความเหมาะกับอุปกรณ์เคลื่อนที่เมื่อเทียบกับบอทของ Google ทั่วไป เราพยายามดึงทรัพยากรอย่างรวดเร็วที่สุดจากเซิร์ฟเวอร์ที่ใช้งานจริง และในระหว่างการสร้างดัชนี เราจะแคชทรัพยากรจำนวนมากและเพียงแค่ใช้เวอร์ชันแคชของหน้า ดังนั้นสิ่งที่คุณอาจเห็นในการทดสอบความเหมาะกับอุปกรณ์พกพาก็คือเราพยายามแสดงหน้านี้โดยเร็วที่สุด และเราสามารถรับทรัพยากรเหล่านี้ได้มากมาย แต่สำหรับบางคน เราจะหมดเวลากับความสามารถในการดึงข้อมูลนี้ เซิฟเวอร์. นั่นคือข้อผิดพลาดส่วนใหญ่ที่คุณเห็นในการทดสอบความเป็นมิตรกับมือถือ ฉันยังเชื่อด้วยว่าในเครื่องมือตรวจสอบ URL หากคุณใช้การทดสอบแบบสด เรากำลังพยายามดึงทุกอย่างที่ใช้งานได้จริง และบางครั้งสิ่งนี้ก็ไม่สามารถทำได้จริง และสำหรับการจัดทำดัชนี เรามีเวลาอีกมาก นานขึ้นอีกเล็กน้อยที่เราสามารถทำได้ ดังนั้นหากเราเห็นว่าทรัพยากรเหล่านี้มีความจำเป็น เราจะดึงมันออกมา เราจะแคชมัน และเราจะพยายามให้มันพร้อมใช้งานเมื่อเราพยายามทำการเรนเดอร์ นั่นคือสิ่งที่เราไม่จำเป็นต้องทำ iot live ดังนั้นหากใช้เวลานานกว่านี้อีกนิด เราจะอดทนรอและรอให้ทุกอย่างมารวมกัน ยังมีบางแง่มุมของเวลาที่มีอยู่ซึ่งทรัพยากรเหล่านี้ทั้งหมดนั้นเราไม่สามารถแคชได้ (เช่น ID เซสชันและ JS URLS ทั้งหมด) ซึ่งทำให้เราสามารถเก็บเวอร์ชันแคชไว้ได้จริง ๆ และ นำกลับมาใช้ใหม่ในภายหลัง นั่นคือสิ่งที่เราอาจ ไม่รู้ว่าด้วยเหตุผลใดก็ตาม ไม่สามารถดึงข้อมูลเพื่อสร้างดัชนีได้ กล่าวโดยสรุป ฉันคิดว่าการวินิจฉัยปัญหาเช่นนี้เป็นเรื่องยาก โดยเฉพาะอย่างยิ่งหากคุณมีทรัพยากรที่ฝังอยู่จำนวนมาก แนวทางปฏิบัติที่ฉันได้รับจากทีมวิศวกรโดยทั่วไปคือ เราควรบอกให้ผู้คนมีทรัพยากรที่ฝังตัวน้อยลง และพวกเขามักจะไม่พบปัญหานี้ นั่นไม่ใช่เรื่องง่ายเสมอไป ดังนั้น แต่โดยทั่วไปแล้ว สิ่งที่ฉันจะทำคือทำการทดสอบความเป็นมิตรกับอุปกรณ์เคลื่อนที่เป็นแนวทางคร่าวๆ ดังนั้นหากใช้งานได้ใน MTF คุณจะปลอดภัยอย่างแน่นอน หากคุณเห็นสิ่งอื่น ๆ หมดเวลาพร้อมกับข้อผิดพลาดอื่นนี้ ส่วนใหญ่แล้ว เรายังคงสามารถใช้สิ่งนั้นเพื่อสร้างดัชนีได้

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

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

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

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

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

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

คำถาม 20:36 ฟังก์ชันมาร์กอัปมาร์กอัปของ Search Console ใหม่ยังคงเหมือนเดิมกับฟังก์ชันเก่าหรือไม่

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

คำถาม 21:00 แล้วความเร็วสำหรับเวอร์ชันมือถือนั้นสำคัญไฉนที่ต้องมีความเร็วในโซนสีเขียว และถ้าใช่ ทำไมเว็บไซต์ชั้นนำจำนวนมากถึงยังช้าอยู่อย่างนั้น

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

คำถาม 22:30 มาร์กอัปสคีมาประเภทใดที่เหมาะสำหรับ Google เราควรใช้ JSON หรือ micro-data รูปแบบ micr อันไหนดีกว่ากัน?

คำตอบ 22:48 ขณะนี้เราชอบมาร์กอัป JSON-LD ฉันคิดว่าข้อมูลที่มีโครงสร้างประเภทใหม่ส่วนใหญ่ออกมาสำหรับ JSON-LD ก่อน นั่นคือสิ่งที่เราต้องการ

คำถาม 23:00 Google ได้ทำการอัพเดทครั้งใหญ่ในเดือนกุมภาพันธ์หรือมีนาคมหรือไม่?

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

คำถาม 23:24 เนื้อหาแบบบางมีความหมายอย่างไรสำหรับเว็บไซต์ในเครือ

คำตอบ 23:34 เนื้อหาแบบบางไม่ได้มีความหมายอะไรสำหรับไซต์ในเครือเมื่อเทียบกับเว็บไซต์อื่น สิ่งที่เราได้เห็น โดยเฉพาะกับเว็บไซต์ในเครือ มีแนวโน้มว่าจะใช้เนื้อหาจากฟีดเพราะทำได้ง่ายมาก คุณสามารถให้ scripts hat ช่วยคุณได้อย่างรวดเร็ว ทำได้ง่ายมาก คุณไม่ต้องทำงานมากสองอย่าง มันสร้าง URL จำนวนมาก แต่แน่นอนว่าสำหรับผู้ใช้และสำหรับเรา มันไม่ได้น่าสนใจขนาดนั้นเพราะคุณมอบสิ่งเดียวกันกับที่คนอื่นๆ มีอยู่แล้ว

คำถามที่ 24:40 เนื้อหาที่ซ่อนอยู่ในแท็บมีปัญหาในการจัดทำดัชนีหรือไม่

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

คำถามที่ 25:10 Anchor text ยังคงเป็นปัจจัยสำคัญในปี 2019 หรือไม่? บริษัทจำนวนมากได้ทำการศึกษาว่าพวกเขาชี้ให้เห็นว่าไม่มีความสัมพันธ์กัน แล้วก็มีลิงค์ไปยังสิทธิบัตรของ Google

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

คำถาม 27:00 ช่วยบอกเราหน่อยได้ไหมว่ากระบวนการ DMCA ทำงานอย่างไร

คำตอบ 27:01 ฉันไม่สามารถบอกคุณได้ว่ามันทำงานอย่างไรเพราะฉันไม่รู้รายละเอียดเกี่ยวกับเรื่องนั้นและเป็นกระบวนการทางกฎหมายด้วย และฉันไม่สามารถให้คำแนะนำทางกฎหมายแก่คุณได้

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

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

คำถาม 48:50 - เราขายต่อโรงแรมในกรีซผ่านเว็บไซต์ของเรา เราได้พัฒนาส่วนที่ดีสำหรับโรงแรม อย่างไรก็ตาม เรายังทำซ้ำเนื้อหาและชื่อของโรงแรมเหล่านั้นเมื่อเราฝังวิดีโอ YouTube ของโรงแรมเหล่านั้น เป็นอันตรายต่อเราหรือไม่?

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

คำถาม 50:00 - หากเรื่องราวถูกเปลี่ยนเส้นทางเนื่องจากเป็นเนื้อหาบางและมีอายุหลายปี ผลกระทบด้านลบของบทความจะถูกส่งต่อด้วยการเปลี่ยนเส้นทางหรือไม่

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

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

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

คำถาม 1:01:01- เป็นความคิดที่ดีหรือไม่ที่จะเพิ่ม nofollow ลงในลิงก์วิกิพีเดียและบทความช่วยเหลือของ Google เช่นลิงก์ภายนอกอื่นๆ และเครื่องมือเน้นข้อมูลที่ดีใช้เวลาเท่าใดจึงจะมีผลในการค้นหา

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

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

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