The cheap fixes first. The order we work in a real GEO engagement.

Why sequence matters more than the items

Every GEO improvement compounds on the work underneath it. Schema markup that points at a vague entity is wasted markup. An FAQ block answering a question on a page the engines cannot place in your business is an answer credited to nobody. A polished service description on a page with the wrong business name in the metadata is an asset attributed to a different entity entirely. Doing the right items in the wrong order is the most common failure mode we see in owner-driven GEO work, and it is the one that produces the painful "we spent six weeks on this and nothing moved" feeling.

The order we work in is built around two principles. First, fix the cheapest items first, because they unlock the rest. Second, fix the items that downstream work depends on before fixing the items that depend on them. The pattern is almost always the same across every category we audit, from dental practices to plumbers to fine-dining restaurants. We work through five stages.

Stage 1. Entity clarity (day one to day three)

The first hour of every RalliGEO engagement is spent reading the homepage like a stranger and the Schema.org JSON-LD like a machine. We look for the six basic signals that let an engine know who the business is, where it is, what it does, who runs it, how to reach it, and what proof it has. Most sites get half of these right and half wrong. Some get none of them right, usually because the website was built five years ago for human readers and never reviewed against an AI retrieval pass.

Entity clarity comes first because nothing downstream pays back fully if the engine is still resolving two competing definitions of the business. Schema markup, FAQ blocks, content rewrites, third-party reconciliation, none of those work fully on top of an ambiguous entity. Fix the entity first and every other improvement multiplies. Skip this step and every other improvement diminishes.

The work in this stage is almost entirely textual. A clean first paragraph on the homepage. A meta description that says the same four facts. A schema name that matches the visible brand. A canonical statement of location. A named principal if the category cares about one. A services list written in industry-standard terms rather than marketing phrases. The full checklist lives in our piece on entity clarity. Most owners can run the checklist themselves in two hours, and many do. What we add inside an engagement is the audit of where each defect is hurting which engine, the structured-data fixes that owners do not enjoy doing, and the open-web reconciliation that comes later in stage four.

Stage 2. FAQ blocks (day three to day seven)

Once the engine knows who you are, the next leverage point is question coverage. AI engines retrieve answers, not pages. When a buyer asks a question that touches your category, the engine prefers to cite a source that already contains the question phrased the way a buyer asks it, followed by an answer in plain language. FAQ blocks are the single highest-conversion structural element we publish in stage two, and they pay back faster than any other item in the program.

The work here is to inventory the twenty questions a buyer in your category actually asks before they choose someone. Not the questions you wish they asked. Not the SEO-keyword version of the questions. The literal sentences. We pull these from three places. The first is your own inbox and phone logs, which is the highest-signal source and the one most owners underuse. The second is the questions buyers ask the engines themselves, which we sample by running test prompts across all eight surfaces. The third is the existing FAQ pages of competent competitors, which we read for completeness rather than for copying.

Each question becomes a short answer. Each pair becomes an entry in an FAQPage Schema.org block on the page where the question is naturally relevant. We do not put all twenty on one mega-FAQ page. We put them where buyers would expect to find them, paired with the services and pages they are about. Engines retrieve question-answer pairs cleanly when they are grounded in the page that owns the topic, and they retrieve them poorly when they live in a generic dump.

The output of this stage is between ten and thirty Q-A pairs across the site, each one in plain language, each one marked up with FAQPage schema, each one attached to a page that already has clean entity signals from stage one. The owner reviews the answers for accuracy. We do not invent claims. If we do not know whether the practice accepts a specific insurance, we ask. The no-guess rule applies to content as strictly as it applies to email addresses.

Stage 3. Schema.org markup (day five to day fourteen)

Schema is the second-most-asked-about item and the second-most-misunderstood. Owners who have heard about GEO often arrive convinced that the entire answer is a perfectly-formed LocalBusiness or ProfessionalService block in the homepage JSON-LD. They are partly right. Schema is important. It is also not first.

We handle schema in stage three, after entity clarity is clean and after the FAQ inventory exists, because schema is a hint to the engine and the prose on the page is the evidence the engine cross-checks against. Schema that disagrees with the prose is worse than no schema, because it tells the engine your site is internally inconsistent and reduces overall confidence. The right sequence is prose first, schema second.

The schema work itself is mechanical. We add or correct the LocalBusiness or ProfessionalService (or Dentist, Restaurant, AttorneyService, Plumber, etc.) block on the homepage. We add Person markup for named principals where the category benefits. We add Service markup for each named offering. We attach FAQPage blocks to the pages they live on. We add Review or AggregateRating only where we have permission to publish and a verified source. We use sameAs to point at the canonical third-party listings (Google Business profile, professional license listing, industry association membership) so the engine has a graph of confirmed connections.

