Structured Data That Actually Helps an SMB Rank

Atamyrat Hangeldiyev

Systems Architect

January 31, 2026

Structured data is machine-readable markup that states what a page's entities are and what is true about them, so a search engine can confirm and present them, in the context of small and mid-sized businesses that need a small, correct, honest set of it rather than more of it. It does not move a page up the rankings. It tells a machine, in a format read exactly, who the business is, what each page is, and what is true about it, so what the page already says can be confirmed and shown.

Deleting seven of a regional services company's nine schema types is what finally got it the knowledge panel its developer had promised for a year. The plugin had stamped every page with Organization, WebSite, Article, FAQPage, Product, Offer, AggregateRating, Review, and BreadcrumbList, and none of it produced a rich result. Product and Offer described products the company did not sell. AggregateRating asserted a star average with no reviews on the page to support it, which is the exact pattern that earns a structured-data manual action, and this site had one. We removed everything that did not match what was on each page and kept four types that did: Organization with the real legal name and logo, WebSite with the search action, BreadcrumbList matching the visible breadcrumb, and FAQPage on the two pages with real question-and-answer content. The penalty was reconsidered and lifted, the panel appeared within weeks, and the FAQ pages started showing expanded results. Nine types and zero rich results became four honest ones and a panel, and the only thing that changed was subtraction down to what was true.

This guide is the procedure for deciding which markup an SMB needs, shipping it, and proving it honest. It stays on the markup: which types pay, what they earn, how to validate them, and the penalty risk if they lie. It does not re-teach the entity concept the markup encodes, the on-page content the schema confirms, the link wiring, the local playbook, or the crawl mechanics; those have their own guides and are handed off at the seams.

What structured data actually does for a small business

Structured data earns presentation and confirms identity. It does not rank the page. A search engine ranks a page on what it is about, how well it answers the query, and the authority the site has earned around the subject; correct markup changes none of those. What it changes is whether the engine can read the page's identity with confidence and whether the page is eligible to be shown as something richer than a plain blue link: a knowledge panel, a sitelinks search box, a breadcrumb trail, an expanded FAQ. A page with no markup can still rank. The same page with correct markup ranks the same and is eligible to be presented better and cited more confidently. That is the entire honest claim, and an SMB should hold it exactly that tightly.

It earns presentation and confirms entities; it does not directly rank the page

The mechanism is confirmation, not promotion. The page text says the business has a particular name, is at a particular address, answers a particular question; the markup states the same facts in a structure the engine does not have to infer. That removes ambiguity: the engine no longer has to guess whether two name variants are the same company or whether a block of text is a genuine question-and-answer pair, and removing that ambiguity is what makes it willing to present the page richly and answer about the business directly. It is also why markup that states something the page does not say is worse than no markup at all. The engine treats schema as a claim it can act on, so a false one is a false claim it acted on: the penalty surface, not an optimization.

An example: nine schema types and zero rich results, cut to four that matched the page

The regional company from the opening is the common shape. A plugin was installed, a setting was left on, and the site accumulated schema nobody read. Volume felt like coverage and was actually exposure: every false block was a claim the engine could hold against the site, and the AggregateRating with no supporting reviews was the one that did. The fix was not adding the "right" schema on top. It was deleting everything that did not correspond to something visible on the page until what remained was small, true, and validatable. The lesson generalizes: an SMB's structured-data problem is almost never too little markup, it is markup that is broken, decorative, or describing content that is not there.

More schema is not more results; the wrong markup is a liability

The instinct a plugin trains is that more schema types means more chances at rich results. For an SMB the opposite is true. Each type is a set of claims the engine can verify against the page and against reality. Types that match the page and add nothing false are eligible for presentation. Types that describe things not on the page are liabilities that sit dormant until an algorithm update or a spam reviewer reads them, then cost the site its eligibility across the board, not just on the offending page. The correct model is not a collection to maximize; it is a small set of true statements to get exactly right.

What a plugin's schema dump actually costs

