Squarespace 7.0 and Brine

12 Dec

Audio Block

Double-click here to upload or link to a .mp3. Learn more

TL;DR.

This lecture addresses the complexities involved in migrating from Squarespace 7.0 to 7.1, focusing on key considerations such as legacy system challenges, maintenance choices, and the features of the Brine template family. It aims to educate users on best practices for a successful transition.

Main Points.

Migration Challenges:
- Legacy systems require careful updates to avoid disruptions.
- Migration to 7.1 involves significant changes in structure and layout.
- Content parity must be maintained to protect SEO and user experience.
Brine Template Insights:
- The Brine template family offers extensive layout options but requires careful management of global styles.
- Users must understand the differences in editing experiences between 7.0 and 7.1.
- Small changes can have significant impacts on functionality and user engagement.
Maintenance Strategies:
- Consider when to refactor, rebuild, or maintain existing setups.
- Document legacy constraints to inform future updates and changes.
- Establish clear expectations for what constitutes a 'safe change'.
SEO Management:
- Careful planning of URLs and redirects is essential to maintain search rankings.
- Regular monitoring of site performance post-migration is crucial.
- Engage users in testing to gather feedback and improve the experience.

Conclusion.

The migration from Squarespace 7.0 to 7.1 is a multifaceted process that requires careful planning and execution. By understanding the challenges associated with legacy systems, leveraging the features of the Brine template family, and implementing effective maintenance and SEO strategies, users can ensure a successful transition that enhances their website's functionality and user experience. Continuous evaluation and adaptation will be key to thriving in the evolving digital landscape.

Key takeaways.

Migration from Squarespace 7.0 to 7.1 involves significant structural changes.
Maintaining content parity is crucial for SEO during migration.
The Brine template family offers extensive customisation but requires careful management.
Testing and rollback plans are essential for a smooth transition.
Documenting legacy constraints aids in future updates and maintenance.
Incremental updates should be thoroughly tested to avoid disruptions.
SEO risks must be managed through careful URL and redirect planning.
Engaging users in the testing process can provide valuable insights.
Establishing clear expectations for changes fosters stakeholder trust.
Regular performance monitoring post-migration is vital for ongoing success.

Play section audio

Why Squarespace 7.0 still matters.

Older websites rarely fail because they are “old”. They fail because the surrounding ecosystem moves forward while their foundations stay still. A large number of businesses still run critical revenue pages, lead capture funnels, and long-standing blog libraries on Squarespace 7.0, often because the site was built years ago and kept alive through small, careful changes. That reality creates a specific kind of operational tension: the site must remain stable for day-to-day trading, yet it also needs modern performance, accessibility, and security expectations to be met.

When a site becomes part of a business’s routine, even minor edits can feel risky. Stakeholders may want “safe improvements”, but they often mean very different things by “safe”. One person might mean “no visual change”, another might mean “no ranking loss”, and another might mean “no checkout disruption”. That mismatch is where legacy work becomes expensive: not because the work is impossible, but because the constraints are rarely written down and the risks are rarely quantified before changes begin.

Common legacy scenarios.

Legacy Squarespace work usually starts the same way: someone inherits a site, something needs to change, and nobody wants to be the person who breaks it. That is not a technical weakness so much as a governance problem. The older the site, the more likely it is that decisions were made for good reasons at the time, but those reasons were never recorded in a way that helps the next person operate confidently.

Legacy risk is rarely in the content, it is in the hidden dependencies.

A common pattern is an inherited design built on specific template families with behaviours that are not obvious until a change is introduced. A site can look “fine” on the surface while relying on small structural quirks that keep layouts aligned, navigation usable, or banners rendering correctly. The moment a new block is added or a theme tweak is applied, those quirks can flip from invisible to disruptive, especially when the original builder used workarounds that were never documented.

Within 7.0, the Brine family is a frequent example of this dynamic: different templates can share a family name yet behave differently in edge cases, particularly around spacing, header variants, and how certain elements respond across breakpoints. A change that looks safe in one template can cause unexpected knock-on effects in another, which is why “it worked on the homepage” is not meaningful proof that it will work across the full site.

Technical debt also shows up in styling choices. Older builds often depend on tightly scoped, sometimes brittle CSS selectors that were written to match the markup of that moment in time. If a new block type is introduced, a section is duplicated, or Squarespace adjusts underlying DOM patterns, those selectors can begin targeting the wrong elements. The outcome is not always dramatic; it can be subtle, like a button alignment drifting on mobile, a summary grid losing consistent heights, or a form label becoming unreadable in dark mode. Those “small” issues still cost time because they tend to appear only after deployment.

Another legacy scenario is a site that has accumulated external scripts over the years, such as analytics tags, pop-up widgets, booking tools, and custom marketing snippets. Each addition may have been justified, but the combined result is a dependency chain that is hard to reason about. A performance tweak can accidentally change load order, which breaks a third-party embed. A cookie banner update can prevent a tracking script from firing, which makes reporting look “wrong” even though the site is functioning. In practice, the maintenance problem is not a single script; it is the absence of an inventory of scripts, what they do, and what pages they affect.

From a business perspective, migration pressure tends to collide with stability requirements. Teams know the platform has evolved, and they can see benefits in modern editing and layout control, but they also know that the current site still produces leads and sales. The fear is rarely irrational. If a site includes long-standing landing pages with good rankings, a minor change to internal linking, headings, or URL structure can reduce search visibility. If the site includes high-intent product pages, a “clean-up” that changes user flow can reduce conversions even if the design looks better.

Support and maintenance costs then increase gradually. The site needs more “special handling”, changes take longer, and people start avoiding improvements because they have been burned before. Over time, that avoidance becomes expensive in a different way: the website becomes harder to evolve, which limits experimentation, slows marketing iteration, and increases reliance on manual workarounds rather than systematic improvements.

Migration considerations.

Moving from one version of a platform to another is never a simple “upgrade”, even when it looks like a version number change. The core issue is that the website is not just a collection of pages; it is a set of behaviours, assumptions, and workflows that the organisation relies on. A migration only succeeds when those behaviours are identified, prioritised, and validated, not when the new site merely looks similar.

A successful migration preserves outcomes, not pixels.

Transitioning to Squarespace 7.1 introduces a more unified editing environment, but it also changes how layouts are constructed, how sections behave, and how certain blocks render across devices. That matters because older sites often rely on template-driven layout patterns, while newer builds encourage a more consistent, section-based approach. Teams that are used to “this template does that” may need time to reframe their thinking into “this layout is composed like this”. That learning curve is not a blocker, but it must be acknowledged, especially for organisations where non-technical staff publish content regularly.

One of the biggest practical issues is content parity. Not every element maps cleanly from an older setup to a newer one. Some layouts can be reproduced visually but behave differently when edited. Some blocks may need replacements. Some old content structures might be better rebuilt rather than ported directly. The right approach depends on what the page is for. A brand story page can tolerate small presentation differences. A checkout-adjacent page, a pricing page, or a top-ranking blog post usually cannot.

Search visibility is another area where conceptual planning must become concrete. The migration plan needs a clear strategy for URL redirects so that existing inbound links, indexed pages, and bookmarked customer paths continue working. This is not limited to top-level pages. Image URLs, blog slugs, category pages, and old campaign landing pages can all contribute meaningful traffic. When redirects are handled inconsistently, the cost is not just broken links; it is a gradual decline in trust signals as users bounce and search engines re-evaluate relevance.

Testing is where many migrations win or lose. A robust rollback plan mindset does not mean expecting failure; it means treating recovery as part of responsible delivery. That mindset changes how teams work: changes are staged, validation checklists are created, and there is a documented path back to a known-good state if something unexpected appears. In practice, rollback planning reduces panic, because it removes the feeling that a launch is a one-way door.

There is also a difference between functional testing and outcome testing. Functional testing asks, “Does the page load and do the links work?” Outcome testing asks, “Do users still do the thing this page exists to enable?” That includes checking conversion paths, verifying forms and automations, confirming email notifications, validating ecommerce flows, and ensuring analytics still represent reality. For organisations that run on marketing attribution, the migration must confirm that tracking continues to work as expected, otherwise the team will interpret “missing data” as “performance dropped”, even when it did not.

Pre-migration audit checklist.

Catalogue critical pages by purpose: revenue, lead capture, authority content, support content.
List embedded tools and scripts: booking widgets, form handlers, analytics, advertising pixels, chat tools.
Identify layout patterns that must be preserved: navigation, headers, footers, product layouts, key landing pages.
Record current baselines: page speed, top queries, conversion rates, form completion rates, bounce points.
Map URL inventory: current slugs, legacy campaign pages, high-traffic blog posts, key inbound links.

Technical depth.

Migration stability improves when the work treats the website as a system of dependencies rather than a set of pages. For example, if a site relies on older structural hooks for styling, a safe approach is to define a consistent naming and targeting strategy that reduces reliance on fragile DOM patterns. This is where structured tooling can help. A plugin ecosystem such as Cx+ can reduce the need for bespoke, one-off injections by providing repeatable, documented behaviours that are designed to be maintained over time. That does not remove the need for careful planning, but it reduces the surface area of custom logic that can fail silently.

In parallel, long-running sites often benefit from reducing support load after a migration, because users may encounter new layouts or updated flows. That is where a self-serve layer can be useful. A system like CORE can act as an on-site knowledge and guidance mechanism, helping visitors find answers without relying on email back-and-forth, particularly during transition periods where “Where did that move to?” becomes a common question. The key is not adding tools for their own sake, but using them to reduce friction at the exact moments users are most likely to hesitate.

Maintenance choices.

When a site sits on older foundations, the organisation typically faces three paths: refactor what exists, rebuild the site, or keep it as-is and accept the trade-offs. None of these is universally correct. The decision becomes clearer when the organisation defines what it is optimising for, such as speed of delivery, risk reduction, long-term maintainability, or immediate feature gains.

The best choice is the one that reduces future uncertainty.

A refactor approach is often attractive because it preserves the existing site while improving specific weak points. That might involve tightening styles, reducing script bloat, simplifying navigation, improving mobile layouts, or rewriting brittle custom logic into more stable patterns. Refactoring can be effective when the site’s structure is still fundamentally sound and the organisation needs incremental improvement without a major change programme. The downside is that refactoring can uncover hidden complexity. Each improvement may reveal another dependency, which makes scope control essential.

A rebuild is usually justified when the current site’s structure is fighting the organisation’s goals. That includes situations where editing is painful, where layout consistency is hard to maintain, where performance is persistently poor, or where growth requires new content models and clearer information architecture. A rebuild offers the cleanest opportunity to create consistency, improve accessibility, and modernise structure. It also demands stronger governance, because it is easier to drift into “while we’re here, let’s also…” scope expansion unless outcomes are kept tight.

Leaving the site largely as-is can also be rational, especially if the website is stable, the business relies on it, and the team cannot support a change programme right now. The key is honesty. If the choice is to maintain, then the organisation should adopt a maintenance discipline: document constraints, create a change approval process, and keep a record of what has been added over time. Maintenance is only cheap when it is controlled; reactive maintenance becomes expensive because every change requires rediscovery of the same facts.

Reducing fragile customisation is a practical goal across all three paths. That does not mean removing everything custom. It means replacing undocumented, hard-to-test tweaks with patterns that can be understood by someone new. Documentation is a force multiplier here: a simple log of “what was changed, why it was changed, and what it affects” prevents repeated debugging months later. It also makes it easier to outsource work safely, because constraints and expectations are explicit rather than assumed.

For teams that want stability without dedicating internal headcount, structured support can reduce operational drag. Ongoing management through Pro Subs is one example of a maintenance model that treats the website as a living asset, not a one-time project. The advantage of that mindset is consistency: recurring reviews, planned updates, and controlled changes reduce the chance that the site becomes a patchwork of untracked edits. The principle matters more than the provider: maintenance works best when it is systematic and measurable.

Decision signals worth tracking.

How often “small changes” cause regressions elsewhere.
How long it takes to publish or update key pages.
How many scripts and integrations exist, and whether they are documented.
Whether performance issues are isolated or structural.
Whether the site’s structure supports future content plans and product growth.

Ultimately, the question is not whether an older Squarespace site can be maintained. It can. The real question is whether the organisation can maintain it predictably, with controlled risk and clear outcomes. When teams treat legacy work as a strategic discipline rather than a fragile mystery, they gain the confidence to improve performance, protect rankings, and modernise user experience without gambling the business on a single change.

From here, the practical next step is to translate these concepts into an actionable plan: identify critical journeys, define what “safe change” means for the organisation, and choose a path that matches resources and risk tolerance while keeping the website adaptable for what comes next.

::contentReference[oaicite:0]{index=0}

Play section audio

Migration considerations.

How 7.1 changes site structure.

