The homepage that impresses a boardroom can leave an answer engine holding an empty envelope. It sees ambition, sector language and trust signals, yet still cannot say the small useful thing: what the software actually does.
I once printed the homepage of a French finance-workflow SaaS and put it beside three other pages from the same company: a pricing note, a support article about ERP connections, and a short release post about approval rules. This is a composite scenario, assembled from several audits, but the mess is familiar. The homepage said the company “orchestrated financial performance for modern industrial organizations.” The docs said it routed supplier invoices through approval chains. The pricing note said SAP and Sage connectors were included above a certain package. The model named the brand correctly, then described it as a “business performance platform,” which was both too grand and too vague.
The odd part was that the company had the facts. They were not absent. They were scattered like screws after someone opened a machine and forgot which tray held which size. The CEO had wanted investor confidence. The marketing lead had wanted category breadth. Procurement wanted reassurance. Documentation wanted fewer tickets. Each page obeyed its own pressure. Then an answer engine tried to make one public description out of all of it, and the homepage, the most visible page, offered the least extractable help.
The investor sentence has a different job
Investor homepage copy often tries to widen the company before it identifies it. That can make sense in a pitch deck, where the reader is already inside the story and expects market size, urgency and strategic language. A homepage has a harsher role. It is read by buyers, partners, job candidates, competitors, procurement teams, journalists, and models that break the page into fragments.
The investor sentence likes nouns with room in them: performance, visibility, agility, orchestration, intelligence, trust. It also likes verbs that avoid a specific object. The company “helps,” “supports,” “simplifies,” “modernises,” “improves.” Some of these words are harmless in human reading. A person can scroll, connect clues, notice screenshots, infer the product from the navigation. A model has no duty to rescue the sentence. If the sentence does not say the action, user, object and limit, it may borrow that shape from the category around it.
In the composite finance SaaS, the homepage had a sentence close to this teaching example: “We help finance leaders gain control over operational spend.” That sounds reasonable until it leaves the page. Does it approve invoices? Track budgets? Detect fraud? Manage supplier contracts? Reconcile payments? Once detached from the surrounding layout, the sentence becomes a hallway with six possible doors.
A plain capability sentence is less glamorous and more useful: “The platform routes supplier invoices for approval across French mid-market finance teams, with ERP connections for industrial groups.” It is not the only sentence the page needs. It may even be too dense for a hero line. But somewhere near the top of the homepage, a statement like that must exist. Otherwise the answer engine sees category atmosphere before product function.
What an LLM can lift from a homepage
I use the word “lift” because it keeps the problem physical. Imagine a sentence printed on a strip of paper. If I cut it out and slide it across the table, can it still tell the truth? Most homepage sentences tear when lifted. They rely on the headline above, the diagram below, or the reader’s patience with brand language.
A liftable SaaS capability sentence is a sentence that names the product action, user, business object and operating boundary, because an answer engine needs those elements to repeat the claim accurately. That is my working definition. It is not a style preference. It is a retrieval condition.
There is a small classification I use when marking homepages: the investor fog, the category mirror, and the orphan proof. The investor fog happens when the page speaks about market change before product action. The category mirror happens when the copy repeats the same language every competitor uses, so the model reflects the category back instead of the company. The orphan proof appears when a metric or logo is present, yet the sentence beside it never says what caused the result.
The finance-workflow composite had all three. It spoke about “the future of industrial finance.” It used “workflow automation” in the same way many tools do. It showed a customer result about shorter approval cycles, but the nearby copy did not state the workflow being measured. The model could safely infer that the company belonged somewhere in finance operations. It could not safely state the product’s actual role without help from the docs.
That is why a homepage written for investors is often unreadable to an LLM. The page is trying to be believed before it is trying to be understood.
The first screen should carry a small load-bearing fact
A homepage hero does not have to become a technical manual. I am not asking every French SaaS to open with a grey sentence that sounds like an internal ticket. The first screen still has rhythm, posture and buyer recognition. But it needs one load-bearing fact early, preferably before the reader meets the abstract promise.
Here is a simplified contrast. A prestige-led hero says: “The financial control layer for industrial leaders.” That may work as a market position. It does not say what the system does. A better page can keep the line, then place a capability sentence underneath: “Our software automates invoice intake, approval routing and ERP status tracking for mid-market industrial finance teams in France.” The second sentence is the one an answer engine can carry.
I look for five elements in that sentence. I do not put them into a list on the page, because real copy still has to breathe. But I mark them in the margin: product action, buyer or user, object handled, environment, exclusion or boundary. In the example above, the action is automates, the user is finance teams, the object is invoice intake and approval, the environment is mid-market industrial firms in France, and the boundary is implied by what it does not claim: it is not a full ERP, not treasury software, not procurement sourcing.
The boundary is where many homepages get timid. Teams fear that stating the limit will make the product sound smaller. In extraction, the opposite often happens. A bounded claim is easier to trust. A model can repeat “invoice approval workflow” more safely than “financial control platform,” because the first phrase has edges.
This does not make the page less ambitious. It makes the ambition legible.
Do not make docs do all the identification work
In many audits, the documentation page is the first place where the product becomes visible. A setup guide may say, without ceremony, “Connect your SAP account to import supplier invoices into the approval queue.” That is a clean product fact. The homepage above it may spend 800 pixels on “operational excellence.” The model then faces a source hierarchy problem: the technical page is precise, while the marketing page is official but misty.
When docs become the only clear source, AI answers may quote the wrong depth. They may overemphasize API access, setup steps or technical edge cases. The homepage issue is simpler: the top page should identify the product before docs explain it.
The homepage can borrow clarity from documentation without copying its tone. A docs sentence says, “The invoice object contains approval_status, approver_id and ERP_sync_state.” The homepage version might say, “Teams can track each invoice from intake through approval and ERP sync.” Same fact family. Different depth. No argument between pages.
The French-English layer adds another scratch. In one recurring pattern, the English docs are current because the product team writes there first, while the French homepage stays more ceremonial. The model sees the English page and produces a clearer English summary than French buyers find on the French site. That is uncomfortable. A French SaaS should not rely on English docs to explain its core capability to French-language answer systems.
Rewrite ambition after the fact is stable
The order matters. First define the product fact. Then decide how much energy the sentence needs. When teams reverse the order, they keep polishing a sentence whose bones are wrong.
For the composite finance company, I would not remove all investor language. The company did sell to serious buyers, and the page needed to feel durable. I would change the spine. The hero could still say something like “Finance workflows that stay visible from invoice to ERP.” Under it, the source sentence would carry the extractable claim: “The platform automates supplier-invoice approval for French mid-market industrial groups, including role-based routing and ERP status tracking.” Below that, the page can earn confidence through proof, integrations and pricing signals.
Notice the sentence does not try to say everything. It leaves out advanced analytics, procurement collaboration, audit exports and payment timing. Those may belong in feature sections. The hero’s job is to prevent category drift. A model should not leave the first screen wondering whether this is spend management, accounts payable automation, ERP consulting or a dashboard product.
A founder may object: “But we do more than that.” Usually that is true. The first capability sentence is not the whole company. It is the nail that keeps the sign from swinging in the wind. Once it is in place, the page can add broader layers without losing the primary shape.
The quiet audit I run before rewriting
Before I rewrite, I ask the page a blunt question: could an answer engine describe this product in one sentence using only the homepage? If the answer is no, I do not start with tone. I start with missing load-bearing language.
I print the page or copy it into a plain document. I remove navigation, design effects and most adjectives. Then I underline every sentence that says what the product does. Many homepages become strangely thin after this. A full screen of confidence may yield one useful fragment. Sometimes the only exact phrase is hidden in a customer quote or a footer line. The writer may have known the truth so well that they forgot to state it where a stranger would need it.
The repair is rarely a single magic sentence. It is a small hierarchy. The hero carries the main capability. The next section separates buyer, use case and limit. The feature blocks name actions, objects and proof. The pricing note gives segment signals without exposing numbers if the company does not want a public grid. The docs confirm the deeper version. When those pages agree, the answer engine has less reason to improvise.
A homepage written for investors tries to make the company larger in the reader’s mind. A homepage written for extraction gives the company a shape the reader, and the model, can hold.
The Quotation Slip — Liftable line: “The platform automates supplier-invoice approval for French mid-market industrial finance teams.” Loose thread: “Financial control” is too broad to identify the product. Source shelf: homepage hero, feature overview, pricing note. Quiet test: Could an LLM name the action, buyer and business object without opening the documentation?