What To Ask Before Rewriting Your Homepage

homepage rewrite is not a writing project.
It is a buyer-language audit.
That is the part teams skip.
The rewrite starts with a doc full of headline options. The founder wants the page to sound bigger. Product wants accuracy. Sales wants objection handling. Marketing wants clarity. Someone wants fewer words. Someone wants more proof. Someone opens competitor tabs and the language starts drifting toward whatever the market already says.
The team is not short on opinions.
It is short on evidence about what buyers actually understood, doubted, compared, repeated, and needed to believe.
If the homepage matters, do not begin by asking, "What should we say?"
Begin by asking, "What did customers need to hear before they were ready to move?"
The homepage is where internal language goes to look polished
Most weak homepages do not look obviously bad.
They look reasonable.
They have a clear headline. A short subhead. A few use cases. Some proof. A product section. A CTA. Maybe a customer quote. Maybe a section that explains how it works.
The problem is not always structure.
The problem is that the language is often internal.
Teams write from what they know:
the category they want to own
the feature they just shipped
the positioning they use in sales
the pain they believe is strongest
the objection they are tired of hearing
the sentence that made sense in a strategy meeting
Buyers do not arrive with that context.
They arrive with a problem, a comparison, a doubt, a budget constraint, an old way of doing things, and a very small amount of patience.
Your homepage has to meet that reality.
Do not ask if the page is clear
"Is this page clear?" is a weak question.
Most people will try to be helpful. They will say yes if the words make basic sense. They will suggest a shorter headline. They will point out a confusing section. They will tell you the page looks good.
That feedback is polite. It is not enough.
The better question is:
What did this page make you believe we do, and what are you still unsure about?
Now the buyer has to reveal the actual interpretation.
Ask:
What problem do you think this is solving?
Who do you think it is for?
What would you expect to happen after using it?
What part felt specific?
What part felt vague?
What would you need to see before taking the next step?
The goal is not approval.
The goal is to see whether the page creates the right belief.
Ask what language they would use before knowing your category
Your homepage language can be accurate and still miss the buyer.
That happens when the team describes the solution in category language while the buyer still thinks in problem language.
The team says:
"AI voice interviews for decision-ready evidence."
The buyer might say:
"We keep making roadmap calls from vague customer comments."
Both can be true. But they do different jobs.
Ask:
Before you saw a product like this, how would you describe the problem?
What words would your team use for this situation?
What would you search for if you were trying to solve it?
What phrase would make someone on your team recognize the pain quickly?
Which words on this page feel like our language, not yours?
This is where homepage copy gets sharper.
Not by becoming louder. By becoming closer to the buyer's actual sentence.
Ask what they compared you against
A homepage is not read in isolation.
The buyer is comparing you before they can fully explain the comparison.
They might compare you to:
a spreadsheet
a manual interview process
a call recording workflow
a feedback form
a research consultant
a customer success motion
doing nothing until the next planning cycle
If you do not know the comparison, you do not know what the page needs to explain.
Ask:
What did this page make you compare us against?
What felt familiar?
What felt different?
What alternative would your team consider instead?
What would make us feel more credible than that alternative?
What would make doing nothing feel risky?
This tells you whether the page should spend more energy on the problem, the product, the proof, the use case, or the cost of staying with the old way.
Without that evidence, teams tend to over-explain the product and under-explain the decision.
Ask what almost stops the buyer
Message testing should start with the objection.
Not because objections are negative. Because objections tell you what the buyer still needs to believe.
Ask:
What almost stopped you from taking this seriously?
What claim did you not fully believe?
What felt too broad?
What felt too specific?
What risk would your team worry about?
What would your boss, customer, or team push back on?
What proof would reduce that concern?
For Lemma, a buyer might wonder:
Will people actually answer by voice?
Will the follow-ups be useful?
Will the report be credible enough to share?
Is this replacing interviews or helping us run more of them?
Is this for product, CX, marketing, or all of them?
Those questions are not copy problems only.
They are buying problems. The homepage has to help resolve them.
Ask what proof belongs on the page
Weak proof says, "Trust us."
Useful proof answers the doubt the buyer already has.
Before rewriting the proof section, ask:
What claim on the page needs proof most?
What would make that claim credible?
Would you trust a customer quote, sample report, transcript excerpt, use case, workflow, metric, or comparison?
What would you need to show another person internally?
Which proof would make the next step feel low-risk?
This prevents the page from collecting decorative credibility.
A quote is not proof if it does not answer a doubt. A metric is not proof if it does not connect to the decision. A logo is not proof if the buyer still cannot explain why the product matters.
The page does not need more proof.
It needs the right proof in the right place.
What the homepage feedback report should answer
A homepage research report should not say, "The headline needs to be clearer."
That is still too vague.
The report should answer:
What did buyers think the product does?
Who did they think it is for?
Which problem did they recognize fastest?
Which words felt natural to them?
Which words felt like company language?
What did they compare the product against?
Which objections appeared before interest?
Which claims needed proof?
Which quotes should shape the headline, subhead, proof, and CTA?
What should change before the rewrite moves into design?
The output should give the team a sharper homepage decision:
what to say first
what to cut
what to prove
what to explain
what objection to answer earlier
what buyer language to keep
That is more useful than another round of headline voting.
A homepage rewrite interview guide
Use this before rewriting a homepage, landing page, campaign page, or sales page.
What do you think this page is saying we help you do?
Who do you think this is for?
What problem does it seem to solve?
Which sentence felt closest to how you would describe the problem?
Which sentence felt vague or internal?
What would you compare this against?
What would almost stop you from taking the next step?
What claim needs more proof?
What proof would you trust?
What would you need to show someone else before recommending this?
If you rewrote the first sentence in your own words, what would it say?
Do not use these questions to make the buyer write your copy.
Use them to find the belief your copy has to create.
The point
Your homepage should not be a polished version of the team's assumptions.
It should be built from evidence about what buyers recognized, misunderstood, doubted, compared, and needed to believe.
Lemma helps teams run adaptive voice interviews before the rewrite, then turn those conversations into transcript-grounded themes, buyer quotes, message risks, and recommended next actions.
Start with the Landing Page Feedback Interview template before the next homepage rewrite becomes another internal debate about words.
