Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure - Source Excerpt 04 - Wizard redesign
Back to Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure
Summary
This source excerpt begins near Wizard redesign 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
' ' ' json
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "What Is an LLM Wiki?",
"description": "A practical definition of the LLM Wiki pattern, how it differs from RAG and AI Memory, and when to use it.",
"datePublished": "2026-05-11",
"dateModified": "2026-05-11",
"author": {
"@type": "Person",
"name": "Editorial Team"
},
"publisher": {
"@type": "Organization",
"name": "LLMWikis.org",
"url": "https://llmwikis.org/"
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://llmwikis.org/concepts/what-is-an-llm-wiki/"
},
"keywords": [
"LLM Wiki",
"AI knowledge base",
"RAG comparison",
"agent memory"
]
}
' ' '
### Wizard redesign
The current wizard proves that the project has thought deeply about setup, but it is trying to teach governance, graph modeling, source policy, repository hygiene, and multiple memory systems all at once. That is too much for the first-run flow. The redesign should preserve depth while shifting it behind progressive disclosure. The UX principle is simple: **make first-publish easy, advanced governance configurable, and expert modes optional**. That fits both WCAG form guidance and the documented current wizard boundaries. citeturn13view0turn34view0turn27search2turn27search0turn27search1
Recommended wizard structure:
' ' ' mermaid
flowchart TD
A[Welcome] --> B[Choose goal]
B --> C[Name the wiki]
C --> D[Pick audience and scope]
D --> E[Choose structure preset]
E --> F[Review page types and taxonomy]
F --> G[Generate slugs and sample URLs]
G --> H[Preview starter pages]
H --> I[Validation]
I --> J[Export setup packet]
I --> K[Fix errors]
K --> I
E --> E1[Beginner preset]
E --> E2[Team preset]
E --> E3[Migration preset]
E --> E4[Advanced preset]
J --> L[Starter bundle]
J --> M[Redirect map if migrating]
J --> N[Editorial checklist]
' ' '
The wizard should ask for only the minimum required inputs up front:
| Step | Required fields | Optional advanced fields |
|---|---|---|
| Goal | New wiki, migrate existing docs, build archive, publish handbook | Multi-site / handoff mode |
| Identity | Site name, canonical domain, language, owner | Alt name, organization details |
| Scope | Primary audience, top-level content families, first topic | Security/sensitivity model |
| Structure | Preferred preset, section names, slug rules | Graph export / entity IDs |
| Content | Page types to enable, categories, starter topics | Tag vocabularies, schema tuning |
| Migration | Old domain, old URL export, target rules | Redirect regex, alias policy |
| Review | Reviewer, cadence, publish rule | Agent permissions, approvals |
| Output | Preview site map, URLs, metadata defaults | JSON export, advanced packets |
Sample wizard prompts should sound like this:
' ' ' text
What is the main public role of this site?
- Handbook
- Evidence archive
- Mixed site
Which domain should be canonical for this role?
- llmwikis.org
- wiki.fftac.org
- another domain
What should the first three public sections be?
Examples: Concepts, Guides, Templates
Choose your page-title style:
- Plain-English topics
- Task-based how-to titles
- Report titles with dates at the end
Which metadata do you want required on every page?
- Owner
- Status
- Last reviewed
- Category
- Tags
- Meta description
- Canonical URL
Would you like to import existing URLs and generate a redirect map?
- Yes
- No
' ' '
The wizard should also generate a **preview state** before export: sample URLs, sample breadcrumbs, starter pages, and a validation report listing duplicates, weak titles, empty descriptions, missing owners, and conflicting category assignments. That matters because WCAG requires labels and instructions to clearly identify expected input, and because successful setup tools reduce ambiguity before the first content publish. citeturn27search2turn25search2
## Migration, governance, and search
### Content migration and redirect strategy
Migration should be treated as a search-preservation and information-governance project, not just a route rewrite. Google’s site-move documentation explicitly recommends preparing URL mappings and minimizing disruption through correct redirects and canonical handling. Google’s canonical documentation also recommends linking internally to the canonical URL rather than to duplicates. MediaWiki’s redirect model reinforces the same principle from the wiki side: redirects are symbolic links that preserve multiple access paths to the same destination. citeturn32search16turn19search2turn21search0
Recommended migration sequence:
- Export a full URL inventory from current public routes, XML sitemap(s), `llms.txt`, and internal crawl data.
- Choose one canonical domain for the handbook and one clear role for wiki.fftac.org.
- Map every old URL to a single best new URL. Avoid many-to-one collapses unless the underlying content is truly merged.
- Use **direct 301 redirects**, never redirect chains.
- Preserve title intent and page meaning when migrating. If an old page is folded into a new hub, add a redirect plus a visible section anchor or explanatory note.
- Update all internal links, breadcrumbs, canonicals, XML sitemaps, and JSON-LD to the new URLs before launch.
- Validate a statistically meaningful sample in Search Console with URL Inspection and monitor the Page Indexing report after launch. citeturn32search16turn19search2turn36search1turn36search2
Bulk-edit priorities should include:
- Normalizing capitalization: `LLM`, `AI`, `UAI`, `UAIX`
- Rewriting weak titles and date-front-loaded slugs
- Adding missing descriptions and categories
- Adding aliases for common alternative names
- Replacing generic links with descriptive anchor text
- Repointing wiki.fftac.org duplicates to the handbook canonical where appropriate citeturn20search0turn20search1turn25search26
### Governance and editorial workflows
The current ecosystem already values ownership, status, review cadence, trust, and source boundaries. That should now be formalized into a lightweight editorial operating model. The goal is not bureaucracy; it is reliable quality at scale. LLMWikis’ starter bundle already includes governance, trust model, contributing, glossary, onboarding, and agent guidance files, which is exactly the right precedent to turn into public workflow rules. citeturn14view5turn14view6turn14view7
Recommended roles:
| Role | Responsibility |
|---|---|
| Domain owner | Accountable for concept accuracy and review signoff |
| Managing editor | Controls templates, taxonomy, and style |
| SEO/editorial steward | Titles, descriptions, canonicals, structured data, sitemaps |
| Technical/platform owner | Redirects, robots, search, performance, accessibility |
| Reviewer | Approves content state transitions |
| Contributor | Drafts and updates content within templates |
Recommended workflow states:
`draft` → `in review` → `approved` → `current` → `stale` → `archived` → `redirected`
Naming rules should be explicit:
- One page, one primary topic
- One primary category
- Titles must describe the page purpose
- Do not publish pages named only by sequence, date, or internal project code unless that is the real user-facing topic
- Use title case consistently for display; use lowercase hyphenated slugs consistently for routes
- If the page is a report, the title should read like a report and the slug should read like a topic plus date, not a raw ingest artifact. citeturn25search2turn25search26turn20search0
Style-guide essentials:
- First paragraph answers the user’s likely question
- Separate definition, guidance, evidence, and open questions
- Use “last reviewed” and “updated” consistently
- Use descriptive anchors, not “click here” or generic “Part 2”
- Keep intros short; use subheads early for scanability
- Use visible review panels or infoboxes on every substantive page citeturn25search2turn20search1turn32search1
### Search, taxonomy, and internal navigation
Search and browse should be designed together. The future state should combine:
- **Top-level sections** for broad wayfinding
- **Topic pages** and category hubs for browsing
- **Faceted search** for users who know roughly what they need
- **Related pages** and **backlinks** for discovery
- **Typed internal link graph** for humans and agents
- **HTML sitemap**, **XML sitemap**, and **`llms.txt`** for crawlers and AI tools citeturn19search1turn26search6turn16view2turn23search2turn23search26
For public search, I recommend these facets:
| Facet | Values |
|---|---|
| Content type | concept, guide, template, report, tool, example, policy |
| Topic | taxonomy-driven |
| Status | current, draft, stale, archived |
| Audience | builder, maintainer, agent, public |
| Freshness | reviewed this month / quarter / year |
| Source type | original handbook, mirrored evidence, external reference |