Website Content Chatbot: How to Answer From Your Archive

Build a website content chatbot that answers from your archive with clear source rules, correction handling, citations, tests, and useful metrics.

Cover Image for Website Content Chatbot: How to Answer From Your Archive

The New York Post launched Hamilton Search on August 11, giving readers a conversational way to ask about its stories, local culture, and trending news. Axios reports that the Washington Post, Time, and USA Today have also experimented with AI chat interfaces. Publishers are starting to treat their archives as products people can query, not only pages people must find.

That shift applies to any content-rich website: a trade publication, university, museum, nonprofit, research firm, or documentation hub. Before choosing a model or redesigning the search box, write an archive answer contract:

  1. Answer only from the approved content collection.
  2. State the relevant publication or update date when freshness matters.
  3. Distinguish reporting, opinion, reference material, and sponsored content.
  4. Cite the canonical page behind each material claim.
  5. Surface corrections and conflicts instead of blending them.
  6. Say when the archive does not contain enough evidence.
  7. Give the reader a direct path to the original material.

Those seven rules are the foundation of a useful website content chatbot. Everything else—crawling, retrieval, prompts, citations, analytics—should make the contract easier to enforce.

Give the Chatbot One Editorial Job

“Chat with our website” is an interface label, not a job definition. A content chatbot can serve three different reader needs, and combining them without boundaries creates confusing answers.

Archive answers synthesize what the site has published about a question. The bot should identify its sources, preserve dates, and avoid filling gaps from general model knowledge.

Content discovery finds relevant pages without attempting a definitive answer. This is the safer mode when a query is broad, subjective, or poorly represented in the archive.

Personalized recommendations rank material using a reader's stated interests or account history. This requires a separate privacy and consent decision; it should never quietly alter the factual answer layer.

Pick one as the primary job. A practical default is: answer when the archive has sufficient current evidence, then recommend two or three source pages for depth. If evidence is weak, switch to discovery rather than improvising.

The distinction matters because a search replacement and an editorial assistant have different success criteria. Search succeeds when the right page appears. An answer succeeds only when its claims accurately represent the source material.

Build a Source Ledger Before You Crawl

A crawler can collect text, but it cannot infer your editorial hierarchy reliably. Create a source ledger that records how each content type may be used.

FieldPurposeExample
canonical_urlPrevents duplicate versions from competinghttps://example.com/guides/night-market
content_typeSeparates reporting, opinion, reference, and adsservice-guide
published_atPreserves the original time context2025-05-04
updated_atIdentifies the latest approved revision2026-08-12
authorityRanks sources for a defined questionprimary
correction_statusMarks corrected, superseded, or withdrawn pagessuperseded
access_ruleDefines whether text may be quoted or summarizedpublic-summary
expires_atForces review of time-sensitive material2026-09-01

The ledger does not need to start as a complex content system. A small site can maintain it as structured metadata beside its pages. The essential point is that the retrieval layer receives editorial facts the prose alone may not reveal.

Decide authority by question type. A live event page should outrank an old roundup for current opening hours. An official correction should outrank the original article for the corrected fact. An opinion column may be the best source for what its author argued, but it should not become the site's factual position.

If your source pages are not ready for that inventory, fix the pages first. Clear titles, canonical URLs, visible dates, descriptive headings, and explicit correction notices improve both ordinary search and chatbot retrieval. The chatbot training guide explains the broader preparation work; an archive adds the editorial metadata above.

Preserve Time, Type, and Corrections in Retrieval

Most retrieval pipelines split pages into chunks and match a user's question to the closest passages. That is necessary, but a content archive needs three additional controls.

Time-aware ranking. Recency should influence retrieval only where the query depends on current state. “What did the mayor propose in 2024?” needs the 2024 reporting. “What are the current parking rules?” needs the newest authoritative page, even if an older explainer uses more similar wording.

Type-aware labeling. Carry the content type into the answer context. Without it, the model may merge a columnist's prediction, a reported event, and a sponsored guide into one confident summary.

Correction-aware suppression. A corrected passage should not remain an equal candidate beside its replacement. Mark it as superseded, retain it for historical queries, and link it to the correction. Deleting the old page can destroy useful context; leaving it unmarked can reproduce the error.

Avoid indexing navigation text, related-story modules, repeated author biographies, and ad copy as if they were article content. Repeated boilerplate can dominate similarity matching simply because it appears on hundreds of pages.

Canonicalization also needs a rule. Print views, AMP pages, translated editions, syndicated copies, and tracking-parameter URLs may all contain substantially the same text. Choose one canonical record and attach the variants to it. Otherwise, five copies of one claim can look like five independent sources.

Worked Example: A Correction Must Win

Consider a city magazine with two archive pages:

- source: weekend-guide-2025
  published_at: 2025-06-10
  status: superseded
  claim: "The Harbor Night Market opens Saturday and Sunday."
  superseded_by: night-market-hours-2026

- source: night-market-hours-2026
  published_at: 2026-08-12
  status: current
  claim: "The Harbor Night Market now opens Saturdays only."

A reader asks:

Reader: Is the Harbor Night Market open on Sunday?

