CMS collections: separating the site from its content

Thursday, 2:40 p.m. The marketing lead of a service chain with twenty-two branches opens the page editor to add a newly opened location to the website. The branch list is twenty-two cards hand-built inside the page; adding the twenty-third means copying a card, rewriting the text and slotting it in without breaking the order. That same week another branch changed its phone number, and because the number is typed separately on the home page, the contact page and a regional landing page, it has to be fixed in three places. The whole thing looked like a twenty-minute update. It takes three hours, and one page still shows the old number. The numbers are illustrative; the situation is not.

This article is about the distinction that turns those three hours back into twenty minutes: pulling content out of the page and holding it separately, under its own field schema. We will work through it in order — why a content update turns into a design job, what belongs in a collection and what stays on a page, how to design the schema, where the data comes from, how list and detail pages come out of one layout, how a missing translation is kept out of production, how a change goes live and how it is rolled back, where a collection record differs from a CRM record, how search engines see these pages, which measurements prove the split worked, and in what order to build the first collection.

Why does a content update turn into a design job?

Because the content lives inside the page. When a service card's title, summary and price band are typed into the boxes of a section, that text stops being data and becomes a piece of layout. To change it you have to open the layout, find the right box, and get out without nudging something else. With ten cards that is tolerable. With forty cards, three languages and the same list repeated on two pages, it stops being tolerable.

The second cost is the invisible one: nobody knows how many copies of a fact exist. If a branch phone number is typed on three pages, the knowledge of which three pages lives in one person's head — and leaves with them. After a while the site becomes a pile of text nobody can inventory, and the answer to “did we update it?” is only available by checking page by page.

The fix is easy to name: define the content once as structured records, and leave the page with a single instruction — show these records in this layout. You can do that with a separate headless system or inside the platform where the site already lives. The trade-off is integration cost against independence, and the criteria for choosing between a native capability and a third-party tool apply here too. At small and mid scale the “same place” side usually wins: one less system, one less login, one less publishing flow.

What belongs in a collection and what stays on the page?

There is one reliable signal: does it repeat in the same shape? Services, branches, team members, products, testimonials, open roles, blog posts, events — all of them carry identical fields with different values. Those are collections. The home page hero, the about narrative or a one-off campaign landing page are single instances, and forcing them into a schema only creates work.

The second signal is update frequency and ownership. Copy that changes once a year and belongs to marketing can sit on a page. A list that changes several times a week and comes from operations should not, because whoever has to open the page editor becomes the bottleneck. The split matters even more if the same content feeds other channels: structured records are the substrate of turning one piece of content into many, and when the source text is buried in a layout, reuse degrades into copy-paste.

Content	Repetition	Who updates it	Where it belongs
Branch details	Same fields per branch	Operations	Collection
Service cards	Same fields per service	Marketing	Collection
Product catalogue	Hundreds of records, external source	ERP / commerce team	Collection, fed externally
Campaign landing page	One-off, short-lived	Marketing	Page
About narrative	One-off, rarely changes	Leadership	Page

How do you design a schema that still holds six months later?

The first rule is that a field answers exactly one question. Open a single free-text “address” field and, six months later when you want to filter by city, you are left with strings to parse. Split into city, district, street address and postcode, and the list filter, the map link and the structured data all become possible without extra work.

The second rule is to keep appearance out of the schema. Fields like “card colour” or “show in bold” belong to the layout, not the content; once they are in the schema, a design change means editing hundreds of records. The schema holds information only: name, summary, long text, image, category, sort order, publication state.

The third rule is to be stingy with required fields. A schema that makes everything mandatory makes it impossible to park a half-finished record as a draft, and people start filling empty fields with a full stop. Make the fields that appear in the list — name, summary, image — required, and leave the rest optional. In Rocketly this structure is built with CMS Collections: repeating content such as services, branches, team members or products is defined once with a field schema, and the page only carries a collection block, so the list fills itself and updating content no longer means redesigning the page.

Where does the content come from: manual entry, ERP or a spreadsheet?

