Puntos clave
- SSL y contenido mixto: Utiliza buscar y reemplazar en la base de datos para una solución permanente en lugar de depender de plugins temporales.
- Estrategia DNS: Reduce el TTL antes de la migración, supervisa las herramientas de propagación y haz pruebas a través de tu archivo hosts antes de ponerte en marcha.
- Fiabilidad del correo electrónico: Verifica los registros MX tras las actualizaciones del DNS. Utiliza SMTP en lugar de PHP mail() y añade registros SPF/DKIM.
- Empujar código: Las transferencias sólo de archivos son más seguras. Las transferencias de bases de datos corren el riesgo de sobrescribir datos activos: haz siempre copias de seguridad y ten un plan de reversión.
Tu migración a WordPress ha tenido éxito… ¿o no?
Los archivos transferidos. La base de datos importada. Tu sitio se carga en la URL temporal. Pero ahora los visitantes reciben advertencias de seguridad. Tus formularios de contacto no envían correos electrónicos. Y estás mirando la configuración DNS preguntándote si lo has configurado todo correctamente.
¿Te suena familiar?
La mayoría de las guías de migración no te dicen que la transferencia real de archivos es sólo el primer paso. Después de la migración, las cosas se ponen realmente difíciles. Tienes que configurar correctamente los certificados SSL, gestionar la propagación de DNS sin causar tiempo de inactividad, y arreglar el correo electrónico que misteriosamente dejó de funcionar.
A lo largo de los años, los clientes han compartido con nosotros sus problemas de configuración tras la migración. Estas tres áreas (SSL, DNS y correo electrónico) son las que causan más confusión y solicitudes de asistencia. Pero no te preocupes, te ayudamos a entender cómo volver a la normalidad.
Esta guía se centra exclusivamente en las 24-72 horas posteriores a la finalización de la migración. Repasaremos la configuración SSL y la resolución de problemas, la gestión de la propagación DNS, las estrategias de restauración del correo electrónico y los flujos de trabajo seguros de puesta en producción. Piensa en esto como tu compañero técnico para esos primeros días críticos en los que estás preparando tu sitio migrado para la producción.
Empecemos por el problema que afecta a casi todas las migraciones: La configuración SSL.
- ¿Por qué no funciona mi certificado SSL después de la migración?
- Lista de comprobación DNS posterior a la migración
- Optimización del DNS previa a la migración (Lo que deberías haber hecho)
- ¿Cuáles son las mejores herramientas para supervisar la propagación DNS en tiempo real?
- Solución de problemas de DNS tras la migración de WordPress
- Lista de comprobación posterior a la migración: Los correos electrónicos dejaron de funcionar
- Lista de comprobación posterior a la migración: Trasladar con seguridad un sitio de WordPress de la fase de pruebas a la de producción
- La lista de comprobación completa de 72 horas tras la migración
¿Por qué no funciona mi certificado SSL después de la migración?
Las migraciones no transfieren certificados SSL. Empezarás de nuevo en tu nuevo host de WordPress aunque tu sitio anterior tuviera una configuración HTTPS funcional, porque son específicos del servidor.
A la gente le pilla desprevenida. «¡Pero mi sitio tenía SSL!» es una queja habitual. Efectivamente, lo tenía. Ese certificado se instaló y confirmó en tu servidor anterior.
Vas a trasladar los archivos y la base de datos de tu sitio web, pero los certificados SSL no se transfieren automáticamente. Tienes que instalar un nuevo certificado en tu nuevo host, ya sea un servicio gestionado o un VPS. Al igual que la cerradura de una puerta física, tu nuevo servidor tiene que estar configurado para utilizar la clave privada de tu certificado SSL.
Te enfrentarás a diferentes retos dependiendo de tu escenario:
- Migración de HTTP a HTTPS: El primer SSL requiere actualizar todas las URL internas.
- Sitio HTTPS existente: Reinstala SSL y soluciona los problemas de contenido mixto.
- Cambio de dominio: Un nuevo dominio requiere un nuevo certificado y transferencia de URL.
¿Preparado para trasladar todos tus sitios WordPress a un alojamiento mejor?
Realiza migraciones ilimitadas con el plugin Cloudways Migrator y disfruta de un alojamiento WordPress rápido, seguro y escalable.
Instalar certificados SSL en tu host Cloudways
Los certificados SSL (https://) son prácticamente una característica innegociable de un sitio web por motivos de seguridad y credibilidad de la marca. En Cloudways, este proceso es rápido y normalmente gratuito.
Cloudways ofrece SSL Let’s Encrypt gratuito en 1 clic y un SSL personalizado que hayas comprado en otro sitio.
¿Qué hacer después de instalar un certificado SSL?
Quedan dos cosas importantes por hacer en la sección del certificado SSL de la lista de comprobación posterior a la migración:
- Activa la Renovación Automática (para Let’s Encrypt):
- Ahora verás la información de tu certificado en la misma pantalla del Certificado SSL.
- Asegúrate de que el interruptor de Renovación Automática está ACTIVADO. Los certificados Let’s Encrypt caducan cada 90 días. Con este servicio, Cloudways puede renovarlos automáticamente por ti para que tu sitio nunca se caiga.
- Forzar redirección HTTPS:
- Debes asegurarte de que todos los que visiten tu sitio web sean enviados a la versión segura https:// del mismo.
- Ve a Configuración de la aplicación en el menú Gestión de aplicaciones.
- Haz clic en el conmutador situado bajo la sección REDIRECCIÓN HTTPS para activarla.
¿Te encuentras con el error Git SSL tras la migración de WordPress?
Lee nuestra guía para solucionarlo.
¿Cómo soluciono los «Avisos de contenido mixto» en WordPress después de instalar SSL?
Así que acabas de instalar SSL, has pulsado el interruptor a HTTPS, y ahora estás mirando un molesto icono de advertencia en lugar del candado verde que esperabas. ¿La consola de tu navegador? Está lanzando errores de contenido mixto a diestro y siniestro.
Créeme, esto vuelve loco a todo el mundo cuando configura SSL por primera vez. El culpable suelen ser esos viejos enlaces HTTP enterrados en lo más profundo de tu base de datos de WordPress: siguen apuntando a las versiones no seguras de tus imágenes, scripts y hojas de estilo. Cuando tu nueva y reluciente página HTTPS intenta cargar estos recursos HTTP, los navegadores básicamente se asustan y lo marcan como un riesgo para la seguridad.
Detectar contenido mixto:
Enciende Chrome o Firefox y visita tu página problemática. Haz clic con el botón derecho del ratón en algún lugar (cualquier sitio sirve) y pulsa «Inspeccionar» o «Inspeccionar elemento». Haz clic en la pestaña «Consola» y verás advertencias parecidas a las siguientes
❗ Contenido mixto: La página en ‘https://yourdomain.com’ se cargó a través de HTTPS, pero solicitó una imagen insegura ‘http://yourdomain.com/image.jpg’
Esa es tu pistola humeante. Te muestra exactamente qué archivos están causando problemas.
Deshacerse definitivamente de los contenidos mixtos:
He probado casi todos los métodos que existen, y éstos son los tres que realmente funcionan:
- Buscar y reemplazar en base de datos (Recomendado)
Éste aborda el problema en su origen convirtiendo todas esas URL HTTP a HTTPS directamente en la propia base de datos.
Hazte con el plugin «Reemplazar búsqueda mejor». Esto es lo que hay que hacer:
- Ve a Herramientas → Reemplazar búsqueda mejor
- En el campo de búsqueda: http://yourdomain.com
- En el campo sustituir: https://yourdomain.com
- Elige todas las tablas (como mínimo, coge wp_posts, wp_postmeta y wp_options)
- Marca siempre, SIEMPRE, «Ejecutar como prueba en seco» primero: esto te permite previsualizar lo que cambiará
- Si todo parece correcto, desmarca la marcha en seco y aprieta el gatillo
Una advertencia: Haz una copia de seguridad de tu base de datos antes de tocar nada. Lo digo en serio. Lo aprendí por las malas. Quieres esa red de seguridad por si las cosas se tuercen.
- Solución plugin (Solución rápida)
«Really Simple SSL» puede cambiar automáticamente HTTP por HTTPS a medida que se cargan tus páginas. Hace el trabajo, aunque, para ser sincero, está tapando las grietas. En realidad, el plugin no arregla esas URL en tu base de datos; sólo las intercepta y las reescribe sobre la marcha, lo que significa que tu servidor está haciendo un trabajo extra cada vez que alguien visita tu sitio.
Suelo recomendar esto cuando los usuarios necesitan que HTTPS funcione ayer y volveremos más tarde para una limpieza adecuada de la base de datos.
- Constantes manuales de wp-config.php
Coloca estas dos líneas en tu archivo wp-config.php (pégalas encima de la línea «dejar de editar»):
define('FORZAR_SSL_ADMIN', true);
define('FORZAR_SSL_LOGIN', true);
Pero ten en cuenta que esto sólo protege las áreas de administración e inicio de sesión. Tus problemas de contenido mixto del front-end seguirán ahí, pero al menos tu panel de administración permanecerá bloqueado.
¿Cómo puedo solucionar errores comunes de SSL?
Problema: «Certificado no fiable» o «Certificado no válido»
¿Qué ocurre? Nueve de cada diez veces, es un problema de configuración o estás utilizando un certificado autofirmado.
La solución: Consigue un certificado válido firmado por una CA. Let’s Encrypt y Sectigo son buenas opciones. Los navegadores odian los certificados autofirmados y siempre se quejan de ellos. Con Let’s Encrypt, a veces basta con reinstalar el certificado.
Problema: «NET::ERR_CERT_COMMON_NAME_INVALID»
¿Qué ocurre? Tu certificado y tu dominio no coinciden
La solución: Esto suele significar que tienes SSL en «ejemplo.com» pero la gente está pulsando«www.example.com»(o viceversa). La mayoría de los instaladores de certificados gestionan ambas versiones automáticamente, pero comprueba que el tuyo cubre todas las variaciones de tu dominio. Los usuarios de Cloudflare deben comprobar que su modo SSL es «Completo» o «Completo (Estricto)». El ajuste «Flexible» causa todo tipo de dolores de cabeza.
Problema: Bucles de redireccionamiento
¿Qué ocurre? Tienes redirecciones HTTPS luchando entre sí en distintos lugares
La solución: Abre tu archivo .htaccess y cuenta cuántas reglas de redireccionamiento ves. Las redirecciones a nivel de servidor y los plugins que fuerzan HTTPS suelen pisarse mutuamente. Prueba a desactivar temporalmente tu plugin SSL. Si el bucle desaparece, habrás encontrado al culpable. Y no olvides comprobar si el ajuste «Usar siempre HTTPS» de Cloudflare está activado, pues le encanta chocar con las redirecciones a nivel de servidor.
Problema: El área de administración sigue siendo HTTP incluso con HTTPS activado
¿Qué ocurre? La configuración de tu URL de WordPress es incorrecta
La solución: Ve a Ajustes → General y asegúrate de que tanto «Dirección de WordPress (URL)» como «Dirección del sitio (URL)» empiezan por https://. Si no puedes acceder a la administración, añade estas líneas a wp-config.php como solución:
define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');
Lista de comprobación DNS posterior a la migración
Todo el mundo te dice que «la propagación del DNS tarda entre 24 y 48 horas», ¿verdad?
Claro, eso no está mal. Pero esa afirmación general ha confundido a más gente de la que ha ayudado. Te hace imaginar una ola lenta que se arrastra por Internet, actualizando los servidores uno por uno. Lo que ocurre en realidad es mucho más interesante. Una vez que lo entiendes, puedes trabajar con ello en lugar de esperar sin hacer nada.
¿Qué es la propagación del DNS y cuánto tarda realmente?
La cuestión es la siguiente: la propagación del DNS no se produce a la vez en todas partes. Hay miles de servidores DNS en todo el mundo, y cada uno decide cuándo obtener nueva información sobre tu dominio. Y todos ellos siguen las reglas definidas por la configuración TTL (Time To Live) de tu dominio.
Imagínate esto: Un servidor DNS de Tokio tiene tu dirección IP anterior. Seguirá dándote esa dirección antigua hasta que se agote su periodo TTL. ¿Tu TTL está fijado en 86400 segundos? Ese servidor ni siquiera pensará en buscar actualizaciones durante todo un día. Pero, ¿y si lo has bajado a 300 segundos? Ahora estamos llegando a alguna parte; se actualizará cada cinco minutos.
La cronología real:
– Ejecutando un TTL alto (como 86400 segundos): Te enfrentas a esa ventana completa de 24-48 horas antes de que todo el mundo esté en la misma página
– Ejecutar un TTL bajo (digamos, 300 segundos): La mayoría de la gente verá tu nuevo sitio en 30-60 minutos
– Variación geográfica: Los usuarios de distintas regiones ven versiones diferentes porque consultan servidores DNS diferentes
Por eso algunas personas ven tu nuevo sitio inmediatamente mientras que otras siguen viendo el antiguo. Están preguntando a diferentes servidores DNS, que se actualizan en horarios diferentes.
Optimización del DNS previa a la migración (Lo que deberías haber hecho)
En un mundo perfecto, harías lo siguiente: Entre 48 y 72 horas antes de activar la migración, reducirías el TTL de tu dominio a 300 segundos. Básicamente, estás diciendo a los servidores DNS de todo el mundo que empiecen a comprobarlo más a menudo.
Ahora bien, ¿por qué el aviso previo? Porque -y esto es lo más importante- el cambio de TTL tiene que propagarse primero. Si reduces el TTL cinco minutos antes de migrar, la mayoría de los servidores DNS seguirán funcionando con ese antiguo y perezoso programa de actualización. Ni siquiera sabrán que has cambiado las reglas hasta dentro de uno o dos días.
¿No has hecho este trabajo previo? ¡Únete al club! La mayoría de la gente se salta este paso. No es el fin del mundo. Tus cambios de DNS se tomarán su tiempo. Por desgracia, no existe un botón mágico para acelerar las cosas a posteriori, pero hay formas de evitarlo.
¿Cuál es la diferencia entre actualizar un registro A y cambiar los servidores de nombres?
Cuando rediriges tus DNS a tu nuevo proveedor de alojamiento, básicamente estás actualizando las coordenadas GPS de Internet para tu sitio. Tienes dos formas de manejar esto:
Enfoque 1: Una actualización de registros
Este es el enfoque quirúrgico. Sólo cambias a dónde va el tráfico de tu sitio web, dejando todo lo demás (registros de correo electrónico, códigos de verificación, etc.) exactamente donde está.
Primero, localiza la dirección IP de tu nuevo host. A continuación, entra en la configuración DNS y actualízala en consecuencia:
– Tipo de registro: A
– Host/Nombre: @ (representa tu dominio raíz)
– Valor/Puntos a: La dirección IP de tu nuevo servidor
– TTL: 300 (5 minutos) inicialmente
Añade un segundo registro A para www:
– Tipo de registro: A
– Host/Nombre: www
– Valor/Puntos a: Misma dirección IP
– TTL: 300
Enfoque 2: Cambio de servidor de nombres
Esto básicamente entrega las claves DNS a tu nuevo proveedor de alojamiento. Entrarás en la configuración de tu registrador de dominios y cambiarás los servidores de nombres por los que te proporcione tu nuevo proveedor.
Sigue este camino si quieres que tu empresa de alojamiento se encargue de todo el trabajo pesado de los DNS, o si directamente lo necesitan para que su configuración funcione. El inconveniente es que esto hace borrón y cuenta nueva con tus DNS. Todos y cada uno de los registros personalizados desaparecen.
Así que te verás obligado a reconstruir manualmente todos esos registros MX para el correo electrónico, registros SPF para la autenticación y cualquier otra magia DNS personalizada que tuvieras en marcha. No es divertido, pero a veces es necesario.
Si Cloudflare se encarga de tus tareas de DNS y CDN, aquí tienes el libro de jugadas:
- Entra en el panel de gestión de DNS de Cloudflare y cambia ese registro A por la dirección IP de tu nuevo host
- ¿Ves ese pequeño icono en forma de nube? Mantenlo en gris (es el modo sólo DNS) mientras haces pruebas
- Una vez que te hayas puesto manos a la obra y hayas confirmado que todo funciona correctamente, gira esa nube de color naranja para activar el modo proxy
He aquí por qué es importante: Si pasas directamente al modo nube naranja, la caché de Cloudflare podría seguir sirviendo obstinadamente tu antiguo sitio incluso después de que se hayan realizado las actualizaciones de DNS. He visto a gente darse cabezazos contra la pared preguntándose por qué no cambia nada cuando sólo es Cloudflare haciendo sus cosas de caché.
Prueba primero con la nube gris. Asegúrate de que tu nuevo servidor real responde correctamente, y deja que Cloudflare haga su magia de proxy una vez que sepas que todo es sólido.
Pruebas antes de la propagación del DNS (El método del archivo de hosts)
Aquí tienes un consejo profesional que te ahorrará mucha ansiedad: puedes previsualizar tu sitio en el nuevo host antes de actualizar las DNS, anulando temporalmente las DNS en tu ordenador.
Utiliza el archivo «hosts» de tu ordenador, que actúa como un DNS local:
En Windows:
- Abre el Bloc de notas como administrador (botón derecho → Ejecutar como administrador)
- Abre C:\Windows\System32\drivers\etc\hosts
- Añade en la parte inferior:
123.45.67.89 tudominio.com
123.45.67.89 www.yourdomain.com
- Guarda el archivo
En Mac/Linux:
- Terminal abierto
- Escribe: `sudo nano /etc/hosts`
- Añade las mismas líneas en la parte inferior
- Pulsa Ctrl+X, luego Y, luego Intro para guardar
Sustituye 123.45.67.89 por la dirección IP de tu nuevo host.
Tu ordenador utilizará esta anulación en lugar del DNS cuando vayas a tudominio.com en tu navegador. Puedes ver exactamente lo que ocurrirá cuando se propague el DNS, lo que te permite probarlo todo antes de hacer público el traslado.
¿Cuáles son las mejores herramientas para supervisar la propagación DNS en tiempo real?
Una vez que hayas actualizado el DNS, querrás saber cuándo se ha propagado. Estas herramientas te muestran el estado actual:
CuálEsMiDNS.net
Muestra la resolución DNS de docenas de ubicaciones de todo el mundo con un mapa visual. Introduce tu dominio y el tipo de registro (A), y verás qué regiones están viendo tu nueva IP frente a la antigua.
Comprobador DNS
Similar a WhatsMyDNS pero con información más detallada del servidor. Útil para diagnosticar problemas de propagación regional.
Qué considerar «completo»:
No necesitas un 100% de propagación global para ponerte en marcha. Cuando veas que el 75-80% de las ubicaciones probadas devuelven tu nueva IP, la mayoría de los usuarios verán tu nuevo sitio. Los servidores restantes se pondrán al día en cuestión de horas.
¿Cómo borro mi caché DNS local?
Tu ordenador también almacena en caché el DNS. Aunque el DNS se haya propagado globalmente, es posible que sigas viendo el sitio antiguo porque tu ordenador no lo ha actualizado. Limpia tu caché local de DNS:
– Windows: Abre el símbolo del sistema y ejecuta `ipconfig /flushdns`.
– Mac: Abre Terminal y ejecuta `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`.
– En Linux: Varía según la distribución; normalmente `sudo systemd-resolve –flush-caches`.
Después de borrar la caché, haz la prueba en una ventana de navegador de incógnito/privado para evitar problemas con la caché del navegador.
Solución de problemas de DNS tras la migración de WordPress
Problema: «Sigo viendo el sitio antiguo después de 48 horas»
Primero, comprueba que tus registros DNS están realmente actualizados:
- Ir a WhatsMyDNS.net
- Introduce tu dominio
- Comprueba si CUALQUIER ubicación muestra tu nueva IP
Si ninguna ubicación muestra tu nueva IP, tu DNS no se ha actualizado en origen. Accede a tu registrador de dominios o proveedor de DNS y comprueba que los cambios se han guardado correctamente. A veces los cambios se quedan atascados en estado «pendiente».
Si algunas ubicaciones muestran la nueva IP pero no todas, se trata de una propagación normal. Espera un poco más.
Solución: Si todas las ubicaciones muestran la nueva IP pero sigues viendo el sitio antiguo, el problema es la caché local (caché del navegador, caché DNS local o caché del ISP). Borra todas las cachés y haz la prueba desde una red diferente (como datos móviles en lugar de WiFi).
Problema: «Algunos usuarios ven el nuevo sitio, otros ven el antiguo»
Esto es completamente normal durante la propagación. Diferentes usuarios consultan diferentes servidores DNS con diferentes calendarios de actualización. No hay nada que puedas hacer para forzar una propagación más rápida: sólo tienes que esperar a que los ISP de todo el mundo actualicen sus cachés.
Solución: Considera poner un aviso de mantenimiento temporal en tu antiguo sitio que diga «Estamos en proceso de migración. Si ves este mensaje, borra la memoria caché y vuelve a comprobarlo en breve».
Problema: «Registro A actualizado pero faltan registros MX-email roto»
Esto ocurre cuando cambias los servidores de nombres en lugar de actualizar sólo los registros A. Los cambios de servidor de nombres borran todos los registros DNS, incluidos los registros MX para el correo electrónico.
Solución: Entra en tu gestor de DNS y vuelve a añadir manualmente todos los registros MX, SPF y cualquier otra entrada DNS que se haya perdido. (Trataremos el DNS específico del correo electrónico en la siguiente sección).
Problema: «Cloudflare muestra la IP antigua incluso después de actualizar»
Si utilizas Cloudflare, comprueba dos cosas:
- ¿Has actualizado el registro A en la gestión de DNS de Cloudflare (no sólo en tu registrador)?
- ¿La caché de Cloudflare está sirviendo el sitio antiguo?
Solución: Actualiza el registro A en el panel de Cloudflare y, a continuación, purga la caché de Cloudflare (Caché → Configuración → Purgar todo). Desactiva también temporalmente el proxy (nube gris del registro DNS) para comprobar si el problema es de Cloudflare.
Lista de comprobación posterior a la migración: Los correos electrónicos dejaron de funcionar
La rotura del correo electrónico tras la migración de WordPress pilla a la gente por sorpresa. «¡Pero si yo no he tocado la configuración de mi correo electrónico!», nos dicen. Y es cierto, pero la migración afecta al correo electrónico de formas que no son evidentes a primera vista.
¿Por qué no funcionan los correos electrónicos de WordPress si sólo he migrado mi sitio web?
Esto es lo que ocurre: Los registros DNS, especialmente los registros MX, informan a otros servidores de correo sobre dónde enviar el correo electrónico de tu dominio. Cuando trasladas tu sitio web y alteras las DNS, la forma en que haces las modificaciones puede cambiar cómo se enruta el correo electrónico.
Tres situaciones habituales del correo electrónico tras la migración:
Escenario 1: Correo electrónico alojado en el antiguo proveedor de alojamiento web
Es posible que tu antigua empresa de alojamiento controlara tus cuentas de correo electrónico. Si es así, esos servidores de correo electrónico no están conectados a tu sitio web. Acabas de decirle a Internet que tudominio.com tiene una nueva dirección IP cuando cambiaste las DNS para que apuntaran al nuevo host. Sin embargo, no le dijiste dónde enviar el correo electrónico.
Resultado: El correo electrónico no se entrega o se envía en la dirección equivocada.
Escenario 2: Correo electrónico de terceros (Google Workspace, Microsoft 365)
Es bueno que tu correo electrónico sea almacenado por separado por Google o Microsoft. El correo electrónico debería seguir funcionando aunque cambie el host de tu sitio web. Los servidores de nombres, no sólo los registros A, pueden haberse perdido cuando cambiaste de servidor de nombres. Estos registros apuntan a los servidores de correo de Google y Microsoft.
Resultado: Otros servidores no pueden gestionar el correo entrante porque no saben dónde enviarlo.
Escenario 3: Correos electrónicos transaccionales de WordPress (formularios de contacto, restablecimiento de contraseñas)
El envío de correos electrónicos en WordPress se realiza por defecto con el método mail() de PHP. Muchos sitios no permiten esta función en absoluto por motivos de seguridad o le ponen muchos límites para detener el spam. Es posible que tu antiguo host te lo permitiera, pero puede que tu nuevo host no.
Resultado: Tu sitio web no puede enviar correos electrónicos. El restablecimiento de contraseñas, las notificaciones de formularios de contacto y las confirmaciones de venta de WooCommerce fallan sin hacer ruido.
¿Cómo puedo diagnosticar qué parte de mi correo electrónico está averiada?
Antes de que puedas arreglar el correo electrónico, tienes que entender qué es lo que no funciona. Realiza estas pruebas:
Prueba 1: Restablecer la contraseña de WordPress
En la página de inicio de sesión de tu sitio (wp-login.php), haz clic en «¿Has perdido tu contraseña?». Escribe tu dirección de correo electrónico y pide que se restablezca. Dale unos minutos. ¿Has recibido el correo electrónico? Mira también en tu carpeta de correo no deseado.
Prueba 2: Envía un formulario de contacto
Envía un mensaje de prueba utilizando el formulario de contacto de tu sitio web. ¿Ha llegado? Si tienes WooCommerce u otro plugin de comercio electrónico, haz un pedido de prueba y busca correos electrónicos que confirmen el pedido.
Prueba 3: Prueba un correo electrónico de fuera de la empresa
Envía un correo electrónico desde una cuenta externa (como Gmail o Outlook) al correo electrónico de tu dominio ([email protected]). ¿Llegó allí? Esto comprueba el correo electrónico entrante, que depende del registro MX.
Cómo leer los resultados:
– No funciona nada: Parece que los registros DNS o MX faltan o son incorrectos.
– Los correos electrónicos que llegan funcionan, pero los de WordPress no: Problema con la configuración del correo electrónico de WordPress (se necesita SMTP)
– Todo va a parar a spam: No hay registros de autenticación (SPF/DKIM)
Ahora vamos a solucionar cada problema.
¿Cómo arreglo mi correo electrónico comprobando o añadiendo registros MX?
Los registros MX (Mail Exchanger) informan a otros servidores de correo electrónico dónde enviar el correo de tu dominio. Si son incorrectos o están ausentes, el correo electrónico no llegará.
Encontrar tus registros MX correctos:
Los registros MX que necesitas dependen de dónde esté alojado tu correo electrónico:
Para Google Workspace:
Prioridad 1: ASPMX.L.GOOGLE.COM
Prioridad 5: ALT1.ASPMX.L.GOOGLE.COM
Prioridad 5: ALT2.ASPMX.L.GOOGLE.COM
Prioridad 10: ALT3.ASPMX.L.GOOGLE.COM
Prioridad 10: ALT4.ASPMX.L.GOOGLE.COM
Para Microsoft 365:
Prioridad 0: sudominio-com.mail.protection.outlook.com
(Sustituye «tudominio-com» por tu dominio, utilizando guiones en lugar de puntos)
Para el correo electrónico de tu antiguo host:
Entra en el panel de control de tu antiguo host ANTES de cancelar la cuenta. Busca la sección de correo electrónico o DNS y copia todos los registros MX exactamente como se muestran. Tendrás que volver a crearlos en tu nuevo proveedor de DNS.
Añadir registros MX:
Dónde los añadas depende de tu configuración DNS:
– Si simplemente has cambiado los registros A: Añade registros MX allí donde gestiones las DNS, que suele ser tu registrador de dominios (como Namecheap, GoDaddy, etc.).
– Si has cambiado los servidores de nombres a tu nuevo host: Añade registros MX a la configuración DNS de tu nuevo host.
– Si utilizas Cloudflare: Añade registros MX a la configuración DNS de Cloudflare.
El formato suele ser el siguiente
– Tipo de registro: MX
– Nombre/Host: @ (o déjalo en blanco-representa tu dominio)
– Prioridad: 1, 5 ó 10 (números más bajos = prioridad más alta)
– Valor/Puntos a: La dirección del servidor de correo
Verificación:
Después de añadir los registros MX, espera de 10 a 30 minutos y compruébalo con MXToolbox:
- Ve a mxtoolbox.com/SuperTool.aspx
- Introduce tu dominio
- Selecciona «Búsqueda MX» en el menú desplegable
- Comprueba que aparecen todos los registros MX esperados
Una vez verificado, prueba el correo electrónico entrante enviando un mensaje desde Gmail u otro servicio externo.
Configuración SMTP de WordPress: La Solución Fiable
WordPress sigue necesitando un medio para ENVIAR correo electrónico, incluso cuando los registros MX están configurados correctamente para gestionar el correo entrante. La función PHP mail() no es muy fiable porque los servidores de correo receptores suelen bloquearla, desactivarla o marcarla como spam.
SMTP (Simple Mail Transfer Protocol) es la respuesta. WordPress envía los mensajes directamente a un servidor de correo en lugar de utilizar la función de correo del servidor. Esto está verificado, es fiable y facilita mucho la entrega.
Configurar SMTP con el plugin WP Mail SMTP:
- Consigue el plugin «WP Mail SMTP» y actívalo (la versión gratuita funciona perfectamente).
- Haz clic en Configuración en WP Mail SMTP
- Escribe tu «Correo electrónico del remitente», que puede ser [email protected].
- Escribe el nombre de tu web o negocio en el campo «Nombre del remitente».
Ahora tienes que elegir un servicio de correo. Tienes varias opciones:
Opción 1: Utiliza tu proveedor de correo electrónico actual
Si tienes Google Workspace o Microsoft 365, puedes utilizar sus servidores SMTP:
Configuración de Google Workspace:
– Host SMTP: smtp.gmail.com
– Cifrado: TLS
– Puerto SMTP: 587
– Autentificación: ON
– Nombre de usuario: [email protected]
– Contraseña: Tu contraseña específica de la aplicación (NO tu contraseña habitual de Google; debes generarla en la configuración de seguridad de Google).
Configuración de Microsoft 365:
– Host SMTP: smtp.office365.com
– Cifrado: STARTTLS
– Puerto SMTP: 587
– Autentificación: ON
– Nombre de usuario: [email protected]
– Contraseña: Tu contraseña de Microsoft
Opción 2: Utiliza un servicio de correo electrónico transaccional
Para un mayor volumen o una mejor capacidad de entrega, considera los servicios de correo electrónico transaccional dedicados:
– SendGrid: El nivel gratuito incluye 100 correos electrónicos/día
– Mailgun: El nivel gratuito incluye 5.000 correos electrónicos/mes
– SendLayer: Especializado en correo electrónico transaccional de WordPress
– Amazon SES: Muy asequible para grandes volúmenes (0,10 $ por cada 1.000 correos electrónicos)
Estos servicios proporcionan credenciales SMTP en sus paneles. Introduce esas credenciales en la opción «Otro SMTP» de WP Mail SMTP.
Pruebas:
Tras la configuración, WP Mail SMTP tiene una función de prueba incorporada:
- Ve a WP Mail SMTP → Prueba de correo electrónico
- Introduce tu dirección de correo electrónico
- Haz clic en «Enviar correo electrónico»
- Comprueba si ha llegado (incluida la carpeta de spam)
Si la prueba tiene éxito, tus correos electrónicos de WordPress ya funcionan. Si falla, comprueba el mensaje de error. Suele indicar si se trata de un problema de autenticación, bloqueo de puertos o error de configuración.
Problemas comunes de SMTP:
«No se puede autentificar«: Vuelve a comprobar el nombre de usuario y la contraseña. Además, Google se ha vuelto más exigente. Ahora necesitarás una contraseña específica para la aplicación, no tu nombre de usuario habitual.
«La conexión se ha interrumpido en el puerto 587«: Puede que tu host esté haciendo de policía de tráfico con el SMTP saliente. Cambia del puerto 587 con TLS al puerto 465 con SSL y comprueba si eso ayuda. ¿Sigues bloqueado? Es hora de que te pongas en contacto con el servicio de asistencia de tu alojamiento. Algunos servidores bloquean deliberadamente el SMTP para mantener a raya a los spammers.
«Error en la verificación del certificado«: La configuración SSL de tu host probablemente esté obsoleta. Podrías desactivar la verificación SSL en la configuración SMTP de WP Mail como solución, aunque esa es definitivamente la opción más arriesgada.
Registros SPF y DKIM: Evitar la carpeta de spam
Si tu correo electrónico funciona bien, pero todo sigue aterrizando en el spam, es súper frustrante. Es probable que te falten los registros de autenticación para que tus mensajes sean creíbles.
SPF (Sender Policy Framework) funciona como un remite en un sobre postal. Indica a los servidores de correo receptores qué direcciones IP tienen permiso para enviar correo desde tu dominio. Sin esta verificación, los servidores tratan tus mensajes como paquetes sin marcar que aparecen en la puerta de alguien. Sin duda, sospechoso.
DKIM (DomainKeys Identified Mail) lleva las cosas más lejos. Piensa en ello como si fuera el sello de lacre de una carta antigua. Añade una firma digital a tus correos salientes, demostrando que el contenido no ha sido manipulado durante el tránsito. Igual que un escriba de castillo se daría cuenta de un sello roto en un sobre, los servidores pueden detectar si alguien ha alterado tu mensaje por el camino.
Ambos mejoran significativamente la capacidad de entrega. Vamos a configurarlos.
Configurar registros SPF:
SPF se añade como un registro TXT en tu DNS. El formato depende de quién envíe el correo electrónico de tu dominio:
Si utilizas Google Workspace:
v=spf1 include:_spf.google.com ~all
Si utilizas Microsoft 365:
v=spf1 include:spf.protection.outlook.com ~todos
Si utilizas el servidor de correo de tu alojamiento web:
v=spf1 mx ~todos
(Esto dice «los servidores que figuran en los registros MX pueden enviar correo electrónico»)
Si utilizas varios servicios de correo electrónico:
Puedes encadenar varios includes:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Añádelo como registro TXT en tu DNS:
- Tipo de registro: TXT
- Nombre/Host: @ (o dejar en blanco)
- Valor: Tu cadena de registro SPF
Ten sólo UN registro SPF. Si ya tienes uno, edítalo para añadir inclusiones adicionales en lugar de crear un segundo registro SPF (los registros SPF múltiples provocan fallos de validación).
Configurar DKIM:
DKIM es más complejo porque implica la generación de un par de claves. El proceso varía según el proveedor:
Espacio de trabajo de Google:
- Consola de administración → Aplicaciones → Espacio de trabajo de Google → Gmail → Autenticar correo electrónico
- Haz clic en «Generar nuevo registro»
- Copia los valores del registro TXT
Microsoft 365:
- Centro de administración → Configuración → Dominios
- Selecciona tu dominio → Registros DNS
- Busca registros DKIM y actívalos
SendGrid/Mailgun: Estos servicios generan registros DKIM en sus cuadros de mandos, en los ajustes de autenticación o DNS.
Añade el registro DKIM a tu DNS como un registro TXT con el nombre específico proporcionado (normalmente algo como predeterminado._clavedominio.tudominio.com).
Verificación:
Utiliza estas herramientas para verificar la autenticación de tu correo electrónico:
- MXToolbox: Comprueba los registros SPF con su herramienta SPF Record Lookup
- Mail-tester.com: Envía un correo electrónico a la dirección que te facilitan y, a continuación, consulta tu puntuación (intenta obtener un 8/10 o más).
- Validador DKIM: Busca «validador DKIM» y utiliza cualquiera de las herramientas gratuitas
Una vez que SPF y DKIM estén correctamente configurados, la entregabilidad de tu correo electrónico debería mejorar drásticamente.
Lista de comprobación posterior a la migración: Trasladar con seguridad un sitio de WordPress de la fase de pruebas a la de producción
Para los usuarios de Cloudways, todo este proceso se gestiona dentro de un entorno de puesta en escena dedicado y de 1 clic, que está diseñado para evitar exactamente los problemas de pérdida de datos descritos aquí.
El Entorno de Escenificación Cloudways 1-Click
En lugar de empujes manuales de archivos o complejas fusiones de bases de datos, el flujo de trabajo es:
- Crear puesta en escena: Desde tu panel de Gestión de Aplicaciones, haz clic en «Crear Puesta en Escena». Cloudways clona todo tu sitio activo (archivos y base de datos) en una aplicación de ensayo separada y protegida por contraseña.
- Prueba y desarrollo: Puedes realizar cualquier cambio con seguridad (actualizar plugins, modificar temas, probar código nuevo) en este sitio de ensayo sin que afecte a tu sitio de producción en vivo.
- Empujar o extraer datos: Cuando estés listo para desplegar, la pestaña Gestión de la puesta en escena te ofrece dos sencillas opciones:
- Empujar: Esto mueve tus cambios (puedes elegir archivos, base de datos o ambos) de Puesta en Escena a Producción (En Vivo).
- Tirar: Esto actualiza tu sitio de Escenificación con los últimos datos de Producción (útil si tu sitio en vivo tiene nuevos pedidos o comentarios con los que necesitas hacer pruebas).
Fundamentalmente, la función push gestiona automáticamente la búsqueda y sustitución de URL de la base de datos y te ofrece un control granular, permitiéndote mover archivos mientras dejas intacta tu base de datos activa (con sus nuevos pedidos o comentarios).
Por qué la puesta en escena necesita su propia estrategia
¿Usas un entorno de pruebas para probar antes de ponerte en marcha? Estás tratando con una bestia totalmente diferente a una migración básica. No se trata de mover un sitio que está quieto. Estás intentando sincronizar cambios entre dos entornos que están vivos y coleando, y lo más probable es que la gente esté utilizando activamente tu sitio de producción mientras lo haces.
El principal riesgo: sobrescribir los datos de producción. Si has estado probando en la fase de pruebas durante una semana mientras los clientes hacen pedidos o los usuarios comentan en tu sitio de producción, un descuido al «pasar a producción» podría borrar todos esos datos nuevos.
Esta sección trata de la sincronización selectiva: mover sólo lo que pretendías cambiar, conservando los datos de producción que se crearon o modificaron mientras trabajabas en la puesta en escena.
Comprender lo que debe (y no debe) empujarse
Antes de pasar nada de la fase de ensayo a la de producción, párate a pensar: ¿Ha cambiado algo en el sitio activo desde que lo clonaste en la fase de ensayo?
Si no ha cambiado nada (tal vez sea un sitio nuevo o lo hayas bloqueado con el modo de mantenimiento), sigue adelante y envíalo todo. Estás a salvo.
¿Pero si han pasado cosas en producción mientras trabajabas? Ahora tienes que elegir con cuidado.
Seguro para empujar desde la puesta en escena:
- Archivos del tema (wp-content/themes/yourtheme/)
- Archivos de plugins (wp-content/plugins/)
- Nuevos archivos multimedia que hayas añadido en la fase de pruebas
- Contenido de la base de datos que hayas creado (nuevas entradas, páginas)
- Ajustes del plugin/tema (si has reconfigurado los ajustes)
Es peligroso sobrescribir en producción:
- Cuentas y perfiles de usuario (tablas wp_users, wp_usermeta)
- Comentarios sobre el contenido de producción (tabla wp_comments)
- Pedidos de WooCommerce realizados en producción (varias tablas woocommerce_*)
- Envíos de formularios de contacto recibidos en producción
- Cualquier contenido creado por visitantes/clientes durante tu trabajo de puesta en escena
La matriz de decisión crítica:
| Tipo de sitio | Puede Empujar con Seguridad | Debe ser Selectivo |
| Blog (sin comercio electrónico) | Base de datos completa si no se publicaron nuevos posts en producción | Excluir contenido nuevo de producción |
| Tienda WooCommerce | Sólo archivos de tema/plugin | NUNCA empujar la base de datos (borraría los pedidos) |
| Sitio de miembros | Archivos de temas/plugins | Excluir cuentas de usuario y datos de afiliación |
Métodos de puesta en escena
Método 1: Push sólo archivos
Este es el enfoque más seguro para los sitios activos. Transfieres los archivos de temas y plugins, pero dejas intacta la base de datos de producción.
Utilizando FTP/SFTP:
- Conéctate a staging y a producción mediante FTP
- Descarga la carpeta del tema actualizado desde la puesta en escena
- Súbela a producción, sobrescribiendo los archivos del tema existente
- Repite el proceso con las carpetas de plugins actualizadas
- Prueba el sitio de producción
Esto funciona muy bien para:
- Actualizaciones de temas
- Actualizaciones de plugins
- Añadir nuevos archivos multimedia
Esto no funciona para:
- Nuevas entradas/páginas creadas en staging
- Cambios en la configuración del plugin
- Actualizaciones de menú
- Cambios en la ubicación de los widgets
¿Por qué? Porque esos datos viven en la base de datos, no en archivos.
Método 2: Push Selectivo de Bases de Datos (Avanzado)
Si necesitas introducir cambios en la base de datos sin sobrescribir los datos de producción, tendrás que exportar tablas concretas.
Herramientas para ello:
- WP Migrate DB Pro (plugin) – Te permite seleccionar tablas específicas para empujar
- phpMyAdmin – Exportación/importación manual de tablas específicas
- WP-CLI – Operaciones con la base de datos desde la línea de comandos
Ejemplo de flujo de trabajo:
- Identifica qué tablas de la base de datos contienen tus cambios (normalmente wp_posts para el contenido, wp_options para la configuración)
- Exporta esas tablas específicas desde la puesta en escena
- Haz una copia de seguridad de la base de datos de producción (¡una copia de seguridad completa!)
- Importa las tablas específicas a producción
- Ejecuta buscar-reemplazar si las URL difieren entre puesta en escena/producción
Importante: Esto requiere entender la estructura de la base de datos de WordPress. La tabla wp_posts contiene entradas/páginas pero también menús de navegación. La tabla wp_options contiene configuraciones, pero también plugins activos. Importar las tablas incorrectas puede romper tu sitio.
Método 3: Push asistido por plugins
Algunos proveedores de alojamiento gestionado y plugins de migración ofrecen la función de empuje de montaje a producción con salvaguardas integradas:
- WP Staging Pro – Ofrece empuje selectivo con filtrado de tablas
- BlogVault – Incluye gestión por etapas con opciones de fusión
- Funciones de host gestionado – Cloudways, WP Engine, Kinsta, Flywheel incluyen staging push
Estas herramientas proporcionan GUIs para seleccionar lo que se debe empujar, reduciendo el riesgo de errores.
Lista de comprobación de la verificación posterior al empuje
Después de pasar los cambios de montaje a producción, prueba inmediatamente estas funciones:
Pruebas de función crítica:
- ¿Puedes iniciar sesión en el área de administración?
- ¿Las páginas frontales se cargan sin errores?
- ¿Los formularios se envían correctamente?
- ¿Funciona la búsqueda?
- Para comercio electrónico: ¿Pueden los usuarios añadir a la cesta y pasar por caja?
- Para afiliaciones: ¿Pueden los usuarios iniciar sesión?
Comprobaciones técnicas:
- Borra todas las cachés(caché del servidor, caché del plugin, caché del navegador)
- Comprueba si hay errores PHP (activa WP_DEBUG temporalmente si es necesario)
- Comprueba que SSL sigue funcionando
- Prueba en dispositivos móviles
- Comprueba los tiempos de carga de la página (no deberían ser drásticamente más lentos)
Verificación del contenido:
- Siguen apareciendo entradas/páginas recientes
- Los menús de navegación funcionan correctamente
- Los widgets aparecen en las ubicaciones correctas
- Las imágenes se cargan correctamente
Problemas comunes tras el empuje:
Errores 404 en todas las páginas excepto en la página de inicio:
Es necesario actualizar tu estructura de enlaces permanentes. Ve a Configuración → Enlaces permanentes y haz clic en «Guardar cambios» sin cambiar nada. Esto regenera el archivo .htaccess (o la configuración de nginx) con las reglas de reescritura adecuadas.
Pantalla blanca de la muerte:
Suele ser un conflicto de plugins o un error fatal de PHP. Accede a tu sitio mediante FTP y cambia el nombre de la carpeta wp-content/plugins/ por wp-content/plugins-disabled/. Esto desactiva todos los plugins. Si el sitio se carga, sabrás que se trata de un problema de plugins. Vuelve a cambiar el nombre de la carpeta y, a continuación, aísla el plugin problemático desactivándolo de uno en uno.
Error de conexión a la base de datos:
Si has sobrescrito accidentalmente wp-config.php durante el push, es posible que hayas roto las credenciales de la base de datos. Vuelve a introducir el nombre de la base de datos, el nombre de usuario y la contraseña correctos en wp-config.php.
Imágenes rotas o desaparecidas:
Comprueba la carpeta wp-content/uploads/. Si has transferido las subidas a producción, es posible que hayas sobrescrito las imágenes de producción. Restaura desde la copia de seguridad.
¿Cuál es un plan de retroceso seguro si fracasa mi empuje de puesta en escena?
Ten siempre una estrategia de reversión antes de pasar la puesta en escena a producción.
Antes de empujar:
- Haz una copia de seguridad completa de la producción (archivos y base de datos)
- Documenta exactamente lo que estás cambiando
- Anota la hora actual para saber qué copia de seguridad restaurar en caso necesario
- Comprueba que puedes acceder a producción mediante FTP/SSH en caso de que el área de administración quede inaccesible
Si se rompe algo:
Que no cunda el pánico. Éste es tu proceso de recuperación:
- Para problemas menores: Arréglalo in situ si conoces el problema exacto
- Para problemas graves: Restaura desde la copia de seguridad previa inmediatamente
- No puedes acceder al admin: Utiliza FTP para cambiar el nombre de la carpeta del plugin/tema recientemente actualizado para desactivarlo
- Pantalla blanca por todas partes: Sustituye todos los archivos de la copia de seguridad por FTP
- Problemas con la base de datos: Importa la copia de seguridad de tu base de datos previa al push mediante phpMyAdmin
La clave es tener esa copia de seguridad previa al empuje. Sin ella, recuperarse de un mal empuje es extremadamente difícil.
La lista de comprobación completa de 72 horas tras la migración
Juntemos todo en un plan de acción basado en un calendario. Esto tiene en cuenta la realidad de la propagación del DNS y prioriza las tareas que evitan el tiempo de inactividad o la pérdida de datos.
| Tarea | Finalizada |
|---|---|
| Inmediatamente después de la migración de WordPress (Hora 0-2) | |
| Confirma que el sitio se carga en la URL temporal proporcionada por el nuevo host | |
| Probar el inicio de sesión del administrador de WordPress en una URL temporal | |
| Haz clic en las páginas principales para comprobar si hay errores evidentes | |
| Haz ahora una copia de seguridad nueva (se convertirá en tu punto de restauración «post-migración»). | |
| Borra todas las cachés (si tienes un plugin de caché, bórralo) | |
| Probar la funcionalidad básica: formularios, búsqueda, inicio de sesión de usuario | |
| Después de la actualización del DNS (Hora 2-24) | |
| Localiza la dirección IP del servidor de tu nuevo host | |
| Accede a tu registrador de dominios o proveedor de DNS | |
| Actualiza el registro A de @ (dominio raíz) a la nueva IP | |
| Actualizar registro A de www a nueva IP | |
| Baja el TTL a 300 segundos si aún no lo has hecho | |
| Anota la hora exacta en que hiciste los cambios en el DNS | |
| Mantén activa la antigua cuenta de alojamiento (¡no la canceles todavía!) | |
| Configuración del correo electrónico | |
| Verificar que los registros MX siguen existiendo tras la actualización del DNS | |
| Si faltan registros MX, añádelos inmediatamente | |
| Añadir registro SPF si falta | |
| Envía un correo electrónico de prueba para comprobar el enrutamiento | |
| Configuración SSL | |
| Instala el certificado SSL una vez que el DNS apunte al nuevo servidor | |
| Activar la redirección HTTPS | |
| Activa la renovación automática de SSL si está disponible | |
| Durante la propagación del DNS (Hora 24-48) | |
| Comprueba WhatsMyDNS.net cada pocas horas para controlar la propagación | |
| Prueba regularmente tu sitio en modo incógnito (evita la caché) | |
| Busca advertencias de contenido mixto en la consola del navegador | |
| Si se encuentra contenido mixto: Ejecuta la búsqueda-sustitución de la base de datos o instala Really Simple SSL | |
| Prueba la entregabilidad del correo electrónico (envía mensajes de prueba desde WordPress) | |
| Comprueba que los formularios de contacto envían notificaciones | |
| Comprueba las integraciones críticas (procesadores de pago, analítica, etc.) | |
| Supervisa si hay errores 404 o enlaces rotos | |
| Una vez finalizada la propagación (Hora 48-72) | |
| Ejecuta un rastreo completo del sitio con Screaming Frog o una herramienta similar | |
| Comprueba si hay errores de rastreo en Google Search Console | |
| Genera un nuevo mapa del sitio XML y envíalo a Google | |
| Probar el rendimiento del sitio (GTmetrix, PageSpeed Insights) | |
| Verifica que la CDN funciona si utilizas una | |
| Configurar copias de seguridad automatizadas en el nuevo host | |
| Actualiza cualquier IP codificada en integraciones de terceros | |
| Programar la cancelación del alojamiento antiguo para dentro de 30 días (no inmediatamente) | |
| Tareas finales de optimización | |
| Revisar y ajustar la configuración de la caché | |
| Habilitar CDN si está disponible | |
| Configura la monitorización del tiempo de actividad (UptimeRobot, Pingdom) | |
| Actualiza la información de contacto de emergencia en la cuenta de acogida | |
| Documenta cualquier cambio de configuración para futuras referencias | |
⚠️ No hagas estas cosas todavía:
- No hagas cambios importantes de contenido (la propagación podría causar confusión)
- No canceles el alojamiento antiguo
- No elimines los registros DNS temporales si utilizaste el método del archivo hosts
¿Quieres migrar tu sitio WordPress con sólo unos clics?
Utiliza el plugin gratuito Cloudways WordPress Migrator para realizar migraciones ilimitadas y sin complicaciones, con el respaldo de la asistencia de expertos 24 horas al día, 7 días a la semana.
¿Cuáles son los errores más críticos que hay que evitar después de migrar WordPress?
Estos errores pueden causar problemas importantes:
❌ No canceles el alojamiento antiguo inmediatamente – Espera al menos 7-30 días para asegurarte de que todo es estable
❌ No te saltes la copia de seguridad previa al push – Necesitas un punto de restauración si el push de montaje sale mal
❌ No ignores las advertencias SSL – «Lo arreglaré más tarde» a menudo significa nunca, y los usuarios no confiarán en tu sitio web
❌ No olvides borrar TODAS las cachés: la caché del servidor, la caché del plugin, la caché CDN y la caché del navegador.
❌ No introduzcas cambios en la base de datos durante la propagación del DNS – Espera a que finalice la propagación para realizar operaciones importantes en la base de datos
Conclusión
Completar una lista de comprobación posterior a la migración no es un trabajo sexy, pero es lo que separa un sitio que funciona de uno que realmente rinde.
SSL, DNS y correo electrónico: estos tres problemas son los que más quebraderos de cabeza te darán después de cualquier migración. Sin embargo, hay buenas noticias: una vez que entiendes lo que ocurre bajo el capó, todos siguen patrones predecibles que puedes abordar.
¿Esas primeras 72 horas tras la migración? Es cuando todo se rompe. El DNS se propaga, el SSL lanza errores, los correos rebotan y descubres lo que se te olvidó. Sigue la lista de comprobación hora a hora y resiste el impulso de precipitarte.
Accede a nuestros recursos de migración de sitios web paso a paso
¿Qué hacer ahora?
¿Estás migrando? Empieza de forma sencilla. Confirma que tu sitio carga, pon en marcha el SSL y comprueba el DNS. Una cosa cada vez.
¿Planeando con antelación? Marca esta guía y elimina el TTL de tu DNS ahora. Ese simple movimiento te ahorrará horas de tiempo de propagación más adelante.
¿Te enfrentas a una crisis? Ve directamente a lo que no funciona. Solución de problemas de SSL, de DNS o de correo electrónico. Cada sección te lleva rápidamente del problema a la solución.
Mira, las migraciones ya son bastante estresantes sin el lío posterior a la migración. Al menos ahora sabes lo que te espera.
Zain Imran
Zain es ingeniero electrónico y MBA, y le encanta profundizar en las tecnologías para comunicar el valor que crean para las empresas. Interesado en arquitecturas de sistemas, optimizaciones y documentación técnica, se esfuerza por ofrecer perspectivas únicas a los lectores. Zain es aficionado a los deportes y le encanta dedicarse al desarrollo de aplicaciones como hobby.
