Structured Data for Companies: A JSON-LD Implementation Guide for 2026

To search engines, most company websites are half-invisible. The page loads and gets crawled, but without structured data Google still has to guess what your company does and whether to trust you.

Structured data ends the guessing. It tells search engines, and the AI systems people now ask instead, exactly what each page is.

The payoff is real: Rotten Tomatoes saw a 25% higher click-through rate after marking up its pages, and Nestlé saw 82% higher CTR on rich results, both per Google's own documentation.

This guide covers the one thing most sites skip: the schema you need, the format, the rules that get you penalized, and copy-paste code.

Before You Build Your Structured Data Schema: Audit the SERP First

Here's a mistake we see all the time: teams rush to mark up their own content without first checking what the competitive landscape is already telling them. Don't skip this step. It's the difference between schema that earns you something and schema that just sits there.

Before you write a single line of JSON-LD, run a keyword gap analysis against your target terms. A gap analysis compares the keywords your site ranks for against the keywords your competitors rank for, and more usefully, it surfaces the topics, intent variations, and long-tail queries you haven't covered yet. Pair that with a quick SERP weakness check. Where the pages currently ranking are thin or low-authority, a well-structured, schema-enhanced page of yours has a real shot at displacing them.

Pay special attention to forum dominance. When Reddit or Quora threads are running the top of a SERP, it usually means no authoritative company has bothered to claim that answer yet. Those are some of the clearest AI Overview citation opportunities you'll find. Generative search engines actively reach for authoritative, well-structured sources, and a forum-heavy results page is basically an open door.

So before you build, do three things:

1. Run the audit.
2. Map which schema types your top three competitors deploy.
3. Aim your implementation at the gaps.

It's about an hour of work, and it shapes everything that comes after it.

What Structured Data Actually Does

Structured data is a standardized way of describing a page and classifying what's on it. That classification is the whole game. It moves your page from something Google interprets probabilistically, a best guess, to an entity Google understands definitively.

It works on two levels, and both matter.

1. Rich results. Validated schema makes your pages eligible for the enhanced treatments you've seen all over the SERP: star ratings, FAQ dropdowns, breadcrumb trails, recipe cards, job boxes, event dates. They take up more real estate, they catch the eye, and they're where those CTR lifts up top come from.
2. Entity disambiguation. Search engines keep a knowledge graph, and structured data ties your web presence to a node in it. The sameAs property is how you connect your site to your LinkedIn page, your Crunchbase entry, your Wikipedia article. All that cross-referencing helps Google confirm you're a real, distinct company, which is exactly what shapes how you show up in branded searches, knowledge panels, and AI-generated answers about your brand.

Why JSON-LD Is the Right Format

There are three ways to add structured data to the web:

1. JSON-LD.
2. Microdata.
3. RDFa.

Use JSON-LD. We'll save you the suspense on the other two.

JSON-LD is a JSON-based format for serializing linked data, and here's why it wins for companies: your structured data stays completely separate from your site's design and layout, and that separation is the gift that keeps giving.

A redesign, a CMS migration, a template refactor your frontend team ships on a Friday, none of it can accidentally corrupt your schema, because your schema was never tangled up in the visible markup to begin with.

Microdata and RDFa, by contrast, embed the markup right inside your HTML elements, which means every layout change is a chance to quietly break something.

JSON-LD lives in a tidy <script type="application/ld+json"> block in your <head>, walled off from everything the design touches. The practical upside: your markup is auditable, versionable, and testable on its own, and when a redesign goes sideways, your structured data is still standing.

Three Rules That Govern Everything

Quick heads-up before you build: Google doesn't send a warning shot. There's no yellow card here. A page either qualifies for rich results or it doesn't, and a policy violation means it doesn't. The good news is that almost every disqualification traces back to just three rules. Get these right and you've cleared the hard part.

1. Visibility parity. "Don't mark up content that is not visible to readers of the page." If your JSON-LD declares a product price, that price has to be on the page. If your Organization schema lists a phone number, that number has to be visible in the HTML. Hidden schema reads as deliberate spam to Google, and it can trigger a manual action that kneecaps rich-result eligibility across your whole site. Not worth it.
2. Relevance. "Your structured data must be a true representation of the page content." The schema on your About page describes your company. The schema on a blog post describes that post. FAQPage schema belongs on a page that genuinely shows FAQs. Mismatched schema is a policy violation even when it's technically valid. Google's systems are good at spotting the gap between what your markup claims and what a visitor actually sees.
3. String encoding. For any property that takes long-form text (description, abstract, text), use \n for line breaks: two characters, a backslash and a lowercase n. Drop a real newline into a JSON string and you'll break the parser and fail the Rich Results Test silently, with nothing visibly wrong on the page to tip you off. It's the kind of bug that hides for weeks, so get it right the first time.

