Mark up only what is visible on the page
I have also seen a green validator and zero effect. You can copy JSON-LD into the head and get “valid,” but if the code describes something a person does not see, it will not fix an empty page.
The mistake I would remove first: Inserting a made-up rating or price.
What to prepare and what result to expect
- Outcome: Search engines get clear page hints, and you can validate JSON-LD before publication.
- Choose one primary page entity and gather the real name, URL, phone, address, service, and breadcrumbs.
- Keep source data and access rights separate from the output so you can verify what Schema.org page markup produced.
- Match every field to visible text and test the URL in Rich Results Test, the Schema.org validator, and Search Console.
Add JSON-LD and validate it before publication
- Choose the page type
Use Service for a service, Organization/LocalBusiness for the company, Article for an article, and BreadcrumbList for navigation. Do not put Product on a regular service.
Проверьте: The type describes the page’s real primary entity.
Если не сработало: Keep only Article/Organization and do not mark up what you are unsure about.
- Add JSON-LD
In a CMS look for Custom code/Head; on a static site add a script in head. Fields must match visible content and the canonical URL.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Service", "name": "Air conditioner repair", "serviceType": "Residential AC repair", "url": "https://example.com/services/repair/" } </script>Проверьте: JSON-LD parses and contains no data missing from the page.
Если не сработало: Check quotes, commas, and JSON encoding.
- Validate markup with tools
Run Rich Results Test and Validator.Schema.org, then submit the URL in Search Console → URL Inspection. Report names may vary.
Проверьте: No syntax errors or critical warnings for the chosen type.
Если не сработало: Fix the JSON first, then check support for a specific rich result.
- Monitor after publication
After updates, review enhancement reports and confirm markup did not go stale with address, price, or FAQ changes.
Проверьте: Structured data matches the current page.
Если не сработало: Remove a type you can no longer support with visible text.
I choose the type by page meaning
For a typical service page, `Organization`, `Service`, and `BreadcrumbList` are often enough. Do not add `aggregateRating` if there are no reviews on the page; do not invent a price; do not turn a service into Product. JSON-LD data must match visible text and real URLs.
In a CMS look for `Custom code / Head`; on a static site add a `script` in `<head>`. Then check the page with Rich Results Test and `validator.schema.org`, and open URL Inspection in Search Console.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Service",
"name": "Business process automation",
"serviceType": "Business process automation",
"url": "https://example.com/services/automation/"
}
</script>How to tell the markup is not lying
Open the source HTML and find every `application/ld+json`: a common problem is CMS and hand-added code publishing two conflicting graphs. Check that `url`, `@id`, images, and breadcrumbs point to pages that return 200. Before changes, save impressions, clicks, CTR, and position for 5–10 similar pages, or you cannot compare effect.
- Valid syntax does not guarantee a rich result.
- Markup does not replace actual content.
- Do not use hidden data only for a snippet.
I do not test markup by claims alone
Save the URL, schema type, validation date, validator errors, the visible block on the page, and the expected outcome. If you added FAQPage, questions and answers must be expandable and visible to people. If you added Service, the name and service scope must match the page text.
After publication, do not promise the client a rich snippet. Wait for recrawl, then compare impressions and CTR with similar URLs. Structured data helps search engines understand the page, but it does not replace useful copy and does not guarantee special display.
How to choose a Schema.org type without inventing facts
| Criterion | Question | Good sign |
|---|---|---|
| Input | What exactly goes into Schema.org page markup? | Choose one primary page entity and gather the real name, URL, phone, address, service, and breadcrumbs. |
| Action | What is the system allowed to do on its own? | Only pre-listed actions, without access to the entire account |
| Verification | How do you know the result is acceptable? | Match every field to visible text and test the URL in Rich Results Test, the Schema.org validator, and Search Console. |
| Failure | Where does an unclear case go? | Remove the disputed field or type instead of filling it with a made-up rating, price, or address. |
What should change after setup
Search engines get clear page hints, and you can validate JSON-LD before publication.
Why valid markup still does not earn a snippet
Inserting a made-up rating or price.
Marking up hidden text the visitor never sees.
Adding ten types without understanding the primary entity.
Treating valid JSON as a guarantee of a rich result.
When schema needs to connect to site data
Bring in a specialist if markup is generated for hundreds of page types, ties into a catalog, or spans multiple locales.
What to check in JSON-LD
Can I add ten schema types at once?
Better start with types that describe the page’s primary entity and are actually supported by visible text.
Where should I validate JSON-LD?
In Rich Results Test, the Schema.org validator, and via URL Inspection after publication.
Does FAQPage guarantee an FAQ snippet?
No. Markup helps understand the content, but display format and eligibility are decided by the search engine.
Can I mark up reviews from a form?
Only if the review is actually published, relates to the entity, and you follow search engine rules.
