Improving AIWikis Org And LLMWikis Org Guidance, Setup Wizard, And Site Structure

The sampled public surfaces already express a valuable domain split: **LLMWikis.org** positions itself as the handbook for creating and governing LLM Wikis, while **AIWikis.org** positions itself as a transparent demo...

Metadata

Field	Value
Source site	llmwikis.org
Source URL	https://llmwikis.org/
Canonical AIWikis URL	https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-2f49aa61/
Source reference	raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-11/Improvement/handoff-recovery-wizard-guidance/Improving AIWikis.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-05-11T13:16:50.0613669Z
Content hash	sha256:2f49aa61e6cbcb51fe98023fc865e9578588b599c0088f830c4d356759258186
Import status	unchanged
Raw source layer	data/sources/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-11-imp-2f49aa61e6cb.md
Normalized source layer	data/normalized/llmwikis/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2026-06-13-2026-05-11-imp-2f49aa61e6cb.txt

Current File Content

Structure Preview

• Improving AIWikis.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure
• Executive summary
• Current state diagnosis
• Proposed information architecture and URL schema
• Proposed site hierarchy
• URL schema options
• Recommended canonical URL rules
• Canonicals, redirects, and indexation policy
• Guidance and setup wizard redesign
• Proposed wizard flow
• Required metadata for all public pages
• Automated taxonomy suggestions and slug generation
• Content templates, naming conventions, and discovery
• Recommended public page types
• Naming conventions
• Internal linking and cross-page discovery
• Transclusion policy
• Migration, governance, and quality control
• Migration plan
• Example redirect policy
• Governance and editorial workflow
• Metrics and QA tests
• Phased implementation roadmap
• Open questions and limitations

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 40209
• Preview characters: 11798

# Improving AIWikis.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure

## Executive summary

The sampled public surfaces already express a valuable domain split: **LLMWikis.org** positions itself as the handbook for creating and governing LLM Wikis, while **AIWikis.org** positions itself as a transparent demonstration, provenance, and dogfood layer for source-governed AI memory systems. That conceptual separation is explicit in site copy, but it is not yet enforced strongly enough in navigation, taxonomy, URL design, or canonicalization. AIWikis still exposes overlapping concept pages and recovered summaries of LLMWikis materials, while topic indexes mix concepts, logs, source proxies, provenance items, and cross-domain pages in the same browse surface. The result is a system that is intellectually rich but operationally harder to navigate, harder to scale, and more vulnerable to duplicate-intent SEO problems than it needs to be. citeturn4view1turn7view1turn14view1turn19view0turn25view3

The most important strategic recommendation is to turn the current **implicit role split** into an **explicit information architecture contract**. In practice, that means making **LLMWikis.org the canonical instructional domain** for concepts, guides, reference standards, templates, and tools, and making **AIWikis.org the canonical evidence domain** for provenance, source records, audit trails, recovered content, and cross-site memory operations. Google’s canonicalization guidance is clear that preferred URLs should be reinforced with canonicals, redirects, and sitemap inclusion rather than relying on body copy alone. Google also recommends descriptive titles, unique descriptions, crawlable internal links, breadcrumb trails, and carefully planned site moves when URLs change. citeturn25view3turn37view1turn35view1turn35view3turn25view1turn25view4turn37view0

The current **setup wizard** is promising, but it asks for advanced architecture, graph, workspace, and policy decisions very early and in a dense format. Its current public form already combines setup-mode selection, audience, scope, workspace rules, Git preflight, context-budget policy, large-file policy, knowledge-graph strategy, handoff strategy, and support boundaries in a single experience. Official guidance for complex forms favors asking only what is necessary, using branching, and starting with one thing per page. The wizard should therefore become a progressive-disclosure system that first captures site role, scope, audience, page types, taxonomy, and URL policy, and only then reveals advanced branches for multisite work, provenance capture, GraphRAG, or Project Handoff. citeturn32view0turn32view1turn32view3turn34view0

The highest-return implementation sequence is straightforward. First, define page types, naming standards, canonical ownership, and a hierarchical URL policy. Second, redesign navigation and breadcrumbs around that taxonomy. Third, refactor the wizard so it generates templates, slugs, aliases, canonicals, redirects, breadcrumbs, and metadata from the same registry. Fourth, migrate old URLs with permanent redirects and updated internal links. Fifth, institutionalize governance, QA, and measurement through Search Console, Lighthouse, and editorial review. That sequence aligns with Google’s advice to prepare URL mappings, change one thing at a time, and monitor the move. citeturn40view0turn37view0turn37view1turn39search0turn39search18

