[94] When Squarespace Adds a Feature, Should You Remove Your Custom Code?

The term Disney is a trademark of Disney Enterprises, Inc. This content is not affiliated with Disney Enterprises, Inc.

Squarespace added the feature. Now what happens to your code?

You built something with custom code. Maybe it was two years ago, maybe it was last spring. It worked, the client loved it, and you moved on.

Then Squarespace shipped the feature natively.

Hiding a header and footer on a landing page is a toggle now. Two columns of products on mobile is a setting in the store section. Custom fonts have an upload button. Backgrounds and borders on a text block are in the editor. Hover and scroll effects live in the design panel.

So the question lands on every site you have ever touched: do you go back and rip the code out, or leave it alone?

I have a rule. It comes down to one question, and it is not the one most designers ask first.

The first question is scope, not age

Most people ask "is this code old?" That is the wrong question. Old code that works is fine. The right question is how many places does this code touch?

Three answers, three different decisions.

One page, one section, one block. Leave it. A single landing page where you hid the header and footer with code is doing its job. Use the native toggle on the next landing page you build. Do not go back and re-do the old ones for the sake of tidiness.

Sitewide, or anything that changes layout. Remove the code and rebuild it with the Squarespace feature. This is the category where leaving old code in place causes real problems, and I will explain why below.

Every instance of one block type. Keep the code. This is the one people get wrong most often, and it is the strongest argument for custom code still existing at all.

Remove these: layout and sitewide

Two columns of products on mobile. This was one of the most copied snippets in the Squarespace world for years, because there was no other way to do it. There is now. In mobile view, click Edit, then Edit section, then use the plus or minus icon to change the number of columns. Squarespace covers it in Styling store pages.

Remove the old CSS and use the setting. Product grid code sits deep in the layout, and layout code is the category where custom CSS and native settings fight each other hardest.

Sitewide custom fonts. If you loaded a font file with code and that font is used across the whole site, move it to the uploader. You will find it in Site Styles under Fonts: click a font type, open the dropdown, and click the upload icon. Squarespace documents the full process in Uploading custom fonts.

The reason is load time. When you install a font with code, that file loads on every page of the site whether the page uses it or not. We are talking milliseconds, and I am not going to promise you a speed transformation. But every millisecond counts, and this one costs you nothing to claim.

If the font only appears on one or two pages, the code is fine where it is. Scope again.

One important order of operations: when you remove layout code, remove the code first, then make the change in the editor. If you edit in the editor while the old code is still live, the code distorts what you see and you end up designing against a moving target.

Keep these: anything you would otherwise click a gazillon times

Here is the part that gets missed: Squarespace's newer design tools are applied block by block. That is the whole point of them, and it is a good thing. It is also the reason custom code is not going anywhere.

Take a hover effect for example. Let’s say that you want every secondary button on the site to grow slightly, lift on the Y axis, and change color. In custom code that is one snippet and it covers every secondary button that will ever exist on that site, including the ones you add next year.

In the editor, that is every single button, one at a time, forever. Including the ones you add next year.

So the rule inside content blocks is: one or two instances, use the editor. Every instance of that type, use code.

Color on hover is worth calling out separately. Squarespace's Finish Layer tools cover animations, transforms, opacity, rotate, scale, and skew, and you can read what shipped in Finish Layer tools for website design. Check whether a hover color change is available for your button style before you decide. If you are writing it in CSS, I walk through the selectors and the !important problem in my button customization guide.

Same logic for backgrounds and borders on a text block. Native for a one-off. Code if you want it on every text block on the site.

What I still customize with code, every single time

The mobile menu. The editor gives you alignment and link spacing. That is close to all of it. Everything I want beyond that is code: extra space between the links, a divider line between them, flipping the order so the social icons sit above the button instead of below it. A click-to-call button that appears on mobile and stays hidden on desktop. None of that is in a menu.

The small branded details. I call this Disneyfying a site, and I owe the name to a trip to Disneyland I did not enjoy. Expensive food, long lines, sunburn. What I did notice is that Mickey was everywhere. In the trash can trim. In the bricks. Under the tables. Details nobody consciously registers and everybody feels.

My favorite example on a real client project: they had an unusual logo shape, so I made a few PNGs in matching shapes and used them as the backgrounds for the carousel and banner arrows. Not circles with a brand color in them. Actual shapes that belonged to that brand.

No design menu builds that. Code does. And that is exactly the kind of work clients notice and pay for.

One note on hiding your footer

If you hide a footer, whether with the native toggle or with code, check that your privacy policy, terms, and copyright are still reachable. Add them as a section on the page if they need to be visible everywhere.

This is not legal advice. This is one Squarespacer talking to another. But it is the thing I check every time, and I would rather say it twice than skip it.

I cover both methods in how to hide the header and footer on a single page, including collection pages where the toggle does not appear.

The rule, in one paragraph

Sitewide changes and layout changes move to the native feature. Remove the code first, then rebuild in the editor. One-off customizations stay exactly where they are. Anything that applies to every instance of one block type stays in code, because the editor makes you do it by hand each time. And the mobile menu, the mobile-only elements, and the branded details that make a site feel like it was made for one specific business stay in code, because there is no menu for them.

Squarespace absorbing the basics is not a loss for designers. It clears the desk so the code you write is the code that only you would have thought to write.

‍ Want the code for any of this without hunting for selectors? Custom Codey is an AI trained on Squarespace. Describe what you want, get working code and where to paste it.

Resources mentioned in this episode

Squarespace support articles:

Styling store pages

Uploading custom fonts

Changing fonts

Finish Layer tools for website design

How to use Finish Layer to design more and code less

From Inside the Square

How to hide the header and footer on a single page

How to upload custom fonts in Squarespace: 2025 update

Custom fonts in Squarespace: the font menu trick and the CSS method

How to choose fonts for your Squarespace site

CSS hover effects for Squarespace

A beginner's guide to Squarespace hover effects

How to customize buttons in Squarespace with CSS

A beginner's guide to Squarespace button blocks

Next
Next

[93] Vibe Coding 101