LLM Wikis As Mind Maps For AI - Source Excerpt 03 - Information architecture and SEO design

Back to LLM Wikis As Mind Maps For AI

Summary

This source excerpt begins near Information architecture and SEO design and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md

This diagram is a synthesis of Google’s hierarchy/breadcrumb model, graph-style note navigation patterns, and graph-aware retrieval flows. citeturn24view2turn25view1turn28view6turn2search4turn24view5

## Information architecture and SEO design

The core IA rule is simple: **one important node, one canonical URL, one visible page**, even if the same content also appears in graph views, summaries, or API results. Google recommends picking one canonical URL per page, putting canonicals in HTML or headers, linking internally to the canonical version, and including preferred canonicals in sitemaps. That guidance is especially important for interactive graph products because filters, path visualizations, and parameterized canvases can otherwise create duplicate or near-duplicate states. citeturn24view0turn24view3turn25view5

The public URL scheme should be human-readable and machine-stable. Google recommends simple URL structures, lowercase normalization, and hyphen-separated words rather than underscores; it also warns that excessive parameters, session IDs, and other irrelevant query strings can produce large duplicate URL spaces and waste crawl resources. For a mind-map wiki, that means graph state should usually be **progressive enhancement** on top of a clean canonical page, not a new indexable URL for every zoom, filter, or layout. citeturn25view4turn25view5turn24view0

A robust metadata model for node pages can be expressed with generic web standards plus domain-specific fields. Schema.org provides the common structured-data vocabulary and supports JSON-LD; Google recommends JSON-LD when possible and requires that structured data reflect user-visible page content. Multiple user-visible items can be marked up on one page, such as the page itself plus breadcrumb information. For concept-heavy wiki nodes, the most practical pattern is usually to combine page-level types such as `WebPage` or `CollectionPage` with auxiliary graph objects such as `BreadcrumbList`, and then optionally include domain-specific types like `DefinedTerm`, `FAQPage`, `Dataset`, `Organization`, or `ProfilePage` when they genuinely match the visible content. citeturn26view0turn26view1turn31view0turn31view1turn31view2

A recommended node schema is below. This is a design proposal, not a web standard, but it aligns with semantic wiki, RDF, and structured-data practice.

| Field | Purpose |
|---|---|
| `node_id` | Stable internal ID that never changes even if slug or title changes |
| `slug` | Human-readable path component used in canonical URLs |
| `title` | Primary display label |
| `summary` | One- or two-sentence orientation text |
| `node_type` | `hub`, `concept`, `entity`, `task`, `source`, `faq`, `dataset`, `api_ref`, `glossary_term` |
| `canonical_url` | Preferred public URL |
| `lang` | Locale code |
| `parent_id` | Primary hierarchy parent for breadcrumbing |
| `aliases[]` | Alternative names and redirect terms |
| `relations[]` | Typed outgoing edges with target IDs and optional weights |
| `citations[]` | Source IDs or references used to support the node |
| `updated_at` | Last substantive update timestamp |
| `visibility` | `public`, `internal`, `private` |
| `embedding_ref` | Pointer to embedding/vector record |
| `entity_ids[]` | Optional references to normalized entities in a KG |

The corresponding ER model should keep nodes, relations, aliases, versions, and embeddings separate enough that the graph can evolve without breaking URLs.

