12°
Portada del artículo: The seven GEO rules: I reproduced the only test that exists, then audited my own 72 pages
SEOGEOStatisticsToolsData

The seven GEO rules: I reproduced the only test that exists, then audited my own 72 pages

A Russian study tested the seven rules the GEO industry keeps repeating against 73 pages that six engines had cited, and not one survived. I rebuilt its counts and reproduced all seven p-values exactly. Then I took the detector to my own 72 pages, and there something appeared that none of the rules looks at: four different pages declaring the same entity.

Efrain Garay 23 August 2026

I have spent weeks reading the same list of rules for getting a language model to cite your page. It shows up everywhere, always identical, always with no number behind it: put the keyword at the front of the title, add an FAQ block, mark everything up with Schema.org, keep the URL clean, show the date, sign it with your name.

Nobody ever shows the measurement. And since the site you are reading this on meets almost all of them, I wanted to know whether they were worth anything.

Somebody measured it, and the result is awkward

On 23 August an experiment appeared on Habr doing exactly what was missing. Its author ran 20 queries, three times each, against six engines. That list of six is the first thing making this experiment different.

Six engines answered the same 20 queries, three times each. Two of them are Russian, which is why this experiment exists and why the English-language coverage does not have it.
  • ChatGPTUnited States
  • ClaudeUnited States
  • PerplexityUnited States
  • GeminiUnited Statessource not visible
  • GigaChatRussia
  • AlisaRussia

One of the six does not show who it cites

Gemini returns its sources through vertexaisearch.cloud.google.com, and the real page address is not visible behind the redirect. Another 160 addresses were set aside for that reason: they exist, they were cited, and there is no way to tell what they point at.

From the citations to the sample

  1. 199 usable addressesappeared in the engines’ cited sources
  2. 76 candidates36 cited by two engines or more, plus the first 40 alphabetically of the singly-cited
  3. 73 pages analysed34 and 39: three did not download
  4. 160 opaque addressesGemini redirects, set aside. Not part of the 199.

From the usable addresses he built two groups: 36 candidates cited by two engines or more, and of those cited once, the first 40 in alphabetical order. Thirty-four and 39 downloaded, so 73 pages.

That second group deserves a second look: it is an alphabetical slice, not a random sample. Sorting by URL clusters by domain, so a site with many singly-cited pages can end up overrepresented in half the experiment. It does not invalidate anything, but it is the kind of detail that decides how much weight a small difference deserves.

He then downloaded each one with curl, without running JavaScript, detected the attributes and compared both groups with Fisher’s exact test, which is the right one when the sample is small.

The seven rules, one by one

Before arguing about numbers it helps to pin down what we are talking about, because almost no article on GEO defines its own terms. These are the seven, with the exact criterion the detector uses to decide whether a page meets each one. The criterion matters as much as the rule: “have an FAQ” means nothing until somebody says what counts as an FAQ.

What each one asks for, how the detector decides whether a page meets it, and the p-value it came back with.
  1. Keyword at the start of the title

    That the term you want to rank for opens the title, not that it appears somewhere in it.

    measured as The <title> is taken, tags stripped, and the keyword looked for in its first 40 characters.

    0.2058p

  2. Keyword at the start of the h1

    The same in the heading the reader sees.

    measured as Same rule, applied to the page’s first <h1>.

    0.1615p

  3. Visible publication date

    That you can tell when it was written.

    measured as Counts if there is a datePublished or dateModified in the markup, an article:published_time, or a <time>.

    0.6383p

  4. FAQ block

    Short questions and answers a model can quote verbatim.

    measured as Counts either a FAQPage in the markup or the words «frequently asked» on the page. Either one.

    0.7837p

  5. Schema.org markup

    Stating in machine-readable form what this page is.

    measured as One application/ld+json block that parses is enough, or a schema.org itemtype.

    0.1646p

  6. URL without parameters

    A stable, clean address.

    measured as On the final URL after redirects: no «?» and not ending in .html, .php, .aspx or .jsp.

    0.2432p

  7. Text volume and subheadings

    Enough body, broken into sections.

    measured as h2 to h4 are counted, and the characters of the text with tags and scripts removed. Continuous figures.

    The only continuous one: the study published medians and never ran a test on it. This is why there are seven p-values and not eight.

    no test

  8. Visible authornot on the list

    That it is clear who wrote it.

    measured as author in the markup, or itemprop="author", rel="author", name="author" or article:author.

    0.0127p

