Embedded Semantics Technical SEO, AEO, GEO, and Machine-Readable Publishing Strategy

Full report

On this page

Audit date: August 23, 2026 Scope: Fresh public audit of https://embeddedsemantics.com/, including publicly retrievable HTML pages, robots.txt, llms.txt, registry/status APIs, registry manifest, Concept registry, research/FAQ/about/contact surfaces, and publicly discoverable search results. No privileged source-code, server, analytics, Search Console, or repository access was used.

Executive assessment

Embedded Semantics already has something many technically sophisticated sites lack: a disciplined semantic boundary. The public site repeatedly distinguishes stable ConceptCode identity from model-derived evidence, production exact resolution from experimental semantic retrieval, and authoritative registry records from embeddings and scores. That conceptual discipline is visible on the homepage, research page, FAQ, About page, status page, API, and llms.txt.

The principal SEO/AEO/GEO problem is therefore not copywriting or keyword density. It is that the site currently describes a concept system much more clearly than it publishes the actual concepts as web entities. The public Concept Registry reports 0 published concepts; the production status API reports 0 published concepts, 0 reviewed exact expressions, no languages, no domains, and no active semantic runtime. At the same time, a public prerelease registry manifest enumerates 11 concepts and 55 expressions.

That creates the central information-retrieval problem:

The site currently explains what a Concept is, but gives crawlers almost no canonical, individually addressable Concept corpus from which to learn the ontology itself.

The homepage even uses semantic_registry.stable_concept_identity as an illustrative first-class concept, while the status page identifies that code among the eleven records missing from the deployed public registry. That is internally understandable to a careful human, but an automated summarizer can easily collapse “illustrated,” “available in a prerelease pack,” “published,” and “production-deployed” into one incorrect assertion.

Strategic verdict

Google's current 2026 guidance is particularly important for separating fact from GEO folklore. Google says that its generative Search features remain grounded in core Search indexing and ranking systems, that pages must be indexed and snippet-eligible, and that publishers do not need special AEO/GEO markup, tiny content chunks, AI-specific rewriting, or llms.txt for Google Search. Google explicitly states that Search ignores llms.txt.

Bing's 2026 guidance is somewhat more direct about generative citation optimization: Bing Webmaster Tools now exposes AI citation activity, grounding queries, and cited-page metrics, while Bing advises publishers to strengthen topical depth, use clear headings and tables where useful, support claims with evidence, keep information current, and remove ambiguity across formats. Those are useful recommendations, but they should still be understood as content-quality and retrieval-readiness guidance, not a formula that guarantees citations.

The recommended information architecture in one sentence

Publish one persistent canonical HTML resource for every public Concept; connect those resources to one registry/scheme entity, immutable release artifacts, human-readable research/evidence, machine-readable JSON-LD/SKOS/API representations, the project entity, and the creator entity—while expressing the same production/experimental/deployment status vocabulary everywhere.

That structure answers all thirteen of the mission's central questions:

Crawlability, indexability, canonicalization, and metadata audit

Crawlability audit

The current robots.txt is extremely simple:

User-agent: *
Allow: /

Sitemap: https://embeddedsemantics.com/sitemap.xml

That makes the public site broadly crawlable under normal robots interpretation and advertises the sitemap location.

For the stated objective—discoverability and citation—this is a sensible baseline. Google recommends using robots.txt for crawl control and sitemaps for discovery; a sitemap declaration in robots.txt is supported. Google also stresses that sitemap submission is a hint rather than an indexing guarantee.

OpenAI's current publisher documentation says that content intended for ChatGPT Search summaries/snippets should not block OAI-SearchBot. It separately identifies GPTBot as the crawler publishers can disallow when opting pages out of potential training. In other words, search discovery and training policy can be managed separately.

Anthropic states that its bots honor standard robots.txt directives, while Perplexity also documents robots-based crawler controls.

Recommendation: retain broad discovery access, but make crawler policy intentional rather than accidental. A future file could make the search-versus-training decision explicit:

User-agent: *
Allow: /

User-agent: OAI-SearchBot
Allow: /

# Optional policy decision, independent of ChatGPT Search inclusion:
# User-agent: GPTBot
# Disallow: /

Sitemap: https://embeddedsemantics.com/sitemap.xml

Do not add crawler-specific directives merely for cosmetic “AI SEO.” Add them only when they encode an actual content-use policy.

Sitemap audit and recommendations

The sitemap is declared in robots.txt and linked publicly from the site footer.

The XML payload itself could not be reliably rendered through the public extraction interface used for this audit, so I am not asserting its current URL inventory.

The target sitemap architecture should contain only URLs that the project actually wants treated as canonical searchable resources:

Include:

/ /concepts every published /concepts/{ConceptCode} /status /research plus substantive research artifacts /faq /about /contact future /specification, /governance, /registry/releases/..., /api documentation pages

Generally exclude:

/api/v1/resolve?... query/result endpoints empty/filter variants of /concepts raw JSON API responses raw JSON Schema files transient generated responses parameterized search URLs experimental/debug surfaces

Google says sitemap URLs should represent preferred canonical URLs, and that sitemaps help discovery but do not ensure crawling or indexing.

For release artifacts intended to function as downloadable datasets, use an indexable HTML Dataset/release landing page and link its JSON distributions from there rather than relying on the raw JSON files themselves as search landing pages.

Indexability audit

The site has a major qualitative indexability gap despite good crawlability: the central entities are not yet published as HTML records. /concepts currently states “0 published concepts,” while /api/v1/concepts returns:

{"count":0,"data":[]}

This means indexing /concepts today teaches an engine:

• a Concept Registry exists;
• what kinds of information it is intended to hold;
• that the current deployed registry is empty.

It does not give the engine a crawl graph of canonical Concept entities.

That should be considered the highest-severity SEO/AEO issue.

The ideal URL pattern is:

https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity
https://embeddedsemantics.com/concepts/semantic_registry.hard_negative
https://embeddedsemantics.com/concepts/semantic_registry.semantic_embedding
...

