Improvement Plan for Protocol5, JustAnIota, and AIWikis Pages

Full report

On this page

Executive summary

These four pages already have a meaningful foundation: they explicitly define authority boundaries, they repeatedly distinguish approximate semantic mapping from exact translation, and they include visible “Skip to content” affordances on load. That is a better trust baseline than many early-stage protocol and AI-tooling sites. The core problem is not lack of substance; it is that the substance is presented in an order that favors insiders over first-time visitors. On the audited pages, users often meet dense navigation, governance language, archival framing, or protocol vocabulary before they see a plain-English value proposition, a concrete example, or an obvious next step.

The highest-impact changes are straightforward. First, disambiguate “IOTA / IOTA-1 / Iota” from the official IOTA Foundation ecosystem unless these properties are formally part of it; the IOTA Foundation’s own trademark policy says third-party projects should avoid implying endorsement and should include a trademark notice when referring to IOTA. Second, simplify the top of each page so that “what this is,” “who it is for,” “what I should do next,” and “what makes it trustworthy” appear before deep specification or provenance detail. Third, standardize technical SEO and localization: align <title>, H1, and visible hero copy; use unique descriptions; implement reciprocal hreflang where localized pages exist; and make canonical/indexing choices explicit for AIWikis so it does not compete ambiguously with source-authority pages.

The performance and Core Web Vitals portion of this report should be read as a risk-based audit rather than a numeric benchmark. PageSpeed Insights combines lab and field data, but exact public PSI result URLs for these four pages were not retrievable from this environment. The correct operational move is to capture baseline PSI mobile and desktop reports in the first sprint, then manage against Google’s published thresholds: LCP at or below 2.5s, INP at or below 200ms, and CLS at or below 0.1 at the 75th percentile.

If you only do five things in the next thirty days, do these: replace each page lead with a plain-English headline and one-sentence subhead; add a visible affiliation/trademark clarification where needed; collapse and reorder navigation, especially on JustAnIota; add example-first onboarding on the converter; and decide whether AIWikis pages are meant to rank as provenance resources or should be noindex, follow referral pages back to source authority.

Current-state audit

Two audit notes before the page-by-page tables. First, exact <head> metadata, response headers, and public PSI result pages were not exposed in the rendered page extracts available here, so those rows are marked as “verify in source” where appropriate. Second, the WCAG observations below are based on visible structure, controls, language handling, images, and likely interaction patterns, not on a full automated scan. The applicable accessibility standards for this work are descriptive headings and labels, programmatic structure, language of page, keyboard operability, visible focus, non-text alternatives, and sufficient contrast.

Protocol5 — Language Converter Reviewed from the live page title, heading structure, converter controls, evidence panes, and internal links.

JustAnIota — home page Reviewed from the live /en-us/ page, including nav, language selector, hero, imagery, section order, and CTAs.

AIWikis — Protocol5 page Reviewed from the live page’s heading, summary, sections, and boundary copy.

AIWikis — JustAnIota page Reviewed from the live page’s preserved-batch summary, authority boundaries, retrieval path, and change log.

Competitor benchmark

The most useful benchmarks for this portfolio are not random crypto sites; they are documentation and community surfaces that solve the same trust-and-comprehension problems. IOTA Docs and IOTA’s “Get Started” page segment users by task, surface search and tooling, and connect product, docs, community, and contribution paths in one system. Shimmer packages a technical product with fast visual proof blocks. Ethereum’s docs and contribution pages make community contribution and translation first-class. Polkadot docs and wiki add “Edit this page / Report an issue” affordances and even expose LLM-friendly markdown indexing, which is especially relevant for your AI-oriented properties.

The benchmark implication is simple: your sites do not need less rigor; they need rigor in a more progressive presentation order. The best-performing references explain first, prove second, and archive/specify third. Your current pages often specify first.

Prioritized recommendations

