Has JSON-LD LiveBlogPosting

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 IDRG-SCJ-136
FamilyStructured Data – JSON-LD
MeasurementBinary presence (0 / 1)
Measured zoneRaw 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>
ValueMeaning
1A LiveBlogPosting @type string was found in the raw HTML.
0No 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.