QBiz Leads AI

AI Visibility · 9 October 2026

By , Founder

Structured Data Testing Tools for Law Firm Websites: Setup and Validation Guide

Legal

Same report, two verdicts

A rich result status report listing two item types. LegalService carries one non-critical issue and is badged valid with a warning. FAQPage carries one critical issue and is badged invalid with an error. Two annotations point at the badges: the first records that the item is still eligible to appear because no critical issue is attached to it, the second that the item is prevented from appearing because one critical issue is enough.
One report, two rows, and only one of them has to be fixed before the page can appear. Telling them apart is the first thing a test is for.

Summary

A law firm's structured data can look correct in the page source and still fail every test that matters. Two free tools check it properly: Google's Rich Results Test and the Schema Markup Validator. Run your URL or code through both. The Rich Results Test tells you whether Google can use the markup for a rich result and flags critical errors against non-critical warnings. The Schema Markup Validator extracts the markup, shows the structured data graph it found, and identifies syntax mistakes against schema.org itself. For a law firm, the types worth checking are LegalService (not the deprecated Attorney type), LocalBusiness properties, FAQPage, and Review or AggregateRating, each with its own rule for what counts as valid.

Short version

Clean, parseable structured data does not move your Google ranking on its own. Google states plainly that a structured data problem affects rich-result eligibility, not ranking. What it does do is give AI systems and search engines an unambiguous set of facts about your firm, which is one of the concrete mechanisms behind getting identified and cited correctly by AI search tools. Test with both validators, fix every critical error, and treat clean markup as the floor, not the finish line.

A law firm's schema can pass a casual glance at the page source and still be worthless to Google. The markup might reference a field that no longer exists on the page. It might sit in a block of JSON with one missing comma, which breaks the whole object rather than just one line. It might describe a FAQ section that was removed from the page six months ago. None of these show up by eye. All of them show up the moment you run the right tool.

This guide walks through how to actually test structured data on a law firm website: which tools to use, which schema types matter for a legal practice, the errors that quietly break markup, and what a clean result does and does not get you.

Which tool actually tests structured data?

Two free tools cover this job, and they check different things, so use both rather than picking one.

Google's introduction to structured data names the Rich Results Test as the standard validation step: "the Rich Results Test is an easy and useful tool for validating your structured data, and in some cases, previewing a feature in Google Search." The same page sets two checkpoints: the Rich Results Test "during development", and the Rich result status reports "after deployment", because a page can break once it is live through templating or serving changes.

The Rich Results Test accepts either a live URL or a pasted code snippet. A URL test shows you what Google's crawler actually sees on the rendered page, which catches a class of error a code paste cannot: markup injected by a template that never reaches the final HTML, or a JavaScript framework that renders the schema client-side in a way the crawler cannot see. Pasting code is faster for checking a block before it goes live, but it only proves the code itself is valid, not that it will reach Google in that form on the real page.

Choosing an input

What each input mode leaves unproven

The two input modes of the Rich Results Test, and what each one leaves unproven Two panels side by side. The left panel, pasted code, is marked as proving that the snippet itself parses, and as leaving unproven whether that markup survives into the page a crawler receives. The right panel, live URL, is marked as proving what the crawler receives from the rendered page, and as leaving unproven whether an unpublished block will survive the same journey. A footer notes that Google sets a checkpoint for each one, the test during development and the status reports after deployment. INPUT: PASTED CODE Checks the block you hold PROVES The block is well formed and its types resolve. LEAVES OPEN Whether the page ever serves that block in that shape. A template can drop it and a script can add it too late. INPUT: LIVE URL Checks the page as served PROVES What the crawler receives from the rendered page. LEAVES OPEN Whether a block you have not published yet would survive the same journey intact. GOOGLE SETS A CHECKPOINT FOR EACH The test "during development", the status reports "after deployment".
Neither input is the thorough one. Each closes a different gap, which is why a block that validates before release is still worth retesting from its published address.

What "pass" and "fail" actually mean

Google Search Console's rich result reports split every structured data item into two categories, and the distinction matters more than it sounds. "A valid item is an item that doesn't have any critical issues and can appear on Google as a rich result. An invalid item has at least one critical issue preventing it from appearing as a rich result."

Underneath that split sit two tables: critical issues that prevent your structured data from being used at all, and non-critical issues that Google separately describes as items to "improve item appearance." A critical issue is a stop. A non-critical issue is a quality note you can act on later without losing eligibility.

That distinction answers the question underneath it: does a warning in the Rich Results Test mean your schema is broken? No. If the tool shows the item as valid with warnings attached, Google can still use it. Fix the warnings when you have time; fix critical errors before you do anything else.

