This factor reports whether RankGear finds a @type of Pediatric in a page’s raw HTML — a simple present-or-absent (1 / 0) signal. It is a text match on the source, not a validation that the structured data forms a correct JSON-LD graph.
| Factor ID | RG-SCJ-196 |
|---|---|
| Family | Structured Data — JSON-LD |
| Measurement | Binary presence (0 / 1) |
| Measured zone | Raw rendered HTML |
What it measures
This factor reports whether RankGear finds an @type value of Pediatric in the page’s raw source. It answers one narrow question: does the markup declare a Pediatric schema type anywhere in the HTML? It does not measure the quality, completeness, or correctness of that structured data — only that the type string is present.
How RankGear measures it
RankGear searches the raw HTML for the string "@type": "Pediatric", allowing flexible whitespace around the colon and optionally permitting a schema: prefix on the type value. Matching is case-insensitive, so capitalization differences do not change the result. A match anywhere in the source returns 1; no match returns 0.
What RankGear looks for
"@type": "Pediatric"
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Pediatric"
}
</script>| Value | Meaning |
|---|---|
| 1 | The Pediatric @type string was found in the raw HTML. |
| 0 | No Pediatric @type string was found in the raw HTML. |
How to optimize it
Use the Pediatric type only for a genuine pediatric medical service, and back it with accurate structured data: real practitioners and credentials, the age range served, the services offered, and the location and contact information. Every property should reflect content a user can verify on the page itself. Treat the 1 / 0 value as an observation of what your markup declares, not a target to chase — adding the string without a real pediatric service behind it adds no value and risks structured-data that does not match your content.
Important considerations
- The detector pattern-matches source text rather than validating a JSON-LD graph, so it confirms the string is present, not that the structured data is well-formed.
- A matching string that sits outside valid JSON-LD — for example in a comment, a code sample, or broken markup — can still produce a 1.
- Capitalization differences do not affect detection; the match is case-insensitive.
- Validate your complete structured data independently (for example with a schema validator) rather than relying on this presence check alone.
- This is a prioritization signal that relates to patterns within a measured result set. Presence of the type correlates with observed positioning; it does not by itself cause or guarantee a ranking.
Related factors
Part of the Factors reference · how RankGear measures · glossary.