How to Add Schema Markup to Your Site
Where structured data goes, how to replace an existing plugin node instead of duplicating it, the developer brief, and the facts-must-match rule.
What you are adding, and where
A block of JSON-LD — a short piece of structured text in a script tag — placed in the head of your page, describing your business in a form a machine reads directly instead of inferring from your prose. You never see it on the page; it exists only for machines. If you are using a plugin or a platform field that generates it for you, your job is to make sure the facts you give that tool match your website exactly.
Check what you already have first
Most sites already emit some schema, often from a theme or an SEO plugin, and this is where the damage usually starts. View your page source and search for "application/ld+json". If you find one, read it: note the business name, address, phone and any ratings. If you add a second block without removing the first, you now publish two different descriptions of one business, and a model that finds conflicting phone numbers trusts neither. Never add a second source of truth — replace, do not append.
On WordPress
Your SEO plugin almost certainly already has a settings screen that writes the organisation or local business node — look for that before adding anything by hand, because it is maintained through updates and the hand-written version is not. Use it to fill in the business name, address or service area, phone, logo and social profiles, then check the rendered page source to confirm what it actually produced. Only add a custom JSON-LD block for the parts your plugin does not cover — typically the Person node for the owner, FAQ markup on a specific page, or the @id links that turn separate blocks into one connected graph.
Paste it per page, or template it?
Page-specific nodes — a FAQ block, a service page description, an article's author — belong on that page. Business-wide nodes — who you are, where you operate, how to reach you — should be emitted once and referenced by @id from everywhere else, which is exactly what turns a pile of blocks into a graph. If your plugin handles the business node, leave it to the plugin and add only the page-level pieces. If you hand-place everything on every page, you will eventually publish two pages that disagree, and that is worse than having no graph.
If your site has a developer
This is a good task to hand over, because getting it right once is far less work than fixing it repeatedly. Send them: the drafted JSON-LD, the instruction that it belongs in the document head of the relevant pages, that the business node should be emitted once and referenced by @id rather than duplicated, and that every fact must match the visible page text. Ask them to confirm no existing LocalBusiness or Organization node is left emitting conflicting values, and to validate the result in Google's Rich Results Test and the Schema Markup Validator before calling it done.
Validate before you consider it live
Put the live URL into Google's Rich Results Test and the Schema Markup Validator. Both should parse your markup without errors. Warnings about optional properties are usually harmless; errors are not, and an error often means a single missing comma or a trailing comma that JavaScript tolerates but strict JSON does not. Validate the published page rather than the draft, because a CMS can alter or escape the block as it renders it.
The facts must match the page
This is the rule that decides whether any of the work counts. A rating in your markup that does not appear as a visible rating on the page is treated as unverifiable, and for ratings it can attract a manual penalty from Google. A phone number in the markup that differs from the one in your footer is a contradiction. The standing test is simple: every value in the structured data should be findable by a human reading the page. If it is not, remove it — a smaller honest graph beats a larger invented one.
When you change something, change it here too
Structured data is a snapshot, and it goes stale quietly. A changed phone number, a new address, a rebrand, a service you have stopped offering — each of these needs updating in the markup in the same sitting as the site, because a model reading stale structured data will confidently repeat yesterday's facts. If your schema is plugin-generated this happens automatically; if it is hand-placed, add it to whatever checklist you use for site changes.
Did this guide answer your question?
See how visible your business is to AI
Get your free 0–100 AEO score across ChatGPT, Perplexity, Gemini, Claude, and Google AI Overviews.