The five schema types worth checking for a law firm

Not every schema.org type applies to a legal practice, and using the wrong one is a precision problem even when the markup technically parses.

The Attorney-to-LegalService correction is a one-value fix: change the "@type" field in the relevant JSON-LD block, not a redesign. Do it because schema.org itself deprecates the type, and because Google's guidance is to "use the most specific applicable type."

The Review/AggregateRating rule is worth singling out, because it looks like the obvious thing to do: you have real five-star reviews, so why not mark them up? Google's structured data documentation for review snippets answers this directly, scoping the Local Business review property to "only for sites that capture reviews about other local businesses." A law firm's own site, marking up its own rating, falls outside that scope regardless of how genuine the reviews are. The reviews themselves can and should appear in ordinary page text.

Schema.org type choice

Where a firm starts depends on what it already declares

Decision path from a firm's existing markup to the type it should carry A decision path with one question at the top and two routes below it. The question asks which type the firm's identity block currently declares. The left route, already LegalService, ends at a check that the inherited local business values are real and current rather than left over from a staging build. The right route, still Attorney, ends at a single field change rather than a redesign. Both routes converge on one closing card for the separate review question, which is scoped to sites capturing reviews about other local businesses. START FROM WHAT IS ALREADY THERE Which type does the identity block declare? ALREADY LEGALSERVICE Nothing to change here The inherited local business values are the thing to check instead: address, phone, opening hours, geo and area served. A staging placeholder parses fine. STILL ATTORNEY One field, not a redesign schema.org deprecates the type, and Google's guidance is to use the most specific applicable one. Change the type field in the relevant block and retest. EITHER WAY, THE RATING QUESTION IS SEPARATE The review property is scoped to sites capturing reviews about other local businesses, so a firm's own rating belongs in ordinary page text.
A firm already on the right type has nothing to change in the type field, and its remaining risk sits in values a parser will happily accept.

Common implementation errors that make schema invisible to parsers

Broken structured data can look completely fine to a human reading the HTML. Google Search Console's own error taxonomy for unparsable structured data names the exact failure classes. Its error-type table states each as a name and a description:

Google notes that "the most common cause of a single error affecting multiple pages is an underlying template error," which is exactly why one missing comma in a site-wide template can quietly break the schema on every page that uses it.

Unparsable data report

Reading the three error names as questions

Three unparsable-data error names read as a sequence of three questions Three stacked rows. Each row pairs one error name from Google's unparsable structured data error-type table with the description cell that sits beside it, and then with the question that error asks of the file. The rows cover a top-level syntax error, a missing comma or closing brace, and an invalid escape sequence in a string value. A footer card records that one error repeating across many pages points at a shared template rather than at each page. ERROR NAME AND ITS DESCRIPTION CELL WHAT IT ASKS OF THE FILE 1 "Invalid JSON document" "The JSON had a top-level syntax error." Does the document open as JSON at all? 2 "Parsing error: Missing ',' or '}'" "Missing a comma or closing brace." Is every object and list actually closed? 3 "Bad escape sequence in string" "An invalid escape sequence used in a string value." Does every quoted value survive escaping? One repeating across many pages points at a shared template, not at each page.
Taken in order, the three names walk a file from whether it opens at all down to a single escaped character inside one value.

A second class of error is not a syntax problem at all: it is a content-matching problem. Google's own structured data guidelines state the rule directly: "Don't mark up content that is not visible to readers of the page." A FAQPage block that references questions no longer shown on the page, or a LegalService block that still lists a practice area the firm dropped two years ago, will still parse as syntactically valid JSON. The syntax is fine. It is also describing something that is not there, which is a guideline violation that a syntax checker alone will not catch. Fixing this means reading the live page next to the live markup, not just running the markup through a validator in isolation.

Where the tools stop

Two failures a parser cannot see

Where a syntax checker stops and the page itself has to be read Two bands. The upper band holds the failures a validator can report on its own, covering the document opening as JSON, closing braces and commas, and escape sequences inside string values. The lower band holds the failures that need the live page open beside the markup: a block describing something no visitor can read, and a block rendered too late for the crawler to receive. An arrow between the bands marks the point where a clean parse stops being evidence. A VALIDATOR REPORTS THESE ON ITS OWN The file answers for itself Whether the document opens as JSON at all. Whether every brace and comma is where it belongs. Whether an escape sequence inside a string is legal. a clean parse stops here THESE NEED THE PAGE OPEN BESIDE THE MARKUP Only the page can answer A block describing a question, a practice area or an offer that no visitor to that page can read. A block that renders after the crawler has already taken the page, so it is correct and still never arrives.
The lower band is the part no report returns a verdict on, which is why both of these survive a clean result and reach a reader intact.

