5 สิ่งที่คุณต้องรู้เกี่ยวกับ SEO บนขอบกับ Chris Green

วันนี้เราจะมาดูกันว่าคุณจะสามารถปรับปรุงคุณภาพชีวิต SEO ของคุณได้อย่างไรโดยการทำธุรกิจของคุณให้ทันสมัยมากขึ้นด้วย Jump Roper ซึ่งชอบที่จะเกาเคราของเขาอย่างรอบคอบขณะจิบกาแฟและวิสกี้ หรือ อาจเป็นอุดมคติของกาแฟไอริช เขาเป็นผู้ฝึกสอน นักพูด และแก้ปัญหาการค้นหา ขอต้อนรับอย่างอบอุ่นสู่พอดคาสต์ In Search SEO ที่ปรึกษา SEO อาวุโส Chris Green

ห้าภารกิจคือ:

• แยกการทดสอบ
• การจัดการเปลี่ยนเส้นทาง
• การบันทึกการเข้าถึงบอท
• การสร้าง/การจัดการแผนผังเว็บไซต์
• การฉีดเนื้อหา

คริส: ขอบคุณที่มีฉันเดวิด

D: คุณสามารถหา Chris ได้ที่ chris-green.net คริส คุณไม่ได้พูดแบบนั้น แต่คุณเป็นคนขี้ขลาดอยู่เสมอเหรอ?

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

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

1. การทดสอบแยก SEO

C: ในที่สุดการทดสอบภายใน SEO ก็เพิ่มขึ้นอีกเล็กน้อย และมีหลายวิธีในการทดสอบ SEO จากการปรับใช้ง่ายจริง ตรวจสอบกับ Analytics ว่าได้ผลหรือไม่ได้ผล นี่เป็นวิธีที่ง่ายที่สุดในทางทฤษฎี เราทุกคนใน SEO ควรทำ แต่วิธีการทำงานของ "ขอบ" คือการปรับใช้การเปลี่ยนแปลง 50% ของหน้าภายในกลุ่มอย่างมีประสิทธิภาพและให้ Google ไปที่หน้าทดสอบแล้วไปที่หน้าควบคุม/ไม่เปลี่ยนแปลง วิธีนี้ช่วยให้คุณทำการเปลี่ยนแปลงกลุ่มหน้าบนเว็บไซต์ของคุณโดยไม่ต้อง ที่จริงแล้วเปลี่ยนฐานโค้ดหรือเพิ่มข้อกำหนดเพิ่มเติมบนเซิร์ฟเวอร์หรือ CMS เหมือนกับการเพิ่มเลเยอร์พิเศษที่ระบุว่าในหน้าเหล่านี้เราจะแสดงเวอร์ชันต่างๆ แก่ผู้คน ซึ่งคุณทำได้ในหลายจุดในกระบวนการ

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

D: ดังนั้น SEO ส่วนใหญ่จึงสร้างสคริปต์ของตัวเองหรือใช้สคริปต์ง่าย ๆ เพื่อรันการทดสอบแยกเหล่านี้หรือไม่? หรือมีซอฟต์แวร์ทดสอบแยกเฉพาะที่คุณอยากแนะนำให้ใช้ร่วมกับ edge หรือไม่?

