Alojamos WordPress para vivir. Lo borramos de nuestro propio sitio.

Equipo RemarkableCloud

Sí, leíste bien el título. Operamos una empresa de hosting gestionado. Una parte importante de los servidores que cuidamos a las 3 a.m. corre WordPress, y con gusto te venderemos mañana un Cube afinado para él. Y en 2026 tomamos nuestro propio sitio web, quince años de costumbre WordPress, y lo reemplazamos con un sitio estático construido en Astro.

Esta es la historia de por qué, qué ganamos, qué perdimos honestamente, y por qué el dinero (unos $1,000 al año en licencias de plugins) nunca fue el punto.

¿Por qué una empresa de hosting dejaría WordPress?

Porque nuestro sitio web dejó de ser un sitio web y se convirtió en un catálogo de productos con opiniones. Unas 300 páginas en dos idiomas: 47 páginas de apps de un clic, 12 páginas de paneles de control, 20 comparativas contra competidores, un sistema de precios que debe cuadrar al centavo con nuestra plataforma de facturación, y documentación que cambia cuando ingeniería publica, no cuando marketing se acuerda.

WordPress es un gestor de contenidos. Nuestro problema no era gestionar contenido. Nuestro problema era gestionar la verdad: un precio, una especificación, una afirmación, mostrados idénticos en inglés y español a través de cientos de páginas, para siempre.

En el stack anterior, la verdad se mantenía a mano, y las manos fallan. Durante una auditoría SEO del sitio viejo encontramos meta descripciones cortadas a media palabra exactamente en el carácter 158 en más de 15 páginas por un bug de plantilla, un título que decía “WordPres” en Google durante meses, y resultados de búsqueda citando precios 80 por ciento más altos que la página real porque dos sistemas no se ponían de acuerdo en cuánto cobramos. Nada de eso era culpa de WordPress, exactamente. Todo era el resultado predecible de un stack donde cada página es un objeto artesanal editado por el último que lo tocó.

¿Cómo es el stack nuevo?

Astro, generando HTML estático desde archivos de datos, desplegado automáticamente con cada push a git. El titular menos glamoroso: nuestro sitio web ahora tiene una suite de QA.

Un archivo JSON describe las 47 apps: nombres, requisitos de RAM, categorías, traducciones. Las páginas de apps se generan desde ahí. El carrito lee un archivo generado de la misma fuente. Cuando agregamos una app, la página en inglés, la página en español y el formulario de pedido no pueden contradecirse, porque no hay nada que contradecir. Hay un solo hecho, y todo lo demás lo muestra.

Y el build se niega a publicar ciertos errores. Falla con un precio desactualizado. Falla si una página en español olvida que es español. Falla con caracteres tipográficos que nuestra guía de estilo prohíbe. Una clase de bug que antes descubrían ingenieros avergonzados leyendo resultados de Google ahora no puede existir. Intenta cablear eso en un page builder.

Los números: así se ve un puntaje perfecto

El 28 de agosto de 2026, PageSpeed Insights calificó la página principal con 100 en las cuatro categorías: Rendimiento, Accesibilidad, Mejores Prácticas y SEO.

Las métricas detrás: First Contentful Paint 0.5s. Largest Contentful Paint 0.5s. Total Blocking Time 0 ms. Cumulative Layout Shift 0.004. Speed Index 0.6s.

Y aquí viene la parte que nos parece genuinamente graciosa: ese puntaje se midió sin plugin de caché y sin CDN frente a la página. Vendemos licencias de LiteSpeed. Operamos infraestructura de CDN. El sitio nuevo no necesitó ninguna de las dos para llegar a 100, porque el stack de optimización más rápido del mundo sigue siendo más lento que no tener nada que optimizar. El sitio viejo necesitaba una capa de caché para sentirse aceptable. El nuevo simplemente está… listo, antes de que la caché hubiera calentado.

Cero milisegundos de bloqueo no es un logro de afinación. Es lo que pasa cuando tu sitio de marketing deja de enviar una aplicación JavaScript a gente que vino a leer una tabla de precios.

