Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure - Source Excerpt 02 - Wizard, search, and editorial experience

Back to Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure

Summary

This source excerpt begins near Wizard, search, and editorial experience and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Deep Research Report on Improving LLMWiki Navigation, SEO, and Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Deep Research Report on Improving LLMWiki Navigation, SEO, and Structure.md

The public metadata standard on `LLMWikis.org` is a good start, but it is still too wiki-internal and not web-search-complete. The reviewed standard emphasizes `title`, `owner`, `status`, `last_reviewed`, `review_cycle`, `sensitivity`, `agent_use`, and `related`. That is valuable for governance, yet the public guidance reviewed here does not surface a first-class schema for canonical URL, meta description, slug, primary category, tags, aliases, redirects, social image, JSON-LD type, or visible byline-date policy. Google’s documentation on title links, snippets, byline dates, site names, organization markup, article markup, and structured data makes those omissions expensive because they reduce control over how pages appear and are interpreted in search. citeturn14view2turn20search0turn20search1turn32search1turn32search0turn31search0turn31search2turn31search10

The sitemap/discovery setup also appears inconsistent. `LLMWikis.org` advertises `robots.txt` and `sitemap.xml` on its homepage, but its `robots.txt` points to `https://llmwikis.org/sitemaps.xml`, and that endpoint returned a 404 in this audit. Google treats sitemaps as hints, not guarantees, but they still matter for discovery and crawl efficiency, particularly on a route-rich content site. At minimum, the homepage discovery-file references, the robots declaration, and the actual working sitemap endpoints must agree exactly. citeturn12view0turn16view0turn29view0turn26search0turn26search6

### Wizard, search, and editorial experience

The current setup wizard is ambitious but overloaded. It is framed as a seven-step browser-only planning tool, which is reasonable, but the sampled public content reveals that it quickly dives into advanced topics such as multisite workspaces, Git preflight rules, runtime artifact exclusion, large-file policy, duplicate-file policy, knowledge-graph claim/source-span policy, export boundaries, Project Handoff alignment, and capability cataloging. Those topics are valuable for mature implementations, but they are too early in the journey for most first-time wiki users. The result is a form that behaves more like an expert planning checklist than an onboarding wizard. citeturn13view0turn34view0turn34view1

The wizard also generates large packets and JSON blocks before basic IA and content primitives are fully stabilized. That is backwards for usability. W3C’s guidance on labels/instructions and consistent navigation, paired with WCAG reflow requirements, points toward shorter steps, clearer labels, fewer cognitive branches per screen, and stronger separation between required fields and advanced settings. The current wizard already has good intent; it needs progressive disclosure, presets, and far fewer default questions. citeturn13view0turn27search2turn27search0turn27search1

Visible site search is also underpowered in the reviewed public experience. `LLMWikis.org` shows a search field and quick links, but the public IA sampled here does not demonstrate faceted filtering by page type, status, freshness, audience, or source. That matters because wiki UX works best when browse and search reinforce each other. DokuWiki and MediaWiki both expose concepts that support this direction: namespaces, metadata, backlinks, category hierarchies, page indices, and enhanced search. NN/g’s IA guidance also stresses taxonomy and tree testing as core findability tools, not optional extras. citeturn12view0turn14view3turn23search0turn23search1turn23search2turn23search26turn22search0turn22search18turn25search1turn25search28

### Before-and-after transformations

The “before” examples below are drawn from public pages and routes observed during this audit on `wiki.fftac.org` and `LLMWikis.org`. The “after” column is the recommended canonical target format. citeturn2view1turn11view0turn12view0turn13view0turn33view0turn33view1