Using the stable ConceptCode directly has an important architectural advantage: the URL remains bound to the governed identifier even if the preferred English label later changes. This is aligned with W3C data-publishing principles recommending persistent URIs for identifiers and preservation of identifiers over time.

Do not generate indexed Concept pages simply for every code that exists in development. The rule should instead be:

Every public/published Concept gets a canonical page; every canonical Concept page must contain enough governed information to stand on its own.

A draft Concept that has no public definition, evidence, or stable publication status should remain unpublished or noindex, not become a thin doorway page.

API indexability

The top navigation's API link currently resolves directly to the raw /api/v1/concepts JSON response rather than a human API documentation page; because the public registry is empty, that destination is presently an empty JSON collection.

That should change.

Recommended pattern:

/api                         -> indexable HTML documentation
/api/reference               -> indexable HTML API reference
/api/openapi.json            -> machine API contract
/api/v1/concepts             -> machine collection, X-Robots-Tag: noindex
/api/v1/concepts/{code}      -> machine representation, normally noindex
/api/v1/status               -> machine status, noindex
/api/v1/resolve              -> functional/query endpoint, noindex

OpenAPI is designed specifically as a language-neutral interface description that allows humans and machines to understand an HTTP API without source-code access. The current OpenAPI specification line includes v3.2.0.

For non-HTML resources Google supports indexing control through the X-Robots-Tag HTTP header. Critically, Google advises that a crawler must be allowed to fetch a resource if it is expected to see its noindex instruction; blocking it in robots.txt can prevent that instruction from being read.

Accordingly:

X-Robots-Tag: noindex

is preferable to:

Disallow: /api/

for machine resources that should remain fetchable to agents but should not become normal search-result landing pages.

Canonicalization audit

Canonical <link> elements could not be independently confirmed from the public extraction output used here, so this audit treats current canonical markup as unverified, not absent.

Google currently recommends self-referential canonical links on canonical pages, consistent internal linking to the canonical form, and canonical-only sitemap inclusion. Google also says that robots.txt is not a canonicalization mechanism and that sitemap and canonical signals should not conflict.

Recommended canonical rules:

The distinction between canonical and citable is worth preserving. RFC 8574 defines a separate cite-as link relation because the URI preferred for scholarly/reference citation is not necessarily identical to the canonical URI chosen for search indexing.

For immutable research datasets or release artifacts, that provides a clean architecture:

HTML access page         -> SEO canonical
immutable DOI/release ID -> preferred scholarly reference identifier
JSON distribution        -> machine representation

Current metadata audit

The publicly extracted page titles are generally strong and appropriately specific:

The corresponding visible H1s are also specific and semantically useful.

The homepage's title and H1 are intentionally not identical, which is perfectly reasonable. Google can generate result titles from multiple signals and may rewrite displayed search titles; exact title display is not guaranteed.

Meta-description, canonical-tag, Open Graph, Twitter-card, and embedded JSON-LD values were not exposed reliably enough by this audit's extraction layer to declare them present or absent. They should therefore be validated directly in rendered/raw response inspection, Google URL Inspection, Rich Results Test where applicable, and a generic Schema.org validator.

The target Concept metadata template should be approximately:

<title>Stable Concept Identity — ConceptCode semantic_registry.stable_concept_identity | Embedded Semantics</title>

<meta
  name="description"
  content="Governed definition, multilingual expressions, provenance, relationships,
           and registry status for ConceptCode semantic_registry.stable_concept_identity.">

<link
  rel="canonical"
  href="https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity">

Open Graph should describe the same entity, not a marketing variant:

<meta property="og:title"
      content="Stable Concept Identity | Embedded Semantics">

<meta property="og:description"
      content="Governed definition and evidence for ConceptCode semantic_registry.stable_concept_identity.">

<meta property="og:type" content="article">

<meta property="og:url"
      content="https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity">

<meta property="og:image"
      content="https://embeddedsemantics.com/assets/concept-card.png">

The Open Graph protocol specifies og:title, og:type, og:image, and og:url as its basic required metadata and defines og:url as the graph object's permanent/canonical URL.

The critical rule is cross-format consistency:

HTML title
H1
visible ConceptCode
canonical URL
og:url
JSON-LD @id
API concept code
registry-pack code
SKOS notation
sitemap URL
internal anchor URLs

must all describe the same entity.

Structured data, terminology, and entity graph

Structured-data audit

Embedded JSON-LD could not be conclusively inspected through the public page-extraction layer, so existing structured-data implementation is unverified.

That should not delay a design decision, because the appropriate data model is unusually clear.

Google recommends JSON-LD as a structured-data serialization and requires structured-data content used for Search features to accurately represent visible page content. Structured data helps Google understand page content and can enable supported rich-result features, but correct markup does not guarantee a rich result.

A crucial distinction:

Schema.org vocabulary support is broader than Google rich-result support.

DefinedTerm, DefinedTermSet, ResearchProject, Dataset, TechArticle, ScholarlyArticle, and WebAPI can improve machine semantics even when Google offers no dedicated rich result for them. Google explicitly says there is no special structured-data schema required for generative Search.

Entity graph recommendation

The site should publish a stable graph with these entity classes:

Embedded Semantics ResearchProject
        │
        ├── has website ──────> WebSite
        │
        ├── creator/founder ──> Michael Kappel (Person)
        │
        ├── publishes ────────> Concept Registry (DefinedTermSet / ConceptScheme)
        │                           │
        │                           ├── Concept A
        │                           ├── Concept B
        │                           └── Concept N
        │
        ├── publishes ────────> Registry Dataset / releases
        │
        ├── documents ────────> TechArticle / specification
        │
        ├── evaluates ────────> Research reports
        │
        └── exposes ──────────> WebAPI

Schema.org defines ResearchProject as a research project, under its Project hierarchy, although Schema.org currently labels the term as being in its newer vocabulary area.

Schema.org defines DefinedTerm specifically for a word, phrase, acronym, name, or other item with a formal definition; its documentation explicitly recommends name, termCode, description, and about. It defines DefinedTermSet for glossaries, classifications, dictionaries, and other defined-term collections.

