How to Write Landing Page Hero Copy With AI Without Inventing Claims
Above the fold you get one headline, one line, and one button — and the pull is to spend all three on how good the product is, or on a metric nobody can back. Here is how to write landing page hero copy with AI: an outcome the reader wants, grounded in the facts you actually have.
Get the Landing Page Hero Copy PromptOne headline, one line, one button — spent on the wrong thing
Above the fold you get three moves: a headline, a line under it, and a button. That is the whole hero, and it is the most-read and least-forgiving copy on the page — the part a visitor decides on before they scroll, if they scroll. So it is worth noticing what those three moves get spent on when the copy comes out weak, because it is almost always the same two mistakes.
The first is spending the headline on the product instead of the reader: "the complete purchasing platform," "a smarter way to work," a sentence about what the company built rather than what the visitor gets. It is accurate and it converts nobody, because the person reading it is not asking what you made — they are asking what changes for them. The second is worse: reaching for a number to sound credible — a percentage, a customer count, a "trusted by thousands" — that nobody actually measured. It reads well, and the visitor who clicks on it and finds it untrue does not come back.
Both failures get more likely, not less, when you hand the job to an AI, because a model will happily produce a confident, polished hero full of outcomes it invented and proof it made up — in exactly the same fluent voice it uses for the true parts. This guide is about the opposite discipline: building a hero that says what the reader gets, in words traceable to facts you actually have, and marking the proof you do not have instead of inventing it.
What the AI writes from, and what it cannot see
The hero the AI drafts is built from what you paste and nothing else: the product truth, the audience, the problem, the outcome, the differentiator, whatever proof you actually have, and the real next action. Everything past that list is invisible to it. It has no window into your site or your analytics, no read on who lands on the page or where they came from, no view of what a competitor says on theirs — and it does no research to find out. So the current conversion rate, the traffic source, the thing the visitor already saw: none of it reaches the draft.
Which means every persuasive-sounding fact in the draft came from you or was invented, and the model cannot tell you which. A hero that says "trusted by 4,000 teams" is either repeating a number you supplied or fabricating one, and the copy looks identical either way. It publishes no page and it runs no A/B test, so it cannot tell you whether the draft will convert — a claim that it will is a guess with no data under it. The claims and the CTA are yours to confirm against what is real, and there is no conversion, revenue, or SEO guarantee attached to any of it.
So the useful frame is narrow and it is the whole method: give the model real inputs, make it build the message from them, and hold the line on proof — because the one thing a hero cannot survive is a reader acting on a promise that turns out to be false.
Step 1: Gather the real inputs before you write a word
A hero is a compression of things you have to know before you can compress them, so assemble them first. What is the page for; who specifically is the primary reader and what state are they in when they land — the trigger that brought them; the problem in their words; the outcome they want; the plain truth of what the product is and the one thing that makes it the right choice over the alternative or over doing nothing. Then the two that discipline everything downstream: the proof you actually have, and the one real next action.
The proof input is the one people fudge, and it is the one that matters most. Write down only proof that exists — a real metric, a named integration, a genuine guarantee — and, just as important, the claims you must not make. If you have no customer count and no time-saved figure, that is a fact about your inputs, not a gap to paper over, and naming it now stops the model from filling it later. A hero built on real-but-modest facts outperforms one built on impressive-but-invented ones the first time a reader checks.
Name the real next action too, because the button has to point somewhere that exists. "See an example," "book a demo," "start a trial," "build your first report" — whatever the product actually offers next. A CTA that promises a step the product flow does not have is a broken promise the visitor discovers one click in.
- Collect page goal, audience + trigger, problem, outcome, product truth, and the single differentiator before writing.
- Proof is an input: list the proof you have, and explicitly list the claims you may not make.
- No proof is a fact to state, not a hole to fill. A modest true line beats an impressive invented one.
- The CTA must be a real next step in the product flow — not an action the product cannot actually offer.
Step 2: Choose a headline direction, do not reach for a formula
There is no one headline shape that always wins, so the move is to draft a few genuinely different directions and choose, rather than pour the facts into a template. The useful directions are distinct strategies, not rewordings: outcome-led (name what the reader gets), problem-led (name the pain they came with), category-led (name what kind of thing this is), audience-led (name who it is for), and mechanism-led (name the specific thing that makes it work). The same product produces real alternatives across these, and seeing them side by side is how you find the angle that fits your audience instead of the first one the model reached for.
Every direction, whichever you pick, has to pass the same short test: can a reader tell what it is, who it is for, and what changes; is the claim grounded in the facts you supplied; and does it match what the CTA promises. A headline that sounds great but leaves the visitor unsure what the product does has failed the first part; one that promises a transformation the CTA cannot deliver has failed the last. The test is what separates a strong direction from a nice-sounding one.
This is also where the empty verbs get caught. A headline built on "transform your workflow," "revolutionize how you work," or "unlock your potential" is reaching for motion without saying what moves — and a model reaches for them constantly, because they sound like hero copy. They are not wrong because the words are banned; they are wrong because they carry no information a reader can act on. Prefer the concrete noun and the specific verb: what, exactly, does the reader see or do or get.
- Draft several distinct directions — outcome / problem / category / audience / mechanism — and choose, do not template.
- Every direction passes one test: clear what/who/what-changes, grounded in supplied facts, matched to the CTA.
- A headline that sounds strong but hides what the product does has failed the test, however good it reads.
- Empty motion verbs say nothing a reader can act on. Prefer the concrete noun and the specific verb.
Step 3: Build the hierarchy — headline, support, button
The hero is three lines doing three different jobs, and the draft is stronger when each does only its own. The headline names the outcome — the one thing worth reading if the visitor reads nothing else. The supporting line makes it concrete: who it is for and how it works, in one sentence that turns the headline's promise into something the reader can picture. The button is the next action, stated plainly. When one line tries to do two jobs — a headline that also explains the mechanism, a support line that also sells — the hero blurs, and blur is what makes a visitor bounce.
The most common way the hierarchy goes wrong is feature-stuffing the top of the page: a headline or support line that lists what the product has — the import, the engine, the dashboard, the export — instead of what the reader gets from it. Features belong on the page; they belong below the fold, under a benefit that explains why they matter. The hero is where the outcome goes, because the outcome is what earns the scroll to the features.
Keep the CTA continuous with the promise above it. If the headline offers to show the reader something, the button says "see an example," not "sign up now" — the two have to feel like the same motion, or the click asks for more commitment than the hero earned. A secondary CTA is worth adding only when there is a genuinely lower-commitment path ("see how it works" beside "start a trial"); if there is not, one clear button beats two competing ones.
- Three lines, three jobs: headline names the outcome, support makes it concrete, button states the next action.
- Do not feature-stuff the hero. Features earn their place below the fold, under the benefit that explains them.
- The CTA must continue the headline's promise — same motion, not a bigger ask than the hero earned.
- Add a secondary CTA only for a real lower-commitment path; otherwise one clear button beats two.
Step 4: Hold the line on proof
This is the step the whole guide is built around, because it is the one an AI will quietly break. The trust element of a hero — the metric, the logo row, the "trusted by" line — is only worth having if it is true, and a model asked to write one will invent a customer count, a conversion lift, a time saved, a "best-in-class," a testimonial, an integration, a certification, or a free-trial condition, and it will word every one of them exactly like the claims that happen to be true. None of those may appear unless you supplied them.
When you have no proof, you have three honest moves and inventing one is not among them. Leave the proof slot empty and let the hero stand on a clear outcome. Write a narrower claim that is fully true — a capability you do have rather than a result you cannot cite. Or mark the slot explicitly — "[needs evidence: real customer count]," "owner confirmation required" — so the gap is visible to whoever fills the page and cannot be quietly closed with a plausible number. A visible gap is a task; an invented number is a liability that ships.
The forbidden list is worth stating plainly to the model, because its instinct is to be helpful and a fabricated proof point feels helpful right up until a reader checks it: no customer count, no percentage, no hours-saved, no revenue figure, no market-leadership claim, no superlative you cannot back, no quotation you were not given, no integration or certification or guarantee that was not supplied. If it was not in the inputs, it does not go in the hero.
- The trust element is worth having only if it is true. A model will fabricate one in the same voice as the real copy.
- No proof, three honest moves: leave it empty, narrow the claim to a true capability, or mark it needs-evidence.
- A visible gap is a task for whoever fills the page; an invented number is a liability that ships.
- If a number, quote, integration, cert, or guarantee was not in the inputs, it does not go in the hero.
Step 5: Verify against the facts, then hand off the rest of the page
Before the hero is done, run it against the inputs one line at a time. Can every claim be traced to a supplied fact — the outcome to the real outcome, any number to a real number, the differentiator to the real one? Is the CTA a step the product actually offers? Does the mobile version, where the support line gets shorter, still carry the meaning rather than dropping the part that made it true? Is anything in the hero a feature that should have been a benefit? The check is quick and it is where a fabricated claim that slipped past the drafting gets caught.
Then stop, because the hero is one artifact and the page is several. The benefits section that turns features into outcomes, the proof and risk-reversal and objection-handling that build trust further down, the pricing, the testimonials — those are separate pieces with their own shapes, and folding them into the hero is how the first screen gets crowded and slow. The hero earns the scroll; the rest of the page is what the scroll leads to.
The same goes downstream: once you have two hero directions you genuinely cannot choose between, comparing them is its own step, not something to resolve by argument in the draft. Write the hero to be strong and grounded; let the sections below it and the comparison after it do the jobs that are not the hero's.
- Verify line by line: every claim traced to a fact, the CTA real, the mobile version still true, no feature masquerading as the hero.
- The hero is the first screen only. Benefits, proof, objections, pricing, and testimonials are separate pieces.
- Do not resolve two strong directions by arguing in the draft — comparing finished variants is its own downstream step.
- A grounded hero earns the scroll; the rest of the page does the work the hero should not.
Common mistakes
The ways a hero comes out polished and wrong, most of them because the model optimized for sounding good over being true:
- Describing the product instead of the outcome. "The complete purchasing platform" tells the visitor what you built, not what they get, and what they get is why they stay.
- Inventing proof to sound credible. A customer count, a percentage, or a "trusted by thousands" that nobody measured reads well and breaks the first time a reader checks it.
- Feature-stuffing the headline. The import, the engine, the export are real and they belong below the fold — the hero is for the outcome those features produce.
- Reaching for empty verbs. "Transform," "revolutionize," "unlock" carry motion and no information; a reader cannot act on a promise that names nothing.
- A CTA that promises a step the product does not have. If the button says "start free trial" and there is no trial, the visitor finds out one click in.
- Letting the mobile version drop the true part. When the support line shortens, the clause that grounded the claim is often the first thing cut — and then the short hero says something the product does not do.
- Turning the hero into the whole page. Benefits, testimonials, pricing, and objections crowding above the fold bury the one line the visitor actually needed first.
A worked example: a hero for a purchasing workspace
Here is a hero written for a fictional B2B product with a deliberately modest fact sheet — no metrics, no customers to name, one genuine differentiator — because that is the case where the temptation to invent is strongest and the discipline matters most.
Watch two things in particular: the metric-led headline gets rejected not because it reads badly but because it fabricates a number and a capability the product does not have, and the proof line stays empty rather than inventing a trust cue the facts cannot support. Every line that ships traces back to a supplied fact, and where there was nothing to claim, nothing is claimed.
A hero from a modest fact sheet: five headline directions with two rejected for describing the product and for inventing a metric, a proof slot left as needs-evidence rather than faked, and every shipped line traced back to a supplied factTHE FACTS YOU WERE GIVEN (a fictional B2B product):
product : a purchasing workspace that lines up supplier price lists
side by side
audience : a purchasing person at a ~30-person manufacturer who today
compares supplier quotes by hand
trigger : three suppliers just sent updated price lists -- CSV and
spreadsheet files -- and they have to find what changed and
who is cheapest per item
problem : matching the SAME item across differently-formatted lists is
slow and error-prone in a spreadsheet
outcome : see the same items lined up across suppliers, no hand-matching
different : it MATCHES the items for you; you stay in control of the call
proof : NONE. no customer count, no hours-saved figure, no cost %.
and a hard rule: it does NOT decide the purchase for you.
real CTA : see an example comparison workspace
FIVE HEADLINE DIRECTIONS (compared, not formula-filled):
outcome-led "See every supplier's price for the same item, side by
side." -> clear, grounded
mechanism-led "Match the same items across every supplier's price list."
-> grounded
problem-led "Stop hand-matching supplier price lists in spreadsheets."
-> leads on the pain
category-led "A purchasing workspace for supplier price lists."
-> REJECTED: describes the product, not what changes for
the reader. Says what it IS, not what they GET.
metric-led "Cut purchasing costs 20% with automatic supplier
comparison."
-> REJECTED, twice over: it invents 20% (no proof), and it
promises a cost cut the product does not deliver -- it
lines the prices up; the buyer decides and negotiates.
A fabricated number bolted to a result it never produces.
THE HERO THAT SHIPS:
headline : See every supplier's price for the same item, side by side.
support : Upload the price lists your suppliers already send. The
workspace matches the same items across
them, so you compare prices without lining up rows by hand --
you review every match and make the call.
primary : [ See an example comparison ] (the real next step)
second : none. the facts supply one real next step and no lower-
commitment path -- so one clear button beats inventing a second.
proof : none supplied, so none invented. The social-proof slot is left
as [needs evidence: real customer count or integration list].
The only true trust line available is a capability, not a
metric: "Works from the CSV and spreadsheet files your
suppliers already send."
EACH LINE, TRACED BACK:
"same item, side by side" <- outcome + differentiator (matching)
"the files they send" <- supplied fact (CSV + spreadsheet lists)
"you review... make the call" <- the hard rule (no auto-decision)
"See an example comparison" <- the real CTA, verbatim
nothing in the hero claims a number, a customer, or a speed. There was
none to claim.
MOBILE (meaning kept, length cut):
headline : Compare every supplier's price, item by item.
support : Match the same items across the files your suppliers send
-- you review and decide.
primary : [ See an example ]
A FEATURE-HEAVY DRAFT, FIXED:
before : "Bulk CSV import, fuzzy item-matching engine, multi-supplier
grid, exportable tables."
after : "See what each supplier charges for the same item, without
matching rows yourself."
the features are real; the reader does not buy features, they buy the
afternoon they get back. Lead with the outcome; the features can wait
for the section below the fold.
A DRAFT REJECTED ON A FABRICATED CLAIM:
"Save 12 hours a week and cut costs 20%."
-> rejected. No hours-saved figure and no cost percentage exist in the
supplied facts. It reads well and it is not true, which is the worst
combination a hero can have -- the reader who acts on it and finds it
false does not come back.
LEFT TO THE REST OF THE PAGE (not this artifact):
the benefits section, the proof / risk-reversal / objection FAQ, the
pricing, the testimonials, and comparing two finished hero variants --
each is its own piece, below the fold or downstream. The hero is the
first screen and the first promise, and that is all it is here.Where this fits in NewPrompt
The Landing Page Hero Copy Prompt is the starting point because it already carries the discipline this guide is about: it asks for the product, the audience, the problem, the positioning, and — the load-bearing slot — the proof you actually have and the claims you must not make, and its own rule is to mark a missing proof point as needs-evidence rather than invent it. You fill those slots with your real facts and it returns a hero draft. It is built with the Markdown Output Builder, which assembles the prompt in your browser and runs nothing; what comes back is prompt text you run in your own AI tool, and the claims are yours to confirm.
The hero is one section of a page, and the rest is deliberately not this artifact. The Landing Page Benefits Copy Prompt is where the features you kept out of the hero become outcomes, below the fold. The Landing Page Proof & Objection Copy Prompt is where the trust layer — social proof, risk reversal, the objections a buyer raises — gets written, using only real proof, which is the same discipline the hero holds. Naming these keeps the hero doing the hero's job and nothing else.
Downstream, when you have two hero directions you cannot choose between, the Landing Page CTA & Hero Variant Comparison Prompt scores them before you commit — a different job from writing one. Zoomed out, all of this is the copy stage of a larger build: the AI Landing Page Copywriting Workflow runs from the value proposition through the hero and benefits to the objection-handling and the variant test, and drafting the hero is its second step; a whole site is the Build a Company Website With AI path, where the copy is one stage among structure, pages, and launch. The hero is the first promise the page makes — and the only rule that outranks writing it well is not making a promise the product cannot keep.