Moving a site between major platform versions is rarely a simple “upgrade”. When teams migrate from Squarespace 7.0 to Squarespace 7.1, they are stepping into a different philosophy of layout, styling, and template behaviour. The platform becomes more standardised, which can make long-term maintenance cleaner, but it also means older design decisions may stop behaving the same way.

In practical terms, a 7.0 site often leans on template-family quirks. Those quirks are not always accidental; they can be the reason a layout “just works” for a specific brand. When a business has tuned spacing, navigation patterns, and content blocks over months or years, the migration is less about copying pages and more about rebuilding the intent behind each page.

Migration works best when the team migrates outcomes, not layouts.

Template families in 7.0 could behave like separate design systems. A well-known example is the Brine family, which encouraged deep customisation patterns and supported many layout expectations that site owners came to rely on. In 7.1, the experience is more uniform across templates, which reduces fragmentation, but it can also remove certain “special” behaviours that used to be available through template choice alone.

That uniformity is not inherently negative. It can reduce the time spent troubleshooting template-specific issues, and it helps teams standardise internal processes, especially when managing multiple sites. The trade-off is that the migration can surface hidden dependencies: spacing assumptions, navigation structures, and section arrangements that existed because the 7.0 template quietly supported them.

One helpful way to plan is to treat the migration like a controlled redesign. The team can document what the current site is trying to achieve on each page: the primary goal, the key path (what a visitor does next), and the minimum acceptable experience on mobile. Once those outcomes are clear, rebuilding in 7.1 becomes a structured exercise rather than a stressful “why does nothing line up” scramble.

Common structural shifts.

Expect layout behaviour to change before content changes.

Structural changes tend to show up early, sometimes within minutes of previewing the migrated site. Navigation may feel slightly different, spacing may compress or expand, and section-level design decisions can become more prominent. These shifts often impact perception first, even when the underlying content is still correct.

Header and footer layouts can render differently, particularly if the old site relied on template-family defaults.
Page sections can stack and align in ways that feel “cleaner”, but the new defaults may not match the brand’s established rhythm.
Content blocks can look similar at first glance while behaving differently in responsiveness and spacing.
Design changes can alter scanning patterns, which affects how quickly users find key information.

When a business has conversion goals, these visual changes matter. Even small spacing shifts can change whether visitors notice a call-to-action, whether product benefits feel readable, or whether a service page feels trustworthy. Migration planning should include a deliberate pass on “information hierarchy” rather than just a pass on “broken elements”.

Content parity rarely maps 1:1.

Once the broad structure is understood, the next challenge is content parity. Not everything from a 7.0 site has a direct equivalent in 7.1, and that mismatch often appears in the details: block settings, style controls, or features that were previously supported through a template’s unique behaviours. The risk is not only visual; it can affect usability, accessibility, and performance.

Teams often underestimate how many “micro-decisions” exist inside a mature site. A single page might contain dozens of small layout and formatting choices that collectively create clarity. During migration, some of those choices become unavailable or need to be achieved differently. The time cost comes from identifying what matters and rebuilding it intentionally, rather than chasing pixel perfection everywhere.

The goal is functional equivalence, not visual cloning.

A practical approach is to audit pages by category. A service page, a product page, a blog post, and a policy page each have different requirements. Service pages need strong narrative flow and obvious next steps. Product pages need clarity on price, options, delivery, and trust signals. Blog posts need readability and internal linking. Policy pages need predictable structure and stable URLs. Categorising pages prevents the team from treating every page like a one-off.

When differences appear, they should be logged as “gaps” rather than “bugs”. A gap can be solved by adjusting design, changing content structure, replacing a feature, or rebuilding the experience with code. That last option is not always required, but it can be relevant when a business has a repeatable need across many pages, especially on content-heavy sites.

Mapping blocks and behaviours.

Document what a block does, then rebuild the behaviour.

A block in 7.0 might have been used in a very specific way, such as creating an accordion-like experience by combining formatting, spacing, and user expectation. In 7.1, the team may need to recreate that behaviour more explicitly. This is where technical decisions become valuable: deciding which patterns are worth rebuilding and which should be simplified for maintainability.

Edge cases tend to appear around content that mixes formats. For example, a long services page might combine text, images, quotes, and repeated call-to-actions. If the old layout relied on a template’s default spacing to keep everything readable, the migrated version may feel cramped or overly airy. The fix is often not “change padding everywhere”, but to restructure the page into clearer sections with consistent intent.

Identify blocks that carry business-critical meaning (pricing tables, FAQs, booking prompts, lead forms).
Identify blocks that carry trust signals (testimonials, certifications, case-study snippets, guarantees).
Identify blocks that carry navigation value (tables of contents, in-page jump links, structured headings).
Identify blocks that carry performance cost (large galleries, heavy video embeds, repeated animations).

Once that inventory is in place, the team can rebuild the experience using the 7.1 structure, choosing modern defaults when they improve clarity and only reintroducing complexity where it protects business outcomes. If the site has many repeated interaction patterns, a plugin approach can also reduce manual work across pages. For Squarespace environments, systems like Cx+ can be relevant when a team wants consistent UI behaviours across collections without rebuilding each page by hand.

There is also a content strategy angle. Migration is a forcing function that reveals thin or outdated content. When a section no longer fits neatly into the new layout, it can be a sign that the content is doing too many jobs at once. Breaking a long section into tighter sub-sections often improves readability and reduces layout friction.

SEO stability needs deliberate planning.

Migration problems become expensive when search traffic drops. The core issue is rarely “Google dislikes the new design”. The common failure mode is that URLs change, internal links break, or metadata becomes inconsistent. To protect organic performance, teams need a plan that treats SEO as a migration requirement, not a post-launch repair job.

Step one is documentation. A complete list of current URLs, page titles, and the page’s purpose is the baseline. Without that list, it becomes difficult to recognise what changed and why. This is especially important for older sites that have grown organically, where multiple pages may cover similar topics and only one is ranking well.

Preserve URLs wherever possible, redirect only when necessary.

When a URL must change, the migration should include a 301 redirect from the old URL to the new one. This preserves most of the link equity and prevents users from landing on dead pages. The “must” here is not rhetorical; broken URLs can lead to immediate traffic loss and a slow recovery curve, especially if the old URLs were linked from external sources.

Redirect planning needs to be systematic. Teams should avoid redirect chains (old A redirects to B, which redirects to C) because chains can dilute signals and create slow user experiences. The cleaner approach is to redirect old URLs directly to their final destination. If a page no longer exists, redirecting to the nearest relevant category page or a carefully designed equivalent page is usually better than redirecting everything to the homepage.

URL, redirects, and internal linking.

Search engines notice broken paths faster than teams expect.

Internal links often break silently during a rebuild, particularly when links were pasted manually over time. After migration, every broken internal link becomes a user-experience issue and an indexing issue. That makes link checking an essential part of the launch checklist, not an optional polish step.

Export or record the current URL list, including high-traffic pages and top landing pages.
Mark which URLs will remain identical and which must change due to restructuring.
Create a redirect map that pairs every changed URL with its new destination.
Update internal links to point to the new URLs directly, not through redirects.
After launch, crawl the site to detect 404s and unexpected redirect chains.

Metadata also deserves attention. Page titles and descriptions should be reviewed, not only preserved. Migration is an opportunity to remove duplication, tighten phrasing, and align metadata with the site’s real intent. The caution is to avoid changing everything at once. If the team changes URLs, page titles, headings, and content structure simultaneously, diagnosing SEO changes becomes harder because too many variables move together.

Post-launch monitoring should be routine. Using Google Search Console helps teams spot indexing issues, coverage errors, and sudden ranking shifts. Google Analytics can show whether traffic patterns changed by source, by landing page, and by device category. The objective is quick detection: if a key landing page collapses in traffic, the team should know within days, not weeks.

Testing and rollback prevent downtime.

A smooth migration requires a launch mindset that resembles software release management. A site is a product surface, and migration is a release. That means the team needs structured testing, clear acceptance criteria, and a plan to revert if the release fails. Without that discipline, teams can find themselves “debugging live” while real visitors encounter broken experiences.

Testing should cover three layers: correctness (is everything present), usability (does it feel clear and navigable), and resilience (does it hold up on different devices and browsers). The last category is where many migrations stumble. A layout that looks fine on a desktop preview can break on small screens, and a form that works in one browser can behave differently in another.

Testing should mirror real user journeys, not just page inspections.

Journey-based testing means the team performs the same actions a real visitor would perform: arriving from a search result, scanning a page, clicking internal links, submitting a form, navigating to a product, and returning to a category. This reveals friction that page-by-page checking misses. It also reveals whether the site still “feels” like the same brand, which matters when trust is part of conversion.

Launch readiness checklist.

A migration is successful when users do not notice it.

Validate navigation on desktop and mobile, including dropdowns and folder behaviour.
Check mobile responsiveness across common breakpoints, ensuring text remains readable and tap targets remain usable.
Verify forms, checkout flows, and any integrated scheduling or payment steps.
Audit images for correct scaling and file weight, especially on content-heavy pages.
Confirm key pages load quickly and do not introduce new performance bottlenecks.
Review headings for structure and accessibility, ensuring pages remain scannable.
Run a broken-link sweep and validate the redirect map.

A rollback plan should be explicit. If a launch introduces critical issues, teams should already know how they will revert and what the trigger conditions are. Triggers might include broken checkout, widespread 404 errors, major layout failures on mobile, or sudden loss of tracking data. The rollback decision should not be emotional; it should be tied to business impact.

Controlled experimentation can also reduce risk. Teams can use A/B testing selectively on high-impact pages, particularly if the migration forces a significant layout redesign. The point is not to test everything; it is to validate changes that materially affect conversion, such as pricing presentation, lead capture flows, or product page hierarchy. Even lightweight tests can reveal whether the new design supports the same outcomes as the old one.

Finally, migration is a chance to tighten operational workflows. Teams that manage content across multiple systems, such as websites, databases, and automation layers, can use migration as a moment to standardise naming, URL structures, and content templates. When the operational ecosystem includes platforms like Knack, Replit, or Make.com, a cleaner structure reduces downstream friction, particularly for search, content reuse, and automation reliability.

Handled well, a 7.1 migration becomes more than a platform change. It becomes a structured reset that improves maintainability, strengthens information hierarchy, and reduces hidden technical debt. With clear outcomes, disciplined SEO planning, and release-style testing, teams can step into the newer architecture while protecting the equity they have already built, setting up the next phase of site optimisation and growth.

Play section audio

Maintenance choices.

Squarespace maintenance looks deceptively simple because much of the platform is managed for the site owner. Hosting, certificates, core feature updates, and baseline security are handled upstream. The hard part sits elsewhere: deciding what should change, what should stay, and how to avoid breaking a site that already earns trust, traffic, and revenue.

For teams running a live site, maintenance is not a single task. It is a repeated decision cycle: evaluate the current state, choose the least risky path to improvement, and document why that choice was made. That cycle becomes even more important when the site has years of accumulated tweaks, page-specific overrides, and “one more script” additions that were never designed to be maintained long-term.

Refactor, rebuild, or hold.

Most maintenance decisions can be reduced to three options: improve what exists, replace what is failing, or keep the current setup unchanged for now. The key is separating urgency from importance, then aligning the decision with the site’s real constraints such as time, budget, internal skills, and operational risk.

Refactoring is the process of improving structure without changing outward behaviour. In a website context, that often means reorganising custom code, removing duplication, tightening selectors, simplifying templates, and improving performance without changing what visitors see or how they complete key actions.

Rebuilding is the deliberate choice to replace a page, a pattern, or an entire site structure because the current approach is too limiting to evolve safely. A rebuild is not “starting over for fun”. It is the admission that incremental fixes will cost more over time than replacing a weak foundation.

Holding the current setup, sometimes called maintaining the status quo, is also a valid option. It becomes the correct option when the site is stable, goals are being met, and the changes being requested do not justify the risk. The mistake is not holding; the mistake is holding without monitoring, because that quietly accumulates future costs.

Signals that guide the choice.

Choose the path that reduces future work.

A reliable decision process uses observable signals rather than preference. The most useful signals are those tied to outcomes, such as conversions, support load, SEO visibility, and the time it takes the team to ship changes without incidents.

User feedback shows friction that analytics cannot always explain, such as confusion, mistrust, or repeated questions.
Performance metrics reveal whether the site is slowing down due to scripts, heavy media, or layout patterns that trigger expensive rendering.
Change frequency indicates how often the team must update the site and how painful each update currently is.
Constraint severity clarifies whether the site can realistically support the next phase of growth without structural change.

The decision is often obvious when these signals are viewed together. If updates are frequent and fragile, refactoring is usually the fastest win because it reduces breakage while keeping scope controlled. If the site cannot support required features, workflows, or content structure, a rebuild becomes the safer long-term choice because it removes the constraint rather than negotiating with it forever.

