- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Most libraries copy rather than reference, so a later fix reaches only the page you were looking at — and everyone assumes otherwise.
Save section to library: reuse that does not drift
Saving a section to a reusable library is the difference between building a page and assembling one. An agency that has done the work once — a hero that converts, a testimonial block that looks right, a form section that validates properly — should not be rebuilding it for the next client.
The catch is that most libraries are a copy mechanism rather than a reference. What you save is duplicated into each page that uses it, so a fix made later reaches only the page you were looking at. The library then becomes a collection of things that were correct on the day they were saved, which is worse than useless because everyone assumes otherwise.
Establish which kind of library you have
| Behaviour | What it means | How to work with it |
|---|---|---|
| Copy on insert | Each use is independent; later edits do not propagate | Treat the library as a starting point and version it deliberately |
| Linked or global | Edits propagate to every page using it | Powerful and dangerous — one careless change reaches everything |
| Copy, with an update prompt | You are told when the source changed | The best of both, if anyone acts on the prompt |
Test which you have before relying on either assumption: save a section, use it on two pages, change the saved version, and look at both. Five minutes spent on that experiment prevents the confident wrong belief that causes most library problems.
What makes a section worth saving
- It is genuinely repeated. Saving something used once creates maintenance for no benefit.
- It is finished. A section still being argued about should not be propagated to five client sites.
- It has no client-specific content baked in. A hero with one client’s headline is not a reusable hero; it is that client’s hero.
- It behaves correctly at every width. A section that only works on a desktop will fail identically everywhere it lands — check it against how a phone stacks your columns before saving, not after.
- It carries no hard-coded identifiers. Tracking IDs, account references and absolute URLs are the things that quietly send one client’s data somewhere else.
That last point deserves emphasis. A saved section carrying an analytics identifier or a specific domain reproduces it faithfully into every account it is inserted into, which is a version of the problem what moves and what breaks on import describes and one of the hardest to notice because everything appears to work.
Naming and organisation, which sound trivial and are not
A library nobody can search is a library nobody uses, and people rebuild instead. Name sections by what they are and where they belong — “Hero, image left, single CTA” rather than “Hero 3 final v2” — and include the version or date if your library copies on insert, so that a page built last quarter can be identified as using an older one.
Keep the count down. A library of two hundred sections is a search problem; a library of twenty that are actually good is a tool. Delete what is superseded, and be deliberate about the difference between a variant worth keeping and a one-off that should never have been saved.
Where several people contribute, write down who may add to the shared library and what has to be true before something goes in. That is an ordinary piece of process documentation, in the form structure, owners and exceptions describes, and it is what keeps a shared library from becoming a shared mess.
Living with a copy-on-insert library
Since a later fix does not propagate, you need a way to find the pages that need it. Keeping a simple index of which client sites use which sections — the kind of record a durable record outside the platform supports — turns “we should update that everywhere” from an aspiration into a list.
When you do fix something, fix it at the source first and then work through the list, rather than patching pages as complaints arrive. The alternative produces a set of sites that each differ from the library and from each other, which is the state most agencies are actually in.
Where the platform offers protection for assets that must not be edited downstream, use it. Marking the parts a client should not change, as protected snapshot assets describes, prevents the other half of the drift problem: a section edited in place until it no longer resembles what you deployed.
What tends to be wrong the first time a saved section lands
Assets that did not travel. Images referenced by URL rather than embedded may not resolve in the destination account, leaving gaps that only appear on the live page.
Fonts and colours from a different theme. A section styled against one account’s palette inherits the destination’s, and the result is occasionally unreadable rather than merely different.
Behaviour that depended on page-level code. A section relying on something added through code in the page header works where it was built and nowhere else. Sections should be self-contained or clearly documented as not being so.
Forms that lost their destination. A saved form section usually keeps its fields and loses where the submission goes, which produces enquiries that vanish. Check the destination and the validation rules separately — required-field validation is the part most often missing.
Visibility rules and image behaviour. Per-device rules from hiding an element on mobile, collapsed panels as in the accordion FAQ element, and the loading strategy described in lazy loading funnel images all travel with the section, and any of them may be wrong for the new context.
The habit that makes it worthwhile
Insert, then check the page as a visitor on a phone before moving on. A library saves the building time, not the checking time, and the temptation is to treat a saved section as verified because it was verified once somewhere else.
For an agency reselling under its own brand, this matters more than it looks: every client site assembled from the same library is a version of your product, and the drift between them is visible to anyone who sees two of them — the consistency obligation described in a white-label arrangement. A small, well-named, genuinely current library is one of the few things that gets easier the longer you run it.
See also: Global Sections Page Builder: Propagation and Overrides
Frequently Asked Questions
Does editing a saved section update the pages that already use it?
It depends on the platform, and you should test rather than assume. Save a section, use it on two pages, change the saved version and look at both. Many libraries copy on insert, so a later fix reaches only the page you were looking at.
What should not be saved to a library?
Anything used once, anything still being argued about, anything with a specific client’s content baked into it, and anything carrying hard-coded identifiers — tracking IDs, account references or absolute URLs, which reproduce faithfully into every account the section lands in.
How should sections be named?
By what they are and where they belong — ‘Hero, image left, single CTA’ rather than ‘Hero 3 final v2’. Include a version or date where the library copies on insert, so a page built earlier can be identified as using an older copy.
How do you keep a copy-on-insert library from drifting?
Keep an index of which sites use which sections, so a fix becomes a list rather than an aspiration. Fix at the source first and then work through the list, rather than patching pages as complaints arrive.
What is usually wrong the first time a saved section is inserted?
Images referenced by URL that do not resolve in the new account, fonts and colours inherited from a different theme, behaviour that depended on page-level code, and forms that kept their fields but lost the destination the submission was going to.
How large should a section library be?
Small enough to search. Two hundred sections is a search problem; twenty good ones is a tool. Delete what is superseded, and be deliberate about the difference between a variant worth keeping and a one-off that should not have been saved.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.