A third, quieter version of the same problem is markup that never reaches the page at all. Some content management systems and JavaScript frameworks render structured data client-side, after the initial page load. If the Rich Results Test is run on a pasted code snippet rather than the live URL, this failure mode is invisible: the snippet validates perfectly, because the snippet is correct. The live page, as Google's crawler actually receives it, may never render that script tag. This is the specific reason to test the live URL, not just the code you intend to publish.

A working example: LegalService JSON-LD

Here is a minimal, correctly typed LegalService block for a law firm's homepage, using the properties inherited from LocalBusiness:

Paste this into the Schema Markup Validator first to confirm it parses against schema.org, then run the live page URL through the Rich Results Test to confirm Google's crawler receives it unchanged.

Why this is necessary, and why it is not the whole job

Everything above answers one question: is your structured data technically correct? That question matters, and most of this guide has been about answering it properly rather than glancing at a page source and assuming it is fine.

But technically valid, parseable structured data is necessary and not sufficient. Google's own guidance on AI features in Search lists structured data as one item on a list of existing SEO fundamentals it says still apply to AI Overviews and AI Mode, alongside crawlability, internal linking and having important content available in textual form: "making sure your structured data matches the visible text on the page." It is named as groundwork, not as a lever that moves a ranking or an AI citation on its own. A structured data manual action "doesn't affect how the page ranks in Google web search"; it only removes eligibility for a rich result.

What clean, matching structured data actually does is give an AI system or search engine an unambiguous set of facts: this is the firm's name, this is its practice area, this is its address and phone number. That is one of the concrete mechanisms behind getting correctly identified and cited by AI search tools, because an engine assembling an answer has to extract facts about your firm from somewhere, and clean structured data is a cleaner source than parsing prose and hoping the inference is right.

Whether that clarity shows up in how a firm actually ranks is a separate measurement, and QBiz put numbers on it in Structured Data Markup vs. On-Page SEO for Law Firms. The broader mechanics of how a page earns an AI citation once it is technically sound, covering ranking overlap, freshness and extractable formatting, are in How to Get Cited in Google AI Overviews.

Frequently asked questions

Does the Rich Results Test check whether my schema improves my Google ranking?

No. The Rich Results Test checks eligibility for rich-result display, not ranking. Google's own structured data guidelines state that a structured data manual action "doesn't affect how the page ranks in Google web search," it only removes rich-result eligibility. Ranking and schema validity are separate questions.

What is the difference between the Rich Results Test and the Schema Markup Validator?

The Rich Results Test checks specifically whether Google can use your markup for a rich result in Google Search, splitting results into critical errors and non-critical issues. The Schema Markup Validator extracts the markup and identifies syntax mistakes against schema.org itself, including types Google does not use for rich results at all. Running both catches different problems.

Should a law firm use the Attorney or LegalService schema type?

LegalService. Schema.org's own page for the Attorney type states directly that it "is deprecated - LegalService is more inclusive and less ambiguous." LegalService also carries the LocalBusiness properties such as address, phone and opening hours, and Attorney defines no properties of its own on top of them.

Can a law firm mark up its own star rating with Review or AggregateRating schema?

Not for rich-result eligibility. Google's structured data guidelines scope the Local Business review property to sites that capture reviews about other local businesses, not a business reviewing itself. A firm's own five-star rating should appear as ordinary page text rather than as Review or AggregateRating structured data pointing at its own entity.

Why does my structured data still fail after the JSON looks correct to me?

Two common causes beyond pure syntax: the markup describes content that is no longer visible on the live page (Google's guidelines explicitly forbid this), or the markup is injected by JavaScript and never reaches the version of the page Google's crawler actually receives. Testing a pasted code snippet only checks the code; testing the live URL checks what Google actually sees.

Once your schema validates clean, check what it is actually doing for you

A clean pass on the Rich Results Test and the Schema Markup Validator means your structured data is technically sound. It does not tell you whether AI search tools can find your firm, describe it correctly, or cite it over a competitor's. Those are measured separately, and QBiz's AI-readiness check looks specifically at whether the technical signals on your site, including structured data, are actually giving AI systems a reason to name your firm. It takes about thirty seconds and tells you which of the key signals you are passing or failing right now.

Sources

Get your AI Visibility audit →

Leave a comment

Thoughts on this post? Leave a comment below. Comments are moderated before they appear, so yours will not show on the page straight away.

Your email is used only to contact you about your comment if needed; it is never published.

Comments

No comments yet. Be the first to leave one above.