How to Add Schema Markup to a Website Without Losing the Page

Add schema markup by describing the page you already have, writing the facts as JSON-LD, and placing that block in the rendered HTML. The safest build starts with visible content and ends with a test of the real public URL.

Do not begin with a generator and ask what you can make it emit. Begin with the page. The page decides the type. The visible facts decide the properties.

Step 1: Name the job of the page

Write one plain sentence that says what the page gives a visitor. For example:

• This page sells one coffee grinder.
• This page explains how to clean a coffee grinder.
• This page introduces the company that makes the grinder.
• This page lists the navigation trail to the grinder.

Those pages do different jobs. They should not all use Product as the main type merely because the same grinder appears on them.

Step 2: Choose a type that matches the visible content

Use the narrowest accurate type, not the type with the most exciting search feature. A product detail page may use Product. A how-to article may use Article when the page does not meet the requirements for a supported HowTo feature. A company page may use Organization. A normal information page may use WebPage.

Use the schema type guide when two types seem possible.

Step 3: List the facts the page can support

Make a short inventory before writing code. A basic article might support:

• Headline
• Canonical URL
• Author
• Publication date
• Modification date
• Primary image
• Publisher

If the page does not show or support a fact, do not smuggle it into the markup. Add the information to the page first when the reader should see it.

Step 4: Build a small accurate JSON-LD block

{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/grinder-cleaning/#article",
  "headline": "How to Clean a Burr Coffee Grinder",
  "url": "https://example.com/grinder-cleaning/",
  "datePublished": "2026-10-10",
  "dateModified": "2026-11-02",
  "author": {
    "@id": "https://example.com/about/#person"
  },
  "publisher": {
    "@id": "https://example.com/#organization"
  }
}

The identifiers connect this article to author and publisher nodes that can remain consistent across the site. If those nodes do not exist yet, publish complete author or publisher details in the same graph rather than leaving references with no defined entity.

Step 5: Put the JSON-LD in rendered HTML

Wrap the JSON in an application/ld+json script:

<script type="application/ld+json">
{ ... valid JSON-LD ... }
</script>

The exact edit depends on the website:

• Static HTML: Add the script to the page HTML, commonly in the head or body.
• PHP or another server template: Build the data from the canonical content record, encode it as JSON, and print one safe script block.
• Content management system: Use a theme, custom field system, or plugin that lets the visible content and markup stay synchronized.
• JavaScript application: Confirm that the final rendered response exposes the block and that the values update when the page changes.

Google can process JSON-LD placed in the head or body. The important part is that the rendered page contains valid markup that describes the visible page.

Step 6: Compare the markup with the page

Read the schema as if it were a second version of the page. Compare the name, headline, dates, author, image, price, availability, breadcrumbs, and canonical URL.

A validator may accept a well-formed lie. Accuracy still needs a human check.

Step 7: Test the block and the public URL

1. Parse the JSON-LD and confirm every block is readable.
2. Use the Schema.org Markup Validator to inspect types, properties, and connected nodes.
3. Use Google's Rich Results Test when the page targets a Google-supported feature.
4. Deploy the page.
5. Test the public URL again so routing, caching, template logic, and canonical output are included.

The existing schema testing guide explains why the official tools give different answers.

Step 8: Keep schema tied to the content source

Hand-edited markup drifts. A price changes on the page but not in the JSON-LD. An author name changes in one template. A moved page keeps the old URL in its identifiers.

Generate repeated facts from the same canonical content fields whenever possible. One source should feed the visible page and the schema. That does not remove the need for review, but it stops two versions of the same fact from aging apart.

Step 9: Watch the page after publication

Use Search Console enhancement reports when the type has one. Inspect the indexed URL. Watch for new errors after template changes. Recheck pages when prices, dates, availability, authors, or canonical URLs change.

Do not measure success only by whether a rich result appears. Accurate markup, stable entity references, clean rendered output, and maintainable generation are wins you control.

A plugin is not the implementation plan

A plugin can save time. It can also choose a broad type, duplicate markup from another plugin, or publish fields that no longer match the page.

Use a plugin when it gives you control over the final graph and stays synchronized with the content. Test the output. The button you clicked is not the release receipt. The rendered page is.

Finish with your own page

Open the Schema Markup Checker and test the exact URL you changed. If the types surprise you, trace which template, plugin, or content field created them before adding another block.

When you need a model to compare against, use the schema markup examples.