Disclosure: I own Nalqerio. This article was written with AI assistance and checked against the documentation linked below. The organization, addresses and migration scenario are fictional. The Python example only checks local sample data; it makes no network requests and accesses no server.

Define a narrow contract

Suppose the visible contact page for a fictional organization says:

• Name: Example Workshop
• Website: https://example.com/
• Contact email: hello@example.com

We want those three facts to agree with one Organization object in the page's JSON-LD. This is a release contract chosen for this example, not a list of Google's required properties.

The intended object is:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Workshop",
  "url": "https://example.com/",
  "email": "hello@example.com"
}

Schema.org documents Organization and its properties here: Schema.org Organization

The example deliberately omits ratings, awards, logos and social profiles. Add information only when it is accurate and relevant; the shortest object is not automatically the right one for every site.

Check the values you actually control

This standard-library Python example compares three fields. It expects the single Organization object above, after JSON parsing. It does not extract data from a page or resolve a JSON-LD graph.

EXPECTED = {
    "name": "Example Workshop",
    "url": "https://example.com/",
    "email": "hello@example.com",
}

def field_mismatches(organization, expected):
    return {
        key: {"expected": value, "actual": organization.get(key)}
        for key, value in expected.items()
        if organization.get(key) != value
    }

assert field_mismatches(dict(EXPECTED), EXPECTED) == {}

stale = dict(EXPECTED, url="https://old.example.com/")
assert set(field_mismatches(stale, EXPECTED)) == {"url"}

missing = dict(EXPECTED)
del missing["email"]
assert field_mismatches(missing, EXPECTED)["email"]["actual"] is None

All three assertions were executed successfully for this article. That result covers the illustrated field comparison only.

The first assertion passes when the fields match. The second detects an old website URL. The third detects the missing mailbox value. A missing field is a failure of our chosen release contract; that alone does not establish invalid Schema.org markup or ineligibility for a Google feature.

Exact string matching is intentional here. It will also flag a trailing slash or capitalization change. Decide the desired output in advance. Do not normalize away differences casually: changing a path, subdomain or email address can change its meaning.

For production, connect the check to the actual rendered output of your build. Keep the expected values in a maintained source of truth. If the same bug changes both the expected values and generated markup, a green test can still hide the problem. Independently compare the public contact page during review.

Add a human evidence review

Use a short review record for each relevant property:

The table reviews evidence. It does not suggest that every property is required. An unrelated directory listing is not automatically a suitable sameAs identity reference, and an optimistic description does not become true because it is machine readable.

Google's general structured data guidelines require truthful, relevant information consistent with the page. They also explain that correct markup does not guarantee a rich result: Google structured data guidelines

Separate the validation questions

There are several different checks to record:

1. Does the JSON parse?
2. Are the vocabulary and types appropriate?
3. Do the facts agree with visible, current content?
4. If targeting a Google search feature, does the implementation meet that feature's current documentation?
5. After deployment, is the intended markup actually present on the public page?

The local function addresses a small part of question three. It is not a JSON-LD validator, a Rich Results Test replacement or a crawler-access test. Choose additional checks for your real output format, including arrays or @graph if your site uses them.

Nalqerio's business schema guide provides the broader type-selection and validation workflow: Business schema markup: examples and validation

For Google's interpretation of Organization markup, consult its feature documentation directly: Google Organization documentation

Close a release review with a precise statement: which fields were compared, what evidence was checked, and which validation steps passed. Record search appearances and AI citations separately. Neither a passing assertion nor valid structured data proves that an AI system will cite the page.