Content Audit and Improvement Plan for 2IA.org

Full report

On this page

Executive summary

2IA.org has a strong editorial premise, a clearly stated public-interest mission, and a surprisingly well-developed thematic structure for a small research archive. The site frames itself as an “independent, information-only research archive,” separates evidence from inference, and exposes substantial topical breadth through a unified discovery layer that points users to an Intelligence Library, Research Briefs, Research Guides, Topic Hubs, Organizations, World Events, Historical Sources, and Current Developments. The public site also claims substantial scope: 63 report adaptations, 12 briefs, 12 guides, 321 indexed public routes, 224 World Events records, 2,058 nuclear records, and 19 sources plus 29 feeds in its historical-source layer.

The central problem is not lack of substance. It is that too much of the site’s internal editorial scaffolding is visible as public content. A large share of public pages open with repeated “Page review,” “Review boundary,” “Evidence and review note,” “Use this when,” “Records that answer it,” and “Verification focus” blocks. In many places, the public experience feels like reading a content model, QA checklist, or release package rather than a finished editorial product. That pattern is especially visible on /contact/ , /lawful-contact/ , /newsletter/ , /privacy-policy/ , /public-records-and-foia/ , /topic-hubs/ , /corrections-and-right-of-reply/ , and many nested child pages.

Several pages appear to be prelaunch or operator-facing content exposed publicly. The clearest examples are /developments/ , which shows zero current entries, says no scheduled refresh has completed, and instructs an operator to run php bin/update-developments.php; /newsletter/ , which explicitly says signup is not active; /contact/ , which says there is no public inbox, no secure drop, and no PGP or Signal route published; and /privacy-policy/newsletter-donation-and-volunteer-data/ , which reads like an internal governance checklist rather than a user-facing policy page. These pages undermine trust because the site is presenting “routes” and calls-to-action that are not yet operational.

Branding and search presentation are also inconsistent. The publication increasingly describes itself as the “International Intelligence Archive,” and the About page explicitly says Anonymous is now a major research collection rather than the publication’s identity. Yet search results, page titles, and footer boilerplate still repeatedly surface “2IA — Two Identities Of Anonymous.” The retained route /two-identities/ now maps to “Identity Layers,” and /psychological-warfare/ is titled “Influence Operations and Media Literacy.” Those mismatches are not fatal, but they create unnecessary cognitive friction for readers and search engines.

SEO and discoverability are held back less by topic quality than by editorial duplication and indexing hygiene. Some search snippets look rich and descriptive, but several others are dominated by boilerplate, footer text, or repeated sitewide phrasing, which suggests weak page differentiation and possibly underperforming meta descriptions or snippet control. More seriously, at least two indexed URLs currently return 404s: /start-here/choose-a-path/ and /methodology/confirmed-corroborated-inferred-disputed-unknown/ . That points to stale indexation and a likely need for stronger redirect, canonical, robots, and sitemap discipline.

The site’s technical direction appears privacy-forward and potentially performance-friendly. The privacy policy says this plain-PHP release does not add tracking pixels, external fonts, CDN assets, behavioral heatmaps, third-party analytics, or unnecessary cookies; the historical-sources page says it makes zero third-party page-load requests; and the developments page says it uses server-side ingestion plus local snapshots with zero browser-side feed calls. Those are positives. However, I could not directly verify response headers, canonical tags, robots directives, XML sitemaps, or live Core Web Vitals in this environment, so those areas should be treated as partially assessed and in need of direct tooling validation.

The highest-priority actions are straightforward: stop indexing placeholder and operator-facing pages; make every promoted CTA actually usable; unify the brand and URL vocabulary; redirect stale 404 routes; reduce boilerplate at the top of public pages; and run a direct technical audit for canonicals, robots, sitemaps, security headers, and broken links. Those changes would improve trust, clarity, search performance, and conversion without requiring a wholesale rewrite of the archive’s underlying thesis.

Scope and assumptions

This audit is based on anonymous, public access only. I did not have credentials for any CMS, analytics, Search Console, server logs, staging environment, raw HTML source inspection, or non-public areas. The site itself presents a research/discovery layer that claims 321 indexed public routes, and I used those public discovery pages plus live representative page opens and search-index evidence to map the site’s public structure.

Because this environment did not expose raw HTTP headers or full HTML source for every page, the assessment of canonical tags, robots directives, XML sitemaps, some metadata behavior, security headers, and device-specific responsiveness is necessarily partial. Where direct verification was not possible, I have called that out explicitly and based recommendations on publicly observable behavior, search results, and the site’s own implementation claims. No assumptions were made about any non-public admin, authoring, or moderation workflows beyond what the public pages themselves reveal.

Public site map and structure

At a family level, 2IA has a coherent and fairly robust information architecture. The top navigation is consistent across sampled pages, with recurring routes for Start Here, Topics, Research, Anonymous, Developments, Method, and About. Beneath that, the site organizes public content into research layers rather than a traditional blog taxonomy. That is generally a strength: users can move from orientation pages to topic hubs to directories to more granular dossiers and data layers.