A typical SMB schema plugin ships Organization, WebSite, and BreadcrumbList correctly, then offers Product, Offer, AggregateRating, Review, Event, and a dozen more as toggles, and a well-meaning operator turns most on. The cost is not performance. It is three liabilities. First, invalid markup: blocks with required properties missing, which produce no rich result and clutter the validation report so real errors hide. Second, decorative markup: valid blocks for types the engine has no rich treatment for on an SMB site, which earn nothing and add maintenance. Third, the expensive one, dishonest markup: AggregateRating or Review on pages with no real reviews, Product and Offer on a services page with no products, FAQPage built from text that is not a real question and answer. The third category is what turns markup from inert to dangerous.

Why markup that lies about content not on the page is a penalty risk, not an edge

A structured-data manual action is a documented penalty: the search engine determines that a site's markup misrepresents its content and removes its eligibility for rich results until the markup is fixed and the site reconsidered. It is not theoretical and not rare on SMB sites running unattended plugins. The trigger is consistent: schema asserting something the page does not contain. Reviews not on the page. A rating with nothing generating it. A product not sold. An FAQ that is marketing copy reshaped to look like questions. The defense is one rule with no exceptions: every property in every schema block must correspond to something a human can see on that exact page. The moment markup claims more than the page, it is a liability earning a penalty, not an edge earning a result.

How to ship the structured data an SMB actually needs

The procedure produces a small set of validated, honest markup and the order to ship it. It does not require hand-editing a script tag. It requires deciding the shortlist, briefing a developer or configuring a plugin to emit exactly that, validating it, and confirming each block mirrors its page. A non-engineer can run all four steps and check the result.

1. →
   Decide the shortlist

   List only the types that match real pages: Organization and WebSite site-wide, BreadcrumbList where breadcrumbs are visible, Article on real articles, FAQPage only on real Q&A pages, LocalBusiness if the business serves a physical area.

2. →
   State the attributes

   For the Organization, name the real entity attributes a machine should read using additionalProperty, so the markup carries verifiable facts, not just a name.

3. →
   Ship it

   Brief a developer or configure the plugin to emit exactly that set as JSON-LD, and to emit nothing else.

4. →
   Validate and verify honesty

   Run every page type through a validator, fix every error, then read each block against its page and confirm every property is something a visitor can see.

The shortlist, type by type

There are six types worth an SMB's attention, and most sites need four of them.

1. Organization (site-wide, usually on the home page). States the business as an entity: legal name, URL, logo, and the attributes below. This is the block that earns the knowledge panel and lets the engine reconcile every name variant to one company. Every SMB ships this.

2. WebSite (site-wide). States the site and, with potentialAction, the on-site search, which is what makes a sitelinks search box eligible. Cheap, honest, worth shipping on every site that has site search.

3. BreadcrumbList (on pages with a visible breadcrumb). Mirrors the breadcrumb the visitor sees and produces the breadcrumb trail in the result. Ship it only where the breadcrumb is actually rendered on the page.

4. Article (on genuine articles and guides, not service or landing pages). States headline, author, and dates for real editorial content. It does not turn a thin page into a credible one; it states facts about a page that already is one.

5. FAQPage (only on pages with real, visible question-and-answer content). Can earn an expanded result. The constraint is absolute: the questions and answers in the markup must be the questions and answers a visitor reads on the page. Reshaping marketing copy into FAQ markup is the dishonest pattern that gets penalized.

6. LocalBusiness (only if the business serves customers at or from a physical location). States name, address, phone, hours, and geographic service area as machine-readable facts. The local visibility this supports is its own discipline, covered below and owned by the local-SEO guide; here it is one more honest block, not a local-SEO program.

Everything else (Product, Offer, AggregateRating, Review, Event, and the long tail) is shipped only if the page genuinely is that thing and contains the content the type requires. For a normal SMB selling services, that usually means none of them. Skipping a type costs nothing. Shipping a false one costs eligibility.

Here is what the core site-wide block looks like as JSON-LD, so an owner can recognize it and confirm a developer or plugin produced it correctly:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Regional Services Co.",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://www.example-directory.com/regional-services-co"
  ]
}

