How to fix missing structured data (JSON-LD)
You fix missing structured data by adding valid, typed JSON-LD to the page: 1 <script type="application/ld+json"> block per page that names what the page is, starting with an Organization and an Article. As Google's structured data documentation explains, this markup is how engines understand a page beyond its words. Put plainly: “structured data is how a machine knows what your page actually is.”
The symptom: engines are guessing what your page is
Structured data, written in Schema.org vocabulary as JSON-LD, is machine-readable markup that tells search engines and AI exactly what a page represents: an Organization, an Article, a Product, a FAQPage, a LocalBusiness. It is not for human readers. It sits in the page source and answers the question a crawler asks before it quotes you: what is this thing?
The symptom we catch most often is one of two states. The first is no JSON-LD at all, so the engine has nothing to read and falls back to guessing from your headings, your title, and whatever text it can scrape. The second is worse and quieter: JSON-LD that is present but invalid, a stray comma or an unclosed brace that makes the whole block fail to parse. To the engine, broken markup and no markup look the same. Either way, the machine is left inferring your identity instead of reading it, and inference is where citations get awarded to someone else.
The cause: identity was never written down for machines
A page can be beautifully written for people and say nothing to a parser. A browser renders your logo, your author byline, your publish date, and your business name as pixels. A crawler does not see a logo or a byline. It sees HTML, and unless those facts are also expressed as typed data, it has no reliable way to know that the page is an article published on a given date by a named organization. The gap between what a human reads and what a machine can confirm is exactly the gap structured data closes.
The usual causes are ordinary. A static site was hand-built and the markup was never added. A theme stripped it during a redesign. A plugin emitted JSON-LD with a syntax error that no one noticed because the page still looked fine. A page declared a type, say Article, but omitted properties that type requires, so the block is technically present and practically useless. None of these are visible without looking at the source, which is why this failure persists for months on otherwise healthy sites.
The fix: add valid, typed JSON-LD
Add a <script type="application/ld+json"> block to the <head> of the page. Start with the two types nearly every site needs. The first is Organization, which establishes who you are. Include name, url, logo, and sameAs linking to your verified profiles:
<!-- Tells engines who publishes this site --> <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Organization", "name": "Acme Roofing", "url": "https://acmeroofing.com/", "logo": "https://acmeroofing.com/logo.png", "sameAs": [ "https://www.linkedin.com/company/acme-roofing", "https://www.facebook.com/acmeroofing" ] } </script>
For a content page, add an Article. It needs at least a headline to be valid, but to clear the recommended tier and give engines the full picture, include image, datePublished, dateModified, author, and publisher. Match the headline to the page's real H1, and use real dates:
<!-- Tells engines what this specific page is -->
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to replace a roof in Austin",
"image": "https://acmeroofing.com/og-image.png",
"datePublished": "2026-06-14",
"dateModified": "2026-06-14",
"author": { "@type": "Organization", "name": "Acme Roofing" },
"publisher": {
"@type": "Organization",
"name": "Acme Roofing",
"logo": {
"@type": "ImageObject",
"url": "https://acmeroofing.com/logo.png"
}
}
}
</script>
Two rules keep this honest. Pick the type that actually matches the page, and do not invent it: a service page is not an Article, and a blog post is not a Product. And include every property the type requires, because a partial block is the broken-markup symptom in a different coat. The structured data should describe what is genuinely on the page and nothing more. Markup that claims a rating or a review that does not exist on the page is a violation, not an optimization.
Be honest about what structured data does
Structured data does not guarantee a rich result, and Google has deprecated several rich-result types over the years, so adding markup is not a lever that forces a fancier listing. We say that plainly because the opposite is a common sales pitch and it is not true. What structured data reliably does is let a machine understand the page and the entity behind it without guessing. That understanding is the foundation generative engines and search both build on, and it is worth doing for that reason alone, with or without a rich result attached.
Verify: validate, then re-audit
Once the markup is in place, confirm it parses and is well-formed. Run the page through Google's Rich Results Test and the Schema.org validator. Both will flag a syntax error, a missing required property, or a type mismatch, which is exactly the class of bug that makes a block silently useless. Fix what they report and run them again until they are clean.
Then verify the fix the way the engines will see it. Re-run an audit on the live URL and confirm the JSON-LD is detected, typed correctly, and complete. You can do this by hand, or paste your link into our AEO checker or the full Brimm audit and we will read the page the way a crawler does, report whether typed JSON-LD is present and valid, and print any missing properties in fix order. If you want the broader context on why machine-readability decides citations, our guide on generative engine optimization covers it, and the rest of the fix library walks through the other failures we find most.