Schema markup on Webflow CMS pages, written once

To add schema markup to Webflow CMS pages, paste one JSON-LD script into the collection template’s Page settings, under Custom code, inside the head tag, and insert CMS field values with “+ Add field”. Every item in the collection then publishes its own structured data, built from its own fields.

The short answer

You write the markup once, on the template, not once per item. Webflow replaces each inserted field with that item’s value when the page is published, so a blog with two hundred posts gets two hundred correct blocks from one script.

Three things decide whether it works:

• The fields you insert should not contain straight quote marks, which Webflow encodes for HTML rather than for JSON.
• The values in the markup must match what the page visibly says.
• You check the published result in a validator, not the code in the editor.

Before the how, a word on what the markup will and will not do for you, because a lot of advice on this is out of date.

What schema markup does today

Structured data is not a ranking factor, by Google’s own statements. Adding it does not move a page up. What it does is make the page eligible for rich results, such as a product price and rating, an event date or a breadcrumb trail in place of a raw URL, and those features are shown at Google’s discretion.

Some rich results are gone for most sites. In August 2023 Google limited FAQ rich results to well-known, authoritative government and health websites, and stopped showing HowTo rich results around the same time. Markup written to win the FAQ dropdown in search no longer wins it for a typical business site.

That does not make the markup pointless. JSON-LD states a page’s facts in a form with no room for interpretation: this is an article, this is its author, this is the date it was last changed, this is the organisation that published it. Crawlers and answer engines read pages, and markup makes those facts unambiguous to parse. We would not promise more than that, and nobody can honestly measure more than that today.

Where the block goes on a CMS template

Open the CMS collection template page in the Designer and go to its Page settings. In the Custom code section, use the field for code inside the head tag. That code runs on every item page of the collection.

While the cursor is in that field, “+ Add field” inserts a reference to a CMS field of the collection. In the editor it appears as a token. On the published page it is replaced by the item’s value. Everything you type around the tokens stays literal, which is exactly what JSON-LD needs: fixed keys, variable values.

Site-wide markup, such as the Organization block, goes on the home page’s own Page settings instead, so it is written once for the whole site.

A BlogPosting block, filled from fields

Here is a block for a blog collection. Where it says {{Name}} or {{Summary}}, insert that field with “+ Add field” instead of typing the braces.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "{{Name}}",
  "description": "{{Summary}}",
  "image": "{{Main image}}",
  "datePublished": "{{Published date}}",
  "dateModified": "{{Updated date}}",
  "author": { "@type": "Person", "name": "{{Author name}}" },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": "https://example.com/blog/{{Slug}}"
}
</script>

Open the published page, view the source and read the rendered block. Check that the image is a full URL and that both dates read in ISO 8601, like 2026-10-04, which is the format the date properties expect. If a field prints something else, use a different field or a plain text field you fill in that format.

The publisher points at an @id instead of repeating the company’s details. That identity is declared once, on the home page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Studio",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png"
}
</script>

The quote mark in a CMS field

Each inserted value lands between two straight double quotes in your script, and Webflow encodes it for HTML, not for JSON. A straight quote in a field is published as ", so a headline like The "right" way to migrate reaches the markup as The "right" way to migrate. The block still parses, and the headline a machine reads no longer matches the one on the page.

Paste the same title into a hand written block as typed and it is worse: the quote ends the string early, the rest is a syntax error, and the whole block is ignored. Nothing on the page looks wrong in either case. Try both in the demo at the top of this note.

After every content migration or bulk import, open the published source of a handful of items and run them through a validator, starting with the ones whose titles contain quotes.

Which types to use

Pick the type that describes the item, and fill the properties the page can back up.

• BlogPosting or Article for posts, news and guides: headline, datePublished, dateModified, author, image and publisher.
• Product for a product collection: name, image, description, and offers with price and currency, if the price is on the page.
• Event for an events collection: name, startDate, location, and endDate where there is one.
• FAQPage when the page shows questions with their answers. Every question and answer in the markup must be visible on the page, word for word.
• BreadcrumbList for the trail from the home page to the item: home, the collection page, then the item itself.
• Organization once, on the home page, with an @id that every other block references.

Leave out any property you cannot fill truthfully. A rating with no reviews behind it, or a date that is not the real one, is worse than no property at all.

Validate before you trust it

Test the published URL, not the code you pasted. Two tools, for two different questions:

1. Google’s Rich Results Test tells you whether the page is eligible for the rich results Google still shows, and flags missing required properties.
2. The Schema Markup Validator checks the markup against schema.org itself, including types Google has no rich result for.

We do this on our own site too: every page ships JSON-LD generated from one route table, the same idea as one block on a CMS template. Our SEO and AEO page reads its own markup live, so you can see the exact output we are describing. If your Webflow site is moving at the same time, the migration checklist covers the redirects that should go with it.