Knoku vs SiteGPT
Both can be legitimate choices. The right one depends on where the team's knowledge lives and what it needs to do after an answer is generated.
| Capability | Knoku | SiteGPT |
|---|---|---|
| Core approach | A shared project index that combines product, engineering, support, community, and internal sources, with source-group controls and cited answers | A chatbot trained from website, sitemap, file, connected-app, text-snippet, and custom-response content |
| Website and documentation content | Website crawling with path scope, preview and URL selection, sitemap and robots discovery, recrawling, and conflict handling; GitHub repository documentation sync for Markdown and MDX | Website links, sitemaps, exact URL lists, crawl-depth and page limits, allowed domains, content selectors, files, text snippets, and custom responses |
| GitHub / developer knowledge | Repository documentation sync plus separate ingestion for GitHub Discussions, Issues, and Pull Requests, with filters and GitHub permalink citations | GitHub connector for Markdown, MDX, text, reStructuredText, and HTML files selected by repository and file pattern; equivalent Discussions, Issues, and Pull Requests ingestion is Not established in the reviewed official documentation. |
| Other knowledge sources | Notion, Confluence, Jira, Zendesk Help Center, OpenAPI, and PDF, DOCX, Markdown, and text uploads | Notion, Google Drive, Dropbox, OneDrive, Box, GitHub, and file uploads; SharePoint and Confluence are listed in CLI/API documentation |
| Public / internal knowledge | Public and Internal source groups route indexed documents to appropriate surfaces and API scopes | Internal knowledge boundaries and a public-versus-internal source-group model are Not established in the reviewed official documentation. |
| Citations | Cited answers with links to source pages, GitHub files, or discussion threads; source links can be checked during setup and review | Answers can include source links and per-answer sources |
| Website assistant | Website widget using the project's public corpus; multiple allowlisted domains can be served from one project | Embeddable website chatbot trained on selected content |
| Slack / community channels | Slack and Discord answer surfaces, with channel controls, source links, feedback, sessions, and optional curated thread ingestion | Slack, Facebook Messenger, Google Chat, and other documented communication integrations; Discord support is Not established in the reviewed official documentation. |
| MCP | MCP server that searches the Public source group | MCP server is listed in the developer documentation; its source-scope and internal-knowledge behavior are Not established in the reviewed official documentation. |
| API / developer interfaces | Public API with corpus scope controls; conversation and message APIs support analytics synchronization | REST Agent API v2, scoped tokens, webhooks, SDKs, CLI, widget SDK, and MCP |
| Support deflection | Support Form Deflector searches Public knowledge before submission, shows a possible cited answer, preserves the support path, and records the outcome | Lead capture, support workflows, and escalation are documented; an equivalent pre-submission support-form deflector is Not established in the reviewed official documentation. |
| Human handoff / escalation | Support-form visitors can continue to the original support path after reviewing a possible answer | Human takeover, transcript context, real-time agent replies, escalation notifications, and handoff integrations are documented |
| Analytics / knowledge gaps | Sessions, messages, feedback, repeated questions, coverage gaps, cited and unused sources, and support-form saves, with links back to exact sessions | Chat history, analytics, conversation insights, unanswered turns, recurring questions, leads, escalations, AI-resolved and handed-off outcomes |
| Best fit | Teams that need one governed knowledge layer across documentation, engineering, support, community, internal work, and reusable developer surfaces | Teams that primarily need a content-trained website and support chatbot with strong conversation review and handoff workflows |
A shared project index that combines product, engineering, support, community, and internal sources, with source-group controls and cited answers
A chatbot trained from website, sitemap, file, connected-app, text-snippet, and custom-response content
Website crawling with path scope, preview and URL selection, sitemap and robots discovery, recrawling, and conflict handling; GitHub repository documentation sync for Markdown and MDX
Website links, sitemaps, exact URL lists, crawl-depth and page limits, allowed domains, content selectors, files, text snippets, and custom responses
Repository documentation sync plus separate ingestion for GitHub Discussions, Issues, and Pull Requests, with filters and GitHub permalink citations
GitHub connector for Markdown, MDX, text, reStructuredText, and HTML files selected by repository and file pattern; equivalent Discussions, Issues, and Pull Requests ingestion is Not established in the reviewed official documentation.
Notion, Confluence, Jira, Zendesk Help Center, OpenAPI, and PDF, DOCX, Markdown, and text uploads
Notion, Google Drive, Dropbox, OneDrive, Box, GitHub, and file uploads; SharePoint and Confluence are listed in CLI/API documentation
Public and Internal source groups route indexed documents to appropriate surfaces and API scopes
Internal knowledge boundaries and a public-versus-internal source-group model are Not established in the reviewed official documentation.
Cited answers with links to source pages, GitHub files, or discussion threads; source links can be checked during setup and review
Answers can include source links and per-answer sources
Website widget using the project's public corpus; multiple allowlisted domains can be served from one project
Embeddable website chatbot trained on selected content
Slack and Discord answer surfaces, with channel controls, source links, feedback, sessions, and optional curated thread ingestion
Slack, Facebook Messenger, Google Chat, and other documented communication integrations; Discord support is Not established in the reviewed official documentation.
MCP server that searches the Public source group
MCP server is listed in the developer documentation; its source-scope and internal-knowledge behavior are Not established in the reviewed official documentation.
Public API with corpus scope controls; conversation and message APIs support analytics synchronization
REST Agent API v2, scoped tokens, webhooks, SDKs, CLI, widget SDK, and MCP
Support Form Deflector searches Public knowledge before submission, shows a possible cited answer, preserves the support path, and records the outcome
Lead capture, support workflows, and escalation are documented; an equivalent pre-submission support-form deflector is Not established in the reviewed official documentation.
Support-form visitors can continue to the original support path after reviewing a possible answer
Human takeover, transcript context, real-time agent replies, escalation notifications, and handoff integrations are documented
Sessions, messages, feedback, repeated questions, coverage gaps, cited and unused sources, and support-form saves, with links back to exact sessions
Chat history, analytics, conversation insights, unanswered turns, recurring questions, leads, escalations, AI-resolved and handed-off outcomes
Teams that need one governed knowledge layer across documentation, engineering, support, community, internal work, and reusable developer surfaces
Teams that primarily need a content-trained website and support chatbot with strong conversation review and handoff workflows
What Knoku is designed to do
Knoku treats a project as a shared index rather than a single website widget. Sources are brought into that index, assigned to source groups, and then made available according to the surface asking the question. The documented Public group can feed the website widget, support form deflector, MCP, Discord, and public-scope API. Internal content can be reserved for team and support surfaces or an internal-scope API.
That distinction matters when one company has both public documentation and material that should remain inside the organization. A team can manage the boundary at the source-group level instead of maintaining entirely separate answers by hand. The same indexed knowledge can then support a public product assistant, an internal question-and-answer workflow, and developer tooling, while the surface determines which corpus it can search.
Answers cite the pages, files, GitHub documents, or discussion permalinks used to produce them. The setup guidance includes checking that source links open real pages, making citations part of operational review rather than a purely decorative answer feature.
Knoku analytics cover sessions and messages, helpful feedback, channel mix, repeated questions, coverage gaps, cited sources, unused sources, and support-form outcomes. Questions can be grouped into frequent or needs-support gaps, and source usage can reveal which documents are carrying the answer load and which are not being used. That gives documentation and support teams a way to turn unanswered questions into corpus improvements.
What SiteGPT is designed to do
SiteGPT’s current official documentation describes a chatbot trained from content supplied by a team. That content can come from website links, sitemaps, exact URL lists, uploaded files, text snippets, custom responses, YouTube transcripts, and connected applications. Website controls include crawl depth, page limits, allowed domains, sitemap scanning, and inclusion or exclusion selectors.
The resulting chatbot is designed to answer visitors and support workflows. SiteGPT supports website embedding, source links in answers, lead capture, conversation history, analytics, and human support handoff. Its support model goes beyond simply displaying an answer: an agent can take over a conversation with transcript context, reply in real time, and receive escalation notifications. Documented integrations include platforms such as Zendesk, Freshdesk, Crisp, Zoho SalesIQ, Slack, Google Chat, and Facebook Messenger.
A substantial developer surface
The official developer documentation lists an Agent API v2, scoped tokens, webhooks for messages, leads, and escalations, SDKs, a CLI, widget SDK capabilities, and an MCP server. Its chat history and conversation-insights tools support transcript review, source inspection, negative-feedback filtering, corrections through custom responses, tagging, resolving, exports, recurring-question analysis, and outcome tracking.
This makes SiteGPT more than a static documentation widget. Its center of gravity remains a content-trained chatbot that operates on a website and in customer-support channels. A broader internal knowledge governance model, with explicit public and internal source groups routing the same index to different surfaces, was not verified in the reviewed documentation.
Website chatbot vs shared knowledge layer.
The practical difference appears when the team maps its knowledge flow.
Starts from the project index
Knoku starts from the project index and asks where each source should be available. Its website crawl is one input among several, alongside repository documentation, GitHub discussions and work items, support content, structured API descriptions, connected knowledge systems, and uploaded files. Public and Internal source groups create an explicit boundary around the indexed material.
Starts from the content the chatbot should learn
SiteGPT’s website-first model starts with the content the chatbot should learn. A team can restrict the crawl to selected domains or URLs, add files and connected sources, and refine behavior with text snippets and custom responses. This is a sensible operating model when the main job is answering prospective or existing customers from a controlled set of business content.
That difference affects reuse. With Knoku, a public website answer, an internal team question, a Slack response, a Discord response, an MCP query, and a public API request can all draw from the same project index, subject to their source scope. The documented characteristic is shared indexing across surfaces with explicit scope controls.
SiteGPT also supports several surfaces and developer interfaces, so it can be integrated into broader workflows. The distinction is that the reviewed official documentation establishes content ingestion, chatbot operation, support handoff, analytics, and extension APIs more clearly than it establishes a shared public/internal knowledge governance model. Teams should test the exact access boundaries they need rather than assume that multiple integrations imply equivalent corpus controls.
Citations are another useful dividing line. Both products document source links. Knoku’s model makes source-group scope and cited source usage part of the index and analytics workflow. SiteGPT provides per-answer sources, chat history review, and tools for correcting missed answers. Neither reviewed official source set establishes directly comparable citation-accuracy measurements or independently measured support-deflection performance.
GitHub and technical knowledge.
For developer documentation, GitHub support should be evaluated at the level of material the product can use, not merely whether a GitHub logo appears in an integrations list.
Two different GitHub workflows
Repository sync indexes documentation files from a selected branch and directory, with exclude globs, visibility controls, commit-aware refresh, and citations to GitHub file URLs. Separately, its GitHub App can ingest Discussions, Issues, and Pull Requests. Filters can limit the material by repository, accepted or marked answers, and minimum upvotes. Answers can cite the relevant file or thread permalink.
That distinction lets a team combine formal documentation with selected engineering and community context. A repository’s reference material can sit alongside accepted answers in Discussions, recurring issue resolutions, or useful Pull Request context. The source boundary still matters: teams should decide which of those materials belong in the Public group and which should remain Internal.
Repository file synchronization
SiteGPT’s official GitHub connector syncs supported repository files, including Markdown, MDX, text, reStructuredText, and HTML, according to repository and file-pattern selection. That can cover a conventional documentation repository effectively.
GitHub Discussions, Issues, and Pull Requests ingestion was not verified in the reviewed documentation. Teams that rely on issue history or community answers should validate that requirement directly instead of treating repository-file synchronization as an equivalent capability.
The resulting choice is about technical context. If “developer knowledge” means a documentation repository, both products have documented paths to ingest repository files. If it includes the conversations and work artifacts around that documentation, Knoku’s documented GitHub source model covers more source types.
How their answer surfaces compare.
Knoku can expose the same project index through a website widget, Slack, Discord, MCP, public API, and Support Form Deflector. Slack can work with Public and Internal groups under its documented controls, while Discord uses the Public group. These surfaces include source links, sessions, and feedback workflows. The important characteristic is shared indexing with surface-specific scope, not the number of integrations by itself.
SiteGPT provides an embeddable website chatbot and documented communication and support integrations, including Slack, Google Chat, Facebook Messenger, Crisp, Zendesk, Freshdesk, and Zoho SalesIQ. It also exposes an Agent API, SDKs, CLI, webhooks, widget tooling, and MCP. Human agents can take over conversations in supported workflows, and chatbot history remains available for review.
SiteGPT’s surfaces are well aligned with visitor assistance and customer support. Knoku’s surfaces are aligned with distributing a governed project corpus across public, internal, support, community, and developer contexts.
Support deflection and escalation.
A form-interception workflow
Knoku’s Support Form Deflector operates before a visitor submits a support request. It uses the subject and body context to search the Public corpus, then presents a possible cited answer. The visitor can indicate that the answer resolved the issue or continue to support. The original support path remains available, and Knoku records the outcome.
This is a specific form-interception workflow. It connects a support request to documentation at the moment the user is about to create a ticket, while preserving a measurable record of whether the request was avoided or continued.
Live handoff to an agent
SiteGPT documents a different set of support capabilities. Its chatbot can capture leads, answer visitors, and escalate conversations. Human support workflows include escalation controls, notifications, transcript context, agent-mode takeover, and real-time replies. Integrations connect those handoffs with documented support and messaging platforms.
Those workflows should not be treated as interchangeable. SiteGPT’s human handoff is designed to move an active conversation to an agent. An equivalent pre-submission support-form deflector was not verified in the reviewed documentation. Knoku’s deflector is designed to offer a cited self-service answer before the form is sent, while still allowing escalation through the existing form.
The distinction affects measurement as well. A team focused on reducing duplicate ticket creation needs to measure form outcomes. A team focused on ensuring that complex live conversations reach an agent with context needs to measure escalation and handoff outcomes.
Analytics and knowledge gaps.
Knoku’s analytics connect the answer layer to the underlying knowledge index. Teams can review sessions and messages, helpful feedback, repeated questions, frequent questions, needs-support gaps, cited documents, unused sources, and support-form saves. Deflection outcomes link back to sessions, allowing a reviewer to inspect the answer and the visitor’s eventual action. Source usage can highlight documentation that is frequently cited as well as material that contributes little to answers.
That supports a documentation improvement loop: find a repeated or unsupported question, identify the relevant gap, update the source, and observe whether later answers improve. The analysis is organized around both conversations and corpus coverage.
SiteGPT’s chat history and analytics focus on operating and improving the chatbot. Teams can review full transcripts, inspect per-answer sources, filter negative feedback, add corrections as custom responses, tag and resolve conversations, and export data. Conversation insights identify recurring topics and top questions. Analytics expose unanswered turns, escalations, leads, AI-resolved conversations, and handed-off outcomes.
SiteGPT therefore gives support and chatbot operators a clear way to investigate missed answers and monitor outcomes. Its recurring-question workflow can feed custom-response remediation directly. Knoku’s documented analytics place more emphasis on source usage, public knowledge coverage, repeated questions, and support-form deflection within one governed index.
Neither official source set establishes an independently measured deflection rate or a directly comparable citation-accuracy score. A meaningful evaluation should use the team’s own representative questions and define success before comparing dashboards.
Which product fits which scenario?
When knowledge is distributed
Choose Knoku when your knowledge is distributed across product documentation, a GitHub repository, engineering discussions, issues, pull requests, support articles, structured API material, and internal systems. It is especially relevant when those sources must be combined into one index while public and internal access remain distinct.
It also fits teams that want the same cited knowledge to serve a website, support-form deflection, Slack, Discord, MCP, and API workflows. The deciding signal is a need to improve the corpus itself through source traceability, repeated-question analysis, coverage gaps, and deflection outcomes.
When the chatbot is the operating problem
Choose SiteGPT when the primary operating problem is deploying and improving a chatbot trained on website and business content. Its website controls, file and connected-app ingestion, source links, chat history, analytics, lead capture, and custom-response workflow suit teams that want to answer visitors and refine the bot from real conversations.
It may fit well when human support handoff is central. Transcript-aware takeover, agent replies, escalation notifications, and support-platform integrations can connect the chatbot to an existing service workflow. Confirm any need for internal knowledge boundaries, GitHub work-item ingestion, Discord, or pre-submission form deflection against the current official documentation before making them selection criteria.
The practical decision rule.
Test both products with the same five questions:
A public documentation question
A GitHub or technical-context question
An internal knowledge question
A support question
A question missing from the corpus
For each answer, compare the citation and source link, the breadth of sources searched, the access boundary applied, and how clearly the system handles uncertainty. Then test what happens next: whether the user can reach support, whether an agent receives the relevant context, whether the interaction is recorded as deflected or handed off, and whether the unanswered question appears in analytics as an actionable knowledge gap.
The decision follows the team’s operating model. A website-and-support chatbot may be enough when the corpus is relatively controlled and live handoff is the main extension. A shared, citation-first knowledge index may be the better match when product, engineering, support, community, and internal knowledge must remain connected without losing control of where each answer can appear.