Practical Lens 58: FAQ pages can train the wrong answer

The risk

Old objections can keep old positioning, pricing logic or product assumptions alive after the business has changed.

The control

Every material answer has a claim owner, a source of truth, an approval date and a trigger for re-review.

Why this happens

FAQs often begin as sales enablement. A team adds answers to overcome an objection or reduce support demand; then product scope, pricing, market focus or delivery changes. Because FAQs are compact and useful, they tend to survive redesigns and content migrations. The result is not necessarily false content. It is content with an expired business context.

What this usually indicates

• FAQ content has no review trigger tied to product or commercial change.
• Marketing owns publication but nobody owns the underlying statement.
• Removed offers, former audiences or superseded pricing logic remain publicly discoverable.
• Business leaders cannot show which FAQ claims are current without reading pages one by one.

These observations do not prove an AI system has reused an answer. They identify a public-evidence risk that can be checked and controlled.

What to verify (evidence-only)

1. Inventory every live FAQ. Include standalone FAQ pages, product-page accordions, help-centre articles and campaign landing pages.
2. Extract material claims. Flag statements about price, eligibility, capability, security, geography, integrations, timing, availability, outcomes and target customer.
3. Compare with current business truth. Have the owner of each claim classify it: current, revise, remove or escalate. Do not let the copywriter certify the fact alone.
4. Record the outcome. Keep the page URL, exact question, claim owner, source of truth, decision, approval date and next trigger in one register.
5. Recheck the published page. After updates, retrieve the live page and confirm the obsolete phrase no longer appears in the customer-visible content.

Terminal check example

Replace the URL and the keywords with terms from your former offer, pricing model, product name or target audience. The expected result is a list of matching lines for a human reviewer; a match is a review candidate, not proof that the claim is wrong.

FAQ_URL="https://www.example.com/faq"
curl -fsSL "$FAQ_URL" -o faq.html
sed 's/ / /g; s/&/\&/g; s/<//g; s/<[^>]*>/ /g' faq.html |
  tr -s '[:space:]' ' ' |
  grep -Ein 'old-product-name|former-plan|old-pricing-term|legacy-use-case' || true

This does not certify the FAQ. It only shows what the selected terms matched in this page retrieval; each match enters the currency check with the claim owner.

PowerShell check example

Replace the URL and keywords. The expected result is candidate wording, stripped from the page markup, for review against your claim register.

$faqUrl = 'https://www.example.com/faq'
$keywords = 'old-product-name|former-plan|old-pricing-term|legacy-use-case'
$html = (Invoke-WebRequest -Uri $faqUrl -UseBasicParsing).Content
$text = [regex]::Replace($html, ' ',' ')
$text = [regex]::Replace($text, '&','&')
$text = [regex]::Replace($text, '<','<')
$text = [regex]::Replace($text, '>','>')
$text = [regex]::Replace($text, '<[^>]*>',' ')
$text -split "`n" | Select-String -Pattern $keywords -CaseSensitive:$false

Retain this output with the decision record. Evidence is the live published text plus the current approved business position—use both before deciding whether to keep, revise or remove an answer.