Teams should also distinguish “platform change” from “site change”. Platform changes happen whether the team is ready or not. Site changes are optional, and should be planned. Mixing the two creates reactive work, which is where most maintenance stress comes from.

Template realities and migrations.

Not all foundations evolve equally.

Sites built on the Brine template family often carry a long history of design decisions that made sense at the time. Those decisions can become constraints when the business wants new layouts, modern content patterns, or consistent editing workflows across pages.

When a team is considering a move from Squarespace 7.0 to a newer structure, a rebuild conversation frequently appears. The reason is not aesthetic. The reason is structural: the editing model, page architecture, and component behaviours differ enough that “patching” can turn into a months-long exercise of chasing edge cases.

A practical example is the navigation and header system. If the site depends on a complex folder structure, custom overlays, and menu behaviours tied to specific DOM assumptions, a simple request like “add a second-level menu treatment” can trigger a cascade of conflicting changes. In those cases, rebuilding the header pattern as a clean, documented system is often safer than stacking more fixes on top.

Another example is content-heavy pages with repeated blocks, embedded media, and layered scripts. If page load issues persist despite optimisation attempts, the real issue may be architectural: too many competing scripts and patterns, not a single “slow image”. A rebuild can replace multiple fragile patterns with fewer, more reliable ones.

Technical depth block.

Refactor reduces entropy, rebuild removes constraints.

From a technical perspective, refactoring is often about reducing unpredictability. Unpredictability shows up as selectors that rely on fragile class chains, scripts that assume a specific rendering order, and styling that only works because of accidental specificity. These issues can be improved without changing page layout by tightening the rules of the system.

Rebuilding, by contrast, is a controlled reset of assumptions. It allows the team to redefine content patterns, simplify JavaScript responsibilities, and choose a consistent approach to layouts. The most important part is that a rebuild makes future changes cheaper, because the system becomes understandable again.

Reduce fragile customisations.

Custom code can be valuable, but only when it behaves like a maintainable product rather than a collection of one-off fixes. Fragility usually comes from customisations that are tightly coupled to a specific structure, rely on timing quirks, or depend on third-party scripts that can change without warning.

Fragile customisations are not “bad code” by default. They are code that lacks clear boundaries. If a script affects multiple pages without strong targeting, or if it modifies markup that the platform may render differently in another context, it becomes a future incident waiting for a minor update.

The goal is not to eliminate customisation. The goal is to make it predictable, testable, and reversible. That typically means using fewer moving parts, keeping behaviours scoped to the right pages, and using a consistent approach to configuration so the team knows what is active and why.

Practical tactics that hold up.

Make custom work behave like a system.

Prefer platform-native features before reaching for scripts, especially for layout and content presentation.
Use page-level targeting rules so scripts do not unintentionally affect unrelated pages.
Introduce a consistent configuration pattern so features can be toggled without editing multiple code blocks.
Keep dependencies minimal, and remove third-party scripts that are no longer essential.
Design with “failure modes” in mind, so the site still works if a script fails to load.

Teams often underestimate how much risk lives in seemingly small tweaks. For example, a single animation library can add kilobytes, delay rendering, and create accessibility issues if it is applied to critical UI elements. Removing that dependency can improve speed and stability more than any micro-optimisation.

Integrations also deserve scrutiny. Third-party integrations can provide essential functionality, but each one introduces an external change surface. A single external script update can break a checkout flow, a form embed, or tracking integrity. Regular audits help ensure the site is not carrying “dead weight” that creates risk without producing value.

When the site uses a maintained plugin ecosystem, the team can reduce fragility by standardising how features are deployed and documented. For instance, a codified plugin library such as Cx+ can be treated as a controlled layer, where features are enabled intentionally and the team knows which behaviours are active. The important principle is not the brand, it is the discipline: make custom behaviour discoverable and consistent.

Performance and usability trade-offs.

Custom features must earn their cost.

Every custom enhancement has a cost, even when it “works”. The cost can show up as slower loading, reduced stability, or more complex editing workflows. The decision should be framed as a trade-off: what does this feature improve, and what does it risk?

A useful practice is to define a simple performance boundary and treat it like a budget. If a new feature increases script size or blocks rendering, something else should be removed to keep the site within acceptable limits. This keeps the system from becoming heavier over time.

Usability is part of this equation. A custom feature that looks impressive but confuses visitors can reduce conversion, increase support requests, and damage trust. Maintenance is not only technical; it is behavioural. The site’s job is to be understood quickly.

Technical depth block.

Scope, isolation, and conflict prevention.

Custom code is safer when it is isolated. Isolation means that selectors are scoped, events are namespaced conceptually, and scripts avoid manipulating large parts of the page tree. It also means avoiding situations where two scripts compete for control of the same element.

Conflicts often appear when multiple enhancements target similar UI patterns. A classic example is two scripts that both transform product descriptions, each assuming it is the only one running. Preventing this requires simple guardrails such as explicit feature flags, predictable target classes, and early exits when a conflicting feature is detected.

Document constraints and quirks.

Maintenance becomes dramatically easier when the team can answer, quickly and accurately, what the site depends on. Documentation turns hidden complexity into visible facts. Without it, every change becomes detective work, and knowledge becomes locked inside the memory of whoever last touched the code.

Legacy constraints include anything that limits future change: old layout assumptions, content that cannot be restructured without breaking URLs, scripts that rely on specific block types, or business processes that require certain pages to remain unchanged during peak periods.

Known quirks are the “weird behaviours” that repeat: a layout that breaks on a specific device, a form embed that fails if loaded too early, or a styling override that only works because it is placed in a particular order. These quirks are not shameful; they are operational facts that should be captured so future work is predictable.

What good documentation contains.

Write it for the next operator.

A map of custom code locations and what each block is responsible for.
A list of active scripts, what they do, and which pages they target.
A record of integrations, what data they touch, and who owns the account access.
A summary of critical pages and the actions that must never break.
A change log of major decisions, including why alternatives were rejected.

A centralised repository is usually better than scattered notes. The format matters less than the habit. A single document that is kept current is more valuable than a perfect document that is abandoned.

Documentation should also include an inventory of what is no longer required. Removing outdated scripts and redundant patterns is one of the highest-return maintenance activities because it reduces future risk without needing new features.

Periodic reviews turn documentation into a living system. A quarterly review is often enough for smaller teams, while fast-moving sites may need monthly reviews. The point is to prevent knowledge drift, where the site changes but the documentation remains frozen in the past.

Technical depth block.

Versioning makes changes traceable.

When possible, treat code injection like a small software project. Keeping script snippets in a versioned repository, even if deployment is manual, allows the team to compare changes, revert mistakes, and understand when a behaviour was introduced.

This does not require heavy process. A simple naming convention for releases, a short change log entry, and a habit of linking changes to a purpose can remove hours of future debugging. Traceability is what turns maintenance from panic into routine.

Define safe changes.

A safe change is not “a small change”. A safe change is one that has been evaluated, tested, and deployed with a plan for what happens if it fails. Defining this standard matters because it aligns stakeholders, reduces chaos, and protects the user experience while the site evolves.

Safe change expectations should be written and shared across the team. That includes what must be tested, what must be documented, who approves the change, and how success is measured. When the rules are clear, speed improves because the team spends less time arguing about process and more time executing it.

A good standard also respects business reality. Teams do not always have a perfect staging copy, unlimited time, or full QA resources. The goal is not perfection. The goal is to reduce risk with a repeatable method.

A practical change workflow.

Test, deploy, observe, then learn.

Define the change outcome in plain terms, including what should be better after release.
Assess risk by listing what could break, who would notice, and how quickly it must be fixed.
Test the change in a controlled environment when possible, including mobile and accessibility checks.
Deploy with a rollback option, so the team can revert quickly if an issue appears.
Monitor after release using analytics, error logs, and real user feedback.
Document what was changed, why it was changed, and what was learned from the result.

A common failure is launching a change without post-release observation. Many issues do not show up immediately, especially when they are tied to specific browsers, device conditions, or rare user paths. Observation turns the release into a controlled experiment rather than a blind hope.

Another common failure is treating SEO as separate from change management. Page structure, headings, internal linking, and metadata changes can alter discoverability. Safe changes include checking that critical pages remain indexable and that internal navigation still supports the content journey.

User feedback should be treated as part of the workflow, not an afterthought. A lightweight feedback loop can be as simple as tracking support enquiries after a change, reviewing comments, or checking whether visitors are abandoning a page at a new point. When the team listens, maintenance improves because the system is tuned based on reality.

Technical depth block.

Reversibility is the hidden superpower.

Safe deployment is easier when changes are reversible. Reversibility can be achieved through feature toggles, isolated scripts that can be disabled quickly, and modular CSS that can be rolled back without affecting unrelated pages. The objective is to make “undo” quick and low-stress.

Monitoring also benefits from deliberate instrumentation. Simple console tracing during testing, clear event naming for analytics, and post-release checks of key flows can reveal problems before users report them. The result is a maintenance culture that is calm, evidence-led, and resilient.

When maintenance is approached as a disciplined system, the site becomes easier to evolve without fear. The next step is to connect these maintenance choices to measurable goals, so the team can prioritise changes based on impact rather than urgency and keep the site moving forward with confidence.

Play section audio

Brine templates and safe customisation.

Why Brine still matters.

Squarespace site owners often treat a template as a skin, but the more useful view is to treat it as a framework with opinions about layout, navigation, content stacking, and responsiveness. The Brine template family became popular because it gives teams a wide visual range without changing the underlying mechanics. That matters for operations, because the moment a site grows beyond a handful of pages, the limiting factor is rarely “how it looks” and far more often “how reliably it can be extended without breaking”.

Brine is best understood as a shared engine with many aesthetic variations. Although the designs look different, the base feature set is consistent enough that a team can standardise training, documentation, and maintenance across multiple sites that use different Brine-derived themes. In practical terms, this reduces the time spent relearning where key settings live, how banners behave, how navigation responds to structure changes, and which page types are safe to scale. It also makes it easier to set expectations internally, because a repeatable pattern emerges for how content blocks render and how global settings cascade.

Template family breadth also matters for branding. When a business wants a distinctive look, it usually needs typography and spacing control, predictable header and footer behaviour, and enough layout flexibility to support “marketing pages” and “operational pages” side-by-side. Brine’s range is helpful here because teams can choose a style that fits the brand while keeping the same operational foundation. That reduces risk during redesigns, because changes can stay mostly cosmetic rather than requiring structural rebuilds.

What Brine commonly enables.

Flexible layouts, consistent mechanics.

When a site is built for growth, the important question becomes whether the layout system can support repeated patterns without drifting into one-off hacks. Brine templates typically support full-bleed areas, banner-driven storytelling, and modular sections that can be rearranged without rewriting the site architecture. This makes them suited to service businesses, e-commerce brands, and agencies that need a reliable page-building rhythm for campaigns, case studies, product launches, and evergreen content.

Navigation patterns that can be structured for simple sites and expanded for deeper information architecture.
Banner and section layouts that support marketing narratives without requiring custom page builders.
Page types that handle mixed content such as articles, galleries, and products with predictable formatting.
Responsive behaviours that preserve hierarchy and readability across desktop, tablet, and mobile.

Index pages and page architecture.

Index pages are one of the more operationally useful Brine-era features because they encourage a “compose once, reuse patterns” mindset. Instead of treating every page as isolated, a team can structure a long-form page as a sequence of sections with clear intent, such as an introduction, proof, offers, FAQs, and calls-to-action. This approach often improves comprehension for visitors because it reduces unnecessary clicking and keeps related information in one navigable flow.

Information architecture becomes easier to manage when sections behave predictably. A business can plan a content strategy that maps to section blocks: one section for credibility, one for process, one for pricing logic, one for common objections, one for next steps. That structure is not only helpful for humans; it also tends to create cleaner heading hierarchies and more scannable content, which supports discoverability when the site is crawled and indexed.

User journey outcomes often improve when friction is reduced. If visitors can find product details, supporting proof, and relevant links without bouncing between multiple pages, fewer sessions end prematurely. For teams managing a site under real-world constraints, this is why Brine-style composition remains useful: it makes it easier to ship a page that feels complete, even when the business is iterating weekly. The site can evolve by adjusting sections, not by redesigning the whole experience.

Technical depth for section stacking.

Design decisions become dependency chains.

Section stacking is powerful, but it creates dependencies that teams should acknowledge. A small change in header height, banner padding, or typography scale can shift the perceived rhythm of an entire index-style page. The practical response is not to avoid stacking, but to build a lightweight checklist: confirm heading hierarchy, confirm spacing rhythm, confirm mobile breakpoints, and confirm that CTA elements remain visible and tappable.

