Use Search Console to find a question your app page needs to answer more clearly. Start with the query and the page shown for it, then inspect the content. A low click count alone does not tell you what to rewrite, especially when the site has little data.
I make AppFound, a NaguBuilds project. This is a review method for an app website, not a report of AppFound's traffic or a feature available inside AppFound.
Record the report you are actually reading
Open the relevant Search Console property and its Search results performance report. Record the date range, search type and any country, device or page filters before comparing numbers.
Use complete dates for the review. Google's data guidance says the newest data may be preliminary and marked with a dotted line. A partial current day is a poor comparison for a complete earlier day.
If the report is still processing, cannot be loaded or has no usable rows, record that state. Do not translate an unavailable report into zero demand. You can still correct a broken link or outdated product fact, but that is a content-quality fix rather than an inference from search performance.
Connect one query to the page Google showed
Google's common tasks guide describes this sequence: open Queries, select a query to filter the report, then open Pages to see the associated URLs. Keep the query filter in place while inspecting the page rows.
Choose a query that relates to a real job your app or article can help with. Read the phrase as a person's question. Are they looking for instructions, a specific app, a comparison or a feature your product does not offer?
Then open the associated public page. Check whether its title, opening answer and relevant section deliver that task. If the page is already useful, a small number of impressions does not supply a reason to change it.
Google defines CTR as clicks divided by impressions and average position as an aggregate in its performance report overview. Neither is a universal score for your writing. A tiny denominator can make CTR swing sharply; an average position is not a promise that every searcher saw one fixed rank.
Write a page decision note
- Property, date range, search type and filters:
- Exact observed query:
- Page shown for that query:
- Clicks, impressions, CTR and position as displayed:
- Missing or preliminary data:
- Reader's likely task:
- What the current page actually answers:
- Specific mismatch, if one is visible:
- Product fact or other evidence needed before editing:
- Decision: improve this page, investigate further or leave it unchanged:
- Change date and a comparable period to review later:
Keep a saved report or export with the note. If a displayed value is unavailable, preserve that fact in your working record. Google's data guidance warns that values shown as unavailable can become zeros in an export.
Turn a real gap into a bounded edit
Consider a fictional timer app. An observed query asks whether work and break intervals can have different sounds. The product page describes custom sounds but never explains whether that means one sound for the whole timer or separate choices.
First verify the actual behavior. If the released app supports separate sounds, add a direct answer and the relevant setup instructions. If it does not, do not write the feature into the page to match the query. If no such query appears in your report, this remains an editorial question, not an observed search opportunity.
Record the change and revisit the same page/query with comparable filters and complete periods. Google's common tasks guide notes that other events can affect performance, so a later increase does not by itself prove your edit caused it. Keep the observation and your interpretation separate.
For questions about what an AI assistant actually recommends, use the separate AI recommendation audit worksheet. Search Console's Google report does not supply a saved ChatGPT answer.
AppFound's public page currently offers a prelaunch waitlist and labels its report as example data. You can join the waitlist there.