Improving wiki.fftac.org Org And Llmwikis Org Guidance, Setup Wizard, And Site Structure - Source Excerpt 05 - Phased implementation roadmap

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

Summary

This source excerpt begins near Phased implementation roadmap 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

| Goal | Metric or QA test | Tool | Success target |
|---|---|---|---|
| Better search visibility | Impressions, clicks, CTR, average position for priority pages | Search Console Performance report citeturn38search0 | Upward trend after migration stabilization |
| Better indexing | Percent of intended canonical URLs indexed | Search Console Page indexing report citeturn38search1 | High coverage; investigate duplicate and excluded clusters |
| Better crawl and sitemap health | Sitemap processing errors; stale URLs remaining in sitemap | Search Console Sitemaps report citeturn38search12turn38search16 | Zero critical sitemap errors |
| Better snippet quality | Unique `<title>` and meta description on all critical URLs | crawler + page QA; guided by Search Central citeturn35view1turn35view3 | 100% on top-priority pages |
| Better hierarchy expression | Valid breadcrumb markup and visible breadcrumb path on all content pages | structured-data validation + page QA citeturn25view4turn38search3 | 100% valid on in-scope pages |
| Better internal discovery | Internal-link coverage, orphan-page count, pages with 2–6 related links | crawler + Links report citeturn39search1turn25view1 | Zero orphans in canonical public surface |
| Better page quality | Lighthouse SEO, accessibility, and performance audits | Lighthouse citeturn39search0 | Internal threshold such as 90+ on priority templates |
| Better real-world performance | LCP, INP, CLS status by page group | Search Console Core Web Vitals report citeturn39search2turn39search5 | Most important page groups in “Good” |
| Better navigation UX | Median clicks from homepage to a top task; task success rate in moderated tests | analytics + usability testing | Top tasks reachable in 2–3 clicks |
| Better editorial quality | Metadata completeness rate; stale-page rate; duplicate-page rate | internal QA dashboard | Near-zero missing core metadata |

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

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

| Phase | Key work | Effort | Main risks | Risk control |
|---|---|---|---|---|
| Foundation | Inventory URLs, define domain roles, identify duplicate-intent pages | Medium | Missing important legacy URLs | Use sitemap, crawl, Search Console, backlink exports |
| Taxonomy design | Define page types, sections, categories, tags, naming rules, canonical ownership matrix | High | Taxonomy sprawl or overdesign | Limit sections; pilot on top-priority pages first |
| Template registry | Create shared schema for templates, metadata, breadcrumbs, title/meta rules, canonicals, aliases | Medium | Tooling drift between docs and implementation | Keep one source registry, following current starter-template pattern |
| Wizard redesign | Rebuild flow around progressive disclosure and branching | High | Wizard becomes too abstract or too technical | Test with first-time and expert users separately |
| Navigation rollout | Implement section hubs, sidebars, related pages, breadcrumb trails, local “next” paths | Medium | Global nav remains cluttered | Reduce repeated footer navigation; emphasize local context |
| URL migration | Launch new paths, permanent redirects, updated canonicals, sitemap refresh, direct-link cleanup | High | Redirect chains, conflicting signals, temporary ranking drops | Test redirect map, update internal links, monitor Search Console closely |
| Stabilization | Review indexing, snippets, performance, breadcrumbs, orphan pages, user analytics | Medium | False positives or overcorrection | Predefine KPI thresholds and hold steady for evaluation windows |
| Governance hardening | Assign owners, review cadence, editorial checklist, quarterly IA audit | Low to medium | Process decay after launch | Build checks into publishing workflow, not only post hoc reviews |

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

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

The biggest unresolved product question is strategic rather than technical: **how much of wiki.fftac.org 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. citeturn4view1turn14view0turn14view1turn37view0