By Saurav · saavos
[!TLDR] "Training ChatGPT on your website" almost always means RAG (retrieval-augmented generation), not fine-tuning. RAG indexes your site, retrieves the relevant chunks at query time, and feeds them to a frontier model — so the bot answers from your content with citations and updates whenever your site does. Custom GPTs are easier but live inside ChatGPT.com. Fine-tuning teaches style, not facts, and is almost never the right tool for product knowledge. For 95% of teams, RAG over a crawl of your site is the answer.
What people actually mean by "training ChatGPT on your data"
Five different things, depending on who's asking:
- A Custom GPT. A configuration inside ChatGPT.com that gives the model a name, a system prompt, and up to 20 uploaded files. Lives inside ChatGPT — visitors need a paid ChatGPT account to use it.
- Fine-tuning. Adjusting the weights of a base model (GPT-4o-mini, Llama, Claude Haiku) on your own dataset. Teaches the model your style; rarely teaches facts reliably.
- A RAG chatbot embedded on your site. Indexes your content, retrieves at query time, generates with citations. The default modern approach.
- Putting your docs in the system prompt. Pasting a chunk of FAQ into a hardcoded prompt. Works for tiny sites; fails the moment your content exceeds the context window or a few thousand tokens of useful retrieval.
- A direct API call. With no retrieval, the model only knows what was in its pretraining data. Almost never the right answer for product knowledge that ships changes weekly.
When somebody says "I want to train ChatGPT on our website," they almost always mean #3 — they want a chatbot that knows their content and lives on their site. The confusion is mostly OpenAI's branding fault: it doesn't separate the model (GPT-4o) from the product (ChatGPT.com) from the deployment pattern (API call, Custom GPT, embedded chatbot).
The three real options, compared
| Approach | What it does | Setup time | Cost (small site) | Updates when site changes | Lives on your site |
|---|---|---|---|---|---|
| Custom GPT (ChatGPT.com) | System prompt + 20 files | 30 min | $20/mo per ChatGPT Plus user | Manual re-upload | No — only inside ChatGPT |
| Fine-tuning a model | Adjusts model weights | 1–7 days | $50–$500 + per-token | Re-train per change | No — needs hosting |
| RAG chatbot on your site | Retrieves at query time | 5 min – 2 wks | $0–$199/mo | Automatic re-index | Yes — embed widget |
These solve different problems. Custom GPTs are good for personal or internal-team use. Fine-tuning teaches a model how to write. RAG teaches a model what your business knows. They're not really alternatives in the way "Postgres or MySQL" are alternatives — and you can run more than one.
Why RAG wins for website data
Three reasons, in order of importance.
Updates are free. When your pricing page changes, a RAG chatbot reflects it the next time someone asks. Fine-tuned models don't — you re-train. Custom GPTs need a manual file re-upload. For a website that ships changes weekly, the operational overhead of anything except RAG is immediately painful.
Citations are possible. Because RAG retrieves specific chunks, the bot can attach a "source: /pricing" link to every claim. Fine-tuning blends content into the model's weights — there's no longer a per-claim source you can cite. For a public-facing chatbot that earns trust by being verifiable, this matters more than almost anything else.
Hallucinations are reducible, not just hopeable. A well-tuned RAG pipeline with a fallback message ("I don't know — email support@yourbusiness.com") fails visibly when retrieval finds nothing. Fine-tuned models confidently invent things outside their training set, and you'd never know unless you tested every possible question.
When RAG isn't enough, it's rare but real: if your bot needs to imitate a specific writing voice (a customer-service tone unique to your brand) more than it needs current facts, you might add fine-tuning on top of RAG. If your bot needs to do multi-step reasoning that your existing pages don't capture (e.g., "given an X budget, recommend Y plan"), you'll need application logic on top of retrieval. Neither replaces RAG; both layer on.
The 5-minute path: training RAG on your website
The mechanics are simpler than the marketing makes them sound. Five steps:
1. Pick a managed RAG platform
Anything that ingests a URL — saavos, Chatbase, Wonderchat, Botsonic. The DIY route (LangChain or LlamaIndex plus a vector DB) takes 2–8 weeks of engineering, and unless retrieval quality is your competitive moat, it's almost never worth the time. Managed platforms in 2026 are production-grade.
2. Paste your homepage URL
The platform crawls your public pages. For sites under 100 pages this finishes in under a minute. The crawler typically respects robots.txt and follows internal links up to a configurable depth.
3. Wait for the embedding step
Each ~500-token chunk gets converted into a 1,536-dimensional vector (typically via OpenAI's text-embedding-3-small). For a 50-page site this takes 1–2 minutes. The embeddings are stored in the platform's vector database — you don't see them, you don't manage them.
4. Set the fallback message
This is the one most people skip. If retrieval finds nothing, what should the bot say? "I'm not sure about that — please email us at support@yourbusiness.com" is infinitely better than letting the model improvise. A visible fail beats an invented answer every time, and visitors respect the honesty.
5. Embed the widget
A single <script> tag before </body>. The page renders first, the widget loads after — zero impact on Largest Contentful Paint or Time to Interactive. On saavos the snippet looks like this:
<script src="https://saavos.com/embed.js" data-bot="your-slug" defer></script>
That's the entire training process for 95% of teams. The complexity that used to live in retrieval pipelines now lives inside the platform.
Common mistakes that ruin RAG quality
In rough order of how often we see them:
- Training on PDFs that are scanned images. The chunker reads text, not pixels. Run scanned PDFs through OCR first — most platforms do this automatically; some don't.
- Dumping every blog post into the index. Blog posts are usually written for SEO, not accuracy. They contain marketing claims that get retrieved over the actual product page. Scope sources tightly: docs, FAQ, pricing, product spec pages. Add blog posts only if they're factual.
- No re-crawl schedule. Some platforms only crawl once. If yours doesn't auto-refresh weekly, set a calendar reminder to trigger a manual re-index after every meaningful site change.
- Forgetting non-HTML content. Pricing tables that live inside a Notion embed, FAQ in a Google Doc, internal handbooks. Upload these as separate sources — the public crawler won't see them.
- Generic system prompt. Most platforms ship with "You are a helpful assistant." Replace it with role-specific guidance: "You answer questions about [Company]'s [product category]. Decline questions outside this scope politely. Cite a source for every factual claim."
What training actually costs in 2026
For RAG on a small-to-medium site:
- Embedding cost (one-time per crawl): ~$0.02 per 100 pages on
text-embedding-3-small. - Storage: Bundled into the platform's monthly fee.
- Per-message inference: Bundled into the message quota on most consumer platforms — you pay $19–$199/mo and don't see the underlying model API cost.
- Total monthly cost for a typical SMB: $0 (no-card preview) to $49/mo (mid-tier), with 1,000–3,500 messages included.
For fine-tuning, the math looks different and worse for most teams: $50–$500 to train, then per-token inference forever, plus your own hosting if you're not on OpenAI's hosted fine-tuning. And every site change means re-training.
For a Custom GPT, you pay $20/mo per user for ChatGPT Plus — but only the people you share the GPT with can use it, and they all need their own ChatGPT account. Useless for public customer support.
When to use each approach
- Custom GPT. You want a private assistant for yourself or your team, you don't need it on your website, and your users have ChatGPT Plus. Free, low-effort, internal-only. Don't use it for public customer support.
- Fine-tuning. You have a unique writing voice you can't get from prompting alone, you have 1,000+ high-quality training examples, and you've already exhausted RAG plus good prompting. Rarely the answer for product knowledge — common in legal, medical, and other voice-sensitive domains.
- RAG chatbot. You want a chatbot on your site, trained on your content, that updates automatically and shows citations. Almost always the answer for customer-facing support and sales bots in 2026.
Privacy: will OpenAI or Anthropic train on my data?
For paid API access: no, by default. As of 2026, both OpenAI and Anthropic explicitly do not use API-submitted data to train shared models — this is part of their enterprise contract terms and applies to all paid API usage. Free-tier ChatGPT.com conversations are different — those can be used for training unless you opt out in settings.
For platforms in between (saavos, Chatbase, Wonderchat, etc.), you're trusting the platform to pass your data through to the underlying API without retaining it for cross-tenant training. Always check the data processing addendum. saavos stores conversation history in your own dedicated Postgres tables, never feeds it back into model training, and keeps each customer's index isolated from every other tenant.
What to do next
If you want to "train ChatGPT on your website" for actual customer use — a public support bot, a sales assistant, anything visitors will see — go with RAG via a managed platform. Test saavos, Chatbase, and Wonderchat with your real content; pick the one with the best fallback handling and citation UX for your specific audience. The full evaluation usually takes a Saturday afternoon.
Preview saavos — paste your URL, get a working chatbot in 5 minutes, no credit card required for the no-card preview. Or see our pricing for paid-tier specifics when you outgrow the free 50/month.