Every value there is a fact you can verify: the real name, the real URL, the real logo file, and profiles that genuinely belong to the company. Nothing is asserted that a person could not confirm.

Stating entity attributes with additionalProperty

An Organization block with only a name and logo states that the company exists. It does not state what is true about it. additionalProperty is how you attach machine-readable attributes to the entity: facts a search engine can read as structured statements rather than infer from prose. Each is a PropertyValue with a name and a value. This is the schema-side expression of the entity-attribute-value model: schema is the machine encoding of the idea that an entity is defined by its attributes and their values, an idea owned in full by entities, attributes, and why search ranks topics not keywords. This guide does not re-argue that model; it shows the markup that serializes it, and the rule that the model imposes here is the same rule that governs every block: an attribute you state must be a fact the page supports.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Regional Services Co.",
  "url": "https://example.com",
  "additionalProperty": [
    {
      "@type": "PropertyValue",
      "name": "Service area",
      "value": "Three named counties"
    },
    {
      "@type": "PropertyValue",
      "name": "Year established",
      "value": "2009"
    }
  ]
}

Add only attributes that are true and, ideally, visible somewhere on the site. The point of additionalProperty is to make verifiable facts machine-readable, not to inject claims the site does not back up. The same honesty constraint that governs every other block governs this one.

Brief a developer or configure a plugin to ship it

You do not need to write JSON-LD. You need to specify it precisely enough that a developer or a plugin produces exactly the set above and nothing else. A workable brief is four lines: ship Organization and WebSite site-wide with these exact values; ship BreadcrumbList on templates that render a visible breadcrumb; ship Article on the blog and guide templates only; ship FAQPage only on the specific pages that contain real Q&A, and add LocalBusiness with these address and hours values if we serve a location. The instruction that matters most is the negative one: emit nothing else, and turn off any plugin-default schema for types not on this list. Most SMB schema problems are not missing instructions. They are a plugin emitting types nobody asked for.

For generating and checking the actual JSON-LD against a specific page, Claude is the tool to reach for. Claude models, via the Claude API or in a chat, will produce correct JSON-LD for a given page and, more usefully, check an existing block against the page's visible content and tell you which properties are not supported by anything on the page, which is the exact judgment that prevents a penalty. Claude Code is the agentic tool for doing this across a whole site: it reads each template, generates or corrects the markup, and validates it in place, rather than fixing one page at a time. Other tools and validators exist and are named below where they genuinely fit; for the generate-and-honesty-check step, lead with Claude because that is the step where an unsupported property has to be caught before it ships.

Validate it, and prove it mirrors the page honestly

Validation is two checks, and most people only run the first. The first is mechanical: run each distinct page type (home, an article, an FAQ page, a breadcrumbed page, a location page) through a schema validator and Google's Rich Results Test. Fix every error and every warning until the report is clean. A block with a missing required property earns nothing and hides real problems in the noise. The second check is the one that actually prevents the penalty: read each block next to the page it is on and confirm that every single property corresponds to something a visitor can see. Name matches the name on the page. Reviews exist on the page. The FAQ questions are the questions on the page. The breadcrumb matches the rendered breadcrumb. A block that passes the validator but fails this read is exactly the markup that earns a manual action. Mechanical validity is necessary and not sufficient; honesty against the page is the check that actually matters, and it is the one a tool will not do for you unless you ask it to compare the markup to the content.

Structured data versus the things it gets confused with

Structured data gets conflated with three near-neighbors, and each conflation produces a different mistake.

Schema markup vs the entity concept it encodes

The entity concept is the idea that search ranks things, not strings: a business, a place, a topic are entities with attributes and values, and an engine reasons about them. Schema markup is the machine encoding of that idea, not the idea itself. You can understand entities perfectly and ship no schema, and you can ship schema while misunderstanding entities and produce markup that says nothing useful. The concept, including why an engine ranks entities and how to think in entities and attributes about your own business, is owned by entities, attributes, and why search ranks topics not keywords. This guide assumes that model and shows only its serialization: Organization plus additionalProperty is the entity model written down where a machine reads it.

Schema vs on-page extractable content

