Schema markup for financial firms

Schema markup is a block of structured data in your page's <head> that states, unambiguously, what your firm is: its type, services, location, and credentials. It won't get you cited on its own — but it removes the guesswork at the grounding step, so when an engine does find you, it reads you correctly. Here's the right type and a block you can paste.

Pick the right type

schema.org has specific subtypes for professional firms. Using the precise one tells a retrieval system exactly what category you belong to — which is the whole point.

Firm	schema.org @type	Note
RIA / financial advisor / wealth manager	`FinancialService`	The general financial-services type; use for planning and investment firms
Accounting / CPA firm	`AccountingService`	A subtype of FinancialService; more specific is better
Law firm / estate planning	`LegalService` or `Attorney`	Use `Attorney` for a solo/named practitioner
Insurance	`InsuranceAgency`	Subtype of FinancialService
Any local office generally	`ProfessionalService`	The safe fallback if none fit cleanly

Prefer the most specific type that's accurate. AccountingService beats FinancialService for a CPA firm; both beat the generic LocalBusiness.

A validated FinancialService block

Paste this inside a <script type="application/ld+json"> tag in your homepage <head>, and replace the values with your firm's real details. This exact structure parses cleanly — the diagnostic's fix pack refuses to ship JSON-LD that doesn't JSON.parse(), and you should hold yourself to the same bar.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FinancialService",
  "name": "Bluff Creek Advisors",
  "url": "https://bluffcreek.com",
  "description": "Fee-only registered investment advisor providing flat-fee financial planning for physicians and dental practice owners.",
  "areaServed": { "@type": "City", "name": "Austin" },
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "500 W 2nd St, Suite 1900",
    "addressLocality": "Austin",
    "addressRegion": "TX",
    "postalCode": "78701",
    "addressCountry": "US"
  },
  "telephone": "+1-512-555-0100",
  "priceRange": "$$$",
  "knowsAbout": [
    "fee-only financial planning",
    "physician wealth management",
    "flat-fee fiduciary advice"
  ],
  "hasCredential": "SEC-registered investment adviser"
}
</script>

The fields that actually earn their place

Most of the ambiguity a model has about a firm is resolved by four fields. Prioritize getting these exactly right over adding a dozen optional ones:

@type — the single highest-value field. It puts you in the right category before a word is read.
description and knowsAbout — state your specialty and fee model in the buyer's language ("fee-only," "physicians," "cross-border tax"). These are the phrases that match a prospect's fan-out queries. Mirror your real positioning; don't keyword-stuff.
areaServed + address — locality is decisive for "near me" and city-scoped questions, which is most of them.
hasCredential — "SEC-registered," "CFP®," "CPA," "state bar admission" are trust anchors a model can ground on. State only what's true and verifiable.

Keep it compliant

Structured data is factual metadata, which is exactly why it's safe for regulated firms — but two rules still apply:

No aggregateRating or review markup for RIAs and, in most states, for attorneys. Marking up reviews can pull them into your presentation in ways the SEC marketing rule or a state bar restricts. Leave rating/review types off entirely; the score you're chasing is presence, not stars.
No superlatives or performance claims in description. "Fee-only fiduciary advisor," yes. "Top-performing," no.

Validate before it ships

Two checks, both quick:

Does it parse? Paste the JSON (without the script tags) into any JSON validator. If it doesn't parse, an engine won't read it. This is non-negotiable — invalid JSON-LD is worse than none, because it can poison the whole block.
Does it match reality? Run it through Google's Rich Results Test or the schema.org validator to confirm the type resolves and the fields are recognized, then read it back against your actual firm details.

Schema is a grounding aid, not a citation source. It helps a model that already found you describe you correctly — necessary, not sufficient. The citations themselves come from third-party surfaces, and whether any of this moved your number is a question only re-measuring answers.

Get schema built and validated for your firm — inside the diagnostic.

The paid report generates a typed, QC-checked JSON-LD block from your real positioning (it won't ship if it doesn't parse), alongside your llms.txt and the third-party action plan. Run the free scan first to see whether you need it.

Get my free scan Full diagnostic — $490