| Current URL | Current title | Problem | Recommended canonical URL | Recommended title |
|---|---|---|---|---|
| `wiki.fftac.org/llm-wiki/` | `LLM Wiki Index` | Flat mega-index with mixed content types | `llmwikis.org/handbook/` | `LLM Wiki Handbook` |
| `wiki.fftac.org/topics/` | `Topic Index` | Browse-only list, weak differentiation by type/status | `llmwikis.org/topics/` | `Topics` |
| `wiki.fftac.org/uai-reference/llm-wikis/` | `Llm Wikis` | Brand inconsistency and vague source page | `wiki.fftac.org/sources/llmwikis/` | `LLMWikis Source Overview` |
| `wiki.fftac.org/ai-memory-systems/source-proxy-cross-site-archive-transfer-2026-04-28/` | `Source Proxy: Cross-Site Archive Transfer 2026-04-28` | Overlong slug and title-first date coding | `wiki.fftac.org/reports/archive-transfer/2026-04-28/` | `Archive Transfer Report` |
| `llmwikis.org/what-is-an-llm-wiki/` | `What Is an LLM Wiki?` | Good page, but should live inside a visible concepts tree | `llmwikis.org/concepts/what-is-an-llm-wiki/` | `What Is an LLM Wiki?` |
| `llmwikis.org/how-to-build-an-llm-wiki/` | `How To Build an LLM Wiki` | Guide route inconsistent with future library pattern | `llmwikis.org/guides/build-an-llm-wiki/` | `How to Build an LLM Wiki` |
| `llmwikis.org/tools/llm-wiki-setup-wizard/` | `LLM Wiki Setup Wizard` | Tool route is accurate but longer than needed | `llmwikis.org/setup/wizard/` | `LLM Wiki Setup Wizard` |
| `wiki.fftac.org/files/` | `Global File Index` | Utility page lacks archive/evidence framing | `wiki.fftac.org/evidence/files/` | `Evidence File Index` |
| `wiki.fftac.org/source-map/` | `Source Map` | Good concept, but machine-readable registry not yet exposed | `wiki.fftac.org/evidence/sources/` | `Source Registry` |
| `wiki.fftac.org/what-is-an-llm-wiki/` | `What Is an LLM Wiki?` | Concept duplicated across domains without clear canonical target | `llmwikis.org/concepts/what-is-an-llm-wiki/` | `What Is an LLM Wiki?` |

## Recommended information architecture

Because no CMS was specified, the recommendations below are CMS-agnostic. They translate cleanly to MediaWiki categories/short URLs/redirects, DokuWiki namespaces/metadata/backlinks, GitHub wiki sidebars, and GitLab wiki sidebars. The design goal is the same across stacks: a small, obvious top-level taxonomy; descriptive, stable slugs; shallow public depth; and strong browse/search reinforcement. citeturn22search0turn22search1turn21search0turn23search1turn23search2turn23search3turn21search2turn21search3

I recommend a two-site public architecture unless a full consolidation is preferred. In that model, `LLMWikis.org` is the canonical handbook and editorial knowledge site, while `wiki.fftac.org` is the evidence, provenance, and archive site. That recommendation follows the roles the sites already describe publicly, but it makes them concrete enough for navigation, search, and canonical SEO. citeturn11view0turn12view0turn12view1turn19search2turn32search16

' ' ' mermaid
graph TD
    A[Home] --> B[Concepts]
    A --> C[Guides]
    A --> D[Templates]
    A --> E[Operations]
    A --> F[Governance]
    A --> G[Examples]
    A --> H[Tools]
    A --> I[Topics]
    A --> J[Reports]
    A --> K[About]

    B --> B1[What is an LLM Wiki]
    B --> B2[LLM Wiki vs RAG]
    B --> B3[LLM Wiki vs AI Memory]

    C --> C1[Build an LLM Wiki]
    C --> C2[Ingest]
    C --> C3[Query]
    C --> C4[Lint]

    D --> D1[Page Templates]
    D --> D2[Metadata Schema]
    D --> D3[Starter Bundle]

    E --> E1[Navigation]
    E --> E2[Search]
    E --> E3[Security and Privacy]

    F --> F1[Governance]
    F --> F2[Source Policy]
    F --> F3[Editorial Standards]

    G --> G1[Personal Wiki]
    G --> G2[Team Wiki]
    G --> G3[Model Registry]

    H --> H1[Setup Wizard]
    H --> H2[Checklist]

    I --> I1[Topics by taxonomy]
    I --> I2[Tags]
    I --> I3[Collections]

    J --> J1[Research Reports]
    J --> J2[Case Studies]
    J --> J3[Release Notes]
' ' ' 

This structure follows Google’s preference for simple URLs and breadcrumb-friendly hierarchies, and it matches wiki-platform conventions where namespaces, categories, and sidebars represent stable content groupings. It also respects NN/g’s distinction between transition pages and destination pages: top-level section pages should orient and route, while leaf pages should satisfy the user’s actual information need. citeturn20search2turn19search0turn24search1turn22search0turn23search3turn21search2turn21search3

### URL policy

The URL rules should be explicit and non-negotiable: