Embedded Semantics SEO, AEO, GEO, Structured-Data, and Generative-Citation Strategy

Full report

On this page

Executive assessment and audit findings

Audit date: August 23, 2026 Primary site audited: https://embeddedsemantics.com/ Audit mode: fresh public-web audit without source-code or server-console access.

Executive summary. Embedded Semantics already has one unusually strong quality for a novel technical project: its public prose repeatedly distinguishes governed exact resolution from experimental embedding-based semantic retrieval. The homepage says stable ConceptCodes and registry definitions are authoritative while vectors are evidence; the Research, FAQ, About, Status, and llms.txt pages repeat substantially the same boundary. That consistency is exactly the kind of thing that reduces the risk of an answer engine collapsing “research direction” into “shipping capability.”

The principal weakness is more fundamental than title tags or schema: the public concept corpus is currently empty. The Concept Registry reports 0 published concepts, the concept API returns {"count":0,"data":[]}, the status page reports zero published Concepts and zero reviewed exact expressions, and the status API says the semantic runtime is not production-active for arbitrary-query resolution. At the same time, a public prerelease manifest contains eleven Concepts and fifty-five expressions in two source packs. The site explains that those records are not deployed, so this is not literally contradictory; nevertheless, it creates a significant machine-interpretation hazard because a retrieval system that finds the manifest without the Status context can easily summarize “Embedded Semantics has 11 concepts and 55 expressions” as a current production fact.

That is the most important finding of this audit:

Embedded Semantics currently has a good explanatory layer but not yet the public entity corpus that search and answer engines need in order to learn the standard concept-by-concept.

The production wording also needs one refinement. Several pages correctly describe the production resolver design as exact and registry-first, but the live status says there are presently zero deployed Concepts and zero reviewed exact expressions. The safest formulation is therefore: “The production resolver mode is registry-first exact resolution; the current public deployment contains zero production-authoritative records, so positive public resolution becomes available when governed records are deployed.” This distinguishes implementation maturity from corpus availability and removes an otherwise plausible AI-generated inference that the public endpoint can already positively resolve the examples shown on the homepage.

Google's current 2026 guidance is especially important to the strategy. Google says its generative Search experiences remain grounded in core Search systems, that normal SEO remains the foundation, that there are no additional technical requirements for AI Overviews or AI Mode beyond normal indexability and snippet eligibility, that no special schema is needed, and that site owners should not over-focus on techniques such as AI-specific rewriting, unnecessary “AI text files,” or arbitrary content chunking. Google's July 10, 2026 guide explicitly calls out llms.txt as something publishers do not need for Google generative Search.

Bing's current guidance is complementary rather than contradictory. Its February 2026 AI Performance launch says publishers can now see citations, cited URLs, grounding-query samples, and citation trends across supported Microsoft AI experiences; Bing specifically recommends clarity, strong structure, supporting claims with evidence, freshness, and reducing ambiguity across formats. Those are useful AEO/GEO practices, but they should be implemented because they improve the document and its evidence structure—not as keyword-density tricks.

For this report I use four evidence levels:

Overall audit assessment.

The audit's limits matter. I was able to retrieve the public HTML representation, robots.txt, llms.txt, the concept/status API responses, and the registry manifest. sitemap.xml is publicly declared in robots.txt, but the audit client's XML parser did not expose its body, so I cannot honestly certify its exact URL inventory. Likewise, because this is explicitly a source-code-free audit and the public rendering layer did not expose all raw <head> elements or response headers, canonical, Open Graph, meta-description, robots-meta and JSON-LD findings should be treated as “not independently verified,” not “definitively absent.” The post-implementation launch procedure below therefore includes URL Inspection, response-header checks, Rich Results Test, Schema.org validation, and Search Console/Bing verification as mandatory validation steps.

Crawlability, indexability, canonicalization, and metadata

Crawlability audit. The current robots.txt is minimal and syntactically straightforward:

User-agent: *
Allow: /

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

That means there is no site-level robots prohibition in the retrieved file. It is a good default for a project whose purpose is public technical dissemination. The footer also links directly to the sitemap, robots.txt, llms.txt, registry schema, Concept Registry, Status, Research and APIs, so these resources are not hidden from discovery.

Google explicitly recommends allowing crawling, making important pages findable through internal links, and keeping important information in textual form for both normal Search and its AI features. Google also emphasizes that links are used to discover pages and understand page relevance. The site's conventional top navigation and footer therefore provide a good foundation, but they cannot compensate for nonexistent individual Concept pages.

Indexability audit. The most important indexability issue is not a noindex directive visible in the audit—it is that there is currently nothing at the concept-record layer to index. /concepts reports zero published records and /api/v1/concepts confirms zero public records. Until stable Concept pages exist, search engines can understand the project-level proposition but cannot build a strong crawlable document graph around semantic_registry.stable_concept_identity, semantic_registry.hard_negative, mt.core.steganography, and the other governed ConceptCodes listed by Status.

This should not be fixed by manufacturing keyword pages. Google's 2026 generative-search guidance explicitly says publishers do not need a page for every variation of a possible query and warns against AI-specific or scaled-content tactics. A dedicated Concept page is warranted here for a different reason: the Concept itself is a stable first-class entity in the standard. One page per published Concept is information architecture, not keyword expansion.

Canonicalization audit. Current canonical tags could not be conclusively inspected through the rendering interface. The implementation target should nevertheless be unambiguous. Google recommends self-referencing canonicals, consistent internal links to canonical URLs, canonical-only sitemap entries, and supports an HTTP Link: ...; rel="canonical" header for non-HTML representations.

Use this canonical model:

Google's noindex documentation is relevant to the raw JSON resources: for non-HTML resources, X-Robots-Tag: noindex is the appropriate mechanism, and a resource must remain crawlable for a crawler to see that directive. robots.txt should therefore not be used as an indexing-control substitute.

This policy deliberately separates machine accessibility from search-result eligibility. An API can remain publicly fetchable and linked while the human page becomes the preferred search result and citation destination. The intent is not to hide data from answer systems; it is to keep search indexes from choosing an opaque JSON object instead of the page that provides definition, evidence, lifecycle status, context, authorship and citations.

Recommended Concept canonical pattern. Use:

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

