How structured data gets onto your site

A lot is written about structured data: what it is, which types exist, what it does in the search results.

About the question after that, almost nothing. Namely: by which route does the stuff actually get into your page?

That is no side issue. There are three routes, they differ considerably, and the decision is usually never made at all — you install a plugin, and with that it has been made.

What actually gets built in

Structured data is a small block of text in the source of your page. Not visible content, but a description of what is on the page: this is a business, this is its address, these are the opening hours. Or: this is an article, this is the author, this is the date.

The common format for it is one self-contained block that can sit anywhere in the page and does not touch the page's content. Exactly that makes it interchangeable — and that is why there is a choice about how it gets there at all.

Route one: straight into the page

The block is written in where it belongs. Done.

In favour: it is there without detours. No additional program, no additional script, no intermediate step where something can fail. What is in the source is in the source — for everyone who reads the page, immediately and without conditions.

Against: it is manual work, and it repeats. With fifty posts, fifty times. If you change your opening hours, you have to know in which places they are entered.

Makes sense for: a few fixed details that rarely change. The description of the business on the contact page. The details for the home page.

Route two: a plugin

The plugin builds the block from your settings and puts it on every fitting page.

In favour: it scales. Set it up once, and every new post gets its markup automatically. It sticks to the rules without you having to know them. And when the rules change — which happens regularly — you get an update.

That last argument is stronger than it sounds. Markup rules change without anyone announcing it. Details built in by hand quietly go out of date.

Against: it is one more plugin. It runs on every page view, it has to be kept up to date, and it ties you to itself — if you replace it, the markup is gone, because it lived in its settings and not in your content.

And whoever wants to use it seriously usually ends up with a paid version. The free ones often cover only the simplest cases.

Makes sense for: sites with lots of content of the same kind. A blog, a directory, a catalogue.

Route three: through a tag manager

The most interesting route, and the one least is written about.

A tag manager is a tool with which code snippets can be inserted into a page without touching the page itself. You enter them in an interface of their own, and they appear on the website.

In favour — and this is the real argument: whoever does it needs no access to your website.

That is a serious advantage. If you hire someone for it, you do not have to give them admin access. If someone in-house takes it on, that person does not have to reach everything else. And all inserted snippets sit in one place instead of scattered across theme, plugins and settings.

Against — and this is where it gets uncomfortable: a tag manager is an additional program from a third party that runs on every page view. It builds the details into the page afterwards, instead of them being there from the start. And depending on which one it is and what else it does, it becomes something visitors have to be informed about and may have to consent to.

So a route meant to solve an access question can open a consent question. That is a bad trade for a handful of lines that could just as well sit in the source.

Makes sense for: larger organisations with separate responsibilities, where access to the website really is an issue — and where such a tool is running anyway.

Does not make sense for: a site that would introduce it for this reason alone.

The fourth route that is not one

There is a tool with which content can be marked up directly in a search engine's interface, without touching the page.

That sounds convenient and has a catch that decides everything: only this one search engine sees that markup. Other search engines and all other services that use structured data see nothing of it — because nothing is on your page.

For a quick test it may do. As a solution it is none.

What I recommend for small sites

A mixed route, because the requirements differ.

The fixed details about the business straight into the page. Name, address, opening hours, contact routes — that rarely changes and belongs in the source without a detour.

Recurring content through whatever is running anyway. Many SEO plugins already bring the markup for posts and pages. Before you install a second plugin for it: check whether the existing one can do it. Very often it can, and it is just not switched on.

A tag manager only if it is there anyway. Introducing it anew for this purpose costs more than it brings.

That is not a particularly elegant answer. It has the advantage of getting by without an additional program.

How you know it works

The test takes a minute and does not depend on the chosen route.

The quick look: open the source of your page and search for the word schema. If you find a block, something is there. If you find nothing, either nothing is there — or it is built in afterwards, and then it is only in the fully assembled state.

The test that counts: there are public testing tools where you enter your address and that show you what is actually recognised. That is the reliable answer, because they look at the page the way a search engine does.

And that is also the point where route three shows in practice: details built in afterwards show up in some tests and not in others — depending on whether the tool assembles the page fully or only reads the delivered source.

With routes one and two the question does not arise.

The core

The question is not whether you need structured data. The question is what building it in costs you.

An additional plugin, an additional third-party script, or a few lines written once by hand that then stand on their own — those are three very different answers to a task that has the same result in all three cases.

And the third is sufficient more often than it looks.

Sources

• Udemy, SEO: Structured Data & Schema Markup for Webmasters, section 5 — that there are several routes to get the markup block into a page: directly into the source, through an extension that generates the code from settings, or through a tag manager; that the tag manager is useful because it needs no access to the website's admin — whether because someone in the company is to look after the markup, someone is hired for it, or you simply want to keep it separate; that other inserted scripts can be managed in one place through the same interface; and that there is also a markup tool in the search engine's interface, whose markings only this one search engine sees, which is why it is worthless for other search engines and all other users of structured data.
• Udemy, SEO: Structured Data & Schema Markup for Webmasters, section 6 — that generating markup by hand is a lot of work and that an extension is therefore often used; that a paid extension is updated regularly and follows changes to the markup rules; and that free extensions are often limited in scope, so that for the features needed you end up with a paid version anyway.
• Own assessment — the objection that a tag manager is an additional third-party script that runs on every page view, builds the details in afterwards and depending on its setup may require consent, so that the solved access question raises a new question; the recommendation of a mixed route for small sites; the advice to check before installing a second extension whether the existing SEO extension already brings the markup; and the observation that details built in afterwards show up or not depending on the testing tool.
• On the age of the source — the course names a testing tool that has since been replaced by another, and a particular extension with its pricing at the time. Both are deliberately not taken over here. The statements on the three routes do not depend on any generation of tools.