The Website Specification

 (specification.website)
4 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • एक अच्छे वेबसाइट में होने वाली तकनीकी क्षमताओं को platform-agnostic तरीके से व्यवस्थित करने वाला specification, जो <title> से llms.txt तक को कवर करता है
  • यह इंसानों और agents दोनों के लिए है, और WHATWG, W3C, IETF RFCs, WCAG, MDN जैसे आधुनिक वेब standards को reference करता है
  • WordPress, Next.js, Django app, pure HTML आदि किसी भी deployment तरीके से अलग, specification खुद समान रहती है, और इसमें implementation hints भी शामिल हैं
  • पूरा विषय Foundations, SEO, Accessibility, Security, Performance आदि 10 क्षेत्रों में बंटा है और व्यापक रूप से स्वीकृत standards से mapped है
  • सार्वजनिक MCP server, Agent Skill, /llms.txt, और Markdown responses उपलब्ध हैं, ताकि agents और operators audit, learning, और improvement workflow में उनका उपयोग कर सकें

अच्छे वेबसाइट के लिए platform-independent specification

  • The Website Specification एक अच्छे वेबसाइट में होने वाली तकनीकी क्षमताओं को platform-agnostic तरीके से व्यवस्थित करने वाला specification है, जो <title> से /.well-known/security.txt, WCAG contrast, llms.txt तक को कवर करता है
  • यह इंसानों और agents दोनों के लिए है, और हर विषय WHATWG, W3C, IETF RFCs, WCAG, MDN जैसे आधुनिक वेब standards के स्रोतों से जुड़ा है
  • WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, Django app, pure HTML आदि किसी भी तरीके से deploy करें, specification खुद समान रहती है, और implementation hints उसके बाद दिए गए हैं
  • हर पेज पर Edit on GitHub लिंक है, PR स्वीकार किए जा सकते हैं, और हर पेज पर sources दिखाए गए हैं

  • कवर किए गए क्षेत्र

    • पूरा विषय व्यापक रूप से स्वीकृत standards से mapped 10 क्षेत्रों में बंटा है
    • Foundations: 14 items में HTML, head, document के बुनियादी तत्व शामिल हैं
    • SEO: 13 items में robots.txt, sitemap, canonical, structured data जैसे search visibility elements शामिल हैं
    • Accessibility: 20 items में सभी क्षमताओं वाले users के लिए साइट उपयोग योग्य बनाने हेतु WCAG-आधारित rules दिए गए हैं
    • Security: 12 items में visitors की सुरक्षित सुरक्षा के लिए headers, transport, policies शामिल हैं
    • Well-Known URIs: 9 items में /.well-known/ के तहत standard agreement paths व्यवस्थित किए गए हैं
    • Agent Readiness: 18 items में वे तत्व शामिल हैं जो AI agents और crawlers को साइट पढ़ने योग्य बनाते हैं
    • Performance: 19 items में Core Web Vitals, caching, images, fonts, network behavior शामिल हैं
    • Privacy: 6 items में consent, signals, और visitor choices के सम्मान को शामिल किया गया है
    • Resilience: 5 items में error pages, offline, redirects जैसी graceful failure स्थितियाँ शामिल हैं
    • Internationalisation: 12 items में language, locale, direction, translated content शामिल हैं

