Forem: BuildWithTall

The SEO-era CMS is dead. Here's what comes next.

BuildWithTall — Mon, 06 Apr 2026 15:24:22 +0000

Search visibility still matters. But the next advantage is making content structured, attributable, and maintainable.

WordPress became the dominant CMS by solving a real problem: making it easy to publish crawlable, keyword-targetable content. Install Yoast, fill in the meta description, hit publish. Google does the rest. That playbook still works — but it's no longer sufficient.

When someone asks ChatGPT, Perplexity, or Claude a question, the answer isn't a list of ten blue links. It's a synthesised response drawn from sources that were readable, attributable, and trustworthy. Your content either makes it into that synthesis — or it doesn't.

The right question isn't "how do we optimise for AI?" That framing chases the wrong things. The better question is: what does it mean for content to be genuinely legible in 2025?

What "legible" actually means

Legibility isn't a new concept. It's what good semantic HTML has always been about — content that's meaningful to the medium it travels through, not just to the human reading it in a browser.

In the SEO era, legibility meant clean URLs, descriptive title tags, heading hierarchy, and internal links. These still matter. But AI systems extract meaning differently than crawlers do. They look for:

Structured data — not just as an SEO signal, but as a machine-readable contract about what this content actually is
Attributability — who wrote this, when, and what makes them credible
Extractability — does a paragraph answer a specific question, or does it meander?
Freshness signals — when was this last verified? Is it still accurate?

A CMS that makes these easy to produce by default — not via plugins bolted on afterward — has a structural advantage in the current landscape.

What to be careful about

Before going further, some of the "AI-optimised CMS" conversation is moving faster than the evidence warrants. A few claims worth scrutinising:

"llms.txt is the new robots.txt" is an interesting emerging convention, but not yet a stable enough foundation to build a product strategy around. Worth supporting if it matures. Not a core thesis today.

"AI tools consume content via APIs, not browsers" is overstated. Many AI systems still rely on crawlable, rendered HTML. API-first is genuinely valuable — but clean public HTML remains equally critical.

"Structured content will be cited by AI more reliably" involves factors well outside any CMS's control. The honest version: structured, well-attributed content is more extractable and more likely to survive summarisation intact. That's still a meaningful claim — but it's not a guarantee.

These cautions matter because the worst version of this thesis is a CMS that chases AI hype instead of building something durable. The best version focuses on what has always mattered: clear, structured, trustworthy content. AI legibility is a consequence of doing those things well, not a separate goal.

Content maintenance is the missed layer

Almost every CMS treats content creation as the primary workflow. Content maintenance — reviewing, updating, verifying — is an afterthought.

AI systems are exposing this gap. Stale content isn't just an SEO liability anymore. It's a trust signal. A well-maintained corpus that reflects current reality is more useful as a source than a site that published 400 posts in 2021 and stopped updating.

A CMS that surfaces stale content proactively — "this article was last reviewed 18 months ago, here are five that haven't been touched in two years" — is doing something valuable that almost nobody has built well yet.

The winning CMS in this era makes content maintenance as easy as content creation. That's a smaller, more tractable problem than "building an AI CMS" — and a more durable one.

What this means for TallCMS

We're building TallCMS around the idea that content should be legible to humans, search engines, and AI systems alike. Concretely, that means:

Schema-first content types. When you add an FAQ block, a how-to guide, or a product page, the appropriate structured data is generated automatically. Schema.org markup is a primitive, not a plugin.
First-class attribution and review metadata. Author credentialing, last-reviewed dates, and expert attribution are real fields in the editor — not custom meta buried in settings.
Maintenance workflows over AI gimmicks. Stale content detection, review reminders, and freshness indicators built into the editorial experience.

TallCMS's block system already stores content as typed, structured data — not WYSIWYG blobs. The leap from structured blocks to structured data output is small. That's a genuine architectural advantage, not a marketing claim.

What we're deliberately not doing

Saying no is as important as saying yes. Here's what we're choosing not to build:

AI content generation in the editor. We're not adding a "write this for me" button. AI-assisted quality — flagging thin content, suggesting structure — is useful. AI-replacing-authorship is not a CMS feature, it's a crutch.
Headless-only architecture. TallCMS is full-stack by default: admin panel, frontend, themes. The API is strong and well-documented for when you need it. But we're not abandoning the integrated experience to chase a trend.
Chasing llms.txt as a centrepiece. We'll support it if the convention stabilises. We're not building our product story around it.
Promising AI citeability. We can make content more extractable, more structured, and more trustworthy. We can't control what any AI system decides to surface. We won't pretend otherwise.