The validator we use throughout is Google's Rich Results Test. The schema we publish is read by every engine we care about, not just Google. The validator catches the same defects that ChatGPT, Claude, Perplexity, and the rest read off your site, because the underlying JSON-LD spec is shared. Owners who try to write schema without validating it end up with broken blocks that engines ignore silently. The validator is free and authoritative.

Stage 4. Third-party reconciliation (week two to week four)

By the end of stage three, your own site is internally consistent and clearly structured. The next stage is the open-web mentions of your business that exist outside your control. Google Business profile. Yelp. Industry directories. Chamber of commerce listings. Your professional license listing. Social profiles. News mentions. Old vendor pages. Old client pages. The legacy "your business" page on a 2014 ranking site that has been picked up by every engine because the page never went anywhere.

Engines do not just retrieve your site. They cross-check your site against the open web. If your homepage says one thing and twelve open-web listings say another, the open web wins more often than the owner expects. The signal weight of a third-party citation that disagrees with your site is high enough that we treat reconciliation as a first-class stage rather than an afterthought.

The work in this stage is two-part. First, the inventory: a full list of every place the business name appears on the open web, sorted by signal weight. Second, the reconciliation pass: every mismatch gets addressed. Some we fix ourselves through the listing's own claim flow. Some require the owner to log in. Some require us to write a polite request to the listing owner. Some are unreachable and we mark them in the report so the engine's continued reference to them is documented rather than mysterious.

This stage is slower than the others because the open web cooperates on its own clock. A Google Business correction takes hours. A chamber-of-commerce listing correction takes a week. A 2014 ranking site that has not been updated since 2017 may never correct. The point is not to fix every listing. The point is to fix the ones the engines actually weight, which we identify through the same test-prompt work that informed the FAQ inventory.

Stage 5. Content rewrites (week three to week six)

Last in the order, not because it does not matter, but because it is the most expensive item in the program and it pays back fully only on top of the four stages before it. A polished services page on a site with clean entity signals and good schema is a high-conversion asset. The same polished services page on a site with ambiguous entity signals is an asset credited to the wrong business or not retrieved at all.

The content rewrites we do are not SEO copy in the classic sense. They are retrieval-friendly prose that answers the questions buyers ask, names the services in industry-standard terms, attributes the work to the named principal where the category benefits, and links cleanly to the FAQ entries and Schema.org structures the earlier stages put in place. We rewrite the homepage first paragraph if it was not closed out in stage one. We rewrite the services pages. We rewrite the About page to make the principal a clean retrieval target. We rewrite the contact and location pages to match the canonical statement of where the business is.

Some categories need more rewriting than others. A medical or legal practice that needs every claim to be defensible will spend longer here, because the legal review pass is part of the work. A trade contractor whose services pages are already concrete and named-correctly may need only a homepage and About refresh. We size the stage based on what the audit found, not on a fixed template.

The rewrites also feed back into stage three. Every rewrite changes what the schema should claim about that page. We re-run the validator after rewrites land. The two stages move together at the end.

Why the order is not negotiable

Owners occasionally ask if we can rearrange the stages to start with the items that feel most pressing. We almost always say no, and the reason is the compounding pattern. Each stage's payoff is measurable only when the stages before it are in place. Doing FAQ blocks before entity clarity produces FAQ answers credited to an ambiguous entity. Doing schema before FAQ blocks produces a schema with no FAQPage attachments to populate it. Doing third-party reconciliation before stages one through three produces an open web that points at a clean external listing and a messy internal site, which the engines then have to resolve and almost always resolve in the direction of the messier internal version.

The owner-readable version of this is: clean the inside of the house first, then the front yard, then the property line. If you start at the property line, the inside of the house is still messy and the engines tell their callers about the mess.

The owner version of this guide

For an owner reading this who wants to do the stages themselves without engaging anyone, the order is the same and the items are the same. The work compresses badly when one person is doing it all in parts of evenings, but the sequence still holds. Start with the entity-clarity checklist in our field notes on entity clarity. Move to FAQ inventory once entity clarity is clean. Move to schema once the FAQ inventory exists. Reconcile the open web once your own site is consistent. Rewrite content last. The order is the same whether the work takes three weeks of focused agency time or three months of evenings and weekends. The compounding pattern does not change.

For context on which engines you are even trying to be retrieved by, see the eight AI engines in plain English. For the Portsmouth field data underneath these patterns, see how a Portsmouth business shows up in AI search. For the professional-services slice see how customers find a dentist, lawyer, or CPA through AI search.