Schema markup, in plain English. Stage 3 of a RalliGEO engagement.

What schema actually is, without the jargon

Schema.org is a shared vocabulary. Google, Microsoft, Yahoo, and Yandex created it more than a decade ago so that anyone publishing on the web could label what their content means, not just how it looks. A page that says "Open 7 days a week" looks the same to a human reader whether or not it has schema. To an engine, that same line in schema markup becomes a precise fact attached to a precise business, with the days and hours expressed in a format the engine can read in one pass.

Schema is published on most sites in a format called JSON-LD. JSON-LD is a small block of structured text that lives inside a script tag in the page's HTML head. It is not visible to a human reader. It does not change how the page looks. It does change what the engines understand the page to mean. AI search engines, including the eight covered in Guide 03, read JSON-LD natively. Most retrieval-quality signals they assign to a local business begin from the schema block.

The four blocks every local business needs

A complete schema layer for a Seacoast small or mid-sized business is usually four blocks. We do them in this order because each one builds on the last.

Block one. LocalBusiness or Organization.

This is the foundation. It is the schema block that names the business, gives its address, phone number, hours, geographic service area, and the type of business it is. The most specific Schema.org type wins. A medical practice should use MedicalBusiness or one of its subtypes like Dentist or Physiotherapy, not the generic LocalBusiness. A law firm should use Attorney or LegalService. A restaurant should use Restaurant or FoodEstablishment. The more specific the type, the cleaner the retrieval. The engines route category queries through the type hierarchy, so a generic LocalBusiness tag forces them to guess which sub-category to file the business under, and they often guess wrong.

The fields that move retrieval most are name, address, telephone, openingHoursSpecification, areaServed, and url. Every one of those must match exactly what is on the contact page, the Google Business Profile, and the public listings. If the phone number on the schema block is the cell line and the phone number on the contact page is the main office, the engines see two different businesses at the same address. The fix is one pass and is the cheapest item in the stage.

Block two. Service or Product, one per service line.

After the business is established, each distinct service line gets its own Service block on its own page. A dental practice that does general dentistry, implants, and orthodontics has three Service blocks across three pages, each one naming the service, the provider, the geographic service area, and the conditions or use cases it addresses. A custom-home builder that does new construction, renovations, and small commercial work has three Service blocks. A plumbing-and-HVAC shop that does residential service, new installation, and water filtration has three Service blocks.

The reason for the separation is retrieval. A buyer asking ChatGPT for "Portsmouth dentist for All-on-4 implants" is asking a service-specific question, not a business-specific one. The engine prefers to cite the page whose Service schema names that exact procedure over the page whose schema only describes the practice. One monolithic schema block that lists everything inside the business block does not retrieve as cleanly as four small schema blocks distributed across four service pages.

Block three. FAQPage, on the pages that own the questions.

FAQPage schema marks up the question-and-answer pairs that came out of the FAQ inventory in Guide 06. Each pair becomes a structured object the engines can retrieve verbatim. The pair lives on the page where the question naturally belongs, not on a generic FAQ page, for the same reason the Service blocks live on their own pages. Retrieval is grounded in topical context. A question about insurance coverage marked up on the contact page retrieves more cleanly than the same question on an FAQ dump.

A minimal FAQPage block looks like this in JSON-LD.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Do you accept new patients?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Yes. We accept new patients every week and most insurance plans. Call the office for an opening this week."
    }
  }]
}

The question is the literal sentence a buyer asks. The answer is the authoritative answer the business gives. Both are written for a human, not for the engine. The engines retrieve verbatim phrasing better than they retrieve paraphrased marketing copy.

Block four. Person or named-provider, where applicable.

Many of the categories that show up in AI search rely on credentialed individuals. Doctors. Lawyers. Financial advisors. Chiropractors. Architects. Real-estate brokers. When the buyer asks the engine for a provider, the engine prefers to surface businesses where the named provider is visible and verifiable. A Person schema block, attached to the business or service block via the provider field, gives the engine an entity to cite by name. The fields that matter are name, jobTitle, credentials (sameAs links to state bar, medical board, or professional association profiles count here), and a memberOf or worksFor pointing back to the Organization.

Most Seacoast small businesses already have a leadership or staff page. The work is mechanical. Lift the credentials from the page into structured fields and attach them to the Organization. Verify against the public record. Done.

