Product teams often know too much to notice what a page leaves unsaid. The reviewer should temporarily set aside the demo, the pitch deck, and the conversations that normally fill the gaps. Can the page stand on its own for the audience it claims to serve?
This review focuses on clarity and evidence. It can identify material worth improving before a broader AEO assessment, but it is not a prediction of whether an AI system will cite the page.
Use six reader questions
| Question | Evidence on the page |
|---|---|
| What is it? | A plain-language product description |
| Who is it for? | A specific audience and situation |
| What does it do? | Capabilities tied to an observable workflow |
| What does it require? | Inputs, responsibilities, prerequisites, and scope limits |
| Why should I believe it? | Support for material claims |
| What happens next? | A clear, accurately described action |
Record evidence rather than a vague grade
For each question, mark the answer clear, incomplete, absent, or not applicable. Quote or link the relevant section in your working notes. A label such as “weak messaging” is hard to improve; “the page never identifies who supplies the initial data” is a specific problem.
Use a second reviewer for claims about technical requirements or delivery scope. An editor can identify ambiguity without knowing the correct answer. The subject-matter owner must supply that answer. Do not use polished language to cover a fact the business has not settled.
Prioritize the consequential gaps
Not every omission deserves another section. Start with uncertainty that could cause a poor-fit purchase, an incorrect expectation, or a failed next step. Then improve supporting details that make evaluation easier. If the answer is extensive, a linked implementation guide may work better than doubling the product page’s length.
Repeat the review after a major product or commercial change. Keep the previous findings and note which ones were resolved. This creates a record of progress grounded in the page itself, rather than a score that changes without explaining why.
For the next implementation step, use Writing product explanations that stand on their own.
