Squarespace 7.0 and Brine | Squarespace development kit

1. Why Squarespace 7.0 still matters

Squarespace 7.0 still underpins a large number of active, revenue-critical sites. These sites are often years old, but they remain central to lead capture, repeat bookings, and product sales. Their challenge is not age in itself, but the gap between an environment that keeps evolving and a foundation that stays largely static. The organisation needs stability for day-to-day operations, yet users now expect faster performance, better accessibility, and cleaner mobile experiences.

In this context, the phrase ‘safe change’ becomes ambiguous. Different stakeholders mean different things when they describe a change as safe. For some, it means no visible difference. For others, it means no impact on search rankings, form handling, or checkout. Without written constraints, the team works from assumptions. Work becomes slower and more stressful, not because the platform is incapable, but because nobody can clearly state what is allowed and what is off-limits.

Legacy risk in 7.0 usually lives in hidden dependencies rather than in content. Brine-family templates are a typical example. Sites can appear straightforward but rely on template quirks around spacing, header behaviour, or index pages. Minor edits can expose those quirks. A block added to one section, or a small adjustment to global styles, may produce unexpected shifts in another area of the site. The fact that a change behaved well on a single page is not evidence that it will behave well across the entire structure.

Styling choices often encode technical debt. Older builds depend on CSS written against very specific markup patterns. When Squarespace adjusts the DOM, or when a site owner introduces a new block type or duplicates a section, selectors can start matching different elements from those originally intended. The visual issues that follow are not always dramatic. They might be subtle misalignments, uneven card heights, odd wrapping of headings, or dark-mode contrast problems that only appear on mobile devices. These small issues still demand time to diagnose.

External scripts add another layer. Over years, many sites accumulate analytics tags, pop-up widgets, tracking pixels, booking tools, and marketing snippets. Each addition made sense at the time, but the combined stack forms a dependency chain that is hard to reason about. A simple performance improvement, such as deferring scripts or changing load order, can cause a third-party embed to fail quietly. A cookie banner adjustment can stop a tracking script from firing, altering reporting and making performance appear worse even when user behaviour is unchanged.

From a business standpoint, migration pressure frequently collides with the requirement to keep revenue steady. Teams can see the advantages of newer editing models and layout controls, yet they also know that long-standing landing pages rank well, and that product pages are already converting. Small changes to headings, internal links, or user flow can affect those outcomes. The risk is not imaginary. If experimentation is poorly controlled, the site becomes harder to trust as an operational asset.

Avoidance then becomes its own cost. Each difficult change encourages people to postpone the next improvement. Over time, the site requires more special handling and more individual attention for each edit. Marketing experiments slow down because every adjustment feels like a potential source of regression. Eventually, the website ceases to be a flexible tool and becomes a fragile surface that nobody wants to touch.

Despite this, 7.0 and Brine still matter because they can remain entirely viable if treated as systems rather than collections of pages. When constraints are documented, dependencies are inventoried, and changes are tested rather than guessed, legacy sites can continue to deliver results while the organisation decides whether and when a structural shift is genuinely required. The key is to treat the existing site as a living system with clear rules, not as a museum piece that must never be disturbed.

2. What really changes when moving to Squarespace 7.1

Moving from Squarespace 7.0 to 7.1 is not a simple upgrade in the sense of applying a patch. It involves adopting a different editing philosophy and a different structural model. In 7.0, template families such as Brine behave almost like independent design systems, each with its own features and quirks. In 7.1, the experience becomes more unified. The feature set is broadly consistent and styling is consolidated, which helps long-term maintainability but removes some of the template-specific shortcuts that experienced builders previously used.

The day-to-day difference is most visible in layout construction. The newer environment emphasises section-based patterns and a grid-driven editing model. Content is composed from sections and blocks with more standardised behaviour across templates. This helps when onboarding new contributors or working across multiple sites, because the same controls apply everywhere. The trade-off is that some patterns once achieved through template quirks now need to be rebuilt deliberately, with more attention paid to how sections stack and reflow.

Migration work is therefore less about copying pixels and more about preserving outcomes. Older sites often rely on very specific balances between text, imagery, and calls-to-action that emerged through incremental iteration. When those pages are rebuilt, the aim is to recreate the intent rather than to chase exact visual duplication. A services page needs narrative clarity and obvious next steps. A product page needs transparent pricing, options, and trust signals. A blog post needs readability and sensible internal links. A policy page needs predictable structure and stable URLs.

Content parity is rarely one-to-one. Certain blocks do not have direct equivalents, or behave differently under the newer layout model. Micro-decisions embedded in a mature site become visible during migration. Headings, captions, small visual separators, and emphasis blocks may all need to be reconstructed. Rebuilding every detail for every page is usually unnecessary; the task is to identify which elements are critical to the function of a page, and which can be simplified in favour of maintainability without harming outcomes.

Structural shifts appear early in the process. Navigation may render differently, headers and footers may occupy space in new ways, and spacing between sections may change. These adjustments do not only affect appearance. They also influence scanning patterns, the visibility of key messages, and the position of important actions, particularly on mobile. A comfortable desktop preview can mask issues where essential content slips below the first screen on phones, or where interactions become crowded.

SEO adds another dimension. Search performance is sensitive to URL stability, internal linking, and consistent metadata. A migration plan needs a clear URL inventory, a redirect map where changes are unavoidable, and a strategy for preserving the intent of high-value pages. When URLs change without redirects, or when headings and structured content are altered without a clear rationale, search engines effectively receive mixed signals. Organic traffic can then decline in ways that are hard to diagnose after the event.

Testing also has to shift from a page-centric view to a journey-centric view. Checking whether each page loads and whether its links work is necessary but not sufficient. The more meaningful question is whether key journeys still function: a visitor lands on a search result, scans a page, follows an internal path, submits a form, or completes a purchase. Testing those flows reveals issues with forms, analytics, automations, and third-party integrations that are not obvious when pages are inspected in isolation.

For these reasons, planning a migration is as much an operational design exercise as a visual redesign. It involves auditing the existing site, categorising content by purpose, mapping URLs, documenting critical scripts and integrations, and setting explicit acceptance criteria for what counts as a successful move. When handled this way, 7.1 is not simply a new editor interface. It becomes a platform for more consistent structure and future-proof workflows, while deliberately protecting the search equity and user behaviours that already work.

3. Maintenance, change strategy, and legacy risk

Whether a site remains on 7.0 or moves to 7.1, maintenance is fundamentally a question of how change is managed. Most decisions reduce to three paths: refactor the existing structure, rebuild from a cleaner foundation, or hold the current state and accept its constraints. None is universally right. The appropriate path depends on how often the site changes, how fragile those changes feel, and which outcomes matter most to the organisation.

Refactoring aims to improve internal structure without altering what users see. In a Squarespace context, that might involve reorganising custom CSS, removing outdated scripts, tightening selectors, simplifying navigation patterns, or consolidating repeated layout fragments into better-defined templates. Refactors are effective when the underlying architecture is sound and the main problems are incremental, such as gradually increasing complexity or repeated minor regressions after small edits.

Rebuilding is justified when the current structure resists change to such an extent that incremental fixes are more expensive than replacement. Typical signals include severe editing pain, inconsistent layouts that cannot be standardised, persistent performance problems, or content models that do not match how the organisation works. In those cases, a rebuild offers the chance to reset assumptions, modernise layout logic, and create patterns that make future changes cheaper rather than more difficult.

Holding the current setup is acceptable when the site is stable, outcomes are being met, and the organisation cannot realistically support a significant change programme. The risk is not in choosing to hold; the risk lies in holding without a maintenance discipline. Without clear rules for what may be altered, and without basic monitoring, even a quiet site accumulates changes over time. Scripts are added, styles are tweaked, and content is shuffled. Eventually, the picture of how everything fits together becomes unclear.

Across all paths, fragile customisation is a recurring concern. Custom CSS and JavaScript can unlock useful patterns, but they are safer when treated as small products with a clear scope, documented purpose, and explicit boundaries. Problems emerge when customisations rely on fragile selectors, timing quirks, or assumptions about template behaviour that are not written down. When someone new edits a page, or when the platform makes an underlying change, these assumptions can break. The site then appears unpredictable, which erodes trust in future changes.

Documentation reduces this unpredictability. A simple record of where custom code lives, what each script does, which pages it targets, and which external services it touches can transform maintenance from detective work into routine work. It also supports delegation. When external help is required, constraints and dependencies can be communicated clearly instead of reconstructed under pressure. This is particularly important for sites that integrate with other systems, such as automation tools, databases, or analytics platforms.

Safe change is best defined by process rather than by size. A small change can still be unsafe if it bypasses testing and monitoring. A practical safety standard includes a defined outcome, a basic risk assessment, testing on relevant devices, a clear rollback path, and observation after release. This does not require heavy bureaucracy, but it does require consistency. Over time, such a process makes people less reluctant to improve the site, because they know issues can be detected and reversed without crisis.