For small collections, manual entry is the cheapest path. Twenty branches, twelve services or thirty team members are entered once and edited by hand a few times a month; building automation for that is an investment that never pays itself back.

For a large collection whose authority sits in another system, the logic reverses. If SKUs, price tiers and technical specifications are already maintained inside an ERP, every record copied into the site by hand will drift eventually. The rule for such a collection is blunt: the source system writes, the collection reads, and the fields on the site are not hand-edited.

For the cases in between, a spreadsheet is a practical bridge. Marketing prepares records where they are comfortable and a sync job moves the file into the collection on a schedule; the setup rules for syncing a spreadsheet with a system of record hold here as well: one direction of flow, fixed column headers, and a stable identifier per row. Without an identifier every import creates duplicates.

When several sources are involved — products from the ERP, stock from a marketplace, descriptions from a file — a single orchestration layer is easier to run than three separate jobs, and that threshold is exactly where integration platforms start to earn their place.

Whichever route you take, respect the limits of the source system: a nightly bulk pull, small deltas during the day, and increasing back-off on retries. Ignore rate limits and quota management and the first large import will spend the day being rejected.

How do list and detail pages come out of a single layout?

This is where a collection pays for itself. The list page is one layout: how many columns, which fields show, what the sort order is, whether there is a filter. The detail page is another: title, image, long text, contact block, related records. You build the two layouts once, and even if the record count reaches a hundred, the number of pages you maintain is still two.

Three details save the work in practice. First, the empty state: what does the list show when a category has no records? Second, the sort rule: manual order, date, or alphabetical? Third, length tolerance: does the layout break when a card title wraps to two lines? A list published without testing those three will break on the first real batch of data.

The same logic extends past customer-facing pages. In a catalogue opened to dealers, the product list comes from a collection while the ordering flow is a separate application; when you build a dealer ordering portal, leaving content to the collection and transactions to the app lets the two evolve independently. In Rocketly the page skeleton is assembled in the Site Studio section editor: sections such as hero, feature list, FAQ and form are ordered, each gets a layout variant, and critical sections are locked against unauthorised editing.

How do you keep a missing translation out of a multilingual collection?

The most common mistake in multilingual content is storing a translation as a copy of the record. Create two separate records and one day one of them gets updated while the other does not, and the two languages start describing different realities. The correct shape is a single record with language-dependent fields: identifier, category and image shared; title, summary and body per language.

The second question is what a missing translation should do. There are three options: hide the record in that language, fall back to the primary language, or block publication. For corporate sites the safest default is hiding — a half-translated card leaves a worse impression than a card that is not there.

Tracking that by hand is unreliable, because the missing field is never where anyone is looking on publication day. In Rocketly, Pre-publish audit takes the job over: a missing page title, a missing description or text left incomplete in one language is listed as a finding, and a version cannot be prepared until blocking findings are cleared. A half-finished translation never reaches the publish button.

How does a collection change go live, and how is it rolled back?

There is a tension here. The point of separating content from the page is faster updates — but if every record edit is live instantly, so is a mistyped price band or a half-written description. The resolution is that editing and publishing are not the same moment.

In Rocketly what goes live is not your draft but a frozen copy of that moment: under Versions and frozen snapshots the version is numbered and its content never changes again, so you can keep working on the draft while visitors keep seeing the previous version until someone presses publish. If a change goes wrong, One-click rollback returns to an earlier version and also clears any pending scheduled publish, so two decisions cannot overwrite each other. To restrict who may publish at all, a Review and approval policy defines which roles must approve before a version can go out.

Fed collections raise one more question: if the source system and the site record change at the same time, which one wins? That is a classic conflict problem, and left unwritten it turns into silent data loss; the most robust approach to deciding who wins in a two-way sync is to define the rule per field rather than per collection. Price always from the ERP, marketing copy always from the site.

Does a collection record replace a CRM record?

It does not, and missing that line is where the expensive mistakes happen. A collection is public content that exists to be read: a service description, a branch address, a product specification. A CRM record is private, belongs to a person and carries a process: lead, deal, quote, appointment. The first is shown to everyone, the second is shown according to permission.