A stack note is warranted. LLMWikis.org’s public `robots.txt` suggests at least some WordPress-style infrastructure, but this report remains intentionally stack-agnostic because the underlying implementation stack is otherwise unspecified. The recommendations below are therefore framed as architecture and governance patterns that can be implemented in WordPress, GitBook, Docusaurus, MkDocs, MediaWiki, or custom docs-as-code systems. citeturn8view0turn25view14turn25view15turn25view16turn25view17

## Current state diagnosis

The strongest current asset is conceptual clarity: LLMWikis.org clearly says it is a practical LLM Wiki creation handbook, while AIWikis.org says it is a transparent demonstration and documentation hub for source-governed AI memory systems and explicitly states that it does not replace the canonical sources. The problem is that the public content model still lets those roles blur at the URL and page-type level. citeturn7view1turn4view1

| Area | What is happening now | Why it is a problem | Priority |
|---|---|---|---|
| Domain role overlap | AIWikis states that LLMWikis remains the handbook source, yet AIWikis still publishes pages such as `What Is an LLM Wiki` and recovered summaries like `LLM Wiki README` that derive from LLMWikis material. citeturn4view1turn30search1turn14view1 | Two domains compete for closely related user intent. This weakens topic ownership and muddies canonical signals. | High |
| Navigation overload | AIWikis home and browse pages foreground many related sites and long “start” lists; LLMWikis pages repeat large global section lists and source-map links in addition to page content. citeturn4view1turn12view0turn7view1turn6view0 | Users get a lot of routes, but not enough prioritization. Important tasks are discoverable, but not always *obvious*. | High |
| Taxonomy mixing | AIWikis `Topic Index` mixes concepts, reports, ingest logs, source proxies, logos, guidance pages, and cross-site items in one flat list. It even says it provides “short retrieval handles,” while many listed titles are long and highly specialized. citeturn19view0 | The taxonomy is doing too many jobs at once: page-type inventory, concept map, provenance index, and cross-site catalog. That hurts both findability and maintainability. | High |
| Source taxonomy incompleteness | `Source Map` says source manifest records are not available yet. citeturn11view1 | A site built around provenance should expose its own public taxonomy/manifest contract, not just prose about it. | High |
| URL inconsistency | LLMWikis mixes top-level guide/reference pages like `/metadata-standard/` and `/llm-wiki-structure/` with a tool under `/tools/llm-wiki-setup-wizard/`; AIWikis mixes short hubs like `/topics/` with long, date-stamped report slugs and file-derived slugs such as `/best-practices/llm-wiki-readme/`. citeturn23view0turn23view2turn5view0turn14view1turn30search12 | The URLs do not yet communicate a consistent content model. Users and crawlers learn less from the path than they should. | High |
| Snippet and title quality | Search Central says titles should be concise, descriptive, and distinct, while descriptions should be unique per page. Current indexed results often show long list-like snippets, boilerplate-heavy summaries, or even corrupted/binary-looking text on at least one AIWikis page. citeturn35view1turn35view3turn30search3turn30search5turn10search3 | This is both a UX and an SEO problem. Search results do not always show a clean reason to click. | High |
| Breadcrumb weakness | Sampled LLMWikis pages show very shallow visible trails such as `Home > Setup wizard` or `Home > Structure standard`; Google recommends breadcrumb trails because they help users understand hierarchy and explore a site effectively. citeturn5view0turn23view0turn25view4 | The pages lack a consistently expressed middle layer such as Section > Subsection > Page. | Medium |
| Interlinking pattern | AIWikis compact pages often link mainly to indexes, while LLMWikis pages rely heavily on repeated global menus. Google says links help discovery and understanding, and MediaWiki treats categories as automatic indexes that support browsing. citeturn14view0turn14view1turn25view1turn25view8 | The sites have many links, but not enough typed, local, context-rich links that explain relation, dependency, or sequence. | Medium |
| Content granularity imbalance | AIWikis source-summary pages are intentionally compact, but some public pages are so provenance-centric that they offer little standalone user value beyond “orientation and provenance.” Meanwhile, index pages can become very dense. citeturn14view0turn14view1turn20search10 | Thin pages can be useful for records, but not every record should be a public, indexable landing page. | High |
| Naming inconsistency | Search and topic results show variation such as `Llm Wikis`, `Ai Wikis`, highly verbose report titles, and date-coded items like `04 28 Cross Site Archive Transfer`. citeturn19view0turn30search3turn30search5 | Wikipedia’s naming guidance favors titles that are recognizable, natural, precise, concise, and consistent. Current naming is often accurate but not consistently natural or concise. | Medium |

