Caso: de WordPress a un sitio hecho a la medida, qué cambió

Lo que cambió, medido, fue qué hay detrás del sitio: del WordPress con sus plugins, su base de datos y su panel pasamos a un puñado de archivos ya armados, y en el camino aparecieron errores que el sitio viejo arrastraba sin que nadie los viera. Lo que no podemos decir es que el sitio nuevo cargue más rápido o posicione mejor: no tenemos una medición de la velocidad del WordPress antes de apagarlo, y el efecto en Google no se puede separar de otros cambios. Este caso cuenta lo documentado y deja claro lo que falta.

De qué sitios hablamos

En septiembre de 2026 pasamos cinco sitios de negocios con varias sucursales de WordPress a sitios exportados como archivos estáticos: un sitio principal, el de una sucursal, un blog de posicionamiento, el de otra marca del mismo grupo y un sitio de campañas. Todo lo que sigue sale de las notas de trabajo de esos proyectos. No incluimos nada de clientes finales ni de contenido sensible.

Lo que había detrás del WordPress

El panel del hosting del sitio principal, leído el 9 de septiembre de 2026, mostraba PHP 7.4, 12 actualizaciones de plugins pendientes y 91 vulnerabilidades detectadas. Tenía cerca de veinte plugins instalados, y al inventariarlos aparecieron duplicados:

• Dos plugins de píxel de Meta a la vez, además de las etiquetas de píxel que ya vivían dentro del administrador de etiquetas de Google.
• Dos plugins de SEO activos al mismo tiempo. Compiten por escribir las mismas etiquetas de título y canónica de cada página.
• Dos plugins de respaldo y migración.
• Un plugin de formularios que cargaba su hoja de estilos y su JavaScript en páginas sin un solo formulario. Lo comprobamos revisando las seis páginas: no había ni una etiqueta de formulario.

También el tamaño: el respaldo completo del WordPress de uno de los sitios de sucursal fueron 25,781 archivos y una base de datos de 21.2 MB repartida en 42 tablas. El de otro de los sitios, 17,750 archivos y 211 MB, para un sitio de siete páginas. Ese sitio, ya migrado, se publicó con 92 archivos. No decimos que 92 sea «mejor» que 17,750: los respaldos incluyen imágenes y temas que el sitio nuevo ya no necesita. Decimos que son cantidades que alguien tiene que mantener y vigilar.

Lo que apareció al migrar

Las direcciones llevaban «index.php» en medio

En el sitio principal, las cinco páginas internas solo existían con «index.php» en la ruta: la dirección limpia daba error 404. Esas eran las direcciones de los anuncios. Solo una de ellas recibía unos 642 clics de anuncios por semana. Publicar rutas limpias sin más habría mandado tráfico pagado a un error desde el primer minuto. La solución fue una redirección permanente que quita el prefijo y conserva el resto de la dirección, incluido el identificador que Google Ads agrega para medir qué anuncio trajo cada visita. Se verificó en producción, ruta por ruta, que las viejas redirigían a las nuevas.

Una página era copia exacta de otra

Al respaldar el contenido de uno de los sitios apareció una página idéntica a otra byte por byte, salvo el título. El título mencionaba una ciudad y el cuerpo no la nombraba en ninguna parte. Entre las dos recibían unos 500 clics de anuncios por semana. Nadie lo había notado porque ambas se veían bien. En el sitio nuevo se escribieron con contenido propio de cada ciudad.

Botones que no decían lo que hacían

El botón del encabezado mostraba un número de teléfono, pero el enlace llevaba a otro. En otra página, dos botones de una sucursal apuntaban al número de una distinta. Es el tipo de error que se arrastra años porque nadie compara el texto con el destino. No lo corregimos «a ojo»: el sitio nuevo apunta los botones del cuerpo al único número sin ambigüedad, y queda pendiente que el negocio confirme cuál corresponde a cada sucursal.

Una medición que nunca funcionó empezó a funcionar, doble

En el WordPress de uno de los sitios, uno de los cuatro activadores de conversión de WhatsApp nunca se cumplía, porque el botón del plugin no era un enlace. En el sitio nuevo los botones sí son enlaces y ese activador empezó a disparar: cada clic registraba dos veces cada conversión. No infló los números porque las acciones estaban configuradas para contar una sola por clic, pero el día que alguien cambiara esa opción habría duplicado todo sin explicación. Se dejó un solo activador.

Cómo fue el corte

En el sitio principal el corte fue el 10 de septiembre de 2026. Se subieron 72 archivos del sitio nuevo con el WordPress todavía sirviendo; a las 09:48:45 se cambió el archivo de configuración del servidor y se renombró el archivo index.php, y se purgó el CDN, la capa de caché del hosting que puede seguir sirviendo la versión vieja. Renombrar en lugar de borrar fue a propósito: volver atrás eran dos operaciones de segundos. La ventana real de indisponibilidad fue de segundos.

Dos tropiezos que anotamos para la próxima. Primero, wp-login.php siguió respondiendo con éxito unos minutos después del corte porque la regla que lo bloqueaba tenía un defecto, y nadie que mire el sitio lo nota: hay que verificar cada archivo de entrada de WordPress, no solo la carpeta de administración. Segundo, el respaldo de uno de los sitios, que creíamos hecho, resultó ser un simple listado de archivos. Lo rehicimos completo antes de borrar nada. Verifica tus respaldos antes de apagar, no después.

A las rutas de administración les respondimos con error 410 («ya no existe»). En nuestras notas habíamos escrito que eso le avisaba a Google que no reintentara. Al revisar la documentación, Google dice que trata igual todos los errores de la familia 4xx, salvo el 429, incluidos el 404 y el 410. Por eso aquí no lo presentamos como una ventaja del 410.

Lo que cambió y lo que no podemos afirmar

Lo que cambió, por construcción: un sitio exportado como archivos no tiene panel de administración, base de datos ni PHP que actualizar, así que las vulnerabilidades del software viejo dejaron de aplicar donde lo borramos. El precio es real: ya no se edita desde un panel, los cambios los hacemos nosotros. Para una clínica con textos que cambian poco es un buen trueque; para un sitio con un equipo que publica todos los días, no necesariamente.

Lo que no se midió: la velocidad. No corrimos una prueba del WordPress antes de apagarlo, así que no afirmamos que el sitio nuevo sea más rápido ni cuánto. Lo que se midió pero no se puede atribuir: en el sitio de posicionamiento, Search Console mostró 3.2 clics por día entre el 11 de julio y el 31 de agosto (con WordPress), 14.6 entre el 14 y el 30 de septiembre y 14.1 entre el 1 y el 10 de octubre; las impresiones pasaron de 266 a 1,176 por día. El salto llegó dos días después de la migración, pero en esas semanas también se publicaron artículos nuevos. No podemos separar los efectos y no vas a leer aquí que migrar sube tu posición.

Un detalle más: el sitemap viejo de WordPress, con 136 direcciones, siguió apareciendo en Search Console como «no se ha podido obtener» hasta que lo quitamos el 26 de octubre y enviamos el nuevo. Las 96 direcciones viejas de ese sitio se habían redirigido de forma permanente, que es lo que Google recomienda cuando una dirección cambia.

En resumen

Migrar de WordPress destapó duplicados, direcciones que se iban a romper y errores de medición, y dejó un sitio sin panel ni plugins que mantener. No demostró que cargue más rápido ni que posicione mejor. Si tu WordPress lo mantiene alguien de confianza y no te estorba, no migres por moda. Si no sabes qué carga, empieza por el inventario.