An old product claim can remain in a help article long after the team has stopped saying it aloud. When that article becomes an input to an AI answer, the forgotten sentence becomes an active customer-facing risk again.
TLDR: Maintain a claim register with an authoritative source, owner and verification date. Review version-sensitive statements when products or policies change. Correct the source, confirm the relevant content sync and test the resulting answer before calling the issue resolved.
Inventory product claims in the knowledge content audit
We recommend starting with claims that affect a buyer's decision or a customer's next action: availability, subscription requirements, limits, pricing, integrations, permissions and promised outcomes.
Do not review only the main article body. Inspect comparison tables, downloadable files, short answers and linked pages. If the same claim appears in several places, record the copies so a correction is not limited to the easiest one to find.
Your existing Service Hub knowledge-base guide addresses the setup context. This process concerns the facts the knowledge content carries after setup.
Assign a source and an owner to each claim
We recommend recording the exact sentence, its source URL or approved internal record, the applicable product/version and a reviewer. Separate the source of truth from the page that repeats it.
For a platform feature, use current official documentation. For your own service promise, use an approved commercial or operating record. A sentence appearing elsewhere on your website is not independent proof that it is correct.
The following register is synthetic. The statements are invented examples of claims to review, not facts about HubSpot or Selworthy.
| Example claim | Evidence needed | Owner and action |
|---|---|---|
| “Every subscription includes this feature.” | Current official eligibility documentation | Product owner verifies scope or removes the statement. |
| “Support responds within one hour.” | The applicable approved service commitment | Service owner checks the exact promise and exceptions. |
| “This integration preserves every field.” | A verified mapping and supported behavior | Integration owner replaces the blanket claim with tested scope. |
Record “not verified” when the evidence is missing. Do not quietly soften a precise unsupported promise into a vague one and mark it checked.
Use content freshness review triggers as well as dates
We recommend reviewing affected claims after a product update, subscription change, integration change, service-policy change or customer-reported contradiction. A calendar review alone can miss a material change that happens between scheduled checks.
For each trigger, identify the pages and files that depend on the changed fact. Keep the old wording and the reason for the correction in your internal change log. The public content should clearly describe the current scope without preserving obsolete instructions as though they still apply.
Confirm what the customer agent actually uses
As checked on September 7, 2026, HubSpot documents management of customer-agent sources, including HubSpot content, files and public URLs. It states that synced knowledge-base updates trigger resyncing, while other sources are automatically resynced weekly; manual refresh and sync-status review are also documented. Verify the source type and account requirements before relying on an update schedule. HubSpot customer-agent source management
A corrected public page is one step. We recommend confirming that the relevant source is included, the intended version is available and no conflicting copy remains in another source.
Do not assume a successful sync proves the answer is accurate. Inspect the output against the approved claim and its limitations.
Test the correction with realistic questions
Use approved or synthetic inputs that ask directly about the changed claim, approach it indirectly and test its boundary. For a tier requirement, include a question from someone on an ineligible plan. For a service promise, include a situation outside the agreed scope.
- Verify the answer. It should match the current source and preserve relevant limitations.
- Verify uncertainty. Missing information should remain unresolved rather than be filled with a guess.
- Verify the citation. The linked source should support the answer, not merely mention the topic.
- Retain the review. Record the question, output, date and reviewer decision.
Testing itself needs the appropriate action and credit approvals. Do not use customer data or deploy a channel merely to complete the content checklist.
Run a focused HubSpot knowledge content freshness audit
This audit asks whether the knowledge content still supports accurate answers. It does not attempt to certify the entire HubSpot portal, redesign deal pipelines or replace a broader data-quality review.
Choose a bounded source set, such as the articles used for one customer-agent topic. Record what was included and excluded. A focused audit with clear limits is more useful than a “complete” label without an inventory.
Follow a claim across its copies
A product requirement may appear in a knowledge base article, a short answer, a landing page and a downloadable guide. Record the places the audience or agent can encounter it.
If one copy is corrected and another remains outdated, the conflict is still unresolved. Retain the relationship between the claim and each source version.
Do not assume the visible website is the only input. Review the configured source list using the appropriate account permissions before describing the coverage.
Distinguish a content problem from a data problem
An article may accurately explain a process while a CRM record contains an incorrect value. Conversely, accurate CRM data does not make an obsolete instruction current.
Record the observed problem before choosing the correction. A source edit addresses the knowledge claim; a data correction or configuration change needs its own owner and authorization.
Keeping that distinction helps service operations, marketing teams and administrators avoid changing the wrong layer of the process.
Prioritize claims with meaningful consequences
We recommend reviewing product eligibility, permissions, limits, service commitments and steps that can change records or trigger communications first. These statements can affect what a customer or operator does next.
A cosmetic wording issue can still be corrected, but it should not hide an unresolved operational instruction. Keep the reason for priority visible rather than relying only on page traffic.
Keep the source boundary safe
HubSpot warns that content added as a source can inform responses even when the source is private and not cited. Do not treat a disabled citation link as protection for the source's information. HubSpot's source-management guidance
Review source suitability before inclusion. Personal, confidential or sensitive information should not be placed in a public-answer knowledge source merely because the file is convenient to upload.
Inspect the source type and sync state
Identify whether the configured source is a synced knowledge base article, a public URL, a file or another supported type. Use the documented behavior for that type.
Record the observed sync state and the version needed for the correction. If the source has an error, keep the content issue open until the intended version is available through the configured source path.
A completed sync proves a step in the process. It does not by itself prove that the next answer will use the source accurately.
Verify the corrected answer and its boundary
Use the same question that exposed the problem, then add an indirect question and a relevant exception. Keep inputs approved and avoid unnecessary customer information.
Synthetic example: A fictional source previously said a service was available everywhere. The approved correction limits it to a named operating region. The test should cover a request inside the region, one outside it and one without enough location information.
The expected result is a supported answer with the appropriate limitation. These are proposed tests, not observed agent behavior.
Close the audit with an evidence-based work list
For each finding, record the source, exact claim, priority, correction owner and acceptance evidence. Separate completed corrections from pending sync checks or tests.
Give unresolved findings a next step. “Content needs work” is less useful than identifying the obsolete requirement, the official source to verify and the affected article.
How often should knowledge content be reviewed?
Use a sustainable review cadence plus event-based triggers. A material product or policy change can require an earlier review than the next calendar date.
Record the date the claim was verified, not just the date someone changed the page formatting. A fresh timestamp does not establish fresh evidence.
Does a freshness audit prove better customer satisfaction?
No. It can establish which claims were reviewed and which corrections were verified. Customer satisfaction needs a separate measure and observation process.
Who owns the content after the audit?
Name a business owner for the claim and an operator for maintaining its published or synced copies. Include the support route for product or technical questions that the content owner cannot resolve alone.
Treat freshness as an ownership process
Google's current generative AI guidance says special AI markup is not required. That does not remove the need to check its separate inclusion requirements, and adding markup is not a substitute for verifying the visible claim. Google generative AI guidance
If you are evaluating how AI fits your operations, the forward-deployed AI overview offers broader context. For help establishing claim ownership and review, explore HubSpot operations support or request a scoped review.
