// guide
How do you do GEO on your own site in practice?
Updated: 2026-08-03
// short answer
Technical GEO is hygiene, not magic. On get-geo.ai one half-day of work made every signal point to a single host, gave AI fetchers the content on the first request, switched Search Console to a domain property, and put the full guide corpus into per-locale llms-full files that auto-update from the same registry as the pages. Content decides whether you get cited; engineering decides whether anyone reads far enough to cite you.
Starting point: a site that looks right
We sell GEO — which means our own website has to be the reference implementation. This guide is not theory but the protocol of one real working day: what we found, how we fixed it, and what we verified. Every example comes from this very site.
get-geo.ai was built "by the book" from day one: server-side rendering, 8 languages with hreflang, Schema.org JSON-LD, answer-first structure, llms.txt. What could there possibly be to fix? The audit found a problem you cannot see with your eyes.
Finding #1: the apex vs. www conflict
The site physically lived on www.get-geo.ai, while every signal — canonical, sitemap, hreflang, JSON-LD, llms.txt — pointed to get-geo.ai (the apex, the domain without a subdomain). Meanwhile, the apex answered with a 308 redirect back to www.
The result was a loop: "the canonical version is the apex" → the apex redirects to www → www says "the canonical version is the apex." A classic Google crawler survives this, though it burns crawl budget. AI fetchers often do not: many of them have a budget of one or two requests per page, and some simply never reach the content through a redirect. For GEO this is critical: a file invisible to the fetcher is a file that does not exist.
The fix: the apex was made the primary domain on the host (Vercel), with www set to a 308 redirect to the apex. One switch — and every signal became consistent: the actual address, canonical, internal links, sitemap, and llms.txt now all point to the same place.
The lesson: the choice between apex and www does not matter. What matters is that the site lives on exactly one of them and the other redirects hard. Any gap between "where the site lives" and "where the signals point" is a tax on every crawler visit.
Finding #2: an outdated tip from an AI agent
The diagnostics were run by an AI agent, and its checklist included: "verify that the apex A record points to 76.76.21.21." Checking the live DNS showed otherwise: the domain resolves to 216.198.79.1 — Vercel's newer infrastructure, which the host migrated to after the model's training cutoff.
The advice was not harmful — just stale. The model was confidently quoting the past.
The lesson: an AI agent without verification tools is memory, not knowledge. Check any technical recommendation from a model against the live state of the system: a single DNS query takes a second and settles the question. This, incidentally, is the core principle of GEO itself: models answer from what they managed to read — which is exactly why we make content readable.
Step 3: Google Search Console — the domain property
After switching the primary host, the old GSC property (a URL-prefix on https://www.get-geo.ai/) became useless: it covers only www, while the pages were moving to the apex.
The correct configuration is a domain property (get-geo.ai, no protocol, no subdomain): it covers apex, www, http, https, and all subdomains at once. It can only be verified via a DNS TXT record — with one pleasant detail: the google-site-verification token is tied to the account, not to the verification method, so a record added to DNS earlier passed verification instantly. Then — submitting the sitemap under the apex address: https://get-geo.ai/sitemap.xml.
The lesson: a freshly submitted sitemap in GSC often sits with a red "Couldn't fetch" status and zero pages. That is not an error but a placeholder until the first processing pass — it is asynchronous and can take up to a couple of days. Before panicking, check three things: the file opens at its direct URL, every <loc> inside points to the right host, and robots.txt contains a Sitemap: line. If all three hold — just wait.
Step 4: the sitemap as a GEO instrument, not a formality
Our sitemap includes more than pages. It lists llms.txt, llms-full.txt, and every language version of llms-full/{locale} — with lastmod dates and priorities.
Why: AI crawlers (GPTBot, ClaudeBot, PerplexityBot) have been observed reading sitemaps, and explicitly listing the LLM files gives them a direct route to the machine-readable version of the site — without relying on the fetcher knowing the /llms.txt convention.
The lesson: treat the sitemap as a menu for machines, not a checkbox. Everything you want AI systems to see should be listed there with honest lastmod dates.
Step 5: llms-full — full content, not a table of contents
The convention distinguishes two files: llms.txt is a table of contents with links; llms-full.txt is the full content for systems that do not follow links. Our full version initially contained only the landing page: the guides — our most citable asset — were available only page by page.
What we changed:
- Per-locale files. The full guide texts moved into llms-full/{locale}, each file entirely in its own language. Dumping 8 languages into one file means diluting the useful density for any specific query eightfold.
- A URL under every heading. Inside the file, each guide opens with its title and canonical URL right beneath it — so a model that lifts the text can cite the page, not the txt file itself.
- Auto-generation from a single registry. The files are built from the same source as the guide pages. A new guide reaches the site, the sitemap, and llms-full in one action. Manual synchronization dies within a month — we never even started it.
- A limit with honest degradation. The file has a size cap; on overflow, instead of silent truncation, it appends a list of the guides that did not fit, with links.
- A lesson from an unexpected place: the first 100 KB limit was nearly broken by a writing system. Devanagari (Hindi) takes 3 bytes per character in UTF-8 versus 1 for Latin — the Hindi file hit 85 KB while the English one was half that. We raised the limit to 200 KB. If your site is multilingual, budget with the script in mind: CJK and Indic writing systems weigh several times more.
The day's result
Half a day of work, not a single new page of content — and yet:
- every signal on the site points to one host, with no loops or extra redirects;
- an AI fetcher with a one-request budget gets the content on the first try;
- GSC collects data for the whole domain, not one subdomain;
- the full corpus of guides in 8 languages is available to machines as one file per locale;
- publishing a new guide automatically updates the site, the sitemap, and llms-full.
Hygiene, not magic
This is the technical side of GEO: not magic, but hygiene. Content decides whether you get cited. Engineering decides whether anyone reads far enough to cite you.
Related questions
Does apex vs www matter for GEO?
The choice itself does not. What matters is that the site lives on exactly one host and every signal — canonical, sitemap, hreflang, JSON-LD, llms.txt — points there, with the other hostname hard-redirecting. A loop between apex and www burns crawl budget and often stops AI fetchers that only make one or two requests.
Should I use a domain property in Google Search Console?
Yes, if you care about both apex and www (or http and https). A domain property covers all of them at once and verifies via DNS TXT. A URL-prefix property on www alone goes blind the moment the primary host moves to the apex.
Why list llms.txt in the sitemap?
AI crawlers have been observed reading sitemaps. Listing llms.txt and the per-locale llms-full files gives them a direct route to the machine-readable corpus without relying on every fetcher knowing the /llms.txt convention.
Why per-locale llms-full files instead of one multilingual dump?
A single file with eight languages dilutes useful density eightfold for any specific query. One file per locale keeps the corpus dense, puts a canonical URL under every guide heading, and can be generated from the same registry as the HTML pages.