RAG guide / 2026
How to Build a Public-Web RAG Pipeline in 2026
RAG works best when retrieval units are understandable to models and reviewers. Start with a small set of high-quality public sources, use readable content rather than page chrome, and store enough metadata to trace an answer to its URL.
Quick answer
Collect less raw HTML and keep every chunk attributable.
Discover sources, extract readable content, store canonical URLs and dates, chunk by headings, and refresh only sources whose facts may have changed.
curl --get 'https://extractor.sh/api/extract' \
--data-urlencode 'url=https://example.com/' \
--data-urlencode 'format=json'Available data
What you can extract
- Readable heading-aware content
- Canonical source URLs and metadata
- Typed entities for supported sources
- Stable JSON fields for indexing
AI workflows
Where normalized data helps
- Knowledge-base ingestion
- Answer citations and audits
- Document refresh workflows
- Cross-source retrieval evaluation
AI-ready output
Markdown for models. JSON for systems.
Raw HTML consumes tokens on navigation, scripts, styling, and interface labels. Clean Markdown keeps the readable hierarchy for LLM prompts and RAG chunks. Normalized JSON is better when your application needs an explicit semantic type, source, author, publication date, media, attributes, and collection items.
Always retain the canonical URL from the response. AI-generated summaries should remain traceable to the public source, especially when the underlying page can change.
Boundaries
Public data only
- A RAG pipeline still needs its own chunking and embedding policy.
- Do not ingest private or restricted content.
- A cache is not a freshness guarantee.
extractor.sh does not bypass CAPTCHAs, login walls, paywalls, access controls, or regional restrictions. Review the source’s terms and applicable law before collecting or reusing data.