Define a repeatable section pattern (intro, proof, offer, objection-handling, CTA).
Keep headings consistent to avoid confusing both users and crawlers.
Test the stacked page on at least one narrow mobile width and one tablet width.
Measure scroll depth and exits to confirm the page structure matches real behaviour.

Global styles and cascading effects.

Global styles are efficient because they centralise design control, but they also behave like a multiplier. When a team adjusts a font scale, a colour system, or button styling at a global level, the change propagates across multiple page types. That is often the desired result, yet it can also produce unintended side-effects in places that are not immediately visible during a quick edit session.

Cascading effects usually show up in predictable places: navigation spacing, banner text legibility, button contrast on image backgrounds, and vertical rhythm between sections. A small typographic tweak can cause headings to wrap differently, which can push key content below the fold on mobile. A minor colour shift can reduce contrast and hurt accessibility. The risk is rarely catastrophic, but it is expensive in time when the team only discovers issues after publishing.

Performance budget is also connected to styling decisions. Overly heavy visual effects, large background images, and complex interactions can slow load times, particularly on mobile networks. When a site becomes slower, conversion and engagement often drop. The remedy is not “make it plain”, but to treat design as a system that must also meet performance constraints, especially for businesses relying on organic traffic and paid campaigns.

Operational approach to global changes.

Change control beats guesswork.

Versioned documentation is an underrated advantage for small teams. When global changes are tracked with short notes about what was changed, where it was changed, and why it was changed, diagnosing issues becomes far easier. This can be as simple as a running changelog in a shared document. The goal is not bureaucracy; it is reducing rework when a quick tweak causes a hidden regression.

Use preview and device checks before publishing changes that affect typography or navigation.
Keep a reference of the prior configuration so rollback is possible without memory guessing.
Review global styling quarterly to remove clutter and keep the system coherent.
Validate contrast and tap targets after changes that affect buttons or navigation.

Custom code and maintenance risks.

Custom CSS is often the fastest way to bridge a design gap, but it should be treated like a long-term commitment rather than a one-time fix. The immediate risk is conflict: overriding a default rule without understanding the underlying selectors can cause unexpected layout shifts. The longer-term risk is drift: as a site evolves, the code may no longer match the current structure, and small edits become increasingly fragile.

JavaScript introduces another layer of complexity because it can change behaviour, not just appearance. A script that manipulates the DOM, modifies navigation interactions, or adjusts layout measurements can fail when the template updates, when a content editor changes block structure, or when a browser update affects timing. This is why teams benefit from treating scripts as small “products” with owners, documentation, and a defined place to be installed and removed.

Staging workflow is the practical mitigation strategy. Testing code in a safe environment before it reaches production catches conflicts early and reduces public-facing issues. Even when a full staging site is not available, a team can still adopt a discipline of isolating changes, applying them in small increments, and validating on key devices. That approach prevents a site from becoming a brittle web of interdependent tweaks.

When plugins reduce custom risk.

Standardised extensions can be safer.

Cx+ style plugin libraries can be useful when the goal is to add repeatable UI patterns without accumulating bespoke scripts. The strategic benefit is consistency: if multiple sites need the same behaviour, a standardised implementation reduces one-off code variations. The important principle is not the brand name of the tooling, but the maintenance model: upgrades, compatibility checks, and stable configuration patterns.

Prefer small, single-purpose additions over large scripts that touch many elements.
Keep a clear inventory of installed code and what each piece is responsible for.
Remove unused code proactively to avoid hidden performance and conflict costs.
Monitor performance after changes to confirm improvements are real, not assumed.

Small changes and big outcomes.

Micro-adjustments in spacing, headings, or navigation can reshape a site’s usability more than teams expect. A few pixels of padding can change whether a layout feels balanced on desktop, but the same change can cause a stacked mobile layout to feel cramped or confusing. Because Brine-driven layouts rely heavily on rhythm and hierarchy, seemingly minor edits can alter how quickly visitors understand what the site offers.

Conversion rate is often affected by design details that look “small” in isolation. If buttons lose contrast, if navigation becomes visually noisy, or if key information is pushed lower on mobile, visitors hesitate. That hesitation often shows up as higher bounce rates, shorter sessions, and fewer completed actions. For founders and operators, the lesson is simple: the impact of a change should be measured, not assumed, even when the change feels cosmetic.

SEO sensitivity is another reason to treat small changes carefully. Heading structures, content placement, internal links, and page speed all influence how easily a site can be discovered and understood by search engines. A design tweak that accidentally demotes headings, hides text behind interactions, or slows the page can reduce performance over time. The most reliable approach is to maintain clean structure, fast loading, and clear content signals, then iterate using measured outcomes.

Practical iteration methods.

Test, observe, refine.

A/B testing is not only for large organisations. Even a simple experiment, such as comparing two button labels, two hero layouts, or two navigation structures, can reveal which version reduces friction. When paired with analytics, these small experiments turn design work into evidence-based iteration rather than opinion-based debate.

Collect user feedback after meaningful changes, especially on mobile navigation and checkout flows.
Track engagement signals such as scroll depth, exits, and click-through on key sections.
Establish a baseline before edits, then compare results over a consistent time window.
Keep changes small enough that cause and effect remain clear.

Operational maturity with Brine templates comes from recognising that visual flexibility does not remove the need for process. The teams that get the most from Brine treat design settings, global styles, and custom code as a managed system, not a collection of isolated tweaks. When structure, measurement, and documentation become normal behaviour, Brine’s flexibility turns into an advantage that compounds over time, enabling faster iteration without sacrificing stability.

Play section audio

Practical differences in 7.1.

Editing experience shifts.

The biggest day-to-day change between Squarespace 7.0 and Squarespace 7.1 is not a single feature, but the editing model itself. Teams moving across versions tend to feel it immediately because page building, style control, and layout behaviour are organised differently. What once felt like “this template edits like this” becomes “the platform edits like this”. That consistency is useful, yet it can also remove familiar levers that older sites relied on.

In 7.0, many sites were built on the Brine template family, where template variants exposed different knobs and switches. That meant two organisations could both “be on Squarespace” while having very different editing workflows and layout constraints. Some site owners loved that variety because it rewarded deep familiarity with a given template. Others found it frustrating because a change that was simple on one template could be awkward on another.

7.1 pushes the experience towards standardisation. The editor is intended to behave consistently across the platform, so the learning curve becomes flatter for new team members and cross-site work becomes simpler. From an operations perspective, this matters: onboarding a contractor, delegating page updates, or documenting internal processes becomes easier when the same controls exist site-wide.

That standardisation comes with trade-offs. When a workflow in 7.0 depended on template-specific behaviour, migration can feel like losing a favourite tool, even if the “new way” is objectively cleaner. A common example is layout control that was once achieved through template settings, spacing options, or quirky editor behaviours that people learned to exploit. In 7.1 those behaviours are often replaced by a more opinionated layout system, which can require rethinking how a page is constructed rather than copying it across.

What standardisation changes.

Template quirks become platform rules.

Standardisation means fewer surprises across templates, but it also means fewer “hidden wins” that experienced 7.0 builders used to achieve specific outcomes. The practical implication is that teams should stop thinking in terms of “which template can do this” and start thinking in terms of “how the platform expects this layout to be built”. That difference shows up in spacing, alignment, section structures, and how global styles flow through the site.

Design control in 7.1 is typically routed through the Style Editor, which is meant to consolidate global decisions. For brand consistency, that is a positive step: typography, colour palettes, and button styles can be managed in a central place rather than being scattered across pages and template settings. For teams with limited design capacity, the system reduces the chance that one page quietly drifts away from brand standards.

At the same time, centralised styling can create new constraints. When a site owner wants one page to break the rules for a campaign landing page, or when a legacy design relies on isolated exceptions, the “global first” approach can make exceptions feel harder than before. The outcome is not that exceptions are impossible, but that they are often better handled via deliberate techniques such as careful section structuring, scoped custom CSS, or explicit component patterns.

Layout building on 7.1.

Fluid placement rewards planning.

7.1 is strongly shaped by Fluid Engine, which changes how layout is assembled and adjusted. It enables more flexible placement in many cases, yet it also introduces rules about how blocks align, how grids resolve, and how content reflows. People migrating from 7.0 can misread this flexibility as “total freedom”, then get frustrated when certain placements refuse to behave consistently across devices.

The operational reality is that a layout that looks perfect on desktop can still be structurally fragile if it was built without a clear grid intention. Teams that treat page building like composing a system tend to do better: defining repeatable content patterns, using consistent section padding, and favouring predictable alignment choices that hold up when content changes.

For organisations that need repeatable enhancements without rewriting core layouts, code injection becomes a practical tool rather than a last resort. This is where a curated plugin approach can help when used responsibly. For example, Cx+ style add-ons can provide repeatable UI behaviour across a site, but the key lesson is broader than any product name: stable improvements come from stable patterns. If a site relies on one-off hacks, edits become risky and every change creates hidden knock-on effects.

Standard tools reduce training time, but remove template-specific shortcuts.
Central styling improves consistency, but exceptions need more deliberate handling.
Flexible layout systems reward repeatable patterns over improvisation.
Enhancements are safest when they reinforce structure rather than fight it.

Responsiveness expectations.

Responsiveness is where many migrations feel “fine” until a thorough device check reveals subtle issues. The underlying challenge is not that 7.1 is non-responsive; it is that the platform’s default behaviour may not match what a team expects based on prior habits. A site can look excellent at a glance, yet still contain frustrating edge cases where spacing collapses, alignment shifts, or text loses hierarchy on specific screen widths.

In 7.0, many builders developed a high level of control over responsive design, particularly in template families that exposed more device-specific settings. That control often created confidence: if something looked wrong on mobile, there was usually an obvious lever to pull. In 7.1, the system tends to prioritise automatic adjustments, which can feel like a loss of control to teams that previously tuned layouts with precision.

The key idea is that “responsive by default” and “responsive as intended” are not the same thing. Automatic responsiveness can make a site usable across devices, yet still fail the organisation’s standards for polish, conversion clarity, or brand presentation. That matters commercially because mobile visitors rarely forgive friction. If a pricing table becomes hard to scan, if a call-to-action drops below a fold unexpectedly, or if images crop in a way that hides the product, the site may technically function while still underperforming.

How layouts reflow.

Breakpoints shape behaviour.

Most responsiveness issues become easier to understand when teams think in terms of breakpoints. The platform makes decisions at certain width ranges about stacking, resizing, and spacing. A layout that is built with tight positioning and minimal tolerance can fail when it crosses those width thresholds. That failure can present as misaligned buttons, unexpected stacking orders, or text wrapping that turns tidy headings into awkward multi-line blocks.

Testing is not a one-time “mobile check”. Mature teams treat device validation like quality assurance: checking key templates, key flows, and key conversion pages across several common device sizes. The practical goal is to catch structural fragility early, before content updates amplify the problem. A page built on fragile alignment often looks acceptable when it is empty or uniform, then breaks when real-world content is added or when translations lengthen copy.

Content strategy and responsive strategy are linked. In 7.0, some sites were designed around very specific image-to-text pairings that worked because the editor allowed tight control. In 7.1, automatic adjustments can change the perceived balance between text and imagery. The fix is rarely to fight the platform at every point; it is usually to redesign the content pattern so it survives reflow. That can mean shorter headings, more consistent image aspect ratios, clearer section separation, or layouts that assume stacking will happen and still look intentional.

Practical checks after changes.

Validate flow, not just looks.

A polished responsive site is not only visually correct; it is also behaviourally correct. Teams benefit from validating flows: can a visitor scan the value proposition, find the primary action, and complete the intended task without hunting? On mobile, that often means checking tap targets, spacing between interactive elements, legibility of small text, and whether important information stays near the call-to-action.

Where the platform’s defaults do not align with business requirements, controlled customisation is still possible. The safest approach is normally minimal, targeted adjustments that solve a specific issue, rather than broad overrides that create new ones. When a team adds custom CSS or scripts to “fix everything”, they often create a maintenance trap where future edits become risky because the site is now balanced on undocumented assumptions.

Automatic reflow is useful, but it can diverge from brand expectations.
Device testing should be systematic, not occasional.
Content patterns should be designed to survive reflow gracefully.
Small targeted fixes outperform broad overrides over the long term.

CSS and DOM challenges.

Custom code is often where migration effort becomes real work rather than a simple rebuild. Even when two pages look similar, the underlying structure can differ enough that old styling rules stop applying. Teams that relied heavily on custom CSS in 7.0 should expect a re-validation phase in 7.1, because the platform’s structure and class naming conventions may not match legacy assumptions.

In practical terms, CSS selectors that were stable on a 7.0 template might not map cleanly in 7.1. That is not a moral judgement on either version; it is a reminder that styling rules are dependent on structure. When the structure changes, selectors need to be revisited. For organisations, this is a risk area because “small” style tweaks can silently break important interface behaviour.

