Public FirstSales pages now serve a clean text version to assistants that ask for one. When somebody asks Claude or another assistant about FirstSales, the answer can come from what the page actually says.
What changed
Assistants read web pages, and a modern web page is a poor thing to read. Most of what is in the file is layout, scripts, and navigation, and the sentences that matter are scattered through it.
A page can offer a plain text version to a client that asks for one, using the same mechanism browsers use to negotiate any other format. Our pages now do. Ask for the page normally and you get the page. Ask for markdown and you get the content as clean text, with headings and links intact and none of the scaffolding.
Getting this right also required care with caching. A page served through a cache has to keep the two versions apart, or a browser can receive the text version and an assistant can receive the styled one. Both are wrong and the second is invisible until somebody complains their page looked broken.
Why it matters
More people ask an assistant about a product than read its documentation directly. That is simply how the question gets asked now, and the answer they get is shaped by what the assistant could read.
An assistant that cannot read the page cleanly answers from whatever it absorbed during training, which for a product that ships weekly is out of date by definition. It describes features that changed and misses ones that did not exist yet.
Serving the real text means the answer reflects the product as it is. That is better for the person asking and better for us, and it does not require anyone to change how they ask.
What this covers
Documentation, guides, and the changelog. The pages that describe how things work, which are the pages questions are actually about.
Marketing pages describing features and pricing, so an assistant asked what FirstSales costs can read the answer rather than remember one.
The blog, where longer explanations live.
What it does not cover
Anything behind a login. Your workspace, campaigns, and data are not public and are not served this way to anything.
For an assistant to reach your own data there is the MCP connection, which is separate, requires your explicit approval, and is scoped to one workspace. Public pages and private data are two different mechanisms and neither leaks into the other.
For people building things
The mechanism is standard content negotiation. Request a public page with an Accept header asking for markdown and you get markdown.
That makes the pages usable as a source for anything that reads documentation, not only conversational assistants. A script that pulls the changelog to post internally can take the text version and skip the parsing entirely.
Nothing about the normal page changed. Browsers request what they always requested and receive what they always received.
The caching problem, briefly
A cache in front of a site stores a response and serves it to the next request for the same address. When one address can return two different things, the cache has to know that, or it serves the wrong one.
The standard way to signal this is a header telling the cache which part of the request matters. Getting that configuration exactly right, in a way the cache in front of the site actually honours, was most of the work here and none of the visible result.
The visible result is that both versions are always correct, which is the kind of outcome that is only noticeable when it fails.
Keeping the changelog current
This page is one of the pages served as clean text, which is deliberate. Questions about what changed and when are among the most common ones asked about any product, and they are the ones where an out of date answer is most obviously wrong.
An assistant asked what shipped in FirstSales last month can now read the entries rather than reconstruct them, which is the difference between an accurate answer and a plausible one.
The same applies to how features work. Documentation that changes when the product changes is only useful if the thing answering the question can see the change.
What we are not doing
There is no content served to assistants that differs in substance from what a person sees. The text version is the same content without the scaffolding, not a separate document written for machines.
Serving one thing to a reader and another to a crawler is a well established bad practice, and it is worth saying plainly that this is not that. The two versions carry the same words.
What an assistant can answer now
Questions about how a feature works, what a setting does, what a plan includes, and what changed and when. All of that lives on public pages and all of it is now readable cleanly.
What it still cannot answer is anything about your account, because that is not public. An assistant asked how many emails your campaign sent yesterday needs the MCP connection, not the website.
Keeping that line clear is deliberate. Public information should be easy for anything to read. Private information should require your explicit, revocable permission, and it does.
Verifying it yourself
Request any public page with an Accept header asking for markdown and compare it against the same page in a browser. The words should match and the scaffolding should be gone.
If the two ever disagree in substance, that is a bug worth reporting, because they are generated from the same source and disagreeing is not something they should be capable of.
Availability
Live now across public FirstSales pages. Nothing to enable, and no change to how the site behaves in a browser.