' ' ' mermaid
erDiagram
    NODE ||--o{ RELATION : source
    NODE ||--o{ RELATION : target
    NODE ||--o{ ALIAS : has
    NODE ||--o{ PAGE_VERSION : versions
    NODE ||--o{ EMBEDDING_RECORD : indexed_by

    NODE {
      string node_id
      string slug
      string title
      string node_type
      string canonical_url
      string parent_id
      string lang
      datetime updated_at
      string visibility
    }

    RELATION {
      string relation_id
      string source_node_id
      string target_node_id
      string relation_type
      float weight
      string rationale
    }

    ALIAS {
      string alias_id
      string node_id
      string alias_text
      string lang
    }

    PAGE_VERSION {
      string version_id
      string node_id
      string status
      datetime published_at
    }

    EMBEDDING_RECORD {
      string embedding_id
      string node_id
      string model
      string store_name
    }
' ' ' 

Human-facing URL patterns should prefer clean resource classes and locale prefixes where needed. The examples below follow Google’s URL and localization guidance.

' ' ' text
/en/ai/
/en/ai/llm-wikis/
/en/ai/llm-wikis/mind-map-navigation/
/en/concepts/knowledge-graph/
/en/concepts/rag/
/en/tasks/build-an-ai-wiki/
/en/sources/graphrag-paper/
/id/n_01J8Z0D3H2Q9A2W7K3M4/
' ' ' 

If the site is multilingual, Google allows equivalent `hreflang` signaling through HTML, HTTP headers, or XML sitemaps, and explicitly notes that one method is enough. Locale-specific subdirectories are a strong default for docs-style sites. citeturn25view0turn25view4

For structured data, the following JSON-LD pattern is a strong default for a canonical concept page. It is intentionally conservative and uses page types that map cleanly to visible content.

' ' ' json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "CollectionPage",
      "@id": "https://example.com/en/ai/llm-wikis/#page",
      "url": "https://example.com/en/ai/llm-wikis/",
      "name": "LLM Wikis",
      "inLanguage": "en-US",
      "isPartOf": {
        "@id": "https://example.com/en/ai/#page"
      },
      "about": [
        { "@id": "https://example.com/id/knowledge-graph" },
        { "@id": "https://example.com/id/rag" }
      ],
      "breadcrumb": {
        "@id": "https://example.com/en/ai/llm-wikis/#breadcrumb"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/en/ai/llm-wikis/#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "AI",
          "item": "https://example.com/en/ai/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "LLM Wikis",
          "item": "https://example.com/en/ai/llm-wikis/"
        }
      ]
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://example.com/id/knowledge-graph",
      "name": "Knowledge graph",
      "inDefinedTermSet": "https://example.com/en/glossary/"
    }
  ]
}
' ' ' 

That pattern is consistent with Schema.org’s JSON-LD support, Google’s recommendation for JSON-LD, Google’s breadcrumb markup guidance, and the principle that the markup should reflect visible page content. citeturn26view0turn26view1turn31view0turn24view2turn31view1

Sitemaps should list **canonical URLs only**, not every interactive state. Google says sitemap URLs are canonical preferences and merely hints for crawling, while the Sitemap protocol requires UTF-8 XML and host consistency within a sitemap file. For localized pages, alternate locales can be expressed directly in the sitemap. citeturn24view3turn26view2turn25view0

' ' ' xml
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://example.com/en/ai/llm-wikis/</loc>
    <lastmod>2026-05-11</lastmod>
    <xhtml:link rel="alternate" hreflang="en-us"
                href="https://example.com/en/ai/llm-wikis/"/>
    <xhtml:link rel="alternate" hreflang="de-de"
                href="https://example.com/de/ki/llm-wikis/"/>
  </url>
  <url>
    <loc>https://example.com/en/concepts/knowledge-graph/</loc>
    <lastmod>2026-05-11</lastmod>
  </url>
</urlset>
' ' ' 

The sitemap tree below shows the right shape: a small number of top-level hubs, clean subdirectories, and leaf nodes that correspond to canonical pages rather than transient graph states.

' ' ' mermaid
flowchart TD
    root["/"]
    root --> ai["/en/ai/"]
    ai --> llm["/en/ai/llm-wikis/"]
    llm --> mapnav["/en/ai/llm-wikis/mind-map-navigation/"]
    llm --> seonav["/en/ai/llm-wikis/seo-crawlability/"]
    llm --> apinav["/en/ai/llm-wikis/agent-interfaces/"]
    root --> concepts["/en/concepts/"]
    concepts --> kg["/en/concepts/knowledge-graph/"]
    concepts --> rag["/en/concepts/rag/"]
    concepts --> graphrag["/en/concepts/graphrag/"]
    root --> tasks["/en/tasks/"]
    tasks --> build["/en/tasks/build-an-ai-wiki/"]
    root --> sitemap["/sitemap.xml"]
' ' ' 

## AI navigation interfaces and evaluation