Guía para decidir mejor
Cómo revisar una web después de cambiar de servidor
Una portada operativa no demuestra que datos, correo e integraciones estén completos.
Después de cambiar de servidor, una portada que carga no demuestra que el traslado terminó. Hay que revisar rutas, datos, DNS, SSL, correo, tareas programadas y registros desde el nuevo entorno. Esta guía sirve para cualquier web; la verificación específica de WordPress añade sus comprobaciones de aplicación.
Identifica qué servidor responde
Comprueba resolución DNS desde varias redes y compara el destino esperado con el que responde la URL pública. Una caché local puede mostrar el servidor anterior: prueba otra conexión y no uses solo la IP que devuelve tu equipo. Conserva ambos servicios durante la ventana acordada y registra la hora de corte. Si ves una versión antigua, revisa por qué el dominio muestra la web anterior antes de copiar datos otra vez.
Recorre funciones, no solo páginas
| Área | Prueba de cierre |
|---|---|
| Contenido | Portada, páginas profundas, archivos e imágenes devuelven la versión prevista sin 404. |
| Datos | Registros nuevos y modificados están presentes; no se sobreescribe producción con una copia antigua. |
| Formularios | Envío de prueba recibido en el buzón correcto. |
| SSL | Certificado válido, redirección a HTTPS y recursos sin avisos de contenido mixto. |
| Procesos | Cron, colas, integraciones y webhooks se ejecutan una vez donde corresponde. |
Si es una tienda, comprueba con especial cuidado pedidos creados alrededor del corte. No repitas una importación de base que pueda borrar ventas recientes. Coordina una conciliación de pedidos con el propietario.
Compara comportamiento y errores
Revisa los registros de aplicación y servidor para 404, 5xx, errores PHP y problemas de permisos. Ejecuta una prueba de rendimiento comparable a la base previa: misma URL, región, estado de caché y horario similar. Un TTFB distinto puede deberse a red, redirecciones o aplicación, no solo a CPU. Comprueba también que analítica, canonical, robots y sitemap siguen apuntando a las URL definitivas.
Firma el cierre y conserva una salida
Documenta resultados, responsables y plazo para apagar el servidor antiguo. Mantén copia de ambos estados hasta confirmar correo, datos y tráfico residual. Si la revisión falla, decide si corregir en destino o volver al origen; cambiar DNS repetidamente sin plan puede complicar el diagnóstico. Para soporte, consulta el alcance de una migración acompañada. IDEIHOSTING no debe considerarse responsable de una aplicación o proveedor de correo externo sin acuerdo expreso.
Si la portada funciona pero las rutas interiores responden 404, revisa la reescritura y los enlaces permanentes de WordPress. Comprueba además que las tareas programadas siguen ejecutándose: una web visible puede haber perdido publicaciones o procesos de fondo.