Custom CSS Disappear After Switching Squarespace Templates - Why?

Why Custom CSS Stops Working After a Template Switch

Different HTML Class Names

Each Squarespace 7.0 template generates different HTML. The Brine template might use .header-nav-list for navigation while Bedford uses .Main-nav. If your CSS targets .header-nav-list, it works on Brine but does nothing on Bedford because that class does not exist. The CSS rule is still in your editor - it just has no matching elements on the page.

Different HTML Structure

Beyond class names, the nesting structure of HTML elements differs between templates. A CSS rule that targets .content-wrapper .sqs-block h2 may not work if the new template nests those elements differently - even if the individual class names still exist, the parent-child relationship may have changed.

Different Default Styles

Your CSS may have been overriding specific default styles from the old template. The new template has different defaults, which means your CSS overrides may: no longer be necessary (the new template already has the style you wanted), target the wrong properties (the element exists but the property name or default value changed), or conflict with the new template's styling in unexpected ways.

How to Fix Your Custom CSS After Switching

Step 1: Do Not Delete Your Old CSS

Keep your old CSS in the editor - it documents what you previously styled and provides the values (colors, sizes, spacing) you want to recreate. Comment it out with /* */ so it does not interfere while you work on new rules.

Step 2: Inspect Elements in the New Template

Open your site in the browser, right-click on the element you want to style, and select Inspect. The browser's developer tools show the element's current HTML class names and structure. These are the selectors you need for the new template. For CSS debugging, our guide to Squarespace custom CSS covers using DevTools to find selectors.

Step 3: Rewrite CSS with New Selectors

For each old CSS rule, find the equivalent selector in the new template and rewrite the rule. Keep the property values (colors, sizes, spacing) from your old CSS - just update the selectors. This is faster than writing CSS from scratch because you already know what values you want.

Step 4: Test Each Rule

Add rules one at a time and verify each one works before adding the next. The Custom CSS editor shows changes in real time, so you can see immediately whether a new selector targets the correct element.

Step 5: Clean Up

Once all rules are rewritten, remove the commented-out old CSS. Add comments to the new rules explaining what each one does - this makes future template switches easier. For CSS organization, our guide to adding custom CSS to Squarespace covers documentation and maintainability practices.

Preventing CSS Loss in the Future

Always Back Up CSS Before Switching

Copy your entire Custom CSS to a text file before switching templates. Label it with the template name and date. This backup preserves your property values and serves as a reference for rewriting rules on the new template. For backup procedures, our guide to backing up your Squarespace site covers preserving all custom code.

Use Descriptive Comments

Comment every CSS rule with what it does (not what it targets): /* Make heading blue - brand primary color */ instead of /* Style for .header-nav-list */. The functional description helps you recreate the intent on any template, while selector-based comments are useless after a switch.

Use Generic Selectors Where Possible

When feasible, use standard HTML selectors (h1, h2, p, a) instead of template-specific class names. Standard selectors work across templates. Template-specific classes (.header-nav-list, .Main-nav) break on switch. Of course, generic selectors affect all elements of that type, so use them only when you want a site-wide change.

Consider Migrating to 7.1

On Squarespace 7.1, all sites share the same HTML structure. CSS you write on 7.1 survives redesigns because there is no template switching - you customize the same base. If repeated CSS rewrites after template switches are frustrating, migrating to 7.1 eliminates the problem permanently. For version differences, our guide to checking your Squarespace version covers migration considerations.

Common CSS Rules That Break After Switching

Navigation styling: Navigation class names differ the most between templates. Expect to rewrite all navigation CSS.

Header styling: Header structure varies significantly. Logo, menu, and header background CSS all need new selectors.

Button styling: Button class names are somewhat consistent (.sqs-block-button-element works on many templates) but hover states and sizing may differ.

Footer styling: Footer structure is entirely template-dependent. All footer CSS needs rewriting.

Gallery and blog styling: Gallery and blog HTML structures vary between templates. Image hover effects, blog grid layouts, and gallery spacing CSS break after switching. For CSS reference, our Squarespace CSS cheat sheet covers common selectors. For template switching details, our guide to changing templates on Squarespace covers the complete process. For design strategies, our Squarespace design tips guide covers visual customization principles.

Your CSS Is Not Gone - It Just Needs New Selectors

Custom CSS disappearing after a template switch is the most predictable issue in Squarespace 7.0. The code stays. The class names change. The fix is inspecting elements on the new template and rewriting selectors while keeping your property values.

Back up before you switch. Comment your CSS by function. Use generic selectors where possible. And if repeated rewrites frustrate you, consider 7.1 where this problem does not exist.