Schema, Structured Data, and Your Credit Union

Just becuase your rates are public, it doesn't mean AI search can easily read them. How to structure credit union content for maximum crawlability. 

Let me present a situation that is not inherently unique to a community bank or credit union, but still presents a very unique situation.

A human person is looking to buy a used car. They are looking for two things: a specific vehicle, and the loan they’ll use to purchase that vehicle. They may eventually speak to a human salesperson at a used car lot, just as they may eventually speak to a human at a credit union or community bank to begin the loan process. But right now, they’re just … looking.

And that looking is happening completely separate from everything. They have opened a chatbot and asked a question:

"What's a good auto loan rate right now, and who near me offers it?"

The answer comes back quickly and confidently. Maybe it names the big bank across town, or quotes a national average. Or, maybe it rattles off a rate that was true two weeks ago. One thing is for sure: despite your website showing current and competitive rates for anyone to read, your credit union or community bank did not show up.

This is the new world of search. Your rates aren’t a secret — anyone can find them, if they look. It’s just that “anyone” now includes machines, and machines don’t read the way people do.

Structured data helps with meaning.

When organizations worry about not showing up in AI search, they usually assume it’s a content problem — that they need to write more articles about a topic, or find a hyper-unique angle within that topic to be found and remembered. Partially, that’s true! As we get to know more about how AI-assisted search tools work, all of the signs point to real content for real humans still carrying the biggest benefits for being found.

There’s another side to content that, in the midst of writing and editing and publishing, we often forget: structure. The words we write mean something to humans, and the robots in our AI machines know those words mean something to humans — but they don't read for meaning the way we do. They're strong at spotting patterns and much weaker at the context we take for granted. So we need to help provide that context.

This is where schema comes in. A person reading a page about loans for used cars understands that “5.99% APR, 60mo., rates as low as…” describes the best-case rate on a five-year used car loan. An answer engine doesn’t. To a machine, “5.99” is just a number near some words. It has to guess whether that’s the rate, the fee, the minimum, or something it should just totally ignore.

Schema is how you stop making AI search guess. As a shared vocabulary maintained via schema.org, schema provides context, so a crawler doesn't have to infer that "5.99" is an annual percentage rate — you've told it directly. Schema doesn't teach a machine to understand language, but it removes the ambiguity so the machine can read your numbers the way you meant them.

The scope and compliance of financial service schema.

Do a search on determining the right schema for your site and you’ll find a lot of the same answers — Organization, LocalBusiness, Article, and a few others that apply to nearly any site. But schema.org includes a relatively deep suite of schema for specific industries and situations that you wouldn’t need to worry about if you were building a general content site or an online store. One of those industries is financial services and, specifically, financial products.

Financial products are different in three ways that make schema both more valuable and more specific.

First, financial products are precise. A rate is a regulated number, so it requires a level of precision — and that precision is important because answer engines want to quote facts and figures. Your product pages hold some of the clearest factual information you publish, so getting those numbers right matters.

Second, financial products change. And they change a lot. Rates move weekly, or fees change based on a business decision, or a product retires. This means structured schema can’t be stale. Structured data that was accurate in March and never touched since may now be giving incorrect information to answer engines.

Finally, as an extension of the first point: all financial services are regulated. Just as disclosure requirements impose a kind of structure on how you present rates and terms in general, good schema should line up with those disclosures, not contradict them. In fact, this is a place where sloppy structured data is worse than none at all — if your schema says one APR and your disclosure says another, you've created a compliance problem.

In other words, for a credit union, structured data is both an SEO tactic and an extension of your organization's compliance model. So let’s take a look at both of those things: the schema that’s unique to you as a credit union, and the work needed to keep that schema up to date.

Unique schema for financial products.

Schema.org has a dedicated set of types for financial services. You don't need all of it, but you will want the handful that matches what your credit union offers. Here's how the real products line up:

• A credit union has its own “Organization” type — BankOrCreditUnion — that is built specifically for crawlers to understand that related content is tied to a financial institution. The BankOrCreditUnion schema carries your name, address, contact info, and website URL. It’s the entity your product pages point back to.
• Auto loans, personal loans, mortgages, and home equity lines of credit (HELOCs) have their own unique schema: LoanOrCredit (with MortgageLoan as a more specific type for home loans). The properties that matter here are annualPercentageRate for the APR, interestRate for the base rate, loanTerm for the length, and amount for the loan amount. Note that schema.org treats APR and interest rate as two different things — because they are — so you can express both without confusing them.
• Credit cards use CreditCard, which includes fields for describing annualPercentageRate, feesAndCommissionsSpecification for the fee structure, and gracePeriod.
• Checking and savings accounts use BankAccount and DepositAccount, with feesAndCommissionsSpecification for monthly fees and interestRate where it applies.
• Share certificates and money markets use DepositAccount (which sits under InvestmentOrDeposit), with interestRate and amountfor the minimum to open.

You express a rate range — for things such as "as low as" pricing ranges — with a QuantitativeValue that carries a minValue and maxValue, so verbiage such as "rates from 5.99% to 10.61% APR" becomes something parsable by a web crawler.

Whew, that’s a lot. Don’t worry — the point isn't to memorize property names, but to understand that a schema set already exists for every product at your organization. Rather than inventing structure, you’re applying structure that has already been vetted and designed in part by financial institutions themselves.

A note on accuracy: These type and property names are current as of writing, verified against schema.org. Before implementation, your development team should validate the final markup with schema.org's validator, and use Google's Rich Results Test only to confirm the specific things Google supports. Keep in mind that most financial product schema won't produce a Google rich result at all — valid, correct markup and a visible rich result are two different things. The vocabulary is also a working document that still sees periodic revisions, so plan to re-check over time.

Beyond rates: answering member questions.

Structured data isn't only for numbers and products. Because answer engines are usually trying to find answers to a human’s question, financial services sites with structured FAQ content have a leg up on those that don’t.

If you followed the content strategy space in the mid-10s, this is close to heresy. We hated FAQ, because FAQ was shorthand for “here’s all the crap we couldn’t find a place for on the site.” We said “FAQ doesn’t actually represent frequently asked questions, ya goobers.”

Well, things have changed. 

As we just said, answer engines want to find answers, which means they’re looking for questions that match the user’s question. In other words, FAQs are now all shifting back toward what us content strategists had hoped for in the beginning: actual frequently asked questions.

That’s the trick! Financial institution FAQs only work if they answer the questions members really ask, not the ones you wish they'd ask. Things like "What credit score do I need for an auto loan?" or "How long does it take to close a HELOC?" or "Can I join if I don't live in the county?" These are real questions with real answers, and when you mark them up with FAQPage schema, you're telling the answer engine that the text in that accordion is a vetted answer to a common question.

While we’re here, let’s touch on Google itself: the old rich result FAQ dropdowns that Google used to highlight are going away as of May 2026. However, the markup is still worth adding — FAQPage is a valid schema type. Google still reads it to understand your page, and the crawlers behind AI answer engines and other search engines still use it to match a question to its answer.

And if you’re looking at this and wondering how you know which questions are the most frequent, the answer is already on board: FAQ aren’t “content” as much as they’re “customer services.” FAQ and plain ol’ member service are parts of the same member experience process. Content that helps a member get an answer is content an answer engine wants to surface.