Schema confirms the answer; it is not the answer. A search engine and an answer engine extract the human-readable content of the page to decide what it says and whether to cite it. Schema tells the machine, in structure, that the content it just extracted means what it appears to mean. It is confirmation layered on extractable content, never a substitute for it. FAQPage markup on a page with no real FAQ does not create an answer; it makes a false claim about a page that has none. Writing the extractable, citable content that schema then confirms is a separate discipline owned by writing pages that win snippets and AI citations. The handoff is strict: that guide owns making the page worth citing; this guide owns the markup that confirms what the page already, honestly says.

Schema vs a "ranking factor"

This is the misconception that does the most damage, so state it plainly. Structured data is not a ranking factor. Adding more of it does not move a page up. The engine ranks a page on relevance and earned authority around the subject; correct markup changes neither. What it changes is presentation eligibility and identity clarity. Treating schema as a ranking lever leads directly to the plugin dump, because if more markup meant higher rankings, maximizing it would be rational. It does not, and it is not. A page ranks on being the better answer with the authority behind it; schema decides whether that page is shown richly and its entity read confidently, which is a different and narrower thing.

What correct markup changes around your site

Once the core set is correct, three things change, and each is owned by a different discipline.

How a machine reads your identity and attributes once it is right

With correct Organization and WebSite markup and honest additionalProperty facts, a search engine can reconcile every variant of the business name to one entity, read its attributes as statements rather than inferring them from prose, and answer about the business directly with confidence. That confidence is what underlies a knowledge panel, accurate direct answers about the company, and confident citation by an answer engine. Getting this right, across every template, validated, and kept honest as the site changes, is technical execution work most SMBs do not have someone on staff to own. Specifying, shipping, and validating correct site-wide markup so a machine reads the business cleanly is exactly the kind of technical SEO execution Iron Goo's SEO service runs for companies that do not staff it internally. The shortlist is the cheap decision an owner can make this week; emitting it correctly across a real site and keeping it honest is the sustained part.

How LocalBusiness markup supports area visibility

LocalBusiness markup states the address, hours, and service area as machine-readable facts, which supports being found by people searching in or for that area. This guide ships the block honestly and stops there. Why an SMB ranks for the place it serves, how the map presence, local signals, and place-based content actually work, is a full playbook owned by local SEO for a business that serves an area. The relationship is clean: that guide owns being found locally; this guide owns the one honest block of markup that the local discipline relies on. Shipping LocalBusiness is necessary for the local playbook and is not the local playbook.

How the schema must honestly mirror the on-page content

Every change to the markup is downstream of the content. If a page's visible content changes, the schema must change to still match it, and if the schema would say something the content does not, the content is the source of truth and the schema is wrong. This is the permanent dependency: schema is a confirmation of extractable content, so the content decides what the schema is allowed to say, always in that direction. Producing content worth confirming and citing is owned by writing pages that win snippets and AI citations. The discipline here is narrower and absolute: the markup tracks the page, never the reverse, and a block that has drifted from its page is a defect to fix, not a claim to keep.

The one honest set, and the first block to ship and validate this week

Structured data is how an SMB lets a machine read its identity and content cleanly, and the answer is not more markup. It is a small, correct, honest set: Organization and WebSite site-wide with true additionalProperty facts, BreadcrumbList where the breadcrumb is visible, Article on real articles, FAQPage only where the Q&A is real, and LocalBusiness if the business serves a place, every property verifiable against what a visitor can see, validated and then read for honesty against the page. The expensive mistake is never too little. It is a plugin dump with a block that lies, and the fix is subtraction down to what is true, the same move that turned nine types and zero results into four honest ones and a knowledge panel.

The most useful next action is not "add more schema" and not "install another plugin". This week, open your site's source on the home page and find the Organization block, or confirm there is not one. If it is missing, that is the first block to ship: the real name, URL, and logo, plus two or three true additionalProperty facts. If it exists, run it through the Rich Results Test, then read it against the page and delete any property the page does not support. That single block, correct and honest, is where an SMB's structured data starts, and once it is right the rest is the same discipline applied page by page: state only what is true, validate it, and stop.