C: คุณสามารถเปลี่ยนจากความประเสริฐไปสู่ความไร้สาระได้ หากคุณกำลังพูดถึงขอบ ฉันคิดว่าอาจมีผู้เล่นจำนวนหนึ่งในพื้นที่ที่สร้างขึ้น ดังนั้น Search Pilot หรือ ODN อย่างเป็นทางการจึงถูกสร้างขึ้นบนโครงสร้างพื้นฐานของเอดจ์อย่างแท้จริง พวกเขาได้สร้าง meta CMS ที่ให้คุณควบคุมทุกอย่างได้ จากนั้นพวกเขาก็ดึงเอาการวิเคราะห์และวิธีการวิเคราะห์ที่ชาญฉลาดมาทั้งหมด ฉันไม่สามารถอ้างสิทธิ์ในการเป็นเจ้าของหรือเริ่มต้นสิ่งนี้ได้ ไกลจากมัน. พวกเขาเป็นผู้บุกเบิกที่ใหญ่ที่สุด แต่สิ่งที่คุณสามารถทำได้ด้วย edge บนโครงสร้างพื้นฐาน edge ทุกประเภท เช่น Akamai, Cloudflare และ Fastly คือคุณสามารถเขียนสคริปต์เพื่อทำสิ่งนี้ได้ด้วยตัวเอง และเมื่อคุณพูดถึงขอบ สิ่งที่คุณต้องทำการทดสอบเหล่านี้คือหน้าที่จะเป็นหน้าควบคุม ซึ่งจะเป็นหน้าทดสอบ แล้วสคริปต์ที่ทำการเปลี่ยนแปลงเวอร์ชันทดสอบอย่างมีประสิทธิภาพ และความซับซ้อนโดยรอบนั้นขึ้นอยู่กับความซับซ้อนของการทดสอบ ตัวอย่างเช่น หากคุณเพียงแค่เขียนชื่อหน้าใหม่ การทำเช่นนี้จะกลายเป็นเรื่องตรงไปตรงมาจริงๆ ฉันไม่ใช่วิศวกร ฉันเป็น SEO ที่เอาแต่ใจตัวเองในบางครั้ง แต่สิ่งเหล่านี้ โดยเฉพาะใน Cloudflare อาจเป็นหนึ่งในองค์ประกอบที่เข้าถึงได้มากที่สุดในนั้น ตัวฉันและ Simon Thompson เมื่อหลายปีก่อน ย้อนกลับไปเมื่อเราทั้งคู่อยู่ในเครื่องมือสร้างเอเจนซี่ชื่อ Tool Spark ซึ่งกลายเป็นรุ่นเบต้าและข้อพิสูจน์แนวคิดมากกว่า แต่นั่นก็อยู่เหนือโครงสร้างพื้นฐานของ Cloudflare และอีกครั้ง ให้คุณปรับใช้การทดสอบแยกบนเอดจ์ โดยพื้นฐานแล้ว ฟรี ณ จุดนั้น แต่นั่นก็กลายเป็นแซนด์บ็อกซ์มากกว่า คุณจึงสามารถดำเนินการตามแนวทางผ่านซอฟต์แวร์ระดับองค์กรเพื่อสร้างซอฟต์แวร์ของคุณเองได้ แล้วมีแพลตฟอร์มใหม่ๆ ที่คุณสามารถเรียกใช้ได้ แต่ฉันคิดว่าในฐานะ SEO คุณต้องคิดถึงกองที่คุณกำลังสร้างอยู่ คุณต้องการให้ใครเข้าร่วมอีก หากคุณต้องการลดความเสี่ยงและต้องเผยแพร่สิทธิ์และประวัติการเปลี่ยนแปลง คุณจะได้รับตัวเลือก Enterprise หากคุณเพิ่งมีใครสักคนที่บู๊ทสแตรปแต่ต้องการทดสอบจริงๆ ให้สร้างตรงที่ขอบ หาคนที่สามารถเขียนโค้ดสำหรับผู้ปฏิบัติงาน และคุณสามารถทดสอบสิ่งต่างๆ ได้

D: ฉันรู้สึกว่าเราสามารถพูดคุยเกี่ยวกับการทดสอบแยกบนขอบได้ประมาณสามชั่วโมง แต่มาต่อกันที่ส่วนที่สองที่คุณอยากจะแนะนำว่าดีกว่าและมีประสิทธิภาพมากขึ้นบนขอบ การจัดการเปลี่ยนเส้นทาง

2. การจัดการการเปลี่ยนเส้นทาง

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

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

D: และข้อที่สาม การบันทึกการเข้าใช้บอท

3. การบันทึกการเข้าถึงบอท

