Structured data that earns a manual action

Two of Apple’s own numbers about one app, read within the same hour on 5 August 2026:

apps.apple.com          ratingValue        4.9        reviewCount      1770266
itunes.apple.com/lookup averageUserRating  4.89705    userRatingCount  1769848

418 ratings apart. Both are Apple’s. Both describe the Eventbrite app. Neither is wrong. That is what a live counter looks like when you photograph it twice.

I start there because it is the cheap end of a question that gets expensive quickly: where did the number in your markup come from? AggregateRating is a machine-readable statement, made by you, in your own markup, that many people rated a thing and this is their average. When that statement is false there is nothing left to reinterpret afterwards. No tone, no context, no “that isn’t what I meant.”

Google’s rules for the type are mostly about provenance rather than accuracy, and they are stricter than most people implementing them realise. Six conditions have to hold at once. Below: the two documented rules the six come from, the list itself, and then the list run against four public directories that all publish ratings about the same product.

What a structured data manual action is, and is not

Google’s general structured data guidelines define the penalty precisely:

If your page contains a structured data issue, it can result in a manual action. A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn’t affect how the page ranks in Google web search.
General structured data guidelines, Google Search Central

So it is narrower than people fear and worse than they assume. Your rankings are untouched. Your stars are gone, and a human at Google has looked at your page and concluded you were being manipulative. The Search Console documentation describes what triggers it:

Google has detected that some of the markup on your pages may be using techniques that are outside our structured data guidelines, for example: marking up content that is invisible to users, marking up irrelevant or misleading content, or other manipulative behavior.
Manual Actions report, Google Search Console Help

Three triggers: invisible, irrelevant or misleading, manipulative. The first is a technical mismatch. The second and third are accusations of bad faith.

Rule one: markup describes what the reader can see

The quality guidelines are blunt about it:

Don’t mark up content that is not visible to readers of the page. For example, if the JSON-LD markup describes a performer, the HTML body must describe that same performer.
Don’t mark up irrelevant or misleading content, such as fake reviews or content unrelated to the focus of a page.
Don’t use structured data to deceive or mislead users. Don’t impersonate any person or organization, or misrepresent your ownership, affiliation, or primary purpose.
General structured data guidelines, Google Search Central

The same page states the relevance test as one sentence: “Your structured data must be a true representation of the page content”. It gives two examples of failure, a live streaming site labelling broadcasts as local events, and a woodworking site labelling instructions as recipes.

The review snippet documentation repeats the visibility rule specifically for ratings:

If you use AggregateRating, users should be able to see that aggregate rating on the page.
Review snippet structured data, Google Search Central

A number that exists only in the JSON-LD is already a violation before anyone asks whether it is accurate.

Rule two: ratings come from users, not from you

This is the rule most often broken by businesses with no intent to deceive, because it feels reasonable to publish your own testimonials. Google closed it in September 2019 and explained why in the announcement:

Reviews that can be perceived as “self-serving” aren’t in the best interest of users. We call reviews “self-serving” when a review about entity A is placed on the website of entity A - either directly in their markup or via an embedded third-party widget.
Making Review Rich Results more helpful, Google Search Central Blog

The current documentation states the consequence and the sourcing requirement:

If the entity that’s being reviewed controls the reviews about itself, their pages that use LocalBusiness or any other type of Organization structured data are ineligible for star review feature. […]
Ratings must be sourced directly from users.
Don’t rely on human editors to create, curate, or compile ratings information for local businesses.
Review snippet structured data, Google Search Central

Two more constraints sit alongside it. AggregateRating is defined by its documentation as markup for “an aggregate evaluation of an item by many people,” which is a statement about where the number came from and not just what shape it has. Schema.org’s own definition of the type is “The average rating based on multiple ratings or reviews.” And “Don’t aggregate reviews or ratings from other websites,” which rules out the obvious workaround of scraping somebody else’s average and marking it up as your own.

The enforcement note is filed where nobody reads it, inside a paragraph about completeness: “users prefer recipes with actual user reviews and genuine star ratings (note that reviews or ratings not by actual users may result in manual action).”

The six conditions

Put the two rules together and an AggregateRating you may legitimately publish has to satisfy all of:

It is about an item, not a category or a list.
The ratings came from users.
Those users were not you.
You did not copy the average from another site.
A human editor did not compile it.
The reader can see the same number on the page.

Conditions 2 to 5 are all provenance. Only 6 is about the page. Which means most of the work of getting this right happens before any markup is written, in the boring question of who supplied the numbers and how you know.

Four directories, one product, one day

Provenance is easier to see in the wild than in the abstract, so: Eventbrite, read across four public sources on 5 August 2026.

On the App Store, Apple’s Eventbrite page carries its own aggregate rating markup: a ratingValue of 4.9 from a reviewCount of 1,770,266, which the page renders for the reader as “1.8M Ratings.” Apple’s public iTunes Lookup API, queried a few minutes later, answered averageUserRating 4.89705 from userRatingCount 1769848. That is the 418-rating gap at the top of this page. The long decimals here are perishable in a way the policy quotations above are not; query the lookup endpoint yourself and you will get a third number. The rounded value, 4.9, is the part that holds still.

On Google Play, the store listing’s own markup reported 4.8 (4.81129264831543) from 273,901 ratings, read the same day.

Two software directories put the organiser-facing product lower, and much closer to each other: Capterra’s Eventbrite reviews page and GetApp’s both showed 4.6 from 5,804 reviews, read in a browser. Those two are flagged here rather than listed as machine-checked sources, for two reasons. Both answer a plain command-line request with HTTP 403 (I tried again while revising this paragraph and got 403 from each), so the build cannot re-verify them on deploy the way it re-verifies everything else, and that pair of figures is the one claim on this page you have to take on my word. They are also both Gartner Digital Markets properties drawing on a shared review pool, which makes the matching number one dataset rather than two independent confirmations.

Across four directories the range is 4.6 to 4.9, and the spread is not the interesting part. The App Store and Play figures describe a consumer app used by attendees. The directory figures describe software bought by event organisers. Different populations, answering different questions, and no single figure among them is entitled to be published as the rating for the product.

Now notice what Apple and Google are doing on those pages. Both publish AggregateRating markup about a product they do not own. Both are within policy, because each is aggregating ratings that real users left with them, and each shows the reader the same number it marks up. The type is not forbidden. Condition 3 is about whether the ratings are about you, not about whether the subject is somebody else. Provenance is what makes the assertion true or false.

The rules, short

Mark up what is on the page. If the reader cannot see it, do not assert it.
Do not rate yourself. Self-serving reviews on LocalBusiness or Organization make the page ineligible for the star feature.
Do not rate other people’s products unless real users handed you the ratings. Ask who those people were. If the answer is a spreadsheet, stop.
Do not copy someone else’s average into your markup.
If a number is a live counter, say so in prose, because the markup cannot.
If you cannot show the reader how the number was produced, write prose instead of schema. Prose invites an argument. AggregateRating does not. It only asserts, and it asserts to machines that have no way to ask you a follow-up question.

This build emits no Review or AggregateRating markup about any third party, and the editorial policy carries that as a standing rule rather than as a one-time cleanup.