JSON-LD (JavaScript Object Notation for Linked Data) is a lightweight linked data format and the recommended encoding method for implementing Schema.org structured data on web pages using a standalone script block.
Quick Answer
JSON-LD (JavaScript Object Notation for Linked Data) is a lightweight linked data format and the recommended encoding method for implementing Schema.org structured data on web pages using a standalone script block.
JSON-LD is placed in a standalone script tag, keeping structured data completely separate from visual HTML and making it easy to update without affecting page layout.
Multiple JSON-LD blocks on a single page are supported and recommended when a page contains multiple schema types such as Product, BreadcrumbList, and FAQPage simultaneously.
Dynamic generation of JSON-LD from database values is the standard approach for CMS and e-commerce pages where properties like price and review count change per product.
Key Takeaways
JSON-LD is placed in a standalone script tag, keeping structured data completely separate from visual HTML and making it easy to update without affecting page layout.
Multiple JSON-LD blocks on a single page are supported and recommended when a page contains multiple schema types such as Product, BreadcrumbList, and FAQPage simultaneously.
Dynamic generation of JSON-LD from database values is the standard approach for CMS and e-commerce pages where properties like price and review count change per product.
How JSON-LD Works
The fundamental syntax of a JSON-LD structured data block begins with a @context declaration pointing to https://schema.org and a @type declaration specifying the schema type being described. Properties of that type are then declared as key-value pairs using the property names defined in the Schema.org specification. Nested entity types — such as an AggregateRating nested within a Product schema — are expressed as nested JSON objects within the parent schema, creating a hierarchical data structure that mirrors the entity relationships defined in the Schema.org vocabulary.
Why JSON-LD Matters for B2B Marketing
One of JSON-LD's most significant practical advantages is that it can be generated and injected dynamically by JavaScript without modifying the page's HTML structure. This makes it ideal for CMS platforms, e-commerce systems, and server-side frameworks where structured data values like product price, review count, or event date are pulled from a database and vary per page. CMS plugins like Yoast SEO, Rank Math, and Schema Pro generate JSON-LD automatically for common schema types, while custom schema types typically require manual implementation or custom code.
JSON-LD: Best Practices & Strategic Application
Multiple JSON-LD blocks can coexist on a single page, each describing a different entity or adding properties to the same entity. An e-commerce product page might have one JSON-LD block for the Product schema, another for BreadcrumbList, and a third for FAQPage if the product description includes questions and answers. Google processes all JSON-LD blocks on a page independently, so there is no conflict from having multiple schema blocks as long as each accurately describes real content on the page.
Agency Perspective: JSON-LD in Practice
Common JSON-LD errors include using incorrect property names (case-sensitive in JSON-LD), invalid data types (using a string where a URL or number is expected), referencing entity types that are not appropriate for the actual content, and omitting required properties for rich result eligibility. Google's Rich Results Test tool identifies these errors by fetching the URL and parsing all JSON-LD blocks, reporting which properties are missing, invalid, or create conflicts. Regular audits through Google Search Console's Enhancements reports catch new errors introduced by CMS updates or template changes.
Frequently Asked Questions: JSON-LD
JSON-LD (JavaScript Object Notation for Linked Data) is a lightweight linked data format and the recommended encoding method for implementing Schema.org structured data on web pages using a standalone script block.
Google can process JSON-LD in either the head or the body of the HTML document, and both placements are valid. Best practice is to place JSON-LD in the head section for faster discovery, particularly for schema types that influence how a page is indexed like Article, Product, and BreadcrumbList. For dynamically generated schema injected by JavaScript after page load, placement in the body is acceptable. The key requirement is that the JSON-LD is present in the fully rendered DOM that Googlebot processes, not just in the pre-render HTML shell.
You can have multiple JSON-LD blocks of the same type on a page, but it is generally better to consolidate properties into a single block to avoid ambiguity. Multiple Product blocks on a single product page, for example, might confuse Google about which is the primary product. The exception is carousel-style pages like recipe lists or event listings where multiple items of the same type are legitimately presented together — in those cases, either an ItemList schema wrapping multiple items or separate blocks for each item are both acceptable approaches per Google's guidelines.
The easiest method is through an SEO plugin. Yoast SEO, Rank Math, and SEOPress all generate JSON-LD automatically for posts, pages, products, and other content types based on configuration settings. For custom schema types not covered by plugins, add JSON-LD through a functions.php hook using wp_head action, a custom mu-plugin, or a code snippet plugin that injects a script tag in the page head. For WooCommerce product schema, plugins like Schema Pro or the Rank Math Pro schema builder allow property mapping from product meta fields to Product schema properties without custom development.
MV3 Marketing helps B2B companies apply these strategies to drive measurable pipeline growth. Our team executes our services for technology, SaaS, and professional services companies.
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
