¿Qué sale mal al mover un sitio de WordPress de local a producción?

El sitio es perfecto en tu portátil. Cada página carga, cada imagen es nítida y el proceso de compra funciona. Luego, lo subes al servidor en producción, lo abres en un navegador y algo no va bien.

Los entornos local y de producción son más diferentes de lo que parecen. Esa brecha es donde ocurre la mayoría de los problemas.

Duplicator es un plugin de copias de seguridad y migración de WordPress que se ejecuta en más de 1,5 millones de sitios. Una parte importante de los sitios que ejecutan Duplicator Pro son entornos locales o de desarrollo, cerca de 1 de cada 10. Eso es mucha gente creando en un portátil y enviando a un servidor en vivo.

Examinamos los tickets de soporte de personas que envían sitios de entornos locales a servidores en vivo. Los fallos son consistentes, y uno de ellos aparece mucho más aquí que en cualquier otro lugar de nuestros datos.

Estas cifras reflejan el volumen de tickets de soporte y los datos de instalación anonimizados, no el número de clientes o ventas.

Tabla de Contenidos

Hallazgos Clave

Aquí se explica lo que dicen los tickets sobre la migración de un sitio de WordPress desde el desarrollo local a un servidor en vivo. Cada cifra proviene de los propios registros de Duplicator.

• Cerca de 1 de cada 10 sitios que ejecutan Duplicator Pro son entornos locales o de desarrollo. Crear primero localmente es una práctica común, no un caso excepcional.
• Los problemas de local a en vivo representan aproximadamente 1 de cada 8 de todos los tickets de soporte de migración. Para un solo escenario, es una gran parte.
• SSL es el fallo característico de esta transferencia. Aparece en aproximadamente 1 de cada 5 tickets de local a en vivo, unas quince veces más a menudo que en los tickets de migración en general.
• Las incompatibilidades de versión de PHP son unas tres veces más altas aquí que en otras migraciones porque las herramientas locales utilizan PHP moderno, y muchos hosts en vivo se quedan atrás.
• El problema individual más común es un límite del host que detiene la instalación, no un fallo en la propia migración.
• Casi todos los fallos se remontan a una diferencia entre los dos entornos, no a la transferencia.

En resumen: Tu portátil y tu servidor en vivo suelen discrepar en cuatro cosas: versión de PHP, SSL, permisos de archivo y el dominio del sitio. Soluciona esos puntos antes de migrar, y la transferencia se realizará sin problemas.

Una advertencia que da forma a cómo leer esto. Estos son tickets de soporte, por lo que muestran dónde falla la transferencia de local a en vivo, no con qué frecuencia falla.

Muchas de estas migraciones van bien y nunca generan un ticket. Y la cifra de 1 de cada 10 describe sitios que ejecutan Duplicator Pro, no WordPress en su conjunto.

Por qué Local y Producción Están Más Lejos de lo que Parecen

Un entorno local de WordPress se crea para pruebas privadas. Un servidor en vivo se crea para Internet público. Son trabajos diferentes, y las configuraciones lo reflejan.

Cuatro diferencias causan casi todo en este informe:

• Versión de PHP. Las herramientas locales y los hosts web en vivo pueden ejecutarse con diferentes versiones predeterminadas de PHP.
• SSL. Local se ejecuta en http:// simple o con un certificado autofirmado. En vivo se espera uno real.
• Permisos de archivo. Local es permisivo porque eres el único usuario. En vivo está más restringido.
• El dominio. Tu sitio se conoce a sí mismo como algo como midominio.local. Después de la migración, ese nombre no existe.

Ya sea que uses Local, MAMP, XAMPP, Docker, o una configuración simple de localhost, los modos de fallo son los mismos porque la brecha se encuentra entre los entornos en lugar de entre las herramientas.

El Problema de SSL del que Nadie Te Advierte

El sitio aparece en el servidor en producción y falta el candado. O el diseño está roto porque la mitad de las hojas de estilo no se cargaron. O el navegador muestra una advertencia de contenido mixto y no tienes idea de a qué se refiere.

Este es el fallo más distintivo en todo el conjunto de datos. Los problemas de SSL aparecen en aproximadamente 1 de cada 5 tickets de local a producción, en comparación con aproximadamente 1 de cada 70 en los tickets de migración en general. Eso es unas quince veces la tasa normal, y la razón se reduce a la sincronización en lugar de la mudanza en sí.

