WordPress JSON-LD: Inspect and Maintain the Rendered Markup

Inspect what WordPress already publishes

Before adding JSON-LD to a WordPress site, inspect a rendered article page for script elements whose type is application/ld+json. A theme, SEO plugin or content block may already emit the article, author and site entities. Adding a second manually maintained block without checking the existing output can create conflicting descriptions.

Record which component owns each block. Use the site's staging environment when changing plugin or theme behavior. The relevant control panel labels vary by the installed component and version, so follow that component's documentation instead of assuming every WordPress dashboard has the same structured-data switch.

Map fields to the actual content record

For an article, start with its visible title, public URL and credited author. Preserve its original publication date and distinguish a substantive revision date from a page cache refresh. An image should refer to the appropriate public media file, not an editor's local upload path.

A fictional minimal record might look like this before the publishing template embeds it. It omits dates and images intentionally because a minimal illustration should not invent facts it has not supplied.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/map-notes/#article",
  "url": "https://example.com/map-notes/",
  "headline": "Keep useful map notes",
  "author": {
    "@type": "Person",
    "name": "Example Author",
    "url": "https://example.com/about#editor"
  }
}

In a real implementation, derive those values from the article record and the site's chosen author identity. Do not copy one author's data into every page or infer a professional credential from a username. If the visible credit is an organization, model that actual entity instead.

Choose a maintainable publishing owner

If an existing plugin already generates suitable structured data, use its supported configuration or extension hooks to adjust the fields. If a custom theme owns the markup, keep the logic in the project's maintained code rather than pasting separate permanent copies into hundreds of posts.

The WordPress wp_head hook is one documented place where code can emit content into the document head. A hook-based implementation still needs appropriate page conditions: an article-specific object should not accidentally appear on search results, category archives or a contact page.

Keep customizations in a maintained child theme or project plugin where appropriate to the site's architecture. Editing a vendor theme file directly can make an update overwrite the change. Test the chosen ownership path when updating the theme or plugin.

Serialize data safely in the template

Build a data structure and serialize it instead of concatenating JSON strings around post titles. WordPress provides wp_json_encode for JSON encoding. The surrounding HTML script context also needs safe escaping, including a literal closing script sequence inside user-editable content.

Use the encoding options and template strategy appropriate to that context, then inspect the generated page source. Ordinary HTML text escaping can produce entity text that is wrong inside a JSON script block; ordinary JSON encoding without HTML-context handling can leave a script boundary problem. Verify both layers rather than relying on the function name alone.

Test a title containing an ampersand, a double quote and a less-than character. Parsing the script's text should recover the intended title, and the HTML parser should still see one intact data block with no accidental executable element.

Check representative pages after the change

Review a standard article, an article with a different author and a page that should not receive Article markup. Check draft or private content through the site's normal access rules so the public output does not disclose content that was meant to remain unpublished.

Clear or refresh the relevant page cache through the site's established process, then inspect the public rendered response. A correct editor preview does not establish that a cached page has updated. Compare the visible byline, title, image and dates with the corresponding JSON-LD values.

The local JSON-LD Generator can help draft a synthetic starting object, but it does not install a WordPress integration or identify existing plugin output. Keep the actual publication logic tied to the site's content data and use the applicable consumer's validation tools before relying on the markup.

Related guides

JSON-LD vs Microdata: Keep One Consistent Article Identity

Compare equivalent JSON-LD and Microdata article examples, preserve nested author scope, and prevent conflicting markup during a migration.

JSON-LD Markup: Describe One Page with Consistent Entities

Build a small JSON-LD article object, choose stable entity identifiers, embed JSON safely, and compare the markup with the visible page.

FAQ JSON-LD: Model Questions Without Obsolete Search Claims

Create FAQPage JSON-LD from visible question-and-answer pairs, check pairing and escaping, and understand the retired Google FAQ search feature.