Schema for accounting firms in AI search: what actually matters

Schema markup does not make ChatGPT, Perplexity, or Google AI Overviews cite your firm. It makes it easier for those engines to correctly parse what you've already said clearly on the page. That distinction is the single most misunderstood point in accounting-firm SEO right now, and it's why so many firms pay a developer to bolt on structured data and see no movement in AI-generated answers.

This guide covers which schema types actually matter for an accounting firm's visibility in AI search (AEO — AI Engine Optimisation), how they work together, the mistakes that quietly break them, and a checklist you can hand to a developer without needing to write a line of JSON-LD yourself.

Does schema markup help a firm get cited by ChatGPT or Perplexity?

Schema markup helps AI engines extract accurate, structured facts from your site faster and with fewer errors — it does not directly cause citation, but it removes a common blocker to it. Large language models and their retrieval layers (whether that's Bing's index behind ChatGPT search, Google's index behind AI Overviews, or Perplexity's own crawler) still have to read your actual page content to decide whether you're a credible source. Schema is a translation layer sitting on top of that content. It tells the machine "this block of text is a service description," "this person is the author and holds these credentials," "this is a direct answer to this specific question."

Think of it as labelling, not persuasion. A firm with excellent structured data and thin, vague page copy will not outrank a firm with no structured data and a genuinely detailed, well-organised page. But a firm with strong content *and* clean schema gives every retrieval system the shortest possible path to lifting the right sentence and attributing it to the right entity. In a market where AI answers increasingly replace the ten blue links, that shortest path matters.

Which schema types actually matter for an accounting firm?

Six schema types cover almost everything an accounting firm needs for AI search visibility: Accountant/LocalBusiness, Service, Person, FAQPage, Article, and Review/AggregateRating. Each does a distinct job, and the value comes from how they interlink, not from any single tag in isolation.

Accountant (or LocalBusiness) schema

This is your firm's identity anchor. It tells engines your legal/trading name, address, phone number, opening hours, geographic service area, and — critically — that you are an accounting practice rather than, say, a software company or a blog. Schema.org has a specific Accountant type nested under LocalBusiness, and using it (rather than the generic LocalBusiness or ProfessionalService) gives engines a more precise signal about what you do.

Why it matters for AEO specifically: when someone asks Perplexity "find me a small business accountant in Leeds," the answer engine is trying to match entities to a category and a location. If your markup says Accountant with a areaServed field listing Leeds and surrounding postcodes, you're directly answering the machine's matching question. If you're marked up as generic LocalBusiness with no category specificity, you're relying on the engine to infer your specialism from prose alone — which it may or may not do correctly.

Service schema

Service markup breaks your offering into discrete, named units — VAT returns, self-assessment, payroll, R&D tax credits, Companies House filings, management accounts — each with its own description, provider link back to your Accountant entity, and ideally an areaServed. This matters because AI engines increasingly answer narrow, service-specific queries ("who does R&D tax credit claims near me," "accountant for Etsy sellers UK") rather than broad ones. A single undifferentiated "we do accounting" page gives an engine nothing to match against a specific query. Six or eight Service entries, each properly typed and linked to a corresponding page with real depth, gives the engine six or eight distinct hooks to cite you on.

Person schema