Chatbot: No. The current schedule says the market opens on Saturdays
only. An older 2025 weekend guide listed Sunday hours, but that page has
been superseded. See “Harbor Night Market Hours,” updated August 12, 2026.

That answer does four useful things: it resolves the conflict, states the current fact, explains why an older page disagrees, and names the governing source. A weak pipeline might retrieve both passages and answer “The market is generally open on weekends,” which sounds reasonable while preserving the exact error the correction was meant to fix.

Turn this example into four tests:

  • Ask whether the market is open Sunday; expect a clear “no” with the current source.
  • Ask what the 2025 guide said; expect the historical Saturday-and-Sunday statement plus its superseded status.
  • Ask why two pages disagree; expect the correction relationship.
  • Ask for next Sunday's special events; expect no answer unless a current event page supports one.

One small fixture tests current truth, historical truth, conflict handling, and honest uncertainty.

Define When the Bot Must Stop Answering

An archive chatbot needs a sufficiency rule that is stricter than “retrieval returned something.” Use the following decision order:

  1. Current primary source found: answer and cite it.
  2. Several compatible sources found: synthesize, preserving dates and attribution.
  3. Current sources conflict: describe the conflict and link both; do not choose silently.
  4. Only superseded or expired material found: label it historical and avoid presenting it as current.
  5. Only opinion or sponsored material found: attribute it explicitly or switch to discovery.
  6. No adequate source found: say the archive cannot answer, then offer relevant pages or a narrower query.

Write these outcomes into the system instructions and evaluation set. A generic “use the context” prompt leaves too much judgment to the model, especially when a retrieved passage is relevant but stale.

The no-answer path should still help. “I couldn't find a current schedule in this archive” is better when followed by the latest event page, a site search link, or a contact route. It is worse when followed by a guess from the model's general knowledge.

Make Citations Part of the Reading Experience

A raw list of URLs at the bottom of a long response forces readers to reverse-engineer which source supports which statement. Put citations next to the claims they support and expose enough metadata to judge them: title, publisher or section, publication date, and correction status where relevant.

For short answers, one primary link may be enough. For synthesis, cap the visible set to the few sources that materially shaped the answer and provide an option to expand. Ten loosely related links look thorough but make verification harder.

Anchor citations to canonical pages, not cached excerpts or internal chunk identifiers. If a page is behind a paywall, say so before the click. If your rights allow only a summary, keep quoted text short and send the reader to the original. The detailed chatbot citation design guide covers claim-level evidence and citation testing.

Do not measure citation success only by whether a link rendered. Test whether the cited page contains the claim, whether the date is represented correctly, and whether a correction or later update changes its meaning.

Keep Personalization Out of the Evidence Layer

Personalization can make an archive easier to explore. A sports reader may want team coverage first; a local subscriber may care about one borough; a researcher may prefer primary documents. Those signals may rank recommendations after the answer.

They should not change the underlying evidence. Two readers asking the same factual question should not receive incompatible facts because their reading histories differ. Keep a stable retrieval and citation record for the answer, then personalize optional follow-up material.

Collect only the data required for the promised experience. An anonymous reader can state an interest in the conversation without creating a durable profile. Signed-in personalization needs a clear purpose, retention rule, and reset control. Never turn a reader's questions into publishable source material or training data without a separate review and rights decision.

Release With a Small, Difficult Test Set

Start with 30 questions, not 300 easy ones. Use five groups of six:

  • current facts with one authoritative page;
  • historical questions where the older source should win;
  • corrected or conflicting claims;
  • opinion, review, and sponsored-content boundaries;
  • missing, ambiguous, or out-of-scope questions.

Record the expected source, required facts, forbidden claims, date behavior, and whether the bot should answer or switch to discovery. Add common paraphrases only after the core judgment is correct.

Track a compact set of launch metrics:

MetricCalculationWhat it reveals
Supported-claim rateSupported material claims / reviewed material claimsWhether answers follow the archive
Current-source accuracyCorrect current-source choices / freshness-sensitive casesWhether updates and corrections win
Honest no-answer rateCorrect abstentions / insufficient-evidence casesWhether the bot resists guessing
Source-open rateConversations with a citation click / cited conversationsWhether readers use the evidence path
Correction lagTime from correction publish to corrected chatbot answerWhether the index stays current
Query reformulation rateReworded queries / conversationsWhere answers or discovery paths confuse readers

Review transcripts behind the totals. A high source-open rate could mean readers value the links, or that the answer failed to satisfy them. Pair clicks with answer ratings, follow-up questions, and a manual claim check.

Turn the Archive Into a Trustworthy Interface

A website content chatbot earns repeat use when it makes an archive easier to question without flattening its history. The operating discipline is straightforward: define the editorial job, label the sources, preserve time and corrections, cite the evidence, and make uncertainty useful.

In Agentkit, you can crawl website sources, add documents and controlled Q&A pairs, review conversations in chat logs, and keep eligible website sources refreshed automatically.

Build your chatbot for free →

No credit card required.

Zacznij bezpłatnieKarta kredytowa nie jest wymagana