Coveo ships a polished, deep documentation site with a real llms.txt, .md source exports, and Redocly API references — but the agent-facing layer it advertises is partly broken: the .md files promised as "fully resolved plain text" leak raw Liquid and AsciiDoc across multiple pages, the API references render only under a real browser, and two different "authentication methods" pages give two different answers.
1. The .md exports promised to agents contain raw, unevaluated template code (critical)
Problem:llms.txt explicitly tells agents the per-page .md files "contain the full documentation content with all includes resolved, conditionals evaluated, and glossary terms expanded to plain text." The Deprecations page .md violates that promise directly. Instead of a table it ships raw Liquid:
The template assigns sorted_deprecations but never iterates it (there is no {% for %} loop), and the single table row references an undefined notice variable. The live HTML page renders five real dated rows (e.g. "August 31, 2026 — .NET (C#) Platform SDK"); the .md renders zero.
Consequence: An AI agent — exactly the consumer llms.txt is built for — asking "what Coveo features are being deprecated and when" gets a table with no rows and no dates. The single most date-sensitive page in the docs is invisible to the machine-readable path Coveo advertises as authoritative.
The fix: Render the deprecations table to static Markdown in the .md export (iterate sorted_deprecations with a {% for %} and emit literal dates/titles), and add an export-time check that fails the build if any .md file still contains {% %} or {{ }} tokens.
2. API reference pages are 100% client-rendered — no-JS fetchers and HTML-only agents see only a banner (critical)
Location: and (and all pages)
Code verification
Runtime snippet checks
Run the public examples from this audit in an isolated sandbox and attach the pass, fixed, skipped, and failed counts to the report.
Problem: Fetched without JavaScript, the entire body of these API reference pages is just the AI-agent banner: "AI agent context: a documentation index for this site is available at /llms.txt. A markdown version of this page is also available by appending .md to this page URL." On the Index API reference (/en/9/) that non-JS body measures 165 characters total; the Search API reference (/en/13/api-reference/search-api) returns the identical one-line banner. Only a real Chromium render produces the 775,026-character Redocly reference for the Search API. Zero API content is server-rendered.
Consequence: No-JS HTTP fetchers, link-checkers, and any agent that reads raw HTML rather than executing JavaScript see an empty page for Coveo's entire REST API reference. (Modern search crawlers like Googlebot and Bing do execute JS and would render the Redocly content, so SEO indexing is likely fine — the affected consumers are non-rendering clients.) For those clients, endpoint specs, request schemas, and privilege requirements are undiscoverable except through the (separately defective — see Issue 1) .md fallback.
The fix: Server-render or pre-render the Redocly reference to static HTML (SSR/SSG), or at minimum guarantee the appended-.md fallback is complete and correctly resolved for every api-reference page so the documented escape hatch actually works for non-JS clients.
3. The canonical REST APIs overview .md ships a raw AsciiDoc table with dead [code]/[guide] placeholder links (significant)
Problem: This is the master index of every Coveo REST API — and the .md source llms.txt directs agents to has two compounding defects. First, the API table is emitted as raw AsciiDoc, not Markdown:
[%header, cols="2,4,^1,^1"]
|===
|API name
|Usage
|Reference documentation
|Guide
|Activity
|Access the [activity] information of a Coveo organization.
|[code]
|N/A
...
|Search
a|* Perform queries on an index. ...
|[code]
|[guide]
|===
Second — and worse — every "Reference documentation" and "Guide" cell is a literal placeholder token [code] or [guide] instead of an actual URL. So in the agent-facing .md of Coveo's central API directory, none of the per-API reference or guide links exist. The same .md-leakage pattern recurs on q4dd0300.md, where the "Timeline" table is left as raw AsciiDoc ([%header,cols="~,~"] … |===) and the Step-3 ordered list uses literal AsciiDoc . list markers (". Validate…", ". Remove…"). With Issue 1 (q2ib0310.md), that's three separate pages where the .md export leaks unrendered markup — a systemic export bug, not a one-off.
Consequence: An agent that lands on the resolved REST APIs overview to discover where to find the Push, Search, or Commerce reference gets a malformed table and zero working links — it cannot navigate from the index to any individual API. This is the same failure class as Issue 1 but with broader blast radius: it breaks the single page meant to route agents to everything else.
The fix: Fix the .md exporter to convert AsciiDoc tables to Markdown and to resolve [code]/[guide] link macros to real URLs before publishing. Add the export-time gate proposed in Issue 1, extended to fail on raw AsciiDoc tokens (|===, [%header, a|, leading-. list markers) as well as Liquid, and backfill the missing reference/guide links on 143.md.
4. Two "authentication methods" pages list different methods (significant)
Problem: The apis-collection page "Authentication methods" lists three: API key, Platform token, and Coveo access token. The build-a-search-ui-collection page "Search API authentication methods" lists four different ones: API key, Search token, Claims, SAML. The first page footnotes that "The Search API uses separate methods: API keys, search tokens, claims, and SAML" — but the two pages share an overlapping title and neither cleanly disambiguates which applies to a given task.
Consequence: A developer searching "Coveo authentication methods" lands on two similarly titled pages with non-matching method lists. Without already knowing the apis-vs-search-UI split, they can't tell whether "Platform token" and "Search token" are the same thing (they aren't) or which list governs their integration.
The fix: Retitle one page to make the scope unambiguous (e.g. "Management/Platform API authentication methods" vs "Search API authentication methods"), and add a one-line cross-reference at the top of each clarifying which authentication surface it covers and linking to the other.
5. The Atomic auth code example is empty (significant)
Problem: Under "### Atomic library" the page states you "set the API key when calling the initialize method on the atomic-search-interface component" and "should also set the search-hub attribute" — then shows an empty code block. The Headless example beside it has a complete buildSearchEngine({...}) snippet, and the JavaScript Search Framework example references configureCloudV2Endpoint, but its code block is also left open/empty at the end of the source.
Consequence: Atomic is Coveo's primary recommended UI library, and this is the simplest authentication method documented. A developer (or an agent) trying to copy-paste the Atomic auth setup gets nothing to copy. Prose describes an initialize call and a search-hub attribute with no example of either.
The fix: Add the missing atomic-search-interface example showing the initialize call with accessToken and searchHub, and close/populate the trailing JavaScript Search Framework block.
6. Search API reference labels itself v1 while exposing only V3 operations (significant)
Problem: The page heading and breadcrumb read "Search API (v1)", but the operation switcher on the same page lists "Search V3 / Passages V3 / Analysis V3 / Search / Statements / ... / Passages Alpha." The version in the title does not match the versioned operations the reference actually documents.
Consequence: A developer reading "Search API (v1)" reasonably assumes v1 request/response shapes, then encounters V3 and Alpha operations with no explanation of the relationship. It's unclear whether v1 is the API surface, the document version, or a stale label — and whether "Passages Alpha" is production-safe.
The fix: Reconcile the heading with the operation set (e.g. label the reference by the API surface, not a stray "v1"), and add a short note explaining the V3 vs Alpha tiers and their stability/support status.
7. Base URL differs across Coveo's own APIs with no consolidated guidance (significant)
Problem: The Push API reference states it "still uses region-specific endpoints" and lists five hostnames — api.cloud.coveo.com (US), api-ca, api-eu, api-au, and apihipaa. The Index API .md declares a single unified server, https://platform.cloud.coveo.com. The Search API is not shown with an explicit base URL in the evidence, but the REST APIs overview (143.md) resolves its generated Swagger UI to that same unified platform.cloud.coveo.com host — so by inference Search shares the unified host, not the Push region pattern. The word "still" implies a migration the other APIs completed and Push did not, but no page maps which APIs use which host pattern.
Consequence: A developer wiring up multiple Coveo APIs will hit platform.cloud.coveo.com for Index (and, per the Swagger reference, Search) and then silently fail against Push if they assume the same host — or vice versa. The region-vs-unified split is documented only incidentally inside each API's own page, so there's no single place to learn the rule.
The fix: Add a "Base URLs and regions" reference table covering every public API (Push, Index, Search, Commerce, Analytics), stating for each whether it uses the unified platform.cloud.coveo.com host or region-specific hosts, and note any planned consolidation of Push.
8. The REST API source example uses plain http:// (minor)
Problem: The canonical configuration example sets "Url": "http://example.com/api/v1" — plain HTTP — while also passing a bearer token in the Authorization header ("Authorization": "Bearer @ApiKey"). The one worked example in the page pairs a credential with an unencrypted scheme.
Consequence: Developers copy the example as a template; an HTTP base URL transmits the bearer token in cleartext. Even as a placeholder, the canonical snippet models an insecure pattern for a credentialed crawl source.
The fix: Change the example URL to https://example.com/api/v1 and add a one-line note that REST API sources should use HTTPS endpoints when sending an Authorization header.
9. Changelog index has no 2026 entry as of mid-2026 (minor)
Problem: The Product News section index lists annual feature pages through "New features of 2025" (plus 2024, 2023, 2022) but no "New features of 2026" page. The audit date is June 2026, nearly half a year in.
Consequence: A developer or agent checking the changelog index for what shipped in 2026 finds the newest annual page is the prior year, making it look as though nothing has been released — or that the docs are stale — even if individual feature pages exist elsewhere.
The fix: Add (and link from this index) a "New features of 2026" page, or surface a rolling/recent-changes feed so the changelog's currency isn't gated on an annual page being created.
10. Same deprecation item has two different names across pages (minor)
Problem: The Deprecations section index lists "Coveo ML Product Recommendation model update," while the rendered deprecations table calls the same item "Coveo Machine Learning Product Recommendation model update." The "ML" vs "Machine Learning" wording diverges for one announcement.
Consequence: Minor, but it weakens exact-match search and machine cross-referencing: an agent or reader matching the index title against the detail page title sees a mismatch and may treat them as two different notices.
The fix: Standardize the announcement title to a single canonical string used in both the index and the rendered table.
What they do well
Real agent-readiness scaffolding exists: a structured llms.txt, an llms-full.txt flat index, per-page .md exports, and an in-page banner pointing agents to both — more than most platforms ship.
Security and permission semantics are documented with genuine care (e.g. the Index API's WARNING permission state explicitly flags "a security hole" requiring "immediate attention").
Deprecation notices like the search/listing API page give hard dates (Aug 31, 2026), explicit replacement APIs, and step-by-step migration guidance.
Top 3 recommendations
Fix the agent-facing exports you advertise. Add a build gate that fails if any .md file contains unrendered Liquid ({% %}/{{ }}) or raw AsciiDoc (|===, [%header...], a|, leading-. list markers, [code]/[guide] placeholder tokens). Three pages already leak — q2ib0310.md (zero deprecation dates), 143.md (broken REST API index with no working links), and q4dd0300.md.
Make API references readable without a browser. Server-render or pre-render the Redocly references, or guarantee a complete, resolved .md fallback for every api-reference page so no-JS fetchers, link-checkers, and HTML-only agents don't see a one-line banner.
Disambiguate authentication and base URLs. Consolidate the two conflicting "authentication methods" pages and publish a single base-URL/region reference table, so developers stop getting different answers depending on which collection they landed in.