Migración de WordPress a estático
Quédate la web. Retira el servidor de debajo.
Tu web va lenta, se cae justo cuando llega tráfico, pide actualizaciones cada semana y te cobra un hosting todos los meses. El problema no es tu web: es el servidor que tiene debajo. Nosotros generamos tus páginas una vez y las servimos desde la red de AWS, sin máquina que mantener. Mismo diseño, mismas URL, mismo CMS para tu equipo, y nada que actualizar, que se caiga ni que puedan hackear.
- Sin servidorNada que actualizar, nada que se caiga
- 99,9 %SLA de disponibilidad de AWS
- 0 €/mesHosting gratis con tráfico normal
Qué cambia de verdad
Cuatro problemas que dejan de serlo
No son cuatro mejoras. Son cuatro categorías de fallo que una arquitectura estática elimina en lugar de mitigar.
La velocidad deja de depender de tu hosting
Una página de WordPress se monta en cada petición: arranca PHP, se consulta la base de datos, los plugins filtran la salida y delante hay una caché intentando deshacerlo todo. Una página estática se montó en el build y ya está en un nodo de CDN cerca de tu visitante. No hay caché que calentar, ni plugin que retrase el primer byte, ni diferencia entre tu página más rápida y la más lenta.
Se acabaron las llamadas de «la web está caída»
AWS respalda S3 y CloudFront con un SLA de disponibilidad del 99,9 %, y eso ya es más de lo que te firma tu hosting actual. Pero lo que de verdad cambia es que no queda servidor donde caerse: sin base de datos, sin proceso PHP y sin máquina en el camino, lo que tumba una web WordPress —una consulta desbocada, un límite de memoria, la actualización de un plugin, el pico de tráfico del día que saliste en prensa— ya no tiene dónde ocurrir.
La seguridad pasa a ser el estado por defecto
No se ejecuta PHP en ninguna petición, así que no hay nada que ejecutar. No hay base de datos donde inyectar, ni un panel de acceso en tu dominio público al que hacer fuerza bruta, ni un plugin en el camino que cargue con el próximo CVE. El bucket es privado y se sirve a través de CloudFront: lo único que hay en internet es una carpeta de ficheros que no pueden hacer nada.
El hosting desaparece de tus gastos fijos
Dejas de pagar una máquina que está ociosa la mayor parte del día. CloudFront regala 1 TB de tráfico y 10 millones de peticiones al mes de forma permanente, que es más de lo que consume una web corporativa normal, así que servirla cuesta 0 €. Lo único que queda en la factura son céntimos de almacenamiento. Y si un día tienes mucho tráfico, pagas transferencia por las visitas que te están dando algo, no un plan de servidor que contrataste por adelantado por si acaso.
Un ejemplo real
Empezamos haciéndonoslo a nosotros
La web que estás leyendo era WordPress. Su home enviaba 212 KB de HTML, 48 hojas de estilo y 23 scripts, porque estaba montada en un maquetador visual que añade una petición por cada comodidad.
La nueva se genera estáticamente y se sirve desde una CDN: el mismo contenido, una fracción del peso y ningún servidor en el camino de la petición. Se trajeron todas las páginas, los 785 artículos y la taxonomía entera, en inglés, español y catalán, en más de mil URL.
Por eso podemos hablar de esto con cifras en lugar de con adjetivos, y por eso las partes incómodas de una migración son cosas con las que ya nos hemos dado nosotros, no cosas que descubriremos en tu web.
La pregunta de verdad
«¿Y esto cómo se edita?»
Es la objeción de siempre, y merece una respuesta directa y no una frase tranquilizadora, incluida la parte en la que la respuesta es que no.
Tu equipo conserva un CMS. Lo que no conserva es un servidor.
Combinamos el build estático con Pages CMS, un editor respaldado por Git. Tu equipo entra con GitHub, edita en un panel de administración normal con campos de verdad —texto, imágenes, listas, subidas— y le da a guardar. Guardar hace un commit en tu repositorio, CI reconstruye la web y la CDN sirve la página nueva. No interviene ningún desarrollador ni se abre ningún ticket. Esta web funciona exactamente así.
Lo que se pierde: la vista previa visual de arrastrar y soltar.
Pages CMS edita contenido estructurado, no un lienzo. Quien edita cambia los campos que componen una página en lugar de mover cajas por encima, y ve el resultado en un build de vista previa y no en vivo dentro del editor.
Lo que se gana en su lugar: cada edición es un commit.
Historial completo, un autor por cada cambio y la posibilidad de revertir cualquier cosa con un clic, incluida la página que alguien borró sin querer. No hay base de datos del CMS que respaldar, ni CMS que mantener parcheado, ni forma de que una edición de contenido tumbe la web, porque lo que se está sirviendo es el último build que salió bien.
A quién le decimos que se quede como está.
Si el trabajo principal de tu equipo de marketing es componer maquetas de página nuevas cada semana, un CMS respaldado por Git les va a frenar. Eso es un coste real y no un detalle, y es la razón principal por la que a algunos les quitamos la idea antes de que se comprometan, y no después.
Cómo se hace la migración
El riesgo de una migración está en el buscador, no en la ingeniería
Una web nueva que te hunde el posicionamiento te ha costado más de lo que costaba el servidor. Así que todo el proceso gira sobre una condición: nada sale a producción hasta demostrar que la web nueva equivale a la vieja, página por página.
Inventario y auditoría
Rastreamos la web en producción y sacamos sus sitemaps y su contenido por REST para construir la lista completa de lo que existe: cada URL, sus metadatos, su canónica, sus alternativas de idioma y lo que ya redirige. Es el documento contra el que se mide todo lo demás, y es tuyo vayas adelante o no.
Reconstruir las plantillas
Tu diseño, reconstruido como plantillas de un generador estático en lugar de como un theme. Aquí es donde sale el peso de página: el marcado del maquetador, las hojas de estilo de los plugins y los scripts que se cargaban en todas las páginas las usaran o no.
Migrar el contenido
Páginas, entradas, medios, categorías, etiquetas y traducciones se mueven como contenido estructurado, con scripts y no a copiar y pegar. El volumen es justo el motivo: unos cientos de entradas son trabajo para un script que se ejecuta igual todas las veces, no para dos semanas de reescritura a mano.
Demostrar la equivalencia antes del cambio
Las URL se mantienen idénticas siempre que pueden. Todo lo que tiene que moverse recibe un 301. Títulos, descripciones, canónicas, datos estructurados y hreflang se comparan página por página con la web antigua, y los enlaces internos se resuelven contra el build nuevo para que ninguno acabe en un 404. Es una condición para publicar, no una tarea de limpieza posterior.
Cambiar y entregar
El DNS pasa a CloudFront, el mapa de redirecciones entra en el edge y se vigila Search Console durante la transición. Recibes el repositorio, la cuenta de AWS, el CMS y la documentación. El hosting antiguo se cancela cuando estés conforme, no antes.
Qué incluye
Lo que es tuyo al día siguiente del cambio
El repositorio y la cuenta de AWS
Los dos tuyos desde el primer commit. La web la construye CI a partir de código que tienes tú, sobre infraestructura definida como código en tu cuenta. En ningún momento tu web vive dentro de nuestros sistemas y cuesta recuperarla.
El mapa de redirecciones, en el edge
Cada URL antigua que respondía la web anterior, mapeada y servida como un único 301 desde CloudFront. Un salto y no una cadena: una redirección que vuelve a redirigir es un salto que Google cuenta y una ida y vuelta que tu visitante espera.
Formularios que siguen funcionando
Los formularios de contacto y de consulta pasan a un endpoint serverless pequeño con protección antispam, en lugar de mantener vivo un servidor entero para aceptar un POST. Los envíos se validan en la frontera y llegan al buzón o al CRM al que llegaban antes.
Analítica y etiquetas, recableadas
Tag Manager, gestión del consentimiento y eventos de conversión trasladados y verificados disparando, para que los informes en los que vive tu equipo no se queden en silencio la semana del cambio.
Accesibilidad y SEO técnico
Recorridos con teclado, estados de foco, contraste y semántica probados y no afirmados. Canónicas, sitemaps, datos estructurados y hreflang generados por el build en lugar de mantenidos a mano o por un plugin.
Documentación y traspaso
Escrita para que un desarrollador nuevo sea productivo sin tener que agendar tiempo con nosotros, y una sesión con quien edita sobre el CMS que va a usar de verdad.
Preguntas frecuentes
Lo que se pregunta antes de comprometerse
¿Vamos a perder posicionamiento?
No si la migración se hace bien, y es justo aquí donde la mayoría de rediseños hacen daño. Las URL se mantienen idénticas siempre que se puede, todo lo que tiene que moverse recibe un 301 servido en el edge de la CDN, y los metadatos se comparan página por página con la web antigua antes del cambio, no por muestreo después.
La comparación de equivalencia es una condición para publicar. Si una página no cuadra, el cambio espera.
¿Y nuestra tienda WooCommerce?
Un checkout no es un problema estático, y no vamos a fingir lo contrario. Carritos, cuentas con sesión, stock en vivo y flujos de pago necesitan algo en ejecución, así que una tienda transaccional o se queda donde está o pasa a una API de comercio detrás de un front estático: un proyecto mayor que este y con otro caso de negocio.
Donde encaja este servicio en una tienda es en todo lo de alrededor: las páginas de marketing, las de categoría y contenido, el blog y las landings, que suelen ser la mayor parte de la web y todo el tráfico. Si tu tienda es la web entera, te propondríamos construirla bien en lugar de esto.
¿Y si una parte de nuestra web tiene que ser dinámica de verdad?
Entonces esa parte recibe una API pequeña y el resto se queda estático. Un buscador, un área de socios, un calendario de reservas, una calculadora de precios: cada cosa es un endpoint concreto y no una razón para mantener una instalación entera de WordPress en marcha sirviendo páginas que no cambian nunca. Nuestro propio formulario de contacto funciona así.
¿Cuánto tarda una migración?
Una web corporativa se mide normalmente en semanas. Un fondo de contenido grande depende de cuántas URL y cuántos idiomas, que es exactamente para lo que sirve el inventario del primer paso: recibes el alcance y el coste por escrito antes de comprometerte, y no una horquilla que después se va ensanchando.
¿Cuánto va a costar mantenerla después?
Con tráfico normal de web corporativa, 0 € al mes de entrega: CloudFront incluye de forma permanente 1 TB de transferencia y 10 millones de peticiones al mes, y una web corporativa rara vez se acerca a ese techo. Para ser exactos, cero del todo no es: el almacenamiento en S3 son unos céntimos y la zona de DNS ronda los 0,50 $ al mes. Comparado con lo que pagas ahora de servidor, mantenimiento y licencias de plugins, es ruido. Con mucho tráfico sí hay coste de transferencia, y escala con tus visitas. Durante la revisión modelamos tus cifras reales a partir de tu analítica actual, en lugar de darte una media.
¿Podemos dar marcha atrás si no nos convence?
Sí, y es una pregunta legítima. La web antigua sigue en pie y sin tocar hasta que estés conforme con la nueva, el DNS es lo único que se mueve, y revertirlo te deja exactamente donde estabas. Nada de la migración es destructivo con lo que tienes ahora.
¿Esto sólo vale para WordPress?
No. WordPress es el caso habitual, pero el mismo enfoque sirve para Drupal, Joomla, un maquetador visual o un PHP escrito a mano que nadie se atreve a tocar desde hace seis años. Lo que importa es si las páginas son esencialmente iguales para todas las visitas, no qué las generó.
Mándanos tu web actual
Te diremos qué la está frenando, cuánto costaría servirla en estático y si la migración te compensa, antes de que gastes nada.