Una herramienta de migración reescribe el dominio de tu sitio durante la instalación. misitio.local se convierte en t கொள்ளலாம்.com en toda la base de datos, incluso dentro de los datos serializados. Esa parte está resuelta.

El protocolo es una cuestión aparte. Si SSL no está activo en tu host de producción cuando migras, entonces http://t கொள்ளலாம்.com es la dirección correcta del sitio en ese momento. Así que eso es lo que se escribe en la base de datos.

Activa el certificado después, y tu sitio ahora está sirviendo a través de HTTPS mientras que su propia base de datos todavía dice http://. Cada recurso guardado durante el desarrollo local hereda el mismo problema, ya que ninguno de ellos necesitó HTTPS.

Nada falló. El sitio se trasladó a la dirección que tenía en ese momento.

La solución consiste principalmente en hacer las cosas en el orden correcto:

• Activa SSL en el host de producción antes de migrar. La mayoría de los hosts emiten un certificado gratuito, generalmente en una sección llamada SSL, SSL/TLS o Seguridad en el panel de control de alojamiento. Haz esto primero, y la instalación escribirá https:// desde el principio.
• Si ya te has mudado, actualiza las URL del sitio. Las encontrarás en Ajustes » Generales en el panel de WordPress, en los campos Dirección de WordPress y Dirección del sitio.
• Ejecuta una búsqueda y reemplazo de las referencias http:// que quedaron del desarrollo local para que los enlaces de recursos antiguos coincidan con el nuevo protocolo.
• Comprueba el contenido mixto. Carga el sitio en producción, abre la consola de desarrollador de tu navegador y busca advertencias sobre recursos inseguros. Indicarán los archivos exactos que todavía se cargan a través de http://.

Gestiona SSL antes de la mudanza, y un número sorprendente de problemas nunca ocurrirán.

Qué Falla en las Migraciones de Local a Producción

SSL es la razón destacada por la que las migraciones de local a producción fallan, pero no está solo. Aquí tienes otros errores que aparecen, sus causas y cómo solucionarlos.

Qué sale mal	Aproximadamente con qué frecuencia	Qué hay detrás	Cómo se resuelve
Un límite del host detiene la instalación	Lo más común	El tiempo de espera de PHP o el límite de memoria del servidor en producción que interrumpe la extracción, algo que tu portátil nunca impuso	Aumenta max_execution_time y memory_limit en el host
El sitio no es seguro después de la mudanza	Aproximadamente 1 de cada 5	SSL no estaba activo en el host en el momento de la mudanza, por lo que la dirección guardada sigue siendo http://	Activa SSL en el host antes de migrar, luego confirma que las URL del sitio usan https://
La importación de la base de datos falla	Aproximadamente 1 de cada 7	Las credenciales de la base de datos en producción no coinciden con las que creó el host	Introduce el nombre de usuario, contraseña y nombre de base de datos correctos durante la instalación
Los permisos de archivo bloquean la escritura	Aproximadamente 1 de cada 8	El entorno local es permisivo, el entorno real no lo es, por lo que la propiedad y el acceso de escritura importan de repente	Establece las carpetas en 755 y los archivos en 644 en el destino
No podrás iniciar sesión una vez que esté en producción	Aproximadamente 1 de cada 9	La URL del sitio guardada no coincide con la dirección en producción, lo que provoca un bucle de redirección	Corrige la dirección de WordPress y la dirección del sitio, luego borra las cookies
Aparecen errores de PHP en el sitio en producción	Aproximadamente 1 de cada 11	La herramienta local utiliza una versión de PHP más reciente que la que ejecuta el servidor, por lo que las funciones están obsoletas o faltan	Haz coincidir las versiones de PHP en ambos extremos antes de moverte
Quedan algunas referencias locales	Aproximadamente 1 de cada 16	URLs codificadas de forma rígida en archivos de temas, código personalizado, cachés o servicios de terceros, fuera de la base de datos	Busca en el tema y en el código personalizado el dominio local, luego borra todas las cachés