On revenue-critical flows, especially checkout and key enquiry forms, change should be treated as a constrained resource. Frequent structural experiments on these paths carry higher risk than adjustments to supporting content pages. Where possible, improvements should reduce friction without altering familiar navigation, wording, or ordering of critical steps unless there is clear evidence that change is required. When more substantial experiments are necessary, they are best handled as controlled tests with tightly defined scope and metrics.

Ultimately, maintenance strategy is about keeping the relationship between effort and predictability favourable. A legacy Squarespace site does not become dangerous simply by being old. It becomes difficult when each adjustment is a guess, when nobody can explain how custom layers interact, and when outcomes cannot be measured reliably. A structured refactor, an intentional rebuild, or a disciplined hold can each restore predictability, provided that maintenance is treated as an ongoing practice rather than an occasional reaction to visible problems.

4. Brine templates, 7.1, and planning for the future

The Brine template family earned its place in many Squarespace 7.0 builds because it combines visual range with consistent underlying mechanics. It supports a variety of page types, handles index-style stacking well, and offers sufficient styling control to align layouts with a brand without constant recourse to code. For organisations that maintain multiple sites, the familiarity of Brine’s patterns has practical value: training, documentation, and internal processes can be standardised around a known behaviour set.

Brine’s strengths are closely linked to its support for modular composition. Index pages encourage a pattern where long-form content is organised into structured sections, each with a clear purpose. This can simplify information architecture because visitors encounter a guided story instead of diving through many short pages. When executed carefully, such pages support both comprehension and conversion, particularly for services and productised offers where visitors want context before committing.

The same features that make Brine flexible also create dependencies. Section stacking, global styles, and template-level controls mean that small adjustments can have wide effects. A change in heading scale can alter the perceived rhythm of an entire page, pushing important information below the first screen or changing how users scan a sequence of blocks. Adjustments to global colours can influence contrast and accessibility in places that are not immediately visible in a quick review.

Brine also has acknowledged limitations from a modern content perspective. It lacks some native patterns that contemporary sites often rely on, such as built-in sidebars for navigation, richer related-content components, or certain author-level structures. These gaps can be bridged through careful use of blocks, custom layout patterns, and selected plugins, but each workaround adds maintenance overhead. If these patterns are required across many posts or sections, they need to be implemented as consistent systems rather than as one-off experiments.

Heavy reliance on custom code to overcome template constraints can introduce performance and maintenance risks. Over time, layers of CSS and JavaScript accumulate, often written by different people at different points. Without regular review, this stack can slow down pages, create conflicts, and make the site sensitive to platform changes. A performance budget mindset helps here: new features should be weighed against their cost in load time, complexity, and editorial effort.

Squarespace 7.1 addresses many of these pressures through a unified feature set and a more standardised editing environment. Instead of selecting between template families with divergent capabilities, teams build within a single architecture and shape the design through styling and layout decisions. This reduces the likelihood of discovering late in a project that the chosen template cannot support a required pattern without extensive workarounds. It also aligns with where future platform improvements are concentrated.

Deciding whether to move from a Brine-based 7.0 site to 7.1 is therefore a strategic question rather than a purely technical one. The key consideration is whether the current limitations are materially affecting operations. If Brine’s layout and feature set are still supporting content, navigation, and performance needs, and if maintenance is predictable, remaining on 7.0 with disciplined governance can be a sensible choice in the near term.

If, however, the site has grown into a complex content library, if repeated workarounds are required to add routine features, or if the editing model is slowing down publishing, then a transition becomes easier to justify. In that case, a structured migration that combines content inventory, information-architecture redesign, SEO planning, and testing can turn 7.1 into a more sustainable foundation rather than simply a cosmetic update.

Looking ahead, the most resilient approach treats both Brine and 7.1 as frameworks for deliberate systems rather than as skins. On Brine, that means codifying section patterns, documenting customisations, and accepting where the template’s constraints define reasonable boundaries. On 7.1, it means using the unified toolset to build repeatable layouts, consistent navigation, and manageable integrations. In either environment, a clear view of sacrificial trade-offs, maintenance costs, and future goals allows organisations to decide whether legacy Squarespace foundations still serve their needs, or whether the time has come to invest in a new structure that will remain workable for the next cycle of growth.

Thank you for taking the time to read this lecture. Hopefully, this has provided you with insight to assist your career or business.

Read the full lecture here.