Structured data describes visible facts in a machine-readable form. Choose types that match the page and keep names, dates, URLs and offers consistent. An article can identify Orvunweb as its organizational author without inventing an individual editor or specialist biography. Do not add fake ratings, reviews, offices or awards to make the markup appear richer.
Choose types that describe what is actually on the page
Structured data is a way to describe public information in an organised form. For a business presentation site, the organisation, a service and an editorial article are different subjects. Keeping those subjects distinct is more useful than adding every available type to every page. A service page should not be disguised as a physical product merely because another result format appears attractive.
Google's structured-data introduction explains the relationship between markup, page information and supported search features. Valid syntax is necessary for a machine to read the data, but it does not promise a particular search appearance. Review semantic accuracy as well as whether the JSON parser accepts the file.
Start with a small inventory of verified facts. Which name is public? Is the legal business identity confirmed? Which logo and website address are current? If an address or rating is not verified, leave it out rather than filling the property with a plausible placeholder. Empty owner configuration is a reason to complete the business information, not permission to fabricate it.
Keep service and article facts tied to their sources
A service description should match the visible offer and its limits. If a price is published, its currency and basis need to be consistent with the pricing card. A one-time creation fee should not become a monthly subscription in machine-readable data. When the package catalogue changes, all outputs should change together from the same approved source.
For an article, use its real title, author attribution and publication information. Do not update the modification date merely because the site was rebuilt. A corrected paragraph or revised technical recommendation is a content change; a new deployment of identical text is not necessarily one. Keep editorial dates meaningful so readers can judge freshness.
Consider a design concept presented in a portfolio-style layout. It can look polished without being a client project. The text and metadata should preserve that distinction. Attaching fictional reviews or a client organisation to the concept would create a false claim even if the visible design is otherwise excellent. Data outside the main paragraph remains part of what the business publishes.
Validate meaning with a short comparison sheet
For a representative page, place the visible facts beside the structured-data fields. Check name, description, price, currency, language, canonical address and dates. Ask whether a reader would learn anything materially different from the markup. If so, determine which version is wrong and fix the shared source rather than editing outputs separately.
Use a parser and an appropriate validation tool to catch malformed data, then open the page itself. A successful validator result does not establish ownership, truthfulness or usefulness. It also does not mean every eligible enhancement will appear in search. Keep those conclusions separate in the launch report.
Finally, include the data layer in future change requests. Renaming a service, changing a package or moving an article affects more than headings. A central content model reduces duplication, while the comparison sheet gives a nontechnical owner a practical way to review the result. Accurate modest markup is more dependable than elaborate markup filled with unsupported claims.
An owner review can stay nontechnical. Ask for a plain list of the business facts being published in markup. Read it as if it were a brochure. Is the name correct, is the service described accurately and are prices expressed on the same basis as the proposal? A field being invisible in the page layout does not make it exempt from ordinary editorial approval.
Pay particular attention to properties suggesting endorsement or authority. Reviews, awards, addresses and affiliations should never be added just to make a validator output look more complete. If a fact is absent because it is unconfirmed, the report should explain that absence rather than quietly substitute a guess.
When an editor changes a public fact, include the structured-data comparison in the same change process. This can be lightweight if the site generates everything from one source. The aim is to keep one honest description across formats, not to maintain a more persuasive hidden version for machines. Valid data and truthful data are related but distinct checks.
Practical checklist
- Match visible page content
- Validate JSON syntax
- Use the real publisher
A concrete example: An article can identify Orvunweb as its organizational author without inventing an individual editor or specialist biography.
A boundary to keep clear: Do not add fake ratings, reviews, offices or awards to make the markup appear richer.
Your next step
Tell Orvunweb about your project
