Two Identities Of Anonymous Website Audit And Improvement Plan - Source Excerpt 06 - Rollout Roadmap and KPIs

Back to Two Identities Of Anonymous Website Audit And Improvement Plan

Summary

This source excerpt begins near Rollout Roadmap and KPIs and preserves the surrounding evidence from 2IA.org/agent-file-handoff/Archive/2026-05-18-publication-readiness-pass/Two Identities Of Anonymous Website Audit and Improvement Plan.md.

**Source path:** 2IA.org/agent-file-handoff/Archive/2026-05-18-publication-readiness-pass/Two Identities Of Anonymous Website Audit and Improvement Plan.md

The CMS appears very likely to be WordPress, based on the “Hello world!” archive post and exposed WordPress/theme-seeding language. If 2IA stays on WordPress, that is completely workable. The best configuration would be a custom post type for **Briefings**, one taxonomy for **Topics**, author/editor profiles, a deliberate noindex strategy for thin archives, an SEO layer for titles/meta/canonicals, and lightweight JSON-LD for Organization, BreadcrumbList, and Article. Google explicitly notes that CMSes such as WordPress often already generate sitemaps and may offer settings or plugins for structured data and meta tags; use those capabilities, but keep the plugin stack lean so the site honors its privacy-first promise. If long-term privacy and operational simplicity matter more than editorial convenience, a static or statically rendered front end is also a reasonable future option, especially for the mostly text-driven content model here. citeturn30view1turn23view0turn37view3turn24view6turn41view0

The structured-data plan should be conservative and visible-content-only. Use **Organization** on the homepage for entity clarity, **BreadcrumbList** on interior pages to reinforce hierarchy, and **Article** on real briefings once they exist. Do not add markup to blank or unfinished pages just to chase rich results; Google explicitly says structured data should describe the content visible on that page. citeturn37view3turn35view0turn37view1turn24view6

## Rollout Roadmap and KPIs

The implementation sequence should begin with launch blockers, then move into architecture/templates, then content and measurement. Accessibility and performance should not be deferred to the end; they should be part of template work from the first sprint. Chrome’s Lighthouse documentation recommends running audits on every page you care about and using Lighthouse CI to prevent regressions; W3C’s quick reference remains the right manual checklist for keyboard flow, labels, link purpose, focus states, and reflow. For search QA, use Search Console URL Inspection, the Performance report, Rich Results Test, and sitemap submission. citeturn21view0turn21view2turn19view0turn20view0turn19view5turn19view6turn19view7turn19view8turn19view9turn35view1turn23view0turn39view0

A practical testing plan should therefore cover four tracks at once. First, **route integrity**: every public internal link should return a live page or be removed/noindexed. Second, **template QA**: homepage, archive, topic page, article page, and policy/contact page should each pass manual keyboard testing, mobile reflow checks, and Lighthouse/PSI checks. Third, **search presentation**: verify titles, snippets, canonical choice, schema, and sitemap coverage in Search Console. Fourth, **editorial QA**: every briefing should have byline, date, source notes, correction path, and related links before publication. Google’s own documentation also recommends measuring Core Web Vitals in the field with first-party instrumentation using the `web-vitals` library or equivalent and then aggregating those values in your analytics endpoint. citeturn24view1turn24view3turn24view4turn37view1turn35view0turn23view0turn17view0

' ' ' mermaid
gantt
    title 2IA rollout roadmap
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Quick wins
    Remove placeholder/default content        :a1, 2026-05-19, 7d
    Hide or fix inaccessible public links     :a2, 2026-05-19, 10d
    Simplify homepage hero and footer         :a3, 2026-05-22, 10d
    Noindex empty archives and low-value pages:a4, 2026-05-22, 7d

    section Core architecture
    Publish Start Here and Methodology        :b1, 2026-06-01, 14d
    Rebuild archive and briefing templates    :b2, 2026-06-01, 21d
    Unify navigation and breadcrumb model     :b3, 2026-06-05, 14d
    Implement schema and sitemap checks       :b4, 2026-06-08, 10d

    section Content system
    Publish cornerstone briefing set          :c1, 2026-06-20, 21d
    Launch support/newsletter/contact flows   :c2, 2026-06-20, 14d
    Add source notes and correction workflow  :c3, 2026-06-20, 14d

    section Measurement and hardening
    Lighthouse CI and accessibility QA        :d1, 2026-07-05, 14d
    Core Web Vitals RUM instrumentation       :d2, 2026-07-05, 10d
    Search Console review and iteration       :d3, 2026-07-10, 21d
' ' ' 

The KPI set should be small, privacy-respecting, and directly tied to user outcomes. Google’s Search Console Performance report already gives clicks, impressions, CTR, and average position. Google’s Web Vitals documentation gives the user-experience thresholds worth targeting. The rest should be first-party product metrics, not behavioral overreach. citeturn39view0turn17view0

| KPI | How to measure | Suggested target after rollout | Why it matters |
|---|---|---|---|
| Linked public URL success rate | Crawl all internal routes; monitor 200/301/404/500 | 100% of nav/footer/CTA links return intentional outcomes | Removes the biggest trust blocker |
| Search impressions, clicks, CTR, average position | Search Console Performance report citeturn39view0 | Establish baseline in first month; improve CTR on key landing pages after title/meta rewrite | Measures discoverability and snippet quality |
| Core Web Vitals | RUM via `web-vitals`; validate with PSI/Lighthouse citeturn17view0turn21view2 | p75 LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 | Measures real user experience |
| Homepage primary CTA rate | First-party event on Start Here / Archive / Methodology clicks | One clear primary CTA outperforming all others | Confirms the homepage is routing readers well |
| Archive engagement | Internal search usage, zero-result rate, “Open file”/briefing clicks | Zero-result rate kept low; archive CTR rising as content grows | Shows whether the archive is actually usable |
| Contact completion quality | Contact form starts/submits or email-click events; manual review of message quality | More legitimate contact, fewer misrouted requests | Tests whether Contact/Lawful Contact are clear |
| Newsletter/support conversion | Signup/donation completions using first-party events | Publishable baseline and steady trend growth | Measures community and sustainability |
| Accessibility defect count | Manual WCAG review + automated scans per release | Zero critical blockers on core templates | Prevents regressions and improves reach |
| Placeholder/thin page count | Editorial QA and crawl audit | Zero publicly exposed placeholders/empty archives | Keeps the site publish-ready |
| Corrections workflow health | Correction requests logged and resolved | Clear turnaround target with visible update notes | Operationalizes the accountability promise |

The core success condition is simple: after rollout, a first-time visitor should be able to understand what 2IA is, why it matters, how it does its work, where the evidence lives, how to contact it, and how to support it—without hitting unfinished pages, placeholder content, or structural dead ends. Right now, the site is close conceptually, but not yet there operationally. The plan above is the shortest path from “smart but partially scaffolded” to “credible, rigorous, and publish-ready.” citeturn29view0turn30view1turn30view0turn12view2