This factor reports whether RankGear finds a LiveBlogPosting @type declaration in a page’s raw HTML — a 1 when the string is present, a 0 when it is not. It is a text pattern match on the source, not a validation that the structured data forms a correct JSON-LD graph.
| Factor ID | RG-SCJ-136 |
|---|---|
| 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 LiveBlogPosting in the raw source of the page. LiveBlogPosting is the schema.org type for a continuously updated live blog — the running coverage format used for events, launches, and breaking news. The result is binary: present (1) or absent (0).
How RankGear measures it
RankGear searches the raw HTML for "@type": "LiveBlogPosting", allowing flexible whitespace around the punctuation and optionally permitting a schema: prefix on the type value. Matching is case-insensitive, so capitalization differences do not affect the result. Because it pattern-matches the source text directly, the detector does not parse or validate the surrounding JSON-LD graph.
What RankGear looks for
"@type": "LiveBlogPosting"
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "LiveBlogPosting",
"coverageStartTime": "2026-08-26T09:00:00-05:00",
"coverageEndTime": "2026-08-26T17:00:00-05:00"
}
</script>| Value | Meaning |
|---|---|
| 1 | A LiveBlogPosting @type string was found in the raw HTML. |
| 0 | No matching LiveBlogPosting @type string was found. |
How to optimize it
Use LiveBlogPosting only for a genuine, continuously updated live blog with accurate coverage dates, updates, authoring, and publication information. Ensure every property reflects content a reader can verify on the page. Treat this factor as an observation about the page you are analyzing rather than a target to chase: adding the type to a page that is not actually a live blog invites a structured-data mismatch, not an advantage. Because the check is case-insensitive and whitespace-tolerant, correct casing is not required for detection — but it is still worth keeping your markup clean for the validators that do parse it.
Important considerations
- The detector pattern-matches source text instead of validating a JSON-LD graph, so a 1 confirms the string is present, not that the structured data is well-formed.
- A matching string that appears outside valid JSON-LD — in a comment, an example snippet, or escaped text — can still produce a 1.
- Capitalization differences do not affect detection; matching is case-insensitive.
- Validate the complete structured data independently with a schema validator; this factor is not a substitute for that check.
- This is a correlation-level prioritization signal within a measured result set, not a cause of ranking. Presence of the markup does not make a page rank.
Related factors
Part of the Factors reference · how RankGear measures · glossary.