Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure - Source Excerpt 04 - Internal linking and cross-page discovery

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

Summary

This source excerpt begins near Internal linking and cross-page discovery 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

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. citeturn19view0turn30search3turn30search5turn27view2

### 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. citeturn25view1turn25view8turn28view3

Use four layers of discovery:

| Discovery layer | Role | Rule |
|---|---|---|
| Primary section | Gives every page one stable home | Each page belongs to exactly one primary section |
| Categories | Hierarchical browse structure | Keep the tree curated and shallow |
| Tags | Secondary facets such as topic, source site, or audience | Limit to 3–5 controlled tags |
| Related pages | Contextual, hand-curated next links | Include 2–6 pages that answer “what next?” |

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 wiki.fftac.org 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. citeturn14view0turn14view1turn6view0turn6view1

### 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 wiki.fftac.org 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. citeturn4view1turn14view1turn25view3

## 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. citeturn37view0turn37view1

### 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. citeturn37view0turn38search2turn38search16

**Choose canonical winners by intent, not by recency.** For every topic, decide whether the canonical public answer belongs on LLMWikis or wiki.fftac.org. 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 wiki.fftac.org. citeturn7view1turn4view1turn25view3

**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. citeturn37view1

**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. citeturn25view3turn25view4turn25view5

**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. citeturn25view3

### 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/`
- wiki.fftac.org 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. citeturn25view15turn37view1

### 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. citeturn40view0turn24view0

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 wiki.fftac.org**: 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. citeturn24view0turn40view0turn25view13

### 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. citeturn39search18turn39search7turn39search0