GEO-Ready Website: A Small Business Infrastructure Guide

Most small business websites look good to the human eye but cannot be read by a machine; when AI crawlers cannot see the text on a page, the business never appears in AI answers, no matter how well the site is designed.

This does not mean the designer did a bad job. For the past decade the yardstick for commissioning a website has been "make it load fast, don't let it break on mobile, make it look good" — those criteria still hold, but they are no longer enough on their own. Your customer today may not be finding you through Google's ten blue links at all. They may be asking ChatGPT, or the assistant on their phone, "I'm looking for a reliable X in this area", and arriving through the answer that comes back. If the system producing that answer cannot read your site, it cannot recommend you.

This guide is a checklist for business owners who are about to commission a website or rebuild the one they have. Every item explains what it is, why it matters and how you can verify it yourself; at the end there are ten questions you can put to the agency.

Why doesn't your website appear in AI answers?

AI assistants depend on software that crawls the web; these are called bots — GPTBot, ClaudeBot, PerplexityBot, Google-Extended and others. A bot arrives at your site, takes the HTML file your server sends back, and reads the text inside it.

Here is the critical part: most of these bots do not do the work your browser does. When Chrome opens a page it runs the JavaScript, fetches the data and paints the text onto the screen. A bot, most of the time, looks only at the first file it receives. If the content only comes into existence after JavaScript has run in the browser, the bot sees an empty page.

The result is a strange contradiction: you open the site and everything is where it should be; the bot goes to the same address and finds nothing at all. The site is not broken, it is simply invisible to machines — and this is the most common technical reason behind the complaint "AI never mentions us".

What is server-side content, and how do you check it?

The fix is for the content to be ready before it reaches the browser. There are two common ways to do that:

SSR (server-side rendering): when a visitor asks for a page, the server builds the HTML at that moment and sends it.
SSG (static site generation): the pages are produced as HTML files in advance, when the site is published; the server simply hands over a file that already exists.

Both give you the same outcome: the bot receives a full HTML document on the very first request. The site you are reading, for instance, runs on static generation — a real HTML file is created at build time for every article and every service page, so the text is already sitting there when a bot arrives.

How to check it: right-click the page and choose "View page source", then use Ctrl+F to search the text that opens for a sentence you know is on your page. If the sentence is there, the content is ready on the server side. If all you see is an empty shell such as <div id="root"></div>, your site may be showing up blank to bots. A second test: switch JavaScript off and reload the page — if the screen stays white, you have a problem.

This single check matters more than anything else on the list: if the content is not visible, the rest of the improvements have nothing to work on.

Does every page have its own URL, title and canonical?

One-page sites went through a period of real popularity: services, about, contact — everything on a single page you scroll down. That is fine for a human visitor, but it is a serious loss on the search and AI side. When an answer is produced, one address is cited as the source; if everything lives at one address, the system is left with a single general page that cannot answer any specific question clearly.

Every topic that matters should live on its own page, and every page should carry the following:

Its own URL: a readable address that describes the topic (something like /services/teeth-whitening, not /page?id=47).
Its own <title>: the heading that shows up in the browser tab and in search results. It must be different on every page.
Its own meta description: a one-sentence summary of that page.
A canonical tag: the statement "this is the real address of this content", which stops signals from being split when the same content can be opened from more than one address.

How to check it: open three different pages of your site and compare the titles in the browser tabs. If all three show the same text — often just the company name — page-level meta tags have not been set up.

Semantic HTML and contact details: what the machine actually reads

The visual hierarchy of a page and its code hierarchy are not the same thing: a line that looks large and bold in the design may be an ordinary text box in the code. The machine reads the code, not the picture. The correct structure is a single H1 on the page, H2s below it separating the topics, and H3s where they are needed. Heading tags should not be used for decoration. This arrangement is what lets a system quote a single section from your page — it can tell where that section starts and ends.

The same logic applies to images: every image needs alt text, a short description that tells a reader who cannot see the image, or a machine, what it shows. It is required for accessibility as well.

