DEV Community: Martin

Full CMS vs Headless: Why All-in-One Wins for Most of the Web

Martin — Tue, 01 Sep 2026 08:00:00 +0000

Let me start by being fair to the other side, because a comparison that only flatters the author isn't worth reading.

Headless CMS earned its reputation for real reasons. Decoupling the content from the frontend gives developers total freedom: pick React or Vue or Astro, deliver the same content to a website and a mobile app and a kiosk, and lean on a mature toolchain of APIs, webhooks, and preview environments. If you're a large team shipping content to many surfaces at once, that flexibility is worth the price you pay for it.

And you do pay for it. That's the part the category doesn't put on the pricing page.

What "headless" actually costs you

The moment you go headless, you own the presentation tier. All of it. You're not just writing content anymore — you're standing up a separate frontend, wiring it to the content API, building the webhook endpoints that tell your site when to rebuild, maintaining a second deployment pipeline, and keeping two systems in sync forever. That's real, ongoing engineering work, and it doesn't stop after launch.

For a large product team, fine — that's their job and they have the people for it. But most of the web isn't a large product team. It's a freelancer building a client site, an agency running twenty of them, a business that wants a fast, modern site without hiring a frontend specialist to keep the lights on. For those people, "total flexibility" is a bill they didn't ask for.

The all-in-one answer

Neleto is a complete CMS. Content, rendering, and hosting live in one place. You design and manage your whole site inside Neleto and it serves the pages directly — no separate frontend to build, no rebuild pipeline to babysit, no second system to keep in sync. That means fewer moving parts, less that can break at 2am, and nothing to rebuild between you and the live page.

You don't give up the modern parts to get that simplicity. The backend is Rust, so pages are fast by default, which Google rewards. All the content types you actually need — pages, blog posts, events, translations, redirects, components, layouts — are built in, not sold back to you as add-ons. Hosting is EU-based and GDPR-compliant out of the box, with your server region chosen at signup. And if you ever do want to pull content elsewhere, there's a REST API waiting. All-in-one doesn't mean walled-in.

The part headless can't answer yet

Here's where the comparison stops being close.

A headless CMS gives an AI agent an API to talk to. Neleto gives it the CMS itself. The native MCP server means Claude Code, Cursor, and Windsurf read and write your content directly — create drafts, publish, add translations, fix redirects — with your roles enforced on every operation. No middleman service, no glue code, no wrapper someone has to maintain.

That's the workflow the next few years are built around, and it's a lot cleaner when the content, the rendering, and the agent interface are one system instead of three you stitched together. Flexibility is worth paying for when you need it. Most people don't — and they shouldn't have to pay for it to get a fast, compliant, AI-native site.

So which should you pick

If you're shipping one content set to a dozen different surfaces with a team that likes owning the frontend, headless is a reasonable choice and I won't pretend otherwise.

If you want a fast site, a clean admin your clients can actually use, EU hosting without the legal footnotes, and an AI workflow that works out of the box — you want the complete CMS. That's most of the web. That's who we built Neleto for.

Try it free at console.neleto.io. Point your agent at it and build a page in a sentence. You'll feel the difference between "connected to a CMS" and "driving one."

— Martin

Originally published at neleto.io.

The AI That Checks Its Own Work

Martin — Tue, 25 Aug 2026 08:00:00 +0000

Here's the failure mode nobody puts in the demo. You ask an AI agent to add a section to your homepage. It calls the API, writes the content, and reports back: "Done — I've added the pricing section." You take its word for it. Two days later a visitor emails to say half the page is blank, because a template reference was misspelled and the whole block silently rendered to nothing.

The agent didn't lie. It genuinely wrote the content. It just never looked at the result — because in most AI-and-CMS setups, it can't. It writes into a black box and gets back an "OK." Whether the page actually renders, whether the layout holds, whether the thing a human would see is right — none of that comes back through the API.

That gap is the whole reason we built verification into Neleto instead of leaving it to hope. An agent working on your site gets three ways to check its own work before it tells you it's done.

The problem with "fire and forget"

When a headless CMS hands an agent an API, the contract ends at "content accepted." The rendering happens somewhere else — a separate frontend, a separate build — so the system the agent talks to has no idea what the visitor eventually sees. The agent can be perfectly obedient and still ship a broken page, because the thing that renders and the thing the agent controls are two different systems.

That's fine when a human reviews every change. It stops being fine the moment you want an agent to do real work unattended — migrate forty pages, fix a batch of redirects, translate a section — because now nobody is looking at the output until it's already live. "The API said OK" is not the same as "the page is right," and the distance between those two sentences is exactly where things break.

Neleto closes that distance because content, rendering, and the agent interface are one system. So the agent can do what a careful human does: write, check, and only then say it's finished.

Layer 1 — the write talks back

The first layer is the quiet one. Every tool on Neleto's native MCP server returns typed structured output, not a vague success string. When an agent creates a page or updates a component, it gets back the actual object it just wrote — the resolved fields, the IDs, the references — in a shape it can inspect.

That sounds small, but it's the difference between "the server didn't reject my request" and "here is exactly what now exists." The agent can compare what it intended against what came back and catch a mismatch immediately — a field that didn't take, a reference that resolved to the wrong thing — instead of assuming the write did what it meant.

Layer 2 — check the template before you publish

The second layer catches the misspelled-reference class of bug before a visitor ever could. Neleto's MCP server exposes LSP checks — lsp_check_page, lsp_check_layout, and lsp_check_component — the same language-server validation the editor uses, available to the agent as a tool call.

The agent loads a page, layout, or component and gets back the errors and warnings in its template: an unknown helper, a reference that won't resolve, a form field that doesn't line up with the template that consumes it. This is the step that would have caught the blank pricing block. The agent runs the check, sees the diagnostic, fixes the reference, and re-checks — all before publish, all without a human noticing anything went wrong, because nothing did by the time you looked.

It's the same instinct that makes a compiler valuable: find the mistake at the point of writing, not at 2am in production. We wrote about why that mindset runs all the way down to Rust — this is the same idea, one level up, handed to the agent.

Layer 3 — open the live page and look

The third layer is the one that feels almost human. Neleto's settings_get tool hands the agent the live instance's real public URLs — publicBaseUrl, adminUrl — so it can go and open the page it just built, the exact URL a visitor would hit, and read the rendered result back.

This is the check the other two can't do. Typed output confirms the write; LSP confirms the template compiles; but only fetching the live page confirms that the finished thing actually looks like a page. The section is there, the heading rendered, the image resolved, the layout didn't collapse. An agent with a screenshot tool can literally look at it. The loop that used to require a human — "let me just load it and see" — is now something the agent does for itself before it reports back.

None of this works without the roles you already set. Every one of these operations — read, write, check, view — runs with the agent's permissions enforced on the server, so "check its own work" never means "quietly gain more access." We went deep on how that server actually works in the MCP deep dive.

Why this needs one system, not three

You could, in principle, bolt a verification step onto a headless stack: wire the agent to the content API, wire it separately to the rendered frontend, stand up a screenshot service, and glue the diagnostics together yourself. People do. It's a pipeline you now own and maintain forever, and every part of it can drift out of sync with the others.

