Two Identities Of Anonymous Website Audit and Improvement Plan

Full report

On this page

Executive Summary

2IA already has a distinctive editorial voice and a few solid fundamentals. The published pages consistently expose a skip link, most rendered pages have clear page titles and visible H1s, the site uses HTTPS, and the privacy policy explicitly says the theme avoids analytics, tracking pixels, external fonts, CDN assets, and unnecessary cookies by default. Those are meaningful strengths for a site about surveillance, identity, and civil liberties.

The larger problem is not concept; it is launch readiness. The current public experience still looks partly like a seeded or pre-launch WordPress build: the archive shows the default “Hello world!” post, the homepage still advertises draft topics, six footer-linked topic archives are empty, and several high-value routes exposed in navigation, footer, or homepage teasers could not be fetched in the audit environment, including Start Here, Methodology, Support, Newsletter, Volunteer, Public Records and FOIA, Corrections and Right of Reply, and multiple planned briefing URLs. That combination weakens trust, wastes crawl value, and interrupts user journeys at exactly the points where first-time readers or supporters need clarity.

The most important immediate move is to stop exposing unfinished structure. Every linked public route should either be fully publishable or intentionally hidden/noindexed. Google’s guidance is explicit that good title links are descriptive and distinct, snippets are built from page content and sometimes meta descriptions, structured data should describe visible page content, and noindex is the correct page-level way to keep low-value pages out of Google Search. For 2IA, that means removing or noindexing placeholder posts, empty taxonomies, and incomplete routes before investing in finer SEO polish.

The second priority is to turn the site into a coherent funnel. Right now, the homepage nav emphasizes Start Here, Methodology, Support, and About, while interior pages switch to a different nav model built around Home, What They Look For, Two Identities, Research Archive, and About. That inconsistency makes the site harder to understand and harder to navigate, especially on mobile or for first-time visitors. A single navigation model centered on cornerstone pages, topic hubs, and evidence-backed briefings will produce a much stronger user experience and a cleaner crawl path.

The third priority is to make the published content look and behave like research, not just rhetoric. The best existing pages are thoughtful, high-level concept essays, but most of them still need dates, bylines, source notes, cross-links, clearer evidence framing, and related-briefing pathways. Google’s article, organization, and breadcrumb documentation makes it straightforward to support this with structured data, while manual accessibility testing should focus on text alternatives, descriptive link purpose, visible focus, labels, and reflow at 320 CSS pixels.

If those three things are done well—publishable routes only, one coherent information architecture, and real research-page craftsmanship—the site can quickly move from “intriguing concept with unfinished scaffolding” to “credible independent research publication.”

Audit Scope and Method

This audit was based on rendered-page review, public route discovery from navigation/footer/internal links, and comparison against official guidance from W3C WCAG 2.1 and Google’s Lighthouse, Search Central, Search Console, and web.dev documentation. Several same-domain URLs were discoverable from public navigation or homepage cards but could not be rendered in the browsing environment because they returned fetch failures; those were treated as public-facing risks and included in the page inventory below rather than omitted. Lighthouse itself is designed for exactly this kind of work: it audits performance, accessibility, SEO, and related quality dimensions, and can be run in Chrome DevTools, from the command line, or in CI via Lighthouse CI.

Because direct PageSpeed Insights or Lighthouse reports were not available within this audit capture, the performance observations below are qualitative, structure-based estimates rather than lab scores. They should be validated during implementation with mobile and desktop Lighthouse runs, PageSpeed Insights, and real-user monitoring. Google’s Web Vitals guidance remains the right benchmark: p75 LCP should be at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Google also recommends first-party real-user monitoring for these metrics rather than relying only on aggregated tools.

The effort estimates below use this scale: Low means copy, config, routing, or template cleanup; Medium means template/component/CMS changes or substantial rewrites; High means a new content model, significant engineering work, or a multi-sprint editorial rollout.

The chart below shows a qualitative performance-risk estimate by page template, based on page structure rather than machine-scored lab tests.

xychart-beta
    title "Qualitative performance-risk by template"
    x-axis ["Home","Archive","Topic essays","Legal/contact","Empty taxonomies"]
    y-axis "Risk score" 0 --> 5
    bar [5,4,3,2,1]

Sitewide Findings

The most serious sitewide issue is that the public IA currently exposes more ambition than execution. The homepage advertises Start Here and Methodology as primary onboarding routes, but those routes could not be fetched. The footer advertises Public Records, Corrections, Newsletter, and Contact-related pathways, but some of those routes were likewise unavailable. Meanwhile, the footer’s “Research areas” links route users into empty taxonomy archives rather than the better-developed conceptual pages that do exist. Google emphasizes that links are crucial both for users and for discovery, and weak internal-link destinations directly undercut that.

Branding is also inconsistent enough to create trust and SEO drag. The homepage H1 uses “2IA - Two Identities of Anonymous,” the footer uses “2IA — Two Identities of Anonymous” or “Two Identities Anonymous,” inner-page eyebrow text varies, and the visible site name line includes “International Intelligence Apparatus” even while the page repeatedly states that the project is “not affiliated with any government agency.” Google recommends distinct, concise titles and a clear main title relationship between page content and title text; 2IA should settle on one canonical brand string and use it everywhere.

