Sacamos nuestro propio sitio de WordPress
Esto es un relato, con WordPress tratado con justicia. El relato de qué estaba realmente mal en nuestro sitio viejo, qué nos dio la mudanza y en qué casos seguimos recomendando WordPress hoy.
Antes que nada, para que quede clara la dirección: WordPress es un buen software. Según W3Techs corre en el 40.7 por ciento de todos los sitios web y en el 58.9 por ciento de los sitios con gestor de contenidos conocido (al 7 de septiembre de 2026). Eso no pasa por casualidad. Seguimos construyendo sitios en WordPress para clientes donde encaja.
Nuestro propio sitio ya no corre ahí desde julio de 2026. Aquí está por qué y qué nos dio. Con las partes incómodas incluidas.
Qué estaba realmente mal en nuestro sitio viejo
Antes de mudarnos hicimos inventario. El resultado fue aleccionador, y lo interesante es esto: casi nada de eso era culpa de WordPress.
| Hallazgo | ¿Era WordPress? |
|---|---|
| 10 de 14 páginas sin descripción para buscadores | No, nunca se llenó |
| 3 páginas sin encabezado h1 | No, estructura de la página |
| 2 páginas de prueba públicas y en el sitemap | No, se olvidaron |
| Una página ajena al tema en el índice | No, se olvidó |
| Sin hreflang aunque existía versión en español | En parte, WordPress no lo hace sin extensión |
Páginas en español declarando lang="de" |
En parte, lo mismo |
| Seis logos de clientes con el mismo texto alternativo | No, pasó al capturar contenidos |
| Dos tipografías ajenas y dos de iconos como lastre | Sí, restos de plantilla y extensiones |
Ocho hallazgos, y seis los habríamos podido corregir en WordPress igual de bien que en cualquier otro lado. Quien compra software nuevo para resolver un problema de mantenimiento termina con un problema de mantenimiento y software nuevo.
Es la frase más honesta de este artículo, y aplica a la mayoría de los cambios de los que nos enteramos.
Qué inclinó la balanza de todos modos
Dos cosas, y ambas tienen que ver con la operación diaria.
La cantidad de piezas móviles
Nuestro sitio viejo corría sobre una plantilla comprada con su propio constructor, una plantilla hija, una extensión para el constructor y varias extensiones más. Cada una recibe actualizaciones, cada una puede romperse y cada una puede tener un hueco.
Los números son claros. Patchstack contó 11,334 vulnerabilidades nuevas en el ecosistema de WordPress durante 2025, un 42 por ciento más que el año anterior. Se repartieron así:
| Origen | Porcentaje |
|---|---|
| Extensiones | 91 % |
| Plantillas | 9 % |
| Núcleo de WordPress | 6 en total, todas de riesgo bajo |
O sea que el núcleo no es el problema. El problema es el conjunto alrededor, y crece con cada deseo que uno se cumple rápido. Un número más explica la presión de tiempo: el 46 por ciento de las vulnerabilidades no tenía corrección al momento de hacerse públicas, y en las más atacadas el tiempo mediano hasta el primer ataque es de cinco horas.
Es manejable. Requiere actualizaciones automáticas, respaldos que de verdad se puedan restaurar y alguien que revise. Para un sitio de cliente con presupuesto de mantenimiento ese es el camino normal. Para nuestro propio sitio preferimos no tener la tarea.
Construir en vez de operar
La segunda razón es gusto, y lo escribimos como tal. Con una plantilla de constructor el diseño vive en una interfaz y en una base de datos. Cambiar algo significa hacer clic. Entender por qué algo se ve de cierta forma significa recorrer capas a clics.
Nosotros queríamos el diseño en texto claro, versionado, con historial. No es un requisito universal, es el nuestro. Para quien quiere armar su sitio a clics es justo el camino equivocado.
Qué nos dio la mudanza
Nos mudamos a un sistema de archivos planos que guarda el contenido en archivos de texto en lugar de una base de datos. Medido hoy en la portada:
| Medida | Hoy |
|---|---|
| HTML, comprimido | 17 KB |
| Hojas de estilo | 1 de la plantilla, 114 KB en bruto, 39 KB transferidos |
| Archivos de tipografía | 1, 27 KB |
| Archivos de JavaScript | 0 |
| Base de datos | ninguna |
Las dos últimas filas son el cambio real. Ni un solo archivo de JavaScript, todo el comportamiento de la página cabe en tres bloques cortos dentro del código. Y sin base de datos no hay respaldo de base de datos, ni servidor de base de datos, ni procedimiento de restauración, ni usuario con permisos de más.
El archivo de tipografía es buen ejemplo de lo que cambia de paso. El sitio viejo cargaba cuatro tipografías: la de la marca, dos ajenas que quedaron de extensiones y dos de iconos. Hoy es una, recortada a los caracteres que necesitan tres idiomas.
La operación ahora se ve así: los cambios llegan al servidor por git, no hay actualizaciones de extensiones y el respaldo es una copia de una carpeta.
Qué empeoró
Esta es la sección que otros relatos suelen omitir.
El mercado de soluciones listas es diminuto. WordPress tiene más de 60,000 extensiones. Lo que nos faltaba lo tuvimos que construir: la conexión con buscadores, la administración de los envíos de formulario. Eso fue trabajo que en WordPress habrían sido dos clics.
El grupo de gente disponible es más chico. Quien tiene un sitio en WordPress encuentra a alguien que lo retome en cualquier lado. Con un sistema menos común ese círculo es mucho más estrecho. Es un riesgo real, y quien decide por un cliente tiene que decirlo.
No hay constructor visual. Las secciones nuevas se hacen en código. Textos, imágenes y todo el contenido se siguen editando en el panel, el diseño mismo no.
Una mudanza cuesta más o menos lo que cuesta reconstruir. Cada página se toca una vez, cada dirección necesita una redirección. Lo que eso implica está en nuestro artículo sobre el relanzamiento.
Cuándo WordPress sigue siendo lo correcto
| Situación | Recomendación |
|---|---|
| Varias personas mantienen contenidos, con permisos distintos | WordPress |
| Tienda en línea con WooCommerce | WordPress |
| Funciones nuevas con frecuencia, sin desarrollo a la medida | WordPress |
| En la empresa ya hay quien sepa WordPress | WordPress |
| Cinco a quince páginas que cambian poco | Ambos sirven, gana el más ligero |
| El objetivo principal es el mínimo esfuerzo continuo | Archivos planos o estático |
| Sin presupuesto para mantenimiento | Archivos planos o estático |
| Multiidioma desde el primer día | Revisar qué hace el sistema sin extensiones |
La fila del presupuesto de mantenimiento que falta es la que más nos importa. Un sitio de WordPress sin cuidado es a la larga la variante más cara de todas, porque el trabajo se acumula y regresa como falla.
Las cuatro preguntas que deciden
Después de esta mudanza plantearíamos la pregunta de otra forma. En vez de "qué gestor de contenidos", mejor:
- ¿Cuántas piezas del sitio reciben actualizaciones propias? Cada pieza es una fecha y un riesgo.
- ¿Quién revisa y cada cuánto? Si la respuesta es nadie, la arquitectura tiene que compensarlo.
- ¿Qué pasa si una pieza falla? ¿Se cae el sitio o solo falta un detalle?
- ¿Quién puede retomarlo en tres años? Mientras menos común el sistema, más importa la documentación.
Quien responde esas cuatro llega a WordPress o a otro lado, y en ambos casos es una decisión y no una costumbre.
Si estás pensando si te conviene cambiar, escríbenos con la dirección de tu sitio. Vemos cuántas piezas móviles tiene y te decimos con honestidad si sale la cuenta. Muchas veces la respuesta es no.
Fuentes
Vigencia de este artículo
Sin cambios de fondo desde su publicación.
Preguntas frecuentes sobre la mudanza
¿WordPress es inseguro?
El núcleo de WordPress está bien mantenido. De las 11,334 vulnerabilidades que Patchstack registró en el ecosistema de WordPress durante 2025, seis estaban en el núcleo y el 91 por ciento en extensiones. El riesgo está en el conjunto que se le agrega y crece con cada extensión. Un sitio de WordPress con cinco extensiones bien mantenidas es algo muy distinto de uno con treinta.
¿Qué es un CMS de archivos planos?
Un gestor de contenidos que guarda el contenido en archivos de texto en el disco en lugar de una base de datos. Cada página es un archivo con el texto y unos campos arriba. La ventaja es la poca cantidad de piezas móviles: sin base de datos, sin servidor de base de datos, sin respaldos que dependan de ella. La desventaja es un mercado mucho menor de extensiones listas y menos gente que lo conoce.
¿Vale la pena cambiar un sitio existente?
Normalmente no como proyecto aparte. Un cambio de sistema cuesta más o menos lo que cuesta reconstruir, porque cada página se toca una vez. Tiene sentido cuando de todos modos toca un relanzamiento, o cuando el esfuerzo continuo por actualizaciones y fallas supera claramente lo que el sitio aporta. Si el sitio funciona y no da trabajo, el mejor momento para cambiar es nunca.
¿Puedo seguir editando mis contenidos sin WordPress?
Sí. Otros sistemas también traen un área de edición donde se cambian textos e imágenes sin conocimientos técnicos. La diferencia está menos en editar que en ampliar: en WordPress instalas una función nueva con dos clics, en otro lado alguien tiene que construirla.
¿Cuándo seguirían recomendando WordPress?
Cuando varias personas distintas mantienen contenidos, cuando hay una tienda con WooCommerce, cuando se agregan funciones nuevas con frecuencia, o cuando en la empresa ya hay alguien que sabe WordPress. En esos casos el ecosistema grande es justo la ventaja para la que fue hecho.
¿Cuántas extensiones son demasiadas?
No hay un número fijo, pero sí una buena prueba: ¿puedes decir qué hace cada extensión y cuándo se actualizó por última vez? Si no, son demasiadas. Lo que lleva más de un año sin actualización merece revisión y, en la duda, reemplazo.