CMS estático para webs de clientes
Un CMS estático para webs de clientes, donde cada guardado es un commit
jtakeit es un CMS estático basado en git para webs de clientes: el propietario edita tocando el texto, los textos son JSON en tu repositorio, cada guardado es un commit y el sitio sigue siendo salida estática.
$ git pull
$ git log --oneline -3 -- jtk/content/
b3dc408 save: client-site at rev 14
5e0a9c1 save: client-site at rev 13
a41f7d2 save: client-site at rev 12
$ git show --stat --format= HEAD
jtk/content/index.json | 2 +-01/ qué es
¿Qué es un CMS estático?
Un CMS estático edita el contenido de un sitio que se genera de antemano como HTML plano, en lugar de montarse desde una base de datos en cada visita. Los visitantes cargan archivos; el CMS es la forma de cambiar las palabras de esos archivos.
En un sitio de cliente eso son dos tareas a la vez. El propietario tiene que poder cambiar sus propios textos sin llamarte, y el resultado tiene que seguir siendo el sitio estático y rápido que construiste: sin PHP, sin base de datos y sin plugins en el propio sitio.
En jtakeit el sitio es un proyecto estático —Astro por defecto, o cualquier otro generador estático— en un repositorio git que tienes tú. Los textos del propietario son documentos JSON en ese repositorio, el propietario los edita tocando el texto en la página, y cada guardado es un commit.
02/ git o api
¿CMS basado en git o headless CMS basado en API?
Un headless CMS basado en API guarda el contenido en su propia base de datos y lo sirve mediante una API, algo que encaja cuando un equipo de contenidos publica en una web, una app y más. Un CMS basado en git guarda el contenido como archivos junto al código. Un sitio de cliente tiene un propietario y un sitio, y por eso jtakeit está basado en git.
| Headless CMS basado en API | La mayoría de CMS basados en git | jtakeit | |
|---|---|---|---|
| Contenido publicado | En la base de datos del CMS, obtenido por su API | Archivos Markdown o JSON en el repositorio | JSON en el repositorio que tienes tú |
| Un guardado | Una actualización de registro | Un commit | Un commit; los borradores quedan en la base de datos de la plataforma |
| Dónde trabaja el editor | En una app de administración aparte | Normalmente en un formulario de administración aparte | En la propia página, tocando su texto |
| Qué puede cambiar el editor | Lo que permita el modelo de contenido | Lo que exponga la configuración del CMS | Solo los campos que declara el catálogo; sin botón de añadir página ni de añadir bloque |
| Formularios, reservas, hosting | Fuera del CMS, añadidos por separado | Fuera del CMS, añadidos por separado | Operados por la plataforma, con la facturación, las copias de seguridad y el dominio |
| El sitio tal como estaba en marzo | Depende del historial del CMS | Un solo comando de git | Un solo comando de git |
03/ más allá de editar
Lo que necesita un CMS para sitios estáticos de clientes
Un CMS responde a una pregunta: ¿cómo cambia el propietario los textos? Un sitio de cliente plantea tres más: qué pasa cuando un visitante escribe, cuando quiere reservar y cuando el cliente quiere irse.
Ediciones que no rompen el diseño
El propietario solo rellena lo que declara el catálogo. La estructura es un commit, hecho por ti o por tu agente.
Formularios de consulta
Los formularios están protegidos contra el spam, y las consultas llegan a Telegram, al email o a la bandeja del panel.
Reservas de pago
El módulo de reservas envía las reservas pagadas directamente al Stripe del propio negocio.
Datos que pueden llevarse
Las consultas y las reservas se exportan en CSV y JSON. Exportar nunca exige una suscripción activa, y nada se borra porque una venza.
Una vista previa antes de pagar
El cliente aprueba el sitio real, en una vista previa, antes de pagar.
Un SEO que sigue activado
Se rechaza un build con noindex, un robots.txt que bloquea a los rastreadores, un sitemap vacío o un canonical en otro dominio.
04/ escrito por tu agente
Un CMS para generador de sitios estáticos que escribe tu agente de IA
Astro es el scaffold por defecto y funciona cualquier generador estático; en ambos casos, cada parte del CMS es un archivo en el mismo repositorio: las páginas, la declaración de lo que el propietario puede editar y los documentos de contenido. Tu agente —Claude Code, por ejemplo, a través del servidor MCP de jtakeit— escribe los tres, compila el sitio y te entrega una vista previa.
- Declarar. Un campo que declaras es un campo que el propietario puede editar; todo lo demás es diseño.
- Comprobar. La comprobación del catálogo rechaza un campo declarado pero no renderizado, o renderizado pero no declarado.
- Revisar. Lees el trabajo del agente como un diff, como cualquier otro código.
Cómo se declara la edición en el Astro CMS →
El flujo con Claude Code, paso a paso →
{
"path": "/",
"seo": { "title": "…", "description": "…" },
"blocks": [
{ "type": "hero", "v": 1,
"title": "Fresh bread from six",
"lead": "Order by noon, collect tomorrow." },
{ "type": "questions", "v": 1,
"items": [ … ] }
]
}05/ cómo elegir
Cómo elegir el mejor CMS basado en git para webs de clientes
Hay muchos CMS basados en git buenos, y el adecuado depende de quién edita. Si tus editores escriben artículos largos y están a gusto en un formulario de administración, o quieres alojar y operar el CMS tú mismo, puede que un CMS basado en git de uso general te sirva mejor.
jtakeit es más acotado a propósito. Es para desarrolladores cuyo agente de IA escribe los sitios de clientes, y cuyos clientes deben poder cambiar sus propios textos —y nada más— sin llamarte. También opera lo que un sitio de cliente necesita alrededor del CMS: formularios, reservas, facturación, copias de seguridad, hosting y el dominio.
¿Vas a sacar a un cliente de un sitio basado en base de datos? Lee sobre jtakeit como alternativa a WordPress para desarrolladores. Para ver cómo se declaran en código los campos del propietario, lee el Astro CMS para webs de clientes.
06/ preguntas
Preguntas sobre el CMS estático
- ¿Qué es un CMS estático?
- Un CMS estático edita el contenido de un sitio que se genera de antemano como HTML plano, en lugar de montarse desde una base de datos en cada visita. En jtakeit el contenido es JSON en el repositorio git del sitio, el propietario lo edita en la propia página y cada guardado es un commit en ese repositorio.
- ¿Es jtakeit un headless CMS basado en git?
- Está basado en git, pero está hecho para un sitio de cliente, no para servir contenido a muchos canales. El contenido vive como archivos JSON junto al código, y el propietario lo edita en la propia página en lugar de en un panel de administración aparte.
- ¿Qué generador de sitios estáticos usa?
- Astro por defecto: el scaffold de jtakeit crea un proyecto Astro con la comprobación del catálogo, los formularios y los specimens integrados, y lo compila en menos de un minuto. Cualquier otro generador estático funciona igual —Next.js como export estático, Nuxt, SvelteKit, Eleventy o Vite—, organizado según el mismo contrato, en unos 90 segundos por build. En ambos casos cada página se prerrenderiza a HTML en el build —componentes de React, Vue o Svelte incluidos— y no hay plugins, ni PHP, ni base de datos en el sitio.
- ¿Puede el cliente romper el diseño?
- No. El propietario solo puede rellenar los campos que declara el catálogo, y no hay botón de añadir página ni de añadir bloque. Cambiar la estructura es un commit, hecho por ti o por tu agente de IA.
- ¿Qué pasa con el contenido si el cliente se va?
- El sitio es un repositorio git que tienes tú, con el contenido dentro. El traspaso es un enlace, y las consultas y las reservas del cliente se exportan en CSV y JSON. Exportar nunca exige una suscripción activa, y nada se borra porque una venza.
07/ prueba gratis
Pruébalo en un sitio de cliente real
Regístrate en el panel y crea tu primer sitio de cliente. Crearlo y verlo en vista previa no cuesta nada: pagas un precio mayorista solo cuando un sitio se lanza.
Prueba gratisadmin.jtakeit.com
- Gratis hasta que un sitio se lanza
- Después, un precio mayorista por sitio activo, desde €5 al mes
- El código se queda en tu repositorio git