Re-indexing isn’t verification.

Short answer Re-indexing, which some tools call retraining or re-syncing, makes a search tool or AI support agent read the latest version of your articles. It can’t tell whether those articles still match your product. Verification follows the documented steps in the running product and records what was checked, so verify first, then re-index.

Here’s a familiar situation. A customer says the support bot sent them to a button that doesn’t exist. Someone re-syncs the bot’s sources, asks the same question, and gets the same wrong answer, because the article the bot reads still describes last quarter’s product.

Re-indexing did its job; the problem sits upstream. This guide covers what each step does, what re-indexing can’t catch, what a verification record should contain, and a checklist you can run this week without a new tool.

What does re-indexing actually do?

Re-indexing goes by many names: retraining, re-syncing, refreshing sources, re-crawling. The mechanics are much the same. The system fetches your current articles, splits them into passages and rebuilds the index it searches. When a customer asks a question, it retrieves the most relevant-looking passages and writes an answer from them, a pattern often called retrieval-augmented generation, or RAG.

Despite the name, “retraining” in most support tools doesn’t change the model; it changes what the model is handed when it answers. That step is necessary. Without it, an agent keeps answering from an old copy of an article you already fixed. It’s fast and mechanical, and many tools run it on every publish or on a schedule.

Its job is narrow: the AI system reads the same text your readers see. It says nothing about whether that text is true.

Why can an AI agent still be wrong after a re-sync?

Because an article can be wrong in a way that reading it won’t reveal. Help content drifts when the product changes and the text doesn’t. The article stays well written, internally consistent and freshly indexed. It just describes a product that no longer exists.

The common kinds of drift:

• A renamed button or menu item. The article says “Invite teammates”; the product now says “Add members.”
• A moved setting. The option still exists, one menu deeper or on another page.
• A new required step. A confirmation screen or a mandatory field appears mid-flow, and the article skips it.
• A step that depends on role. It works for admins; members never see the button.
• A changed default. New projects are now private, and the article still says everyone can see them.
• A plan-gated feature. The feature moved to a higher plan, and nothing in the article says so.
• An outdated screenshot. Someone fixed the text, but the image still shows the old screen and contradicts it.

None of these shows up as an error in the text. Re-indexing copies each one faithfully, and the agent answers with confidence. It’s doing its job well; the source is out of date.

Other text-based checks share the blind spot. An AI model reviewing your articles can find contradictions, gaps and broken links, but not a renamed button, because that evidence isn’t in the text. Suggestions drawn from support conversations help, though they arrive after customers have hit the problem. To know whether an instruction still works, someone has to follow it in the product.

A worked example: one renamed button

Here’s an illustrative example using Acme, the fictional app in the release demo on our homepage.

Acme’s help center has an article called “Invite your team to Acme.” Step 2 says: “Click Invite teammates in the top-right corner.” Release v2.4 renames the button Add members and moves it to Settings › Members. Nobody edits the article, and the nightly re-sync runs as usual.

After the re-sync, the agent’s copy is perfectly fresh, and a customer who asks “How do I invite a colleague?” gets a confident answer pointing at a button that’s gone.

The old label also hides where a title search won’t find it. In the homepage sample, the rename touches three articles and four screenshots, plus a tip written by Maria, a teammate: “If you don’t see Invite teammates, ask an admin for access.”

A verification run approaches it from the product side. It replays “Invite a teammate” on v2.4 and compares each step with the article:

1. Step 1 matches.
2. Step 2 fails: there is no Invite teammates button. The run finds Add members under Settings › Members, and notes that screenshot 2 no longer matches the product.
3. Step 3 matches.
4. Step 4 would send real invitations, so it isn’t executed. It stays labeled unverified.

The result is a finding tied to one step, with the evidence attached, and a small fix a person can approve: 2 of the article’s 26 blocks change, the step and its screenshot. Maria’s tip is flagged for her rather than rewritten. Once the fix is approved and published, the re-index finally has something correct to copy.

What does verification mean?

Verification means following the documented steps in the running product and keeping a record of what happened. Reading an article and deciding it looks right is review. Both are useful; only one tells you whether the steps work.

A useful verification record answers six questions:

• Where? Production or staging, and which build or version.
• As whom? The account role, and the plan when features depend on it. A step verified as an admin says little about what a member sees.
• When? The date and time of the run.
• In which language? Labels differ by locale, so a check in English doesn’t cover a translated interface.
• What ran? Which steps were executed, and what was seen at each one.
• What didn’t, and why? A step that would email real people, delete data or charge a card is followed up to the last safe screen and stopped. It stays labeled unverified instead of being assumed to work.

