Skip to content
Contact us
  • There are no suggestions because the search field is empty.

Add the right structured data to your site

Structured data is machine-readable markup that tells engines, in explicit terms, what a page is about — which helps them read and represent your brand more reliably. This guide shows you how to add it, usually with a hand from your developer.

Why this matters for AI visibility

Structured data is code you add to a page to spell out what it contains: that this is your company (an Organization), that this is a product with a price (a Product), that this is an article with an author (an Article), and so on.

Under the hood it works as entity–property–value triples: a thing (an entity, like your company), a property of it (its name, its logo, its founding date), and a value ("GetMint", a URL, 2023). String enough triples together and you've described the entity in a way a machine can parse without guessing. The shared vocabulary that defines which entities and properties exist is schema.org — a standard maintained jointly by Google, Microsoft, Yahoo, and Yandex — and the format everyone recommends for writing it is JSON-LD, a small script block in the page's code.

Left to itself, an engine has to infer what your page means from the raw text. Structured data reduces that guesswork by stating your key facts explicitly. That helps Google show rich results, and it gives AI engines cleaner signals about your entity. It won't single-handedly change how a model describes you — it's one input among many — but it removes ambiguity, and it's the foundation for the entity linking below.

The part that matters most for AI: entity linking

Naming your entity isn't enough. What actually moves AI visibility is connecting your Organization to the same entity engines already know from other trusted sources — your Wikipedia page, Wikidata, LinkedIn, Crunchbase. Two properties do this:

  • sameAs — an array of URLs pointing to your authoritative profiles elsewhere. It tells the engine "the company on this page is the same one described at these other places," which is how a model resolves you to a known, trusted entity instead of an anonymous website.
  • @id — a stable, unique identifier (usually a canonical URL like https://yoursite.com/#organization) that you reuse across every page and every schema block, so all your markup resolves to one entity rather than many disconnected ones.

This is the mechanism a structured-data guide is really promising for AI visibility: fewer isolated facts, one well-connected entity the models can recognize.

Step 1: Check what you already have

You don't need to audit every page. Because websites are built from templates, three representative pages cover about 90% of your site:

  • Your homepage.
  • One key transactional page — for a B2B site, a product, solution, or pricing page; for ecommerce, a product page or a category page.
  • One blog article.

For each, check what structured data is already there. The easiest way is to run the page through Google's Rich Results Test or the Schema Markup Validator, which detect and list any structured data found. If you prefer, open the page source and search for application/ld+json. Note what exists and what's missing.

Step 2: Identify the right types for each page

The right structured data depends on your type of site and the type of page. Here's a sensible baseline to start from.

For a B2B / SaaS site:

  • Homepage — Organization (company name, logo, URL, social profiles) and WebSite.
  • Transactional page — SoftwareApplication for a SaaS product, or Service for a B2B service.
  • Blog article — Article or BlogPosting, with author and publish date.

For an ecommerce site:

  • Homepage — Organization and WebSite.
  • Product page — Product with its Offer (price, availability, currency) and, if genuine, AggregateRating and Review.
  • Category page — ItemList of the products it lists.
  • Blog article — Article or BlogPosting.

Across both, where relevant: BreadcrumbList for navigation, and FAQPage on pages that genuinely have a FAQ.

Treat this as a starting point, not a rulebook. The exact types and their required properties vary a lot by industry, page, and the rich result you're aiming for. This is exactly why the next point matters.

Step 3: Lean on Google's documentation for the specifics

There are many special cases, and getting the required and recommended properties right is what makes structured data actually work. Rather than guess, go to the source:

Find the types that match your pages in the gallery, and follow the property list there. This is the reference to trust, because it's kept up to date with what engines actually support.

Step 4: Write and add the JSON-LD (with your developer)

Structured data is added as a <script type="application/ld+json"> block in the page's code. Here's a complete Organization example with entity linking — the shape your developer adapts per page and per type:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yoursite.com/#organization",
  "name": "Your Brand",
  "url": "https://yoursite.com",
  "logo": "https://yoursite.com/logo.png",
  "description": "One factual sentence about what you do.",
  "sameAs": [
    "https://en.wikipedia.org/wiki/Your_Brand",
    "https://www.wikidata.org/wiki/Q00000000",
    "https://www.linkedin.com/company/your-brand",
    "https://www.crunchbase.com/organization/your-brand"
  ]
}
</script>

Rolling it out across a whole template so every page of that type is covered is usually a developer job. Give your developer the page types, the schema types you identified, the Google gallery link, and two rules that keep you safe:

  • The markup must match what's visible on the page. Don't mark up a price, rating, or content that a visitor can't actually see. Google can penalize markup that misrepresents the page.
  • Use real, accurate values. Never invent reviews or ratings.

Producing fully copy-paste-ready code for every case is genuinely hard because of all the variations, so the practical path is: your developer builds it from the Google gallery examples and the pattern above, using your real data.

Step 5: Validate and deploy

Before and after deploying, test each page type with the Rich Results Test and the Schema Markup Validator. Fix any errors and review the warnings. Once a template validates cleanly, deploy it so every page built on that template inherits the markup. Then re-test one live page of each type to confirm it's working in production.

Need a hand with this?

Structured data gets fiddly fast once you're into the per-industry details, and it usually needs a developer. If you'd rather have an expert scope exactly what your site needs and brief your team, GetMint's Customer Success team can help.

Talk to a GetMint CSM about the Enterprise plan →

Key takeaways

  • Structured data describes a page as entity–property–value triples in a machine-readable format (JSON-LD + schema.org) — so engines guess less.
  • Entity linking is the AI-visibility payoff: use sameAs (links to Wikipedia, Wikidata, LinkedIn, Crunchbase) and a shared @id so your pages resolve to one known entity.
  • Audit three representative pages (homepage, one key transactional page, one blog article) — templates cover ~90% of the site.
  • Trust Google's gallery for the exact required and recommended properties per type. Guessing rarely works.
  • Two safety rules: markup must match what's visible on the page; never invent reviews, ratings, or facts.
  • Roll out template-by-template with your developer, then validate one live page of each type after deployment.