Migrar de WordPress a un sitio estático: el caso de esta web, con lo que no mejoró

Respuesta breve

Migrar de WordPress a un sitio estático cambia menos de lo que se anuncia en velocidad y bastante más de lo que se cuenta en operación. En esta web la comparación que motivó la decisión resultó estar mal atribuida: el sitio estático que servía de referencia respondía mejor, pero la ventaja coincidía con no pasar por la capa de caché del proveedor, no con la tecnología. Lo que sí cambió de forma clara fue la superficie que hay que mantener y el control sobre lo que se sirve. Y lo que se rompió fue publicar: en un sitio estático el reloj editorial deja de vivir en el servidor y pasa a depender de que alguien compile.

Puntos clave

• La medición que parecía justificar la migración medía otra cosa: la diferencia venía de la capa de caché intermedia, no del gestor de contenidos.
• Una medición sin repetición no es una medición. La primera lectura daba una diferencia enorme entre dos webs idénticas; con seis tomas y mediana, no había diferencia.
• Lo que se retira no se borra: el WordPress quedó movido en el mismo servidor, con su base de datos volcada y las instrucciones de vuelta atrás escritas.
• Cambiar la estructura de URLs es la parte cara de cualquier migración. Aquí los artículos vivían en la raíz y pasaron a una carpeta, con redirecciones permanentes generadas en cada compilación.
• Publicar deja de ser entrar en un escritorio. Eso hay que resolverlo antes de conmutar, no después.
• Un sitio estático no te libra de lo que cargas en el navegador: esta web servía cientos de kilobytes de terceros que no dependían del gestor.

Por qué se planteó

El punto de partida no fue una queja de velocidad de nadie, sino una comparación entre webs propias que compartían servidor. Dos de ellas funcionaban con WordPress y una tercera, más reciente, con un generador estático. La tercera respondía notablemente mejor, y la conclusión cómoda era la evidente: el gestor de contenidos pesa.

La conclusión cómoda casi siempre es la que hay que medir primero. Antes de decidir nada se tomaron seis lecturas del tiempo hasta el primer byte de cada web y se calculó la mediana, porque una lectura suelta en una red doméstica no distingue una web lenta de un segundo malo. Ese detalle no es pedantería: una lectura anterior, tomada una sola vez, daba entre las dos webs de WordPress una diferencia de más del triple. Con seis tomas, esa diferencia desapareció.

Lo que dijo la medición

Las dos webs con WordPress rendían igual entre sí. La web estática rendía mejor que las dos. Y la web estática era, además, la única que no pasaba por la capa de caché que el proveedor coloca delante de los dominios.

La comprobación decisiva fue medir desde el propio servidor, sin esa capa en medio. Ahí las dos webs de WordPress respondían en unos nueve milisegundos. El origen no era el problema. La cabecera que el propio proveedor añade a la respuesta declaraba un tiempo de subida al origen de casi medio segundo para un origen que contestaba en nueve milisegundos.

Dicho de otro modo: la capa que se vende como aceleradora estaba añadiendo el retraso, y la ventaja del sitio estático coincidía exactamente con quién la tenía activada. Atribuir esa diferencia a la tecnología habría sido publicar una causa falsa, y sobre esa causa falsa se habría justificado el trabajo.

Entonces por qué migrar

Porque la velocidad no era la única razón, y resultó no ser la buena. Las razones que quedaron en pie son de mantenimiento y de control:

• Superficie que actualizar. El WordPress retirado ocupaba doscientos veintinueve megabytes de ficheros y veintiuna tablas de base de datos para servir cincuenta artículos y veintitrés páginas. Cuatro plugins activos, cada uno con su ciclo de actualizaciones y su posibilidad de romper algo un martes por la mañana.
• Control de lo que se emite. El marcado de datos estructurados, las etiquetas de la cabecera y las redirecciones pasan a estar en el repositorio, versionados y comprobables antes de publicar, en lugar de repartidos entre ajustes de plugin y campos de administración.
• Comprobaciones antes de publicar. Un sitio compilado permite pasar controles sobre el resultado exacto que va a recibir el visitante, y no subir nada si alguno falla. Eso en un gestor dinámico es mucho más difícil de garantizar.

Ninguna de esas tres razones es «va más rápido». Merece la pena decirlo porque es lo que más se lee sobre este tipo de migraciones.

La parte cara: las URLs

El coste real de esta migración no estuvo en el diseño ni en el contenido, sino en las direcciones. Los cincuenta artículos se servían en la raíz del dominio, que es como Google los tenía indexados y como los listaba el mapa del sitio. La estructura nueva los coloca en una carpeta.

Un cambio así se paga en posiciones si se hace mal. Lo que evita el daño no es la buena intención, sino que cada dirección antigua responda con una redirección permanente hacia la nueva, que esa redirección sea directa y no una cadena, y que el mapa del sitio y los enlaces internos apunten ya a la dirección definitiva.

Aquí las redirecciones no se escribieron a mano. Se generan en cada compilación a partir de la lista real de artículos, y hay una comprobación que impide subir nada si el fichero de configuración del servidor se ha quedado sin sustituir. La razón es sencilla: una lista escrita a mano envejece en cuanto se publica el artículo cincuenta y uno, y nadie se acuerda.

Lo que se rompió