Contact details are frequently overlooked. There are sites that bury the phone number in an image out of fear of spam, or write it out later with JavaScript; that information is invisible to a machine. When an assistant answers "how do I reach this business" and cannot find your number as plain text inside the HTML, you cannot be part of the answer. Address, phone and email should sit there as readable text, marked up with tel: and mailto: links.

What does structured data (schema) solve?

Text tells a machine what you have written; structured data tells it what you are. The JSON-LD blocks written to the Schema.org standard are like an identity card embedded in the page: this is a business, this is its name, this is its address, these are the services it provides.

An SMB site should carry at least the following:

LocalBusiness or Organization: the name, address, phone number, opening hours and social profiles of the business.
Service: for every service page, a description of the service and the area it is offered in.
FAQPage: the frequently asked questions and answers on the page.
BreadcrumbList: where the page sits within the site.
Article / BlogPosting: author and date information for written pieces.

This markup does not guarantee a ranking; it reduces ambiguity, so the system does not have to guess your name and your address. We covered how the subject connects to trust signals in more detail in our article on Schema Markup and E-E-A-T.

How to check it: enter your page address into Google's Rich Results Test or the Schema.org validator. If no structured data is found at all, this layer has simply never been built.

Page speed and Core Web Vitals: what do LCP and CLS mean?

Core Web Vitals are a handful of concrete metrics Google uses to measure page experience. Knowing two of them is enough:

LCP (Largest Contentful Paint): how long the largest visual element on the page takes to appear; the moment the user feels that "the page has loaded". The general consensus is that under 2.5 seconds is good.
CLS (Cumulative Layout Shift): how much the content jumps around while the page loads. A page that shifts just as you are about to tap a button damages this metric. Lower is better.

Speed is not discussed as a direct GEO ranking factor, but it has an effect in two places: fewer pages of a slow site get read during a crawl, and visitors leave quickly. Always run the measurement in mobile mode.

How to check it: put your address into PageSpeed Insights and look at the "Mobile" tab. Sites with a good desktop score and a poor mobile score are fairly common.

robots.txt, sitemap.xml and llms.txt: three files, three jobs

These three small files are the face your site turns towards machines.

robots.txt says which bot is allowed where. The most frequent and most expensive mistake is blocking AI bots without realising it: some hosting panels and security services ship a "block AI crawlers" option switched on by default, and while that option is on, all of the work above goes to waste. GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot and Google-Extended should be explicitly allowed.

sitemap.xml is the list of every address on the site; it keeps the bot from missing a page. It should not be maintained by hand — it should update itself whenever new content is added.

llms.txt is a plain-text site map written for AI models, describing in simple language what you do and where your most important pages are. For the details, see our article on what llms.txt is and how to manage AI crawlers.

How to check it: type yoursite.com/robots.txt into the browser; if nothing opens, the file does not exist. If it does open, look for a Disallow: / line or any rule that blocks AI bots.

The GEO-ready website checklist

On the content side the goal is simple: the questions your customers ask should have clear answers on your pages. In practice that usually means three page types — a service page for every service, a location page for every area you serve, and a frequently asked questions page. We described the strategy side in how to build a GEO strategy; the table below sums up the technical side at a glance.