C: การบันทึกการเข้าใช้บอทเป็นสิ่งที่น่าสนใจ หากคุณเคยพยายามตรวจสอบไฟล์บันทึก และคุณบอกว่าฉันต้องการบันทึกการเข้าถึงเพื่อทำการวิเคราะห์ คุณไปที่ DevOps หรือใครก็ตาม พวกเขาจะให้คุณดูงงๆ หรือพวกเขาจะพูดว่า ไม่นะ มันใหญ่เกินไป เราไม่เก็บ หรือเราเก็บค่าวัน หรือคุณสามารถมีได้ แต่กรุณาต่อคิวยาว นั่นเป็นสิ่งที่ท้าทายจริงๆ และยิ่งไปกว่านั้น หากคุณใช้ CDN ในการแคช บันทึกการเข้าถึงเซิร์ฟเวอร์ของคุณอาจไม่ได้รับปริมาณการใช้งานบอททั้งหมดอยู่ดี ดังนั้นบันทึกของคุณจะไม่สมบูรณ์ ทุกอย่างที่ผ่าน CDN จะถูกรับโดยการรับส่งข้อมูลทั้งหมด ไม่ว่าจะเป็นแคชหรือไม่ก็ตาม และหากคุณใช้ Edge เพื่อจัดเก็บข้อมูลบันทึกนี้อย่างมีประสิทธิภาพและสตรีมไปยังบริการ เช่น ตรรกะของ Sumo หรือที่เก็บข้อมูลประเภทอื่น คุณจะมีโอกาสดูดข้อมูลทั้งหมดออกจาก Edge แทนที่จะพยายามค้นหา จากเซิร์ฟเวอร์ของคุณ แต่หากคุณกำลังเขียนคนทำงานโดยใช้เหตุผลหรือตรรกะที่ถูกต้อง ณ จุดนั้น คุณสามารถตั้งค่าให้บันทึกเฉพาะการเข้าชมของบอทที่คุณต้องการเท่านั้น โดยปกติแล้ว Googlebot หรือบอทของเครื่องมือค้นหา แต่คุณสามารถทำสิ่งต่างๆ เช่น ตรวจสอบที่อยู่ IP เพื่อให้แน่ใจว่าไม่ได้มีคนปลอมแปลง และรวบรวมเฉพาะข้อมูลการเข้าถึงที่คุณต้องการ ซึ่งช่วยลดพื้นที่จัดเก็บได้อย่างมาก และเครื่องมือบางอย่างเช่น Content King สามารถเชื่อมต่อกับ CDN บางตัวได้โดยตรงเพื่อรวบรวมข้อมูลจากระดับนั้นโดยตรง ดังนั้น สมมติว่าคุณมีระดับการเข้าถึงที่เหมาะสม และ DevOps ตอบว่าใช่ คุณสามารถเริ่มรวบรวมบันทึกเหล่านั้นได้โดยตรง ซึ่งหมายความว่าคุณสามารถทำการวิเคราะห์ SEO เชิงเทคโนโลยีได้ด้วยการยกระดับเพียงเล็กน้อย

D: มีเว็บไซต์ขนาดใดในแง่ของหน้าเว็บที่มันคุ้มค่าที่จะดูไฟล์บันทึกเท่านั้นหรือ SEO ทุกคนควรดูไฟล์บันทึกหรือไม่?

C: ตามหลักการทั่วไป ถ้าเว็บไซต์ของคุณมีไม่ถึง 10,000 หน้า ฉันมักจะไม่พึ่งพาหรือไปหาบันทึกในทันที ส่วนใหญ่เพราะการเข้าถึงพวกเขาเป็นฝันร้าย หากฉันสามารถเข้าถึงข้อมูลนั้นได้อย่างง่ายดายและวิเคราะห์ได้อย่างง่ายดาย… ดังนั้นโปรแกรมรวบรวมข้อมูล SaaS รายใหญ่ เช่น Deep Crawl จะได้รับการวิเคราะห์ไฟล์บันทึกทั้งหมด ถ้าผมสามารถดึงข้อมูลนั้นมาวิเคราะห์ได้ ก็ลองทำดู แต่ถ้าฉันมีหน้าไม่ถึง 10,000 หน้าและได้ข้อมูลนั้นมาก็ไม่ใช่เรื่องยาก ฉันจะไม่อารมณ์เสียเกินไป ตอนนี้การนับหน้านั้นเป็นสิ่งที่ไม่แน่นอน แต่ถ้าคุณมีจำนวนมากกว่าล้านเพจแล้ว logfile จะมีข้อมูลและข้อมูลเชิงลึกมากมายที่จะช่วยให้คุณได้รับชัยชนะที่เพิ่มขึ้น ภายใต้นั้นอาจจะไม่คุ้มค่า D: และประการที่สี่ งานที่มีประสิทธิภาพมากขึ้นที่จะทำบนขอบ การสร้าง/การจัดการแผนผังเว็บไซต์