Those semantics map remarkably well onto Embedded Semantics.

Every public Concept should be a first-class entity

The answer to “Should every Concept have a dedicated page?” is:

**Every published Concept should.**

That page should not merely be a search landing page. It should be the authoritative public documentation URI for the concept.

Concept entity identity:

Page:
https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity

WebPage entity:
https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#webpage

Abstract concept entity:
https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept

Separating the document from the abstract Concept via fragment identifiers is useful Linked Data hygiene: a WebPage and the abstract meaning described by the page are not literally the same thing. JSON-LD is a W3C Recommendation for expressing Linked Data graphs in JSON and supports stable IRIs and graph relationships directly.

Schema.org layer for Concept pages

Recommended page graph:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://embeddedsemantics.com/#website",
      "url": "https://embeddedsemantics.com/",
      "name": "Embedded Semantics"
    },
    {
      "@type": "ResearchProject",
      "@id": "https://embeddedsemantics.com/#project",
      "name": "Embedded Semantics",
      "url": "https://embeddedsemantics.com/",
      "description": "Registry-backed multilingual semantic identity using stable ConceptCodes and governed expression evidence.",
      "founder": {
        "@id": "https://embeddedsemantics.com/contact#person"
      }
    },
    {
      "@type": "Person",
      "@id": "https://embeddedsemantics.com/contact#person",
      "name": "Michael Kappel",
      "url": "https://embeddedsemantics.com/contact",
      "sameAs": [
        "https://mikekappel.com/",
        "https://www.linkedin.com/in/michaelkappel/",
        "https://github.com/MichaelKappel"
      ]
    },
    {
      "@type": "DefinedTermSet",
      "@id": "https://embeddedsemantics.com/concepts#registry",
      "name": "Embedded Semantics Concept Registry",
      "url": "https://embeddedsemantics.com/concepts",
      "about": {
        "@id": "https://embeddedsemantics.com/#project"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#webpage",
      "url": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
      "name": "Stable Concept Identity",
      "isPartOf": {
        "@id": "https://embeddedsemantics.com/#website"
      },
      "mainEntity": {
        "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept"
      }
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept",
      "name": "Stable concept identity",
      "termCode": "semantic_registry.stable_concept_identity",
      "description": "A governed semantic identity intended to remain stable across changes in language expressions, model versions, and retrieval implementations.",
      "url": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
      "inDefinedTermSet": {
        "@id": "https://embeddedsemantics.com/concepts#registry"
      },
      "identifier": {
        "@type": "PropertyValue",
        "propertyID": "ConceptCode",
        "value": "semantic_registry.stable_concept_identity"
      }
    }
  ]
}

The exact sameAs URLs should be checked before deployment. sameAs means identity, not “related to.” Do not use sameAs for Protocol5 or JustAnIota. The existing llms.txt already wisely says those projects are related project surfaces, “not aliases or alternate identities.”

SKOS layer for the actual concept system

Schema.org is appropriate for broad web/search semantics. For the project's actual knowledge-organization model, W3C SKOS is a better conceptual fit.

SKOS explicitly supports concepts identified by URIs, multilingual labels, notations/codes, definitions, concept schemes, broader/narrower/related relationships, and mappings between schemes.

A machine representation can therefore look like:

{
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#",
    "prov": "http://www.w3.org/ns/prov#"
  },
  "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept",
  "@type": "skos:Concept",
  "skos:notation": "semantic_registry.stable_concept_identity",
  "skos:prefLabel": [
    {
      "@value": "Stable concept identity",
      "@language": "en"
    }
  ],
  "skos:definition": {
    "@value": "A governed semantic identity intended to remain stable across changes in language expressions, model versions, and retrieval implementations.",
    "@language": "en"
  },
  "skos:inScheme": {
    "@id": "https://embeddedsemantics.com/concepts#scheme"
  }
}

As translations become governed, language-tagged labels can be added. JSON-LD 1.1 explicitly supports language-tagged strings and language maps.

Do not force all linguistic evidence into skos:prefLabel. The project's model is richer than a vocabulary thesaurus: reviewed expressions have provenance, equivalence strength, locale, and potentially ambiguity. That evidence belongs in explicit first-party properties or provenance records rather than pretending every expression is a simple preferred/alternate synonym.

Provenance graph

W3C PROV-O exists specifically to represent and exchange provenance information across systems.

That maps directly to the project's philosophy.

A Concept definition might be:

Concept
 ├─ definition version
 │   ├─ generated/approved by governance activity
 │   ├─ attributed to reviewer/person/project
 │   └─ derived from supporting references
 │
 ├─ reviewed expression evidence
 │   ├─ language
 │   ├─ reviewer
 │   ├─ review timestamp
 │   └─ equivalence classification
 │
 └─ evaluation evidence
     ├─ benchmark version
     ├─ model profile
     ├─ result
     └─ timestamp

This does not need to appear in full RDF vocabulary in Google's search-facing JSON-LD. A sensible two-layer architecture is:

Layer A — Web-search semantics: straightforward Schema.org JSON-LD.

Layer B — Standards-grade data: SKOS + PROV JSON-LD in a linked machine representation.

That avoids overloading a search-engine parser with an unnecessarily complex research ontology while still publishing the full semantic graph.

Terminology consistency audit

Current terminology is already strong but should be tightened into a controlled editorial vocabulary.

The following phrases appear consistently across the public site:

• ConceptCode
• reviewed exact expressions
• stable concept identity
• registry-first exact authority
• experimental semantic candidate retrieval
• abstention
• unknown_expression
• ambiguous_expression
• embeddings/vectors as evidence, not authority.

One inconsistency worth correcting is that the research page sometimes says “Concept ID” while the rest of the project strongly privileges ConceptCode.

Recommendation:

Use ConceptCode as the normative technical term everywhere. “Concept identifier” can appear as explanatory prose only after an explicit equivalence statement.

Create a terminology registry containing at least:

This terminology file should feed visible documentation, API field descriptions, schema documentation, llms.txt, and editorial review.

