Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure - Source Excerpt 01 - Improving wiki.fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure

Back to Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure

Summary

This source excerpt begins near Improving wiki.fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving wiki-fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/Improving wiki-fftac.org and LLMWikis.org Guidance, Setup Wizard, and Site Structure.md

# Improving wiki.fftac.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 **wiki.fftac.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. wiki.fftac.org 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 **wiki.fftac.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 wiki.fftac.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 | wiki.fftac.org states that LLMWikis remains the handbook source, yet wiki.fftac.org 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 | wiki.fftac.org 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 | wiki.fftac.org `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/`; wiki.fftac.org 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 wiki.fftac.org 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 | wiki.fftac.org 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 | wiki.fftac.org 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`, `wiki.fftac.org`, 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 |