WWW ยังคงอยู่ใน URL หรือไม่ PlatoBlockchain ข้อมูลอัจฉริยะ ค้นหาแนวตั้ง AI.

WWW ยังอยู่ใน URL หรือไม่

เป็นเวลาหลายปีที่สงครามอวดรู้ขนาดย่อมเกิดขึ้นในแถบที่อยู่ของเรา ในมุมหนึ่งมีแบรนด์ดัง Google, Instagramและ Facebook. กลุ่มนี้เลือกที่จะเปลี่ยนเส้นทาง example.com ไปยัง www.example.com. ในมุมตรงข้าม: GitHub, DuckDuckGoและ ไม่ลงรอยกัน. กลุ่มนี้เลือกที่จะย้อนกลับและเปลี่ยนเส้นทาง www.example.com ไปยัง example.com.

“WWW” อยู่ใน URL หรือไม่ นักพัฒนาบางคนมีความคิดเห็นที่ชัดเจนในเรื่องนี้ เราจะสำรวจข้อโต้แย้งสำหรับและต่อต้านหลังจากประวัติศาสตร์เล็กน้อย

เป็นอะไรกับ Ws?

Ws สามตัวย่อมาจาก “เวิลด์ไวด์เว็บ”ซึ่งเป็นสิ่งประดิษฐ์ช่วงปลายทศวรรษ 1980 ที่ทำให้โลกรู้จักเบราว์เซอร์และเว็บไซต์ หลักปฏิบัติในการใช้ “WWW” เกิดจากประเพณีการตั้งชื่อโดเมนย่อยตามประเภทของบริการที่มีให้:

  • เว็บเซิร์ฟเวอร์ที่ www.example.com
  • เซิร์ฟเวอร์ FTP ที่ ftp.example.com
  • เซิร์ฟเวอร์ IRC ที่ irc.example.com

ข้อกังวลเกี่ยวกับโดเมน WWW-less 1: การรั่วไหลของคุกกี้ไปยังโดเมนย่อย

นักวิจารณ์โดเมน “WWW-less” ได้ชี้ให้เห็นว่าในบางสถานการณ์ โดเมนย่อย.example.com จะสามารถอ่านคุกกี้ที่กำหนดโดย example.com. สิ่งนี้อาจเป็นสิ่งที่ไม่พึงประสงค์ เช่น หากคุณเป็นผู้ให้บริการเว็บโฮสติ้งที่ให้ลูกค้าดำเนินการโดเมนย่อยบนโดเมนของคุณ แม้ว่าข้อกังวลนั้นถูกต้อง แต่ลักษณะการทำงานนั้นเฉพาะกับ Internet Explorer

RFC 6265 กำหนดมาตรฐานวิธีการปฏิบัติต่อคุกกี้ของเบราว์เซอร์และเรียกพฤติกรรมนี้อย่างชัดเจนว่าไม่ถูกต้อง

อีกแหล่งที่มาของการรั่วไหลคือ Domain ความคุ้มค่า ของคุกกี้ใด ๆ ที่กำหนดโดย example.com. หาก Domain ค่าถูกกำหนดอย่างชัดเจนเป็น example.comคุกกี้จะถูกเปิดเผยในโดเมนย่อยด้วย

ค่าคุกกี้ สัมผัสกับ example.com สัมผัสกับ โดเมนย่อย.example.com
secret=data
secret=data; Domain=example.com

โดยสรุป ตราบใดที่คุณไม่ได้ตั้งค่า a Domain ค่าและผู้ใช้ของคุณไม่ได้ใช้ Internet Explorer ไม่ควรมีการรั่วไหลของคุกกี้

ความกังวลเกี่ยวกับโดเมน WWW-less 2: อาการปวดหัว DNS

บางครั้ง โดเมน “WWW-less” อาจทำให้การตั้งค่าระบบชื่อโดเมน (DNS) ของคุณยุ่งยาก

เมื่อผู้ใช้พิมพ์ example.com ในแถบที่อยู่ของเบราว์เซอร์ เบราว์เซอร์จำเป็นต้องทราบที่อยู่อินเทอร์เน็ตโปรโตคอล (IP) ของเว็บเซิร์ฟเวอร์ที่พวกเขากำลังพยายามเยี่ยมชม เบราว์เซอร์ร้องขอที่อยู่ IP นี้จากเนมเซิร์ฟเวอร์ของโดเมนของคุณ ซึ่งโดยปกติจะส่งทางอ้อมผ่านเซิร์ฟเวอร์ DNS ของผู้ให้บริการอินเทอร์เน็ต (ISP) ของผู้ใช้ หากเนมเซิร์ฟเวอร์ของคุณได้รับการกำหนดค่าให้ตอบกลับด้วย บันทึก มีที่อยู่ IP โดเมน "WWW-less" จะทำงานได้ดี

ในบางกรณี คุณอาจต้องการใช้ a แทน ชื่อบัญญัติ (CNAME) บันทึกสำหรับเว็บไซต์ของคุณ บันทึกดังกล่าวสามารถประกาศได้ว่า www.example.com เป็นนามแฝงของ example123.somecdnprovider.comซึ่งจะบอกให้เบราว์เซอร์ของผู้ใช้ค้นหาที่อยู่ IP ของ example123.somecdnprovider.com และส่งคำขอ HTTP ไปที่นั่น

