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

Full report

On this page

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.

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.

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.

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.

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.

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.

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.

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.

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.

Proposed site hierarchy

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"]

This hierarchy also matches what strong documentation systems do in practice. MDN distinguishes reference, guide, and navigation pages; Docusaurus can generate categories from folders; MkDocs can auto-build navigation from files but will default to alphabetical order if you do not define nav, which is exactly why explicit architecture is preferable; GitBook automatically preserves moved pages with 301 redirects; WordPress supports customizable permalinks. In other words, the required behavior is common across modern wiki and docs platforms even though the underlying stack here is unspecified.

URL schema options

Recommended canonical URL rules

For LLMWikis.org, use a stable section-based scheme such as the following:

• llmwikis.org/guide/what-is-an-llm-wiki/
• llmwikis.org/guide/build/
• llmwikis.org/guide/governance/
• llmwikis.org/reference/metadata/
• llmwikis.org/reference/content-types/
• llmwikis.org/reference/trust-model/
• llmwikis.org/tools/setup-wizard/
• llmwikis.org/examples/personal/
• llmwikis.org/comparisons/rag/

For AIWikis.org, use a source-first and evidence-first scheme such as the following:

• aiwikis.org/sources/llmwikis/public/
• aiwikis.org/sources/llmwikis/recovered/llm-wiki-readme/
• aiwikis.org/sources/uaix/public/
• aiwikis.org/provenance/llmwikis/starter-bundle/
• aiwikis.org/reports/cross-site/relationship-audit/
• aiwikis.org/coverage/topics/
• aiwikis.org/coverage/files/
• aiwikis.org/coverage/sources/

The rule set should be strict:

Breadcrumbs should mirror this hierarchy. Google’s breadcrumb guidance is explicit that breadcrumb trails help users understand a page’s position in the hierarchy and explore the site effectively. On these sites, that means examples like Home > Guide > Build > Setup wizard for LLMWikis and Home > Sources > LLMWikis > Recovered > LLM Wiki README for AIWikis, with matching BreadcrumbList structured data.

Canonicals, redirects, and indexation policy

A simple policy works best:

• LLMWikis handbook pages: self-canonical, indexable, included in sitemap.
• AIWikis unique provenance pages: self-canonical if they add distinct evidentiary value.
• AIWikis convenience duplicates of handbook content: either cross-domain canonical to LLMWikis or noindex,follow if the page is mostly a retrieval convenience.
• Large generated/faceted/search-result pages: keep out of indexed surface unless they truly serve a browse use case; Google recommends careful handling of problematic and faceted URLs.

Guidance and setup wizard redesign

The wizard should stop behaving like an expert checklist first and a setup assistant second. Structuring forms guidance from GOV.UK recommends knowing why you are asking each question, using branching questions, and starting with one thing per page so users can focus, recover from errors, and move through unfamiliar processes. That maps directly onto the current wizard’s biggest pain point: too many advanced decisions appear too early.

Proposed wizard flow

The wizard should also become branching and progressive. The default path for a new public handbook should not ask about GraphRAG, WordPress runtime artifacts, multi-repo Git health, or archive-transfer patterns unless the user has already signaled that those features apply. Those are valuable advanced branches, but they should be conditional, not foundational.

Required metadata for all public pages

LLMWikis already has a solid metadata standard. MDN similarly requires core front matter like title, slug, and page-type, and its page structure model shows the value of explicit page-type architecture. The next step is to make that metadata richer and more operational by connecting it to taxonomy, canonicalization, and navigation.

The wizard should collect a small core set first: site role, scope, audience, page type, section, title, summary, owner, review cadence, canonical owner, and URL policy. More specialized fields should appear only when relevant. That follows GOV.UK’s “know why you’re asking every question” rule and keeps the setup experience legible.

Automated taxonomy suggestions and slug generation

The setup wizard should generate suggestions from a single source-of-truth registry, following the pattern LLMWikis already uses for starter templates, where the visible examples and downloadable bundle come from the same canonical registry. That is exactly the right model to extend to sections, page types, tags, skeleton files, and URL rules.

The automation logic should work like this:

• infer page type from user intent and selected site role;
• suggest section from page type and summary;
• propose slug from normalized title, but enforce the site’s section-based path policy;
• generate aliases from prior names, file names, and common query forms;
• suggest related pages from same section, same tags, and same entities;
• create a meta description from the summary and page metadata, because Google explicitly encourages unique, human-readable, and even programmatically generated descriptions for large sites when done well.

Autogeneration should remain assistive, not authoritative. Docusaurus and MkDocs both show why: they can generate navigation from the filesystem, but MkDocs will auto-sort by filename if navigation is not explicitly defined. That is convenient for scaffolding and dangerous for long-term information architecture. Use automation for suggestions, then require editorial confirmation for final taxonomy placement.

Content templates, naming conventions, and discovery