4. การสร้าง/การจัดการแผนผังเว็บไซต์

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

D: พูดถึงการสร้างมันให้ถูกต้องในครั้งแรก การสร้างแผนผังไซต์ XML โดยอัตโนมัติมีอันตรายหรือไม่ เพื่อให้รวมขยะมากเกินไป?

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

D: และข้อที่ห้าคือการฉีดเนื้อหา คุณกำลังพูดถึงเนื้อหาประเภทใด

5. การฉีดเนื้อหา

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

D: ฉันจำได้เมื่อนานมาแล้ว การรวมเนื้อหาโดยใช้เฟรมและ PHP รวมอยู่ด้วย และทั้งสองวิธีนี้เป็นวิธีที่ล้าสมัยในการทำเช่นนี้ มีข้อเสียใด ๆ ในการแทรกเนื้อหาจากแหล่งอื่นหรือเว็บเซิร์ฟเวอร์อื่น ๆ หรือไม่? จะมีข้อเสีย SEO ใด ๆ ที่อาจเกิดขึ้นจากการทำเช่นนั้นหรือไม่?

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

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

D: ฉันคาดหวังให้มีการสัมมนาผ่านเว็บเกี่ยวกับวิธีรับประกันเวลาทำงานจริง 100% นั่นจะน่าสนใจ

C: เป็นไปได้ เป็นไปได้มากกว่าที่เคยเป็นมา ฉันคิดว่าถ้าคุณรวม Cloudflare และ Akamai หรือ Cloudflare และ Fastly หรือ Similarweb เข้าด้วยกัน คุณก็จะเข้าใกล้ได้มาก ซึ่งน่าสนใจมาก

D: เอาล่ะ มาจบด้วย Pareto Pickle กันเถอะ Pareto กล่าวว่าคุณสามารถได้รับ 80% ของผลลัพธ์จาก 20% ของความพยายามของคุณ กิจกรรม SEO ใดที่คุณอยากแนะนำที่ให้ผลลัพธ์ที่น่าทึ่งสำหรับความพยายามเพียงเล็กน้อย

The Pareto Pickle - เผยแพร่การเปลี่ยนแปลง

C: สิ่งนี้เกือบทำให้กลายเป็น Edge List ของฉันแล้ว แต่ก็ไม่ได้ค่อนข้างดีและมันก็แฮ็คนิดหน่อย ดังนั้นบางคนจะไม่ชอบสิ่งนี้โดยเนื้อแท้ แต่ใช้ขอบเพื่อทำบางสิ่งให้เสร็จ ดังนั้นเราจึงพูดคุยเกี่ยวกับ Meta CMS สั้น ๆ และเป็นสิ่งที่ทีม Search Pilot และ John Avildsen ช่วยกันแสดงให้โลกเห็น แต่คุณสามารถใช้ Edge เพื่อเผยแพร่การเปลี่ยนแปลงที่มิฉะนั้นจะติดอยู่ในคิวการพัฒนา และแนวคิดในการทำให้สำเร็จ นำไปใช้จริง พิสูจน์แนวคิด เพิกเฉยต่อความเสี่ยงของหนี้ด้านเทคโนโลยี และละเว้น DevOps ที่น่ารำคาญเป็นเวลาหนึ่งนาทีเพราะทั้งสองปัจจัยเป็นปัจจัย แต่คุณค่าทั้งหมดใน SEO ก็คือการถ่ายทอดสด เนื้อหาที่ดำเนินการและ Edge สามารถลัดสิ่งนั้นได้ และไม่สวยและไม่ใช่วิธีที่ถูกต้อง แต่การผลักดันเนื้อหาบางส่วนให้เปลี่ยนแปลงแบบสด และการหลีกเลี่ยงคิวมีผลดีหากทางเลือกอื่นรอหกเดือนแต่ไม่เกิดขึ้น

D: ฉันเป็น David Bain โฮสต์ของคุณ คริส ขอบคุณมากสำหรับการเข้าร่วมในพอดคาสต์ In Search SEO

C: ขอบคุณที่มีฉันเดวิด

D: และขอขอบคุณสำหรับการฟัง ดูตอนก่อนหน้าทั้งหมดและลงทะเบียนเพื่อทดลองใช้แพลตฟอร์ม Rank Ranger ได้ฟรีที่ rankranger.com