agents और site operators के लिए उपयोग का तरीका

  • पूरा specification read-only, बिना authentication वाले सार्वजनिक MCP server के रूप में उपलब्ध है
  • एक Agent Skill प्रकाशित है, जो compatible agents को बताता है कि specification का कब और कैसे उपयोग करना है
  • हर specification URL, /llms.txt और Accept: text/markdown के माध्यम से per-page Markdown प्रदान करता है
  • MCP server configuration example इस प्रकार है
{  
  "mcpServers": {  
    "specification-website": {  
      "transport": "http",  
      "url": "https://mcp.specification.website/mcp";  
    }  
  }  
}

  • उपयोग workflow

    • Audit: checklist को देखते हुए हर item को “क्या साइट यह करती है — हाँ/नहीं” के रूप में जांचें
    • Learn: हर item में देखें कि यह क्या है, यह क्यों महत्वपूर्ण है, और इसे कैसे implement किया जाए
    • Improve: यदि कोई कमी, पुराना तथ्य, या छूटा हुआ विषय मिले, तो source जोड़कर PR खोला जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • Agent Readiness ऐसी चीज़ लगती है जो समय बीतने पर "Web 4.0 Blockchain Integration" की तरह शर्मनाक लग सकती है
    ऐसा इसलिए नहीं कि agent महत्वहीन हो जाएंगे, बल्कि इसलिए कि अगर वे महत्वपूर्ण भी हो जाएँ, तब भी अगर किसी साइट को agents के लिए अलग exception handling करनी पड़े, तो यह उसके मूल उद्देश्य को ही नुकसान पहुँचाता है
    आखिरकार इसका इस्तेमाल बुरे actor इस तरह करेंगे कि agent को कुछ और दिखे और इंसान को कुछ और, और इसी वजह से लगता है कि इसे जानबूझकर नज़रअंदाज़ किया जाएगा

    • मैं 2000s में लौटना चाहता हूँ। उस समय baseline बस pure HTML और थोड़ी-सी CSS थी, और browser की default stylesheet से ही responsive के काफ़ी करीब layout, पढ़ने में आसान text, और user-friendly GUI मिल जाता था
      आजकल websites पर हर चीज़ एक component है। सीमित सूची वाले एक साधारण dropdown में भी अपना loader होता है और बिना किसी वजह के 10 fetch requests चली जाती हैं। यह बढ़ा-चढ़ाकर नहीं कह रहा, Instagram और Facebook का web देख लीजिए
      इन सारी specifications को छोड़िए, और बस मुझे original HTML दीजिए जो React जैसी चीज़ों से obfuscate न की गई हो, जो हर नए JS framework को game changer बताती रहती हैं
    • पहले मैं इसका विरोध करने वाला था, लेकिन थोड़ा और सोचने पर निष्कर्ष से सहमत हूँ। बस मेरी वजह थोड़ी अलग है
      web मूल रूप से एक hostile environment है, और websites चलाने वालों में काफ़ी लोगों को मैं खुद malicious actor मानता हूँ। websites जानबूझकर agent को इंसान से अलग चीज़ दिखाएँगी, जैसे वे search engines के साथ करती रही हैं
      "Agent Readiness" के ज़्यादा समय तक न टिकने की वजह यह होगी कि site operators जल्दी ही समझ जाएँगे कि agent असल में access automation हैं। और यह वही चीज़ है जिससे वे हमेशा लड़ते आए हैं, क्योंकि यह उनकी monetization क्षमता को ख़तरे में डालती है
    • websites को इतना bloated और ads से भरा हुआ देखकर लगता है कि इंसानों के लिए भी एक pure text version होना चाहिए। मैं चाहूँगा कि agents इंसानों वाले जटिल version को संभालें
      लेकिन वास्तव में ऐसा होगा, इस पर शक है। malicious actor वाली समस्या तो बहुत पहले से संभव थी। उदाहरण के लिए search engine crawlers को वह content देना जो user click करने के बाद दिखने वाली चीज़ से अलग हो। अगर मुझे सही याद है, तो एक समय Google ऐसी sites को penalty भी देता था
    • साइट की overall idea ठीक है, लेकिन अगर आपको AI/blockchain वाला बकवास हिस्सा पसंद नहीं है, तो इस तरह की checklist काफ़ी आम है। पिछले कुछ सालों से मेरी पसंदीदा यह रही है
      https://frontendchecklist.io/rules
    • Agent readiness पूरी तरह उपयोगी कदम लगता है। मेरी website पर लोग blockchain इस्तेमाल नहीं करते, लेकिन AI करते हैं, और AI को website इंसान की तरह इस्तेमाल करने की ज़रूरत नहीं है
      इंसान एक अच्छी दिखने वाली website चाहते हैं, और वह pure HTML से भी संभव है। agents को वह भी नहीं चाहिए; आदर्श रूप से उनके लिए page की content सिर्फ Markdown में दिख जाए तो काफ़ी है
      agent version क्यों नहीं होना चाहिए? इससे client agents और website host, दोनों का समय और पैसा बचेगा
      llms.txt जैसे किसी standard से यह बताना अच्छा होगा कि "agents इस mirror पर जाएँ, जो इंसानों को दिखने वाली चीज़ का raw Markdown version है"
      इस साइट की agent readiness का कुछ हिस्सा AI के लिए SEO जैसा है। और उलटे, जो sites AI crawling नहीं चाहतीं, उनके लिए यह उसका उलटा काम भी कर सकता है

  • login form जैसी जगहों के लिए best practices होना अच्छा होगा। जैसे password manager द्वारा पहचाने जाने वाले standard input field names का इस्तेमाल, login fields में autocomplete और automatic capitalization बंद करना, email के लिए सही HTML5 input type इस्तेमाल करना, ऐसे forms से बचना जहाँ पहले सिर्फ email भरवाया जाए और फिर दोबारा click करके password भरना पड़े, और NIST SP 800-53 का पालन करते हुए SMS two-factor authentication या मनमाने periodic password changes और composition rules से बचना
    सिर्फ एक input वाले form में भी auto focus न देने वाली sites बहुत ज़्यादा हैं

    • Adam Silver के blog पर form best practices पढ़ना काफ़ी दिलचस्प लगा था
      https://adamsilver.io/blog/form-design-from-zero-to-hero-all...
      उसके बाद भी उन्होंने बहुत-सी नई posts डाली हैं, और यह web पर सबसे अच्छे UX resources में से एक हो सकता है
    • password डालने से पहले login email submit करवाना, अगर auth system थोड़ा भी non-trivial है, तो वास्तव में लगभग ज़रूरी होता है
      user submit होने से पहले यह पता नहीं चल सकता कि वह password इस्तेमाल करता है या कोई और तरीका
    • मैं कई सालों से frontendchecklist इस्तेमाल कर रहा हूँ, और इसमें इसी तरह के rules और best practices के collection हैं। अफ़सोस है कि हाल में साइट शायद ai-readiness को अपनाने की दिशा में बदल गई है, लेकिन rules अभी भी मौजूद हैं
      https://frontendchecklist.io/rules/html/input-types
      जब भी शुरुआत से UI components बनाने होते हैं, मुझे यह साइट बहुत पसंद है
      https://component.gallery/
      यह कई design systems के components से जोड़ती है, और उनमें से कई accessibility, internationalization जैसी guidelines को भी गहराई से शामिल करते हैं। documentation के ख़ास तौर पर अच्छे उदाहरण Salesforce का Lightning Design System और StackOverflow का Stacks हैं
      https://www.lightningdesignsystem.com/2e1ef8501/p/99642e-car...
      https://stackoverflow.design/system/forms/checkbox
    • सिर्फ एक input वाले form में auto focus न देना, इस बात का उदाहरण है कि web stack ऐसी सुविधाओं को, जो native UI toolkits में default हुआ करती थीं, हर website से खुद implement करने की उम्मीद करता है
      फिर ज़्यादातर websites इसे priority नहीं मानतीं, या यह भी नहीं जानतीं कि इसे सोचना चाहिए, और नतीजा वही होता है जो आज दिखता है
    • ऐसे login forms जहाँ पहले सिर्फ email डालना पड़ता है, ख़ासकर बड़ी tech companies की sites पर बढ़ते हुए लगते हैं। मुझे व्यक्तिगत रूप से भी यह परेशान करता है
      मुझे हमेशा लगा कि sites के इस pattern पर जाने के पीछे कोई वजह होगी, जैसे bot defense में यह बेहतर हो। जानना चाहूँगा कि क्या किसी को इसके बारे में और पता है

  • ऊपर-ऊपर से देखने पर यह लगभग पूरी तरह AI-जनित सामग्री जैसा लगता है, इसलिए इसकी प्रस्तुति शायद असरदार न हो। फिर भी कई बिंदु पढ़ने पर, Agent सेक्शन को छोड़कर बाकी हिस्सा काफ़ी स्पष्ट तरीके से मज़बूत web hygiene बताता है, इसलिए मुझे लगता है कि इसे अभी आगे बढ़ रहे web developers को भेजना ठीक रहेगा।
    लेकिन यह विडंबना है कि साइट खुद उन प्रथाओं को भी लागू नहीं करती जिन्हें उसने "ज़रूरी" कहा है।

    • "Compression (gzip, brotli, zstd): required" और "cache-control: required" — यह शुरू से अंत तक AI कचरा है

  • https://validator.w3.org/nu/?doc=https%3A%2F%2Fspecification...
    मुझे समझ नहीं आता कि इस वेबसाइट का लक्ष्य क्या है। इसे specification कहकर प्रचारित किया गया है, लेकिन यह आखिर किस चीज़ की specification है, यह स्पष्ट नहीं है।
    हर बिंदु किसी और "source of truth" को स्रोत मान रहा है।

    • यह best practices का संग्रह है, और एक ही जगह देखने लायक checklist के रूप में इसकी कुछ कीमत है
    • मैंने इसे LinkedIn[1] पर देखा था, जहाँ लेखक ने यह लिखा था
      "मैं एक ही recommendation को सहारा देने के लिए छह अलग-अलग sources दिखाते-दिखाते थक गया था। HTML के लिए WHATWG, accessibility के लिए WCAG, headers के लिए IETF, structured data के लिए schema.org, और बाकी के लिए MDN, web.dev, Google Search Central थे।
      आधुनिक वेबसाइटों को वास्तव में क्या करना चाहिए, इस पर कोई एकल, स्पष्ट राय वाला, और platform-neutral specification मौजूद नहीं था।
      इसलिए मैंने एक लिख दिया।"
      [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
      मैंने इसे व्यवहार में इस्तेमाल होते कभी नहीं सुना।
      Google का URL https://accounts.google.com/.well-known/change-password पर है, मुख्य domain पर नहीं।
    • security.txt अगर होता है तो हमेशा इसी फ़ोल्डर के अंतर्गत होता है। Let's Encrypt भी certificate या renewal failure जैसी चीज़ों के लिए इसी स्थान का उपयोग करता है

  • यह कचरा फ़ैक्टरी से निकली चीज़ लगती है। "SEO", "Agent-readiness" — यह वही चीज़ें हैं जो एक अच्छी वेबसाइट को नहीं करनी चाहिए।
    जैसा कि उम्मीद थी, इसे Claude LLM इस्तेमाल करने वाले Wordpress "SEO" विशेषज्ञ और निजी निवेशक ने बनाया है। विज्ञापन कचरे से उस इंटरनेट को बर्बाद करके धन कमाने वाला व्यक्ति, जिसे हम प्यार करते थे, अब LLM कचरे से जो थोड़ा बचा है उसे भी बर्बाद करने चला है।

    • लंबी dash, वाक्य पैटर्न जैसे "X नहीं, Y" और दोहराव वाली सामग्री मेरे लिए इसे लगभग AI-जनित साबित कर देती है।
      "stable URLs" को "agent readiness" के तहत रखना इस बात का संकेत लगता है कि लेखक इंसानों से ज़्यादा AI की परवाह करता है। मैं इस domain को block list में डालूँगा। यह पहले से साफ़ दिख रहा है कि यह web development जानकारी खोजने का काम और खराब करेगा।
    • about page(https://specification.website/about/) में यह लिखा है
      "यह framework नहीं है। यह guide नहीं है। यह specification है — क्या अनिवार्य है, क्या अनुशंसित है, और किससे बचना चाहिए।"
      साइट का कितना हिस्सा LLM कचरा है, यह कहना मुश्किल है, लेकिन कुछ वाक्यांश निश्चित रूप से वैसे लगते हैं
    • यह पूरी तरह AI कचरा जैसा लगता है। मैं https://tropes.fyi/vetter इस्तेमाल करता हूँ
    • पूरा single-page specification आजकल के AI कचरा web development का पोस्टर-चाइल्ड लगता है
      https://specification.website/llms-full.txt
    • मुझे भी कचरे के संकेत साफ़ दिखते हैं।
      पहला, required, optional, recommended जैसे छोटे रंगीन टैग।
      दूसरा, पागलपन भरी मात्रा में ऐसा content जिसे कोई पढ़ेगा नहीं।
      तीसरा, कमज़ोर विचारों को पीड़ादायक स्तर तक बारीकी से ठेलते हुए आगे बढ़ाने का तरीका

  • मैं खुद ऐसा कुछ बनाने की सोच रहा था, लेकिन इसे किसी भी agent chat में paste करने पर यह बेहद अच्छा काम करता है।
    अभी-अभी मैंने local model(Qwen3.6 27B / pi) से एक पुराने Hugo site में छूटे हुए ज़रूरी standards की सूची बनवाई, फिर todo list बनवाई, और उसके बाद उन्हें एक-एक करके पूरा करवाया, जबकि हर बदलाव मुझे review के लिए दिखाया गया।
    उसने missing favicon भी logo से symbol काटकर बना दिया, और नतीजा काफ़ी अच्छा निकला।

    • जानना चाहूँगा कि आपने pi के साथ कितना काम किया है। छोटे agent/system prompt का low-overhead एहसास अच्छा है, लेकिन अगर इसे कोई मनमाना काम बस थमा दिया जाए, तो लगता है इसमें इंतज़ार और dead ends काफ़ी आ सकते हैं

  • मैंने MacBook पर साइट खोली तो CPU usage 50% से ऊपर चला गया।
    यह देखते हुए कि यह वेबसाइट इस बारे में specification होने का दावा करती है कि वेबसाइट कैसी होनी चाहिए, यह काफ़ी विडंबनापूर्ण है।

    • मुझे यहाँ वही व्यवहार नहीं दिख रहा। यह देखना अच्छा रहेगा कि आपकी तरफ़ क्या हो रहा है

  • कुछ सामग्री काफ़ी अच्छी है, लेकिन उम्मीद है कि इसे 128-आइटम checklist में बदल देने से लोग वेबसाइट बनाना डरावना काम न समझने लगें

  • मेरी पसंदीदा specification तो hallucinated specification है। पता नहीं इसे बधाई देनी चाहिए या नहीं।
    agent-चालित ISO विकल्प या LLM द्वारा चलाए जाने वाले slot machine का इंतज़ार अभी से है