Webflow and SaaS company
What a Webflow pricing page actually says to something that only reads text
Almost every subscription business builds its pricing page the same way here: a monthly and annual toggle, and a tier comparison split across tabs. To a visitor that is one set of numbers at a time. To anything reading the served HTML it is every set of numbers at once, adjacent, with nothing in the text saying which one is currently showing. That is the whole of this pairing, and it produces answers that look like invention and are not.
Why this pairing is its own job
The Webflow install guide covers the tag, and the SaaS company guide covers what the assistant has to know. What follows is the part that belongs to neither.
- A billing toggle is an interaction over two blocks that both exist in the published markup. Hiding one visually does not remove it from the page, so a crawl reads both price sets as equally true statements about the same tier.
- Tier comparison built as tabs behaves the same way: every pane renders into the source, so the feature ticks for all three plans arrive as one undifferentiated block of text.
- The product itself is not a Webflow page. It is on another origin, built elsewhere, so the widget stops at the marketing site by default and so does anything it can read.
- That split is unusually clean on this pairing and worth exploiting: everything a subscription assistant can safely answer is on the Webflow side, and everything it must refuse lives on the side it cannot see.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Webflow guide. Everything below is about where it goes on a SaaS company site specifically.
One project, one surface
The footer field is emitted on published pages of this project. Your application, on its own subdomain and built somewhere else entirely, is not one of them and never becomes one.
So the install covers the marketing site completely and the product not at all, which is usually the shape you want. State it deliberately rather than discovering it, because it decides which half of your audience ever meets the assistant.
Whether the assistant follows the customer into the product
If you decide it should, that is a separate install on a separate platform with its own tag placement, plus that origin added to the allowlist. It is not a Webflow task at all.
Think about the material before doing it. An assistant that answers prospect questions well is answering a different audience from a signed in customer, whose questions are almost entirely about their own account and therefore almost entirely refusals.
Where the answerable material lives
| The pricing section, with every toggle state present in the source | Both price sets, both billing periods, all in the same block of text. Nothing in the markup marks one as conditional, because from the platform's point of view nothing is: an interaction changes what is shown, not what was published. |
|---|---|
| The comparison table, with every tab pane rendered | Feature lists for all tiers arriving as one run of text with the tab labels somewhere above them. This is what turns a question about one plan into an answer that describes the union of three. |
| CMS collection pages, whether or not anything links to them | Changelog entries, help articles, integration listings. Every published item has its own URL and appears in the generated sitemap, so a crawl reaches items that do not appear anywhere in your navigation. |
| The tier boundary rules, which are not on this site at all | What counts as a seat, what happens at a limit, how a mid cycle change is handled. These live in the product or in somebody's head, and the assistant cannot answer them until they exist as text somewhere it reads. |
The first thing to get right
Put the billing period into the text of each price block, so the annual block says billed annually inside the block rather than only on the toggle above it.
It costs one text edit per block and it is the difference between a corpus that contains two contradictory prices and one that contains two clearly labelled prices. It also improves the page for anyone reading it with styles off, which is the same reading the crawl performs.
The failure that belongs to this combination
Both prices, cited correctly, in one answer
A visitor asks what the middle tier costs and gets two figures back, with a citation pointing at your pricing page. The natural reading is that the assistant made something up, so somebody goes looking for a fault in the assistant.
There is no fault. The page says both numbers, the citation is accurate, and opening the page in a browser shows only one of them because an interaction is hiding the other. That gap between what the page shows and what the page contains is why this one takes so long to diagnose.
Confirm it by viewing the published page source and searching for the annual figure while the monthly toggle is selected. If it is there, the corpus has it. Label the blocks in text, re-index, and ask the same question again.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a SaaS company visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Should we move the pricing detail out of tabs entirely?
- You do not have to. Tabs are fine for a reader and the content is in the source either way, which is what you want. What matters is that each pane carries enough text to stand alone, so a plan name appears next to its own features rather than only in the tab label above them.
- Will it read collection items that are still drafts?
- No. Drafts are not served to anybody, so they are not read either. Published items are a different matter: they have live URLs and sit in the sitemap even when nothing on the site links to them, which is worth checking before a first crawl.
- Can it answer questions about a customer's account on our product?
- No, and on this pairing that limit is enforced twice over. It answers from indexed pages and documents, and the product is a separate origin it does not read. Have it explain the published rules, say plainly that it cannot see the account, and take a name and an email.
Keep reading
- Installing on WebflowPaste the tag into the footer custom code field, publish again, and allowlist the webflow.io staging address as well as your domain.
- Everything for a SaaS companyOne widget serves prospects, trialists and paying customers. What it can answer about plans and limits, and what has to reach a person.
- One agency, many Webflow projects, and the key that ends up in all of themOne key pasted into a client project answers on their domain with your material, and a transferred project takes the footer code with it.
- One origin, two build systems, and a tag from eachDocs proxied under a path on the marketing domain can end up carrying two tags, and the loader installs once, so one team's key quietly loses.
- A help centre on one domain and the commercial material on anotherThe help centre holds how-to articles. Plans, limits and trust pages live on your marketing site, a separate origin and a separate crawl.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.