SEO Office Hours – ตุลาคม 8, 2021
เผยแพร่แล้ว: 2021-10-15นี่คือบทสรุปของคำถามและคำตอบที่น่าสนใจที่สุดจาก Google SEO Office Hours กับ John Mueller เมื่อวันที่ 8 ตุลาคม 2021
จำนวนหน้าที่จัดทำดัชนีเทียบกับผู้มีอำนาจของไซต์
03:52 “ดังนั้น คุณได้แนะนำหลายครั้งในอดีตว่าไซต์ขนาดใหญ่ […] เน้นที่ชุดหน้าเล็ก […] ไซต์ที่ฉันกำลังดำเนินการอยู่ เรามี […] ประมาณ 1,000 หน้าที่ไม่ได้รับการเข้าชม ที่เก่า ดังนั้นฉันจึงแนะนำให้ลบออก แต่มีคำถามหนึ่งที่ทีมนักพัฒนาซอฟต์แวร์ของเรารู้สึกว่ายิ่งมีหน้าเว็บที่ Google จัดทำดัชนีของไซต์ของคุณมากเท่าไร ก็ยิ่งมีอำนาจเหนือกว่าในการอ้างอิงถึงไซต์ และไม่เต็มใจที่จะลบหน้าใดๆ ออก คุณช่วยทำให้กระจ่างเกี่ยวกับสิ่งนั้นได้ไหม”
ตามที่จอห์นกล่าวว่า “ไม่ใช่กรณีที่ถ้าคุณมีการจัดทำดัชนีหน้าเว็บมากกว่าที่เราคิดว่าเว็บไซต์ของคุณจะดีกว่า […] บางครั้งการจัดทำดัชนีหน้าเว็บจำนวนมากก็สมเหตุสมผล บางครั้ง หน้าเหล่านี้เป็นหน้าที่มีประโยชน์ในการจัดทำดัชนีแบบนั้น แต่ไม่ใช่สัญญาณของคุณภาพเกี่ยวกับจำนวนหน้าที่จัดทำดัชนี และโดยเฉพาะอย่างยิ่ง หากคุณกำลังพูดถึง […] 1,000, 2,000, 5,000 หน้า นั่นเป็นตัวเลขที่ค่อนข้างต่ำสำหรับระบบของเราโดยทั่วไป และไม่ใช่ว่าเราจะพูดว่า 5,000 หน้าดีกว่า 1,000 หน้า สำหรับเรา มันเป็นเว็บไซต์ขนาดเล็ก และเราทำสิ่งที่เราสามารถดึงออกมาได้ และแน่นอนว่าเว็บไซต์ขนาดเล็กนั้นสัมพันธ์กัน ไม่เหมือนบอกว่าเป็นเว็บไซต์ที่ไม่เกี่ยวข้อง มันอาจจะเล็ก แต่ก็ยังมีประโยชน์มาก […]”
การประเมินวัตถุประสงค์หลักของเว็บไซต์
10:03 “ครั้งสุดท้ายที่เราพูดถึงปัญหาบางอย่างกับเว็บไซต์ […] – เป็นเว็บไซต์อีคอมเมิร์ซที่เรามีข้อมูลและธุรกรรม […] คำแนะนำของคุณคือแยกเนื้อหานี้ออกเล็กน้อยในหน้าธุรกรรมและหน้าข้อมูล ดังนั้นฉันจึงมีคำถามอื่นเกี่ยวกับเรื่องนี้ ถ้าคุณมี สมมติว่าเป็นเว็บไซต์อีคอมเมิร์ซ และคุณมีบล็อกขนาดใหญ่ นิตยสาร หรืออะไรทำนองนั้นที่คุณมีข้อมูลมากมาย แต่เป็นส่วนเก่า ในทางกลับกัน คุณมีหน้าผลิตภัณฑ์และหมวดหมู่ทั้งหมดเหล่านี้ และอื่นๆ ดังนั้นบล็อกขนาดใหญ่นี้ที่มีข้อมูลที่บริสุทธิ์จะทำให้ทั้งเว็บไซต์มีข้อมูลหรือตัวอักษรเพื่อให้ Google กล่าวว่าโอ้เราไม่แน่ใจว่านี่เป็นสิ่งที่ […] สิ่งที่ผู้คนสามารถรับข้อมูลแทนที่จะซื้อสิ่งของหรือเป็น การประเมินนี้ทำบนฐานต่อหน้า?”
จอห์นกล่าวว่า: “ […] ความเข้าใจของฉันคือสิ่งนี้เป็นเรื่องระดับหน้ามากกว่า […] เว็บไซต์จำนวนมากมีเนื้อหาหลายประเภทผสมกัน จากนั้นคุณพยายามหาว่าหน้าใดตรงกับเจตนาของผู้ค้นหาและพยายามจัดอันดับให้เหมาะสม […]
ฉันหมายความว่าคุณเห็นสิ่งนั้นกับเว็บไซต์ข่าวบ่อยครั้ง […] พวกเขามีเหตุการณ์ล่าสุด แต่พวกเขายังมีส่วนสำหรับเหตุการณ์ที่เก่ากว่าที่เกิดขึ้นหรือ […] สำหรับกิจกรรมใหญ่อื่น ๆ พวกเขามีส่วนเก็บถาวรแยกต่างหาก และนั่นเป็นความตั้งใจที่แตกต่างกันมาก ถ้าคุณต้องการบางสิ่งที่กำลังเกิดขึ้นจริงๆ หรือถ้าคุณต้องการการวิจัยข้อมูลประเภทใดประเภทหนึ่ง เนื้อหาประเภทที่ไม่มีวันเสื่อมคลาย
[…] เราต้องดูมันแบบต่อหน้า และอย่าพูดว่านี่คือเว็บไซต์การวิจัยเพราะมีเนื้อหาการวิจัยอยู่ที่นี่”
การเปลี่ยนเส้นทางของลิงก์
13:21 “เรากำลังเห็นว่าผู้คนกำลังเชื่อมโยงไปยัง […] สมมติว่าหมวดหมู่ย่อยของเพจ และปัญหาคือ […] เนื้อหาของเรามีมาและไป ซึ่งหมายความว่าบางครั้งมีเนื้อหาปรากฏขึ้นในบางหมวดหมู่มากขึ้น บางครั้ง เนื้อหาถูกลบ ดังนั้นหมวดหมู่ย่อยจึงสามารถสร้างและหายไปได้เช่นกัน และเราเห็นผู้อ้างอิงจำนวนมากจากลิงก์ย้อนกลับเนื่องจากลิงก์ไปยังหมวดหมู่ย่อยที่ไม่มีอยู่อีกต่อไป คำถามของฉันที่นี่คือ: ตกลงไหมที่จะเปลี่ยนเส้นทาง […] ลิงก์เหล่านี้ไปยังหมวดหมู่หลัก และถ้าเราทำเช่นนั้น เราจะทำอย่างนั้นได้อย่างไร - กับ 302 เป็นต้น? เช่นเดียวกับการเปลี่ยนเส้นทางชั่วคราว เพราะในอนาคต หมวดหมู่ย่อยนี้อาจเต็มไปด้วยเนื้อหาอีกครั้ง […] ไม่ใช่การเปลี่ยนเส้นทางแบบถาวร”
John ตอบว่า: “ดังนั้น หากเราเห็นว่าสิ่งนี้เกิดขึ้นในระดับที่ใหญ่กว่าที่คุณเปลี่ยนเส้นทางไปยังระดับหลัก เราอาจเห็นว่าเป็น soft 404 […] และแทนที่จะเป็นรหัส 404 คุณกำลังเปลี่ยนเส้นทาง และบางทีนั่นอาจเป็น ดีกว่าสำหรับผู้ใช้ แต่เราเห็นว่ามันเป็น 404 […] ถ้ามันสมเหตุสมผลจากมุมมองของผู้ใช้ในการเปลี่ยนเส้นทางฉันก็จะทำ
[…] ในส่วนที่เกี่ยวกับ 301 หรือ 302 ฉันไม่คิดว่ามันสำคัญตรงไหน เพราะเราจะ มองว่านี่เป็น soft 404 หรือเราจะมองว่ามันเป็นคำถามเกี่ยวกับการกำหนดมาตรฐาน หากเป็น soft 404 รหัสก็ไม่สำคัญ หากเป็นคำถาม Canonicalization แสดงว่า URL ใดที่เราแสดงในผลการค้นหา และโดยปกติ ระดับที่สูงกว่าจะมีสัญญาณที่แรงกว่าอยู่ดี และเราจะเน้นที่ระดับที่สูงกว่า ดังนั้นไม่สำคัญว่าจะเป็น 301 หรือ 302 ในกรณีนั้น
[…] ถ้าเราเห็นว่าเป็น soft 404, […] เราจะชะลอการรวบรวมข้อมูลของ URL นั้น ๆ เนื่องจากไม่มีสิ่งใดที่นี่ […] ถ้าเราเห็นว่าเป็นการเปลี่ยนเส้นทาง […] เราไม่จำเป็นต้องรวบรวมข้อมูลนี้ทุกวัน เพราะเราเน้นที่ URL หลัก ดังนั้น ฉันคิดว่าในทั้งสองกรณี เราจะชะลอการรวบรวมข้อมูลของ URL นั้นจนกว่าเราจะได้สัญญาณใหม่ที่บอกเราว่า นี่อาจเป็นสิ่งใหม่อีกครั้ง […] นั่นจะเป็นเหมือนการลิงก์ภายในหรือไฟล์แผนผังเว็บไซต์ […] และนั่นจะเป็นสัญญาณที่แข็งแกร่งกว่าที่เราจะคลานอีกครั้ง แต่ฉันคิดว่าการรวบรวมข้อมูลช้าลงจะคล้ายกันในทุกกรณี
[…] ฉันคิดว่า [อัปเดต] แผนผังเว็บไซต์เพียงอย่างเดียวอาจไม่เพียงพอ ฉันจะทำให้แน่ใจว่าการเชื่อมโยงภายในนั้นชัดเจน ”
การกู้คืนจากการอัพเดทหลัก
18:34 “ประมาณหนึ่งปีที่แล้ว เราเห็นปริมาณการใช้ข้อมูลลดลงอย่างมีนัยสำคัญ หลังจากการตรวจสอบ […] สัญญาณทั้งหมดชี้ไปที่ไซต์ที่มีปัญหาด้านคุณภาพของไซต์ เราสามารถแก้ไขปัญหาเหล่านั้นได้ภายในเดือนกุมภาพันธ์ปีนี้ และในการอัปเดตหลักของเดือนมิถุนายน เราเห็นการเพิ่มขึ้นบางอย่าง แต่ก็ยังไม่ถึงระดับที่เราเคยเป็นมาก่อนลดลงเมื่อประมาณปีที่แล้ว ดังนั้น คำถามของฉันคือปัญหาคุณภาพของไซต์ หากเป็นกรณีนี้ นี่คือการกู้คืนที่เราคาดหวังได้ หรือเราสามารถคาดหวังการกู้คืนได้มากขึ้นหากเราคิดว่าเราได้จัดการปัญหาทั้งหมดที่ระบุ […]
จอห์นกล่าวว่า: “ […] ไม่มากที่เราจะถือว่ามันเป็นสถานการณ์ที่คุณต้องแก้ไขบางสิ่งบางอย่าง แต่ […] หากคุณพยายามปรับปรุงความเกี่ยวข้องของเว็บไซต์ของคุณ […] คุณมีเว็บไซต์ที่ดีกว่า ดังนั้นไม่ใช่ว่า […] เราจะเปลี่ยนกลับเป็นสถานะก่อนหน้า […] มันไม่เหมือนเดิมหรือเทียบได้กับเมื่อก่อน ดังนั้นจึงเป็นเรื่องยากที่จะคาดหวังว่ามันจะเปลี่ยนไปเป็นเมื่อก่อน […]
[…] ด้วยการอัปเดตหลัก เราไม่ได้มุ่งเน้นเฉพาะประเด็นส่วนบุคคลมากนัก แต่ให้ความสำคัญกับความเกี่ยวข้องของเว็บไซต์โดย รวม และอาจรวมถึงสิ่งต่างๆ เช่น ความสามารถในการใช้งาน และโฆษณาบนหน้าเว็บ แต่โดยพื้นฐานแล้วก็คือเว็บไซต์โดยรวม และโดยปกติแล้ว นั่นหมายถึงจุดเน้นของเนื้อหา วิธีที่คุณนำเสนอ วิธีที่คุณทำให้ผู้ใช้เข้าใจอย่างชัดเจนถึงสิ่งที่อยู่เบื้องหลังเนื้อหา เช่น แหล่งที่มาคืออะไร […] หากคุณต้องการให้ Google เห็นว่าเว็บไซต์ของคุณเป็นสิ่งที่ดีกว่าอย่างมาก คุณอาจต้องทำงานด้านเนื้อหา ด้วย
[…] ลองนึกถึงที่ที่จะมีเนื้อหาคุณภาพต่ำซึ่งผู้ใช้อาจสับสนเมื่อไปที่เว็บไซต์ของฉัน และความสับสนนั้นเป็นสิ่งที่เราสามารถจัดการกับปัญหาทางเทคนิคด้วยการเปลี่ยนแปลง UX หรือไม่ หรือเราต้องเปลี่ยนเนื้อหาที่เรานำเสนอจริง ๆ ?”
ลิงก์ในโพสต์ของแขก
28:24 “[…] หาก [เว็บไซต์มี] โพสต์ของแขกและ Google ไม่ทราบว่าได้รับการชำระเงินหรือไม่ Google จะตรวจสอบได้อย่างไรว่า [พวกเขาควร] นำลิงก์นี้หรือเบิร์นลิงก์นี้ คำตอบคืออะไรเพื่อให้เราปลอดภัยจากทุกมุม”
ตามที่จอห์นกล่าวว่า “ […] คำแนะนำของเราสำหรับลิงก์และโพสต์ของแขกคือไม่ควรปฏิบัติ ตาม […] ฉันจะระวังจริงๆ เพื่อให้แน่ใจว่าลิงก์นั้นไม่มีการติดตาม เพื่อที่คุณกำลังกระตุ้นการรับรู้ คุณกำลังพูดถึงสิ่งที่คุณทำ คุณกำลังสร้างมันขึ้นมาเพื่อให้ผู้ใช้สามารถไปที่ หน้าหนังสือ. แต่โดยพื้นฐานแล้ว มันคือโฆษณาสำหรับธุรกิจของคุณ จากมุมมองนั้น ฉันจะทำให้พวกเขาไม่ปฏิบัติตาม”
ราคาสินค้าเป็นปัจจัยอันดับ
32:25 “หากมีเว็บไซต์อีคอมเมิร์ซที่แข่งขันกันสองแห่งซึ่งขายผลิตภัณฑ์เดียวกันทุกประการ – เว็บไซต์หนึ่งเสนอผลิตภัณฑ์ในราคา $500 อีกเว็บไซต์หนึ่งมีราคา $100 สัญญาณ SEO ทั้งหมดจะเท่ากัน เว็บไซต์ที่ราคาไม่แพงจะมีโอกาสติดอันดับได้ดีขึ้นเพราะราคาสินค้าตัวเดียวกันต่างกันมากไหม”
จอห์นกล่าวว่า: “จากมุมมองของการค้นหาเว็บล้วนๆ ไม่ใช่ ไม่ใช่กรณีที่เราจะพยายามรับรู้ราคาบนหน้าเว็บและใช้เป็นปัจจัยในการจัดอันดับ ดังนั้น ไม่ใช่กรณีที่เราจะบอกว่าเราจะเอาอันที่ถูกกว่ามาจัดอันดับให้สูงกว่านั้น […]
อย่างไรก็ตาม ผลิตภัณฑ์จำนวนมากยังลงเอยด้วยผลการค้นหาผลิตภัณฑ์ ซึ่ง อาจเป็นเพราะคุณส่งฟีด หรืออาจเป็นเพราะเรารู้จักข้อมูลผลิตภัณฑ์ในหน้าเหล่านี้ และผลการค้นหาสินค้า ไม่ทราบว่าสั่งยังไง อาจเป็นเพราะพวกเขาคำนึงถึงราคาหรือสิ่งต่าง ๆ เช่นความพร้อม […]
ดังนั้นจากมุมมองของการค้นหาเว็บ เราจะไม่พิจารณาราคา จากมุมมองของการค้นหาผลิตภัณฑ์ เป็นไป ได้ และส่วนที่ยุ่งยาก ผมคิดว่า เนื่องจาก SEO คือแง่มุมต่างๆ ของการค้นหา ซึ่งมักจะรวมไว้ในหน้าผลการค้นหาหน้าเดียว ซึ่งคุณจะเห็นผลการค้นหาเว็บปกติ และบางทีคุณอาจเห็นผลลัพธ์ของผลิตภัณฑ์ด้านข้าง หรือบางที คุณจะเห็นการผสมผสานบางอย่าง […]”
การย้าย URL ระหว่างแผนผังเว็บไซต์
34:04 “ถ้าเรามีไฟล์แผนผังเว็บไซต์ 200 ไฟล์ และ 20% ถึง 30% ของ URL กระโดดจากไฟล์หนึ่งไปยังอีกไฟล์หนึ่งทุกสัปดาห์ มันจะแย่ขนาดไหน? หรือเราควรเก็บ URL ของเราไว้ในไฟล์เดียวกันอย่างเคร่งครัดตลอดไป”
“ […] โดยปกติแล้ว คำแนะนำของเราคือให้เก็บ URL เดียวกันไว้ในไฟล์แผนผังเว็บไซต์ เดียวกัน สาเหตุหลักคือเราประมวลผลไฟล์แผนผังเว็บไซต์ในอัตราที่ต่างกัน ดังนั้น หากคุณย้าย URL หนึ่งจากไฟล์แผนผังเว็บไซต์หนึ่งไปยังอีกไฟล์หนึ่ง อาจเป็นไปได้ว่าเรามี URL เดียวกันในระบบของเราจากไฟล์แผนผังเว็บไซต์หลายไฟล์ และหากคุณมีข้อมูลที่แตกต่างกันสำหรับ URL เดียวนี้ เช่น วันที่เปลี่ยนแปลงต่างๆ เราจะไม่ทราบว่าแอตทริบิวต์ใดที่จะใช้จริง
จากมุมมองนั้น หากคุณมีมันอยู่ในไฟล์แผนผังเว็บไซต์เดียวกันเสมอ ก็จะง่ายกว่ามากที่เราจะพูดว่า โอ้ เรามีข้อมูลสำหรับ URL นี้ที่นี่ และเราสามารถเชื่อถือข้อมูลนั้นได้เพราะมันอยู่ที่นั่นเท่านั้น นั่นคือสิ่งที่ฉันพยายามหลีกเลี่ยง […] URL เหล่านี้สับเปลี่ยนแบบสุ่ม แต่ในขณะเดียวกัน ก็มักจะไม่ทำให้การประมวลผลไฟล์แผนผังเว็บไซต์หยุดชะงัก และจะไม่มีผลต่อการจัดอันดับเว็บไซต์ของคุณอย่างแน่นอน ดังนั้นจึงไม่มีอะไรในระบบแผนผังไซต์ของเราที่จะจับคู่กับคุณภาพของเว็บไซต์ ”
เนื้อหาหลายภูมิภาค
38:13 “ผมทำงานในแนวข่าว ทีมของฉันต้องการขยายการแสดงตนในระดับสากล และได้ทำงานเพื่อตั้งค่าไดเรกทอรีย่อยหลายภูมิภาค โดยส่วนใหญ่ หน้าในรุ่นต่างๆ ในหลายภูมิภาคจะมีลักษณะเหมือนกัน หน้าแรกและหน้าส่วนต่างๆ เช่น การเมืองหรือไลฟ์สไตล์จะมีเนื้อหาที่คล้ายกันลบเฉพาะบางส่วนในภูมิภาคนี้
บทความมีความยุ่งยาก มีไม่มากที่เราสามารถแยกความแตกต่างในไดเรกทอรีย่อยหลายภูมิภาคนอกโมดูลที่มีลิงก์ที่เกี่ยวข้อง ซึ่งทำให้เรากังวลเกี่ยวกับปัญหาเนื้อหาที่ซ้ำกัน Google จัดการกับเนื้อหาที่ซ้ำกันในพื้นที่ข่าวอย่างไร […] เนื้อหายังคงเดิม แต่องค์ประกอบของเทมเพลตต่างกัน ควรมีเพียงหนึ่งบัญญัติในเว็บไซต์หลายภูมิภาคหรือไม่”
คำตอบของจอห์นคือ: “ […] ดูเหมือนว่าภูมิภาคเหล่านี้เป็นภูมิภาคที่แตกต่างกันภายในประเทศเดียวกัน และเป็นเนื้อหาภาษาเดียวกัน […] หากประเทศเหล่านี้ต่างกัน แสดงว่าคุณมีแง่มุมของการกำหนดเป้าหมายตามภูมิศาสตร์ ซึ่งมีบทบาทหากภาษาเหล่านี้ต่างกัน ดังนั้น หากคุณกำลังทำงาน เช่น ในยุโรป และคุณครอบคลุมเยอรมนี ฝรั่งเศส และอิตาลี หรืออย่างอื่น แสดงว่าคุณมีภาษาที่แตกต่างกันเช่นกัน
[…] แต่ถ้าคุณกำลังพูดถึงในประเทศเดียวกัน เนื้อหาภาษาเดียวกัน […] จะง่ายกว่านิดหน่อยเพราะคุณไม่ต้องกังวลเกี่ยวกับการเชื่อมต่อทางเทคนิคทั้งหมด แต่ในทางกลับกัน ปัญหาเนื้อหาที่ซ้ำกันจะมองเห็นได้ชัดเจนยิ่งขึ้น และเมื่อพูดถึงเนื้อหาที่ซ้ำกัน สิ่งที่ยุ่งยากในเว็บไซต์เหล่านี้ก็คือคุณจะต้องแข่งขันกับตัวเอง และถ้าคุณมีบทความข่าวหนึ่งบทความที่คุณเผยแพร่ในเว็บไซต์ระดับภูมิภาคต่างๆ ห้าหรือหกแห่ง เว็บไซต์ระดับภูมิภาคต่างๆ เหล่านี้จะพยายามจัดอันดับบทความเดียวกันทุกประการ และนั่นอาจส่งผลให้บทความนั้นไม่ได้อันดับเช่นเดียวกับที่อื่นอาจทำได้
ด้วยเหตุนี้ ฉันจึงขอแนะนำให้พยายามค้นหา URL ตามรูปแบบบัญญัติสำหรับบทความแต่ละบทความเหล่านี้ เพื่อให้คุณสามารถพูดได้ว่า 'ฉันมีบทความหนึ่งบทความในเว็บไซต์ระดับภูมิภาคทั้งห้าแห่งของฉัน แต่นี่เป็นเวอร์ชันที่ฉันต้องการเห็น ค้นหา'. จากนั้นเราสามารถรวมพลังงานทั้งหมดของเรา สัญญาณทั้งหมดของเรา ไปที่เวอร์ชันที่ต้องการนั้น และเราสามารถพยายามจัดอันดับอันนั้นให้ดีขึ้นอีกนิด ไม่จำเป็นต้องเป็นรุ่นเดียวกันตลอดเวลา ดังนั้น เป็นไปได้อย่างแน่นอนว่าคุณมีบทความข่าวหนึ่งบทความที่อยู่ภายในภูมิภาคหนึ่งประเภทที่เป็นที่ยอมรับ บทความข่าวอื่นเป็นเนื้อหาที่เป็นที่ยอมรับมากกว่าสำหรับภูมิภาคอื่น วิธีเลือกภูมิภาคที่คุณเลือกตามบัญญัตินั้นขึ้นอยู่กับคุณโดยสิ้นเชิง […] โดยปกติ คุณจะพยายามค้นหาว่าส่วนใดมีความเกี่ยวข้องมากที่สุด และเลือกอันนั้นเป็นเวอร์ชันตามรูปแบบบัญญัติ นั่นคือสำหรับบทความแต่ละบทความเอง
สำหรับหมวดหมู่ และส่วนต่างๆ และโฮมเพจ ดูเหมือนว่าเนื้อหาจะมีความพิเศษเฉพาะตัวมากกว่า และเจาะจงกว่าในแต่ละภูมิภาค และด้วยเหตุนั้น ฉันจึงพยายามแยกระดับดัชนีเหล่านั้นออกจากกัน ดังนั้น หากคุณมีเว็บไซต์ระดับภูมิภาคที่แตกต่างกันห้าแห่ง หน้าแรกของเว็บไซต์ ส่วนหมวดหมู่ เว็บไซต์ทั้งหมดจะได้รับการจัดทำดัชนีทีละรายการ และบทความข่าวเองก็จะถูกแมปไปยังภูมิภาคต่างๆ เหล่านี้ นั่นคือแนวทางที่เราแนะนำที่นั่น […]
และแนวทางนี้ยัง […] ใช้ได้กับชื่อโดเมนต่างๆ ดังนั้น หากคุณมีโดเมนที่แตกต่างกันสำหรับแต่ละภูมิภาค แต่ทั้งหมดเป็นส่วนหนึ่งของกลุ่มข่าวเดียวกัน คุณยังคงปรับเปลี่ยนตามรูปแบบบัญญัติในเวอร์ชันต่างๆ ได้ หากคุณกำลังดำเนินการภายในโดเมนเดียวกันกับไดเรกทอรีย่อย ก็ไม่เป็นไร”
การเปลี่ยนเส้นทางในการย้ายไซต์
44:34 “อะไรคือแนวทางปฏิบัติที่ดีที่สุดเมื่อคุณต้อง 301 เปลี่ยนเส้นทาง URL ทั้งหมดไปยัง URL ชุดใหม่ จำนวนหน้าจะมากกว่าหนึ่งล้านหน้า และคุณต้องการลดผลกระทบของแซนด์บ็อกซ์หรือไม่ ถ้ามีเอฟเฟกต์แซนด์บ็อกซ์จะนานแค่ไหน? เราจะสูญเสียอันดับที่เราไม่สามารถกู้คืนได้หรือไม่? เราวางแผนที่จะทำการเปลี่ยนเส้นทางแบบหนึ่งต่อหนึ่ง และได้ร้องขอการเปลี่ยนเส้นทางแบบกลุ่ม แต่นั่นไม่สามารถทำได้ ดังนั้นหน้า รูปภาพ URL ฯลฯ จะต้องพลิกพร้อมกัน”
ดังที่จอห์นกล่าวว่า “สำหรับฉัน เรื่องนี้ฟังดูเหมือนสถานการณ์การย้ายไซต์แบบดั้งเดิม คุณย้ายจากโดเมนหนึ่งไปยังอีกโดเมนหนึ่ง และเปลี่ยนเส้นทาง URL ทั้งหมดจากเว็บไซต์เก่าของคุณไปยังโดเมนใหม่ และเราต้องจัดการกับมัน […] ไม่มีอะไรที่ถูกกำหนดให้เป็นเอฟเฟกต์แซนด์บ็อกซ์อย่างแน่นอน เมื่อพูดถึงการย้าย ไซต์ ดังนั้น หากคุณจำเป็นต้องย้ายไซต์ ให้ทำการย้ายไซต์ และเปลี่ยนเส้นทางหน้าทั้งหมดของคุณ บ่อยครั้งวิธีที่ง่ายที่สุดคือเปลี่ยนเส้นทางทุกหน้าพร้อมกัน ระบบของเรายังได้รับการปรับแต่งเล็กน้อยเพื่อพยายามรับรู้ ดังนั้น เมื่อเราเห็นว่าเว็บไซต์เริ่มเปลี่ยนเส้นทางหน้าทั้งหมดไปยังเว็บไซต์อื่น เราจะพยายามประมวลผลใหม่ให้เร็วขึ้นเล็กน้อย เพื่อให้เราสามารถดำเนินการย้ายเว็บไซต์ได้โดยเร็วที่สุด และไม่ใช่กรณีที่เราจะพูดว่า โอ้ พวกเขากำลังย้ายไซต์ ดังนั้น เราจะช้าลง […]”
API และการรวบรวมข้อมูลงบประมาณ
46:13 “ฉันมีเว็บไซต์ที่เชื่อมต่อกับ API ทางฝั่งไคลเอ็นต์เพื่อรับข้อมูล URL เหล่านั้นรวมอยู่ในงบประมาณการรวบรวมข้อมูลหรือไม่ หากคุณไม่อนุญาต URL เหล่านั้น […] นั่นจะสร้างปัญหาหรือไม่”
“ […] หาก API เหล่านี้ถูกรวมไว้เมื่อแสดงผลหน้าเว็บ ใช่แล้ว API เหล่านี้จะถูกรวมในการรวบรวมข้อมูลและจะนับรวมในงบประมาณการรวบรวมข้อมูลของคุณเป็นหลัก เนื่องจากเราต้องรวบรวมข้อมูล URL เหล่านั้นเพื่อแสดงหน้าเว็บ คุณสามารถบล็อกได้โดย robots.txt หากคุณต้องการไม่ให้มีการรวบรวมข้อมูลหรือไม่ได้ใช้ระหว่างการแสดงผล ขึ้นอยู่กับคุณหากคุณต้องการทำเช่นนั้น โดยเฉพาะอย่างยิ่งถ้าคุณมี API ที่มีค่าใช้จ่ายสูงในการบำรุงรักษาหรือใช้ทรัพยากรจำนวนมาก บางครั้งมันก็สมเหตุสมผล
ส่วนที่ยุ่งยาก ฉันเดาว่า หากคุณไม่อนุญาตให้รวบรวมข้อมูลปลายทาง API ของคุณ เราจะไม่สามารถใช้ข้อมูลใดๆ เกี่ยวกับการส่งคืน API สำหรับการจัดทำดัชนี ดังนั้น หากเนื้อหาของหน้ามาจาก API เพียงอย่างเดียว และคุณไม่อนุญาตให้รวบรวมข้อมูลของ API เราจะไม่มีผู้ติดต่อนั้น […] หาก API ทำอะไรบางอย่างเสริมในหน้า เช่น อาจวาดแผนที่หรือ […] กราฟิกของตารางตัวเลขที่คุณมีบนหน้า […] บางทีก็ไม่สำคัญว่าเนื้อหานั้นจะไม่ ไม่รวมอยู่ในการจัดทำดัชนี อีกสิ่งหนึ่งคือบางครั้ง หน้าที่การทำงานของหน้าเมื่อ API ถูกบล็อกไม่ใช่เรื่องแปลก โดยเฉพาะอย่างยิ่ง หากคุณใช้ JavaScript และการเรียก API ถูกบล็อกเนื่องจาก robots.txt คุณต้องจัดการกับข้อยกเว้นนั้นด้วยวิธีใดวิธีหนึ่ง และขึ้นอยู่กับว่าคุณฝัง JavaScript บนหน้าอย่างไร สิ่งที่คุณทำกับ API คุณต้องตรวจสอบให้แน่ใจว่ายังคงใช้งานได้ ดังนั้น หากการเรียก API นั้นใช้งานไม่ได้ และการเรนเดอร์หน้าที่เหลือก็พังโดยสมบูรณ์ เราก็ไม่สามารถจัดทำดัชนีได้มากนักเพราะไม่มีอะไรเหลือให้แสดงผล
อย่างไรก็ตาม หากการเรียก API หยุดทำงาน และเรายังสามารถจัดทำดัชนีส่วนที่เหลือของหน้าเว็บของคุณได้ นั่นก็อาจเป็นเรื่องปกติ […] ฉันคิดว่ามันยากกว่าถ้าคุณเรียกใช้ API สำหรับคนอื่นเพราะถ้าคุณไม่อนุญาตการรวบรวมข้อมูล คุณจะมีผลอันดับที่สองที่เว็บไซต์ของคนอื่นอาจขึ้นอยู่กับ API ของคุณ และขึ้นอยู่กับว่า API ของคุณทำอะไร ทันใดนั้น เว็บไซต์ของพวกเขาก็ไม่มีเนื้อหาที่จัดทำดัชนีได้ และพวกเขาอาจจะไม่ได้สังเกตด้วยซ้ำ เพราะพวกเขาไม่รู้ว่าจู่ๆ คุณเพิ่ม disallow ที่นั่น และนั่นอาจทำให้เกิดผลกระทบทางอ้อมเช่น […]”
JavaScript และ Google cache
49:36 “ดังนั้นจึงมีสองหน้าที่มาจากโดเมนเดียวกัน URL จะแตกต่างกันเล็กน้อย ซึ่งเป็นส่วนหนึ่งของโครงสร้างไดเรกทอรีเดียวกัน และ […] สิ่งเหล่านี้ถูกสร้างขึ้นโดย NextJS ดังนั้น NextJS จึงเป็นเฟรมเวิร์กการโต้ตอบที่แสดงผลทางฝั่งเซิร์ฟเวอร์ และกำลังได้รับการจัดทำดัชนี แต่ฉันเห็นหน้าหนึ่งในแคชของ Google และหน้าที่สองไม่อยู่ในแคชของ Google และฉันเห็นรูปแบบเดียวกันไม่ว่าฉันจะสร้างเพจอย่างไร […] หน้าส่วนใหญ่ของฉันอยู่ในแคชของ Google แต่ตอนนี้ฉันกังวลเพราะตอนนี้ฉันกำลังย้ายจากสแต็กเทคโนโลยีที่ใช้ Java ซึ่งสร้างหน้าเหล่านี้ทั้งหมดไปยัง Google NextJS […] เมื่อฉันทำการดีบั๊ก ฉันพบว่านี่เป็นปัญหากับ Java stack รุ่นเก่าที่เราใช้อยู่
ดังนั้นคำถามคือสองส่วน โดยทั่วไปทำไมพฤติกรรมนี้? และอย่างที่สองคือ พฤติกรรมนี้จะส่งผลต่ออันดับของฉันหรือไม่ ฉันเห็นหน้าเหล่านั้นปรากฏในผลการค้นหาซึ่งไม่อยู่ในแคชของ Google”
จอห์นตอบว่า: “ […] หน้าแคชแยกจากสิ่งที่เราจัดทำดัชนีอย่างสมบูรณ์ ดังนั้น หากมีหน้าแคชหรือไม่ ไม่สำคัญเลยสำหรับการจัดอันดับ ไม่สำคัญเลยสำหรับการจัดทำ ดัชนี บางครั้ง มีเหตุผลทางเทคนิคว่าทำไมเราไม่มีหน้าแคช บางครั้ง เราแค่ไม่มีหน้าแคชสำหรับ URL แต่ละรายการ อีกสิ่งหนึ่งคือถ้าหน้านั้นใช้เฟรมเวิร์ก JavaScript แล้วการที่ JavaScript ทำงานบนหน้าแคชนั้นอาจเป็นเรื่องยากในบางครั้ง เพราะหน้าแคชนั้นโฮสต์บนโดเมน Google ขึ้นอยู่กับประเภทของ JavaScript ที่คุณมี ที่ที่ดึงไฟล์ JavaScript ในบางครั้ง JavaScript ไม่สามารถทำงานบนโดเมน Google
[…] หน้าแคชไม่ใช่หน้าที่แสดงผล โดยพื้นฐานแล้วเป็นเพียงไฟล์ HTML ที่เราร้องขอ และสำเนาของไฟล์นั้น และหากไฟล์ HTML แสดงบางอย่างก็ไม่เป็นไร หากใช้ JavaScript และ JavaScript ไม่ทำงานเนื่องจากเป็นหน้าแคช ก็ถือว่าใช้ได้ คุณไม่เห็นมันในหน้าแคช ดังนั้นหากหน้าแคชไม่แสดง ฉันจะไม่กังวลเรื่องนั้น นั่นไม่ใช่สัญญาณของปัญหาใด ๆ และบ่อยครั้ง […] คุณไม่สามารถควบคุมได้ว่ามีหน้าแคชหรือไม่ ฉันจะเพิกเฉยต่อสิ่งนั้น”
https://www.youtube.com/watch?v=Vd0rEQrwHDc