rather than inventing a separate keyword slug for every language. The ConceptCode is stable by the project's own architecture, and the preferred label can change independently. That makes the URL a durable entity URI and avoids redirect churn caused by terminology refinements. The site already treats ConceptCode as stable semantic identity.

A separate /id/{ConceptCode} semantic-URI layer is possible, but I would not add that complexity yet. W3C SKOS prefers URI identification for concepts, and the HTML Concept URL itself can serve as that URI. If future formal standardization requires strict distinction between an abstract concept URI and its document representation, /id/ plus content negotiation or 303 redirects can be introduced later.

Multilingual canonicalization. Do not create one SEO page for every translated expression. Expressions are properties/evidence of one Concept. If, later, Embedded Semantics creates genuinely localized full explanatory pages—not merely a label swap—those language pages should be self-canonical within their language and connected with hreflang; they should not all canonicalize to English merely because they share Concept identity. Google specifically advises that hreflang implementations use a canonical in the same language where possible.

Faceted registry URLs. The registry currently exposes search/filter controls. Avoid turning every ?q=, ?language=, or filter combination into an indexable search page. Use client-side state or non-indexable filter states for arbitrary combinations and create ordinary crawlable category pages only when a category has durable editorial meaning, such as a real namespace or domain. This prevents a future faceted crawl space from diluting the Concept pages.

Sitemap recommendations. The current robots file correctly declares https://embeddedsemantics.com/sitemap.xml, but its body could not be inspected by this audit interface. Google recommends putting preferred canonical URLs in the sitemap and stresses that submission is a hint rather than a guarantee of crawling/indexing. Bing likewise recommends maintaining XML sitemaps and monitoring them in Bing Webmaster Tools.

At current scale, keep one simple XML sitemap. It should contain:

/
 /concepts
 /concepts/{every published ConceptCode}
 /status
 /research
 /research/{published research artifacts}
 /faq
 /about
 /contact
 /docs
 /docs/api
 /docs/architecture
 /docs/terminology
 /registry/releases/{version}

Do not put routine API responses, raw schemas, robots.txt, llms.txt, filter/search URLs, or noindexed raw registry packs into the canonical HTML sitemap. Once the Concept corpus grows substantially, a separate sitemap-concepts.xml can improve operational monitoring, but splitting a tiny sitemap provides no inherent ranking benefit. Google says sitemap URL order does not matter.

Use meaningful and accurate <lastmod> values generated from the underlying Concept/research record rather than rebuilding every URL with today's date after each deployment. Bing specifically emphasizes sitemap freshness in AI-powered search and provides sitemap processing information in Webmaster Tools.

Current metadata audit. These page titles are observable in the public representation:

The visible H1s are concise and strongly aligned with page purpose; for example, the homepage says “Stable meaning, across languages,” the registry says “Concept Registry,” and Research says “Measure meaning before claiming universality.”

I would slightly strengthen the homepage <title> by making the brand/entity first-class:

Embedded Semantics — Stable Concept Identity Across Languages

That is an entity-clarity recommendation, not a ranking hack. Concept pages should use:

Stable Concept Identity — Concept Definition | Embedded Semantics

with the stable ConceptCode visible immediately below the H1 rather than necessarily forcing a long machine identifier into every title.

Meta descriptions should tell the truth about capability rather than maximize keyword breadth. An appropriate homepage pattern would be:

Embedded Semantics is a registry-backed multilingual concept-identity system.
Governed exact expressions map to stable ConceptCodes; embedding-based
arbitrary-query retrieval remains experimental.

A Concept description should use the governed definition and status rather than marketing language.

Open Graph metadata. Raw OG tags were not verifiable in the audit interface. Implement or verify at minimum og:title, og:description, og:url, og:type, and an appropriate og:image, with og:url matching the canonical. The Open Graph protocol defines these page-level graph properties; their primary benefit is clean sharing and consistent entity presentation, not a Google ranking bonus.

For Concept pages, generate an image that includes the preferred label and ConceptCode only if it is actually useful to humans. Do not put changing “production” claims into static OG artwork, because social caches can preserve outdated capability information.

Content architecture for Concepts, registry, research, FAQ, evidence, and links

Concept-page architecture. Yes: every publicly published stable Concept should receive a dedicated canonical HTML page. Do not create separate pages for synonyms, translations, arbitrary embeddings, every user query, or every hard negative. The atomic publishing unit is the governed Concept. This aligns the website's document graph with the project's semantic model. The current site already describes Concepts as “first-class records,” but the registry reports zero published records, so this architecture is the site's highest-priority content change.

A Concept page should teach both search engines and answer engines by answering a predictable set of questions in visible text:

Schema.org DefinedTerm is almost tailor-made for the basic public representation: it supports a formal name, description, termCode, inDefinedTermSet, identifier, url, sameAs, and mainEntityOfPage. Importantly, Schema.org validity does not mean Google promises a special rich result for the type. Google says structured data can provide explicit clues about a page but there is no special schema required for generative Search.

What teaches a search engine best? The confirmed foundations are: a stable indexable URL, unique valuable visible content, a crawlable internal-link path, canonical consistency, textual descriptions, a sitemap, and structured data consistent with the visible page. Google specifically states that generative Search still depends on core Search systems and that indexed/snippet-eligible pages are the ones eligible as AI supporting links.

What teaches an answer engine best? The strongest current platform-backed approach is the same foundation plus unambiguous, evidence-bearing prose. Bing explicitly recommends clear structure, tables/FAQ where useful, evidence for claims, freshness, and consistent representation of entities across formats. Answer-first summaries, explicit “is / is not” blocks, non-examples, version dates and evidence blocks are therefore justified. For Google they should be regarded as good technical writing, not as a special GEO markup recipe.

There is also research support for fine-grained, source-attributable content. Controlled GEO work has found that source characteristics such as relevance, evidence/citations and certain factual details can affect citation behavior, while RAG citation research shows the value of fine-grained grounding. However, these experiments are not search-engine ranking specifications and should not be converted into formulaic writing rules.

Draft versus published Concept pages. Use three publication policies:

This avoids both extremes: hiding legitimate technical work and flooding search with automatically generated placeholders. Google's current guidance puts far more emphasis on unique, useful content than on covering every search variation.

