La idea: tener un blog simple, no un WordPress que mantener
Este sitio está montado con una idea bastante clara: simpleza antes que potencia innecesaria.
Como expliqué en la primera entrada, quería tener un sitio propio para escribir sobre lo que hago, investigo o me interesa, pero sin convertirlo en otro proyecto enorme que mantener.
No quería montar un CMS completo para esto. WordPress, Ghost, Drupal y compañía tienen su sitio, pero aquí me parecían demasiado aparato. Un panel de administración, una base de datos, usuarios, plugins, actualizaciones, temas, cachés, copias de seguridad, seguridad extra... todo eso tiene sentido cuando el proyecto lo pide. Para un blog personal donde escribo entradas, páginas sueltas y poco más, me sobraba casi todo.
Me apetecía algo más bruto y más controlable: escribir en Markdown, ejecutar un comando y obtener una carpeta con HTML estático lista para publicar.
Sin panel ni base de datos. Sin complicaciones.
El contenido vive en Markdown
Las entradas están en content/posts/ y las páginas en content/pages/. Cada fichero es un .md normal con una cabecera en YAML al principio:
---
title: "Título de la entrada"
date: "2026-05-24"
tags: ["devlog", "python", "markdown"]
summary: "Resumen corto de la entrada."
slug: "titulo-de-la-entrada"
draft: false
---
Con eso el generador ya tiene bastante: título, fecha, etiquetas, resumen, URL y si debe publicar la entrada o dejarla como borrador.
Después de esa cabecera viene el contenido en Markdown de toda la vida. Puedo escribir con cualquier editor, versionar los textos con Git y corregir una entrada sin entrar en ninguna interfaz web.
Un script de Python hace de generador
El corazón del sitio es build.py, un script en Python que hace la generación:
- Limpia la carpeta
dist/. - Copia los archivos de
static/. - Lee las entradas y páginas desde
content/. - Convierte Markdown a HTML.
- Renderiza las plantillas con Jinja.
- Genera la portada paginada.
- Genera páginas individuales para cada post.
- Genera páginas de etiquetas.
- Genera
feed.xml. - Genera
sitemap.xml.
El proceso acaba ahí. El resultado son ficheros estáticos, sin servidor de aplicación ni nada que mantener en producción.
Cuando quiero regenerar el sitio, ejecuto:
python build.py
El resultado queda en dist/, la carpeta final que se puede subir al hosting.
Las plantillas separan contenido y presentación
La parte visual vive en templates/. Uso Jinja porque es sencillo, conocido y suficiente para este tipo de proyecto.
La plantilla base está en base.html: ahí está la estructura común del sitio, el <head>, los metadatos, la navegación, el RSS, los estilos y el pie. Luego hay plantillas para la portada, las entradas, las páginas y las etiquetas.
Así puedo tocar el diseño desde las plantillas y seguir escribiendo entradas sin repetir HTML a mano.
Los archivos estáticos van aparte
Todo lo que no se genera desde Markdown vive en static/: CSS, imágenes, favicon, robots.txt, página 404 y cosas similares.
Durante la generación, el script copia esa carpeta dentro de dist/. El resultado final ya incluye todo lo necesario para funcionar como una web estática normal.
Tags, RSS y sitemap sin complicarse
Aunque el sistema es pequeño, tiene algunas comodidades que quería tener desde el principio.
Las etiquetas se calculan a partir del front matter de cada entrada. Si una entrada tiene tags: ["linux", "steam"], el generador la mete automáticamente en sus páginas de etiqueta correspondientes.
También se genera un feed.xml. El RSS sigue siendo una forma estupenda de seguir blogs sin depender de redes sociales ni algoritmos.
El sitemap.xml sale del mismo proceso y ayuda a que los buscadores encuentren las URLs principales y sus fechas de actualización.
Todo esto sale de leer ficheros y escribir HTML/XML. No hace falta instalar un plugin para cada cosa.
Lo bueno de hacerlo así
La ventaja principal es que el sitio es muy fácil de mantener.
Si algo falla, el problema suele estar en uno de estos sitios:
- El Markdown de una entrada.
- El front matter.
- Una plantilla de Jinja.
- El CSS.
- El propio
build.py.
Me ahorro una parte importante del ruido típico de un CMS: tablas que migran, plugins incompatibles, actualizaciones que cambian medio panel o temas que arrastran dependencias que no controlo.
Además, al generar HTML estático, la web final es rápida, barata de servir y con una superficie de ataque muy pequeña. En producción solo quedan ficheros.
Lo malo también existe
Claro, esto tiene renuncias.
No tengo editor visual, programación de publicaciones desde un panel, comentarios integrados, búsqueda avanzada ni subida de imágenes desde el navegador. Si quiero una funcionalidad nueva, tengo que construirla o integrarla yo.
Esa limitación me encaja. Prefiero añadir piezas cuando las necesite antes que empezar con un sistema enorme y pasarme la vida desactivando cosas.
Para este sitio, el coste de no tener CMS es menor que el coste mental de mantener uno completo.
Un blog como carpeta de texto
Este blog es casi eso: una carpeta de textos, unas plantillas y un script que lo convierte todo en una web.
No pretende ser un producto ni una plataforma. Es una herramienta pequeña para publicar lo que escribo con el menor ruido posible.
Cuanto más lo uso, más claro tengo que esa era la decisión correcta para mí. Podría haber montado algo más sofisticado, claro. El problema es que entonces acabaría dedicando demasiada energía a mantener el sistema en vez de escribir en él.