flowchart TD
    Home["Home"]
    Start["Start Here"]
    Research["Research"]
    Topics["Topic Hubs"]
    Anonymous["Anonymous Collection"]
    Issues["Issues Map"]
    Orgs["Organizations Directory"]
    World["World Events"]
    Nuclear["Nuclear Catalog"]
    Sources["Historical Sources and Feeds"]
    Dev["Current Developments"]
    Method["Methodology"]
    FOIA["Public Records and FOIA"]
    Privacy["Privacy Policy"]
    Corrections["Corrections and Right of Reply"]
    Support["Support"]
    Newsletter["Newsletter"]
    Volunteer["Volunteer"]
    Contact["Contact and Lawful Contact"]

    Home --> Start
    Home --> Research
    Home --> Topics
    Home --> Anonymous
    Home --> World
    Home --> Issues

    Research --> Orgs
    Research --> World
    Research --> Nuclear
    Research --> Sources
    Research --> Dev
    Research --> Method

    Topics --> FOIA
    Topics --> Method
    Topics --> Privacy
    Topics --> Corrections

    Home --> Support
    Home --> Newsletter
    Home --> Volunteer
    Home --> Contact

The site map is conceptually sound, but the public experience is burdened by too many near-duplicate editorial prefixes. In IA terms, 2IA has a strong backbone and a weak front-of-house. The best pages act like durable entry points; the weaker ones act like content-type demonstrations.

Findings on content, navigation, and SEO

The strongest content characteristic is intellectual clarity about the site’s mission. The homepage and About page consistently present a rights-focused, source-aware editorial identity, and the Research page makes a strong case for why different publication formats exist. The site also does a good job of expressing boundaries: it distinguishes evidence classes, warns against operational misuse, and explicitly marks uncertainty. That kind of rigor is unusual and valuable.

The primary content weakness is that the editorial template overwhelms the editorial message. Across many pages, users encounter the same scaffolding before the specific page value starts: “Page review,” “Review boundary,” “Evidence and review note,” “Use this when,” “Records that answer it,” “Verification focus,” and “Copy this question.” That repetition makes individual pages feel duplicative, lengthens scroll depth, and weakens the distinct SERP identity of each route. On subpages like /newsletter/cadence-beats-noise/ , /privacy-policy/newsletter-donation-and-volunteer-data/ , /what-they-look-for/records-to-request/ , /ai-surveillance/do-not-let-ai-launder-uncertainty/ , and /two-identities/pseudonymity-can-be-civic-infrastructure/ , the same pattern reappears almost verbatim.

A second major problem is public-facing placeholder content. Several pages are published even though they explicitly say the related function is not live. The newsletter page says signup is not active and should not ask for an email address. The contact page says no public inbox, secure drop, PGP key, or Signal route is published. The developments page says no scheduled refresh has ever completed and exposes the CLI instruction to run the updater. The corrections page says a public correction log “should” exist, but that no public corrections are logged yet. These are not small polish issues; they change whether users can trust calls-to-action and trust-related navigation at all.

Audience targeting is directionally correct but inconsistently executed. The site appears to target a mixed audience of researchers, journalists, civil-liberties advocates, FOIA users, digital-rights readers, and technically literate members of the general public. That broad target is visible in the homepage’s “Choose a reader task” flow and in the Organizations Directory. But the prose frequently slips into internal language such as “source-controlled site,” “review boundary,” “evidence packet,” “current-through cutoff,” “protected analytical tracks,” and release-version notation. That vocabulary will feel precise to an editor or archivist, but opaque or over-engineered to many first-time readers.

Calls-to-action are one of the clearest UX/content misfires. The homepage promotes Newsletter, Support, and Volunteer, but the newsletter is not operational. The Contact pathway exists, but it is effectively a boundary page plus a downloadable correction template, not an active communications route. The homepage also appears to yield concatenated CTA text in search/rendered extraction—“ReadResearch files RequestRecords and contracts CorrectFlags and claims”—which suggests that crawler-visible copy separation is not clean enough. Even if the visual presentation is better in-browser, the extracted text indicates there is room to improve semantic clarity and machine-readable separation.

Branding is the largest strategic consistency issue. The About page makes a clear move toward “International Intelligence Archive,” and it explicitly says Anonymous is a major collection rather than the publication identity. Yet search results and route labels repeatedly surface the older “Two Identities Of Anonymous” brand. The retained route /two-identities/ now serves “Identity Layers,” which is sensible for backward compatibility, but it adds another interpretive layer for users who are already trying to understand whether the publication is about Anonymous, intelligence institutions, identity systems, or all three. Likewise, the route /psychological-warfare/ now carries the page title “Influence Operations and Media Literacy,” which is more moderate and precise than the slug. These mismatches should be cleaned up.