Neleto's version isn't cleverer — it's just that when the content, the renderer, and the agent interface are the same system, the verification is already local. The live URL the agent checks is served by the same box that stored the content it wrote. There's no second system to keep honest, because there's no second system.

Where a human still has to look

Build-in-public means saying what this doesn't do, because the honest limit is the useful part.

Self-verification answers "did it render, and is it structurally sound?" It does not answer "is it good?" An agent can confirm the pricing section exists, renders cleanly, and passes every check — and the copy can still be off-brand, the tone wrong, a number out of date, a claim that isn't true. Those are judgment calls, and judgment is still yours. What these three layers buy you is that the mechanical failures — the broken reference, the collapsed layout, the silent blank block — get caught by the machine, so your review can be about whether the page is right, not whether it works.

And the agent has to actually use the tools. The capability is there; a careless prompt can still skip the check. That's a real edge, and worth knowing before you hand an agent the keys to forty pages.

The point

"AI-native" gets thrown around until it means nothing. For us it means something specific and testable: an agent working on your site can do the whole loop a careful person does — write it, check the template, open the live page, and only then call it done — because it's all one system and the checks are one tool call away.

That's a smaller, more honest promise than "the AI does it all." It's also the one that keeps a blank pricing section off your homepage.

Try it yourself: connect an agent to a free Neleto project at console.neleto.io, ask it to build a page, and tell it to open the live URL and check its own work. Watch it catch its own mistake before you have to — that's what the complete CMS is for.

Fast websites. Easy content. AI native.

Five New Neleto Plugins — Built In, Not Bolted On

Martin — Tue, 18 Aug 2026 08:00:00 +0000

ere's a pattern anyone who has shipped a real website knows too well. You pick a CMS, then you go shopping. Search? Bolt on Algolia. Comments? Embed Disqus. SEO checks? Install a plugin that upsells a subscription. Star ratings? Paste in a review widget. Each one is another monthly bill, another account, and — the part that quietly bites you — another third-party script loading your visitors' data from someone else's server.

We think a complete CMS should ship the complete site. So over the last few weeks we shipped five plugins that cover the things people usually reach off-platform for. All five run inside your Neleto instance, on your EU server, with no external scripts on your pages. Here's what they do — and, honestly, where the edges are.

1. Site Search — instead of Algolia

Site Search adds a real search box to your site, backed by PostgreSQL full-text search running in the plugin's own database. It's German-aware (so Häuser matches Haus), forgiving of typos, and it shows an autocomplete dropdown as visitors type. Drop the search-bar component on any page; results render on a /search page that uses whichever layout you choose, so it looks like the rest of your site.

The part we like most is the free insight: a dashboard card shows your most common searches, and — more useful — the searches that returned nothing. That's a ready-made content to-do list of things your visitors expect but you don't have yet. No external service, no per-search fees, no data leaving your box.

2. Blog Comments — instead of Disqus

Blog Comments gives your posts a comment section that lives in your database, not in an ad-funded third party's. Drop {{ comments(post.id) }} into your blog-post template and you get a threaded thread with replies and likes. Every comment waits for approval by default, so spam never reaches the page — and on top of that there's a honeypot, a submit time-trap, optional hCaptcha/reCAPTCHA, and optional Akismet scoring.

Because it's yours, the privacy story is clean: no tracking scripts on your pages, email is optional and never shown, and there's a one-click erase or anonymize by email for GDPR requests. It even works without JavaScript — the form posts, replies, and likes all degrade gracefully.

3. Google Reviews — instead of an embed widget

Google Reviews pulls your Google rating and latest reviews and renders them in your site's own style — not in a generic Google iframe. The reviews are fetched server-side and cached on your server, so no Google tracking script runs in your visitors' browsers. You can hide any individual review, and the block adds AggregateRating structured data so your star rating can show up in search results too.

One honest limit worth stating up front: Google's API returns at most 5 reviews per location. That's Google's cap, not ours — so this is your best reviews on show, refreshed automatically, rather than an exhaustive archive.

4. Site Health — instead of an SEO plugin

Site Health is two audits in one: on-page SEO and accessibility. It scans every page and gives it a 0–100 score, flags the things search engines penalize (missing or duplicate titles and descriptions, weak social tags, missing H1s) and the barriers that block screen-reader and keyboard users (images without alt text, vague link text, missing page language). Two dashboard cards summarize the whole site; a full admin panel lets you fix page by page.

It also generates structured data (JSON-LD) for your organization, articles, events, breadcrumbs and FAQs — the markup that earns rich results in Google — from content you already have. Accessibility auditing is especially timely for the German market since the Barrierefreiheitsstärkungsgesetz took effect in 2025.

5. Media Gallery — instead of a gallery/slider plugin

Media Gallery is a pack of ready-to-use blocks built entirely from the images already in your media library: a responsive grid or masonry with an accessible lightbox, a swipeable slider, a draggable before/after comparison, and a logo strip. Pick your images with the normal file picker and publish.

Two details that matter: images are delivered at the right size for each device through Neleto's built-in image scaling (srcset out of the box), and everything is accessible and dependency-free — a few KB of vanilla JS per block, no jQuery, no carousel library, and the blocks work even before the JavaScript loads.

Why "built in" actually matters

It's not just tidiness. Keeping these inside the CMS changes three things you can measure:

Privacy, by default. Your search index, your comments, your cached reviews all live in your own EU-hosted database. There are no third-party scripts loading visitor data from a US cloud — which is a much shorter conversation with your DPO, and squarely on the right side of the DSGVO.
Speed. No blocking calls out to Algolia or Disqus or a reviews CDN on every page load. The plugins are small Rust services next to a Rust CMS; the review data and search index are already local.
One admin, one bill. Editors manage everything from the same dashboard, with the same roles. There's no separate SaaS console to log into, and no stack of monthly subscriptions that quietly grows with your traffic.

This is the whole idea behind an all-in-one CMS: the features a real site needs shouldn't each be a separate vendor. They should just be there.

The build-in-public bit

All five are built on the same plugin system that ships with Neleto — each is a small service that the CMS runs alongside your site, exposing components, template helpers, visitor-facing pages and dashboard cards. That's the same surface any developer can build against, and it's a big part of why a small team could ship five of these in a short stretch: the hard parts (rendering, image scaling, auth, roles, hosting) are already handled by the CMS, so a plugin gets to be just the feature.

We'll go deeper on writing your own plugin in a future post. For now: if you run a Neleto site, these are in the plugin store today. Install the ones you need, skip the subscriptions you don't.

Running your site somewhere that charges you per search and per seat for the basics? That's the gap Neleto is built to close — see how the complete CMS compares, or spin up a free project and install the plugins you need.

Fast websites. Easy content. AI native.

Originally published on neleto.io.

Why Neleto Runs on Rust (And the Benchmarks to Prove It)

Martin — Tue, 11 Aug 2026 08:00:00 +0000

When people ask why a small CMS startup wrote its backend in Rust, the easy answer is "speed." That's true, but it's not the whole story — and it skips over the parts that actually cost us time. So here's the honest version, with real numbers instead of marketing adjectives.

