GEO means generative engine optimisation: work intended to improve visibility in AI-generated search answers (Google for Developers). For a content team, the practical question is what to change when a reader can receive an answer before visiting your website. My response has been to build clearer answers, source review and a way to record observations into LocAlign, the content tool I developed.
There is enough experience in that work to explain the process. There is not yet evidence that it has increased my citations, traffic or conversions. That distinction matters. Here I explain how AI-powered search affects the publishing problem, which practices I have implemented, and how I would test their results. My AI discoverability guide covers the accompanying technical checks.
How AI-powered search is changing discovery
AI-powered search adds another place where readers can encounter information from a website. A publisher therefore needs to consider the usefulness of an answer and the visits it generates separately. Being referenced does not automatically mean someone will arrive on the page.
Google's current guidance treats optimisation for its generative search features as part of SEO (Google for Developers). Its AI features documentation says that special schema or new AI text files are unnecessary (Google for Developers). I read this as a reason to improve the underlying content rather than build a separate production line for supposed GEO tricks.
There is evidence of a change in clicking behaviour, although its scope matters. Pew Research Center analysed browsing data from 900 US adults in March 2025. Traditional-result clicks followed 8% of Google search visits with an AI summary, compared with 15% without one. The researchers collected the associated results pages in April 2025 (Pew Research Center).
This was an observational study of a particular panel and period, with results pages reconstructed later. It does not establish that AI summaries caused a fixed percentage loss for every publisher, or describe every search product today (Pew Research Center). It does give content teams a reason to measure visibility and visits separately. My operational response is to make a page useful enough to consult in full, with evidence, examples and decisions that go beyond a generic summary.
Why measuring AI visibility is harder than it looks
Measurement starts with identifying what each source of data actually records. Google Search Console's Generative AI performance report shows impressions in AI Overviews and AI Mode, with page, country, date and device dimensions (Google Search Console Help). It is useful evidence about Google's features. It cannot establish what happened in ChatGPT Search, Perplexity or Gemini Apps, or whether an appearance produced a business outcome.
Eligibility also needs a separate check. Google's current guidance requires an indexed, snippet-eligible page and participation in Search generative AI features (Google Search Central). The participation control can include or exclude site content; child properties may inherit their parent's setting (Google Search Console Help). A missing report can reflect insufficient impressions or exclusion, so absence of a chart alone is not a diagnosis (Google Search Console Help).
For an editorial team, I would keep distinct records of mentions, exact page citations, referral visits and meaningful actions on the website. A brand mention is not a recommendation. A citation is not a visit. A visit is not a conversion. These observations can inform the same review, but they answer different questions.
The workflow I built in LocAlign and what each check actually tells me
LocAlign connects the brief, section plan, grounded research, evidence review, drafting, quality checks, human editing and image production. The important change is that a writer receives a purpose and reviewed evidence before producing the article. The editor can return to an earlier stage when the material is inadequate.
I start with the reader's decision: what should someone be able to understand or do after reading? That guides the section plan. Research then builds a source list. The app distinguishes sources matched to search evidence from URLs merely supplied by the model and claims without a source. Those labels help direct review; an editor still has to inspect the original passage and decide whether it supports the wording.
Completed drafts have an AI search tab. It surfaces the opening paragraph, visible structure, source-review status and the presence of supplied expertise. It also gives the editor candidate questions to review. It cannot establish that an opening answers the question well, that an author's experience is authentic, or that all useful questions have been covered. Those remain editorial decisions.
My aim is to make these decisions visible and repeatable. A clear opening should help a reader understand the answer; a relevant comparison should help them decide. I do not present either as a proven way to win an AI citation. Keyword metrics in the current app are synthetic planning inputs, so I do not use them as measured search demand.
A strong quality score still needed an editor
One real test of an app-generated discoverability article showed why human review remains necessary. The draft received a strong score from the general automated quality checks. It still contained unsupported explanations of AI model internals, claims that formatting causes citation, and arbitrary numerical thresholds.
The score did not create those errors. It failed to catch them. The checks examine specified properties such as headings, links, citation references and traceable figures; they cannot independently establish the truth of every sentence. Calling a draft well organised would not settle those factual questions either.
Manual source review and rewriting were required before publication. That is a useful operational lesson from an actual drafting test, rather than evidence about search performance. I use the checks to focus attention, then apply the claim-by-claim fact-checking method before accepting the copy.
How the observation journal works and what it can't prove
I added a manual observation journal so the app can store evidence of what an AI search service actually returned. It supports ChatGPT Search, Perplexity, Google AI Overviews and Gemini. Each entry records the exact query, engine, market, baseline or follow-up phase, answer or no-answer outcome, brand mention, cited URLs and response evidence. Its UTC timestamp records when the entry was saved; the evidence should also note when the query was run if those times differ.
Exact page citations are counted separately from mentions. That prevents a response that merely names the brand from being counted as a link to the target article. A no-answer entry is retained rather than quietly dropped from the sample.
This is a recording facility, not an automatic monitoring service. It does not run queries, measure referrals or attribute conversions. It also cannot make a small query sample representative of an entire engine. The journal has its own CSV export and separate browser storage, so it needs a separate backup from the main workspace.
A practice to evidence table for this GEO approach
This is how I separate the practices implemented in LocAlign from checks that belong on the published website. Documented requirements and editorial judgement both matter, but neither is a measured performance result.
| Practice | Evidence or purpose | What remains to check |
|---|---|---|
| Supply a reader decision and genuine first-hand notes | Implemented editorial inputs; Google recommends useful, distinctive content (Google Search Central) | The editor must check that the draft uses the experience accurately |
| Review source passages and draft openings | Implemented source list and AI search review | These controls do not establish factual completeness or citation probability |
| Record mentions and exact page citations separately | Implemented manual observation journal | A saved observation does not measure engine-wide visibility or business impact |
| Check live indexing, snippets and Google participation | External eligibility requirements documented by Google (Google Search Central) | Eligibility does not guarantee appearance |
| Review search crawling separately from training choices | OpenAI distinguishes OAI-SearchBot from GPTBot; Perplexity documents PerplexityBot for search (OpenAI; Perplexity) | Inspect the site's actual crawler and hosting settings; access does not guarantee citation |
| Measure clicks separately from citations | Pew observed clicks on AI-summary source links in about 1% of visits with a summary in its study (Pew Research Center) | Measure the outcomes of our own content rather than importing that rate as a forecast |
Running a small baseline and follow-up test yourself
Download the AI search observation starter kit
You can use this resource without a LocAlign account. Download the starter kit ZIP for a blank CSV, an illustrative example and a quick-start guide. You can also download the files separately:
- Blank AI search observation template (CSV)
- Fictional completed example (CSV)
- Quick-start instructions and field guide (TXT)
The template contains no recorded results. The separate example is entirely invented, uses an example.org page and is labelled illustrative. It does not report observations of my website, LocAlign or any engine. Keep it separate from your real records.
Open the blank CSV in Excel, Google Sheets or another spreadsheet editor. Add one row for each exact query, engine and observation time. Record the market and language, the actual UTC query time, relevant engine settings, the brand and target page, the answer outcome and supporting evidence. The guide explains every column. The files are standalone and do not automatically import into LocAlign.
For example, a response might name a brand without linking to its target page. Record Brand mentioned = yes and Target page cited = no. A link to another page on the same site does not count as a citation of the target page. This is an explanation of how to record an outcome, not a result from a search we performed.
Use no-answer when the relevant AI answer does not appear, including a Google results page without an AI Overview. Use unavailable when you could not inspect a response because of failed access or an error. Keep both cases, and leave mention and citation fields as n/a. If an answer appears but its links cannot be inspected, record unknown rather than guessing.
Start with a fixed set of questions relevant to your readers and collect a baseline before changing the page. Repeat those exact questions with comparable settings for follow-up observations. Compare matched groups by engine and market, and describe the sample and any missing evidence. The CSV does not measure clicks or conversions; check website analytics separately.
The next step I propose is a small, repeatable baseline and follow-up exercise. It would test the process without pretending to prove a ranking formula.
- Define the scope. Choose a fixed set of reader questions, target pages, engines and markets. State why the questions matter; model-generated suggestions are hypotheses to validate.
- Capture the baseline. Run the queries and save response evidence, the exact cited URLs and no-answer cases. Note the query time and relevant settings, such as language, location and signed-in state.
- Make a bounded editorial change. Record what changed on the page and when it was published. Confirm the live content and relevant technical eligibility before interpreting a later result.
- Repeat comparable observations. Use the same questions and settings for follow-up checks. Repeated observations are more informative than selecting one favourable answer.
- Review outcomes separately. Examine available provider reporting, referral visits and the actions that matter to the website. Record gaps in attribution instead of treating every mention as value.
Even this comparison would have limits. Changes in engine behaviour, competing pages and audience conditions can affect the result. A before-and-after difference would be a signal to investigate, not proof that our edit caused it. I would keep the original evidence so another reviewer can assess that interpretation.
What I still don't know
I have implemented a workflow for preparing and reviewing content, plus a journal for recording AI search observations. I have not established a citation uplift or traffic increase from those practices. The distinction gives the next test a clear purpose.
For a small content team, my recommendation is to start with one useful page and one explicit reader decision. Preserve genuine expertise, check the supporting sources and make the answer easy to follow. Then measure what happens. GEO becomes a more useful discussion when a team can show both the work it changed and the evidence it still needs.