Lee la tercera columna y el patrón es difícil de pasar por alto. Casi nada de lo que ves aquí es causado por la transferencia. Es causado por que el servidor en producción está configurado de manera diferente a tu portátil.

Cuando un Límite del Hosting Detiene la Instalación

Inicias la instalación en el servidor en producción, se procesa durante un tiempo y luego se detiene.

Este es el problema individual más común en los tickets de local a producción, y es un límite del host en lugar de una transferencia fallida. El tiempo de espera de PHP o el límite de memoria del servidor interrumpe el proceso durante la extracción, que es el paso más pesado. Las máquinas locales no tienen tal techo, por lo que una compilación que funcionó bien en tu portátil puede toparse con un muro en el alojamiento compartido.

Aumenta max_execution_time y memory_limit en el servidor de destino. Estos se encuentran en el panel de control de tu host, a menudo bajo Opciones de PHP o Editor INI MultiPHP, y el soporte de tu host puede aumentarlos rápidamente si no los encuentras.

Aquí es también donde la herramienta que utilizas marca la diferencia.

Un archivo zip estándar tiene que ser desempaquetado en una sola ejecución continua. En un servidor con un límite de ejecución corto, eso es un problema.

Si el desempaquetado tarda más de lo que permite el host, el proceso se interrumpe a mitad de camino y te quedas con un sitio medio desempaquetado y sin un error claro.

DupArchive es el formato de archivo de copia de seguridad personalizado de Duplicator, diseñado para ser desempaquetado en piezas más pequeñas en su lugar. Funciona a través del sitio en fragmentos, por lo que ninguna ejecución individual tiene que extenderse más allá del límite del host.

Eso es lo que permite a Duplicator manejar sitios grandes, incluidas migraciones reales de 400 GB, en servidores que se ahogarían con un archivo convencional.

El instalador independiente resuelve un problema relacionado en el otro extremo. No necesita que WordPress ya exista en el destino, por lo que puedes mover una compilación local a un servidor completamente vacío sin configurar nada primero.

PHP Es Más Nuevo en tu Portátil que en tu Hosting

Todo funciona localmente, luego el sitio en producción arroja errores en páginas que utilizan funciones específicas de plugins o temas.

Esto aparece aproximadamente tres veces más a menudo en las migraciones de local a producción que en otras migraciones, y se reduce a cómo se empaquetan las herramientas.

Los entornos de desarrollo local utilizan una versión actual de PHP. Muchos hosts en producción todavía usan por defecto algo más antiguo, por lo que las funciones que funcionaron en tu portátil están obsoletas o faltan en el servidor.

Comprueba ambos antes de moverte. En tu herramienta local, la versión de PHP suele mostrarse en el panel de configuración del sitio.

En el host, busca en Versión de PHP, Seleccionar versión de PHP o Administrador MultiPHP. Haz que coincidan y compila contra la versión a la que realmente desplegarás.

La Importación de la Base de Datos Falla

El sitio en vivo carga un error al establecer una conexión con la base de datos, o la instalación se detiene en el paso de la base de datos.

Después de una mudanza, esto es casi siempre un problema de credenciales en lugar de una base de datos rota. El nombre, el usuario o la contraseña no coinciden con lo que creó el host en vivo.

Obtén el nombre de la base de datos, el nombre de usuario, la contraseña y el valor del host de tu cuenta de hosting en vivo, e introdúcelos cuidadosamente durante el paso de instalación. Si el sitio ya está en funcionamiento y falla, esos valores se encuentran en wp-config.php en la carpeta raíz de tu sitio, accesible a través del administrador de archivos de tu host o un cliente FTP.

Los permisos de archivo no se transfieren

La instalación se detiene con un error que dice que no puede escribir un archivo o crear una carpeta.

Los entornos locales son permisivos porque eres la única persona que los usa. Los servidores en vivo son más estrictos. La propiedad y el acceso de escritura que nunca importaron en tu portátil empiezan a importar aquí.

Establece las carpetas en 755 y los archivos en 644 en el destino. Puedes cambiar los permisos de archivo a través de un cliente FTP o el administrador de archivos de tu host, ambos muestran una opción de permisos o CHMOD al hacer clic derecho en una carpeta. La documentación de tu host confirmará el usuario correcto del servidor web si no estás seguro.