Registry-page architecture. /concepts should become a true crawlable directory rather than primarily a filter interface. Once the eleven prerelease records are governed and actually published, emit ordinary anchor links to all eleven Concept pages. At future scale, paginate with real crawlable anchors and maintain stable taxonomy/namespace browse pages. Google's link guidance explicitly says crawlable links help it discover new pages.

The registry page should contain:

• a concise definition of what an Embedded Semantics Concept is;
• an explicit count of published/deployed Concepts, not pack artifacts;
• current registry version and publication date;
• namespaces/domains;
• a crawlable list of Concept labels and ConceptCodes;
• status filters as UI rather than new crawl destinations;
• link to versioned registry release;
• links to Status, methodology, schema and machine dump.

The pack count and deployed count must be visibly differentiated. Today the manifest says eleven Concepts/fifty-five expressions while Status says none are deployed. Make the registry page speak in terms such as “Published registry: 0”, “Prerelease bundle: 11 candidate/governed records, not deployed”, not merely “11 concepts” somewhere without scope.

Research-page architecture. The current Research page is a strong methodological hub: it distinguishes exact production from experimental generalization, describes concept resolution versus generic similarity, names evaluation measures such as Recall@1/5, MRR, cross-language agreement and abstention metrics, and explicitly emphasizes provenance. That content should remain, but it should become the top of a research-document tree instead of the only research artifact.

Recommended tree:

/research
/research/methodology
/research/evaluation-protocol
/research/benchmarks/{benchmark-version}
/research/evaluations/{evaluation-id}
/research/limitations
/research/provenance

/registry/releases/{registry-version}
/registry/changelog

/docs/architecture
/docs/terminology
/docs/namespaces
/docs/capabilities
/docs/api
/docs/data-model

Every benchmark/result page should say what model/version was tested, which registry version, which dataset, which language set, the exact sample size, metrics, confidence/uncertainty where appropriate, exclusions, failure cases and reproduction artifact. The present research page's principle—“every semantic claim should be traceable”—is an excellent editorial rule to elevate into formal publication policy.

Use TechArticle for substantial technical documentation; use ScholarlyArticle only where a page genuinely represents a scholarly paper or preprint, not merely because the project is technical; use Dataset for released benchmarks and registry datasets. This is semantic modeling, not a promise of Google rich-result treatment.

FAQ/AEO architecture. Keep /faq. Its current questions are genuinely useful and unusually precise: “Is an embedding vector the source of truth?”, “Can Embedded Semantics resolve an unseen paraphrase today?”, and “How does the current resolver handle uncertainty?” directly attack likely model hallucinations.

Expand the FAQ based on conceptual confusion, not search volume alone:

What is a ConceptCode?
What is the difference between a Concept and an expression?
Is a ConceptCode an embedding?
What does "reviewed exact expression" mean?
What is unknown_expression?
What is ambiguous_expression?
Can unseen paraphrases resolve in production?
What does "experimental" mean in Embedded Semantics?
What is the difference between a registry pack and the deployed registry?
How are multilingual expressions reviewed?
Can two languages partition a concept differently?
How are Concept definitions versioned?
What happens when a Concept is deprecated?
How are external concept schemes mapped?
How should an Embedded Semantics Concept be cited?

Do not build this around hopes for a FAQ rich result. Google's 2026 generative guidance says no special schema is necessary for AI visibility, and Google's former FAQ rich-result documentation now routes into its Search documentation update history rather than presenting FAQ markup as a general-purpose generative-search tactic.

Evidence/citation architecture. Yes, technical claims should have visible evidence blocks—particularly empirical performance claims, cross-language claims, production capability claims, and statements about model behavior. “Evidence block” should not mean attaching a citation to every marketing sentence. It means making atomic, testable claims traceable.

A recommended block:

Claim
Embedding profile X achieved Y on benchmark Z.

Claim status
Experimental result — not a production capability claim.

Scope
Registry version:
Benchmark version:
Model:
Languages:
Evaluation date:

Method
Exact description of the test and comparison.

Result
Metric:
Numerator / denominator:
Confidence interval or repeated-run information where applicable:

Limitations
Known exclusions, failure modes, external-validity limits.

Evidence
Dataset / release:
Code or reproducibility artifact:
Primary citations:

Last verified
YYYY-MM-DD

W3C PROV-O exists specifically to represent and interchange provenance information and can be used in the richer machine graph to model entities, activities and agents behind registry/evaluation artifacts. That makes it a more appropriate provenance layer than trying to force every research relationship into generic Schema.org properties.

The visible text should also distinguish normative authority from empirical evidence. A governed Concept definition may be authoritative because it is the registry's normative definition; a claim that a particular model retrieves it with 93% Recall@1 is empirical and requires benchmark evidence. Do not blur those two epistemic categories.

Research/scholarly citation architecture. Every substantial technical paper or evaluation should expose:

Title
Author(s)
Author identifiers when available
Project/publisher
Publication type: technical report / preprint / peer-reviewed paper
Publication date
Last revised date
Version
Canonical URL
DOI or persistent archive identifier where one exists
Abstract
Method
Data availability
Code/reproduction availability
References
Cite as
BibTeX
RIS

A preprint must visibly say “preprint” or “not peer reviewed” rather than inheriting the credibility implication of ScholarlyArticle. Versioned datasets should ideally receive durable archival identifiers when the work reaches a state worth external citation.

Fine-grained references are preferable to an undifferentiated references list where claims are empirical: readers and machines should be able to tell which reference supports which assertion. Research on RAG attribution likewise emphasizes fine-grained grounding and citation evaluation, but that is a publishing-quality rationale rather than a guaranteed visibility factor.

Example Concept-page outline.

Breadcrumbs
Embedded Semantics › Concept Registry › Stable Concept Identity

H1: Stable Concept Identity

ConceptCode
semantic_registry.stable_concept_identity

Status
Published / Draft / Deprecated
Registry version
Last reviewed

Direct definition
[governed normative definition]

Current capability relevance
This Concept is part of ...
This statement does NOT imply that arbitrary-query semantic
retrieval is production-active.

Normative definition
...

In scope
...

Not in scope
...

Reviewed expressions
Language | Expression | Relationship | Review state | Provenance

Important distinctions
Not the same as ...
Do not confuse with ...

