How to Add Schema Markup by Platform
The useful question is not how to add markup on each platform. It is what your platform already does without being asked, because most businesses have structured data they never installed, do not know about and have never checked.
You Probably Already Have Some
Every common platform outputs structured data automatically. Nobody asked it to, nobody reviewed it and the site has been making those claims since the day it launched.
Why businesses are unaware. Nothing announces it.
No setting was switched on, no invoice mentioned it and nothing on the page reveals it. The markup exists in a part of the page nobody looks at, describing the business to anything that reads it.
Why that matters rather than being harmless. It is still an assertion.
Automatically produced markup states things as fact exactly as hand-written markup would. The claims are being made on your behalf whether or not anybody in the business knows what they say.
What this page is therefore about. Discovery before addition.
Establishing what exists, where each part comes from and whether it is accurate. Adding more before knowing that is how sites end up asserting the same thing twice in different ways.
How much of it is wrong. More than anybody expects.
Not usually through carelessness. A platform describes a business using whatever it was told at setup. Businesses then move, change numbers and adjust their hours. The markup keeps stating the original values until somebody notices.
What it will not contain. Configuration steps.
No settings to change, no extensions named, no instructions. Those date within months and the judgement does not, so this page stays at the level of what to establish and what has to be true.
Squarespace
The platform we build on, which means we know precisely what it produces and where the limits sit. It outputs a reasonable baseline automatically and leaves the specific types to you.
What it produces without being asked. The structural basics.
Descriptions of the site itself, of individual pages and of blog posts including their dates. Enough that a page is identified correctly. Not enough to describe a business, a product or a location properly.
What it does not produce. The commercially useful types.
Nothing describing your business as an organisation, your premises, your services or your products in the detail those types allow. Those have to be added deliberately, which is where most of the value sits.
How additional markup gets added. Into the page itself.
The platform allows additional blocks to be placed on individual pages or across the site, which is sufficient for everything a business needs. It is a decision about what to assert rather than a technical obstacle.
What we do on every build. The full set.
Article, questions and breadcrumb descriptions on every guide, organisation details site-wide, then local business or product descriptions where the page contains one. Nothing added that the page does not display.
The specific thing to watch. Commerce pages.
Where the platform's shop is used, product details are produced from the product fields. Those fields are the assertion, which block six covers.
WordPress
The platform itself produces very little. Almost all the markup on a WordPress site comes from an extension or a theme rather than from the platform. That distinction has consequences.
What the platform supplies. Barely anything.
The underlying software is a publishing system rather than a search tool, so the structured data most sites carry was added by something else installed on top of it.
Which means the markup is not yours. It belongs to what produced it.
The descriptions your site outputs depend entirely on which extension is active and how it is configured. Change the extension and the assertions change with it.
The consequence people discover late. Removal removes assertions.
Deactivating or replacing whatever produces the markup deletes everything it was describing. Nothing visible changes, no error appears and the site has silently stopped making claims it made yesterday.
Why that matters at a rebuild. Themes carry markup too.
Some themes output their own descriptions independently. Changing a theme can therefore alter structured data even where no extension was touched, which is rarely anticipated.
What to establish first. Which thing is responsible.
Before changing anything, find out what is producing the markup. On this platform that is genuinely the first question. The troubleshooting page covers finding all the sources.
Shopify
A store produces product markup by default, which sounds convenient and creates a specific complication: themes and add-ons both produce markup, which is how stores end up with duplicates and conflicts.
What a store produces by default. Product details.
Names, prices, availability and images drawn from the product records. Genuinely useful and automatically maintained as products change, while taking whatever the records say.
Where the duplication comes from. Two willing sources.
The theme produces product markup. Add-ons frequently produce their own, particularly anything handling reviews or feeds. Neither knows about the other, so both describe the same product.
Why this is worse on stores than elsewhere. More moving parts.
A typical store runs several add-ons, each potentially describing something. That produces more possible sources than either of the other platforms. Each addition is a new one nobody audits.
The specific case worth checking. Ratings.
Where a review add-on and the theme both describe ratings, a product can carry two different figures. Review markup sets out the rule that governs any of them.
The other complication. Feeds.
Stores frequently send product data to other places as well, with those exports coming from the same records. A wrong value therefore appears in the markup and in the feed simultaneously, which multiplies a single error rather than containing it.
What a store owner should assume. More than one source.
On a store with several add-ons, assume duplication until checked rather than the other way round. That assumption is right more often than not.
The Duplication Problem
A theme, an extension and a manual addition can each output the same type. That produces conflicting assertions about one page. Finding all the sources is the first step rather than changing any of them.
How three sources arise. Nobody coordinating.
The theme was written by one party, the extension by another and the manual addition by whoever was asked to improve things. None of them knew about the others and each did a reasonable job alone.
What the conflict actually is. Contradictory claims.
Two descriptions of the same business with different phone numbers. Two product descriptions with different prices. The page is now asserting both. Nothing decides which is true.
Why it is hard to spot. Everything validates.
Each description is well formed on its own, so no check reports a problem. The fault is the disagreement between them, which requires somebody reading all of them together.
Why finding comes before fixing. Removing the wrong one.
Deleting the source you found first frequently removes the correct description while leaving the wrong one. Establishing the full list before touching anything prevents that.
What the right outcome looks like. One source per type.
Each type described once, by something you know about, with values you have checked. That is achievable on all three platforms and it is rarely the starting position.
Automatic Markup Asserts Whatever It Was Given
Generated markup takes its values from fields somebody filled in. Nobody checks those fields afterwards, so a wrong value becomes a false assertion at scale rather than once.
Where the values come from. Settings and records.
A business name typed during setup, an address entered once, opening hours filled in by whoever built the site. Product fields completed at upload, sometimes imported in bulk.
Why nobody revisits them. They are not visible.
A wrong value in a settings field affects no page anybody looks at. Nothing prompts a review, so an error entered during setup can persist for the life of the site.
Why the scale is the problem. One field, every page.
A hand-written mistake is one false claim on one page. A wrong settings value is the same false claim on every page the platform generates, which is a different order of problem.
The commonest examples. Four.
An old phone number, hours that changed, an address from a previous premises and a business name entered slightly differently from the one used everywhere else.
What this means practically. Audit the fields, not the pages.
Since the markup inherits from the fields, checking the fields checks every page at once. That is the efficient version of the accuracy work rather than reading page by page.
Hosted Platforms Limit What You Can Do
Some platforms restrict where markup can be placed and what can be changed. That is a real limit rather than an excuse. It is worth knowing before anybody promises anything.
What gets restricted. Two things.
Where additional markup can be inserted, plus whether the platform's own automatic output can be altered or switched off. The second is the one that causes difficulty.
Why the second matters. You cannot remove what you did not add.
Where a platform produces markup you would rather it did not while offering no way to suppress it, the only options are working around it or accepting it. Neither is satisfying.
What that produces in practice. Unavoidable duplication.
Adding a better description of something the platform already describes leaves both in place. On a hosted platform that is occasionally the best available outcome rather than a mistake.
Why the trade is usually still worth it. Everything else is easier.
Hosted platforms remove a great deal of maintenance in exchange for these limits. Our Squarespace material covers that trade properly. Structured data is a small part of it.
What to do before committing. Ask what can be changed.
Anybody proposing markup work on a hosted platform should be able to say what the platform will and will not permit. Vagueness there is worth noticing.
What To Check On Any Platform
Three questions, in this order, whatever your site is built on. None of them requires touching anything and all three have to be answered before any change is worth making.
What types exist. The inventory.
Which descriptions your pages currently carry, across the different page types rather than on one example. A shop, a service page and a guide will each carry something different.
Where each one comes from. The attribution.
Platform, theme, extension or manual addition. This is the question that takes the longest and the one that prevents removing the wrong thing later.
Whether the values are accurate. The assertion check.
Reading what each description actually says and confirming it is true of the business today. Names, numbers, addresses, hours, prices and availability.
What to do with the answers. Reduce, then correct.
Remove duplicate sources so each type is described once, then fix the values in whatever remains. Doing it the other way round means correcting descriptions you are about to delete.
How to see what a page outputs. Check the published version.
Platform-generated markup only appears on a live page rather than in a template. How to test schema markup covers that distinction. The full series is on the schema and structured data guide.
Find every
source before
removing any.
Deleting the first source you find frequently removes the correct description and leaves the wrong one. We establish what your pages assert, where each part comes from and whether the values are still true, before changing anything.
On every page we build:
Squarespace is our core build platform, so we know exactly what it will and will not permit.
Every guide.
One practice.
What structured data is, which types apply to your business, how to test it, where the results features come from and what to do when nothing appears.