ขอให้สังเกตว่าตัวอย่างด้านบนใช้โดเมนย่อย WWW ไม่สามารถกำหนดระเบียน CNAME สำหรับ example.com. ตามที่ RFC 1912ระเบียน CNAME ไม่สามารถอยู่ร่วมกับระเบียนอื่นได้ หากคุณพยายามกำหนดระเบียน CNAME สำหรับ example.com, Nameserver (NS) บันทึกสำหรับ example.com ที่มีที่อยู่ IP ของเนมเซิร์ฟเวอร์ของโดเมนจะไม่ได้รับอนุญาตให้มีอยู่ ด้วยเหตุนี้ เบราว์เซอร์จึงไม่สามารถทราบได้ว่าเนมเซิร์ฟเวอร์ของคุณอยู่ที่ใด

ผู้ให้บริการ DNS บางรายจะอนุญาตให้คุณหลีกเลี่ยงข้อจำกัดนี้ได้ Cloudflare เรียกโซลูชันของพวกเขา CNAME แบน. ด้วยเทคนิคนี้ ผู้ดูแลระบบโดเมนจะกำหนดค่าระเบียน CNAME แต่เนมเซิร์ฟเวอร์จะเปิดเผยระเบียน A

ตัวอย่างเช่น หากผู้ดูแลระบบกำหนดค่าระเบียน CNAME สำหรับ example.com ชี้ไปที่ example123.somecdnprovider.com, และบันทึกสำหรับ example123.somecdnprovider.com มีอยู่ชี้ไปที่ 1.2.3.4จากนั้น Cloudflare จะเปิดเผยบันทึก A สำหรับ example.com ชี้ไปที่ 1.2.3.4.

โดยสรุป แม้ว่าข้อกังวลจะใช้ได้กับเจ้าของโดเมนที่ต้องการใช้ระเบียน CNAME แต่ผู้ให้บริการ DNS บางรายก็เสนอวิธีแก้ปัญหาที่เหมาะสม

WWW-ผลประโยชน์น้อย

ส่วนใหญ่ ข้อโต้แย้ง WWW ใช้งานได้จริงหรือเป็นเครื่องสำอาง ผู้สนับสนุน "No-WWW" แย้งว่าพูดและพิมพ์ง่ายกว่า example.com กว่า www.example.com (ซึ่งอาจสร้างความสับสนให้กับผู้ใช้ที่ไม่เชี่ยวชาญด้านเทคโนโลยีน้อยกว่า)

ฝ่ายตรงข้ามของโดเมนย่อย WWW ยังชี้ให้เห็นว่าการลดโดเมนนั้นมาพร้อมกับข้อได้เปรียบด้านประสิทธิภาพที่ต่ำต้อย เจ้าของเว็บไซต์สามารถลด 4 ไบต์ออกจากแต่ละคำขอ HTTP ได้ด้วยการทำเช่นนั้น แม้ว่าการประหยัดเหล่านี้อาจเพิ่มขึ้นสำหรับเว็บไซต์ที่มีผู้เข้าชมสูงเช่น Facebook แต่โดยทั่วไปแล้วแบนด์วิดท์ไม่ใช่ทรัพยากรที่หายาก

ประโยชน์ของ WWW

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

ผลกระทบต่อการจัดอันดับของเครื่องมือค้นหาของคุณ

ฉันทามติในปัจจุบันคือการเลือกของคุณไม่ส่งผลต่อประสิทธิภาพของเครื่องมือค้นหาของคุณ หากคุณต้องการย้ายจากที่หนึ่งไปยังอีกที่หนึ่ง คุณจะต้องกำหนดค่าการเปลี่ยนเส้นทางถาวร (HTTP 301) แทนการเปลี่ยนเส้นทางชั่วคราว (HTTP 302) การเปลี่ยนเส้นทางแบบถาวรช่วยให้มั่นใจได้ว่าค่า SEO ของ URL เก่าของคุณจะถูกถ่ายโอนไปยัง URL ใหม่

เคล็ดลับในการสนับสนุนทั้งคู่

เว็บไซต์มักจะเลือกอย่างใดอย่างหนึ่ง example.com or www.example.com เป็นเว็บไซต์อย่างเป็นทางการและกำหนดค่าการเปลี่ยนเส้นทาง HTTP 301 สำหรับอีกเว็บไซต์หนึ่ง ในทางทฤษฏีรองรับทั้งสองอย่างได้ www.example.com และ  example.com. ในทางปฏิบัติ ค่าใช้จ่ายอาจมีมากกว่าผลประโยชน์

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

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

เพื่อรักษาการควบคุมลักษณะที่ปรากฏของคุณใน Google ขอแนะนำให้ใส่แท็กลิงก์ตามรูปแบบบัญญัติ ขั้นแรก ตัดสินใจว่าชื่อโฮสต์ใดจะเป็นชื่อทางการ (ตามรูปแบบบัญญัติ)

ตัวอย่างเช่น หากคุณเลือก www.example.comคุณจะต้องแทรกส่วนย่อยต่อไปนี้ใน  ติดแท็ก https://example.com/my-article:

ตัวอย่างนี้ระบุให้ Google ทราบว่าตัวแปร "WWW-less" แสดงถึงเนื้อหาเดียวกัน โดยทั่วไป Google จะชอบเวอร์ชันที่คุณทำเครื่องหมายเป็น Canonical ในผลการค้นหา ซึ่งจะเป็นรูปแบบ "WWW" ในตัวอย่างนี้

สรุป

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

ประทับเวลา:

เพิ่มเติมจาก เคล็ดลับ CSS