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.

Search metadata

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

LayerImplementationSuccess condition
CrawlabilityServer-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 descriptionsRoute-aware titles and meta descriptions for homepage, docs, packages, package guides, support pages, and discovery pages.Each page targets one concrete reader intent.
Structured dataOrganization, 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 disambiguationSeparate UAIX.LmRuntime from LiteRT-LM, LM Studio runtime engines, LinkMove LmRuntime, and generic runtime language.Search systems get clean entity boundaries.
Internal linkingHomepage, 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.
PerformanceStatic assets, local fonts only, lightweight CSS/JS, no tracker dependency, and cacheable root JSON files.Fast crawl and fast developer reading path.
AccessibilitySemantic headings, skip link, keyboard navigation, readable code blocks, text alternatives, visible focus, and responsive layout.Human-first remains the baseline.
GovernanceRelease 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

Schema-only claimsDo not add package capabilities, compatibility, benchmarks, or certifications to JSON-LD unless the same claim is visible and evidenced on the page.
Hidden machine textDo not publish hidden summaries, ranking text, or doorway content intended only for crawlers or generated-answer systems.
Keyword driftDo not chase unrelated LiteRT-LM, flashlight runtime, or LinkMove traffic by mixing topics into package documentation.
Over-broad snippetsDo not let meta descriptions imply model downloads, provider APIs, production certification, or broad compatibility.
Duplicate route clustersDo not create multiple equivalent pages with conflicting titles, descriptions, or canonical URLs.
Stale machine filesDo not leave route inventories, sitemap, release JSON, or llms files behind after content changes.

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.