How Do Squarespace Templates Work and When Should You Customise Them?
Most advice online describes an older version of this platform, where a template locked you into a fixed set of features and switching meant rebuilding. That is no longer how it works. The difference changes what you should worry about.
What A Template Actually Is Now
A Squarespace template is a starting point rather than a container. On current sites it determines what your site looks like on the first day and almost nothing about what it can become, which is the reverse of how the platform once worked.
That reversal is the single most useful thing on this page, because a great deal of the guidance in circulation still describes the older arrangement. Articles telling you to choose your template with enormous care, since you will be stuck with its limitations, were accurate when written. They are describing a version of the platform most sites no longer run on.
The commercial consequence is worth stating first. Buyers routinely spend a fortnight agonising over template choice. Some pay for advice on it. On the current platform it is close to the least consequential decision in the whole project.
What matters instead is what gets done afterwards. Structure, styling, content and restraint decide whether the site works. Every one is available regardless of which starting point you picked.
The blocks below set out precisely what changed, what you can alter without any code, what genuinely needs code and which plan, what the phrase custom Squarespace design actually covers and what customisation costs you two years later.
What Changed
The old arrangement. Templates came in families. Each family carried its own style settings and its own features, so choosing one determined what the site could do rather than only how it looked. Switching family moved your content across while your design did not follow.
The current arrangement. Per Squarespace's own documentation in 2026, all sites on the current version belong to a single template family sharing the same features and style options. Nothing is reserved for one starting point.
Now the detail most articles get wrong in one direction or the other. It is worth being exact.
You cannot switch template on a current site. The function was removed. Stated alone that sounds like a restriction worse than the old arrangement, which is how it frequently gets reported.
It is not, because there is nothing to switch to. Squarespace's documentation describes the current version as designed to remove the need to switch, with the template chosen at creation intended only as a starting point. Since every site shares one system, any starting point can be restyled to resemble any other. Switching was removed because it became meaningless rather than because access was withdrawn.
So choosing wrongly is recoverable. It costs restyling time rather than a rebuild. And if you are reading guidance that tells you to choose carefully because you will be stuck, check the date on it before acting.
Sections And The Editor
A page is a stack of sections, each a self contained band with its own settings. Adding one, removing one, reordering them and changing what each contains happens in the editor without touching any code.
That covers considerably more than buyers assume, including a great deal that genuinely did require a developer on the older arrangement. Page layouts, the way each page type is put together and the visual treatment throughout are all now settings.
One detail nobody explains, which causes real confusion. Current sites run two editing systems rather than one. Most block sections use the newer editing experience, while certain areas, including blog posts and events, use the older classic editor.
That is a platform arrangement rather than something a designer selects or a fault in your site. It explains why editing a page can feel different from editing a blog post, plus why an instruction you read somewhere does not match what you see.
Knowing this in advance saves the specific frustration of assuming you have broken something or missed a setting. You have not. You have simply moved between two parts of the platform that behave differently. No amount of paying somebody will consolidate them.
What You Can Change Without Code
Six areas, all available through settings, applied across the site rather than page by page.
Typefaces and type sizes. Which fonts, at what scale, with heading levels set once and applied everywhere.
Colour. Handled as site wide palettes rather than as decisions made element by element, which is what keeps a site coherent as it grows.
Spacing. Between sections and within them, which is the control that does most of the work described in our guide to good Squarespace design.
Section layouts. How content arranges inside each band, including on narrow screens.
Page structure and navigation. What exists, what sits beneath what, what appears in the menu.
Buttons and form styling. Shape, weight and treatment, consistently applied.
Here is why this list is worth reading closely before you agree to anything. Buyers regularly pay for custom code to achieve things the settings already do. It is rarely deliberate. A supplier reaching for code is often reaching for what is familiar rather than what is necessary.
The question that prevents it costs nothing to ask. Before agreeing to any custom code, ask which setting was tried first and why it was not sufficient. A specific answer is reassuring. A vague one means nobody looked.
What Needs Code, And Which Plan
Three things sit outside the settings. Styling beyond what the controls expose. Behaviour the platform does not offer at all. And third party scripts, including tracking beyond what Squarespace handles natively.
The plan constraint, stated precisely. Per Squarespace's documentation in 2026, custom CSS is available across billing plans, while code injection sits on the Core plan and above. Those are two different things and the distinction matters.
Custom CSS covers visual styling. If your requirement is that something should look a particular way beyond what the controls allow, that is generally available to you.
Code injection covers scripts, HTML and tracking pixels. If your requirement involves a third party tool, a chat widget, a booking script or a tracking pixel the platform does not natively support, you need Core or above.
Which turns the plan into part of the specification. If anything in your build needs a script, the tier is no longer an administrative choice made after launch. It is a permanent monthly cost attached to a design decision. It should be established before a quote rather than discovered during the build.
We are not quoting plan prices, since they change, differ by region and differ between billing periods. Squarespace publishes current pricing on its own site and that is the version worth working from.
What Custom Squarespace Design Actually Means
The phrase appears constantly in proposals and it covers considerably less than most buyers assume.
What it is. Custom styling and custom code applied within the platform. Somebody writes CSS to achieve a visual treatment the controls do not expose, perhaps adds a script for something the platform does not do.
What it is not. A bespoke system built from scratch. You remain on Squarespace throughout. The pages are still sections. The platform still hosts it, still updates it, still renders it and still sets the boundaries described in block five.
That distinction sounds pedantic until you consider what a buyer pictures when they hear the word custom. Many picture something built specifically for them, in the way a bespoke system would be, then price it against that expectation.
The disappointment that follows is entirely avoidable, since nothing was actually misrepresented. The supplier delivered custom styling within the platform, which is what the phrase means in this industry. The buyer expected a different category of thing.
One question resolves it before anybody signs. Ask which parts of the proposal are styling within the platform's own controls, which parts are custom CSS and which parts are code. A supplier who answers cleanly is describing real work. A supplier who treats the distinction as a technicality is relying on you not asking.
When Customising Is Justified
Two situations, stated directly, because vagueness here costs buyers money for no return.
A genuine brand requirement the controls cannot meet. Not a preference. A specific visual requirement that matters commercially to the business and cannot be approximated with what the platform provides. These exist, mostly among businesses whose identity is itself the product.
A functional need with no other route. Something the site has to do that the platform does not offer, established by checking rather than assumed. Somebody has actually confirmed there is no setting and no supported alternative.
Outside those two, most sites do not need it. The controls cover more than buyers expect, as block four sets out. Every piece of custom code is a small permanent liability, as block ten explains.
The justification that reveals there is no requirement. Wanting the site not to look like Squarespace.
That is a preference rather than a requirement. It is almost always answered better by other means. Sites are recognisable as Squarespace when they use the demonstration layouts unchanged, with stock imagery and default type. What removes that resemblance is your own photography, your own words and considered structure. Code is an expensive way to solve a problem that restraint and a photographer solve permanently.
The Middle Path
A well chosen starting point, careful styling within the platform's own controls, plus a small amount of custom code only where something genuinely requires it.
Why it works. You keep everything the platform does on your behalf, which is most of what you are paying the subscription for. You get the specific things your business needs. And the maintenance burden stays small enough that nobody has to think about it, which is the difference block ten describes.
What it looks like in practice. Type and colour set properly rather than left at defaults. Sections arranged deliberately rather than in the order the demonstration used. Content shaped for your business. Perhaps two or three small pieces of custom styling where the controls stop short of something that matters.
Why it is rarely the option offered. Two reasons, neither of them sinister. Custom design is easier to sell and more interesting to make than using the settings well. And proposing this arrangement requires a supplier to say openly that most of what you want is already available, which reduces their own scope.
If you take one thing into a conversation with a designer, make it this. Ask what the platform already does before discussing what needs building. The answer separates suppliers faster than any portfolio.
How To Choose A Starting Template
Given block two, this is a smaller decision than it feels. Three things are worth checking anyway, since starting closer to where you want to end up saves restyling.
Which one is nearest to your intended result. Not which is best. Which needs least changing.
How it behaves with the amount of content you actually have. A design built for short punchy text looks quite different carrying three paragraphs of explanation, which service businesses generally need.
Whether it is built around photography you possess. Many are constructed around large imagery, which is wonderful with good photographs and unforgiving without them.
The warning that catches nearly everybody. Every template is presented with photography commissioned for it and copy written by a designer to fit the layout precisely. Your material will not behave that way.
Seeing past it takes two minutes. Find the longest heading you will realistically use and picture it in the space allowed. Imagine your least impressive photograph in the largest image slot. Then count how many sections the demonstration uses against how much you actually have to say.
Then choose the closest and move on. Deliberating for a fortnight costs more than the difference between two starting points. Block two explains why the decision is recoverable anyway.
What Customisation Costs Later
Custom code has to be maintained, for a reason outside anybody's control. The platform changes. Code written against how Squarespace behaved two years ago can stop working when something underneath it moves.
What that means in practice. Three consequences. The first costs most.
Somebody has to notice. Custom code rarely fails loudly. It stops doing its job while the page continues to look broadly correct, so the discovery is usually a visitor who does not report it, else nobody at all for several months.
Somebody has to fix it. That is whoever wrote it, if they are still available, else somebody else learning code they did not write in order to repair something they cannot see the purpose of.
Squarespace will not help. Custom code sits outside the platform's support, which is reasonable and worth knowing before you depend on it.
None of that makes custom code a bad idea. It makes it a liability with a running cost, which is a different thing. Worth accepting for something the business genuinely needs. Poor value for a visual preference, which is why block seven draws the line where it does.
Ask two questions before agreeing to any of it. Who maintains this? And what happens to it when the platform changes?
We use the settings
before we write code.
Most requirements we are sent are already covered by the platform's own controls. We will tell you which of yours are before proposing anything. Where custom code is genuinely needed, we document it and tell you what maintaining it involves.
What a Squarespace project covers:
Ongoing management afterwards sits inside our fixed monthly fee. Project work is quoted per site.
Fourteen guides.
One platform.
This page covers templates and customisation. The rest of the series covers the role, cost, timescales, what good design looks like, designing for enquiries, the platform comparisons and what to ask before hiring.
