The docs cover the no-code editor and publishing flow competently, but the developer surface (chatbot web component, React SDK, MCP, webhooks, JWT auth) is thin, gated behind "contact support," and contains a security-reversing typo plus a broken support email. There is no API reference, no OpenAPI spec, and no llms.txt — agent-driven integration has to reverse-engineer most of the platform.
1. JWT auth guide tells you to expose your auth secret in the frontend (critical)
Problem: The text reads: "For Single Page applications, this step needs to run on backend to ensure that DOCSHOUND_AUTH_SECRET is exposed in the frontend code." A missing "not" inverts the entire security guidance. Read literally, this instructs developers to expose the signing secret to the browser. The same page later (correctly) warns "It is important to protect your DOCSHOUND_AUTH_SECRET and ensure it is never exposed in client-side code," so the page contradicts itself within a few paragraphs.
Consequence: A developer (or an AI agent generating integration code) parsing the literal sentence could place the signing secret in client-side JavaScript, allowing any visitor to mint authentic tokens and bypass authentication for protected docs portals. Even the contradiction alone is dangerous — both readings are stated as fact.
The fix: Rewrite to: "For Single Page applications, this step must run on a backend so that DOCSHOUND_AUTH_SECRET is never exposed in frontend code." Audit every other security-sensitive sentence in the auth section for similar inversions.
2. Broken support email in the Chrome extension troubleshooting docs (critical)
Location: /docs/generate-docs-with-chrome-extension → "What if I still have issues capturing my workflow?"
Problem: The page directs users to "contact DocsHound support at support@docsound.com for assistance" — missing the h in docshound. Every other page (support, custom-domain, change-password, publish-pdf, guide-settings) correctly uses support@docshound.com.
Consequence: Users hitting the exact case the FAQ is written for — a workflow consistently failing to capture — send tickets into a nonexistent mailbox and silently get nothing back. This is the highest-friction support moment in the product.
The fix: Fix the typo on this page and add a regression test or grep check across the docs build that flags any reference to (and any other near-miss spellings).
3. No llms.txt and an SPA homepage with no static content (critical)
Location: /llms.txt (404), / (SPA shell only)
Problem:https://docs.docshound.com/llms.txt returns 404. The docs root rendered without JavaScript shows only "Skip to main content / DocsHound Docs / Made with DocsHound / Docs / Chat / Chat history empty." Content only materializes after client-side rendering. There is no llms-full.txt either.
Consequence: AI agents (Claude, Cursor, Copilot, ChatGPT browse) and non-JS crawlers cannot efficiently discover or index the documentation. For a product whose own pitch revolves around AI-readable knowledge bases and an MCP server, the docs site itself is poorly readable to LLMs. Search engines that don't fully render JS will see a near-empty page at the canonical entry point.
The fix: Publish /llms.txt listing the canonical docs URLs and a /llms-full.txt with concatenated content. Server-render at least a static fallback for the root and category pages so agents that read the initial HTML can extract content.
4. No REST API, OpenAPI spec, or machine-readable reference for the developer surface (critical)
Location: Sitewide — no /api, /reference, or OpenAPI link in the sitemap
Problem: DocsHound exposes a chatbot web component, a React package (@docshound/chat-react), a webhooks endpoint, and an MCP server. None of these have a programmatic reference. The webhook page describes payload contents in prose ("User name (if provided)", "Complete chat history with timestamps") with zero JSON example. The MCP page says "it will automatically discover the available 'tools' (i.e., knowledge endpoints)" without listing a single tool, schema, or example request. The React useDocsHoundChat hook documents only show() and clear() with no return-type or error semantics.
Consequence: An agent generating webhook handler code has nothing to type against — it has to invent a payload shape and hope. Anyone integrating MCP can't know what tools exist without runtime discovery against a live endpoint. Sales-engineering scoping ("can it do X?") becomes impossible without a call.
The fix: Publish an OpenAPI 3.x spec for webhooks (with real JSON examples and HTTP status semantics) and a machine-readable schema for the MCP tools list. Add a TypeScript-typed reference page for the React SDK that mirrors the actual exported types from @docshound/chat-react.
5. Keyboard shortcut documentation is internally inconsistent (significant)
Problem:"on Mac, pressing CMD OPT 2 switches to heading 1, CMD OPT 1 switches to heading 2, and CMD OPT 0 switches to standard body copy." Either the numbers are swapped or the heading labels are swapped — convention universally maps Cmd+Opt+1 → H1, Cmd+Opt+2 → H2.
Consequence: Users following the docs press the documented keys and get the opposite heading level. Either the docs are wrong or the product violates a widespread convention; in either case the page is the source of confusion.
The fix: Test the actual shortcuts in the live editor and rewrite the sentence to match. If the product really does map them inverted, add a sentence acknowledging the deviation and explaining why.
Problem: The sitemap ends with <url><loc>https://docs.docshound.com/settings — the closing </loc></url> and any subsequent settings pages are cut off. The earlier /settings/auth/jwt-auth page is reachable but is not in the sitemap (the sitemap lists /settings/auth and then truncates).
Consequence: Search engines and agents that rely on the sitemap (the recommended discovery surface for the indexing guide DocsHound itself publishes) will miss settings pages, including the JWT auth integration page. Strict XML parsers may reject the malformed file entirely.
The fix: Regenerate the sitemap and validate against an XML parser in CI. Add /settings/auth/jwt-auth and any other present-but-unlisted settings pages.
7. Half the developer features are gated behind "contact support" with no in-doc setup path (significant)
Simple Password Auth: "Reach out to your DocsHound representative if you want this feature enabled."
JWT Auth: "Reach out to DocsHound team to set up authentication configuration for your guide."
Custom MCP tools: "contact DocsHound support to enable this feature and provide your MCP server URL."
Custom webhook auth headers: "For custom authentication headers contact DocsHound Support for advanced configuration options."
PDF website editing: "To edit your website, contact DocsHound support. Send an email to support@docshound.com with the link to your PDF."
Consequence: A developer evaluating DocsHound can't self-serve any non-trivial integration. Worse, the docs don't disclose what tier each feature requires (only JWT mentions "Pro Plan"), so plan/feature gating is invisible until someone replies to the email.
The fix: For each gated feature, add an explicit "Availability" callout (which plan, what kind of approval) and a self-serve setup form or in-app toggle. If approval is genuinely required, document the SLA and what information to include in the request.
8. Two overlapping chatbot setup pages with no clear relationship (significant)
Location: /chatbot/set-up-chatbot-alxq8a vs /chatbot/enable-chatbot
Problem: Both pages describe how to turn on the chatbot. "Set Up Chatbot" talks about deploying via the install snippet from publishing settings. "Enable Chatbot" talks about toggling "Enable Chatbot" and "Display on Docs" inside Preview Guide. Neither links to the other; neither states which is the canonical entry point. The "Set Up Chatbot" URL also carries a random-looking slug suffix -alxq8a, suggesting a duplicate/imported page that was never canonicalized.
Consequence: Users (and agents writing integration code) read one page, follow it to completion, and never discover the other half of the configuration. The slug noise also breaks deep links if the page is renamed.
The fix: Merge into one "Set up the chatbot" page with sub-sections (1: enable in settings, 2: install on your site, 3: configure attributes), and 301 the other URL. Drop the -alxq8a slug suffix.
9. Chatbot position attribute is documented contradictorily (significant)
Problem: The prose says "set the position attribute to either or right , right-top , or right-bottom" — the "either … or" syntax is broken and only right-anchored options are listed. The All Parameters table immediately below also lists only 'right', 'right-top', or 'right-bottom'. There is no documented left or left-* option, but the awkward "either or right" phrasing implies one was meant. The React table on /chatbot/chatbot-react repeats right, right-top, or right-bottom.
Consequence: Developers can't tell whether left-anchored positioning is unsupported, undocumented, or planned. Agents generating component config will guess left and either get a silent failure or unexpected behavior.
The fix: Decide and state: either explicitly say "right-anchored only — left is not supported," or add the left-anchored values to both the prose and the parameter tables.
10. MCP server documentation pins to SSE only with no protocol version (significant)
Location: /chatbot/extend-chatbot-with-custom-tools → "MCP Server Requirements"
Problem:"Transport: SSE (Server-Sent Events) / Authentication: JWT Bearer token via the Authorization HTTP header (optional)" — no MCP protocol version is named, no mention of the Streamable HTTP transport that has superseded SSE in newer MCP specs, no mention of which MCP SDK versions are compatible.
Consequence: Customers building against a current MCP SDK will produce a server DocsHound can't connect to and won't know why. There's no error-handling page to fall back to.
The fix: State the supported MCP protocol version(s), list compatible SDK versions, and clarify whether Streamable HTTP is on the roadmap. Provide a minimal working example MCP server (Node and Python) wired to DocsHound.
11. Webhook integration page has no payload example or response contract (significant)
Problem: The page describes what fields are sent ("User name (if provided)", "Complete chat history with timestamps", "Inquiry type classification") but never shows a JSON example. There is no documented field name, type, format, or top-level schema. The only response contract stated is "Verify your endpoint returns a success status (200-299)" — no retry policy, no idempotency key, no signature/HMAC, no timeout.
Consequence: A developer can't write a typed handler, an agent can't generate one, and there's no way to know whether a missed webhook will be retried or dropped. The "Verify webhook configuration" steps redundantly list "Confirm your endpoint receives the correct data structure" and "Verify your endpoint receives the correct data structure" back-to-back, suggesting the section was never reviewed.
The fix: Publish a full JSON example payload, a field-by-field schema (types, required/optional, possible values for inquiry_type), the retry policy, the request signing scheme (or state explicitly that there isn't one), and request timeout. Deduplicate the verification checklist.
12. JWT auth page has broken sentences and typos in security-critical setup steps (significant)
Location: /settings/auth/jwt-auth
Problem: Multiple errors in the integration walkthrough:
"You will to provide an authentication URL" — missing word.
"the inital challenge recevied" — two typos in one phrase, in the URL parameter description.
Several places run words together: "DOCSHOUND_AUTH_SECRETcreate", "thatDOCSHOUND_AUTH_SECRETis".
Consequence: Combined with the inverted-secret issue (#1), the most security-sensitive doc on the site reads as if it was never proofread. Developers lose trust; agents extract garbled tokens or variable names.
The fix: Copy-edit the entire page, normalize all DOCSHOUND_AUTH_SECRET mentions as inline code, and add a working end-to-end code sample (Node/Express or Next.js API route) with the JWT signing call shown explicitly.
13. Editor Product Updates page is the closest thing to a changelog and last updated Feb 2025 (minor)
Location: /editing-tools/editor-product-updates
Problem: The only changelog-like surface in the docs is headed "February 2025" with no entries newer than that, despite the docs describing more recently-introduced features (MCP server, custom MCP tools, webhook workflows). There is no top-level /changelog or release-notes URL in the sitemap.
Consequence: Customers can't tell what shipped recently, and agents have no canonical place to look up "when was feature X added." It also reads as if the product paused development in early 2025.
The fix: Either rename to a true rolling changelog with dated entries, or split into /changelog and keep this as the editor-specific subset. Add entries for MCP, custom tools, and webhooks.
What they do well
The chatbot web-component attribute table on /chatbot/advanced-chatbot-settings is genuinely complete (parameter, description, default) and mirrored in the React props table — the kind of structured reference the rest of the developer surface lacks.
The custom-domain page covers the realistic cases (Cloudflare proxied vs DNS-only, SSL auto-provisioning, propagation timing, subdomains).
The indexing page correctly points users at /sitemap.xml and explains the Block robots toggle, even if the sitemap itself is truncated.
Top 3 recommendations
Fix the JWT auth page today — restore the missing "not" so the security guidance is correct, copy-edit the typos, and add a working backend code sample. This is a single-page change with outsized risk reduction.
Publish an OpenAPI spec for webhooks and a tools schema for MCP, plus an llms.txt and a static-rendered docs root. These four artifacts unlock agent-driven integration, which is what the product itself sells.
Close every "contact support" loop with a self-serve path or an explicit availability callout. Five distinct features currently dead-end at an email — pick the two highest-value (JWT, custom MCP tools) and ship in-product enablement first.