Concept, registry, research, FAQ, evidence, and citation architecture

Concept-page architecture

A Concept page should answer a human's first question within the first screen while also exposing enough structure for machine retrieval.

Recommended outline:

Label and identity

Stable Concept Identity

ConceptCode: semantic_registry.stable_concept_identity

One-sentence governed definition

A concise definition that is safe to quote without surrounding context.

Registry status

Publication: Published
Registry version: 1.0
Definition status: Governed
Production exact-resolution evidence: Active
Experimental retrieval evidence: Not production-active
Last reviewed: 2026-08-23

What this Concept means

A fuller definition and scope.

What it does not mean

This is especially powerful for technically adjacent concepts and hallucination resistance.

For example:

Stable concept identity does not mean that a vector representation remains numerically stable.

Reviewed expressions

Human-readable table:

The exact values should come only from the governed registry.

Examples

Concrete examples of when the Concept applies.

Counterexamples / hard negatives

This is unusually useful for Embedded Semantics because discrimination among close concepts is part of the project's own research objective. The research page explicitly emphasizes hard negatives and distinguishing semantic neighbors rather than generic topical similarity.

Relationships

Broader
Narrower
Related
Exact external mapping
Close external mapping

Do not invent relationships merely to create a dense graph.

Evidence

Links to governance records, research, evaluations, test artifacts, and immutable releases.

Implementation boundary

Explicitly distinguish whether the concept exists from whether a resolver capability involving it is production-ready.

Machine access

JSON
JSON-LD
Registry release
API representation
Schema

Citation

Preferred title
ConceptCode
Registry version
Canonical URL
Date modified
Publisher
Suggested citation

Registry-page architecture

The existing /concepts page provides a reasonable registry introduction but, because it currently contains no published records, cannot yet function as an effective entity hub.

Turn /concepts into both a navigation hub and a DefinedTermSet/concept-scheme landing page.

Recommended sections:

What this registry is A concise definition.

Authority model What is authoritative and what is evidence.

Publication state Current production deployment—not source-pack potential.

Browse concepts Indexable links to every published Concept.

Namespaces/domains For example semantic_registry.*, mt.*, with definitions of namespace semantics.

Versioning policy What changes may occur without changing ConceptCode; what constitutes a breaking semantic revision.

Governance Who may approve expressions/definitions and what “reviewed” means.

Machine distributions Immutable releases and current manifest.

Schema Human documentation of the JSON Schema.

Citation/license How the registry should be cited and reused.

Structured data:

DefinedTermSet
Dataset
WebPage
ResearchProject reference

Do not canonicalize the registry page to the latest Dataset release or vice versa. They represent different resources:

/concepts       = living registry collection
/registry       = publishing/governance landing page
/registry/releases/1.0 = immutable release

Resolving the prerelease-versus-production ambiguity

This is the most important factual inconsistency in the current machine-facing publication architecture.

The public status surfaces say:

published concepts: 0
reviewed exact expressions: 0
deployment: 0 / 11 concepts
deployment: 0 / 55 expressions
semantic runtime: inactive

Yet registry-packs/manifest.json says:

"counts": {
  "concepts": 11,
  "expressions": 55
},
"version": "prerelease"

and identifies two source packs containing those records.

These statements can all be logically correct, but the ontology of the status itself is too implicit.

Add explicit fields:

{
  "artifactStatus": "prerelease",
  "publicationStatus": "public_artifact",
  "deploymentStatus": "not_deployed",
  "productionEligible": false,
  "registryCoverage": {
    "packagedConcepts": 11,
    "deployedConcepts": 0,
    "packagedReviewedExpressions": 55,
    "deployedReviewedExpressions": 0
  }
}

Then use exactly the same words in HTML.

Avoid an overloaded word such as “public” to mean both “downloadable artifact exists” and “active production registry record exists.”

Research-page architecture

The current research page is strong conceptually. It explicitly separates the exact production resolver from model-backed research, defines the target as Concept resolution rather than generic similarity, names hard negatives, identifies evaluation metrics, and treats abstention as a first-class outcome.

Its next evolution should be from a single methodological overview to a citable research publication hierarchy:

/research
/research/methodology
/research/evaluations
/research/evaluations/exact-resolution-v1
/research/evaluations/cross-lingual-retrieval-v1
/research/evaluations/abstention-calibration-v1
/research/benchmarks/{benchmark-id}
/research/model-profiles/{profile-id}

Do not create these until substantive evidence exists.

Each evaluation page should contain:

Research question

Status

Experimental
Not production-active
Evaluation version: ...
Run date: ...

Hypothesis

Dataset

Including registry version and content hash.

Model/runtime

Exact model/profile versions.

Method

Enough information for reproducibility.

Metrics

The existing site's Recall@1, Recall@5, MRR, cross-language agreement, false-neighbor rate, spread measures, margins, and abstention metrics provide a good starting vocabulary.

Results

Prefer tabular raw numbers to adjective-only claims.

Interpretation

Separate observation from conclusion.

Limitations

Required for any statement about generalization.

Production implication

Explicit:

This evaluation does / does not change the current production capability.

Artifacts

Data, scripts/repository release if public, hashes.

References

Original scholarly sources.

For methodology/specification documents, TechArticle is appropriate; for work that is genuinely a scholarly publication with scholarly structure, ScholarlyArticle is available in Schema.org. Do not label every documentation page ScholarlyArticle merely to look authoritative.

FAQ/AEO architecture

The current FAQ is good answer-engine content because it answers substantive architecture questions directly:

• what Embedded Semantics is;
• whether embeddings are authoritative;
• whether unseen paraphrases resolve today;
• how multilingual resolution works;
• why hard negatives are used;
• how uncertainty is handled.

Keep it.

Expand it only with real recurring conceptual ambiguities, not dozens of fabricated long-tail questions.

High-value additions:

What is a ConceptCode?
What makes an expression “reviewed”?
What is the difference between a Concept and an embedding?
What does “production” mean on this site?
What does “experimental” mean?
What is the difference between a registry pack and the deployed registry?
Can two expressions map to more than one Concept?
Can one Concept have expressions in many languages?
How are Concept definitions versioned?
Can ConceptCodes change?
How should Embedded Semantics be cited?

The answer should begin with a direct statement, then link to the authoritative Concept/specification/research page.

Do not expect FAQ schema to produce ordinary Google FAQ rich results for this technical site. Google restricted FAQ rich-result display primarily to well-known authoritative government and health sites; Google has said other sites need not remove valid FAQ markup, but it generally has no visible FAQ Search effect for them.

Thus FAQ markup here would be semantic convenience—not an SEO jackpot.

Evidence and claim architecture

Yes, technical claims should include evidence blocks.

This is not a Google indexing requirement. It is a strong recommendation for:

• human auditability;
• answer-engine grounding;
• version awareness;
• reduction of stale claims;
• distinction between design intent and demonstrated behavior.

Bing's current AI guidance explicitly recommends supporting claims with examples, data, and cited sources.

A reusable block:

Claim
Reviewed exact multilingual expressions can resolve to a stable ConceptCode.

Capability status
PRODUCTION

Evidence class
Deployed behavior

Scope
Production resolver reviewed_exact_registry_first

Verified
2026-08-23

Evidence
- status API
- resolver conformance test
- registry release
- implementation/version identifier

Limitations
Only governed exact expressions are authoritative.
Unseen paraphrases do not resolve through this production path.

For an experimental claim:

Claim
Embedding retrieval may support cross-lingual candidate generation.

Capability status
EXPERIMENTAL

Evidence class
Research hypothesis / benchmark result

Production impact
NONE

Known limitations
Not calibrated for arbitrary production resolution.
Not semantic authority.

The most important field is often not “Evidence” but “Production impact: none.”

Evidence taxonomy

Use a controlled evidence ladder:

design_intent
prototype_observation
benchmark_observation
reproduced_evaluation
deployed_observation
governed_production_fact

A claim should never silently climb this ladder through editorial wording.

For example:

“The research explores language-neutral retrieval.”

is not equivalent to:

“The resolver provides language-neutral semantic resolution.”

The site already avoids that mistake unusually well. Preserve that discipline.

Scholarly citation architecture

W3C's Data on the Web Best Practices recommends persistent identifiers, version identifiers/history, metadata, provenance, standardized vocabularies, and citation of original publications.

For each formal research page, include a visible References section with:

Author(s)
Title
Venue/publisher
Year
DOI when available
Persistent URL
Version/access date where relevant

In JSON-LD use appropriate:

author
datePublished
dateModified
citation
identifier
version
license

For the project's own research software or datasets, a CITATION.cff can provide human- and machine-readable citation metadata; the Citation File Format explicitly supports software and datasets.

For stable scholarly releases, consider an archival DOI only when the artifact is actually mature enough to deserve an immutable scholarly citation.

The project should also distinguish:

Canonical web URL
Preferred citation URI
Dataset/release identifier
Source repository URL

rather than assuming one URL serves every identity role.

Machine-readable documentation, APIs, llms.txt, and generative search

Machine-readable documentation architecture

The site's current machine-access story is already stronger than most early research projects. It publicly links:

• the Concept API;
• status API;
• registry-pack JSON Schema;
• public registry manifest;
• individual packs;
• resolver API;
• sitemap.

What it lacks is a clear hierarchy explaining which artifact is authoritative for what purpose.

Recommended hierarchy:

Human authoritative definition
    /concepts/{ConceptCode}

Machine semantic representation
    /concepts/{ConceptCode}.jsonld
    or API representation

Registry collection
    /concepts

Registry publishing documentation
    /registry

Immutable registry release
    /registry/releases/{version}

Release distributions
    /registry-packs/{immutable-file}.json

Current deployment status
    /status

Machine deployment status
    /api/v1/status

API documentation
    /api

API contract
    /api/openapi.json

JSON Schema documentation
    /schemas/reviewed-registry-pack-v1

JSON Schema artifact
    /schemas/reviewed-registry-pack-v1.schema.json

AI/agent map
    /llms.txt

The human HTML resource should usually be the place an engine cites to a human. The machine representation should exist to remove interpretive ambiguity, not to compete with the HTML page in search results.

W3C best practices explicitly support complementary presentations, machine-readable standardized formats, versioning, APIs, persistent identifiers, and metadata/provenance.

llms.txt analysis

The current llms.txt is one of the site's better artifacts.

It says, in very compact form:

• production = reviewed exact expression → stable ConceptCode;
• unknown expressions abstain;
• governed ambiguities abstain;
• embedding candidate retrieval is experimental;
• reranking/calibration/unseen-paraphrase resolution are not production-active;
• ConceptCode and registry definition are semantic authority;
• model-derived information is evidence.

That is exactly the kind of content an optional machine navigation document should contain.

But its realistic value must be stated conservatively.

Google now explicitly says that Google Search does not use llms.txt and that creating one neither helps nor harms Google Search visibility or ranking. Google also says that there is no requirement for special AI text files or AI-specific markup to participate in generative Search.

Therefore:

Keep llms.txt, but do not treat it as an optimization primitive.

Its role should be:

map
orientation
capability-boundary summary
pointers to canonical sources

Its role should not be:

canonical authority
replacement for Concept pages
replacement for robots.txt
replacement for sitemap
ranking mechanism
secret AI index

Most importantly, never let llms.txt contain a stronger capability claim than /status, the API, or the research pages.

A useful enhancement would be a line near the top:

Authoritative capability status:
https://embeddedsemantics.com/status

Authoritative Concept definitions:
https://embeddedsemantics.com/concepts

This file is a navigation summary, not the semantic source of truth.

That mirrors the project's own philosophy.

API indexing recommendations

Recommended policy matrix:

Where machine clients benefit from discoverability, links from authoritative HTML are sufficient; search-result indexing is not necessary.

Public registry as Dataset

Create an indexable /registry/releases/{version} landing page typed as Dataset.

Schema.org defines Dataset as a body of structured information and maps it to data-vocabulary concepts such as DCAT Dataset.

