A guide to using reusable blocks

What a block actually is

A block is a feature that's already built: designed, coded and tested on real sites before it ever reaches yours. Blogs, pricing tables, galleries, contact forms, login areas, hero sections — each one lives in a shared library that every Claude CMS site can draw on. The quiet superpower: you never have to paste anything in or explain what a block is. Claude simply knows what's on the shelf, the same way it knows your pages and brand colours.

Blocks arrive wired to your site — your colours, your fonts, your navigation — because Claude adapts them on the way in. The difference between a block and asking Claude to build from scratch is the difference between fitting a tested part and machining a new one: both work, but one has already survived contact with real websites.

Step 1 — See what's on the shelf

Say"List latest blocks"

Claude lists the current library with a short description of each entry — what it does, what it needs, where it works best. The library grows over time, so it's worth re-asking now and then; new blocks appear for every connected site automatically, with no update to install.

Step 2 — Deploy the ones you need

Say"Deploy the blog and pricing table blocks"

That's the whole process. Claude takes the tested code, restyles it to match your site, and wires it into your pages and navigation. A feature that would be an afternoon of plugin-hunting elsewhere is one message here — and because the underlying code is proven, you skip the first-draft debugging too. Anything the library doesn't cover, describe in your own words and Claude builds it custom.

Step 3 — Save your own

New: the shelf now works both ways. When you and Claude build something worth keeping — a component you'll reuse, a rule about how your site should be written, your brand palette — save it:

Say"Save this as a policy block"

Saved blocks belong to your site, not to the shared library and not to one conversation. From the next session onwards, Claude simply remembers them — every session, every time, without being reminded. Anyone else with access to your site shares the same set, so a rule saved once holds for the whole team.

There are four kinds of block you can save, and the kind tells Claude how to treat it:

Type	What it's for
component	Reusable page parts — a call-to-action strip, a testimonial card, a footer signup. Claude drops them into pages on request, styled as saved.
policy	Standing rules — "product names are always italicised", "never mention prices in blog posts". Claude follows them without being asked.
brand	Your visual identity — colours, fonts, logo usage, tagline. One saved brand block ends the era of re-explaining your palette.
recipe	Step-by-step procedures — "how we publish a case study". Claude runs the steps in order whenever you invoke it.

A few examples of the pattern in the wild:

"Save our colour scheme and fonts as a brand block" — every future page matches, automatically.
"Save a policy block: blog images always get alt text describing the scene, never the filename."
"That testimonial section came out great — save it as a component block called customer-praise."

Why saving blocks pays off

Shared with your colleagues

Blocks belong to the site, not to one person's chat. Save a rule or component once and everyone working on the site builds with the same intel — no forwarded notes, no drift.

Recurring tasks, one prompt

Code and procedures you use again and again stay on hand. "Add the customer-praise section" or "run the weekly promo recipe" works first time, every time — no digging through old conversations.

Your intel, portable

Saved blocks live with your website — not locked inside any single AI's history. If you choose, the same intel can be shared with other platforms and AI models you connect.

Centralised oversight

Everything you've taught Claude about your site sits in one reviewable list — easy to update, retire or audit, so you always know exactly what your AI is working from.

Step 4 — Manage what you've saved

Say"List my saved blocks"

Claude shows everything saved for the site — and from there, editing and removing are exactly what you'd expect: "update the brand block, the accent colour is now teal" or "delete the customer-praise block". Changes take effect from the next session. If you want to stage something without switching it on, ask Claude to save it as a draft — it's stored but stays silent until you activate it.

The house rules

Names are unique. Every saved block gets a short name (a "slug"), and it can't reuse a name from the shared library — so your saved blocks can never accidentally override a library block. If there's a clash, Claude tells you and suggests an alternative.
Keep them lean. Saved blocks are part of what Claude keeps in mind while working on your site, so there's a sensible size limit per block (16 KB) and a cap of 50 per site. If you hit either, Claude says so plainly rather than quietly trimming.
Your site only. Saved blocks never leak to other sites or other customers — they're scoped to the site they were saved on, full stop.

The short version

Three prompts cover the whole feature: list latest blocks to see the shared shelf, deploy the … block to use it, and save this as a … block to teach Claude something permanent about your site. The library keeps you from rebuilding what's already proven; saved blocks keep you from re-explaining what's already decided.

← Back to News