A scalable wiki lives or dies by page types and naming rules. MDN explicitly distinguishes guide, reference, and navigation pages. Wikipedia’s title guidance says good titles are recognizable, natural, precise, concise, and consistent, and it also recommends creating redirects for names readers may reasonably search for. MediaWiki’s category system exists precisely to support browseable hierarchies and automatic indexes. Those three models should anchor the content policy here.

Recommended public page types

For LLMWikis.org, the primary types should be:

• Guide: explanatory, task-oriented, sequence-based content such as getting started, build, governance, and operations.
• Reference: standards, metadata, trust model, schema, page-type definitions, and naming conventions.
• Tool: setup wizard, starter bundle, checklists, validators.
• Example: personal wiki, team wiki, and worked page examples.
• Comparison: LLM Wiki vs. RAG, LLM Wiki vs. AI Memory.

For AIWikis.org, the primary types should be:

• Source overview: public source context per upstream site.
• Recovered summary: provenance-oriented page about a specific source object.
• Provenance record: source, archive, and duplicate-resolution information.
• Report: audit, relationship analysis, coverage, migration report.
• Coverage index: topic, source, and file coverage hubs.

This structure also corrects a current imbalance. Some AIWikis pages are compact and probably should remain public records, but not every recovered item deserves equal indexable prominence. The handbook should explain; the evidence site should prove.

Naming conventions

Canonical naming rules should be simple and enforceable:

• Use the exact brand casing for site names: AIWikis, LLMWikis, UAIX.
• Use sentence case or another single editorial standard consistently across public page titles, except where brand names require special casing. Wikimedia governance guidance favors sentence case where possible.
• Do not use “Part 1,” “Part 2,” “revised publication report,” “set,” or internal workflow labels as the canonical title for evergreen concept pages.
• If the content is a true report, label it as a report. If it is a concept page, title it as the concept.
• Use dates only for genuine logs, releases, or time-bound reports.

Examples:

• Prefer AIWikis navigation improvements over Part 2 of improving AIWikis.
• Prefer Relationship audit or Cross-site relationship audit over Relationship Audit Set 2026-04-29 as the evergreen concept page; the dated run can remain a child report.
• Prefer What is an LLM Wiki as the canonical concept page and Publication review of What is an LLM Wiki as a separate report page.

This matters because the current public corpus already shows title drift in exactly these directions: long report-style titles, inconsistent brand casing, and date-coded log items appear inside directories that users may interpret as primary knowledge surfaces. Wikipedia’s title criteria are the right corrective.

Internal linking and cross-page discovery

Google says links help it discover pages and understand relevance, and it specifically recommends good anchor text and internal cross-references. On the wiki side, MediaWiki categories provide automatic browse indexes, and MDN requires sidebars that render hierarchical navigation from structured definitions. The right internal-linking model here is therefore multi-layered, not purely menu-based.

Use four layers of discovery:

Each page should also support typed relationships in metadata and rendering:

• depends_on
• supersedes
• contradicts
• source_for
• related_to
• see_also

That is better than today’s pattern where some AIWikis pages mostly point back to a handful of indexes and some LLMWikis pages rely heavily on repeated global blocks. Contextual links inside the content body, plus a small “Related pages” block near the conclusion, will improve both human navigation and machine retrieval.

Transclusion policy

Transclusion is useful, but it should be narrow and controlled.

Good candidates for transclusion:

• review-status panels;
• canonical-source banners;
• trust label legend;
• provenance mini-card;
• common glossary definitions;
• support-boundary notices.

Poor candidates for transclusion:

• full concept pages across domains;
• large report bodies;
• whole reference documents inside evidence pages.

That distinction matters because AIWikis repeatedly states canonical source boundaries in prose. Instead of repeating large chunks of concept content across sites, transclude only the status and provenance shell and link out to the canonical handbook page. That preserves discovery without creating a second quasi-canonical concept page.

Migration, governance, and quality control

A good migration for these sites is not just a redirect exercise. It is a content contract migration: deciding which domain owns which topics, which existing pages remain public records, which are merged, which are redirected, and which are removed from indexation. Google’s site move guidance recommends preparing a URL mapping, testing thoroughly, changing one thing at a time, and monitoring both old and new URLs. Google’s redirect guidance recommends permanent server-side redirects for permanent moves and notes that the redirect type is a canonicalization signal.

Migration plan

Inventory and classify. Build a complete URL inventory from current sitemaps, page lists, internal crawls, Search Console, and backlink data. For each URL, classify it as keep, move, merge, archive-noindex, or retire. Pages with strong backlinks or search demand should be treated as primary migration targets.

Choose canonical winners by intent, not by recency. For every topic, decide whether the canonical public answer belongs on LLMWikis or AIWikis. If a page is instructional, the default winner should be LLMWikis. If a page is evidentiary, provenance-oriented, or cross-site archival, the default winner should be AIWikis.