Example information:

Embedded Semantics Public Registry — Release 1.0

Release status: Published
Released: YYYY-MM-DD
Concept count: 11
Reviewed expression count: 55
Languages: ...
Schema version: ...
SHA-256: ...
License: ...
Supersedes: ...
Superseded by: ...

Then:

Distribution: registry.json
Distribution: registry.jsonld
Distribution: CSV if useful
Schema: ...

The existing SHA-256 practice is excellent for artifact identity and should be retained. The current prerelease status page and manifest already expose a shared bundle SHA-256, allowing the human and machine surfaces to be cross-checked.

Production-versus-experimental claim handling

This area deserves a formal site-wide schema because it is directly tied to hallucination resistance.

Create one controlled capability vocabulary:

production
experimental
planned
inactive
deprecated

Separately create deployment:

deployed
partially_deployed
not_deployed

Separately create evidence maturity:

design
prototype
benchmarked
validated
production_observed

Do not collapse these axes.

A feature can be:

experimental + deployed-in-research-environment + benchmarked

without being:

production

Likewise a registry artifact can be:

public + prerelease + not_deployed

That is exactly the ambiguity currently exposed by the 11/55 manifest versus 0/0 production deployment.

Every capability page should show:

Status: EXPERIMENTAL
Production availability: NO
Current evidence: benchmark v0.2
Last verified: YYYY-MM-DD
Applies to: model/profile/version

Use the same data object to generate HTML, API JSON, JSON-LD-compatible metadata where applicable, and llms.txt summaries. That minimizes cross-surface drift.

Internal-link architecture

Internal linking should represent the semantic graph—not merely site navigation.

Current global navigation already connects Concepts, Status, Research, FAQ, About, Contact, and API.

The next layer should use contextual links.

A Concept page should link to:

Registry
Related Concepts
Broader/narrower Concepts
Relevant research
Evidence
Current implementation status
API representation
Registry release

A research report should link every named Concept to its canonical Concept page.

FAQ answers should link the first meaningful occurrence of ConceptCode, “hard negative,” “semantic embedding,” etc. to their Concept pages.

Status should link every deployed/missing ConceptCode to its Concept documentation once those Concepts are public. A missing/deployment status should not imply that the definition page must disappear: documentation existence and runtime deployment are separate dimensions.

Registry release pages should link each Concept in that release.

Concept pages should have breadcrumbs:

Home > Concept Registry > Stable Concept Identity

Google supports BreadcrumbList structured data to express page hierarchy.

What helps generative citation—and what is speculative

It is useful to divide recommendations into three confidence classes.

Confirmed search/AI-platform guidance

These are high-confidence:

• content must be crawlable and indexable for Google Search generative features;
• ordinary SEO remains foundational;
• unique, useful, well-structured content is preferable to commodity content;
• there is no special Google GEO schema;
• Google ignores llms.txt;
• OpenAI Search discovery benefits from not blocking OAI-SearchBot;
• Bing now reports AI citations and recommends clarity, evidence, freshness, and low ambiguity.

Standards-based interoperability

Also high-confidence as technical publishing architecture, though not guaranteed ranking factors:

• persistent entity URIs;
• JSON-LD;
• Schema.org DefinedTerm/DefinedTermSet;
• SKOS;
• PROV;
• versioned datasets;
• OpenAPI;
• machine-readable citation metadata.

Experimental GEO hypotheses

These may be worth testing, not asserting as engine rules.

The original Generative Engine Optimization research literature and subsequent controlled experiments suggest that source relevance, evidence, citations, completeness, freshness indicators, and other content properties can affect citation selection in certain RAG/LLM environments. A 2026 controlled study across six models and 252,000 paired trials found topical relevance to be a dominant factor, with smaller effects for some explicit factual/trust/freshness cues and little benefit from formatting-only changes.

That does not prove that adding a date or evidence box makes ChatGPT, Google AI Mode, or Bing Copilot rank a page higher in production. Retrieval stacks, ranking stages, context selection, model behavior, and citation policies differ.

The safe interpretation is:

Build evidence architecture because it makes the source more precise, auditable, and reusable—not because an unverified “GEO factor” promises ranking gains.

Google's own current guidance strongly reinforces that restraint.

Content gaps, recommended pages, and example publishing templates

Highest-value content gaps

The Concept corpus is missing. This is the dominant gap. The status page already identifies eleven intended prerelease ConceptCodes.

Once governance permits publication, those eleven become the obvious initial entity corpus:

mt.core.steganography
mt.linguistic.contraction_choice
mt.representation.differential
mt.representation.human_visible
mt.representation.machine_readable
mt.representation.unicode_code_point
semantic_registry.cross_lingual_semantic_alignment
semantic_registry.hard_negative
semantic_registry.semantic_embedding
semantic_registry.semantic_residue
semantic_registry.stable_concept_identity

Do not index them before the public definitions are substantively ready.

A normative specification page is missing. The homepage, FAQ, research, and About pages explain architecture, but there should be one durable document answering:

What is a Concept?
What is a ConceptCode?
What is an expression?
What does reviewed mean?
What evidence classes exist?
What are equivalence semantics?
What constitutes ambiguity?
What is abstention?
What can change without changing identity?
What causes a new ConceptCode?
How does versioning work?

Recommended URL:

/specification

or, once versions become meaningful:

/specification/1.0

Registry governance documentation is missing.

Recommended:

/governance

It should define review authority, acceptance criteria, change policy, deprecation, provenance, disputes, and versioning.

Human API documentation is missing from the primary navigation experience.

Recommended:

/api

with an actual documentation surface and OpenAPI link.

Human schema documentation is missing.

Recommended:

/schemas
/schemas/reviewed-registry-pack-v1

The raw .schema.json remains a machine artifact.

Release history is missing as a first-class citation structure.

Recommended:

/registry/releases
/registry/releases/{version}

A citation page would improve research use.

Recommended:

/citation

Include:

