AI search optimization: what the machine may do before it names anyone
AI does not rank, it selects: it lifts out a few paragraphs and decides whether to say your name next to them. This article walks through the steps of that decision and shows which of them you can influence.
Published ·

In search optimization, a ranking position can have direct value. Ten results appear, and even the seventh place can sometimes bring a visitor. An AI answer, however, usually has room for fewer names: often only two or three fit, and the buyer may never learn about the rest. There is no second page to be found on either.
AI search optimization looks at how your company can become one of those names. This article presents three observations, each backed by measurement.
The first is that the machine's decision can be broken into seven consecutive stages, each of which can be influenced differently. The second suggests that a large part of the work done on a website may be structural, because the machine often quotes paragraphs rather than whole pages. According to the third measurement, Hungarian language marking, the much-discussed lang="hu-HU", probably matters less than is commonly assumed.
What AI search optimization is, and what does not belong here
The field uses three names for this area. Each refers to a different job.
AEO aims for a featured answer to be built from your own text. GEO deals with the case where the engine assembles an answer from several sources and then selects whom to name in it. KEO refers to what the model may know about you from its training, without searching.
In this article, AI search optimization is not a separate, fourth area. We use it as the plain-language collective name for the first two. The term is typically searched for by people who already know search optimization but may not yet have come across the name GEO.
It is worth starting with what has probably not changed. The machine has to find the text, be able to read it, and recognise that it is about your company. Crawlability, server-side content and unambiguous identification may therefore matter on AI surfaces as well.
One significant difference has appeared nonetheless. Previously there was a single, checkable ranking to work with, whereas an AI answer may be assembled from at least two kinds of source: what the model learned about you during training, and what it finds while composing the answer. The two results can differ. In our measurements this happened regularly.
When and in what way may a search engine optimize?
This process is easy to misread. The machine's decision can be broken into seven stages, and weeks or even months may pass between some of them. If the intervention happens at the wrong point, a well-built website may still fail to produce a mention by name.
First you have to let the robot in
This stage may decide whether the machine can access your website at all.
The robots.txt file does not let you allow or block a single robot type. Three groups are worth accounting for, and they may serve different purposes:
- training robots (GPTBot, ClaudeBot, Google-Extended) may reach material that later appears in the model's training;
- search robots (Googlebot, Bingbot) collect content for the index, from which the machine may select while composing an answer;
- answering robots (OAI-SearchBot, PerplexityBot) may fetch the page directly for the answer.
One of our own measurements provides an example. A Hungarian trade magazine blocks GPTBot, ClaudeBot and Google-Extended, while allowing OAI-SearchBot and PerplexityBot. It therefore restricts training-related access but not the fetch needed for answering. An article published there probably will not enter the model's training material, yet it may still be used when searching.
Two details are worth clarifying separately. There is no robot called Gemini or AIO. Google AI Overviews may draw on content reached by Googlebot. Google-Extended is a setting with which you can control whether Gemini may use your content for training.
After that the page may enter the index
The answering layer typically does not work directly from the whole internet. It may use an index. If the page is not in it, its content probably will not become one of the possible sources.
This is worth checking engine by engine, because their behaviour can differ. Google indexed all six of the Hungarian pages examined, while Bing indexed none from the same language branch. The server, the HTML, the robots.txt and the sitemap were identical. According to the measurement, Bing discovered the pages and still did not fetch them over twenty days.
It is still often said that ChatGPT's search is built on Bing. That statement may have reflected the situation in 2024. According to later measurements, the Bing overlap of pages cited by ChatGPT fell from 87 percent to 26 and then to 8 percent by the summer of 2025, while the Google overlap rose from 12 to 33 percent. The Bing index may therefore still be useful for debugging, and it may matter because of Copilot, but on its own it probably does not explain general AI visibility.
When asked, the machine may rewrite your question
This is discussed less often, although it can have a significant effect on source selection.
When someone asks an AI a question, the machine does not necessarily search for the original question. It may break it into several background questions and launch searches from those. The field calls this query fan-out, and Gemini also shows which search terms it used.
In our stored data, 233 answers carried 1034 background questions, of which 863 were distinct. On average 4.44 background questions fell to one answer, and the highest value was 20. The measurement showed two phenomena that may also matter when selecting keywords.
The machine may use different words. From the question "which is the best AI visibility agency in Hungary", four background questions were produced, three of which no longer contained the word "visibility"; the system used the phrase "AI marketing" instead. On a larger sample, the word survived in 12 percent of the background questions formed from questions containing "visibility". The term "GEO" carried over in 34 percent of cases. Instead, the system searched for words such as seo, marketing and service.
Expect varying searches rather than a fixed list. Of the 89 runs measured, 88 produced different background questions. The meaning mostly stayed, but the concrete wording changed.
One practical consideration follows from this. When compiling target words, it is worth taking into account not only your own vocabulary but also what the machine actually searches for. That way your position becomes measurable not only against your own professional terms but also against the expressions the system uses.
After that it may select the quotable paragraph
Once a few possible pages are available, the machine may also search within the page. It often selects a single portion of the page.
Because of this, structure may play as important a role as content in AI search optimization. The next chapter presents this in detail.
It may examine whom the selected paragraph is about
From the extracted passage, the machine may try to identify the people, companies and concepts appearing in it. At this stage what counts is the extracted passage itself. If the name appears in the title, in the main heading and in the structured data, but not in the given paragraph, then identifying the company from the excerpt may be harder.
We measured this on our own site as well. In the 341-character text under the heading "Who works with GEO in Hungary?", neither the company name nor the name of the country appeared. Yet for the background question "GEO agency in Hungary", this paragraph was the closest match on the entire page. The structured data was flawless, but that mainly helped identify the page; in this measurement it did not secure the name's entry into the answer.
Whether your name appears may be decided as the answer is assembled
At this stage it may become clear whether a fact enters the answer together with the name of its source.
In one of our own measurements, Perplexity quoted a figure from our Hungarian measurement study in all five runs, but never named the source. The author and the publisher were present in the structured data. In the cases examined, that setting was still not enough.
It may help if the name appears in the very sentence the machine extracts. We obtained a similar result on another of our surfaces: the brand name appeared in none of the 194 Hungarian passages examined, while the structured data was flawless. After the fix, 34 of 203 passages already contained the name.
There is also a slower-changing layer: the model's memory
This process can be slower. When someone says they "want to get into AI", they may not be thinking of this layer.
Establishing machine readability and identifiability may be one-off work whose effect can appear within weeks. The model's memory, however, may form over months, and may build primarily from what the system finds about you during training. If a piece of information is left out of that, it may remain unknown to the model for a longer period.
Two different workstreams are therefore worth accounting for. One may help the machine reach your crawlable, indexed, fresh and clearly structured page. The other may act on the model's memory: here what may count is what others write about you, how consistently they do so, and how long that information has been available. If someone only puts the first area in order, the technical state of the website may be adequate and ChatGPT may still not mention it. In that case the gap is not necessarily on the website.
Which engine may look for sources, and when?
The market often speaks of "AI" as a single category. Based on our measurements, there can be significant differences between how engines behave.
We put twelve buyer questions to three engines, five times per question. That came to 180 measurements on 2026-08-12:
| Engine | Runs in which it looked at a source | Questions where it had a source at all |
|---|---|---|
| ChatGPT | 7 / 60 (12%) | 2 / 12 |
| Gemini | 43 / 60 (72%) | 11 / 12 |
| Perplexity | 60 / 60 (100%) | 12 / 12 |
An independent measurement with 167 stored answers, different questions and a different panel gave a similar result. ChatGPT searched on 17.3 percent of Hungarian purchase questions, with a margin of error between 9.4 and 29.7 percent.
This suggests that ChatGPT may answer a significant share of Hungarian purchase questions without searching. In such cases a fresh website alone may not be enough, and the picture formed in the model's memory may also play a role.
"Whom not to" questions showed a different pattern. In thirty runs, ChatGPT never launched a search. Nor did the engines examined name a company to avoid: in 90 negative runs this did not happen once. The answers instead listed criteria about what to watch for and what may be a warning sign.
This may also carry business significance. If a company sets out those criteria in detail, the buyer may make a decision based on the yardstick published there. In such a case the engine may not recommend the company itself, but it may pass on the evaluation criteria that company formulated.
Google's three surfaces may give different results
On 2026-08-25 we put the same Hungarian question to three Google surfaces, in literally identical form, from a browser without a login and with Hungarian settings.
In default search no AI summary appeared. Only the usual result list was visible.
In the classic, AI-free list, three pages appeared that were also among the default ten results. In this measurement, then, the two surfaces did not return the same result set.
We ran AI Mode three times in a row. There was no company that appeared in all three results. The three runs together surfaced ten different pages, and five of these did not appear among the first ten organic results.
The measurement raises two considerations. A position on the organic result list and an appearance in AI Mode may be separate jobs. Methodologically, an AI Mode screenshot shows only a single sample, so it is worth completing at least three runs before drawing a conclusion.
The discipline of page structure
This chapter deals with structural elements you can change directly. Most of them are under the control of whoever runs the website.
One principle is worth remembering. The machine may cut the page up along the headings and then treat each part separately. A heading may therefore act as a boundary: the content beneath it may become a quotable unit, and the text of the parent headings may be placed at the start of the excerpt.
The following numbers come from the 2026-08-14 sweep of our own website. We examined 122 pages, 122 main headings, 694 second-level and 823 third-level headings, that is 1517 sections in total. The fixes were introduced in five rounds.
One main heading, descriptive subheadings, no level skips
Formal order can be established with relatively little work, and on many websites it is already adequate. One h1 per page is recommended, with real h1–h6 elements; in the header and the footer it is advisable to avoid headings.
Level skips are worth checking separately. On ten of our pages an h4 followed directly after an h2, because one component was built that way. This may have changed the structural tree and the path the machine can write at the start of an excerpt. The fault was fixable in a single place.
Only a cautious comparison can be made with the AirOps sample, because the result shows co-occurrence, not a causal relationship. Exactly one h1 appeared on 87 percent of the pages cited by ChatGPT, and 68.7 percent of them had no level skip in their structure.
Your glossary can easily become a single large block
For us this caused the most structural work. The glossary page intended for "what is GEO" type questions appeared as a single block of 4611 tokens, with no internal boundaries. The concepts were in a definition list (dl, dt, dd), but dt does not count as a heading. The machine may therefore have treated the whole page as one section.
The fix required structural rework. Every concept received its own section and its own h2 heading. A similar problem may occur on websites where the glossary or the frequently asked questions sit in a definition list.
The heading should contain only the heading text
This fault is less conspicuous. On twenty of our pages the concept tooltip ended up inside the h2, while the rendering looked correct. The machine read out roughly 500 characters of repeating text as the heading, and could then insert that block at the start of the parts below it as well.
It can be filtered out with a simple check. No heading should contain a tooltip element.
Every subheading should have text of its own
On fifty-seven of our pages there were 106 h2 headings immediately followed by an h3, with their own text running between 0 and 34 tokens. In such a case the parent heading's claim has no independently quotable passage attached to it.
Two or three sentences under every such heading may help, preferably with a number or a date. If the pages are produced from a template, one component and a few sentences per template may be enough.
The heading should name the topic, and preferably not repeat
Four of our generic headings repeated across between ten and twenty-one pages. "Frequently asked questions" appeared on 21, "Sources" on 13 and "The procedure" on 10 pages.
"The procedure" carries little information on its own, while this is the text that may enter the index and the start of extracted excerpts. All ten instances came from separate, hand-written code, so fixing one did not modify the others.
A more precise form might be, for example, "Frequently asked questions about GEO agencies" or "Setting up robots.txt step by step". As a check, it can be used that within one language the same h2 should preferably not appear on two separate pages.
The section should be understandable on its own
If the machine cuts out a section, the text should ideally remain interpretable in that form too. This does not rule out demonstrative pronouns. The excerpt may include its own heading, so a "this" referring back to it does not necessarily cause a problem.
Our first checker searched for pronouns and reported 100 faults. The real trouble may arise, however, when the text refers back outside the section, for example with "the previous" or "the above". After the rule was made more precise, eighteen hits remained instead of a hundred, and manual reading identified a single real fault. The measurement itself worked, but the interpretation of the rule needed correcting.
The section should be neither too short nor too long
According to the distribution measured across 1517 sections, 44 percent were under 90 tokens, 50 percent between 90 and 400 tokens, and 6 percent above 400 tokens.
The short sections often came from templates. One of our checklists created twenty subheadings of 33 to 55 tokens each under a single heading. Instead of one coherent part, twenty small excerpts were produced. At the other extreme, a section of nearly 2000 tokens may be cut in two by the machine, and the second part may be left without a heading of its own.
The 90 and the 400 tokens are, however, a soft boundary, that is an industry rule of thumb. The right order of magnitude is plausible; the exact number is not. It is therefore not advisable to build automated checks solely on an estimated threshold.
Text placed at the bottom of the page may be quoted less often
Forty-three of our pages had a frequently asked questions block, and on revenue-supporting pages 57 to 61 percent of the text came after it. According to research examining roughly 98 thousand citations, the bottom tenth of the page produced 2.4 to 4.4 percent of citations.
The order can be changed without deleting anything. The three or four most important questions, for example price, guarantee, the difference from SEO and the time required, can move up into the body text with headings of their own. The rest can stay at the end of the page. With this, our ratio fell from 61 to 42 and from 59 to 44 percent.
The structured data can be preserved even if the frequently asked questions block is built from two lists. In our case all 12 questions still appeared in it.
A limitation belongs to this as well. For now we can only support the effect of the move with structural numbers. We have not proven that the change produces more citations, so it is worth treating only as a possibility.
If the heading is the buyer's question, the paragraph can give the answer
This is one of the important practical considerations of this chapter. If a heading matches word for word what the buyer types in, the machine may lift out the paragraph beneath it. It is therefore worth naming the company there, and where it operates, too.
A name in the title, in the main heading and in the structured data does not necessarily substitute for this. The machine, after all, often selects a paragraph rather than a whole page.
In the 2026-08-25 field measurement, a single page appeared on all three Google surfaces. On that page the buyer's question appeared as an interrogative sentence, in a heading: "Which agency understands AI search optimization in Hungary?"
Give headings an anchor, but know what it is good for
Of our 1517 headings, 1481 had no identifier of their own. After the fix, 99 percent of headings received one.
This does not mean that an anchor can produce a citation on its own, and it does not replace a deep link pointing at a passage. It is therefore not justified to promise such a result. Without an anchor, however, it is harder to measure which section the system quotes, so the identifier may above all be a precondition for measurement.
One practical consequence is worth accounting for. If you rewrite the heading, the anchor changes as well. This is an established solution, GitHub and MDN work this way too, and it may require less maintenance than a separate anchor list that can drift away from the text over time.
What I deliberately do not recommend
We found no adequate measurement behind the following rules, which are circulating in the field.
The 40 to 60 word answer block as a general rule. This number appears in several articles, with a different value in each version, but there is no measurement behind it. The mechanical part may nonetheless be usable: it is worth putting the answer at the start of the section. Checking a fixed word count is not advisable.
The interrogative heading as a goal in itself. The studies measured how well the heading matched the question; they did not measure the effect of the question mark itself. A declarative heading can match just as precisely.
Placing frequently asked questions structured data on every page.
The claim that "correct hierarchy earns 2.8 times more citations". This is a relayed ratio, used in a different sense. We do not use it in client material.
Producing a separate Markdown version for robots. It may be risky, it requires significant maintenance, and the published tests do not show a large change.
In our own experience, most of the faults were created by four templates and then repeated across ten to twenty pages. The fix was therefore primarily a development task, not copywriting.
Is lang="hu-HU" needed?
This question comes up often, and the obvious answer is not necessarily accurate.
The uncertainty is understandable. If html lang and hreflang contain only the value hu, it may occur to you that Gemini or Google's AI summary does not consider the marking precise enough. We measured this on 2026-08-26, before the modifications.
What did the measurement show?
Our other website already used hu-HU marking, with a Hungarian .hu suffix and a domain made of Hungarian words. In none of the fifteen runs did it enter Gemini or Google's AI summary. In this in-house test, then, that setting alone did not come with an appearance.
The field gave the following result in the same measurement:
| page | how many times it got in (out of 15) | html lang |
|---|---|---|
| tartalomdesign.hu | 10 | hu |
| hdmarketing.hu | 6 | en |
| agrandlabs.hu | 4 | hu |
| markestic.hu | 3 | hu-HU |
| marketing21.hu | 3 | hu-HU |
| vantgarddigital.hu | 3 | hu |
The page with the most appearances uses simple hu marking. With Hungarian content, hdmarketing.hu reached 40 percent with English language marking. If an imprecise language label caused automatic exclusion, some trace of it would be expected at that page. Neither we nor the leader of the field sent a Content-Language header.
Based on the measurement, switching to hu-HU probably does not address the most important bottleneck. Using it may do no harm, but on its own it is unlikely to produce an appearance.
What may go into which field?
The fields carry different meanings. When setting them, it is therefore worth considering not merely formal consistency but also their purpose.
| field | recommended form | why |
|---|---|---|
| html lang | hu | it follows the logic of hreflang |
| hreflang | hu | this is targeting |
| og:locale | hu_HU | OpenGraph prescribes this form |
| structured data inLanguage | hu-HU | this is a description of the document |
| Content-Language header | not needed | it made no difference in the measurement |
hreflang="hu-HU" may signal to the search engine that you intend the page for users living within the territory of Hungary. This may exclude Hungarian readers in Transylvania, Slovakia and Vojvodina from the targeting. If language is what matters rather than the national border, plain hu may be the more appropriate marking.
inLanguage describes the language of the document. More precise marking here excludes no readers, while it may give the machine clearer information. For this field, therefore, using hu-HU may be justified.
It is advisable to protect the two settings with separate checks. A later modification aimed at unifying language labels could easily overwrite the correct value of one of the fields.
What may genuinely be a language signal
While examining the language labels we also found a more significant gap. Our own machine-readable table of contents (llms.txt) listed 64 English pages and not a single Hungarian one. The entire Hungarian part consisted of one English sentence pointing at the home page, leaving the translation to the reader. None of the seven Hungarian pages appeared in the machine-readable listing.
The machine probably does not determine language from a single attribute. Several signals together may count: the Hungarian web address, title, main heading and text, along with the Hungarian lines of the machine-readable listing.
In the language layer, therefore, the following are worth checking:
- A Hungarian web address should appear on Hungarian pages, not the English web address with Hungarian text.
- A Hungarian title and main heading should be produced, not identical letter for letter to its English counterpart. In our case ten product pages and two important subpages had titles that matched exactly across the two languages.
- Language marking should go into the structured data. In our case it was missing from 1157 elements, and 28 pages said nothing at all about what language they were in.
- Hungarian lines should go into the machine-readable table of contents, drawn from the Hungarian pages' own Hungarian text.
- The default language should be the one the website actually uses as its default.
One trap of the Hungarian language: inflection
When measuring or grouping Hungarian text, it is easy to arrive at a wrong result. What is more, the fault may go unnoticed.
We found two cases. In the first, our instrument searched for the form "láthatóság" but no longer recognised the form "láthatósági". Because of this it showed 6 percent instead of 22, that is it under-measured performance by nearly fourfold.
The second case related to stemming. In the program we also cut off the -ás/-és and the -ság/-ség endings. As a result, szolgáltatás stemmed deeper than the plural szolgáltatások, so the base word did not end up in the same group as its own plural. The -ás/-és is a derivational suffix: szolgáltat is the verb, szolgáltatás the noun, and the concept under examination appears in the noun.
For Hungarian text, therefore, simply cutting off suffixes cannot on its own be regarded as reliable stemming. Inflection has to be separated from derivation. And it is worth recording the known limits in the test as well, otherwise the gap list may later look falsely like full coverage.
What may the domain, the web address and the title reveal?
If the earlier conditions are met but the appearance still fails to come, these fields may also provide an explanation.
On 2026-08-17 we examined why the machine recommends competitors for Hungarian questions. The sample did not support the following obvious explanations:
- the heading structure: our page led the field, and the co-occurrence of structure and citation was negative (−0.26);
- the amount of content: our pages stood second and third in the field measured;
- the age of the domain: among those that got in there was both a 15.6 year old and a brand new domain;
- external mentions: three of the most frequently mentioned companies had no such hits;
- the length of the text: the page appearing most often was the shortest.
The remaining shared characteristic was the presence of the everyday searched word. All 14 pages that got in contained this word in the domain, the web address or the title. Of the 38 pages cited by Gemini and Google's AI summary, 28, that is 74 percent, met this condition.
Two clarifications are needed so that no general rule is born from the result.
Based on the measurement, the .hu suffix cannot be regarded as a condition of entry. 86 percent of citations came from .hu domains, but the other pages were in Hungarian and got in with a web address containing Hungarian words. A .com domain with a Hungarian language prefix and a Hungarian web address appeared in all three runs.
A domain made of Hungarian words is not necessarily enough on its own. A significant share of the companies appearing in AI Mode used such a domain, but our other website was of this kind too and still did not enter any of the results. That page was three days old, and not a single external link pointed at it.
The limitation of the finding matters. This shows co-occurrence on the data of a single question set and one engine, so it does not prove that placing a word can produce an appearance on its own.
What is worth doing on Monday morning?
The following order moves from the steps with less effort and greater certainty towards the slower tasks.
- Check the robots.txt file for all three robot types. Set separately what you allow the training, the search and the answering robots.
- See whether the text appears in the HTML sent by the server. If JavaScript assembles the content, it may remain unreachable for some systems.
- Break up the glossary and the long sections with headings. Without this the page is harder to divide into separately quotable parts.
- Write a paragraph of its own under every heading that is immediately followed by a subheading.
- Lift the three or four most important questions into the body text, the ones that until now sat among the frequently asked questions at the bottom of the page.
- Find the heading that matches the buyer's question word for word, then check the text beneath it. If it does not contain the company name and the location, complete it with a single sentence.
- Put the language fields in order: have a Hungarian web address, a Hungarian title, language marking in the structured data and Hungarian content in the machine-readable listing. Setting hu-HU can be last on this list.
- Examine what words the machine uses for your category. It may not choose your expressions. If the market's everyday vocabulary differs from the professional term, that expression has to find a place in the content as well.
- Re-measure from at least three runs, and record it as well if nothing changed.
What cannot responsibly be promised
Behind the numbers published in this article stand our own or external measurements. It is just as important to signal their limits.
The strength of the evidence varies. It is documented machine behaviour that a heading may mark a boundary and that parent headings may enter the excerpts. The rarer citation of text at the bottom of the page is co-occurrence observed on a large sample. The exact token counts, by contrast, are rules of thumb, as the article notes at every point concerned.
It is hard to separate the effect of individual changes. If you modify the structure, the vocabulary and the internal links at once, it may not be possible afterwards to determine which change contributed to the result. The precise, separate effect of each step could therefore only be promised alongside an appropriate measurement.
Engine behaviour can change. One important figure in this article, the overlap between ChatGPT's and Bing's results, fell from 87 percent to 8 percent in two years. Every claim holds for a given point in time, and may later require review.
A general conclusion should not be drawn from a single run. In the three AI Mode runs there was no named company that appeared in all three results. A screenshot therefore documents a single sample, not necessarily the lasting state.
The author is the founder of AVE Studio. The studio measures whether AI answer engines name companies, and ships in code the fix that lets a machine identify a company and its content unambiguously. The figures in this article come from its own measurements.