ข้อกำหนดเว็บไซต์

 (specification.website)
4 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นข้อกำหนดที่สรุปความสามารถทางเทคนิคที่เว็บไซต์ที่ดีควรมีโดยไม่ขึ้นกับแพลตฟอร์ม ครอบคลุมตั้งแต่ <title> ไปจนถึง llms.txt
  • ออกแบบมาสำหรับทั้งมนุษย์และ เอเจนต์ โดยอ้างอิงมาตรฐานเว็บสมัยใหม่ เช่น WHATWG, W3C, IETF RFCs, WCAG และ MDN
  • ไม่ว่าจะเผยแพร่ด้วย WordPress, Next.js, แอป Django หรือ HTML ล้วน ๆ ตัวข้อกำหนดเองเหมือนกันทั้งหมด และยังมีคำแนะนำในการนำไปใช้รวมอยู่ด้วย
  • หัวข้อทั้งหมดแบ่งเป็น 10 หมวด เช่น Foundations, SEO, Accessibility, Security, Performance และแมปกับมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวาง
  • มี เซิร์ฟเวอร์ MCP แบบสาธารณะ, Agent Skill, /llms.txt และการตอบกลับแบบ Markdown เพื่อให้เอเจนต์และผู้ดูแลระบบใช้ในการตรวจสอบ เรียนรู้ และปรับปรุงได้

ข้อกำหนดอิสระจากแพลตฟอร์มสำหรับเว็บไซต์ที่ดี

  • The Website Specification เป็นข้อกำหนดที่สรุปความสามารถทางเทคนิคที่เว็บไซต์ที่ดีควรมีโดยไม่ขึ้นกับแพลตฟอร์ม ครอบคลุมตั้งแต่ <title> ไปจนถึง /.well-known/security.txt, ความสอดคล้องกับ WCAG และ llms.txt
  • ออกแบบมาสำหรับทั้งมนุษย์และเอเจนต์ โดยแต่ละหัวข้อเชื่อมโยงกับแหล่งมาตรฐานเว็บสมัยใหม่ เช่น WHATWG, W3C, IETF RFCs, WCAG, MDN
  • ไม่ว่าจะเผยแพร่ด้วย WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, แอป Django หรือ HTML ล้วน ๆ ตัวข้อกำหนดเองเหมือนกันทั้งหมด ส่วนคำแนะนำในการนำไปใช้จะตามมาภายหลัง
  • ทุกหน้ามีลิงก์ Edit on GitHub สามารถส่ง PR ได้ และแต่ละหน้าจะแสดงแหล่งอ้างอิงไว้

  • ขอบเขตที่ครอบคลุม

    • หัวข้อทั้งหมด แบ่งเป็น 10 หมวดที่แมปกับมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวาง
    • Foundations: 14 รายการ ครอบคลุม HTML, head และองค์ประกอบพื้นฐานของเอกสาร
    • SEO: 13 รายการ รวมองค์ประกอบสำหรับการแสดงผลในการค้นหา เช่น robots.txt, sitemap, canonical และ structured data
    • Accessibility: 20 รายการ นำเสนอกฎที่อิงตาม WCAG เพื่อให้ผู้ใช้ทุกความสามารถสามารถใช้งานเว็บไซต์ได้
    • Security: 12 รายการ ครอบคลุม header, การส่งข้อมูล และนโยบายเพื่อปกป้องผู้เยี่ยมชมอย่างปลอดภัย
    • Well-Known URIs: 9 รายการ สรุปเส้นทางมาตรฐานที่ตกลงร่วมกันภายใต้ /.well-known/
    • Agent Readiness: 18 รายการ ครอบคลุมองค์ประกอบที่ช่วยให้ AI เอเจนต์และครอว์เลอร์อ่านเว็บไซต์ได้
    • Performance: 19 รายการ ครอบคลุม Core Web Vitals, caching, รูปภาพ, ฟอนต์ และพฤติกรรมเครือข่าย
    • Privacy: 6 รายการ ครอบคลุมความยินยอม สัญญาณ และการเคารพตัวเลือกของผู้เยี่ยมชม
    • Resilience: 5 รายการ ครอบคลุมการล้มเหลวอย่างนุ่มนวล เช่น หน้าข้อผิดพลาด ออฟไลน์ และการรีไดเรกต์
    • Internationalisation: 12 รายการ ครอบคลุมภาษา โลแคล ทิศทาง และเนื้อหาที่แปลแล้ว