The count needs care here, because everything else depends on it. The list has seven rules, but one never reached the test: text volume and subheadings are continuous figures, and of those he published only the medians, with no test. That leaves six. In exchange he added an attribute the list does not contain, visible author. Seven p-values in total.

Six of those seven came back between 0.16 and 0.78. Nothing. The seventh, the one he added himself, gave 0.0127: the only one under the usual 0.05.

I reproduced his numbers and got exactly the same

A result nobody repeats is not a result. So before believing him, I rebuilt the counts from the percentages he publishes over his 34 and 39 pages, ran them through scipy.stats.fisher_exact and compared.

All seven values come out identical to his, to the fourth decimal. That is not a formality: it means his table can be audited without asking him for the data, which is more than almost anything published about GEO offers.

His reading is right too. He tested seven hypotheses on the same pair of groups, and when you run seven comparisons the chance that one turns up a false positive by pure luck is no longer 5%: it is considerably higher. He says so himself, computes the Bonferroni cut at 0.05/7 ≈ 0.007, and grants that his 0.0127 does not reach it.

The seven attributes the study ran through Fisher’s exact test. Each bot sits where its p-value left it, on a logarithmic scale.
0.00714 Bonferroni
0.05 uncorrected
  • FAQ block0.7837
  • Visible date0.6383
  • Clean URL0.2432
  • Keyword in title0.2058
  • Schema.org markup0.1646
  • Keyword in h10.1615
  • Visible author0.0127

Six landed nowhere near any threshold. The seventh, the one carrying the signature, made it into the band: it clears the usual 0.05 and fails the cut that seven comparisons on the same sample demand. The author runs that same arithmetic and reaches the same place.

This deserves care, because the article is about rigour: Bonferroni is not “the honest statistic”, it is a deliberately conservative correction among several. But here the choice makes no difference. Under Holm, which is less strict, the smallest p-value is still compared against that same 0.00714. It does not reach by any route.

The confusion the whole business rests on

Two questions have to be told apart here, and almost nobody does:

  1. Whether an engine retrieves your page when somebody asks something.
  2. Whether, once retrieved and placed in front of the model, it gets cited in the answer.

The academic work that coined the term, “GEO: Generative Engine Optimization” by Aggarwal et al., presented at KDD 2024, reports visibility gains of up to 40%. That is a real result and it has to be said. But it measures the second question: its benchmark starts from queries that already come with their relevant web sources, and what it optimises is how that content, already in front of the engine, is written.

That is not what the GEO industry promises. What gets sold is the first question: add an FAQ and some Schema and the engine will find you. The Habr experiment is one of the few that looks at precisely that, over pages engines genuinely cited, and there no signal appears.

So the precise sentence is not “GEO does not work”. It is more uncomfortable: there is evidence that a document the engine already retrieved can be made more citable, and none that these seven attributes get it retrieved. A score that averages the seven and calls it visibility is charging for the second thing with the evidence for the first.

And to be clear about what this does not mean: not that the rules are harmful. Declaring the author, marking up with Schema.org or keeping URLs clean are good practice for reasons that have nothing to do with AI, such as accessibility or rich results.

I applied it to my own site

I wrote a detector for the seven binary attributes and ran it over the 72 HTML pages of efraingaray.com, under the study’s own rule: download without running JavaScript. Before touching anything:

AttributeMeets itp from the study
Schema.org markup72/72 · 100%0.1646
URL without parameters72/72 · 100%0.2432
Visible date58/72 · 81%0.6383
Keyword in the title39/72 · 54%0.2058
Visible author24/72 · 33%0.0127
FAQ block24/72 · 33%0.7837
Keyword in the h119/72 · 26%0.1615

The median subheading count came out at 8 and the median body text at 4,097 characters.

Before drawing anything from that table, two rows need care, and this holds for any GEO audit you are shown: both keyword rows depend on which word you decide is the keyword of each page. I passed one short list for all 72, and with a short list an article about the OSI model contains none of them. That 26% does not say my headings are wrong: it says my test words were not theirs.

Check it with the same detector. Over the real h1 The OSI model explained: the 7 layers and encapsulation, the keyword osi returns met and the keyword rust returns not met. Same page, same heading. An attribute whose value depends on what you typed into the form is not a property of the page, and folding it into an average is what turns a score into smoke.

That is why the tool now leaves those two not measured when you give it no keywords, instead of counting them as failed. A silent zero reads as a fail.

