Enterprise Technical SEO - การสัมมนาผ่านเว็บเรื่อง Power Page One
เผยแพร่แล้ว: 2021-10-08สวัสดีทุกคน ขอต้อนรับสู่บทสรุปของการสัมมนาผ่านเว็บแบบกลุ่มของ Page One Power เกี่ยวกับ Enterprise Technical SEO
ก่อนอื่น ผมต้องขอขอบคุณผู้ร่วมอภิปรายที่ยอดเยี่ยมสำหรับการแบ่งปันเวลาและข้อมูลเชิงลึกกับเราและผู้ชมของเรา! แผงผู้เชี่ยวชาญของเรานำเสนอ:
- Tom Anthony หัวหน้าฝ่ายวิจัยและพัฒนาของ Distilled
- Paul Shapiro ผู้อำนวยการฝ่ายกลยุทธ์และนวัตกรรมที่ Catalyst
- Patrick Stox ผู้เชี่ยวชาญด้าน SEO ที่ IBM
- และ Nicholas Chimonas ผู้อำนวยการฝ่ายวิจัยและพัฒนาที่ Page One Power
นี่เป็นการสัมมนาผ่านเว็บที่ยอดเยี่ยมพร้อมการอภิปรายและการสนทนาที่น่าสนใจในหัวข้อต่างๆ ที่เกี่ยวข้องกับ SEO ด้านเทคนิคระดับองค์กร
หมายเหตุ: บทสรุปนี้จะถอดความการสนทนา ไม่ใช่การถอดความโดยตรง หากคุณสนใจที่จะฟังการสนทนาที่แน่นอน คุณสามารถชมวิดีโอที่ฝังไว้ได้ตลอด
ภาพรวม
การสนทนากินเวลาประมาณหนึ่งชั่วโมง โดยการอภิปรายของเราครอบคลุมหัวข้อ ความท้าทาย และแนวทางแก้ไขจำนวนหนึ่ง
เพื่อให้การสนทนาเข้าใจง่ายขึ้น ฉันได้แยกย่อยทุกอย่างลงที่นี่ รวมวิดีโอที่ฝังไว้ซึ่งเริ่มต้นที่จุดเริ่มต้นของคำถามที่เกี่ยวข้องแต่ละข้อ (แสดงด้วยส่วนหัวย่อยสีเหลือง)
ฉันยังดึงคำพูดหรือแนวคิดที่น่าสนใจเป็นพิเศษออกมาผ่านทางข้อความบล็อกเพื่อให้อ่านง่ายขึ้น อีกครั้ง นี่ไม่ใช่ คำพูดโดยตรง
หากคุณต้องการดูวิดีโอที่บันทึกอย่างครบถ้วน นี่คือ:
นี่คือคำถามที่คณะผู้เชี่ยวชาญของเรากล่าวถึง:
- ไซต์องค์กรมีหน้าเพจนับพัน คุณจัดลำดับความสำคัญและจัดการปัญหาทางเทคนิคในระดับนี้อย่างไร
- การทำงานกับลูกค้าองค์กรหมายถึงวงจรการใช้งานที่ช้าลง วางแผนอย่างไรให้เหมาะสม?
- SEO มักจะได้รับการยอมรับเพียงเล็กน้อยในโครงสร้างองค์กร คุณต่อสู้เพื่องบประมาณ ขายมูลค่าต้นน้ำ และรับลำดับความสำคัญอย่างไร
- SEO ด้านเทคนิคต้องการความร่วมมือจากแผนกต่างๆ คุณสร้างความร่วมมือระหว่างแผนกอย่างไร?
- คุณชอบอะไรเกี่ยวกับเทคนิค SEO มากที่สุด?
- คุณจัดการกับการเปลี่ยนแปลงสินค้าคงคลังจำนวนมากที่ก่อให้เกิด 404s ต่อวันได้อย่างไร
- ควรมี CSS และ Javascript ขนาดใหญ่สำหรับเว็บไซต์ในส่วนท้ายเพื่อให้โหลดเร็วขึ้นหรือไม่
- คุณวัดผลลัพธ์ของการเปลี่ยนแปลงอย่างแม่นยำและแสดงผลลัพธ์เหล่านั้นให้กับลูกค้าได้อย่างไร
คำถามเหล่านี้เป็นจุดเริ่มต้นสำหรับการสนทนา ช่วยแนะนำการสนทนามากกว่าที่จะควบคุม
เนื่องจากการสนทนาไม่ได้เขียนขึ้นเป็นสคริปต์ ผู้ร่วมอภิปรายของเราจึงสามารถรวมเกร็ดเล็กเกร็ดน้อยส่วนตัว กลยุทธ์ที่ไม่เหมือนใคร และข้อมูลและคำแนะนำมากมายในโลกแห่งความเป็นจริง
หวังว่าคุณจะสนุก!
คำถามที่หนึ่ง: ไซต์องค์กรมีหน้าเพจนับพัน คุณจัดลำดับความสำคัญและจัดการปัญหาทางเทคนิคในระดับนี้อย่างไร
การสนทนาเริ่มต้นเวลา 4:05 น.
Nicholas: แพทริค ไป กัน เถอะ
จัดลำดับความสำคัญโดย Impact
แพทริค : โอเค ฉันจะบอกว่าตีที่คุณกำลังจะสร้างผลกระทบที่ดี ในระดับนั้นสำหรับหน้าต่อหน้า เว้นเสียแต่ว่าเป็นหน้าที่สำคัญที่สุดหน้าใดหน้าหนึ่งก็จะไม่สร้างความแตกต่างมากนัก แต่บางครั้งคุณต้องทำทีละหน้าเพื่อให้ได้ชัยชนะเล็กๆ น้อยๆ และสร้างความไว้วางใจที่จำเป็นในการจัดการโครงการที่ใหญ่กว่า
สำหรับเรา มันเป็นเรื่องของการจัดการปัญหาต่างๆ กับระบบ CMS ที่แตกต่างกันและหน่วยธุรกิจต่างๆ ทีละหน่วย เพื่อให้เราสามารถสร้างกรณีศึกษาและแสดงผลกระทบต่อผู้อื่นได้ นั่นคือวิธีที่เราไปเกี่ยวกับมัน
Nicholas: คุณพบว่าคุณมีเวลาในการซื้อได้ง่ายขึ้นหรือไม่ หากคุณได้พิสูจน์กรณีของคุณด้วยส่วนย่อยที่เล็กกว่าในไซต์ของคุณ ถ้าอย่างนั้นคุณมีพลังยิงที่จะโน้มน้าวให้ทีมพัฒนาทำอย่างนั้นในวงกว้างหรือไม่?
แพทริค: ใช่อย่างแน่นอน
Nicholas: พอล คุณคิดอย่างไรกับเรื่องนี้? นอกจากนี้เรายังมีคำถามจากผู้ชมหากคุณต้องการตอบคำถามนั้น คำถามคือ "คุณปรับงบประมาณการตระเวนให้เหมาะสมสำหรับไคลเอ็นต์องค์กรได้อย่างไร"
พอล: ให้ฉันจัดการคำถามหลักก่อน
ฉันคิดว่ามันขึ้นอยู่กับความสามารถในการประเมินผลกระทบของการเปลี่ยนแปลงใด ๆ ที่คุณกำลังจะทำ
เมื่อคุณรู้ว่าจะต้องเสียค่าใช้จ่ายเท่าไรและจะต้องทำอะไร คุณควรจัดลำดับความสำคัญได้ง่ายขึ้น
นั่นหมายถึงการสร้างแบบจำลอง การคาดการณ์ผลกระทบ การคำนวณต้นทุน (ผู้คน ทรัพยากร เทคโนโลยี ฯลฯ) เพื่อนำการเปลี่ยนแปลงไปใช้ และจากนั้น คุณควรจะสามารถจัดลำดับความสำคัญตามนั้นได้ เมื่อคุณรู้ว่าจะต้องเสียค่าใช้จ่ายเท่าไรและจะต้องทำอะไรเพื่อไปถึงจุดนั้น คุณควรจัดลำดับความสำคัญได้ง่ายขึ้น
งบประมาณการรวบรวมข้อมูล
ในแง่ของคำถามเกี่ยวกับงบประมาณการรวบรวมข้อมูล คุณสามารถดูบทความที่ฉันเขียนสำหรับ Search Engine Land ซึ่งอธิบายวิธีที่คุณสามารถใช้อัลกอริธึม PageRank และคำนวณสิ่งนั้นทั่วทั้งเว็บไซต์ของคุณภายในองค์กร และใช้เพื่อส่งผลต่องบประมาณการรวบรวมข้อมูลของคุณ
นิโคลัส: แน่นอน นั่นเป็นแนวทางที่ถูกละเลยค่อนข้างบ่อย โดยพยายามหาข้อมูลเบื้องหลังว่าทำไมคุณถึงคิดว่าการเปลี่ยนแปลงในสถาปัตยกรรมนี้จะทำให้การเปลี่ยนแปลงที่คุณคาดหวัง
ทอม คุณคิดอย่างไรกับเรื่องนี้?
เชื่อมโยง ROI กับ Technical SEO
ทอม: อย่าง แรก ฉันเห็นด้วยกับทั้งแพทริคและพอล ความสัมพันธ์ของสิ่งที่พวกเขาสัมผัสคือการพยายามทำความเข้าใจว่าการแก้ไขใดจะมี ROI สูงสุด
คุณจำเป็นต้องระบุว่าส่วนใดของไซต์องค์กรที่สามารถทำงานได้จริง และเข้าใจว่าสามารถดำเนินการสิ่งต่างๆ ได้เร็วเพียงใด
ดังนั้น คุณไม่เพียงแค่ต้องมีสมมติฐานว่าต้องใช้ความพยายามแค่ไหน แต่คุณต้องพูดถึงผลตอบแทนและอายุขัยด้วย ตัวอย่างของกรณีที่แย่คือบางสิ่งที่ผู้พัฒนาใช้เวลานานกว่าจะไปถึง ซึ่งเมื่อถึงเวลาผลตอบแทนก็จะไม่คุ้มค่าอีกต่อไป
คุณจำเป็นต้องระบุว่าส่วนใดของไซต์องค์กรที่สามารถทำงานได้จริง และเข้าใจว่าสามารถดำเนินการสิ่งต่างๆ ได้เร็วเพียงใด
ในแง่ของ Distilled ODN สิ่งที่น่าตื่นเต้นอย่างหนึ่งจากมุมมองของเราคือการมีสมมติฐานเกี่ยวกับผลกระทบที่ดีกว่า
โดยปกติ ไซต์องค์กรจะมีการเปลี่ยนแปลงทางเทคนิค SEO ที่ค้างอยู่เป็นเวลานาน ซึ่งต้องมีการจัดลำดับความสำคัญในระดับหนึ่ง ดังนั้นเราจึงสนับสนุนให้ผู้คนใช้ ODN ในการทดสอบเพื่อช่วยให้เราตั้งสมมติฐานถึงผลกระทบของการเปลี่ยนแปลงบางอย่างได้ดีขึ้น เป็นเรื่องยากอย่างน่าประหลาดใจที่จะคาดการณ์ ROI ของการเปลี่ยนแปลง SEO ทางเทคนิคบนไซต์องค์กร แต่ ODN ช่วยให้เราสามารถทดสอบสิ่งต่างๆ ได้มากมาย
Nicholas: ฉันคิดว่านั่นเป็นเรื่องจริงโดยเฉพาะอย่างยิ่งในระดับนี้ (องค์กร) การเปลี่ยนแปลงง่ายๆ อาจส่งผลกระทบมากกว่าที่คุณคาดหวัง และฉันคิดว่า SEO บนหน้ามีความสำคัญมากกว่าเมื่อทำงานกับไซต์ขนาดใหญ่
ทอม: แน่นอน และ Mike King มีโพสต์ที่ยอดเยี่ยมเกี่ยวกับ SEO ด้านเทคนิคเกี่ยวกับ Moz
Nicholas: ใช่ โพสต์ของ Mike เป็นจุดที่ดีมากที่เครื่องมือ SEO ของเราจำนวนมากอยู่เบื้องหลังเกม ดังนั้น หากคุณเพียงแค่ใช้เครื่องมือและไม่ตรวจสอบสิ่งต่างๆ ด้วยตนเอง คุณอาจกำลังพลาดประเด็นสำคัญ เป็นกระทู้ที่น่าสนใจและแนะนำให้ลองดูครับ
คำถามที่สอง: การทำงานกับลูกค้าองค์กรหมายถึงวงจรการใช้งานที่ช้าลง วางแผนอย่างไรให้เหมาะสม?
การสนทนาสำหรับคำถามนี้เริ่มต้นเวลา 12:50 น.
Nicholas: Patrick กลับมาหาคุณเพื่อสิ่งนี้
Patrick: ฮ่า นั่นเป็นคำถามที่สนุก! บางครั้งคุณกำลังรอ การเปลี่ยนแปลงมากมายที่ฉันรอ ฉันไม่คาดหวังว่าจะเกิดขึ้นในปีนี้หรือปีหน้าในบางกรณี แต่ก็ยังมีอะไรให้ทำอีกมากมาย
แต่ก็ไม่ใช่อย่างนั้นเสมอไป หากคุณมีระบบ buy-in ของผู้บริหารและทีม buy-in ก็สามารถเคลื่อนไหวได้อย่างรวดเร็ว มันไม่ได้ช้าเสมอไป
Nicholas: ใช่ ฉันเคยเจอเหรียญทั้งสองด้าน ฉันคิดว่าคุณพูดถูก และขึ้นอยู่กับว่าคุณซื้อจากที่ใด (ในระดับใดขององค์กร) ที่สามารถผลักดันและทำให้มันเกิดขึ้นได้เร็วยิ่งขึ้น
และในอีกด้านหนึ่ง—ที่ซึ่งสิ่งต่างๆ ดำเนินไปอย่างช้าๆ และไม่มีการดำเนินการ—เป็นเพราะคุณยังไม่ได้รับความไว้วางใจหรือการยอมรับจากการพิสูจน์ตัวเอง เมื่อคุณได้พิสูจน์ความสำคัญของคำแนะนำแล้ว คำแนะนำมักจะกลายเป็นวงจรการใช้งานที่รวดเร็วยิ่งขึ้น
พอล คุณคิดอย่างไรกับเรื่องนี้?
การดำเนินการเปลี่ยนแปลงตัวเอง
พอล: บ่อยครั้งที่คุณไม่สามารถทำอะไรเกี่ยวกับเวลาดำเนินการได้ มันจะเป็นกระบวนการที่ช้า สิ่งที่คุณสามารถทำได้คือนำสิ่งต่าง ๆ ไปปฏิบัติด้วยตนเอง เมื่อเป็นไปได้ หากคุณมีโอกาสที่จะเปลี่ยนแปลงตัวเอง จะช่วยเร่งกระบวนการให้พร้อม สิ่งเล็กๆ น้อยๆ ที่คุณสามารถนำไปใช้ได้เองจะทำให้กระบวนการนี้เร็วขึ้น
หากคุณมีทีมเทคโนโลยีที่เข้มแข็ง คุณสามารถสร้างความไว้วางใจกับนักพัฒนาและวิศวกรได้ด้วยการยอมรับว่าการเปลี่ยนแปลงในส่วนของพวกเขาอาจไม่สำคัญ และเสนอให้ความช่วยเหลือเมื่อทำได้ คุณสามารถทำสิ่งต่างๆ ให้เสร็จเร็วขึ้นได้เพียงแค่รู้ว่าคุณกำลังทำอะไรอยู่
นอกจากนี้ ตรวจสอบให้แน่ใจว่าคุณกำลังสื่อสารถึงคุณค่าของการเปลี่ยนแปลงเหล่านี้อย่างชัดเจนและพูดคุยกับคนที่เหมาะสม หากคุณมีทีมเทคโนโลยีที่เข้มแข็ง คุณสามารถสร้างความไว้วางใจกับนักพัฒนาและวิศวกรได้ด้วยการยอมรับว่าการเปลี่ยนแปลงในจุดสิ้นสุดของพวกเขาอาจไม่สำคัญ และให้ความช่วยเหลือเท่าที่คุณจะทำได้ คุณสามารถทำสิ่งต่างๆ ให้เสร็จเร็วขึ้นได้เพียงแค่รู้ว่าคุณกำลังทำอะไรอยู่
Nicholas: การ เต็มใจที่จะรับสายบังเหียนและสนับสนุนนักพัฒนาและเห็นอกเห็นใจต่อแบนด์วิดท์ของพวกเขาช่วยได้ เป็นความจริงอย่างยิ่งที่ถ้าคุณทำให้ตัวเองว่าง คุณจะสามารถเข้าถึงได้ และบ่อยครั้งที่การเข้าถึงเพื่อทำการเปลี่ยนแปลงด้วยตัวคุณเองนั้นง่ายกว่าการอยู่ในงานในมือและทำให้มันไปถึงจุดสูงสุด
ทอม คุณช่วยชั่งน้ำหนักที่นี่ได้ไหม
การสร้างความสัมพันธ์กับทีม Dev
ทอม: ฉันสะท้อนสิ่งที่คนอื่นพูดเกี่ยวกับการเป็นมิตรกับผู้พัฒนาและทำให้พวกเขาอยู่เคียงข้างคุณ
เพียงแค่แสดงตัว คุณจะพบว่าคุณสามารถทำสิ่งต่างๆ ได้มากขึ้น มากกว่าเมื่อคุณได้รับอีเมลแบบไม่ต้องเปิดเผยตัวตนที่เข้ามาในกล่องจดหมายของพวกเขา
จากมุมมองของเอเจนซี่ หากคุณมีลูกค้า คุณควรไปทำงานจากสำนักงานของพวกเขา เมื่อคุณอยู่ในสำนักงานของพวกเขา คุณจะเห็นการเปลี่ยนแปลงและทำความเข้าใจว่าคุณต้องคุยกับใครเพื่อทำสิ่งต่างๆ ให้เสร็จสิ้น ในแง่ของทีมนักพัฒนา ดูว่าคุณสามารถเข้าร่วมการประชุมของพวกเขาได้หรือไม่
เพียงแค่แสดงตัว คุณจะพบว่าคุณสามารถทำสิ่งต่างๆ ได้มากขึ้น มากกว่าเมื่อคุณได้รับอีเมลแบบไม่ต้องเปิดเผยตัวตนที่เข้ามาในกล่องจดหมายของพวกเขา เรามีที่ปรึกษาเข้าร่วมการประชุม และจู่ๆ ตั๋ว SEO ที่อ่อนล้าไปก่อนหน้านี้ก็เริ่มลอยขึ้นสู่จุดสูงสุด ที่ปรึกษาไม่ต้องพูดอะไรเลย—เพียงแค่เป็นคนจริงที่ลงทุนในผลลัพธ์ของตั๋วเหล่านี้ ทำให้ตั๋วเหล่านั้นลอยขึ้นไปบนสุด
จากนั้นค้นหาสิ่งที่คุณสามารถทำได้เพื่อช่วยนักพัฒนา มักจะมีตั๋วที่พวกเขาพบว่ายากด้วยเหตุผลบางประการ ซึ่งมักจะไม่ได้รับการติดต่อกลับหาคุณ แต่ถ้าคุณไปคุยกับพวกเขาจริงๆ คุณจะรู้ได้ว่าทำไมพวกเขาถึงลำบากและให้ความช่วยเหลือ สิ่งนี้จะทำให้คุณไว้วางใจกับพวกเขาเพราะพวกเขาจะขอบคุณที่คุณได้พูดคุยกับพวกเขาและรับรู้ถึงความท้าทายของพวกเขา
งบประมาณการรวบรวมข้อมูล (ต่อ)
การวิเคราะห์บันทึกสามารถเข้าถึงได้มากกว่าที่คุณคิด และคุณสามารถใช้เพื่อรวบรวมข้อมูลที่สามารถดำเนินการได้จำนวนมาก มันเป็นอะไรที่ล้มลงข้างทาง แต่ท่อนซุงเป็นเหมืองทองคำ
และเมื่อย้อนกลับไปที่เรื่องงบประมาณการรวบรวมข้อมูล การวิเคราะห์บันทึกมาตราส่วนระดับองค์กรจะมีประโยชน์มากสำหรับงบประมาณการรวบรวมข้อมูล การวิเคราะห์บันทึกสามารถเข้าถึงได้มากกว่าที่คุณคิด และคุณสามารถใช้เพื่อรวบรวมข้อมูลที่สามารถดำเนินการได้จำนวนมาก มันเป็นอะไรที่ล้มลงข้างทาง แต่ท่อนซุงเป็นเหมืองทองคำ
Nicholas: และไม่เคยง่ายอย่างนี้มาก่อนด้วยเครื่องมืออย่าง Screaming Frog Log Analyzer หากคุณไม่เคยทำมาก่อน คุณควรลองดูเพราะคุณจะทึ่งในสิ่งที่คุณสามารถเรียนรู้ได้
ทอม: บ่อยครั้ง ส่วนที่ยากที่สุดในระดับองค์กรคือการโน้มน้าวให้ใครบางคนให้คุณเข้าถึงบันทึก แต่อีกครั้ง การฝังตัวเองลงในทีมที่เหมาะสมจะช่วยได้
การใช้ ODN เพื่อข้ามวงจรการใช้งาน
Nicholas: และอีกอย่างหนึ่ง ด้วย ODN ของ Distilled คุณสามารถข้ามวงจรการใช้งานและรับผิดชอบการเปลี่ยนแปลงด้วยตนเอง ODN ทำหน้าที่เหมือน CDN และช่วยให้คุณสามารถเลี่ยงผ่านระบบเก่าที่มีอยู่ได้
ทอม: ใช่ มันปรับใช้คล้ายกับ CDN และจากมุมมองของผู้ใช้ พวกเขาไม่เห็นว่ามันอยู่ที่นั่น และทำหน้าที่เกือบจะเหมือนกับ CMS ใหม่ที่อยู่เหนือสิ่งอื่นใด
สิ่งที่น่าสนใจมากเกี่ยวกับเรื่องนี้คือเราคาดว่าจะได้รับการตอบกลับจำนวนมากจากทีมพัฒนา เนื่องจากพวกเขาจะรู้สึกสูญเสียการควบคุม แต่สิ่งที่น่าประหลาดใจก็คือทีมพัฒนาจำนวนมากยินดีต่อการเปลี่ยนแปลงนี้เพราะพวกเขารู้สึกผิดหวังกับแพลตฟอร์มเก่าเช่นกัน ดังนั้นเราจึง (SEO) รู้สึกหงุดหงิดที่ตั๋วของเราไม่เสร็จ และพวกเขา (ผู้พัฒนา) รู้สึกหงุดหงิดที่ไม่สามารถดำเนินการให้เสร็จสิ้นได้ ODN สร้างแพลตฟอร์มที่ SEO สามารถช่วยทีมพัฒนาและบรรลุเป้าหมายร่วมกันในการทำให้เว็บไซต์ประสบความสำเร็จเท่าที่จะทำได้
Nicholas: ใช่ มันเป็นชัยชนะทั่วๆ ไป
หมายเหตุ: นิโคลัสรวมคำถามที่สามและสี่เข้าด้วยกันเนื่องจากคำถามที่สามได้รับการสัมผัสแล้ว และเชื่อมโยงอย่างดีกับคำถามที่สี่ คำตอบสำหรับคำถามสองข้ออยู่ด้านล่าง
คำถามที่สาม: SEO มักจะได้รับการยอมรับเพียงเล็กน้อยในโครงสร้างองค์กร คุณต่อสู้เพื่องบประมาณ ขายมูลค่าต้นน้ำ และรับลำดับความสำคัญอย่างไร
คำถามที่สี่: SEO ด้านเทคนิคต้องการความร่วมมือจากแผนกต่างๆ คุณสร้างความร่วมมือระหว่างแผนกอย่างไร?
การอภิปรายเกี่ยวกับคำถามเหล่านี้เริ่มเวลา 23:30 น.
Nicholas: มาเริ่ม กัน เลยกับแพทริค ฉันคิดว่านี่เป็นคำถามที่น่าสนใจเป็นพิเศษในบริบทของ IBM
การฝึกอบรมและการทำงานร่วมกันในระดับองค์กร
Patrick: ตกลง เรามีสองคำถามในหนึ่งเดียว เท่าที่ได้รับการยอมรับในโครงสร้างองค์กร เราได้พูดคุยเกี่ยวกับการทดสอบ กรณีศึกษา การคาดการณ์ ROI ฯลฯ แต่ฉันคิดว่าส่วนใหญ่ที่ขาดหายไปคือการฝึกอบรมพนักงานและทีมต่างๆ
การให้เครดิตกับทีมไปได้ไกล หากทีมทำงานได้ดีก็ให้เครดิตพวกเขา หากพวกเขาทำงานหนักมากและปรับปรุงตามที่คุณแนะนำ พวกเขาก็จะได้รับชัยชนะพร้อมกับคุณ
เชื่อหรือไม่ แต่ในองค์กร SEO เรากำลังทำงานกับ SEO น้อยกว่ามากตามขนาดของไซต์ ดังนั้นการฝึกอบรมจึงเป็นสิ่งจำเป็น และส่วนที่ดีของการฝึกอบรมคือช่วยให้คุณพบคนที่เข้าใจ และจะกลายเป็นผู้ประกาศข่าวประเสริฐของคุณ
การให้เครดิตกับทีมไปได้ไกล หากทีมทำงานได้ดีก็ให้เครดิตพวกเขา หากพวกเขาทำงานหนักมากและปรับปรุงตามที่คุณแนะนำ พวกเขาก็จะได้รับชัยชนะพร้อมกับคุณ
หากมีสิ่งใดที่คุณคิดว่าจะมีผลกระทบ ก็อย่ายอมแพ้ คุณเพียงแค่ต้องหาใครสักคนที่จะรับฟังและหาวิธีที่จะทำให้แน่ใจได้ว่างานในมือจะไม่ตาย
การทำงานร่วมกันเป็นทีมซ้ำๆ จะช่วยสร้างความสัมพันธ์ แม้ในบางครั้ง คุณสามารถช่วยให้ทีมได้รับงบประมาณหรือจ่ายงบประมาณของคุณเองเพื่อช่วยให้พวกเขาได้รับทรัพยากรที่จำเป็นสำหรับการทำโครงการ
อย่ายอมแพ้กับโครงการ
Patrick: ฉันได้ยินสิ่งที่ค้าง งานในมือ งานในมือ...ซึ่งเกิดขึ้นค่อนข้างบ่อย ภายในหรือหน่วยงาน แค่ผลักดันต่อไปไม่สำคัญ หากมีสิ่งใดที่คุณคิดว่าจะมีผลกระทบ ก็อย่ายอมแพ้ คุณเพียงแค่ต้องหาใครสักคนที่จะรับฟังและหาวิธีที่จะทำให้แน่ใจได้ว่างานในมือจะไม่ตาย
Nicholas: ใช่ นั่นทำให้ฉันแทบบ้าเมื่อเกิดเรื่องขึ้น แต่ฉันพบบ่อยกว่าไม่ ถ้าฉันยังคงผลักดัน ฉันสามารถทำให้มันเกิดขึ้นได้ เป็นสิ่งสำคัญมากที่คุณจะไม่ยอมแพ้
แพทริค: ทอมเคยพูดไว้ก่อนหน้านี้ว่าคนในสังกัดจะเข้ามา เมื่อมีคนเข้ามา ปกติแล้วทอมจะได้พบกับคนที่ใช่และพร้อมจะรับฟัง คุณสามารถพูดสิ่งเดียวกันห้าอย่างกับคนในบ้านและไม่ได้ผลลัพธ์ แต่ถ้าตัวแทนเข้ามาและพูดในสิ่งเดียวกันในทันใด มีคนเข้ามาซื้อมากขึ้น และคุณได้รับการยืนยันแล้ว
Nicholas: ใช่ มันเป็นเรื่องจริงมาก มีคนในองค์กรพูดว่า "ขอบคุณ ฉันก็พูดแบบเดียวกัน แต่เราแค่ต้องการใครสักคนจากภายนอกมาพูดอีกครั้ง"
ขอบคุณสำหรับคำตอบของคุณแพทริค ฉันขอขอบคุณความโปร่งใสของคุณ และพอล มาฟังความคิดของคุณเกี่ยวกับคำถามเหล่านี้กัน
พูดภาษา
พอล: ก่อนอื่น ฉันชอบเคล็ดลับของทอมที่เขาพูดถึงก่อนหน้านี้เกี่ยวกับการหาโอกาสสร้างความสัมพันธ์แบบเห็นหน้ากับลูกค้า
ในด้านอื่นๆ ที่คุณสามารถทำได้ การรู้ว่าคุณกำลังพูดกับใครและพูดภาษาของเขาช่วยได้จริงๆ ตัวอย่างเช่น หากคุณกำลังพูดคุยกับทีมการตลาด คุณจะต้องพูดถึงดอลลาร์และเซ็นต์ และจะส่งผลต่องานของพวกเขาอย่างไร
Nicholas: แน่นอนว่านี่เป็นเคล็ดลับที่ดีในการไปที่สำนักงานของลูกค้า ทอม คุณมีเคล็ดลับดีๆ อะไรอีกบ้างสำหรับเรา
การรายงาน SEO ทางเทคนิค
ทอม: สิ่งหนึ่งที่เรายังไม่ได้พูดถึง—ที่เกี่ยวกับคำถามที่สาม—คือวิธีการรายงานของคุณ SEO มีแนวโน้มที่จะเขียนรายงานขนาดใหญ่ที่ผสมผสานเหตุผล SEO กับผลตอบแทน เคล็ดลับหนึ่งสำหรับการรายงานที่ดีขึ้นคืออย่าฝังลูกค้าเป้าหมาย หัวเรื่องอีเมลของคุณควรเป็นการเพิ่มมูลค่าระดับบนสุด แต่อย่าเพิ่งให้เอกสาร Word จำนวนมากแก่พวกเขา
คุณควรดูว่าลูกค้าใช้ภาษาใดในรายงานประจำปีหรือบนเว็บไซต์ของพวกเขา และจำลองภาษานั้นในชุดสไลด์ของคุณ ด้วยวิธีนี้ ทุกคำพูดของคุณจะเชื่อมโยงกลับไปในภาษาของพวกเขาเอง
คุณสามารถสร้างรายงานเป็นชุดสไลด์ที่นำเสนอประเด็นสำคัญในระดับสูง ทำให้เข้าถึงและแชร์ข้อมูลได้มาก เนื่องจากรายงานข้อความขนาดใหญ่นั้นจะไม่ถูกอ่านโดยระดับการจัดการ แต่ถ้าคุณให้ชุดสไลด์ที่สแกนได้ คนในธุรกิจจำนวนมากขึ้นจะได้เห็นสิ่งที่คุณกำลังทำเพื่อธุรกิจของพวกเขา
ประเด็นสำคัญอีกประการหนึ่งคือประเด็นที่เปาโลสร้างขึ้น—พูดภาษาของพวกเขา คุณควรดูว่าลูกค้าใช้ภาษาใดในรายงานประจำปีหรือบนเว็บไซต์ของพวกเขา และจำลองภาษานั้นในชุดสไลด์ของคุณ ด้วยวิธีนี้ ทุกคำพูดของคุณจะเชื่อมโยงกลับไปในภาษาของพวกเขาเอง และเชื่อมโยงกับรายได้ เพราะนั่นคือสิ่งที่ระดับผู้บริหารให้ความสำคัญ
เน้นเป้าหมาย/วัตถุประสงค์ร่วมกัน
แนวทางเชิงยุทธวิธีเพิ่มเติมคือการค้นหาว่าเป้าหมายของแต่ละแผนกคืออะไร การทำความเข้าใจวัตถุประสงค์จะช่วยให้คุณสามารถอธิบายว่าการเปลี่ยนแปลงของคุณจะช่วยให้พวกเขาบรรลุเป้าหมายได้อย่างไร
Nicholas: ใช่ เป็นจุดที่ดีจริงๆ ที่จะเข้าใจเป้าหมายของแผนกที่คุณทำงานด้วย และเชื่อมโยงการรายงานของคุณเข้ากับประเด็นนั้นโดยตรง
Patrick: นั่นเป็นจุดที่ดี ทุกแผนกจะมีเป้าหมายที่แตกต่างกัน และคุณสามารถสร้างดัชนีชี้วัดที่จะแสดงให้แผนกต่างๆ เห็นว่าคำแนะนำของคุณจะช่วยให้พวกเขาบรรลุเป้าหมายส่วนตัวได้อย่างไร
นิโคลัส: ถูกต้อง และนั่นสามารถสร้างแรงจูงใจให้ก้าวผ่านวงจรการนำไปปฏิบัติ
Paul: มีโพสต์ที่ยอดเยี่ยมโดย Rob Ousbey ในบล็อก Moz ที่ฉันแนะนำให้คุณอ่านหากคุณกำลังจัดการกับปัญหานี้
Nicholas: โพสต์ที่ David Sottimano เขียนซึ่งมีรายการตรวจสอบสำหรับ SEO ระดับจูเนียร์ก็คุ้มค่าที่จะลองดู
สร้างรายงานอเนกประสงค์
Nicholas: อีกสิ่งหนึ่งที่คุณพูดถึง Tom ที่น่าสนใจสำหรับฉันคือสามเหลี่ยมแห่งการรายงาน ในใจของฉัน ฉันเห็นเสมอว่ามันเป็นรายงานสามประเภทที่แตกต่างกันที่คุณจะรวบรวม ซึ่งรวมถึง: สเปรดชีตและการสรุปข้อมูล สไลด์โชว์สำหรับระดับผู้บริหารที่ไม่ต้องการเนื้อหาสาระแต่ต้องการสรุป และ จากนั้นรายงานยาวที่อธิบายทุกอย่างในเชิงลึก
เมื่อคุณทำรายงาน ปกติแล้วคุณทำทั้งสามอย่างหรือคุณปรับแต่งรายงานของคุณโดยพิจารณาจากคนที่คุณทำงานด้วย
ทอม: สิ่งที่เรามักจะทำคือแปลงรายงานที่มีข้อความจำนวนมากเป็นตาราง ดังนั้น คุณสามารถมีคำแนะนำในประโยคเดียว จากนั้นในคอลัมน์ คุณสามารถมีเหตุผลทางเทคนิค สิ่งที่ต้องทำ และผลกระทบที่อาจเกิดขึ้น วิธีนี้ใช้ได้ผลดีเนื่องจากทีมต่างๆ อาจสนใจคอลัมน์ต่างๆ และสามารถข้ามข้อมูลที่ไม่เกี่ยวข้องได้อย่างง่ายดาย
หากคุณสามารถสร้างรายงานหนึ่งฉบับในแบบที่หลายทีมสามารถเข้าถึงได้ คุณไม่จำเป็นต้องสร้างรายงานที่แตกต่างกันหลายฉบับ
Nicholas: ใช่ ฉันพบว่ามันเป็นเรื่องจริง
ทอม: ดังนั้น หากคุณสามารถสร้างรายงานหนึ่งฉบับในแบบที่หลายทีมสามารถเข้าถึงได้ คุณไม่จำเป็นต้องสร้างรายงานที่แตกต่างกันหลายฉบับ
Nicholas: ใช่ นั่นสมเหตุสมผลแล้ว ฉันคิดว่าการใส่ข้อมูลลงในสไลด์โชว์ด้วยกราฟและรูปภาพจะมีประโยชน์เสมอ แต่ฉันชอบที่จะหลีกเลี่ยงเมื่อเป็นไปได้ เพราะงานยุ่งมาก
คำถามที่ห้า: คุณชอบอะไรเกี่ยวกับเทคนิค SEO มากที่สุด?
เริ่มการสนทนาเวลา 38:42 น.
Nicholas: แพทริค ให้นายพาพวกเราออกไป
SEO ทางเทคนิค: ความท้าทายใหม่ ความคิดสร้างสรรค์ และผลลัพธ์ที่วัดได้
Patrick: ฉันชอบคำถามนี้! สำหรับฉัน ฉันชอบที่มีปัญหาใหม่และสิ่งที่ฉันไม่เคยเห็นมาก่อนเสมอ มีบางอย่างที่ฉันรู้สึกเหมือนไม่เห็นที่อื่นเสมอ มีสิ่งใหม่ๆ อยู่เสมอ
Nicholas: ฉันเห็นด้วย นั่นเป็นหนึ่งในสิ่งที่ดีที่สุดเกี่ยวกับเทคนิค SEO ไม่ค่อยมีช่วงเวลาที่แห้งแล้ง มักมีปริศนาใหม่ๆ ให้แก้อยู่เสมอ
พอล แล้วคุณล่ะ คุณรักอะไรมากที่สุด?
Paul: คุณรู้ไหม SEO ทางเทคนิคทำให้ชื่อเสียงนี้แห้งแล้งมาก แต่ฉันพบว่ามันเป็นหนึ่งในส่วนที่สร้างสรรค์ที่สุดของ SEO เพราะคุณกำลังเผชิญกับรูปแบบของข้อจำกัด และคุณถูกบังคับให้คิดหาวิธีแก้ไขที่ไม่เหมือนใครและแก้ปัญหาด้วยวิธีที่น่าสนใจ ดังนั้น สำหรับฉัน ความคิดสร้างสรรค์ที่เกี่ยวข้องกับเทคนิค SEO จริงๆ นั่นแหละที่ทำเพื่อฉัน
นิโคลัส: แน่นอน ต้องใช้ความคิดสร้างสรรค์แบบนอกกรอบในการแก้ไขปัญหาทางเทคนิคและทำความเข้าใจ
ทอม คุณชอบอะไรเกี่ยวกับเทคนิค SEO ที่สุด?
ทอม: ฉันจะสะท้อนคำตอบเดียวกับที่ฉันคิด—ส่วนการไขปริศนานี้ บ่อยครั้ง ไม่มีคำตอบที่ถูกต้อง หรือเมื่อมี เราไม่สามารถแก้ปัญหานั้นได้ เราจึงต้องหาคำตอบที่ดีที่สุดต่อไป การคิดอย่างสร้างสรรค์นั้นคือการหาทางแก้ไขที่แตกต่างกัน
ในด้านเทคนิค SEO คุณสามารถดูสิ่งที่คุณประสบความสำเร็จได้จริง
อีกเหตุผลหนึ่งก็คือ มันเป็นหนึ่งในพื้นที่ของการตลาดที่คุณสามารถเริ่มวัดได้ว่าผลกระทบของคุณคืออะไร ในขณะที่มันยากที่จะทำในด้านอื่นๆ ของการตลาด ในด้านเทคนิค SEO คุณสามารถดูสิ่งที่คุณประสบความสำเร็จได้จริง
Nicholas: แน่นอน หนึ่งในส่วนที่ดีที่สุดของเทคนิค SEO คือการทดสอบและทดลอง การเล่นกับเสิร์ชเอ็นจิ้นและอัลกอริธึมการเรียนรู้ของเครื่องและพยายามคิดว่าสิ่งใดจะได้ผลดีที่สุดนั้นน่าทึ่งสำหรับฉัน
ทอม: ครับ และการเพิ่มประสิทธิภาพให้อัลกอริทึมของ Google ซึ่งเปลี่ยนแปลงตลอดเวลาหมายความว่าสิ่งที่ใช้ได้ผลเมื่อสองสามเดือนก่อนอาจไม่เป็นเช่นนั้นอีกต่อไป ดังนั้นคุณต้องเรียนรู้ต่อไป
นิโคลัส: แน่นอน นั่นเป็นเหตุผลที่ดีจริงๆ ว่าทำไมเทคนิค SEO ถึงน่าทึ่ง ขอบคุณสุภาพบุรุษ
คำถามที่หก: คุณจัดการกับการเปลี่ยนแปลงสินค้าคงคลังจำนวนมากที่ก่อให้เกิด 404 ตันต่อวันได้อย่างไร
การสนทนาเริ่มต้นที่เวลา 43:40 น.
Patrick: ฉันคิดว่านั่นคืออีคอมเมิร์ซ ฉันเดาว่าฉันจะเริ่มต้นด้วยผลิตภัณฑ์จะกลับมาหรือไม่? หากเป็นเพียง 404ing เนื่องจากไม่มีในสินค้าคงคลัง แต่จะมีสินค้าคงคลังในสัปดาห์หน้าซึ่งต่างจากสินค้าที่เพิ่งหมดไป
ในกรณีของอดีตฉันจะไม่ปล่อยให้หน้า 404 เหล่านั้น ฉันแค่แสดงว่ามันหมดสต็อกแล้ว ในกรณีหลัง ถ้าเป็นเรื่องมากมาย คุณอาจต้องขยายขนาดการเปลี่ยนเส้นทางของคุณหรือจัดลำดับความสำคัญตามลิงก์ที่เข้ามา (ทั้งภายในและภายนอก) เพื่อให้แน่ใจว่าคุณจะไม่ได้รับ 404 จำนวนมาก
กำลังตรวจสอบข้อมูล
Nicholas: ฉันสงสัยว่าคำถามนี้มาจากคนที่ได้รับข้อผิดพลาดหลายอย่างในเครื่องมือของผู้ดูแลเว็บหรือไม่ เพราะสิ่งเหล่านี้คือ soft 404 ดังนั้นจึงเป็นเรื่องปกติที่จะเป็น 404 แต่ไม่ควรเป็นแบบ soft 404 และคุณต้องตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ของคุณส่งการตอบกลับที่เหมาะสม
ทอม: นี่เป็นอีกเหตุผลหนึ่งสำหรับการวิเคราะห์ไฟล์บันทึก เพราะนั่นคือข้อมูลที่คุณเชื่อถือได้จริงๆ บางครั้งเครื่องมือของผู้ดูแลเว็บอาจเป็นเรื่องยากที่จะทราบว่าข้อมูลเชื่อถือได้หรือไม่ และการมีปฏิกิริยาตอบโต้และลงมือทำอาจเป็นอันตรายได้ ดังนั้นคุณจึงต้องการตรวจสอบสิ่งที่เกิดขึ้นก่อน
Paul: คุณอาจต้องการถามว่าทำไมมันถึง 404ing เป็นความตั้งใจหรือไม่? คุณอาจต้องการกำหนดค่าสิ่งต่างๆ ใหม่ เพื่อไม่ให้เกิดข้อผิดพลาด 404 เมื่อสินค้าหมดสต็อก และนั่นจะขึ้นอยู่กับ CMS ที่คุณใช้อยู่
Nicholas: และมันขึ้นอยู่กับสถานการณ์จริงๆ ว่าสินค้าเหล่านี้เป็นผลิตภัณฑ์ที่หายไปตลอดกาลหรือกำลังจะกลับมา? นั่นเป็นปัจจัยในการตัดสินใจจริงๆ
คำถามที่เจ็ด: ขอแนะนำให้ใช้ CSS และ JavaScript ขนาดใหญ่สำหรับเว็บไซต์ในส่วนท้ายเพื่อให้โหลดเร็วขึ้นหรือไม่
เสวนาเริ่มเวลา 46:20 น.
ทอม: มีคำถามสองข้อจริงๆ JavaScript ควรอยู่ในส่วนท้าย ซึ่งเป็นแนวทางปฏิบัติที่ดีที่สุดมาตรฐานสำหรับความเร็วหน้าเว็บ ฉันไม่เคยได้ยินกรณีที่ดีสำหรับมัน (JavaScript) ที่มีผลกระทบต่อ SEO
คุณควรตรวจสอบสิ่งที่เกิดขึ้นภายใน Search Console อยู่เสมอ
ปัญหาที่ใหญ่กว่าของไฟล์ JavaScript เมื่อเร็ว ๆ นี้คือผู้คนกำลังใช้ไฟล์ JavaScript ของบุคคลที่สามซึ่งบางครั้งช้ากว่าและมักถูกบล็อกโดย robots.txt ดังนั้น หากคุณทำการเรนเดอร์ใดๆ กับ Google ใน Search Console คุณจะเห็นว่ามันถูกบล็อกจริงๆ ดังนั้นคุณควรตรวจสอบสิ่งที่เกิดขึ้นภายใน Search Console อยู่เสมอ
นิโคลัส: ถูกต้อง ปัญหาที่น่าสนใจอย่างหนึ่งที่ฉันมีเกี่ยวกับการมี JavaScript อยู่ในหัวคือ Search Console ตรวจพบโค้ด hreflang ด้านล่าง ดังนั้น Search Console จึงกล่าวว่าไม่มีหน้าที่มีมาร์กอัป และเป็นเพราะ JavaScript อยู่เหนือ hreflang ในส่วนหัว
ดังนั้นเราจึงย้าย JavaScript ไปที่ส่วนท้าย และตรวจพบ hreflang และทำให้การดึงข้อมูลและการแสดงผลทำงานได้อย่างถูกต้องเช่นกัน
คำถามที่แปด: คุณวัดผลลัพธ์ของการเปลี่ยนแปลงอย่างแม่นยำและแสดงผลลัพธ์เหล่านั้นให้กับลูกค้าได้อย่างไร
การสนทนาเริ่มต้นที่ 48:51 น.
ทอม: มีหลายวิธีในการทำเช่นนี้ วิธีหนึ่งที่น่าสนใจคือการใช้ไลบรารี CausalImpact ของ Google เพื่อช่วยคุณทดสอบผลกระทบของการเปลี่ยนแปลงที่คุณทำ ทอมอ้างถึงโพสต์นี้โดย Mark Edmondson
ยิ่งไปกว่านั้น ผู้คนเริ่มใช้วิธีการ A/B มากขึ้นเรื่อยๆ ทอมอ้างถึงโพสต์นี้โดย Etsy
Nicholas: มาฟังจาก Patrick หรือ Paul เกี่ยวกับเรื่องนี้กัน
Patrick: มันจะขึ้นอยู่กับขนาด คุณเพียงแค่ต้องติดตามสิ่งที่สำคัญ เพียงให้แน่ใจว่าคุณมีข้อมูลที่จำเป็นในการติดตามสิ่งที่คุณต้องการทำ
นิโคลัส: แน่นอน ฉันไม่รู้ว่าคุณเคยลงไปจนสุดถนนแล้วหรือยังและไม่มีข้อมูล แต่นั่นไม่ใช่สถานที่ที่น่าอยู่
เอาล่ะ มาปิดท้ายด้วยความคิดสุดท้ายของคุณพอล
พอล: แน่นอน ก่อนอื่น ฉันคิดว่าวิธีการทดสอบ A/B นั้นประเมินค่าต่ำเกินไปในสภาพแวดล้อม SEO และหากคุณสามารถหากระบวนการที่ดีในการทำสิ่งนั้นภายในองค์กรของคุณ ฉันขอแนะนำอย่างยิ่ง
หากไม่สามารถทำได้ แสดงว่าคุณติดอยู่กับการดูว่าการเปลี่ยนแปลงใดเกิดขึ้น เกิดขึ้นเมื่อใด เครื่องมือค้นหารับทราบการเปลี่ยนแปลงเหล่านี้เมื่อใด และผลกระทบคืออะไร (การเข้าชมเพิ่มขึ้น การแปลงที่ดีขึ้น ฯลฯ)
จากนั้นคุณพยายามกำจัดปัจจัยภายนอกให้ได้มากที่สุด และแยกปัจจัยภายนอกออกจากการเปลี่ยนแปลงที่คุณได้ทำไว้ ไม่ใช่เรื่องง่ายเสมอไป แต่อย่างน้อยคุณสามารถทำงานที่ดีในการบอกทิศทางว่านี่คือผลกระทบของการเปลี่ยนแปลงที่กำหนด