Person markup is what lets an engine attribute expertise to a named human rather than an anonymous "team." For a profession built on trust — where a prospect is choosing who signs off their accounts — this is not decorative. Mark up each partner or senior accountant with their name, job title, alumniOf (relevant for professional credibility), and crucially hasCredential or a clear textual statement of qualification: ACCA, ACA, CTA, ICAEW membership, CPA in the US. This is also where E-E-A-T (Google's experience-expertise-authoritativeness-trust framework) becomes machine-readable rather than just implied by a nice bio page.

Practical detail: Person schema should appear on author bylines of blog content *and* on the firm's about/team page, with the same identifiers used consistently. Inconsistent naming (e.g. "Sam Hoye" on one page, "S. Hoye ACMA CGMA" on another) weakens the entity match.

FAQPage schema

FAQPage markup structures question-and-answer pairs so engines can lift a direct answer verbatim. This is arguably the highest-leverage schema type for AEO because it mirrors exactly how people query AI assistants — in natural questions, not keywords. "Do I need to register for VAT if I'm a sole trader earning under £90,000?" as an FAQ entry, answered in two or three plain sentences, is close to ready-made for a ChatGPT or Google AI Overview citation.

The catch: FAQPage schema must match visible on-page content word-for-word or near enough. Google has been explicit that hidden or markup-only FAQ content that doesn't appear on the rendered page can lead to the rich result being suppressed, and increasingly, engines cross-check structured data against rendered text to catch exactly this pattern.

Article schema

Article (or more specifically TechArticle or NewsArticle where relevant) schema applies to your blog content, guides, and long-form explainers — this piece included, if you're a firm publishing your own. It carries datePublished, dateModified, author (linking to your Person entity), and publisher (linking to your Accountant/Organization entity). For AI engines weighing freshness and provenance — both of which matter more for finance content given HMRC and IRS rule changes — accurate date and authorship fields are a low-effort, high-value addition.

Review and AggregateRating schema

Review markup surfaces third-party trust signals — client testimonials, Google Business Profile ratings — in a structured form. Used honestly (aggregating real, verifiable reviews, not fabricated ones), this feeds directly into how confidently an AI engine will present you as a recommended option rather than merely a matching one. Google's guidelines are strict here: review schema tied to reviews that don't independently verify on a platform like Google Business Profile or Trustpilot risks manual action, so this is not a place to cut corners.

How do these schema types work together rather than in isolation?

The six schema types function as a linked graph, not six separate tags — each one should reference the others by @id so engines understand they describe one coherent entity. This is the part most WordPress plugin implementations get wrong: they generate technically valid schema for each page in isolation, with no shared identifiers connecting a Person to the Organization they work for, or a Service to the firm that provides it.

A well-built implementation looks like this conceptually: your Accountant entity has a permanent @id (typically your homepage URL with a fragment, like https://yourfirm.co.uk/#organization). Every Person entity includes a worksFor reference to that same @id. Every Service entity includes a provider reference to that same @id. Article schema's publisher field references it too, and its author field references the specific Person's @id. FAQPage entries can sit on Service pages, directly reinforcing that specific service's content. Review/AggregateRating attaches to the Accountant entity itself.

The payoff is that an engine encountering any single page on your site — a service page, a blog post, a team bio — can traverse the graph and understand the full context: this Person, with this credential, works for this Accountant, which offers this Service, in this location, with this review record. That's a materially richer entity profile than six disconnected schema blocks, and it's the difference between an engine treating your firm as a loosely related set of pages versus one coherent, citable entity.

What schema mistakes actually confuse AI engines?

The most damaging schema mistakes are inconsistency between structured data and visible content, duplicate or conflicting markup, and generic typing that fails to signal what the business actually does. Each of these actively works against you rather than being merely wasted effort.

Mismatched NAP (name, address, phone) data. If your schema says one phone number and your footer says another — often left over from an office move or a rebrand — engines treat this as a low-confidence signal about your identity and may deprioritise citing you as a local option entirely.

Schema that describes content not present on the page. Marking a page as FAQPage when the actual visible Q&A pairs are thinner or worded differently than the markup, or claiming Service details in schema that aren't explained anywhere in the body copy, is a direct violation of Google's structured data guidelines and increasingly gets ignored or penalised by other engines' crawlers too, since they cross-check against the rendered DOM.

Multiple conflicting Organization or LocalBusiness entities. This happens frequently after a WordPress theme change or plugin migration, where an old SEO plugin's schema wasn't fully removed and a new one was layered on top. The result is two different @id values both claiming to represent the same firm, which fragments your entity graph rather than reinforcing it.

Using generic types instead of specific ones. Organization instead of Accountant, Thing instead of Service, or omitting @type specificity altogether. Generic typing is valid schema — it just carries far less useful information, and specificity is what earns citation preference when an engine is choosing between several structurally similar competitors.

Missing or stale dateModified fields. For a profession governed by annually changing thresholds — the VAT registration threshold, ISA allowances, IRS mileage rates — an Article schema block with a datePublished from three years ago and no dateModified tells engines your content may be out of date, even if you've quietly updated the figures in the text.

Overloading a single page with irrelevant schema. Adding Recipe, Event, or Product schema to an accounting firm's homepage because a plugin defaults to it, or because "more schema is better" is a persistent myth. Irrelevant markup dilutes rather than strengthens the entity signal, and in some cases can trigger manual review flags in Google Search Console's Rich Results report.

Does schema replace the need for strong page content?

No — schema is a structured summary of content that must already exist in clear, visible, well-organised prose; it cannot substitute for thin or absent content. This is worth stating plainly because it's the most common reason firms invest in schema and see no return: they treat markup as the fix for a page that doesn't actually explain anything.

AI engines — ChatGPT via its browsing and retrieval layer, Perplexity's crawler, Google's AI Overviews, Gemini grounded in Search — are ultimately answering a user's question with the best available text they can find and verify. Schema tells them where to look and how to categorise what they find, but the actual answer still has to be written by a human, in plain language, at sufficient depth to be trustworthy. A Service schema entry for "R&D Tax Credits" pointing to a page with 80 words of vague marketing copy will not get cited over a competitor's page with 800 words that actually explains eligibility criteria, the claim process, and common HMRC rejection reasons — regardless of whose schema is more technically pristine.

The practical implication: prioritise the content work first. Write the FAQ answers in full, plain sentences before you ever ask a developer to wrap them in FAQPage markup. Build out genuinely distinct service pages before you generate Service schema for services that don't have a page at all. Schema amplifies what's there. It has nothing to amplify on a thin page.

What's a safe schema implementation checklist for a WordPress site?

For WordPress, the safest path is a dedicated schema plugin (Schema Pro, Rank Math's schema generator, or Yoast's structured data module) configured manually per type rather than left on full auto-detect, with every entity's @id checked for consistency. Concretely, here's what to ask a developer or in-house marketer to verify:

1. Confirm there is exactly one Organization/Accountant entity, with a stable @id, and audit for leftover schema from any previous plugin or theme that might still be firing.
2. Set NAP fields to match your Google Business Profile exactly — same phone format, same address, same trading name — since inconsistency here undermines both traditional local SEO and AI entity matching.
3. Add Person schema for every named partner or senior accountant, each with worksFor pointing to the firm's @id, and credentials stated in hasCredential or in the visible bio text the schema summarises.
4. Build individual Service entries for each real, distinct service (not one blanket "accounting services" entry), each with provider linking to the firm's @id and areaServed populated accurately.
5. Only apply FAQPage schema to pages where the Q&A content is fully visible, unaltered, and in the same wording as the markup — no summarised or edited-down versions in the schema itself.
6. Apply Article schema to every blog post and guide, with author linked to a specific Person @id, datePublished accurate, and dateModified updated any time figures or rules change (not just when prose is edited).
7. Connect Review/AggregateRating only to genuinely collected, verifiable reviews — pull from Google Business Profile or a review platform via API where possible, rather than hand-entering testimonials.
8. Validate every page type using Google's Rich Results Test and Schema.org's validator before publishing, and re-check quarterly, since plugin updates can silently alter output.
9. Check for duplicate schema blocks in page source (view-source or a browser extension like Schema Markup Validator) — a common WordPress issue is a theme, a plugin, and a manually added script all outputting overlapping JSON-LD.
10. Keep a single source of truth for firm details (name, address, credentials, service list) that both your CMS and your schema pull from, so a change in one place propagates rather than needing manual updates in six.

What's different for a custom-built website?

On a custom site, schema needs to be maintained as versioned code with the same rigor as any other production dependency, since there's no plugin auto-updating it for you. The checklist items above still apply, but the implementation detail shifts:

• Schema should live in a shared template/component (for Organization, Person, and Service data that appears across many pages) rather than being hand-copied into each page's HTML — hand-copied JSON-LD is the single most common source of the NAP-mismatch and stale-date problems described above.
• Assign clear ownership: someone on the dev or content team should be responsible for updating dateModified whenever a page's factual content changes, ideally triggered automatically by your CMS's last-modified timestamp rather than relying on memory.
• Run automated schema validation as part of your deployment pipeline (a pre-deploy script checking for valid JSON-LD and required fields) rather than only checking manually after launch.
• If the firm operates across multiple jurisdictions (UK and US, for example), maintain separate Accountant/LocalBusiness entities per registered office rather than one entity trying to serve both, since areaServed and address fields can't meaningfully represent two different regulatory jurisdictions in a single entity.

What should a firm owner actually ask a developer to do?

Ask your developer to implement Accountant, Service, Person, FAQPage, Article, and Review schema as one interlinked graph — not six separate scripts — and to validate every page against Google's Rich Results Test before and after any theme or plugin change. If a developer proposes "adding schema" as a single line-item task without asking what content already exists to summarise, that's a signal they're planning to auto-generate markup rather than build a genuine entity graph — and it's worth pausing to have the content-first conversation described above before any code gets written.

The honest summary: schema is necessary infrastructure for AI search visibility, not a growth lever on its own. Get the content right first — clear service pages, real FAQ answers, named and credentialed team members, genuine reviews — then have it properly, consistently marked up. Firms that do both in that order are the ones showing up when someone asks ChatGPT or Perplexity to recommend an accountant.