The underlying reason is the DOM shape. If a template wraps content differently, nests blocks differently, or uses different classes, a selector can suddenly become too broad, too narrow, or irrelevant. Some teams discover this only after launch, when an update causes headings to lose spacing or buttons to inherit the wrong styles. That experience is avoidable when the migration process includes a code audit and a test plan.

Custom scripts and structure.

JavaScript depends on stable targets.

Custom JavaScript can be even more sensitive than CSS because it often depends on specific element relationships or event behaviours. A script that attached click handlers to a selector that once existed in a certain location may stop working if the structure changes. The most reliable scripts are those that target stable, intentional hooks, such as explicit data attributes or clearly defined component wrappers, rather than relying on fragile class chains.

From an engineering standpoint, it is useful to treat custom code as a product in its own right. It needs naming conventions, documentation, and a clear boundary between “site content” and “site behaviour”. When that boundary is unclear, marketing edits can accidentally break engineering logic. When the boundary is clear, teams can iterate faster because the impact of a content change is more predictable.

Performance is part of this conversation. A migration that carries over unoptimised scripts or heavy style overrides can produce a visually correct site that loads slower and behaves worse. This is where platform upgrades can accidentally increase friction: the organisation invests in modernisation, yet the resulting site feels heavier because legacy code was brought across without review.

Code hygiene during migration.

Reduce technical debt deliberately.

Migration is an opportunity to reduce technical debt rather than carry it forward. A useful process is to inventory every custom rule and script, assign it a purpose, and decide whether it is still needed. If a feature is now native in 7.1, the custom code can often be removed. If a feature is still required, it can be rewritten to target stable hooks and to behave predictably across devices.

Documentation is not optional when multiple people touch a site. Even lightweight notes about what a script does, what it targets, and what could break it can prevent hours of future debugging. This matters for operations teams because content work is often time-sensitive, and broken behaviour typically shows up when deadlines are tight.

Structure changes can invalidate styling rules even if pages look similar.
Scripts are safest when they target intentional hooks rather than brittle selectors.
Migration is a chance to remove unnecessary code and improve performance.
Simple documentation protects future edits from accidental breakage.

Migrate or maintain.

The decision to migrate is rarely a purely technical one. It is a strategic choice about risk, capability, and timing. A site can remain on an older version and still perform well if it is maintained carefully. Conversely, a rushed migration can harm performance, SEO, and customer trust even if the new editor feels modern.

Migration offers benefits that tend to compound over time: access to a more consistent editing model, alignment with current platform development, and a clearer foundation for future enhancements. For teams that expect frequent content updates, collaboration across roles, or scaling into more complex workflows, those benefits can outweigh the initial disruption.

Maintenance can be the right choice when an existing site is stable, heavily customised, and performing strongly. If the organisation’s revenue depends on specific behaviours that are expensive to reproduce, stability can be more valuable than novelty. The trade-off is that maintenance usually means accepting constraints: fewer platform improvements, more reliance on legacy patterns, and potentially more effort required to keep performance and security practices high.

Decision framing for teams.

Optimise for outcomes, not version numbers.

A strong decision process starts with outcomes. If the goal is better lead capture, faster publishing, improved mobile conversion, or cleaner content operations, the team can evaluate which path supports that goal with the least risk. This is where QA becomes central. Migration should be treated like a release: a checklist, a staged environment where possible, and validation of key flows before going live.

SEO is a common fear, yet it becomes manageable when addressed directly. A careful migration plan includes SEO checks, metadata validation, and a redirect map where URLs change. When necessary, 301 redirects protect rankings and preserve inbound link value. Analytics baselines also matter: if the team cannot measure pre- and post-migration outcomes, it becomes difficult to know whether the migration improved the business or simply changed the site.

Performance should be evaluated with user-centric metrics rather than gut feel. Checking Core Web Vitals and real-world load behaviour helps teams spot regressions early. Improvements often come from simplifying layouts, reducing heavy scripts, compressing media, and avoiding over-engineered visual effects that look impressive but slow down interaction.

Operational pathways after choice.

Build a sustainable support model.

Whatever decision is made, long-term success depends on operational habits. A maintained 7.0 site needs governance: content discipline, careful code management, and regular checks so the site does not slowly degrade. A migrated 7.1 site needs a similar mindset: documented patterns, repeatable page structures, and a controlled approach to enhancements.

This is where supportive systems can play a role when the organisation is ready. For example, Pro Subs style maintenance thinking is essentially an operations principle: treat the site as an evolving asset, not a one-time project. In parallel, tools like CORE can become relevant when a site’s support load grows and visitors expect instant answers, since reducing repetitive enquiries improves both user experience and team capacity. The key is timing and fit; the platform decision is only one part of a larger workflow story.

When the differences in editing, responsiveness, and code structure are understood as operational realities rather than platform drama, teams can plan confidently. The next logical step is to translate these realities into a practical checklist: inventory what exists, define what must remain identical, identify what can improve, and sequence the work so that risk stays controlled while the site’s capabilities move forward.

Play section audio

Avoid risky website changes.

Protect stable revenue flows.

When a website already produces dependable income, large structural changes deserve extra scrutiny. A stable website is not just a marketing asset, it is an operating system for sales, enquiries, bookings, and repeat behaviour. If the current experience reliably converts, the safest path is often to improve around the edges rather than rebuild the centre.

A revenue-critical website typically has patterns that users have learned over time. Navigation habits, purchase flows, and even small interface cues become muscle memory. A major redesign can unintentionally break those habits, increasing friction in places that previously felt effortless. The risk is rarely theoretical, because even slight confusion at checkout, pricing, or key information pages can cause measurable drop-offs.

Change should be treated like a budgeted resource. A change budget frames how much disruption is acceptable in a given period, based on seasonality, campaign schedules, and operational capacity. For example, an e-commerce site entering peak trading weeks can justify optimisation work, but not wholesale navigation experiments. The same logic applies to service businesses that rely on predictable lead flow from a small set of high-ranking pages.

There is also a hidden cost to disruptive change: internal time. Support teams often absorb the impact first through increased questions, more “where did this go?” messages, and higher abandonment. Even if long-term gains are possible, short-term instability can create operational strain that cancels out the intended benefit.

Identify the pages and flows that directly contribute to income, then treat them as high risk areas.
Separate “cosmetic improvement” work from “behaviour-changing” work, because the risk profile differs.
Consider seasonality, campaigns, and staffing capacity before scheduling disruptive releases.
Prefer improvements that reduce friction without changing learned navigation patterns.

Ship in controlled increments.

Incremental change is the safest way to modernise without destabilising performance. Smaller releases reduce the blast radius when something behaves unexpectedly, and they make it easier to isolate the cause of performance shifts. This approach is not slower in practice, because it prevents long rollback cycles and post-launch firefighting.

A disciplined release rhythm relies on regression testing, meaning the most important journeys are re-checked after every change. On content and commerce sites, the “most important journeys” are usually simple: navigation to key pages, form submissions, product selection, basket behaviour, and checkout completion. If any of those fail, the release should be treated as broken regardless of how successful the visual redesign appears.

Testing should include both behaviour and discoverability. Even a “minor” layout shift can change how search engines interpret internal linking, headings, and content prominence. This is why controlled releases are often paired with clear measurement windows, allowing teams to compare a baseline period against a post-change period without overlapping initiatives.

When teams have enough traffic, A/B testing becomes a practical way to validate hypotheses rather than relying on taste. The test should be attached to one specific goal: improved conversion rate, reduced bounce, higher scroll depth, or increased clicks to an intended next step. If multiple changes are bundled together, a test may show a result, but it will not reveal what caused it.

Technical depth: testing stack.

Use measurement that isolates causes.

Controlled change works best when the measurement model is designed before the design work begins. Analytics should be configured to track events that map to business outcomes, such as add-to-basket, form completion, booking confirmation, or outbound click to a payment provider. Heatmaps and session recordings can add qualitative context, but they should support decisions rather than replace quantifiable evidence.

For teams operating across a website and backend systems, the test scope should include integrations. A site built on Squarespace may appear stable visually while an embedded form, third-party scheduler, or payment flow fails silently. Similarly, a database-driven workflow in Knack can introduce breaking changes if field structures are modified without aligning automations and front-end queries.

Define one measurable hypothesis per change set, with a single primary metric.
Create a checklist for core journeys and execute it after every release.
Use staged rollouts where possible, starting with low-risk pages before high-value flows.
Keep release notes so that metric changes can be mapped to specific updates.

Lock templates early.

Template decisions are architectural decisions, even when the platform markets them as simple themes. Switching templates late often forces rework because layout rules, spacing behaviours, and feature assumptions change underneath the content. The further a project progresses, the more a template change behaves like a rebuild rather than a swap.

In practice, a late template switch can break consistency across typography, navigation patterns, and component behaviour. It can also introduce subtle inconsistencies that only appear on certain devices. Those inconsistencies then drain time as teams chase small visual misalignments while more important work stalls.

This is particularly relevant when a site has custom enhancements layered on top. A plugin, code injection, or bespoke CSS may have been written against specific markup patterns. A template change can alter those patterns, producing unpredictable results. The time cost is not only in fixing problems, but also in re-validating the work that previously felt complete.

Choose a template based on layout needs, content structure, and long-term flexibility, not only aesthetics.
Test critical page types early: landing pages, product pages, blog posts, and forms.
Document the reasons for template selection so later stakeholders understand the constraint.

Design for reversibility.

A reversible change strategy is a safety net that enables improvement without fear. When changes can be reversed quickly, teams can experiment responsibly. When changes cannot be reversed, teams often become overly cautious, which slows progress and keeps avoidable inefficiencies in place.

Version control is one of the simplest ways to achieve reversibility for code-based changes. Even when a site is primarily no-code, injected scripts, custom CSS, and integration logic benefit from tracked history. When something fails, the fix is clearer: the previous known-good state is visible and can be restored without guesswork.

Reversibility is not only technical. Content edits, navigation label changes, and SEO metadata updates should also be traceable. A simple change log that records what changed, why it changed, and who approved it creates accountability and prevents repeated debates that burn time.

Where possible, changes should be guarded with feature flags. A flag allows a release to ship while remaining controllable, so behaviour can be toggled off if metrics drop. This is especially useful when deploying enhancements that affect core flows, such as checkout guidance, search behaviour, or dynamic content loading.

Technical depth: safe environments.

Separate testing from production risk.

A staging environment is ideal, but not always available on every platform. When staging is not feasible, teams can simulate staging by testing changes on duplicate pages, password-protected areas, or low-traffic sections first. The key is to avoid using real users as the test harness for high-impact changes.

For workflows involving automation, reversibility should extend beyond the website. Automation platforms such as Make.com can amplify small field changes into large operational issues if scenarios run on old assumptions. Backend logic hosted on Replit can also fail in ways that appear unrelated to the front-end if endpoints, credentials, or payload formats shift without coordinated updates.

Keep a clear rollback path for every release, including content and configuration.
Store configuration in a controlled location so that flags and settings are auditable.
Ensure automations and integrations have safe failure modes, not silent failures.

Plan beyond quick wins.

Some changes look beneficial in the short term but create long-term complexity. A feature that boosts engagement today may require constant maintenance tomorrow. A new integration may reduce manual effort initially but introduce fragile dependencies that break when a vendor updates an API.

Long-term thinking starts with a clear model of what the site is meant to achieve. When changes do not align with business strategy, they tend to become clutter. Clutter then slows down future work, because every new improvement must navigate a growing pile of exceptions, patches, and legacy decisions.

Planning should also account for discoverability. Any significant structural change can affect search engine optimisation through internal linking changes, URL shifts, and altered content hierarchy. A site may look better visually while becoming harder to find, which is a poor trade when traffic is the fuel for conversion.

When performance is part of the plan, it helps to track Core Web Vitals and other page experience indicators that influence usability. Large visual updates can increase asset weight, add scripts, and slow the experience on mobile devices. A site that feels fast is often more persuasive than a site that merely looks modern.

Evaluate maintenance cost as part of the decision, not after launch.
Prioritise improvements that simplify future work rather than increasing dependency chains.
Consider performance budgets so design changes do not silently degrade speed.

Bring stakeholders into scope.

Website changes affect more than design teams. Stakeholders include operations, support, sales, and the users themselves. When decisions are made in isolation, important constraints are often missed, and those constraints appear later as avoidable problems.

Stakeholder involvement also reduces resistance. People support what they help shape. If teams contribute to priorities and risk assessment early, the implementation phase becomes smoother, because fewer people are surprised by outcomes.