วิธีใช้งานสำหรับเอเจนต์และผู้ดูแลเว็บไซต์

  • ข้อกำหนดทั้งหมดให้บริการผ่านเซิร์ฟเวอร์ MCP แบบสาธารณะ ที่อ่านได้อย่างเดียวและไม่ต้องยืนยันตัวตน
  • มีการเผยแพร่ Agent Skill ที่อธิบายว่าเอเจนต์ที่เข้ากันได้ควรใช้ข้อกำหนดนี้เมื่อใดและอย่างไร
  • URL ของข้อกำหนดแต่ละรายการสามารถให้ Markdown รายหน้าได้ผ่าน /llms.txt และ Accept: text/markdown
  • ตัวอย่างการตั้งค่าเซิร์ฟเวอร์ MCP มีดังนี้
{  
  "mcpServers": {  
    "specification-website": {  
      "transport": "http",  
      "url": "https://mcp.specification.website/mcp";  
    }  
  }  
}

  • ขั้นตอนการใช้งาน

    • Audit: ไล่ดูเช็กลิสต์ และตรวจแต่ละข้อว่า “เว็บไซต์ทำสิ่งนี้หรือไม่ — ใช่/ไม่ใช่”
    • Learn: ตรวจดูในแต่ละข้อว่ามันคืออะไร ทำไมจึงสำคัญ และจะนำไปใช้อย่างไร
    • Improve: หากพบส่วนที่ขาด ข้อมูลที่ล้าสมัย หรือหัวข้อที่ตกหล่น สามารถแนบแหล่งอ้างอิงแล้วเปิด PR ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • Agent Readiness ดูมีโอกาสจะกลายเป็นอะไรที่น่าเขินในอนาคตแบบเดียวกับ "Web 4.0 Blockchain Integration"
    ไม่ใช่เพราะเอเจนต์จะหมดความหมาย แต่เพราะต่อให้มันสำคัญขึ้นมาจริง ถ้าเว็บไซต์ต้องทำข้อยกเว้นพิเศษสำหรับเอเจนต์ก็เท่ากับทำลายเจตนารมณ์เดิม
    สุดท้ายคงถูกเอาไปใช้โดยผู้ไม่หวังดีเพื่อทำให้สิ่งที่เอเจนต์เห็นต่างจากสิ่งที่คนเห็น และเพราะงั้นมันก็น่าจะถูกเพิกเฉยโดยตั้งใจ

    • อยากกลับไปยุค 2000 ตอนนั้นพื้นฐานก็แค่ HTML ล้วน กับ CSS นิดหน่อย และแค่สไตล์ชีตเริ่มต้นของเบราว์เซอร์ก็ให้เลย์เอาต์ที่เกือบตอบสนองได้ดี ข้อความอ่านง่าย และ GUI ที่เป็นมิตรกับผู้ใช้แล้ว
      ทุกวันนี้เว็บไซต์ทุกอย่างกลายเป็นคอมโพเนนต์หมด แม้แต่ dropdown ง่าย ๆ ที่มีรายการจำกัดก็ยังมี loader ของตัวเองและยิงคำขอ fetch 10 ครั้งแบบไม่มีเหตุผล ไม่ได้พูดเกินจริง แค่ไปดูเว็บ Instagram กับ Facebook ก็พอ
      อยากโยนสเปกพวกนี้ทิ้งไปให้หมด แล้วขอแค่ HTML ต้นฉบับที่ไม่ถูกทำให้อ่านยากด้วยอะไรอย่าง React ที่คอยอ้างว่า JS framework ตัวใหม่จะมาเปลี่ยนเกม
    • ตอนแรกกะจะโต้แย้ง แต่พอคิดอีกทีก็เห็นด้วยกับข้อสรุป เพียงแต่เหตุผลต่างกันนิดหน่อย
      โดยพื้นฐานแล้วเว็บเป็น สภาพแวดล้อมที่เป็นปฏิปักษ์ และคนที่ดูแลเว็บไซต์จำนวนมากก็มองได้ว่าเป็นผู้ไม่หวังดีเสียเอง การทำให้สิ่งที่คนเห็นกับสิ่งที่เอเจนต์เห็นต่างกันเป็นสิ่งที่เว็บจะตั้งใจใช้ เหมือนที่เคยทำกับเสิร์ชเอนจิน
      เหตุผลที่ "Agent Readiness" น่าจะไปไม่รอดคือ ผู้ดูแลเว็บจะนึกออกในไม่ช้าว่าเอเจนต์ก็คือ การทำให้การเข้าถึงเป็นอัตโนมัติ นั่นเอง ซึ่งเป็นสิ่งที่พวกเขาสู้มาตลอดและเป็นภัยต่อความสามารถในการหารายได้
    • พอเห็นว่าเว็บไซต์บวมและเต็มไปด้วยโฆษณาขนาดนี้ ก็รู้สึกว่าแม้แต่สำหรับคนก็น่าจะมี เวอร์ชันข้อความล้วน ได้แล้ว อยากให้เอเจนต์เป็นฝ่ายจัดการความซับซ้อนที่ทำไว้สำหรับคน
      แต่ก็สงสัยว่าจะเกิดขึ้นจริงไหม ปัญหาผู้ไม่หวังดีนั้นเป็นไปได้มานานแล้ว เช่นให้คอนเทนต์กับ crawler ของเสิร์ชเอนจินไม่เหมือนกับสิ่งที่ผู้ใช้เห็นหลังคลิก ถ้าจำไม่ผิดเหมือน Google เคยลงโทษเว็บแบบนี้อยู่ช่วงหนึ่ง
    • ไอเดียโดยรวมของเว็บนี้โอเค แต่ถ้าไม่ชอบคำพูดเพ้อเจ้อเรื่อง AI/บล็อกเชน checklist แบบนี้ก็มีอยู่ทั่วไป อันที่ชอบที่สุดมาหลายปีก็คืออันนี้
      https://frontendchecklist.io/rules
    • Agent readiness ดูเป็นขั้นตอนที่มีประโยชน์เต็ม ๆ บนเว็บไซต์ของผม คนไม่ได้ใช้บล็อกเชนแต่ใช้ AI และ AI ก็ไม่จำเป็นต้องใช้เว็บไซต์แบบเดียวกับคน
      คนต้องการเว็บที่ดูดี ซึ่งทำได้แม้ด้วย HTML ล้วน เอเจนต์ไม่ต้องการแม้แต่ระดับนั้น และในอุดมคติแค่เห็นเนื้อหาหน้าเป็น Markdown ก็พอ
      แล้วทำไมจะไม่มีเวอร์ชันสำหรับเอเจนต์ล่ะ? มันช่วยประหยัดเวลาและเงินทั้งของ client agent และโฮสต์เว็บไซต์
      ถ้ามีมาตรฐานอย่าง llms.txt ที่ระบุได้ว่า "เอเจนต์ควรไปเยี่ยมชม mirror นี้แทน ซึ่งเป็นเวอร์ชัน Markdown ดิบของสิ่งที่มนุษย์เห็น" ก็คงดี
      ความพร้อมสำหรับเอเจนต์บางส่วนของเว็บนี้ก็คือ SEO สำหรับ AI และในทางกลับกัน ถ้าเว็บไหนไม่ต้องการให้ AI crawl ก็ใช้ทำสิ่งตรงข้ามได้ด้วย

  • น่าจะมี แนวปฏิบัติที่ดี สำหรับส่วนอย่างฟอร์มล็อกอิน เช่น ใช้ชื่อฟิลด์มาตรฐานที่ตัวจัดการรหัสผ่านรู้จัก ปิด autocomplete และการเปลี่ยนอักษรตัวแรกเป็นตัวพิมพ์ใหญ่โดยอัตโนมัติสำหรับช่องล็อกอิน ใช้ HTML5 input type ที่ถูกต้องถ้าเป็นอีเมล หลีกเลี่ยงฟอร์มที่ให้กรอกแค่อีเมลก่อนแล้วต้องคลิกอีกครั้งเพื่อกรอกรหัสผ่าน และทำตาม NIST SP 800-53 โดยเลี่ยง 2FA ผ่าน SMS หรือข้อบังคับเปลี่ยนรหัสผ่านเป็นระยะ/กฎการผสมรหัสผ่านแบบสุ่ม เป็นต้น
    มีเว็บไซต์มากเกินไปด้วยที่ไม่ตั้งโฟกัสอัตโนมัติให้กับฟอร์มที่มีช่องกรอกเพียงช่องเดียว

    • การอ่าน แนวปฏิบัติที่ดี เรื่องฟอร์มในบล็อกของ Adam Silver สนุกกว่าที่คิดมาก
      https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
      หลังจากนั้นเขาก็เขียนเพิ่มอีกเยอะ และมันอาจเป็นหนึ่งในแหล่งข้อมูล UX บนเว็บที่ดีที่สุด
    • การให้ส่งแค่อีเมลล็อกอินก่อนใส่รหัสผ่านนั้น สำหรับระบบยืนยันตัวตนที่ไม่ใช่แบบง่าย ๆ แล้ว ถือว่าแทบจำเป็นเลย
      ก่อนจะรับชื่อผู้ใช้เข้ามา คุณไม่มีทางรู้ได้ว่าผู้ใช้นั้นใช้รหัสผ่านหรือใช้วิธีอื่น
    • ใช้ frontendchecklist มาหลายปีแล้ว และมันก็มีชุดกฎกับแนวปฏิบัติที่ดีแบบนี้อยู่ น่าเสียดายที่ช่วงหลังเหมือนเว็บจะหันไปรับเอา ai-readiness มากขึ้น แต่กฎต่าง ๆ ก็ยังอยู่
      https://frontendchecklist.io/rules/html/input-types
      เวลาจะสร้าง UI component ตั้งแต่ต้น ชอบเว็บนี้มากจริง ๆ
      https://component.gallery/
      มันลิงก์ไปยังคอมโพเนนต์จากหลาย design system ซึ่งหลายอันก็ครอบคลุมแนวทางอย่าง accessibility และ internationalization ไว้อย่างลึกซึ้งด้วย ตัวอย่างที่เอกสารดีเป็นพิเศษคือ Lightning Design System ของ Salesforce และ Stacks ของ StackOverflow
      https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
      https://stackoverflow.design/system/forms/checkbox
    • การไม่ตั้งโฟกัสอัตโนมัติให้ฟอร์มที่มีช่องกรอกเดียว เป็นตัวอย่างของการที่ เว็บสแตก คาดหวังให้แต่ละเว็บไซต์ไปลงมือทำสิ่งที่ใน native UI toolkit เคยเป็นค่าเริ่มต้นกันเอง
      ผลคือเว็บไซต์ส่วนใหญ่ไม่มองว่าสิ่งนี้สำคัญ หรือไม่รู้ด้วยซ้ำว่าควรต้องทำ สุดท้ายเลยออกมาเป็นสภาพแบบทุกวันนี้
    • ฟอร์มล็อกอินที่ให้กรอกแค่อีเมลก่อนดูเหมือนจะเพิ่มขึ้น โดยเฉพาะในเว็บของบริษัทยักษ์ใหญ่สายเทค ซึ่งส่วนตัวก็รำคาญเหมือนกัน
      ผมเลยคิดมาตลอดว่าต้องมีเหตุผลที่เว็บต่าง ๆ เปลี่ยนมาใช้แพตเทิร์นนี้ เช่น อาจช่วยเรื่องป้องกันบอตได้ดีกว่า อยากรู้เหมือนกันว่ามีใครรู้มากกว่านี้ไหม

  • ดูเผินๆ แล้วแทบทั้งหมดเหมือนเป็น สิ่งที่ AI สร้างขึ้น เลย ทำให้วิธีการสื่อสารอาจไม่ได้ผลนัก แต่ถ้าอ่านหลายๆ หัวข้อแล้ว นอกจากส่วน Agent ที่เหลือก็สื่อเรื่องสุขอนามัยของเว็บที่แข็งแรงได้ค่อนข้างชัดเจน เลยคิดว่าส่งต่อให้เว็บดีเวลอปเปอร์ที่เพิ่งเริ่มเติบโตก็ยังพอได้
    แต่ตัวเว็บเองกลับไม่ทำตามแนวปฏิบัติที่ตัวเองบอกว่าเป็น "ข้อบังคับ" เสียด้วยซ้ำ ตรงนี้ก็น่าขันดี

    • บอกว่า "Compression (gzip, brotli, zstd): required" กับ "cache-control: required" นี่มัน เศษขยะ AI ตั้งแต่ต้นจนจบเลย

  • https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
    ผมไม่เข้าใจเป้าหมายของเว็บไซต์นี้เลย อวดอ้างว่าเป็นสเปก แต่ไม่รู้ว่าสุดท้ายแล้วกำลังสเปกอะไรอยู่กันแน่
    ทุกหัวข้ออ้างอิง "แหล่งความจริง" อื่นทั้งหมด

    • มันเป็นชุดรวม แนวปฏิบัติที่ดี และก็มีคุณค่าในฐานะเช็กลิสต์ที่ดูได้จากที่เดียว
    • ผมเห็นโพสต์นี้บน LinkedIn[1] และผู้เขียนเขียนไว้แบบนี้
      "ผมเหนื่อยกับการต้องอ้างอิงแหล่งข้อมูลหกแห่งเพื่อรองรับคำแนะนำเพียงข้อเดียว HTML มาจาก WHATWG, accessibility มาจาก WCAG, headers มาจาก IETF, structured data มาจาก schema.org, ที่เหลือมาจาก MDN, web.dev และ Google Search Central
      มันไม่มีสเปกเดียวที่เป็นหนึ่งเดียว มีจุดยืนชัดเจน และเป็นกลางต่อแพลตฟอร์ม ว่าเว็บไซต์สมัยใหม่ควรทำอะไรจริงๆ
      เลยเขียนมันขึ้นมาเอง"
      [1] https://www.linkedin.com/posts/jdevalk_the-website-specifica...

  • ผมสงสัยว่าสิ่งต่างๆ ในนี้มันพบได้บ่อยแค่ไหน /.well-known/change-password มีไว้ก็ดี แต่พอดู https://news.ycombinator.com/.well-known/change-password กับ google.com/.well-known/change-password แล้วดูเหมือนจะไม่ได้ทำไว้

    • ดูเหมือนว่าใช้งานได้ใน Safari และ Chrome: https://web.dev/articles/change-password-url
      ไม่เคยได้ยินว่ามีการใช้งานจริง
      URL ของ Google อยู่ที่ https://accounts.google.com/.well-known/change-password และไม่ได้อยู่บนโดเมนหลัก
    • ถ้ามี security.txt ก็จะอยู่ใต้โฟลเดอร์นี้เสมอ Let's Encrypt ก็ใช้ตำแหน่งนี้สำหรับเรื่องใบรับรองหรือความล้มเหลวของการต่ออายุด้วย

  • นี่ดูเหมือนออกมาจาก โรงงานผลิตขยะ เลย คำว่า "SEO" กับ "Agent-readiness" เนี่ย มันคือสิ่งที่เว็บไซต์ที่ดีไม่ควรทำเลย
    แล้วก็ไม่ผิดคาด มันถูกทำโดยผู้เชี่ยวชาญ Wordpress ด้าน "SEO" ที่ใช้ Claude LLM และเป็นนักลงทุนรายย่อย คนที่สะสมความมั่งคั่งจากการพังอินเทอร์เน็ตที่เราเคยรักด้วยขยะโฆษณา ตอนนี้กำลังจะมาพังเศษที่เหลือด้วยขยะ LLM อีก

    • จากขีดยาวและรูปแบบประโยค เช่นการใช้สำนวน "ไม่ใช่ X แต่เป็น Y" รวมถึงเนื้อหาซ้ำๆ สำหรับผมมันแทบจะฟ้องว่าเป็น AI สร้าง
      การจัด "stable URLs" ไปอยู่หมวด "agent readiness" ดูเป็นสัญญาณว่าผู้เขียนสนใจ AI มากกว่ามนุษย์ ผมจะใส่โดเมนนี้ลงในบล็อกลิสต์ เพราะเห็นได้แล้วว่ามันจะทำให้การค้นหาข้อมูลเว็บดีเวลอปเมนต์แย่ลง
    • หน้า about (https://specification.website/about/) เขียนไว้แบบนี้
      "มันไม่ใช่ framework ไม่ใช่ guide แต่มันคือ specification — ว่าอะไรจำเป็น อะไรแนะนำ และอะไรควรหลีกเลี่ยง"
      ยากจะบอกว่าส่วนไหนของเว็บนี้เป็นขยะ LLM มากน้อยแค่ไหน แต่บางถ้อยคำก็ดูเป็นแบบนั้นแน่นอน
    • ดูเป็น ขยะ AI ล้วนๆ ผมใช้ https://tropes.fyi/vetter
    • สเปกแบบทั้งหน้าเดียวเต็มๆ เป็นเหมือนโปสเตอร์ตัวแทนของ เว็บดีเวลอปเมนต์ขยะ AI ยุคนี้เลย
      https://specification.website/llms-full.txt
    • สำหรับผมก็มีสัญญาณขยะดังขึ้นเหมือนกัน
      อย่างแรกคือป้ายสีเล็กๆ อย่าง required, optional, recommended
      อย่างที่สองคือคอนเทนต์ยาวบ้าคลั่งที่ไม่มีใครอ่าน
      อย่างที่สามคือการขยายไอเดียที่อ่อนมากให้ละเอียดจนน่าเจ็บปวด

  • ผมเองก็เคยคิดจะทำอะไรแบบนี้ แต่พอเอามันไปวางในแชตเอเจนต์อะไรก็ได้ มันกลับทำงานได้ดีมาก
    เมื่อกี้ผมใช้โมเดลโลคัล (Qwen3.6 27B / pi) ให้ทำรายการมาตรฐานสำคัญที่ขาดไปในเว็บไซต์ Hugo เก่าๆ ของผม แล้วทำรายการงานที่ต้องทำ จากนั้นก็ให้จัดการทีละอย่าง โดยแต่ละการเปลี่ยนแปลงผมตรวจทานได้
    มันยังทำ favicon ที่หายไปให้ด้วย โดยตัดสัญลักษณ์ออกจากโลโก้มาใช้ ซึ่งออกมาค่อนข้างดี

    • อยากรู้ว่าคุณลองเล่น pi ไปมากแค่ไหนแล้ว ความรู้สึกแบบ ไร้ภาระ ของ agent/system prompt สั้นๆ นั้นดีอยู่ แต่ถ้าปล่อยให้มันทำงานสุ่มๆ เอง ผมเดาว่าคงมีทั้งการรอและการตันอยู่พอสมควร

  • ผมเปิดไซต์นี้บน MacBook แล้ว การใช้ CPU ทะลุ 50%
    พอนึกว่าเว็บนี้เป็นสเปกว่าด้วยเรื่องเว็บไซต์ควรเป็นอย่างไร มันก็ยิ่งชวนขำ

    • ที่นี่ไม่เห็นอาการเดียวกันนะ น่าจะดีถ้าลองดูว่าเกิดอะไรขึ้นฝั่งผู้ใช้

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

  • สเปกที่ผมชอบที่สุดคือ สเปกที่หลอนขึ้นมาเอง นี่แหละ ควรบอกว่าทำได้ดีไหมนะ
    เริ่มตั้งตารอ ISO ทางเลือกที่ขับเคลื่อนด้วยเอเจนต์ หรือสล็อตแมชชีนที่ควบคุมโดย LLM แล้ว