Related Concepts
Broader ...
Narrower ...
Related ...
External exact/close mappings ...

Evidence and provenance
...

Version history
...

Research and references
...

Machine access
JSON
JSON-LD / SKOS
Registry schema

Cite this Concept
...

Last verified
...

Example Registry-page outline.

H1: Embedded Semantics Concept Registry

Direct definition of the registry

Current published state
Published Concepts: N
Reviewed exact expressions: N
Registry version:
Effective date:

Important status note
Prerelease artifacts are / are not deployed.

Namespaces
semantic_registry
mt
...

Browse all published Concepts
[ordinary crawlable anchors]

Registry release
Version / date / checksum / release notes

How governance works
Definition → review → publication → versioning → deprecation

Machine representations
JSON-LD
SKOS
JSON API
Schema
Release download

Example Research-page outline.

H1: Evaluation of Cross-Lingual Concept Candidate Retrieval

Research status
Experimental — not production-active

Question
...

Hypothesis
...

Registry version
...

Model/profile
...

Dataset and languages
...

Evaluation protocol
...

Metrics
...

Results
...

Failure cases
...

Limitations
...

Production gate
What exact evidence would be required before this capability
could be declared production-ready?

Reproduction
...

References
...

Citation metadata
...

Internal-link architecture. The site should become an entity graph in HTML before it becomes an entity graph in JSON-LD:

                         Home
                          |
              +-----------+-----------+
              |           |           |
           Registry     Research     Status
              |           |           |
        Concept pages  Benchmarks   Capabilities
         /    |    \      |           |
     related related   releases       |
       \      |       /                |
        \----Evidence-----------------/
              |
           API docs
              |
        machine resources

FAQ ----------> Concept pages / Status / Research
About --------> Project entity / Creator
Release pages -> Concepts / Data downloads / Research

Every Concept mention that is conceptually important should link to its Concept page with natural anchor text. “Stable concept identity” on the homepage, for example, should become a direct link once that Concept is published. Contextual body links are more semantically useful than relying only on a footer. Google explicitly uses crawlable links for discovery and relevance understanding.

Do not use sameAs or language implying identity between Embedded Semantics, Protocol5 and JustAnIota. The current llms.txt helpfully says the projects are related surfaces, not aliases. Preserve that distinction in visible HTML and structured data.

Terminology consistency. Establish a project-wide terminology contract:

The last distinction is particularly important. The site should model publication status, deployment status, and evidence maturity as different axes rather than putting everything into one generic “status.”

A machine-safe state could look like:

{
  "registryPublicationStatus": "published",
  "deploymentStatus": "deployed",
  "capabilityStatus": "production",
  "evidenceStatus": "validated"
}

or:

{
  "artifactPublicationStatus": "prerelease",
  "deploymentStatus": "not_deployed",
  "capabilityStatus": "experimental",
  "evidenceStatus": "evaluation_pending"
}

That design would materially reduce the chance that a model mistakes “a prerelease pack exists” for “this capability is running in production.”

Production-versus-experimental claim handling. Put a small visible capability block near the top of every page making runtime-related assertions:

Current capability status

Production resolver mode:
Reviewed exact registry-first lookup.

Current public deployment:
0 published Concepts / 0 reviewed exact expressions.

Experimental:
Embedding-based arbitrary-query candidate retrieval.

Not production-active:
Unseen-paraphrase resolution, semantic reranking, confidence calibration.

Status verified:
2026-08-23

Authoritative live status:
[Status]

The first three claims reflect the current public Status/API state.

Do not hide experimental material with data-nosnippet merely because it is experimental. It is intellectually important content and should be discoverable. Use explicit labels and controlled terminology instead. Snippet-suppression controls are appropriate only where a particular passage genuinely should not be reused in search snippets/AI surfaces; Google documents nosnippet, data-nosnippet and related controls for that purpose.

Content gaps and recommended new pages. The highest-value missing surfaces are:

The new content should emerge from real governed/project knowledge. Do not create dozens of generic “What is semantic X?” articles duplicating Concept pages. Google's 2026 guidance favors unique, expert-led, non-commodity material and specifically says publishers need not write one page for every query fan-out variation.

Structured data, entity graph, and terminology model

Structured-data audit. The public parsed pages did not expose JSON-LD blocks to the audit client. Because raw source access was unavailable, that should be treated as not observed/unverified, rather than a definitive claim that the site emits none. The implementation below should be validated against the actual delivered HTML.

Google says structured data gives explicit clues about page meaning and must describe the visible content to which it applies. Google also states that structured data is not required for its generative Search features and that there is no special AI schema to add. This distinction is central to the strategy: use structured data because Embedded Semantics is inherently entity-oriented and benefits from a clean machine graph—not because JSON-LD is a magic GEO ranking switch.

Recommended page-type mapping.

Schema.org defines DefinedTerm as a term with a formal definition and explicitly recommends name for the term, termCode when it has an assigned alphanumeric code, description for its definition, and inDefinedTermSet for membership in a formal term set. That is an exceptionally close semantic fit for ConceptCode records.

Glossary/DefinedTerm recommendation. Do not build a parallel SEO glossary unrelated to the Concept Registry. The registry is the glossary/defined-term system. Each published Concept page should carry one primary DefinedTerm; /concepts should represent the DefinedTermSet.

Use:

DefinedTerm.name
DefinedTerm.termCode
DefinedTerm.description
DefinedTerm.inDefinedTermSet
DefinedTerm.identifier
DefinedTerm.url
DefinedTerm.mainEntityOfPage
DefinedTerm.alternateName   only for governed aliases where semantically justified
DefinedTerm.sameAs          only for actual identity mappings

Do not use sameAs to mean “related,” “inspired by,” “similar concept,” or “another project by the same creator.” Schema.org describes sameAs as a URL that unambiguously indicates the item's identity.

SKOS layer. For deeper machine-readable semantics, Schema.org should be complemented—not replaced—by W3C SKOS. SKOS provides multilingual prefLabel, altLabel, and hiddenLabel, notations/codes, concept-scheme membership, semantic relationships, and cross-scheme exact/close mappings. W3C explicitly says URIs are preferred for computer identification while notations provide a bridge to existing code systems.

A good mapping is:

Concept page URL                  -> skos:Concept URI
ConceptCode                       -> skos:notation
governed preferred label          -> skos:prefLabel
governed alternative label        -> skos:altLabel
lookup-only lexical variant       -> skos:hiddenLabel, only where semantics fit
normative definition              -> skos:definition
scope limitations                 -> skos:scopeNote
related Concept                   -> skos:related
hierarchy                         -> skos:broader / skos:narrower
external identity equivalence     -> skos:exactMatch
strong but non-identical mapping  -> skos:closeMatch
registry                          -> skos:ConceptScheme

Do not automatically turn every reviewed expression, training paraphrase or retrieval candidate into a SKOS alternate label. The project's evidence model is more nuanced than a thesaurus. Where lexical evidence needs its own identifier, reviewer, provenance, equivalence strength and lifecycle, consider SKOS-XL or a small Embedded Semantics vocabulary plus PROV rather than losing that information in simple strings. W3C's SKOS model explicitly distinguishes preferred, alternative and hidden lexical labels.

Entity-graph recommendation. The core graph should be:

Embedded Semantics WebSite/project
        |
        +---- creator/contact ---- Michael Kappel
        |
        +---- defines/contains --- Concept Registry
        |                              |
        |                              +--- Concept A
        |                              +--- Concept B
        |                              +--- Concept C
        |
        +---- publishes ---------- Registry release
        |                              |
        |                              +--- DataDownload
        |
        +---- publishes ---------- Research article
        |                              |
        |                              +--- cites Dataset
        |                              +--- about Concept
        |
        +---- documents ---------- APIReference
        |
        +---- related project ---- Protocol5
        +---- related project ---- JustAnIota

The current contact page identifies Michael Kappel as project contact, links to MikeKappel.com, GitHub and LinkedIn, and explicitly says MikeKappel.com is the canonical public portfolio. Those verified identity links can anchor the Person entity.

Do not invent an Organization merely because search schemas often use one. If Embedded Semantics is not a legal/organizational entity, model the site/project with WebSite plus the most truthful CreativeWork/software or project representation and connect creator to the Person. Semantic accuracy is more important than forcing a popular schema type.

Project-versus-related-project entity identity. Protocol5 and JustAnIota should be related nodes, not sameAs targets. The site's own llms.txt already explicitly tells machines that these are related project surfaces rather than alternate identities. Replicate that statement in the human About/ecosystem page and machine graph.

Example Concept JSON-LD. The definition below intentionally uses a placeholder so that SEO code never becomes an unauthorized source of semantic truth:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebSite",
      "@id": "https://embeddedsemantics.com/#website",
      "url": "https://embeddedsemantics.com/",
      "name": "Embedded Semantics"
    },
    {
      "@type": "DefinedTermSet",
      "@id": "https://embeddedsemantics.com/concepts#registry",
      "url": "https://embeddedsemantics.com/concepts",
      "name": "Embedded Semantics Concept Registry"
    },
    {
      "@type": "WebPage",
      "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#page",
      "url": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
      "name": "Stable Concept Identity — Concept Definition | Embedded Semantics",
      "isPartOf": {
        "@id": "https://embeddedsemantics.com/#website"
      },
      "mainEntity": {
        "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept"
      },
      "datePublished": "REPLACE_WITH_RECORD_DATE",
      "dateModified": "REPLACE_WITH_RECORD_DATE"
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#concept",
      "url": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
      "name": "Stable concept identity",
      "termCode": "semantic_registry.stable_concept_identity",
      "identifier": "semantic_registry.stable_concept_identity",
      "description": "REPLACE_WITH_THE_GOVERNED_NORMATIVE_DEFINITION",
      "inDefinedTermSet": {
        "@id": "https://embeddedsemantics.com/concepts#registry"
      },
      "mainEntityOfPage": {
        "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity#page"
      }
    }
  ]
}

The DefinedTerm, termCode, description, inDefinedTermSet and mainEntityOfPage choices follow Schema.org's model; the markup must mirror visible content rather than secretly asserting additional facts.

Do not put productionActive: false directly into Schema.org JSON-LD as though it were a Schema.org property. Use either a project-specific JSON-LD context in the separate semantic representation or visible status data modeled with valid generic properties. Keep the Google-facing Schema.org graph standards-valid.

Example machine-oriented SKOS JSON-LD.

{
  "@context": {
    "skos": "http://www.w3.org/2004/02/skos/core#"
  },
  "@id": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
  "@type": "skos:Concept",
  "skos:notation": "semantic_registry.stable_concept_identity",
  "skos:prefLabel": [
    {
      "@value": "Stable concept identity",
      "@language": "en"
    }
  ],
  "skos:definition": [
    {
      "@value": "REPLACE_WITH_GOVERNED_DEFINITION",
      "@language": "en"
    }
  ],
  "skos:inScheme": {
    "@id": "https://embeddedsemantics.com/concepts"
  }
}

JSON-LD is a W3C Recommendation specifically designed as a JSON serialization of Linked Data and supports language-tagged values, making it a reasonable interchange format for this layer.

Keep the in-page Schema.org block and the richer SKOS/PROV representation conceptually synchronized but operationally separable. Trying to force every internal research/evidence relationship into the Google-facing JSON-LD usually makes validation and governance harder.

Version/provenance graph. A registry release should be a versioned entity with fields such as:

{
  "releaseId": "embedded-semantics.public-registry-prerelease",
  "releaseVersion": "prerelease",
  "artifactStatus": "prerelease",
  "deploymentStatus": "not_deployed",
  "publishedConceptCount": 0,
  "artifactConceptCount": 11,
  "publishedReviewedExactExpressionCount": 0,
  "artifactExpressionCount": 55,
  "generatedAt": "2026-08-23T...",
  "sha256": "...",
  "sourceRegistryVersion": "...",
  "supersedes": null
}

That is deliberately more explicit than the current manifest's generic counts.concepts: 11 and counts.expressions: 55. The current status API already gives the crucial complete:false, presentConcepts:0, expectedConcepts:11, presentReviewedExactExpressions:0 and expected...:55; promoting those distinctions into every machine resource would make decontextualized summaries safer.

Machine-readable documentation, llms.txt, APIs, and crawler controls