What to look for in any CMS

Regardless of which CMS you use, here's what matters most in the current landscape:

Schema-first content types — structured data as a primitive, not a plugin
Author and expert attribution — first-class fields, not custom meta
Last-reviewed / last-verified metadata — surfaced to editors, not just stored
FAQ and Q&A blocks with clean semantic output — automatic Schema markup
Clean API output — headless-capable without being headless-only
Stale content detection — proactive, not on-demand
llms.txt generation — a nice extra, not the centrepiece

The bottom line

WordPress won because it made publishing accessible. The next era rewards something different: making content genuinely trustworthy and extractable at every level of the stack.

The CMS that wins isn't the one that bolts on AI features. It's the one that makes structured, well-attributed, well-maintained content the path of least resistance.

Built for how content gets discovered now — not how it got indexed then.

Why I Built My Own CMS (Again) — This Time with Laravel + Filament

BuildWithTall — Sat, 04 Apr 2026 14:35:53 +0000

Most developers don’t wake up thinking:

“You know what the world needs? Another CMS.”

And yet… here we are.

The Problem with Existing CMS (From a Developer’s POV)

I’ve worked with a lot of CMS platforms over the years — from WordPress to headless setups.

They all work… until you try to do something slightly different.

That’s when things get messy:

You fight plugins instead of building features
You bend your architecture around the CMS
You inherit years of legacy decisions you didn’t sign up for

At some point, I realized:

I wasn’t building products — I was working around the CMS.

The “What If” Question

So I started asking:

What if a CMS was built the way we build modern Laravel apps today?

Not constrained by legacy.
Not pretending to be everything for everyone.

Just:

Clean architecture
Developer-first
Extensible by design
Actually enjoyable to work with

Why Laravel + Filament?

If you’re in the Laravel ecosystem, this part will make sense.

Laravel gives you:

Structure without being restrictive
A clean service layer
First-class DX

Filament gives you:

A powerful admin panel out of the box
Forms, tables, actions — already solved
A consistent UI layer

Together, they solve 80% of what a CMS needs.

The remaining 20%?
That’s where things get interesting.

The Hard Parts (That No One Talks About)

Building a CMS isn’t about CRUD.

It’s about abstractions.

1. Content as Blocks (Not Fields)

What I wanted:

Flexible, composable content blocks

But that introduces problems:

How do you store them?
How do you version them?
How do you render them cleanly?

2. Editor Experience vs Developer Control

There’s always tension between:

Giving non-tech users flexibility
Keeping developers sane

Too flexible → chaos
Too strict → unusable

Finding that balance is harder than it sounds.

3. Plugin Architecture

I didn’t want:

“Just hack it into the codebase”

I wanted:

A system where features can be dropped in cleanly

Which means:

Discovery
Registration
Isolation
Extensibility points

I ended up building TallCMS, an open-source CMS powered by Laravel + Filament.

Current features:

Block-based page builder
Pages & posts
Publishing workflow (draft → scheduled → published)
Revision history
Media library
Menu builder
Plugin architecture

Still early. Still evolving.

Unexpected Lessons

1. Frameworks Matter More Than You Think

Working within Laravel + Filament constraints actually made things better.

It forced:

Consistency
Reusability
Less over-engineering

2. Agentic Coding Is Powerful… But Dangerous

I’ve been experimenting with AI-assisted development.

What I learned:

Without structure → chaos
With a clear plan → massive acceleration

I now always:

1. Generate a plan
2. Review it
3. Execute in controlled steps

3. CMS Is a Systems Problem

It’s not:

“Build pages”

It’s:

“Design a system that lets others build anything”

That shift changes everything.

Where This Is Going

I’m still exploring:

Better block composition
AI-assisted content creation
Multi-site architecture
Developer experience improvements

Curious What Others Think

If you’ve ever:

Built your own CMS
Fought with one
Or are happily using one

I’d love to hear:

What’s the one thing your CMS does really well — or really badly?

Closing

I’m building this as an open-source project called TallCMS.

Not trying to replace everything.

Just trying to make something that feels right for modern Laravel developers.

If you’re curious, happy to share more.