ब्राउज़र टूल कैटलॉग को मशीन-पठनीय खोज अनुबंध चाहिए, केवल HTML पृष्ठ नहीं
स्थिर ब्राउज़र-आधारित उपयोगिता साइटें अक्सर सैकड़ों छोटे टूल दिखाकर परिपक्व लगती हैं, लेकिन मानव-पठनीय पृष्ठ अपने-आप यह नहीं बताते कि खोज इंजन, स्थानीयकृत पाठक, या LLM एजेंट सही टूल कैसे पाएंगे और उसकी सीमा कैसे समझेंगे। यह अध्ययन alexandrai-tools workspace को एक केस के रूप में पढ़ता है और आधिकारिक वेब, Schema.org, Google Search Central, Astro, RFC 9309, sitemaps और llms.txt स्रोतों से तुलना करता है। वर्तमान checkout में 249 tool folders, 249 tool-local tests, 249 i18n files, 249 Body.astro files, और 251 passing Vitest test files मिले। मुख्य योगदान Machine-Readable Discovery Accountability Chain है: human page, canonical URL, sitemap inventory, localized alternates, structured data, LLM index, client-side execution boundary, और verification gate को अलग-अलग evidence states माना जाता है। निष्कर्ष यह है कि tool catalog को केवल HTML pages या sitemap से नहीं, बल्कि सबसे कमजोर प्रमाणित discovery stage से रिपोर्ट करना चाहिए।
परिचय
एक static browser-tool catalog उपयोगकर्ता को सरल पृष्ठ देता है: calculator, converter, formatter या generator खोलिए और ब्राउज़र में काम कीजिए। लेकिन discovery की समस्या इससे अलग है। Search crawler को URL inventory, canonical signal, structured data और localized alternates चाहिए; LLM agent को यह समझना पड़ता है कि URL fetch करने पर computed result नहीं बल्कि application HTML मिलेगा; और मानव उपयोगकर्ता को private client-side boundary दिखाई देनी चाहिए [[cite:googleSitemaps,googleCanonical,googleStructured,llmsRoute]].
Discovery को एक consumer-neutral शब्द मानना भ्रम पैदा करता है। Human navigation link equity और page hierarchy पर निर्भर हो सकती है; search engine sitemap और canonical hints पढ़ता है; rich-result system visible content और structured entity alignment देखता है; locale-aware search hreflang graph पर निर्भर हो सकता है; और LLM agent compressed task index चाहता है। इन consumers की जरूरतें overlap करती हैं, पर वे interchangeable नहीं हैं [[cite:sitemapsProtocol,googleSitemaps,googleHreflang,googleStructured,llmsTxt]].
alexandrai-tools इस समस्या का उपयोगी case है। README इसे fast, free, no-signup static Astro tools site बताता है; package metadata Astro, sitemap integration और Vitest को दिखाता है; registry हर tool की metadata को folder modules से auto-discover करती है; dynamic routes Body.astro और i18n modules से pages बनाते हैं [[cite:readme,packageJson,toolsRegistry,englishRoute,localizedRoute]]. इस architecture में discovery एक single feature नहीं है, बल्कि कई independent records का संयोजन है.
पूर्व AlexandrAI paper ने इसी repository पर यह दिखाया था कि static utility sites को tool counts के बजाय pure-logic accountability चाहिए [[cite:alexPureLogic]]. यह paper उस निष्कर्ष को दोहराता नहीं है। यहाँ research question है: static browser-tool catalog को search engines और LLM agents के लिए discovery कैसे प्रमाणित करनी चाहिए, जब visible HTML, structured metadata और client-side execution अलग-अलग states हैं? योगदान Machine-Readable Discovery Accountability Chain है, जो discovery को staged evidence problem बनाता है.
विधि
Study mode workspace-grounded conceptual synthesis है। मैंने repository documentation, package scripts, registry, dynamic routes, head component, SEO helpers, i18n shell, ToolChrome, llms.txt route, और वर्तमान test output पढ़ा। फिर official external sources से mapping बनाई: Astro dynamic routing और i18n, llms.txt proposal, RFC 9309, Sitemaps protocol, Google sitemap/hreflang/structured-data/canonical guidance, और Schema.org types [[cite:astroRouting,astroI18n,llmsTxt,rfc9309,sitemapsProtocol,googleSitemaps,googleHreflang,googleStructured,googleCanonical,schemaSoftware,schemaBreadcrumb,schemaFAQ]].
Local inventory reproducible command evidence से लिया गया: current snapshot में 249 tool directories, 249 tool-local index.test.ts files, 249 tool-local i18n.ts files, और 249 Body.astro files मिले। उसी checkout में npm test ने 251 test files और 2184 tests पास किए [[cite:testRun]]. ये numbers discovery success नहीं मापते; वे case artifact की वर्तमान breadth और verification denominator को anchor करते हैं.
Inclusion criteria conservative रखे गए। Workspace source तभी final reference बना जब वह discovery chain का कोई implemented layer दिखाता था: registry, route, head metadata, structured-data helper, locale helper, agent note या llms.txt route। External source तभी retained हुआ जब वह primary documentation, standard, official search guidance या schema reference था। Blog commentary, market pages, older count registers और duplicate agent guides screened रहे लेकिन final evidence base में नहीं आए, ताकि paper tool promotion या SEO folklore में न बदल जाए.
Synthesis procedure में हर discovery record को उसके consumer और failure mode से जोड़ा गया। Human page का consumer व्यक्ति है; sitemap का consumer crawler है; hreflang localized search selection में मदद करता है; JSON-LD entity extraction को support करता है; llms.txt और in-page comments agent orientation देते हैं; और tests/build gates drift को पकड़ते हैं। Claim ledger में factual claims को source ids या computation ids से बांधा गया, और inference claims को explicit reasoning notes दिए गए [[cite:alexClaimEdge]].
केस आर्टिफैक्ट: alexandrai-tools discovery surface
Repository का मूल contract tool metadata से शुरू होता है। src/lib/tools.ts हर src/tools/*/index.ts module से meta पढ़ता है, फिर tools को title के आधार पर sort करता है और categories derive करता है [[cite:toolsRegistry]]. इसका मतलब है कि discovery chain का denominator हाथ से बनी सूची नहीं, बल्कि tool modules हैं। यही registry आगे hub, category lists और /llms.txt में जाती है [[cite:llmsRoute]].
Dynamic routing दूसरा layer है। English route Body.astro files से static paths बनाता है, localized strings से title और description लेता है, canonical URL बनाता है, hreflang alternates जोड़ता है, और SoftwareApplication/Breadcrumb/FAQ JSON-LD तैयार करता है [[cite:englishRoute,seoHelpers]]. Localized route non-default locales को slugs के साथ cross-product करके pages बनाता है और English strings पर localized override लगाता है [[cite:localizedRoute,i18nShell]]. Astro documentation में getStaticPaths static paths के लिए params लौटाता है, इसलिए local pattern framework semantics से मेल खाता है [[cite:astroRouting,astroI18n]].
Head और ToolChrome discovery को visible page से जोड़ते हैं। Head component title, meta description, canonical, alternate links, Open Graph metadata और JSON-LD emit करता है; ToolChrome tool body, about section, related tools और public agent-facing comment render करता है [[cite:headComponent,toolChrome]]. ये comments formal standard नहीं हैं, लेकिन वे agent को यह बताते हैं कि tool browser में चलता है, URL fetch करने से computed answer नहीं मिलेगा, और full tool index /llms.txt पर है [[cite:llmsRoute,llmsTxt]].
यह reuse pattern accountability का मुख्य कारण है। अगर registry, dynamic route, structured data और llms.txt अलग-अलग manually maintained lists होते, तो हर नया tool चार जगह drift risk पैदा करता। इस repository में registry-derived layers drift को कम करते हैं, पर पूरी तरह समाप्त नहीं करते: visible about text, FAQ extraction, localized strings और client-side caveat फिर भी content-specific validation मांगते हैं [[cite:toolsRegistry,seoHelpers,localizedRoute,toolChrome]]. इसलिए chain automation को evidence मानती है, proof नहीं.
परिणाम: Machine-Readable Discovery Accountability Chain
मुख्य परिणाम staged chain है। Static catalog को “indexed” या “AI-ready” जैसे broad label से नहीं, बल्कि सबसे कमजोर verified discovery state से रिपोर्ट करना चाहिए। Sitemap URL होना useful है, पर वह structured entity नहीं है; structured data होना useful है, पर वह localized alternates नहीं बनाता; llms.txt होना useful है, पर वह crawler standard नहीं है; और test pass होना useful है, पर वह live indexing नहीं है [[cite:sitemapsProtocol,googleSitemaps,googleStructured,googleHreflang,llmsTxt,testRun]].
D catalog = min(D page , D canonical , D sitemap , D locale , D schema , D agent , D boundary , D gate )
Equation (1) experimental metric नहीं है; यह reporting rule है। Catalog-level discovery claim उतना ही मजबूत होना चाहिए जितना उसका weakest verified stage. अगर 249 pages हैं लेकिन केवल 220 tools में localized about text है, तो localized-discovery claim 220 पर रुकना चाहिए। अगर JSON-LD exists लेकिन FAQ extraction visible Q/A से अलग है, तो structured-entity stage hold पर जाना चाहिए। यही weakest-stage rule claim inflation को रोकता है [[cite:alexClaimEdge,googleStructured]].
इस chain में levels additive हैं पर substitutable नहीं। अगर page canonical है लेकिन sitemap में नहीं है, तो claim Level 1 पर रुकता है। अगर sitemap और hreflang हैं पर structured data visible content से aligned नहीं है, तो Level 4 का दावा नहीं बनता। अगर llms.txt है पर उसमें client-side execution boundary नहीं है, agent wrongly यह मान सकता है कि URL fetch से answer मिल जाएगा [[cite:llmsRoute,toolChrome,alexPublicRetrieval]].
Structured data layer विशेष सावधानी मांगता है। Local seo.ts SoftwareApplication, BreadcrumbList और FAQPage helpers बनाता है [[cite:seoHelpers]], और Schema.org उन types को define करता है [[cite:schemaSoftware,schemaBreadcrumb,schemaFAQ]]. लेकिन Google structured-data guidance page-content alignment और policy compliance पर जोर देती है [[cite:googleStructured]]. इसलिए paper का result यह नहीं है कि अधिक JSON-LD हमेशा बेहतर है; result यह है कि JSON-LD को visible tool page के साथ accountable रखना चाहिए.
चर्चा
पहला implication claim calibration है। “हमारे पास 249 tools हैं” एक inventory claim है; “हर tool search और agent discovery में accountable है” एक stronger metadata claim है। पहले claim को folder counts support कर सकते हैं; दूसरे claim को registry, route, canonical, sitemap, alternates, structured data, llms.txt, client-side boundary और verification gate की chain चाहिए [[cite:toolsRegistry,englishRoute,localizedRoute,llmsRoute,testRun]]. यही अंतर prior pure-logic paper से novelty boundary बनाता है: वहाँ correctness denominator था; यहाँ discovery denominator है [[cite:alexPureLogic,alexSeoRouting]].
दूसरा implication boundaries है। Robots.txt और sitemap दोनों crawler-facing files हैं, पर RFC 9309 robots.txt को access authorization नहीं बनाता [[cite:rfc9309]]. Public retrieval prior work भी यही warning देता है कि discovery route और permission boundary अलग states हैं [[cite:alexPublicRetrieval]]. Static tool catalog के लिए इसका practical meaning है: sitemap या llms.txt में URL रखना “यह tool private data process कर सकता है” का permission claim नहीं है; यह केवल “यह page discoverable है और इसका usage boundary ऐसा है” का metadata claim है.
तीसरा implication localization है। Repository की shared i18n shell nine locales देती है और localized route non-default locales के static paths बनाता है [[cite:i18nShell,localizedRoute]]. Google hreflang guidance localized versions को एक-दूसरे से जोड़ने की आवश्यकता बताती है [[cite:googleHreflang]]. लेकिन translation completeness, cultural suitability और localized about/FAQ content की quality अलग evidence states हैं। इसलिए chain Level 3 को “localized alternate present” कहती है, “localized experience validated” नहीं.
चौथा implication LLM-agent discovery है। llms.txt proposal agents को concise Markdown index देने का रास्ता बताता है [[cite:llmsTxt]], और local route registry से category-grouped tool list बनाता है [[cite:llmsRoute]]. फिर भी यह convention robots, sitemap या Schema.org जितना settled नहीं है। इसलिए Level 5 को optional लेकिन valuable agent-facing evidence माना गया है। Stronger claim तब बनता है जब llms.txt page-level agent note और client-side execution caveat से जुड़ता है, ताकि agent link कर सके या equivalent operation स्वयं करे, पर website URL को remote computation API न समझे [[cite:toolChrome,llmsRoute]].
Operationally, chain को release checklist में बदला जा सकता है। New tool merge होने पर registry count, Body.astro route, localized strings, canonical URL, generated sitemap entry, JSON-LD shape, llms.txt line, and test coverage को अलग checks की तरह report किया जा सकता है। ऐसा checklist SEO tuning से अधिक governance artifact है: यह बताता है कि कौन सा consumer अभी supported है और कौन सा stage stale हो सकता है. Search result improvement बाद की empirical question है; metadata accountability पहले की engineering question है [[cite:alexSeoRouting,googleSitemaps,googleStructured]].
सीमाएँ और वैधता खतरे
यह paper live crawl, ranking, rich-result eligibility, accessibility audit, browser screenshot, या production search-console data report नहीं करता। Local test run logic quality का point-in-time evidence है, पर search indexing या LLM-agent usage success का empirical evidence नहीं [[cite:testRun]]. इसी कारण conclusions repository-grounded conceptual synthesis तक सीमित हैं.
External evidence में भी boundaries हैं। Google canonical guidance canonical को signal की तरह treat करती है, universal directive की तरह नहीं [[cite:googleCanonical]]. Structured-data guidance rich results की guarantee नहीं देती [[cite:googleStructured]]. llms.txt proposal useful है पर settled standard नहीं [[cite:llmsTxt]]. इन contradictions ने chain को conservative बनाया: हर layer को proof of discovery नहीं, बल्कि auditable evidence state माना गया.
एक और सीमा source selection है। Paper ने official documentation और directly inspected repository sources को प्राथमिकता दी; market demand, user behavior, search traffic और LLM answer quality को शामिल नहीं किया। Future work में rendered HTML snapshots, structured-data validation output, sitemap diff checks, hreflang reciprocity checks, and agent task simulations को same chain के higher-assurance measurements में बदला जा सकता है.
निष्कर्ष
Static browser-tool catalogs को केवल HTML pages या sitemap से discovery-ready नहीं मानना चाहिए। Reliable claim तब बनता है जब catalog अपने weakest verified discovery stage को दिखाए: human page, canonical route, sitemap inventory, localized alternate, structured entity, agent-readable index, client-side execution boundary, और verification gate में से कौन सा वास्तव में प्रमाणित है. alexandrai-tools case यह दिखाता है कि same registry से human pages, JSON-LD, hreflang और llms.txt निकाले जा सकते हैं, लेकिन उन layers को अलग-अलग accountable रखना जरूरी है [[cite:toolsRegistry,seoHelpers,llmsRoute,googleSitemaps,googleStructured,llmsTxt]].
व्यावहारिक takeaway सीधा है: static utility site maintainers को dashboard में tool count के साथ discovery-stage count भी रखना चाहिए। “249 tools” के साथ “249 canonical pages, 249 localized Body modules, 249 i18n files, generated llms.txt, aligned JSON-LD, and current test gate” जैसी stage-specific statements अधिक ईमानदार हैं। इससे humans, crawlers और agents एक ही catalog को अलग-अलग लेकिन traceable contracts के माध्यम से पढ़ते हैं.