Boloop-made explanatory illustration: parsing, truthful description, feature eligibility and observed search appearance are separate checks.
While checking Boloop’s structured data, we encountered a view that could easily have ended the work too soon: the test reported valid items, yet a page image still faced crawl restrictions, and software pages had no verifiable offers or ratings.
A green result is useful. It simply answers a narrower question than whether SEO is finished. I began recording separate checks: can the data be parsed, does the description match reality, are the target feature’s requirements met, and what has actually happened in search?
Separate the jobs of the two validators
The Schema.org Validator helps check vocabulary and structure. Google’s Rich Results Test concerns search features Google supports. It may identify articles, software or breadcrumbs, but it does not list every Schema.org type as a separate rich result.
Boloop’s work pages use CreativeWork and image entities. Google’s test showed valid breadcrumbs at that time. That did not make the work description invalid, nor did it mean we should remove other truthful semantics to match the number of detected items.
Conversely, a tool recognizing a type does not establish that every documented requirement for a particular search appearance has been met. Google’s structured data introduction distinguishes its search-feature conventions from the broader Schema.org vocabulary.
A green software result exposed the gap between detection and eligibility
When we checked the Magpie recommendation page, Google’s test listed a valid SoftwareApplication, while showing missing offers and aggregate ratings as non-critical notices.
A screenshot of the green result could easily become “software rich results fully passed.” But checking the Google software app documentation property by property showed requirements for a price and a qualifying review or rating. The tool’s wording had not supplied those facts for us.
I left missing data empty. An open-source license does not automatically establish that every distribution method is free. GitHub stars are not user ratings, and site likes cannot be converted into stars. If a page has no genuine, visible and applicable offer or review, a zero price or invented scores cannot be added merely to clear a notice.
A page can have a truthful semantic description while still not meeting every requirement for the target rich result. Keeping those conclusions separate tells us whether we are missing data or code.
Authors, publishers and update times have different roles
Boloop contains original articles, external recommendations and interactive work. Publishing a recommendation page does not make the site the author of the recommended software or source article. When correcting authorship, we kept third-party creators and standardized only confirmed original-article authors as Tink, linking them to the same public person identity.
The visible name, About information and structured data need to agree. sameAs should link only verified public identities. Wanting a richer person node is not a reason to add unconfirmed employers, career details or social profiles.
Dates create a similar issue. Our CMS’s existing public timestamp changes on republication, so the interface labels it “Last updated” and the structured data uses dateModified. Without a reliable first-publication record, we do not infer datePublished from creation time or quietly present the latest republication as the first publication.
This leaves fewer fields, but gives the date readers see a more accurate meaning.
Follow image fields through to the actual response
Declaring image on an article does not finish the check. The image needs to relate to the content, appear on the page and be accessible to the relevant crawler. Its URL should also agree across the visible page, structured data and sharing metadata.
On October 22, 2026, we found a problem on the bug-fix guide: the image loaded, and Google’s test recognized a valid article, but the asset path was still restricted by the API crawl rules and a noindex response header. A field’s presence and a normal-looking page could not replace an image-access check.
Likewise, a page without a suitable image should not fill that field with a logo, decorative texture or fabricated screenshot. New illustrations can be made when the content needs them, with clear labeling as explanatory illustrations rather than real product interfaces.
Record validation in four layers
I now keep four kinds of structured-data conclusions:
| Layer | Question | |---|---| | Parsing | Can the data actually served in live HTML or the rendered page be read, with valid syntax? | | Semantics | Do entities, relationships and properties match visible content and reliable sources? | | Feature eligibility | Against the target feature’s official requirements, which applicable facts or access conditions are still missing? | | Observed behavior | Have Search Console and search results shown crawling, indexing and the relevant appearance? |
Each actual test keeps its own page, language and result. If a particular Traditional Chinese test has not completed, an English result cannot substitute for it. A tool left on its submission screen is neither a page-test pass nor a failure.
This breakdown stopped us describing everything as “zero errors.” Accurate markup is one completed part; whether a search engine crawls, indexes and uses a particular appearance requires later evidence. The Google software documentation also states that structured-data features do not guarantee an appearance.
If you ask AI to add Schema to a site, request a comparison against visible fields and a list of missing facts as well. That is more likely to reveal whether a complete-looking JSON-LD block describes a real website than generating more types at once.