Schema for accounting firms in AI search: what actually matters

Schema for accounting firms in AI search: what actually matters

Schema markup does not make ChatGPT, Perplexity, or Google AI Overviews cite your accounting firm. It makes it easier for those engines to *understand and trust* the content you've already written well. If the underlying page content is thin, generic, or vague about who you serve, no amount of structured data will fix that. Get the content right first, then use schema to remove ambiguity for machines reading it.

That's the correct mental model for this whole topic, and it's the one most "add JSON-LD to your site" advice skips. This guide covers which schema types actually move the needle for an accounting firm trying to show up in AI answers, how they connect to each other, where firms typically get it wrong, and a checklist you can hand to a developer without needing to write code yourself.

Why does schema matter for AI search at all?

Schema matters because large language models and AI answer engines pull from a mix of crawled text, structured data, and third-party trust signals — and structured data disambiguates facts that plain prose can leave fuzzy. When ChatGPT's browsing tool, Perplexity, or Google's AI Overview system crawls a page, it's trying to extract discrete facts: who is this firm, what services do they offer, where are they located, who leads the team, what do clients say, what question does this article answer. Well-formed schema answers those questions in a machine-readable format that sits alongside your visible text.

This is different from classic SEO, where schema mainly earned you rich results — star ratings, FAQ dropdowns, sitelinks. AI engines use structured data more aggressively as a confidence signal. A LocalBusiness entity with consistent name, address, and phone (NAP) data across your site and citations (Companies House listing, ICAEW or ACCA firm directory, Google Business Profile) helps an engine resolve "who is this business" with less ambiguity — which matters when it's deciding whether to name you in an answer to "best accounting firm for contractors in Leeds" or "R&D tax credit specialists near me."

The direct answer: schema is a trust and disambiguation layer, not a ranking hack. Firms that pair clean schema with genuinely specific, well-organised content get cited more often than firms that do either alone.

Which schema types actually matter for an accounting firm?

Six schema types cover nearly everything an accounting firm needs for AI visibility: Accountant (or LocalBusiness/ProfessionalService), Service, Person, FAQPage, Article, and Review/AggregateRating. Everything else — BreadcrumbList, Organization, WebSite with sitelinks search box — is useful housekeeping but secondary.

Here's what each one does and why it's on the list.

Accountant / LocalBusiness / ProfessionalService. Schema.org has a specific Accountant type (a subtype of LocalBusiness and ProfessionalService). It lets you declare your firm name, address, phone, opening hours, price range, geo-coordinates, and areas served in one structured block. This is the anchor entity everything else attaches to. If you serve multiple locations, each location should ideally have its own page with its own Accountant markup rather than one generic block stretched across the whole site.

Service. Each core service line — tax planning, audit, bookkeeping, payroll, R&D tax credits, business advisory — should have its own page with Service schema describing what it is, who it's for, and which provider (your firm) offers it. This is where AI engines pick up the specificity that makes them confident enough to recommend you for a narrow query like "outsourced payroll for hospitality businesses" instead of a generic "accounting services."

Person. Every named partner, director, or senior accountant who authors content or is presented as a point of contact should have Person schema, ideally linked via sameAs to their LinkedIn profile and any professional body listing (ICAEW, ACCA, AICPA, CIMA). This matters more than most firms realise: AI engines weigh author credibility when deciding whether to surface advice-style content, and a named, verifiable qualified accountant behind an article is a stronger signal than "Admin" or no byline at all.

FAQPage. FAQ schema marks up literal question-and-answer pairs on a page — "Do I need to register for VAT if I'm a sole trader?", "What's the deadline for Corporation Tax filing?" This format maps almost exactly onto how people phrase prompts to ChatGPT and Perplexity, which is why FAQ-structured content gets lifted into AI answers disproportionately often. Google has restricted rich-result display of FAQPage for most sites, but the schema still helps AI crawlers parse question/answer structure — display in Google's SERP and usefulness to LLM crawlers are two separate things.

Article. Blog posts, guides, and insight pieces should carry Article (or BlogPosting) schema with author (linked to your Person markup), datePublished, dateModified, and publisher. AI engines use dateModified as a freshness signal — an article that hasn't been technically "modified" in three years, even if still accurate, is less likely to be trusted for time-sensitive topics like tax thresholds or filing deadlines.