Where each block belongs on the site

The four blocks do not all live on one page. We distribute them.

Block one, the LocalBusiness or Organization block, lives sitewide. It is published on every page of the site, usually in the shared head or footer template, so that every page carries the business identity. Most CMS platforms support this with a single template edit.

Block two, the Service blocks, each live on the page that owns the service. The general dentistry service block is on the general dentistry page. The implant service block is on the implant page. The retrieval signal lives where the topical context lives.

Block three, the FAQPage block, lives on the page where the question is grounded, following the same rule covered in Guide 06. Cross-cutting questions live on the main FAQ page. Topic-specific questions live on the topic page.

Block four, the Person blocks, attach to the team or provider page where the named individuals are already described, and they reference back to the Organization via worksFor or memberOf so the engine can chain the entity. Most teams have one Person block per provider on a single staff page, with the credentials filled in once.

How we verify the markup actually works

We run every schema block through three checks before we ship it.

The first check is Google's Rich Results Test. It accepts a URL or a pasted block of JSON-LD, parses it, and reports whether the block is structurally valid and which rich-results categories it qualifies for. This catches missing required fields, malformed dates, and most syntax errors. It is the fastest sanity pass and we do it on every block.

The second check is Schema.org's own validator. It is stricter than Google's tool and catches issues like deprecated fields, ambiguous type assignments, and properties used on the wrong type. It does not score retrieval potential. It scores structural correctness against the full Schema.org vocabulary. We use it as the final structural sign-off before shipping.

The third check is the engines themselves. After the schema has been live for a full crawl cycle, usually one to two weeks, we re-run the same retrieval queries we ran in stage zero across the eight engines. If the schema is doing its job, the buyer-intent queries that previously returned competitors should now return the client, at least intermittently, with the citation grounded in the new schema-rich page. If the schema is structurally valid but the engines still are not citing the business, the issue is upstream of schema, usually entity inconsistency from stage one or a missing FAQ block from stage two.

The mistakes that quietly burn the work

Three failure modes account for most of the bad schema we audit on Seacoast small-business sites.

The first failure mode is asserting things the rest of the site does not back up. A schema block that claims hours of 7 AM to 7 PM, on a contact page that says 9 AM to 5 PM, on a Google Business Profile that says 8 AM to 6 PM, is read by the engines as three contradictory sources for one entity. The engine does not pick one. It downgrades the entity's retrieval credibility across all three. The fix is reconciliation. Every claim in schema must match every other public surface. This is also why we sequence entity clarity, covered in Guide 04, before schema in the engagement order.

The second failure mode is using the generic LocalBusiness type when a specific subtype exists. A pediatric dental practice using LocalBusiness instead of Dentist forces the engine to infer the subcategory from the page text, and the inference is unreliable. We always use the most specific Schema.org type that applies, even when the field appetite is greater. The work is identical. The retrieval is materially better.

The third failure mode is shipping schema once and never auditing it. Sites change. Hours change. A new service line gets added to the website but never to the schema. A provider leaves the practice and the Person block is left in place for a year. Stale schema is read by the engines as the canonical answer, and they will cite hours, providers, or services that no longer apply. We re-audit schema at the one-week, one-month, and three-month follow-up points covered in the engagement summary, and most engagements turn up at least one drift item that needs fixing.

What changes after stage three

After schema markup ships and the engines have crawled the site for a full cycle, three changes usually show up in the retrieval picture.

The first is that buyer-intent queries route to the business more often. The category-plus-geography prompts that previously returned only the established competitors begin to return the client as well, at first intermittently and then steadily, as the engines refresh their indices.

The second is that the citations themselves become cleaner. Before schema, an engine answer about the business often quotes the homepage hero or a generic paragraph. After schema, the engine quotes the specific structured fact, citing the service page, the hours block, or the named provider. The citation is tighter and the buyer reads a precise answer.

The third is that questions the buyer never thought to ask get answered. The FAQ block, paired with FAQPage schema, surfaces in the engines as a checklist that pre-empts objections. A buyer who was on the fence about insurance acceptance or new-patient availability gets the answer in the engine's first response, with the business named as the source.

Stage three is where the cheap-fixes-first sequencing in Guide 05 stops being theoretical and starts producing retrieval wins. Stage four is third-party reconciliation, and stage five is content rewrites. We will walk through both in upcoming guides.