The practical consequence is that a website form should not write straight into the CRM. In Rocketly, under Forms connect to the CRM, a submission first lands in a site-specific submission inbox, is mapped field by field into a workflow, and only then creates a record — and you can run a dry run before going live to confirm the mapping. Which record types an app may touch is chosen one by one through CRM data scope, and scope changes are written to the audit log. If an external service feeds the collection, restrict its access with the same discipline: the guidance on scoping and storing API keys applies to content feeds too, because when the content key and the data key are the same key, one leak opens both.

When the need to unify customer behaviour across channels grows, the question moves to a different system, and the boundary is exactly where a customer data platform differs from a CRM. But site content never needs that debate: a collection is for content, not for people data.

How do search engines see pages generated from a collection?

Detail pages generated from a collection can be the most valuable pages you own: each one maps to a specific service, branch or product and answers a narrow intent. Getting that value takes three things. First, the page must be rendered on the server, so the title and description are in the HTML before the browser runs any JavaScript. Second, each record needs its own stable address. Third, the title and description should be derived from record fields.

The third point looks small but carries the whole advantage: define a pattern such as “{name} — {city} branch” and a hundred records produce a hundred distinct titles automatically. In Rocketly, Search engine visibility means public pages are server-rendered with title, description, canonical, hreflang and structured data inside the HTML; every published site gets its own sitemap.xml and robots.txt, and indexing preference is set per page.

One warning: because a collection makes pages cheap, it also makes thin pages cheap. Two hundred records consisting of a name and two sentences are two hundred weak pages. The test is simple — if a record's own page carries no fact specific to that record, keep it in the list and do not give it a page.

Which measurements tell you the split actually worked?

The first measure is time: how long a content change takes from request to live. Note it roughly for a week before you make the split, and repeat the same measurement afterwards. The second is people dependency: how many colleagues can make the change? Going from one person to three is proof that you built an editing surface that requires no design knowledge.

The third measure is the outcome itself. In Rocketly, Daily site metrics accumulates page views, form starts, form submissions, abandonment and page depth by day, broken down by device and traffic source, so you can read which detail page actually converts. After building a collection, the questions to ask are: what share of list-page visitors reach a detail page, and which detail pages are never seen at all? Records nobody sees are either in the wrong place in the list or should never have had a page.

Where to start: a two-week order of work for the first collection

Week one is inventory. List the repeating content on the site, and for each item write down how many copies exist and who updates it. Then pick the single collection that hurts most — usually branches or services. Draft the field schema on paper, fill five sample records by hand, and see whether the schema cracks on the fifth; if it cracks, a field is missing.

Week two is layout. Build the list and detail layouts, test the empty state and a long title, choose the multilingual behaviour, then migrate the records. When the migration is done, delete the old hand-built section; if two sources sit side by side, the argument about which one is correct will run for six months. If you would rather not make template and theme decisions from scratch, Start from a template gives you ready-made layouts, and Brand kits hold colour, typeface and logo decisions in one place while showing which sites a change would affect before you make it.

Week three has no build work, only measurement. At the end of the first month, look again at update time and the number of people who can edit. If you want to try the sequence on your own site, open a free Rocketly account and build the first collection around a single service list.

FAQ

Do I need to know how to code to build a collection?

No. Defining a field schema, entering records and placing a collection block on a page are configuration tasks. Code enters the picture only for a very specific presentation or a custom feed from an external system.

Does moving an existing site to collections mean rebuilding it?

No, and it does not have to happen at once. Start with one list, let that list come from a collection, and leave the rest of the site as it is. The gain is visible after the first migration.

Can I use the same collection on more than one page?

Yes, and that is the point. The same branch collection can appear as a map list on the contact page and a filtered card list on a regional page; because there is one record, one update applies in both places.

Will the list page slow down as the record count grows?

That depends on pagination and filtering. Rather than showing hundreds of records on one page, split by category, show a fixed number per page, and fetch only the fields the list actually displays.