Review / AggregateRating. Genuine client reviews, marked up correctly, feed the same trust evaluation that influences whether an engine treats your firm as a credible recommendation. Never fabricate or bulk-generate review markup — this is one of the fastest ways to get flagged by Google's structured data guidelines and it erodes the exact trust signal you're trying to build.

How do these schema types work together?

They work together as a connected graph, not six isolated tags — each type should reference the others by @id so engines can traverse the relationships instead of treating each block as a standalone claim.

Picture the structure like this: your Accountant entity sits at the centre. It has a member or employee relationship to Person entities (your partners and staff). It makesOffer or is linked via provider to your Service entities. Your Article content has author pointing back to a Person, and publisher pointing back to the Accountant/Organization entity. Review and AggregateRating attach directly to the Accountant entity or to specific Service entities if you're collecting service-specific feedback. FAQPage markup usually lives on service or resource pages and doesn't need to reference the other entities, but its content should logically reinforce what the Service schema already claims.

This is the part developers get wrong most often: they implement each schema type in isolation, copy-pasted from a generator tool, with no shared @id references. The result is six technically valid blocks of JSON-LD that Google's Rich Results Test will pass individually, but that describe six disconnected things rather than one coherent entity. AI engines building an internal knowledge representation of your firm benefit far more from a connected graph than from valid-but-isolated fragments.

Ask your developer directly: "Are our schema entities linked by @id, or are they separate blocks?" If they don't know what you mean, that's a useful signal about the quality of the original implementation.

What are the most common schema mistakes that confuse AI engines?

The most common mistake is markup that describes something the visible page doesn't actually say — schema making claims that aren't backed up in plain text. This is sometimes called schema spam, and it's the single biggest reason structured data hurts more than it helps. If your Service schema says you offer "same-day VAT registration" but that phrase appears nowhere in the visible copy, you've created a mismatch between what a crawler infers structurally and what it extracts textually. AI engines cross-check these two signals, and mismatches reduce confidence in the whole page.

Six other mistakes show up repeatedly on accounting firm sites:

Inconsistent NAP data. Your address on the schema doesn't match your Google Business Profile, which doesn't match your Companies House registered office, which doesn't match your ICAEW directory listing. Each inconsistency is a small trust deduction. Audit these four sources side by side and fix mismatches before doing anything else.

Generic Organization markup instead of Accountant. Using bare Organization schema when Accountant (or at minimum ProfessionalService) is available means you're giving up specificity for no reason. The more precise type is the one that helps an engine categorise you correctly against a query like "accountant near me."

One giant LocalBusiness block for a multi-office firm. If you have offices in Manchester, Bristol, and London, one schema block listing all three addresses under a single entity confuses location-based queries. Each location needs its own page and its own entity.

FAQ schema stuffed with questions nobody actually asks. Marking up ten FAQ pairs that exist purely to target keywords, rather than genuine client questions, reads as manipulative to both Google's spam systems and to any LLM cross-referencing the FAQ against the rest of the page. Keep FAQ content to real questions your team fields from clients.

Missing or stale dateModified. A datePublished from 2022 with no dateModified field tells engines nothing about whether your Corporation Tax rate guidance or your dividend allowance figures are still current. For any page referencing thresholds, rates, or deadlines, update the content and the dateModified field whenever HMRC or the IRS changes a figure — not just on an annual refresh schedule.

Review schema with no visible reviews on the page. AggregateRating markup should correspond to reviews a human visitor can actually read on that page or a clearly linked page. Structured ratings floating with no visible source are a red flag under Google's structured data guidelines and offer no verification path for an AI engine either.

Does schema replace the need for strong page content?

No — schema has no independent value if the visible content is weak, and AI engines increasingly cross-reference structured claims against the actual text before deciding what to trust. Think of schema as a translation layer, not a content substitute. It tells a machine "this paragraph is answering the question 'what is R&D tax relief,'" but it doesn't make the paragraph itself good.

What still has to be true regardless of your schema implementation:

• The page needs to answer the specific question a prospect would ask, in plain language, near the top of the content — not buried under three paragraphs of firm history.
• Service pages need real specificity: which industries, which company sizes, which jurisdictions, what the engagement actually involves. "We handle accounting for small businesses" gives an AI engine nothing to differentiate you from ten thousand other firms with the same sentence.
• Author credentials need to be visible in the text, not just encoded in Person schema. A line like "Written by Priya Shah ACA, tax director with 12 years advising owner-managed businesses" does double duty — it's readable by humans and reinforces exactly what the schema is asserting.
• Freshness has to be real. Updating a dateModified timestamp without actually changing the content is the kind of gaming that structured-data audits (and increasingly, LLM training and retrieval pipelines) are getting better at detecting.

Firms that treat schema as a checkbox exercise — bolt it on, never touch the content — tend to plateau. Firms that use the schema audit as a forcing function to also tighten up their content tend to see the compounding effect: better content plus correctly connected schema is what actually earns citations in ChatGPT, Perplexity, and AI Overviews.

What should a safe schema implementation checklist look like?

A safe implementation prioritises accuracy and consistency over volume — a handful of correctly connected schema types on your real content beats a comprehensive schema library implemented against thin pages. Use this checklist whether you're on WordPress or a custom-built site; the questions to ask a developer are the same, only the delivery mechanism changes.

Before any implementation:

• Confirm your firm's legal name, trading name, address, and phone number are identical across your website, Google Business Profile, Companies House record, and any professional body directory (ICAEW, ACCA, AICPA, CIMA, or state board listings for US firms).
• List every named person who will be credited as an author or listed as a service contact, along with their professional qualification and a link to a verifiable profile (LinkedIn, professional body member page).
• List every distinct service line that has, or should have, its own dedicated page.

Core entity setup:

• Implement Accountant (or ProfessionalService if Accountant isn't fully supported by your platform) on the homepage or a dedicated "About" page, with full NAP, opening hours, and sameAs links to your Google Business Profile, LinkedIn company page, and professional body listing.
• If you operate multiple locations, create a dedicated page per location, each with its own Accountant/LocalBusiness entity and unique address.
• Link every Person entity to the main organization entity via @id reference, not just by name.

Service and content layer:

• Implement Service schema on each core service page, with provider pointing back to your organization entity via @id.
• Add Article/BlogPosting schema to every guide, insight, or news post, with author linked to a real Person entity and both datePublished and dateModified kept current.
• Add FAQPage schema only where the visible page contains a genuine, readable FAQ section — never inject hidden or off-page FAQ content purely for schema purposes.

Trust layer:

• Add Review and AggregateRating schema only where real, verifiable client reviews are visible on the page or clearly linked from it.
• If you display third-party review platform scores (Google, Trustpilot, industry-specific directories), pull them via the platform's own verified integration rather than hand-typing numbers into JSON-LD.

Validation and maintenance:

• Run every template through Google's Rich Results Test and the Schema.org validator before publishing — a technically invalid schema block can be worse than none, since it can be silently ignored or, in some cases, flagged.
• Re-audit NAP consistency and dateModified accuracy quarterly, particularly on pages referencing tax rates, thresholds, or filing deadlines that change with HMRC or IRS updates.
• Keep a single source-of-truth document (a shared sheet or CMS field set) listing every entity's @id, so future developers extend the same graph instead of creating parallel, disconnected schema blocks.

Platform-specific notes:

On WordPress, a schema plugin (Yoast, RankMath, or Schema Pro are the common choices) can generate most of this automatically, but default plugin output rarely includes the @id cross-referencing described above — you will likely need a developer to customise the plugin's schema templates or add supplementary JSON-LD manually to get a properly connected graph. On a custom-built site, this is typically handled through a templating layer that injects JSON-LD server-side per page type; ask your developer to show you the shared schema component library rather than per-page hardcoded blocks, since hardcoding invites drift and inconsistency over time.

What should you check first if you're not sure where your firm stands?

Start by viewing page source (or using a browser's "view page source" function) on your homepage and your three highest-traffic service pages, and search for application/ld+json — if you find nothing, you have no structured data at all, which is a faster fix than a bad implementation. If you do find JSON-LD, check whether it includes @id fields that appear in more than one block; if every block has its own disconnected @id or none at all, you have the isolated-fragment problem described above, and that's the priority fix before adding anything new.

The firms getting cited by ChatGPT, Perplexity, and Google AI Overviews right now aren't the ones with the most exotic schema types installed. They're the ones whose structured data accurately reflects specific, current, well-authored content — and whose entity data is consistent everywhere a machine might look for it.