Optimizing Your Webpages for Spara Scraping
How Spara scrapes your webpages into Knowledge, and what makes a page read well or badly.
Spara scrapes your public webpages and adds them to https://docs.spara.com/platform/knowledge, the shared content library every Spara agent draws on — chat, email, and voice alike. Whatever survives the scrape is what your agents know about your product, pricing, and positioning; whatever doesn't, they can't use. This page is for the web or engineering team that owns the site: what Spara captures, what it misses, and the handful of markup choices that make the difference.
Knowledge is also where you manage which pages are indexed and review what Spara captured from each one.
How Spara reads your pages
Spara scrapes your site ahead of time, on a recurring pass — it isn't fetching pages live during a conversation. Each page is loaded in a browser, its JavaScript runs, and the rendered result is converted to plain text and markdown. That text is what lands in Knowledge, and it's all your agents have to work from.
Because the page is genuinely rendered, client-side frameworks are not a problem: a React, Vue, or Svelte site reads the same as a server-rendered one.
What doesn't survive is anything that never becomes text on the rendered page. Spara reads the page as it loads and doesn't interact with it — no clicking, hovering, or scrolling — so content that a visitor has to act on to reveal stays hidden. And information carried only visually — pixels inside an image, a color, a CSS-drawn icon — leaves no text for the conversion to pick up.
One principle covers most of what follows: if your page meets web accessibility standards, it will read well. The semantics that let a screen reader convey a page are the same semantics this conversion extracts. If a screen reader can make sense of the page, so can Spara.
What reads well
Content that is on the page once it has finished loading. Whether the markup came from the server or was rendered in the browser makes no difference. Server-rendered and static pages remain the most predictable choice, because nothing depends on timing.
Semantic structure —
<article>,<section>, real headings (<h1>–<h3>), lists, and paragraphs. These carry through as headings and lists, which is what tells your agents which facts belong to which topic.Clean, readable body text. If a sentence could be read aloud and still make sense, it survives.
Informative content in the main article flow. Sidebars, nav, footers, ads, social widgets, and modals are treated as boilerplate and dropped before conversion. If a fact matters, don't leave it in a widget.
Real
<table>markup for tabular data such as pricing and feature comparisons.Paginated listings. Spara reads one URL at a time, and paginated pages have real URLs it can follow.
What reads badly
Content that only appears after a particular user interaction — click-to-expand sections, tabbed panels, "load more" buttons. Spara doesn't click, so whatever the interaction would have revealed is not read.
Content that arrives after the page has settled. Spara doesn't wait around for late additions once the page has loaded, so a slow request still streaming content in can miss the window.
Text baked into images. In a screenshot or an exported graphic, the words are part of the image itself, not machine-readable text. A spec sheet saved as a PNG contributes nothing.
Canvas and WebGL interfaces. Text drawn into a
<canvas>element or a 3D scene is invisible to the conversion.Infinite scroll in place of pagination. Items that load only as a visitor scrolls are never fetched.
Images and figures
alt text is what carries an image's meaning through the conversion, and it is sufficient on its own — it becomes the image's content in Knowledge. Give descriptive alt text to every image that is structural to the information on the page: a diagram, a screenshot of a report, a checkmark that means "supported."
For a dense chart or diagram, a <figcaption> is worth adding for a reason of its own: unlike alt, it is visible to every reader, and it has room for detail that doesn't sit comfortably in an alt string.
The alt attribute carries the numbers into Knowledge; the caption puts them in front of human readers as well.
Tables
Pricing and comparison tables are the most common place information gets lost, in two distinct ways.
Use real table markup, not stacked <div>s. A table assembled from <div>s converts to an undifferentiated run of text: the words come through, but which value belongs to which plan is lost.
Don't put meaning in a decorative checkmark. This is the single item most worth checking on your own pricing page. A checkmark marked up as an image with alt text reads correctly:
The same checkmark drawn with a CSS background-image, or marked up as <div role="img" aria-label="Supported">, produces an empty table cell. There is no text for the conversion to pick up, so Knowledge holds a blank where you meant "supported" — and a blank in a pricing table is easily read as "not included." Use an <img> with descriptive alt text, or simply put the word in the cell.
Checking a page yourself
Three checks catch nearly everything, all of them free.
Search the rendered DOM without touching the page. Load the page, open DevTools (F12), and search the Elements panel for the text you expect Spara to capture. That rendered DOM is close to what Spara reads. The discipline is not to click, expand, or scroll first — if you have to interact with the page to make the text appear, Spara won't see it either.
Run an accessibility audit. Lighthouse is built into Chrome DevTools (Lighthouse panel, Accessibility category); axe DevTools is a free browser extension that reports more detail. Anything flagged as missing alt text, a non-semantic table, or an unlabeled control is likely also missing from what Spara captures.
Read the page with a screen reader. VoiceOver is built into macOS (Cmd+F5) and NVDA is free on Windows. This is the human-scale version of the same check, and it is the fastest way to notice a checkmark or a table cell that conveys nothing.
To see roughly what the text extraction yields, pipe the page through a local HTML-to-markdown converter such as Pandoc (pandoc -f html -t markdown). Save the rendered DOM from DevTools rather than the raw response, so the converter sees the same content Spara does.
FAQ
How soon will markup changes show up in Knowledge?
By default, Spara re-crawls each site once every 24 hours, so a markup change is normally reflected within a day. The refresh interval is configurable per domain, so yours may be set differently — ask your Spara representative if you need to know or change the interval for your site. If you need an immediate refresh after a site update, they can also re-index the affected pages on request.
Can I check what Spara actually captured from a page?
Yes. The https://docs.spara.com/platform/knowledge page lists every indexed page and lets you review the content Spara extracted from each one, which is the fastest way to confirm a fix worked.
Last updated