Content maturity is the next major issue. The site’s strongest pages are conceptual essays on identity, surveillance, OSINT, influence operations, ethics, privacy, and contact boundaries. That gives the project a coherent worldview. But the site still lacks the visible signals of a mature research publication: real briefings in the archive, stable topic hubs, bylines, publication/updated dates on most key pages, source notes, correction history, and outward-facing transparency about who writes and how claims are checked. Google’s SEO Starter Guide emphasizes useful, people-first content and corroborating resources, while Article structured data is specifically designed to help search engines understand titles, dates, authors, and images on article pages.

Accessibility has a decent baseline but needs manual verification on the right components. The good news is that the site exposes a skip link, which aligns with WCAG’s requirement to let users bypass repeated blocks. The riskier areas are the generic “Image” exposure on multiple pages, the archive’s apparently blank linked element around the placeholder post, the sitewide search control that renders as “Search Search,” and the dense inline content blocks that may become difficult to reflow or navigate at narrow widths. WCAG 2.1 is especially relevant here for non-text content, bypass blocks, link purpose, headings and labels, visible focus, input labels, programmatic names and roles, contrast, and 320px reflow.

SEO fundamentals are partly present and partly unverified. The rendered pages appear to have descriptive titles such as “About 2IA,” “Research Archive,” “Open-Source Intelligence,” “Two Identities,” and “Privacy Policy,” which is a good start. But the audit environment could not directly confirm meta descriptions, canonical tags, or on-page JSON-LD. Google recommends that every page have a clear title, that meta descriptions offer a short relevant summary when useful, that one canonical method be chosen consistently, and that structured data be used to describe visible content on the page—not blank or thin pages. That means 2IA should explicitly verify homepage Organization markup, interior BreadcrumbList markup, and Article markup for published briefings, while removing or noindexing pages that are empty or unfinished.

Performance risk appears manageable but is still real. The pages are largely text-based, which is favorable, yet the homepage is long, image-bearing, and structurally dense. Google’s Web Vitals documentation sets the user-experience thresholds, while web.dev guidance recommends lazy loading for below-the-fold images, eager loading for likely LCP images, explicit width/height (or aspect ratio) on all images to reduce CLS, and modern image formats such as WebP to reduce file size. The current template should therefore be treated as image- and footer-sensitive, with the homepage and archive template as the highest-priority pages for optimization.

Privacy is a genuine strength and should remain one. The privacy policy says the theme avoids analytics, tracking pixels, external fonts, CDN assets, and unnecessary cookies by default; it also warns that any future forms, newsletters, or analytics packages need review for purpose, consent, retention, access, deletion, and opt-out behavior. That posture fits the site’s subject matter and brand. The right next step is not “more tracking”; it is measured, first-party, privacy-preserving instrumentation. At the same time, Google’s Lighthouse best-practices guidance remains relevant for security hardening, including CSP, HSTS, and clickjacking protection.

The highest-return priorities are below.

Page-by-Page Audit

The table below compresses the audit for every discoverable public route. The primary issue patterns referenced here map back to the sitewide standards analysis above.

Reviewed pages

Secondary routes, empty taxonomies, and discoverable but not fully inspectable URLs

Recommended Architecture and Component Plan

The clearest way to improve 2IA is to align the site’s structure with the route patterns it is already hinting at. Right now, the public IA mixes homepage concept pages, empty taxonomy archives, footer trust/policy pages, and unreleased child-briefing routes. The better model is a three-layer architecture: cornerstone pages for orientation and trust, topic hubs for themes, and briefings for specific claims or case studies. Google’s SEO guidance supports logical site organization, breadcrumbing, structured data for visible content, and CMS-generated sitemaps where appropriate; 2IA’s own route map strongly suggests that it is already moving in this direction, just not consistently yet.

A recommended public sitemap is below. It preserves the site’s current conceptual strengths but removes the dead-end taxonomy pattern and turns the discoverable “planned” routes into a coherent publishing model.

graph TD
    A[Home] --> B[Start Here]
    A --> C[Research Archive]
    A --> D[Methodology]
    A --> E[Topic Hubs]
    A --> F[About]
    A --> G[Support]
    A --> H[Policies]
    A --> I[Contact]

    B --> B1[What 2IA is]
    B --> B2[How to use the archive]
    B --> B3[Recommended first briefings]

    D --> D1[OSINT framework]
    D --> D2[Verification and source standards]
    D --> D3[Ethics and civil liberties]

    E --> E1[Metadata and Identity]
    E --> E2[Keyword Monitoring]
    E --> E3[AI Surveillance]
    E --> E4[Anonymous and Hacktivism]
    E --> E5[Influence Operations]
    E --> E6[Public Records and FOIA]
    E --> E7[False Positives]

    C --> C1[All briefings]
    C --> C2[Filter by topic]
    C --> C3[Archive search]

    H --> H1[Privacy Policy]
    H --> H2[Corrections and Right of Reply]
    H --> H3[Lawful Contact]

    G --> G1[Newsletter]
    G --> G2[Volunteer]
    G --> G3[Support]

The template/component layer should change with the same logic. The global header should be consistent on every page; the current split between homepage navigation and interior-page navigation should be removed. The homepage hero should become a concise positioning statement with one main action and one secondary action. The briefing card should display a title, dek, topic, date, author/editor, reading time, and one-sentence why-it-matters summary, instead of blank-card or draft-card behavior. The article template should include H1, dek, byline, published and updated dates, source notes, confidence statement, related briefings, and a visible corrections link. The contact/policy template should include a last-updated date and a clear action path, rather than policy-only prose. The footer should be simplified: keep brand/legal/accountability links, remove archive month/default-category noise, and stop sending users to empty taxonomies.

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.

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.

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.

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.

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.

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.”