A marketing-led site for a security/privacy automation product with no developer documentation surface, an internally contradictory privacy/trust posture, orphaned and duplicate pages indexed by search, and FAQs that ship questions without answers. The most consequential issue is a Privacy Policy that disclaims data sharing with a hosting provider the site doesn't actually use.
1. Privacy Policy describes the wrong hosting provider (critical)
Location: /trust/privacy-policy and /trust/subprocessors
Problem: The Privacy Policy (last updated March 11, 2026) states that "This website is hosted by Webflow," that Webflow is the analytics provider, that "We share this information with Webflow, our online store hosting provider," and that "We share your contact information with Webflow, our email marketing provider." However, the live site is served by Framer — every 404 returns <title>Page Not Found | Framer</title>, and the DOM is populated with framer-* class names and data-framer-hydrate-v2 attributes. Meanwhile, the /trust/subprocessors page (last updated April 6, 2026) lists only PropelAuth, Ryvn, AWS, Convex, OpenAI, and Anthropic — neither Webflow nor Framer appears anywhere on the subprocessor list.
Consequence: The single document a GDPR/CCPA-regulated buyer or privacy regulator relies on is factually wrong about where personal data actually flows. EU customers cannot do an accurate transfer impact assessment, and the subprocessor disclosure is incomplete by omission of the actual website host. For a company whose entire pitch is "regulator-ready privacy assessments," this is the most consequential trust-surface defect on the site.
The fix: Rewrite the Privacy Policy "Information We Automatically Collect" section to name Framer (the actual host) — or migrate the public site to Webflow to match the policy. Add the website host to /trust/subprocessors. Publish a "last reviewed" cadence that catches a hosting migration on the legal pages.
2. SOC 2 attestation has no findable trust surface, and the whitepaper CTA is broken (critical)
Location: /trust/security-privacy (and absence on the rest of the site)
Problem: The dedicated trust page enumerates infrastructure, access control, data security, GRC, and AI Governance — but never mentions SOC 2. The only references to the company's SOC 2 status on the entire site are buried inside two blog posts: /blog/security-soc-2-startups ("Yes, Clearly AI has our SOC 2. But that is not the purpose of this blog post") and /blog/one-year-of-clearly-ai (mentions "SOC2 certification" in passing alongside other "bells & whistles"). There is no Trust Center, no Vanta/Drata embed, no "request our SOC 2 report" CTA, no listed framework certifications. /solutions/grc-teams advertises alignment with "ISO, NIST, PCI-DSS, NYDFS" — none of which are substantiated elsewhere. The trust page also ends with a "Learn more about Security & Privacy — Explore Our Whitepaper" CTA that has no underlying link or download — the page promises a whitepaper and doesn't deliver one.
Consequence: An enterprise security buyer who lands on the dedicated trust page concludes Clearly AI has no formal attestation, when in fact the company claims one. The dead whitepaper CTA compounds the impression that the trust surface is unfinished. Procurement bounces. Worse, this is a security/GRC product selling to GRC teams — the trust surface IS the product surface.
The fix: Add a "Certifications & Attestations" block to /trust/security-privacy listing SOC 2 (with type, scope, and a request-the-report form). If ISO/NIST/PCI/NYDFS alignment is real, link the mappings. If not, remove the framework name-drops from /solutions/grc-teams. Either publish the whitepaper or remove the CTA.
3. Five FAQ accordions promise answers and deliver none (critical)
Problem: Every use-case page has a section headed "FAQ — Answers to your top questions" with three to four expandable questions (e.g., "How does automated threat modeling work?", "Can Clearly AI follow up with a vendor on my behalf?", "Can I create custom escalation behavior?"). In every case, the DOM contains no answer body — clicking the row reveals nothing. The pattern is identical across all five use-case pages.
Consequence: The five highest-intent landing pages on the entire site (the ones a prospect arrives at from a search like "automated threat modeling") tease answers to qualifying questions and then withhold them. Visitors leave with the impression the site is broken or, worse, that the company is deliberately gating basic answers behind a demo call.
The fix: Either populate the FAQ answer bodies (the questions are good ones — they correspond to real buyer objections) or remove the FAQ component entirely. If the answers exist in a CMS but the rendering is broken, fix the accordion component — this is a single defect repeated across five pages.
4. Duplicate "Product" page is indexed, linked from the homepage, and contradicts the canonical one (significant)
Location: /product-archive (vs. /product)
Problem: /product-archive has <title>Product</title> identical to /product, is in sitemap.xml, is reachable from the homepage CTA "Customized to YOUR Policies > Read More", and is allowed by robots.txt. It carries claims that don't appear on the canonical /product page: "30+ Automated Review Templates", "20+ Native Integrations", and "built-in Drawio" diagramming. It also misspells "Scalability" as "Scalibility" and attributes a testimonial from Ashley Haynes as "Sr. Security Engineering Manager" with no obvious canonical equivalent on the live product page.
Consequence: Google indexes two competing Product pages with conflicting feature counts. Prospects who follow the homepage CTA land on a page the team has presumably deprecated and read claims (template count, integration count, Drawio support) that don't appear on the live product page — and that an AI agent scraping the site cannot reconcile.
The fix: 301-redirect /product-archive to /product. Fix "Scalibility". If the "30+ templates / 20+ integrations / Drawio" claims are accurate, port them to /product; if not, retire them. Reconcile testimonial attributions to one canonical title per speaker.
5. No llms.txt and no machine-readable product surface (significant)
Problem: /llms.txt and /llms-full.txt both 404. There is no OpenAPI spec (the product has no public REST surface documented anywhere), no structured integrations list (the homepage says "Jira, GitHub, Confluence, Google Drive, and more"; /blog/how-to-automate-security-and-privacy-reviews-with-clearly-ai adds ServiceNow; /product-archive claims "20+ Native Integrations" without naming them), and no machine-readable feature matrix. The most technical content on the site, /blog/clearly-ai-technical-explanation, exists only as prose in a single blog post. The /blog/one-year-of-clearly-ai post compounds the problem — its "Clearly by the Numbers" sections render as empty blocks because the numbers are inside images with no alt text, so any agent (or screen reader) sees a blank section under that heading.
Consequence: AI coding agents and AI buyer-research tools (now a primary discovery channel for B2B security tools) cannot reliably summarize the product, integration list, or trust posture. A buyer who asks an agent "what does Clearly AI integrate with" gets contradictory answers — and the contradictions come from Clearly AI's own pages.
The fix: Publish an llms.txt pointing to canonical pages for product, trust, integrations, and case studies. Publish a structured integrations page enumerating every supported tool (Jira, GitHub, Confluence, Google Drive, ServiceNow, Slack, anything else) with one row per integration. Replace image-based metrics with real text. If the product has a REST API or webhooks (the how-to-automate blog says "You can configure webhooks on different actions"), publish a reference.
6. Rivian's and HID's headline metrics are described different ways across different pages (significant)
Problem: The same Rivian 90% number is variously labeled "Reduction in review completion time" (homepage), "PIA timelines by 90%" (/solutions/security-teams), "PIA completion time by 90%" (/solutions/privacy-teams), and "Reduction in review turnaround time" (case study). The "4x" Rivian metric is "Increase in team capacity" on the homepage but "Increase in review capacity" on the case study. HID Global's 75% number is "engineering time spent on threat modeling" on /use-cases/threat-modeling but "engineering time spent on compliance tasks" on /case-study/hid-global. William Brown's title at HID Global appears in at least three different forms across three pages ("Sr. Director Product Security and Data Privacy" / "Sr. Director for Product Security and Privacy, HID Global" / a third variant in the homepage testimonial). On /case-study/hid-global itself, three pull-quotes in the body have no attribution at all, even though Brown is named at the top of the page.
Consequence: A prospect comparing claims across pages can't tell whether Clearly AI cut Rivian's "PIA completion time" specifically (a narrow workflow claim) or all "review turnaround time" (a much broader claim). For a product that sells "consistent, high-quality documentation," the inconsistency of the company's own headline metrics undermines the pitch. The unattributed HID quotes also break basic case-study credibility.
The fix: Pick a single canonical phrasing for each customer metric and an authoritative title for each named customer contact. Replace the variants site-wide. Attribute every pull-quote on case-study pages. Treat customer metric phrasing as a content style-guide entry.
7. Founder origin story contradicts itself across pages (significant)
Problem: /about-us says the founders reviewed apps "at Amazon" (Moveworks unmentioned). /solutions/security-teams says "at Amazon and Moveworks." /blog/security-soc-2-startups explicitly confirms the CEO was at Moveworks and that this is where SOC 2 expertise was acquired. The canonical About page drops Moveworks entirely. Separately, Ellen Pao appears as "fmr CEO, Reddit" under "Notable Angel Investors" on /about-us but /blog/seed-round describes "an incredible group of advisors, including ... the former CEO of Reddit" — investor vs. advisor framing is inconsistent. Alesya Nasimova is "Head of Privacy & DPO, Brex" angel investor on /about-us, while /blog/seed-round refers to "the former CPO of Brex" as a separate advisor.
Consequence: Due-diligence reviewers and journalists comparing the about page to the seed announcement get a different story about the founders' background and the cap table. For a company whose differentiator is "Amazon-Tested Expertise," dropping Moveworks from the canonical About page is a real omission, since the SOC 2 expertise the company sells came from Moveworks.
The fix: Standardize the founder backgrounds across /about-us, /solutions/security-teams, and the seed-round post. Clarify the "investor" vs. "advisor" distinction for each named person and use one consistent role label.
8. Trust section has an orphan partial-duplicate and an orphan subprocessors page (significant)
Location: /trust/privacy and /trust/subprocessors (both orphaned)
Problem: /trust/privacy is a strict subset of /trust/security-privacy — same headings, same body — but lives at its own URL with no nav/footer link, discoverable only via sitemap.xml. /trust/subprocessors is the only place that names Convex (the data plane), the only place that reveals Ryvn powers on-prem deployments, and the only place that says "no customer data leaves the United States" — yet it's not linked from /trust/security-privacy, the footer, or anywhere else. robots.txt allows indexing of both.
Consequence: EU/regulated buyers who need a subprocessor list to complete a DPA can't find it from the trust page. Search engines will surface a thin duplicate (/trust/privacy) alongside the canonical page, splitting authority. And the most concrete trust facts on the site — "Convex hosts your data," "all data stays in the US" — are hidden from the people who need them most.
The fix: Add an explicit "Subprocessors" link from /trust/security-privacy and the footer. Either consolidate /trust/privacy into /trust/security-privacy with a 301, or noindex it. Surface the "no data leaves the US" promise on the main trust page.
9. Threat Modeling use case is the headline pitch but missing from the use-case nav (significant)
Location: Footer "Use Cases" menu vs. /use-cases/threat-modeling
Problem: The homepage opens with threat modeling as the lead use case ("automating design reviews and threat modeling"). /case-study/hid-global is entirely about threat modeling. /use-cases/threat-modeling exists and is a substantive page. But the footer "Use Cases" menu lists only AI Risk Reviews, Privacy Impact Assessments, Vendor Risk Assessments, and Triage — Threat Modeling is missing. The page is only reachable via the HID Global case study and direct URLs.
Consequence: A visitor coming in via search for "automated threat modeling" can navigate to the page once but can't find their way back via the nav. AI agents enumerating use cases from the footer will miss the company's flagship one.
The fix: Add "Threat Modeling → /use-cases/threat-modeling" to the footer Use Cases menu. While editing the menu, fix the slug/label mismatches (label "Privacy Impact Assessments" maps to slug /privacy-impact; label "Triage" maps to slug /automate-triage) by either renaming labels or slugs to align.
10. Tech-stack and feature claims that exist in exactly one place, plus a stale compliance post (significant)
Problem: Capabilities advertised only in single blog posts: "#ask-security Slack integration", "custom YAML-style questionnaires", "BYO LLM API key", "see the exact prompts being run, modify them, version them", "near-deterministic outputs", "DAG workflow system", Claude 3.5 Sonnet on Amazon Bedrock, ingestion of "breach databases and external risk ratings", SSO/SAML/SCIM support. None of these appear on /product, /trust/security-privacy, or any solutions page. The Bedrock post (March 2025) still names Claude 3.5 Sonnet — two model generations stale as of May 2026. Separately, /blog/navigating-eu-red-compliance-meeting-the-august-2025-deadline references a mandatory deadline of August 1, 2025 that has been in the past for nine months, with no update banner or post-deadline note — even though /use-cases/threat-modeling lists "Cyber Resilience Act, Radio Equipment Directive, EU Data Act" together as if they're one compliance bundle (they are three different regulations).
Consequence: A buyer reading the product page sees a thin feature list; a buyer who hunts through the blog finds the real product. SSO/SAML/SCIM in particular is an enterprise gate that should not be hidden in a one-year-retrospective blog post — the trust page only mentions "2FA, single sign-on (SSO), and domain-based login restrictions." And a compliance-product blog post that's nine months past its own deadline, with regulations conflated on the use-case page, will land badly with the GRC buyers Clearly AI is courting.
The fix: Promote durable feature claims out of blog posts and onto /product (Slack ask-bot, BYO LLM API key, prompt versioning, YAML questionnaires) and /trust/security-privacy (SAML, SCIM). Update the Bedrock post with current model versions. Add a post-deadline update banner to the EU RED post and split EU CRA / RED / EU Data Act into distinct entries on the threat-modeling page.
11. Visible copy defects on flagship solution and use-case pages (significant)
Problem: /solutions/grc-teams has a section heading "Risk Framework Alignment" whose body reads "Evaluate vendor privacy risks effectively" — text that clearly belongs to the Vendor Risk section above it. /use-cases/ai-risk-reviews has the H1-adjacent subhead "Generate a AI Risk review in 5 minutes or less" (ungrammatical — should be "an AI"). And both /product and /solutions/privacy-teams render the company's own name as "Clearly Al" (capital-i instead of lowercase-l) inside the embedded Jim Gregoire testimonial — root cause unclear (a font/Unicode substitution issue or a literal source typo).
Consequence: These are the highest-intent pages on the site — a GRC buyer, an AI-governance buyer, and a buyer reading the product page. Copy-paste errors and a misrendered brand name on those pages signal to both human visitors and AI buyer-research agents that nobody is proofreading the primary surfaces.
The fix: Replace the Vendor Risk paragraph with actual Risk Framework Alignment copy. Fix the "a AI" article on /use-cases/ai-risk-reviews. Track down whether "Clearly Al" is a font substitution or a literal source typo and correct it everywhere the testimonial appears.
12. Four contact addresses, no contact form, no in-house careers page (minor)
Problem: The footer "Contact Us" routes to mailto:marketing@clearly-ai.com. /trust/privacy-policy directs questions to legal@clearly-ai.com. /blog/the-ai-engineer-cheat-sheet says "contact us at support@clearly-ai.com." /trust/subprocessors also uses support@clearly-ai.com. Four addresses, no contact form, no clarity on which to use for what. The "Careers" footer link points to https://www.ycombinator.com/companies/clearly-ai/jobs — the YC jobs board — rather than an in-house careers surface, even though /blog/one-year-of-clearly-ai actively recruits a "Founding Engineer."
Consequence: A prospect with a security question has to guess; a journalist sends to marketing@; a regulator sends to legal@ but isn't sure that's monitored; a job candidate finds the company has no canonical careers page. Minor on its own, but adds to the trust-surface fragmentation.
The fix: Publish a single /contact page that routes by intent (sales, support, legal, security disclosure) and link it from the footer. Add an in-house /careers page (even one that links out to YC) so the company controls its own hiring surface.
13. Brand spelling drift on the company's own LLM partners (minor)
Problem: "OpenAI" is spelled three ways across the same domain: "Open AI" (with space) on /trust/security-privacy and /blog/the-ai-engineer-cheat-sheet, "OpenAI" on /trust/subprocessors and /blog/clearly-ai-technical-explanation. "Zero-Day Retention" is hyphenated on /trust/security-privacy and /trust/privacy but unhyphenated ("Zero Day Retention") on /trust/subprocessors and in the bullet text of /blog/the-ai-engineer-cheat-sheet (where the icon legend on the same page uses the hyphenated form).
Consequence: Trivial in isolation; in aggregate, signals to an agent that the trust page and the subprocessor page were written by different people who never reconciled.
The fix: Add "OpenAI" and "Zero-Day Retention" to a style guide and search/replace site-wide.
What they do well
/blog/clearly-ai-technical-explanation is a genuinely useful technical post — clear architecture, named competitors, explicit positioning ("a harness for security teams to build complex evaluation workflows"). It's the page a technical buyer actually needs.
The trust page covers the right surface areas (infrastructure, encryption, access control, AI governance, subprocessor review) even when individual items are incomplete.
Customer metrics, when standardized, are concrete and falsifiable (90% / 4x / 300 products / 75%) — better than the vague "saves time" pitch most competitors run.
Top 3 recommendations
Fix the Privacy Policy and Subprocessor list before anything else. Naming Webflow as the host of a Framer-hosted site is the kind of defect a regulator or a careful enterprise buyer will catch — and it's a one-day fix.
Build a real trust center. SOC 2 attestation, SAML/SCIM, framework alignments, subprocessors, "no data leaves the US," and the missing whitepaper all exist (or are claimed) but are scattered across blog posts and orphan pages. Consolidate to /trust with a request-the-report flow.
Promote feature claims out of the blog and into /product, then publish llms.txt. The product surface is significantly richer than /product suggests; the blog has been doing the product page's job. Once the canonical pages tell the full story, an llms.txt makes that story discoverable to the AI agents that increasingly mediate B2B research.