Practical stakeholder input tends to reveal real-world context. Support teams can identify recurring questions that suggest missing content. Sales teams can identify friction points in enquiry journeys. Operations teams can highlight where the website connects to fulfilment, invoicing, or onboarding processes.

Stakeholder work should remain structured. Feedback is valuable when it is anchored to goals, evidence, and constraints. Unstructured feedback often becomes a contest of opinions, which slows decisions and reduces clarity.

Gather input around specific journeys, such as enquiry, purchase, or onboarding.
Use short review cycles so feedback is timely and actionable.
Document approvals and constraints so decisions remain stable over time.

Measure impact after launch.

Launching a change is not the end of the work, it is the start of validation. Many teams stop at deployment, then move on before learning whether the change helped or harmed. Post-launch evaluation turns website work into a learning loop rather than a sequence of isolated projects.

Evaluation begins with clearly defined key performance indicators. These should map to the original goal: conversion rate, lead quality, time-to-complete tasks, bounce rate, scroll depth, or support ticket volume. If measurement is vague, a team may interpret any outcome as success, which prevents real improvement.

Quantitative data should be paired with qualitative signals. User feedback can explain why metrics moved. For instance, a conversion dip might be caused by confusion, mistrust, or performance regressions. Without qualitative context, teams may “fix” the wrong problem.

Reporting keeps evaluation honest. Regularly sharing results forces accountability and supports better decisions. It also helps stakeholders understand trade-offs, so future releases are governed by evidence rather than urgency.

Build dashboards that track outcomes daily during the first weeks after release.
Compare baseline periods against post-change periods with consistent time windows.
Record observations and decisions so future work compounds rather than resets.

Expect surprises, respond fast.

Unexpected outcomes are normal in digital work, even with careful planning. A small UI change can trigger large behaviour shifts. A performance tweak can improve speed but reduce engagement if it alters content presentation. Surprises should be expected and managed, not treated as failure.

The most reliable defence is a defined response playbook. An incident playbook outlines what happens when metrics drop, errors appear, or users report confusion. It clarifies who assesses the issue, who approves rollbacks, and how communication is handled.

Fast response protects trust. If a release causes friction, the speed of correction matters as much as the correction itself. Users often forgive issues when the organisation responds quickly and communicates clearly.

Communication should stay factual and calm. When changes affect workflows, stakeholders and users prefer clear statements: what changed, what is known, what is being done, and when an update will follow. This preserves credibility while the issue is resolved.

Maintain the ability to revert quickly, even if full reversibility is not always used.
Keep an escalation path so issues do not stall due to uncertainty.
Capture learnings after incidents, then update processes to prevent repeat failures.

Build skills continuously.

Website performance improves faster when teams improve. Digital platforms shift constantly, and best practices evolve as browsers, devices, and user expectations change. Training is not a luxury, it is the mechanism that keeps decision-making accurate.

Ongoing learning supports better judgement. Teams that understand accessibility, performance optimisation, analytics hygiene, and content strategy make fewer risky decisions and recover faster when issues occur. They also communicate more clearly with stakeholders, because they can explain why trade-offs exist.

Training should be practical. Workshops, focused courses, and internal knowledge sharing tend to deliver more value than broad theory. The aim is competence that applies to daily work: better testing habits, cleaner deployments, and clearer measurement.

Building a learning culture also improves continuity. When knowledge is shared across a team, the organisation becomes less dependent on single individuals. This reduces operational risk and increases the speed at which improvements can be delivered.

Encourage targeted learning aligned with the site’s biggest constraints.
Schedule knowledge sharing so insights move across roles, not only within roles.
Document lessons from releases so training is grounded in real outcomes.

Track trends with evidence.

Trends are useful when they are filtered through context. Copying competitors without evidence often leads to misaligned changes. Trend-aware teams focus on understanding why something works, then adapt it to their own audience and constraints.

Research should be structured. Tools such as Google Trends, industry publications, and competitor reviews can reveal shifts in language, expectations, and common patterns. Analytics then confirms whether those shifts apply to the audience already using the site.

User preference is rarely static. What felt modern two years ago may now feel slow or cluttered. At the same time, novelty for its own sake is rarely valuable on a site designed to convert. Evidence-based trend adoption means selecting improvements that reduce friction and improve clarity, not selecting changes that merely look current.

Trend tracking is also a way to avoid technical debt. When platforms evolve, earlier shortcuts become liabilities. Regular research helps teams spot upcoming constraints early, such as changes in browser behaviour, SEO guidelines, or integration requirements, allowing upgrades to be planned rather than forced.

Handled well, cautious change becomes a competitive advantage. The strongest sites are not those that change constantly, but those that improve predictably, measure honestly, and protect what already works while still making room for progress.

Play section audio

Key features of Brine templates.

Page types that reduce layout bottlenecks.

The Brine template family is widely recognised for offering a broad spread of built-in layouts, which matters when a site needs to do more than publish a few static pages. A template that supports varied formats tends to reduce late-stage compromises, where teams are forced to “make a blog behave like a catalogue” or push important content into awkward workarounds.

Within Squarespace, those formats are typically expressed as distinct page experiences, such as blogging, events, galleries, albums, and commerce. The practical upside is planning freedom. A business can launch with a simple structure, then evolve into richer content without rebuilding the site’s foundations each time a new requirement appears.

Brine is often described as having “around 50” variations. The important detail is not the count, but the shared underlying capability. When templates share the same foundation, switching designs later tends to be less disruptive, because the site is not moving between entirely different feature sets. That continuity helps teams iterate on aesthetics while protecting functionality.

From an operational perspective, page types act like pre-defined containers with opinions about content. A store page expects products, pricing, and checkout logic. A blog page expects chronology, tagging, and author context. Choosing containers that match the content keeps the editorial workflow clean and reduces the amount of custom glue required to make day-to-day publishing feel “normal”.

Album pages.
Blog pages.
Cover pages.
Events pages.
Gallery pages.
Index pages.
Layout pages.
Store pages.

How to choose page types deliberately.

Use the content model to pick the container.

A practical method is to list the content that must be created, updated, and retired over time, then map each item to the container that natively supports it. If the business publishes weekly articles, a blog container prevents “manual chronology”. If the business runs periodic launches, event-style publishing patterns can keep dates and registrations consistent. If the business sells physical goods, commerce-native pages reduce checkout friction.

Edge cases usually show up when a site tries to force one container to serve two competing jobs. A common example is using a gallery to act like a store catalogue, then manually adding pricing and purchase flows. It can work, but it increases maintenance effort and usually creates a brittle experience on mobile devices, where spacing and touch targets become harder to control.

Styling that supports brand consistency.

Template versatility only matters if the design can be shaped to match a brand without becoming fragile. Brine is often praised for extensive styling controls that let teams tune spacing, typography, colour, overlays, and layout behaviour without requiring constant code edits.

A key benefit is that many changes can be made through configuration rather than custom development. That distinction matters in real operations. When a non-technical teammate can adjust a banner overlay or recalibrate padding safely, the team moves faster, and fewer changes have to be queued behind developer time.

Another practical advantage is responsive design. A layout that looks tidy on desktop can become cluttered on smaller screens if the template cannot adapt typography scale, image cropping, and section spacing. Brine’s styling options make it easier to preserve hierarchy across devices so the message stays readable and the calls-to-action remain usable.

Technical depth.

Design controls are a governance tool.

When styling is centralised, it behaves like a guardrail system. Fonts and colours become “site-level decisions” rather than per-page improvisations. That reduces visual drift, keeps accessibility considerations more consistent, and makes audits easier because adjustments can be applied globally rather than chased across dozens of pages.

Teams should still treat styling changes as experiments with measurable outcomes. A spacing tweak that increases readability may also push key content below the fold on mobile, which can reduce conversions. The safest approach is to change one variable, observe behaviour, then keep or revert based on evidence.

Index pages for structured storytelling.

Index pages are one of the most useful organisational ideas in the Brine ecosystem because they make it possible to assemble multiple sections into a single narrative flow. Instead of forcing visitors to hop between pages to understand what a business does, a well-built index can guide them through a sequence that feels intentional.

For businesses with diverse offerings, that stacked structure can prevent overwhelm. Rather than showing everything at once, the site can introduce the highest-level promise first, then progressively reveal proof, services, outcomes, and next steps. This creates a calmer experience, which is often what increases trust.

Index pages are also useful for campaigns and seasonal pushes. A team can curate a page that highlights only the most relevant sections for a specific period, while keeping the broader site intact. This avoids rebuilding navigation every time a new initiative appears.

Technical depth.

Long pages need performance discipline.

Stacked pages can become heavy if they include too many large images, background media, or repeated interactive blocks. In practice, the risk is not just slower load time, but uneven interaction, where scrolling becomes janky on mid-range mobile devices. The mitigation is content discipline: compress images, reduce decorative media, and keep above-the-fold elements lean so the initial render stays fast.

When a site needs richer interaction on long pages, codified enhancements such as Cx+ style plugins can help improve navigation patterns and micro-interactions, but only when they are applied selectively and tested against real devices. The goal is always clarity first, effects second.

Social sharing that fits the brand.

Social sharing features matter when the content itself is part of growth. If a business publishes articles, galleries, or case studies, share buttons can reduce friction for visitors who want to pass something along. When sharing is easy, distribution becomes a by-product of good content rather than a constant manual push.

The most effective share placements are usually contextual rather than everywhere. Buttons placed near a strong insight, a key visual, or the end of a useful section tend to feel purposeful. Buttons placed randomly can look like clutter and reduce attention on the content that actually drives conversion.

Where tracking is required, teams can use tagged links and analytics to observe what content gets shared and which platforms produce high-intent traffic. The value is not vanity metrics, but pattern recognition: which topics attract the right audience, and which formats lead to meaningful actions.

SEO foundations built into the structure.

Brine’s emphasis on SEO is mainly about providing the levers that help a site communicate with search engines clearly. When teams can define titles, descriptions, and image descriptions cleanly, they have more control over how pages appear in search results and how accessible the site is to visitors using assistive technologies.

At a practical level, meta tags help shape how pages are summarised and understood by crawlers and social platforms. Clear titles that match search intent, paired with accurate descriptions, reduce the mismatch between what a visitor expects and what the page delivers. That alignment improves engagement signals over time.

Brine also supports structured data patterns, which can improve the way information is interpreted and displayed in enhanced search results. The key point is not chasing every possible markup option, but ensuring the essentials are correct: business identity, content type, and consistent page metadata.

Technical depth.

SEO is tightly coupled to performance and UX.

Search visibility is rarely a single setting. It is the combined effect of content quality, internal linking, load speed, and interaction stability. A page can have perfect metadata and still underperform if it loads slowly or confuses visitors. That is why template choice, media discipline, and navigation clarity should be treated as SEO decisions, not just design decisions.

Support resources and operational resilience.

Templates become more valuable when the surrounding support ecosystem reduces downtime and confusion. Documentation, tutorials, and community knowledge help teams implement features correctly, and they shorten the learning curve for new contributors who join later.

Ongoing updates matter for a different reason: stability and security. A site is not a “set and forget” asset. It is a living system connected to browsers, devices, and third-party services that change continuously. Regular maintenance, backups, and a clear change log approach reduce the chance that a small tweak turns into a broken experience.

Integrations that extend the stack safely.

Most modern sites are not standalone. They connect to analytics, email marketing, and commerce workflows. Brine sites can be integrated with common tooling through platform integrations and code injection patterns, but teams should treat integrations as part of architecture, not a collection of random add-ons.

For measurement, Google Analytics style tracking helps teams understand acquisition, behaviour, and conversions. For lifecycle marketing, platforms such as Mailchimp can support newsletter capture and segmentation. For commerce, some organisations also connect external storefront systems such as Shopify or WooCommerce through links, embeds, or dedicated checkout flows, depending on how the stack is designed.

The operational rule is simple: each integration should have an owner, a purpose, and a maintenance plan. If nobody can explain why a tool exists, it becomes a hidden cost and a future failure point.

Security features that protect trust.

Security is not a single checkbox. It is a collection of practices and platform features that protect visitors and protect the business. Brine sites typically benefit from platform-level HTTPS via SSL, which secures data in transit and is now a baseline expectation for professional websites.

Account hardening is often where real risk sits. Enabling two-factor authentication, using strong unique passwords, restricting admin access, and maintaining backups all reduce the likelihood that a compromised credential becomes a full site incident. These steps are unglamorous, but they are foundational to long-term reliability.

Performance optimisation that compounds over time.

Site speed is directly tied to user behaviour. If pages load slowly, users abandon sessions, and search engines interpret that as poor experience. Brine’s performance strengths are typically supported by clean structure, but results still depend on how content is produced and managed.

The most common performance issues come from oversized images, excessive animations, and long pages packed with heavy media. A disciplined workflow that compresses images, limits decorative assets, and keeps templates lean usually beats any last-minute “speed fix” attempt.

