Squarespace Schema Setup: Steps and Pitfalls to Avoid
A cafe owner on Squarespace has found two different routes for adding schema, header code injection and code blocks, with mixed advice online about which one actually works. Short answer: for site wide markup, use code injection. For page specific markup, use a code block or page header injection where your plan allows it. Whichever route you choose, always check that your schema block appears exactly once in the rendered page source, because the pitfalls in this process are almost always duplicates or the wrong scope, not a wrong syntax.
This post gives you the steps for each route, the pitfalls most likely to trip you up, and how to verify a block is actually live once you have added it. Squarespace's default output differs by template and version, so the guidance throughout is to check your own page directly rather than assume it behaves like any example described here.
Two Routes, Two Different Jobs
Code injection, found under Settings, Advanced in Squarespace's editor, lets you add code that applies sitewide, typically in the header of every page. This is the right tool when you want a piece of structured data, such as your shop's basic LocalBusiness details, to appear consistently across every page of the site, since it only needs to be entered once and then applies everywhere.
A code block, added directly onto an individual page, is scoped to that one page only. This is the right tool for markup that genuinely differs page by page, such as a FAQ block that should only apply to a specific page's actual FAQ content, or an Event listing tied to one specific page about one specific event. Using sitewide code injection for page specific markup would apply that markup to every page regardless of whether the content on that page matches it, which creates exactly the kind of mismatch between markup and visible content that causes real problems.
Squarespace's plan structure affects which of these routes is available. Code injection, both sitewide and on a per page basis where the platform allows it, is generally tied to higher tier plans rather than the most basic plan level, so the first practical step for any owner is confirming their current plan includes code injection access before planning a setup around it.
Steps for Sitewide Code Injection
Open Settings, then Advanced, then Code Injection. This is where Squarespace exposes fields for header and footer code that will apply across the entire site. Paste your LocalBusiness JSON LD block, wrapped in a script tag with the appropriate type attribute, into the header field.
Save the change and publish the site if a separate publish step is required, since a saved change in the editor does not always mean it is live on the public facing page until a publish action completes. This distinction between saving and publishing is one of the more common places an owner assumes a change is live when it is still sitting unpublished.
Once published, view the live page's source directly, not the editor preview, and confirm the script tag and its JSON LD content appear in the rendered header exactly as entered. A preview inside the editor does not always reflect what the final published page outputs, so the only reliable confirmation is checking the live, published URL's actual source.
Steps for Page Specific Markup
For markup that should only apply to one page, add a code block directly onto that page through the page editor, or use page level header code injection if your plan and template support it separately from the sitewide field. A code block sits in the page's content area itself, while page level header injection, where available, places the code in that specific page's head section rather than the body.
This distinction, head versus body placement, matters for JSON LD specifically. JSON LD is commonly placed in either location and is generally read correctly by structured data tools regardless of head or body placement, but a code block added to the page's visible content area can sometimes render inconsistently depending on how the specific template handles that content block, which is exactly the kind of template dependent behavior that makes checking your own page directly, rather than assuming, essential.
After adding page specific markup, publish the page and view its live source the same way described for sitewide injection. Confirm the block appears in the rendered page and that it did not also get duplicated by any sitewide code injection that might already be outputting a similar or identical block.
Pitfall One: Duplicate Blocks
The most common and most consequential pitfall in this whole process is ending up with two schema blocks on the same page describing the same thing, one from sitewide code injection and a second added separately as a page specific code block, both outputting overlapping or identical LocalBusiness information. Structured data testing tools can flag this as a conflict, and even where a tool does not flag an outright error, duplicate blocks describing the same entity are messy and can create ambiguity about which block a system reading the page should treat as authoritative.
The fix is procedural, not technical: before adding any page specific block, view that page's current live source first and check whether a sitewide injected block is already present and already covering what you were about to add again. If it is, either skip the page specific addition or adjust the sitewide block instead, rather than adding a second, overlapping one.
This single habit, check before you add, prevents the majority of duplicate block problems before they happen, and it takes less time than diagnosing and removing a duplicate after the fact once it has already been published for a while.
Pitfall Two: A Block That Does Not Render
A code block placed in a section of the page that does not output into the rendered head, or that gets stripped or altered by the specific template in use, is a real, template dependent risk. Not every Squarespace template treats every content block identically, and a code block behaving one way on one template can behave differently on another.
This is exactly why viewing the live, published source, not the editor preview, is the only reliable check. A preview inside the editor can visually appear correct while the actual published output differs, since previews and live pages are not always rendered through identical processes. Treat the editor preview as a starting indicator only, and the live source view as the actual verification step.
If a block does not appear in the live source after publishing, the most likely explanations are a missed publish step, a template that alters or strips that specific type of content block, or the code having been placed in a field that does not correspond to where you intended it to output. Working through these three possibilities in order, rather than assuming the code itself is wrong, resolves most non rendering issues.
Pitfall Three: Markup That Contradicts Visible Content
Structured data is meant to describe what is on the page, and markup that states something different from what a visitor sees, a phone number in the schema that does not match the phone number displayed on the page, hours in the markup that do not match the hours shown, is a real problem independent of any technical rendering issue. This kind of mismatch commonly happens when a schema block was set up once, correctly, and then the visible page content changed later, hours updated, a phone number changed, without the schema being updated to match.
The practical fix is treating schema as a piece of content that needs the same maintenance attention as any other detail on the page. When hours, contact information, or other basic details change on the visible page, the same change needs to be made in the corresponding schema block, whether that block lives in a sitewide code injection field or a page specific block.
This is a genuinely easy pitfall to fall into precisely because schema is invisible to a normal site visitor and easy to forget about during a routine content update that only touches what visitors can see. Building a habit of checking schema alongside any hours or contact information change closes this gap before it becomes a real accuracy problem.
Pitfall Four: Cache and Preview Differences
Squarespace, like most website platforms, can serve cached versions of a page to visitors for a period after a change is published, meaning a change that is technically live may not appear immediately to every visitor or every tool checking the page. This can create a confusing situation where a change appears correct in one check and missing in another, depending on whether a cached version was served.
The practical response is patience combined with a direct check: after publishing a change, wait a short period before running a structured data verification tool, and if the tool shows an unexpected result immediately after publishing, try again after some time has passed rather than assuming the change failed. A hard refresh, bypassing the browser's own cache, on the live URL is also worth doing before concluding a change did not take effect.
This pitfall is more about patience and process than about anything being technically wrong. Most cache related discrepancies resolve on their own within a short window, and treating an immediate post publish check as the final word can lead to unnecessary troubleshooting of a change that worked correctly.
Timing: Publish Versus Preview
One detail worth its own explicit mention, since it causes confusion often enough to name separately: saving a change in the Squarespace editor and publishing that change are not always the same action, and a code injection or code block change that looks saved may still need a separate publish step before it appears on the live, public facing page. An owner who checks their schema immediately after saving, without confirming a publish also completed, can easily conclude a change failed when it simply has not gone live yet.
This distinction is worth building into a personal checklist: save, publish, then verify, in that order, every time a schema change is made, rather than treating save and publish as interchangeable steps. It costs nothing extra to confirm publish happened explicitly, and it removes an entire category of false alarms where a change appears to not be working simply because it was never published.
Verifying a Block Is Live and Correct
Verification has two steps, done in order. First, view the live, published page's source directly and confirm the JSON LD script tag and its content appear exactly once, matching what you intended to add, with no unintended duplication from a separate injection route. This is the count check, and it is worth doing on its own before any external tool, since a duplication or absence problem is easiest to catch by looking at the raw source directly.
Second, run the live URL through Google's Rich Results Test and through the Schema Markup Validator at validator.schema.org, both of which read the actual live page and report back on what structured data they detect, any errors, and any warnings. These tools give a second, independent confirmation beyond your own visual check of the source, and they will flag certain kinds of errors, like a malformed property, that might not be obvious from reading the raw JSON LD by eye.
Together, these two checks, a manual source count and an external validator run, cover both the risk of a duplicate or missing block and the risk of a structurally malformed one, and running both takes only a few minutes once a block has been published.
Related Reading
More from Hillcane on this topic, plus the pages on the site that sit next to the work.
Frequently Asked Questions
Where do I find code injection in Squarespace?
Open Settings, then Advanced, then Code Injection. Squarespace exposes header and footer fields there for code that applies sitewide, and the header field is where a LocalBusiness JSON LD block, wrapped in a script tag, usually goes. Code injection is generally tied to higher tier plans rather than the most basic one, so confirm your current plan includes it before planning your setup around that route.
Should I use code injection or a code block for schema?
Use sitewide code injection, under Settings, Advanced, Code Injection, for markup that should appear on every page, such as basic LocalBusiness details entered once. Use a page specific code block, or page level header injection where your plan allows it, for markup that differs page by page, such as an Event tied to one event page or a FAQ block matching that page's visible questions. Wrong scope creates mismatches.
What is the most common schema mistake on Squarespace?
Duplicate blocks: a sitewide code injection block and a separate page specific code block both outputting overlapping LocalBusiness data on the same page. Google's Rich Results Test and the validator at validator.schema.org can flag the conflict, and even unflagged duplicates leave ambiguity about which block is authoritative. Before adding any page level block, view that page's live source and check what the sitewide injection already covers.
Does it matter whether JSON LD is placed in the head or the body?
JSON LD is generally read correctly by structured data tools regardless of head or body placement, but a code block added to a page's visible content area can render inconsistently depending on how the specific template handles that block, so checking your own live page source is the only reliable way to confirm placement worked as intended.
How do I check that a schema block is live?
Save, publish, then view the live page's source directly, not the editor preview, and confirm the JSON LD script tag appears exactly once with the content you intended. The editor preview can look right while published output differs by template. If the block is missing, check three things in order: a skipped publish step, a template that strips that content block, or code placed in the wrong field.
Why might a code block not render even after I save it?
The most likely reasons are a missed publish step, since a saved change is not always a published one, a template that alters or strips that type of content block, or the code being placed in a field that does not correspond to where you intended it to output. Work through these three possibilities before assuming the code itself is wrong.
What tools should I use to validate the schema once it is live?
Use Google's Rich Results Test and the Schema Markup Validator at validator.schema.org. Both read the live page and report detected structured data, errors and warnings, and together they catch problems such as a malformed property that are hard to spot by eye. Run them after a manual count of script tags in the live page source, and if results look odd right after publishing, wait and recheck.
Can a cached page show an outdated result after I publish a change?
Yes. Squarespace, like most platforms, can serve a cached version of a page for a period after a change is published, so a working change can look missing in an immediate check by the Rich Results Test or the Schema Markup Validator. Wait a short while, do a hard refresh on the live URL to bypass your browser's cache, and confirm a publish happened before troubleshooting further.
Do all Squarespace templates handle schema and code blocks the same way?
No. Output differs by template and version, and a code block that renders one way on one template can be altered or stripped on another. That is why this post recommends checking your own live page source rather than assuming it matches any example. Note which template you use when troubleshooting. Squarespace runs 267 of the 1,109 shops in Hillcane's census, so that template variety is real.
How can Hillcane help set up schema correctly on a Squarespace site?
Hillcane can confirm your plan includes code injection, pick the right route for each piece of markup, sitewide LocalBusiness in Settings, Advanced, Code Injection or page specific blocks for events and FAQs, and then verify on the live source that each block appears exactly once and passes the Rich Results Test and validator.schema.org. Reach out at hillcane.co/contact or call (256) 384-2449 to talk through your Squarespace setup.
Work with Hillcane
Two routes for Squarespace schema, header injection and code blocks, and most of the confusion comes down to duplicates or the wrong scope. Here is how to get it right.
Want a second set of eyes on your Squarespace schema setup? Reach Hillcane at hillcane.co/contact or call (256) 384-2449.
Comments