Setting those aside, the striking part was the only attribute with any signal in the study: visible author, on a third of the pages. The articles do declare it; what did not was everything else.

What I fixed, and what I decided not to fix

I could have marked authorship on all 72 pages. The number would have jumped to 100% and the before-and-after would have looked spectacular.

I did not, and that is the part that matters.

The rule I used: a page declares an author when somebody wrote something on it. The topic hubs, which carry editorial text of their own. The lab and the projects, where each entry has its own description. Left out were the chronological listings and the reel pages, which only enumerate links.

Marking all 72 would have been exactly the trick this experiment fails to back up: moving an attribute without anything real changing behind it.

Before and after the fix, over the same 72 pages:

AttributeBeforeAfter
Visible author24/72 · 33%28/72 · 39%
FAQ block24/72 · 33%24/72 · 33%
Keyword in the h119/72 · 26%19/72 · 26%
Schema.org markup72/72 · 100%72/72 · 100%
Visible date58/72 · 81%58/72 · 81%
URL without parameters72/72 · 100%72/72 · 100%
Every HTML page on the site, one square each. Four of them gained a byline.

33%39%

24/72 · 28/72

  • 24 already signed Articles, topic hubs, lab and projects
  • 4 signed in this pass
  • 44 deliberately left unsigned Chronological listings and reel pages: nobody wrote them.

Filling in the other 44 would have read as 100% and meant nothing.

Four pages. A jump from 33% to 39%. It is a modest result and it is the correct one.

My own detector was lying too

Shipping a tool and not auditing it would be the same sin I accuse everyone else of, so I fed the first version some prepared cases. It passed all five.

Three attributes are called visible and measured nothing visible. A date that exists only inside the JSON-LD counted as a visible date. A <meta name="author"> counted as a visible author. And a link to “FAQ” in the menu marked the FAQ block as present on every page of the site, because the menu is on every page. On top of that, a datePublished written inside an HTML comment counted as a date, and the keyword ia matched inside the word “familia”.

Now visible means it appears in the text a reader sees, with navigation, header and footer excluded; and a byline counts when the name declared in the markup is actually found on the page, or when there is a hand-written “By Someone”.

With that fixed my own figures get worse, and that is the valuable part:

AttributeNaive detectorCorrected detector
Visible publication date81%51%
Visible author39%44%
FAQ block33%31%

The interesting part is not the number but what shows up underneath: 15 pages carry the date in their markup and never show it to anyone, and 14 declare an author who appears nowhere. That is a real flaw in my site that the first version of the detector hid behind a pass. The tool now reports it separately, because it is the only part of the report that tells you what to do tomorrow.

Measured over the 84 pages in the sitemap, with the same detector that is published.

The flaw that was worth it, and that none of the seven detects

While going through the markup I found something rather worse than a missing author.

Every page that is not an article shared the same WebSite node, with the same fixed identifier. To an engine reading the graph, the topic index and the home page were literally the same object. No section had an identity of its own.

Now each one emits its own WebPage, with its identifier on the canonical URL and an isPartOf relation back to the site.

Four pages of the site, and how many distinct entities an engine saw when reading their markup.

Before

1 entity

/en//en/topics//en/lab//en/projects/#website

All four declared the same @id. To the graph they were one and the same object.

After

4 entities

/en//en/topics//en/lab//en/projects//en//en/topics//en/lab//en/projects/

Each one with its own @id on its canonical URL, plus an isPartOf link back to the site.

None of the seven attributes looks at this. The detector flagged Schema.org present on all 72 pages, because markup there was. That the markup collapsed four pages into a single object is something none of the recommendations checks.

When it is worth it and when it is not

The seven attributes are worth having for what they are: accessibility, rich results, a link you can decently share. Meet them for that.

The detector I used for all of this is published in the site’s lab: GEO detector. It reports each attribute separately with its p-value beside it, and hands out no averaged score, which is precisely the thing that cannot be supported.

What makes no sense is treating them as a discovery lever, or paying for a score that averages them. That part is not demonstrated, and the one observational experiment that measured it found nothing.

If you are going to invest time in getting a model to cite you, the available evidence points to something far more boring: content that is original, verifiable and written by somebody identifiable. Which is, incidentally, the same thing that works with no models involved.

Sources

Comments

No comments yet. The first one is yours.

Reviewed before publishing. The email is not stored and never appears anywhere.