A strong cross-site pattern already exists inside your own copy: JustAnIota says every core record should start with a short explanation, then a technical summary, then a detail layer; Protocol5’s root also frames itself in readable layers. The immediate recommendation is to operationalize that promise on every page. In practice, that means one above-the-fold plain-English summary, one clear action path, and one expandable deep layer for evidence, schema, or provenance. That copy order also aligns with how Google derives title links and snippets from title elements, visible headings, and on-page content, and with how multilingual pages should be clustered through canonical and hreflang signals.

A second priority is naming clarity. The official IOTA trademark policy says third-party projects should avoid implying they are the IOTA network or an official IOTA Foundation product, and should use a visible trademark notice when referring to IOTA. Because these pages use “Iota Protocol,” “IOTA-1,” and “JustAnIota” in close proximity to public-language claims, I would add a visible clarifier in the footer or hero trust strip if there is no official affiliation. I would also standardize internal naming so the user sees one product name, not three overlapping names, for the same experience.

A third priority is accessibility and localization hardening. All four pages should get programmatically determinable language, descriptive headings and labels, explicit keyboard paths, visible focus states, and sufficient contrast. Symbol-heavy content must have accessible spoken equivalents. JustAnIota already shows real localization intent with /en-us/ and a Chinese selector, so it should be the first site to receive a fully reciprocal hreflang cluster and an x-default page; Protocol5 and AIWikis can follow when they have real locales to maintain. Google recommends different URLs for different language versions, while W3C requires that the default language of each page be programmatically determinable.

A fourth priority is trust and community. Ethereum, IOTA, and Polkadot all make contribution, support, or bug-report paths visible. Your pages should do the same. For JustAnIota, that means “Report an issue,” “Suggest an example,” and “Discuss implementation”; for Protocol5, it means “Try a sample phrase,” “Open validator,” and “Report a mismatch”; for AIWikis, it means “Request correction,” “See source authority,” and “Review provenance.”

The most important UX flows should look like this:

flowchart TD
    A[Search or referral landing] --> B{Visitor intent}
    B -->|Understand it| C[Plain English overview]
    B -->|Try it now| D[Converter or Validator]
    B -->|Trust the claims| E[Evidence and Registry]
    C --> F[Three-step how it works]
    F --> D
    D --> G[Result summary]
    G --> H[Evidence trace]
    H --> I[Spec, examples, API, next step]

flowchart TD
    A[AIWikis source memory page] --> B[What this page is]
    B --> C[Last preserved batch and timestamp]
    C --> D[Plain-English summary]
    D --> E[What changed]
    E --> F[Source authority CTA]
    D --> G[Provenance and hash manifest]
    G --> H[Correction or refresh request]

For the homepage wireframes, I would keep them simple and brutally scannable:

JustAnIota mobile wireframe
[Utility bar: Language | Search | Status]
[Hero: H1 + 1 sentence + Primary CTA + Secondary CTA]
[Proof strip: Converter | Validator | Registry | Last updated]
[Intent cards: Build | Review | Understand]
[How it works in 3 steps]
[Authority boundary block]
[Community / report issue / roadmap]

Protocol5 converter mobile wireframe
[Hero: what conversion means]
[Example chips]
[Input card]
[Mode / direction controls]
[Result summary]
[Evidence accordion]
[Advanced JSON]
[Spec / validator / examples CTA row]

Roadmap and success metrics

The roadmap below assumes no hard budget or stack constraints. It is intentionally sequence-first: clarify positioning, then fix IA and SEO, then invest in performance, localization, and contribution systems. That order follows how search engines interpret page titles, snippets, canonicals, and language variants, and how users interpret trust and relevance before they care about deep implementation detail.

Testing and QA checklist

The release gate should cover accessibility, SEO, performance, localization, security, and contribution pathways together. Google’s guidance on snippets, title links, canonicals, and localized versions; W3C’s WCAG guidance on language, labels, headings, keyboard, focus, contrast, and non-text alternatives; and OWASP/RFC guidance on security headers and security.txt are the right standards backbone for this portfolio.

The guiding principle for all four pages is the same: keep the rigor, but move it into a layered experience. The sites are already rich in boundaries, evidence, and provenance. What they need next is faster comprehension, cleaner intent paths, and clearer signals to users, search engines, assistive tech, and contributors about what each page is for.