How to test your law firm schema before it goes live

Before your schema goes live, run it through three checks: validate the syntax so the code is well-formed, confirm rich-result eligibility so you know what it qualifies for, and verify the markup actually renders in the HTML a crawler receives. That third one catches the failure almost nobody looks for, because the most common schema problem on law firm sites isn't broken markup. It's valid markup that never makes it onto the page at all.

Schema is cheap to add and easy to get subtly wrong, and a wrong or absent block does nothing for you while looking, from your CMS dashboard, like it's working. Here are the three tests that catch it before it costs you.

Why do you need to test schema before it's live?

Because you can't see schema by looking at your page, and a mistake is invisible until you check for it. Malformed JSON-LD can silently fail, the wrong type can cost you rich-result eligibility, and schema that renders in your CMS preview but not in the live HTML does nothing while appearing to be present. None of this shows up visually. The page looks fine either way.

That invisibility is the whole reason testing matters. With most of your site, a broken thing looks broken: a mangled layout, a dead link, a missing image. Schema fails quietly. Your practice-area page can carry beautifully written LegalService markup that a single stray character has invalidated, and you'd never know from looking at it. The only way to know your markup is doing its job is to test it deliberately, before it ships and again whenever the site changes.

How do you validate the syntax?

Run the code through the Schema Markup Validator, the tool maintained at validator.schema.org. Paste your URL or the JSON-LD directly, and it parses the markup and flags structural errors: missing brackets, invalid property names, malformed values. If the validator throws errors, an engine reading your page will trip over the same problems.

This is the first gate because syntax errors break everything downstream. A single missing comma or unclosed brace can invalidate an entire schema block, and JSON-LD is unforgiving that way. The validator is vocabulary-agnostic, meaning it checks that your markup is well-formed schema.org, whether or not Google shows a rich result for it. Clear its errors first, then move on to the question of what the markup actually earns you.

How do you check rich-result eligibility?

Use Google's Rich Results Test at search.google.com/test/rich-results. Enter your URL and it tells you which rich-result enhancements the page qualifies for based on the markup it detects. It's the check that connects your schema to something Google might actually display, rather than just confirming the code is valid.

Keep your expectations calibrated, though, and this is the FirmForte stance we hold everywhere: schema is hygiene and rich-result eligibility, not a lever that makes an engine rank or cite you. The Rich Results Test confirms you're eligible for enhancements and that Google can parse your markup cleanly. It does not promise a rich result will appear, and it certainly doesn't promise a citation. What it does give you is confidence that the legibility layer is correct, so that when your content earns attention, nothing in the markup is getting in the way.

How do you confirm the schema is actually on the page?

Look at the raw HTML a crawler receives, not the page your browser assembles. This is the check that catches the most common and most frustrating failure: schema that exists in your CMS or a plugin's settings but never renders into the HTML an engine reads, usually because a builder or plugin injects it in a way crawlers don't pick up.

The quickest way to verify is a tool that fetches your page the way a bot does and shows you what's actually in the response. Our crawler's-eye view tool does this, and it's free: if your schema block is present in that view, it's really on the page; if it's missing, your markup is living somewhere a crawler never sees. This is the exact trap that catches DIY-builder and locked-platform sites, where the schema you configured never quite makes it into the served HTML, which we get into in why website builders hurt law firm AI search. Valid markup in the wrong place is the same as no markup.

What order should you run the checks in?

Syntax first, eligibility second, on-page presence third, because each one only makes sense once the prior gate is clear. There's no point asking whether Google shows a rich result for a block that doesn't parse, and no point confirming eligibility for markup that never reaches the page. Work the checks in that order and each result is easy to read: a failure tells you exactly which layer broke.

The practical loop looks like this. Draft or generate your markup, then paste it into the Schema Markup Validator and clear every structural error before you do anything else. Once it parses clean, run the same page through Google's Rich Results Test and read what it says you're eligible for, so your expectations match what the markup actually earns. Then publish to a staging URL or a preview deployment and fetch that page the way a crawler would, confirming the block is present in the served HTML rather than only in your CMS. If all three pass on staging, you ship with confidence. If any one fails, you know which tool to go back to and roughly where the problem lives, instead of guessing.