Machine-readable documentation architecture. Embedded Semantics is exactly the type of project that benefits from a multi-representation architecture, provided one representation is declared authoritative for each kind of fact.

Recommended hierarchy:

Human / citation layer
/concepts/{ConceptCode}
/status
/research/...
/registry/releases/{version}
/docs/api
/docs/data-model

Search-oriented structured semantics
in-page Schema.org JSON-LD

Knowledge-organization layer
/registry/embedded-semantics.skos.jsonld
/registry/embedded-semantics.ttl

API representations
/api/v1/concepts
/api/v1/concepts/{ConceptCode}
/api/v1/status
/api/v1/resolve

Specification resources
/openapi.json
/schemas/...
/context/v1.jsonld       if a project vocabulary is needed

Versioned datasets
/registry-packs/...
/benchmarks/...

Discovery/orientation
/llms.txt
/sitemap.xml

Citation
/citation
/citation.bib
/citation.ris

W3C JSON-LD provides an interoperable Linked Data serialization, while SKOS provides a mature model for concept schemes and PROV provides interoperable provenance modeling. Those standards provide a much stronger long-term semantic foundation than inventing an SEO-only custom JSON format.

Machine authority hierarchy. Publish an explicit authority statement:

Normative Concept meaning
    Concept registry record + governed definition

Current runtime capability
    /status and /api/v1/status

Artifact/release composition
    versioned registry release + manifest

Human technical explanation
    /docs and /research

Lexical/model/evaluation evidence
    evidence records and provenance graph

llms.txt
    orientation only; never normative

The current llms.txt already says ConceptCode plus registry definition are authoritative and expressions, embeddings, scores, prototypes and model metadata are evidence. Keep that rule and expand it to state that Status is authoritative for current deployment capability and the release manifest is authoritative only for the contents of that release artifact.

llms.txt analysis. The existing file is good as an orientation document. It concisely gives the production/experimental boundary, links core pages, distinguishes related projects from aliases, enumerates machine endpoints, and says what is semantically authoritative.

What llms.txt realistically accomplishes, however, must be stated conservatively. Google's July 2026 guidance explicitly says publishers can ignore unnecessary AI text files such as llms.txt for Google generative Search. Google says there is no special AI markup/file requirement. OpenAI, Anthropic and Perplexity's public crawler controls center on robots.txt user agents rather than presenting llms.txt as an indexing/ranking requirement.

Therefore:

Confirmed: llms.txt is not needed for Google AI Search visibility.

Not confirmed: there is no basis in the primary crawler documentation reviewed here for claiming that publishing llms.txt causes ChatGPT, Claude or Perplexity to index, rank or cite a site more often.

Reasonable optional use: retain it because tools, agents, developers or future systems may voluntarily consume a concise orientation file. Treat it like an automatically generated project map, not a ranking lever.

Generate llms.txt from the same configuration/data used by Status rather than hand-maintaining capability statements in yet another location. Drift is the main risk. Add:

## Authority
- Current deployment status: https://embeddedsemantics.com/status
- Machine deployment status: https://embeddedsemantics.com/api/v1/status
- Concept definitions: canonical Concept pages and registry records
- Registry bundle manifests describe artifacts and do not imply deployment.

## Citation preference
- Cite human Concept pages for Concept definitions.
- Cite /status for current production capability.
- Cite versioned research/release pages for empirical findings.

API audit. Publicly retrievable responses currently establish:

GET /api/v1/concepts

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

and Status reports zero active embeddings, no languages/domains, exact-registry-first production mode, no configured semantic runtime, zero present public Concepts/expressions, and eleven/fifty-five expected from the prerelease public bundle.

The manifest, by contrast, identifies a prerelease bundle with eleven Concepts and fifty-five expressions and lists a five-Concept starter pack and six-Concept FugitiveAI pilot projection.

The API architecture is technically useful but the site's global “API” navigation currently routes directly to the raw Concept API. A human visitor—or a search result—should instead reach an indexable /docs/api page containing endpoint purpose, method, parameters, response schema, status semantics, examples, versioning and links to canonical Concepts. The raw endpoint remains available underneath. The homepage currently exposes that raw API link in both navigation and footer.

API-indexing recommendations.

This recommendation uses Google's documented X-Robots-Tag mechanism for non-HTML resources and its support for HTTP canonical Link headers.

A Concept JSON response should include canonical identity explicitly:

{
  "conceptCode": "semantic_registry.stable_concept_identity",
  "canonicalUrl": "https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity",
  "registryUrl": "https://embeddedsemantics.com/concepts",
  "publicationStatus": "published",
  "registryVersion": "...",
  "definition": "...",
  "lastModified": "...",
  "machineRepresentations": {
    "jsonld": "...",
    "skos": "..."
  }
}

Return HTTP link relationships where infrastructure permits:

Link: <https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity>; rel="canonical"
Link: <https://embeddedsemantics.com/concepts/semantic_registry.stable_concept_identity.jsonld>; rel="alternate"; type="application/ld+json"

OpenAI crawler policy. OpenAI currently documents separate controls. OAI-SearchBot is used to surface websites in ChatGPT search results; GPTBot relates to content that may be used for foundation-model training; and OpenAI says those preferences are independent. OpenAI recommends allowing OAI-SearchBot, together with requests from its published IP ranges, when a publisher wants its content eligible for ChatGPT search.

That means the site owner can make an explicit policy choice:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Allow: /

if both search discovery and training are desired, or:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

if search visibility is desired but training crawling is not. OpenAI explicitly documents that separation.

The current wildcard Allow: / does not express such a distinction; it is effectively an open policy for compliant bots.

Anthropic crawler policy. Anthropic documents three different agents as of April 7, 2026: ClaudeBot for content that could contribute to model development/training, Claude-User for user-directed access, and Claude-SearchBot for search-result quality. Anthropic says all three honor robots directives, with the expected loss of training, user-directed access, or search visibility depending on which is blocked.

For maximum public technical discoverability:

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

Then make a separate owner-policy decision about:

User-agent: ClaudeBot
Allow: /

or Disallow: /. That is a governance choice, not an SEO requirement.

Perplexity crawler policy. Perplexity says PerplexityBot is designed to surface/link websites in its search results and is not used for foundation-model training. It recommends allowing the bot and its published IP ranges. Perplexity-User handles user-triggered retrieval and, according to Perplexity, generally ignores robots because the user initiated the fetch.