Check	Why it matters	How to verify it
Is the content produced server-side (SSR/SSG)	If a bot cannot see the text without running JavaScript, the site never appears in answers at all	View the page source and search for one of your sentences with Ctrl+F; or turn JavaScript off and reload
Does every page have its own URL	Each topic needs a separate address before it can be cited as a source in an answer	Click every link in the menu and watch the address bar change
A different `<title>` and meta description on every page	Keeps pages distinct from one another and matched to the right query	Open three different pages and compare the browser tab titles
Is the `canonical` tag correct	The same content opening from several addresses splits the signals	Search the page source for `rel="canonical"` and confirm the address is right
A single H1 and a clean heading hierarchy	Lets a machine quote one specific section out of the page	Check the H1 count with a free heading auditor extension
Is JSON-LD schema in place	States your business identity, services and questions to machines in explicit terms	Enter the address into the Rich Results Test or the Schema.org validator
Are the contact details there as plain text	A phone number or email buried in an image or written by JS is invisible to a machine	Search the page source for your phone number and your email address
Do the images have `alt` text	Required for accessibility and for making the content understandable	Right-click an image and inspect the element, or run an accessibility audit
Mobile speed and Core Web Vitals	A slow page is crawled less and loses the visitor	PageSpeed Insights, the "Mobile" tab
Is `robots.txt` open to AI bots	A blocked bot can never read your site; this is the most expensive silent error	Open `yoursite.com/robots.txt` and check for blocking lines
Is `sitemap.xml` current and automatic	Speeds up the discovery of new pages	Open `yoursite.com/sitemap.xml` and see whether your newest page is listed
Does `llms.txt` exist	Gives AI models a plain map of the site	Open `yoursite.com/llms.txt`

Ten questions to ask an agency when commissioning a website

Asking these at the quotation stage costs far less than having the site rebuilt afterwards. The answers do not have to be technical; they have to be clear.

Will the content be produced server-side? Will the site still show text with JavaScript turned off?
After delivery, can we open the source code of a page together and see the text in it? This is the proof of the first question.
Will every page have its own title, description and canonical tag? Will those be editable from the admin panel later?
Which schema types will be implemented? Are LocalBusiness, Service and FAQPage in scope?
What will the mobile PageSpeed score and the LCP value be at delivery? Can you commit to a target?
Will AI bots be explicitly allowed in the robots.txt file? If the hosting or security layer is blocking them, will that be switched off?
Will sitemap.xml be generated automatically, or are we going to update it by hand?
Is llms.txt in scope? If not, what would adding it involve?
Who is going to write the content? Is the copy for the service and location pages included in the price, or expected from us?
Will we be able to add content ourselves after delivery? Will opening a new service page mean coming back to the agency every time?

Working with an agency that answers these clearly produces far fewer surprises; once the scope is written down plainly, the budget becomes something you can actually discuss. You can see how corporate website design and GEO infrastructure are built together on our solutions page. If you will also sell through the site, product data and the checkout flow are a separate job; that side belongs to e-commerce website setup.

We described how professional service offices such as accounting and consultancy practices build the same infrastructure on our accountants solution page.

Frequently Asked Questions

Do I have to have my existing site rebuilt from scratch?

Not always. If the site already produces its content server-side, schema, meta tags, llms.txt and speed improvements can be added on top of the structure you have. But if the content is created entirely in the browser with JavaScript and the underlying setup will not allow that to change, a rebuild works out cheaper than patching. The page source test is what makes this distinction clear.

Does a one-page site never show up in AI searches?

It can, but only in a very limited way. Because every topic sits at the same address, there is no separate address to cite as the source for a specific question. Your chances of appearing in searches for your business name remain; for questions of the "who provides this service in this area" type, competitors with separate service and location pages come out ahead.

Are the website and the GEO work separate jobs?

They are two layers of the same job. The website is the infrastructure that makes the content machine-readable; GEO is the content and visibility work built on top of it. GEO work done before the infrastructure is ready goes to waste, because there is no readable page to point at. That is why it is more efficient to plan the rebuild and the GEO setup at the same time.

Which platform should I use?

Configuration decides this, not the choice of platform. Most of the common content management systems produce HTML on the server and work without trouble when they are set up correctly; a custom site built with a modern JavaScript framework, by contrast, can look empty to bots until server-side rendering is switched on. The question is not "which platform" but "does this setup send full HTML to a machine".

When will I see the results of these changes?

The effect of technical fixes depends on bots crawling the site again, which is usually a matter of weeks. Being mentioned regularly in AI answers takes longer, because it requires content to accumulate and the brand to be corroborated in other sources. Fixing the infrastructure is the first step, not the only step.

All of the tests above take a few minutes; you can see for yourself where your site stands against this list. If you want a more detailed breakdown, we at Next GEO Agency review your site against these items and write up what is missing; the contact page is all you need.