One nuance worth holding onto: the first two checks can be done against pasted code, but the third can only be done against a real served page. That's why the on-page check comes last and why it's the one people skip. It's the only test that needs a live or staged URL, so it's the easiest to postpone and the most likely to catch you out.

What does a real check look like?

Here's an illustrative walkthrough, not a real client, to make the loop concrete. Say a firm adds LegalService markup to its personal-injury practice page through a plugin. In the Schema Markup Validator, the block parses with no errors, so the syntax gate is clear. In the Rich Results Test, Google reports it can read the markup and the page is eligible for the enhancements that type supports, so eligibility checks out too. On the first two tools, everything looks done.

Then they fetch the served HTML the way a crawler does, and the LegalService block isn't there. The plugin was injecting it through a script that ran in the browser but never made it into the response a bot receives, so the markup the validators saw was the pasted code, not what the live page actually serves. Two green checks, and the schema still wasn't on the page. That gap between what a validator confirms about your code and what a crawler receives from your server is the exact failure the third check exists to catch, and it's why pasting code into a validator is never the whole test.

What are the most common schema mistakes to catch?

A handful of recurring ones account for most of the failures worth catching before launch:

• The wrong @type. Using deprecated Attorney or bare LocalBusiness instead of LegalService, which we work through in LegalService vs Attorney vs LocalBusiness schema.
• NAP that doesn't match. A name, address, or phone in your schema that disagrees with your site, your Google Business Profile, or your directory listings.
• Invalid JSON-LD. A stray character or missing bracket that quietly invalidates the whole block.
• Present in preview, absent in the live HTML. The plugin-injection failure above, and the one people miss most.
• Marking up content that isn't on the page. Schema should describe what's actually visible; claiming things the page doesn't show is a guideline violation.

What's the pre-launch checklist?

Run through this before any page with schema goes live. It's the three checks plus the details that catch the failures above:

• The JSON-LD parses clean. No errors in the Schema Markup Validator, on the actual page or block you're shipping.
• The @type is right. LegalService for a firm, not deprecated Attorney or bare LocalBusiness.
• The page is eligible for what you expect. The Rich Results Test reads your markup and reports the enhancements the page qualifies for, with no blocking errors.
• The block is in the served HTML. You've fetched the page the way a crawler does and confirmed the schema is really there, not just in your CMS.
• NAP matches everywhere. Name, address, and phone in the schema agree with your visible page, your Google Business Profile, and your directory listings.
• The markup only describes what's on the page. Nothing claimed in schema that a visitor can't actually see.

Six lines, and every one maps to a failure that's invisible until you check for it. A page that clears all six is machine-readable and eligible, which is exactly what schema is for and the honest limit of what it does. It doesn't buy you a ranking or a citation. It removes the legibility problems that would otherwise hold you back, so nothing in your markup is working against you when your content earns attention. If you want the underlying types sorted before you start testing, our AEO service handles the whole legibility layer, and the SEO work covers the content and signals that testing alone can't.

How often should you re-test?

After any change that touches your templates, CMS, or hosting, not on a schedule. Schema isn't something you tend weekly, but a theme update, a plugin change, or a platform migration can silently strip or break it, and you won't see it happen. Re-run the three checks after any structural change to the site.

The rhythm, then, is: test thoroughly before launch, then again after anything that could have moved the underlying code. Once it's validated, eligible, and confirmed present in the served HTML, leave it alone until the next site change. Getting the type right in the first place is covered in the seven schema types every law firm website needs, and if you'd rather generate clean, valid markup to start from, our law firm schema generator builds it for you. To have the whole thing audited on your live site, the free audit includes a schema check, and every site we build ships with the full set correct and confirmed present from launch through our AEO service.