For search visibility:

User-agent: PerplexityBot
Allow: /

and verify legitimate traffic against Perplexity's maintained IP source rather than trusting User-Agent strings alone.

Google/Bing controls. Do not create bot-specific directives simply to “activate AI.” Google says normal Googlebot/Search indexing controls govern eligibility for AI features in Search; snippet/noindex controls can constrain how content appears.

The practical crawler policy should therefore be written around owner intent:

# Normal public search
User-agent: *
Allow: /

# Explicit search/answer crawlers
User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

# Training crawlers: choose deliberately
User-agent: GPTBot
Allow: /       # or Disallow: /

User-agent: ClaudeBot
Allow: /       # or Disallow: /

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

Do not blindly copy this until the site's AI-training policy is consciously decided. Search access and training consent are separate questions on platforms that expose separate agents.

Generative-search strategy, measurement, and launch plan

GEO/generative-search recommendations. The strategy should deliberately separate confirmed platform guidance from experimental optimization ideas.

Google's current guidance supports the first six distinctions, while Bing's AI Performance guidance directly recommends clarity, evidence, freshness and reduced ambiguity for AI citation use.

Academic GEO results are useful but must be treated as research. The 2024 ACM GEO work tested interventions such as citations, quotations, statistics and writing quality and reported visibility effects in controlled generative-engine settings. A 2026 competitive-GEO study using controlled two-document experiments across multiple models found that topical relevance and source position were major citation drivers, with some benefits from recency and concrete factual information. These studies demonstrate that document properties can affect citation behavior; they do not establish universal ranking factors for Google AI Mode, ChatGPT, Claude, Copilot or Perplexity.

SourceBench likewise evaluates AI-cited sources along dimensions such as relevance, factual accuracy, objectivity, freshness, authority/accountability and clarity. That strengthens the rationale for rigorous technical publishing but still does not turn those dimensions into platform requirements.

For Embedded Semantics, the safest GEO principle is therefore:

Optimize extractability of true, scoped, attributable facts—not prose designed to manipulate a model into citing you.

A strong Concept page should make these atomic statements easy to extract independently:

Definition:
X means ...

Identifier:
Its ConceptCode is ...

Current status:
This Concept is published / draft / deprecated.

Production fact:
The current production resolver supports ...

Non-capability:
Arbitrary unseen-query retrieval is experimental.

Evidence:
This result was measured using ...

Limitation:
This result does not establish ...

That structure is particularly valuable here because the cost of an AI system conflating “experimental semantic embedding research” with “production semantic resolution” is much higher than the cost of not ranking for an extra query.

Hallucination-resistance strategy. Build deliberate contradiction-prevention into the publishing system:

1. One source of truth should generate the human Status page, status JSON, homepage capability badge and llms.txt capability summary.
2. Every capability statement should carry a controlled state rather than free-form terms.
3. Every prerelease artifact should say whether it is deployed.
4. Concept publication status and runtime capability status must remain separate.
5. Every research result should identify model/profile, registry version and evaluation date.
6. The current-state page should link historical versions rather than silently replacing their status.
7. Old capability pages should preserve historical dates and say “historical,” not look like current documentation.
8. Machine JSON should use explicit negative booleans/state terms—not merely omit unsupported capabilities.

Those are architectural recommendations rather than search-engine requirements, but they directly address the project's stated hallucination-resistance objective.

Measurement plan. Measure three layers independently.

Search discovery metrics:

Google advises using Search Console for technical diagnostics; Bing Webmaster Tools similarly exposes indexing and crawl diagnostics.

Generative citation metrics:

Bing's AI Performance dashboard now exposes total citations, average cited pages, sample grounding queries, page-level citation activity and trends across supported AI experiences, making it a particularly direct first-party measurement source.

Google's newer July 2026 guide says the Search Console Generative AI performance report can be used to measure discovery through Google's generative Search experiences; that guidance is newer than its December 2025 AI-features documentation that described AI-feature traffic in the general Web performance report. Follow the current July 2026 documentation in the live account.

Semantic integrity metrics:

HTML definition == API governed definition
HTML ConceptCode == API ConceptCode
HTML status == status API status
JSON-LD mainEntity == canonical Concept
manifest deployment state == Status interpretation
llms.txt capability boundary == Status capability boundary
sitemap URLs == canonical indexable HTML set
SKOS labels == governed lexical records

Run those as automated release tests. For Embedded Semantics, that consistency suite is probably more valuable than a traditional keyword-density audit.

Manual answer-engine evaluation suite. Maintain a dated, versioned set of approximately thirty to fifty prompts spanning:

Definition
"What is Embedded Semantics?"

Concept identity
"What is stable concept identity?"

Contrast
"Is a ConceptCode an embedding vector?"

Production capability
"Can Embedded Semantics resolve unseen paraphrases?"

Status
"How many Concepts are currently deployed?"

Artifact-versus-runtime
"How many concepts are in the prerelease bundle,
and are they production-deployed?"

Multilingual semantics
"Do translations share a ConceptCode?"

Abstention
"What does unknown_expression mean?"

Research
"How is cross-language semantic retrieval evaluated?"

Limitations
"Does Embedded Semantics claim language-neutral meaning?"

Creator
"Who created / maintains Embedded Semantics?"

Citation
"What primary source defines Concept X?"

For each engine/date, capture cited URLs, answer text, factual correctness, production/experimental classification and whether the cited page actually entails the answer. This is a measurement framework, not an attempt to reverse-engineer a permanent ranking algorithm.

Search Console/Bing Webmaster launch plan.

At launch:

Google Search Console

Verify the domain property, submit the canonical XML sitemap, inspect /, /concepts, /status, /research, /docs/api and several representative Concept pages, confirm Google's selected canonical matches the declared canonical, and validate rendered content/structured data. Google says sitemap submission is a hint rather than an indexing guarantee and recommends Search Console for AI/Search technical diagnostics.

Do not manually request indexing for hundreds of generated pages. For the initial small Concept corpus, requesting a recrawl for the major new canonical pages is reasonable; subsequent discovery should flow through the sitemap and internal links.

Bing Webmaster Tools

