Troubleshoot missing or failed Knowledge

Find the failure before changing anything#

Open the website's Knowledge tab and note the crawl state, processed-page count and Last crawl error. Then open the source in the Knowledge library to check which documents are active.

Confirm the selected workspace and website. Installation status is a separate check: a detected widget can still have incomplete Knowledge, and a prepared source can exist before widget installation. Do not replace an installation token to repair a content-extraction problem.

Interpret common crawl errors#

Check the website as a visitor#

Open the configured hostname without relying on an administrator session. Confirm that important text is visible, public and linked from the site. A password-protected storefront, login requirement or browser challenge can explain why collection differs from what you see while signed in.

Correct the domain or website configuration with the person responsible for the site. Do not disable security indiscriminately. If the content cannot be made publicly accessible, add only the verified customer-facing portion as a manual Business facts entry.

If some pages or facts are missing#

Crawls have page limits and follow same-host links. PDF attachments, unlinked pages and content behind search or authentication can be absent. A rendered fallback is attempted only when normal collection yields no usable pages; it is not a promise that every dynamic page will be included.

Use the source reader and original page links to identify the gap. Publish accessible HTML or add a scoped manual fact, then re-crawl and test. Check for contradictions between shared entries and website-specific policies if an answer uses the wrong rule.

If a manual entry cannot save#

For a size error, split the text into focused entries below the portal's 60 KB combined-title-and-body check. For source_changed_reload, copy the draft, reopen the entry and reconcile the latest revision. A generic save failure keeps the draft; do not close it before preserving important edits.

For a persistent source or answer problem, contact Reesponder with the public domain, source title, exact question, expected verified fact and visible error. Do not include passwords, credentials, private test tokens or personal customer records. These details let support distinguish website access, Knowledge coverage and answer generation without guessing.

Worked example: the right fact belongs to another site#

A workspace has two regional stores. A reviewer sees the correct delivery rule in Knowledge, but the tested website keeps using a different rule. They check the source's scope and find that the correct fact belongs only to the other store. Being visible to an administrator in the workspace is not the same as being eligible for every website's answers.

The policy owner confirms which rule the tested store should use. The maintainer creates or corrects an appropriately scoped source and removes any obsolete conflicting statement, then checks each store's normal and exceptional case. Copying the whole other store's source without reviewing applicability would create a second error rather than solve the first.

Know when a controlled retry is justified#

Retry a crawl after correcting the observed public-access, hostname or content issue, then inspect its state and active documents. Do not queue repeated work while the previous crawl is still queued or running. For a save conflict, reopen and reconcile the current revision instead; a crawl retry cannot recover an unsaved manual draft.

If the same bounded reproduction still fails after the relevant correction, provide the support evidence below. Keep the question and expected business fact unchanged so successive results can be compared. Changing the token, theme, policy and guidance at once destroys that comparison and makes it harder to identify the actual cause.

Sort the symptom before changing configuration#

Three symptoms can sound like missing Knowledge but have different causes. The source may be absent, the stored text may be wrong, or the available text may be handled badly in the answer. Start with the exact customer question and expected approved fact. Open the relevant source and inspect its active documents. Without this comparison, repeated crawls and duplicate manual entries are guesses rather than a diagnosis.

If a policy document is absent, investigate public access, same-host links and collection bounds. If the document exists but contains an old statement, check the published page and last collection. If the fact is present and correct but the answer ignores a condition, review contradictory sources and guidance. Keep the website and workspace selection explicit. A source in another site or workspace does not automatically apply to the customer conversation being tested.

Installation detection is independent. Replacing a snippet cannot make an inaccessible PDF policy readable to the crawler. Conversely, a source marked Ready does not install the chat on a public template. Write the symptom as one sentence with the observed evidence, then choose the relevant correction. This gives support a reproducible problem: source absence, stale content or incorrect handling, rather than a vague statement that the assistant does not work.

Worked recovery cases#

For an attachment-only warranty, the fix is not another crawl of the same page. Linked PDFs are not parsed by the supported crawler. Publish appropriate readable HTML or add verified customer-facing warranty facts manually. Keep private customer records out of that entry. Then test an ordinary warranty question and an exception, using the actual business policy as the expected outcome.

For a page behind an anti-bot challenge, inspect the public visitor response and visible crawl error with the website maintainer. Do not disable all security to make a single diagnostic succeed. Decide how eligible public policy content can be made accessible safely, or use the appropriate manual facts. If your administrator browser sees the page because it is authenticated, that does not establish public collector access.

For a conflicting shared policy, inspect the sites it affects before editing. A regional rule can be wrong for one website even when it is correct for another. Create the appropriate scoped source and stop using obsolete shared text, rather than duplicating two unlabeled alternatives. Retest both customer contexts. For a concurrent manual-save error, preserve the draft and reconcile the current revision; the missing-save problem is not a website collection failure and does not need new installation code.

Prepare a useful support report#

Include the public domain, source title and scope, approximate time, visible safe error and precise question. State the expected verified fact and where it is approved. If the problem followed a website release, say whether the page URL, public access or navigation changed. If it followed a manual edit, describe whether the save succeeded and whether the source remains enabled. These details distinguish collection, editorial and answer-generation issues.

Do not send authenticated URLs, passwords, API tokens, private-test credentials or unrelated customer records. A public policy reference and synthetic reproduction are usually enough for factual diagnosis. If you need an actual retained conversation, identify it through the authorized account context rather than publishing its full transcript. Preserve unsaved editorial work before closing an error state, especially when the draft is the only record of an approved change.

After recovery, check both the source and answer. A job changing from failed to Ready proves preparation progressed, not that the specific business condition is accurate. Inspect the document, test the original question and an adjacent exception, and record the observed result. If the issue persists, keep the same bounded reproduction rather than repeatedly changing several unrelated controls. That makes subsequent investigation comparable and prevents accidental loss of a previously working configuration.