LMRuntime.com / Search metadata
Technical Search Metadata
Technical search metadata for LMRuntime.com: crawlable package pages, canonical routes, meta descriptions, JSON-LD, sitemap, robots, accessibility, and discovery-file parity.
Technical search work on LMRuntime.com means crawlable package documentation, truthful metadata, matching structured data, fast accessible pages, clean route ownership, and synchronized discovery files.
Direct answer
LMRuntime.com search metadata is useful only when it helps readers find the correct visible package documentation. The durable foundation is ordinary page quality: canonical URLs, accurate titles, concise descriptions, semantic headings, direct NuGet links, evidence boundaries, and accessible code examples.
Technical search layers
| Layer | Implementation | Success condition |
|---|---|---|
| Crawlability | Server-render critical content and expose robots, sitemap, canonical routes, and stable aliases. | Important package facts are visible without JavaScript-only rendering or images of text. |
| Titles and descriptions | Route-aware titles and meta descriptions for homepage, docs, packages, package guides, support pages, and discovery pages. | Each page targets one concrete reader intent. |
| Structured data | Organization, WebSite, WebPage/TechArticle, BreadcrumbList, FAQPage where visible FAQs exist, SoftwareSourceCode for packages, and ItemList for the package catalog. | JSON-LD matches visible page content. |
| Entity disambiguation | Separate UAIX.LmRuntime from LiteRT-LM, LM Studio runtime engines, LinkMove LmRuntime, and generic runtime language. | Search systems get clean entity boundaries. |
| Internal linking | Homepage, Documentation, Packages, package pages, Evidence, Capabilities, Runtime Disambiguation, Package Answers, Source Map, and Discovery Policy cross-link by task. | Every important route is reachable from public navigation, sitemap, and root files. |
| Performance | Static assets, local fonts only, lightweight CSS/JS, no tracker dependency, and cacheable root JSON files. | Fast crawl and fast developer reading path. |
| Accessibility | Semantic headings, skip link, keyboard navigation, readable code blocks, text alternatives, visible focus, and responsive layout. | Human-first remains the baseline. |
| Governance | Release metadata, discovery check, route inventory, no-action boundary, and unsupported-claim list. | Search visibility does not become an overclaiming surface. |
Canonical route model
The site uses one canonical route for each major intent and keeps legacy aliases as route-resolved fallbacks.
/
/packages/
/package-local-endpoint/
/package-gguf/
/package-tokenization/
/package-models-llama/
/getting-started/
/architecture/
/capabilities/
/evidence-benchmarks/
/runtime-disambiguation/
/ai-ready-web/
/answer-engine-optimization/
/generative-engine-optimization/
/technical-seo/
The four discovery/search routes above are retained for compatibility, but their content is target-site documentation: public discovery policy, direct package answers, generated-answer source map, and technical metadata checklist.
Structured data policy
- Organization and WebSite data identify LMRuntime.com and site search.
- WebPage and TechArticle data describe visible documentation pages.
- BreadcrumbList data mirrors visible breadcrumbs and parent sections.
- FAQPage data appears only where the visible page contains the same FAQ questions and answers.
- SoftwareSourceCode data appears on package pages and points to the public NuGet package route without publishing stale package version numbers.
- ItemList data appears on the package catalog and names public packages in task-selection order.
Release checks
- Homepage first viewport contains product identity, purpose, install command, primary actions, and local-only boundary.
- Package catalog uses “Required For” task language and links to every NuGet package page.
- Each package page has a unique title, description, install block, dependency statement, examples, NuGet link, ownership boundary, and Not For section.
- Getting Started begins with a run-first LocalEndpoint path before long explanations.
- Discovery Policy, Package Answer Index, Generated-Answer Source Map, and Technical Search Metadata are linked from documentation, footer, machine files, and sitemap.
- Structured data is emitted only for visible page facts and never creates hidden claims.
- Robots and sitemap point to canonical routes, not stale or duplicate aliases.
- Runtime Disambiguation protects entity search intent from unrelated LM runtime meanings.
- No public package install command pins a UAIX.LmRuntime package version.
- Root discovery files are public-safe and contain no private memory, source paths, or credential material.
Anti-patterns blocked
Maintenance cadence
Each site release should update route-aware metadata, route inventory, sitemap, release JSON, llms.txt, llms-full.txt, discovery manifests, package catalog, and JSON-LD logic together. If a page adds or removes a claim, the machine-readable layer must move in the same release.
Operational checks should track crawl health, indexed canonical routes, package-intent queries, entity-confusion queries, broken outbound NuGet links, generated-answer accuracy, and outdated roadmap summaries. None of those metrics justify hidden text, cloaking, schema-only claims, or ranking promises.
