Every CMS I've used eventually turns into a negotiation with its plugin list. One plugin does sitemaps, another does schema, another fights them both over canonical tags, and the site you actually wanted is somewhere underneath. SpicaCMS is my attempt to stop negotiating. It's a single-site, SEO-first CMS runtime with no plugins at all, and it's live. It's also still in active development, and I'd rather say that up front than let you find out from a changelog.
The problem I kept hitting
I run a lot of content sites. Reviews, directories, guides, the odd magazine. The setup was always the same: pick a CMS, install a stack of plugins, then spend evenings figuring out why the sitemap forgot a chunk of the pages or why several plugins all decided to print JSON-LD.
The SEO basics weren't the hard part. The hard part was that they lived in someone else's add-on, configured in a settings screen I'd forget about, and broke quietly when something updated. So I built the boring parts into the runtime and threw away the idea of plugins entirely.
If every site needs it, it isn't a plugin. It's the product.
— me, after untangling one canonical tag too many
What SpicaCMS actually is
Each deployment runs exactly one site. The backend is Django, the frontend is Next.js, and editors work in a staff Control Panel that I've tried hard to keep fast and plain. There's no marketplace, no theme store and no mystery code from strangers.
One site per deployment sounds like a limitation, and it is one. It's also the reason I can reason about a site without wondering which tenant broke what. If you want to run lots of sites, you run lots of deployments. Dull, predictable, debuggable.
Template packs are data models, not skins
This is the part I care about most. A template pack in SpicaCMS isn't a coat of paint. It's a full data model for a type of site, with the fields, pages and structured data that type actually needs. A job board needs different fields from a travel guide, and pretending otherwise is how you end up stuffing salary ranges into a custom field called extra_3.
The packs today cover:
- Blogs and magazines
- Knowledge bases
- Affiliate reviews and software alternatives
- Directories
- Real estate and jobs
- Events
- Travel guides with itineraries and maps
SEO that ships with the runtime
| Concern | How SpicaCMS handles it |
|---|---|
| Structured data | Validated schema.org JSON-LD per page type |
| Sitemaps | Multi-index sitemaps generated by the runtime |
| Languages | Automatic hreflang |
| Changed slugs | Automatic 301 redirects |
| Extensions | None. No plugins by design |
What happens when an editor renames a page
- The editor changes the slug in the Control Panel and saves.
- The runtime records the old path and issues a 301 to the new one.
- The sitemap picks up the new URL instead of the old one.
- Structured data and hreflang follow the page instead of pointing at a ghost.
- Nobody has to remember to install a redirect plugin first.
Self-host or not. The Community edition is free and open-source per site if you want to run it yourself. If you'd rather not babysit servers, there's a managed cloud option. Pricing lives on the site and I'm not going to paste it into an essay that will outlive it.
What's honestly not done
SpicaCMS is live, but the portfolio still lists it as active development, and that's accurate. Template packs and the Control Panel are still changing. If you need a frozen API surface that won't move for two years, this isn't that yet.
There's also a companion SEO tool, SpicaSEO, that's meant to work alongside it. SpicaSEO is in development. Please don't pick a CMS on the strength of a tool that isn't finished; I wouldn't.
And the no-plugins rule cuts both ways. If your site depends on some niche integration, the answer today is probably no, or not yet. I'd rather say no than ship an extension system I then have to support forever.
Is SpicaCMS a fit for you?
- You run content sites where search traffic matters
- Your site matches one of the template pack types
- You're fine with one site per deployment
- You don't need a plugin ecosystem
- You can live with a product that's still evolving
Note: Why Django and Next.js. Django gives me a solid admin-friendly backend and data modelling I trust. Next.js renders the public pages. Splitting them means the editing side and the reading side can each be boring in their own way, which is the highest compliment I give software.
Where to look
If any of this sounds like the CMS you wished you had a few plugin conflicts ago, the details are at spicacms.com. The rest of what I'm building is on spicanet.net/products, and I'm happy to hear what's missing from your side.
SpicaCMS: spicacms.com. Originally published on spicanet.dev.
Top comments (0)