Teams should also understand caching at a conceptual level. When assets can be reused instead of re-downloaded on every visit, repeat sessions become faster, and the site feels more stable. While much of this is handled by the platform and browsers, content decisions still influence the outcome.

With these capabilities in place, the next step is usually to assess how template choices influence real user journeys, such as discovery, trust-building, and conversion, then decide which enhancements belong in configuration, which belong in content operations, and which require targeted development to remove friction without adding complexity.

Play section audio

Limitations of Brine templates.

The Brine template family is widely recognised for clean layouts and strong typography defaults, yet it also carries structural constraints that can affect modern content strategies. These limitations rarely “break” a website, but they do shape what is easy, what is awkward, and what becomes expensive in time or maintenance. For founders and small teams, the real risk is not the limitation itself, it is the hidden operational cost of workarounds that slowly accumulate across navigation, content publishing, and performance.

Many of the gaps described below appear when a site grows beyond a small brochure format. As soon as a website becomes a knowledge hub, a blog library, or a product catalogue that needs clear pathways, the template’s defaults start acting like guardrails. Some guardrails are helpful, but others block useful patterns such as persistent navigation surfaces, structured author information, or content discovery components that reduce bounce and improve session depth.

Lack of built-in sidebar functionality.

A missing sidebar sounds minor until the site needs a stable second column for navigation, filtering, or contextual content. In Brine, the absence of native sidebar patterns forces teams to re-think layout from the ground up, because the template’s “expected” structure centres the main content as the only persistent reading lane. For content-heavy sites, that default can reduce clarity when visitors need quick access to categories, related links, or content series navigation.

Sidebars are not only decorative. They often act as part of an information architecture system, offering secondary navigation that lowers the number of clicks needed to reach key pages. Without a sidebar, important supporting items tend to get pushed into the header navigation, buried into the footer, or repeated as manual blocks inside each post. Each option works, but each one introduces either clutter, inconsistency, or ongoing editing overhead.

Pattern supply.

When the template does not supply a pattern, the pattern still has to exist somewhere.

Practical workarounds that stay manageable.

A common workaround is to build a repeatable “sidebar-like” column using page sections and blocks, then treat it as a standard layout component used across posts. The catch is that Brine does not automatically “attach” that component to every blog post, so teams typically end up duplicating structures. This is where process discipline matters: if the team cannot enforce consistent block placement and spacing, the sidebar becomes inconsistent and loses its value as a navigational anchor.

Assess whether a sidebar is needed for navigation, conversion, or trust building, rather than adding it because it “looks traditional”.
Prefer a single reusable pattern for the sidebar content (for example, category links plus a short callout), rather than changing it per post.
Keep the sidebar content lightweight so it does not compete with the main reading flow or inflate page weight.

Technical depth: building a sidebar effect.

Most sidebar implementations in Brine end up using a combination of layout blocks and CSS overrides. This can work well if it is done with restraint and tested across breakpoints. The main edge case is responsive behaviour: a sidebar that looks perfect on desktop can become an awkward content pile on mobile if it is not repositioned or collapsed. Another edge case is editing: if a non-technical editor moves blocks around, the layout can break, which means the solution must be resilient to normal content updates.

For teams that want a more productised route, a structured plugin approach can help, where the “sidebar” is treated as a controlled component with clear rules for placement and behaviour. In the Squarespace ecosystem, solutions like Cx+ may be relevant when the goal is to retrofit consistent UI patterns without repeatedly custom-coding per page, but the selection should still be driven by the site’s requirements rather than novelty.

Absence of certain blogging features.

Brine can publish blog posts cleanly, but several features many modern blogs rely on are not always present by default. This becomes noticeable when a team tries to scale content output and expects the platform to handle discovery and attribution automatically. If those features are missing, a blog can still function, but it loses compounding advantages that help visitors continue reading and help editors manage content with less manual labour.

Two commonly missed capabilities are related posts surfaces and structured author areas. Related posts reduce the “dead end” problem by offering contextual next steps. Author profiles add accountability and expertise signalling, especially for businesses that publish educational content intended to build trust. When these are absent, teams often substitute them with manual internal linking inside paragraphs, which is useful but inconsistent unless it is governed by a publishing checklist.

Friction control.

Blog features are less about decoration and more about reducing friction in content discovery.

Common gaps and what they affect.

Comment sections: without built-in conversation spaces, community building often shifts to external platforms, which can reduce on-site engagement.
Social sharing buttons: missing share prompts can lower distribution, especially for posts intended to travel through social or email forwarding.
Post formats and structured fields: limited variation makes it harder to present content as quotes, galleries, audio notes, or quick updates.

Technical depth: reducing plugin sprawl.

When these missing features are filled by third-party add-ons, the risk becomes plugin sprawl. Each plugin might solve one need, but collectively they can create inconsistent styling, conflicting scripts, and increased maintenance. A better strategy is to map requirements first, then choose a small set of solutions that cover multiple needs cleanly. If a team needs related posts, author profiles, and social sharing, it is often smarter to adopt one coherent approach for blog enhancement rather than three unrelated scripts that each inject their own UI.

It also helps to separate “must-have” features from “nice-to-have” features. For example, related posts that are automatically generated may be essential for a publication-style site, while a smaller business blog might benefit more from a tightly curated “next recommended reading” block that is manually maintained but consistent across cornerstone articles.

Sticky navigation not included.

Sticky navigation keeps key links accessible while a visitor scrolls, which reduces effort on long pages and helps users orient themselves. In Brine, this is not always a native behaviour, which pushes teams toward either living without it or implementing their own solution. The decision matters most for content-heavy sites, product feature pages, and long-form educational posts, where navigation friction can quietly increase bounce.

From a usability standpoint, sticky navigation is a convenience feature that becomes a conversion feature when it improves page flow. When people can jump between sections, return to a category, or reach contact actions without scrolling back to the top, the site feels responsive and modern. Without it, a visitor may abandon the page simply because the next step is inconvenient to find.

UX.

Navigation design influences behaviour, even when the content is strong.

Implementation considerations.

Decide what should remain visible: a full menu, a slim header, or a single call-to-action button.
Test the sticky behaviour on mobile, where screen space is limited and persistent headers can feel intrusive.
Validate that the sticky header does not overlap anchor links or cover section headings when scrolling.

Technical depth: performance and interaction risks.

Sticky navigation is typically achieved through JavaScript or CSS positioning strategies. Both can work, but both carry edge cases. For example, a sticky header can cause layout shift when it toggles between states, which can feel jarring and can also affect performance metrics. Another common issue is compatibility with announcement bars or cookie banners, where multiple stacked fixed elements can overlap and reduce usable space.

Where possible, a light implementation that minimises scroll listeners and avoids constant recalculation tends to behave better. If a plugin is used, it should be evaluated not only for visuals, but for how it handles resizing, different header configurations, and unexpected content injections from other scripts.

Limited customisation options.

Brine offers a set of built-in design settings, but those settings can feel restrictive when a brand needs precise typography control, unique spacing rules, or a highly differentiated layout. The practical issue is not that customisation is impossible, it is that customisation frequently requires stepping outside the template controls and into code, which changes who can safely manage the site day to day.

When a site is trying to express a distinct identity, constraints around type scale, colour schemes, and layout variation can lead to a “template look” that is hard to escape. That can be acceptable for some businesses, but for brands that compete on design sophistication or need to signal premium quality, it may create a mismatch between brand promise and on-site experience.

Consistency.

Customisation is valuable only when it stays consistent and maintainable.

Strategies that avoid fragile design.

Use small, controlled overrides rather than rewriting large sections of the template behaviour.
Document every custom rule so the site remains maintainable if a different editor or developer takes over.
Prioritise changes that improve clarity and conversion, not changes that exist solely to look “different”.

Technical depth: designing for editors.

Any custom layer must consider the editing workflow. If the site depends on custom CSS rules that require specific block sequences or exact class targeting, an editor can unknowingly break the layout by making normal content changes. The more bespoke the customisation becomes, the more the site shifts from “template-managed” to “developer-managed”. In operational terms, that can be acceptable, but it should be an intentional decision, because it changes the cost and speed of publishing.

Performance issues with heavy customisation.

As soon as teams attempt to compensate for missing features by stacking scripts, injected widgets, and extra styling layers, performance becomes the next constraint. Slow sites frustrate users, weaken SEO visibility, and reduce conversion rates, especially on mobile connections. The challenge is that performance problems often do not appear immediately, they appear after a few rounds of incremental additions.

This is where a performance budget mindset helps. Instead of adding features until the site feels “complete”, teams set boundaries around acceptable load time, script weight, and image payload. That forces better decisions about which enhancements genuinely improve the experience and which ones simply add complexity.

Investment.

Every extra enhancement has a cost, even when it is small on its own.

Practical optimisation actions.

Regularly test page speed using tools such as Google PageSpeed Insights and track changes after updates.
Limit heavy plugins and avoid duplicating functionality across multiple scripts.
Optimise images, remove oversized media, and ensure formats are appropriate for the display size.
Audit third-party embeds and remove anything that no longer delivers measurable value.

Technical depth: conflicts and cascading load.

Performance issues are not always caused by a single heavy script. They can come from the interaction of multiple small scripts that each attach scroll listeners, resize observers, or DOM mutation observers. Over time, these can create a cascade where the browser spends more time managing behaviour than rendering content. This is particularly relevant when multiple plugins try to control navigation, animation, or content loading simultaneously.

For teams running larger content libraries or e-commerce catalogues, it can be worth consolidating enhancements into fewer, more intentional components, rather than collecting independent scripts over months. That approach also simplifies troubleshooting, because failures become easier to isolate.

Incompatibility with certain plugins.

Not all plugins are built with Brine’s structure in mind, and incompatibility can present as broken layouts, missing features, or unexpected behaviour on certain pages. This is frustrating because the plugin might work perfectly on another template family, creating confusion about where the problem actually sits. In practice, the more customised the theme is, the more likely it is that assumptions made by a plugin developer will not hold.

A good safeguard is a simple staging environment approach, where changes are tested before they go live. Even without a formal staging site, teams can test on a hidden page or a duplicated template page first, then validate across devices. This reduces the risk of shipping a broken experience to users and protects revenue for stores that rely on stable checkout and product browsing.

Check compatibility notes and recent reviews before installing any plugin.
Test new features on a small subset of pages first, especially pages with complex layouts.
Prefer plugins with clear update history and responsive support channels.

Limited support and documentation.

When a template family has limited official documentation or uneven community coverage, troubleshooting can become slower than it needs to be. For business owners, the true cost is the delay between identifying a problem and deploying a fix, especially when that problem impacts publishing schedules or sales. When guidance is scattered across forums, videos, and partial tutorials, teams can waste hours trying approaches that do not apply to their exact configuration.

To compensate, teams benefit from building their own internal reference notes. Even a simple checklist of what has been customised, which scripts have been added, and where code has been injected can dramatically reduce recovery time when something breaks. That internal clarity can be more valuable than external documentation, because it reflects the site’s reality rather than an idealised setup.

Join relevant communities where Brine users share practical fixes and patterns.
Save reputable tutorials and annotate them with notes about what did or did not apply.
Consider expert assistance for high-impact problems, especially those involving checkout, security, or site-wide scripts.

Brine’s limitations do not automatically make it the wrong choice, but they do require a more deliberate approach to growth. Once the site needs richer navigation, stronger content discovery, or scalable publishing workflows, the template’s defaults should be treated as a starting point, then measured against the real operational needs of the business. From there, the smartest path is usually a controlled set of enhancements, implemented with consistency, tested with discipline, and maintained with the same seriousness as any other business-critical system.

Play section audio

Moving to Squarespace 7.1.

The practical benefits that matter.

When a site owner considers moving to Squarespace 7.1, the decision is rarely about novelty. It is usually about removing limitations that have quietly become expensive, such as slow layout changes, inconsistent template behaviours, and a growing gap between what the business wants to publish and what the platform makes convenient. A successful transition starts by naming the outcomes that actually matter: faster page building, clearer maintenance, stronger mobile presentation, and a site structure that stays manageable as content scales.

One of the biggest operational differences is the unified template system. Instead of picking a template family that dictates which features exist, teams build on a single feature set and then shape the visual layer through styling and layout choices. That reduces “template lock-in” where a redesign unintentionally breaks a feature, or where a feature request forces a costly rebuild. It also helps multi-person teams, because everyone is working with the same baseline tools and the same editing concepts.

The editing experience also changes how pages are produced. With Fluid Engine, layout adjustments tend to become quicker, more visual, and less dependent on workaround blocks. That matters for organisations that publish often, because small adjustments happen constantly: campaign landing pages, seasonal homepage shifts, new service pages, new product launches, or revised navigation. A platform that makes these changes easier reduces the friction that typically pushes updates into “later”, which then becomes “never”.