¿Qué dejamos de pagar?

Elementor Pro. Rank Math Pro. La suscripción del plugin de traducción. En conjunto, unos $1,000 al año, fuera.

Y queremos ser precisos aquí, porque “ahorramos dinero” es la parte menos interesante de esta historia: mil dólares al año es el almuerzo de una empresa, y si esas licencias hubieran hecho mejor el sitio las pagaríamos felices. No migramos para ahorrar $83 al mes. Migramos porque cada una de esas suscripciones existía para compensar un desajuste entre la herramienta y el trabajo, y los visitantes eran quienes pagaban el precio real, en tiempo de carga, en saltos de layout, en precios desactualizados.

El dinero es una nota al pie. La experiencia es la historia.

La parte picante: lo que pensamos ahora

Habiendo vivido en ambos lados, algunas conclusiones contra las que habríamos discutido hace dos años:

Un page builder es deuda técnica con interfaz amigable. Cada widget es markup que no controlas, CSS que no escribiste y JavaScript que no puedes quitar. Una vez perdimos una tarde porque el sanitizador de WordPress se comía en silencio las etiquetas <style> de un widget al guardar. La página quedó mostrando markup crudo sin menú. Eso no es un bug que arreglas; es una relación que abandonas.

La mayoría de los sitios de empresa no necesita una base de datos. Si tus páginas cambian cuando tú decides que cambien, estás sirviendo archivos y pagando por una base de datos, un runtime PHP, una capa de caché para esconder la base de datos, y una industria de seguridad para proteger la torre completa. Un folleto fingiendo ser una aplicación.

La economía de plugins es un impuesto a la indecisión. Plugin de SEO, plugin de caché, plugin de traducción, plugin de formularios, cada uno una suscripción, un ciclo de actualizaciones y una superficie de ataque, cada uno parchando la brecha entre lo que la plataforma es y lo que realmente necesitabas.

“Pero los editores necesitan herramientas visuales” es cierto para quizá una décima parte de los sitios que las usan. Sé honesto sobre quién edita tu sitio y con qué frecuencia. El nuestro lo edita gente que ya vive en git.

Lo que perdimos, sin hoja de parra

El editor visual se fue, y esa pérdida es real.

Cada artículo de este sitio, incluido este, se escribe ahora en Markdown. Cada cambio es un commit. No hay un botón que un compañero no técnico pueda presionar para corregir un error de dedo a las 9 p.m. desde el teléfono. Acostumbrarse a escribir solo en Markdown tomó tiempo, y hubo momentos al principio en que arrastrar un bloque en Elementor por treinta segundos sonaba bastante bien comparado con pelear una tabla a mano.

Si tu sitio lo editan a diario marketers, escritores y encargados de tienda, este cambio es un error para ti, punto. Esa no es una frase de consolación; es la línea divisoria real.

Entonces, ¿deberías dejar WordPress?

Pregunta equivocada. La correcta: ¿qué es tu sitio web, realmente?

Si es una operación viva de contenido (una tienda, una publicación, un sitio de membresías, cualquier cosa donde gente no técnica crea a diario) entonces WordPress sigue siendo la mejor herramienta jamás construida para ese trabajo, y lo sabemos bien: alojamos miles de estos sitios, afinamos LiteSpeed para ellos, y seguiremos recomendándolo sin ironía.

Si es un sitio de producto mantenido por gente que escribe código (páginas que cambian por decisión, precios que deben cuadrar con un sistema de facturación, contenido generado desde datos) entonces tienes en las manos un folleto que se cree aplicación, y cada plugin que agregas es una disculpa por el desajuste.

Nosotros éramos el segundo tipo fingiendo ser el primero. El puntaje perfecto, el cero bloqueo, las suscripciones borradas: todo es consecuencia de admitir esa única frase.

Nuestros clientes de WordPress, mientras tanto, también ganan algo con esto: su host ahora entiende, por experiencia vivida en ambos stacks, exactamente dónde brilla cada uno. Eso vale más que una insignia de 100.