Publicar. En WordPress, un artículo programado sale porque el servidor tiene un reloj. En un sitio estático no hay servidor que ejecute nada: la página existe porque alguien compiló el sitio después de que llegara la fecha. Si ese alguien es una tarea programada en un ordenador, el reloj editorial depende de que ese ordenador esté encendido.

En esta web la tarea que publica los artículos programados se creó desactivada, días antes de conmutar, y nadie la activó. No se rompió nada visible: simplemente faltaban páginas que nunca llegaron a existir, y eso no genera ningún error que alguien pueda ver. Se descubrió mirando el registro de ejecuciones, que estaba vacío.

La conclusión operativa es que en una migración a estático el mecanismo de publicación es parte del alcance, no un detalle posterior. Y necesita su propia vigilancia: algo externo que compare lo que el calendario dice que debería estar publicado con lo que el sitio sirve de verdad.

Lo que no arregla una migración

Un sitio estático controla lo que tú envías, no lo que cargas de terceros. Cinco días después de conmutar, esta misma web servía en su portada cientos de kilobytes de una librería de medición externa, y lo hacía en la primera carga, antes de que el visitante decidiera nada sobre las cookies.

Ese comportamiento no tenía relación con WordPress ni con el generador estático: dependía de cómo estaba insertada la etiqueta. Se corrigió cargando esa librería solo después del consentimiento. La lección es que el peso y la privacidad de una página se miden contando peticiones de red en un navegador, y que ningún cambio de tecnología los arregla por sí solo.

En tres láminas

50 artículos que cambiaron de URL. Se servían en la raíz del dominio, que es como Google los tenía indexados. Sin una redirección por pieza, la migración los convierte en 404.

curl -sI https://seonidas.com/blog. HTTP/1.1 301 / location: https://seonidas.com/blog/. Leído el 10 de septiembre de 2026.

medición: tomas de tiempo de respuesta el mismo día / 263 ms … 15.681 ms / / # con esa dispersión, publicar una mejora / # habría sido inventarla: no se publica / # van las cifras estructurales, que no / # dependen de la red

Errores frecuentes

• Atribuir a la tecnología una diferencia que produce la capa de caché. Se comprueba midiendo desde el propio servidor, sin intermediarios.
• Decidir con una sola lectura. Sin repetición y mediana, se está midiendo el momento, no la web.
• Borrar el sitio anterior al conmutar. Mover y conservar cuesta lo mismo y permite volver atrás el mismo día.
• Escribir las redirecciones a mano. La lista envejece con el siguiente artículo publicado.
• Dejar redirecciones encadenadas. Cada salto añade latencia y diluye la señal; la antigua debe apuntar directamente a la definitiva.
• Conmutar sin resolver cómo se publica. El calendario editorial deja de tener reloj propio y nadie se entera hasta semanas después.
• Dar por hecho que estático significa ligero. Un solo script de terceros puede pesar más que toda la plantilla.
• Migrar sin conservar los metadatos propios. Títulos, descripciones y canónicas escritas a mano son trabajo acumulado que no se recupera solo.

Preguntas habituales

¿Migrar a un sitio estático mejora el posicionamiento?

Por sí solo, no. Puede mejorar la experiencia de carga si la lentitud venía del gestor, y puede empeorar las posiciones si el cambio de direcciones se ejecuta mal. Lo que sí aporta es control: se puede comprobar antes de publicar exactamente lo que recibirá el visitante y el buscador, y eso reduce la clase de errores que pasan meses sin detectarse.

¿Cómo se sabe si la lentitud viene del gestor o de otra capa?

Midiendo el origen sin intermediarios. Si el servidor responde en milisegundos y el visitante espera cientos, el problema está entre medias, y cambiar el gestor no lo va a tocar. Es una comprobación de dos minutos que evita justificar semanas de trabajo con una causa equivocada.

¿Qué se hace con el sitio antiguo?

Se mueve fuera de la carpeta pública y se conserva, con la base de datos volcada y unas instrucciones escritas de cómo volver atrás. Borrarlo el día de la conmutación no ahorra nada relevante y convierte cualquier imprevisto de las primeras semanas en un problema sin salida.

¿Y si el sitio necesita partes interactivas?

Se reescriben para que funcionen en el navegador o se dejan en un servicio aparte. Conviene inventariarlas antes de decidir la migración, porque suelen ser la parte que más tiempo consume y la que más fácilmente se olvida al planificar.

Próximo paso

Antes de plantear una migración así, haz la medición que la puede desmontar: seis lecturas del tiempo de respuesta desde fuera y otras seis desde el propio servidor. Si la diferencia está en la capa intermedia, ya sabes qué tocar y no hace falta migrar nada. Si decides seguir adelante, escribe primero el mapa de direcciones antiguas a nuevas, decide cómo se van a publicar los contenidos programados y prueba ese mecanismo de extremo a extremo antes de conmutar. Y conserva el sitio anterior movido, no borrado, al menos hasta que el buscador haya procesado las redirecciones.

Fuentes

• Google Search Central, migraciones de sitio con cambios de URL — guía oficial.
• Google Search Central, redirecciones y Google Search — tipos y efectos.
• web.dev, Core Web Vitals — definición de las métricas.
• Agencia Española de Protección de Datos, guía sobre el uso de cookies — documento oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo para wordpress es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo para wordpress