Read the record critically and its limits are plain. It shows the steps work for an admin, on staging, in English. It doesn’t yet show what a member sees in production. That isn’t a flaw in the record; it’s the record doing its job.

Four labels, one per statement

Every statement in a checked article carries one of four labels:

• Observed Seen in the product during a replay, by a named account, on a named build.
• Inferred Derived from a release or code change, not yet replayed. A merged change isn’t proof that it’s deployed.
• Imported Carried over from your existing help center. Your team’s words, not yet re-checked.
• Unverified Couldn’t be checked, with the reason. It waits for a person instead of being guessed.

You can see all four labels on a sample article on our homepage. A plain “unverified, and here’s why” is more useful than a green tick that implies more was tested than actually was.

How do re-indexing and verification fit together?

They answer different questions. Re-indexing asks whether the AI system is reading the latest text. Verification asks whether the latest text is still true. You need both, in a fixed order: verify, fix, review, publish, then re-index.

Why the order matters

Re-index before you verify and you’ve refreshed the agent’s copy of a wrong instruction. Fix without re-indexing and the help center is right while the agent keeps answering from the old copy until its next sync.

If your AI tool re-syncs automatically when you publish, the order takes care of itself. If it syncs on a schedule, trigger a sync after publishing an important fix rather than waiting.

Why a freshness date isn’t enough

A “last updated” date records when someone last saved the article, not when anyone checked it against the product. A typo fix resets the date on an article whose steps are wrong; an article untouched for a year may still be right. A recent date also makes a wrong article more convincing to readers, not less.

A “last verified” date is better, but only with its scope. “Verified today” means little if the check ran as an admin, on staging, in a different language from your readers. Keep the scope next to the date, or the date will overstate what was checked.

A checklist you can use this week

You don’t need a tool to start. A spreadsheet, a test account and a handful of important articles are enough to see how far your help center has drifted.

1. Pick the articles that matter most. Start small: the articles customers read most, the ones your support team links in replies, and anything in the path of a recent release.
2. List what the last release changed. From release notes or merged changes, note every renamed label, moved setting, new step and permission change. Merged isn’t the same as deployed, so confirm what actually shipped.
3. Search for the old words. Search your help center for each old label, exactly as written. Check screenshots by eye; search won’t read the text inside an image.
4. Follow each priority article in the product. Use a test account with the role most readers have, on the build customers use, in the language they read. Do exactly what the article says, nothing more.
5. Stop before anything you can’t undo. Don’t send, delete or pay. Note the step as not run, and why.
6. Record the check. Date, build and environment, role, language, the steps you ran and the ones you didn’t. One row per article is enough.
7. Label each step. Observed if you saw it work, inferred if you’re relying on release notes, imported if you didn’t re-check it, unverified if you couldn’t, with the reason.
8. Fix, review and publish. Have a second person review anything touching billing, permissions, security or data deletion. For the rest, our guide on which help-center updates you can automate sets out how much review each change needs.
9. Re-index, then ask the agent. Trigger your AI support agent’s re-sync, then ask it the questions customers actually ask about the flows you fixed. Keep that list and ask it again after every release.

Treat that last step as its own measurement. Better sources help, but an agent’s answers also depend on retrieval, its instructions and when it hands off to a person, so don’t assume a fixed article means a fixed answer.

Where HelpCenter.AI fits

HelpCenter.AI takes on the verification half of this loop. It replays the flows your articles describe inside your app, using a test account you provide; the password is kept in an encrypted vault and never shared with the AI model. It links GitHub release changes to the articles and screenshots they affect, records the scope of every check, and labels each statement observed, inferred, imported or unverified. Steps that would delete, send or pay are never executed.

When something no longer matches, it proposes a block-level edit and a re-rendered screenshot for your team to review. Text your team wrote is flagged, never silently rewritten. Approved updates publish to HelpCenter.io or export as Markdown and llms.txt, so the next re-index reads a corrected source.

It doesn’t replace your AI support agent or docs platform; it checks what they rely on. See our comparison with AI support agents and docs platforms, or how HelpCenter.AI checks, records and proposes updates.

HelpCenter.AI is in early access with assisted onboarding. The easiest start is an audit of the help center you already have: a public-URL audit needs no app access, and checking steps inside your signed-in product needs a test account when you’re ready.