How to cite the project
How to cite a Concept
How to cite a registry release
How to cite a research report
Preferred project name
Creator
Persistent URLs
License
CITATION.cff

A changelog/history page would reduce stale summaries.

Recommended:

/changelog

Especially valuable when a production capability graduates from experimental to production.

Recommended site tree

/
├── concepts
│   ├── semantic_registry.stable_concept_identity
│   ├── semantic_registry.hard_negative
│   ├── semantic_registry.semantic_embedding
│   └── ...
│
├── glossary
│
├── specification
│   └── [future immutable versions]
│
├── governance
│
├── registry
│   ├── releases
│   │   └── {version}
│   └── schema
│
├── research
│   ├── methodology
│   ├── evaluations
│   ├── benchmarks
│   └── model-profiles
│
├── evidence
│   └── [optional evidence catalog]
│
├── status
│
├── faq
├── about
├── contact
├── citation
├── changelog
│
├── api
│   ├── reference
│   └── openapi.json
│
├── schemas
│   └── reviewed-registry-pack-v1
│
├── api/v1/...
├── registry-packs/...
├── llms.txt
├── robots.txt
└── sitemap.xml

Do not implement the whole tree merely to make the site larger. Google specifically warns against producing large quantities of pages designed primarily to capture query variations and says there is no ideal content length or requirement to break content into special AI-sized chunks.

Example Concept page outline

TITLE
Stable Concept Identity — semantic_registry.stable_concept_identity | Embedded Semantics

H1
Stable Concept Identity

Identity card
ConceptCode
Publication status
Registry version
Last reviewed

Definition
One governed quotable definition.

Direct answer
Two to four sentences explaining the concept in plain technical English.

Semantic boundary
What it includes.
What it excludes.

Why this exists
Problem the Concept solves.

Reviewed multilingual expressions
Table with language, expression, equivalence class, review provenance.

Examples
Positive examples.

Non-examples
Commonly confused meanings.

Hard negatives
Adjacent Concepts that must remain distinct.

Relationships
Broader / narrower / related / mappings.

Production use
Exactly what production system currently does with this Concept.

Experimental use
Separate research-only capability.

Evidence
Claims with status, method, version, results.

Provenance
Definition/review history.

Registry history
First published, changed, deprecated if applicable.

References
Scholarly and standards sources.

Machine access
JSON-LD / API / registry release.

Citation
Canonical URL, ConceptCode, version, date.

Example registry-release page

TITLE
Embedded Semantics Public Registry 1.0 | Release

H1
Public Registry 1.0

Release status
Published / prerelease / deprecated

Release date

Summary
Concept count
Expression count
Languages
Domains

Authority
What this release means.

Changes since previous version

Concept inventory
Canonical links to each Concept.

Expression coverage

Known limitations

Production deployment
Is this release deployed?
Where?
Since when?

Integrity
SHA-256
Schema version

Downloads
JSON
JSON-LD

Machine schema

License

Citation
Suggested citation
Preferred stable reference URI

Provenance

Changelog

Example research-evaluation page

TITLE
Cross-Lingual Concept Retrieval Evaluation — Experiment ES-2026-01

H1
Cross-Lingual Concept Retrieval Evaluation

Status banner
EXPERIMENTAL — NOT PRODUCTION-ACTIVE

Research question

Hypothesis

Related Concepts

Registry version

Dataset

Model profile

Method

Evaluation metrics

Results table

Failure analysis

Hard-negative analysis

Abstention behavior

Cross-language behavior

Reproduction information

Limitations

Production impact
NONE / candidate for review / promoted after gate...

Evidence artifacts

Scholarly references

Citation

Change history

Recommended direct-answer pattern

Each substantive page should contain a concise passage that remains correct when extracted without the rest of the page.

For example:

Stable concept identity is the separation of a governed semantic identifier from the language expressions and model-derived representations used as evidence for it. In Embedded Semantics, a ConceptCode is intended to remain stable when those evidence representations change.

Then immediately add the important qualification:

This architectural definition does not imply that arbitrary unseen-language queries are resolved in production; the current production path is registry-first exact resolution.

That second sentence is often more important for hallucination resistance than additional promotional detail.

Measurement, launch, post-indexing plan, and risks

Measurement plan

Measure three different systems rather than combining everything into “SEO traffic.”

Search discoverability

Track:

Indexed canonical pages
Google-selected canonical versus declared canonical
Sitemap discovered/crawled URLs
Concept-page impressions
ConceptCode queries
branded/non-branded impressions
crawl errors
structured-data validation

Google recommends Search Console for index status, crawling diagnostics, URL Inspection, and performance monitoring. Individual priority URLs can be submitted through URL Inspection, while sitemaps provide broader discovery signals.

Generative citation visibility

Bing Webmaster Tools' 2026 AI Performance report exposes:

Total citations
Average cited pages
Grounding queries
Page-level citation activity
Citation trends

Google's current Search documentation also identifies a Generative AI performance report in Search Console for visibility in Google generative Search experiences.

OpenAI says ChatGPT Search referral URLs include:

utm_source=chatgpt.com

which makes ChatGPT referral traffic directly measurable in analytics.

Semantic accuracy

This project should measure something ordinary SEO sites usually do not:

Does the answer engine state the project's capability boundary correctly?

Build a fixed test suite such as:

What is Embedded Semantics?
What is a ConceptCode?
Does Embedded Semantics use embeddings as semantic truth?
Can Embedded Semantics resolve unseen paraphrases in production?
How many Concepts are currently deployed?
What is stable concept identity?
What is a hard negative in Embedded Semantics?
Is semantic reranking currently production-active?

For each platform/run, score:

Correct
Partially correct
Incorrect
Unsupported claim
Production/experimental confusion
Correct citation
Wrong citation
No citation

This is a much better GEO KPI for this project than “AI visibility” alone.

Suggested baseline KPIs

Do not create arbitrary traffic targets before a baseline exists.

Google Search Console launch plan

After the first canonical Concept corpus is deployed:

Verify domain-level Search Console ownership.

Submit sitemap.xml. Google says sitemap submission through Search Console shows access and processing errors, though submission does not guarantee indexing.