Implement permanent redirects. Use permanent server-side redirects for moved URLs. Update internal links so the live site points directly to final URLs, not to redirect hops. Google explicitly recommends permanent server-side redirects whenever a page’s URL shown in search should change.

Align canonicals, sitemaps, and breadcrumbs. Every canonical page should self-canonical and appear in the sitemap; alternate or duplicate URLs should redirect or canonicalize to the winner; breadcrumb paths should match the new hierarchy; and moved pages should not leave conflicting canonical signals behind. Google’s canonical guidance specifically recommends picking a canonical URL, including preferred canonicals in sitemaps, and using canonicals for duplicate consolidation.

Preserve non-HTML asset logic. If you expose PDFs or other document formats, use canonical headers where needed. Google explicitly supports rel="canonical" HTTP headers for non-HTML files.

Example redirect policy

The redirect policy should be deterministic and easy to audit. Examples:

• llmwikis.org/how-to-build-an-llm-wiki/ → llmwikis.org/guide/build/
• llmwikis.org/metadata-standard/ → llmwikis.org/reference/metadata/
• llmwikis.org/llm-wiki-structure/ → llmwikis.org/reference/structure/
• llmwikis.org/navigation/ → llmwikis.org/reference/navigation/
• AIWikis concept duplicates with no unique public value → either 301 to the LLMWikis canonical page or noindex,follow if the page must remain public for provenance context

For strong SEO preservation, keep important redirects in place indefinitely, and at minimum for a long enough period that users, backlinks, crawlers, and internal references have all converged on the new structure. GitBook’s documentation is a useful platform example here: when a page is moved or renamed, it automatically creates an HTTP 301 redirect from the old URL to the new one.

Governance and editorial workflow

LLMWikis already has the right ingredients in its own starter-registry model: ownership, review cadence, trust level, agent guidance, and human review requirements are attached to templates. Those same controls should become the editorial operating model for both sites.

A pragmatic governance model is:

• IA owner: owns taxonomy, URL policy, canonical ownership model, and navigation standards.
• Domain steward for LLMWikis: owns handbook tone, page types, reference integrity, and tools.
• Domain steward for AIWikis: owns source-policy compliance, provenance structure, and archive-facing surfaces.
• Section editors: own specific handbook or evidence sections.
• Technical SEO owner: owns redirects, canonicals, sitemaps, structured data, and Search Console.
• Reviewers: approve authoritative pages by page type and sensitivity.
• Publisher / release owner: approves structural changes and migrations.

The workflow should be explicit:

draft → in review → approved → published → stale/needs-review → archived/deprecated

And the mandatory quality checks should include:

• metadata completeness;
• title/slug/canonical lint;
• redirect coverage for renamed pages;
• no orphan pages;
• no empty categories;
• valid breadcrumbs;
• unique titles and descriptions for critical pages;
• link validity;
• contradiction or supersession markers where relevant.

That approach matches LLMWikis’ current trust-model and metadata thinking and aligns with Microsoft’s guidance to make categories and navigation consistent and user-friendly.

Metrics and QA tests

Search Console, Lighthouse, and the site’s own analytics should become the core measurement layer. Google describes Search Console as the place to understand search performance, crawling, indexing, and appearance. Lighthouse can audit performance, accessibility, and SEO.

Phased implementation roadmap

Google’s site-move guidance recommends preparation, URL mapping, phased rollout, and monitoring; it also explicitly recommends changing one thing at a time. That matters here because taxonomy, URLs, canonicals, and content role-splitting are deeply connected. The implementation should therefore be staged rather than “big bang.”

flowchart LR
    A["Foundation<br>Inventory and role split"] --> B["Taxonomy design<br>Page types, sections, naming rules"]
    B --> C["Template registry<br>Metadata, breadcrumbs, canonicals, aliases"]
    C --> D["Wizard redesign<br>Progressive flow and automation"]
    D --> E["Migration<br>301s, canonicals, sitemap, internal links"]
    E --> F["Stabilization<br>Search Console, QA, editorial tuning"]
    F --> G["Governance hardening<br>Ongoing review and metrics"]

A practical delivery cadence would be:

• Foundation and taxonomy first;
• template registry and wizard second;
• navigation and URL implementation third;
• migration and measurement fourth.

That order prevents the common migration mistake of moving URLs before the target architecture and editorial rules are stable.

Open questions and limitations

This report is based on a deep review of representative public pages and indexed results, not a full crawl of every URL on both domains. Some technical issues, such as the exact presence or absence of HTML canonical tags or structured-data implementations on every page, cannot be conclusively verified from the sampled public surface alone. Where that uncertainty matters, the recommendations above are framed as architecture and QA requirements rather than assumptions about code that is definitely absent.

The biggest unresolved product question is strategic rather than technical: how much of AIWikis should remain indexable as a public knowledge surface, versus becoming a more clearly separated evidence layer with stronger use of canonicals or noindex on thin convenience pages. That decision should be made before URL migration begins, because it affects the redirect map, sitemap contents, and editorial workload.