Verify/import the site, submit the same canonical sitemap, review Site Explorer/URL diagnostics, and enable IndexNow for additions, meaningful updates and deletions. Bing's current Webmaster documentation emphasizes sitemap monitoring, indexing diagnostics and AI visibility, while its AI Performance feature now supplies citation metrics.

IndexNow should publish only canonical URLs whose state actually changed. Do not ping every Concept on every deployment if the records are unchanged.

Crawler-log validation

After crawler-policy changes, verify:

Googlebot
bingbot
OAI-SearchBot
Claude-SearchBot
Claude-User
PerplexityBot

against vendor guidance and, where vendors publish it, their current IP data. OpenAI and Perplexity explicitly publish crawler IP information; Anthropic documents bot identification and robot controls.

Post-indexing plan.

Initial foundation phase — launch through roughly two weeks.

The first goal is not content volume. Reconcile all current-state semantics; deploy genuinely publishable Concept records; give each a canonical page; implement canonical tags, metadata and JSON-LD; build /docs/api; create a verified XML sitemap; verify GSC/BWT; establish crawler access and logging; validate the entity graph; and add automated consistency checks.

The single release gate should be:

No Concept or capability goes public unless its HTML, API, structured-data and Status representations agree.

Entity-and-evidence phase — following weeks.

Publish the first versioned Registry release landing page, machine SKOS/JSON-LD export, architecture/terminology/capability documentation, a formal evaluation protocol, provenance model and citation instructions. Add evidence blocks to any empirical research claims. Do not wait for a large corpus; eleven high-quality governed Concepts are much more useful than hundreds of autogenerated pages.

Citation-development phase — middle of the ninety-day window.

Publish genuinely reference-worthy material: benchmark methodology, reproducible evaluation results, precise failure analyses, cross-language case studies and versioned registry releases. The goal is to create primary technical sources that external researchers and developers can legitimately cite. Independent citations and discussion should be earned from useful artifacts rather than solicited as synthetic “brand mentions.” Google's 2026 guidance explicitly warns against inauthentic mention-seeking.

Evaluation-and-refinement phase — final month.

Compare indexed Concept counts with published counts, inspect canonical selection, review Bing AI citations and Google generative performance, run the manual answer-engine test suite, calculate hallucinated-capability and stale-status rates, examine which pages—not which keywords—are being used as sources, and revise pages whose definitions or evidence are ambiguous.

Do not change authoritative definitions merely because a model is more likely to cite different wording. If a retrieval system misunderstands a technically necessary definition, improve surrounding disambiguation and examples while preserving the governed definition.

Risks, implementation backlog, and source register

Major risks.

Highest risk — artifact/runtime ambiguity. The prerelease manifest contains eleven Concepts/fifty-five expressions while the public deployed registry contains zero/zero. Humans can understand the distinction because /status explains it, but retrieval systems may encounter the manifest independently. Add explicit artifactCount, deployedCount, deploymentStatus, asOf and human status references everywhere.

High risk — empty canonical concept corpus. The site talks about stable first-class Concept identity while exposing no published individual Concepts through the live registry. Until that changes, engines have little primary entity-level material to index or cite.

High risk — “production” interpreted as positive availability. The production resolver architecture is exact and registry-first, but its public authoritative corpus is currently empty. Rewrite current-capability summaries to distinguish production mode from data deployment.

High risk — raw JSON becoming the citation surface. The global API link currently exposes raw JSON directly. A human /docs/api page and human canonical Concept/Status pages should be the preferred citation targets.

Medium-high risk — unsupported structured-data expectations. DefinedTerm, SKOS and JSON-LD are highly appropriate here, but Google explicitly says no special schema is required for generative Search. Treat them as semantic/document-quality infrastructure, not a ranking hack.

Medium-high risk — publication-status conflation. “Published,” “prerelease,” “deployed,” “production,” “experimental” and “validated” describe different dimensions. A single status field invites false equivalence.

Medium risk — thin auto-generated Concept pages. Dedicated Concept pages are justified only because Concepts are real entities. Never turn each expression, query variation or provisional vector into a separate page. Google's current guidance explicitly rejects the premise that publishers need pages for every fan-out/query variation.

Medium risk — multilingual duplication. Language-specific expressions belong to one Concept unless there is genuinely localized explanatory content. Future localized full pages need coherent hreflang and canonicalization.

Medium risk — abusing sameAs. External concept mappings and related projects are not automatically identities. Use SKOS mapping relationships and true sameAs only when identity is warranted.

Medium risk — llms.txt false confidence. It is currently useful editorially, but Google explicitly says it is unnecessary for generative Search, and reviewed AI crawler docs do not establish it as a citation-ranking control.

Medium risk — research claims becoming timeless facts. Every evaluation needs model, registry, dataset, date and limitations so an engine does not cite a 2026 experimental score as a permanent property of the standard.

Medium risk — WAF/CDN crawler mismatch. robots.txt can allow a bot while infrastructure still blocks it. Google explicitly mentions CDN/hosting access as part of AI-feature crawl eligibility, and OpenAI/Perplexity publish IP guidance for their search crawlers.

Prioritized implementation backlog.

The first implementation milestone should not be “add more SEO text.” It should be:

One coherent public truth model: published Concepts have canonical pages; current capability has one authoritative status; prerelease artifacts cannot be mistaken for deployment; every machine representation identifies its human citation target.

That change simultaneously addresses SEO, AEO, GEO, machine-readable documentation, scholarly citation and hallucination resistance.

Source register. The sources below prioritize primary platform documentation, Web standards and primary research, as requested. Dates are publication/update dates where the source exposes one; otherwise the source was accessed August 23, 2026.

The strategic hierarchy that follows from those sources is clear: normal crawl/index/canonical quality is the prerequisite; canonical Concept pages and rigorous technical publishing are the substance; Schema.org/SKOS/PROV make the entity and evidence graph explicit; machine resources improve interoperability; llms.txt is optional orientation; and GEO-specific tactics remain secondary and experimental unless a platform explicitly documents them. Google's current guidance directly rejects the premise that generative visibility requires special AI files, special schemas, query-variation pages or AI-specific rewriting, while Bing's current first-party tooling makes citation measurement and evidence-oriented content quality increasingly measurable.