Inspect representative URL classes:

/
 /concepts
 /concepts/{one Concept}
 /research
 /status
 /registry/releases/{version}

Check:

crawl allowed?
index allowed?
user-declared canonical?
Google-selected canonical?
rendered content complete?

Google's URL Inspection tool exposes indexed status, crawl information, canonical information, and live testing.

Use request-indexing sparingly for the handful of highest-value new URLs; Google notes that repeated requests do not accelerate crawling.

Validate structured data with Rich Results Test for Google-supported types and a general Schema.org validator for types such as DefinedTerm that may not produce Google-specific rich results. Google's structured-data tools only imply eligibility for supported experiences, not ranking or display guarantees.

Bing Webmaster launch plan

Add and verify the site in Bing Webmaster Tools, submit the sitemap, and inspect indexing/crawl reports. Bing's Webmaster documentation provides both verification and sitemap submission workflows.

Implement IndexNow for meaningful URL lifecycle events:

Concept published
Concept materially updated
Research report published
Registry release published
Page removed

Do not submit unchanged URLs continuously. IndexNow communicates changes; it does not guarantee indexing. Bing specifically recommends IndexNow as a freshness mechanism for search and AI experiences.

Once sufficient data accumulates, establish baselines from Bing's AI Performance report by cited URL and grounding query.

Post-indexing plan

Initial foundation phase

Publish the canonical architecture before promoting it:

self-canonicals
title/meta templates
Concept URL rules
Concept page template
status vocabulary
human API docs
structured-data base graph
sitemap generation rules
noindex headers for machine/query resources

Publish only governed Concept pages.

Reconcile all visible status values before indexing them.

Early observation phase

Monitor:

discovered vs indexed URLs
Google canonical selection
Bing indexing
brand query presentation
ConceptCode queries
crawler errors
ChatGPT referrals
initial Bing AI citations

Search manually for exact ConceptCodes to verify whether the canonical Concept page becomes the dominant explanatory result.

Entity reinforcement phase

Publish:

/specification
/governance
/registry/releases
/citation
/schema documentation
research artifact pages

Add contextual internal links from every relevant FAQ/research/status mention to Concept pages.

Begin external scholarly/technical citations only through legitimate technical publishing—repositories, papers, project documentation, conference materials, standards discussion—not artificial “mention acquisition.”

Evaluation phase

Run the fixed generative-answer test suite weekly or biweekly across available engines.

Compare errors by class.

Example:

Before:
"Embedded Semantics resolves arbitrary multilingual queries using embeddings."

After:
"Embedded Semantics currently resolves reviewed exact expressions;
embedding-based arbitrary-query retrieval is experimental."

When the second formulation becomes consistently dominant, the architecture is succeeding at more than SEO: it is improving model grounding.

Major risks

Empty-ontology risk. The biggest risk is describing many novel concepts without publishing their canonical entity pages. Search engines can index the marketing/documentation layer but cannot build a strong first-party concept graph.

Deployment ambiguity risk. The 11/55 prerelease manifest versus 0/0 deployed registry is logically explainable but machine-ambiguous.

Illustrative-example risk. Showing a ConceptCode prominently on the homepage before it is deployed can be summarized as proof of production availability unless it is visibly labeled as example/prerelease.

Entity-name ambiguity. “Embedded Semantics” is a descriptive phrase used in broader technical literature, so the site cannot rely on the name alone to establish project identity. Stable project URLs, creator identity, explicit descriptions, sameAs links only for true identity, and consistent branded context become important.

Schema-overconfidence risk. DefinedTerm, SKOS, JSON-LD, and rich graphs improve machine interpretability but do not guarantee rankings or AI citations. Google explicitly warns against overfocusing on special structured data for generative Search.

llms.txt placebo risk. The current file is useful, but treating it as a primary visibility mechanism would divert effort from actual canonical content. Google explicitly ignores it.

API-index bloat risk. Query/result endpoints can generate low-value or near-duplicate searchable resources. Keep them out of the index.

Version-collapse risk. Canonicalizing old research/registry releases to “latest” destroys historical citeability. Immutable versions need durable identities.

Status-semantic drift. If HTML says “experimental,” API says not_production_active, a manifest merely says prerelease, and documentation says “supports,” answer engines may combine the strongest wording. Generate status messaging from one vocabulary.

sameAs misuse. Related projects are not identity aliases. The site's own llms.txt already states this correctly.

Premature authority claims. Research evidence should not be promoted to claims of universality. The current research page explicitly rejects premature universality claims; this should remain a core editorial rule.

GEO cargo cult risk. Formatting tricks, artificial “citation optimization,” mass FAQ production, and AI-specific keyword variants can create low-value pages. Google's 2026 generative Search guidance explicitly says not to pursue many of these tactics.

Prioritized implementation backlog and source register

Implementation backlog

The first implementation sequence I would choose

The first release should not begin with more SEO copy.

It should begin with:

1. Status vocabulary and manifest reconciliation
2. Canonical Concept URI policy
3. Concept-page template
4. First governed Concept corpus
5. Canonicals + sitemap + internal linking
6. Schema.org DefinedTerm graph
7. Human API documentation + API noindex policy
8. Specification/governance pages
9. Versioned registry releases
10. Evidence/citation layer

That sequence turns the website from a description of a semantic system into a web-published semantic system.

Source register

The following are the primary or first-party sources most material to this audit. “Accessed” dates are August 23, 2026 unless otherwise stated.

The overall technical strategy is therefore straightforward even though its implementation is substantial: make the governed Concept—not the homepage, not the embedding, not llms.txt, and not the API query result—the primary web entity. Give every published Concept a persistent human-readable URI; make its machine representations converge on that identity; connect it to a versioned registry, evidence, provenance, creator, project, research, and status graph; and encode production boundaries identically in prose and data.

That architecture does not depend on speculative GEO tricks. It follows conventional indexing principles, W3C publishing practices, Schema.org semantics, current crawler guidance, and the project's own core idea: stable meaning should remain separate from probabilistic evidence.