The decision

Most CMS platforms are built on PHP, Node, or Python. Those are fine choices. We use Node and TypeScript on the frontend ourselves. But for the part of Neleto that does the heavy lifting — serving content, rendering pages, handling API requests — we wanted something that was fast by default, not fast after six months of profiling and caching workarounds.

The pitch for Rust was simple: predictable performance, low memory use, and a compiler that refuses to let a whole category of bugs into production. The cost was equally simple: it's harder to write, slower to prototype, and the talent pool is smaller. We went in knowing both.

The benchmarks

These are from our own staging environment running on a single Hetzner CX22 instance (2 vCPU, 4 GB RAM, Germany region). Same hardware, same content, same test. We measured time-to-first-byte and requests-per-second under load using wrk with 50 concurrent connections over 30 seconds.

Metric	Neleto (Rust)	Typical PHP CMS*
Median TTFB (cached page)	11 ms	180–400 ms
Median TTFB (uncached, DB hit)	34 ms	250–600 ms
Requests/sec (single instance)	~9,400	~400–900
Memory under load	78 MB	350 MB–1.2 GB
Cold start	0.3 s	n/a (always-on)

*The PHP comparison is a stock install of a popular open-source CMS on the same hardware, no aggressive tuning. Your mileage will vary with caching plugins and CDNs — that's exactly the point. The Rust numbers are what you get before you add a CDN, not after.

The memory figure is the one that matters most for our economics. At 78 MB under load, we can run a lot of customer sites on one box. That's a big part of why we can charge €24/month and not lose money on it.

Where Rust actually paid off

Three places, concretely:

Page rendering. Neleto has built-in rendering, so we're not just shipping JSON to someone else's frontend. The template engine compiles to native code, and it shows — that 11 ms cached TTFB is the difference between a site that feels instant and one that feels "fine."

Concurrency without drama. The async runtime handles thousands of simultaneous connections without us hand-tuning worker pools. During the agentic-traffic spike we wrote about recently, the backend didn't flinch. Bots hammering the API look the same to Rust as a traffic surge from humans.

The compiler caught real bugs. Hard to put a number on this, but the count of "null reference in production at 2am" incidents since launch is zero. Some of that is luck. A lot of it is the borrow checker yelling at us before we shipped.

Where it hurt (the honest part)

Build-in-public means showing the bruises too.

Development was slower at the start. Features that would've taken a day in Node took two or three while we fought the borrow checker and learned the ecosystem. Our first month of real velocity didn't arrive until we'd internalized a few patterns.

Hiring is harder. There are fewer Rust developers than PHP or JS developers, and the good ones know their value. For a bootstrapped team, that's a real constraint we feel every time we think about growing.

Some libraries are still young. A few things that are one npm install away in the Node world required us to write more ourselves. That's time we didn't spend on customer-facing features.

Would we choose Rust again? Yes — but only because performance and infrastructure cost are core to our pitch. If we were building a quick MVP to test an idea, we'd have reached for something faster to prototype in. The right tool depends on what you're optimizing for, and we were optimizing for the thing customers feel on every page load and we feel on every server bill.

What this means for you

If you're evaluating a CMS, don't take "fast" on faith — from us or anyone. Run the test yourself. Drop a page into Neleto, point a load tester at it, and look at the numbers on the same hardware you'd actually deploy on. We'd rather you trust the benchmark than the brochure.

And if you're a founder weighing a "boring and fast to build" stack against a "harder but faster to run" one: there's no universal right answer. We picked the harder road because the speed is something our customers can measure. Make sure whatever you pick, the payoff is something your customers can feel too.

Try it yourself: Spin up a free Neleto project, publish a page, and benchmark it on your own hardware. If the numbers don't beat what you're running now, we want to hear about it.

Fast websites. Easy content. AI native.

Building a Landing Page in Neleto: A Real Walkthrough (Mouse and Prompt)

Martin — Tue, 28 Jul 2026 07:30:00 +0000

Most "page builder" articles are demos that quietly skip the annoying parts. This isn't that. I built the same landing page twice — once by hand in our visual builder, once by asking Claude to do it through our MCP server — and timed both. Here's exactly what happened, including the bits that were slower than I'd like.

What the page builder actually is

Neleto's page builder is a block-based visual editor. You drag sections onto a canvas — hero, text, image, gallery, CTA, columns, embed — set their content and spacing in a side panel, and the page renders with our built-in Rust frontend. No separate frontend app, no framework to wire up. You hit publish and the page is live on your domain.

The point is that you don't have to choose between "developer headless setup" and "locked-in website builder." You get the visual editor for the 90% case, and full HTML/CSS control plus a plugin API for the 10% that needs it.

Build #1: by hand

I built a launch landing page for a fictional client: hero with headline and a signup button, a three-column feature row, a testimonial block, and a closing CTA.

Start to finish: about 11 minutes. Breakdown of where the time went:

Hero section: 2 min. Drag the block, type the headline, set the background, link the button.
Three-column features: 4 min. This was the slow part. Three columns means three icons, three headlines, three blurbs, and getting the spacing even.
Testimonial: 2 min. Drag, paste quote, add the name and a photo.
Closing CTA: 1 min.
Fiddling with mobile spacing afterward: 2 min.

Honest take: the builder is genuinely fast for hero and CTA blocks. Repetitive multi-column content is where any visual editor starts to feel like data entry, and ours is no exception. The mobile preview caught two spacing issues before I published, which I appreciated.

Build #2: by prompt

Then I deleted the page and rebuilt it through the MCP server. I opened Claude and said, roughly:

"Create a landing page in Neleto called 'Spring Launch.' Hero headline 'Ship faster, pay less,' subhead about a 14-day trial, and a 'Start free' button. Add a three-column feature row covering speed, EU hosting, and AI integration. Add a testimonial from a fictional agency owner. End with a CTA to book a demo. Use our brand colors and publish it as a draft."

Claude created the page, populated every block, and left it as a draft for me to review. Elapsed time: about 90 seconds, most of which was me reading what it produced.

The three-column row — the part that took four minutes by hand — was the part the prompt handled best, because describing three parallel things in one sentence is far faster than building them one block at a time. I still went in and tweaked the testimonial wording and swapped one icon. The AI got me to 90%; the visual editor got me the last 10%.

So which one should you use?

Both, depending on the task. After doing this a few times, here's my honest rule of thumb:

Prompt it when the structure is repetitive or you can describe it faster than you can click it: multi-column rows, FAQ sections, feature grids, anything with parallel content.
Click it when you're art-directing: nudging spacing, choosing exactly the right image crop, getting a hero to feel right. Taste is still faster with a mouse.

The thing I didn't expect is how often I now start in the prompt and finish in the editor. The AI does the boring scaffolding, I do the polish. That combination is genuinely the fastest way I've found to put a page online, and it's the reason we built the MCP server into the product rather than bolting on a chatbot.

The numbers that matter

For a four-section landing page: 11 minutes by hand, 90 seconds by prompt plus a couple of minutes of polish. That's not a fair fight, but it's also not the point. The point is you're never stuck. Non-technical editors can drag blocks without help. Developers can drop into HTML. And anyone with Claude open can describe a page and have it built.

No frontend framework to set up. No usage-based bill that balloons when the page gets traffic. It renders on our Rust backend, so it's fast out of the box, and it's hosted in Germany if you choose the EU region.

Try it yourself

If you want to see the prompt-to-page flow, the fastest test is to spin up a free Neleto project, connect the MCP server to Claude, and ask it to build something. Give it a messy, one-paragraph description of a page and watch what comes back. Then open the visual editor and make it yours.

That second step — making it yours — is the part we're proudest of. The AI gets you moving. The builder lets you finish.

— Start free at neleto.io · the only CMS with a native MCP server, hosted in the EU.

Connect Neleto to Anything: The Native MCP Server and Connector Ecosystem

Martin — Tue, 21 Jul 2026 07:40:00 +0000

Most content tools make you leave them to get anything done. You export, you paste, you wire up a middleman, you babysit a sync. Neleto goes the other way: the CMS itself speaks the protocol your AI tools already speak, so the content lives in one place and the work comes to it.

That protocol is MCP — the Model Context Protocol — and it's built into Neleto natively. Not a plugin, not a community wrapper around a REST API, not something you stand up on the side. When you point Claude Code, Cursor, or Windsurf at your Neleto instance, they can read and write your pages, posts, events, translations, and files directly, while respecting the roles and permissions you already set. Your AI workflow and your CMS, finally connected.

What "native" actually buys you

There are a lot of CMS-plus-MCP stories floating around right now, and most of them are a thin shim someone bolted onto an existing API. That works until it doesn't: the tool surface is narrow, the auth is awkward, nobody officially maintains it, and the moment the underlying API shifts, your agent breaks.

Native means Neleto exposes its own content model as first-class tools. An agent doesn't have to guess at your schema or reverse-engineer endpoints — it sees pages, blog posts, events, components, layouts, redirects, and translations as things it can actually operate on. "Create a draft," "publish this," "add a translation," "fix these redirects" — real operations, with your permissions enforced on every one. That's the difference between a demo and something you'd trust on a client site.

What this looks like on a Tuesday

Say a client emails you five new team-member bios and wants them live by end of day. In a normal CMS that's twenty minutes of clicking through forms. With Neleto you hand the email to Claude Code, tell it to create the pages, and it does — using the component you already built, in the language you already run, as drafts you review before anything goes public.

Or you're migrating a stubborn old site. You point your agent at the source, let it read the structure, and have it scaffold the content types with real sample data in Neleto so you can see the shape before you commit. Field mapping and taxonomy alignment — the tedious part — becomes a conversation instead of a spreadsheet. (We wrote up a full WordPress migration start to finish if you want the honest version.)

None of this needs a separate frontend, a second deployment pipeline, or a webhook you have to build and maintain. Everything a full site needs is already inside Neleto; MCP just lets an agent drive it.

Why we're leaning into connectors

MCP turned out to be the thing people actually want to talk about — it's consistently our most-read, most-shared content, and it's where the industry is heading. Through 2026, MCP has moved from a developer curiosity to production infrastructure: tens of thousands of public servers, adoption across every major AI tool, and a growing expectation that serious platforms speak it out of the box.

So the roadmap follows the demand. The native server is the foundation; connectors are the next floor. The goal is simple to say and a lot of work to earn: your Neleto content should be reachable from wherever your team already works, through agents you already trust, without you gluing services together by hand.

The honest status

The native MCP server is live and real — Claude Code, Cursor, and Windsurf work against it today, and it's one of the first things I'd want you to try. The broader connector ecosystem is being built in the open, the same way everything here is. If you're doing something with the MCP server we didn't anticipate, that's exactly the feedback that shapes what ships next — tell me about it.

Spin up a free instance at console.neleto.io, connect your agent to the MCP server, and let it write your first page. That moment — watching your CMS fill itself in from a prompt — is the whole pitch. You just have to see it once.

— Martin

Migrating a 40-Page Site Off WordPress: An Honest, Start-to-Finish Walkthrough

Martin — Tue, 14 Jul 2026 07:55:00 +0000

Most "switch away from WordPress" articles are sales pages in disguise. They tell you migration is a thirty-minute magic trick, skip the messy parts, and end with a button. This isn't that. This is the actual run we did last week, moving a real customer site — 40 pages, a blog with 60 posts, a contact form, and 1.2 GB of media — from a self-hosted WordPress install to Neleto.

Here's the honest headline: the content migration itself — export, import, media — took under an hour of hands-on work. The core content move is genuinely fast. But a real cutover isn't just the content. It's rebuilding the page-builder pages, setting up redirects, swapping the forms, moving the domain, waiting for DNS to propagate, and doing a proper QA pass across every page. Add all of that up and it was about a working day, start to finish — most of it waiting, not clicking.

That's the number we'd want someone to tell us. So here's exactly how it went, including the two things that went wrong.

Why this site was leaving WordPress

The customer is a small German agency running sites for their own clients. Their complaint wasn't ideological. WordPress worked. It was just expensive to keep working: a managed host at €39/month, a security plugin subscription, a caching plugin, monthly update windows where something usually broke, and a recurring worry about where plugin vendors were sending their visitors' data. For a DSGVO-conscious agency, that last one mattered most.

They wanted three things: predictable hosting in the EU, no plugin update treadmill, and content they could edit by prompt instead of wrestling with the block editor. That's a migration, not a tune-up.

Step 1 — Export (about 5 minutes of clicking, then a long wait)