Break any one of these and the rest of your effort is wasted. So don't.

Choosing Your Schema Types

Schema.org's vocabulary is huge: 823 types and 1,529 properties, all built on the RDF Schema standard. Take a breath, though. Most companies need fewer than eight of them. Here's how to figure out which ones are yours. Work down this path:

• Does your company have a physical location customers visit?
  • Yes: use LocalBusiness, and pick the most specific subtype available, such as Restaurant, MedicalBusiness, FinancialService, LegalService, or HomeAndConstructionBusiness.
  • No: use Organization. And if you're a software or SaaS company, add SoftwareApplication on your product pages.

Once you know your base type, layer the rest on top as the pages call for them:

Start with WebSite plus your base organization type, then add others as you build out templates. Trying to ship them all at once before you've validated anything is exactly how implementations break quietly at scale. We've seen it, and it's no fun to untangle after the fact.

Minimal First: The Homepage Baseline

If you do one thing this week, do this. The highest-value, lowest-risk place to start is a single block on your homepage that defines two linked entities together: your WebSite and your Organization (or LocalBusiness). In the live JSON-LD these two sit side by side inside a @graph array, which just means "here are several related entities in one place." Nail this before you touch any other page type.

Here is every field in that homepage block and what each one is for:

The thing to understand here, not just copy: the publisher field on the WebSite points back to the Organization by its @id, and that little internal link is how Google understands the two are the same brand, not two strangers. The sameAs list is your disambiguation payload. Every verified profile you add is one more vote that you're a real, distinct company. So make it count, and only list profiles that are really yours and really live.