This diagnosis is reinforced by official documentation models that the current sites are already close to, but do not yet fully exploit. Microsoft’s information architecture guidance emphasizes consistent labels, contextual clues, and easy findability. MediaWiki’s categories form tree-like hierarchies and automatic indexes. MDN separates page types into reference, guide, and navigation pages, and requires front matter that includes core identifiers like title, slug, and page type. Those patterns match the goals of AIWikis and LLMWikis almost exactly. citeturn25view13turn25view9turn28view0

The setup wizard deserves a special mention because it is both a product feature and a content model. It already has the right ambition, but its current implementation reads more like an expert planning console than a guided entry path. Step two alone includes project stage, collaboration model, reader model, root URL, coding-standards path, workspace setup, target policy, known sites, Git health, runtime artifacts, and context budget. Later steps introduce graph strategy, handoff rules, large-file policy, and safety posture. That is powerful, but it is not yet optimized for first-run comprehension. citeturn32view0turn32view1turn32view3

## Proposed information architecture and URL schema

The solution should be built around a simple principle: **each domain should own a different content job**. LLMWikis should own the “how, what, why, standard, template, tool” layer. AIWikis should own the “source, evidence, provenance, review, archive, cross-site relationship” layer. This aligns with Google’s emphasis on helping users and search engines understand content, with Microsoft’s information architecture guidance, with MediaWiki’s category trees, and with MDN’s page-type discipline. citeturn25view0turn25view13turn25view9turn28view0

### Proposed site hierarchy

```mermaid
graph TD
    A["Knowledge ecosystem"]

    A --> B["LLMWikis.org<br>Canonical handbook"]
    A --> C["AIWikis.org<br>Evidence and provenance"]

    B --> B1["Guide"]
    B --> B2["Reference"]
    B --> B3["Tools"]
    B --> B4["Examples"]
    B --> B5["Comparisons"]
    B --> B6["Glossary and changelog"]

    B1 --> B1a["Getting started"]
    B1 --> B1b["Build"]
    B1 --> B1c["Govern"]
    B1 --> B1d["Operate"]
    B1 --> B1e["Agent guidance"]

    B2 --> B2a["Metadata"]
    B2 --> B2b["Content types"]
    B2 --> B2c["Trust model"]
    B2 --> B2d["Schema"]

    B3 --> B3a["Setup wizard"]
    B3 --> B3b["Starter bundle"]

    C --> C1["Sources"]
    C --> C2["Provenance"]
    C --> C3["Reports"]
    C --> C4["Coverage and indexes"]
    C --> C5["Cross-site relationship pages"]

    C1 --> C1a["uaix"]
    C1 --> C1b["llmwikis"]
    C1 --> C1c["protocol5"]
    C1 --> C1d["spiralist"]

    C2 --> C2a["Public source records"]
    C2 --> C2b["Recovered summaries"]
    C2 --> C2c["Archive evidence"]

    C4 --> C4a["Topic coverage"]
    C4 --> C4b["File coverage"]
    C4 --> C4c["Source coverage"]
```

Why This File Exists

This is a memory-system evidence file from llmwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: Improving AIWikis.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure; Executive summary; Current state diagnosis; Proposed information architecture and URL schema; Proposed site hierarchy; URL schema options; Recommended canonical URL rules; Canonicals, redirects, and indexation policy. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-246 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "Improving AIWikis Org And LLMWikis Org Guidance, Setup Wizard, And Site Structure",
    "source_site":  "llmwikis.org",
    "source_url":  "https://llmwikis.org/",
    "canonical_url":  "https://aiwikis.org/llmwikis/files/raw-system-archives-llmwikis-agent-file-handoff-retired-source-archive-2-2f49aa61/",
    "source_reference":  "raw/system-archives/llmwikis/agent-file-handoff/retired-source-archive-2026-06-13/2026-05-11/Improvement/handoff-recovery-wizard-guidance/Improving AIWikis.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:2f49aa61e6cbcb51fe98023fc865e9578588b599c0088f830c4d356759258186",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-05-11T13:16:50.0613669Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-246",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}