01
Separate schema vocabulary from search features
Schema.org defines many types and properties that services can interpret. Search engines support selected combinations for particular features and publish their own required properties and policies. A valid schema.org type is not automatically eligible for a Google rich result.
Choose markup because it accurately describes the main visible content, not because a plugin offers a long list of types. Organisation, breadcrumb, article, product or event data each has a different purpose. Adding every possible type makes maintenance harder and can create contradictions.
02
Mark up real, visible and specific information
Use the most specific appropriate type and complete the required properties for the feature being targeted. Names, prices, availability, dates, authors and business details must agree with what a visitor can see and with the organisation’s actual records.
Do not invent reviews, ratings, jobs, events, addresses or FAQ answers for markup. Do not mark one generic service as a product merely to seek stars. Misleading structured data can lose feature eligibility and may lead to a manual action even when the code passes a syntax test.
- Represent the page’s primary subject
- Keep marked-up facts visible to visitors
- Use genuine reviews and current availability only
- Remove markup when the visible feature is removed
03
Implement maintainable JSON-LD
JSON-LD places a structured object in a script element and is often easier to generate from the same typed content that renders the page. Stable identifiers can connect an article, service and organisation without repeating conflicting business details.
Escape user-controlled values safely and avoid creating markup through fragile string concatenation. On templated sites, map each field deliberately and omit unavailable optional data. A common mistake is copying an example with placeholder dates, logos or addresses left unchanged.
04
Validate syntax, meaning and live output
Use the Schema Markup Validator for vocabulary and the relevant rich-results test for supported search features, then inspect the rendered live page. A passing result shows that required syntax was found; it does not confirm factual accuracy or guarantee display.
Monitor Search Console reports after deployment and retest when templates or providers change. Search features and policies evolve, so remove deprecated implementation rather than preserving it for a result type that is no longer supported.
Practical next steps
Checklist
- 01Identify the page’s real primary subject
- 02Check current search-feature documentation
- 03Select the most specific accurate type
- 04Map markup to visible maintained content
- 05Include required properties without invented values
- 06Use stable organisation and page identifiers
- 07Validate vocabulary and feature eligibility
- 08Monitor live templates after releases
Common questions
Questions and answers
Does schema markup improve rankings?
It can help systems understand content and enable eligible search features, but it is not a ranking guarantee and cannot replace useful content or technical access.
Is JSON-LD better than microdata?
Search engines can support several formats. JSON-LD is often easier to generate and maintain separately from presentation, provided it stays consistent with the visible page.
Can I add review stars to every service page?
No. Review markup must follow the current feature rules and represent genuine visible reviews for an eligible subject. Self-serving or invented ratings are not appropriate.
Why does valid markup not show a rich result?
Validation establishes technical eligibility, not selection. Search engines consider policies, page quality, relevance, device and other factors when choosing a result presentation.
Need a considered recommendation?
Discuss the website, not just the symptom.
AHANIX reviews each requirement manually. Technical recommendations may depend on access to the website, hosting or DNS configuration.
Continue learning