From a visitor perspective, the upgrade can improve responsive design consistency across devices. The practical goal is not simply that the site looks good on mobile, but that it behaves predictably: sections stack logically, buttons remain tappable, forms stay usable, and readability holds up without requiring duplicate page builds. When this foundation is stable, content teams can focus on clarity and persuasion rather than firefighting layout issues every time a page is updated.

More consistent features across designs, reducing rebuild risk during redesigns.
More flexible page building options for modern layouts and content patterns.
Potential performance improvements when pages are streamlined and assets are managed well.
A clearer long-term path because the platform’s future development is centred here.

Deciding whether timing is right.

Before any migration work starts, a business benefits from treating the move as a platform decision, not a design tweak. The key question is whether the new capabilities remove constraints that are currently slowing down publishing, harming conversion, or making maintenance too costly. If the current website already meets its objectives and updates are rare, delaying may be rational. If the site is actively used to generate leads, sell products, publish knowledge, or support customers, the cost of staying on an older build often increases over time.

For content-heavy organisations, changes to advanced blogging workflows can be a strong reason to move. Publishing is not only about writing posts. It includes structuring categories, linking related content, maintaining consistent formatting, reusing components, and ensuring that older articles remain discoverable. A migration becomes an opportunity to correct messy categories, thin internal linking, and unclear navigation patterns that gradually build up as a site grows.

For commercial sites, the decision often comes down to integration and operational overhead. Better support for third-party integrations can matter when the business relies on email marketing, booking, analytics, automation, or external databases. If a team is already stitching together tools such as Knack, Replit, or Make.com to handle operations, the website should not be the weak link that requires manual effort to keep things in sync. The most useful upgrades are the ones that reduce human effort, reduce error rates, and make the “correct way” the easiest way.

There is also a people factor. A migration can temporarily slow a team down if knowledge is concentrated in one person or if internal documentation is weak. When the new workflows are learned and documented properly, speed usually returns and improves. When training is ignored, teams often revert to unsafe habits: ad-hoc edits, inconsistent components, and rushed publishing that creates technical debt.

Decision framework.

A migration is justified when it removes recurring friction.

A practical framework is to list the top workflow bottlenecks, then decide whether the transition eliminates them or simply replaces them with different problems. If the site owner can name repeat issues such as “layout changes take too long”, “mobile fixes break desktop”, “content is hard to navigate”, or “updates are avoided because the editor feels limiting”, then the move has a clear purpose. If the only reason is “the newer version exists”, the project is likely to drift, because there is no operational win to protect.

Identify the three most frequent site update tasks and how long they currently take.
List the features that cannot be delivered cleanly on the current build.
Estimate the cost of rebuilding content versus the cost of staying put for 12 months.
Decide whether the team can absorb short-term disruption for long-term stability.

Planning for the manual workload.

A common misconception is that moving from Squarespace 7.0 is a simple switch. In practice, the transition frequently requires rebuilding structure and copying content into a new site build, because the underlying architecture differs. That means time, careful sequencing, and a willingness to treat the work as a controlled project rather than an “in-between” task squeezed into spare hours. The complexity increases with the number of pages, the number of products, and the number of custom elements that have been layered on over time.

The safest starting point is a complete content inventory. This is not just a list of pages. It includes navigation items, blog categories, product collections, images, downloadable assets, forms, embedded code, and any “hidden” pages used for campaigns or customer flows. Inventory work often reveals duplicated pages, outdated offers, or legacy content that should be retired instead of migrated. Removing that clutter before rebuilding keeps the new site lighter and easier to maintain.

Once content is inventoried, it becomes easier to rebuild the information architecture. This includes how content is grouped, how visitors move through it, and how search engines interpret it. Migration is an ideal moment to correct vague page titles, inconsistent headings, and confusing menu structures. It is also a good time to decide which pages should act as hubs, which pages should be conversion-focused, and which content exists primarily to educate and attract organic traffic.

A detailed checklist prevents migration chaos. It sets a timeline, clarifies responsibilities, and reduces rework. It also gives teams a way to validate progress without guessing. A “done” page is not just visually complete. It should have correct links, correct metadata, correct mobile layout, and correct tracking. The aim is to avoid a situation where the site looks finished but leaks conversions because a form breaks, a checkout step is missing, or internal links silently point to old URLs.

Catalogue every page, post, and product that must exist after the move.
Rebuild the new structure first, then migrate content into that structure.
Standardise page patterns so future pages are faster to produce.
Back up critical assets and capture screenshots for reference where needed.
Run structured testing before changing any DNS or publishing settings.

Technical depth on SEO safety.

Preserve discoverability with deliberate URL mapping.

Search visibility is often the hidden risk in a rebuild. If URLs change and no 301 redirects are applied, older links break and search engines treat the new pages as unrelated content. That can cause traffic drops that look mysterious because the site “works” for humans but fails for crawlers and long-tail searches. A good migration treats URL mapping as a first-class task, not a final clean-up item.

Metadata also needs intentional handling. Page titles, descriptions, and social sharing fields should be reviewed and migrated as part of SEO metadata hygiene. Businesses often discover that older pages were published with vague titles, duplicated descriptions, or missing headings. A rebuild is a chance to correct that, but it only helps if decisions are consistent. When teams change titles without a strategy, rankings can fluctuate because the topic focus becomes unclear.

Finally, pages should avoid conflicting duplicates. When similar content exists in multiple places, search engines can struggle to decide which page is authoritative. In more complex sites, using canonical URLs appropriately and reducing near-duplicate pages can stabilise performance. The goal is not to “game” search engines, but to remove ambiguity so the best page earns and keeps the ranking.

Execution, testing, and team readiness.

Once rebuilding begins, the work benefits from being treated as quality assurance, not just publishing. A site can look correct and still fail on basics such as navigation depth, form handling, or mobile tap targets. Testing should be systematic: key pages, key flows, and key devices. That includes confirmation emails, payment steps, embedded calendars, newsletter signups, and any integrations that pass data into external systems.

Many teams reduce risk by building and validating on a staging site first. The main advantage is psychological as well as technical: the team can iterate without fear of breaking the live website. It also allows parallel work, where one person rebuilds templates and global styling while another migrates content and checks links. A staging approach makes it easier to identify missing assets and to verify that global elements such as headers, footers, and collection layouts behave consistently.

Accessibility and clarity should be included in the testing plan. Practical accessibility checks include readable contrast, sensible heading order, keyboard navigation where applicable, and form labels that make sense. These are not just compliance concerns. They improve usability for everyone, especially on mobile devices and slower connections, and they often reduce abandonment on forms and checkout flows.

Performance should be measured, not assumed. Capturing an analytics baseline before launch makes it possible to judge whether the migration improved outcomes. Metrics might include conversion rate, bounce rate, time on page, form completion rate, and key landing page behaviour. It can also be useful to monitor Core Web Vitals once, then treat the results as a guide for asset optimisation and layout simplification rather than chasing perfect scores at the expense of content clarity.

Test navigation and internal links across the full site, not just key pages.
Validate forms, automations, and email deliverability for every conversion path.
Check mobile layouts on multiple devices and screen sizes, including older phones.
Verify image compression and loading behaviour to avoid slow pages.
Confirm tracking and measurement for marketing, campaigns, and commerce flows.

Future-proofing beyond the rebuild.

Long-term stability is one of the main arguments for moving, because future updates and improvements increasingly concentrate on future support for the newer architecture. Even when older sites continue to operate, the practical issue is that improvements arrive elsewhere first. For businesses that depend on continuous iteration, staying aligned with the platform’s direction reduces uncertainty and avoids rushed migrations later under pressure.

Security is another often overlooked factor. Remaining current reduces exposure to issues that are fixed through security updates and platform-level improvements. While Squarespace handles much of the underlying maintenance, the site owner is still responsible for how content and integrations behave. A rebuild is a chance to remove obsolete embeds, minimise excessive scripts, and adopt cleaner patterns that are easier to manage and audit.

Operationally, the biggest win is building a site that supports repeatable publishing. That means documented patterns, shared rules, and a clear content lifecycle. Strong operational governance is not corporate theatre; it is the difference between a site that improves each month and a site that slowly degrades as multiple people make uncoordinated changes. Governance can be simple: defined page templates, rules for headings, rules for image sizes, and a small checklist that is followed before publishing.

For teams that want to reduce ongoing workload, selective automation can be layered in after the migration is stable. On Squarespace, a well-curated plugin approach can improve navigation and content behaviour without turning the site into an unstable experiment. Where it fits naturally, tools such as Cx+ can be used to add consistent UI patterns across pages, while keeping the underlying site structure clean. In higher-support contexts, CORE can also be relevant when the goal is to reduce repetitive enquiry handling by turning structured site knowledge into on-page answers, but only when the site’s content is already organised enough to be a reliable knowledge source.

A well-executed move is not a finish line. It is a foundation that makes the next improvements easier: better content structure, clearer messaging, faster publishing, and more reliable measurement. From there, the next logical step is usually to refine page patterns and internal linking so that content discovery improves naturally, which sets up stronger performance for future campaigns and new sections without another rebuild.

Frequently Asked Questions.

What are the main challenges when migrating from Squarespace 7.0 to 7.1?

Key challenges include managing legacy systems, ensuring content parity, and adapting to new layout behaviours in 7.1.

How can I maintain SEO during the migration process?

To maintain SEO, carefully plan URL structures and implement 301 redirects for any changed URLs.

What should I consider when choosing between refactoring or rebuilding my site?

Evaluate the current performance, user feedback, and the long-term vision for your site to make an informed decision.

How do I ensure a smooth transition to Squarespace 7.1?

Implement thorough testing and establish a rollback plan to address any issues that arise during migration.

What are the benefits of using the Brine template family?

The Brine template family offers extensive layout options, responsive design, and a variety of built-in features for customization.

How can I manage the risks associated with customizations?

Limit custom code to essential changes, document all modifications, and regularly review third-party integrations for stability.

What are the implications of not migrating to 7.1?

Staying on 7.0 may limit access to new features, updates, and support, potentially leaving your site vulnerable to security issues.

How can I gather user feedback during the migration process?

Engage users in testing phases and solicit their feedback to identify pain points and improve the overall experience.

What should I do if I encounter issues during migration?

Establish a contingency plan that includes a rollback strategy and clear communication with users about any problems.

How can I stay informed about industry trends and best practices?

Regularly research market trends, follow industry publications, and engage with online communities to gather insights.

References

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

Big Cat Creative. (2021, May 19). Why Brine is the best Squarespace 7.0 template & when you shouldn't use it! Big Cat Creative. https://www.bigcatcreative.com/blog/best-squarespace-template
Squarespace. (2025, August 20). Brine template family. Squarespace Support. https://support.squarespace.com/hc/en-us/articles/212512738-Brine-template-family
Read Creative, R. (2022, April 12). How to edit a Squarespace 7.0 (Brine family) website. Rebekah Read Creative. https://rebekahreadcreative.com/how-to-edit-a-squarespace-7-0-brine-family-website/
Squarespace Forum. (2022, May 19). Switching from 7.0 to 7.1. Squarespace Forum. https://forum.squarespace.com/topic/220292-switching-from-70-to-71/
Taylar, L. (2021, January 31). Why Brine is the best Squarespace 7.0 template family. Lauren Taylar. https://laurentaylar.com/blog/brine-best-squarespace-template
Dekle, K. (2020, February 1). The Brine Family are still the best Squarespace 7.0 templates. Launch the Damn Thing. https://www.launchthedamnthing.com/blog/squarespace-brine-best-template
Brunton, P. (2018, September 4). What is the best Squarespace template? Brine. Here's why. Paige Brunton. https://www.paigebrunton.com/blog/best-squarespace-template-brine
SQSPThemes. (2024, August 9). What Squarespace version is Brine? SQSPThemes. https://www.sqspthemes.com/squarespace-faqs/what-squarespace-version-is-brine?srsltid=AfmBOoqgcseVh44jZnX3WES-1c5VId0Vm_v1cUHVfSogds5sRfC2EtQn
Squarespace Forum. (2023, August 3). Which 7.1 template is closest to 7.0 Brine family Margot template. Squarespace Forum. https://forum.squarespace.com/topic/249254-which-71-template-is-closest-to-70-brine-family-margot-template/
Zooby Media. (2020, August 20). Why Brine Family Is Still My Jam. Zooby Media. https://www.zoobymedia.com/blog/brine-is-my-jam

Key components mentioned

This lecture referenced a range of named technologies, systems, standards bodies, and platforms that collectively map how modern web experiences are built, delivered, measured, and governed. The list below is included as a transparency index of the specific items mentioned.

ProjektID solutions and learning: