CSS Architecture for Client Sites (Not Just Snippets)
You know that feeling when you open a client's Squarespace site to make a small edit and you find a sprawling mess of CSS comments that read like a developer's diary from 2019? Random padding fixes. Mysterious color overrides. Rules that seem to do nothing but you're too afraid to delete them in case something breaks.
That's what happens when CSS becomes a graveyard of copy-pasted snippets from blog posts and Stack Overflow answers.
If you're building client sites on Squarespace 7.1, you need a system. Not because you're obsessed with clean code, but because your future self, and the next designer who inherits the site, will thank you. And more importantly, your clients won't call you in a panic because someone accidentally removed a line that was doing something crucial.
The Snippet Problem
I get it. You find a blog post titled "5 CSS Tricks for Squarespace Designers" and one of the snippets solves your exact problem. You copy it into the Custom CSS panel. It works. Life is good.
Then you find another snippet. And another. Six months in, you have 300 lines of CSS with no context. The comments say things like "FIX FOR HEADER" and "DONT TOUCH THIS". You've got duplicate selectors. You've got rules fighting each other over specificity. And when you need to change something, you're playing CSS Jenga, hoping you don't break the client's mobile menu.
Here's the thing: a handful of snippets might work for a simple portfolio site. But for real client work, where you might be maintaining this site for years or handing it off to another designer, you need structure.
Three Places to Put CSS in Squarespace 7.1
Before we talk architecture, let's be clear about your options. Squarespace gives you three main ways to add custom CSS:
Custom CSS panel. This is your primary workspace. Navigate to Design -> Custom CSS. Everything here gets compiled and loaded as part of the site's main stylesheet. It's the cleanest, most performance-friendly option for most changes.
Code Injection in the header. Design -> Website Tools -> Code Injection, then the Header Code tab. This runs in the <head> before your site fully renders. Use this for scripts and critical styles, but it's not ideal for CSS that can wait until the page loads. Keep it minimal.
Code Injection in the footer. Same location, but the Footer Code tab. This runs just before the closing </body> tag. Good for analytics and non-critical scripts. Avoid putting CSS here unless you have a specific reason.
Then there's per-page Code Injection, which we'll cover in the third article. For now, assume most of your CSS lives in the Custom CSS panel.
Building a Structure
Here's a system that works at scale. It's not fancy. It's boring. That's the point.
Split your Custom CSS into logical sections. At the top of the file, add a table of contents:
/* ============================================================
SQUAREHEAD CLIENT: ACME DESIGNS
Author: Dave Hawkins
Last updated: 2025-03-15
============================================================
TABLE OF CONTENTS
1. Global reset and variables
2. Typography
3. Header and navigation
4. Hero section
5. Features section
6. Footer
7. Mobile adjustments
============================================================ */Then break your actual CSS into these sections with clear headers:
/* ============================================================
1. GLOBAL RESET AND VARIABLES
============================================================ */
:root {
--color-primary: #2c3e50;
--color-accent: #e74c3c;
--font-size-base: 16px;
--spacing-unit: 8px;
}
* {
box-sizing: border-box;
}
/* ============================================================
2. TYPOGRAPHY
============================================================ */
h1, h2, h3 {
font-weight: 600;
line-height: 1.2;
margin-bottom: calc(var(--spacing-unit) * 2);
}
h1 {
font-size: 2rem;
}
h2 {
font-size: 1.5rem;
}
p {
line-height: 1.6;
margin-bottom: 1rem;
}
/* ============================================================
3. HEADER AND NAVIGATION
============================================================ */
.sqs-page-header {
background: var(--color-primary);
padding: calc(var(--spacing-unit) * 4);
}
.header-nav {
display: flex;
gap: 2rem;
}
.header-nav a {
color: white;
text-decoration: none;
transition: color 0.3s ease;
}
.header-nav a:hover {
color: var(--color-accent);
}See what's happening here? Everything is grouped. Everything is commented. Someone reading this file in six months can instantly find what they're looking for.
Naming and Specificity
Use class names that describe what something is or does, not how it looks. Don't name things .red-button or .large-text. What happens when your client asks to change that red button to blue? Now your class name is a lie.
Instead, use meaningful names: .cta-button, .hero-text, .testimonial-card. These tell you what the element's purpose is.
Keep specificity low. This is crucial. In Squarespace, template styles are already fairly specific. If you start writing rules like this:
.page-wrapper section div.sqs-block.sqs-block-image img {
max-width: 100%;
}You're adding unnecessary specificity debt. You'll paint yourself into a corner when you need to override that rule later.
Use single class selectors where possible. If you need to combine them, use a descendant combinator and keep it short:
.testimonial .author-name {
font-weight: 600;
}
.testimonial .author-title {
font-size: 0.875rem;
color: #666;
}This is easier to override later and easier to debug.
Working with Squarespace Block Selectors
Squarespace generates a lot of its own classes. You need to know the common ones so you can target them without fighting the cascade.
Some key ones you'll use constantly:
.sqs-block - wraps every Squarespace block
.sqs-block-image - an image block
.sqs-block-text - a text block
.sqs-layout - a layout column
.page-section - a section divider
.header-nav - main navigation
.sqs-form - form container
Don't fight these. Use them. They're stable selectors that Squarespace maintains. Here's an example of targeting them properly:
/* Center all images in a specific section */
.page-section.about .sqs-block-image img {
display: block;
margin: 0 auto;
}
/* Add spacing to text blocks */
.page-section.services .sqs-block-text {
margin-bottom: 2rem;
}
/* Style form inputs */
.sqs-form input[type="text"],
.sqs-form input[type="email"] {
border: 1px solid #ddd;
padding: 0.75rem;
font-size: 1rem;
}Notice the pattern. We're targeting Squarespace's block classes, but we're combining them with page-specific sections to keep things scoped and maintainable.
Custom CSS vs Code Injection: The Decision
Here's the rule: Put it in Custom CSS unless you have a specific reason not to.
Custom CSS is compiled, minified, and delivered as part of your site's main stylesheet. It's performant. It's clean. It's the default choice.
Use Code Injection in the header when you need to:
Load a critical script before anything renders (Typekit fonts, for example)
Set a critical style that prevents flash of unstyled content
Add analytics or tracking code (though footer is usually better)
Don't put CSS in Code Injection unless you absolutely have to. It creates extra HTTP requests and is harder to maintain.
Leaving Notes for the Next Designer
Comment your code. Not excessively, but meaningfully. If something is a workaround for a Squarespace quirk, explain it:
/*
Hero image padding fix
Squarespace adds padding to .page-section on desktop.
We compensate with negative margin on the image block
to make it bleed to the edges. Remove this if Squarespace
updates their template styles.
Last tested: March 2025
*/
.page-section.hero {
margin: 0 -15%;
padding: 0;
}
/*
Mobile menu toggle
The .header-menu-open class is added by Squarespace
when the mobile menu is triggered. We use this to hide
the main nav and show a vertical stack instead.
*/
.header-menu-open .header-nav {
flex-direction: column;
gap: 0.5rem;
}These comments aren't novels. They're breadcrumbs for the next person. They explain why something exists, not what the CSS does (the code already does that).
Maintenance Habits
Every few months, review the Custom CSS. Look for duplicates. Look for rules that don't apply anymore. Look for specificity debt that's crept in. Delete what you don't need.
Version your comments. When you make a significant change, update the "Last updated" date at the top. Better yet, add a comment when you modify a rule:
/*
Updated March 15, 2025: Changed from 1rem to 1.5rem padding
to match new client branding guidelines
*/
.cta-button {
padding: 1.5rem;
background: var(--color-accent);
}This takes 30 seconds and saves hours of detective work later.
The Real Benefit
You might be thinking this feels like overkill. For a simple site, maybe it is. But when you're managing five client sites and someone asks "can you change that blue to teal", you open the Custom CSS panel, search for "blue", find the exact rule, change it, and move on.
No scrolling through 300 lines of mystery CSS. No accidental deletions. No panic calls.
That's worth a little structure upfront.
Related Reading
If you found this useful, these might be worth your time too:
Tools That Help
Squarehead Chrome Extension can help with the workflows discussed in this article.
Want to go deeper? The Squarehead Advanced Course covers these topics and more across 11 structured modules.