Pro Tip: keep a single source of truth for your @id values (a short doc or a config file). The whole entity graph depends on those identifiers staying consistent across pages, and one typo (#organization one place, #org another) quietly splits one company into two in Google's eyes.

Implementation by Schema Type

Organization (SaaS / digital-first)

No storefront, no walk-in customers, just a SaaS platform, a digital agency, or a remote-first team? Then Organization is your base type, and you already built it in the homepage baseline above. There's nothing more to do at the company level beyond keeping sameAs complete and contactPoint accurate. For digital companies, the real work happens one level down, on your product and editorial pages, which is where the next two sections come in.

SoftwareApplication

This is the one for your SaaS product and pricing pages. It tells search engines the page is about software (what category it's in, what it runs on, what it costs) and links the product back to the Organization that publishes it.

Two things matter more here than anywhere else, so don't gloss over them.

• First, set applicationCategory to BusinessApplication for B2B SaaS, not the generic WebApplication.
• Second, and this trips people up constantly: only add an aggregateRating field if real, individual reviews are actually visible on that page.

A rating with no reviews behind it on the page is a textbook visibility-parity violation and one of the faster ways to earn a manual action. Most B2B pricing pages don't host on-site reviews, and if yours doesn't, just leave the rating out. Honest schema is the only schema worth shipping.

LocalBusiness

For any company with a physical address customers actually visit. Reach for the most specific subtype you can: a dental practice uses Dentist, a law firm uses LegalService, a restaurant uses Restaurant. And don't treat geo as optional. AI-generated summaries that surface local business info lean on coordinate data to verify your location, and the auto-schema that most website builders generate skips this field entirely. That gap is a quiet opportunity for you.

Run more than one location? Give each one its own LocalBusiness block on its own dedicated page. Don't try to cram several addresses into a single block. Google treats each physical location as its own distinct entity, and your markup should too.

BreadcrumbList

Add this to every interior page. It renders as the little path trail beneath your URL in search results, and it directly shapes how both readers and crawlers understand the way your site is organized. The block is just an ordered list of steps, each with a position, a name, and a URL:

In the markup, the @type is BreadcrumbList, and each row above is one ListItem inside the itemListElement list. Two quick gotchas: position values have to be integers starting at 1, and every item URL has to be crawlable and return a 200. Point a breadcrumb at a redirected or broken URL and it'll fail validation without a peep.

FAQPage

These can expand right inside the SERP, answering a searcher's question before they've even clicked. That makes them a quiet workhorse on bottom-of-funnel and pricing pages, where people are actively comparing their options and a clear answer can tip the decision your way. The block holds a list of question-and-answer pairs:

In the markup, the @type is FAQPage, each pair lives in the mainEntity list as a Question with an acceptedAnswer, and any multi-sentence answer uses backslash-n for its line breaks. One non-negotiable: every question and answer in your schema has to appear, visibly, on the page. Don't bolt FAQPage schema onto a page that doesn't actually show the Q&A. (Remember visibility parity? This is where it bites people most.)

Article / BlogPosting

For your editorial and blog content. This is the type that links each article back to the Organization you defined on the homepage, knitting your pages into one coherent entity graph instead of a pile of disconnected URLs.

See how publisher points back to your homepage Organization @id? That cross-page link is the quiet hero of the whole setup. It's how you hand machines the context they can't infer on their own: how one entity on your site relates to another, and how all of them ladder back up to your company.

Validation Before Deployment

Always validate before you go live, every type, every time. Run them in this order and you'll catch problems while they're still cheap to fix:

1. Schema Markup Validator Checks your syntax against the Schema.org spec. Run it first; it'll catch malformed JSON before Google ever lays eyes on it.
2. Google Rich Results Test Confirms rich-result eligibility and flags policy violations. Paste in a live page URL or the raw JSON-LD. Green means you're eligible; a warning means the schema is valid but not yet rich-result-eligible; an error means it won't be processed at all.
3. Google Search Console (after deployment) Head to Enhancements and pick the relevant type. Search Console reports errors at crawl scale, so it'll sometimes surface issues on pages that sailed through the Rich Results Test, usually because the page's content conflicts with the schema at crawl time. Check back after the crawl and clean those up.

Pre-deployment checklist:

• All schema properties have corresponding visible on-page content
• description and text fields use \n, not raw newlines
• Schema type is the most specific applicable subtype
• sameAs links resolve to live, verified brand profiles
• @id values are stable canonical URLs with consistent fragment identifiers (#organization, #website, #article)
• No schema markup deployed on pages it does not describe

Pro Tip: make the Rich Results Test the last step before every publish, not an afterthought you get to "eventually." The teams that win at this treat validation like a pre-flight checklist, not a cleanup job.

AEO / GEO: Optimizing for AI Overviews

Here's the shift that changes the math: Google no longer just ranks pages, it generates answers. Which means your structured data now has two jobs instead of one.

• The first is the familiar one: earn rich results in traditional search.
• The second is newer and a little different: become a source that AI Overviews actually cite.

And that second job has its own rulebook.

AI Overviews tend to pull their answers from pages that share a certain shape. In our experience, and in the patterns researchers keep documenting, the pages that get cited tend to be:

• Lightweight and fast-rendering: AI scrapers favor pages that parse cleanly without waiting on JavaScript to execute.
• Structured as scannable data: tables, numbered lists, and definition blocks get extracted far more reliably than dense walls of paragraph.
• Explicitly authoritative: an AI is more comfortable citing an entity it can verify against its own knowledge graph.

Put those together and the schema implication is straightforward: a page with clean Organization markup, verified sameAs links, and clear mainEntity declarations is simply a more citable source than an unstructured page saying the exact same thing. You're making yourself easy to trust.

A few additions worth considering for AI Overview eligibility:

• Speakable. Add a WebPage block with a speakable property of type SpeakableSpecification, and point its cssSelector at the parts of the page that carry the core answer, for example .article-headline and .article-summary. It tells Google which sections are best suited to voice and AI extraction.
• DefinedTermSet. For glossary or definition pages, this signals that your page is the canonical source for a given term. Worth it if you own a niche vocabulary.
• Clean mainEntity declarations on every page say plainly what the page is primarily about. A blog post about SoftwareApplication schema should declare that as its mainEntity, not fall back to a generic WebPage.

And remember that forum-dominated SERP from the start of this guide? That's still your loudest opportunity signal. Nobody authoritative has claimed the answer yet, so a schema-enhanced, table-structured page from your domain is a strong candidate to displace it, in both traditional rich results and AI Overview citations. Go claim it.

Platform Considerations

How much control you have over your schema comes down to the platform you publish on, and so does where the gaps will show up. Here's the honest lay of the land.

Wix.

Wix's AI Structured Data Generator will auto-create Article, BlogPosting, FAQPage, and Recipe schema from your blog content, and for standard post types it covers the basics fine. Where it runs out of road is customization: it's a closed ecosystem, so anything beyond its native form fields isn't directly editable.

If you need detailed Organization, LocalBusiness, or nested entity graphs, you'll hit the ceiling fast. Work inside those limits on purpose, and don't assume the auto-generated output is the whole story.

Framer

You add structured data through the Custom Code panel, dropped into the site <head>.

Framer's CMS binding via {{field_name}} syntax generates a unique schema block for each CMS item on the fly, which makes it a nice fit for big editorial or product catalogs that need per-page schema at scale.

Bind headline, description, datePublished, and image to your CMS fields and you've got clean automated generation. And because you're injecting into the <head> yourself, you keep full control over the JSON-LD structure.

Pure AI site builders.

The describe-it-and-it-builds-itself tools usually hand you a single generic schema block (often a bare WebSite or WebPage) with none of the fields that drive local SEO, entity disambiguation, or rich-result eligibility.

If you're on one of these, treat the auto-generated schema as a placeholder, not a finish line, and audit every field: geo, openingHoursSpecification, sameAs, and multi-entity @graph linking are almost always missing. The audit takes about an hour. Leaving those gaps in place costs you every rich result those fields would've unlocked, so it's an easy hour to justify.

And I would strongly recommend RebelMouse's AI Builder. It delivers pages with solid performance, top-of-the-line built-in SEO, and strong AI visibility.

Headless / Custom

Full control, full responsibility, the classic developer's bargain. Inject JSON-LD server-side into the <head> of every page template. For pages generated programmatically at scale, lean on typed schema objects (Zod, if you're in TypeScript) to enforce valid output before it ever ships. One malformed field in a shared template can propagate across thousands of pages before Search Console catches it, so the guardrails earn their keep.

Managed enterprise platforms

On a fully managed publishing platform, structured data is generated server-side and injected into the <head> at render time, which, if you've read this far, is exactly the isolation principle JSON-LD was built around, just handled for you. Schema survives redesigns because it never lived in the visible template to begin with.

The trade-off is the mirror image of the AI-builder problem: a little less manual control, a lot more consistency at scale. Three questions tell you whether a managed platform is actually pulling its weight here.

• Does it emit WebSite and Organization on the homepage?
• Does it generate BlogPosting on every article automatically, with publisher linked back to your Organization @id?
• And can you extend the graph for the page types it doesn't cover out of the box?

A yes to all three means structured data quietly leaves your team's to-do list for good, which, frankly, is where it belongs.

What to Do Now

None of this is as hard as it looks from the outside. Every schema type in this guide follows the same rhythm: declare the entity, describe its properties, link it to its neighbors, validate before you deploy. The companies that win the rich-result real estate aren't the ones who found a trick. They're the ones who do this consistently while everyone else keeps meaning to get around to it.

Here's the sequence we'd actually run, in order:

1. Run the gap analysis. See which schema types your top three competitors deploy, and which of your target SERPs are still propped up by thin or forum content.
2. Deploy the homepage baseline. WebSite + Organization (or LocalBusiness). Validate it with the Rich Results Test before you call it done.
3. Audit Search Console. After the crawl, check Enhancements for errors and fix them before you expand to new page types.
4. Add BreadcrumbList site-wide. Highest reach, lowest effort. It's the obvious next step after the homepage.
5. Layer by page type. FAQPage on support and pricing pages. SoftwareApplication on product pages. BlogPosting on editorial. JobPosting on careers. Validate each type on its own before you roll it out everywhere.

The barrier was never knowledge, but follow-through: validating before you deploy, keeping visibility parity intact as your content changes, and treating schema as infrastructure instead of a one-and-done task.

And that last part is really a question about where you publish. Schema you hand-maintain tends to decay. A redesign drops a field, a migration breaks an @id, a new template ships without its publisher link, and nobody notices until the rankings start slipping. Schema generated server-side and injected at render time doesn't decay, because it isn't tied to anything the visible template touches. If structured data keeps falling to the bottom of your roadmap, that's your signal to move it from a manual chore to a platform capability, and to put those three managed-platform questions to whatever you're running today.

That's the kind of thing we think about all day at RebelMouse. Whether you want a hand auditing your current schema, a faster platform that handles this for you at render time, or honestly just someone to talk through your SEO and AIO strategy with, we're happy to dig in with you. No pressure, just a real conversation.

Frequently Asked Questions