From an SEO perspective, the good news is that many titles are descriptive, the slugs are generally clean and hyphenated, and the site has substantial topical clustering. The bad news is that Google’s own guidance emphasizes unique, useful snippet and canonical signals, while several 2IA search results surface generic/footer-like text rather than page-specific value, and at least two indexed URLs now resolve to 404. That combination strongly suggests a need for better page differentiation, redirect management, and index-control hygiene. Google’s documentation also makes clear that meta descriptions, canonical tags, robots controls, and sitemaps all play a role in helping search engines understand which pages should be shown and how.

Findings on accessibility, performance, mobile, and security

The site shows some promising accessibility signals. At least one sampled page includes a “Skip to content” link, and the site makes extensive use of headings, section labels, and text-based content, which is a good baseline for WCAG-friendly structure. W3C guidance emphasizes meaningful heading hierarchy and clear headings and labels, and 2IA’s content architecture is at least visibly sectioned rather than visually flattened.

The main accessibility risks are cognitive load and image-text handling, not flashy UI failures. The homepage and many child pages are very dense, and their repeated template sections create long-scroll, high-effort reading on any device. In addition, the crawler-visible rendering of at least one homepage image appears only as “Image,” which suggests that some non-text content may not yet have adequately descriptive alternative text. WCAG requires text alternatives for non-text content, and WAI guidance stresses that alt text should reflect the image’s function, not default to a generic label.

On mobile responsiveness, I could not directly test breakpoints or viewport behavior. The best public inference is that the site is likely layout-light because it is overwhelmingly text-driven, but the content density itself is a mobile UX issue. Long directories like Organizations and Historical Sources, and template-heavy child pages like the dossier pages, will create deep scroll stacks and make “where am I?” orientation harder on smaller screens, even if the CSS is technically responsive.

Performance posture appears favorable in principle. The privacy policy says the public release avoids tracking pixels, external fonts, CDN assets, behavioral heatmaps, third-party analytics, and unnecessary cookies. The historical-sources page says it makes zero third-party page-load requests, and the developments page says it uses server-side ingestion with a local snapshot and zero browser-side feed calls. Those are all positive architectural choices because fewer third-party resources and less client-side work often reduce latency, privacy risk, and fragility. But real performance should still be validated with Core Web Vitals and PageSpeed Insights, because content length, DOM size, and interactive script behavior can still degrade LCP, INP, and CLS even on “light” pages.

Security is mixed in the sense that the implementation philosophy looks conservative, but the critical transport/browser hardening controls were not directly inspectable here. The site publicly claims no visitor login, no application cookie, and minimal tracking surface on the public release, which is good. However, response-header hardening should still be verified directly, because HSTS, CSP, and frame-embedding protections are delivered at the HTTP/browser-policy layer, not inferred from page copy. MDN’s documentation is clear that HSTS enforces HTTPS, CSP constrains what browsers can load/execute, and X-Frame-Options or CSP frame-ancestors mitigate clickjacking.

Broken-link checking was possible only on a sampled basis, not as a full crawler export. The good news is that many top-level internal links and route families did resolve cleanly during this audit. The bad news is that at least two stale indexed URLs returned 404s, which is enough to justify a direct broken-link crawl and a redirect map pass. Duplicate-content risk is also real, not because of copied articles, but because so many pages share the same lead structure and explanatory template. From Google’s perspective, that kind of near-duplicate framing can weaken canonical clarity and snippet quality.

Prioritized recommendations and remediation workflow

The fastest way to improve 2IA is not to add more content. It is to tighten the public promise. Every page that appears in primary navigation or receives search traffic should either do a real thing or stop pretending to do that thing. In practice, that means making the public archive feel more finished and less source-controlled. Google’s guidance supports this direction: make pages useful to users first, differentiate snippets, declare canonicals clearly, control indexation for pages that should not appear in search, and keep sitemap/indexing hygiene current. W3C and MDN guidance similarly support cleaning up headings, alt text, and browser security policy.

Estimated effort below assumes a small team with editing access and light development support.

flowchart TD
    A["Inventory all indexed public routes"] --> B["Classify each route"]
    B --> C["Public-ready editorial page"]
    B --> D["Placeholder or prelaunch page"]
    B --> E["Stale or broken URL"]

    C --> F["Rewrite front matter for clarity and unique search intent"]
    D --> G["Choose: launch, merge, hide, or noindex"]
    E --> H["301 redirect or retire from sitemap/index"]

    F --> I["Normalize titles, slugs, internal links, and CTAs"]
    G --> I
    H --> I

    I --> J["Run technical QA: broken links, canonicals, robots, sitemap"]
    J --> K["Run accessibility and performance QA"]
    K --> L["Re-submit in Search Console and monitor snippets/indexation"]

If 2IA follows only three actions in the next cycle, they should be these: first, remove or hide the non-operational trust/CTA pages; second, redirect stale 404s and clean indexing controls; third, strip the repeated review-template boilerplate from the top of public pages and lead with the page’s actual human value. Those three changes would make the site feel significantly more trustworthy, more usable, and more search-ready while preserving its strongest asset: a serious, source-aware editorial identity.