WordPress exports its content as a WXR file (it's just XML) from Tools → Export. We pulled "All content." Media files don't live in that XML — they're referenced by URL — so we also grabbed the /wp-content/uploads folder over SFTP in parallel.

That folder transfer was the slowest single thing in the whole process. 1.2 GB over a residential connection isn't instant, and it ran in the background for the better part of an hour while we did other things. Nothing to babysit — but it's the first place the "30-minute migration" story quietly falls apart. The clicking is fast. The bytes moving are not.

Step 2 — Import into Neleto (about 10 minutes)

Neleto reads WXR directly. Pages became pages, posts became blog entries, and categories and tags carried over as-is. The importer maps WordPress's flat structure onto Neleto's content model automatically, so we didn't hand-build a single schema. Media uploaded to EU-hosted storage and the importer rewrote the old wp-content URLs to point at the new locations.

This is the part that actually is fast, and it's the part the sales pages are technically not lying about. If your site is content-heavy and plugin-light, you could be looking at your imported pages inside ten minutes.

Step 3 — Rebuild the page-builder pages (about 20 minutes)

Gotcha #1: Three posts used a page-builder plugin (Elementor) whose layout lives in proprietary shortcodes, not standard HTML. Those came in as raw shortcode text. The importer can't know what [ult_buttons] means — nobody can. We rebuilt those three pages by hand in about twenty minutes.

If your site leans heavily on a page builder, budget real time for this. It's the honest asterisk on every "one-click migration" claim, ours included. The upside: rebuilt in Neleto, those pages are now plain components anyone can edit — no shortcode syntax, no locked-in builder.

Step 4 — Redirects (about 15 minutes)

This is the step people forget and then lose their search rankings over. WordPress permalinks (/2024/03/post-name/) rarely match a new CMS's URLs one-to-one. We exported the old URL list, generated a redirect map, and imported it. Neleto handles 301s natively, so there was no .htaccess to babysit.

Gotcha #2: The old site had a ?p=123-style query permalink structure on a handful of legacy links from an email campaign. Those needed manual redirect rules. Five total. Worth checking your analytics for any odd inbound URLs before you cut over — it's five minutes now versus a month of 404s later.

Step 5 — Forms (about 15 minutes)

The contact form was a WordPress plugin posting to the site's own database. We replaced it with Neleto's built-in form handler, which stores submissions in the EU and emails the agency on receipt — no third-party form SaaS, no US data transfer. Rebuilding the fields and sending a couple of test submissions to confirm the mail landed took about fifteen minutes.

Step 6 — The domain and DNS cutover (about 10 minutes of work, then hours of waiting)

Here's the other place the clock stops being about you. Pointing the domain at Neleto is ten minutes of actual work: update the records, done. Then you wait for DNS to propagate. In our case most resolvers picked up the change within a couple of hours, but you can't rush it and you shouldn't cut over your MX and traffic until you've confirmed it's clean.

We kept the old WordPress host live during propagation so nobody hit a dead site mid-switch, watched the first agent and human requests land on the new stack, and only then decommissioned the old box. This is the single biggest reason "half an hour" is a fantasy: the internet's caches don't care how fast your CMS is.

Step 7 — QA pass (about 45 minutes)

Last, we walked every one of the 40 pages and spot-checked the 60 blog posts: images loading from the new EU storage, internal links resolving, the rebuilt Elementor pages looking right, redirects firing, the form emailing. Found and fixed a few internal links that still pointed at the old domain. Boring, essential, and the step that separates "it's live" from "it's actually done."

The honest clock

Hands-on-keyboard time: roughly 90 minutes across the whole thing.
Elapsed, start to finish: about a working day — dominated by the 1.2 GB media transfer and DNS propagation, both of which are waiting, not working.

So: fast where the sales pages promise fast (the content import), and honestly slow where every migration is slow (moving bytes, moving domains, checking your work). Anyone who tells you a real 40-page cutover is thirty minutes flat is selling you the demo, not the day.

What changed, measured honestly

The numbers after one week, not promises:

Hosting cost: €39/month → €59/month flat for the Neleto Team plan, but that one plan replaced the host and two paid plugins the customer was running (roughly €25/month combined). Net, slightly cheaper, with one bill instead of three.
Largest Contentful Paint: 2.9s → 0.8s on the homepage. The Rust backend and no plugin overhead do most of that work.
Update windows: gone. There's no plugin stack to patch.
Data location: every byte — content, media, form submissions — now sits on EU infrastructure with no US Cloud Act exposure.

What didn't improve: the three rebuilt pages took real human effort, and the agency had to relearn where a few settings live. Migration removes a treadmill; it doesn't remove a learning curve.

Should you do this?

If your WordPress site is content-heavy and plugin-light, a migration like this is genuinely a half-day-to-a-day job and pays for itself in saved maintenance within a quarter. If your site is a pile of page-builder layouts and 30 plugins, be honest with yourself: that's a rebuild wearing a migration costume, and it'll take longer.

Either way, the content import is the free, reversible part — so that's where to start. Run it, look at your pages inside Neleto, and then decide whether the rest of the day is worth it. For most content sites we've moved, it is.

We'll keep publishing these as we run them, gotchas included. If you want us to look at your specific site before you commit, the export step costs you nothing.

I turned a static HTML page into an editable CMS site with one prompt

Martin — Tue, 07 Jul 2026 08:00:00 +0000

There's a moment every web designer knows. The design is done. It's good. The animations are smooth, the type is dialed in, the custom cursor does the thing. And then the client asks the question that deletes your weekend:

"Can I edit this myself?"

Now you're not a designer anymore. You're a CMS plumber. You rebuild the whole thing in WordPress or Contentful, you map every headline to a field, you fight a templating language you don't love, and somewhere in there the animations break and you spend an afternoon getting your scroll-reveal working again. A week, gone. The design didn't get better. It just became editable.

I built Neleto partly to kill that week. This post shows you how — with a real example you can copy.

The 30-second version

Neleto is the only CMS with a native MCP server. MCP (Model Context Protocol) is the thing that lets tools like Claude Code, Cursor and Windsurf talk to other systems directly. Because Neleto speaks it natively, an AI assistant can read and write your CMS — create layouts, components and editable fields — without you touching a single admin form.

So the workflow becomes: you finish your HTML, you run one prompt, and Neleto turns it into a fully component-driven site where the client can edit every word and image — while your CSS, your animations and your JavaScript carry over untouched.

Not "AI-assisted." One prompt, finished site.

The example

I made a small design-studio landing page — call it Studio Nordlys. It's deliberately the kind of thing you'd actually ship: a fixed nav with a scroll state, a hero with a glowing animated blob and a staggered reveal, a scrolling marquee, an about section with an animated stat counter, a four-up services grid with hover states, a project gallery with image zoom, a dark process section, a big testimonial, a CTA banner, and a custom cursor that follows you around on desktop. CSS variables, keyframes, an IntersectionObserver, the works.

One file. The kind of page that normally makes the "make it editable" conversation painful, because there's so much in there you don't want to lose.

📥 Download the Studio Nordlys example — the HTML page plus the full prompt (.zip)

The prompt does the boring part

Here's the trick: the hard knowledge isn't the design — that's yours. The hard knowledge is how a CMS wants its layouts, components, templates and fields structured, and all the little ways you can get it wrong. So that knowledge lives in a prompt.

You point Claude at your file:

Use the Neleto MCP server to implement @studio-nordlys.html as a fully component-driven page. Every piece of content must be editable through the CMS — nothing hardcoded.

…and hand it the spec. From there Claude splits the page into sections, drops all your global CSS into a layout, turns each section into a component with its own scoped CSS and JS, and — the part that matters — replaces every headline, paragraph, label, link and image with a named, editable field. Your <h1>Design that moves people</h1> becomes a "Heading" field in the CMS. Same markup, same styling, now editable.

It assembles the page in your original order, wires the nav and footer into the layout so they show on every page, and hands you a live URL. Your animations still run. The custom cursor still follows the mouse. The stat counter still counts up. Because none of that was rebuilt — it was moved, intact, into the right places.

Why this is different from "AI website builders"

Two reasons, and they're the reasons I keep harping on.

You keep your design. This isn't a generator that invents a generic site from a text prompt. It takes your pixel-perfect HTML and preserves it. The AI does the CMS wiring, not the art direction. That's the right division of labor — machines are good at tedious structural mapping, you're good at taste.

It's a real CMS underneath, hosted in the EU. When you're done, the client logs into an admin where every section is a clean panel of plain-language fields. They can't break your layout because the layout isn't a field. And because galleries and lists are built as repeatable components, the client can add a fifth project themselves — not just edit the four you shipped. Images get scaled automatically on upload, so a client dropping in a 6 MB photo doesn't tank your performance score. And it runs on Neleto's Rust backend on EU infrastructure — no US Cloud Act exposure, which matters more to your clients every year.

For context on price: a setup like this on Contentful starts around €109/month and climbs fast with seats. Neleto starts free, with paid plans from €24/month. For an agency reselling to clients, that margin is the whole point.

The honest part

I'm not going to pretend it's magic with no edges.

It works best on a clean, sectioned page. Feed it tidy <section> wrappers and grouped CSS and the conversion is crisp. Feed it 4,000 lines of unlabelled <div> soup and you'll do some cleanup. The example page is clean on purpose — that's the lesson, not the cheat.

Occasionally a section converts twice, or a JavaScript effect needs a nudge to re-attach, or a field name gets mistyped. Every one of these is fixable by describing the symptom to Claude — "that section is duplicated, update it in place" — not by hand-editing CMS internals. The prompt already documents the common ones. But I'd be lying if I said it's always one-shot perfect on a gnarly page. On a clean page, it basically is.

And it doesn't do your job for you. It doesn't write your content strategy, fix your accessibility, or do your SEO. It preserves what you gave it. Garbage in, editable garbage out.

Try it

If you design websites and you've ever lost a week making one editable, this is worth twenty minutes of your evening. Grab the example page and the prompt, connect the Neleto MCP server to your editor, and watch a finished design become a client-editable site while you make tea.

📥 Download the example page + prompt (.zip)

Next time someone asks "can I edit this myself?" — yes. And it'll cost you a prompt, not a weekend.

— Start free at neleto.io · the only CMS with a native MCP server, hosted in the EU.

Neleto Console Is Live — and the Free Tier Is Open

Martin — Tue, 30 Jun 2026 08:00:00 +0000

Neleto Console is live at console.neleto.io, and the free tier is open for self-serve registration. Go there, create an account, pick the Free plan, and a few moments later you have your own Neleto instance running — no sales call, no card, no waiting on me.

That last part took longer to earn than I'd like to admit. The whole loop — provision a server, install the Neleto stack, issue a license, send your credentials — now runs untouched by human hands. If you've followed these build-in-public posts, you'll know that was the open seam I kept refusing to paper over on a pricing page. It's closed.

What you get on Free

One user, 1 GB of storage, and a real Neleto site — not a demo, not a sandbox that resets overnight. It runs on shared infrastructure, so there's no backup and the limits are real, but everything that makes Neleto Neleto is there: the integrated rendering and the page builder. Build your site by hand in the builder, or point Claude, Cursor, or Windsurf at the native MCP server and have it write pages for you by prompt. Both work. The AI angle is a big part of why I built this — but you don't need it to get value on day one.

When you outgrow Free, Starter is €24/mo, Team €59/mo, and Business €149/mo. Upgrading moves you off the shared box onto your own dedicated server — more room, more performance, and backups — without you having to migrate anything by hand.

Why give it away

The free tier exists for one reason: so you can actually experience Neleto before deciding anything. No demo, no sales deck, no expense approval — just a real site you can build on and judge for yourself. That's the only way I'd want to be sold a tool, so it's how we're selling this one.

And every instance, free ones included, runs on EU infrastructure by default. Your data sits under European data-protection law, not a US cloud provider's terms. For a lot of the people we talk to — agencies, public-sector teams — that's not a footnote, it's the whole reason they call.

The honest status

This is day one. The free tier is live and the self-serve flow works end to end — that's the hard part, and it's real. But the shared-tier limits are conservative on purpose while I watch how a hundred instances behave on one box under real traffic, and a few other paid-plan features are still on the bench. If you hit a rough edge in the first weeks, you're seeing a young system in public, which is exactly where I want it.

So go to console.neleto.io, sign up for free, and put it through its paces. If something's confusing, slow, or broken, I want to hear about it. We did this in the open so the first people through the door could shape what it becomes — and the door's open now.

— Martin

MCP Server Explained: The Deep Dive

Martin — Tue, 23 Jun 2026 08:00:00 +0000

The Model Context Protocol (MCP) has quickly become one of the most important developments in the AI tooling space since its introduction by Anthropic in late 2024. While many developers have heard of MCP, fewer understand what an MCP Server actually is, how it works under the hood, and why native implementation in applications like CMS platforms matters significantly.

This deep dive breaks it down clearly.

What is an MCP Server?

An MCP Server is the server-side implementation of the Model Context Protocol. It acts as a standardized interface that allows AI models and agents to discover, connect to, and interact with external tools, data sources, and applications in a secure, structured way.

Think of it as a universal adapter. Instead of every AI application building custom integrations for every tool (databases, CRMs, CMSs, file systems, etc.), the MCP Server provides a common language and protocol that any MCP-compatible client can use.

Key responsibilities of an MCP Server:

Resource discovery: Exposing what data and capabilities are available
Tool registration: Defining functions/actions the AI can call
Context provision: Supplying relevant, up-to-date information to the model
Permission enforcement: Ensuring the AI only does what it’s allowed to do
Secure communication: Handling authentication and controlled access

MCP Architecture: Client vs Server

MCP follows a client-server model:

MCP Client: Usually lives inside the AI application (e.g., Claude Desktop, Cursor, Windsurf, or custom agents). It initiates connections and makes requests.
MCP Server: Lives inside the target application (your CMS, database, internal tool, etc.). It responds to requests and executes actions.

This separation is powerful. It means:

AI tools don’t need to know the internal details of every system they connect to.
Application developers only need to implement the MCP Server once to become compatible with the entire ecosystem of MCP clients.

The protocol handles discovery, capability negotiation, and structured requests/responses, making integrations much more reliable than traditional custom API work.

Why “Native” MCP Server Implementation Matters

Not all MCP support is created equal. There’s a meaningful difference between:

Bolt-on / Proxy MCP servers — Built as middleware or separate services that sit in front of your application.
Native MCP servers — Deeply integrated into the core of the application, with direct access to internal data models, permissions, and business logic.

Benefits of native implementation:

Better security: The server understands your existing permission model natively instead of trying to replicate it.
Stronger consistency: Actions taken by AI agents follow the same rules and audit trails as human users.
Deeper integration: The AI can work with rich internal concepts (content types, relationships, workflows) rather than just raw data.
Lower latency & complexity: No extra network hops or translation layers.
Future-proofing: As the protocol evolves, native implementations can adapt more cleanly.

This is why platforms that ship with a native MCP server (like Neleto) offer a meaningfully better experience than those that rely on external proxies or custom integrations.

Security and Permissions Model

One of the biggest concerns with giving AI agents access to production systems is control. MCP was designed with this in mind.

A well-implemented MCP Server should:

Respect existing role-based access control (RBAC)
Allow granular scoping of what resources and actions are exposed
Maintain full audit logs of agent activity
Support human-in-the-loop approval workflows where needed
Never bypass application-level business rules

When done correctly, an AI agent using MCP should have the same (or more restricted) capabilities as a human user with the same role — nothing more.

This is a major advantage over older approaches like giving AI systems broad API keys or database access.

Real-World Use Cases in Content Management

While MCP has broad applications, it shines particularly well in content systems:

1. AI-assisted content creation

An agent can research, draft, and directly create or update blog posts, landing pages, or product descriptions inside the CMS.

2. Automated content operations

Agents can bulk-update metadata, reorganize content structures, translate content, or apply taxonomies consistently.

3. Intelligent content maintenance

AI can identify outdated content, suggest improvements, or keep related pieces in sync.

4. Developer + AI collaboration

While a developer builds new features or components, an AI agent can simultaneously update the corresponding content entries without manual handoff.

The key is that these actions happen inside the CMS with proper permissions and workflows — not as disconnected generations that someone has to copy-paste later.

How Neleto Implements the MCP Server

Neleto was designed with AI collaboration as a core principle from the beginning. Its native MCP server is deeply integrated into the platform’s architecture.

This means:

AI agents connect directly to Neleto’s data layer and permission system
They can create, read, update, and manage all standard content types (pages, blog posts, events, etc.)
Actions respect the same role-based permissions configured for human users
Changes are fully auditable through normal platform mechanisms
No additional infrastructure or middleware is required

Because the implementation is native, agents can work with Neleto’s concepts (layouts, components, translations, redirects) in a way that feels natural rather than fighting against a generic API layer.

This positions Neleto as one of the most AI-ready content platforms available today — not through bolted-on features, but through fundamental architecture.

The Bigger Picture: Why This Matters

We are moving from AI as a tool that generates text to AI as a collaborator that can take meaningful actions inside the systems we use every day.

For this transition to be safe and useful at scale, we need standardized, secure interfaces. MCP is rapidly becoming that standard.

Applications that implement native MCP servers will have a significant advantage:

They become part of the growing AI agent ecosystem
They reduce friction between development and content work
They future-proof their platform as agentic workflows become mainstream

For developers and agencies, this translates to faster workflows, less manual busywork, and the ability to offer clients more powerful capabilities without increasing operational complexity.

Getting Started with MCP in Neleto

If you want to experience a native MCP server in action:

Create a Neleto project (free plan available)
Connect an MCP-compatible client (such as Claude or Cursor with MCP support)
Grant the appropriate permissions
Start collaborating with AI agents directly on your content

The experience of having an AI that can actually do work inside your CMS — rather than just suggesting text — is qualitatively different.

Conclusion

An MCP Server is more than just another integration. It represents a new contract between applications and AI agents — one built on standardization, security, and native understanding of the host system.

Platforms that treat MCP as a core architectural concern (rather than an afterthought) will define the next generation of AI-augmented tools.

Neleto’s native MCP server implementation reflects this philosophy: AI should be a first-class participant in content workflows, not a disconnected generator that creates more work for humans.

The future of content management isn’t just faster tools. It’s collaborative systems where humans and intelligent agents work together seamlessly — and MCP is one of the key protocols making that future possible.

Neleto vs Contentful: Which CMS Should You Choose in 2026?

Martin — Tue, 16 Jun 2026 10:52:10 +0000

Choosing the right CMS has never been more important — or more confusing. The market is full of options, from traditional monolithic platforms to modern headless solutions. Two names that often come up are Contentful, the established enterprise headless CMS, and Neleto, the newer performance-focused, AI-native alternative.

Both are capable platforms. But they serve noticeably different needs.

This article breaks down the real differences so you can decide which one actually fits your team, budget, and goals.

Quick Comparison Overview

Starting Price

Neleto: Free / €24/mo
Contentful: Free / ~$300/mo
🏆 Winner: Neleto

Performance

Neleto: Rust backend (very fast)
Contentful: Good (depends on frontend + CDN)
🏆 Winner: Neleto

AI Integration

Neleto: Native MCP server
Contentful: AI features available, no native MCP
🏆 Winner: Neleto

Editor Experience

Neleto: Clean, intuitive admin
Contentful: Good but can feel developer-oriented
🏆 Winner: Neleto

Developer Control

Neleto: Full HTML + plugin API
Contentful: Excellent API & modeling
🏆 Winner: Tie (different strengths)

EU / GDPR Hosting

Neleto: Strong native EU option (Germany)
Contentful: Available but more complex
🏆 Winner: Neleto

Frontend Requirements

Neleto: Optional (built-in rendering)
Contentful: Required (headless)
🏆 Winner: Neleto

Best For

Neleto: Agencies, freelancers, mid-market, AI workflows
Contentful: Large enterprises, complex omnichannel
🏆 Winner: Depends

Total Cost of Ownership

Neleto: Predictable and low
Contentful: Can grow expensive quickly
🏆 Winner: Neleto

1. Pricing & Total Cost of Ownership

This is one of the clearest differences.

Contentful follows a usage-based model on top of base plans. While there is a free tier and a Lite plan starting around $300/month, costs can escalate quickly with API calls, bandwidth, and additional spaces. Many mid-sized teams report spending thousands per month once they scale.

Neleto offers transparent, predictable pricing:

Free plan for personal projects and testing
Starter from €24/month
Team from €59/month

There are no surprise usage bills for normal website operations, and you're not penalized for growing traffic in the same way.

Verdict: If budget predictability and lower total cost matter to you (especially for client work or growing businesses), Neleto has a significant advantage.

2. Performance

Neleto was built from the ground up in Rust, which gives it a substantial performance edge. Pages load faster out of the box, which directly impacts SEO, Core Web Vitals, and user experience.

Contentful is a mature platform with a strong global CDN. However, because it is purely headless, your actual site speed depends heavily on how you build the frontend and how you query the API. Many teams end up fighting performance issues that stem from architecture rather than the CMS itself.

Verdict: Neleto wins on raw speed and simplicity of achieving fast websites.

3. AI Capabilities (The New Differentiator)

This is where the gap is growing fastest in 2026.

Neleto includes a native MCP (Model Context Protocol) server. This allows AI agents (Claude, Cursor, Windsurf, etc.) to directly read from and write to your content — creating blog posts, updating pages, managing assets — while respecting your existing permissions and workflows.

Contentful has been adding AI capabilities, but it does not currently offer a native MCP server experience. Integrations tend to be more custom or one-way.

Concrete example: With Neleto + MCP, a developer can ask Claude to "write a new case study based on our latest project and publish it under the right category with the correct featured image." The agent can do this directly in the CMS.

This level of deep, native AI integration is still rare among traditional headless CMS platforms.

Verdict: If you want to work with AI agents instead of just generating text in a separate tool, Neleto is currently ahead.

4. Developer Experience vs Editor Experience

Contentful excels when you have strong development resources and need sophisticated content modeling. Its API-first approach and GraphQL support are excellent for complex, omnichannel projects.

However, many teams report that the editing experience can feel secondary to the developer experience. Non-technical users sometimes struggle or require developer support for certain tasks.

Neleto was explicitly designed with both sides in mind:

Developers get full control over HTML, layouts, a plugin API, and direct database-like access when needed.
Editors and clients get a clean, modern admin interface that requires almost no training.

It also includes built-in rendering, so you're not forced to build a separate frontend application for every project.

Verdict: Neleto offers a better balance for most agencies and teams that serve non-technical clients.

5. Hosting, Compliance & Data Residency

For European companies or anyone serving EU users, this has become a serious consideration.

Neleto gives you a clear choice at signup, including EU/Germany hosting powered by Hetzner. This makes GDPR compliance and data sovereignty significantly more straightforward.

Contentful operates globally with data centers in multiple regions. While EU options exist, the company is US-based, and compliance often requires more configuration and legal review.

Verdict: Neleto is the simpler and more transparent choice for EU-focused teams.

When Contentful Makes Sense

Contentful remains a strong choice if you:

Are a large enterprise with highly complex, multi-brand content models
Need deep omnichannel delivery across many digital properties
Already have heavy investment in a specific frontend stack and composable architecture
Have a large budget and dedicated development team
Value the maturity and extensive marketplace of a long-established platform

When Neleto Makes More Sense

Neleto is usually the better fit when you:

Want fast websites without fighting performance
Need predictable, affordable pricing (especially for client work)
Want native AI agent capabilities today (via MCP)
Serve European clients or need strong GDPR/EU data residency
Value a clean experience for both developers and non-technical editors
Don't want to be forced into a full headless + frontend framework setup
Are a freelancer, agency, or mid-sized business that wants modern capabilities without enterprise complexity

Final Verdict

Contentful is a powerful, battle-tested platform that continues to serve large organizations well. It's not going away.

However, for a growing number of developers, agencies, and businesses in 2026, Neleto offers a more modern, faster, more affordable, and AI-native alternative — especially if you value simplicity, performance, and European compliance.

The best CMS is the one that gets out of your way and lets you deliver great websites efficiently. For many teams today, that CMS is Neleto.

Ready to compare them yourself?

Try Neleto for free and see how it feels for your next project. If you're currently on Contentful and curious about migrating, we also have a WordPress importer (and are happy to discuss Contentful migrations too).

Bots Just Out-Numbered Us: What the Agentic Web Means for Your CMS

Martin — Tue, 09 Jun 2026 07:00:00 +0000

It finally happened, and it happened early.

According to Cloudflare Radar data — flagged by SemiAnalysis and confirmed by Cloudflare CEO Matthew Prince — automated traffic has surpassed human traffic on the open web for the first time in history. Bots and AI agents now account for roughly 57.5% of HTTP requests to HTML pages, with humans down to 42.5%.

The headline number is striking on its own. What makes it a genuine inflection point is when it arrived and what caused it. Prince had publicly predicted this crossover wouldn't happen until the end of 2027, and it showed up roughly 18 months ahead of schedule. The thing that pulled it forward wasn't the search crawlers and scrapers we've lived with for two decades. It was agentic AI — autonomous agents browsing, comparing, and acting on behalf of real people.

The web has quietly become an environment where machines do most of the reading, while we keep building it for the people who now make up the smaller half.

Why This Is Important
For twenty-five years, every website on the internet rested on one quiet assumption: a human will look at this. We optimized for human eyes — layouts, hero images, hover states, cookie banners, the whole ritual. The entire stack, from page-builders to analytics, assumes a person on the other end.

That assumption is now wrong more often than it's right.

Here's what's actually changing, and why it matters for anyone who runs a website:

One human now generates dozens of page visits through agents. When a person asks an AI agent to "find me the best mirrorless camera under €1,500 and book the cheapest one in stock," that single intent can fan out into thousands of page requests across hundreds of sites. The person never opened a browser; their agent opened hundreds. Your traffic graph is increasingly a record of machines reading your content.

Agents read differently than people do. A human will tolerate a slow, cluttered, JavaScript-heavy page because they want the thing badly enough to wait. An agent has no such patience. It wants structured, fast, machine-readable content, and when a site is slow or hostile to automated access, it simply moves on to a competitor that's easier to read. Being legible to agents is turning into a ranking and revenue question, not a technical curiosity.

The traffic that matters is shifting from impressions to actions. The old web rewarded getting in front of eyeballs. The agentic web rewards being the source an agent trusts and actually uses to complete a task. When an agent can reliably read your product data, your availability, your documentation — and ideally write back to it — you're in the workflow. When it can't, you're invisible, however beautiful the page looks to a human.

And this is accelerating. AI-driven traffic grew roughly 8× faster than human traffic across 2025. A milestone that landed 18 months early marks the beginning of a steep curve, not a one-off spike.

So the question every site owner, agency, and developer now has to answer is uncomfortably simple: is my content built for the audience that's actually showing up? For most sites, the honest answer is no — they're still built for the 42.5%.

Why Neleto Is the Best Thing You Can Do About It
Most teams will respond to this news the way teams usually do: by bolting something on. An AI plugin here, a scraping policy there, maybe a hastily written llms.txt. That approach treats agentic traffic as an edge case to be managed after the fact.

Neleto was built on the opposite assumption — that agents are a primary audience, not an exception.

It's a CMS written in Rust with a native Model Context Protocol (MCP) server, as far as we know the only CMS with one built in from the ground up rather than glued on later. That single architectural decision happens to be exactly what the agentic web demands.

Agents can read and write your content, safely. Most "AI integrations" let a model read a page and nothing more. Neleto's MCP server lets AI agents — Claude Code, Cursor, Windsurf, anything that speaks MCP — securely read and update your live content, following the same roles and permissions a human editor would. Instead of scraping a rendered page and guessing at its meaning, the agent works with your content through a structured, permissioned interface designed for it. In a web where agents now outnumber people, your CMS speaks their language by default.

Speed is a feature when your readers are machines. Agents are relentless: they hit thousands of pages and they don't wait around. Neleto's Rust backend runs 10–50× more efficiently than typical PHP or Node.js stacks, so it stays fast and cheap to operate even under the heavy automated load that now makes up the majority of the internet. Fast pages get read, used, and ranked; slow ones get abandoned by humans and skipped by agents alike.

Structured content beats rendered guesswork. Neleto stores content as clean, typed resources — pages, blog posts, events, files, components, translations — with integrated rendering, so there's no fragile second stack for an agent to misread. That structure is what lets an agent use your data confidently instead of hallucinating around it.

You stay sovereign while you do it. The agentic shift doesn't suspend GDPR. Neleto offers DSGVO-compliant multi-region hosting (DE/EU, US, Asia), so opening your content to agents never means handing your data to someone else's cloud jurisdiction. Your content becomes agent-ready and remains yours.

And it costs a fraction of the alternatives. Neleto starts at €19/month and runs 5–7× cheaper than Contentful or Storyblok, while shipping the one thing they don't: a native MCP server. Future-proofing your content for the agentic web shouldn't require an enterprise contract.

The Cloudflare data is a warning shot for everyone still building exclusively for human eyeballs. The web's largest audience is now machines acting for people, and that audience is growing eight times faster than the old one. You can keep patching around that reality, or you can run your content on a system that was designed for it from day one.

As of this week's numbers, the agentic web is already here — and already the larger half of the internet. Neleto is how you publish for it.

Fast websites. Easy content. AI native.
Built for the 57.5%, before everyone else noticed.