Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure - Source Excerpt 05 - Success metrics, roadmap, and open questions
Back to Deep Research Report On Improving Llmwiki Navigation, Seo, And Structure
Summary
This source excerpt begins near Success metrics, roadmap, and open questions 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
Google’s faceted-navigation guidance matters here: do not let every filter combination become indexable. Only create indexable landing pages for a small subset of curated, strategic facets such as “LLM Wiki guides,” “metadata templates,” or “RAG comparisons.” Everything else should remain user-helpful but crawl-constrained. citeturn19search1
Related-content modules should be standardized rather than ad hoc. Every content page should end with something like:
- **Read next**
- **Used by / linked from**
- **Compare with**
- **Evidence / source pages**
- **Updated by the same workflow or owner**
This recommendation is supported by DokuWiki’s backlinks model, MediaWiki’s category hierarchy, and GitHub/GitLab wiki sidebar patterns, all of which reinforce the same idea: a wiki becomes navigable when relationships are explicit and reusable rather than buried in prose. citeturn23search2turn22search0turn21search2turn21search3
## Success metrics, roadmap, and open questions
### KPIs that actually matter
The analytics model should combine search visibility, content quality, and user/task success. Google Search Console already provides the core search metrics: clicks, impressions, CTR, average position, URL indexing status, structured-data visibility, and URL inspection diagnostics. Search Console’s Core Web Vitals and Page Indexing reports should be part of the same operational dashboard. citeturn36search7turn36search0turn36search2turn36search1turn26search9turn26search2
Recommended KPI set:
| KPI | Why it matters | Primary source |
|---|---|---|
| Non-homepage organic clicks | Measures whether the site is becoming content-rich rather than homepage-dependent | Search Console Performance |
| Impressions by section | Measures discoverability of concepts, guides, templates, and reports | Search Console Performance |
| CTR on priority pages | Tests title/description quality | Search Console Performance |
| Indexed canonical page count | Confirms migration and crawl health | Page Indexing report |
| Redirect error / chain rate | Protects SEO and UX during migration | Crawl logs + QA crawler |
| Good Core Web Vitals URL share | Tracks real-world page experience | Search Console CWV |
| Orphan page rate | Measures internal navigability | Internal crawl / graph |
| Pages with complete metadata | Measures template adoption | CMS audit |
| Stale-review rate | Measures editorial governance health | Content audit |
| Internal search success rate | Measures on-site findability | Product analytics |
| Wizard completion rate | Measures onboarding friction | Product analytics |
| Time to first publish | Measures whether setup is getting easier | Wizard + CMS instrumentation |
### Implementation roadmap
Effort estimates below assume no known CMS constraint. If the stack ends up being WordPress, static generation, or another wiki engine, implementation details will differ, but the sequencing should largely hold.
| Priority | Workstream | Outcome | Effort |
|---|---|---|---|
| Highest | Choose canonical domains and content roles | Clear answer to “handbook vs evidence archive,” plus redirect and canonical policy | Medium |
| Highest | Repair discovery files | Working `robots.txt`, XML sitemap(s), `llms.txt`, and consistent canonical declarations | Low |
| Highest | Ship new IA and URL standard | New top-level sections, depth rules, slug rules, breadcrumb rules | Medium |
| Highest | Normalize titles and labels | Better SERP titles, stronger information scent, fewer opaque page names | Medium |
| Highest | Implement metadata v2 | Canonical URL, description, category, tags, aliases, status, owner, dates, JSON-LD | Medium |
| Highest | Redesign the setup wizard | Shorter first-run flow, advanced settings behind disclosure, preview + validation | Medium |
| High | Build redirect map and run migration | Preserve SEO and user paths during route changes | High |
| High | Add related-pages, backlinks, and topic hubs | Better human/agent navigation and stronger internal linking | Medium |
| High | Add faceted search with crawl constraints | Better findability without index bloat | High |
| Medium | Establish editorial workflow and style guide | Repeatable governance across future content | Low |
| Medium | Instrument KPIs and dashboards | Ongoing measurement in Search Console and product analytics | Low |
| Medium | Performance and accessibility pass | Mobile navigation cleanup, reflow QA, heading/landmark checks | Medium |
A sensible phasing model would be:
- **Immediate:** canonical decision, sitemap/robots repair, title cleanup, metadata schema
- **Near term:** IA rebuild, redirects, wizard redesign, topic hubs
- **Later:** faceted search, related-page automation, graph-based recommendations, richer editorial dashboards
### Open questions and limitations
The largest open question is strategic, not technical: which public brand should be canonical for the handbook? The audit clearly shows that `wiki.fftac.org` positions itself as a demonstration/evidence layer, `LLMWikis.org` positions itself as the handbook, and `llmwiki.org` is not currently serving that function. That decision should be made before redesign work begins, because it affects redirects, sitemap strategy, title policy, and brand equity. citeturn11view0turn12view0turn11view1
The second limitation is implementation specificity. No CMS or deployment architecture was specified, so the recommendations are intentionally CMS-agnostic. They are designed to map well to MediaWiki, DokuWiki, GitHub/GitLab wikis, static sites, or a custom content system, but the exact mechanics of redirects, metadata storage, search indexing, and sidebar generation will depend on the final stack. citeturn22search1turn22search0turn23search3turn23search1turn21search2turn21search3
The third limitation is measurement depth. I was able to verify public routes, discovery files, page structures, and handbook guidance, but I did not directly verify underlying HTML head tags, live JSON-LD output, field CWV data for these domains, or a full crawl of every route. Accordingly, the strongest findings here are about architecture, labeling, URL strategy, discoverability, and visible UX patterns; performance and accessibility findings are high-confidence structural recommendations, not full lab or field audits. citeturn26search2turn26search9turn36search1