Eight Checks Before We Call a Page GEO-Ready
We spent the last few weeks doing a full GEO (generative engine optimization) pass on our /ai page and six city landing pages. Each decision generated its own write-up. This is the summary: the eight checks we'd run on any service page before calling it AI-search-ready.
1. Service schema with real areaServed entries
Service JSON-LD needs an areaServed array with typed City objects, not free-form strings. Each city should have a corresponding landing page. If you list Fishers in areaServed but there's no /locations/fishers page, you've made an assertion with no backing evidence. We derive areaServed from the same array that generates the city pages, so the two can't drift apart.
2. FAQPage schema on the same page
Service tells engines what you do and where. FAQPage gives them something to quote. Both belong on a service page. Render them as two separate <script type="application/ld+json"> blocks, not as an array inside one block.
3. FAQ questions written as verbatim search queries
"What services do you offer?" is a bad FAQ question. "What is a fractional AI operations partner?" is a good one, because someone actually types that. Write each question as the exact query you want to intercept. The name field in Question is what the engine matches against.
4. Meta description leads with the entity phrase
The meta description is the first thing AI answer engines read. It should open with the phrase you want associated with your business. "Fractional AI operations partner for service businesses in Hamilton County..." is more useful than "We help businesses grow with AI." The meta description is now a primary source citation, not a click-through hook.
5. The entity phrase appears in three places minimum
Pick one phrase. Put it in the meta description, the Service schema name field, and the FAQ answers. One mention is noise. Three mentions across different document contexts is signal. We also put it in the city page metadata and city FAQ answers, so it appears on seven pages in total.
6. The same @id on every LocalBusiness schema
Every city page that renders a ProfessionalService or LocalBusiness schema should use the same @id: https://yourdomain.com/#business. Six pages with six different identifiers register as six different entities. Six pages with the same @id register as one entity seen from six angles.
7. Schema is server-rendered
Server components only. No useEffect, no dynamic injection after hydration. Googlebot and AI crawlers read the initial HTML. If the schema block is empty on first paint, they don't wait for JavaScript to fill it in.
8. Every claim survives a quote-back test
Read each factual-sounding sentence and ask: if a prospect repeated this to us on a call, could we confirm it? A revenue range, a support commitment, an implied metric. AI engines quote your page verbatim. Anything that would be awkward to defend if a prospect walked in with it printed out should be narrowed or removed before the page goes live.
These eight checks don't require a tool or a paid audit. They require reading your page like an engine would. We ran them on our own site before we offer them as a service to clients. If you want to see what the output looks like, the /ai page and the city landing pages are live.