No puedes iniciar sesión una vez que está en vivo

La mudanza termina, vas a iniciar sesión y la página de inicio de sesión te devuelve o entra en un bucle.

Esto causa más pánico del que merece. Casi nunca significa que la mudanza falló. La URL del sitio almacenada en la base de datos no coincide con dónde vive ahora el sitio, por lo que WordPress te redirige continuamente a una dirección que ya no existe.

Corrige los campos Dirección de WordPress y Dirección del sitio en Ajustes » Generales, y luego borra tus cookies.

Si no puedes acceder al panel de control en absoluto, puedes establecer ambos valores temporalmente en wp-config.php.

Algunas Referencias Locales Sobreviven a la Migración

La mayoría de los enlaces funcionan, pero algo todavía apunta a mysite.local.

Las referencias de la base de datos se reescriben durante la instalación. Lo que sobrevive es todo lo que vive fuera de la base de datos: una URL codificada en un archivo de tema o tema hijo, una ruta escrita en código personalizado, una página en caché o un servicio de terceros que todavía apunta a tu dirección de desarrollo.

Busca el dominio local en tu tema y código personalizado, borra cualquier plugin de caché y la caché del servidor de tu host, y luego recarga. Si hay un servicio como una CDN o un formulario externo involucrado, actualiza la dirección del sitio en ese servicio también.

Una Comprobación Previa Antes de Subir Local a Producción

Puedes evitar la mayoría de los errores de WordPress de local a en vivo con unos cinco minutos de preparación.

• Activa SSL en el host en vivo. Este es el elemento de mayor valor en la lista, y hacerlo primero es lo que hace que funcione.
• Compara las versiones de PHP en tu herramienta local y tu host en vivo, y haz que coincidan.
• Tenga a mano las credenciales de su base de datos en vivo antes de comenzar la instalación.
• Conozca la URL en vivo y espere que las direcciones del sitio cambien con ella.
• Tenga listo su inicio de sesión de administrador para que un bucle de redirección no le bloquee el acceso a su propio sitio.

Si desea la guía paso a paso completa para la migración en sí, nuestra guía sobre cómo migrar un sitio local de WordPress a un servidor en vivo detalla el proceso. Este informe trata sobre las diferencias entre los dos entornos y cómo cerrarlas con anticipación.

Duplicator Pro ayuda más en las partes que fallan aquí. El instalador independiente mueve un sitio a un servidor en blanco, incluso a uno sin WordPress instalado, y DupArchive maneja compilaciones locales grandes sin ahogarse en el paso de extracción.

Preguntas Frecuentes (FAQs)

La Brecha Entre tu Portátil y tu Servidor

Cada problema en este informe proviene del mismo lugar. Su entorno local y su servidor en vivo discrepan sobre PHP, SSL, permisos o el nombre del propio sitio. La migración es donde esas discrepancias salen a la luz de golpe.

Eso vale la pena repetirlo claramente porque cambia la forma en que se prepara. La migración no es la parte arriesgada. La falta de coincidencia lo es.

Antes de compilar el sitio local, verifique la versión de PHP del host en vivo y active su certificado SSL. Desarrolle contra el entorno en el que va a desplegar, y la mayor parte de este informe nunca se aplicará a usted.

Antes de tu Próximo Lanzamiento, Ten un Plan de Respaldo

Un sitio que falla en su primer día en vivo es una mala tarde. Un sitio que falla sin una copia limpia a la que recurrir es mucho peor.

Duplicator Pro es utilizado por más de 1,5 millones de profesionales de WordPress para hacer copias de seguridad, migrar y recuperar sus sitios. Su instalador independiente mueve una compilación local a un servidor en blanco, y sus herramientas de recuperación te permiten volver si un lanzamiento sale mal.

Ya que estás aquí, estos otros recursos de WordPress merecen una mirada:

• Lo que 8.000+ tickets de soporte revelan sobre por qué fallan las migraciones de WordPress
• ¿Qué rompe las copias de seguridad de WordPress: lecciones de más de 1400 tickets de soporte?
• Tu lista de verificación completa para la migración de WordPress (de principio a fin)
• Cómo mover un sitio web de WordPress a un nuevo host
• Cómo restaurar un sitio de WordPress desde una copia de seguridad